summaryrefslogtreecommitdiff
path: root/contrib/bind9/doc
diff options
context:
space:
mode:
authorcvs2svn <cvs2svn@FreeBSD.org>2006-01-04 19:18:44 +0000
committercvs2svn <cvs2svn@FreeBSD.org>2006-01-04 19:18:44 +0000
commitc5589c3a048d325631da28757cff49d71b3aad5b (patch)
treea268a8788a4ed8cbf41cdc0538f8c4a146451537 /contrib/bind9/doc
parentb824835191139c577ca56bab6a86c7af4bd51c96 (diff)
Notes
Diffstat (limited to 'contrib/bind9/doc')
-rw-r--r--contrib/bind9/doc/Makefile.in29
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM-book.xml6658
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch01.html412
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch02.html130
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch03.html525
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch04.html716
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch05.html115
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch06.html3864
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch07.html200
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch08.html124
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.ch09.html388
-rw-r--r--contrib/bind9/doc/arm/Bv9ARM.html222
-rwxr-xr-xcontrib/bind9/doc/arm/Bv9ARM.pdf8964
-rw-r--r--contrib/bind9/doc/arm/Makefile.in63
-rw-r--r--contrib/bind9/doc/arm/README-SGML329
-rw-r--r--contrib/bind9/doc/arm/isc.color.gifbin6384 -> 0 bytes
-rw-r--r--contrib/bind9/doc/arm/nominum-docbook-html.dsl.in148
-rw-r--r--contrib/bind9/doc/arm/nominum-docbook-print.dsl.in42
-rw-r--r--contrib/bind9/doc/arm/validate.sh.in21
-rw-r--r--contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt336
-rw-r--r--contrib/bind9/doc/draft/draft-daigle-napstr-04.txt1232
-rw-r--r--contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt1960
-rw-r--r--contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt241
-rw-r--r--contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt240
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt928
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt393
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt561
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt562
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt1397
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt442
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt616
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt784
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt1457
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt560
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt896
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt3193
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt1849
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt839
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt928
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt639
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt754
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt335
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt334
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt560
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt1559
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt1740
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt2072
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt464
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt840
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt580
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt755
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt1235
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt1292
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt1501
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt730
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt466
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt580
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt1010
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt956
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt1120
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt1176
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt1344
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt1736
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt396
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt1321
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt1848
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt1969
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt1682
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt300
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt391
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt389
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt505
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt485
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt480
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt617
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt616
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt1588
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt951
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt1200
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt614
-rw-r--r--contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt519
-rw-r--r--contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt295
-rw-r--r--contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt1830
-rw-r--r--contrib/bind9/doc/draft/update46
-rw-r--r--contrib/bind9/doc/misc/Makefile.in36
-rw-r--r--contrib/bind9/doc/misc/dnssec84
-rw-r--r--contrib/bind9/doc/misc/format-options.pl36
-rw-r--r--contrib/bind9/doc/misc/ipv6113
-rw-r--r--contrib/bind9/doc/misc/migration255
-rw-r--r--contrib/bind9/doc/misc/migration-4to957
-rw-r--r--contrib/bind9/doc/misc/options386
-rw-r--r--contrib/bind9/doc/misc/rfc-compliance62
-rw-r--r--contrib/bind9/doc/misc/roadmap47
-rw-r--r--contrib/bind9/doc/misc/sdb169
-rw-r--r--contrib/bind9/doc/rfc/index103
-rw-r--r--contrib/bind9/doc/rfc/rfc1032.txt781
-rw-r--r--contrib/bind9/doc/rfc/rfc1033.txt1229
-rw-r--r--contrib/bind9/doc/rfc/rfc1034.txt3077
-rw-r--r--contrib/bind9/doc/rfc/rfc1035.txt3077
-rw-r--r--contrib/bind9/doc/rfc/rfc1101.txt787
-rw-r--r--contrib/bind9/doc/rfc/rfc1122.txt6844
-rw-r--r--contrib/bind9/doc/rfc/rfc1123.txt5782
-rw-r--r--contrib/bind9/doc/rfc/rfc1183.txt619
-rw-r--r--contrib/bind9/doc/rfc/rfc1348.txt227
-rw-r--r--contrib/bind9/doc/rfc/rfc1535.txt283
-rw-r--r--contrib/bind9/doc/rfc/rfc1536.txt675
-rw-r--r--contrib/bind9/doc/rfc/rfc1537.txt507
-rw-r--r--contrib/bind9/doc/rfc/rfc1591.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc1611.txt1683
-rw-r--r--contrib/bind9/doc/rfc/rfc1612.txt1795
-rw-r--r--contrib/bind9/doc/rfc/rfc1706.txt563
-rw-r--r--contrib/bind9/doc/rfc/rfc1712.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc1750.txt1683
-rw-r--r--contrib/bind9/doc/rfc/rfc1876.txt1011
-rw-r--r--contrib/bind9/doc/rfc/rfc1886.txt268
-rw-r--r--contrib/bind9/doc/rfc/rfc1982.txt394
-rw-r--r--contrib/bind9/doc/rfc/rfc1995.txt451
-rw-r--r--contrib/bind9/doc/rfc/rfc1996.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc2052.txt563
-rw-r--r--contrib/bind9/doc/rfc/rfc2104.txt620
-rw-r--r--contrib/bind9/doc/rfc/rfc2119.txt171
-rw-r--r--contrib/bind9/doc/rfc/rfc2133.txt1795
-rw-r--r--contrib/bind9/doc/rfc/rfc2136.txt1460
-rw-r--r--contrib/bind9/doc/rfc/rfc2137.txt619
-rw-r--r--contrib/bind9/doc/rfc/rfc2163.txt1459
-rw-r--r--contrib/bind9/doc/rfc/rfc2168.txt1123
-rw-r--r--contrib/bind9/doc/rfc/rfc2181.txt842
-rw-r--r--contrib/bind9/doc/rfc/rfc2230.txt619
-rw-r--r--contrib/bind9/doc/rfc/rfc2308.txt1067
-rw-r--r--contrib/bind9/doc/rfc/rfc2317.txt563
-rw-r--r--contrib/bind9/doc/rfc/rfc2373.txt1459
-rw-r--r--contrib/bind9/doc/rfc/rfc2374.txt675
-rw-r--r--contrib/bind9/doc/rfc/rfc2375.txt451
-rw-r--r--contrib/bind9/doc/rfc/rfc2418.txt1459
-rw-r--r--contrib/bind9/doc/rfc/rfc2535.txt2635
-rw-r--r--contrib/bind9/doc/rfc/rfc2536.txt339
-rw-r--r--contrib/bind9/doc/rfc/rfc2537.txt339
-rw-r--r--contrib/bind9/doc/rfc/rfc2538.txt563
-rw-r--r--contrib/bind9/doc/rfc/rfc2539.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc2540.txt339
-rw-r--r--contrib/bind9/doc/rfc/rfc2541.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc2553.txt2299
-rw-r--r--contrib/bind9/doc/rfc/rfc2671.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc2672.txt507
-rw-r--r--contrib/bind9/doc/rfc/rfc2673.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc2782.txt675
-rw-r--r--contrib/bind9/doc/rfc/rfc2825.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc2826.txt339
-rw-r--r--contrib/bind9/doc/rfc/rfc2845.txt843
-rw-r--r--contrib/bind9/doc/rfc/rfc2874.txt1123
-rw-r--r--contrib/bind9/doc/rfc/rfc2915.txt1011
-rw-r--r--contrib/bind9/doc/rfc/rfc2929.txt675
-rw-r--r--contrib/bind9/doc/rfc/rfc2930.txt899
-rw-r--r--contrib/bind9/doc/rfc/rfc2931.txt563
-rw-r--r--contrib/bind9/doc/rfc/rfc3007.txt507
-rw-r--r--contrib/bind9/doc/rfc/rfc3008.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc3071.txt563
-rw-r--r--contrib/bind9/doc/rfc/rfc3090.txt619
-rw-r--r--contrib/bind9/doc/rfc/rfc3110.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc3123.txt451
-rw-r--r--contrib/bind9/doc/rfc/rfc3152.txt227
-rw-r--r--contrib/bind9/doc/rfc/rfc3197.txt283
-rw-r--r--contrib/bind9/doc/rfc/rfc3225.txt339
-rw-r--r--contrib/bind9/doc/rfc/rfc3226.txt339
-rw-r--r--contrib/bind9/doc/rfc/rfc3258.txt619
-rw-r--r--contrib/bind9/doc/rfc/rfc3363.txt339
-rw-r--r--contrib/bind9/doc/rfc/rfc3364.txt619
-rw-r--r--contrib/bind9/doc/rfc/rfc3425.txt283
-rw-r--r--contrib/bind9/doc/rfc/rfc3445.txt563
-rw-r--r--contrib/bind9/doc/rfc/rfc3467.txt1739
-rw-r--r--contrib/bind9/doc/rfc/rfc3490.txt1235
-rw-r--r--contrib/bind9/doc/rfc/rfc3491.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc3492.txt1963
-rw-r--r--contrib/bind9/doc/rfc/rfc3493.txt2187
-rw-r--r--contrib/bind9/doc/rfc/rfc3513.txt1459
-rw-r--r--contrib/bind9/doc/rfc/rfc3596.txt451
-rw-r--r--contrib/bind9/doc/rfc/rfc3597.txt451
-rw-r--r--contrib/bind9/doc/rfc/rfc3645.txt1459
-rw-r--r--contrib/bind9/doc/rfc/rfc3655.txt451
-rw-r--r--contrib/bind9/doc/rfc/rfc3658.txt1067
-rw-r--r--contrib/bind9/doc/rfc/rfc3757.txt451
-rw-r--r--contrib/bind9/doc/rfc/rfc3833.txt899
-rw-r--r--contrib/bind9/doc/rfc/rfc3845.txt395
-rw-r--r--contrib/bind9/doc/rfc/rfc3901.txt283
-rw-r--r--contrib/bind9/doc/rfc/rfc4025.txt675
-rw-r--r--contrib/bind9/doc/rfc/rfc4033.txt1179
-rw-r--r--contrib/bind9/doc/rfc/rfc4034.txt1627
-rw-r--r--contrib/bind9/doc/rfc/rfc4035.txt2971
-rw-r--r--contrib/bind9/doc/rfc/rfc4074.txt339
-rw-r--r--contrib/bind9/doc/rfc/rfc4159.txt171
-rw-r--r--contrib/bind9/doc/rfc/rfc952.txt340
191 files changed, 0 insertions, 177250 deletions
diff --git a/contrib/bind9/doc/Makefile.in b/contrib/bind9/doc/Makefile.in
deleted file mode 100644
index 1e69dabdbabb5..0000000000000
--- a/contrib/bind9/doc/Makefile.in
+++ /dev/null
@@ -1,29 +0,0 @@
-# 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,
-# 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: 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
-# tree when doing a build using separate object directories.
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-top_srcdir = @top_srcdir@
-
-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
deleted file mode 100644
index 28ccb360afe03..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM-book.xml
+++ /dev/null
@@ -1,6658 +0,0 @@
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
- "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
- [<!ENTITY mdash "&#8212;">]>
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.59 2005/10/10 00:22:24 marka Exp $ -->
-
-<book>
-<title>BIND 9 Administrator Reference Manual</title>
-
- <bookinfo>
- <copyright>
- <year>2004</year>
- <year>2005</year>
- <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
- </copyright>
- <copyright>
- <year>2000</year>
- <year>2001</year>
- <year>2002</year>
- <year>2003</year>
- <holder>Internet Software Consortium.</holder>
- </copyright>
- </bookinfo>
-
- <chapter id="Bv9ARM.ch01">
- <title>Introduction </title>
- <para>The Internet Domain Name System (<acronym>DNS</acronym>) 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. <acronym>DNS</acronym> data is maintained in a group of distributed
- hierarchical databases.</para>
-
- <sect1>
- <title>Scope of Document</title>
-
- <para>The Berkeley Internet Name Domain (<acronym>BIND</acronym>) 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 (<acronym>ISC</acronym>)
- <acronym>BIND</acronym> version 9 software package for system
- administrators.</para>
-
- <para>This version of the manual corresponds to BIND version 9.3.</para>
-
- </sect1>
- <sect1><title>Organization of This Document</title>
- <para>In this document, <emphasis>Section 1</emphasis> introduces
- the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Section 2</emphasis>
- describes resource requirements for running <acronym>BIND</acronym> in various
- environments. Information in <emphasis>Section 3</emphasis> is
- <emphasis>task-oriented</emphasis> in its presentation and is
- organized functionally, to aid in the process of installing the
- <acronym>BIND</acronym> 9 software. The task-oriented section is followed by
- <emphasis>Section 4</emphasis>, which contains more advanced
- concepts that the system administrator may need for implementing
- certain options. <emphasis>Section 5</emphasis>
- describes the <acronym>BIND</acronym> 9 lightweight
- resolver. The contents of <emphasis>Section 6</emphasis> are
- organized as in a reference manual to aid in the ongoing
- maintenance of the software. <emphasis>Section 7
- </emphasis>addresses security considerations, and
- <emphasis>Section 8</emphasis> contains troubleshooting help. The
- main body of the document is followed by several
- <emphasis>Appendices</emphasis> which contain useful reference
- information, such as a <emphasis>Bibliography</emphasis> and
- historic information related to <acronym>BIND</acronym> and the Domain Name
- System.</para>
- </sect1>
- <sect1><title>Conventions Used in This Document</title>
-
- <para>In this document, we use the following general typographic
- conventions:</para>
-
-<informaltable>
- <tgroup cols = "2">
- <colspec colname = "1" colnum = "1" colwidth = "3.000in"/>
- <colspec colname = "2" colnum = "2" colwidth = "2.625in"/>
- <tbody>
- <row>
- <entry colname = "1">
-<para><emphasis>To
-describe:</emphasis></para></entry>
- <entry colname = "2">
-<para><emphasis>We use the style:</emphasis></para></entry>
- </row>
- <row>
- <entry colname = "1">
-<para>a pathname, filename, URL, hostname,
-mailing list name, or new term or concept</para></entry>
- <entry colname = "2"><para><filename>Fixed width</filename></para></entry>
- </row>
- <row>
- <entry colname = "1"><para>literal user
-input</para></entry>
- <entry colname = "2"><para><userinput>Fixed Width Bold</userinput></para></entry>
- </row>
- <row>
- <entry colname = "1"><para>program output</para></entry>
- <entry colname = "2"><para><computeroutput>Fixed Width</computeroutput></para></entry>
- </row>
- </tbody>
- </tgroup>
-</informaltable>
-
- <para>The following conventions are used in descriptions of the
-<acronym>BIND</acronym> configuration file:<informaltable colsep = "0" frame = "all" rowsep = "0">
- <tgroup cols = "2" colsep = "0" rowsep = "0"
- tgroupstyle = "2Level-table">
- <colspec colname = "1" colnum = "1" colsep = "0" colwidth = "3.000in"/>
- <colspec colname = "2" colnum = "2" colsep = "0" colwidth = "2.625in"/>
- <tbody>
- <row rowsep = "0">
- <entry colname = "1" colsep = "1" rowsep = "1"><para><emphasis>To
-describe:</emphasis></para></entry>
- <entry colname = "2" rowsep = "1"><para><emphasis>We use the style:</emphasis></para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1" colsep = "1" rowsep = "1"><para>keywords</para></entry>
- <entry colname = "2" rowsep = "1"><para><literal>Fixed Width</literal></para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1" colsep = "1" rowsep = "1"><para>variables</para></entry>
- <entry colname = "2" rowsep = "1"><para><varname>Fixed Width</varname></para></entry>
- </row>
-<row rowsep = "0">
-<entry colname = "1" colsep = "1"><para>Optional input</para></entry>
- <entry colname = "2"><para><optional>Text is enclosed in square brackets</optional></para></entry>
-</row>
-</tbody>
-</tgroup></informaltable></para></sect1>
-<sect1><title>The Domain Name System (<acronym>DNS</acronym>)</title>
-<para>The purpose of this document is to explain the installation
-and upkeep of the <acronym>BIND</acronym> software package, and we
-begin by reviewing the fundamentals of the Domain Name System
-(<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>.
-</para>
-
-<sect2>
-<title>DNS Fundamentals</title>
-
-<para>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.</para>
-
-<para>Clients look up information in the DNS by calling a
-<emphasis>resolver</emphasis> library, which sends queries to one or
-more <emphasis>name servers</emphasis> and interprets the responses.
-The <acronym>BIND</acronym> 9 software distribution contains a
-name server, <command>named</command>, and two resolver
-libraries, <command>liblwres</command> and <command>libbind</command>.
-</para>
-
-</sect2><sect2>
-<title>Domains and Domain Names</title>
-
-<para>The data stored in the DNS is identified by <emphasis>domain
-names</emphasis> that are organized as a tree according to
-organizational or administrative boundaries. Each node of the tree,
-called a <emphasis>domain</emphasis>, 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 <emphasis>root</emphasis> 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.</para>
-
-<para>For example, a domain name for a host at the
-company <emphasis>Example, Inc.</emphasis> could be
-<literal>mail.example.com</literal>,
-where <literal>com</literal> is the
-top level domain to which
-<literal>ourhost.example.com</literal> belongs,
-<literal>example</literal> is
-a subdomain of <literal>com</literal>, and
-<literal>ourhost</literal> is the
-name of the host.</para>
-
-<para>For administrative purposes, the name space is partitioned into
-areas called <emphasis>zones</emphasis>, 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 <emphasis>name
-server</emphasis>, which answers queries about the zone using the
-<emphasis>DNS protocol</emphasis>.
-</para>
-
-<para>The data associated with each domain name is stored in the
-form of <emphasis>resource records</emphasis> (<acronym>RR</acronym>s).
-Some of the supported resource record types are described in
-<xref linkend="types_of_resource_records_and_when_to_use_them"/>.</para>
-
-<para>For more detailed information about the design of the DNS and
-the DNS protocol, please refer to the standards documents listed in
-<xref linkend="rfcs"/>.</para>
-</sect2>
-
-<sect2><title>Zones</title>
-<para>To properly operate a name server, it is important to understand
-the difference between a <emphasis>zone</emphasis>
-and a <emphasis>domain</emphasis>.</para>
-
-<para>As we stated previously, a zone is a point of delegation in
-the <acronym>DNS</acronym> 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
-<emphasis>NS records</emphasis> in the
-parent zone, which should be matched by equivalent NS records at
-the root of the delegated zone.</para>
-
-<para>For instance, consider the <literal>example.com</literal>
-domain which includes names
-such as <literal>host.aaa.example.com</literal> and
-<literal>host.bbb.example.com</literal> even though
-the <literal>example.com</literal> zone includes
-only delegations for the <literal>aaa.example.com</literal> and
-<literal>bbb.example.com</literal> 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 <acronym>DNS</acronym> tree is a
-<emphasis>domain</emphasis>, even if it is
-<emphasis>terminal</emphasis>, that is, has no
-<emphasis>subdomains</emphasis>. 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.</para>
-
-<para>Though <acronym>BIND</acronym> is called a "domain name server",
-it deals primarily in terms of zones. The master and slave
-declarations in the <filename>named.conf</filename> file specify
-zones, not domains. When you ask some other site if it is willing to
-be a slave server for your <emphasis>domain</emphasis>, you are
-actually asking for slave service for some collection of zones.</para>
-</sect2>
-
-<sect2><title>Authoritative Name Servers</title>
-
-<para>Each zone is served by at least
-one <emphasis>authoritative name server</emphasis>,
-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.
-</para>
-
-<para>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
-<command>dig</command> (<xref linkend="diagnostic_tools"/>).</para>
-
-<sect3><title>The Primary Master</title>
-
-<para>
-The authoritative server where the master copy of the zone data is maintained is
-called the <emphasis>primary master</emphasis> server, or simply the
-<emphasis>primary</emphasis>. 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 <emphasis>zone file</emphasis> or <emphasis>master file</emphasis>.</para>
-</sect3>
-
-<sect3><title>Slave Servers</title>
-<para>The other authoritative servers, the <emphasis>slave</emphasis>
-servers (also known as <emphasis>secondary</emphasis> servers) load
-the zone contents from another server using a replication process
-known as a <emphasis>zone transfer</emphasis>. 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.</para>
-</sect3>
-
-<sect3><title>Stealth Servers</title>
-
-<para>Usually all of the zone's authoritative servers are listed in
-NS records in the parent zone. These NS records constitute
-a <emphasis>delegation</emphasis> of the zone from the parent.
-The authoritative servers are also listed in the zone file itself,
-at the <emphasis>top level</emphasis> or <emphasis>apex</emphasis>
-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.</para>
-
-<para>A <emphasis>stealth server</emphasis> 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.</para>
-
-<para>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.</para>
-
-</sect3>
-
-</sect2>
-<sect2>
-
-<title>Caching Name Servers</title>
-
-<para>The resolver libraries provided by most operating systems are
-<emphasis>stub resolvers</emphasis>, 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 <emphasis>recursive</emphasis> name server; it performs
-<emphasis>recursive lookups</emphasis> for local clients.</para>
-
-<para>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
-<emphasis>recursive server</emphasis> and
-<emphasis>caching server</emphasis> are often used synonymously.</para>
-
-<para>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.
-</para>
-
-<sect3><title>Forwarding</title>
-
-<para>Even a caching name server does not necessarily perform
-the complete recursive lookup itself. Instead, it can
-<emphasis>forward</emphasis> some or all of the queries
-that it cannot satisfy from its cache to another caching name server,
-commonly referred to as a <emphasis>forwarder</emphasis>.
-</para>
-
-<para>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 <acronym>DNS</acronym> 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 <acronym>DNS</acronym> 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.</para>
-</sect3>
-
-</sect2>
-
-<sect2><title>Name Servers in Multiple Roles</title>
-
-<para>The <acronym>BIND</acronym> 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.</para>
-
-<para>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 <emphasis>authoritative-only</emphasis> 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 <emphasis>caching-only</emphasis> server)
-does not need to be reachable from the Internet at large and can
-be placed inside a firewall.</para>
-
- </sect2>
- </sect1>
-
-</chapter>
-
-<chapter id="Bv9ARM.ch02"><title><acronym>BIND</acronym> Resource Requirements</title>
-
-<sect1>
-<title>Hardware requirements</title>
-
-<para><acronym>DNS</acronym> hardware requirements have traditionally been quite modest.
-For many installations, servers that have been pensioned off from
-active duty have performed admirably as <acronym>DNS</acronym> servers.</para>
-<para>The DNSSEC and IPv6 features of <acronym>BIND</acronym> 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.
-<acronym>BIND</acronym> 9 is fully multithreaded, allowing full utilization of
-multiprocessor systems for installations that need it.</para></sect1>
-<sect1><title>CPU Requirements</title>
-<para>CPU requirements for <acronym>BIND</acronym> 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.</para></sect1>
-
-<sect1><title>Memory Requirements</title>
-<para>The memory of the server has to be large enough to fit the
-cache and zones loaded off disk. The <command>max-cache-size</command>
-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 <acronym>DNS</acronym>
-traffic. It is still good practice to have enough memory to load
-all zone and cache data into memory &mdash; 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.</para></sect1>
-
-<sect1><title>Name Server Intensive Environment Issues</title>
-<para>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
-the bandwidth used by external name lookups. The second alternative
-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.</para></sect1>
-
-<sect1><title>Supported Operating Systems</title>
-<para>ISC <acronym>BIND</acronym> 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.</para>
-</sect1>
-</chapter>
-
-<chapter id="Bv9ARM.ch03">
-<title>Name Server Configuration</title>
-<para>In this section we provide some suggested configurations along
-with guidelines for their use. We also address the topic of reasonable
-option setting.</para>
-
-<sect1 id="sample_configuration">
-<title>Sample Configurations</title>
-<sect2>
-<title>A Caching-only Name Server</title>
-<para>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 <command>allow-query</command>
-option. Alternatively, the same effect could be achieved using suitable
-firewall rules.</para>
-
-<programlisting>
-// 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
- allow-query { corpnets; };
-};
-// Provide a reverse mapping for the loopback address 127.0.0.1
-zone "0.0.127.in-addr.arpa" {
- type master;
- file "localhost.rev";
- notify no;
-};
-</programlisting>
-</sect2>
-
-<sect2>
-<title>An Authoritative-only Name Server</title>
-<para>This sample configuration is for an authoritative-only server
-that is the master server for "<filename>example.com</filename>"
-and a slave for the subdomain "<filename>eng.example.com</filename>".</para>
-
-<programlisting>
-options {
- directory "/etc/namedb"; // Working directory
- allow-query { any; }; // This is the default
- recursion no; // Do not provide recursive service
-};
-
-// Provide a reverse mapping for the loopback address 127.0.0.1
-zone "0.0.127.in-addr.arpa" {
- type master;
- file "localhost.rev";
- notify no;
-};
-// We are the master server for example.com
-zone "example.com" {
- type master;
- file "example.com.db";
- // IP addresses of slave servers allowed to transfer example.com
- allow-transfer {
- 192.168.4.14;
- 192.168.5.53;
- };
-};
-// We are a slave server for eng.example.com
-zone "eng.example.com" {
- type slave;
- file "eng.example.com.bk";
- // IP address of eng.example.com master server
- masters { 192.168.4.12; };
-};
-</programlisting>
-</sect2>
-</sect1>
-
-<sect1>
-<title>Load Balancing</title>
-
-<para>A primitive form of load balancing can be achieved in
-the <acronym>DNS</acronym> by using multiple A records for one name.</para>
-
-<para>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:</para>
-
-<informaltable colsep = "0" rowsep = "0">
-<tgroup cols = "5" colsep = "0" rowsep = "0" tgroupstyle = "2Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.500in"/>
-<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "0.750in"/>
-<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "0.750in"/>
-<colspec colname = "5" colnum = "5" colsep = "0" colwidth = "2.028in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para>Name</para></entry>
-<entry colname = "2"><para>TTL</para></entry>
-<entry colname = "3"><para>CLASS</para></entry>
-<entry colname = "4"><para>TYPE</para></entry>
-<entry colname = "5"><para>Resource Record (RR) Data</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>www</literal></para></entry>
-<entry colname = "2"><para><literal>600</literal></para></entry>
-<entry colname = "3"><para><literal>IN</literal></para></entry>
-<entry colname = "4"><para><literal>A</literal></para></entry>
-<entry colname = "5"><para><literal>10.0.0.1</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para><literal>600</literal></para></entry>
-<entry colname = "3"><para><literal>IN</literal></para></entry>
-<entry colname = "4"><para><literal>A</literal></para></entry>
-<entry colname = "5"><para><literal>10.0.0.2</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para><literal>600</literal></para></entry>
-<entry colname = "3"><para><literal>IN</literal></para></entry>
-<entry colname = "4"><para><literal>A</literal></para></entry>
-<entry colname = "5"><para><literal>10.0.0.3</literal></para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- <para>When a resolver queries for these records, <acronym>BIND</acronym> 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.</para>
- <para>For more detail on ordering responses, check the
- <command>rrset-order</command> substatement in the
- <command>options</command> statement, see
- <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
- This substatement is not supported in
- <acronym>BIND</acronym> 9, and only the ordering scheme described above is
- available.</para>
-
-</sect1>
-
-<sect1>
-<title>Name Server Operations</title>
-
-<sect2>
-<title>Tools for Use With the Name Server Daemon</title>
-<para>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 </para>
-<sect3 id="diagnostic_tools">
-<title>Diagnostic Tools</title>
-<para>The <command>dig</command>, <command>host</command>, and
-<command>nslookup</command> programs are all command line tools
-for manually querying name servers. They differ in style and
-output format.
-</para>
-
-<variablelist>
-<varlistentry>
-<term id="dig"><command>dig</command></term>
-<listitem>
-<para>The domain information groper (<command>dig</command>)
-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.</para>
-<cmdsynopsis label="Usage">
- <command>dig</command>
- <arg>@<replaceable>server</replaceable></arg>
- <arg choice="plain"><replaceable>domain</replaceable></arg>
- <arg><replaceable>query-type</replaceable></arg>
- <arg><replaceable>query-class</replaceable></arg>
- <arg>+<replaceable>query-option</replaceable></arg>
- <arg>-<replaceable>dig-option</replaceable></arg>
- <arg>%<replaceable>comment</replaceable></arg>
-</cmdsynopsis>
-<para>The usual simple use of dig will take the form</para>
-<simpara><command>dig @server domain query-type query-class</command></simpara>
-<para>For more information and a list of available commands and
-options, see the <command>dig</command> man page.</para>
-</listitem>
-</varlistentry>
-
-<varlistentry>
-<term><command>host</command></term>
-<listitem>
-<para>The <command>host</command> 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.</para>
-<cmdsynopsis label="Usage">
- <command>host</command>
- <arg>-aCdlrTwv</arg>
- <arg>-c <replaceable>class</replaceable></arg>
- <arg>-N <replaceable>ndots</replaceable></arg>
- <arg>-t <replaceable>type</replaceable></arg>
- <arg>-W <replaceable>timeout</replaceable></arg>
- <arg>-R <replaceable>retries</replaceable></arg>
- <arg choice="plain"><replaceable>hostname</replaceable></arg>
- <arg><replaceable>server</replaceable></arg>
-</cmdsynopsis>
-<para>For more information and a list of available commands and
-options, see the <command>host</command> man page.</para>
-</listitem>
-</varlistentry>
-
-<varlistentry>
-<term><command>nslookup</command></term>
-<listitem>
-<para><command>nslookup</command> 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.</para>
-<cmdsynopsis label="Usage">
- <command>nslookup</command>
- <arg rep="repeat">-option</arg>
- <group>
- <arg><replaceable>host-to-find</replaceable></arg>
- <arg>- <arg>server</arg></arg>
- </group>
-</cmdsynopsis>
-<para>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.</para>
-<para>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.</para>
-<para>Due to its arcane user interface and frequently inconsistent
-behavior, we do not recommend the use of <command>nslookup</command>.
-Use <command>dig</command> instead.</para>
-</listitem>
-
-</varlistentry>
-</variablelist>
-</sect3>
-
-<sect3 id="admin_tools">
- <title>Administrative Tools</title>
- <para>Administrative tools play an integral part in the management
-of a server.</para>
- <variablelist>
- <varlistentry id="named-checkconf" xreflabel="Named Configuration Checking application">
- <term><command>named-checkconf</command></term>
- <listitem>
- <para>The <command>named-checkconf</command> program
- checks the syntax of a <filename>named.conf</filename> file.</para>
- <cmdsynopsis label="Usage">
- <command>named-checkconf</command>
- <arg>-jvz</arg>
- <arg>-t <replaceable>directory</replaceable></arg>
- <arg><replaceable>filename</replaceable></arg>
- </cmdsynopsis>
- </listitem>
- </varlistentry>
- <varlistentry id="named-checkzone" xreflabel="Zone Checking application">
- <term><command>named-checkzone</command></term>
- <listitem>
- <para>The <command>named-checkzone</command> program checks a master file for
- syntax and consistency.</para>
- <cmdsynopsis label="Usage">
- <command>named-checkzone</command>
- <arg>-djqvD</arg>
- <arg>-c <replaceable>class</replaceable></arg>
- <arg>-o <replaceable>output</replaceable></arg>
- <arg>-t <replaceable>directory</replaceable></arg>
- <arg>-w <replaceable>directory</replaceable></arg>
- <arg>-k <replaceable>(ignore|warn|fail)</replaceable></arg>
- <arg>-n <replaceable>(ignore|warn|fail)</replaceable></arg>
- <arg choice="plain"><replaceable>zone</replaceable></arg>
- <arg><replaceable>filename</replaceable></arg>
- </cmdsynopsis>
- </listitem>
- </varlistentry>
- <varlistentry id="rndc" xreflabel="Remote Name Daemon Control application">
- <term><command>rndc</command></term>
- <listitem>
- <para>The remote name daemon control
- (<command>rndc</command>) program allows the system
- administrator to control the operation of a name server.
- If you run <command>rndc</command> without any options
- it will display a usage message as follows:</para>
- <cmdsynopsis label="Usage">
- <command>rndc</command>
- <arg>-c <replaceable>config</replaceable></arg>
- <arg>-s <replaceable>server</replaceable></arg>
- <arg>-p <replaceable>port</replaceable></arg>
- <arg>-y <replaceable>key</replaceable></arg>
- <arg choice="plain"><replaceable>command</replaceable></arg>
- <arg rep="repeat"><replaceable>command</replaceable></arg>
- </cmdsynopsis>
- <para><command>command</command> is one of the following:</para>
-
-<variablelist>
-
- <varlistentry><term><userinput>reload</userinput></term>
- <listitem><para>Reload configuration file and zones.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><userinput>reload <replaceable>zone</replaceable>
- <optional><replaceable>class</replaceable>
- <optional><replaceable>view</replaceable></optional></optional></userinput></term>
- <listitem><para>Reload the given zone.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><userinput>refresh <replaceable>zone</replaceable>
- <optional><replaceable>class</replaceable>
- <optional><replaceable>view</replaceable></optional></optional></userinput></term>
- <listitem><para>Schedule zone maintenance for the given zone.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><userinput>retransfer <replaceable>zone</replaceable>
- <optional><replaceable>class</replaceable>
- <optional><replaceable>view</replaceable></optional></optional></userinput></term>
- <listitem><para>Retransfer the given zone from the master.</para></listitem>
- </varlistentry>
-
- <varlistentry> <term><userinput>freeze <optional><replaceable>zone</replaceable>
- <optional><replaceable>class</replaceable>
- <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
- <listitem><para>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.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><userinput>thaw <optional><replaceable>zone</replaceable>
- <optional><replaceable>class</replaceable>
- <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
- <listitem><para>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 thawed, dynamic updates
- will no longer be refused.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><userinput>notify <replaceable>zone</replaceable>
- <optional><replaceable>class</replaceable>
- <optional><replaceable>view</replaceable></optional></optional></userinput></term>
- <listitem><para>Resend NOTIFY messages for the zone</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>reconfig</userinput></term>
- <listitem><para>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 <command>reload</command> when there
- is a large number of zones because it avoids the need to examine the
- modification times of the zones files.
- </para></listitem>
- </varlistentry>
-
- <varlistentry><term><userinput>stats</userinput></term>
- <listitem><para>Write server statistics to the statistics file.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><userinput>querylog</userinput></term>
- <listitem><para>Toggle query logging. Query logging can also be enabled
- by explicitly directing the <command>queries</command>
- <command>category</command> to a <command>channel</command> in the
- <command>logging</command> section of
- <filename>named.conf</filename>.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>dumpdb <optional>-all|-cache|-zone</optional> <optional><replaceable>view ...</replaceable></optional></userinput></term>
- <listitem><para>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.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>stop <optional>-p</optional></userinput></term>
- <listitem><para>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. If -p is specified named's process id is returned.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>halt <optional>-p</optional></userinput></term>
- <listitem><para>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. If -p is specified named's process id is returned.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>trace</userinput></term>
- <listitem><para>Increment the servers debugging level by one. </para></listitem></varlistentry>
-
- <varlistentry><term><userinput>trace <replaceable>level</replaceable></userinput></term>
- <listitem><para>Sets the server's debugging level to an explicit
- value.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>notrace</userinput></term>
- <listitem><para>Sets the server's debugging level to 0.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>flush</userinput></term>
- <listitem><para>Flushes the server's cache.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>flushname</userinput> <replaceable>name</replaceable></term>
- <listitem><para>Flushes the given name from the server's cache.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>status</userinput></term>
- <listitem><para>Display status of the server.
-Note the number of zones includes the internal <command>bind/CH</command> zone
-and the default <command>./IN</command> hint zone if there is not a
-explicit root zone configured.</para></listitem></varlistentry>
-
- <varlistentry><term><userinput>recursing</userinput></term>
- <listitem><para>Dump the list of queries named is currently recursing
- on.
- </para></listitem></varlistentry>
-
-</variablelist>
-
-<para>In <acronym>BIND</acronym> 9.2, <command>rndc</command>
-supports all the commands of the BIND 8 <command>ndc</command>
-utility except <command>ndc start</command> and
-<command>ndc restart</command>, which were also
-not supported in <command>ndc</command>'s channel mode.</para>
-
-<para>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
-<command>rndc</command> configuration file is
-<filename>/etc/rndc.conf</filename>, but an alternate
-location can be specified with the <option>-c</option>
-option. If the configuration file is not found,
-<command>rndc</command> will also look in
-<filename>/etc/rndc.key</filename> (or whatever
-<varname>sysconfdir</varname> was defined when
-the <acronym>BIND</acronym> build was configured).
-The <filename>rndc.key</filename> file is generated by
-running <command>rndc-confgen -a</command> as described in
-<xref linkend="controls_statement_definition_and_usage"/>.</para>
-
-<para>The format of the configuration file is similar to
-that of <filename>named.conf</filename>, but limited to
-only four statements, the <command>options</command>,
-<command>key</command>, <command>server</command> and
-<command>include</command>
-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.</para>
-
-<para>The <command>options</command> statement has three clauses:
-<command>default-server</command>, <command>default-key</command>,
-and <command>default-port</command>.
-<command>default-server</command> takes a
-host name or address argument and represents the server that will
-be contacted if no <option>-s</option>
-option is provided on the command line.
-<command>default-key</command> takes
-the name of a key as its argument, as defined by a <command>key</command> statement.
-<command>default-port</command> specifies the port to which
-<command>rndc</command> should connect if no
-port is given on the command line or in a
-<command>server</command> statement.</para>
-
-<para>The <command>key</command> statement defines an key to be used
-by <command>rndc</command> when authenticating with
-<command>named</command>. Its syntax is identical to the
-<command>key</command> statement in named.conf.
-The keyword <userinput>key</userinput> is
-followed by a key name, which must be a valid
-domain name, though it need not actually be hierarchical; thus,
-a string like "<userinput>rndc_key</userinput>" is a valid name.
-The <command>key</command> statement has two clauses:
-<command>algorithm</command> and <command>secret</command>.
-While the configuration parser will accept any string as the argument
-to algorithm, currently only the string "<userinput>hmac-md5</userinput>"
-has any meaning. The secret is a base-64 encoded string.</para>
-
-<para>The <command>server</command> statement associates a key
-defined using the <command>key</command> statement with a server.
-The keyword <userinput>server</userinput> is followed by a
-host name or address. The <command>server</command> statement
-has two clauses: <command>key</command> and <command>port</command>.
-The <command>key</command> clause specifies the name of the key
-to be used when communicating with this server, and the
-<command>port</command> clause can be used to
-specify the port <command>rndc</command> should connect
-to on the server.</para>
-
-<para>A sample minimal configuration file is as follows:</para>
-<programlisting>
-key rndc_key {
- algorithm "hmac-md5";
- secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
-};
-options {
- default-server 127.0.0.1;
- default-key rndc_key;
-};
-</programlisting>
-
-<para>This file, if installed as <filename>/etc/rndc.conf</filename>,
-would allow the command:</para>
-
-<para><prompt>$ </prompt><userinput>rndc reload</userinput></para>
-
-<para>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:</para>
-<programlisting>
-controls {
- inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
-};
-</programlisting>
-<para>and it had an identical key statement for
-<literal>rndc_key</literal>.</para>
-
-<para>Running the <command>rndc-confgen</command> program will
-conveniently create a <filename>rndc.conf</filename>
-file for you, and also display the
-corresponding <command>controls</command> statement that you need to
-add to <filename>named.conf</filename>. Alternatively,
-you can run <command>rndc-confgen -a</command> to set up
-a <filename>rndc.key</filename> file and not modify
-<filename>named.conf</filename> at all.
-</para>
-
- </listitem>
- </varlistentry>
- </variablelist>
-
- </sect3>
- </sect2>
-<sect2>
-
-<title>Signals</title>
-<para>Certain UNIX signals cause the name server to take specific
-actions, as described in the following table. These signals can
-be sent using the <command>kill</command> command.</para>
-<informaltable frame = "all" ><tgroup cols = "2">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.125in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.000in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><command>SIGHUP</command></para></entry>
-<entry colname = "2"><para>Causes the server to read <filename>named.conf</filename> and
-reload the database. </para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>SIGTERM</command></para></entry>
-<entry colname = "2"><para>Causes the server to clean up and exit.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1">
-<para><command>SIGINT</command></para>
-</entry>
- <entry colname = "2"><para>Causes the server to clean up and exit.</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </sect2>
- </sect1>
- </chapter>
-
-<chapter id="Bv9ARM.ch04">
-<title>Advanced DNS Features</title>
-
-<sect1 id="notify">
-
-<title>Notify</title>
-<para><acronym>DNS</acronym> NOTIFY is a mechanism that allows master
-servers to notify their slave servers of changes to a zone's data. In
-response to a <command>NOTIFY</command> 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.</para>
-
-<para><acronym>DNS</acronym>
-For more information about
-<command>NOTIFY</command>, see the description of the
-<command>notify</command> option in <xref linkend="boolean_options"/> and
-the description of the zone option <command>also-notify</command> in
-<xref linkend="zone_transfers"/>. The <command>NOTIFY</command>
-protocol is specified in RFC 1996.
-</para>
-
-</sect1>
-
-<sect1 id="dynamic_update">
-<title>Dynamic Update</title>
-
- <para>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.</para>
-
- <para>Dynamic update is enabled on a zone-by-zone basis, by
- including an <command>allow-update</command> or
- <command>update-policy</command> clause in the
- <command>zone</command> statement.</para>
-
- <para>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.</para>
-
- <sect2 id="journal">
- <title>The journal file</title>
-
- <para>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 the first dynamic update takes place. The name of
- the journal file is formed by appending the
- extension <filename>.jnl</filename> to the
- name of the corresponding zone file. The journal file is in a
- binary format and should not be edited manually.</para>
-
- <para>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.</para>
-
- <para>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.</para>
-
- <para>Changes that result from incoming incremental zone transfers are also
- journalled in a similar way.</para>
-
- <para>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 <command>rndc stop</command>.</para>
-
- <para>If you have to make changes to a dynamic zone
- manually, the following procedure will work: Disable dynamic updates
- to the zone using
- <command>rndc freeze <replaceable>zone</replaceable></command>.
- This will also remove the zone's <filename>.jnl</filename> file
- and update the master file. Edit the zone file. Run
- <command>rndc unfreeze <replaceable>zone</replaceable></command>
- to reload the changed zone and re-enable dynamic updates.</para>
-
- </sect2>
-
-</sect1>
-
-<sect1 id="incremental_zone_transfers">
-<title>Incremental Zone Transfers (IXFR)</title>
-
-<para>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 <xref linkend="proposed_standards"/>.</para>
-
-<para>When acting as a master, <acronym>BIND</acronym> 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
-<command>ixfr-from-differences</command> is set
-to <userinput>yes</userinput>.
-</para>
-
-<para>When acting as a slave, <acronym>BIND</acronym> 9 will
-attempt to use IXFR unless
-it is explicitly disabled. For more information about disabling
-IXFR, see the description of the <command>request-ixfr</command> clause
-of the <command>server</command> statement.</para>
-</sect1>
-
-<sect1><title>Split DNS</title>
-<para>Setting up different views, or visibility, of the DNS space to
-internal and external resolvers is usually referred to as a <emphasis>Split
-DNS</emphasis> setup. There are several reasons an organization
-would want to set up its DNS this way.</para>
-<para>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.</para>
-<para>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.</para>
-<para>Here is an example of a split DNS setup:</para>
-<para>Let's say a company named <emphasis>Example, Inc.</emphasis>
-(<literal>example.com</literal>)
-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.</para>
-<para><emphasis>Example, Inc.</emphasis> 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.</para>
-<para>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.</para>
-<para>The internal servers will be configured to forward all queries,
-except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>,
-and <filename>site2.example.com</filename>, to the servers in the
-DMZ. These internal servers will have complete sets of information
-for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>,<emphasis> </emphasis><filename>site1.internal</filename>,
-and <filename>site2.internal</filename>.</para>
-<para>To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
-the internal name servers must be configured to disallow all queries
-to these domains from any external hosts, including the bastion
-hosts.</para>
-<para>The external servers, which are on the bastion hosts, will
-be configured to serve the "public" version of the <filename>site1</filename> and <filename>site2.example.com</filename> zones.
-This could include things such as the host records for public servers
-(<filename>www.example.com</filename> and <filename>ftp.example.com</filename>),
-and mail exchange (MX) records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).</para>
-<para>In addition, the public <filename>site1</filename> and <filename>site2.example.com</filename> 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.</para>
-<para>Here's an example of a wildcard MX record:</para>
-<programlisting>* IN MX 10 external1.example.com.</programlisting>
-<para>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.</para>
-<para>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.</para>
-<para>In order for all this to work properly, internal clients will
-need to be configured to query <emphasis>only</emphasis> the internal
-name servers for DNS queries. This could also be enforced via selective
-filtering on the network.</para>
-<para>If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s
-internal clients will now be able to:</para>
-<itemizedlist><listitem>
- <simpara>Look up any hostnames in the <literal>site1</literal> and
-<literal>site2.example.com</literal> zones.</simpara></listitem>
-<listitem>
- <simpara>Look up any hostnames in the <literal>site1.internal</literal> and
-<literal>site2.internal</literal> domains.</simpara></listitem>
-<listitem>
- <simpara>Look up any hostnames on the Internet.</simpara></listitem>
-<listitem>
- <simpara>Exchange mail with internal AND external people.</simpara></listitem></itemizedlist>
-<para>Hosts on the Internet will be able to:</para>
-<itemizedlist><listitem>
- <simpara>Look up any hostnames in the <literal>site1</literal> and
-<literal>site2.example.com</literal> zones.</simpara></listitem>
-<listitem>
- <simpara>Exchange mail with anyone in the <literal>site1</literal> and
-<literal>site2.example.com</literal> zones.</simpara></listitem></itemizedlist>
-
- <para>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 <xref
- linkend="sample_configuration"/></para>
-
-<para>Internal DNS server config:</para>
-<programlisting>
-
-acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-
-acl externals { <varname>bastion-ips-go-here</varname>; };
-
-options {
- ...
- ...
- forward only;
- forwarders { // forward to external servers
- <varname>bastion-ips-go-here</varname>;
- };
- allow-transfer { none; }; // sample allow-transfer (no one)
- allow-query { internals; externals; }; // restrict query access
- allow-recursion { internals; }; // restrict recursion
- ...
- ...
-};
-
-zone "site1.example.com" { // sample master zone
- type master;
- file "m/site1.example.com";
- forwarders { }; // do normal iterative
- // resolution (do not forward)
- allow-query { internals; externals; };
- allow-transfer { internals; };
-};
-
-zone "site2.example.com" { // sample slave zone
- type slave;
- file "s/site2.example.com";
- masters { 172.16.72.3; };
- forwarders { };
- allow-query { internals; externals; };
- allow-transfer { internals; };
-};
-
-zone "site1.internal" {
- type master;
- file "m/site1.internal";
- forwarders { };
- allow-query { internals; };
- allow-transfer { internals; }
-};
-
-zone "site2.internal" {
- type slave;
- file "s/site2.internal";
- masters { 172.16.72.3; };
- forwarders { };
- allow-query { internals };
- allow-transfer { internals; }
-};
-</programlisting>
- <para>External (bastion host) DNS server config:</para>
-<programlisting>
-acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-
-acl externals { bastion-ips-go-here; };
-
-options {
- ...
- ...
- allow-transfer { none; }; // sample allow-transfer (no one)
- allow-query { internals; externals; }; // restrict query access
- allow-recursion { internals; externals; }; // restrict recursion
- ...
- ...
-};
-
-zone "site1.example.com" { // sample slave zone
- type master;
- file "m/site1.foo.com";
- allow-query { any; };
- allow-transfer { internals; externals; };
-};
-
-zone "site2.example.com" {
- type slave;
- file "s/site2.foo.com";
- masters { another_bastion_host_maybe; };
- allow-query { any; };
- allow-transfer { internals; externals; }
-};
-</programlisting>
-<para>In the <filename>resolv.conf</filename> (or equivalent) on
-the bastion host(s):</para>
-<programlisting>
-search ...
-nameserver 172.16.72.2
-nameserver 172.16.72.3
-nameserver 172.16.72.4
-</programlisting>
-</sect1>
-<sect1 id="tsig"><title>TSIG</title>
-<para>This is a short guide to setting up Transaction SIGnatures
-(TSIG) based transaction security in <acronym>BIND</acronym>. 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 <acronym>BIND</acronym>.</para>
-<para><acronym>BIND</acronym> primarily supports TSIG for server to server communication.
-This includes zone transfer, notify, and recursive query messages.
-Resolvers based on newer versions of <acronym>BIND</acronym> 8 have limited support
-for TSIG.</para>
-
- <para>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 <command>nsupdate</command>
- program supports TSIG via the <option>-k</option> and
- <option>-y</option> command line options.</para>
-
-<sect2><title>Generate Shared Keys for Each Pair of Hosts</title>
-<para>A shared secret is generated to be shared between <emphasis>host1</emphasis> and <emphasis>host2</emphasis>.
-An arbitrary key name is chosen: "host1-host2.". The key name must
-be the same on both hosts.</para>
-<sect3><title>Automatic Generation</title>
-<para>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.</para>
- <para><userinput>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</userinput></para>
-<para>The key is in the file <filename>Khost1-host2.+157+00000.private</filename>.
-Nothing directly uses this file, but the base-64 encoded string
-following "<literal>Key:</literal>"
-can be extracted from the file and used as a shared secret:</para>
-<programlisting>Key: La/E5CjG9O+os1jq0a2jdA==</programlisting>
-<para>The string "<literal>La/E5CjG9O+os1jq0a2jdA==</literal>" can
-be used as the shared secret.</para></sect3>
-<sect3><title>Manual Generation</title>
-<para>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.</para>
-<para>Also, a known string can be run through <command>mmencode</command> or
-a similar program to generate base-64 encoded data.</para></sect3></sect2>
-<sect2><title>Copying the Shared Secret to Both Machines</title>
-<para>This is beyond the scope of DNS. A secure transport mechanism
-should be used. This could be secure FTP, ssh, telephone, etc.</para></sect2>
-<sect2><title>Informing the Servers of the Key's Existence</title>
-<para>Imagine <emphasis>host1</emphasis> and <emphasis>host 2</emphasis> are
-both servers. The following is added to each server's <filename>named.conf</filename> file:</para>
-<programlisting>
-key host1-host2. {
- algorithm hmac-md5;
- secret "La/E5CjG9O+os1jq0a2jdA==";
-};
-</programlisting>
-<para>The algorithm, hmac-md5, is the only one supported by <acronym>BIND</acronym>.
-The secret is the one generated above. Since this is a secret, it
-is recommended that either <filename>named.conf</filename> be non-world
-readable, or the key directive be added to a non-world readable
-file that is included by <filename>named.conf</filename>.</para>
-<para>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.</para></sect2>
-
-<sect2><title>Instructing the Server to Use the Key</title>
-<para>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 <filename>named.conf</filename> file
-for <emphasis>host1</emphasis>, if the IP address of <emphasis>host2</emphasis> is
-10.1.2.3:</para>
-<programlisting>
-server 10.1.2.3 {
- keys { host1-host2. ;};
-};
-</programlisting>
-<para>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.</para>
-<para>If <emphasis>host1</emphasis> sends a message that is a request
-to that address, the message will be signed with the specified key. <emphasis>host1</emphasis> will
-expect any responses to signed messages to be signed with the same
-key.</para>
-<para>A similar statement must be present in <emphasis>host2</emphasis>'s
-configuration file (with <emphasis>host1</emphasis>'s address) for <emphasis>host2</emphasis> to
-sign request messages to <emphasis>host1</emphasis>.</para></sect2>
-<sect2><title>TSIG Key Based Access Control</title>
-<para><acronym>BIND</acronym> allows IP addresses and ranges to be specified in ACL
-definitions and
-<command>allow-{ query | transfer | update }</command> directives.
-This has been extended to allow TSIG keys also. The above key would
-be denoted <command>key host1-host2.</command></para>
-<para>An example of an allow-update directive would be:</para>
-<programlisting>
-allow-update { key host1-host2. ;};
-</programlisting>
-
- <para>This allows dynamic updates to succeed only if the request
- was signed by a key named
- "<command>host1-host2.</command>".</para> <para>You may want to read about the more
- powerful <command>update-policy</command> statement in <xref
- linkend="dynamic_update_policies"/>.</para>
-
- </sect2>
- <sect2>
- <title>Errors</title>
-
- <para>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.</para>
-
- <para>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
- response will be unsigned with the TSIG extended error code set
- to BADSIG. If a TSIG aware server receives a message with a time
- outside of the allowed range, the response will be signed with
- 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.</para>
-
- </sect2>
- </sect1>
- <sect1>
- <title>TKEY</title>
-
- <para><command>TKEY</command> is a mechanism for automatically
- generating a shared secret between two hosts. There are several
- "modes" of <command>TKEY</command> that specify how the key is
- generated or assigned. <acronym>BIND</acronym> 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 <command>TKEY</command> process
- must use signed messages, signed either by TSIG or SIG(0). The
- result of <command>TKEY</command> is a shared secret that can be
- used to sign messages with TSIG. <command>TKEY</command> can also
- be used to delete shared secrets that it had previously
- generated.</para>
-
- <para>The <command>TKEY</command> process is initiated by a client
- or server by sending a signed <command>TKEY</command> query
- (including any appropriate KEYs) to a TKEY-aware server. The
- server response, if it indicates success, will contain a
- <command>TKEY</command> record and any appropriate keys. After
- this exchange, both participants have enough information to
- determine the shared secret; the exact process depends on the
- <command>TKEY</command> mode. When using the Diffie-Hellman
- <command>TKEY</command> mode, Diffie-Hellman keys are exchanged,
- and the shared secret is derived by both participants.</para>
-
- </sect1>
- <sect1>
- <title>SIG(0)</title>
-
- <para><acronym>BIND</acronym> 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.</para>
-
- <para>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.</para>
-
- <para>SIG(0) signing of multiple-message TCP streams is not
- supported.</para>
-
- <para>The only tool shipped with <acronym>BIND</acronym> 9 that
- generates SIG(0) signed messages is <command>nsupdate</command>.</para>
-
- </sect1>
- <sect1 id="DNSSEC">
- <title>DNSSEC</title>
-
- <para>Cryptographic authentication of DNS information is possible
- through the DNS Security (<emphasis>DNSSEC-bis</emphasis>) extensions,
- defined in RFC &lt;TBA&gt;. This section describes the creation and use
- of DNSSEC signed zones.</para>
-
- <para>In order to set up a DNSSEC secure zone, there are a series
- of steps which must be followed. <acronym>BIND</acronym> 9 ships
- with several tools
- that are used in this process, which are explained in more detail
- below. In all cases, the <option>-h</option> 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 <option>-h</option> option, and
- that the tools shipped with BIND 9.2.x and earlier are not compatible
- with the current ones.</para>
-
- <para>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 <literal>DS</literal> record at the delegation
- point.</para>
-
- <para>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.</para>
-
- <sect2>
- <title>Generating Keys</title>
-
- <para>The <command>dnssec-keygen</command> program is used to
- generate keys.</para>
-
- <para>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
- <command>ZONE</command>, 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.</para>
-
- <para>The following command will generate a 768 bit RSASHA1 key for
- the <filename>child.example</filename> zone:</para>
-
- <para><userinput>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</userinput></para>
-
- <para>Two output files will be produced:
- <filename>Kchild.example.+005+12345.key</filename> and
- <filename>Kchild.example.+005+12345.private</filename> (where
- 12345 is an example of a key tag). The key file names contain
- the key name (<filename>child.example.</filename>), algorithm (3
- is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case).
- The private key (in the <filename>.private</filename> file) is
- used to generate signatures, and the public key (in the
- <filename>.key</filename> file) is used for signature
- verification.</para>
-
- <para>To generate another key with the same properties (but with
- a different key tag), repeat the above command.</para>
-
- <para>The public keys should be inserted into the zone file by
- including the <filename>.key</filename> files using
- <command>$INCLUDE</command> statements.
- </para>
-
- </sect2>
- <sect2>
- <title>Signing the Zone</title>
-
- <para>The <command>dnssec-signzone</command> program is used to
- sign a zone.</para>
-
- <para>Any <filename>keyset</filename> files corresponding
- to secure subzones should be present. The zone signer will
- generate <literal>NSEC</literal> and <literal>RRSIG</literal>
- records for the zone, as well as <literal>DS</literal> for
- the child zones if <literal>'-d'</literal> is specified.
- If <literal>'-d'</literal> is not specified then DS RRsets for
- the secure child zones need to be added manually.</para>
-
- <para>The following command signs the zone, assuming it is in a
- file called <filename>zone.child.example</filename>. By
- default, all zone keys which have an available private key are
- used to generate signatures.</para>
-
-<para><userinput>dnssec-signzone -o child.example zone.child.example</userinput></para>
-
- <para>One output file is produced:
- <filename>zone.child.example.signed</filename>. This file
- should be referenced by <filename>named.conf</filename> as the
- input file for the zone.</para>
-
- <para><command>dnssec-signzone</command> will also produce a
- keyset and dsset files and optionally a dlvset file. These
- are used to provide the parent zone administators with the
- <literal>DNSKEYs</literal> (or their corresponding <literal>DS</literal>
- records) that are the secure entry point to the zone.</para>
-
- </sect2>
-
-<sect2><title>Configuring Servers</title>
-
-<para>Unlike <acronym>BIND</acronym> 8,
-<acronym>BIND</acronym> 9 does not verify signatures on load,
-so zone keys for authoritative zones do not need to be specified
-in the configuration file.</para>
-
-<para>The public key for any security root must be present in
-the configuration file's <command>trusted-keys</command>
-statement, as described later in this document. </para>
-
-</sect2>
-
-</sect1>
- <sect1>
- <title>IPv6 Support in <acronym>BIND</acronym> 9</title>
-
- <para><acronym>BIND</acronym> 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.</para>
-
- <para>For forward lookups, <acronym>BIND</acronym> 9 supports only AAAA
- records. The use of A6 records is deprecated by RFC 3363, and the
- support for forward lookups in <acronym>BIND</acronym> 9 is
- removed accordingly.
- However, authoritative <acronym>BIND</acronym> 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.</para>
-
- <para>For IPv6 reverse lookups, <acronym>BIND</acronym> 9 supports
- the traditional "nibble" format used in the
- <emphasis>ip6.arpa</emphasis> domain, as well as the older, deprecated
- <emphasis>ip6.int</emphasis> domain.
- <acronym>BIND</acronym> 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 <acronym>BIND</acronym> 9 do not understand
- the format any more, and will return an error if given.
- In particular, an authoritative <acronym>BIND</acronym> 9 name
- server rejects to load a zone file containing binary labels.</para>
-
- <para>For an overview of the format and structure of IPv6 addresses,
- see <xref linkend="ipv6addresses"/>.</para>
-
- <sect2>
- <title>Address Lookups Using AAAA Records</title>
-
- <para>The AAAA record is a parallel to the IPv4 A record. It
- specifies the entire address in a single record. For
- example,</para>
-
-<programlisting>
-$ORIGIN example.com.
-host 3600 IN AAAA 2001:db8::1
-</programlisting>
-
- <para>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 <literal>::ffff:192.168.42.1</literal> as the
- address.</para>
- </sect2>
- <sect2>
- <title>Address to Name Lookups Using Nibble Format</title>
-
- <para>When looking up an address in nibble format, the address
- components are simply reversed, just as in IPv4, and
- <literal>ip6.arpa.</literal> is appended to the resulting name.
- For example, the following would provide reverse name lookup for
- a host with address
- <literal>2001:db8::1</literal>.</para>
-
-<programlisting>
-$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.
-</programlisting>
- </sect2>
- </sect1>
- </chapter>
-
- <chapter id="Bv9ARM.ch05"><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title>
-<sect1><title>The Lightweight Resolver Library</title>
-<para>Traditionally applications have been linked with a stub resolver
-library that sends recursive DNS queries to a local caching name
-server.</para>
-<para>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.</para>
-<para>Instead, <acronym>BIND</acronym> 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.</para></sect1>
-<sect1 id="lwresd"><title>Running a Resolver Daemon</title>
-
-<para>To use the lightweight resolver interface, the system must
-run the resolver daemon <command>lwresd</command> or a local
-name server configured with a <command>lwres</command> statement.</para>
-
-<para>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 <command>lwserver</command> lines in
-<filename>/etc/resolv.conf</filename>.</para>
-
-<para>The daemon currently only looks in the DNS, but in the future
-it may use other sources such as <filename>/etc/hosts</filename>,
-NIS, etc.</para>
-
-<para>The <command>lwresd</command> 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
-<command>nameserver</command> lines in <filename>/etc/resolv.conf</filename>
-as forwarders, but is also capable of doing the resolution autonomously if
-none are specified.</para>
-<para>The <command>lwresd</command> daemon may also be configured with a
-<filename>named.conf</filename> style configuration file, in
-<filename>/etc/lwresd.conf</filename> by default. A name server may also
-be configured to act as a lightweight resolver daemon using the
-<command>lwres</command> statement in <filename>named.conf</filename>.</para>
-
-</sect1></chapter>
-
-<chapter id="Bv9ARM.ch06"><title><acronym>BIND</acronym> 9 Configuration Reference</title>
-
-<para><acronym>BIND</acronym> 9 configuration is broadly similar
-to <acronym>BIND</acronym> 8; however, there are a few new areas
-of configuration, such as views. <acronym>BIND</acronym>
-8 configuration files should work with few alterations in <acronym>BIND</acronym>
-9, although more complex configurations should be reviewed to check
-if they can be more efficiently implemented using the new features
-found in <acronym>BIND</acronym> 9.</para>
-
-<para><acronym>BIND</acronym> 4 configuration files can be converted to the new format
-using the shell script
-<filename>contrib/named-bootconf/named-bootconf.sh</filename>.</para>
-<sect1 id="configuration_file_elements"><title>Configuration File Elements</title>
-<para>Following is a list of elements used throughout the <acronym>BIND</acronym> configuration
-file documentation:</para>
-<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2"
- colsep = "0" rowsep = "0" tgroupstyle = "2Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.855in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.770in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>acl_name</varname></para></entry>
-<entry colname = "2"><para>The name of an <varname>address_match_list</varname> as
-defined by the <command>acl</command> statement.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>address_match_list</varname></para></entry>
-<entry colname = "2"><para>A list of one or more <varname>ip_addr</varname>,
-<varname>ip_prefix</varname>, <varname>key_id</varname>,
-or <varname>acl_name</varname> elements, see
-<xref linkend="address_match_lists"/>.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>domain_name</varname></para></entry>
-<entry colname = "2"><para>A quoted string which will be used as
-a DNS name, for example "<literal>my.test.domain</literal>".</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>dotted_decimal</varname></para></entry>
-<entry colname = "2"><para>One to four integers valued 0 through
-255 separated by dots (`.'), such as <command>123</command>,
-<command>45.67</command> or <command>89.123.45.67</command>.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>ip4_addr</varname></para></entry>
-<entry colname = "2"><para>An IPv4 address with exactly four elements
-in <varname>dotted_decimal</varname> notation.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>ip6_addr</varname></para></entry>
-<entry colname = "2"><para>An IPv6 address, such as <command>2001:db8::1234</command>.
-IPv6 scoped addresses that have ambiguity on their scope zones must be
-disambiguated by an appropriate zone ID with the percent character
-(`%') as delimiter.
-It is strongly recommended to use string zone names rather than
-numeric identifiers, in order to be robust against system
-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 <command>fe80::1</command> on the
-link attached to the interface <command>ne0</command>
-can be specified as <command>fe80::1%ne0</command>.
-Note that on most systems link-local addresses always have the
-ambiguity, and need to be disambiguated.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>ip_addr</varname></para></entry>
-<entry colname = "2"><para>An <varname>ip4_addr</varname> or <varname>ip6_addr</varname>.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>ip_port</varname></para></entry>
-<entry colname = "2"><para>An IP port <varname>number</varname>.
-<varname>number</varname> 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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>ip_prefix</varname></para></entry>
-<entry colname = "2"><para>An IP network specified as an <varname>ip_addr</varname>,
-followed by a slash (`/') and then the number of bits in the netmask.
-Trailing zeros in a <varname>ip_addr</varname> may omitted.
-For example, <command>127/8</command> is the network <command>127.0.0.0</command> with
-netmask <command>255.0.0.0</command> and <command>1.2.3.0/28</command> is
-network <command>1.2.3.0</command> with netmask <command>255.255.255.240</command>.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>key_id</varname></para></entry>
-<entry colname = "2"><para>A <varname>domain_name</varname> representing
-the name of a shared key, to be used for transaction security.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>key_list</varname></para></entry>
-<entry colname = "2"><para>A list of one or more <varname>key_id</varname>s,
-separated by semicolons and ending with a semicolon.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>number</varname></para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>path_name</varname></para></entry>
-<entry colname = "2"><para>A quoted string which will be used as
-a pathname, such as <filename>zones/master/my.test.domain</filename>.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>size_spec</varname></para></entry>
-<entry colname = "2"><para>A number, the word <userinput>unlimited</userinput>,
-or the word <userinput>default</userinput>.</para><para>
-An <varname>unlimited</varname> <varname>size_spec</varname> requests unlimited
-use, or the maximum available amount. A <varname>default size_spec</varname> uses
-the limit that was in force when the server was started.</para><para>A <varname>number</varname> can
-optionally be followed by a scaling factor: <userinput>K</userinput> or <userinput>k</userinput> for
-kilobytes, <userinput>M</userinput> or <userinput>m</userinput> for
-megabytes, and <userinput>G</userinput> or <userinput>g</userinput> for gigabytes,
-which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.</para>
-<para>The value must be representable as a 64-bit unsigned integer
-(0 to 18446744073709551615, inclusive).
-Using <varname>unlimited</varname> is the best way
-to safely set a really large number.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>yes_or_no</varname></para></entry>
-<entry colname = "2"><para>Either <userinput>yes</userinput> or <userinput>no</userinput>.
-The words <userinput>true</userinput> and <userinput>false</userinput> are
-also accepted, as are the numbers <userinput>1</userinput> and <userinput>0</userinput>.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>dialup_option</varname></para></entry>
-<entry colname = "2"><para>One of <userinput>yes</userinput>,
-<userinput>no</userinput>, <userinput>notify</userinput>,
-<userinput>notify-passive</userinput>, <userinput>refresh</userinput> or
-<userinput>passive</userinput>.
-When used in a zone, <userinput>notify-passive</userinput>,
-<userinput>refresh</userinput>, and <userinput>passive</userinput>
-are restricted to slave and stub zones.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-<sect2 id="address_match_lists"><title>Address Match Lists</title>
-<sect3><title>Syntax</title>
- <programlisting><varname>address_match_list</varname> = address_match_list_element ;
- <optional> address_match_list_element; ... </optional>
-<varname>address_match_list_element</varname> = <optional> ! </optional> (ip_address <optional>/length</optional> |
- key key_id | acl_name | { address_match_list } )
-</programlisting>
-</sect3>
-<sect3><title>Definition and Usage</title>
-<para>Address match lists are primarily used to determine access
-control for various server operations. They are also used in
-the <command>listen-on</command> and <command>sortlist</command>
-statements. The elements
-which constitute an address match list can be any of the following:</para>
-<itemizedlist><listitem>
- <simpara>an IP address (IPv4 or IPv6)</simpara></listitem>
-<listitem>
- <simpara>an IP prefix (in `/' notation)</simpara></listitem>
-<listitem>
- <simpara>a key ID, as defined by the <command>key</command> statement</simpara></listitem>
-<listitem>
- <simpara>the name of an address match list defined with
-the <command>acl</command> statement</simpara></listitem>
-<listitem>
- <simpara>a nested address match list enclosed in braces</simpara></listitem></itemizedlist>
-
-<para>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.</para>
-
-<para>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.</para>
-
-<para>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.</para>
-
-<para>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 <command>allow-notify</command>,
-<command>allow-query</command>, <command>allow-transfer</command>,
-<command>allow-update</command>, <command>allow-update-forwarding</command>,
-and <command>blackhole</command> 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.</para>
-
-<para>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
-<command>1.2.3/24; ! 1.2.3.13;</command> 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 <command>! 1.2.3.13; 1.2.3/24</command> fixes
-that problem by having 1.2.3.13 blocked by the negation but all
-other 1.2.3.* hosts fall through.</para>
-</sect3>
-</sect2>
-
-<sect2>
-<title>Comment Syntax</title>
-
-<para>The <acronym>BIND</acronym> 9 comment syntax allows for comments to appear
-anywhere that white space may appear in a <acronym>BIND</acronym> configuration
-file. To appeal to programmers of all kinds, they can be written
-in the C, C++, or shell/perl style.</para>
-
-<sect3>
-<title>Syntax</title>
-
-<para><programlisting>/* This is a <acronym>BIND</acronym> comment as in C */</programlisting>
-<programlisting>// This is a <acronym>BIND</acronym> comment as in C++</programlisting>
-<programlisting># This is a <acronym>BIND</acronym> comment as in common UNIX shells and perl</programlisting>
- </para>
- </sect3>
- <sect3>
- <title>Definition and Usage</title>
-<para>Comments may appear anywhere that whitespace may appear in
-a <acronym>BIND</acronym> configuration file.</para>
-<para>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.</para>
-<para>C-style comments cannot be nested. For example, the following
-is not valid because the entire comment ends with the first */:</para>
- <para><programlisting>/* 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. */
-</programlisting></para>
-
-<para>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.</para>
-<para>For example:</para>
- <para><programlisting>// This is the start of a comment. The next line
-// is a new comment, even though it is logically
-// part of the previous comment.
-</programlisting></para>
-<para>Shell-style (or perl-style, if you prefer) comments start
-with the character <literal>#</literal> (number sign) and continue to the end of the
-physical line, as in C++ comments.</para>
-<para>For example:</para>
-
-<para><programlisting># This is the start of a comment. The next line
-# is a new comment, even though it is logically
-# part of the previous comment.
-</programlisting>
-</para>
-
-<warning>
- <para>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.</para>
-</warning>
-</sect3>
-</sect2>
-</sect1>
-
-<sect1 id="Configuration_File_Grammar">
-<title>Configuration File Grammar</title>
-
- <para>A <acronym>BIND</acronym> 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.</para>
-
- <para>The following statements are supported:</para>
-
- <informaltable colsep = "0" rowsep = "0">
- <tgroup cols = "2" colsep = "0" rowsep = "0" tgroupstyle =
- "2Level-table">
- <colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.336in"/>
- <colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.778in"/>
- <tbody>
- <row rowsep = "0">
- <entry colname = "1"><para><command>acl</command></para></entry>
- <entry colname = "2"><para>defines a named IP address
-matching list, for access control and other uses.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>controls</command></para></entry>
- <entry colname = "2"><para>declares control channels to be used
-by the <command>rndc</command> utility.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>include</command></para></entry>
- <entry colname = "2"><para>includes a file.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>key</command></para></entry>
- <entry colname = "2"><para>specifies key information for use in
-authentication and authorization using TSIG.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>logging</command></para></entry>
- <entry colname = "2"><para>specifies what the server logs, and where
-the log messages are sent.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>lwres</command></para></entry>
- <entry colname = "2"><para>configures <command>named</command> to
-also act as a light weight resolver daemon (<command>lwresd</command>).</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>masters</command></para></entry>
- <entry colname = "2"><para>defines a named masters list for
-inclusion in stub and slave zone masters clauses.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>options</command></para></entry>
- <entry colname = "2"><para>controls global server configuration
-options and sets defaults for other statements.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>server</command></para></entry>
- <entry colname = "2"><para>sets certain configuration options on
-a per-server basis.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>trusted-keys</command></para></entry>
- <entry colname = "2"><para>defines trusted DNSSEC keys.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>view</command></para></entry>
- <entry colname = "2"><para>defines a view.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>zone</command></para></entry>
- <entry colname = "2"><para>defines a zone.</para></entry>
- </row>
- </tbody>
- </tgroup></informaltable>
-
- <para>The <command>logging</command> and
- <command>options</command> statements may only occur once per
- configuration.</para>
-
- <sect2>
- <title><command>acl</command> Statement Grammar</title>
-
- <programlisting><command>acl</command> acl-name {
- address_match_list
-};
-</programlisting>
- </sect2>
- <sect2 id="acl">
- <title><command>acl</command> Statement Definition and
-Usage</title>
-
- <para>The <command>acl</command> 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).</para>
-
- <para>Note that an address match list's name must be defined
- with <command>acl</command> before it can be used elsewhere; no
- forward references are allowed.</para>
-
- <para>The following ACLs are built-in:</para>
-
-<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2"
- colsep = "0" rowsep = "0" tgroupstyle = "3Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.130in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.000in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><command>any</command></para></entry>
-<entry colname = "2"><para>Matches all hosts.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>none</command></para></entry>
-<entry colname = "2"><para>Matches no hosts.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>localhost</command></para></entry>
-<entry colname = "2"><para>Matches the IPv4 and IPv6 addresses of all network
-interfaces on the system.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>localnets</command></para></entry>
-<entry colname = "2"><para>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, <command>localnets</command> only matches the local
-IPv6 addresses, just like <command>localhost</command>.
-</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-
-</sect2>
-<sect2>
- <title><command>controls</command> Statement Grammar</title>
-<programlisting><command>controls</command> {
- inet ( ip_addr | * ) <optional> port ip_port </optional> allow { <replaceable> address_match_list </replaceable> }
- keys { <replaceable> key_list </replaceable> };
- <optional> inet ...; </optional>
-};
-</programlisting>
-</sect2>
-
-<sect2 id="controls_statement_definition_and_usage">
-<title><command>controls</command> Statement Definition and Usage</title>
-
- <para>The <command>controls</command> 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 <command>rndc</command> utility to send commands to
- and retrieve non-DNS results from a name server.</para>
-
- <para>An <command>inet</command> control channel is a TCP
- socket listening at the specified
- <command>ip_port</command> on the specified
- <command>ip_addr</command>, which can be an IPv4 or IPv6
- address. An <command>ip_addr</command>
- of <literal>*</literal> 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 <command>ip_addr</command> of <literal>::</literal>.
- If you will only use <command>rndc</command> on the local host,
- using the loopback address (<literal>127.0.0.1</literal>
- or <literal>::1</literal>) is recommended for maximum
- security.
- </para>
-
- <para>
- If no port is specified, port 953
- is used. "<literal>*</literal>" cannot be used for
- <command>ip_port</command>.</para>
-
- <para>The ability to issue commands over the control channel is
- restricted by the <command>allow</command> and
- <command>keys</command> clauses. Connections to the control
- channel are permitted based on the
- <command>address_match_list</command>. This is for simple
- IP address based filtering only; any <command>key_id</command>
- elements of the <command>address_match_list</command> are
- ignored.
- </para>
-
- <para>The primary authorization mechanism of the command
- channel is the <command>key_list</command>, which contains
- a list of <command>key_id</command>s.
- Each <command>key_id</command> in
- the <command>key_list</command> is authorized to execute
- commands over the control channel.
- See <xref linkend="rndc"/> in
- <xref linkend="admin_tools"/>) for information about
- configuring keys in <command>rndc</command>.</para>
-
-<para>
-If no <command>controls</command> statement is present,
-<command>named</command> 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 <command>controls</command> statement
-is present but does not have a <command>keys</command> clause,
-<command>named</command> will attempt to load the command channel key
-from the file <filename>rndc.key</filename> in
-<filename>/etc</filename> (or whatever <varname>sysconfdir</varname>
-was specified as when <acronym>BIND</acronym> was built).
-To create a <filename>rndc.key</filename> file, run
-<userinput>rndc-confgen -a</userinput>.
-</para>
-
- <para>The <filename>rndc.key</filename> feature was created to
- ease the transition of systems from <acronym>BIND</acronym> 8,
- which did not have digital signatures on its command channel messages
- and thus did not have a <command>keys</command> clause.
-
-It makes it possible to use an existing <acronym>BIND</acronym> 8
-configuration file in <acronym>BIND</acronym> 9 unchanged,
-and still have <command>rndc</command> work the same way
-<command>ndc</command> worked in BIND 8, simply by executing the
-command <userinput>rndc-confgen -a</userinput> after BIND 9 is
-installed.
-</para>
-
- <para>
- Since the <filename>rndc.key</filename> feature
- is only intended to allow the backward-compatible usage of
- <acronym>BIND</acronym> 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
- <filename>rndc.conf</filename> with your own key if you wish to change
- those things. The <filename>rndc.key</filename> file also has its
- permissions set such that only the owner of the file (the user that
- <command>named</command> is running as) can access it. If you
- desire greater flexibility in allowing other users to access
- <command>rndc</command> commands then you need to create an
- <filename>rndc.conf</filename> and make it group readable by a group
- that contains the users who should have access.</para>
-
- <para>The UNIX control channel type of <acronym>BIND</acronym> 8 is not supported
- in <acronym>BIND</acronym> 9, and is not expected to be added in future
- releases. If it is present in the controls statement from a
- <acronym>BIND</acronym> 8 configuration file, it is ignored
- and a warning is logged.</para>
-
-<para>
-To disable the command channel, use an empty <command>controls</command>
-statement: <command>controls { };</command>.
-</para>
-
- </sect2>
- <sect2>
- <title><command>include</command> Statement Grammar</title>
- <programlisting>include <replaceable>filename</replaceable>;</programlisting>
- </sect2>
- <sect2>
- <title><command>include</command> Statement Definition and Usage</title>
-
- <para>The <command>include</command> statement inserts the
- specified file at the point where the <command>include</command>
- statement is encountered. The <command>include</command>
- 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.</para>
-
- </sect2>
- <sect2>
- <title><command>key</command> Statement Grammar</title>
-<programlisting>key <replaceable>key_id</replaceable> {
- algorithm <replaceable>string</replaceable>;
- secret <replaceable>string</replaceable>;
-};
-</programlisting>
- </sect2>
-
-<sect2>
-<title><command>key</command> Statement Definition and Usage</title>
-
-<para>The <command>key</command> statement defines a shared
-secret key for use with TSIG (see <xref linkend="tsig"/>)
-or the command channel
-(see <xref linkend="controls_statement_definition_and_usage"/>).
-</para>
-
-<para>
-The <command>key</command> statement can occur at the top level
-of the configuration file or inside a <command>view</command>
-statement. Keys defined in top-level <command>key</command>
-statements can be used in all views. Keys intended for use in
-a <command>controls</command> statement
-(see <xref linkend="controls_statement_definition_and_usage"/>)
-must be defined at the top level.
-</para>
-
-<para>The <replaceable>key_id</replaceable>, also known as the
-key name, is a domain name uniquely identifying the key. It can
-be used in a <command>server</command>
-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.</para>
-
-<para>The <replaceable>algorithm_id</replaceable> is a string
-that specifies a security/authentication algorithm. The only
-algorithm currently supported with TSIG authentication is
-<literal>hmac-md5</literal>. The
-<replaceable>secret_string</replaceable> is the secret to be
-used by the algorithm, and is treated as a base-64 encoded
-string.</para>
-
-</sect2>
- <sect2>
- <title><command>logging</command> Statement Grammar</title>
- <programlisting><command>logging</command> {
- [ <command>channel</command> <replaceable>channel_name</replaceable> {
- ( <command>file</command> <replaceable>path name</replaceable>
- [ <command>versions</command> ( <replaceable>number</replaceable> | <literal>unlimited</literal> ) ]
- [ <command>size</command> <replaceable>size spec</replaceable> ]
- | <command>syslog</command> <replaceable>syslog_facility</replaceable>
- | <command>stderr</command>
- | <command>null</command> );
- [ <command>severity</command> (<option>critical</option> | <option>error</option> | <option>warning</option> | <option>notice</option> |
- <option>info</option> | <option>debug</option> [ <replaceable>level</replaceable> ] | <option>dynamic</option> ); ]
- [ <command>print-category</command> <option>yes</option> or <option>no</option>; ]
- [ <command>print-severity</command> <option>yes</option> or <option>no</option>; ]
- [ <command>print-time</command> <option>yes</option> or <option>no</option>; ]
- }; ]
- [ <command>category</command> <replaceable>category_name</replaceable> {
- <replaceable>channel_name</replaceable> ; [ <replaceable>channel_nam</replaceable>e ; ... ]
- }; ]
- ...
-};
-</programlisting>
-</sect2>
-
-<sect2>
-<title><command>logging</command> Statement Definition and Usage</title>
-
-<para>The <command>logging</command> statement configures a wide
-variety of logging options for the name server. Its <command>channel</command> phrase
-associates output methods, format options and severity levels with
-a name that can then be used with the <command>category</command> phrase
-to select how various classes of messages are logged.</para>
-<para>Only one <command>logging</command> statement is used to define
-as many channels and categories as are wanted. If there is no <command>logging</command> statement,
-the logging configuration will be:</para>
-
-<programlisting>logging {
- category default { default_syslog; default_debug; };
- category unmatched { null; };
-};
-</programlisting>
-
-<para>In <acronym>BIND</acronym> 9, the logging configuration is only established when
-the entire configuration file has been parsed. In <acronym>BIND</acronym> 8, it was
-established as soon as the <command>logging</command> 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 "<option>-g</option>" option
-was specified.</para>
-
-<sect3>
-<title>The <command>channel</command> Phrase</title>
-
-<para>All log output goes to one or more <emphasis>channels</emphasis>;
-you can make as many of them as you want.</para>
-
-<para>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
-<command>info</command>), and whether to include a
-<command>named</command>-generated time stamp, the category name
-and/or severity level (the default is not to include any).</para>
-
-<para>The <command>null</command> destination clause
-causes all messages sent to the channel to be discarded;
-in that case, other options for the channel are meaningless.</para>
-
-<para>The <command>file</command> 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.</para>
-
-<para>If you use the <command>versions</command> log file option, then
-<command>named</command> 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 <filename>lamers.log</filename> then just before it is opened
-<filename>lamers.log.1</filename> is renamed to
-<filename>lamers.log.2</filename>, <filename>lamers.log.0</filename> is renamed
-to <filename>lamers.log.1</filename>, and <filename>lamers.log</filename> is
-renamed to <filename>lamers.log.0</filename>.
-You can say <command>versions unlimited</command> to not limit
-the number of versions.
-If a <command>size</command> 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.</para>
-
-<para>The <command>size</command> option for files is used to limit log
-growth. If the file ever exceeds the size, then <command>named</command> will
-stop writing to the file unless it has a <command>versions</command> 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
-<command>versions</command> 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.</para>
-
-<para>Example usage of the <command>size</command> and
-<command>versions</command> options:</para>
-
-<programlisting>channel an_example_channel {
- file "example.log" versions 3 size 20m;
- print-time yes;
- print-category yes;
-};
-</programlisting>
-
-<para>The <command>syslog</command> destination clause directs the
-channel to the system log. Its argument is a
-syslog facility as described in the <command>syslog</command> man
-page. Known facilities are <command>kern</command>, <command>user</command>,
-<command>mail</command>, <command>daemon</command>, <command>auth</command>,
-<command>syslog</command>, <command>lpr</command>, <command>news</command>,
-<command>uucp</command>, <command>cron</command>, <command>authpriv</command>,
-<command>ftp</command>, <command>local0</command>, <command>local1</command>,
-<command>local2</command>, <command>local3</command>, <command>local4</command>,
-<command>local5</command>, <command>local6</command> and
-<command>local7</command>, however not all facilities are supported on
-all operating systems.
-How <command>syslog</command> will handle messages sent to
-this facility is described in the <command>syslog.conf</command> man
-page. If you have a system which uses a very old version of <command>syslog</command> that
-only uses two arguments to the <command>openlog()</command> function,
-then this clause is silently ignored.</para>
-<para>The <command>severity</command> clause works like <command>syslog</command>'s
-"priorities", except that they can also be used if you are writing
-straight to a file rather than using <command>syslog</command>.
-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.</para>
-<para>If you are using <command>syslog</command>, then the <command>syslog.conf</command> priorities
-will also determine what eventually passes through. For example,
-defining a channel facility and severity as <command>daemon</command> and <command>debug</command> but
-only logging <command>daemon.warning</command> via <command>syslog.conf</command> will
-cause messages of severity <command>info</command> and <command>notice</command> to
-be dropped. If the situation were reversed, with <command>named</command> writing
-messages of only <command>warning</command> or higher, then <command>syslogd</command> would
-print all messages it received from the channel.</para>
-
-<para>The <command>stderr</command> 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.</para>
-
-<para>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 <command>named</command> server
-with the <option>-d</option> flag followed by a positive integer,
-or by running <command>rndc trace</command>.
-The global debug level
-can be set to zero, and debugging mode turned off, by running <command>ndc
-notrace</command>. 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:</para>
-<programlisting>channel specific_debug_level {
- file "foo";
- severity debug 3;
-};
-</programlisting>
- <para>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 <command>dynamic</command> severity use the
-server's global debug level to determine what messages to print.</para>
- <para>If <command>print-time</command> has been turned on, then
-the date and time will be logged. <command>print-time</command> may
-be specified for a <command>syslog</command> channel, but is usually
-pointless since <command>syslog</command> also prints the date and
-time. If <command>print-category</command> is requested, then the
-category of the message will be logged as well. Finally, if <command>print-severity</command> is
-on, then the severity level of the message will be logged. The <command>print-</command> 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 <command>print-</command> options
-are on:</para>
-
-<para><computeroutput>28-Feb-2000 15:05:32.863 general: notice: running</computeroutput></para>
-
-<para>There are four predefined channels that are used for
-<command>named</command>'s default logging as follows. How they are
-used is described in <xref linkend="the_category_phrase"/>.
-</para>
-
-<programlisting>channel default_syslog {
- syslog daemon; // send to syslog's daemon
- // facility
- severity info; // only send priority info
- // and higher
-};
-
-channel default_debug {
- file "named.run"; // write to named.run in
- // the working directory
- // Note: stderr is used instead
- // of "named.run"
- // if the server is started
- // with the '-f' option.
- severity dynamic; // log at the server's
- // current debug level
-};
-
-channel default_stderr {
- stderr; // writes to stderr
- severity info; // only send priority info
- // and higher
-};
-
-channel null {
- null; // toss anything sent to
- // this channel
-};
-</programlisting>
-
-<para>The <command>default_debug</command> channel has the special
-property that it only produces output when the server's debug level is
-nonzero. It normally writes to a file <filename>named.run</filename>
-in the server's working directory.</para>
-
-<para>For security reasons, when the "<option>-u</option>"
-command line option is used, the <filename>named.run</filename> file
-is created only after <command>named</command> has changed to the
-new UID, and any debug output generated while <command>named</command> is
-starting up and still running as root is discarded. If you need
-to capture this output, you must run the server with the "<option>-g</option>"
-option and redirect standard error to a file.</para>
-
-<para>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.</para>
-</sect3>
-
-<sect3 id="the_category_phrase"><title>The <command>category</command> Phrase</title>
-
-<para>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 <command>default</command> category
-instead. If you don't specify a default category, the following
-"default default" is used:</para>
-<programlisting>category default { default_syslog; default_debug; };
-</programlisting>
-<para>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:</para>
-<programlisting>channel my_security_channel {
- file "my_security_file";
- severity info;
-};
-category security {
- my_security_channel;
- default_syslog;
- default_debug;
-};</programlisting>
-<para>To discard all messages in a category, specify the <command>null</command> channel:</para>
-<programlisting>category xfer-out { null; };
-category notify { null; };
-</programlisting>
-<para>Following are the available categories and brief descriptions
-of the types of log information they contain. More
-categories may be added in future <acronym>BIND</acronym> releases.</para>
-<informaltable
- colsep = "0" rowsep = "0"><tgroup cols = "2"
- colsep = "0" rowsep = "0" tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.150in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.350in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><command>default</command></para></entry>
-<entry colname = "2"><para>The default category defines the logging
-options for those categories where no specific configuration has been
-defined.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>general</command></para></entry>
-<entry colname = "2"><para>The catch-all. Many things still aren't
-classified into categories, and they all end up here.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>database</command></para></entry>
-<entry colname = "2"><para>Messages relating to the databases used
-internally by the name server to store zone and cache data.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>security</command></para></entry>
-<entry colname = "2"><para>Approval and denial of requests.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>config</command></para></entry>
-<entry colname = "2"><para>Configuration file parsing and processing.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>resolver</command></para></entry>
-<entry colname = "2"><para>DNS resolution, such as the recursive
-lookups performed on behalf of clients by a caching name server.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>xfer-in</command></para></entry>
-<entry colname = "2"><para>Zone transfers the server is receiving.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>xfer-out</command></para></entry>
-<entry colname = "2"><para>Zone transfers the server is sending.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>notify</command></para></entry>
-<entry colname = "2"><para>The NOTIFY protocol.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>client</command></para></entry>
-<entry colname = "2"><para>Processing of client requests.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>unmatched</command></para></entry>
-<entry colname = "2"><para>Messages that named was unable to determine the
-class of or for which there was no matching <command>view</command>.
-A one line summary is also logged to the <command>client</command> category.
-This category is best sent to a file or stderr, by default it is sent to
-the <command>null</command> channel.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>network</command></para></entry>
-<entry colname = "2"><para>Network operations.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>update</command></para></entry>
-<entry colname = "2"><para>Dynamic updates.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>update-security</command></para></entry>
-<entry colname = "2"><para>Approval and denial of update requests.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>queries</command></para></entry>
-<entry colname = "2"><para>Specify where queries should be logged to.</para>
-<para>
-At startup, specifing the category <command>queries</command> will also
-enable query logging unless <command>querylog</command> option has been
-specified.
-</para>
-<para>
-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).</para>
-<para><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
-</para>
-<para><computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
-</para>
-</entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>dispatch</command></para></entry>
-<entry colname = "2"><para>Dispatching of incoming packets to the
-server modules where they are to be processed.
-</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>dnssec</command></para></entry>
-<entry colname = "2"><para>DNSSEC and TSIG protocol processing.
-</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>lame-servers</command></para></entry>
-<entry colname = "2"><para>Lame servers. These are misconfigurations
-in remote servers, discovered by BIND 9 when trying to query
-those servers during resolution.
-</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>delegation-only</command></para></entry>
-<entry colname = "2"><para>Delegation only. Logs queries that have have
-been forced to NXDOMAIN as the result of a delegation-only zone or
-a <command>delegation-only</command> in a hint or stub zone declaration.
-</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-</sect3>
-</sect2>
-
-<sect2>
-<title><command>lwres</command> Statement Grammar</title>
-
-<para> This is the grammar of the <command>lwres</command>
-statement in the <filename>named.conf</filename> file:</para>
-
-<programlisting><command>lwres</command> {
- <optional> listen-on { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
- <optional> view <replaceable>view_name</replaceable>; </optional>
- <optional> search { <replaceable>domain_name</replaceable> ; <optional> <replaceable>domain_name</replaceable> ; ... </optional> }; </optional>
- <optional> ndots <replaceable>number</replaceable>; </optional>
-};
-</programlisting>
-
-</sect2>
-<sect2>
-<title><command>lwres</command> Statement Definition and Usage</title>
-
-<para>The <command>lwres</command> statement configures the name
-server to also act as a lightweight resolver server, see
-<xref linkend="lwresd"/>. There may be be multiple
-<command>lwres</command> statements configuring
-lightweight resolver servers with different properties.</para>
-
-<para>The <command>listen-on</command> 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.</para>
-
-<para>The <command>view</command> 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.</para>
-
-<para>The <command>search</command> statement is equivalent to the
-<command>search</command> statement in
-<filename>/etc/resolv.conf</filename>. It provides a list of domains
-which are appended to relative names in queries.</para>
-
-<para>The <command>ndots</command> statement is equivalent to the
-<command>ndots</command> statement in
-<filename>/etc/resolv.conf</filename>. 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.</para>
-</sect2>
-<sect2>
- <title><command>masters</command> Statement Grammar</title>
-<programlisting>
-<command>masters</command> <replaceable>name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> } ;
-</programlisting>
-</sect2>
-<sect2>
- <title><command>masters</command> Statement Definition and Usage </title>
-<para><command>masters</command> lists allow for a common set of masters
-to be easily used by multiple stub and slave zones.</para>
-</sect2>
-<sect2>
-<title><command>options</command> Statement Grammar</title>
-
-<para>This is the grammar of the <command>options</command>
-statement in the <filename>named.conf</filename> file:</para>
-
-<programlisting>options {
- <optional> version <replaceable>version_string</replaceable>; </optional>
- <optional> hostname <replaceable>hostname_string</replaceable>; </optional>
- <optional> server-id <replaceable>server_id_string</replaceable>; </optional>
- <optional> directory <replaceable>path_name</replaceable>; </optional>
- <optional> key-directory <replaceable>path_name</replaceable>; </optional>
- <optional> named-xfer <replaceable>path_name</replaceable>; </optional>
- <optional> tkey-domain <replaceable>domainname</replaceable>; </optional>
- <optional> tkey-dhkey <replaceable>key_name</replaceable> <replaceable>key_tag</replaceable>; </optional>
- <optional> dump-file <replaceable>path_name</replaceable>; </optional>
- <optional> memstatistics-file <replaceable>path_name</replaceable>; </optional>
- <optional> pid-file <replaceable>path_name</replaceable>; </optional>
- <optional> statistics-file <replaceable>path_name</replaceable>; </optional>
- <optional> zone-statistics <replaceable>yes_or_no</replaceable>; </optional>
- <optional> auth-nxdomain <replaceable>yes_or_no</replaceable>; </optional>
- <optional> deallocate-on-exit <replaceable>yes_or_no</replaceable>; </optional>
- <optional> dialup <replaceable>dialup_option</replaceable>; </optional>
- <optional> fake-iquery <replaceable>yes_or_no</replaceable>; </optional>
- <optional> fetch-glue <replaceable>yes_or_no</replaceable>; </optional>
- <optional> flush-zones-on-shutdown <replaceable>yes_or_no</replaceable>; </optional>
- <optional> has-old-clients <replaceable>yes_or_no</replaceable>; </optional>
- <optional> host-statistics <replaceable>yes_or_no</replaceable>; </optional>
- <optional> host-statistics-max <replaceable>number</replaceable>; </optional>
- <optional> minimal-responses <replaceable>yes_or_no</replaceable>; </optional>
- <optional> multiple-cnames <replaceable>yes_or_no</replaceable>; </optional>
- <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable>; </optional>
- <optional> recursion <replaceable>yes_or_no</replaceable>; </optional>
- <optional> rfc2308-type1 <replaceable>yes_or_no</replaceable>; </optional>
- <optional> use-id-pool <replaceable>yes_or_no</replaceable>; </optional>
- <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable>; </optional>
- <optional> dnssec-enable <replaceable>yes_or_no</replaceable>; </optional>
- <optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional>
- <optional> dnssec-must-be-secure <replaceable>domain yes_or_no</replaceable>; </optional>
- <optional> forward ( <replaceable>only</replaceable> | <replaceable>first</replaceable> ); </optional>
- <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
- <optional> dual-stack-servers <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>domain_name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ) ; ... }; </optional>
- <optional> check-names ( <replaceable>master</replaceable> | <replaceable>slave</replaceable> | <replaceable>response</replaceable> )( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
- <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> allow-recursion { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> allow-v6-synthesis { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> blackhole { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> avoid-v4-udp-ports { <replaceable>port_list</replaceable> }; </optional>
- <optional> avoid-v6-udp-ports { <replaceable>port_list</replaceable> }; </optional>
- <optional> listen-on <optional> port <replaceable>ip_port</replaceable> </optional> { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> listen-on-v6 <optional> port <replaceable>ip_port</replaceable> </optional> { <replaceable>address_match_list</replaceable> }; </optional>
- <optional> query-source <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional>
- <optional> query-source-v6 <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional>
- <optional> max-transfer-time-in <replaceable>number</replaceable>; </optional>
- <optional> max-transfer-time-out <replaceable>number</replaceable>; </optional>
- <optional> max-transfer-idle-in <replaceable>number</replaceable>; </optional>
- <optional> max-transfer-idle-out <replaceable>number</replaceable>; </optional>
- <optional> tcp-clients <replaceable>number</replaceable>; </optional>
- <optional> recursive-clients <replaceable>number</replaceable>; </optional>
- <optional> serial-query-rate <replaceable>number</replaceable>; </optional>
- <optional> serial-queries <replaceable>number</replaceable>; </optional>
- <optional> tcp-listen-queue <replaceable>number</replaceable>; </optional>
- <optional> transfer-format <replaceable>( one-answer | many-answers )</replaceable>; </optional>
- <optional> transfers-in <replaceable>number</replaceable>; </optional>
- <optional> transfers-out <replaceable>number</replaceable>; </optional>
- <optional> transfers-per-ns <replaceable>number</replaceable>; </optional>
- <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional>
- <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
- <optional> max-ixfr-log-size <replaceable>number</replaceable>; </optional>
- <optional> max-journal-size <replaceable>size_spec</replaceable>; </optional>
- <optional> coresize <replaceable>size_spec</replaceable> ; </optional>
- <optional> datasize <replaceable>size_spec</replaceable> ; </optional>
- <optional> files <replaceable>size_spec</replaceable> ; </optional>
- <optional> stacksize <replaceable>size_spec</replaceable> ; </optional>
- <optional> cleaning-interval <replaceable>number</replaceable>; </optional>
- <optional> heartbeat-interval <replaceable>number</replaceable>; </optional>
- <optional> interface-interval <replaceable>number</replaceable>; </optional>
- <optional> statistics-interval <replaceable>number</replaceable>; </optional>
- <optional> topology { <replaceable>address_match_list</replaceable> }</optional>;
- <optional> sortlist { <replaceable>address_match_list</replaceable> }</optional>;
- <optional> rrset-order { <replaceable>order_spec</replaceable> ; <optional> <replaceable>order_spec</replaceable> ; ... </optional> </optional> };
- <optional> lame-ttl <replaceable>number</replaceable>; </optional>
- <optional> max-ncache-ttl <replaceable>number</replaceable>; </optional>
- <optional> max-cache-ttl <replaceable>number</replaceable>; </optional>
- <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
- <optional> min-roots <replaceable>number</replaceable>; </optional>
- <optional> use-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> provide-ixfr <replaceable>yes_or_no</replaceable>; </optional>
- <optional> request-ixfr <replaceable>yes_or_no</replaceable>; </optional>
- <optional> treat-cr-as-space <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
- <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
- <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
- <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
- <optional> port <replaceable>ip_port</replaceable>; </optional>
- <optional> additional-from-auth <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> additional-from-cache <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> random-device <replaceable>path_name</replaceable> ; </optional>
- <optional> max-cache-size <replaceable>size_spec</replaceable> ; </optional>
- <optional> match-mapped-addresses <replaceable>yes_or_no</replaceable>; </optional>
- <optional> preferred-glue ( <replaceable>A</replaceable> | <replaceable>AAAA</replaceable> | <replaceable>NONE</replaceable> ); </optional>
- <optional> edns-udp-size <replaceable>number</replaceable>; </optional>
- <optional> root-delegation-only <optional> exclude { <replaceable>namelist</replaceable> } </optional> ; </optional>
- <optional> querylog <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> disable-algorithms <replaceable>domain</replaceable> { <replaceable>algorithm</replaceable>; <optional> <replaceable>algorithm</replaceable>; </optional> }; </optional>
-};
-</programlisting>
-</sect2>
-
-<sect2 id="options"><title><command>options</command> Statement Definition and Usage</title>
-
-<para>The <command>options</command> statement sets up global options
-to be used by <acronym>BIND</acronym>. This statement may appear only
-once in a configuration file. If there is no <command>options</command>
-statement, an options block with each option set to its default will
-be used.</para>
-
-<variablelist>
-
-<varlistentry><term><command>directory</command></term>
-<listitem><para>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. <filename>named.run</filename>) is this directory.
-If a directory is not specified, the working directory defaults
-to `<filename>.</filename>', the directory from which the server
-was started. The directory specified should be an absolute path.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>key-directory</command></term>
-<listitem><para>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.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>named-xfer</command></term>
-<listitem><para><emphasis>This option is obsolete.</emphasis>
-It was used in <acronym>BIND</acronym> 8 to
-specify the pathname to the <command>named-xfer</command> program.
-In <acronym>BIND</acronym> 9, no separate <command>named-xfer</command> program is
-needed; its functionality is built into the name server.</para>
-
-</listitem></varlistentry>
-
-<varlistentry><term><command>tkey-domain</command></term>
-<listitem><para>The domain appended to the names of all
-shared keys generated with <command>TKEY</command>. When a client
-requests a <command>TKEY</command> exchange, it may or may not specify
-the desired name for the key. If present, the name of the shared
-key will be "<varname>client specified part</varname>" +
-"<varname>tkey-domain</varname>".
-Otherwise, the name of the shared key will be "<varname>random hex
-digits</varname>" + "<varname>tkey-domain</varname>". In most cases,
-the <command>domainname</command> should be the server's domain
-name.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>tkey-dhkey</command></term>
-<listitem><para>The Diffie-Hellman key used by the server
-to generate shared keys with clients using the Diffie-Hellman mode
-of <command>TKEY</command>. 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.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>dump-file</command></term>
-<listitem><para>The pathname of the file the server dumps
-the database to when instructed to do so with
-<command>rndc dumpdb</command>.
-If not specified, the default is <filename>named_dump.db</filename>.</para>
-</listitem></varlistentry>
-<varlistentry><term><command>memstatistics-file</command></term>
-<listitem><para>The pathname of the file the server writes memory
-usage statistics to on exit. If not specified,
-the default is <filename>named.memstats</filename>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>pid-file</command></term>
-<listitem><para>The pathname of the file the server writes its process ID
-in. If not specified, the default is <filename>/var/run/named.pid</filename>.
-The pid-file is used by programs that want to send signals to the running
-name server. Specifying <command>pid-file none</command> disables the
-use of a PID file &mdash; no file will be written and any
-existing one will be removed. Note that <command>none</command>
-is a keyword, not a file name, and therefore is not enclosed in
-double quotes.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>statistics-file</command></term>
-<listitem><para>The pathname of the file the server appends statistics
-to when instructed to do so using <command>rndc stats</command>.
-If not specified, the default is <filename>named.stats</filename> in the
-server's current directory. The format of the file is described
-in <xref linkend="statsfile"/></para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>port</command></term>
-<listitem><para>
-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.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>random-device</command></term>
-<listitem><para>
-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
-<filename>/dev/random</filename>
-(or equivalent) when present, and none otherwise. The
-<command>random-device</command> option takes effect during
-the initial configuration load at server startup time and
-is ignored on subsequent reloads.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>preferred-glue</command></term>
-<listitem><para>
-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).
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>root-delegation-only</command></term>
-<listitem><para>
-Turn on enforcement of delegation-only in TLDs and root zones with an optional
-exclude list.
-</para>
-<para>
-Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM").
-</para>
-<programlisting>
-options {
- root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
-};
-</programlisting>
-</listitem></varlistentry>
-
-<varlistentry><term><command>disable-algorithms</command></term>
-<listitem><para>
-Disable the specified DNSSEC algorithms at and below the specified name.
-Multiple <command>disable-algorithms</command> statements are allowed.
-Only the most specific will be applied.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>dnssec-lookaside</command></term>
-<listitem><para>
-When set <command>dnssec-lookaside</command> 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 <command>dnssec-lookaside</command>, 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.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>dnssec-must-be-secure</command></term>
-<listitem><para>
-Specify heirarchies which must / may not be secure (signed and validated).
-If <userinput>yes</userinput> then named will only accept answers if they
-are secure.
-If <userinput>no</userinput> then normal dnssec validation applies
-allowing for insecure answers to be accepted.
-The specified domain must be under a <command>trusted-key</command> or
-<command>dnssec-lookaside</command> must be active.
-</para></listitem></varlistentry>
-
-</variablelist>
-
-<sect3 id="boolean_options"><title>Boolean Options</title>
-
-<variablelist>
-
-<varlistentry><term><command>auth-nxdomain</command></term>
-<listitem><para>If <userinput>yes</userinput>, then the <command>AA</command> bit
-is always set on NXDOMAIN responses, even if the server is not actually
-authoritative. The default is <userinput>no</userinput>; this is
-a change from <acronym>BIND</acronym> 8. If you are using very old DNS software, you
-may need to set it to <userinput>yes</userinput>.</para></listitem></varlistentry>
-
-<varlistentry><term><command>deallocate-on-exit</command></term>
-<listitem><para>This option was used in <acronym>BIND</acronym> 8 to enable checking
-for memory leaks on exit. <acronym>BIND</acronym> 9 ignores the option and always performs
-the checks.</para></listitem></varlistentry>
-
-<varlistentry><term><command>dialup</command></term>
-<listitem><para>If <userinput>yes</userinput>, 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 <command>heartbeat-interval</command> and
-hopefully during the one call. It also suppresses some of the normal
-zone maintenance traffic. The default is <userinput>no</userinput>.</para>
-<para>The <command>dialup</command> option
-may also be specified in the <command>view</command> and
-<command>zone</command> statements,
-in which case it overrides the global <command>dialup</command>
-option.</para>
-<para>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
-<command>notify</command> and <command>also-notify</command>.</para>
-<para>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
-<command>heartbeat-interval</command> expires in addition to sending
-NOTIFY requests.</para><para>Finer control can be achieved by using
-<userinput>notify</userinput> which only sends NOTIFY messages,
-<userinput>notify-passive</userinput> which sends NOTIFY messages and
-suppresses the normal refresh queries, <userinput>refresh</userinput>
-which suppresses normal refresh processing and sends refresh queries
-when the <command>heartbeat-interval</command> expires, and
-<userinput>passive</userinput> which just disables normal refresh
-processing.</para>
-
-<informaltable colsep = "0" rowsep = "0">
-<tgroup cols = "4" colsep = "0" rowsep = "0" tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.150in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "1.150in"/>
-<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "1.150in"/>
-<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "1.150in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para>dialup mode</para></entry>
-<entry colname = "2"><para>normal refresh</para></entry>
-<entry colname = "3"><para>heart-beat refresh</para></entry>
-<entry colname = "4"><para>heart-beat notify</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>no</command> (default)</para></entry>
-<entry colname = "2"><para>yes</para></entry>
-<entry colname = "3"><para>no</para></entry>
-<entry colname = "4"><para>no</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>yes</command></para></entry>
-<entry colname = "2"><para>no</para></entry>
-<entry colname = "3"><para>yes</para></entry>
-<entry colname = "4"><para>yes</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>notify</command></para></entry>
-<entry colname = "2"><para>yes</para></entry>
-<entry colname = "3"><para>no</para></entry>
-<entry colname = "4"><para>yes</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>refresh</command></para></entry>
-<entry colname = "2"><para>no</para></entry>
-<entry colname = "3"><para>yes</para></entry>
-<entry colname = "4"><para>no</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>passive</command></para></entry>
-<entry colname = "2"><para>no</para></entry>
-<entry colname = "3"><para>no</para></entry>
-<entry colname = "4"><para>no</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>notify-passive</command></para></entry>
-<entry colname = "2"><para>no</para></entry>
-<entry colname = "3"><para>no</para></entry>
-<entry colname = "4"><para>yes</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-
-<para>Note that normal NOTIFY processing is not affected by
-<command>dialup</command>.</para>
-
-</listitem></varlistentry>
-
-<varlistentry><term><command>fake-iquery</command></term>
-<listitem><para>In <acronym>BIND</acronym> 8, this option
-enabled simulating the obsolete DNS query type
-IQUERY. <acronym>BIND</acronym> 9 never does IQUERY simulation.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>fetch-glue</command></term>
-<listitem><para>This option is obsolete.
-In BIND 8, <userinput>fetch-glue yes</userinput>
-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.</para></listitem></varlistentry>
-
-<varlistentry><term><command>flush-zones-on-shutdown</command></term>
-<listitem><para>When the nameserver exits due receiving SIGTERM,
-flush / do not flush any pending zone writes. The default is
-<command>flush-zones-on-shutdown</command> <userinput>no</userinput>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>has-old-clients</command></term>
-<listitem><para>This option was incorrectly implemented
-in <acronym>BIND</acronym> 8, and is ignored by <acronym>BIND</acronym> 9.
-To achieve the intended effect
-of
-<command>has-old-clients</command> <userinput>yes</userinput>, specify
-the two separate options <command>auth-nxdomain</command> <userinput>yes</userinput>
-and <command>rfc2308-type1</command> <userinput>no</userinput> instead.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>host-statistics</command></term>
-<listitem><para>In BIND 8, this enables keeping of
-statistics for every host that the name server interacts with.
-Not implemented in BIND 9.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>maintain-ixfr-base</command></term>
-<listitem><para><emphasis>This option is obsolete</emphasis>.
- It was used in <acronym>BIND</acronym> 8 to determine whether a transaction log was
-kept for Incremental Zone Transfer. <acronym>BIND</acronym> 9 maintains a transaction
-log whenever possible. If you need to disable outgoing incremental zone
-transfers, use <command>provide-ixfr</command> <userinput>no</userinput>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>minimal-responses</command></term>
-<listitem><para>If <userinput>yes</userinput>, 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 <userinput>no</userinput>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>multiple-cnames</command></term>
-<listitem><para>This option was used in <acronym>BIND</acronym> 8 to allow
-a domain name to have multiple CNAME records in violation of the
-DNS standards. <acronym>BIND</acronym> 9.2 always strictly
-enforces the CNAME rules both in master files and dynamic updates.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>notify</command></term>
-<listitem><para>If <userinput>yes</userinput> (the default),
-DNS NOTIFY messages are sent when a zone the server is authoritative for
-changes, see <xref linkend="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
-<command>also-notify</command> option.
-</para><para>
-If <userinput>explicit</userinput>, notifies are sent only to
-servers explicitly listed using <command>also-notify</command>.
-If <userinput>no</userinput>, no notifies are sent.
-</para><para>
-The <command>notify</command> option may also be
-specified in the <command>zone</command> statement,
-in which case it overrides the <command>options notify</command> statement.
-It would only be necessary to turn off this option if it caused slaves
-to crash.</para></listitem></varlistentry>
-
-<varlistentry><term><command>recursion</command></term>
-<listitem><para>If <userinput>yes</userinput>, 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 <userinput>yes</userinput>.
-Note that setting <command>recursion no</command> 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 <command>fetch-glue</command> above.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>rfc2308-type1</command></term>
-<listitem><para>Setting this to <userinput>yes</userinput> will
-cause the server to send NS records along with the SOA record for negative
-answers. The default is <userinput>no</userinput>.</para>
-<note><simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note>
-</listitem></varlistentry>
-
-<varlistentry><term><command>use-id-pool</command></term>
-<listitem><para><emphasis>This option is obsolete</emphasis>.
-<acronym>BIND</acronym> 9 always allocates query IDs from a pool.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>zone-statistics</command></term>
-<listitem><para>If <userinput>yes</userinput>, the server will collect
-statistical data on all zones (unless specifically turned off
-on a per-zone basis by specifying <command>zone-statistics no</command>
-in the <command>zone</command> statement). These statistics may be accessed
-using <command>rndc stats</command>, which will dump them to the file listed
-in the <command>statistics-file</command>. See also <xref linkend="statsfile"/>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>use-ixfr</command></term>
-<listitem><para><emphasis>This option is obsolete</emphasis>.
-If you need to disable IXFR to a particular server or servers see
-the information on the <command>provide-ixfr</command> option
-in <xref linkend="server_statement_definition_and_usage"/>. See also
-<xref linkend="incremental_zone_transfers"/>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>provide-ixfr</command></term>
-<listitem>
-<para>
-See the description of
-<command>provide-ixfr</command> in
-<xref linkend="server_statement_definition_and_usage"/>
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>request-ixfr</command></term>
-<listitem>
-<para>
-See the description of
-<command>request-ixfr</command> in
-<xref linkend="server_statement_definition_and_usage"/>
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>treat-cr-as-space</command></term>
-<listitem><para>This option was used in <acronym>BIND</acronym> 8 to make
-the server treat carriage return ("<command>\r</command>") 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 <acronym>BIND</acronym> 9, both UNIX "<command>\n</command>"
-and NT/DOS "<command>\r\n</command>" newlines are always accepted,
-and the option is ignored.</para></listitem></varlistentry>
-
-<varlistentry>
-<term><command>additional-from-auth</command></term>
-<term><command>additional-from-cache</command></term>
-<listitem>
-
-<para>
-These options control the behavior of an authoritative server when
-answering queries which have additional data, or when following CNAME
-and DNAME chains.
-</para>
-
-<para>
-When both of these options are set to <userinput>yes</userinput>
-(the default) and a
-query is being answered from authoritative data (a zone
-configured into the server), the additional data section of the
-reply will be filled in using data from other authoritative zones
-and from the cache. In some situations this is undesirable, such
-as when there is concern over the correctness of the cache, or
-in servers where slave zones may be added and modified by
-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.
-</para>
-
-<para>
-For example, if a query asks for an MX record for host <literal>foo.example.com</literal>,
-and the record found is "<literal>MX 10 mail.example.net</literal>", normally the address
-records (A and AAAA) for <literal>mail.example.net</literal> will be provided as well,
-if known, even though they are not in the example.com zone.
-Setting these options to <command>no</command> disables this behavior and makes
-the server only search for additional data in the zone it answers from.
-</para>
-
-<para>
-These options are intended for use in authoritative-only
-servers, or in authoritative-only views. Attempts to set
-them to <command>no</command> without also specifying
-<command>recursion no</command> will cause the server to
-ignore the options and log a warning message.
-</para>
-
-<para>
-Specifying <command>additional-from-cache no</command> 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.
-</para>
-
-<para>
-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 <command>additional-from-cache no</command>
-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.
-</para>
-
-</listitem></varlistentry>
-
-<varlistentry><term><command>match-mapped-addresses</command></term>
-<listitem><para>If <userinput>yes</userinput>, 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
-systems, to work around a kernel quirk that causes IPv4
-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.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>ixfr-from-differences</command></term>
-<listitem>
-<para>
-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.
-</para><para>
-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
-different from the previous one, the set of differences
-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.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>multi-master</command></term>
-<listitem>
-<para>
-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 <userinput>no</userinput>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>dnssec-enable</command></term>
-<listitem>
-<para>
-Enable DNSSEC support in named. Unless set to <userinput>yes</userinput>
-named behaves as if it does not support DNSSEC.
-The default is <userinput>no</userinput>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>querylog</command></term>
-<listitem>
-<para>
-Specify whether query logging should be started when named start.
-If <command>querylog</command> is not specified then the query logging
-is determined by the presence of the logging category <command>queries</command>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>check-names</command></term>
-<listitem>
-<para>
-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
-<command>master</command> zones the default is <command>fail</command>.
-For <command>slave</command> zones the default is <command>warn</command>.
-For answer received from the network (<command>response</command>)
-the default is <command>ignore</command>.
-</para>
-<para>The rules for legal hostnames / mail domains are derived from RFC 952
-and RFC 821 as modified by RFC 1123.
-</para>
-<para><command>check-names</command> 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).
-</para>
-</listitem></varlistentry>
-
-</variablelist>
-
-</sect3>
-
-<sect3><title>Forwarding</title>
-<para>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.</para>
-
-<variablelist>
-<varlistentry><term><command>forward</command></term>
-<listitem><para>This option is only meaningful if the
-forwarders list is not empty. A value of <varname>first</varname>,
-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 <varname>only</varname> is specified, the
-server will only query the forwarders.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>forwarders</command></term>
-<listitem><para>Specifies the IP addresses to be used
-for forwarding. The default is the empty list (no forwarding).
-</para></listitem></varlistentry>
-
-</variablelist>
-
-<para>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 <command>forward only/first</command> behavior,
-or not forward at all, see <xref linkend="zone_statement_grammar"/>.</para>
-</sect3>
-
-<sect3><title>Dual-stack Servers</title>
-<para>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.</para>
-
-<variablelist>
-<varlistentry><term><command>dual-stack-servers</command></term>
-<listitem><para>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 <command>dual-stack-servers</command> have no effect unless
-access to a transport has been disabled on the command line
-(e.g. <command>named -4</command>).</para></listitem>
-</varlistentry>
-</variablelist>
-</sect3>
-
-<sect3 id="access_control"><title>Access Control</title>
-
-<para>Access to the server can be restricted based on the IP address
-of the requesting system. See <xref linkend="address_match_lists"/> for
-details on how to specify IP address lists.</para>
-
-<variablelist>
-
-<varlistentry><term><command>allow-notify</command></term>
-<listitem><para>Specifies which hosts are allowed to
-notify this server, a slave, of zone changes in addition
-to the zone masters.
-<command>allow-notify</command> may also be specified in the
-<command>zone</command> statement, in which case it overrides the
-<command>options allow-notify</command> 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.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>allow-query</command></term>
-<listitem><para>Specifies which hosts are allowed to
-ask ordinary DNS questions. <command>allow-query</command> may also
-be specified in the <command>zone</command> statement, in which
-case it overrides the <command>options allow-query</command> statement. If
-not specified, the default is to allow queries from all hosts.</para>
-</listitem></varlistentry>
-
-
-<varlistentry><term><command>allow-recursion</command></term>
-<listitem><para>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.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>allow-update-forwarding</command></term>
-<listitem><para>Specifies which hosts are allowed to
-submit Dynamic DNS updates to slave zones to be forwarded to the
-master. The default is <userinput>{ none; }</userinput>, which
-means that no update forwarding will be performed. To enable
-update forwarding, specify
-<userinput>allow-update-forwarding { any; };</userinput>.
-Specifying values other than <userinput>{ none; }</userinput> or
-<userinput>{ any; }</userinput> is usually counterproductive, since
-the responsibility for update access control should rest with the
-master server, not the slaves.</para>
-<para>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 <xref linkend="dynamic_update_security"/>
-for more details.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>allow-v6-synthesis</command></term>
-<listitem><para>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.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>allow-transfer</command></term>
-<listitem><para>Specifies which hosts are allowed to
-receive zone transfers from the server. <command>allow-transfer</command> may
-also be specified in the <command>zone</command> statement, in which
-case it overrides the <command>options allow-transfer</command> statement.
-If not specified, the default is to allow transfers to all hosts.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>blackhole</command></term>
-<listitem><para>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 <userinput>none</userinput>.</para>
-</listitem></varlistentry>
-
-</variablelist>
-
-</sect3>
-
-<sect3><title>Interfaces</title>
-<para>The interfaces and ports that the server will answer queries
-from may be specified using the <command>listen-on</command> option. <command>listen-on</command> takes
-an optional port, and an <varname>address_match_list</varname>.
-The server will listen on all interfaces allowed by the address
-match list. If a port is not specified, port 53 will be used.</para>
-<para>Multiple <command>listen-on</command> statements are allowed.
-For example,</para>
-
-<programlisting>listen-on { 5.6.7.8; };
-listen-on port 1234 { !1.2.3.4; 1.2/16; };
-</programlisting>
-
-<para>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.</para>
-
-<para>If no <command>listen-on</command> is specified, the
-server will listen on port 53 on all interfaces.</para>
-
-<para>The <command>listen-on-v6</command> option is used to
-specify the interfaces and the ports on which the server will listen
-for incoming queries sent using IPv6.</para>
-
-<para>When <programlisting>{ any; }</programlisting> is specified
-as the <varname>address_match_list</varname> for the
-<command>listen-on-v6</command> 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.</para>
-
-<para>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.</para>
-
-<para>Multiple <command>listen-on-v6</command> options can be used.
-For example,</para>
-
-<programlisting>listen-on-v6 { any; };
-listen-on-v6 port 1234 { !2001:db8::/32; any; };
-</programlisting>
-
-<para>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.)</para>
-
-<para>To make the server not listen on any IPv6 address, use</para>
-<programlisting>listen-on-v6 { none; };
-</programlisting>
-<para>If no <command>listen-on-v6</command> option is specified,
-the server will not listen on any IPv6 address.</para></sect3>
-
-<sect3><title>Query Address</title>
-<para>If the server doesn't know the answer to a question, it will
-query other name servers. <command>query-source</command> specifies
-the address and port used for such queries. For queries sent over
-IPv6, there is a separate <command>query-source-v6</command> option.
-If <command>address</command> is <command>*</command> or is omitted,
-a wildcard IP address (<command>INADDR_ANY</command>) will be used.
-If <command>port</command> is <command>*</command> or is omitted,
-a random unprivileged port will be used, <command>avoid-v4-udp-ports</command>
-and <command>avoid-v6-udp-ports</command> can be used to prevent named
-from selecting certain ports. The defaults are</para>
-<programlisting>query-source address * port *;
-query-source-v6 address * port *;
-</programlisting>
-<note>
-<para>The address specified in the <command>query-source</command> 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.</para></note>
-<note>
-<para>See also <command>transfer-source</command> and
-<command>notify-source</command>.</para></note>
-</sect3>
-
-<sect3 id="zone_transfers"><title>Zone Transfers</title>
-<para><acronym>BIND</acronym> 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.</para>
-
-<variablelist>
-
-<varlistentry><term><command>also-notify</command></term>
-<listitem><para>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 <command>also-notify</command> list
-is given in a <command>zone</command> statement, it will override
-the <command>options also-notify</command> statement. When a <command>zone notify</command> statement
-is set to <command>no</command>, the IP addresses in the global <command>also-notify</command> list will
-not be sent NOTIFY messages for that zone. The default is the empty
-list (no global notification list).</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-transfer-time-in</command></term>
-<listitem><para>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).</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-transfer-idle-in</command></term>
-<listitem><para>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).</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-transfer-time-out</command></term>
-<listitem><para>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).</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-transfer-idle-out</command></term>
-<listitem><para>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).</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>serial-query-rate</command></term>
-<listitem><para>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 <command>serial-query-rate</command> option,
-an integer, is the maximum number of queries sent per second.
-The default is 20.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>serial-queries</command></term>
-<listitem><para>In BIND 8, the <command>serial-queries</command> 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 <command>serial-queries</command> option.
-Instead, it limits the rate at which the queries are sent
-as defined using the <command>serial-query-rate</command> option.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>transfer-format</command></term>
-<listitem>
-
-<para>
-Zone transfers can be sent using two different formats,
-<command>one-answer</command> and <command>many-answers</command>.
-The <command>transfer-format</command> option is used
-on the master server to determine which format it sends.
-<command>one-answer</command> uses one DNS message per
-resource record transferred.
-<command>many-answers</command> packs as many resource records as
-possible into a message. <command>many-answers</command> is more
-efficient, but is only supported by relatively new slave servers,
-such as <acronym>BIND</acronym> 9, <acronym>BIND</acronym> 8.x and patched
-versions of <acronym>BIND</acronym> 4.9.5. The default is
-<command>many-answers</command>. <command>transfer-format</command>
-may be overridden on a per-server basis by using the
-<command>server</command> statement.
-</para>
-
-</listitem></varlistentry>
-
-<varlistentry><term><command>transfers-in</command></term>
-<listitem><para>The maximum number of inbound zone transfers
-that can be running concurrently. The default value is <literal>10</literal>.
-Increasing <command>transfers-in</command> may speed up the convergence
-of slave zones, but it also may increase the load on the local system.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>transfers-out</command></term>
-<listitem><para>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 <literal>10</literal>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>transfers-per-ns</command></term>
-<listitem><para>The maximum number of inbound zone transfers
-that can be concurrently transferring from a given remote name server.
-The default value is <literal>2</literal>. Increasing <command>transfers-per-ns</command> may
-speed up the convergence of slave zones, but it also may increase
-the load on the remote name server. <command>transfers-per-ns</command> may
-be overridden on a per-server basis by using the <command>transfers</command> phrase
-of the <command>server</command> statement.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>transfer-source</command></term>
-<listitem><para><command>transfer-source</command> 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 <command>allow-transfer</command> option for
-the zone being transferred, if one is specified. This statement
-sets the <command>transfer-source</command> for all zones, but can
-be overridden on a per-view or per-zone basis by including a
-<command>transfer-source</command> statement within the
-<command>view</command> or <command>zone</command> block
-in the configuration file.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>transfer-source-v6</command></term>
-<listitem><para>The same as <command>transfer-source</command>,
-except zone transfers are performed using IPv6.</para>
- </listitem></varlistentry>
-
- <varlistentry>
- <term><command>alt-transfer-source</command></term>
- <listitem>
- <para>
- An alternate transfer source if the one listed in
- <command>transfer-source</command> fails and
- <command>use-alt-transfer-source</command> is
- set.
- </para>
- <note>
- If you do not wish the alternate transfer source
- to be used you should set
- <command>use-alt-transfer-source</command>
- appropriately and you should not depend upon
- getting a answer back to the first refresh
- query.
- </note>
- </listitem>
- </varlistentry>
-
-<varlistentry><term><command>alt-transfer-source-v6</command></term>
-<listitem><para>An alternate transfer source if the one listed in
-<command>transfer-source-v6</command> fails and
-<command>use-alt-transfer-source</command> is set.</para>
- </listitem></varlistentry>
-
-<varlistentry><term><command>use-alt-transfer-source</command></term>
-<listitem><para>Use the alternate transfer sources or not. If views are
-specified this defaults to <command>no</command> otherwise it defaults to
-<command>yes</command> (for BIND 8 compatibility).</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>notify-source</command></term>
-<listitem><para><command>notify-source</command> 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 <command>masters</command>
-zone clause or in an <command>allow-notify</command> clause.
-This statement sets the <command>notify-source</command> for all zones,
-but can be overridden on a per-zone / per-view basis by including a
-<command>notify-source</command> statement within the <command>zone</command>
-or <command>view</command> block in the configuration file.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>notify-source-v6</command></term>
-<listitem><para>Like <command>notify-source</command>,
-but applies to notify messages sent to IPv6 addresses.</para>
-</listitem></varlistentry>
-
-</variablelist>
-
-</sect3>
-
-<sect3>
-<title>Bad UDP Port Lists</title>
-<para>
-<command>avoid-v4-udp-ports</command> and <command>avoid-v6-udp-ports</command>
-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.
-</para>
-</sect3>
-
-<sect3>
-<title>Operating System Resource Limits</title>
-
-<para>The server's usage of many system resources can be limited.
-Scaled values are allowed when specifying resource limits. For
-example, <command>1G</command> can be used instead of
-<command>1073741824</command> to specify a limit of one
-gigabyte. <command>unlimited</command> requests unlimited use, or the
-maximum available amount. <command>default</command> uses the limit
-that was in force when the server was started. See the description of
-<command>size_spec</command> in <xref
-linkend="configuration_file_elements"/>.</para>
-
-<para>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.</para>
-
-<variablelist>
-
-<varlistentry><term><command>coresize</command></term>
-<listitem><para>The maximum size of a core dump. The default
-is <literal>default</literal>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>datasize</command></term>
-<listitem><para>The maximum amount of data memory the server
-may use. The default is <literal>default</literal>.
-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
-the server unable to perform DNS service. Therefore,
-this option is rarely useful as a way of limiting the
-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
-<command>max-cache-size</command> and
-<command>recursive-clients</command>
-options instead.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>files</command></term>
-<listitem><para>The maximum number of files the server
-may have open concurrently. The default is <literal>unlimited</literal>.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>stacksize</command></term>
-<listitem><para>The maximum amount of stack memory the server
-may use. The default is <literal>default</literal>.</para>
-</listitem></varlistentry>
-
-</variablelist>
-
-</sect3>
-
-<sect3>
-<title>Server Resource Limits</title>
-
-<para>The following options set limits on the server's
-resource consumption that are enforced internally by the
-server rather than the operating system.</para>
-
-<variablelist>
-
-<varlistentry><term><command>max-ixfr-log-size</command></term>
-<listitem><para>This option is obsolete; it is accepted
-and ignored for BIND 8 compatibility. The option
-<command>max-journal-size</command> performs a similar
-function in BIND 8.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-journal-size</command></term>
-<listitem><para>Sets a maximum size for each journal file
-(<xref linkend="journal"/>). When the journal file approaches
-the specified size, some of the oldest transactions in the journal
-will be automatically removed. The default is
-<literal>unlimited</literal>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>host-statistics-max</command></term>
-<listitem><para>In BIND 8, specifies the maximum number of host statistic
-entries to be kept.
-Not implemented in BIND 9.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>recursive-clients</command></term>
-<listitem><para>The maximum number of simultaneous recursive lookups
-the server will perform on behalf of clients. The default is
-<literal>1000</literal>. Because each recursing client uses a fair
-bit of memory, on the order of 20 kilobytes, the value of the
-<command>recursive-clients</command> option may have to be decreased
-on hosts with limited memory.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>tcp-clients</command></term>
-<listitem><para>The maximum number of simultaneous client TCP
-connections that the server will accept.
-The default is <literal>100</literal>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-cache-size</command></term>
-<listitem><para>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 <literal>unlimited</literal>, meaning that
-records are purged from the cache only when their TTLs expire.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>tcp-listen-queue</command></term>
-<listitem><para>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.
-</para>
-</listitem></varlistentry>
-
-</variablelist>
-
-</sect3>
-
-<sect3><title>Periodic Task Intervals</title>
-
-<variablelist>
-
-<varlistentry><term><command>cleaning-interval</command></term>
-<listitem><para>The server will remove expired resource records
-from the cache every <command>cleaning-interval</command> minutes.
-The default is 60 minutes. The maximum value is 28 days (40320 minutes).
-If set to 0, no periodic cleaning will occur.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>heartbeat-interval</command></term>
-<listitem><para>The server will perform zone maintenance tasks
-for all zones marked as <command>dialup</command> 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.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>interface-interval</command></term>
-<listitem><para>The server will scan the network interface list
-every <command>interface-interval</command> 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
-<command>listen-on</command> configuration), and will
-stop listening on interfaces that have gone away.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>statistics-interval</command></term>
-<listitem><para>Name server statistics will be logged
-every <command>statistics-interval</command> minutes. The default is
-60. The maximum value is 28 days (40320 minutes).
-If set to 0, no statistics will be logged.</para><note>
-<simpara>Not yet implemented in <acronym>BIND</acronym>9.</simpara></note>
-</listitem></varlistentry>
-
-</variablelist>
-
-</sect3>
-
-<sect3 id="topology"><title>Topology</title>
-
-<para>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 <command>topology</command> statement
-takes an <command>address_match_list</command> 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
-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,</para>
-<programlisting>topology {
- 10/8;
- !1.2.3/24;
- { 1.2/16; 3/8; };
-};</programlisting>
-<para>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.</para>
-<para>The default topology is</para>
-<programlisting> topology { localhost; localnets; };
-</programlisting>
-<note><simpara>The <command>topology</command> option
-is not implemented in <acronym>BIND</acronym> 9.
-</simpara></note>
-</sect3>
-
-<sect3 id="the_sortlist_statement">
-
-<title>The <command>sortlist</command> Statement</title>
-
-<para>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 <command>rrset-order</command>
-statement in <xref linkend="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.</para>
-
-<para>The <command>sortlist</command> statement (see below) takes
-an <command>address_match_list</command> and interprets it even
-more specifically than the <command>topology</command> statement
-does (<xref linkend="topology"/>).
-Each top level statement in the <command>sortlist</command> must
-itself be an explicit <command>address_match_list</command> with
-one or two elements. The first element (which may be an IP address,
-an IP prefix, an ACL name or a nested <command>address_match_list</command>)
-of each top level list is checked against the source address of
-the query until a match is found.</para>
-<para>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 <command>address_match_list</command> in
-a <command>topology</command> 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.</para>
-<para>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
-or
-192.168.3/24 network with no preference shown between these two
-networks. Queries received from a host on the 192.168.1/24 network
-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.</para>
-<programlisting>sortlist {
- { localhost; // IF the local host
- { localnets; // THEN first fit on the
- 192.168.1/24; // following nets
- { 192.168.2/24; 192.168.3/24; }; }; };
- { 192.168.1/24; // IF on class C 192.168.1
- { 192.168.1/24; // THEN use .1, or .2 or .3
- { 192.168.2/24; 192.168.3/24; }; }; };
- { 192.168.2/24; // IF on class C 192.168.2
- { 192.168.2/24; // THEN use .2, or .1 or .3
- { 192.168.1/24; 192.168.3/24; }; }; };
- { 192.168.3/24; // IF on class C 192.168.3
- { 192.168.3/24; // THEN use .3, or .1 or .2
- { 192.168.1/24; 192.168.2/24; }; }; };
- { { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net
- };
-};</programlisting>
-<para>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 <acronym>BIND</acronym> 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.</para>
-<programlisting>sortlist {
- { localhost; localnets; };
- { localnets; };
-};
-</programlisting>
-</sect3>
-<sect3 id="rrset_ordering"><title id="rrset_ordering_title">RRset Ordering</title>
-<para>When multiple records are returned in an answer it may be
-useful to configure the order of the records placed into the response.
-The <command>rrset-order</command> statement permits configuration
-of the ordering of the records in a multiple record response.
-See also the <command>sortlist</command> statement,
-<xref linkend="the_sortlist_statement"/>.
-</para>
-
-<para>An <command>order_spec</command> is defined as follows:</para>
-<programlisting><optional> class <replaceable>class_name</replaceable> </optional><optional> type <replaceable>type_name</replaceable> </optional><optional> name <replaceable>"domain_name"</replaceable></optional>
- order <replaceable>ordering</replaceable>
-</programlisting>
-<para>If no class is specified, the default is <command>ANY</command>.
-If no type is specified, the default is <command>ANY</command>.
-If no name is specified, the default is "<command>*</command>".</para>
-<para>The legal values for <command>ordering</command> are:</para>
-<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2"
- colsep = "0" rowsep = "0" tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.750in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.750in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><command>fixed</command></para></entry>
-<entry colname = "2"><para>Records are returned in the order they
-are defined in the zone file.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>random</command></para></entry>
-<entry colname = "2"><para>Records are returned in some random order.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>cyclic</command></para></entry>
-<entry colname = "2"><para>Records are returned in a round-robin
-order.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-<para>For example:</para>
-<programlisting>rrset-order {
- class IN type A name "host.example.com" order random;
- order cyclic;
-};
-</programlisting>
-<para>will cause any responses for type A records in class IN that
-have "<literal>host.example.com</literal>" as a suffix, to always be returned
-in random order. All other records are returned in cyclic order.</para>
-<para>If multiple <command>rrset-order</command> statements appear,
-they are not combined &mdash; the last one applies.</para>
-
-<note>
-<simpara>The <command>rrset-order</command> statement
-is not yet fully implemented in <acronym>BIND</acronym> 9.
-BIND 9 currently does not support "fixed" ordering.
-</simpara></note>
-</sect3>
-
-<sect3 id="tuning"><title>Tuning</title>
-
-<variablelist>
-
-<varlistentry><term><command>lame-ttl</command></term>
-<listitem><para>Sets the number of seconds to cache a
-lame server indication. 0 disables caching. (This is
-<emphasis role="bold">NOT</emphasis> recommended.)
-Default is <literal>600</literal> (10 minutes). Maximum value is
-<literal>1800</literal> (30 minutes).</para>
-
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-ncache-ttl</command></term>
-<listitem><para>To reduce network traffic and increase performance
-the server stores negative answers. <command>max-ncache-ttl</command> is
-used to set a maximum retention time for these answers in the server
-in seconds. The default
-<command>max-ncache-ttl</command> is <literal>10800</literal> seconds (3 hours).
-<command>max-ncache-ttl</command> cannot exceed 7 days and will
-be silently truncated to 7 days if set to a greater value.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-cache-ttl</command></term>
-<listitem><para><command>max-cache-ttl</command> sets
-the maximum time for which the server will cache ordinary (positive)
-answers. The default is one week (7 days).</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>min-roots</command></term>
-<listitem><para>The minimum number of root servers that
-is required for a request for the root servers to be accepted. Default
-is <userinput>2</userinput>.</para>
-<note>
-<simpara>Not implemented in <acronym>BIND</acronym>9.</simpara></note>
-</listitem></varlistentry>
-
-<varlistentry><term><command>sig-validity-interval</command></term>
-<listitem><para>Specifies the number of days into the
-future when DNSSEC signatures automatically generated as a result
-of dynamic updates (<xref linkend="dynamic_update"/>)
-will expire. The default is <literal>30</literal> 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.</para>
-</listitem></varlistentry>
-
-<varlistentry>
-<term><command>min-refresh-time</command></term>
-<term><command>max-refresh-time</command></term>
-<term><command>min-retry-time</command></term>
-<term><command>max-retry-time</command></term>
-<listitem><para>
-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.
-</para><para>
-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.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term><command>edns-udp-size</command></term>
-<listitem><para>
-<command>edns-udp-size</command> 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.
-</para></listitem></varlistentry>
-</variablelist>
-
-</sect3>
-
-<sect3 id="builtin">
-<title>Built-in server information zones</title>
-
-<para>The server provides some helpful diagnostic information
-through a number of built-in zones under the
-pseudo-top-level-domain <literal>bind</literal> in the
-<command>CHAOS</command> class. These zones are part of a
-built-in view (see <xref linkend="view_statement_grammar"/>) of class
-<command>CHAOS</command> which is separate from the default view of
-class <command>IN</command>; therefore, any global server options
-such as <command>allow-query</command> do not apply the these zones.
-If you feel the need to disable these zones, use the options
-below, or hide the built-in <command>CHAOS</command> view by
-defining an explicit view of class <command>CHAOS</command>
-that matches all clients.</para>
-
-<variablelist>
-
-<varlistentry><term><command>version</command></term>
-<listitem><para>The version the server should report
-via a query of the name <literal>version.bind</literal>
-with type <command>TXT</command>, class <command>CHAOS</command>.
-The default is the real version number of this server.
-Specifying <command>version none</command>
-disables processing of the queries.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>hostname</command></term>
-<listitem><para>The hostname the server should report via a query of
-the name <filename>hostname.bind</filename>
-with type <command>TXT</command>, class <command>CHAOS</command>.
-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 <command>hostname none;</command>
-disables processing of the queries.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>server-id</command></term>
-<listitem><para>The ID of the server should report via a query of
-the name <filename>ID.SERVER</filename>
-with type <command>TXT</command>, class <command>CHAOS</command>.
-The primary purpose of such queries is to
-identify which of a group of anycast servers is actually
-answering your queries. Specifying <command>server-id none;</command>
-disables processing of the queries.
-Specifying <command>server-id hostname;</command> will cause named to
-use the hostname as found by gethostname().
-The default <command>server-id</command> is <command>none</command>.
-</para>
-</listitem></varlistentry>
-
-</variablelist>
-
-</sect3>
-
-<sect3 id="statsfile">
-<title>The Statistics File</title>
-
-<para>The statistics file generated by <acronym>BIND</acronym> 9
-is similar, but not identical, to that
-generated by <acronym>BIND</acronym> 8.
-</para>
-<para>The statistics dump begins with the line <command>+++ Statistics Dump
-+++ (973798949)</command>, 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 <command>--- Statistics Dump --- (973798949)</command>, where the
-number is identical to the number in the beginning line.</para>
-<para>The following statistics counters are maintained:</para>
-<informaltable
- colsep = "0" rowsep = "0"><tgroup cols = "2"
- colsep = "0" rowsep = "0" tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.150in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.350in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><command>success</command></para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>referral</command></para></entry>
-<entry colname = "2"><para>The number of queries which resulted
-in referral responses.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>nxrrset</command></para></entry>
-<entry colname = "2"><para>The number of queries which resulted in
-NOERROR responses with no data.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>nxdomain</command></para></entry>
-<entry colname = "2"><para>The number
-of queries which resulted in NXDOMAIN responses.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>failure</command></para></entry>
-<entry colname = "2"><para>The number of queries which resulted in a
-failure response other than those above.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>recursion</command></para></entry>
-<entry colname = "2"><para>The number of queries which caused the server
-to perform recursion in order to find the final answer.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-
-<para>
-Each query received by the server will cause exactly one of
-<command>success</command>,
-<command>referral</command>,
-<command>nxrrset</command>,
-<command>nxdomain</command>, or
-<command>failure</command>
-to be incremented, and may additionally cause the
-<command>recursion</command> counter to be incremented.
-</para>
-
-</sect3>
-
-</sect2>
-
-<sect2 id="server_statement_grammar">
-<title><command>server</command> Statement Grammar</title>
-
-<programlisting>server <replaceable>ip_addr</replaceable> {
- <optional> bogus <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> provide-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> request-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> edns <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> transfers <replaceable>number</replaceable> ; </optional>
- <optional> transfer-format <replaceable>( one-answer | many-answers )</replaceable> ; ]</optional>
- <optional> keys <replaceable>{ string ; <optional> string ; <optional>...</optional></optional> }</replaceable> ; </optional>
- <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-};
-</programlisting>
-
-</sect2>
-
-<sect2 id="server_statement_definition_and_usage">
-<title><command>server</command> Statement Definition and Usage</title>
-
-<para>The <command>server</command> statement defines characteristics
-to be associated with a remote name server.</para>
-
-<para>
-The <command>server</command> statement can occur at the top level of the
-configuration file or inside a <command>view</command> statement.
-If a <command>view</command> statement contains
-one or more <command>server</command> statements, only those
-apply to the view and any top-level ones are ignored.
-If a view contains no <command>server</command> statements,
-any top-level <command>server</command> statements are used as
-defaults.
-</para>
-
-<para>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 <command>bogus</command> is <command>no</command>.</para>
-<para>The <command>provide-ixfr</command> 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 <command>yes</command>, incremental transfer will be provided
-whenever possible. If set to <command>no</command>, all transfers
-to the remote server will be non-incremental. If not set, the value
-of the <command>provide-ixfr</command> option in the view or
-global options block is used as a default.</para>
-
-<para>The <command>request-ixfr</command> 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 <command>request-ixfr</command> option in the view or
-global options block is used as a default.</para>
-
-<para>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 <command>yes</command> should always work.
-The purpose of the <command>provide-ixfr</command> and
-<command>request-ixfr</command> 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.</para>
-
-<para>The <command>edns</command> clause determines whether the local server
-will attempt to use EDNS when communicating with the remote server. The
-default is <command>yes</command>.</para>
-
-<para>The server supports two zone transfer methods. The first, <command>one-answer</command>,
-uses one DNS message per resource record transferred. <command>many-answers</command> packs
-as many resource records as possible into a message. <command>many-answers</command> is
-more efficient, but is only known to be understood by <acronym>BIND</acronym> 9, <acronym>BIND</acronym>
-8.x, and patched versions of <acronym>BIND</acronym> 4.9.5. You can specify which method
-to use for a server with the <command>transfer-format</command> option.
-If <command>transfer-format</command> is not specified, the <command>transfer-format</command> specified
-by the <command>options</command> statement will be used.</para>
-
-<para><command>transfers</command> is used to limit the number of
-concurrent inbound zone transfers from the specified server. If
-no <command>transfers</command> clause is specified, the limit is
-set according to the <command>transfers-per-ns</command> option.</para>
-
-<para>The <command>keys</command> clause identifies a
-<command>key_id</command> defined by the <command>key</command> statement,
-to be used for transaction security (TSIG, <xref linkend="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.</para>
-
-<para>Although the grammar of the <command>keys</command> clause
-allows for multiple keys, only a single key per server is currently
-supported.</para>
-
-<para>The <command>transfer-source</command> and
-<command>transfer-source-v6</command> 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 <command>transfer-source</command> can
-be specified.
-Similarly, for an IPv6 remote server, only
-<command>transfer-source-v6</command> can be specified.
-Form more details, see the description of
-<command>transfer-source</command> and
-<command>transfer-source-v6</command> in
-<xref linkend="zone_transfers"/>.</para>
-
-</sect2>
-
-<sect2><title><command>trusted-keys</command> Statement Grammar</title>
-<programlisting>trusted-keys {
- <replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ;
- <optional> <replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; <optional>...</optional></optional>
-};
-</programlisting>
-</sect2>
-<sect2><title><command>trusted-keys</command> Statement Definition
-and Usage</title>
-<para>The <command>trusted-keys</command> statement defines DNSSEC
-security roots. DNSSEC is described in <xref linkend="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.</para>
-<para>The <command>trusted-keys</command> 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.</para></sect2>
-
-<sect2 id="view_statement_grammar">
-<title><command>view</command> Statement Grammar</title>
-<programlisting>view <replaceable>view_name</replaceable>
- <optional><replaceable>class</replaceable></optional> {
- match-clients { <replaceable>address_match_list</replaceable> } ;
- match-destinations { <replaceable>address_match_list</replaceable> } ;
- match-recursive-only <replaceable>yes_or_no</replaceable> ;
- <optional> <replaceable>view_option</replaceable>; ...</optional>
- <optional> <replaceable>zone_statement</replaceable>; ...</optional>
-};
-</programlisting></sect2>
-<sect2><title><command>view</command> Statement Definition and Usage</title>
-
-<para>The <command>view</command> statement is a powerful new feature
-of <acronym>BIND</acronym> 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.</para>
-
-<para>Each <command>view</command> 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
-<varname>address_match_list</varname> of the view's
-<command>match-clients</command> clause and its destination IP address matches
-the <varname>address_match_list</varname> of the view's
-<command>match-destinations</command> clause. If not specified, both
-<command>match-clients</command> and <command>match-destinations</command>
-default to matching all addresses. In addition to checking IP addresses
-<command>match-clients</command> and <command>match-destinations</command>
-can also take <command>keys</command> which provide an mechanism for the
-client to select the view. A view can also be specified
-as <command>match-recursive-only</command>, which means that only recursive
-requests from matching clients will match that view.
-The order of the <command>view</command> statements is significant &mdash;
-a client request will be resolved in the context of the first
-<command>view</command> that it matches.</para>
-
-<para>Zones defined within a <command>view</command> statement will
-be only be accessible to clients that match the <command>view</command>.
- 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.</para>
-
-<para>Many of the options given in the <command>options</command> statement
-can also be used within a <command>view</command> statement, and then
-apply only when resolving queries with that view. When no view-specific
-value is given, the value in the <command>options</command> statement
-is used as a default. Also, zone options can have default values specified
-in the <command>view</command> statement; these view-specific defaults
-take precedence over those in the <command>options</command> statement.</para>
-
-<para>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.</para>
-
-<para>If there are no <command>view</command> statements in the config
-file, a default view that matches any client is automatically created
-in class IN. Any <command>zone</command> statements specified on
-the top level of the configuration file are considered to be part of
-this default view, and the <command>options</command> statement will
-apply to the default view. If any explicit <command>view</command>
-statements are present, all <command>zone</command> statements must
-occur inside <command>view</command> statements.</para>
-
-<para>Here is an example of a typical split DNS setup implemented
-using <command>view</command> statements.</para>
-<programlisting>view "internal" {
- // This should match our internal networks.
- match-clients { 10.0.0.0/8; };
-
- // Provide recursive service to internal clients only.
- recursion yes;
-
- // Provide a complete view of the example.com zone
- // including addresses of internal hosts.
- zone "example.com" {
- type master;
- file "example-internal.db";
- };
-};
-
-view "external" {
- // Match all clients not matched by the previous view.
- match-clients { any; };
-
- // Refuse recursive service to external clients.
- recursion no;
-
- // Provide a restricted view of the example.com zone
- // containing only publicly accessible hosts.
- zone "example.com" {
- type master;
- file "example-external.db";
- };
-};
-</programlisting>
-</sect2>
-<sect2 id="zone_statement_grammar"><title><command>zone</command>
-Statement Grammar</title>
- <programlisting>zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> <optional>{
- type ( master | slave | hint | stub | forward | delegation-only ) ;
- <optional> allow-notify { <replaceable>address_match_list</replaceable> } ; </optional>
- <optional> allow-query { <replaceable>address_match_list</replaceable> } ; </optional>
- <optional> allow-transfer { <replaceable>address_match_list</replaceable> } ; </optional>
- <optional> allow-update { <replaceable>address_match_list</replaceable> } ; </optional>
- <optional> update-policy { <replaceable>update_policy_rule</replaceable> <optional>...</optional> } ; </optional>
- <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> } ; </optional>
- <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
- <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
- <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
- <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> file <replaceable>string</replaceable> ; </optional>
- <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
- <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
- <optional> ixfr-base <replaceable>string</replaceable> ; </optional>
- <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
- <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> masters <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> } ; </optional>
- <optional> max-ixfr-log-size <replaceable>number</replaceable> ; </optional>
- <optional> max-transfer-idle-in <replaceable>number</replaceable> ; </optional>
- <optional> max-transfer-idle-out <replaceable>number</replaceable> ; </optional>
- <optional> max-transfer-time-in <replaceable>number</replaceable> ; </optional>
- <optional> max-transfer-time-out <replaceable>number</replaceable> ; </optional>
- <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> ; </optional>
- <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
- <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional>
- <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
- <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
- <optional> database <replaceable>string</replaceable> ; </optional>
- <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
- <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
- <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
- <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
- <optional> multi-master <replaceable>yes_or_no</replaceable> ; </optional>
- <optional> key-directory <replaceable>path_name</replaceable>; </optional>
-
-}</optional>;
-</programlisting>
-</sect2>
-<sect2><title><command>zone</command> Statement Definition and Usage</title>
-<sect3><title>Zone Types</title>
-<informaltable colsep = "0" rowsep = "0">
-<tgroup cols = "2" colsep = "0" rowsep = "0"
- tgroupstyle = "3Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.908in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.217in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>master</varname></para></entry>
-<entry colname = "2"><para>The server has a master copy of the data
-for the zone and will be able to provide authoritative answers for
-it.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>slave</varname></para></entry>
-<entry colname = "2"><para>A slave zone is a replica of a master
-zone. The <command>masters</command> 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
-be changed for all servers by specifying a port number before the
-list of IP addresses, or on a per-server basis after the IP address.
-Authentication to the master can also be done with per-server TSIG keys.
-If a file is specified, then the
-replica will be written to this file whenever the zone is changed,
-and reloaded from this file on a server restart. Use of a file is
-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 <literal>example.com</literal> might place
-the zone contents into a file called
-<filename>ex/example.com</filename> where <filename>ex/</filename> 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.)</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>stub</varname></para></entry>
-<entry colname = "2"><para>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 <acronym>BIND</acronym> implementation.
-</para>
-
-<para>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 <filename>named.conf</filename>.
-This usage is not recommended for new configurations, and BIND 9
-supports it only in a limited way.
-In <acronym>BIND</acronym> 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. <acronym>BIND</acronym>
-9 never mixes together zone data from different zones in this
-way. Therefore, if a <acronym>BIND</acronym> 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.</para>
-
-<para>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
-<literal>10.in-addr.arpa</literal>
-to use a set of internal name servers as the authoritative
-servers for that domain.</para>
-</entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>forward</varname></para></entry>
-<entry colname = "2"><para>A "forward zone" is a way to configure
-forwarding on a per-domain basis. A <command>zone</command> statement
-of type <command>forward</command> can contain a <command>forward</command> and/or <command>forwarders</command> statement,
-which will apply to queries within the domain given by the zone
-name. If no <command>forwarders</command> statement is present or
-an empty list for <command>forwarders</command> is given, then no
-forwarding will be done for the domain, canceling the effects of
-any forwarders in the <command>options</command> statement. Thus
-if you want to use this type of zone to change the behavior of the
-global <command>forward</command> 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.</para>
-</entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>hint</varname></para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>delegation-only</varname></para></entry>
-<entry colname = "2"><para>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.</para>
-<para><varname>delegation-only</varname> has no effect on answers received
-from forwarders.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable></sect3>
-
-<sect3><title>Class</title>
-<para>The zone's name may optionally be followed by a class. If
-a class is not specified, class <literal>IN</literal> (for <varname>Internet</varname>),
-is assumed. This is correct for the vast majority of cases.</para>
-<para>The <literal>hesiod</literal> 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
-<literal>HS</literal> is
-a synonym for hesiod.</para>
-<para>Another MIT development is CHAOSnet, a LAN protocol created
-in the mid-1970s. Zone data for it can be specified with the <literal>CHAOS</literal> class.</para></sect3>
-<sect3>
-
-<title>Zone Options</title>
-
-<variablelist>
-
-<varlistentry><term><command>allow-notify</command></term>
-<listitem><para>See the description of
-<command>allow-notify</command> in <xref linkend="access_control"/></para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>allow-query</command></term>
-<listitem><para>See the description of
-<command>allow-query</command> in <xref linkend="access_control"/></para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>allow-transfer</command></term>
-<listitem><para>See the description of <command>allow-transfer</command>
-in <xref linkend="access_control"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>allow-update</command></term>
-<listitem><para>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
-<xref linkend="dynamic_update_security"/> for details.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>update-policy</command></term>
-<listitem><para>Specifies a "Simple Secure Update" policy. See
-<xref linkend="dynamic_update_policies"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>allow-update-forwarding</command></term>
-<listitem><para>See the description of <command>allow-update-forwarding</command>
-in <xref linkend="access_control"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>also-notify</command></term>
-<listitem><para>Only meaningful if <command>notify</command> is
-active for this zone. The set of machines that will receive a
-<literal>DNS NOTIFY</literal> 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 <command>also-notify</command>. A port may be specified
-with each <command>also-notify</command> address to send the notify
-messages to a port other than the default of 53.
-<command>also-notify</command> is not meaningful for stub zones.
-The default is the empty list.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>check-names</command></term>
-<listitem><para>
-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 <command>master</command> zones the default is <command>fail</command>. For <command>slave</command>
-zones the default is <command>warn</command>.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>database</command></term>
-<listitem><para>Specify the type of database to be used for storing the
-zone data. The string following the <command>database</command> 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.</para>
-<para>The default is <userinput>"rbt"</userinput>, BIND 9's native in-memory
-red-black-tree database. This database does not take arguments.</para>
-<para>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.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>dialup</command></term>
-<listitem><para>See the description of
-<command>dialup</command> in <xref linkend="boolean_options"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>delegation-only</command></term>
-<listitem><para>The flag only applies to hint and stub zones. If set
-to <userinput>yes</userinput> then the zone will also be treated as if it
-is also a delegation-only type zone.
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>forward</command></term>
-<listitem><para>Only meaningful if the zone has a forwarders
-list. The <command>only</command> value causes the lookup to fail
-after trying the forwarders and getting no answer, while <command>first</command> would
-allow a normal lookup to be tried.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>forwarders</command></term>
-<listitem><para>Used to override the list of global forwarders.
-If it is not specified in a zone of type <command>forward</command>,
-no forwarding is done for the zone; the global options are not used.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>ixfr-base</command></term>
-<listitem><para>Was used in <acronym>BIND</acronym> 8 to specify the name
-of the transaction log (journal) file for dynamic update and IXFR.
-<acronym>BIND</acronym> 9 ignores the option and constructs the name of the journal
-file by appending "<filename>.jnl</filename>" to the name of the
-zone file.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>ixfr-tmp-file</command></term>
-<listitem><para>Was an undocumented option in <acronym>BIND</acronym> 8.
-Ignored in <acronym>BIND</acronym> 9.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-transfer-time-in</command></term>
-<listitem><para>See the description of
-<command>max-transfer-time-in</command> in <xref linkend="zone_transfers"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-transfer-idle-in</command></term>
-<listitem><para>See the description of
-<command>max-transfer-idle-in</command> in <xref linkend="zone_transfers"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-transfer-time-out</command></term>
-<listitem><para>See the description of
-<command>max-transfer-time-out</command> in <xref linkend="zone_transfers"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>max-transfer-idle-out</command></term>
-<listitem><para>See the description of
-<command>max-transfer-idle-out</command> in <xref linkend="zone_transfers"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>notify</command></term>
-<listitem><para>See the description of
-<command>notify</command> in <xref linkend="boolean_options"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>pubkey</command></term>
-<listitem><para>In <acronym>BIND</acronym> 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. <acronym>BIND</acronym> 9 does not verify signatures
-on load and ignores the option.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>zone-statistics</command></term>
-<listitem><para>If <userinput>yes</userinput>, the server will keep statistical
-information for this zone, which can be dumped to the
-<command>statistics-file</command> defined in the server options.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>sig-validity-interval</command></term>
-<listitem><para>See the description of
-<command>sig-validity-interval</command> in <xref linkend="tuning"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>transfer-source</command></term>
-<listitem><para>See the description of
-<command>transfer-source</command> in <xref linkend="zone_transfers"/>
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>transfer-source-v6</command></term>
-<listitem><para>See the description of
-<command>transfer-source-v6</command> in <xref linkend="zone_transfers"/>
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>alt-transfer-source</command></term>
-<listitem><para>See the description of
-<command>alt-transfer-source</command> in <xref linkend="zone_transfers"/>
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>alt-transfer-source-v6</command></term>
-<listitem><para>See the description of
-<command>alt-transfer-source-v6</command> in <xref linkend="zone_transfers"/>
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>use-alt-transfer-source</command></term>
-<listitem><para>See the description of
-<command>use-alt-transfer-source</command> in <xref linkend="zone_transfers"/>
-</para>
-</listitem></varlistentry>
-
-
-<varlistentry><term><command>notify-source</command></term>
-<listitem><para>See the description of
-<command>notify-source</command> in <xref linkend="zone_transfers"/>
-</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>notify-source-v6</command></term>
-<listitem><para>See the description of
-<command>notify-source-v6</command> in <xref linkend="zone_transfers"/>.
-</para>
-</listitem></varlistentry>
-
-<varlistentry>
-<term><command>min-refresh-time</command></term>
-<term><command>max-refresh-time</command></term>
-<term><command>min-retry-time</command></term>
-<term><command>max-retry-time</command></term>
-<listitem><para>
-See the description in <xref linkend="tuning"/>.
-</para></listitem></varlistentry>
-
-<varlistentry><term><command>ixfr-from-differences</command></term>
-<listitem><para>See the description of
-<command>ixfr-from-differences</command> in <xref linkend="boolean_options"/>.</para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>key-directory</command></term>
-<listitem><para>See the description of
-<command>key-directory</command> in <xref linkend="options"/></para>
-</listitem></varlistentry>
-
-<varlistentry><term><command>multi-master</command></term>
-<listitem><para>See the description of
-<command>multi-master</command> in <xref linkend="boolean_options"/>.</para>
-</listitem></varlistentry>
-
-</variablelist>
-
-</sect3>
-<sect3 id="dynamic_update_policies"><title>Dynamic Update Policies</title>
-<para><acronym>BIND</acronym> 9 supports two alternative methods of granting clients
-the right to perform dynamic updates to a zone,
-configured by the <command>allow-update</command> and
-<command>update-policy</command> option, respectively.</para>
-<para>The <command>allow-update</command> clause works the same
-way as in previous versions of <acronym>BIND</acronym>. It grants given clients the
-permission to update any record of any name in the zone.</para>
-<para>The <command>update-policy</command> clause is new in <acronym>BIND</acronym>
-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.</para>
-<para>Rules are specified in the <command>update-policy</command> zone
-option, and are only meaningful for master zones. When the <command>update-policy</command> statement
-is present, it is a configuration error for the <command>allow-update</command> statement
-to be present. The <command>update-policy</command> statement only
-examines the signer of a message; the source address is not relevant.</para>
-<para>This is how a rule definition looks:</para>
-<programlisting>
-( <command>grant</command> | <command>deny</command> ) <replaceable>identity</replaceable> <replaceable>nametype</replaceable> <replaceable>name</replaceable> <optional> <replaceable>types</replaceable> </optional>
-</programlisting>
-<para>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.</para>
-
-<para>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 <replaceable>identity</replaceable> field specifies a
-wildcard name, it is subject to DNS wildcard expansion, so the rule will apply
-to multiple identities. The <replaceable>identity</replaceable> field must
-contain a fully qualified domain name.</para>
-
-<para>The <replaceable>nametype</replaceable> field has 4 values:
-<varname>name</varname>, <varname>subdomain</varname>,
-<varname>wildcard</varname>, and <varname>self</varname>.
-</para>
-<informaltable>
- <tgroup cols = "2" colsep = "0"
- rowsep = "0" tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.819in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.681in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>name</varname></para></entry>
-<entry colname = "2"><para>Exact-match semantics. This rule matches when the
-name being updated is identical to the contents of the
-<replaceable>name</replaceable> field.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>subdomain</varname></para></entry>
-<entry colname = "2"><para>This rule matches when the name being updated
-is a subdomain of, or identical to, the contents of the
-<replaceable>name</replaceable> field.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>wildcard</varname></para></entry>
-<entry colname = "2"><para>The <replaceable>name</replaceable> field is
-subject to DNS wildcard expansion, and this rule matches when the name
-being updated name is a valid expansion of the wildcard.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><varname>self</varname></para></entry>
-<entry colname = "2"><para>This rule matches when the name being updated
-matches the contents of the <replaceable>identity</replaceable> field.
-The <replaceable>name</replaceable> field is ignored, but should be
-the same as the <replaceable>identity</replaceable> field. The
-<varname>self</varname> 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 <replaceable>identity</replaceable> would be
-specified as <constant>*</constant> in this case.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-
-<para>In all cases, the <replaceable>name</replaceable> field must
-specify a fully qualified domain name.</para>
-
-<para>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.
-</para>
- </sect3>
- </sect2>
- </sect1>
- <sect1>
- <title>Zone File</title>
- <sect2 id="types_of_resource_records_and_when_to_use_them">
- <title>Types of Resource Records and When to Use Them</title>
-<para>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.</para>
- <sect3>
- <title>Resource Records</title>
-
- <para>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 <xref
- linkend="the_sortlist_statement"/> and <xref
- linkend="rrset_ordering"/>.</para>
-
-<para>The components of a Resource Record are:</para>
-<informaltable colsep = "0"
- rowsep = "0"><tgroup cols = "2" colsep = "0"
- rowsep = "0" tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.000in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.500in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para>owner name</para></entry>
-<entry colname = "2"><para>the domain name where the RR is found.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>type</para></entry>
-<entry colname = "2"><para>an encoded 16 bit value that specifies
-the type of the resource record.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>TTL</para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>class</para></entry>
-<entry colname = "2"><para>an encoded 16 bit value that identifies
-a protocol family or instance of a protocol.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>RDATA</para></entry>
-<entry colname = "2"><para>the resource data. The format of the
-data is type (and sometimes class) specific.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-<para>The following are <emphasis>types</emphasis> of valid RRs:</para>
-<informaltable colsep = "0"
- rowsep = "0"><tgroup cols = "2" colsep = "0"
- rowsep = "0" tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.625in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para>A</para></entry>
-<entry colname = "2"><para>a host address. In the IN class, this is a
-32-bit IP address. Described in RFC 1035.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>AAAA</para></entry>
-<entry colname = "2"><para>IPv6 address. Described in RFC 1886.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>A6</para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>AFSDB</para></entry>
-<entry colname = "2"><para>location of AFS database servers.
-Experimental. Described in RFC 1183.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>APL</para></entry>
-<entry colname = "2"><para>address prefix list. Experimental.
-Described in RFC 3123.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>CERT</para></entry>
-<entry colname = "2"><para>holds a digital certificate.
-Described in RFC 2538.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>CNAME</para></entry>
-<entry colname = "2"><para>identifies the canonical name of an alias.
-Described in RFC 1035.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>DNAME</para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>GPOS</para></entry>
-<entry colname = "2"><para>Specifies the global position. Superseded by LOC.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>HINFO</para></entry>
-<entry colname = "2"><para>identifies the CPU and OS used by a host.
-Described in RFC 1035.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>ISDN</para></entry>
-<entry colname = "2"><para>representation of ISDN addresses.
-Experimental. Described in RFC 1183.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>KEY</para></entry>
-<entry colname = "2"><para>stores a public key associated with a
-DNS name. Described in RFC 2535.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>KX</para></entry>
-<entry colname = "2"><para>identifies a key exchanger for this
-DNS name. Described in RFC 2230.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>LOC</para></entry>
-<entry colname = "2"><para>for storing GPS info. Described in RFC 1876.
-Experimental.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>MX</para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>NAPTR</para></entry>
-<entry colname = "2"><para>name authority pointer. Described in RFC 2915.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>NSAP</para></entry>
-<entry colname = "2"><para>a network service access point.
-Described in RFC 1706.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>NS</para></entry>
-<entry colname = "2"><para>the authoritative name server for the
-domain. Described in RFC 1035.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>NXT</para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>PTR</para></entry>
-<entry colname = "2"><para>a pointer to another part of the domain
-name space. Described in RFC 1035.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>PX</para></entry>
-<entry colname = "2"><para>provides mappings between RFC 822 and X.400
-addresses. Described in RFC 2163.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>RP</para></entry>
-<entry colname = "2"><para>information on persons responsible
-for the domain. Experimental. Described in RFC 1183.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>RT</para></entry>
-<entry colname = "2"><para>route-through binding for hosts that
-do not have their own direct wide area network addresses.
-Experimental. Described in RFC 1183.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>SIG</para></entry>
-<entry colname = "2"><para>("signature") contains data authenticated
-in the secure DNS. Described in RFC 2535.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>SOA</para></entry>
-<entry colname = "2"><para>identifies the start of a zone of authority.
-Described in RFC 1035.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>SRV</para></entry>
-<entry colname = "2"><para>information about well known network
-services (replaces WKS). Described in RFC 2782.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>TXT</para></entry>
-<entry colname = "2"><para>text records. Described in RFC 1035.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>WKS</para></entry>
-<entry colname = "2"><para>information about which well known
-network services, such as SMTP, that a domain supports. Historical.
-</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>X25</para></entry>
-<entry colname = "2"><para>representation of X.25 network addresses.
-Experimental. Described in RFC 1183.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-<para>The following <emphasis>classes</emphasis> of resource records
-are currently valid in the DNS:</para><informaltable colsep = "0"
- rowsep = "0"><tgroup cols = "2" colsep = "0" rowsep = "0"
- tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.625in"/>
-<tbody>
-
-<row rowsep = "0">
-<entry colname = "1"><para>IN</para></entry>
-<entry colname = "2"><para>The Internet.</para></entry>
-</row>
-
-<row rowsep = "0">
-<entry colname = "1"><para>CH</para></entry>
-<entry colname = "2"><para>
-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.,
-<literal>version.bind</literal>.
-</para></entry>
-</row>
-
-<row rowsep = "0">
-<entry colname = "1"><para>HS</para></entry>
-<entry colname = "2"><para>
-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.
-</para></entry>
-</row>
-
-</tbody>
-</tgroup></informaltable>
-
-<para>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.</para>
-<para>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
-zone where the data originates. While short TTLs can be used to
-minimize caching, and a zero TTL prohibits caching, the realities
-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.</para>
-<para>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.</para></sect3>
-<sect3><title>Textual expression of RRs</title>
-<para>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.</para>
-<para>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.</para>
-<para>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.</para>
-<para>The resource data or RDATA section of the RR are given using
-knowledge of the typical representation for the data.</para>
-<para>For example, we might show the RRs carried in a message as:</para> <informaltable
- colsep = "0" rowsep = "0"><tgroup cols = "3"
- colsep = "0" rowsep = "0" tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.381in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "1.020in"/>
-<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "2.099in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>ISI.EDU.</literal></para></entry>
-<entry colname = "2"><para><literal>MX</literal></para></entry>
-<entry colname = "3"><para><literal>10 VENERA.ISI.EDU.</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para><literal>MX</literal></para></entry>
-<entry colname = "3"><para><literal>10 VAXA.ISI.EDU</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>VENERA.ISI.EDU</literal></para></entry>
-<entry colname = "2"><para><literal>A</literal></para></entry>
-<entry colname = "3"><para><literal>128.9.0.32</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para><literal>A</literal></para></entry>
-<entry colname = "3"><para><literal>10.1.0.52</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>VAXA.ISI.EDU</literal></para></entry>
-<entry colname = "2"><para><literal>A</literal></para></entry>
-<entry colname = "3"><para><literal>10.2.0.27</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para><literal>A</literal></para></entry>
-<entry colname = "3"><para><literal>128.9.0.33</literal></para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-<para>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.</para>
-<para>This example shows six RRs, with two RRs at each of three
-domain names.</para>
-<para>Similarly we might see:</para><informaltable colsep = "0"
- rowsep = "0"><tgroup cols = "3" colsep = "0" rowsep = "0"
- tgroupstyle = "4Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.491in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "1.067in"/>
-<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "2.067in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>XX.LCS.MIT.EDU. IN</literal></para></entry>
-<entry colname = "2"><para><literal>A</literal></para></entry>
-<entry colname = "3"><para><literal>10.0.0.44</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>CH</literal></para></entry>
-<entry colname = "2"><para><literal>A</literal></para></entry>
-<entry colname = "3"><para><literal>MIT.EDU. 2420</literal></para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-<para>This example shows two addresses for <literal>XX.LCS.MIT.EDU</literal>,
-each of a different class.</para></sect3></sect2>
-
-<sect2><title>Discussion of MX Records</title>
-
-<para>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.</para>
-
-<para>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
-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 &mdash; 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 <emphasis>must</emphasis> have
-an associated A record &mdash; CNAME is not sufficient.</para>
-<para>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.</para>
-<informaltable colsep = "0" rowsep = "0"><tgroup cols = "5"
- colsep = "0" rowsep = "0" tgroupstyle = "3Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.708in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.444in"/>
-<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "0.444in"/>
-<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "0.976in"/>
-<colspec colname = "5" colnum = "5" colsep = "0" colwidth = "1.553in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>example.com.</literal></para></entry>
-<entry colname = "2"><para><literal>IN</literal></para></entry>
-<entry colname = "3"><para><literal>MX</literal></para></entry>
-<entry colname = "4"><para><literal>10</literal></para></entry>
-<entry colname = "5"><para><literal>mail.example.com.</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para><literal>IN</literal></para></entry>
-<entry colname = "3"><para><literal>MX</literal></para></entry>
-<entry colname = "4"><para><literal>10</literal></para></entry>
-<entry colname = "5"><para><literal>mail2.example.com.</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para><literal>IN</literal></para></entry>
-<entry colname = "3"><para><literal>MX</literal></para></entry>
-<entry colname = "4"><para><literal>20</literal></para></entry>
-<entry colname = "5"><para><literal>mail.backup.org.</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>mail.example.com.</literal></para></entry>
-<entry colname = "2"><para><literal>IN</literal></para></entry>
-<entry colname = "3"><para><literal>A</literal></para></entry>
-<entry colname = "4"><para><literal>10.0.0.1</literal></para></entry>
-<entry colname = "5"><para></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>mail2.example.com.</literal></para></entry>
-<entry colname = "2"><para><literal>IN</literal></para></entry>
-<entry colname = "3"><para><literal>A</literal></para></entry>
-<entry colname = "4"><para><literal>10.0.0.2</literal></para></entry>
-<entry colname = "5"><para></para></entry>
-</row>
-</tbody>
-</tgroup></informaltable><para>For example:</para>
-<para>Mail delivery will be attempted to <literal>mail.example.com</literal> and
-<literal>mail2.example.com</literal> (in
-any order), and if neither of those succeed, delivery to <literal>mail.backup.org</literal> will
-be attempted.</para></sect2>
-<sect2 id="Setting_TTLs"><title>Setting TTLs</title>
-<para>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.</para>
-<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2"
- colsep = "0" rowsep = "0" tgroupstyle = "3Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.750in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.375in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para>SOA</para></entry>
-<entry colname = "2"><para>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.</para><para>The maximum time for
-negative caching is 3 hours (3h).</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>$TTL</para></entry>
-<entry colname = "2"><para>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.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>RR TTLs</para></entry>
-<entry colname = "2"><para>Each RR can have a TTL as the second
-field in the RR, which will control how long other servers can cache
-the it.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
-<para>All of these TTLs default to units of seconds, though units
-can be explicitly specified, for example, <literal>1h30m</literal>. </para></sect2>
-<sect2><title>Inverse Mapping in IPv4</title>
-<para>Reverse name resolution (that is, translation from IP address
-to name) is achieved by means of the <emphasis>in-addr.arpa</emphasis> 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,
-a machine with an IP address of 10.1.2.3 would have a corresponding
-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 <optional>example.com</optional> domain:</para>
-<informaltable colsep = "0" rowsep = "0">
-<tgroup cols = "2" colsep = "0" rowsep = "0"
- tgroupstyle = "3Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.125in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.000in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>$ORIGIN</literal></para></entry>
-<entry colname = "2"><para><literal>2.1.10.in-addr.arpa</literal></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><literal>3</literal></para></entry>
-<entry colname = "2"><para><literal>IN PTR foo.example.com.</literal></para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
- <note>
-<para>The <command>$ORIGIN</command> 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.</para></note></sect2>
-<sect2><title>Other Zone File Directives</title>
-<para>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.</para>
-<para>Master File Directives include <command>$ORIGIN</command>, <command>$INCLUDE</command>,
-and <command>$TTL.</command></para>
-<sect3><title>The <command>$ORIGIN</command> Directive</title>
-<para>Syntax: <command>$ORIGIN
-</command><replaceable>domain-name</replaceable> <optional> <replaceable>comment</replaceable></optional></para>
-<para><command>$ORIGIN</command> sets the domain name that will
-be appended to any unqualified records. When a zone is first read
-in there is an implicit <command>$ORIGIN</command> &#60;<varname>zone-name</varname>><command>.</command> The
-current <command>$ORIGIN</command> is appended to the domain specified
-in the <command>$ORIGIN</command> argument if it is not absolute.</para>
-<programlisting>$ORIGIN example.com.
-WWW CNAME MAIN-SERVER</programlisting>
-<para>is equivalent to</para>
-<programlisting>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</programlisting></sect3>
-<sect3><title>The <command>$INCLUDE</command> Directive</title>
-<para>Syntax: <command>$INCLUDE</command>
-<replaceable>filename</replaceable> <optional>
-<replaceable>origin</replaceable> </optional> <optional> <replaceable>comment</replaceable> </optional></para>
-<para>Read and process the file <filename>filename</filename> as
-if it were included into the file at this point. If <command>origin</command> is
-specified the file is processed with <command>$ORIGIN</command> set
-to that value, otherwise the current <command>$ORIGIN</command> is
-used.</para>
-<para>The origin and the current domain name
-revert to the values they had prior to the <command>$INCLUDE</command> once
-the file has been read.</para>
-<note><para>
-RFC 1035 specifies that the current origin should be restored after
-an <command>$INCLUDE</command>, 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.
-</para></note>
-</sect3>
-<sect3><title>The <command>$TTL</command> Directive</title>
-<para>Syntax: <command>$TTL</command>
-<replaceable>default-ttl</replaceable> <optional>
-<replaceable>comment</replaceable> </optional></para>
-<para>Set the default Time To Live (TTL) for subsequent records
-with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.</para>
-<para><command>$TTL</command> is defined in RFC 2308.</para></sect3></sect2>
-<sect2><title><acronym>BIND</acronym> Master File Extension: the <command>$GENERATE</command> Directive</title>
- <para>Syntax: <command>$GENERATE</command> <replaceable>range</replaceable> <replaceable>lhs</replaceable> <optional><replaceable>ttl</replaceable></optional> <optional><replaceable>class</replaceable></optional> <replaceable>type</replaceable> <replaceable>rhs</replaceable> <optional> <replaceable>comment</replaceable> </optional></para>
-<para><command>$GENERATE</command> is used to create a series of
-resource records that only differ from each other by an iterator. <command>$GENERATE</command> 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.</para>
-<programlisting>$ORIGIN 0.0.192.IN-ADDR.ARPA.
-$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
-$GENERATE 1-127 $ CNAME $.0</programlisting>
-<para>is equivalent to</para>
-<programlisting>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.
-</programlisting>
- <informaltable colsep = "0" rowsep = "0">
- <tgroup cols = "2" colsep = "0" rowsep = "0" tgroupstyle = "3Level-table">
- <colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/>
- <colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.250in"/>
- <tbody>
- <row rowsep = "0">
- <entry colname = "1"><para><command>range</command></para></entry>
- <entry colname = "2"><para>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.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>lhs</command></para></entry>
- <entry colname = "2"><para><command>lhs</command> describes the
-owner name of the resource records to be created. Any single <command>$</command> symbols
-within the <command>lhs</command> side are replaced by the iterator
-value.
-To get a $ in the output you need to escape the <command>$</command>
-using a backslash <command>\</command>,
-e.g. <command>\$</command>. The <command>$</command> may optionally be followed
-by modifiers which change the offset from the iterator, field width and base.
-Modifiers are introduced by a <command>{</command> immediately following the
-<command>$</command> as <command>${offset[,width[,base]]}</command>.
-e.g. <command>${-20,3,d}</command> 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 (<command>d</command>), octal (<command>o</command>)
-and hexadecimal (<command>x</command> or <command>X</command> for uppercase).
-The default modifier is <command>${0,0,d}</command>.
-If the <command>lhs</command> is not
-absolute, the current <command>$ORIGIN</command> is appended to
-the name.</para>
-<para>For compatibility with earlier versions <command>$$</command> is still
-recognized a indicating a literal $ in the output.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>ttl</command></para></entry>
- <entry colname = "2"><para><command>ttl</command> specifies the
- ttl of the generated records. If not specified this will be
- inherited using the normal ttl inheritance rules.</para>
- <para><command>class</command> and <command>ttl</command> can be
- entered in either order.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>class</command></para></entry>
- <entry colname = "2"><para><command>class</command> specifies the
- class of the generated records. This must match the zone class if
- it is specified.</para>
- <para><command>class</command> and <command>ttl</command> can be
- entered in either order.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>type</command></para></entry>
- <entry colname = "2"><para>At present the only supported types are
-PTR, CNAME, DNAME, A, AAAA and NS.</para></entry>
- </row>
- <row rowsep = "0">
- <entry colname = "1"><para><command>rhs</command></para></entry>
- <entry colname = "2"><para>rhs is a domain name. It is processed
-similarly to lhs.</para></entry>
- </row>
- </tbody>
- </tgroup></informaltable>
- <para>The <command>$GENERATE</command> directive is a <acronym>BIND</acronym> extension
-and not part of the standard zone file format.</para>
- <para>BIND 8 does not support the optional TTL and CLASS fields.</para>
- </sect2>
- </sect1>
-</chapter>
-<chapter id="Bv9ARM.ch07"><title><acronym>BIND</acronym> 9 Security Considerations</title>
-<sect1 id="Access_Control_Lists"><title>Access Control Lists</title>
-<para>Access Control Lists (ACLs), are address match lists that
-you can set up and nickname for future use in <command>allow-notify</command>,
-<command>allow-query</command>, <command>allow-recursion</command>,
-<command>blackhole</command>, <command>allow-transfer</command>,
-etc.</para>
-<para>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.</para>
-<para>It is a <emphasis>good idea</emphasis> 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.</para>
-<para>Here is an example of how to properly apply ACLs:</para>
-<programlisting>
-// 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.
-acl our-nets { x.x.x.x/24; x.x.x.x/21; };
-options {
- ...
- ...
- allow-query { our-nets; };
- allow-recursion { our-nets; };
- ...
- blackhole { bogusnets; };
- ...
-};
-zone "example.com" {
- type master;
- file "m/example.com";
- allow-query { any; };
-};
-</programlisting>
-<para>This allows recursive queries of the server from the outside
-unless recursion has been previously disabled.</para>
-<para>For more information on how to use ACLs to protect your server,
-see the <emphasis>AUSCERT</emphasis> advisory at
-<ulink url="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos">ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</ulink></para></sect1>
-<sect1><title><command>chroot</command> and <command>setuid</command> (for
-UNIX servers)</title>
-<para>On UNIX servers, it is possible to run <acronym>BIND</acronym> in a <emphasis>chrooted</emphasis> environment
-(<command>chroot()</command>) by specifying the "<option>-t</option>"
-option. This can help improve system security by placing <acronym>BIND</acronym> in
-a "sandbox", which will limit the damage done if a server is compromised.</para>
-<para>Another useful feature in the UNIX version of <acronym>BIND</acronym> is the
-ability to run the daemon as an unprivileged user ( <option>-u</option> <replaceable>user</replaceable> ).
-We suggest running as an unprivileged user when using the <command>chroot</command> feature.</para>
-<para>Here is an example command line to load <acronym>BIND</acronym> in a <command>chroot()</command> sandbox,
-<command>/var/named</command>, and to run <command>named</command> <command>setuid</command> to
-user 202:</para>
-<para><userinput>/usr/local/bin/named -u 202 -t /var/named</userinput></para>
-
-<sect2><title>The <command>chroot</command> Environment</title>
-
-<para>In order for a <command>chroot()</command> environment to
-work properly in a particular directory
-(for example, <filename>/var/named</filename>),
-you will need to set up an environment that includes everything
-<acronym>BIND</acronym> needs to run.
-From <acronym>BIND</acronym>'s point of view, <filename>/var/named</filename> is
-the root of the filesystem. You will need to adjust the values of options like
-like <command>directory</command> and <command>pid-file</command> to account
-for this.
-</para>
-<para>
-Unlike with earlier versions of BIND, you will typically
-<emphasis>not</emphasis> need to compile <command>named</command>
-statically nor install shared libraries under the new root.
-However, depending on your operating system, you may need
-to set up things like
-<filename>/dev/zero</filename>,
-<filename>/dev/random</filename>,
-<filename>/dev/log</filename>, and/or
-<filename>/etc/localtime</filename>.
-</para>
-</sect2>
-
-<sect2><title>Using the <command>setuid</command> Function</title>
-
-<para>Prior to running the <command>named</command> daemon, use
-the <command>touch</command> utility (to change file access and
-modification times) or the <command>chown</command> utility (to
-set the user id and/or group id) on files
-to which you want <acronym>BIND</acronym>
-to write. Note that if the <command>named</command> daemon is running as an
-unprivileged user, it will not be able to bind to new restricted ports if the
-server is reloaded.</para>
-</sect2>
-</sect1>
-
-<sect1 id="dynamic_update_security"><title>Dynamic Update Security</title>
-
-<para>Access to the dynamic
-update facility should be strictly limited. In earlier versions of
-<acronym>BIND</acronym> 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 <command>allow-update</command> 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
-<command>allow-update</command> 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.</para>
-
-<para>For these reasons, we strongly recommend that updates be
-cryptographically authenticated by means of transaction signatures
-(TSIG). That is, the <command>allow-update</command> option should
-list only TSIG key names, not IP addresses or network
-prefixes. Alternatively, the new <command>update-policy</command>
-option can be used.</para>
-
-<para>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.</para>
-
-</sect1></chapter>
-
-<chapter id="Bv9ARM.ch08">
- <title>Troubleshooting</title>
- <sect1>
- <title>Common Problems</title>
- <sect2>
- <title>It's not working; how can I figure out what's wrong?</title>
-
- <para>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.</para>
-
- </sect2>
- </sect1>
- <sect1>
- <title>Incrementing and Changing the Serial Number</title>
-
- <para>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
- to the year 2000 to see if it will work. They then try to restore
- the old serial number. This will cause problems because serial
- 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.</para>
-
- <para>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.</para>
-
- <para>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.</para>
-
- </sect1>
- <sect1>
- <title>Where Can I Get Help?</title>
-
- <para>The Internet Software Consortium (<acronym>ISC</acronym>) offers a wide range
- of support and service agreements for <acronym>BIND</acronym> and <acronym>DHCP</acronym> servers. Four
- levels of premium support are available and each level includes
- support for all <acronym>ISC</acronym> programs, significant discounts on products
- and training, and a recognized priority on bug fixes and
- non-funded feature requests. In addition, <acronym>ISC</acronym> offers a standard
- support agreement package which includes services ranging from bug
- fix announcements to remote support. It also includes training in
- <acronym>BIND</acronym> and <acronym>DHCP</acronym>.</para>
-
- <para>To discuss arrangements for support, contact
- <ulink url="mailto:info@isc.org">info@isc.org</ulink> or visit the
- <acronym>ISC</acronym> web page at <ulink
- url="http://www.isc.org/services/support/">http://www.isc.org/services/support/</ulink>
- to read more.</para>
- </sect1>
-</chapter>
-<appendix id="Bv9ARM.ch09">
- <title>Appendices</title>
- <sect1>
- <title>Acknowledgments</title>
- <sect2>
- <title>A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym></title>
-
- <para>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
- Internet) became a testbed of experimentation for developing the
- new naming/addressing scheme in an rapidly expanding,
- operational network environment. New RFCs were written and
- published in 1987 that modified the original documents to
- 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 <acronym>DNS</acronym> implementations are
- built.
-</para>
-
- <para>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 <acronym>DNS</acronym> server for Unix machines, the Berkeley Internet
-Name Domain (<acronym>BIND</acronym>) 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 <acronym>BIND</acronym> 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 <acronym>BIND</acronym>
-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 <acronym>BIND</acronym> for 2 years, from 1985
-to 1987. Many other people also contributed to <acronym>BIND</acronym> development
-during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell,
-Mike Muuss, Jim Bloom and Mike Schwartz. <acronym>BIND</acronym> maintenance was subsequently
-handled by Mike Karels and O. Kure.</para>
- <para><acronym>BIND</acronym> versions 4.9 and 4.9.1 were released by Digital Equipment
-Corporation (now Compaq Computer Corporation). Paul Vixie, then
-a DEC employee, became <acronym>BIND</acronym>'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.</para>
- <para><acronym>BIND</acronym> Version 4.9.2 was sponsored by Vixie Enterprises. Paul
-Vixie became <acronym>BIND</acronym>'s principal architect/programmer.</para>
- <para><acronym>BIND</acronym> 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 <acronym>BIND</acronym> version
-8 in May 1997.</para>
- <para><acronym>BIND</acronym> development work is made possible today by the sponsorship
-of several corporations, and by the tireless work efforts of numerous
-individuals.</para>
- </sect2>
- </sect1>
-<sect1 id="historical_dns_information">
-
-<title>General <acronym>DNS</acronym> Reference Information</title>
- <sect2 id="ipv6addresses">
- <title>IPv6 addresses (AAAA)</title>
- <para>IPv6 addresses are 128-bit identifiers for interfaces and
-sets of interfaces which were introduced in the <acronym>DNS</acronym> to facilitate
-scalable Internet routing. There are three types of addresses: <emphasis>Unicast</emphasis>,
-an identifier for a single interface; <emphasis>Anycast</emphasis>,
-an identifier for a set of interfaces; and <emphasis>Multicast</emphasis>,
-an identifier for a set of interfaces. Here we describe the global
-Unicast address scheme. For more information, see RFC 2374.</para>
-<para>The aggregatable global Unicast address format is as follows:</para>
-<informaltable colsep = "0" rowsep = "0"><tgroup cols = "6"
- colsep = "0" rowsep = "0" tgroupstyle = "1Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.477in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.501in"/>
-<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "0.523in"/>
-<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "0.731in"/>
-<colspec colname = "5" colnum = "5" colsep = "0" colwidth = "1.339in"/>
-<colspec colname = "6" colnum = "6" colsep = "0" colwidth = "2.529in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1" colsep = "1" rowsep = "1"><para>3</para></entry>
-<entry colname = "2" colsep = "1" rowsep = "1"><para>13</para></entry>
-<entry colname = "3" colsep = "1" rowsep = "1"><para>8</para></entry>
-<entry colname = "4" colsep = "1" rowsep = "1"><para>24</para></entry>
-<entry colname = "5" colsep = "1" rowsep = "1"><para>16</para></entry>
-<entry colname = "6" rowsep = "1"><para>64 bits</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1" colsep = "1"><para>FP</para></entry>
-<entry colname = "2" colsep = "1"><para>TLA ID</para></entry>
-<entry colname = "3" colsep = "1"><para>RES</para></entry>
-<entry colname = "4" colsep = "1"><para>NLA ID</para></entry>
-<entry colname = "5" colsep = "1"><para>SLA ID</para></entry>
-<entry colname = "6"><para>Interface ID</para></entry>
-</row>
-<row rowsep = "0">
-<entry nameend = "4" namest = "1"><para>&#60;------ Public Topology
-------></para></entry>
-<entry colname = "5"><para></para></entry>
-<entry colname = "6"><para></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para></para></entry>
-<entry colname = "3"><para></para></entry>
-<entry colname = "4"><para></para></entry>
-<entry colname = "5"><para>&#60;-Site Topology-></para></entry>
-<entry colname = "6"><para></para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para></para></entry>
-<entry colname = "2"><para></para></entry>
-<entry colname = "3"><para></para></entry>
-<entry colname = "4"><para></para></entry>
-<entry colname = "5"><para></para></entry>
-<entry colname = "6"><para>&#60;------ Interface Identifier ------></para></entry>
-</row>
-</tbody>
-</tgroup></informaltable>
- <para>Where
-<informaltable colsep = "0" rowsep = "0"><tgroup
- cols = "3" colsep = "0" rowsep = "0" tgroupstyle = "2Level-table">
-<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.375in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.250in"/>
-<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "3.500in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para>FP</para></entry>
-<entry colname = "2"><para>=</para></entry>
-<entry colname = "3"><para>Format Prefix (001)</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>TLA ID</para></entry>
-<entry colname = "2"><para>=</para></entry>
-<entry colname = "3"><para>Top-Level Aggregation Identifier</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>RES</para></entry>
-<entry colname = "2"><para>=</para></entry>
-<entry colname = "3"><para>Reserved for future use</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>NLA ID</para></entry>
-<entry colname = "2"><para>=</para></entry>
-<entry colname = "3"><para>Next-Level Aggregation Identifier</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>SLA ID</para></entry>
-<entry colname = "2"><para>=</para></entry>
-<entry colname = "3"><para>Site-Level Aggregation Identifier</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para>INTERFACE ID</para></entry>
-<entry colname = "2"><para>=</para></entry>
-<entry colname = "3"><para>Interface Identifier</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable></para>
- <para>The <emphasis>Public Topology</emphasis> is provided by the
-upstream provider or ISP, and (roughly) corresponds to the IPv4 <emphasis>network</emphasis> section
-of the address range. The <emphasis>Site Topology</emphasis> is
-where you can subnet this space, much the same as subnetting an
-IPv4 /16 network into /24 subnets. The <emphasis>Interface Identifier</emphasis> is
-the address of an individual interface on a given network. (With
-IPv6, addresses belong to interfaces rather than machines.)</para>
- <para>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).</para>
-<para>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:</para>
-<para><command>2001:db8:201:9:a00:20ff:fe81:2b32</command></para>
-<para>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.</para>
- </sect2>
- </sect1>
- <sect1 id="bibliography">
- <title>Bibliography (and Suggested Reading)</title>
- <sect2 id="rfcs">
- <title>Request for Comments (RFCs)</title>
- <para>Specification documents for the Internet protocol suite, including
-the <acronym>DNS</acronym>, 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
-<ulink url="ftp://www.isi.edu/in-notes/">ftp://www.isi.edu/in-notes/RFC<replaceable>xxx</replaceable>.txt</ulink> (where <replaceable>xxx</replaceable> is
-the number of the RFC). RFCs are also available via the Web at
-<ulink url="http://www.ietf.org/rfc/">http://www.ietf.org/rfc/</ulink>.
-</para>
- <bibliography>
- <bibliodiv>
- <!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
- <title>Standards</title>
- <biblioentry>
- <abbrev>RFC974</abbrev>
- <author>
- <surname>Partridge</surname>
- <firstname>C.</firstname>
- </author>
- <title>Mail Routing and the Domain System</title>
- <pubdate>January 1986</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1034</abbrev>
- <author>
- <surname>Mockapetris</surname>
- <firstname>P.V.</firstname>
- </author>
- <title>Domain Names &mdash; Concepts and Facilities</title>
- <pubdate>November 1987</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1035</abbrev>
- <author>
- <surname>Mockapetris</surname>
- <firstname>P. V.</firstname>
- </author> <title>Domain Names &mdash; Implementation and
-Specification</title>
- <pubdate>November 1987</pubdate>
- </biblioentry>
- </bibliodiv>
- <bibliodiv id="proposed_standards" xreflabel="Proposed Standards">
-
- <title>Proposed Standards</title>
- <!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
- <biblioentry>
- <abbrev>RFC2181</abbrev>
- <author>
- <surname>Elz</surname>
- <firstname>R., R. Bush</firstname>
- </author>
- <title>Clarifications to the <acronym>DNS</acronym> Specification</title>
- <pubdate>July 1997</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2308</abbrev>
- <author>
- <surname>Andrews</surname>
- <firstname>M.</firstname>
- </author>
- <title>Negative Caching of <acronym>DNS</acronym> Queries</title>
- <pubdate>March 1998</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1995</abbrev>
- <author>
- <surname>Ohta</surname>
- <firstname>M.</firstname>
- </author>
- <title>Incremental Zone Transfer in <acronym>DNS</acronym></title>
- <pubdate>August 1996</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1996</abbrev>
- <author>
- <surname>Vixie</surname>
- <firstname>P.</firstname>
- </author>
- <title>A Mechanism for Prompt Notification of Zone Changes</title>
- <pubdate>August 1996</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2136</abbrev>
- <authorgroup>
- <author>
- <surname>Vixie</surname>
- <firstname>P.</firstname>
- </author>
- <author>
- <firstname>S.</firstname>
- <surname>Thomson</surname>
- </author>
- <author>
- <firstname>Y.</firstname>
- <surname>Rekhter</surname>
- </author>
- <author>
- <firstname>J.</firstname>
- <surname>Bound</surname>
- </author>
- </authorgroup>
- <title>Dynamic Updates in the Domain Name System</title>
- <pubdate>April 1997</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2845</abbrev>
- <authorgroup>
- <author>
- <surname>Vixie</surname>
- <firstname>P.</firstname>
- </author>
- <author>
- <firstname>O.</firstname>
- <surname>Gudmundsson</surname>
- </author>
- <author>
- <firstname>D.</firstname>
- <surname>Eastlake</surname>
- <lineage>3rd</lineage></author>
- <author>
- <firstname>B.</firstname>
- <surname>Wellington</surname>
- </author></authorgroup>
- <title>Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG)</title>
- <pubdate>May 2000</pubdate>
- </biblioentry>
- </bibliodiv>
- <bibliodiv>
- <title>Proposed Standards Still Under Development</title>
- <note>
- <para><emphasis>Note:</emphasis> the following list of
-RFCs are undergoing major revision by the IETF.</para>
- </note>
- <biblioentry>
- <abbrev>RFC1886</abbrev>
- <authorgroup>
- <author>
- <surname>Thomson</surname>
- <firstname>S.</firstname>
- </author>
- <author>
- <firstname>C.</firstname>
- <surname>Huitema</surname>
- </author>
- </authorgroup>
- <title><acronym>DNS</acronym> Extensions to support IP version 6</title>
- <pubdate>December 1995</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2065</abbrev>
- <authorgroup>
- <author>
- <surname>Eastlake</surname>
- <lineage>3rd</lineage>
- <firstname>D.</firstname>
- </author>
- <author>
- <firstname>C.</firstname>
- <surname>Kaufman</surname>
- </author>
- </authorgroup>
- <title>Domain Name System Security Extensions</title>
- <pubdate>January 1997</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2137</abbrev>
- <author>
- <surname>Eastlake</surname>
- <lineage>3rd</lineage>
- <firstname>D.</firstname>
- </author>
- <title>Secure Domain Name System Dynamic Update</title>
- <pubdate>April 1997</pubdate>
- </biblioentry>
- </bibliodiv>
- <bibliodiv>
- <title>Other Important RFCs About <acronym>DNS</acronym> Implementation</title>
- <biblioentry>
- <abbrev>RFC1535</abbrev>
- <author>
- <surname>Gavron</surname>
- <firstname>E.</firstname>
- </author>
- <title>A Security Problem and Proposed Correction With Widely Deployed <acronym>DNS</acronym> Software.</title>
- <pubdate>October 1993</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1536</abbrev>
- <authorgroup>
- <author>
- <surname>Kumar</surname>
- <firstname>A.</firstname>
- </author>
- <author>
- <firstname>J.</firstname>
- <surname>Postel</surname>
- </author>
- <author>
- <firstname>C.</firstname>
- <surname>Neuman</surname></author>
- <author>
- <firstname>P.</firstname>
- <surname>Danzig</surname>
- </author>
- <author>
- <firstname>S.</firstname>
- <surname>Miller</surname>
- </author>
- </authorgroup>
- <title>Common <acronym>DNS</acronym> Implementation Errors and Suggested Fixes</title>
- <pubdate>October 1993</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1982</abbrev>
- <authorgroup>
- <author>
- <surname>Elz</surname>
- <firstname>R.</firstname>
- </author>
- <author>
- <firstname>R.</firstname>
- <surname>Bush</surname>
- </author>
- </authorgroup>
- <title>Serial Number Arithmetic</title>
- <pubdate>August 1996</pubdate>
- </biblioentry>
- </bibliodiv>
- <bibliodiv>
- <title>Resource Record Types</title>
- <biblioentry>
- <abbrev>RFC1183</abbrev>
- <authorgroup>
- <author>
- <surname>Everhart</surname>
- <firstname>C.F.</firstname>
- </author>
- <author>
- <firstname>L. A.</firstname>
- <surname>Mamakos</surname>
- </author>
- <author>
- <firstname>R.</firstname>
- <surname>Ullmann</surname>
- </author>
- <author>
- <firstname>P.</firstname>
- <surname>Mockapetris</surname>
- </author>
- </authorgroup>
- <title>New <acronym>DNS</acronym> RR Definitions</title>
- <pubdate>October 1990</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1706</abbrev>
- <authorgroup>
- <author>
- <surname>Manning</surname>
- <firstname>B.</firstname>
- </author>
- <author>
- <firstname>R.</firstname>
- <surname>Colella</surname>
- </author>
- </authorgroup>
- <title><acronym>DNS</acronym> NSAP Resource Records</title>
- <pubdate>October 1994</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2168</abbrev>
- <authorgroup>
- <author>
- <surname>Daniel</surname>
- <firstname>R.</firstname>
- </author>
- <author>
- <firstname>M.</firstname>
- <surname>Mealling</surname>
- </author>
- </authorgroup>
- <title>Resolution of Uniform Resource Identifiers using
-the Domain Name System</title>
- <pubdate>June 1997</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1876</abbrev>
- <authorgroup>
- <author>
- <surname>Davis</surname>
- <firstname>C.</firstname>
- </author>
- <author>
- <firstname>P.</firstname>
- <surname>Vixie</surname>
- </author>
- <author>
- <firstname>T.</firstname>
- <firstname>Goodwin</firstname>
- </author>
- <author>
- <firstname>I.</firstname>
- <surname>Dickinson</surname>
- </author>
- </authorgroup>
- <title>A Means for Expressing Location Information in the Domain
-Name System</title>
- <pubdate>January 1996</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2052</abbrev>
- <authorgroup>
- <author>
- <surname>Gulbrandsen</surname>
- <firstname>A.</firstname>
- </author>
- <author>
- <firstname>P.</firstname>
- <surname>Vixie</surname>
- </author>
- </authorgroup>
- <title>A <acronym>DNS</acronym> RR for Specifying the Location of
-Services.</title>
- <pubdate>October 1996</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2163</abbrev>
- <author>
- <surname>Allocchio</surname>
- <firstname>A.</firstname>
- </author>
- <title>Using the Internet <acronym>DNS</acronym> to Distribute MIXER
-Conformant Global Address Mapping</title>
- <pubdate>January 1998</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2230</abbrev>
- <author>
- <surname>Atkinson</surname>
- <firstname>R.</firstname>
- </author>
- <title>Key Exchange Delegation Record for the <acronym>DNS</acronym></title>
- <pubdate>October 1997</pubdate>
- </biblioentry>
- </bibliodiv>
- <bibliodiv>
- <title><acronym>DNS</acronym> and the Internet</title>
- <biblioentry>
- <abbrev>RFC1101</abbrev>
- <author>
- <surname>Mockapetris</surname>
- <firstname>P. V.</firstname>
- </author>
- <title><acronym>DNS</acronym> Encoding of Network Names and Other Types</title>
- <pubdate>April 1989</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1123</abbrev>
- <author>
- <surname>Braden</surname>
- <surname>R.</surname>
- </author>
- <title>Requirements for Internet Hosts - Application and Support</title>
- <pubdate>October 1989</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1591</abbrev>
- <author>
- <surname>Postel</surname>
- <firstname>J.</firstname></author>
- <title>Domain Name System Structure and Delegation</title>
- <pubdate>March 1994</pubdate></biblioentry>
- <biblioentry>
- <abbrev>RFC2317</abbrev>
- <authorgroup>
- <author>
- <surname>Eidnes</surname>
- <firstname>H.</firstname>
- </author>
- <author>
- <firstname>G.</firstname>
- <surname>de Groot</surname>
- </author>
- <author>
- <firstname>P.</firstname>
- <surname>Vixie</surname>
- </author>
- </authorgroup>
- <title>Classless IN-ADDR.ARPA Delegation</title>
- <pubdate>March 1998</pubdate>
- </biblioentry>
- </bibliodiv>
- <bibliodiv>
- <title><acronym>DNS</acronym> Operations</title>
- <biblioentry>
- <abbrev>RFC1537</abbrev>
- <author>
- <surname>Beertema</surname>
- <firstname>P.</firstname>
- </author>
- <title>Common <acronym>DNS</acronym> Data File Configuration Errors</title>
- <pubdate>October 1993</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1912</abbrev>
- <author>
- <surname>Barr</surname>
- <firstname>D.</firstname>
- </author>
- <title>Common <acronym>DNS</acronym> Operational and Configuration Errors</title>
- <pubdate>February 1996</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2010</abbrev>
- <authorgroup>
- <author>
- <surname>Manning</surname>
- <firstname>B.</firstname>
- </author>
- <author>
- <firstname>P.</firstname>
- <surname>Vixie</surname>
- </author>
- </authorgroup>
- <title>Operational Criteria for Root Name Servers.</title>
- <pubdate>October 1996</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2219</abbrev>
- <authorgroup>
- <author>
- <surname>Hamilton</surname>
- <firstname>M.</firstname>
- </author>
- <author>
- <firstname>R.</firstname>
- <surname>Wright</surname>
- </author>
- </authorgroup>
- <title>Use of <acronym>DNS</acronym> Aliases for Network Services.</title>
- <pubdate>October 1997</pubdate>
- </biblioentry>
- </bibliodiv>
- <bibliodiv>
- <title>Other <acronym>DNS</acronym>-related RFCs</title>
- <note>
- <para>Note: the following list of RFCs, although
-<acronym>DNS</acronym>-related, are not concerned with implementing software.</para>
- </note>
- <biblioentry>
- <abbrev>RFC1464</abbrev>
- <author>
- <surname>Rosenbaum</surname>
- <firstname>R.</firstname>
- </author>
- <title>Using the Domain Name System To Store Arbitrary String Attributes</title>
- <pubdate>May 1993</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC1713</abbrev>
- <author>
- <surname>Romao</surname>
- <firstname>A.</firstname>
- </author>
- <title>Tools for <acronym>DNS</acronym> Debugging</title>
- <pubdate>November 1994</pubdate></biblioentry>
- <biblioentry>
- <abbrev>RFC1794</abbrev>
- <author>
- <surname>Brisco</surname>
- <firstname>T.</firstname>
- </author>
- <title><acronym>DNS</acronym> Support for Load Balancing</title>
- <pubdate>April 1995</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2240</abbrev>
- <author>
- <surname>Vaughan</surname>
- <firstname>O.</firstname></author>
- <title>A Legal Basis for Domain Name Allocation</title>
- <pubdate>November 1997</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2345</abbrev>
- <authorgroup>
- <author>
- <surname>Klensin</surname>
- <firstname>J.</firstname>
- </author>
- <author>
- <firstname>T.</firstname>
- <surname>Wolf</surname>
- </author>
- <author>
- <firstname>G.</firstname>
- <surname>Oglesby</surname>
- </author>
- </authorgroup>
- <title>Domain Names and Company Name Retrieval</title>
- <pubdate>May 1998</pubdate>
- </biblioentry>
- <biblioentry>
- <abbrev>RFC2352</abbrev>
- <author>
- <surname>Vaughan</surname>
- <firstname>O.</firstname>
- </author>
- <title>A Convention For Using Legal Names as Domain Names</title>
- <pubdate>May 1998</pubdate>
- </biblioentry>
- </bibliodiv>
- <bibliodiv>
- <title>Obsolete and Unimplemented Experimental RRs</title>
- <biblioentry>
- <abbrev>RFC1712</abbrev>
- <authorgroup>
- <author>
- <surname>Farrell</surname>
- <firstname>C.</firstname>
- </author>
- <author>
- <firstname>M.</firstname>
- <surname>Schulze</surname>
- </author>
- <author>
- <firstname>S.</firstname>
- <surname>Pleitner</surname>
- </author>
- <author>
- <firstname>D.</firstname>
- <surname>Baldoni</surname>
- </author>
- </authorgroup>
- <title><acronym>DNS</acronym> Encoding of Geographical
-Location</title>
- <pubdate>November 1994</pubdate>
- </biblioentry>
- </bibliodiv>
- </bibliography>
- </sect2>
- <sect2 id="internet_drafts">
- <title>Internet Drafts</title>
- <para>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.
-</para>
- </sect2>
- <sect2>
- <title>Other Documents About <acronym>BIND</acronym></title>
- <para></para>
- <bibliography>
- <biblioentry>
- <authorgroup>
- <author>
- <surname>Albitz</surname>
- <firstname>Paul</firstname>
- </author>
- <author>
- <firstname>Cricket</firstname>
- <surname>Liu</surname>
- </author>
- </authorgroup>
- <title><acronym>DNS</acronym> and <acronym>BIND</acronym></title>
- <copyright>
- <year>1998</year>
- <holder>Sebastopol, CA: O'Reilly and Associates</holder>
- </copyright>
- </biblioentry>
- </bibliography>
- </sect2>
- </sect1>
-
-</appendix>
-
-</book>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch01.html b/contrib/bind9/doc/arm/Bv9ARM.ch01.html
deleted file mode 100644
index 37f1eec39ab75..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch01.html
+++ /dev/null
@@ -1,412 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch01.html,v 1.12.2.2.8.9 2005/10/13 02:33:58 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 1. Introduction </title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="next" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 1. Introduction </th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch01"></a>Chapter 1. Introduction </h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545879">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545905">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545976">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2546234">The Domain Name System (<span class="acronym">DNS</span>)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546254">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2544105">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546579">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546653">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546950">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2547076">Name Servers in Multiple Roles</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<p>The Internet Domain Name System (<span class="acronym">DNS</span>) 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. <span class="acronym">DNS</span> data is maintained in a group of distributed
- hierarchical databases.</p>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2545879"></a>Scope of Document</h2></div></div></div>
-<p>The Berkeley Internet Name Domain (<span class="acronym">BIND</span>) 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 (<span class="acronym">ISC</span>)
- <span class="acronym">BIND</span> version 9 software package for system
- administrators.</p>
-<p>This version of the manual corresponds to BIND version 9.3.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2545905"></a>Organization of This Document</h2></div></div></div>
-<p>In this document, <span class="emphasis"><em>Section 1</em></span> introduces
- the basic <span class="acronym">DNS</span> and <span class="acronym">BIND</span> concepts. <span class="emphasis"><em>Section 2</em></span>
- describes resource requirements for running <span class="acronym">BIND</span> in various
- environments. Information in <span class="emphasis"><em>Section 3</em></span> is
- <span class="emphasis"><em>task-oriented</em></span> in its presentation and is
- organized functionally, to aid in the process of installing the
- <span class="acronym">BIND</span> 9 software. The task-oriented section is followed by
- <span class="emphasis"><em>Section 4</em></span>, which contains more advanced
- concepts that the system administrator may need for implementing
- certain options. <span class="emphasis"><em>Section 5</em></span>
- describes the <span class="acronym">BIND</span> 9 lightweight
- resolver. The contents of <span class="emphasis"><em>Section 6</em></span> are
- organized as in a reference manual to aid in the ongoing
- maintenance of the software. <span class="emphasis"><em>Section 7
- </em></span>addresses security considerations, and
- <span class="emphasis"><em>Section 8</em></span> contains troubleshooting help. The
- main body of the document is followed by several
- <span class="emphasis"><em>Appendices</em></span> which contain useful reference
- information, such as a <span class="emphasis"><em>Bibliography</em></span> and
- historic information related to <span class="acronym">BIND</span> and the Domain Name
- System.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2545976"></a>Conventions Used in This Document</h2></div></div></div>
-<p>In this document, we use the following general typographic
- conventions:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-<p><span class="emphasis"><em>To
-describe:</em></span></p>
-</td>
-<td>
-<p><span class="emphasis"><em>We use the style:</em></span></p>
-</td>
-</tr>
-<tr>
-<td>
-<p>a pathname, filename, URL, hostname,
-mailing list name, or new term or concept</p>
-</td>
-<td><p><code class="filename">Fixed width</code></p></td>
-</tr>
-<tr>
-<td><p>literal user
-input</p></td>
-<td><p><strong class="userinput"><code>Fixed Width Bold</code></strong></p></td>
-</tr>
-<tr>
-<td><p>program output</p></td>
-<td><p><code class="computeroutput">Fixed Width</code></p></td>
-</tr>
-</tbody>
-</table></div>
-<p>The following conventions are used in descriptions of the
-<span class="acronym">BIND</span> configuration file:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><span class="emphasis"><em>To
-describe:</em></span></p></td>
-<td><p><span class="emphasis"><em>We use the style:</em></span></p></td>
-</tr>
-<tr>
-<td><p>keywords</p></td>
-<td><p><code class="literal">Fixed Width</code></p></td>
-</tr>
-<tr>
-<td><p>variables</p></td>
-<td><p><code class="varname">Fixed Width</code></p></td>
-</tr>
-<tr>
-<td><p>Optional input</p></td>
-<td><p>[<span class="optional">Text is enclosed in square brackets</span>]</p></td>
-</tr>
-</tbody>
-</table></div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2546234"></a>The Domain Name System (<span class="acronym">DNS</span>)</h2></div></div></div>
-<p>The purpose of this document is to explain the installation
-and upkeep of the <span class="acronym">BIND</span> software package, and we
-begin by reviewing the fundamentals of the Domain Name System
-(<span class="acronym">DNS</span>) as they relate to <span class="acronym">BIND</span>.
-</p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2546254"></a>DNS Fundamentals</h3></div></div></div>
-<p>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.</p>
-<p>Clients look up information in the DNS by calling a
-<span class="emphasis"><em>resolver</em></span> library, which sends queries to one or
-more <span class="emphasis"><em>name servers</em></span> and interprets the responses.
-The <span class="acronym">BIND</span> 9 software distribution contains a
-name server, <span><strong class="command">named</strong></span>, and two resolver
-libraries, <span><strong class="command">liblwres</strong></span> and <span><strong class="command">libbind</strong></span>.
-</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2544105"></a>Domains and Domain Names</h3></div></div></div>
-<p>The data stored in the DNS is identified by <span class="emphasis"><em>domain
-names</em></span> that are organized as a tree according to
-organizational or administrative boundaries. Each node of the tree,
-called a <span class="emphasis"><em>domain</em></span>, 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 <span class="emphasis"><em>root</em></span> 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.</p>
-<p>For example, a domain name for a host at the
-company <span class="emphasis"><em>Example, Inc.</em></span> could be
-<code class="literal">mail.example.com</code>,
-where <code class="literal">com</code> is the
-top level domain to which
-<code class="literal">ourhost.example.com</code> belongs,
-<code class="literal">example</code> is
-a subdomain of <code class="literal">com</code>, and
-<code class="literal">ourhost</code> is the
-name of the host.</p>
-<p>For administrative purposes, the name space is partitioned into
-areas called <span class="emphasis"><em>zones</em></span>, 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 <span class="emphasis"><em>name
-server</em></span>, which answers queries about the zone using the
-<span class="emphasis"><em>DNS protocol</em></span>.
-</p>
-<p>The data associated with each domain name is stored in the
-form of <span class="emphasis"><em>resource records</em></span> (<span class="acronym">RR</span>s).
-Some of the supported resource record types are described in
-<a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them" title="Types of Resource Records and When to Use Them">the section called &#8220;Types of Resource Records and When to Use Them&#8221;</a>.</p>
-<p>For more detailed information about the design of the DNS and
-the DNS protocol, please refer to the standards documents listed in
-<a href="Bv9ARM.ch09.html#rfcs" title="Request for Comments (RFCs)">the section called &#8220;Request for Comments (RFCs)&#8221;</a>.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2546579"></a>Zones</h3></div></div></div>
-<p>To properly operate a name server, it is important to understand
-the difference between a <span class="emphasis"><em>zone</em></span>
-and a <span class="emphasis"><em>domain</em></span>.</p>
-<p>As we stated previously, a zone is a point of delegation in
-the <span class="acronym">DNS</span> 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
-<span class="emphasis"><em>NS records</em></span> in the
-parent zone, which should be matched by equivalent NS records at
-the root of the delegated zone.</p>
-<p>For instance, consider the <code class="literal">example.com</code>
-domain which includes names
-such as <code class="literal">host.aaa.example.com</code> and
-<code class="literal">host.bbb.example.com</code> even though
-the <code class="literal">example.com</code> zone includes
-only delegations for the <code class="literal">aaa.example.com</code> and
-<code class="literal">bbb.example.com</code> 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 <span class="acronym">DNS</span> tree is a
-<span class="emphasis"><em>domain</em></span>, even if it is
-<span class="emphasis"><em>terminal</em></span>, that is, has no
-<span class="emphasis"><em>subdomains</em></span>. 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.</p>
-<p>Though <span class="acronym">BIND</span> is called a "domain name server",
-it deals primarily in terms of zones. The master and slave
-declarations in the <code class="filename">named.conf</code> file specify
-zones, not domains. When you ask some other site if it is willing to
-be a slave server for your <span class="emphasis"><em>domain</em></span>, you are
-actually asking for slave service for some collection of zones.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2546653"></a>Authoritative Name Servers</h3></div></div></div>
-<p>Each zone is served by at least
-one <span class="emphasis"><em>authoritative name server</em></span>,
-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.
-</p>
-<p>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
-<span><strong class="command">dig</strong></span> (<a href="Bv9ARM.ch03.html#diagnostic_tools" title="Diagnostic Tools">the section called &#8220;Diagnostic Tools&#8221;</a>).</p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2546676"></a>The Primary Master</h4></div></div></div>
-<p>
-The authoritative server where the master copy of the zone data is maintained is
-called the <span class="emphasis"><em>primary master</em></span> server, or simply the
-<span class="emphasis"><em>primary</em></span>. 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 <span class="emphasis"><em>zone file</em></span> or <span class="emphasis"><em>master file</em></span>.</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2546902"></a>Slave Servers</h4></div></div></div>
-<p>The other authoritative servers, the <span class="emphasis"><em>slave</em></span>
-servers (also known as <span class="emphasis"><em>secondary</em></span> servers) load
-the zone contents from another server using a replication process
-known as a <span class="emphasis"><em>zone transfer</em></span>. 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.</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2546921"></a>Stealth Servers</h4></div></div></div>
-<p>Usually all of the zone's authoritative servers are listed in
-NS records in the parent zone. These NS records constitute
-a <span class="emphasis"><em>delegation</em></span> of the zone from the parent.
-The authoritative servers are also listed in the zone file itself,
-at the <span class="emphasis"><em>top level</em></span> or <span class="emphasis"><em>apex</em></span>
-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.</p>
-<p>A <span class="emphasis"><em>stealth server</em></span> 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.</p>
-<p>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.</p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2546950"></a>Caching Name Servers</h3></div></div></div>
-<p>The resolver libraries provided by most operating systems are
-<span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not 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 <span class="emphasis"><em>recursive</em></span> name server; it performs
-<span class="emphasis"><em>recursive lookups</em></span> for local clients.</p>
-<p>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
-<span class="emphasis"><em>recursive server</em></span> and
-<span class="emphasis"><em>caching server</em></span> are often used synonymously.</p>
-<p>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.
-</p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2547050"></a>Forwarding</h4></div></div></div>
-<p>Even a caching name server does not necessarily perform
-the complete recursive lookup itself. Instead, it can
-<span class="emphasis"><em>forward</em></span> some or all of the queries
-that it cannot satisfy from its cache to another caching name server,
-commonly referred to as a <span class="emphasis"><em>forwarder</em></span>.
-</p>
-<p>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 <span class="acronym">DNS</span> 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 <span class="acronym">DNS</span> 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.</p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2547076"></a>Name Servers in Multiple Roles</h3></div></div></div>
-<p>The <span class="acronym">BIND</span> 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.</p>
-<p>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 <span class="emphasis"><em>authoritative-only</em></span> 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 <span class="emphasis"><em>caching-only</em></span> server)
-does not need to be reachable from the Internet at large and can
-be placed inside a firewall.</p>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">BIND 9 Administrator Reference Manual </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 2. <span class="acronym">BIND</span> Resource Requirements</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch02.html b/contrib/bind9/doc/arm/Bv9ARM.ch02.html
deleted file mode 100644
index d3e946ad77065..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch02.html
+++ /dev/null
@@ -1,130 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch02.html,v 1.10.2.1.8.8 2005/10/13 02:33:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 2. BIND Resource Requirements</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction ">
-<link rel="next" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 2. <span class="acronym">BIND</span> Resource Requirements</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch02"></a>Chapter 2. <span class="acronym">BIND</span> Resource Requirements</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547108">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547132">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547143">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547158">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547303">Supported Operating Systems</a></span></dt>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2547108"></a>Hardware requirements</h2></div></div></div>
-<p><span class="acronym">DNS</span> hardware requirements have traditionally been quite modest.
-For many installations, servers that have been pensioned off from
-active duty have performed admirably as <span class="acronym">DNS</span> servers.</p>
-<p>The DNSSEC and IPv6 features of <span class="acronym">BIND</span> 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.
-<span class="acronym">BIND</span> 9 is fully multithreaded, allowing full utilization of
-multiprocessor systems for installations that need it.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2547132"></a>CPU Requirements</h2></div></div></div>
-<p>CPU requirements for <span class="acronym">BIND</span> 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.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2547143"></a>Memory Requirements</h2></div></div></div>
-<p>The memory of the server has to be large enough to fit the
-cache and zones loaded off disk. The <span><strong class="command">max-cache-size</strong></span>
-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 <span class="acronym">DNS</span>
-traffic. It is still good practice to have enough memory to load
-all zone and cache data into memory &#8212; 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.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2547158"></a>Name Server Intensive Environment Issues</h2></div></div></div>
-<p>For name server intensive environments, there are two alternative
-configurations that may be used. The first is where clients and
-any second-level internal name servers query a main name server, which
-has enough memory to build a large cache. This approach minimizes
-the bandwidth used by external name lookups. The second alternative
-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.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2547303"></a>Supported Operating Systems</h2></div></div></div>
-<p>ISC <span class="acronym">BIND</span> 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.</p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 1. Introduction  </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 3. Name Server Configuration</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch03.html b/contrib/bind9/doc/arm/Bv9ARM.ch03.html
deleted file mode 100644
index 4d6d93be1f1bd..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch03.html
+++ /dev/null
@@ -1,525 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch03.html,v 1.26.2.5.4.11 2005/10/13 02:33:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 3. Name Server Configuration</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
-<link rel="next" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 3. Name Server Configuration</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch02.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch04.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch03"></a>Chapter 3. Name Server Configuration</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547334">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547350">An Authoritative-only Name Server</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2547372">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2547656">Name Server Operations</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547661">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2548915">Signals</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<p>In this section we provide some suggested configurations along
-with guidelines for their use. We also address the topic of reasonable
-option setting.</p>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="sample_configuration"></a>Sample Configurations</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2547334"></a>A Caching-only Name Server</h3></div></div></div>
-<p>The following sample configuration is appropriate for a caching-only
-name server for use by clients internal to a corporation. All queries
-from outside clients are refused using the <span><strong class="command">allow-query</strong></span>
-option. Alternatively, the same effect could be achieved using suitable
-firewall rules.</p>
-<pre class="programlisting">
-// 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
- allow-query { corpnets; };
-};
-// Provide a reverse mapping for the loopback address 127.0.0.1
-zone "0.0.127.in-addr.arpa" {
- type master;
- file "localhost.rev";
- notify no;
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2547350"></a>An Authoritative-only Name Server</h3></div></div></div>
-<p>This sample configuration is for an authoritative-only server
-that is the master server for "<code class="filename">example.com</code>"
-and a slave for the subdomain "<code class="filename">eng.example.com</code>".</p>
-<pre class="programlisting">
-options {
- directory "/etc/namedb"; // Working directory
- allow-query { any; }; // This is the default
- recursion no; // Do not provide recursive service
-};
-
-// Provide a reverse mapping for the loopback address 127.0.0.1
-zone "0.0.127.in-addr.arpa" {
- type master;
- file "localhost.rev";
- notify no;
-};
-// We are the master server for example.com
-zone "example.com" {
- type master;
- file "example.com.db";
- // IP addresses of slave servers allowed to transfer example.com
- allow-transfer {
- 192.168.4.14;
- 192.168.5.53;
- };
-};
-// We are a slave server for eng.example.com
-zone "eng.example.com" {
- type slave;
- file "eng.example.com.bk";
- // IP address of eng.example.com master server
- masters { 192.168.4.12; };
-};
-</pre>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2547372"></a>Load Balancing</h2></div></div></div>
-<p>A primitive form of load balancing can be achieved in
-the <span class="acronym">DNS</span> by using multiple A records for one name.</p>
-<p>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:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p>Name</p></td>
-<td><p>TTL</p></td>
-<td><p>CLASS</p></td>
-<td><p>TYPE</p></td>
-<td><p>Resource Record (RR) Data</p></td>
-</tr>
-<tr>
-<td><p><code class="literal">www</code></p></td>
-<td><p><code class="literal">600</code></p></td>
-<td><p><code class="literal">IN</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">10.0.0.1</code></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p><code class="literal">600</code></p></td>
-<td><p><code class="literal">IN</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">10.0.0.2</code></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p><code class="literal">600</code></p></td>
-<td><p><code class="literal">IN</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">10.0.0.3</code></p></td>
-</tr>
-</tbody>
-</table></div>
-<p>When a resolver queries for these records, <span class="acronym">BIND</span> 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.</p>
-<p>For more detail on ordering responses, check the
- <span><strong class="command">rrset-order</strong></span> substatement in the
- <span><strong class="command">options</strong></span> statement, see
- <a href="Bv9ARM.ch06.html#rrset_ordering">RRset Ordering</a>.
- This substatement is not supported in
- <span class="acronym">BIND</span> 9, and only the ordering scheme described above is
- available.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2547656"></a>Name Server Operations</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2547661"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
-<p>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 </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="diagnostic_tools"></a>Diagnostic Tools</h4></div></div></div>
-<p>The <span><strong class="command">dig</strong></span>, <span><strong class="command">host</strong></span>, and
-<span><strong class="command">nslookup</strong></span> programs are all command line tools
-for manually querying name servers. They differ in style and
-output format.
-</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><a name="dig"></a><span><strong class="command">dig</strong></span></span></dt>
-<dd>
-<p>The domain information groper (<span><strong class="command">dig</strong></span>)
-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.</p>
-<div class="cmdsynopsis"><p><code class="command">dig</code> [@<em class="replaceable"><code>server</code></em>] <em class="replaceable"><code>domain</code></em> [<em class="replaceable"><code>query-type</code></em>] [<em class="replaceable"><code>query-class</code></em>] [+<em class="replaceable"><code>query-option</code></em>] [-<em class="replaceable"><code>dig-option</code></em>] [%<em class="replaceable"><code>comment</code></em>]</p></div>
-<p>The usual simple use of dig will take the form</p>
-<p><span><strong class="command">dig @server domain query-type query-class</strong></span></p>
-<p>For more information and a list of available commands and
-options, see the <span><strong class="command">dig</strong></span> man page.</p>
-</dd>
-<dt><span class="term"><span><strong class="command">host</strong></span></span></dt>
-<dd>
-<p>The <span><strong class="command">host</strong></span> 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.</p>
-<div class="cmdsynopsis"><p><code class="command">host</code> [-aCdlrTwv] [-c <em class="replaceable"><code>class</code></em>] [-N <em class="replaceable"><code>ndots</code></em>] [-t <em class="replaceable"><code>type</code></em>] [-W <em class="replaceable"><code>timeout</code></em>] [-R <em class="replaceable"><code>retries</code></em>] <em class="replaceable"><code>hostname</code></em> [<em class="replaceable"><code>server</code></em>]</p></div>
-<p>For more information and a list of available commands and
-options, see the <span><strong class="command">host</strong></span> man page.</p>
-</dd>
-<dt><span class="term"><span><strong class="command">nslookup</strong></span></span></dt>
-<dd>
-<p><span><strong class="command">nslookup</strong></span> 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.</p>
-<div class="cmdsynopsis"><p><code class="command">nslookup</code> [-option...] [[<em class="replaceable"><code>host-to-find</code></em>] | [- [server]]]</p></div>
-<p>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.</p>
-<p>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.</p>
-<p>Due to its arcane user interface and frequently inconsistent
-behavior, we do not recommend the use of <span><strong class="command">nslookup</strong></span>.
-Use <span><strong class="command">dig</strong></span> instead.</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="admin_tools"></a>Administrative Tools</h4></div></div></div>
-<p>Administrative tools play an integral part in the management
-of a server.</p>
-<div class="variablelist"><dl>
-<dt>
-<a name="named-checkconf"></a><span class="term"><span><strong class="command">named-checkconf</strong></span></span>
-</dt>
-<dd>
-<p>The <span><strong class="command">named-checkconf</strong></span> program
- checks the syntax of a <code class="filename">named.conf</code> file.</p>
-<div class="cmdsynopsis"><p><code class="command">named-checkconf</code> [-jvz] [-t <em class="replaceable"><code>directory</code></em>] [<em class="replaceable"><code>filename</code></em>]</p></div>
-</dd>
-<dt>
-<a name="named-checkzone"></a><span class="term"><span><strong class="command">named-checkzone</strong></span></span>
-</dt>
-<dd>
-<p>The <span><strong class="command">named-checkzone</strong></span> program checks a master file for
- syntax and consistency.</p>
-<div class="cmdsynopsis"><p><code class="command">named-checkzone</code> [-djqvD] [-c <em class="replaceable"><code>class</code></em>] [-o <em class="replaceable"><code>output</code></em>] [-t <em class="replaceable"><code>directory</code></em>] [-w <em class="replaceable"><code>directory</code></em>] [-k <em class="replaceable"><code>(ignore|warn|fail)</code></em>] [-n <em class="replaceable"><code>(ignore|warn|fail)</code></em>] <em class="replaceable"><code>zone</code></em> [<em class="replaceable"><code>filename</code></em>]</p></div>
-</dd>
-<dt>
-<a name="rndc"></a><span class="term"><span><strong class="command">rndc</strong></span></span>
-</dt>
-<dd>
-<p>The remote name daemon control
- (<span><strong class="command">rndc</strong></span>) program allows the system
- administrator to control the operation of a name server.
- If you run <span><strong class="command">rndc</strong></span> without any options
- it will display a usage message as follows:</p>
-<div class="cmdsynopsis"><p><code class="command">rndc</code> [-c <em class="replaceable"><code>config</code></em>] [-s <em class="replaceable"><code>server</code></em>] [-p <em class="replaceable"><code>port</code></em>] [-y <em class="replaceable"><code>key</code></em>] <em class="replaceable"><code>command</code></em> [<em class="replaceable"><code>command</code></em>...]</p></div>
-<p><span><strong class="command">command</strong></span> is one of the following:</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><strong class="userinput"><code>reload</code></strong></span></dt>
-<dd><p>Reload configuration file and zones.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>reload <em class="replaceable"><code>zone</code></em>
- [<span class="optional"><em class="replaceable"><code>class</code></em>
- [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
-<dd><p>Reload the given zone.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>refresh <em class="replaceable"><code>zone</code></em>
- [<span class="optional"><em class="replaceable"><code>class</code></em>
- [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
-<dd><p>Schedule zone maintenance for the given zone.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>retransfer <em class="replaceable"><code>zone</code></em>
- [<span class="optional"><em class="replaceable"><code>class</code></em>
- [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
-<dd><p>Retransfer the given zone from the master.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>freeze [<span class="optional"><em class="replaceable"><code>zone</code></em>
- [<span class="optional"><em class="replaceable"><code>class</code></em>
- [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</span>]</code></strong></span></dt>
-<dd><p>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.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>thaw [<span class="optional"><em class="replaceable"><code>zone</code></em>
- [<span class="optional"><em class="replaceable"><code>class</code></em>
- [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</span>]</code></strong></span></dt>
-<dd><p>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 thawed, dynamic updates
- will no longer be refused.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>notify <em class="replaceable"><code>zone</code></em>
- [<span class="optional"><em class="replaceable"><code>class</code></em>
- [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
-<dd><p>Resend NOTIFY messages for the zone</p></dd>
-<dt><span class="term"><strong class="userinput"><code>reconfig</code></strong></span></dt>
-<dd><p>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 <span><strong class="command">reload</strong></span> when there
- is a large number of zones because it avoids the need to examine the
- modification times of the zones files.
- </p></dd>
-<dt><span class="term"><strong class="userinput"><code>stats</code></strong></span></dt>
-<dd><p>Write server statistics to the statistics file.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>querylog</code></strong></span></dt>
-<dd><p>Toggle query logging. Query logging can also be enabled
- by explicitly directing the <span><strong class="command">queries</strong></span>
- <span><strong class="command">category</strong></span> to a <span><strong class="command">channel</strong></span> in the
- <span><strong class="command">logging</strong></span> section of
- <code class="filename">named.conf</code>.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>dumpdb [<span class="optional">-all|-cache|-zone</span>] [<span class="optional"><em class="replaceable"><code>view ...</code></em></span>]</code></strong></span></dt>
-<dd><p>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.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>stop [<span class="optional">-p</span>]</code></strong></span></dt>
-<dd><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. If -p is specified named's process id is returned.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>halt [<span class="optional">-p</span>]</code></strong></span></dt>
-<dd><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. If -p is specified named's process id is returned.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>trace</code></strong></span></dt>
-<dd><p>Increment the servers debugging level by one. </p></dd>
-<dt><span class="term"><strong class="userinput"><code>trace <em class="replaceable"><code>level</code></em></code></strong></span></dt>
-<dd><p>Sets the server's debugging level to an explicit
- value.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>notrace</code></strong></span></dt>
-<dd><p>Sets the server's debugging level to 0.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>flush</code></strong></span></dt>
-<dd><p>Flushes the server's cache.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>flushname</code></strong> <em class="replaceable"><code>name</code></em></span></dt>
-<dd><p>Flushes the given name from the server's cache.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>status</code></strong></span></dt>
-<dd><p>Display status of the server.
-Note the number of zones includes the internal <span><strong class="command">bind/CH</strong></span> zone
-and the default <span><strong class="command">./IN</strong></span> hint zone if there is not a
-explicit root zone configured.</p></dd>
-<dt><span class="term"><strong class="userinput"><code>recursing</code></strong></span></dt>
-<dd><p>Dump the list of queries named is currently recursing
- on.
- </p></dd>
-</dl></div>
-<p>In <span class="acronym">BIND</span> 9.2, <span><strong class="command">rndc</strong></span>
-supports all the commands of the BIND 8 <span><strong class="command">ndc</strong></span>
-utility except <span><strong class="command">ndc start</strong></span> and
-<span><strong class="command">ndc restart</strong></span>, which were also
-not supported in <span><strong class="command">ndc</strong></span>'s channel mode.</p>
-<p>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
-<span><strong class="command">rndc</strong></span> configuration file is
-<code class="filename">/etc/rndc.conf</code>, but an alternate
-location can be specified with the <code class="option">-c</code>
-option. If the configuration file is not found,
-<span><strong class="command">rndc</strong></span> will also look in
-<code class="filename">/etc/rndc.key</code> (or whatever
-<code class="varname">sysconfdir</code> was defined when
-the <span class="acronym">BIND</span> build was configured).
-The <code class="filename">rndc.key</code> file is generated by
-running <span><strong class="command">rndc-confgen -a</strong></span> as described in
-<a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and Usage&#8221;</a>.</p>
-<p>The format of the configuration file is similar to
-that of <code class="filename">named.conf</code>, but limited to
-only four statements, the <span><strong class="command">options</strong></span>,
-<span><strong class="command">key</strong></span>, <span><strong class="command">server</strong></span> and
-<span><strong class="command">include</strong></span>
-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.</p>
-<p>The <span><strong class="command">options</strong></span> statement has three clauses:
-<span><strong class="command">default-server</strong></span>, <span><strong class="command">default-key</strong></span>,
-and <span><strong class="command">default-port</strong></span>.
-<span><strong class="command">default-server</strong></span> takes a
-host name or address argument and represents the server that will
-be contacted if no <code class="option">-s</code>
-option is provided on the command line.
-<span><strong class="command">default-key</strong></span> takes
-the name of a key as its argument, as defined by a <span><strong class="command">key</strong></span> statement.
-<span><strong class="command">default-port</strong></span> specifies the port to which
-<span><strong class="command">rndc</strong></span> should connect if no
-port is given on the command line or in a
-<span><strong class="command">server</strong></span> statement.</p>
-<p>The <span><strong class="command">key</strong></span> statement defines an key to be used
-by <span><strong class="command">rndc</strong></span> when authenticating with
-<span><strong class="command">named</strong></span>. Its syntax is identical to the
-<span><strong class="command">key</strong></span> statement in named.conf.
-The keyword <strong class="userinput"><code>key</code></strong> is
-followed by a key name, which must be a valid
-domain name, though it need not actually be hierarchical; thus,
-a string like "<strong class="userinput"><code>rndc_key</code></strong>" is a valid name.
-The <span><strong class="command">key</strong></span> statement has two clauses:
-<span><strong class="command">algorithm</strong></span> and <span><strong class="command">secret</strong></span>.
-While the configuration parser will accept any string as the argument
-to algorithm, currently only the string "<strong class="userinput"><code>hmac-md5</code></strong>"
-has any meaning. The secret is a base-64 encoded string.</p>
-<p>The <span><strong class="command">server</strong></span> statement associates a key
-defined using the <span><strong class="command">key</strong></span> statement with a server.
-The keyword <strong class="userinput"><code>server</code></strong> is followed by a
-host name or address. The <span><strong class="command">server</strong></span> statement
-has two clauses: <span><strong class="command">key</strong></span> and <span><strong class="command">port</strong></span>.
-The <span><strong class="command">key</strong></span> clause specifies the name of the key
-to be used when communicating with this server, and the
-<span><strong class="command">port</strong></span> clause can be used to
-specify the port <span><strong class="command">rndc</strong></span> should connect
-to on the server.</p>
-<p>A sample minimal configuration file is as follows:</p>
-<pre class="programlisting">
-key rndc_key {
- algorithm "hmac-md5";
- secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
-};
-options {
- default-server 127.0.0.1;
- default-key rndc_key;
-};
-</pre>
-<p>This file, if installed as <code class="filename">/etc/rndc.conf</code>,
-would allow the command:</p>
-<p><code class="prompt">$ </code><strong class="userinput"><code>rndc reload</code></strong></p>
-<p>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:</p>
-<pre class="programlisting">
-controls {
- inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
-};
-</pre>
-<p>and it had an identical key statement for
-<code class="literal">rndc_key</code>.</p>
-<p>Running the <span><strong class="command">rndc-confgen</strong></span> program will
-conveniently create a <code class="filename">rndc.conf</code>
-file for you, and also display the
-corresponding <span><strong class="command">controls</strong></span> statement that you need to
-add to <code class="filename">named.conf</code>. Alternatively,
-you can run <span><strong class="command">rndc-confgen -a</strong></span> to set up
-a <code class="filename">rndc.key</code> file and not modify
-<code class="filename">named.conf</code> at all.
-</p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2548915"></a>Signals</h3></div></div></div>
-<p>Certain UNIX signals cause the name server to take specific
-actions, as described in the following table. These signals can
-be sent using the <span><strong class="command">kill</strong></span> command.</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><span><strong class="command">SIGHUP</strong></span></p></td>
-<td><p>Causes the server to read <code class="filename">named.conf</code> and
-reload the database. </p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">SIGTERM</strong></span></p></td>
-<td><p>Causes the server to clean up and exit.</p></td>
-</tr>
-<tr>
-<td>
-<p><span><strong class="command">SIGINT</strong></span></p>
-</td>
-<td><p>Causes the server to clean up and exit.</p></td>
-</tr>
-</tbody>
-</table></div>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch02.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch04.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 2. <span class="acronym">BIND</span> Resource Requirements </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 4. Advanced DNS Features</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch04.html b/contrib/bind9/doc/arm/Bv9ARM.ch04.html
deleted file mode 100644
index 8165dbba96758..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch04.html
+++ /dev/null
@@ -1,716 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch04.html,v 1.30.2.6.2.14 2005/10/13 02:33:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 4. Advanced DNS Features</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
-<link rel="next" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 4. Advanced DNS Features</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch04"></a>Chapter 4. Advanced DNS Features</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2549203">Split DNS</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549627">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549830">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549838">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549878">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549998">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550042">Errors</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550056">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550173">SIG(0)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550308">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550375">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550450">Configuring Servers</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550473">IPv6 Support in <span class="acronym">BIND</span> 9</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550600">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550620">Address to Name Lookups Using Nibble Format</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="notify"></a>Notify</h2></div></div></div>
-<p><span class="acronym">DNS</span> NOTIFY is a mechanism that allows master
-servers to notify their slave servers of changes to a zone's data. In
-response to a <span><strong class="command">NOTIFY</strong></span> 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.</p>
-<p><span class="acronym">DNS</span>
-For more information about
-<span><strong class="command">NOTIFY</strong></span>, see the description of the
-<span><strong class="command">notify</strong></span> option in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a> and
-the description of the zone option <span><strong class="command">also-notify</strong></span> in
-<a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>. The <span><strong class="command">NOTIFY</strong></span>
-protocol is specified in RFC 1996.
-</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="dynamic_update"></a>Dynamic Update</h2></div></div></div>
-<p>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.</p>
-<p>Dynamic update is enabled on a zone-by-zone basis, by
- including an <span><strong class="command">allow-update</strong></span> or
- <span><strong class="command">update-policy</strong></span> clause in the
- <span><strong class="command">zone</strong></span> statement.</p>
-<p>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.</p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="journal"></a>The journal file</h3></div></div></div>
-<p>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 the first dynamic update takes place. The name of
- the journal file is formed by appending the
- extension <code class="filename">.jnl</code> to the
- name of the corresponding zone file. The journal file is in a
- binary format and should not be edited manually.</p>
-<p>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.</p>
-<p>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.</p>
-<p>Changes that result from incoming incremental zone transfers are also
- journalled in a similar way.</p>
-<p>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 <span><strong class="command">rndc stop</strong></span>.</p>
-<p>If you have to make changes to a dynamic zone
- manually, the following procedure will work: Disable dynamic updates
- to the zone using
- <span><strong class="command">rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>.
- This will also remove the zone's <code class="filename">.jnl</code> file
- and update the master file. Edit the zone file. Run
- <span><strong class="command">rndc unfreeze <em class="replaceable"><code>zone</code></em></strong></span>
- to reload the changed zone and re-enable dynamic updates.</p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="incremental_zone_transfers"></a>Incremental Zone Transfers (IXFR)</h2></div></div></div>
-<p>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 <a href="Bv9ARM.ch09.html#proposed_standards">Proposed Standards</a>.</p>
-<p>When acting as a master, <span class="acronym">BIND</span> 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
-<span><strong class="command">ixfr-from-differences</strong></span> is set
-to <strong class="userinput"><code>yes</code></strong>.
-</p>
-<p>When acting as a slave, <span class="acronym">BIND</span> 9 will
-attempt to use IXFR unless
-it is explicitly disabled. For more information about disabling
-IXFR, see the description of the <span><strong class="command">request-ixfr</strong></span> clause
-of the <span><strong class="command">server</strong></span> statement.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2549203"></a>Split DNS</h2></div></div></div>
-<p>Setting up different views, or visibility, of the DNS space to
-internal and external resolvers is usually referred to as a <span class="emphasis"><em>Split
-DNS</em></span> setup. There are several reasons an organization
-would want to set up its DNS this way.</p>
-<p>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.</p>
-<p>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.</p>
-<p>Here is an example of a split DNS setup:</p>
-<p>Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
-(<code class="literal">example.com</code>)
-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.</p>
-<p><span class="emphasis"><em>Example, Inc.</em></span> 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.</p>
-<p>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.</p>
-<p>The internal servers will be configured to forward all queries,
-except queries for <code class="filename">site1.internal</code>, <code class="filename">site2.internal</code>, <code class="filename">site1.example.com</code>,
-and <code class="filename">site2.example.com</code>, to the servers in the
-DMZ. These internal servers will have complete sets of information
-for <code class="filename">site1.example.com</code>, <code class="filename">site2.example.com</code>,<span class="emphasis"><em> </em></span><code class="filename">site1.internal</code>,
-and <code class="filename">site2.internal</code>.</p>
-<p>To protect the <code class="filename">site1.internal</code> and <code class="filename">site2.internal</code> domains,
-the internal name servers must be configured to disallow all queries
-to these domains from any external hosts, including the bastion
-hosts.</p>
-<p>The external servers, which are on the bastion hosts, will
-be configured to serve the "public" version of the <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones.
-This could include things such as the host records for public servers
-(<code class="filename">www.example.com</code> and <code class="filename">ftp.example.com</code>),
-and mail exchange (MX) records (<code class="filename">a.mx.example.com</code> and <code class="filename">b.mx.example.com</code>).</p>
-<p>In addition, the public <code class="filename">site1</code> and <code class="filename">site2.example.com</code> 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.</p>
-<p>Here's an example of a wildcard MX record:</p>
-<pre class="programlisting">* IN MX 10 external1.example.com.</pre>
-<p>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.</p>
-<p>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.</p>
-<p>In order for all this to work properly, internal clients will
-need to be configured to query <span class="emphasis"><em>only</em></span> the internal
-name servers for DNS queries. This could also be enforced via selective
-filtering on the network.</p>
-<p>If everything has been set properly, <span class="emphasis"><em>Example, Inc.</em></span>'s
-internal clients will now be able to:</p>
-<div class="itemizedlist"><ul type="disc">
-<li>Look up any hostnames in the <code class="literal">site1</code> and
-<code class="literal">site2.example.com</code> zones.</li>
-<li>Look up any hostnames in the <code class="literal">site1.internal</code> and
-<code class="literal">site2.internal</code> domains.</li>
-<li>Look up any hostnames on the Internet.</li>
-<li>Exchange mail with internal AND external people.</li>
-</ul></div>
-<p>Hosts on the Internet will be able to:</p>
-<div class="itemizedlist"><ul type="disc">
-<li>Look up any hostnames in the <code class="literal">site1</code> and
-<code class="literal">site2.example.com</code> zones.</li>
-<li>Exchange mail with anyone in the <code class="literal">site1</code> and
-<code class="literal">site2.example.com</code> zones.</li>
-</ul></div>
-<p>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 <a href="Bv9ARM.ch03.html#sample_configuration" title="Sample Configurations">the section called &#8220;Sample Configurations&#8221;</a></p>
-<p>Internal DNS server config:</p>
-<pre class="programlisting">
-
-acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-
-acl externals { <code class="varname">bastion-ips-go-here</code>; };
-
-options {
- ...
- ...
- forward only;
- forwarders { // forward to external servers
- <code class="varname">bastion-ips-go-here</code>;
- };
- allow-transfer { none; }; // sample allow-transfer (no one)
- allow-query { internals; externals; }; // restrict query access
- allow-recursion { internals; }; // restrict recursion
- ...
- ...
-};
-
-zone "site1.example.com" { // sample master zone
- type master;
- file "m/site1.example.com";
- forwarders { }; // do normal iterative
- // resolution (do not forward)
- allow-query { internals; externals; };
- allow-transfer { internals; };
-};
-
-zone "site2.example.com" { // sample slave zone
- type slave;
- file "s/site2.example.com";
- masters { 172.16.72.3; };
- forwarders { };
- allow-query { internals; externals; };
- allow-transfer { internals; };
-};
-
-zone "site1.internal" {
- type master;
- file "m/site1.internal";
- forwarders { };
- allow-query { internals; };
- allow-transfer { internals; }
-};
-
-zone "site2.internal" {
- type slave;
- file "s/site2.internal";
- masters { 172.16.72.3; };
- forwarders { };
- allow-query { internals };
- allow-transfer { internals; }
-};
-</pre>
-<p>External (bastion host) DNS server config:</p>
-<pre class="programlisting">
-acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-
-acl externals { bastion-ips-go-here; };
-
-options {
- ...
- ...
- allow-transfer { none; }; // sample allow-transfer (no one)
- allow-query { internals; externals; }; // restrict query access
- allow-recursion { internals; externals; }; // restrict recursion
- ...
- ...
-};
-
-zone "site1.example.com" { // sample slave zone
- type master;
- file "m/site1.foo.com";
- allow-query { any; };
- allow-transfer { internals; externals; };
-};
-
-zone "site2.example.com" {
- type slave;
- file "s/site2.foo.com";
- masters { another_bastion_host_maybe; };
- allow-query { any; };
- allow-transfer { internals; externals; }
-};
-</pre>
-<p>In the <code class="filename">resolv.conf</code> (or equivalent) on
-the bastion host(s):</p>
-<pre class="programlisting">
-search ...
-nameserver 172.16.72.2
-nameserver 172.16.72.3
-nameserver 172.16.72.4
-</pre>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="tsig"></a>TSIG</h2></div></div></div>
-<p>This is a short guide to setting up Transaction SIGnatures
-(TSIG) based transaction security in <span class="acronym">BIND</span>. 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 <span class="acronym">BIND</span>.</p>
-<p><span class="acronym">BIND</span> primarily supports TSIG for server to server communication.
-This includes zone transfer, notify, and recursive query messages.
-Resolvers based on newer versions of <span class="acronym">BIND</span> 8 have limited support
-for TSIG.</p>
-<p>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 <span><strong class="command">nsupdate</strong></span>
- program supports TSIG via the <code class="option">-k</code> and
- <code class="option">-y</code> command line options.</p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2549627"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
-<p>A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
-An arbitrary key name is chosen: "host1-host2.". The key name must
-be the same on both hosts.</p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2549643"></a>Automatic Generation</h4></div></div></div>
-<p>The following command will generate a 128 bit (16 byte) HMAC-MD5
-key as described above. Longer keys are better, but shorter keys
-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.</p>
-<p><strong class="userinput"><code>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</code></strong></p>
-<p>The key is in the file <code class="filename">Khost1-host2.+157+00000.private</code>.
-Nothing directly uses this file, but the base-64 encoded string
-following "<code class="literal">Key:</code>"
-can be extracted from the file and used as a shared secret:</p>
-<pre class="programlisting">Key: La/E5CjG9O+os1jq0a2jdA==</pre>
-<p>The string "<code class="literal">La/E5CjG9O+os1jq0a2jdA==</code>" can
-be used as the shared secret.</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2549677"></a>Manual Generation</h4></div></div></div>
-<p>The shared secret is simply a random sequence of bits, encoded
-in base-64. Most ASCII strings are valid base-64 strings (assuming
-the length is a multiple of 4 and only valid characters are used),
-so the shared secret can be manually generated.</p>
-<p>Also, a known string can be run through <span><strong class="command">mmencode</strong></span> or
-a similar program to generate base-64 encoded data.</p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2549830"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
-<p>This is beyond the scope of DNS. A secure transport mechanism
-should be used. This could be secure FTP, ssh, telephone, etc.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2549838"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
-<p>Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span> are
-both servers. The following is added to each server's <code class="filename">named.conf</code> file:</p>
-<pre class="programlisting">
-key host1-host2. {
- algorithm hmac-md5;
- secret "La/E5CjG9O+os1jq0a2jdA==";
-};
-</pre>
-<p>The algorithm, hmac-md5, is the only one supported by <span class="acronym">BIND</span>.
-The secret is the one generated above. Since this is a secret, it
-is recommended that either <code class="filename">named.conf</code> be non-world
-readable, or the key directive be added to a non-world readable
-file that is included by <code class="filename">named.conf</code>.</p>
-<p>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.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2549878"></a>Instructing the Server to Use the Key</h3></div></div></div>
-<p>Since keys are shared between two hosts only, the server must
-be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file
-for <span class="emphasis"><em>host1</em></span>, if the IP address of <span class="emphasis"><em>host2</em></span> is
-10.1.2.3:</p>
-<pre class="programlisting">
-server 10.1.2.3 {
- keys { host1-host2. ;};
-};
-</pre>
-<p>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.</p>
-<p>If <span class="emphasis"><em>host1</em></span> sends a message that is a request
-to that address, the message will be signed with the specified key. <span class="emphasis"><em>host1</em></span> will
-expect any responses to signed messages to be signed with the same
-key.</p>
-<p>A similar statement must be present in <span class="emphasis"><em>host2</em></span>'s
-configuration file (with <span class="emphasis"><em>host1</em></span>'s address) for <span class="emphasis"><em>host2</em></span> to
-sign request messages to <span class="emphasis"><em>host1</em></span>.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2549998"></a>TSIG Key Based Access Control</h3></div></div></div>
-<p><span class="acronym">BIND</span> allows IP addresses and ranges to be specified in ACL
-definitions and
-<span><strong class="command">allow-{ query | transfer | update }</strong></span> directives.
-This has been extended to allow TSIG keys also. The above key would
-be denoted <span><strong class="command">key host1-host2.</strong></span></p>
-<p>An example of an allow-update directive would be:</p>
-<pre class="programlisting">
-allow-update { key host1-host2. ;};
-</pre>
-<p>This allows dynamic updates to succeed only if the request
- was signed by a key named
- "<span><strong class="command">host1-host2.</strong></span>".</p>
-<p>You may want to read about the more
- powerful <span><strong class="command">update-policy</strong></span> statement in <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2550042"></a>Errors</h3></div></div></div>
-<p>The processing of TSIG signed messages can result in
- several errors. If a signed message is sent to a non-TSIG aware
- 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.</p>
-<p>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
- response will be unsigned with the TSIG extended error code set
- to BADSIG. If a TSIG aware server receives a message with a time
- outside of the allowed range, the response will be signed with
- 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.</p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2550056"></a>TKEY</h2></div></div></div>
-<p><span><strong class="command">TKEY</strong></span> is a mechanism for automatically
- generating a shared secret between two hosts. There are several
- "modes" of <span><strong class="command">TKEY</strong></span> that specify how the key is
- generated or assigned. <span class="acronym">BIND</span> 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 <span><strong class="command">TKEY</strong></span> process
- must use signed messages, signed either by TSIG or SIG(0). The
- result of <span><strong class="command">TKEY</strong></span> is a shared secret that can be
- used to sign messages with TSIG. <span><strong class="command">TKEY</strong></span> can also
- be used to delete shared secrets that it had previously
- generated.</p>
-<p>The <span><strong class="command">TKEY</strong></span> process is initiated by a client
- or server by sending a signed <span><strong class="command">TKEY</strong></span> query
- (including any appropriate KEYs) to a TKEY-aware server. The
- server response, if it indicates success, will contain a
- <span><strong class="command">TKEY</strong></span> record and any appropriate keys. After
- this exchange, both participants have enough information to
- determine the shared secret; the exact process depends on the
- <span><strong class="command">TKEY</strong></span> mode. When using the Diffie-Hellman
- <span><strong class="command">TKEY</strong></span> mode, Diffie-Hellman keys are exchanged,
- and the shared secret is derived by both participants.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2550173"></a>SIG(0)</h2></div></div></div>
-<p><span class="acronym">BIND</span> 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.</p>
-<p>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.</p>
-<p>SIG(0) signing of multiple-message TCP streams is not
- supported.</p>
-<p>The only tool shipped with <span class="acronym">BIND</span> 9 that
- generates SIG(0) signed messages is <span><strong class="command">nsupdate</strong></span>.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="DNSSEC"></a>DNSSEC</h2></div></div></div>
-<p>Cryptographic authentication of DNS information is possible
- through the DNS Security (<span class="emphasis"><em>DNSSEC-bis</em></span>) extensions,
- defined in RFC &lt;TBA&gt;. This section describes the creation and use
- of DNSSEC signed zones.</p>
-<p>In order to set up a DNSSEC secure zone, there are a series
- of steps which must be followed. <span class="acronym">BIND</span> 9 ships
- with several tools
- that are used in this process, which are explained in more detail
- below. In all cases, the <code class="option">-h</code> 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 <code class="option">-h</code> option, and
- that the tools shipped with BIND 9.2.x and earlier are not compatible
- with the current ones.</p>
-<p>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 <code class="literal">DS</code> record at the delegation
- point.</p>
-<p>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.</p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2550308"></a>Generating Keys</h3></div></div></div>
-<p>The <span><strong class="command">dnssec-keygen</strong></span> program is used to
- generate keys.</p>
-<p>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
- <span><strong class="command">ZONE</strong></span>, 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.</p>
-<p>The following command will generate a 768 bit RSASHA1 key for
- the <code class="filename">child.example</code> zone:</p>
-<p><strong class="userinput"><code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</code></strong></p>
-<p>Two output files will be produced:
- <code class="filename">Kchild.example.+005+12345.key</code> and
- <code class="filename">Kchild.example.+005+12345.private</code> (where
- 12345 is an example of a key tag). The key file names contain
- the key name (<code class="filename">child.example.</code>), algorithm (3
- is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case).
- The private key (in the <code class="filename">.private</code> file) is
- used to generate signatures, and the public key (in the
- <code class="filename">.key</code> file) is used for signature
- verification.</p>
-<p>To generate another key with the same properties (but with
- a different key tag), repeat the above command.</p>
-<p>The public keys should be inserted into the zone file by
- including the <code class="filename">.key</code> files using
- <span><strong class="command">$INCLUDE</strong></span> statements.
- </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2550375"></a>Signing the Zone</h3></div></div></div>
-<p>The <span><strong class="command">dnssec-signzone</strong></span> program is used to
- sign a zone.</p>
-<p>Any <code class="filename">keyset</code> files corresponding
- to secure subzones should be present. The zone signer will
- generate <code class="literal">NSEC</code> and <code class="literal">RRSIG</code>
- records for the zone, as well as <code class="literal">DS</code> for
- the child zones if <code class="literal">'-d'</code> is specified.
- If <code class="literal">'-d'</code> is not specified then DS RRsets for
- the secure child zones need to be added manually.</p>
-<p>The following command signs the zone, assuming it is in a
- file called <code class="filename">zone.child.example</code>. By
- default, all zone keys which have an available private key are
- used to generate signatures.</p>
-<p><strong class="userinput"><code>dnssec-signzone -o child.example zone.child.example</code></strong></p>
-<p>One output file is produced:
- <code class="filename">zone.child.example.signed</code>. This file
- should be referenced by <code class="filename">named.conf</code> as the
- input file for the zone.</p>
-<p><span><strong class="command">dnssec-signzone</strong></span> will also produce a
- keyset and dsset files and optionally a dlvset file. These
- are used to provide the parent zone administators with the
- <code class="literal">DNSKEYs</code> (or their corresponding <code class="literal">DS</code>
- records) that are the secure entry point to the zone.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2550450"></a>Configuring Servers</h3></div></div></div>
-<p>Unlike <span class="acronym">BIND</span> 8,
-<span class="acronym">BIND</span> 9 does not verify signatures on load,
-so zone keys for authoritative zones do not need to be specified
-in the configuration file.</p>
-<p>The public key for any security root must be present in
-the configuration file's <span><strong class="command">trusted-keys</strong></span>
-statement, as described later in this document. </p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2550473"></a>IPv6 Support in <span class="acronym">BIND</span> 9</h2></div></div></div>
-<p><span class="acronym">BIND</span> 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.</p>
-<p>For forward lookups, <span class="acronym">BIND</span> 9 supports only AAAA
- records. The use of A6 records is deprecated by RFC 3363, and the
- support for forward lookups in <span class="acronym">BIND</span> 9 is
- removed accordingly.
- However, authoritative <span class="acronym">BIND</span> 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.</p>
-<p>For IPv6 reverse lookups, <span class="acronym">BIND</span> 9 supports
- the traditional "nibble" format used in the
- <span class="emphasis"><em>ip6.arpa</em></span> domain, as well as the older, deprecated
- <span class="emphasis"><em>ip6.int</em></span> domain.
- <span class="acronym">BIND</span> 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 <span class="acronym">BIND</span> 9 do not understand
- the format any more, and will return an error if given.
- In particular, an authoritative <span class="acronym">BIND</span> 9 name
- server rejects to load a zone file containing binary labels.</p>
-<p>For an overview of the format and structure of IPv6 addresses,
- see <a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (AAAA)">the section called &#8220;IPv6 addresses (AAAA)&#8221;</a>.</p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2550600"></a>Address Lookups Using AAAA Records</h3></div></div></div>
-<p>The AAAA record is a parallel to the IPv4 A record. It
- specifies the entire address in a single record. For
- example,</p>
-<pre class="programlisting">
-$ORIGIN example.com.
-host 3600 IN AAAA 2001:db8::1
-</pre>
-<p>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 <code class="literal">::ffff:192.168.42.1</code> as the
- address.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2550620"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
-<p>When looking up an address in nibble format, the address
- components are simply reversed, just as in IPv4, and
- <code class="literal">ip6.arpa.</code> is appended to the resulting name.
- For example, the following would provide reverse name lookup for
- a host with address
- <code class="literal">2001:db8::1</code>.</p>
-<pre class="programlisting">
-$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.
-</pre>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 3. Name Server Configuration </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch05.html b/contrib/bind9/doc/arm/Bv9ARM.ch05.html
deleted file mode 100644
index 1720660b65ab1..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch05.html
+++ /dev/null
@@ -1,115 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch05.html,v 1.24.2.5.2.12 2005/10/13 02:34:00 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 5. The BIND 9 Lightweight Resolver</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
-<link rel="next" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch05"></a>Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2550652">The Lightweight Resolver Library</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2550652"></a>The Lightweight Resolver Library</h2></div></div></div>
-<p>Traditionally applications have been linked with a stub resolver
-library that sends recursive DNS queries to a local caching name
-server.</p>
-<p>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.</p>
-<p>Instead, <span class="acronym">BIND</span> 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.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="lwresd"></a>Running a Resolver Daemon</h2></div></div></div>
-<p>To use the lightweight resolver interface, the system must
-run the resolver daemon <span><strong class="command">lwresd</strong></span> or a local
-name server configured with a <span><strong class="command">lwres</strong></span> statement.</p>
-<p>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 <span><strong class="command">lwserver</strong></span> lines in
-<code class="filename">/etc/resolv.conf</code>.</p>
-<p>The daemon currently only looks in the DNS, but in the future
-it may use other sources such as <code class="filename">/etc/hosts</code>,
-NIS, etc.</p>
-<p>The <span><strong class="command">lwresd</strong></span> 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
-<span><strong class="command">nameserver</strong></span> lines in <code class="filename">/etc/resolv.conf</code>
-as forwarders, but is also capable of doing the resolution autonomously if
-none are specified.</p>
-<p>The <span><strong class="command">lwresd</strong></span> daemon may also be configured with a
-<code class="filename">named.conf</code> style configuration file, in
-<code class="filename">/etc/lwresd.conf</code> by default. A name server may also
-be configured to act as a lightweight resolver daemon using the
-<span><strong class="command">lwres</strong></span> statement in <code class="filename">named.conf</code>.</p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 4. Advanced DNS Features </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch06.html b/contrib/bind9/doc/arm/Bv9ARM.ch06.html
deleted file mode 100644
index 4b5300069d1c4..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch06.html
+++ /dev/null
@@ -1,3864 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch06.html,v 1.56.2.12.2.30 2005/10/13 02:34:00 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 6. BIND 9 Configuration Reference</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
-<link rel="next" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch06"></a>Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2551817">Comment Syntax</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552302"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
-Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552471"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552808"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552823"><span><strong class="command">include</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552845"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552867"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553006"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553269"><span><strong class="command">logging</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554474"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554547"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554610"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554653"><span><strong class="command">masters</strong></span> Statement Definition and Usage </a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554668"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562233"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562281"><span><strong class="command">trusted-keys</strong></span> Statement Definition
-and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562349"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
-Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2563022"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2564557">Zone File</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2565990">Discussion of MX Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566487">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566593">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566761"><span class="acronym">BIND</span> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<p><span class="acronym">BIND</span> 9 configuration is broadly similar
-to <span class="acronym">BIND</span> 8; however, there are a few new areas
-of configuration, such as views. <span class="acronym">BIND</span>
-8 configuration files should work with few alterations in <span class="acronym">BIND</span>
-9, although more complex configurations should be reviewed to check
-if they can be more efficiently implemented using the new features
-found in <span class="acronym">BIND</span> 9.</p>
-<p><span class="acronym">BIND</span> 4 configuration files can be converted to the new format
-using the shell script
-<code class="filename">contrib/named-bootconf/named-bootconf.sh</code>.</p>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="configuration_file_elements"></a>Configuration File Elements</h2></div></div></div>
-<p>Following is a list of elements used throughout the <span class="acronym">BIND</span> configuration
-file documentation:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><code class="varname">acl_name</code></p></td>
-<td><p>The name of an <code class="varname">address_match_list</code> as
-defined by the <span><strong class="command">acl</strong></span> statement.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">address_match_list</code></p></td>
-<td><p>A list of one or more <code class="varname">ip_addr</code>,
-<code class="varname">ip_prefix</code>, <code class="varname">key_id</code>,
-or <code class="varname">acl_name</code> elements, see
-<a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called &#8220;Address Match Lists&#8221;</a>.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">domain_name</code></p></td>
-<td><p>A quoted string which will be used as
-a DNS name, for example "<code class="literal">my.test.domain</code>".</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">dotted_decimal</code></p></td>
-<td><p>One to four integers valued 0 through
-255 separated by dots (`.'), such as <span><strong class="command">123</strong></span>,
-<span><strong class="command">45.67</strong></span> or <span><strong class="command">89.123.45.67</strong></span>.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">ip4_addr</code></p></td>
-<td><p>An IPv4 address with exactly four elements
-in <code class="varname">dotted_decimal</code> notation.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">ip6_addr</code></p></td>
-<td><p>An IPv6 address, such as <span><strong class="command">2001:db8::1234</strong></span>.
-IPv6 scoped addresses that have ambiguity on their scope zones must be
-disambiguated by an appropriate zone ID with the percent character
-(`%') as delimiter.
-It is strongly recommended to use string zone names rather than
-numeric identifiers, in order to be robust against system
-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 <span><strong class="command">fe80::1</strong></span> on the
-link attached to the interface <span><strong class="command">ne0</strong></span>
-can be specified as <span><strong class="command">fe80::1%ne0</strong></span>.
-Note that on most systems link-local addresses always have the
-ambiguity, and need to be disambiguated.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">ip_addr</code></p></td>
-<td><p>An <code class="varname">ip4_addr</code> or <code class="varname">ip6_addr</code>.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">ip_port</code></p></td>
-<td><p>An IP port <code class="varname">number</code>.
-<code class="varname">number</code> 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.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">ip_prefix</code></p></td>
-<td><p>An IP network specified as an <code class="varname">ip_addr</code>,
-followed by a slash (`/') and then the number of bits in the netmask.
-Trailing zeros in a <code class="varname">ip_addr</code> may omitted.
-For example, <span><strong class="command">127/8</strong></span> is the network <span><strong class="command">127.0.0.0</strong></span> with
-netmask <span><strong class="command">255.0.0.0</strong></span> and <span><strong class="command">1.2.3.0/28</strong></span> is
-network <span><strong class="command">1.2.3.0</strong></span> with netmask <span><strong class="command">255.255.255.240</strong></span>.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">key_id</code></p></td>
-<td><p>A <code class="varname">domain_name</code> representing
-the name of a shared key, to be used for transaction security.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">key_list</code></p></td>
-<td><p>A list of one or more <code class="varname">key_id</code>s,
-separated by semicolons and ending with a semicolon.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">number</code></p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">path_name</code></p></td>
-<td><p>A quoted string which will be used as
-a pathname, such as <code class="filename">zones/master/my.test.domain</code>.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">size_spec</code></p></td>
-<td>
-<p>A number, the word <strong class="userinput"><code>unlimited</code></strong>,
-or the word <strong class="userinput"><code>default</code></strong>.</p>
-<p>
-An <code class="varname">unlimited</code> <code class="varname">size_spec</code> requests unlimited
-use, or the maximum available amount. A <code class="varname">default size_spec</code> uses
-the limit that was in force when the server was started.</p>
-<p>A <code class="varname">number</code> can
-optionally be followed by a scaling factor: <strong class="userinput"><code>K</code></strong> or <strong class="userinput"><code>k</code></strong> for
-kilobytes, <strong class="userinput"><code>M</code></strong> or <strong class="userinput"><code>m</code></strong> for
-megabytes, and <strong class="userinput"><code>G</code></strong> or <strong class="userinput"><code>g</code></strong> for gigabytes,
-which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.</p>
-<p>The value must be representable as a 64-bit unsigned integer
-(0 to 18446744073709551615, inclusive).
-Using <code class="varname">unlimited</code> is the best way
-to safely set a really large number.</p>
-</td>
-</tr>
-<tr>
-<td><p><code class="varname">yes_or_no</code></p></td>
-<td><p>Either <strong class="userinput"><code>yes</code></strong> or <strong class="userinput"><code>no</code></strong>.
-The words <strong class="userinput"><code>true</code></strong> and <strong class="userinput"><code>false</code></strong> are
-also accepted, as are the numbers <strong class="userinput"><code>1</code></strong> and <strong class="userinput"><code>0</code></strong>.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">dialup_option</code></p></td>
-<td><p>One of <strong class="userinput"><code>yes</code></strong>,
-<strong class="userinput"><code>no</code></strong>, <strong class="userinput"><code>notify</code></strong>,
-<strong class="userinput"><code>notify-passive</code></strong>, <strong class="userinput"><code>refresh</code></strong> or
-<strong class="userinput"><code>passive</code></strong>.
-When used in a zone, <strong class="userinput"><code>notify-passive</code></strong>,
-<strong class="userinput"><code>refresh</code></strong>, and <strong class="userinput"><code>passive</code></strong>
-are restricted to slave and stub zones.</p></td>
-</tr>
-</tbody>
-</table></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="address_match_lists"></a>Address Match Lists</h3></div></div></div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2551560"></a>Syntax</h4></div></div></div>
-<pre class="programlisting"><code class="varname">address_match_list</code> = address_match_list_element ;
- [<span class="optional"> address_match_list_element; ... </span>]
-<code class="varname">address_match_list_element</code> = [<span class="optional"> ! </span>] (ip_address [<span class="optional">/length</span>] |
- key key_id | acl_name | { address_match_list } )
-</pre>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2551587"></a>Definition and Usage</h4></div></div></div>
-<p>Address match lists are primarily used to determine access
-control for various server operations. They are also used in
-the <span><strong class="command">listen-on</strong></span> and <span><strong class="command">sortlist</strong></span>
-statements. The elements
-which constitute an address match list can be any of the following:</p>
-<div class="itemizedlist"><ul type="disc">
-<li>an IP address (IPv4 or IPv6)</li>
-<li>an IP prefix (in `/' notation)</li>
-<li>a key ID, as defined by the <span><strong class="command">key</strong></span> statement</li>
-<li>the name of an address match list defined with
-the <span><strong class="command">acl</strong></span> statement</li>
-<li>a nested address match list enclosed in braces</li>
-</ul></div>
-<p>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.</p>
-<p>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.</p>
-<p>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.</p>
-<p>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 <span><strong class="command">allow-notify</strong></span>,
-<span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
-<span><strong class="command">allow-update</strong></span>, <span><strong class="command">allow-update-forwarding</strong></span>,
-and <span><strong class="command">blackhole</strong></span> 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.</p>
-<p>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
-<span><strong class="command">1.2.3/24; ! 1.2.3.13;</strong></span> 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 <span><strong class="command">! 1.2.3.13; 1.2.3/24</strong></span> fixes
-that problem by having 1.2.3.13 blocked by the negation but all
-other 1.2.3.* hosts fall through.</p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2551817"></a>Comment Syntax</h3></div></div></div>
-<p>The <span class="acronym">BIND</span> 9 comment syntax allows for comments to appear
-anywhere that white space may appear in a <span class="acronym">BIND</span> configuration
-file. To appeal to programmers of all kinds, they can be written
-in the C, C++, or shell/perl style.</p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2551832"></a>Syntax</h4></div></div></div>
-<pre class="programlisting">/* This is a <span class="acronym">BIND</span> comment as in C */</pre>
-<p>
-</p>
-<pre class="programlisting">// This is a <span class="acronym">BIND</span> comment as in C++</pre>
-<p>
-</p>
-<pre class="programlisting"># This is a <span class="acronym">BIND</span> comment as in common UNIX shells and perl</pre>
-<p>
- </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2551861"></a>Definition and Usage</h4></div></div></div>
-<p>Comments may appear anywhere that whitespace may appear in
-a <span class="acronym">BIND</span> configuration file.</p>
-<p>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.</p>
-<p>C-style comments cannot be nested. For example, the following
-is not valid because the entire comment ends with the first */:</p>
-<pre class="programlisting">/* 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. */
-</pre>
-<p>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.</p>
-<p>For example:</p>
-<pre class="programlisting">// This is the start of a comment. The next line
-// is a new comment, even though it is logically
-// part of the previous comment.
-</pre>
-<p>Shell-style (or perl-style, if you prefer) comments start
-with the character <code class="literal">#</code> (number sign) and continue to the end of the
-physical line, as in C++ comments.</p>
-<p>For example:</p>
-<pre class="programlisting"># This is the start of a comment. The next line
-# is a new comment, even though it is logically
-# part of the previous comment.
-</pre>
-<p>
-</p>
-<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Warning</h3>
-<p>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.</p>
-</div>
-</div>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="Configuration_File_Grammar"></a>Configuration File Grammar</h2></div></div></div>
-<p>A <span class="acronym">BIND</span> 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.</p>
-<p>The following statements are supported:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><span><strong class="command">acl</strong></span></p></td>
-<td><p>defines a named IP address
-matching list, for access control and other uses.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">controls</strong></span></p></td>
-<td><p>declares control channels to be used
-by the <span><strong class="command">rndc</strong></span> utility.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">include</strong></span></p></td>
-<td><p>includes a file.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">key</strong></span></p></td>
-<td><p>specifies key information for use in
-authentication and authorization using TSIG.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">logging</strong></span></p></td>
-<td><p>specifies what the server logs, and where
-the log messages are sent.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">lwres</strong></span></p></td>
-<td><p>configures <span><strong class="command">named</strong></span> to
-also act as a light weight resolver daemon (<span><strong class="command">lwresd</strong></span>).</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">masters</strong></span></p></td>
-<td><p>defines a named masters list for
-inclusion in stub and slave zone masters clauses.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">options</strong></span></p></td>
-<td><p>controls global server configuration
-options and sets defaults for other statements.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">server</strong></span></p></td>
-<td><p>sets certain configuration options on
-a per-server basis.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">trusted-keys</strong></span></p></td>
-<td><p>defines trusted DNSSEC keys.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">view</strong></span></p></td>
-<td><p>defines a view.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">zone</strong></span></p></td>
-<td><p>defines a zone.</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>The <span><strong class="command">logging</strong></span> and
- <span><strong class="command">options</strong></span> statements may only occur once per
- configuration.</p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2552302"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting"><span><strong class="command">acl</strong></span> acl-name {
- address_match_list
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="acl"></a><span><strong class="command">acl</strong></span> Statement Definition and
-Usage</h3></div></div></div>
-<p>The <span><strong class="command">acl</strong></span> 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).</p>
-<p>Note that an address match list's name must be defined
- with <span><strong class="command">acl</strong></span> before it can be used elsewhere; no
- forward references are allowed.</p>
-<p>The following ACLs are built-in:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><span><strong class="command">any</strong></span></p></td>
-<td><p>Matches all hosts.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">none</strong></span></p></td>
-<td><p>Matches no hosts.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">localhost</strong></span></p></td>
-<td><p>Matches the IPv4 and IPv6 addresses of all network
-interfaces on the system.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">localnets</strong></span></p></td>
-<td><p>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, <span><strong class="command">localnets</strong></span> only matches the local
-IPv6 addresses, just like <span><strong class="command">localhost</strong></span>.
-</p></td>
-</tr>
-</tbody>
-</table></div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2552471"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting"><span><strong class="command">controls</strong></span> {
- inet ( ip_addr | * ) [<span class="optional"> port ip_port </span>] allow { <em class="replaceable"><code> address_match_list </code></em> }
- keys { <em class="replaceable"><code> key_list </code></em> };
- [<span class="optional"> inet ...; </span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="controls_statement_definition_and_usage"></a><span><strong class="command">controls</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>The <span><strong class="command">controls</strong></span> 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 <span><strong class="command">rndc</strong></span> utility to send commands to
- and retrieve non-DNS results from a name server.</p>
-<p>An <span><strong class="command">inet</strong></span> control channel is a TCP
- socket listening at the specified
- <span><strong class="command">ip_port</strong></span> on the specified
- <span><strong class="command">ip_addr</strong></span>, which can be an IPv4 or IPv6
- address. An <span><strong class="command">ip_addr</strong></span>
- of <code class="literal">*</code> 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 <span><strong class="command">ip_addr</strong></span> of <code class="literal">::</code>.
- If you will only use <span><strong class="command">rndc</strong></span> on the local host,
- using the loopback address (<code class="literal">127.0.0.1</code>
- or <code class="literal">::1</code>) is recommended for maximum
- security.
- </p>
-<p>
- If no port is specified, port 953
- is used. "<code class="literal">*</code>" cannot be used for
- <span><strong class="command">ip_port</strong></span>.</p>
-<p>The ability to issue commands over the control channel is
- restricted by the <span><strong class="command">allow</strong></span> and
- <span><strong class="command">keys</strong></span> clauses. Connections to the control
- channel are permitted based on the
- <span><strong class="command">address_match_list</strong></span>. This is for simple
- IP address based filtering only; any <span><strong class="command">key_id</strong></span>
- elements of the <span><strong class="command">address_match_list</strong></span> are
- ignored.
- </p>
-<p>The primary authorization mechanism of the command
- channel is the <span><strong class="command">key_list</strong></span>, which contains
- a list of <span><strong class="command">key_id</strong></span>s.
- Each <span><strong class="command">key_id</strong></span> in
- the <span><strong class="command">key_list</strong></span> is authorized to execute
- commands over the control channel.
- See <a href="Bv9ARM.ch03.html#rndc">Remote Name Daemon Control application</a> in
- <a href="Bv9ARM.ch03.html#admin_tools" title="Administrative Tools">the section called &#8220;Administrative Tools&#8221;</a>) for information about
- configuring keys in <span><strong class="command">rndc</strong></span>.</p>
-<p>
-If no <span><strong class="command">controls</strong></span> statement is present,
-<span><strong class="command">named</strong></span> 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 <span><strong class="command">controls</strong></span> statement
-is present but does not have a <span><strong class="command">keys</strong></span> clause,
-<span><strong class="command">named</strong></span> will attempt to load the command channel key
-from the file <code class="filename">rndc.key</code> in
-<code class="filename">/etc</code> (or whatever <code class="varname">sysconfdir</code>
-was specified as when <span class="acronym">BIND</span> was built).
-To create a <code class="filename">rndc.key</code> file, run
-<strong class="userinput"><code>rndc-confgen -a</code></strong>.
-</p>
-<p>The <code class="filename">rndc.key</code> feature was created to
- ease the transition of systems from <span class="acronym">BIND</span> 8,
- which did not have digital signatures on its command channel messages
- and thus did not have a <span><strong class="command">keys</strong></span> clause.
-
-It makes it possible to use an existing <span class="acronym">BIND</span> 8
-configuration file in <span class="acronym">BIND</span> 9 unchanged,
-and still have <span><strong class="command">rndc</strong></span> work the same way
-<span><strong class="command">ndc</strong></span> worked in BIND 8, simply by executing the
-command <strong class="userinput"><code>rndc-confgen -a</code></strong> after BIND 9 is
-installed.
-</p>
-<p>
- Since the <code class="filename">rndc.key</code> feature
- is only intended to allow the backward-compatible usage of
- <span class="acronym">BIND</span> 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
- <code class="filename">rndc.conf</code> with your own key if you wish to change
- those things. The <code class="filename">rndc.key</code> file also has its
- permissions set such that only the owner of the file (the user that
- <span><strong class="command">named</strong></span> is running as) can access it. If you
- desire greater flexibility in allowing other users to access
- <span><strong class="command">rndc</strong></span> commands then you need to create an
- <code class="filename">rndc.conf</code> and make it group readable by a group
- that contains the users who should have access.</p>
-<p>The UNIX control channel type of <span class="acronym">BIND</span> 8 is not supported
- in <span class="acronym">BIND</span> 9, and is not expected to be added in future
- releases. If it is present in the controls statement from a
- <span class="acronym">BIND</span> 8 configuration file, it is ignored
- and a warning is logged.</p>
-<p>
-To disable the command channel, use an empty <span><strong class="command">controls</strong></span>
-statement: <span><strong class="command">controls { };</strong></span>.
-</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2552808"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">include <em class="replaceable"><code>filename</code></em>;</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2552823"></a><span><strong class="command">include</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>The <span><strong class="command">include</strong></span> statement inserts the
- specified file at the point where the <span><strong class="command">include</strong></span>
- statement is encountered. The <span><strong class="command">include</strong></span>
- 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.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2552845"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">key <em class="replaceable"><code>key_id</code></em> {
- algorithm <em class="replaceable"><code>string</code></em>;
- secret <em class="replaceable"><code>string</code></em>;
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2552867"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>The <span><strong class="command">key</strong></span> statement defines a shared
-secret key for use with TSIG (see <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
-or the command channel
-(see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and Usage&#8221;</a>).
-</p>
-<p>
-The <span><strong class="command">key</strong></span> statement can occur at the top level
-of the configuration file or inside a <span><strong class="command">view</strong></span>
-statement. Keys defined in top-level <span><strong class="command">key</strong></span>
-statements can be used in all views. Keys intended for use in
-a <span><strong class="command">controls</strong></span> statement
-(see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and Usage&#8221;</a>)
-must be defined at the top level.
-</p>
-<p>The <em class="replaceable"><code>key_id</code></em>, also known as the
-key name, is a domain name uniquely identifying the key. It can
-be used in a <span><strong class="command">server</strong></span>
-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.</p>
-<p>The <em class="replaceable"><code>algorithm_id</code></em> is a string
-that specifies a security/authentication algorithm. The only
-algorithm currently supported with TSIG authentication is
-<code class="literal">hmac-md5</code>. The
-<em class="replaceable"><code>secret_string</code></em> is the secret to be
-used by the algorithm, and is treated as a base-64 encoded
-string.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2553006"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting"><span><strong class="command">logging</strong></span> {
- [ <span><strong class="command">channel</strong></span> <em class="replaceable"><code>channel_name</code></em> {
- ( <span><strong class="command">file</strong></span> <em class="replaceable"><code>path name</code></em>
- [ <span><strong class="command">versions</strong></span> ( <em class="replaceable"><code>number</code></em> | <code class="literal">unlimited</code> ) ]
- [ <span><strong class="command">size</strong></span> <em class="replaceable"><code>size spec</code></em> ]
- | <span><strong class="command">syslog</strong></span> <em class="replaceable"><code>syslog_facility</code></em>
- | <span><strong class="command">stderr</strong></span>
- | <span><strong class="command">null</strong></span> );
- [ <span><strong class="command">severity</strong></span> (<code class="option">critical</code> | <code class="option">error</code> | <code class="option">warning</code> | <code class="option">notice</code> |
- <code class="option">info</code> | <code class="option">debug</code> [ <em class="replaceable"><code>level</code></em> ] | <code class="option">dynamic</code> ); ]
- [ <span><strong class="command">print-category</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
- [ <span><strong class="command">print-severity</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
- [ <span><strong class="command">print-time</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
- }; ]
- [ <span><strong class="command">category</strong></span> <em class="replaceable"><code>category_name</code></em> {
- <em class="replaceable"><code>channel_name</code></em> ; [ <em class="replaceable"><code>channel_nam</code></em>e ; ... ]
- }; ]
- ...
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2553269"></a><span><strong class="command">logging</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>The <span><strong class="command">logging</strong></span> statement configures a wide
-variety of logging options for the name server. Its <span><strong class="command">channel</strong></span> phrase
-associates output methods, format options and severity levels with
-a name that can then be used with the <span><strong class="command">category</strong></span> phrase
-to select how various classes of messages are logged.</p>
-<p>Only one <span><strong class="command">logging</strong></span> statement is used to define
-as many channels and categories as are wanted. If there is no <span><strong class="command">logging</strong></span> statement,
-the logging configuration will be:</p>
-<pre class="programlisting">logging {
- category default { default_syslog; default_debug; };
- category unmatched { null; };
-};
-</pre>
-<p>In <span class="acronym">BIND</span> 9, the logging configuration is only established when
-the entire configuration file has been parsed. In <span class="acronym">BIND</span> 8, it was
-established as soon as the <span><strong class="command">logging</strong></span> 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 "<code class="option">-g</code>" option
-was specified.</p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2553321"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
-<p>All log output goes to one or more <span class="emphasis"><em>channels</em></span>;
-you can make as many of them as you want.</p>
-<p>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
-<span><strong class="command">info</strong></span>), and whether to include a
-<span><strong class="command">named</strong></span>-generated time stamp, the category name
-and/or severity level (the default is not to include any).</p>
-<p>The <span><strong class="command">null</strong></span> destination clause
-causes all messages sent to the channel to be discarded;
-in that case, other options for the channel are meaningless.</p>
-<p>The <span><strong class="command">file</strong></span> 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.</p>
-<p>If you use the <span><strong class="command">versions</strong></span> log file option, then
-<span><strong class="command">named</strong></span> 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 <code class="filename">lamers.log</code> then just before it is opened
-<code class="filename">lamers.log.1</code> is renamed to
-<code class="filename">lamers.log.2</code>, <code class="filename">lamers.log.0</code> is renamed
-to <code class="filename">lamers.log.1</code>, and <code class="filename">lamers.log</code> is
-renamed to <code class="filename">lamers.log.0</code>.
-You can say <span><strong class="command">versions unlimited</strong></span> to not limit
-the number of versions.
-If a <span><strong class="command">size</strong></span> 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.</p>
-<p>The <span><strong class="command">size</strong></span> option for files is used to limit log
-growth. If the file ever exceeds the size, then <span><strong class="command">named</strong></span> will
-stop writing to the file unless it has a <span><strong class="command">versions</strong></span> 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
-<span><strong class="command">versions</strong></span> 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.</p>
-<p>Example usage of the <span><strong class="command">size</strong></span> and
-<span><strong class="command">versions</strong></span> options:</p>
-<pre class="programlisting">channel an_example_channel {
- file "example.log" versions 3 size 20m;
- print-time yes;
- print-category yes;
-};
-</pre>
-<p>The <span><strong class="command">syslog</strong></span> destination clause directs the
-channel to the system log. Its argument is a
-syslog facility as described in the <span><strong class="command">syslog</strong></span> man
-page. Known facilities are <span><strong class="command">kern</strong></span>, <span><strong class="command">user</strong></span>,
-<span><strong class="command">mail</strong></span>, <span><strong class="command">daemon</strong></span>, <span><strong class="command">auth</strong></span>,
-<span><strong class="command">syslog</strong></span>, <span><strong class="command">lpr</strong></span>, <span><strong class="command">news</strong></span>,
-<span><strong class="command">uucp</strong></span>, <span><strong class="command">cron</strong></span>, <span><strong class="command">authpriv</strong></span>,
-<span><strong class="command">ftp</strong></span>, <span><strong class="command">local0</strong></span>, <span><strong class="command">local1</strong></span>,
-<span><strong class="command">local2</strong></span>, <span><strong class="command">local3</strong></span>, <span><strong class="command">local4</strong></span>,
-<span><strong class="command">local5</strong></span>, <span><strong class="command">local6</strong></span> and
-<span><strong class="command">local7</strong></span>, however not all facilities are supported on
-all operating systems.
-How <span><strong class="command">syslog</strong></span> will handle messages sent to
-this facility is described in the <span><strong class="command">syslog.conf</strong></span> man
-page. If you have a system which uses a very old version of <span><strong class="command">syslog</strong></span> that
-only uses two arguments to the <span><strong class="command">openlog()</strong></span> function,
-then this clause is silently ignored.</p>
-<p>The <span><strong class="command">severity</strong></span> clause works like <span><strong class="command">syslog</strong></span>'s
-"priorities", except that they can also be used if you are writing
-straight to a file rather than using <span><strong class="command">syslog</strong></span>.
-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.</p>
-<p>If you are using <span><strong class="command">syslog</strong></span>, then the <span><strong class="command">syslog.conf</strong></span> priorities
-will also determine what eventually passes through. For example,
-defining a channel facility and severity as <span><strong class="command">daemon</strong></span> and <span><strong class="command">debug</strong></span> but
-only logging <span><strong class="command">daemon.warning</strong></span> via <span><strong class="command">syslog.conf</strong></span> will
-cause messages of severity <span><strong class="command">info</strong></span> and <span><strong class="command">notice</strong></span> to
-be dropped. If the situation were reversed, with <span><strong class="command">named</strong></span> writing
-messages of only <span><strong class="command">warning</strong></span> or higher, then <span><strong class="command">syslogd</strong></span> would
-print all messages it received from the channel.</p>
-<p>The <span><strong class="command">stderr</strong></span> 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.</p>
-<p>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 <span><strong class="command">named</strong></span> server
-with the <code class="option">-d</code> flag followed by a positive integer,
-or by running <span><strong class="command">rndc trace</strong></span>.
-The global debug level
-can be set to zero, and debugging mode turned off, by running <span><strong class="command">ndc
-notrace</strong></span>. 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:</p>
-<pre class="programlisting">channel specific_debug_level {
- file "foo";
- severity debug 3;
-};
-</pre>
-<p>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 <span><strong class="command">dynamic</strong></span> severity use the
-server's global debug level to determine what messages to print.</p>
-<p>If <span><strong class="command">print-time</strong></span> has been turned on, then
-the date and time will be logged. <span><strong class="command">print-time</strong></span> may
-be specified for a <span><strong class="command">syslog</strong></span> channel, but is usually
-pointless since <span><strong class="command">syslog</strong></span> also prints the date and
-time. If <span><strong class="command">print-category</strong></span> is requested, then the
-category of the message will be logged as well. Finally, if <span><strong class="command">print-severity</strong></span> is
-on, then the severity level of the message will be logged. The <span><strong class="command">print-</strong></span> 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 <span><strong class="command">print-</strong></span> options
-are on:</p>
-<p><code class="computeroutput">28-Feb-2000 15:05:32.863 general: notice: running</code></p>
-<p>There are four predefined channels that are used for
-<span><strong class="command">named</strong></span>'s default logging as follows. How they are
-used is described in <a href="Bv9ARM.ch06.html#the_category_phrase" title="The category Phrase">the section called &#8220;The <span><strong class="command">category</strong></span> Phrase&#8221;</a>.
-</p>
-<pre class="programlisting">channel default_syslog {
- syslog daemon; // send to syslog's daemon
- // facility
- severity info; // only send priority info
- // and higher
-};
-
-channel default_debug {
- file "named.run"; // write to named.run in
- // the working directory
- // Note: stderr is used instead
- // of "named.run"
- // if the server is started
- // with the '-f' option.
- severity dynamic; // log at the server's
- // current debug level
-};
-
-channel default_stderr {
- stderr; // writes to stderr
- severity info; // only send priority info
- // and higher
-};
-
-channel null {
- null; // toss anything sent to
- // this channel
-};
-</pre>
-<p>The <span><strong class="command">default_debug</strong></span> channel has the special
-property that it only produces output when the server's debug level is
-nonzero. It normally writes to a file <code class="filename">named.run</code>
-in the server's working directory.</p>
-<p>For security reasons, when the "<code class="option">-u</code>"
-command line option is used, the <code class="filename">named.run</code> file
-is created only after <span><strong class="command">named</strong></span> has changed to the
-new UID, and any debug output generated while <span><strong class="command">named</strong></span> is
-starting up and still running as root is discarded. If you need
-to capture this output, you must run the server with the "<code class="option">-g</code>"
-option and redirect standard error to a file.</p>
-<p>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.</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="the_category_phrase"></a>The <span><strong class="command">category</strong></span> Phrase</h4></div></div></div>
-<p>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 <span><strong class="command">default</strong></span> category
-instead. If you don't specify a default category, the following
-"default default" is used:</p>
-<pre class="programlisting">category default { default_syslog; default_debug; };
-</pre>
-<p>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:</p>
-<pre class="programlisting">channel my_security_channel {
- file "my_security_file";
- severity info;
-};
-category security {
- my_security_channel;
- default_syslog;
- default_debug;
-};</pre>
-<p>To discard all messages in a category, specify the <span><strong class="command">null</strong></span> channel:</p>
-<pre class="programlisting">category xfer-out { null; };
-category notify { null; };
-</pre>
-<p>Following are the available categories and brief descriptions
-of the types of log information they contain. More
-categories may be added in future <span class="acronym">BIND</span> releases.</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><span><strong class="command">default</strong></span></p></td>
-<td><p>The default category defines the logging
-options for those categories where no specific configuration has been
-defined.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">general</strong></span></p></td>
-<td><p>The catch-all. Many things still aren't
-classified into categories, and they all end up here.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">database</strong></span></p></td>
-<td><p>Messages relating to the databases used
-internally by the name server to store zone and cache data.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">security</strong></span></p></td>
-<td><p>Approval and denial of requests.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">config</strong></span></p></td>
-<td><p>Configuration file parsing and processing.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">resolver</strong></span></p></td>
-<td><p>DNS resolution, such as the recursive
-lookups performed on behalf of clients by a caching name server.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">xfer-in</strong></span></p></td>
-<td><p>Zone transfers the server is receiving.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">xfer-out</strong></span></p></td>
-<td><p>Zone transfers the server is sending.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">notify</strong></span></p></td>
-<td><p>The NOTIFY protocol.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">client</strong></span></p></td>
-<td><p>Processing of client requests.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">unmatched</strong></span></p></td>
-<td><p>Messages that named was unable to determine the
-class of or for which there was no matching <span><strong class="command">view</strong></span>.
-A one line summary is also logged to the <span><strong class="command">client</strong></span> category.
-This category is best sent to a file or stderr, by default it is sent to
-the <span><strong class="command">null</strong></span> channel.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">network</strong></span></p></td>
-<td><p>Network operations.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">update</strong></span></p></td>
-<td><p>Dynamic updates.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">update-security</strong></span></p></td>
-<td><p>Approval and denial of update requests.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">queries</strong></span></p></td>
-<td>
-<p>Specify where queries should be logged to.</p>
-<p>
-At startup, specifing the category <span><strong class="command">queries</strong></span> will also
-enable query logging unless <span><strong class="command">querylog</strong></span> option has been
-specified.
-</p>
-<p>
-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).</p>
-<p><code class="computeroutput">client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</code>
-</p>
-<p><code class="computeroutput">client ::1#62537: query: www.example.net IN AAAA -SE</code>
-</p>
-</td>
-</tr>
-<tr>
-<td><p><span><strong class="command">dispatch</strong></span></p></td>
-<td><p>Dispatching of incoming packets to the
-server modules where they are to be processed.
-</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">dnssec</strong></span></p></td>
-<td><p>DNSSEC and TSIG protocol processing.
-</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">lame-servers</strong></span></p></td>
-<td><p>Lame servers. These are misconfigurations
-in remote servers, discovered by BIND 9 when trying to query
-those servers during resolution.
-</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">delegation-only</strong></span></p></td>
-<td><p>Delegation only. Logs queries that have have
-been forced to NXDOMAIN as the result of a delegation-only zone or
-a <span><strong class="command">delegation-only</strong></span> in a hint or stub zone declaration.
-</p></td>
-</tr>
-</tbody>
-</table></div>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2554474"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
-<p> This is the grammar of the <span><strong class="command">lwres</strong></span>
-statement in the <code class="filename">named.conf</code> file:</p>
-<pre class="programlisting"><span><strong class="command">lwres</strong></span> {
- [<span class="optional"> listen-on { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
- [<span class="optional"> view <em class="replaceable"><code>view_name</code></em>; </span>]
- [<span class="optional"> search { <em class="replaceable"><code>domain_name</code></em> ; [<span class="optional"> <em class="replaceable"><code>domain_name</code></em> ; ... </span>] }; </span>]
- [<span class="optional"> ndots <em class="replaceable"><code>number</code></em>; </span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2554547"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>The <span><strong class="command">lwres</strong></span> statement configures the name
-server to also act as a lightweight resolver server, see
-<a href="Bv9ARM.ch05.html#lwresd" title="Running a Resolver Daemon">the section called &#8220;Running a Resolver Daemon&#8221;</a>. There may be be multiple
-<span><strong class="command">lwres</strong></span> statements configuring
-lightweight resolver servers with different properties.</p>
-<p>The <span><strong class="command">listen-on</strong></span> 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.</p>
-<p>The <span><strong class="command">view</strong></span> 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.</p>
-<p>The <span><strong class="command">search</strong></span> statement is equivalent to the
-<span><strong class="command">search</strong></span> statement in
-<code class="filename">/etc/resolv.conf</code>. It provides a list of domains
-which are appended to relative names in queries.</p>
-<p>The <span><strong class="command">ndots</strong></span> statement is equivalent to the
-<span><strong class="command">ndots</strong></span> statement in
-<code class="filename">/etc/resolv.conf</code>. 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.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2554610"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">
-<span><strong class="command">masters</strong></span> <em class="replaceable"><code>name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] } ;
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2554653"></a><span><strong class="command">masters</strong></span> Statement Definition and Usage </h3></div></div></div>
-<p><span><strong class="command">masters</strong></span> lists allow for a common set of masters
-to be easily used by multiple stub and slave zones.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2554668"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
-<p>This is the grammar of the <span><strong class="command">options</strong></span>
-statement in the <code class="filename">named.conf</code> file:</p>
-<pre class="programlisting">options {
- [<span class="optional"> version <em class="replaceable"><code>version_string</code></em>; </span>]
- [<span class="optional"> hostname <em class="replaceable"><code>hostname_string</code></em>; </span>]
- [<span class="optional"> server-id <em class="replaceable"><code>server_id_string</code></em>; </span>]
- [<span class="optional"> directory <em class="replaceable"><code>path_name</code></em>; </span>]
- [<span class="optional"> key-directory <em class="replaceable"><code>path_name</code></em>; </span>]
- [<span class="optional"> named-xfer <em class="replaceable"><code>path_name</code></em>; </span>]
- [<span class="optional"> tkey-domain <em class="replaceable"><code>domainname</code></em>; </span>]
- [<span class="optional"> tkey-dhkey <em class="replaceable"><code>key_name</code></em> <em class="replaceable"><code>key_tag</code></em>; </span>]
- [<span class="optional"> dump-file <em class="replaceable"><code>path_name</code></em>; </span>]
- [<span class="optional"> memstatistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
- [<span class="optional"> pid-file <em class="replaceable"><code>path_name</code></em>; </span>]
- [<span class="optional"> statistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
- [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> auth-nxdomain <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> deallocate-on-exit <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em>; </span>]
- [<span class="optional"> fake-iquery <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> fetch-glue <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> flush-zones-on-shutdown <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> has-old-clients <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> host-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> host-statistics-max <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> minimal-responses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> multiple-cnames <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em>; </span>]
- [<span class="optional"> recursion <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> rfc2308-type1 <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> use-id-pool <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> dnssec-enable <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> dnssec-lookaside <em class="replaceable"><code>domain</code></em> trust-anchor <em class="replaceable"><code>domain</code></em>; </span>]
- [<span class="optional"> dnssec-must-be-secure <em class="replaceable"><code>domain yes_or_no</code></em>; </span>]
- [<span class="optional"> forward ( <em class="replaceable"><code>only</code></em> | <em class="replaceable"><code>first</code></em> ); </span>]
- [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
- [<span class="optional"> dual-stack-servers [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>domain_name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ) ; ... }; </span>]
- [<span class="optional"> check-names ( <em class="replaceable"><code>master</code></em> | <em class="replaceable"><code>slave</code></em> | <em class="replaceable"><code>response</code></em> )( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
- [<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> allow-recursion { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> allow-v6-synthesis { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> blackhole { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> avoid-v4-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
- [<span class="optional"> avoid-v6-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
- [<span class="optional"> listen-on [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> listen-on-v6 [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
- [<span class="optional"> query-source [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
- [<span class="optional"> query-source-v6 [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
- [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> tcp-clients <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> recursive-clients <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> serial-query-rate <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> serial-queries <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> tcp-listen-queue <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em>; </span>]
- [<span class="optional"> transfers-in <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> transfers-out <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> transfers-per-ns <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
- [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> max-journal-size <em class="replaceable"><code>size_spec</code></em>; </span>]
- [<span class="optional"> coresize <em class="replaceable"><code>size_spec</code></em> ; </span>]
- [<span class="optional"> datasize <em class="replaceable"><code>size_spec</code></em> ; </span>]
- [<span class="optional"> files <em class="replaceable"><code>size_spec</code></em> ; </span>]
- [<span class="optional"> stacksize <em class="replaceable"><code>size_spec</code></em> ; </span>]
- [<span class="optional"> cleaning-interval <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> heartbeat-interval <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> interface-interval <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> statistics-interval <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> topology { <em class="replaceable"><code>address_match_list</code></em> }</span>];
- [<span class="optional"> sortlist { <em class="replaceable"><code>address_match_list</code></em> }</span>];
- [<span class="optional"> rrset-order { <em class="replaceable"><code>order_spec</code></em> ; [<span class="optional"> <em class="replaceable"><code>order_spec</code></em> ; ... </span>] </span>] };
- [<span class="optional"> lame-ttl <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> max-ncache-ttl <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> max-cache-ttl <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> min-roots <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> use-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> treat-cr-as-space <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em>; </span>]
- [<span class="optional"> additional-from-auth <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> additional-from-cache <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> random-device <em class="replaceable"><code>path_name</code></em> ; </span>]
- [<span class="optional"> max-cache-size <em class="replaceable"><code>size_spec</code></em> ; </span>]
- [<span class="optional"> match-mapped-addresses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> preferred-glue ( <em class="replaceable"><code>A</code></em> | <em class="replaceable"><code>AAAA</code></em> | <em class="replaceable"><code>NONE</code></em> ); </span>]
- [<span class="optional"> edns-udp-size <em class="replaceable"><code>number</code></em>; </span>]
- [<span class="optional"> root-delegation-only [<span class="optional"> exclude { <em class="replaceable"><code>namelist</code></em> } </span>] ; </span>]
- [<span class="optional"> querylog <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> disable-algorithms <em class="replaceable"><code>domain</code></em> { <em class="replaceable"><code>algorithm</code></em>; [<span class="optional"> <em class="replaceable"><code>algorithm</code></em>; </span>] }; </span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="options"></a><span><strong class="command">options</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>The <span><strong class="command">options</strong></span> statement sets up global options
-to be used by <span class="acronym">BIND</span>. This statement may appear only
-once in a configuration file. If there is no <span><strong class="command">options</strong></span>
-statement, an options block with each option set to its default will
-be used.</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">directory</strong></span></span></dt>
-<dd><p>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. <code class="filename">named.run</code>) is this directory.
-If a directory is not specified, the working directory defaults
-to `<code class="filename">.</code>', the directory from which the server
-was started. The directory specified should be an absolute path.</p></dd>
-<dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
-<dd><p>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.</p></dd>
-<dt><span class="term"><span><strong class="command">named-xfer</strong></span></span></dt>
-<dd><p><span class="emphasis"><em>This option is obsolete.</em></span>
-It was used in <span class="acronym">BIND</span> 8 to
-specify the pathname to the <span><strong class="command">named-xfer</strong></span> program.
-In <span class="acronym">BIND</span> 9, no separate <span><strong class="command">named-xfer</strong></span> program is
-needed; its functionality is built into the name server.</p></dd>
-<dt><span class="term"><span><strong class="command">tkey-domain</strong></span></span></dt>
-<dd><p>The domain appended to the names of all
-shared keys generated with <span><strong class="command">TKEY</strong></span>. When a client
-requests a <span><strong class="command">TKEY</strong></span> exchange, it may or may not specify
-the desired name for the key. If present, the name of the shared
-key will be "<code class="varname">client specified part</code>" +
-"<code class="varname">tkey-domain</code>".
-Otherwise, the name of the shared key will be "<code class="varname">random hex
-digits</code>" + "<code class="varname">tkey-domain</code>". In most cases,
-the <span><strong class="command">domainname</strong></span> should be the server's domain
-name.</p></dd>
-<dt><span class="term"><span><strong class="command">tkey-dhkey</strong></span></span></dt>
-<dd><p>The Diffie-Hellman key used by the server
-to generate shared keys with clients using the Diffie-Hellman mode
-of <span><strong class="command">TKEY</strong></span>. 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.</p></dd>
-<dt><span class="term"><span><strong class="command">dump-file</strong></span></span></dt>
-<dd><p>The pathname of the file the server dumps
-the database to when instructed to do so with
-<span><strong class="command">rndc dumpdb</strong></span>.
-If not specified, the default is <code class="filename">named_dump.db</code>.</p></dd>
-<dt><span class="term"><span><strong class="command">memstatistics-file</strong></span></span></dt>
-<dd><p>The pathname of the file the server writes memory
-usage statistics to on exit. If not specified,
-the default is <code class="filename">named.memstats</code>.</p></dd>
-<dt><span class="term"><span><strong class="command">pid-file</strong></span></span></dt>
-<dd><p>The pathname of the file the server writes its process ID
-in. If not specified, the default is <code class="filename">/var/run/named.pid</code>.
-The pid-file is used by programs that want to send signals to the running
-name server. Specifying <span><strong class="command">pid-file none</strong></span> disables the
-use of a PID file &#8212; no file will be written and any
-existing one will be removed. Note that <span><strong class="command">none</strong></span>
-is a keyword, not a file name, and therefore is not enclosed in
-double quotes.</p></dd>
-<dt><span class="term"><span><strong class="command">statistics-file</strong></span></span></dt>
-<dd><p>The pathname of the file the server appends statistics
-to when instructed to do so using <span><strong class="command">rndc stats</strong></span>.
-If not specified, the default is <code class="filename">named.stats</code> in the
-server's current directory. The format of the file is described
-in <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called &#8220;The Statistics File&#8221;</a></p></dd>
-<dt><span class="term"><span><strong class="command">port</strong></span></span></dt>
-<dd><p>
-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.
-</p></dd>
-<dt><span class="term"><span><strong class="command">random-device</strong></span></span></dt>
-<dd><p>
-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
-<code class="filename">/dev/random</code>
-(or equivalent) when present, and none otherwise. The
-<span><strong class="command">random-device</strong></span> option takes effect during
-the initial configuration load at server startup time and
-is ignored on subsequent reloads.</p></dd>
-<dt><span class="term"><span><strong class="command">preferred-glue</strong></span></span></dt>
-<dd><p>
-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).
-</p></dd>
-<dt><span class="term"><span><strong class="command">root-delegation-only</strong></span></span></dt>
-<dd>
-<p>
-Turn on enforcement of delegation-only in TLDs and root zones with an optional
-exclude list.
-</p>
-<p>
-Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM").
-</p>
-<pre class="programlisting">
-options {
- root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
-};
-</pre>
-</dd>
-<dt><span class="term"><span><strong class="command">disable-algorithms</strong></span></span></dt>
-<dd><p>
-Disable the specified DNSSEC algorithms at and below the specified name.
-Multiple <span><strong class="command">disable-algorithms</strong></span> statements are allowed.
-Only the most specific will be applied.
-</p></dd>
-<dt><span class="term"><span><strong class="command">dnssec-lookaside</strong></span></span></dt>
-<dd><p>
-When set <span><strong class="command">dnssec-lookaside</strong></span> 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 <span><strong class="command">dnssec-lookaside</strong></span>, 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.
-</p></dd>
-<dt><span class="term"><span><strong class="command">dnssec-must-be-secure</strong></span></span></dt>
-<dd><p>
-Specify heirarchies which must / may not be secure (signed and validated).
-If <strong class="userinput"><code>yes</code></strong> then named will only accept answers if they
-are secure.
-If <strong class="userinput"><code>no</code></strong> then normal dnssec validation applies
-allowing for insecure answers to be accepted.
-The specified domain must be under a <span><strong class="command">trusted-key</strong></span> or
-<span><strong class="command">dnssec-lookaside</strong></span> must be active.
-</p></dd>
-</dl></div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="boolean_options"></a>Boolean Options</h4></div></div></div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">auth-nxdomain</strong></span></span></dt>
-<dd><p>If <strong class="userinput"><code>yes</code></strong>, then the <span><strong class="command">AA</strong></span> bit
-is always set on NXDOMAIN responses, even if the server is not actually
-authoritative. The default is <strong class="userinput"><code>no</code></strong>; this is
-a change from <span class="acronym">BIND</span> 8. If you are using very old DNS software, you
-may need to set it to <strong class="userinput"><code>yes</code></strong>.</p></dd>
-<dt><span class="term"><span><strong class="command">deallocate-on-exit</strong></span></span></dt>
-<dd><p>This option was used in <span class="acronym">BIND</span> 8 to enable checking
-for memory leaks on exit. <span class="acronym">BIND</span> 9 ignores the option and always performs
-the checks.</p></dd>
-<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
-<dd>
-<p>If <strong class="userinput"><code>yes</code></strong>, 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 <span><strong class="command">heartbeat-interval</strong></span> and
-hopefully during the one call. It also suppresses some of the normal
-zone maintenance traffic. The default is <strong class="userinput"><code>no</code></strong>.</p>
-<p>The <span><strong class="command">dialup</strong></span> option
-may also be specified in the <span><strong class="command">view</strong></span> and
-<span><strong class="command">zone</strong></span> statements,
-in which case it overrides the global <span><strong class="command">dialup</strong></span>
-option.</p>
-<p>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
-<span><strong class="command">notify</strong></span> and <span><strong class="command">also-notify</strong></span>.</p>
-<p>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
-<span><strong class="command">heartbeat-interval</strong></span> expires in addition to sending
-NOTIFY requests.</p>
-<p>Finer control can be achieved by using
-<strong class="userinput"><code>notify</code></strong> which only sends NOTIFY messages,
-<strong class="userinput"><code>notify-passive</code></strong> which sends NOTIFY messages and
-suppresses the normal refresh queries, <strong class="userinput"><code>refresh</code></strong>
-which suppresses normal refresh processing and sends refresh queries
-when the <span><strong class="command">heartbeat-interval</strong></span> expires, and
-<strong class="userinput"><code>passive</code></strong> which just disables normal refresh
-processing.</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p>dialup mode</p></td>
-<td><p>normal refresh</p></td>
-<td><p>heart-beat refresh</p></td>
-<td><p>heart-beat notify</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">no</strong></span> (default)</p></td>
-<td><p>yes</p></td>
-<td><p>no</p></td>
-<td><p>no</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">yes</strong></span></p></td>
-<td><p>no</p></td>
-<td><p>yes</p></td>
-<td><p>yes</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">notify</strong></span></p></td>
-<td><p>yes</p></td>
-<td><p>no</p></td>
-<td><p>yes</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">refresh</strong></span></p></td>
-<td><p>no</p></td>
-<td><p>yes</p></td>
-<td><p>no</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">passive</strong></span></p></td>
-<td><p>no</p></td>
-<td><p>no</p></td>
-<td><p>no</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">notify-passive</strong></span></p></td>
-<td><p>no</p></td>
-<td><p>no</p></td>
-<td><p>yes</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>Note that normal NOTIFY processing is not affected by
-<span><strong class="command">dialup</strong></span>.</p>
-</dd>
-<dt><span class="term"><span><strong class="command">fake-iquery</strong></span></span></dt>
-<dd><p>In <span class="acronym">BIND</span> 8, this option
-enabled simulating the obsolete DNS query type
-IQUERY. <span class="acronym">BIND</span> 9 never does IQUERY simulation.
-</p></dd>
-<dt><span class="term"><span><strong class="command">fetch-glue</strong></span></span></dt>
-<dd><p>This option is obsolete.
-In BIND 8, <strong class="userinput"><code>fetch-glue yes</code></strong>
-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.</p></dd>
-<dt><span class="term"><span><strong class="command">flush-zones-on-shutdown</strong></span></span></dt>
-<dd><p>When the nameserver exits due receiving SIGTERM,
-flush / do not flush any pending zone writes. The default is
-<span><strong class="command">flush-zones-on-shutdown</strong></span> <strong class="userinput"><code>no</code></strong>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">has-old-clients</strong></span></span></dt>
-<dd><p>This option was incorrectly implemented
-in <span class="acronym">BIND</span> 8, and is ignored by <span class="acronym">BIND</span> 9.
-To achieve the intended effect
-of
-<span><strong class="command">has-old-clients</strong></span> <strong class="userinput"><code>yes</code></strong>, specify
-the two separate options <span><strong class="command">auth-nxdomain</strong></span> <strong class="userinput"><code>yes</code></strong>
-and <span><strong class="command">rfc2308-type1</strong></span> <strong class="userinput"><code>no</code></strong> instead.
-</p></dd>
-<dt><span class="term"><span><strong class="command">host-statistics</strong></span></span></dt>
-<dd><p>In BIND 8, this enables keeping of
-statistics for every host that the name server interacts with.
-Not implemented in BIND 9.
-</p></dd>
-<dt><span class="term"><span><strong class="command">maintain-ixfr-base</strong></span></span></dt>
-<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
- It was used in <span class="acronym">BIND</span> 8 to determine whether a transaction log was
-kept for Incremental Zone Transfer. <span class="acronym">BIND</span> 9 maintains a transaction
-log whenever possible. If you need to disable outgoing incremental zone
-transfers, use <span><strong class="command">provide-ixfr</strong></span> <strong class="userinput"><code>no</code></strong>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">minimal-responses</strong></span></span></dt>
-<dd><p>If <strong class="userinput"><code>yes</code></strong>, 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 <strong class="userinput"><code>no</code></strong>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">multiple-cnames</strong></span></span></dt>
-<dd><p>This option was used in <span class="acronym">BIND</span> 8 to allow
-a domain name to have multiple CNAME records in violation of the
-DNS standards. <span class="acronym">BIND</span> 9.2 always strictly
-enforces the CNAME rules both in master files and dynamic updates.
-</p></dd>
-<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
-<dd>
-<p>If <strong class="userinput"><code>yes</code></strong> (the default),
-DNS NOTIFY messages are sent when a zone the server is authoritative for
-changes, see <a href="Bv9ARM.ch04.html#notify" title="Notify">the section called &#8220;Notify&#8221;</a>. 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
-<span><strong class="command">also-notify</strong></span> option.
-</p>
-<p>
-If <strong class="userinput"><code>explicit</code></strong>, notifies are sent only to
-servers explicitly listed using <span><strong class="command">also-notify</strong></span>.
-If <strong class="userinput"><code>no</code></strong>, no notifies are sent.
-</p>
-<p>
-The <span><strong class="command">notify</strong></span> option may also be
-specified in the <span><strong class="command">zone</strong></span> statement,
-in which case it overrides the <span><strong class="command">options notify</strong></span> statement.
-It would only be necessary to turn off this option if it caused slaves
-to crash.</p>
-</dd>
-<dt><span class="term"><span><strong class="command">recursion</strong></span></span></dt>
-<dd><p>If <strong class="userinput"><code>yes</code></strong>, 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 <strong class="userinput"><code>yes</code></strong>.
-Note that setting <span><strong class="command">recursion no</strong></span> 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 <span><strong class="command">fetch-glue</strong></span> above.
-</p></dd>
-<dt><span class="term"><span><strong class="command">rfc2308-type1</strong></span></span></dt>
-<dd>
-<p>Setting this to <strong class="userinput"><code>yes</code></strong> will
-cause the server to send NS records along with the SOA record for negative
-answers. The default is <strong class="userinput"><code>no</code></strong>.</p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>Not yet implemented in <span class="acronym">BIND</span> 9.</p>
-</div>
-</dd>
-<dt><span class="term"><span><strong class="command">use-id-pool</strong></span></span></dt>
-<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
-<span class="acronym">BIND</span> 9 always allocates query IDs from a pool.
-</p></dd>
-<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
-<dd><p>If <strong class="userinput"><code>yes</code></strong>, the server will collect
-statistical data on all zones (unless specifically turned off
-on a per-zone basis by specifying <span><strong class="command">zone-statistics no</strong></span>
-in the <span><strong class="command">zone</strong></span> statement). These statistics may be accessed
-using <span><strong class="command">rndc stats</strong></span>, which will dump them to the file listed
-in the <span><strong class="command">statistics-file</strong></span>. See also <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called &#8220;The Statistics File&#8221;</a>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">use-ixfr</strong></span></span></dt>
-<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
-If you need to disable IXFR to a particular server or servers see
-the information on the <span><strong class="command">provide-ixfr</strong></span> option
-in <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and Usage&#8221;</a>. See also
-<a href="Bv9ARM.ch04.html#incremental_zone_transfers" title="Incremental Zone Transfers (IXFR)">the section called &#8220;Incremental Zone Transfers (IXFR)&#8221;</a>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">provide-ixfr</strong></span></span></dt>
-<dd><p>
-See the description of
-<span><strong class="command">provide-ixfr</strong></span> in
-<a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and Usage&#8221;</a>
-</p></dd>
-<dt><span class="term"><span><strong class="command">request-ixfr</strong></span></span></dt>
-<dd><p>
-See the description of
-<span><strong class="command">request-ixfr</strong></span> in
-<a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and Usage&#8221;</a>
-</p></dd>
-<dt><span class="term"><span><strong class="command">treat-cr-as-space</strong></span></span></dt>
-<dd><p>This option was used in <span class="acronym">BIND</span> 8 to make
-the server treat carriage return ("<span><strong class="command">\r</strong></span>") 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 <span class="acronym">BIND</span> 9, both UNIX "<span><strong class="command">\n</strong></span>"
-and NT/DOS "<span><strong class="command">\r\n</strong></span>" newlines are always accepted,
-and the option is ignored.</p></dd>
-<dt>
-<span class="term"><span><strong class="command">additional-from-auth</strong></span>, </span><span class="term"><span><strong class="command">additional-from-cache</strong></span></span>
-</dt>
-<dd>
-<p>
-These options control the behavior of an authoritative server when
-answering queries which have additional data, or when following CNAME
-and DNAME chains.
-</p>
-<p>
-When both of these options are set to <strong class="userinput"><code>yes</code></strong>
-(the default) and a
-query is being answered from authoritative data (a zone
-configured into the server), the additional data section of the
-reply will be filled in using data from other authoritative zones
-and from the cache. In some situations this is undesirable, such
-as when there is concern over the correctness of the cache, or
-in servers where slave zones may be added and modified by
-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.
-</p>
-<p>
-For example, if a query asks for an MX record for host <code class="literal">foo.example.com</code>,
-and the record found is "<code class="literal">MX 10 mail.example.net</code>", normally the address
-records (A and AAAA) for <code class="literal">mail.example.net</code> will be provided as well,
-if known, even though they are not in the example.com zone.
-Setting these options to <span><strong class="command">no</strong></span> disables this behavior and makes
-the server only search for additional data in the zone it answers from.
-</p>
-<p>
-These options are intended for use in authoritative-only
-servers, or in authoritative-only views. Attempts to set
-them to <span><strong class="command">no</strong></span> without also specifying
-<span><strong class="command">recursion no</strong></span> will cause the server to
-ignore the options and log a warning message.
-</p>
-<p>
-Specifying <span><strong class="command">additional-from-cache no</strong></span> 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.
-</p>
-<p>
-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 <span><strong class="command">additional-from-cache no</strong></span>
-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.
-</p>
-</dd>
-<dt><span class="term"><span><strong class="command">match-mapped-addresses</strong></span></span></dt>
-<dd><p>If <strong class="userinput"><code>yes</code></strong>, 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
-systems, to work around a kernel quirk that causes IPv4
-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.
-</p></dd>
-<dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt>
-<dd>
-<p>
-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.
-</p>
-<p>
-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
-different from the previous one, the set of differences
-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.
-</p>
-</dd>
-<dt><span class="term"><span><strong class="command">multi-master</strong></span></span></dt>
-<dd><p>
-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 <strong class="userinput"><code>no</code></strong>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">dnssec-enable</strong></span></span></dt>
-<dd><p>
-Enable DNSSEC support in named. Unless set to <strong class="userinput"><code>yes</code></strong>
-named behaves as if it does not support DNSSEC.
-The default is <strong class="userinput"><code>no</code></strong>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">querylog</strong></span></span></dt>
-<dd><p>
-Specify whether query logging should be started when named start.
-If <span><strong class="command">querylog</strong></span> is not specified then the query logging
-is determined by the presence of the logging category <span><strong class="command">queries</strong></span>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
-<dd>
-<p>
-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
-<span><strong class="command">master</strong></span> zones the default is <span><strong class="command">fail</strong></span>.
-For <span><strong class="command">slave</strong></span> zones the default is <span><strong class="command">warn</strong></span>.
-For answer received from the network (<span><strong class="command">response</strong></span>)
-the default is <span><strong class="command">ignore</strong></span>.
-</p>
-<p>The rules for legal hostnames / mail domains are derived from RFC 952
-and RFC 821 as modified by RFC 1123.
-</p>
-<p><span><strong class="command">check-names</strong></span> 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).
-</p>
-</dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2557350"></a>Forwarding</h4></div></div></div>
-<p>The forwarding facility can be used to create a large site-wide
-cache on a few servers, reducing traffic over links to external
-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.</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
-<dd><p>This option is only meaningful if the
-forwarders list is not empty. A value of <code class="varname">first</code>,
-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 <code class="varname">only</code> is specified, the
-server will only query the forwarders.
-</p></dd>
-<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
-<dd><p>Specifies the IP addresses to be used
-for forwarding. The default is the empty list (no forwarding).
-</p></dd>
-</dl></div>
-<p>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 <span><strong class="command">forward only/first</strong></span> behavior,
-or not forward at all, see <a href="Bv9ARM.ch06.html#zone_statement_grammar" title="zone
-Statement Grammar">the section called &#8220;<span><strong class="command">zone</strong></span>
-Statement Grammar&#8221;</a>.</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2557400"></a>Dual-stack Servers</h4></div></div></div>
-<p>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.</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">dual-stack-servers</strong></span></span></dt>
-<dd><p>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 <span><strong class="command">dual-stack-servers</strong></span> have no effect unless
-access to a transport has been disabled on the command line
-(e.g. <span><strong class="command">named -4</strong></span>).</p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="access_control"></a>Access Control</h4></div></div></div>
-<p>Access to the server can be restricted based on the IP address
-of the requesting system. See <a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called &#8220;Address Match Lists&#8221;</a> for
-details on how to specify IP address lists.</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
-<dd><p>Specifies which hosts are allowed to
-notify this server, a slave, of zone changes in addition
-to the zone masters.
-<span><strong class="command">allow-notify</strong></span> may also be specified in the
-<span><strong class="command">zone</strong></span> statement, in which case it overrides the
-<span><strong class="command">options allow-notify</strong></span> 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.</p></dd>
-<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
-<dd><p>Specifies which hosts are allowed to
-ask ordinary DNS questions. <span><strong class="command">allow-query</strong></span> may also
-be specified in the <span><strong class="command">zone</strong></span> statement, in which
-case it overrides the <span><strong class="command">options allow-query</strong></span> statement. If
-not specified, the default is to allow queries from all hosts.</p></dd>
-<dt><span class="term"><span><strong class="command">allow-recursion</strong></span></span></dt>
-<dd><p>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.
-</p></dd>
-<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
-<dd>
-<p>Specifies which hosts are allowed to
-submit Dynamic DNS updates to slave zones to be forwarded to the
-master. The default is <strong class="userinput"><code>{ none; }</code></strong>, which
-means that no update forwarding will be performed. To enable
-update forwarding, specify
-<strong class="userinput"><code>allow-update-forwarding { any; };</code></strong>.
-Specifying values other than <strong class="userinput"><code>{ none; }</code></strong> or
-<strong class="userinput"><code>{ any; }</code></strong> is usually counterproductive, since
-the responsibility for update access control should rest with the
-master server, not the slaves.</p>
-<p>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 <a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called &#8220;Dynamic Update Security&#8221;</a>
-for more details.</p>
-</dd>
-<dt><span class="term"><span><strong class="command">allow-v6-synthesis</strong></span></span></dt>
-<dd><p>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.
-</p></dd>
-<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
-<dd><p>Specifies which hosts are allowed to
-receive zone transfers from the server. <span><strong class="command">allow-transfer</strong></span> may
-also be specified in the <span><strong class="command">zone</strong></span> statement, in which
-case it overrides the <span><strong class="command">options allow-transfer</strong></span> statement.
-If not specified, the default is to allow transfers to all hosts.</p></dd>
-<dt><span class="term"><span><strong class="command">blackhole</strong></span></span></dt>
-<dd><p>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 <strong class="userinput"><code>none</code></strong>.</p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2557716"></a>Interfaces</h4></div></div></div>
-<p>The interfaces and ports that the server will answer queries
-from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes
-an optional port, and an <code class="varname">address_match_list</code>.
-The server will listen on all interfaces allowed by the address
-match list. If a port is not specified, port 53 will be used.</p>
-<p>Multiple <span><strong class="command">listen-on</strong></span> statements are allowed.
-For example,</p>
-<pre class="programlisting">listen-on { 5.6.7.8; };
-listen-on port 1234 { !1.2.3.4; 1.2/16; };
-</pre>
-<p>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.</p>
-<p>If no <span><strong class="command">listen-on</strong></span> is specified, the
-server will listen on port 53 on all interfaces.</p>
-<p>The <span><strong class="command">listen-on-v6</strong></span> option is used to
-specify the interfaces and the ports on which the server will listen
-for incoming queries sent using IPv6.</p>
-<p>When </p>
-<pre class="programlisting">{ any; }</pre>
-<p> is specified
-as the <code class="varname">address_match_list</code> for the
-<span><strong class="command">listen-on-v6</strong></span> 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.</p>
-<p>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.</p>
-<p>Multiple <span><strong class="command">listen-on-v6</strong></span> options can be used.
-For example,</p>
-<pre class="programlisting">listen-on-v6 { any; };
-listen-on-v6 port 1234 { !2001:db8::/32; any; };
-</pre>
-<p>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.)</p>
-<p>To make the server not listen on any IPv6 address, use</p>
-<pre class="programlisting">listen-on-v6 { none; };
-</pre>
-<p>If no <span><strong class="command">listen-on-v6</strong></span> option is specified,
-the server will not listen on any IPv6 address.</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2557804"></a>Query Address</h4></div></div></div>
-<p>If the server doesn't know the answer to a question, it will
-query other name servers. <span><strong class="command">query-source</strong></span> specifies
-the address and port used for such queries. For queries sent over
-IPv6, there is a separate <span><strong class="command">query-source-v6</strong></span> option.
-If <span><strong class="command">address</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
-a wildcard IP address (<span><strong class="command">INADDR_ANY</strong></span>) will be used.
-If <span><strong class="command">port</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
-a random unprivileged port will be used, <span><strong class="command">avoid-v4-udp-ports</strong></span>
-and <span><strong class="command">avoid-v6-udp-ports</strong></span> can be used to prevent named
-from selecting certain ports. The defaults are</p>
-<pre class="programlisting">query-source address * port *;
-query-source-v6 address * port *;
-</pre>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>The address specified in the <span><strong class="command">query-source</strong></span> 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.</p>
-</div>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>See also <span><strong class="command">transfer-source</strong></span> and
-<span><strong class="command">notify-source</strong></span>.</p>
-</div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="zone_transfers"></a>Zone Transfers</h4></div></div></div>
-<p><span class="acronym">BIND</span> 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.</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
-<dd><p>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 <span><strong class="command">also-notify</strong></span> list
-is given in a <span><strong class="command">zone</strong></span> statement, it will override
-the <span><strong class="command">options also-notify</strong></span> statement. When a <span><strong class="command">zone notify</strong></span> statement
-is set to <span><strong class="command">no</strong></span>, the IP addresses in the global <span><strong class="command">also-notify</strong></span> list will
-not be sent NOTIFY messages for that zone. The default is the empty
-list (no global notification list).</p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
-<dd><p>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).</p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
-<dd><p>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).</p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
-<dd><p>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).</p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
-<dd><p>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).</p></dd>
-<dt><span class="term"><span><strong class="command">serial-query-rate</strong></span></span></dt>
-<dd><p>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 <span><strong class="command">serial-query-rate</strong></span> option,
-an integer, is the maximum number of queries sent per second.
-The default is 20.
-</p></dd>
-<dt><span class="term"><span><strong class="command">serial-queries</strong></span></span></dt>
-<dd><p>In BIND 8, the <span><strong class="command">serial-queries</strong></span> 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 <span><strong class="command">serial-queries</strong></span> option.
-Instead, it limits the rate at which the queries are sent
-as defined using the <span><strong class="command">serial-query-rate</strong></span> option.
-</p></dd>
-<dt><span class="term"><span><strong class="command">transfer-format</strong></span></span></dt>
-<dd><p>
-Zone transfers can be sent using two different formats,
-<span><strong class="command">one-answer</strong></span> and <span><strong class="command">many-answers</strong></span>.
-The <span><strong class="command">transfer-format</strong></span> option is used
-on the master server to determine which format it sends.
-<span><strong class="command">one-answer</strong></span> uses one DNS message per
-resource record transferred.
-<span><strong class="command">many-answers</strong></span> packs as many resource records as
-possible into a message. <span><strong class="command">many-answers</strong></span> is more
-efficient, but is only supported by relatively new slave servers,
-such as <span class="acronym">BIND</span> 9, <span class="acronym">BIND</span> 8.x and patched
-versions of <span class="acronym">BIND</span> 4.9.5. The default is
-<span><strong class="command">many-answers</strong></span>. <span><strong class="command">transfer-format</strong></span>
-may be overridden on a per-server basis by using the
-<span><strong class="command">server</strong></span> statement.
-</p></dd>
-<dt><span class="term"><span><strong class="command">transfers-in</strong></span></span></dt>
-<dd><p>The maximum number of inbound zone transfers
-that can be running concurrently. The default value is <code class="literal">10</code>.
-Increasing <span><strong class="command">transfers-in</strong></span> may speed up the convergence
-of slave zones, but it also may increase the load on the local system.</p></dd>
-<dt><span class="term"><span><strong class="command">transfers-out</strong></span></span></dt>
-<dd><p>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 <code class="literal">10</code>.</p></dd>
-<dt><span class="term"><span><strong class="command">transfers-per-ns</strong></span></span></dt>
-<dd><p>The maximum number of inbound zone transfers
-that can be concurrently transferring from a given remote name server.
-The default value is <code class="literal">2</code>. Increasing <span><strong class="command">transfers-per-ns</strong></span> may
-speed up the convergence of slave zones, but it also may increase
-the load on the remote name server. <span><strong class="command">transfers-per-ns</strong></span> may
-be overridden on a per-server basis by using the <span><strong class="command">transfers</strong></span> phrase
-of the <span><strong class="command">server</strong></span> statement.</p></dd>
-<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
-<dd><p><span><strong class="command">transfer-source</strong></span> 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 <span><strong class="command">allow-transfer</strong></span> option for
-the zone being transferred, if one is specified. This statement
-sets the <span><strong class="command">transfer-source</strong></span> for all zones, but can
-be overridden on a per-view or per-zone basis by including a
-<span><strong class="command">transfer-source</strong></span> statement within the
-<span><strong class="command">view</strong></span> or <span><strong class="command">zone</strong></span> block
-in the configuration file.</p></dd>
-<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
-<dd><p>The same as <span><strong class="command">transfer-source</strong></span>,
-except zone transfers are performed using IPv6.</p></dd>
-<dt><span class="term"><span><strong class="command">alt-transfer-source</strong></span></span></dt>
-<dd>
-<p>
- An alternate transfer source if the one listed in
- <span><strong class="command">transfer-source</strong></span> fails and
- <span><strong class="command">use-alt-transfer-source</strong></span> is
- set.
- </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
- If you do not wish the alternate transfer source
- to be used you should set
- <span><strong class="command">use-alt-transfer-source</strong></span>
- appropriately and you should not depend upon
- getting a answer back to the first refresh
- query.
- </div>
-</dd>
-<dt><span class="term"><span><strong class="command">alt-transfer-source-v6</strong></span></span></dt>
-<dd><p>An alternate transfer source if the one listed in
-<span><strong class="command">transfer-source-v6</strong></span> fails and
-<span><strong class="command">use-alt-transfer-source</strong></span> is set.</p></dd>
-<dt><span class="term"><span><strong class="command">use-alt-transfer-source</strong></span></span></dt>
-<dd><p>Use the alternate transfer sources or not. If views are
-specified this defaults to <span><strong class="command">no</strong></span> otherwise it defaults to
-<span><strong class="command">yes</strong></span> (for BIND 8 compatibility).</p></dd>
-<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
-<dd><p><span><strong class="command">notify-source</strong></span> 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 <span><strong class="command">masters</strong></span>
-zone clause or in an <span><strong class="command">allow-notify</strong></span> clause.
-This statement sets the <span><strong class="command">notify-source</strong></span> for all zones,
-but can be overridden on a per-zone / per-view basis by including a
-<span><strong class="command">notify-source</strong></span> statement within the <span><strong class="command">zone</strong></span>
-or <span><strong class="command">view</strong></span> block in the configuration file.</p></dd>
-<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
-<dd><p>Like <span><strong class="command">notify-source</strong></span>,
-but applies to notify messages sent to IPv6 addresses.</p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2558398"></a>Bad UDP Port Lists</h4></div></div></div>
-<p>
-<span><strong class="command">avoid-v4-udp-ports</strong></span> and <span><strong class="command">avoid-v6-udp-ports</strong></span>
-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.
-</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2558414"></a>Operating System Resource Limits</h4></div></div></div>
-<p>The server's usage of many system resources can be limited.
-Scaled values are allowed when specifying resource limits. For
-example, <span><strong class="command">1G</strong></span> can be used instead of
-<span><strong class="command">1073741824</strong></span> to specify a limit of one
-gigabyte. <span><strong class="command">unlimited</strong></span> requests unlimited use, or the
-maximum available amount. <span><strong class="command">default</strong></span> uses the limit
-that was in force when the server was started. See the description of
-<span><strong class="command">size_spec</strong></span> in <a href="Bv9ARM.ch06.html#configuration_file_elements" title="Configuration File Elements">the section called &#8220;Configuration File Elements&#8221;</a>.</p>
-<p>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.</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">coresize</strong></span></span></dt>
-<dd><p>The maximum size of a core dump. The default
-is <code class="literal">default</code>.</p></dd>
-<dt><span class="term"><span><strong class="command">datasize</strong></span></span></dt>
-<dd><p>The maximum amount of data memory the server
-may use. The default is <code class="literal">default</code>.
-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
-the server unable to perform DNS service. Therefore,
-this option is rarely useful as a way of limiting the
-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
-<span><strong class="command">max-cache-size</strong></span> and
-<span><strong class="command">recursive-clients</strong></span>
-options instead.
-</p></dd>
-<dt><span class="term"><span><strong class="command">files</strong></span></span></dt>
-<dd><p>The maximum number of files the server
-may have open concurrently. The default is <code class="literal">unlimited</code>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">stacksize</strong></span></span></dt>
-<dd><p>The maximum amount of stack memory the server
-may use. The default is <code class="literal">default</code>.</p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2558584"></a>Server Resource Limits</h4></div></div></div>
-<p>The following options set limits on the server's
-resource consumption that are enforced internally by the
-server rather than the operating system.</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">max-ixfr-log-size</strong></span></span></dt>
-<dd><p>This option is obsolete; it is accepted
-and ignored for BIND 8 compatibility. The option
-<span><strong class="command">max-journal-size</strong></span> performs a similar
-function in BIND 8.
-</p></dd>
-<dt><span class="term"><span><strong class="command">max-journal-size</strong></span></span></dt>
-<dd><p>Sets a maximum size for each journal file
-(<a href="Bv9ARM.ch04.html#journal" title="The journal file">the section called &#8220;The journal file&#8221;</a>). When the journal file approaches
-the specified size, some of the oldest transactions in the journal
-will be automatically removed. The default is
-<code class="literal">unlimited</code>.</p></dd>
-<dt><span class="term"><span><strong class="command">host-statistics-max</strong></span></span></dt>
-<dd><p>In BIND 8, specifies the maximum number of host statistic
-entries to be kept.
-Not implemented in BIND 9.
-</p></dd>
-<dt><span class="term"><span><strong class="command">recursive-clients</strong></span></span></dt>
-<dd><p>The maximum number of simultaneous recursive lookups
-the server will perform on behalf of clients. The default is
-<code class="literal">1000</code>. Because each recursing client uses a fair
-bit of memory, on the order of 20 kilobytes, the value of the
-<span><strong class="command">recursive-clients</strong></span> option may have to be decreased
-on hosts with limited memory.
-</p></dd>
-<dt><span class="term"><span><strong class="command">tcp-clients</strong></span></span></dt>
-<dd><p>The maximum number of simultaneous client TCP
-connections that the server will accept.
-The default is <code class="literal">100</code>.</p></dd>
-<dt><span class="term"><span><strong class="command">max-cache-size</strong></span></span></dt>
-<dd><p>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 <code class="literal">unlimited</code>, meaning that
-records are purged from the cache only when their TTLs expire.
-</p></dd>
-<dt><span class="term"><span><strong class="command">tcp-listen-queue</strong></span></span></dt>
-<dd><p>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.
-</p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2558765"></a>Periodic Task Intervals</h4></div></div></div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt>
-<dd><p>The server will remove expired resource records
-from the cache every <span><strong class="command">cleaning-interval</strong></span> minutes.
-The default is 60 minutes. The maximum value is 28 days (40320 minutes).
-If set to 0, no periodic cleaning will occur.</p></dd>
-<dt><span class="term"><span><strong class="command">heartbeat-interval</strong></span></span></dt>
-<dd><p>The server will perform zone maintenance tasks
-for all zones marked as <span><strong class="command">dialup</strong></span> 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.</p></dd>
-<dt><span class="term"><span><strong class="command">interface-interval</strong></span></span></dt>
-<dd><p>The server will scan the network interface list
-every <span><strong class="command">interface-interval</strong></span> 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
-<span><strong class="command">listen-on</strong></span> configuration), and will
-stop listening on interfaces that have gone away.</p></dd>
-<dt><span class="term"><span><strong class="command">statistics-interval</strong></span></span></dt>
-<dd>
-<p>Name server statistics will be logged
-every <span><strong class="command">statistics-interval</strong></span> minutes. The default is
-60. The maximum value is 28 days (40320 minutes).
-If set to 0, no statistics will be logged.</p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>Not yet implemented in <span class="acronym">BIND</span>9.</p>
-</div>
-</dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="topology"></a>Topology</h4></div></div></div>
-<p>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 <span><strong class="command">topology</strong></span> statement
-takes an <span><strong class="command">address_match_list</strong></span> 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
-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,</p>
-<pre class="programlisting">topology {
- 10/8;
- !1.2.3/24;
- { 1.2/16; 3/8; };
-};</pre>
-<p>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.</p>
-<p>The default topology is</p>
-<pre class="programlisting"> topology { localhost; localnets; };
-</pre>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>The <span><strong class="command">topology</strong></span> option
-is not implemented in <span class="acronym">BIND</span> 9.
-</p>
-</div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="the_sortlist_statement"></a>The <span><strong class="command">sortlist</strong></span> Statement</h4></div></div></div>
-<p>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 <span><strong class="command">rrset-order</strong></span>
-statement in <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called &#8220;RRset Ordering&#8221;</a>).
-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.</p>
-<p>The <span><strong class="command">sortlist</strong></span> statement (see below) takes
-an <span><strong class="command">address_match_list</strong></span> and interprets it even
-more specifically than the <span><strong class="command">topology</strong></span> statement
-does (<a href="Bv9ARM.ch06.html#topology" title="Topology">the section called &#8220;Topology&#8221;</a>).
-Each top level statement in the <span><strong class="command">sortlist</strong></span> must
-itself be an explicit <span><strong class="command">address_match_list</strong></span> with
-one or two elements. The first element (which may be an IP address,
-an IP prefix, an ACL name or a nested <span><strong class="command">address_match_list</strong></span>)
-of each top level list is checked against the source address of
-the query until a match is found.</p>
-<p>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 <span><strong class="command">address_match_list</strong></span> in
-a <span><strong class="command">topology</strong></span> 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.</p>
-<p>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
-or
-192.168.3/24 network with no preference shown between these two
-networks. Queries received from a host on the 192.168.1/24 network
-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.</p>
-<pre class="programlisting">sortlist {
- { localhost; // IF the local host
- { localnets; // THEN first fit on the
- 192.168.1/24; // following nets
- { 192.168.2/24; 192.168.3/24; }; }; };
- { 192.168.1/24; // IF on class C 192.168.1
- { 192.168.1/24; // THEN use .1, or .2 or .3
- { 192.168.2/24; 192.168.3/24; }; }; };
- { 192.168.2/24; // IF on class C 192.168.2
- { 192.168.2/24; // THEN use .2, or .1 or .3
- { 192.168.1/24; 192.168.3/24; }; }; };
- { 192.168.3/24; // IF on class C 192.168.3
- { 192.168.3/24; // THEN use .3, or .1 or .2
- { 192.168.1/24; 192.168.2/24; }; }; };
- { { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net
- };
-};</pre>
-<p>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 <span class="acronym">BIND</span> 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.</p>
-<pre class="programlisting">sortlist {
- { localhost; localnets; };
- { localnets; };
-};
-</pre>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="rrset_ordering"></a>RRset Ordering</h4></div></div></div>
-<p>When multiple records are returned in an answer it may be
-useful to configure the order of the records placed into the response.
-The <span><strong class="command">rrset-order</strong></span> statement permits configuration
-of the ordering of the records in a multiple record response.
-See also the <span><strong class="command">sortlist</strong></span> statement,
-<a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called &#8220;The <span><strong class="command">sortlist</strong></span> Statement&#8221;</a>.
-</p>
-<p>An <span><strong class="command">order_spec</strong></span> is defined as follows:</p>
-<pre class="programlisting">[<span class="optional"> class <em class="replaceable"><code>class_name</code></em> </span>][<span class="optional"> type <em class="replaceable"><code>type_name</code></em> </span>][<span class="optional"> name <em class="replaceable"><code>"domain_name"</code></em></span>]
- order <em class="replaceable"><code>ordering</code></em>
-</pre>
-<p>If no class is specified, the default is <span><strong class="command">ANY</strong></span>.
-If no type is specified, the default is <span><strong class="command">ANY</strong></span>.
-If no name is specified, the default is "<span><strong class="command">*</strong></span>".</p>
-<p>The legal values for <span><strong class="command">ordering</strong></span> are:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><span><strong class="command">fixed</strong></span></p></td>
-<td><p>Records are returned in the order they
-are defined in the zone file.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">random</strong></span></p></td>
-<td><p>Records are returned in some random order.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">cyclic</strong></span></p></td>
-<td><p>Records are returned in a round-robin
-order.</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>For example:</p>
-<pre class="programlisting">rrset-order {
- class IN type A name "host.example.com" order random;
- order cyclic;
-};
-</pre>
-<p>will cause any responses for type A records in class IN that
-have "<code class="literal">host.example.com</code>" as a suffix, to always be returned
-in random order. All other records are returned in cyclic order.</p>
-<p>If multiple <span><strong class="command">rrset-order</strong></span> statements appear,
-they are not combined &#8212; the last one applies.</p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>The <span><strong class="command">rrset-order</strong></span> statement
-is not yet fully implemented in <span class="acronym">BIND</span> 9.
-BIND 9 currently does not support "fixed" ordering.
-</p>
-</div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="tuning"></a>Tuning</h4></div></div></div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">lame-ttl</strong></span></span></dt>
-<dd><p>Sets the number of seconds to cache a
-lame server indication. 0 disables caching. (This is
-<span class="bold"><strong>NOT</strong></span> recommended.)
-Default is <code class="literal">600</code> (10 minutes). Maximum value is
-<code class="literal">1800</code> (30 minutes).</p></dd>
-<dt><span class="term"><span><strong class="command">max-ncache-ttl</strong></span></span></dt>
-<dd><p>To reduce network traffic and increase performance
-the server stores negative answers. <span><strong class="command">max-ncache-ttl</strong></span> is
-used to set a maximum retention time for these answers in the server
-in seconds. The default
-<span><strong class="command">max-ncache-ttl</strong></span> is <code class="literal">10800</code> seconds (3 hours).
-<span><strong class="command">max-ncache-ttl</strong></span> cannot exceed 7 days and will
-be silently truncated to 7 days if set to a greater value.</p></dd>
-<dt><span class="term"><span><strong class="command">max-cache-ttl</strong></span></span></dt>
-<dd><p><span><strong class="command">max-cache-ttl</strong></span> sets
-the maximum time for which the server will cache ordinary (positive)
-answers. The default is one week (7 days).</p></dd>
-<dt><span class="term"><span><strong class="command">min-roots</strong></span></span></dt>
-<dd>
-<p>The minimum number of root servers that
-is required for a request for the root servers to be accepted. Default
-is <strong class="userinput"><code>2</code></strong>.</p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>Not implemented in <span class="acronym">BIND</span>9.</p>
-</div>
-</dd>
-<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
-<dd><p>Specifies the number of days into the
-future when DNSSEC signatures automatically generated as a result
-of dynamic updates (<a href="Bv9ARM.ch04.html#dynamic_update" title="Dynamic Update">the section called &#8220;Dynamic Update&#8221;</a>)
-will expire. The default is <code class="literal">30</code> 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.</p></dd>
-<dt>
-<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
-</dt>
-<dd>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-</dd>
-<dt><span class="term"><span><strong class="command">edns-udp-size</strong></span></span></dt>
-<dd><p>
-<span><strong class="command">edns-udp-size</strong></span> 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.
-</p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="builtin"></a>Built-in server information zones</h4></div></div></div>
-<p>The server provides some helpful diagnostic information
-through a number of built-in zones under the
-pseudo-top-level-domain <code class="literal">bind</code> in the
-<span><strong class="command">CHAOS</strong></span> class. These zones are part of a
-built-in view (see <a href="Bv9ARM.ch06.html#view_statement_grammar" title="view Statement Grammar">the section called &#8220;<span><strong class="command">view</strong></span> Statement Grammar&#8221;</a>) of class
-<span><strong class="command">CHAOS</strong></span> which is separate from the default view of
-class <span><strong class="command">IN</strong></span>; therefore, any global server options
-such as <span><strong class="command">allow-query</strong></span> do not apply the these zones.
-If you feel the need to disable these zones, use the options
-below, or hide the built-in <span><strong class="command">CHAOS</strong></span> view by
-defining an explicit view of class <span><strong class="command">CHAOS</strong></span>
-that matches all clients.</p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">version</strong></span></span></dt>
-<dd><p>The version the server should report
-via a query of the name <code class="literal">version.bind</code>
-with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
-The default is the real version number of this server.
-Specifying <span><strong class="command">version none</strong></span>
-disables processing of the queries.</p></dd>
-<dt><span class="term"><span><strong class="command">hostname</strong></span></span></dt>
-<dd><p>The hostname the server should report via a query of
-the name <code class="filename">hostname.bind</code>
-with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
-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 <span><strong class="command">hostname none;</strong></span>
-disables processing of the queries.</p></dd>
-<dt><span class="term"><span><strong class="command">server-id</strong></span></span></dt>
-<dd><p>The ID of the server should report via a query of
-the name <code class="filename">ID.SERVER</code>
-with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
-The primary purpose of such queries is to
-identify which of a group of anycast servers is actually
-answering your queries. Specifying <span><strong class="command">server-id none;</strong></span>
-disables processing of the queries.
-Specifying <span><strong class="command">server-id hostname;</strong></span> will cause named to
-use the hostname as found by gethostname().
-The default <span><strong class="command">server-id</strong></span> is <span><strong class="command">none</strong></span>.
-</p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="statsfile"></a>The Statistics File</h4></div></div></div>
-<p>The statistics file generated by <span class="acronym">BIND</span> 9
-is similar, but not identical, to that
-generated by <span class="acronym">BIND</span> 8.
-</p>
-<p>The statistics dump begins with the line <span><strong class="command">+++ Statistics Dump
-+++ (973798949)</strong></span>, 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 <span><strong class="command">--- Statistics Dump --- (973798949)</strong></span>, where the
-number is identical to the number in the beginning line.</p>
-<p>The following statistics counters are maintained:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><span><strong class="command">success</strong></span></p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">referral</strong></span></p></td>
-<td><p>The number of queries which resulted
-in referral responses.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">nxrrset</strong></span></p></td>
-<td><p>The number of queries which resulted in
-NOERROR responses with no data.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">nxdomain</strong></span></p></td>
-<td><p>The number
-of queries which resulted in NXDOMAIN responses.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">failure</strong></span></p></td>
-<td><p>The number of queries which resulted in a
-failure response other than those above.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">recursion</strong></span></p></td>
-<td><p>The number of queries which caused the server
-to perform recursion in order to find the final answer.</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>
-Each query received by the server will cause exactly one of
-<span><strong class="command">success</strong></span>,
-<span><strong class="command">referral</strong></span>,
-<span><strong class="command">nxrrset</strong></span>,
-<span><strong class="command">nxdomain</strong></span>, or
-<span><strong class="command">failure</strong></span>
-to be incremented, and may additionally cause the
-<span><strong class="command">recursion</strong></span> counter to be incremented.
-</p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="server_statement_grammar"></a><span><strong class="command">server</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">server <em class="replaceable"><code>ip_addr</code></em> {
- [<span class="optional"> bogus <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> edns <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> transfers <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em> ; ]</span>]
- [<span class="optional"> keys <em class="replaceable"><code>{ string ; [<span class="optional"> string ; [<span class="optional">...</span>]</span>] }</code></em> ; </span>]
- [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="server_statement_definition_and_usage"></a><span><strong class="command">server</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>The <span><strong class="command">server</strong></span> statement defines characteristics
-to be associated with a remote name server.</p>
-<p>
-The <span><strong class="command">server</strong></span> statement can occur at the top level of the
-configuration file or inside a <span><strong class="command">view</strong></span> statement.
-If a <span><strong class="command">view</strong></span> statement contains
-one or more <span><strong class="command">server</strong></span> statements, only those
-apply to the view and any top-level ones are ignored.
-If a view contains no <span><strong class="command">server</strong></span> statements,
-any top-level <span><strong class="command">server</strong></span> statements are used as
-defaults.
-</p>
-<p>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 <span><strong class="command">bogus</strong></span> is <span><strong class="command">no</strong></span>.</p>
-<p>The <span><strong class="command">provide-ixfr</strong></span> 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 <span><strong class="command">yes</strong></span>, incremental transfer will be provided
-whenever possible. If set to <span><strong class="command">no</strong></span>, all transfers
-to the remote server will be non-incremental. If not set, the value
-of the <span><strong class="command">provide-ixfr</strong></span> option in the view or
-global options block is used as a default.</p>
-<p>The <span><strong class="command">request-ixfr</strong></span> 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 <span><strong class="command">request-ixfr</strong></span> option in the view or
-global options block is used as a default.</p>
-<p>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 <span><strong class="command">yes</strong></span> should always work.
-The purpose of the <span><strong class="command">provide-ixfr</strong></span> and
-<span><strong class="command">request-ixfr</strong></span> 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.</p>
-<p>The <span><strong class="command">edns</strong></span> clause determines whether the local server
-will attempt to use EDNS when communicating with the remote server. The
-default is <span><strong class="command">yes</strong></span>.</p>
-<p>The server supports two zone transfer methods. The first, <span><strong class="command">one-answer</strong></span>,
-uses one DNS message per resource record transferred. <span><strong class="command">many-answers</strong></span> packs
-as many resource records as possible into a message. <span><strong class="command">many-answers</strong></span> is
-more efficient, but is only known to be understood by <span class="acronym">BIND</span> 9, <span class="acronym">BIND</span>
-8.x, and patched versions of <span class="acronym">BIND</span> 4.9.5. You can specify which method
-to use for a server with the <span><strong class="command">transfer-format</strong></span> option.
-If <span><strong class="command">transfer-format</strong></span> is not specified, the <span><strong class="command">transfer-format</strong></span> specified
-by the <span><strong class="command">options</strong></span> statement will be used.</p>
-<p><span><strong class="command">transfers</strong></span> is used to limit the number of
-concurrent inbound zone transfers from the specified server. If
-no <span><strong class="command">transfers</strong></span> clause is specified, the limit is
-set according to the <span><strong class="command">transfers-per-ns</strong></span> option.</p>
-<p>The <span><strong class="command">keys</strong></span> clause identifies a
-<span><strong class="command">key_id</strong></span> defined by the <span><strong class="command">key</strong></span> statement,
-to be used for transaction security (TSIG, <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
-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.</p>
-<p>Although the grammar of the <span><strong class="command">keys</strong></span> clause
-allows for multiple keys, only a single key per server is currently
-supported.</p>
-<p>The <span><strong class="command">transfer-source</strong></span> and
-<span><strong class="command">transfer-source-v6</strong></span> 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 <span><strong class="command">transfer-source</strong></span> can
-be specified.
-Similarly, for an IPv6 remote server, only
-<span><strong class="command">transfer-source-v6</strong></span> can be specified.
-Form more details, see the description of
-<span><strong class="command">transfer-source</strong></span> and
-<span><strong class="command">transfer-source-v6</strong></span> in
-<a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2562233"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">trusted-keys {
- <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ;
- [<span class="optional"> <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2562281"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
-and Usage</h3></div></div></div>
-<p>The <span><strong class="command">trusted-keys</strong></span> statement defines DNSSEC
-security roots. DNSSEC is described in <a href="Bv9ARM.ch04.html#DNSSEC" title="DNSSEC">the section called &#8220;DNSSEC&#8221;</a>. 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.</p>
-<p>The <span><strong class="command">trusted-keys</strong></span> 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.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="view_statement_grammar"></a><span><strong class="command">view</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">view <em class="replaceable"><code>view_name</code></em>
- [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
- match-clients { <em class="replaceable"><code>address_match_list</code></em> } ;
- match-destinations { <em class="replaceable"><code>address_match_list</code></em> } ;
- match-recursive-only <em class="replaceable"><code>yes_or_no</code></em> ;
- [<span class="optional"> <em class="replaceable"><code>view_option</code></em>; ...</span>]
- [<span class="optional"> <em class="replaceable"><code>zone_statement</code></em>; ...</span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2562349"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>The <span><strong class="command">view</strong></span> statement is a powerful new feature
-of <span class="acronym">BIND</span> 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.</p>
-<p>Each <span><strong class="command">view</strong></span> 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
-<code class="varname">address_match_list</code> of the view's
-<span><strong class="command">match-clients</strong></span> clause and its destination IP address matches
-the <code class="varname">address_match_list</code> of the view's
-<span><strong class="command">match-destinations</strong></span> clause. If not specified, both
-<span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
-default to matching all addresses. In addition to checking IP addresses
-<span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
-can also take <span><strong class="command">keys</strong></span> which provide an mechanism for the
-client to select the view. A view can also be specified
-as <span><strong class="command">match-recursive-only</strong></span>, which means that only recursive
-requests from matching clients will match that view.
-The order of the <span><strong class="command">view</strong></span> statements is significant &#8212;
-a client request will be resolved in the context of the first
-<span><strong class="command">view</strong></span> that it matches.</p>
-<p>Zones defined within a <span><strong class="command">view</strong></span> statement will
-be only be accessible to clients that match the <span><strong class="command">view</strong></span>.
- 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.</p>
-<p>Many of the options given in the <span><strong class="command">options</strong></span> statement
-can also be used within a <span><strong class="command">view</strong></span> statement, and then
-apply only when resolving queries with that view. When no view-specific
-value is given, the value in the <span><strong class="command">options</strong></span> statement
-is used as a default. Also, zone options can have default values specified
-in the <span><strong class="command">view</strong></span> statement; these view-specific defaults
-take precedence over those in the <span><strong class="command">options</strong></span> statement.</p>
-<p>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.</p>
-<p>If there are no <span><strong class="command">view</strong></span> statements in the config
-file, a default view that matches any client is automatically created
-in class IN. Any <span><strong class="command">zone</strong></span> statements specified on
-the top level of the configuration file are considered to be part of
-this default view, and the <span><strong class="command">options</strong></span> statement will
-apply to the default view. If any explicit <span><strong class="command">view</strong></span>
-statements are present, all <span><strong class="command">zone</strong></span> statements must
-occur inside <span><strong class="command">view</strong></span> statements.</p>
-<p>Here is an example of a typical split DNS setup implemented
-using <span><strong class="command">view</strong></span> statements.</p>
-<pre class="programlisting">view "internal" {
- // This should match our internal networks.
- match-clients { 10.0.0.0/8; };
-
- // Provide recursive service to internal clients only.
- recursion yes;
-
- // Provide a complete view of the example.com zone
- // including addresses of internal hosts.
- zone "example.com" {
- type master;
- file "example-internal.db";
- };
-};
-
-view "external" {
- // Match all clients not matched by the previous view.
- match-clients { any; };
-
- // Refuse recursive service to external clients.
- recursion no;
-
- // Provide a restricted view of the example.com zone
- // containing only publicly accessible hosts.
- zone "example.com" {
- type master;
- file "example-external.db";
- };
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="zone_statement_grammar"></a><span><strong class="command">zone</strong></span>
-Statement Grammar</h3></div></div></div>
-<pre class="programlisting">zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] [<span class="optional">{
- type ( master | slave | hint | stub | forward | delegation-only ) ;
- [<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
- [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
- [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
- [<span class="optional"> allow-update { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
- [<span class="optional"> update-policy { <em class="replaceable"><code>update_policy_rule</code></em> [<span class="optional">...</span>] } ; </span>]
- [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
- [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
- [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
- [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
- [<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
- [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
- [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
- [<span class="optional"> ixfr-base <em class="replaceable"><code>string</code></em> ; </span>]
- [<span class="optional"> ixfr-tmp-file <em class="replaceable"><code>string</code></em> ; </span>]
- [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> masters [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] } ; </span>]
- [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> ; </span>]
- [<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
- [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
- [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
- [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
- [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
- [<span class="optional"> multi-master <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
- [<span class="optional"> key-directory <em class="replaceable"><code>path_name</code></em>; </span>]
-
-}</span>];
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2563022"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2563029"></a>Zone Types</h4></div></div></div>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><code class="varname">master</code></p></td>
-<td><p>The server has a master copy of the data
-for the zone and will be able to provide authoritative answers for
-it.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">slave</code></p></td>
-<td><p>A slave zone is a replica of a master
-zone. The <span><strong class="command">masters</strong></span> 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
-be changed for all servers by specifying a port number before the
-list of IP addresses, or on a per-server basis after the IP address.
-Authentication to the master can also be done with per-server TSIG keys.
-If a file is specified, then the
-replica will be written to this file whenever the zone is changed,
-and reloaded from this file on a server restart. Use of a file is
-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 <code class="literal">example.com</code> might place
-the zone contents into a file called
-<code class="filename">ex/example.com</code> where <code class="filename">ex/</code> 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.)</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">stub</code></p></td>
-<td>
-<p>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 <span class="acronym">BIND</span> implementation.
-</p>
-
-<p>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 <code class="filename">named.conf</code>.
-This usage is not recommended for new configurations, and BIND 9
-supports it only in a limited way.
-In <span class="acronym">BIND</span> 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. <span class="acronym">BIND</span>
-9 never mixes together zone data from different zones in this
-way. Therefore, if a <span class="acronym">BIND</span> 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.</p>
-
-<p>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
-<code class="literal">10.in-addr.arpa</code>
-to use a set of internal name servers as the authoritative
-servers for that domain.</p>
-</td>
-</tr>
-<tr>
-<td><p><code class="varname">forward</code></p></td>
-<td>
-<p>A "forward zone" is a way to configure
-forwarding on a per-domain basis. A <span><strong class="command">zone</strong></span> statement
-of type <span><strong class="command">forward</strong></span> can contain a <span><strong class="command">forward</strong></span> and/or <span><strong class="command">forwarders</strong></span> statement,
-which will apply to queries within the domain given by the zone
-name. If no <span><strong class="command">forwarders</strong></span> statement is present or
-an empty list for <span><strong class="command">forwarders</strong></span> is given, then no
-forwarding will be done for the domain, canceling the effects of
-any forwarders in the <span><strong class="command">options</strong></span> statement. Thus
-if you want to use this type of zone to change the behavior of the
-global <span><strong class="command">forward</strong></span> 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.</p>
-</td>
-</tr>
-<tr>
-<td><p><code class="varname">hint</code></p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">delegation-only</code></p></td>
-<td>
-<p>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.</p>
-<p><code class="varname">delegation-only</code> has no effect on answers received
-from forwarders.</p>
-</td>
-</tr>
-</tbody>
-</table></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2563267"></a>Class</h4></div></div></div>
-<p>The zone's name may optionally be followed by a class. If
-a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>),
-is assumed. This is correct for the vast majority of cases.</p>
-<p>The <code class="literal">hesiod</code> 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
-<code class="literal">HS</code> is
-a synonym for hesiod.</p>
-<p>Another MIT development is CHAOSnet, a LAN protocol created
-in the mid-1970s. Zone data for it can be specified with the <code class="literal">CHAOS</code> class.</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2563434"></a>Zone Options</h4></div></div></div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">allow-notify</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a></p></dd>
-<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">allow-query</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a></p></dd>
-<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
-<dd><p>See the description of <span><strong class="command">allow-transfer</strong></span>
-in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">allow-update</strong></span></span></dt>
-<dd><p>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
-<a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called &#8220;Dynamic Update Security&#8221;</a> for details.
-</p></dd>
-<dt><span class="term"><span><strong class="command">update-policy</strong></span></span></dt>
-<dd><p>Specifies a "Simple Secure Update" policy. See
-<a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
-<dd><p>See the description of <span><strong class="command">allow-update-forwarding</strong></span>
-in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
-<dd><p>Only meaningful if <span><strong class="command">notify</strong></span> is
-active for this zone. The set of machines that will receive a
-<code class="literal">DNS NOTIFY</code> 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 <span><strong class="command">also-notify</strong></span>. A port may be specified
-with each <span><strong class="command">also-notify</strong></span> address to send the notify
-messages to a port other than the default of 53.
-<span><strong class="command">also-notify</strong></span> is not meaningful for stub zones.
-The default is the empty list.</p></dd>
-<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
-<dd><p>
-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 <span><strong class="command">master</strong></span> zones the default is <span><strong class="command">fail</strong></span>. For <span><strong class="command">slave</strong></span>
-zones the default is <span><strong class="command">warn</strong></span>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">database</strong></span></span></dt>
-<dd>
-<p>Specify the type of database to be used for storing the
-zone data. The string following the <span><strong class="command">database</strong></span> 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.</p>
-<p>The default is <strong class="userinput"><code>"rbt"</code></strong>, BIND 9's native in-memory
-red-black-tree database. This database does not take arguments.</p>
-<p>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.</p>
-</dd>
-<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">dialup</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">delegation-only</strong></span></span></dt>
-<dd><p>The flag only applies to hint and stub zones. If set
-to <strong class="userinput"><code>yes</code></strong> then the zone will also be treated as if it
-is also a delegation-only type zone.
-</p></dd>
-<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
-<dd><p>Only meaningful if the zone has a forwarders
-list. The <span><strong class="command">only</strong></span> value causes the lookup to fail
-after trying the forwarders and getting no answer, while <span><strong class="command">first</strong></span> would
-allow a normal lookup to be tried.</p></dd>
-<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
-<dd><p>Used to override the list of global forwarders.
-If it is not specified in a zone of type <span><strong class="command">forward</strong></span>,
-no forwarding is done for the zone; the global options are not used.</p></dd>
-<dt><span class="term"><span><strong class="command">ixfr-base</strong></span></span></dt>
-<dd><p>Was used in <span class="acronym">BIND</span> 8 to specify the name
-of the transaction log (journal) file for dynamic update and IXFR.
-<span class="acronym">BIND</span> 9 ignores the option and constructs the name of the journal
-file by appending "<code class="filename">.jnl</code>" to the name of the
-zone file.</p></dd>
-<dt><span class="term"><span><strong class="command">ixfr-tmp-file</strong></span></span></dt>
-<dd><p>Was an undocumented option in <span class="acronym">BIND</span> 8.
-Ignored in <span class="acronym">BIND</span> 9.</p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">max-transfer-time-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">max-transfer-idle-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">max-transfer-time-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">max-transfer-idle-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">notify</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">pubkey</strong></span></span></dt>
-<dd><p>In <span class="acronym">BIND</span> 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. <span class="acronym">BIND</span> 9 does not verify signatures
-on load and ignores the option.</p></dd>
-<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
-<dd><p>If <strong class="userinput"><code>yes</code></strong>, the server will keep statistical
-information for this zone, which can be dumped to the
-<span><strong class="command">statistics-file</strong></span> defined in the server options.</p></dd>
-<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">sig-validity-interval</strong></span> in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
-</p></dd>
-<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
-</p></dd>
-<dt><span class="term"><span><strong class="command">alt-transfer-source</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">alt-transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
-</p></dd>
-<dt><span class="term"><span><strong class="command">alt-transfer-source-v6</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">alt-transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
-</p></dd>
-<dt><span class="term"><span><strong class="command">use-alt-transfer-source</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">use-alt-transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
-</p></dd>
-<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">notify-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
-</p></dd>
-<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">notify-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-</p></dd>
-<dt>
-<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
-</dt>
-<dd><p>
-See the description in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
-</p></dd>
-<dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">ixfr-from-differences</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.</p></dd>
-<dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">key-directory</strong></span> in <a href="Bv9ARM.ch06.html#options" title="options Statement Definition and Usage">the section called &#8220;<span><strong class="command">options</strong></span> Statement Definition and Usage&#8221;</a></p></dd>
-<dt><span class="term"><span><strong class="command">multi-master</strong></span></span></dt>
-<dd><p>See the description of
-<span><strong class="command">multi-master</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.</p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="dynamic_update_policies"></a>Dynamic Update Policies</h4></div></div></div>
-<p><span class="acronym">BIND</span> 9 supports two alternative methods of granting clients
-the right to perform dynamic updates to a zone,
-configured by the <span><strong class="command">allow-update</strong></span> and
-<span><strong class="command">update-policy</strong></span> option, respectively.</p>
-<p>The <span><strong class="command">allow-update</strong></span> clause works the same
-way as in previous versions of <span class="acronym">BIND</span>. It grants given clients the
-permission to update any record of any name in the zone.</p>
-<p>The <span><strong class="command">update-policy</strong></span> clause is new in <span class="acronym">BIND</span>
-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.</p>
-<p>Rules are specified in the <span><strong class="command">update-policy</strong></span> zone
-option, and are only meaningful for master zones. When the <span><strong class="command">update-policy</strong></span> statement
-is present, it is a configuration error for the <span><strong class="command">allow-update</strong></span> statement
-to be present. The <span><strong class="command">update-policy</strong></span> statement only
-examines the signer of a message; the source address is not relevant.</p>
-<p>This is how a rule definition looks:</p>
-<pre class="programlisting">
-( <span><strong class="command">grant</strong></span> | <span><strong class="command">deny</strong></span> ) <em class="replaceable"><code>identity</code></em> <em class="replaceable"><code>nametype</code></em> <em class="replaceable"><code>name</code></em> [<span class="optional"> <em class="replaceable"><code>types</code></em> </span>]
-</pre>
-<p>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.</p>
-<p>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 <em class="replaceable"><code>identity</code></em> field specifies a
-wildcard name, it is subject to DNS wildcard expansion, so the rule will apply
-to multiple identities. The <em class="replaceable"><code>identity</code></em> field must
-contain a fully qualified domain name.</p>
-<p>The <em class="replaceable"><code>nametype</code></em> field has 4 values:
-<code class="varname">name</code>, <code class="varname">subdomain</code>,
-<code class="varname">wildcard</code>, and <code class="varname">self</code>.
-</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><code class="varname">name</code></p></td>
-<td><p>Exact-match semantics. This rule matches when the
-name being updated is identical to the contents of the
-<em class="replaceable"><code>name</code></em> field.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">subdomain</code></p></td>
-<td><p>This rule matches when the name being updated
-is a subdomain of, or identical to, the contents of the
-<em class="replaceable"><code>name</code></em> field.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">wildcard</code></p></td>
-<td><p>The <em class="replaceable"><code>name</code></em> field is
-subject to DNS wildcard expansion, and this rule matches when the name
-being updated name is a valid expansion of the wildcard.</p></td>
-</tr>
-<tr>
-<td><p><code class="varname">self</code></p></td>
-<td><p>This rule matches when the name being updated
-matches the contents of the <em class="replaceable"><code>identity</code></em> field.
-The <em class="replaceable"><code>name</code></em> field is ignored, but should be
-the same as the <em class="replaceable"><code>identity</code></em> field. The
-<code class="varname">self</code> 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 <em class="replaceable"><code>identity</code></em> would be
-specified as <code class="constant">*</code> in this case.</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>In all cases, the <em class="replaceable"><code>name</code></em> field must
-specify a fully qualified domain name.</p>
-<p>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.
-</p>
-</div>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564557"></a>Zone File</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div>
-<p>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.</p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2564576"></a>Resource Records</h4></div></div></div>
-<p>A domain name identifies a node. Each node has a set of
- resource information, which may be empty. The set of resource
- 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 <a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called &#8220;The <span><strong class="command">sortlist</strong></span> Statement&#8221;</a> and <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called &#8220;RRset Ordering&#8221;</a>.</p>
-<p>The components of a Resource Record are:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p>owner name</p></td>
-<td><p>the domain name where the RR is found.</p></td>
-</tr>
-<tr>
-<td><p>type</p></td>
-<td><p>an encoded 16 bit value that specifies
-the type of the resource record.</p></td>
-</tr>
-<tr>
-<td><p>TTL</p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p>class</p></td>
-<td><p>an encoded 16 bit value that identifies
-a protocol family or instance of a protocol.</p></td>
-</tr>
-<tr>
-<td><p>RDATA</p></td>
-<td><p>the resource data. The format of the
-data is type (and sometimes class) specific.</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>The following are <span class="emphasis"><em>types</em></span> of valid RRs:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p>A</p></td>
-<td><p>a host address. In the IN class, this is a
-32-bit IP address. Described in RFC 1035.</p></td>
-</tr>
-<tr>
-<td><p>AAAA</p></td>
-<td><p>IPv6 address. Described in RFC 1886.</p></td>
-</tr>
-<tr>
-<td><p>A6</p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p>AFSDB</p></td>
-<td><p>location of AFS database servers.
-Experimental. Described in RFC 1183.</p></td>
-</tr>
-<tr>
-<td><p>APL</p></td>
-<td><p>address prefix list. Experimental.
-Described in RFC 3123.</p></td>
-</tr>
-<tr>
-<td><p>CERT</p></td>
-<td><p>holds a digital certificate.
-Described in RFC 2538.</p></td>
-</tr>
-<tr>
-<td><p>CNAME</p></td>
-<td><p>identifies the canonical name of an alias.
-Described in RFC 1035.</p></td>
-</tr>
-<tr>
-<td><p>DNAME</p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p>GPOS</p></td>
-<td><p>Specifies the global position. Superseded by LOC.</p></td>
-</tr>
-<tr>
-<td><p>HINFO</p></td>
-<td><p>identifies the CPU and OS used by a host.
-Described in RFC 1035.</p></td>
-</tr>
-<tr>
-<td><p>ISDN</p></td>
-<td><p>representation of ISDN addresses.
-Experimental. Described in RFC 1183.</p></td>
-</tr>
-<tr>
-<td><p>KEY</p></td>
-<td><p>stores a public key associated with a
-DNS name. Described in RFC 2535.</p></td>
-</tr>
-<tr>
-<td><p>KX</p></td>
-<td><p>identifies a key exchanger for this
-DNS name. Described in RFC 2230.</p></td>
-</tr>
-<tr>
-<td><p>LOC</p></td>
-<td><p>for storing GPS info. Described in RFC 1876.
-Experimental.</p></td>
-</tr>
-<tr>
-<td><p>MX</p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p>NAPTR</p></td>
-<td><p>name authority pointer. Described in RFC 2915.</p></td>
-</tr>
-<tr>
-<td><p>NSAP</p></td>
-<td><p>a network service access point.
-Described in RFC 1706.</p></td>
-</tr>
-<tr>
-<td><p>NS</p></td>
-<td><p>the authoritative name server for the
-domain. Described in RFC 1035.</p></td>
-</tr>
-<tr>
-<td><p>NXT</p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p>PTR</p></td>
-<td><p>a pointer to another part of the domain
-name space. Described in RFC 1035.</p></td>
-</tr>
-<tr>
-<td><p>PX</p></td>
-<td><p>provides mappings between RFC 822 and X.400
-addresses. Described in RFC 2163.</p></td>
-</tr>
-<tr>
-<td><p>RP</p></td>
-<td><p>information on persons responsible
-for the domain. Experimental. Described in RFC 1183.</p></td>
-</tr>
-<tr>
-<td><p>RT</p></td>
-<td><p>route-through binding for hosts that
-do not have their own direct wide area network addresses.
-Experimental. Described in RFC 1183.</p></td>
-</tr>
-<tr>
-<td><p>SIG</p></td>
-<td><p>("signature") contains data authenticated
-in the secure DNS. Described in RFC 2535.</p></td>
-</tr>
-<tr>
-<td><p>SOA</p></td>
-<td><p>identifies the start of a zone of authority.
-Described in RFC 1035.</p></td>
-</tr>
-<tr>
-<td><p>SRV</p></td>
-<td><p>information about well known network
-services (replaces WKS). Described in RFC 2782.</p></td>
-</tr>
-<tr>
-<td><p>TXT</p></td>
-<td><p>text records. Described in RFC 1035.</p></td>
-</tr>
-<tr>
-<td><p>WKS</p></td>
-<td><p>information about which well known
-network services, such as SMTP, that a domain supports. Historical.
-</p></td>
-</tr>
-<tr>
-<td><p>X25</p></td>
-<td><p>representation of X.25 network addresses.
-Experimental. Described in RFC 1183.</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>The following <span class="emphasis"><em>classes</em></span> of resource records
-are currently valid in the DNS:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p>IN</p></td>
-<td><p>The Internet.</p></td>
-</tr>
-<tr>
-<td><p>CH</p></td>
-<td><p>
-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.,
-<code class="literal">version.bind</code>.
-</p></td>
-</tr>
-<tr>
-<td><p>HS</p></td>
-<td><p>
-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.
-</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>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.</p>
-<p>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
-zone where the data originates. While short TTLs can be used to
-minimize caching, and a zero TTL prohibits caching, the realities
-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.</p>
-<p>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.</p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2565564"></a>Textual expression of RRs</h4></div></div></div>
-<p>RRs are represented in binary form in the packets of the DNS
-protocol, and are usually represented in highly encoded form 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.</p>
-<p>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.</p>
-<p>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.</p>
-<p>The resource data or RDATA section of the RR are given using
-knowledge of the typical representation for the data.</p>
-<p>For example, we might show the RRs carried in a message as:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><code class="literal">ISI.EDU.</code></p></td>
-<td><p><code class="literal">MX</code></p></td>
-<td><p><code class="literal">10 VENERA.ISI.EDU.</code></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p><code class="literal">MX</code></p></td>
-<td><p><code class="literal">10 VAXA.ISI.EDU</code></p></td>
-</tr>
-<tr>
-<td><p><code class="literal">VENERA.ISI.EDU</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">128.9.0.32</code></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">10.1.0.52</code></p></td>
-</tr>
-<tr>
-<td><p><code class="literal">VAXA.ISI.EDU</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">10.2.0.27</code></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">128.9.0.33</code></p></td>
-</tr>
-</tbody>
-</table></div>
-<p>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.</p>
-<p>This example shows six RRs, with two RRs at each of three
-domain names.</p>
-<p>Similarly we might see:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><code class="literal">XX.LCS.MIT.EDU. IN</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">10.0.0.44</code></p></td>
-</tr>
-<tr>
-<td><p><code class="literal">CH</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">MIT.EDU. 2420</code></p></td>
-</tr>
-</tbody>
-</table></div>
-<p>This example shows two addresses for <code class="literal">XX.LCS.MIT.EDU</code>,
-each of a different class.</p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2565990"></a>Discussion of MX Records</h3></div></div></div>
-<p>As described above, domain servers store information as a
-series of resource records, each of which contains a particular
-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.</p>
-<p>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
-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 &#8212; 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 <span class="emphasis"><em>must</em></span> have
-an associated A record &#8212; CNAME is not sufficient.</p>
-<p>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.</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><code class="literal">example.com.</code></p></td>
-<td><p><code class="literal">IN</code></p></td>
-<td><p><code class="literal">MX</code></p></td>
-<td><p><code class="literal">10</code></p></td>
-<td><p><code class="literal">mail.example.com.</code></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p><code class="literal">IN</code></p></td>
-<td><p><code class="literal">MX</code></p></td>
-<td><p><code class="literal">10</code></p></td>
-<td><p><code class="literal">mail2.example.com.</code></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p><code class="literal">IN</code></p></td>
-<td><p><code class="literal">MX</code></p></td>
-<td><p><code class="literal">20</code></p></td>
-<td><p><code class="literal">mail.backup.org.</code></p></td>
-</tr>
-<tr>
-<td><p><code class="literal">mail.example.com.</code></p></td>
-<td><p><code class="literal">IN</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">10.0.0.1</code></p></td>
-<td><p></p></td>
-</tr>
-<tr>
-<td><p><code class="literal">mail2.example.com.</code></p></td>
-<td><p><code class="literal">IN</code></p></td>
-<td><p><code class="literal">A</code></p></td>
-<td><p><code class="literal">10.0.0.2</code></p></td>
-<td><p></p></td>
-</tr>
-</tbody>
-</table></div>
-<p>For example:</p>
-<p>Mail delivery will be attempted to <code class="literal">mail.example.com</code> and
-<code class="literal">mail2.example.com</code> (in
-any order), and if neither of those succeed, delivery to <code class="literal">mail.backup.org</code> will
-be attempted.</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="Setting_TTLs"></a>Setting TTLs</h3></div></div></div>
-<p>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.</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p>SOA</p></td>
-<td>
-<p>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.</p>
-<p>The maximum time for
-negative caching is 3 hours (3h).</p>
-</td>
-</tr>
-<tr>
-<td><p>$TTL</p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p>RR TTLs</p></td>
-<td><p>Each RR can have a TTL as the second
-field in the RR, which will control how long other servers can cache
-the it.</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>All of these TTLs default to units of seconds, though units
-can be explicitly specified, for example, <code class="literal">1h30m</code>. </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2566487"></a>Inverse Mapping in IPv4</h3></div></div></div>
-<p>Reverse name resolution (that is, translation from IP address
-to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> domain
-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,
-a machine with an IP address of 10.1.2.3 would have a corresponding
-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 [<span class="optional">example.com</span>] domain:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><code class="literal">$ORIGIN</code></p></td>
-<td><p><code class="literal">2.1.10.in-addr.arpa</code></p></td>
-</tr>
-<tr>
-<td><p><code class="literal">3</code></p></td>
-<td><p><code class="literal">IN PTR foo.example.com.</code></p></td>
-</tr>
-</tbody>
-</table></div>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>The <span><strong class="command">$ORIGIN</strong></span> 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.</p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2566593"></a>Other Zone File Directives</h3></div></div></div>
-<p>The Master File Format was initially defined in RFC 1035 and
-has subsequently been extended. While the Master File Format itself
-is class independent all records in a Master File must be of the same
-class.</p>
-<p>Master File Directives include <span><strong class="command">$ORIGIN</strong></span>, <span><strong class="command">$INCLUDE</strong></span>,
-and <span><strong class="command">$TTL.</strong></span></p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2566612"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
-<p>Syntax: <span><strong class="command">$ORIGIN
-</strong></span><em class="replaceable"><code>domain-name</code></em> [<span class="optional"> <em class="replaceable"><code>comment</code></em></span>]</p>
-<p><span><strong class="command">$ORIGIN</strong></span> sets the domain name that will
-be appended to any unqualified records. When a zone is first read
-in there is an implicit <span><strong class="command">$ORIGIN</strong></span> &lt;<code class="varname">zone-name</code>&gt;<span><strong class="command">.</strong></span> The
-current <span><strong class="command">$ORIGIN</strong></span> is appended to the domain specified
-in the <span><strong class="command">$ORIGIN</strong></span> argument if it is not absolute.</p>
-<pre class="programlisting">$ORIGIN example.com.
-WWW CNAME MAIN-SERVER</pre>
-<p>is equivalent to</p>
-<pre class="programlisting">WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</pre>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2566667"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
-<p>Syntax: <span><strong class="command">$INCLUDE</strong></span>
-<em class="replaceable"><code>filename</code></em> [<span class="optional">
-<em class="replaceable"><code>origin</code></em> </span>] [<span class="optional"> <em class="replaceable"><code>comment</code></em> </span>]</p>
-<p>Read and process the file <code class="filename">filename</code> as
-if it were included into the file at this point. If <span><strong class="command">origin</strong></span> is
-specified the file is processed with <span><strong class="command">$ORIGIN</strong></span> set
-to that value, otherwise the current <span><strong class="command">$ORIGIN</strong></span> is
-used.</p>
-<p>The origin and the current domain name
-revert to the values they had prior to the <span><strong class="command">$INCLUDE</strong></span> once
-the file has been read.</p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-RFC 1035 specifies that the current origin should be restored after
-an <span><strong class="command">$INCLUDE</strong></span>, 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.
-</p>
-</div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2566730"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
-<p>Syntax: <span><strong class="command">$TTL</strong></span>
-<em class="replaceable"><code>default-ttl</code></em> [<span class="optional">
-<em class="replaceable"><code>comment</code></em> </span>]</p>
-<p>Set the default Time To Live (TTL) for subsequent records
-with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.</p>
-<p><span><strong class="command">$TTL</strong></span> is defined in RFC 2308.</p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2566761"></a><span class="acronym">BIND</span> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
-<p>Syntax: <span><strong class="command">$GENERATE</strong></span> <em class="replaceable"><code>range</code></em> <em class="replaceable"><code>lhs</code></em> [<span class="optional"><em class="replaceable"><code>ttl</code></em></span>] [<span class="optional"><em class="replaceable"><code>class</code></em></span>] <em class="replaceable"><code>type</code></em> <em class="replaceable"><code>rhs</code></em> [<span class="optional"> <em class="replaceable"><code>comment</code></em> </span>]</p>
-<p><span><strong class="command">$GENERATE</strong></span> is used to create a series of
-resource records that only differ from each other by an iterator. <span><strong class="command">$GENERATE</strong></span> 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.</p>
-<pre class="programlisting">$ORIGIN 0.0.192.IN-ADDR.ARPA.
-$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
-$GENERATE 1-127 $ CNAME $.0</pre>
-<p>is equivalent to</p>
-<pre class="programlisting">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.
-</pre>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p><span><strong class="command">range</strong></span></p></td>
-<td><p>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.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">lhs</strong></span></p></td>
-<td>
-<p><span><strong class="command">lhs</strong></span> describes the
-owner name of the resource records to be created. Any single <span><strong class="command">$</strong></span> symbols
-within the <span><strong class="command">lhs</strong></span> side are replaced by the iterator
-value.
-To get a $ in the output you need to escape the <span><strong class="command">$</strong></span>
-using a backslash <span><strong class="command">\</strong></span>,
-e.g. <span><strong class="command">\$</strong></span>. The <span><strong class="command">$</strong></span> may optionally be followed
-by modifiers which change the offset from the iterator, field width and base.
-Modifiers are introduced by a <span><strong class="command">{</strong></span> immediately following the
-<span><strong class="command">$</strong></span> as <span><strong class="command">${offset[,width[,base]]}</strong></span>.
-e.g. <span><strong class="command">${-20,3,d}</strong></span> 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 (<span><strong class="command">d</strong></span>), octal (<span><strong class="command">o</strong></span>)
-and hexadecimal (<span><strong class="command">x</strong></span> or <span><strong class="command">X</strong></span> for uppercase).
-The default modifier is <span><strong class="command">${0,0,d}</strong></span>.
-If the <span><strong class="command">lhs</strong></span> is not
-absolute, the current <span><strong class="command">$ORIGIN</strong></span> is appended to
-the name.</p>
-<p>For compatibility with earlier versions <span><strong class="command">$$</strong></span> is still
-recognized a indicating a literal $ in the output.</p>
-</td>
-</tr>
-<tr>
-<td><p><span><strong class="command">ttl</strong></span></p></td>
-<td>
-<p><span><strong class="command">ttl</strong></span> specifies the
- ttl of the generated records. If not specified this will be
- inherited using the normal ttl inheritance rules.</p>
- <p><span><strong class="command">class</strong></span> and <span><strong class="command">ttl</strong></span> can be
- entered in either order.</p>
-</td>
-</tr>
-<tr>
-<td><p><span><strong class="command">class</strong></span></p></td>
-<td>
-<p><span><strong class="command">class</strong></span> specifies the
- class of the generated records. This must match the zone class if
- it is specified.</p>
- <p><span><strong class="command">class</strong></span> and <span><strong class="command">ttl</strong></span> can be
- entered in either order.</p>
-</td>
-</tr>
-<tr>
-<td><p><span><strong class="command">type</strong></span></p></td>
-<td><p>At present the only supported types are
-PTR, CNAME, DNAME, A, AAAA and NS.</p></td>
-</tr>
-<tr>
-<td><p><span><strong class="command">rhs</strong></span></p></td>
-<td><p>rhs is a domain name. It is processed
-similarly to lhs.</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>The <span><strong class="command">$GENERATE</strong></span> directive is a <span class="acronym">BIND</span> extension
-and not part of the standard zone file format.</p>
-<p>BIND 8 does not support the optional TTL and CLASS fields.</p>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch07.html b/contrib/bind9/doc/arm/Bv9ARM.ch07.html
deleted file mode 100644
index 86c2b6af06424..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch07.html
+++ /dev/null
@@ -1,200 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch07.html,v 1.50.2.9.2.24 2005/10/13 02:34:02 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 7. BIND 9 Security Considerations</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
-<link rel="next" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch07"></a>Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2567222"><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
-UNIX servers)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567366">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567424">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="Access_Control_Lists"></a>Access Control Lists</h2></div></div></div>
-<p>Access Control Lists (ACLs), are address match lists that
-you can set up and nickname for future use in <span><strong class="command">allow-notify</strong></span>,
-<span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-recursion</strong></span>,
-<span><strong class="command">blackhole</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
-etc.</p>
-<p>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.</p>
-<p>It is a <span class="emphasis"><em>good idea</em></span> 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.</p>
-<p>Here is an example of how to properly apply ACLs:</p>
-<pre class="programlisting">
-// 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.
-acl our-nets { x.x.x.x/24; x.x.x.x/21; };
-options {
- ...
- ...
- allow-query { our-nets; };
- allow-recursion { our-nets; };
- ...
- blackhole { bogusnets; };
- ...
-};
-zone "example.com" {
- type master;
- file "m/example.com";
- allow-query { any; };
-};
-</pre>
-<p>This allows recursive queries of the server from the outside
-unless recursion has been previously disabled.</p>
-<p>For more information on how to use ACLs to protect your server,
-see the <span class="emphasis"><em>AUSCERT</em></span> advisory at
-<a href="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos" target="_top">ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</a></p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567222"></a><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
-UNIX servers)</h2></div></div></div>
-<p>On UNIX servers, it is possible to run <span class="acronym">BIND</span> in a <span class="emphasis"><em>chrooted</em></span> environment
-(<span><strong class="command">chroot()</strong></span>) by specifying the "<code class="option">-t</code>"
-option. This can help improve system security by placing <span class="acronym">BIND</span> in
-a "sandbox", which will limit the damage done if a server is compromised.</p>
-<p>Another useful feature in the UNIX version of <span class="acronym">BIND</span> is the
-ability to run the daemon as an unprivileged user ( <code class="option">-u</code> <em class="replaceable"><code>user</code></em> ).
-We suggest running as an unprivileged user when using the <span><strong class="command">chroot</strong></span> feature.</p>
-<p>Here is an example command line to load <span class="acronym">BIND</span> in a <span><strong class="command">chroot()</strong></span> sandbox,
-<span><strong class="command">/var/named</strong></span>, and to run <span><strong class="command">named</strong></span> <span><strong class="command">setuid</strong></span> to
-user 202:</p>
-<p><strong class="userinput"><code>/usr/local/bin/named -u 202 -t /var/named</code></strong></p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567366"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
-<p>In order for a <span><strong class="command">chroot()</strong></span> environment to
-work properly in a particular directory
-(for example, <code class="filename">/var/named</code>),
-you will need to set up an environment that includes everything
-<span class="acronym">BIND</span> needs to run.
-From <span class="acronym">BIND</span>'s point of view, <code class="filename">/var/named</code> is
-the root of the filesystem. You will need to adjust the values of options like
-like <span><strong class="command">directory</strong></span> and <span><strong class="command">pid-file</strong></span> to account
-for this.
-</p>
-<p>
-Unlike with earlier versions of BIND, you will typically
-<span class="emphasis"><em>not</em></span> need to compile <span><strong class="command">named</strong></span>
-statically nor install shared libraries under the new root.
-However, depending on your operating system, you may need
-to set up things like
-<code class="filename">/dev/zero</code>,
-<code class="filename">/dev/random</code>,
-<code class="filename">/dev/log</code>, and/or
-<code class="filename">/etc/localtime</code>.
-</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567424"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
-<p>Prior to running the <span><strong class="command">named</strong></span> daemon, use
-the <span><strong class="command">touch</strong></span> utility (to change file access and
-modification times) or the <span><strong class="command">chown</strong></span> utility (to
-set the user id and/or group id) on files
-to which you want <span class="acronym">BIND</span>
-to write. Note that if the <span><strong class="command">named</strong></span> daemon is running as an
-unprivileged user, it will not be able to bind to new restricted ports if the
-server is reloaded.</p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="dynamic_update_security"></a>Dynamic Update Security</h2></div></div></div>
-<p>Access to the dynamic
-update facility should be strictly limited. In earlier versions of
-<span class="acronym">BIND</span> 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 <span><strong class="command">allow-update</strong></span> 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
-<span><strong class="command">allow-update</strong></span> 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.</p>
-<p>For these reasons, we strongly recommend that updates be
-cryptographically authenticated by means of transaction signatures
-(TSIG). That is, the <span><strong class="command">allow-update</strong></span> option should
-list only TSIG key names, not IP addresses or network
-prefixes. Alternatively, the new <span><strong class="command">update-policy</strong></span>
-option can be used.</p>
-<p>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.</p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 8. Troubleshooting</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch08.html b/contrib/bind9/doc/arm/Bv9ARM.ch08.html
deleted file mode 100644
index 9d486e1bd5b6b..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch08.html
+++ /dev/null
@@ -1,124 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch08.html,v 1.50.2.9.2.24 2005/10/13 02:34:02 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 8. Troubleshooting</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
-<link rel="next" href="Bv9ARM.ch09.html" title="Appendix A. Appendices">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 8. Troubleshooting</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch08"></a>Chapter 8. Troubleshooting</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567630">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2567636">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567648">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567665">Where Can I Get Help?</a></span></dt>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567630"></a>Common Problems</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567636"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
-<p>The best solution to solving installation and
- configuration issues is to take preventative measures by setting
- 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.</p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567648"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
-<p>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
- to the year 2000 to see if it will work. They then try to restore
- the old serial number. This will cause problems because serial
- 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.</p>
-<p>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.</p>
-<p>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.</p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567665"></a>Where Can I Get Help?</h2></div></div></div>
-<p>The Internet Software Consortium (<span class="acronym">ISC</span>) offers a wide range
- of support and service agreements for <span class="acronym">BIND</span> and <span class="acronym">DHCP</span> servers. Four
- levels of premium support are available and each level includes
- support for all <span class="acronym">ISC</span> programs, significant discounts on products
- and training, and a recognized priority on bug fixes and
- non-funded feature requests. In addition, <span class="acronym">ISC</span> offers a standard
- support agreement package which includes services ranging from bug
- fix announcements to remote support. It also includes training in
- <span class="acronym">BIND</span> and <span class="acronym">DHCP</span>.</p>
-<p>To discuss arrangements for support, contact
- <a href="mailto:info@isc.org" target="_top">info@isc.org</a> or visit the
- <span class="acronym">ISC</span> web page at <a href="http://www.isc.org/services/support/" target="_top">http://www.isc.org/services/support/</a>
- to read more.</p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Appendix A. Appendices</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch09.html b/contrib/bind9/doc/arm/Bv9ARM.ch09.html
deleted file mode 100644
index 8c7b2bf4450f7..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch09.html
+++ /dev/null
@@ -1,388 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch09.html,v 1.50.2.9.2.25 2005/10/13 02:34:03 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Appendix A. Appendices</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Appendix A. Appendices</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch08.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> </td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="appendix" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch09"></a>Appendix A. Appendices</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2567795">Acknowledgments</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2567800">A Brief History of the <span class="acronym">DNS</span> and <span class="acronym">BIND</span></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#historical_dns_information">General <span class="acronym">DNS</span> Reference Information</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2570087">Other Documents About <span class="acronym">BIND</span></a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567795"></a>Acknowledgments</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567800"></a>A Brief History of the <span class="acronym">DNS</span> and <span class="acronym">BIND</span></h3></div></div></div>
-<p>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
- Internet) became a testbed of experimentation for developing the
- new naming/addressing scheme in an rapidly expanding,
- operational network environment. New RFCs were written and
- published in 1987 that modified the original documents to
- 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 <span class="acronym">DNS</span> implementations are
- built.
-</p>
-<p>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 <span class="acronym">DNS</span> server for Unix machines, the Berkeley Internet
-Name Domain (<span class="acronym">BIND</span>) 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 <span class="acronym">BIND</span> 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 <span class="acronym">BIND</span>
-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 <span class="acronym">BIND</span> for 2 years, from 1985
-to 1987. Many other people also contributed to <span class="acronym">BIND</span> development
-during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell,
-Mike Muuss, Jim Bloom and Mike Schwartz. <span class="acronym">BIND</span> maintenance was subsequently
-handled by Mike Karels and O. Kure.</p>
-<p><span class="acronym">BIND</span> versions 4.9 and 4.9.1 were released by Digital Equipment
-Corporation (now Compaq Computer Corporation). Paul Vixie, then
-a DEC employee, became <span class="acronym">BIND</span>'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.</p>
-<p><span class="acronym">BIND</span> Version 4.9.2 was sponsored by Vixie Enterprises. Paul
-Vixie became <span class="acronym">BIND</span>'s principal architect/programmer.</p>
-<p><span class="acronym">BIND</span> 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 <span class="acronym">BIND</span> version
-8 in May 1997.</p>
-<p><span class="acronym">BIND</span> development work is made possible today by the sponsorship
-of several corporations, and by the tireless work efforts of numerous
-individuals.</p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="historical_dns_information"></a>General <span class="acronym">DNS</span> Reference Information</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="ipv6addresses"></a>IPv6 addresses (AAAA)</h3></div></div></div>
-<p>IPv6 addresses are 128-bit identifiers for interfaces and
-sets of interfaces which were introduced in the <span class="acronym">DNS</span> to facilitate
-scalable Internet routing. There are three types of addresses: <span class="emphasis"><em>Unicast</em></span>,
-an identifier for a single interface; <span class="emphasis"><em>Anycast</em></span>,
-an identifier for a set of interfaces; and <span class="emphasis"><em>Multicast</em></span>,
-an identifier for a set of interfaces. Here we describe the global
-Unicast address scheme. For more information, see RFC 2374.</p>
-<p>The aggregatable global Unicast address format is as follows:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p>3</p></td>
-<td><p>13</p></td>
-<td><p>8</p></td>
-<td><p>24</p></td>
-<td><p>16</p></td>
-<td><p>64 bits</p></td>
-</tr>
-<tr>
-<td><p>FP</p></td>
-<td><p>TLA ID</p></td>
-<td><p>RES</p></td>
-<td><p>NLA ID</p></td>
-<td><p>SLA ID</p></td>
-<td><p>Interface ID</p></td>
-</tr>
-<tr>
-<td colspan="4"><p>&lt;------ Public Topology
-------&gt;</p></td>
-<td><p></p></td>
-<td><p></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p></p></td>
-<td><p></p></td>
-<td><p></p></td>
-<td><p>&lt;-Site Topology-&gt;</p></td>
-<td><p></p></td>
-</tr>
-<tr>
-<td><p></p></td>
-<td><p></p></td>
-<td><p></p></td>
-<td><p></p></td>
-<td><p></p></td>
-<td><p>&lt;------ Interface Identifier ------&gt;</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>Where
-</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td><p>FP</p></td>
-<td><p>=</p></td>
-<td><p>Format Prefix (001)</p></td>
-</tr>
-<tr>
-<td><p>TLA ID</p></td>
-<td><p>=</p></td>
-<td><p>Top-Level Aggregation Identifier</p></td>
-</tr>
-<tr>
-<td><p>RES</p></td>
-<td><p>=</p></td>
-<td><p>Reserved for future use</p></td>
-</tr>
-<tr>
-<td><p>NLA ID</p></td>
-<td><p>=</p></td>
-<td><p>Next-Level Aggregation Identifier</p></td>
-</tr>
-<tr>
-<td><p>SLA ID</p></td>
-<td><p>=</p></td>
-<td><p>Site-Level Aggregation Identifier</p></td>
-</tr>
-<tr>
-<td><p>INTERFACE ID</p></td>
-<td><p>=</p></td>
-<td><p>Interface Identifier</p></td>
-</tr>
-</tbody>
-</table></div>
-<p>The <span class="emphasis"><em>Public Topology</em></span> is provided by the
-upstream provider or ISP, and (roughly) corresponds to the IPv4 <span class="emphasis"><em>network</em></span> section
-of the address range. The <span class="emphasis"><em>Site Topology</em></span> is
-where you can subnet this space, much the same as subnetting an
-IPv4 /16 network into /24 subnets. The <span class="emphasis"><em>Interface Identifier</em></span> is
-the address of an individual interface on a given network. (With
-IPv6, addresses belong to interfaces rather than machines.)</p>
-<p>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).</p>
-<p>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:</p>
-<p><span><strong class="command">2001:db8:201:9:a00:20ff:fe81:2b32</strong></span></p>
-<p>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.</p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="bibliography"></a>Bibliography (and Suggested Reading)</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="rfcs"></a>Request for Comments (RFCs)</h3></div></div></div>
-<p>Specification documents for the Internet protocol suite, including
-the <span class="acronym">DNS</span>, 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
-<a href="ftp://www.isi.edu/in-notes/" target="_top">ftp://www.isi.edu/in-notes/RFC<em class="replaceable"><code>xxx</code></em>.txt</a> (where <em class="replaceable"><code>xxx</code></em> is
-the number of the RFC). RFCs are also available via the Web at
-<a href="http://www.ietf.org/rfc/" target="_top">http://www.ietf.org/rfc/</a>.
-</p>
-<div class="bibliography">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2568712"></a>Bibliography</h4></div></div></div>
-<div class="bibliodiv">
-<h3 class="title">Standards</h3>
-<div class="biblioentry"><p>[<span class="abbrev">RFC974</span>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1034</span>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1035</span>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
-Specification</i>. </span><span class="pubdate">November 1987. </span></p></div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">
-<a name="proposed_standards"></a>Proposed Standards</h3>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2181</span>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <span class="acronym">DNS</span> Specification</i>. </span><span class="pubdate">July 1997. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2308</span>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <span class="acronym">DNS</span> Queries</i>. </span><span class="pubdate">March 1998. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1995</span>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <span class="acronym">DNS</span></i>. </span><span class="pubdate">August 1996. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1996</span>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2136</span>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2845</span>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <span class="acronym">DNS</span> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p></div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Proposed Standards Still Under Development</h3>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p><span class="emphasis"><em>Note:</em></span> the following list of
-RFCs are undergoing major revision by the IETF.</p>
-</div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1886</span>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i><span class="acronym">DNS</span> Extensions to support IP version 6</i>. </span><span class="pubdate">December 1995. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2065</span>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2137</span>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p></div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Other Important RFCs About <span class="acronym">DNS</span> Implementation</h3>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1535</span>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely Deployed <span class="acronym">DNS</span> Software.</i>. </span><span class="pubdate">October 1993. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1536</span>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <span class="acronym">DNS</span> Implementation Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1982</span>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p></div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Resource Record Types</h3>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1183</span>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <span class="acronym">DNS</span> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1706</span>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><span class="acronym">DNS</span> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2168</span>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
-the Domain Name System</i>. </span><span class="pubdate">June 1997. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1876</span>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the Domain
-Name System</i>. </span><span class="pubdate">January 1996. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2052</span>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <span class="acronym">DNS</span> RR for Specifying the Location of
-Services.</i>. </span><span class="pubdate">October 1996. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2163</span>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <span class="acronym">DNS</span> to Distribute MIXER
-Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2230</span>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <span class="acronym">DNS</span></i>. </span><span class="pubdate">October 1997. </span></p></div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">
-<span class="acronym">DNS</span> and the Internet</h3>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1101</span>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><span class="acronym">DNS</span> Encoding of Network Names and Other Types</i>. </span><span class="pubdate">April 1989. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1123</span>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and Support</i>. </span><span class="pubdate">October 1989. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1591</span>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2317</span>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p></div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">
-<span class="acronym">DNS</span> Operations</h3>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1537</span>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <span class="acronym">DNS</span> Data File Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1912</span>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <span class="acronym">DNS</span> Operational and Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2010</span>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2219</span>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <span class="acronym">DNS</span> Aliases for Network Services.</i>. </span><span class="pubdate">October 1997. </span></p></div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Other <span class="acronym">DNS</span>-related RFCs</h3>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>Note: the following list of RFCs, although
-<span class="acronym">DNS</span>-related, are not concerned with implementing software.</p>
-</div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1464</span>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String Attributes</i>. </span><span class="pubdate">May 1993. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1713</span>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <span class="acronym">DNS</span> Debugging</i>. </span><span class="pubdate">November 1994. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1794</span>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><span class="acronym">DNS</span> Support for Load Balancing</i>. </span><span class="pubdate">April 1995. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2240</span>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2345</span>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p></div>
-<div class="biblioentry"><p>[<span class="abbrev">RFC2352</span>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p></div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Obsolete and Unimplemented Experimental RRs</h3>
-<div class="biblioentry"><p>[<span class="abbrev">RFC1712</span>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><span class="acronym">DNS</span> Encoding of Geographical
-Location</i>. </span><span class="pubdate">November 1994. </span></p></div>
-</div>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="internet_drafts"></a>Internet Drafts</h3></div></div></div>
-<p>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.
-</p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2570087"></a>Other Documents About <span class="acronym">BIND</span></h3></div></div></div>
-<p></p>
-<div class="bibliography">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2570097"></a>Bibliography</h4></div></div></div>
-<div class="biblioentry"><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><span class="acronym">DNS</span> and <span class="acronym">BIND</span></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p></div>
-</div>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch08.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> </td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 8. Troubleshooting </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> </td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.html b/contrib/bind9/doc/arm/Bv9ARM.html
deleted file mode 100644
index 71ec32992eb09..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.html
+++ /dev/null
@@ -1,222 +0,0 @@
-<!--
- - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.html,v 1.60.2.9.2.26 2005/10/13 02:33:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>BIND 9 Administrator Reference Manual</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="next" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction ">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">BIND 9 Administrator Reference Manual</th></tr>
-<tr>
-<td width="20%" align="left"> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch01.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="book" lang="en">
-<div class="titlepage">
-<div>
-<div><h1 class="title">
-<a name="id2463864"></a>BIND 9 Administrator Reference Manual</h1></div>
-<div><p class="copyright">Copyright © 2004, 2005 Internet Systems Consortium, Inc. ("ISC")</p></div>
-<div><p class="copyright">Copyright © 2000-2003 Internet Software Consortium.</p></div>
-</div>
-<hr>
-</div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="chapter"><a href="Bv9ARM.ch01.html">1. Introduction </a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545879">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545905">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545976">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2546234">The Domain Name System (<span class="acronym">DNS</span>)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546254">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2544105">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546579">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546653">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546950">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2547076">Name Servers in Multiple Roles</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch02.html">2. <span class="acronym">BIND</span> Resource Requirements</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547108">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547132">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547143">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547158">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547303">Supported Operating Systems</a></span></dt>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch03.html">3. Name Server Configuration</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547334">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547350">An Authoritative-only Name Server</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2547372">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2547656">Name Server Operations</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547661">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2548915">Signals</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch04.html">4. Advanced DNS Features</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2549203">Split DNS</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549627">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549830">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549838">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549878">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549998">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550042">Errors</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550056">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550173">SIG(0)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550308">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550375">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550450">Configuring Servers</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550473">IPv6 Support in <span class="acronym">BIND</span> 9</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550600">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550620">Address to Name Lookups Using Nibble Format</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch05.html">5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2550652">The Lightweight Resolver Library</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch06.html">6. <span class="acronym">BIND</span> 9 Configuration Reference</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2551817">Comment Syntax</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552302"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
-Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552471"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552808"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552823"><span><strong class="command">include</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552845"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552867"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553006"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553269"><span><strong class="command">logging</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554474"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554547"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554610"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554653"><span><strong class="command">masters</strong></span> Statement Definition and Usage </a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554668"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562233"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562281"><span><strong class="command">trusted-keys</strong></span> Statement Definition
-and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562349"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
-Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2563022"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2564557">Zone File</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2565990">Discussion of MX Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566487">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566593">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566761"><span class="acronym">BIND</span> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <span class="acronym">BIND</span> 9 Security Considerations</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2567222"><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
-UNIX servers)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567366">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567424">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch08.html">8. Troubleshooting</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567630">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2567636">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567648">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567665">Where Can I Get Help?</a></span></dt>
-</dl></dd>
-<dt><span class="appendix"><a href="Bv9ARM.ch09.html">A. Appendices</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2567795">Acknowledgments</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2567800">A Brief History of the <span class="acronym">DNS</span> and <span class="acronym">BIND</span></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#historical_dns_information">General <span class="acronym">DNS</span> Reference Information</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2570087">Other Documents About <span class="acronym">BIND</span></a></span></dt>
-</dl></dd>
-</dl></dd>
-</dl>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left"> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch01.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top"> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right" valign="top"> Chapter 1. Introduction </td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.pdf b/contrib/bind9/doc/arm/Bv9ARM.pdf
deleted file mode 100755
index 6119ca4ce244d..0000000000000
--- a/contrib/bind9/doc/arm/Bv9ARM.pdf
+++ /dev/null
@@ -1,8964 +0,0 @@
-%PDF-1.4
-5 0 obj
-<< /S /GoTo /D (chapter.1) >>
-endobj
-8 0 obj
-(1 Introduction)
-endobj
-9 0 obj
-<< /S /GoTo /D (section.1.1) >>
-endobj
-12 0 obj
-(1.1 Scope of Document)
-endobj
-13 0 obj
-<< /S /GoTo /D (section.1.2) >>
-endobj
-16 0 obj
-(1.2 Organization of This Document)
-endobj
-17 0 obj
-<< /S /GoTo /D (section.1.3) >>
-endobj
-20 0 obj
-(1.3 Conventions Used in This Document)
-endobj
-21 0 obj
-<< /S /GoTo /D (section.1.4) >>
-endobj
-24 0 obj
-(1.4 The Domain Name System \(DNS\))
-endobj
-25 0 obj
-<< /S /GoTo /D (subsection.1.4.1) >>
-endobj
-28 0 obj
-(1.4.1 DNS Fundamentals)
-endobj
-29 0 obj
-<< /S /GoTo /D (subsection.1.4.2) >>
-endobj
-32 0 obj
-(1.4.2 Domains and Domain Names)
-endobj
-33 0 obj
-<< /S /GoTo /D (subsection.1.4.3) >>
-endobj
-36 0 obj
-(1.4.3 Zones)
-endobj
-37 0 obj
-<< /S /GoTo /D (subsection.1.4.4) >>
-endobj
-40 0 obj
-(1.4.4 Authoritative Name Servers)
-endobj
-41 0 obj
-<< /S /GoTo /D (subsubsection.1.4.4.1) >>
-endobj
-44 0 obj
-(1.4.4.1 The Primary Master)
-endobj
-45 0 obj
-<< /S /GoTo /D (subsubsection.1.4.4.2) >>
-endobj
-48 0 obj
-(1.4.4.2 Slave Servers)
-endobj
-49 0 obj
-<< /S /GoTo /D (subsubsection.1.4.4.3) >>
-endobj
-52 0 obj
-(1.4.4.3 Stealth Servers)
-endobj
-53 0 obj
-<< /S /GoTo /D (subsection.1.4.5) >>
-endobj
-56 0 obj
-(1.4.5 Caching Name Servers)
-endobj
-57 0 obj
-<< /S /GoTo /D (subsubsection.1.4.5.1) >>
-endobj
-60 0 obj
-(1.4.5.1 Forwarding)
-endobj
-61 0 obj
-<< /S /GoTo /D (subsection.1.4.6) >>
-endobj
-64 0 obj
-(1.4.6 Name Servers in Multiple Roles)
-endobj
-65 0 obj
-<< /S /GoTo /D (chapter.2) >>
-endobj
-68 0 obj
-(2 BIND Resource Requirements)
-endobj
-69 0 obj
-<< /S /GoTo /D (section.2.1) >>
-endobj
-72 0 obj
-(2.1 Hardware requirements)
-endobj
-73 0 obj
-<< /S /GoTo /D (section.2.2) >>
-endobj
-76 0 obj
-(2.2 CPU Requirements)
-endobj
-77 0 obj
-<< /S /GoTo /D (section.2.3) >>
-endobj
-80 0 obj
-(2.3 Memory Requirements)
-endobj
-81 0 obj
-<< /S /GoTo /D (section.2.4) >>
-endobj
-84 0 obj
-(2.4 Name Server Intensive Environment Issues)
-endobj
-85 0 obj
-<< /S /GoTo /D (section.2.5) >>
-endobj
-88 0 obj
-(2.5 Supported Operating Systems)
-endobj
-89 0 obj
-<< /S /GoTo /D (chapter.3) >>
-endobj
-92 0 obj
-(3 Name Server Configuration)
-endobj
-93 0 obj
-<< /S /GoTo /D (section.3.1) >>
-endobj
-96 0 obj
-(3.1 Sample Configurations)
-endobj
-97 0 obj
-<< /S /GoTo /D (subsection.3.1.1) >>
-endobj
-100 0 obj
-(3.1.1 A Caching-only Name Server)
-endobj
-101 0 obj
-<< /S /GoTo /D (subsection.3.1.2) >>
-endobj
-104 0 obj
-(3.1.2 An Authoritative-only Name Server)
-endobj
-105 0 obj
-<< /S /GoTo /D (section.3.2) >>
-endobj
-108 0 obj
-(3.2 Load Balancing)
-endobj
-109 0 obj
-<< /S /GoTo /D (section.3.3) >>
-endobj
-112 0 obj
-(3.3 Name Server Operations)
-endobj
-113 0 obj
-<< /S /GoTo /D (subsection.3.3.1) >>
-endobj
-116 0 obj
-(3.3.1 Tools for Use With the Name Server Daemon)
-endobj
-117 0 obj
-<< /S /GoTo /D (subsubsection.3.3.1.1) >>
-endobj
-120 0 obj
-(3.3.1.1 Diagnostic Tools)
-endobj
-121 0 obj
-<< /S /GoTo /D (subsubsection.3.3.1.2) >>
-endobj
-124 0 obj
-(3.3.1.2 Administrative Tools)
-endobj
-125 0 obj
-<< /S /GoTo /D (subsection.3.3.2) >>
-endobj
-128 0 obj
-(3.3.2 Signals)
-endobj
-129 0 obj
-<< /S /GoTo /D (chapter.4) >>
-endobj
-132 0 obj
-(4 Advanced DNS Features)
-endobj
-133 0 obj
-<< /S /GoTo /D (section.4.1) >>
-endobj
-136 0 obj
-(4.1 Notify)
-endobj
-137 0 obj
-<< /S /GoTo /D (section.4.2) >>
-endobj
-140 0 obj
-(4.2 Dynamic Update)
-endobj
-141 0 obj
-<< /S /GoTo /D (subsection.4.2.1) >>
-endobj
-144 0 obj
-(4.2.1 The journal file)
-endobj
-145 0 obj
-<< /S /GoTo /D (section.4.3) >>
-endobj
-148 0 obj
-(4.3 Incremental Zone Transfers \(IXFR\))
-endobj
-149 0 obj
-<< /S /GoTo /D (section.4.4) >>
-endobj
-152 0 obj
-(4.4 Split DNS)
-endobj
-153 0 obj
-<< /S /GoTo /D (section.4.5) >>
-endobj
-156 0 obj
-(4.5 TSIG)
-endobj
-157 0 obj
-<< /S /GoTo /D (subsection.4.5.1) >>
-endobj
-160 0 obj
-(4.5.1 Generate Shared Keys for Each Pair of Hosts)
-endobj
-161 0 obj
-<< /S /GoTo /D (subsubsection.4.5.1.1) >>
-endobj
-164 0 obj
-(4.5.1.1 Automatic Generation)
-endobj
-165 0 obj
-<< /S /GoTo /D (subsubsection.4.5.1.2) >>
-endobj
-168 0 obj
-(4.5.1.2 Manual Generation)
-endobj
-169 0 obj
-<< /S /GoTo /D (subsection.4.5.2) >>
-endobj
-172 0 obj
-(4.5.2 Copying the Shared Secret to Both Machines)
-endobj
-173 0 obj
-<< /S /GoTo /D (subsection.4.5.3) >>
-endobj
-176 0 obj
-(4.5.3 Informing the Servers of the Key's Existence)
-endobj
-177 0 obj
-<< /S /GoTo /D (subsection.4.5.4) >>
-endobj
-180 0 obj
-(4.5.4 Instructing the Server to Use the Key)
-endobj
-181 0 obj
-<< /S /GoTo /D (subsection.4.5.5) >>
-endobj
-184 0 obj
-(4.5.5 TSIG Key Based Access Control)
-endobj
-185 0 obj
-<< /S /GoTo /D (subsection.4.5.6) >>
-endobj
-188 0 obj
-(4.5.6 Errors)
-endobj
-189 0 obj
-<< /S /GoTo /D (section.4.6) >>
-endobj
-192 0 obj
-(4.6 TKEY)
-endobj
-193 0 obj
-<< /S /GoTo /D (section.4.7) >>
-endobj
-196 0 obj
-(4.7 SIG\(0\))
-endobj
-197 0 obj
-<< /S /GoTo /D (section.4.8) >>
-endobj
-200 0 obj
-(4.8 DNSSEC)
-endobj
-201 0 obj
-<< /S /GoTo /D (subsection.4.8.1) >>
-endobj
-204 0 obj
-(4.8.1 Generating Keys)
-endobj
-205 0 obj
-<< /S /GoTo /D (subsection.4.8.2) >>
-endobj
-208 0 obj
-(4.8.2 Signing the Zone)
-endobj
-209 0 obj
-<< /S /GoTo /D (subsection.4.8.3) >>
-endobj
-212 0 obj
-(4.8.3 Configuring Servers)
-endobj
-213 0 obj
-<< /S /GoTo /D (section.4.9) >>
-endobj
-216 0 obj
-(4.9 IPv6 Support in BIND 9)
-endobj
-217 0 obj
-<< /S /GoTo /D (subsection.4.9.1) >>
-endobj
-220 0 obj
-(4.9.1 Address Lookups Using AAAA Records)
-endobj
-221 0 obj
-<< /S /GoTo /D (subsection.4.9.2) >>
-endobj
-224 0 obj
-(4.9.2 Address to Name Lookups Using Nibble Format)
-endobj
-225 0 obj
-<< /S /GoTo /D (chapter.5) >>
-endobj
-228 0 obj
-(5 The BIND 9 Lightweight Resolver)
-endobj
-229 0 obj
-<< /S /GoTo /D (section.5.1) >>
-endobj
-232 0 obj
-(5.1 The Lightweight Resolver Library)
-endobj
-233 0 obj
-<< /S /GoTo /D (section.5.2) >>
-endobj
-236 0 obj
-(5.2 Running a Resolver Daemon)
-endobj
-237 0 obj
-<< /S /GoTo /D (chapter.6) >>
-endobj
-240 0 obj
-(6 BIND 9 Configuration Reference)
-endobj
-241 0 obj
-<< /S /GoTo /D (section.6.1) >>
-endobj
-244 0 obj
-(6.1 Configuration File Elements)
-endobj
-245 0 obj
-<< /S /GoTo /D (subsection.6.1.1) >>
-endobj
-248 0 obj
-(6.1.1 Address Match Lists)
-endobj
-249 0 obj
-<< /S /GoTo /D (subsubsection.6.1.1.1) >>
-endobj
-252 0 obj
-(6.1.1.1 Syntax)
-endobj
-253 0 obj
-<< /S /GoTo /D (subsubsection.6.1.1.2) >>
-endobj
-256 0 obj
-(6.1.1.2 Definition and Usage)
-endobj
-257 0 obj
-<< /S /GoTo /D (subsection.6.1.2) >>
-endobj
-260 0 obj
-(6.1.2 Comment Syntax)
-endobj
-261 0 obj
-<< /S /GoTo /D (subsubsection.6.1.2.1) >>
-endobj
-264 0 obj
-(6.1.2.1 Syntax)
-endobj
-265 0 obj
-<< /S /GoTo /D (subsubsection.6.1.2.2) >>
-endobj
-268 0 obj
-(6.1.2.2 Definition and Usage)
-endobj
-269 0 obj
-<< /S /GoTo /D (section.6.2) >>
-endobj
-272 0 obj
-(6.2 Configuration File Grammar)
-endobj
-273 0 obj
-<< /S /GoTo /D (subsection.6.2.1) >>
-endobj
-276 0 obj
-(6.2.1 acl Statement Grammar)
-endobj
-277 0 obj
-<< /S /GoTo /D (subsection.6.2.2) >>
-endobj
-280 0 obj
-(6.2.2 acl Statement Definition and Usage)
-endobj
-281 0 obj
-<< /S /GoTo /D (subsection.6.2.3) >>
-endobj
-284 0 obj
-(6.2.3 controls Statement Grammar)
-endobj
-285 0 obj
-<< /S /GoTo /D (subsection.6.2.4) >>
-endobj
-288 0 obj
-(6.2.4 controls Statement Definition and Usage)
-endobj
-289 0 obj
-<< /S /GoTo /D (subsection.6.2.5) >>
-endobj
-292 0 obj
-(6.2.5 include Statement Grammar)
-endobj
-293 0 obj
-<< /S /GoTo /D (subsection.6.2.6) >>
-endobj
-296 0 obj
-(6.2.6 include Statement Definition and Usage)
-endobj
-297 0 obj
-<< /S /GoTo /D (subsection.6.2.7) >>
-endobj
-300 0 obj
-(6.2.7 key Statement Grammar)
-endobj
-301 0 obj
-<< /S /GoTo /D (subsection.6.2.8) >>
-endobj
-304 0 obj
-(6.2.8 key Statement Definition and Usage)
-endobj
-305 0 obj
-<< /S /GoTo /D (subsection.6.2.9) >>
-endobj
-308 0 obj
-(6.2.9 logging Statement Grammar)
-endobj
-309 0 obj
-<< /S /GoTo /D (subsection.6.2.10) >>
-endobj
-312 0 obj
-(6.2.10 logging Statement Definition and Usage)
-endobj
-313 0 obj
-<< /S /GoTo /D (subsubsection.6.2.10.1) >>
-endobj
-316 0 obj
-(6.2.10.1 The channel Phrase)
-endobj
-317 0 obj
-<< /S /GoTo /D (subsubsection.6.2.10.2) >>
-endobj
-320 0 obj
-(6.2.10.2 The category Phrase)
-endobj
-321 0 obj
-<< /S /GoTo /D (subsection.6.2.11) >>
-endobj
-324 0 obj
-(6.2.11 lwres Statement Grammar)
-endobj
-325 0 obj
-<< /S /GoTo /D (subsection.6.2.12) >>
-endobj
-328 0 obj
-(6.2.12 lwres Statement Definition and Usage)
-endobj
-329 0 obj
-<< /S /GoTo /D (subsection.6.2.13) >>
-endobj
-332 0 obj
-(6.2.13 masters Statement Grammar)
-endobj
-333 0 obj
-<< /S /GoTo /D (subsection.6.2.14) >>
-endobj
-336 0 obj
-(6.2.14 masters Statement Definition and Usage)
-endobj
-337 0 obj
-<< /S /GoTo /D (subsection.6.2.15) >>
-endobj
-340 0 obj
-(6.2.15 options Statement Grammar)
-endobj
-341 0 obj
-<< /S /GoTo /D (subsection.6.2.16) >>
-endobj
-344 0 obj
-(6.2.16 options Statement Definition and Usage)
-endobj
-345 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.1) >>
-endobj
-348 0 obj
-(6.2.16.1 Boolean Options)
-endobj
-349 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.2) >>
-endobj
-352 0 obj
-(6.2.16.2 Forwarding)
-endobj
-353 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.3) >>
-endobj
-356 0 obj
-(6.2.16.3 Dual-stack Servers)
-endobj
-357 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.4) >>
-endobj
-360 0 obj
-(6.2.16.4 Access Control)
-endobj
-361 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.5) >>
-endobj
-364 0 obj
-(6.2.16.5 Interfaces)
-endobj
-365 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.6) >>
-endobj
-368 0 obj
-(6.2.16.6 Query Address)
-endobj
-369 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.7) >>
-endobj
-372 0 obj
-(6.2.16.7 Zone Transfers)
-endobj
-373 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.8) >>
-endobj
-376 0 obj
-(6.2.16.8 Bad UDP Port Lists)
-endobj
-377 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.9) >>
-endobj
-380 0 obj
-(6.2.16.9 Operating System Resource Limits)
-endobj
-381 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.10) >>
-endobj
-384 0 obj
-(6.2.16.10 Server Resource Limits)
-endobj
-385 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.11) >>
-endobj
-388 0 obj
-(6.2.16.11 Periodic Task Intervals)
-endobj
-389 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.12) >>
-endobj
-392 0 obj
-(6.2.16.12 Topology)
-endobj
-393 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.13) >>
-endobj
-396 0 obj
-(6.2.16.13 The sortlist Statement)
-endobj
-397 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.14) >>
-endobj
-400 0 obj
-(6.2.16.14 RRset Ordering)
-endobj
-401 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.15) >>
-endobj
-404 0 obj
-(6.2.16.15 Tuning)
-endobj
-405 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.16) >>
-endobj
-408 0 obj
-(6.2.16.16 Built-in server information zones)
-endobj
-409 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.17) >>
-endobj
-412 0 obj
-(6.2.16.17 The Statistics File)
-endobj
-413 0 obj
-<< /S /GoTo /D (subsection.6.2.17) >>
-endobj
-416 0 obj
-(6.2.17 server Statement Grammar)
-endobj
-417 0 obj
-<< /S /GoTo /D (subsection.6.2.18) >>
-endobj
-420 0 obj
-(6.2.18 server Statement Definition and Usage)
-endobj
-421 0 obj
-<< /S /GoTo /D (subsection.6.2.19) >>
-endobj
-424 0 obj
-(6.2.19 trusted-keys Statement Grammar)
-endobj
-425 0 obj
-<< /S /GoTo /D (subsection.6.2.20) >>
-endobj
-428 0 obj
-(6.2.20 trusted-keys Statement Definition and Usage)
-endobj
-429 0 obj
-<< /S /GoTo /D (subsection.6.2.21) >>
-endobj
-432 0 obj
-(6.2.21 view Statement Grammar)
-endobj
-433 0 obj
-<< /S /GoTo /D (subsection.6.2.22) >>
-endobj
-436 0 obj
-(6.2.22 view Statement Definition and Usage)
-endobj
-437 0 obj
-<< /S /GoTo /D (subsection.6.2.23) >>
-endobj
-440 0 obj
-(6.2.23 zone Statement Grammar)
-endobj
-441 0 obj
-<< /S /GoTo /D (subsection.6.2.24) >>
-endobj
-444 0 obj
-(6.2.24 zone Statement Definition and Usage)
-endobj
-445 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.1) >>
-endobj
-448 0 obj
-(6.2.24.1 Zone Types)
-endobj
-449 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.2) >>
-endobj
-452 0 obj
-(6.2.24.2 Class)
-endobj
-453 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.3) >>
-endobj
-456 0 obj
-(6.2.24.3 Zone Options)
-endobj
-457 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.4) >>
-endobj
-460 0 obj
-(6.2.24.4 Dynamic Update Policies)
-endobj
-461 0 obj
-<< /S /GoTo /D (section.6.3) >>
-endobj
-464 0 obj
-(6.3 Zone File)
-endobj
-465 0 obj
-<< /S /GoTo /D (subsection.6.3.1) >>
-endobj
-468 0 obj
-(6.3.1 Types of Resource Records and When to Use Them)
-endobj
-469 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.1) >>
-endobj
-472 0 obj
-(6.3.1.1 Resource Records)
-endobj
-473 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.2) >>
-endobj
-476 0 obj
-(6.3.1.2 Textual expression of RRs)
-endobj
-477 0 obj
-<< /S /GoTo /D (subsection.6.3.2) >>
-endobj
-480 0 obj
-(6.3.2 Discussion of MX Records)
-endobj
-481 0 obj
-<< /S /GoTo /D (subsection.6.3.3) >>
-endobj
-484 0 obj
-(6.3.3 Setting TTLs)
-endobj
-485 0 obj
-<< /S /GoTo /D (subsection.6.3.4) >>
-endobj
-488 0 obj
-(6.3.4 Inverse Mapping in IPv4)
-endobj
-489 0 obj
-<< /S /GoTo /D (subsection.6.3.5) >>
-endobj
-492 0 obj
-(6.3.5 Other Zone File Directives)
-endobj
-493 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.1) >>
-endobj
-496 0 obj
-(6.3.5.1 The \044ORIGIN Directive)
-endobj
-497 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.2) >>
-endobj
-500 0 obj
-(6.3.5.2 The \044INCLUDE Directive)
-endobj
-501 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.3) >>
-endobj
-504 0 obj
-(6.3.5.3 The \044TTL Directive)
-endobj
-505 0 obj
-<< /S /GoTo /D (subsection.6.3.6) >>
-endobj
-508 0 obj
-(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
-endobj
-509 0 obj
-<< /S /GoTo /D (chapter.7) >>
-endobj
-512 0 obj
-(7 BIND 9 Security Considerations)
-endobj
-513 0 obj
-<< /S /GoTo /D (section.7.1) >>
-endobj
-516 0 obj
-(7.1 Access Control Lists)
-endobj
-517 0 obj
-<< /S /GoTo /D (section.7.2) >>
-endobj
-520 0 obj
-(7.2 chroot and setuid \(for UNIX servers\))
-endobj
-521 0 obj
-<< /S /GoTo /D (subsection.7.2.1) >>
-endobj
-524 0 obj
-(7.2.1 The chroot Environment)
-endobj
-525 0 obj
-<< /S /GoTo /D (subsection.7.2.2) >>
-endobj
-528 0 obj
-(7.2.2 Using the setuid Function)
-endobj
-529 0 obj
-<< /S /GoTo /D (section.7.3) >>
-endobj
-532 0 obj
-(7.3 Dynamic Update Security)
-endobj
-533 0 obj
-<< /S /GoTo /D (chapter.8) >>
-endobj
-536 0 obj
-(8 Troubleshooting)
-endobj
-537 0 obj
-<< /S /GoTo /D (section.8.1) >>
-endobj
-540 0 obj
-(8.1 Common Problems)
-endobj
-541 0 obj
-<< /S /GoTo /D (subsection.8.1.1) >>
-endobj
-544 0 obj
-(8.1.1 It's not working; how can I figure out what's wrong?)
-endobj
-545 0 obj
-<< /S /GoTo /D (section.8.2) >>
-endobj
-548 0 obj
-(8.2 Incrementing and Changing the Serial Number)
-endobj
-549 0 obj
-<< /S /GoTo /D (section.8.3) >>
-endobj
-552 0 obj
-(8.3 Where Can I Get Help?)
-endobj
-553 0 obj
-<< /S /GoTo /D (appendix.A) >>
-endobj
-556 0 obj
-(A Appendices)
-endobj
-557 0 obj
-<< /S /GoTo /D (section.A.1) >>
-endobj
-560 0 obj
-(A.1 Acknowledgments)
-endobj
-561 0 obj
-<< /S /GoTo /D (subsection.A.1.1) >>
-endobj
-564 0 obj
-(A.1.1 A Brief History of the DNS and BIND)
-endobj
-565 0 obj
-<< /S /GoTo /D (section.A.2) >>
-endobj
-568 0 obj
-(A.2 General DNS Reference Information)
-endobj
-569 0 obj
-<< /S /GoTo /D (subsection.A.2.1) >>
-endobj
-572 0 obj
-(A.2.1 IPv6 addresses \(AAAA\))
-endobj
-573 0 obj
-<< /S /GoTo /D (section.A.3) >>
-endobj
-576 0 obj
-(A.3 Bibliography \(and Suggested Reading\))
-endobj
-577 0 obj
-<< /S /GoTo /D (subsection.A.3.1) >>
-endobj
-580 0 obj
-(A.3.1 Request for Comments \(RFCs\))
-endobj
-581 0 obj
-<< /S /GoTo /D (subsection.A.3.2) >>
-endobj
-584 0 obj
-(A.3.2 Internet Drafts)
-endobj
-585 0 obj
-<< /S /GoTo /D (subsection.A.3.3) >>
-endobj
-588 0 obj
-(A.3.3 Other Documents About BIND)
-endobj
-589 0 obj
-<< /S /GoTo /D [590 0 R /FitH ] >>
-endobj
-592 0 obj <<
-/Length 221
-/Filter /FlateDecode
->>
-stream
-xÚOKA Åïû)rlÁ‰“Ý™£¥*
-ö s“Öv*…îÖêçw¶[‹ É!$ùñy¾A0ôê¨hž Ömåá­Üî+:3j‚¦"eøãê$
-•
-endobj
-590 0 obj <<
-/Type /Page
-/Contents 592 0 R
-/Resources 591 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 601 0 R
->> endobj
-593 0 obj <<
-/D [590 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-594 0 obj <<
-/D [590 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-591 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-604 0 obj <<
-/Length 302
-/Filter /FlateDecode
->>
-stream
-xÚµ’ÁNÃ0 @ïýŠWiõ;N–+CãºÞ4º±ÃZÔ¡ý= ekCì‚zˆ-?ÙÉ«µÂði%¬'¯œ7 ¨E­v ªM¨Ý%ú‹1 †9$ª»)’„ÈÀ4tR?hÍÈìTæÄƒeâˆßÉdfXyð–¬*ÖJ³ƒxŸU<?ŒòúõÐl7/múXÜ+Apèõ€;` “™6ƒN³> pËкC¿%!šqš‘` ¥‹æU[6UÙvÙâ°oËݾKòºÚ×M»}Ûì
-ÒŒ5†y‚K"3_äñ©Žã“Ûâd&Šk­rF‡âåOŸt6Ä/kã|ßõ7ôŸ±÷¨ûú/Ú­×íûS“êé¨<W çþŽ›ÌqW¯ÞãÊ´­Jendstream
-endobj
-603 0 obj <<
-/Type /Page
-/Contents 604 0 R
-/Resources 602 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 601 0 R
->> endobj
-605 0 obj <<
-/D [603 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-602 0 obj <<
-/Font << /F43 600 0 R /F14 608 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-611 0 obj <<
-/Length 2204
-/Filter /FlateDecode
->>
-stream
-xÚÝYKã6¾ûWø¨ÆZ>ÄWn;3›Å‹Yìv9$9¨%¶-Œ,)ztÇùõ[d‘¶lË3ƒ6X4ЦJ,²XõÕWE›® üѵ)á&[+“¥‚P±.ö+²Þ»¿¯h˜“ žŠŒsxXx»\§B3µÞÌyû°úË÷[3’JÉÄúá鸗T:5<3ë‡òçäÝ.ïFÛßm˜ ½ûõáTËR¥uj¶©2D{…ÍØ·åTŒUÛ„é|mR#™Œ³肹nöÃÎÂÒZ:5Û7vħ÷í>¯Ì÷aÎýaíÇ¿AÞ¼‡ê*)Úf¨†qÀ×í~ŽqýáÐŒùïAØYg‹êép1³ý.V±ÍXJURÝѤÁ¡S‚3ºSQš!XôA8 g$qáŒ&9>î*ÛçýÕI±«Š¼Fé>op³Ê’7 àíqoú;LµÛÜ-2 ¶DùSÛã ´µÝæcÕlÃ>Ó¸kûj3(iŸm˜ëvÈ›°RØŠ‚“¼ƒÏNDý‰ª}WÛ=ø!÷qÝ00tÜå.\J$y1Ny]P¾Ï»GÑ•0ÅûD³8;Ųôž°Ã`‡ŒÐ<¨âÔ2sœV qå
-,¨ç÷ì!â–ÁÇ­_«:”BôbSHúêqý"b)Nê6̽Uó4Ky&Y@qFR&9bž¦
-.ƒpŽ(£cžÀØeÄÛ߇”
-Îzè°Ÿ-&¸
-D’­m<ìpҡèàíÆµáGó¿sV­þöpüöÆHh5]S¡S"¡•+ö«ßV?ÿJÖ劬X‘”-Ö/ð
-ûUÆaH„Ž’zu¿úש혵7-@=k…aõùR›x¦ Í$l©éñû¨ 8ó”r“J“…{ŽošÂ%Ö¼+·q&R˜§×ó-¾Íêã’_0›CØieÎÍþéñ&\†ñP_B¸ÎX
-ñЇÈ\:4W› û¿ƒãPé¡Kÿú3E›pbøÏðÓ×›|N®ÁÌmrǯÜÀÇû"ÄÑmÆáFOXm–üøï¼Á™»vg3×êX×.¾8¨H1ºa¾¿ú†Ë}c_l¿?:ÖÛˆžòÛ7Cô¥ç„ZDôÌsßW¿;Ž•@¿/U9înƒ÷Õìý7ú¹èI¾
-endobj
-610 0 obj <<
-/Type /Page
-/Contents 611 0 R
-/Resources 609 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 601 0 R
->> endobj
-612 0 obj <<
-/D [610 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-6 0 obj <<
-/D [610 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-613 0 obj <<
-/D [610 0 R /XYZ 85.0394 582.8476 null]
->> endobj
-10 0 obj <<
-/D [610 0 R /XYZ 85.0394 512.9824 null]
->> endobj
-614 0 obj <<
-/D [610 0 R /XYZ 85.0394 474.7837 null]
->> endobj
-14 0 obj <<
-/D [610 0 R /XYZ 85.0394 399.5462 null]
->> endobj
-615 0 obj <<
-/D [610 0 R /XYZ 85.0394 363.8828 null]
->> endobj
-18 0 obj <<
-/D [610 0 R /XYZ 85.0394 223.0066 null]
->> endobj
-619 0 obj <<
-/D [610 0 R /XYZ 85.0394 190.9009 null]
->> endobj
-620 0 obj <<
-/D [610 0 R /XYZ 85.0394 170.4169 null]
->> endobj
-621 0 obj <<
-/D [610 0 R /XYZ 85.0394 158.4617 null]
->> endobj
-609 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F58 627 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-630 0 obj <<
-/Length 3297
-/Filter /FlateDecode
->>
-stream
-xÚÍZÝsÛÆ×_ÁGhÆDï8àúæÄv£ÌÄN-u2m’
-·ú]ù=ÛüTæýÃóÚ"FìŸ\]FB'_W—T°› xð˜ÊlS¨®F\üyue,ÄÇ(¿®+±6¦4óÁ…»¬ò‘°=öpqðóݵUAñ¥ç9މE½­šYìì>'ÑusȶŸŠ¾ûõYŽyý£4zÎ0ÿ𪄠Ó’ÒLk=Nu³”§’4ŒR )Ï€ý4$ë³Õ@Ô(ÔäÃQÎ3°«° 9†`'~;d¿7Í>óæxŸí™zûÔõÅ~ÜÕ˜¸dOØÄ޲jª‚öxh‰SIˆýƒó äÍö¸‡4Kt¢Â|C³Å—¶"®ÜK¼KYw}VU>sÂTVç48¶ŸŠ¢½<Œßãô ¤®Ùõ§³Ç!›àpÙ}ñ
-%g:”…vQpÂÅàÛ›âÞ1¤Í‘h¯Ç²`
-ßV%˜ÞÅî8¨šæŽ-='*%=rÅÞL°¹–Á Á”ÃlpcN³f’f!$§&â4ËÚl*ÐÙ‚ j )AK^\•<O%¾¢óNà=tZWÔ9KóùXJg ˜mĦf¾›=÷ìC \®•Ñ¡²6ö:§œX“·»Ãhå–!(§ŠÅ9¼h§<°MKç¡ÎµW$X -XªèÐÓUÌ·-Ž9²áÈòÑ“
-^ ±c$<‹0q7|9_²­Õ†å}žW³kö'Fó;;
-¬´Ä‚T*L’T _Å’º#H¸Âª‘¾v—‹17ûÍ6e½( ¤V!ý^‹au­¢$Œ5:ÆexU>¼ºðØ]hâ2%àšQ¸•
-
-^OaÝÇ…¥ºðˆ¢©+Æßp©KHª4>•€ñ9”•=º–o~Íðƒox¼Ã{©¥… Û·^&­
- v}¬ÏX0Ú¹w”ð«­á(ã'A…ý·}›ÕKaNÅ
-®ˆðNóvrüM½ —J”¿šÛæXåtÞ¦Xh"D°’Œ6Ë*d!C`ka{GR7Ÿ<3–¡ˆaÁÄ3O Gx%™ªdàré(È‚V¤^ôniSR”¬àZ-Qªâ=‡ÞnaCëqÍY‰¡²õ±®9ÐF/ˆ/eÆ‘õ™\±©ï="˜l¯1’
-/!ﺄt˜Ê!âz)3â½;nÎ1Bfš„IES=Ãå\Ü J^P0Öö*C¡{Ò
-B†Oƒ³qù°à®ié ŽÁtáK4¼ Ý «&÷cT¤Á à±þÂ…㊠Ûýç›e8 ÀµÓÈxV‡eí¦o¶MµT«AôUƒ€¡
-2”6¾¸/d€$e8Ž£¬ëšmÉ)~c^¤›#9GP³aäŒω1Î+{£  Qir_T©ÑPýø"ëHÞƒ¨€¬óE Ÿ
-nÏ´ 1Ì)*¡q<u´îض͡÷þµÀÓ@õhŸ-ûÔKŸãü‡ ³Ã^4ŽU1‚©‚úÍJ)±[Js‡û >NÚ«´|=^?ï‰ÏvEán‹íù›ÔL¡¼d!¿”JN¸™µx‡U/01ßmä¨*´!­ZDWæÜÞp•V^¸¸QVT‰%-3¬¾è
-N
-JÐ}y_s5·[®6¹æÊ¹ÙÔø: 5
-ê<eX¿¿0·Ò|ß™¯¼^òñÒ)'üÌ?øU/p1ßíù.rlMªæ] Í]Œ=“{§=
-ü„6ÓC¨m‹ÖHÁ±kXkenׂÐbÒƒ‚âK špxÞ(÷G²šÉ=Ÿe;¤ž|NsºÀA^îƒgÖzË'oŠþT`y†‹–Ò\$L˜¥G¨c tH@ª‰œ4öžÙЕ–PœG‹µøKå¿¿ÝLäËM
-º±±ûZÑô@­r µþ;Esì*בå>i¤`À5”RñÍ’wÊègÛ”NÑ@q÷HyQ÷>>Xêÿ"n¹ÿë(Ü”pêLGõg¹nd³#:ííOüv´pͱyYÞA jà¶x$F‹ g"^sîF™‰C[ g%MšÅQ<¦ñ ]¢>d|ȶ±ÐpŸ]bsÙ÷Ýl*oÒ ‚õ„Úx{ê:8”=YÊ!½Ø}âÀUç®[êZ-ˆÿ1¹¡8‘Áà¹i
-endobj
-629 0 obj <<
-/Type /Page
-/Contents 630 0 R
-/Resources 628 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 601 0 R
-/Annots [ 640 0 R 641 0 R ]
->> endobj
-640 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [272.8897 231.1055 329.1084 243.1651]
-/Subtype /Link
-/A << /S /GoTo /D (types_of_resource_records_and_when_to_use_them) >>
->> endobj
-641 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [190.6691 203.5826 249.6573 212.9922]
-/Subtype /Link
-/A << /S /GoTo /D (rfcs) >>
->> endobj
-631 0 obj <<
-/D [629 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-635 0 obj <<
-/D [629 0 R /XYZ 56.6929 756.8229 null]
->> endobj
-636 0 obj <<
-/D [629 0 R /XYZ 56.6929 744.8677 null]
->> endobj
-22 0 obj <<
-/D [629 0 R /XYZ 56.6929 651.295 null]
->> endobj
-637 0 obj <<
-/D [629 0 R /XYZ 56.6929 612.4036 null]
->> endobj
-26 0 obj <<
-/D [629 0 R /XYZ 56.6929 567.3837 null]
->> endobj
-638 0 obj <<
-/D [629 0 R /XYZ 56.6929 542.6255 null]
->> endobj
-30 0 obj <<
-/D [629 0 R /XYZ 56.6929 441.1968 null]
->> endobj
-639 0 obj <<
-/D [629 0 R /XYZ 56.6929 415.1634 null]
->> endobj
-34 0 obj <<
-/D [629 0 R /XYZ 56.6929 188.7253 null]
->> endobj
-642 0 obj <<
-/D [629 0 R /XYZ 56.6929 161.3171 null]
->> endobj
-628 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F42 597 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-647 0 obj <<
-/Length 3284
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZKsÛF¾ëWð¶TÕ™f
->悺¾­ßó=ñä-„¸Éüò~T”¡Òå6¯™tÈ<€­·é¦»†‰9ÿ´eýPÉ›ì¾*:YnúŽUe@Vk¼ ªÒâ_}µ»]Y­—yÕ6<;àƒ3 ù˜Ÿ:5÷ò
-ÿ aR>½xºÕé²h/^‘xÂá„÷FÞKBîD 6=ñÃŽGmqz*N-‡:÷€·0CŠrò‚Q~I!­Øi
-ì(ÏÀ¸kŽåv?¬I6IiùZª…UjùýûoxÄü zçUE®8ƒ
-t6ƒôÎ.žEÛœ˜®ý"´†)ÐPÖ'Y >sú®Ø@1çLä 8
-N]6öÌšbóg&r™¦Öž'O |žöäaýjúÂuO~½/Jð¥Ø²êW±…–êÂù†¼g#éèêB[zOqª Ñ÷zöÖ`Xµš.»–ðz7Ñ‘ŽfÔ ¥12Ô-Æp0“Ú1ß‚ œq‚ü?¨xᇠ¾™iS$ÉU*œ¤ œ~ÆÂ+u)d¤PÆÛæøÂÓ„^’$,ó!IÒ^€ç°Jbº¤¤>¡¨K6ºÎæ1š;<í(
-`S‡¹3k^S Ôd gh&øäIL½Il9©A’oKHá¨âؼ"8žÎŒ»é²2‘.":ï;æR5ù®™MúìXSuÀ—“,ˆòTâ=@< ¸ —»’šU¤o^øwßòZ¶ ÷ÚAJô…úŽìûü(IE õ…w„àPl÷y]n²à‚i’Žƒx@$‡Ã )Ì’y¸Çb솤Ax“ð0Ç“¤ÐËÂëâP3hyÞ”ÚGÐwøó[º±¤½glê"'á…f#ê(õ.´È!z¾ºk¬#§­\e&M "I-FòD<ÉFòÄƉ ‡qv@4%ÀPÌ f’BK@H½ªL)FÒÌÄ!ä`
- ‰\ù€uó\ ú›»‹ÐÊE&KÆ lvó¡ÛbÜœóäzO ²¡®×˜€äFTŠ˜®–Úb1¢ÓËëP‰T ù
-–Úñ S;É´v¬Ç@Ι‰÷XA\u·zI éGÞp[´Â!è·oÃת1ø©KÝ™cãâ b{?›ØÅÇzÌWÎgˆBÕòåâ݆û ÜKò<Š"…ƒµ£{Ážçñ'Œy%R¨%?Êbr†ø’€¶’dH²ô !%©;é>‘Öl“ú‚¿rׂ4m[n(]$rQ‰5'hƒßêæd¬ˆSäÓ˜‰
-f²}¿¾ewÅk<A{syFÍáòKWäU·ÿ‹æ—6ô·´YU8H?811ÐGÿÖʪ‹ä&HŸæ âǶ|9 tí¿„‡]ˆ«m0ÄtQpd‡È×aD#{k1=¶Å°çŒ½¯8`s€ß‚º²ë;iæB4M
->ðű„€q™°? BBGÏ$3)ɶN.Žq
-,õ@ž/$½ñŸI:,ºHˆ>\)H÷R§oó…, È8šÊ/>R"<ã7$a RÚ…ÛɧaÝ”µé¹ÛÂN‰ _º‘o}K ¦è Hz,Š#£áãH:t6ôžH¤(? „µRבõ±(äƒMä©|Ë Š>¬4²<|i\ÃΔ âxš½ÕjB5~ ŵÃM |á„RæCEÊË*ß„ò= €%ól¼¸jÆï#e^ÉUÖx»Æ¬ÚyþùTR€
-¤„H¯DÃÊhuy¿ÄÄÉÅ>2/­& MO‹žÀ=A;ZT¢Éà²Á›.ß‘uÍ}Wˆ ,À¾Ô´ 'þ6Œ¨­}¹Ûõ\§(b‹J!.éÞÅËO\Ïbôd°¶½“ÏX3¯2‘'\ç
-À‚I£Ê€:¨lòΦؗtË$dÀ§~FWùÚ—².Xê¾™Z¿¯Gÿ >½m‡ûü
-endobj
-646 0 obj <<
-/Type /Page
-/Contents 647 0 R
-/Resources 645 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 601 0 R
-/Annots [ 650 0 R 651 0 R ]
->> endobj
-650 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [519.8432 488.7856 539.579 500.8452]
-/Subtype /Link
-/A << /S /GoTo /D (diagnostic_tools) >>
->> endobj
-651 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 477.498 133.308 488.8901]
-/Subtype /Link
-/A << /S /GoTo /D (diagnostic_tools) >>
->> endobj
-648 0 obj <<
-/D [646 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-38 0 obj <<
-/D [646 0 R /XYZ 85.0394 599.0929 null]
->> endobj
-649 0 obj <<
-/D [646 0 R /XYZ 85.0394 568.7172 null]
->> endobj
-42 0 obj <<
-/D [646 0 R /XYZ 85.0394 457.9037 null]
->> endobj
-652 0 obj <<
-/D [646 0 R /XYZ 85.0394 429.0681 null]
->> endobj
-46 0 obj <<
-/D [646 0 R /XYZ 85.0394 352.2747 null]
->> endobj
-653 0 obj <<
-/D [646 0 R /XYZ 85.0394 326.5176 null]
->> endobj
-50 0 obj <<
-/D [646 0 R /XYZ 85.0394 247.1936 null]
->> endobj
-654 0 obj <<
-/D [646 0 R /XYZ 85.0394 221.4964 null]
->> endobj
-645 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F57 624 0 R /F56 618 0 R /F42 597 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-658 0 obj <<
-/Length 2395
-/Filter /FlateDecode
->>
-stream
-xڥ˒ã¶ñ>_¡[4UM|VNcï:;.ïl¼#RŽXK‚²HÎDùút£ )q*©Jé@ Ñh4úÝX…ð«$ Ò"*VYI(’UÙÜ…«XûÛ`œCÚL±~ØÞ}ÿS­Š H£tµ=LhåA˜çbµÝÿ¾AÜ…p½ýôñ~%áú×ÏO4~zøÌÐç<o?~¦ñ?Ã$üðô q¿"ÍÂõŸþ¾ýø•Ö“||Ú~ýòá··_žîÿØþ|÷q빞ÞL„Yþóî÷?ÂÕ.øó]È"OVo0 QѪ¹‹$±”Rß=ßýê NVíÖEI‰0ˆ$HåVTq´"(’$šÉ*)‚TFÒË* ‡!ÜW•Çʼ°”T£YJúüªÏ^HʉôÃÕ&Šƒ"±¥µ=âŽ<^ŸïE¾Ö][Ã>‚ÔÕî¬Î•îhz²íkµ×{‚ì.ômÚ®§Q{ÒgÕ?0í.]¯»?Y+:XJÒ KQ–""à YêúawËÓÒ]’$ˆ£Hð¾ï`S!×VÆsÐUïFšÙuŒØ‰i{$¼ÚH)ƒ4ò/~ Yª“ÚÕˆ›Âíô…KÚsC‡¤–4 C]Ó¬’þ
-C_µ†÷“$KÝu°‚$BM§á¶×pUó§í+¢Yöµ[n¯øPClÏÕÆÞ,t7"GëA?¯ˆ—%ë­ä^¬Ï8Ši<P˜Ú£$sáD–¹[Øó`›½|-Öm©j‚2@
-åäÿ÷E´ýÈ4_Wóq€Â1®L©Á$ š]3ˆ»:5vG áˆáý‘©°‚‡ºïhýz‡êîèö]fǃÎÓ4Y?WÀƸqÁ´'~e=Hä²q8åÛÚ,)³§µÒ‡P„úà
-é8¡‰<b)¢«„†—¤X&Á(tÀ`Ç€ÖØABzAŒvŠO\X¿¤†Y/(UH2D&§¦›HŒc#âg Fj:”tކZaÍlñ;úêÕÐõŽŒclò¦Ð1Ý›UfL*ýÐ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áåè
-E„©/XR.Wn_=˜Iú~†Æ£:ÕŒòµ­õÿü,’…ëŸ>ÐÈõ¶“ö2sB`ÕÀAÊhª¡‡°‡ñ mÌHððiÄy&@hýCŽÂÔã{lX¬Õ«¾ÚÀùüfõ
-7c®ûrún„u謘+Òi+í{Lßf÷s»x¯÷¼j>µoz,)✌{»B¸ÂNL‰ÖÑ”ŠwáÞ6Ü3.¹Ú¸­JžP4…-|×ﯛ×÷¶Šé[ÕµëöÅ'ηÔjt¼ˆˆ¨fË9'g…k¥äí „ 6BgØ ç¹vÔ Z3?p}w’‡ÎßmƒfåÁáÖ/—’’qo9“W=k£éµ€§Ï:é(%£Ù,—Ì¡D$ÝÃÜŒâÆž½ðš‘Y^d®|¶—`3„£ØÍR/+rC”¥7í=,î«s!Wüˆåy”_…zÿâAÑL‘Ÿº*µ«êª¿L A0uÀ›ò%Ê=_¼#5Œ¬!À—j'$ue¿
-öºD‘äó‡÷
-ÈYÊ%…ÂÜÂÑÔÈhÛ=LÜ1÷t!8Žßbeì}’ €}ú'¥‡Ð7d©¸Š„µjòr—x¨î˜æ¨¯œjUºÆ¦2ˆ}¯Ë²wþ`€ô…ÿ
-,üúD÷ÿù0þgÌóhü_AÎzÚ0(2é™B±¤7Œ»?)n9ÿÔ‹ö`endstream
-endobj
-657 0 obj <<
-/Type /Page
-/Contents 658 0 R
-/Resources 656 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 601 0 R
->> endobj
-659 0 obj <<
-/D [657 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-54 0 obj <<
-/D [657 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-660 0 obj <<
-/D [657 0 R /XYZ 56.6929 749.4437 null]
->> endobj
-58 0 obj <<
-/D [657 0 R /XYZ 56.6929 609.0996 null]
->> endobj
-661 0 obj <<
-/D [657 0 R /XYZ 56.6929 584.3177 null]
->> endobj
-62 0 obj <<
-/D [657 0 R /XYZ 56.6929 437.466 null]
->> endobj
-662 0 obj <<
-/D [657 0 R /XYZ 56.6929 410.2571 null]
->> endobj
-656 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-665 0 obj <<
-/Length 1888
-/Filter /FlateDecode
->>
-stream
-xÚ•XK“Û6 ¾çWø¨‰UIÔÃ:6iÚ¦3Ítší©ékÑgõpEÊŽóë  -oÔN:>
-Œì„SxóþÃ$ý»2ã<í•ý=ëIõj°&˜IóXäeÆfÊ".ÅŽÖÍâôa›&Iý,§æ"'63}mFlê¸.³’­ˆ4Îïþ‡A­Ì¢VNé.BCøEc¥ˆˆFƒŽ@£idh²•gEÊv’¶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
-Íž3_·F^¢vß2Ëm @=¦Â­FÍ4F€!g,©£ïÖ‹HúÔ…ˆ‹Rφ´‚ñ¥É{ìÅI@Á®!šë8ìnåè$÷ØNý;+ß‚ÇO7Œî®:êÒª‚0è»áª¼›ù|ÒS
-½z÷þËòÿP‰"Æÿ»Öþíò"Û› ýÕµDg(°±È’`Ý«^.þ7ûzµ
-endobj
-664 0 obj <<
-/Type /Page
-/Contents 665 0 R
-/Resources 663 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 672 0 R
->> endobj
-666 0 obj <<
-/D [664 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-66 0 obj <<
-/D [664 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-667 0 obj <<
-/D [664 0 R /XYZ 85.0394 573.1436 null]
->> endobj
-70 0 obj <<
-/D [664 0 R /XYZ 85.0394 573.1436 null]
->> endobj
-668 0 obj <<
-/D [664 0 R /XYZ 85.0394 538.4223 null]
->> endobj
-74 0 obj <<
-/D [664 0 R /XYZ 85.0394 433.7668 null]
->> endobj
-669 0 obj <<
-/D [664 0 R /XYZ 85.0394 392.81 null]
->> endobj
-78 0 obj <<
-/D [664 0 R /XYZ 85.0394 329.225 null]
->> endobj
-670 0 obj <<
-/D [664 0 R /XYZ 85.0394 290.8035 null]
->> endobj
-82 0 obj <<
-/D [664 0 R /XYZ 85.0394 191.4678 null]
->> endobj
-671 0 obj <<
-/D [664 0 R /XYZ 85.0394 156.6041 null]
->> endobj
-663 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-675 0 obj <<
-/Length 561
-/Filter /FlateDecode
->>
-stream
-xÚ¥T]o›0}çWø¤áúƒý˜¦´K¥¤)MSׇ4¸ÆÇÚþûl¢tOŠÌ=çúúÜÃu0@êÁ€ùÐD€@x!ÌÀî`!°WÜ…MŽ;&¹Ó¬ëĺºõ PøÄÉ뤇ˆs ’ôÉ&AGU@v¼Y¯"‡vÞ8.aÈ~X‡ÑÌ <;Y¬î4“p;.¶ç_gë$Œ4EL¡ëÅÊìÂøaÍÃ1zÜ,¢p®’ØyNî­09ö0í#Ú7ðÛzzF UíÞ[RÁxS‚X–Ç(d¥#’[±õx,8a‡­Ÿú†$TytiœG
-.â¹ÚáñÑ@/°…vå¡ÊrÙèh[¤ú¥v¸ÝN- Ãê%ßÖæö^j¶è/²ÖTùª×M‘½»yöˤ”ÙŠmÙg'žùæ0fgEZ¾M«D¯W}›}cCÁ˜qJ™¤fƒ*þ¶ìEøD•ìWjw•Û–nºm¥Æó¬i53ÈTH3qWÁZWó¥˜ÝH©áö§)…³›e¨Á‘ÜàYq–¨^ÊÊ)ÿÈ\ci6¸&wmYhVËÐûÎzÓ÷ç4ìB/MÙ 5vRÇ©j¨Î^º6+ ø¯±§ ö³úɪŸqò¿¯Äé 圜¦}:•„#(zÕwÉ/„WçRù_`éendstream
-endobj
-674 0 obj <<
-/Type /Page
-/Contents 675 0 R
-/Resources 673 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 672 0 R
->> endobj
-676 0 obj <<
-/D [674 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-86 0 obj <<
-/D [674 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-677 0 obj <<
-/D [674 0 R /XYZ 56.6929 744.7247 null]
->> endobj
-673 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-680 0 obj <<
-/Length 1190
-/Filter /FlateDecode
->>
-stream
-xÚÍW;ã6î÷W[É@D‹¤ž¸j³y )‚
-.AŠ.D‡óøfæ“EW üèªÌH«tUT)Éš­êÓC²:ÀÙ·Ôë¤'YÊ9lN㌗$+Y±Šo|¹}Ø|“²KHž³lµmf_y8\ØîŽžb0r\Ç,K"¾þeû=^KIQÔ^KÀENhÅþâ$Qù'9žÃÅgÕHv˜FaZÕ{3|U‘*g¹·’S’EêÌ|×ÃÅ*̱ÕvÅ#-kwÕ‰/ŸÃ¸¦e¤Îkµ{/ÓêVÓá µ‘{´Pß¡QItª?x«­9¢êas]ÛK¯Ô¨ÌQ¶#Ê&-É:NS½_W,’ÁœV6=›¥¤Ê2æû½‹Uj€%¿PC[ãR5øDM¡U/vWSƒOÖZÓö2—ƒ¦„§9ó@¦”äIE_Nè:¦Iõ§!{~ Ål(„ì qJXî ͦž¼Q!ŒXõÝ JÞT±Ð,³ý…¸l- <Ï
-¡Ä¸ØyýºkeoôRÛƤ(fÕ>Sç9³áƒÂСgr–FO×üu’ckûÌnÌã„;5íÚÚZ
-®Ý‰ÀÁ ®vª“Fm
-ó:ó= |ïß;O“9ª¦ÎÎö¿¤}GÞ´rDï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<!†iÔ®OÃÌÅ”³»_©pdp1Üò•¿oèÁ¶–‹ 'MøÌ…ìŸráÃ×Ûù»$|mðŒØo—¥/— _uð³å¶SyR
-endobj
-679 0 obj <<
-/Type /Page
-/Contents 680 0 R
-/Resources 678 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 672 0 R
->> endobj
-681 0 obj <<
-/D [679 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-90 0 obj <<
-/D [679 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-682 0 obj <<
-/D [679 0 R /XYZ 85.0394 575.896 null]
->> endobj
-94 0 obj <<
-/D [679 0 R /XYZ 85.0394 529.2011 null]
->> endobj
-683 0 obj <<
-/D [679 0 R /XYZ 85.0394 492.9468 null]
->> endobj
-98 0 obj <<
-/D [679 0 R /XYZ 85.0394 492.9468 null]
->> endobj
-684 0 obj <<
-/D [679 0 R /XYZ 85.0394 466.0581 null]
->> endobj
-102 0 obj <<
-/D [679 0 R /XYZ 85.0394 237.1121 null]
->> endobj
-685 0 obj <<
-/D [679 0 R /XYZ 85.0394 206.4074 null]
->> endobj
-678 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-688 0 obj <<
-/Length 1948
-/Filter /FlateDecode
->>
-stream
-xÚÍXëÛ6ÿî¿BØO23|I¢.Ÿ6¯v‹d“sÜ.Š^?h-îZˆ®$ïvïÐÿ½C)Ë^9›Þ¸Â€5$‡ÃáÃy~,ˆb§< ’T’ˆ²(XW3ÜÂØw3æxži1æz¹š=ó %iÌã`u3’¥UŠ«ü—PAæ †—çïßÌ<¢á§7Ëy…?ÁǶ?||³<Ÿ'2\]|¸ü4_$4•á«ïÏ?®<ÇÓ2^}¸|{ñÝ{9ó_W?ÌÞ¬†]Œwʨ0[ømö˯4ÈaÃ?Ì(©Š‚{hPÂÒ”ÕLF‚DRßSÎ>Íþ9Ú©“È1J¸
-:ýÀ²¦ÜeVi2 $$\Ù·f"WÂ_àgÐJyXܘ^>4sîÞX»7¼ý•Ð8puu…ýƒÓ0û¢ßàx­ûû¦ýŒÝưìdt?f¼¹Á!1æÇœ®Éݼ:Gn×-žMú@JP¤GÂÍpíÖ¤2Û¹S¡Oã°ð  Yip\Hö›ÌÉ^—…®{×}_”¥ënêZ¯q–æ«3¿Teì¡vË4žè7ª†zxµ>§Ù•þÇqZ@ZPˆ2–~]^À ò+¥ó‚ÿn–×c¤ëI pYŽô3E-üž"fDÄ’ IÇÁV‚P‹
-&Ã¥îš=€µF—±ŒÛÿ¢].áŸaûuÖgÇ' x­˜FÁXÛÿ
-<¯ŠºèzÀ—hƒ NÑ7xn¦Ýã^-Ç߸ïÆ+òÐ-&Ë3ú¸âã…±Ìæ?  Lì1h–eÎÈÚ™ƒu®1šëÝímáûX j(ÿüd¹-°`ÿÊÇ«9”ÏÚ‹AÛóSv¦aMÝŠ.º©(ÓA[àiM9¹™˜¼Ã4x2õüÚ·é½S’ Üŧ½Á)9¥ì!}¤¹Ä~¬úŸ<SÝendstream
-endobj
-687 0 obj <<
-/Type /Page
-/Contents 688 0 R
-/Resources 686 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 672 0 R
-/Annots [ 693 0 R ]
->> endobj
-693 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 208.0574 126.0739 220.117]
-/Subtype /Link
-/A << /S /GoTo /D (rrset_ordering) >>
->> endobj
-689 0 obj <<
-/D [687 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-106 0 obj <<
-/D [687 0 R /XYZ 56.6929 492.2203 null]
->> endobj
-690 0 obj <<
-/D [687 0 R /XYZ 56.6929 453.7474 null]
->> endobj
-691 0 obj <<
-/D [687 0 R /XYZ 56.6929 385.673 null]
->> endobj
-692 0 obj <<
-/D [687 0 R /XYZ 56.6929 373.7178 null]
->> endobj
-110 0 obj <<
-/D [687 0 R /XYZ 56.6929 177.8714 null]
->> endobj
-694 0 obj <<
-/D [687 0 R /XYZ 56.6929 136.2124 null]
->> endobj
-114 0 obj <<
-/D [687 0 R /XYZ 56.6929 136.2124 null]
->> endobj
-695 0 obj <<
-/D [687 0 R /XYZ 56.6929 109.3045 null]
->> endobj
-686 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F42 597 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-699 0 obj <<
-/Length 2677
-/Filter /FlateDecode
->>
-stream
-xÚÕZÝsÛ¸÷_¡—N¥éÅA°O—Ë%×ÜÌ%×ÄiÒÌ”– ‹w©);Îôï À$EJÎø©ãàò·ËÅ~f3
-l¦SBE.gY.IJY:[î®èìžýtÅ<Mˆ’.Õ×W}­ø,'¹âjv½î`iBµf³ëÕ§ùË¿¿øõúÕûEÂS:d‘¤ŠÎß¾øå®|€Gi:ÿg xùîíë7?}|ÿb‘Éùõ›woIFs o^~÷ݯ¯ßû°ø|ýóÕ«ëøÝ/eTØOøãêÓg:[Áÿ|E‰Èu:»‡ %,Ïùlw%SAR)DXÙ^}¸úGì<u¯Ži.š¤šg#ª“£ªKs¢Nuö›a‹„QJç?–ÅmU7m¹Ä¯½^0Ææu½mì—žèàÑYÂÉy–;¤ëñD]¦,'4eVVK³*oG€˜$¹ÚÓ|7‚"‰ÖÀ 6 àJN„ÊxDI¸dó¢ZÀqØ®¥'­šm]ÿ~Ü`Ê´Ï2O¸?,˜ž×·‡b×
-;ÏÉÓ”õ?ভʵ•jm8/+ümÚ‡­Á!JƒúØî-ŽA¨]Ñ’›¦°ƒàhJç`\9÷^O”t©¦M0RuŒ¢Ë3‡W´àçy¢ž=» `^J¦}¦ÖZN³ùªÞNCTƒ¦Pe]áÃ[Üñ½S%ÌÿMS:fäR°6ñ VH 1Ë™·A¢µo7²›Ò¸]
-Ü5XÛoMëéëuhü’7h7vfqçjþÆoŠÆÛR
-’S¡ú¶ÔÞ׋DP¢¬Ló·E"Ÿ7¥eŠëeÕšC±lË;óHˆ#gÚbIóì9¼æìÛ…pOÁ$~‘}rS´ËÍê~S†EóÅ,­ipVtáìwоüè^`Ò¦°
-¿rL6È‚ëær[4ͨJI–
-9
-˜ê UM—jºª‰TÝ*µËÔ†<I•:Ï5R°ƒÀ(lYÜã;]†3ÉÏWÐÜ™Æxx„£l]ešÎÍn5C¹`ó¯¦Á%gõå2’øŠWBÒu>
-\ñN
-‰S=ë4¡‹1à#UÏE}6ÂpHüÄøT¯+‘ª›K’¶NÖe8Ýíw¥š0ý¿È'ñìÐu>&a4Uy/9ô=[çÁ(aäŒ~%qVµÂ…û+Zs
-ÑWðXèöh{Ѧ»ä¡n¾Â¡=aDû…‰¯’qâY‡ã`Ï »J¹ò4wÕçÊ.Ž.škQÅ¢Õ2¦ü€fÝéÐsç½0Ý<ì"E‘ÿ“üÙŸhZçl]ðÆ@i¿º„佂ÎQtÕ©êGBL§Ædfü h4¨0“sÜ®#ÐI<< “0²Û_ŒGv„
-µ#÷‚+ÏÌ.¹Qø}lHì¬'¬#[÷BÏã–jü½ñO¬ ÖÖ•,¿r4êÓ’À°Á_T3 ·Ü>íl‹kÖ´?ë€gè£î¸fq3où§{³,-²²ó»
-#¿UÃ¥ìœô­£e0fÆOØGG÷ãÑê‹aº°¿®Ï³”Z;Gà32’ØMZKÿ&žPÃ`3GÕÚû¤M4Ý×Û•³)îÊÚIdϸ¹žß{¤•—¡ª=-âÕ
-ÅðEàð{» åÈm–&™Œ%â¹J&•…S4¦ý±1ã7dh¿á¸ІÖ+2–0‘Û®SÙ$F”d²sõÈýÕã‹Õ®¬@•‡"T
-ñPà·æ6žøï‹CÛ¿)ˆí<ÔÓF½…Ÿ• ŽÕÚLf„ju¡ÖîRM×Ú‘*8Â*YnÌòw°ÄõIÉ­R5Y~^€H5"A¿)HÌû"Lž71;’1Øš“Œçüô¢Õ·RöÕf°/ÍCÕ_†{rZ8ë“ñfØ C&äPœp¥ÒxIGùvú>Æ^ÄjÊÄs*¨.ÆtU©.VuŒAŸcK¥çÈÔÁ˜®ê"ÕØûâî·»¯gOF˜bŒZÇ8s0˶ÆK½á)$Чì[ïEÖåÖLœ;€kNU÷¼`Ìy50¦ê¼ë>ÒL;®§hëk]™S·…’LŸciNx÷]²¼ËüœÃêS‡ VÂÆ‰'9lÂhÓ†; t¬xõqêÏñ´$&Ø%^O_ަDpö¬kȈpæbi¦ÝÐo¶H‰ý¯†4Œ=ûŸƒÿg
-LYhÍÇ@P†žgA(+<cCÉãŠþ?H·endstream
-endobj
-698 0 obj <<
-/Type /Page
-/Contents 699 0 R
-/Resources 697 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 672 0 R
->> endobj
-700 0 obj <<
-/D [698 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-118 0 obj <<
-/D [698 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-655 0 obj <<
-/D [698 0 R /XYZ 85.0394 749.3395 null]
->> endobj
-122 0 obj <<
-/D [698 0 R /XYZ 85.0394 221.8894 null]
->> endobj
-704 0 obj <<
-/D [698 0 R /XYZ 85.0394 197.4323 null]
->> endobj
-697 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R /F77 703 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-707 0 obj <<
-/Length 3116
-/Filter /FlateDecode
->>
-stream
-xÚåZK“Û6¾Ï¯Ð-œªŒA‚{ó&vÖ©Z;±'û(ÇŽHiS¤"R3–+?~h
-ÐCm=3cÍ
-³`Á‚z‹ÿ)þY­@«ÉùQ{@ð—‚Šà•¥<×'loUpª¦”ÓŽ˜¸¢8KÝ,Ú€r;—êl'wÐm°SاOEYb++šC™ž 85éά€û¼qxÜX¥$”(!Åð@mk³p€
- Ž QÓ¶ù…·Ça|TœÃuDzJ?š¹ÏÍŽ`™ú=걘<•ßÈOA ÄknÛÁ0·ÅnÊ3GBqéš«Àšä$GÎC~Éñp•ã¡>NÅC?àù¯òû˜Oùu¦„RÑ;ƒM½ß§U6ÞŠp–87wÕ ,02þÒ’B>LãµP!
-MYM™²£2¦œ—uš]Še°ÎL~Y®§ ¨ƒÂ…a%¿EÉFpD~¢”ïN‘aP”VCZϦ¡ãƒ†Ì©IÆ!x# ççÕÔ§šW“§ª Ì,™·zÑ‹š‹ôÞOp1Æ:•¨Ù6ËÆÙüc‘?MÍex¤Gqà,Y/ëÒS•9ôm Ÿ$´u ÍþÖûC°+óªÛäù=Ssy{T {ì¨p·Ç¼y˜ÚäA¨¸´É>Ò½º=ÿå]9ì lÕ¢6=ÕX» °Ëh¨Ïw#g'w‚?{øÛ§EÕBT^m<ü«-°0Éå[èQ-Ø‚£B[€³j¶ÎË6 ‚¨ZúLþa…è&fË
-õTcÍ”PUú¶Séâf[›ÀP~A»O!°ÁøŒM„à¬á°FË6ѧš· Oebãcžvõž?$JLÀ„6,YVª§kuh'Rð¡ZßšC®Ý»ap:di›7ØÑ™þOñ/;CRVl°ƒ°°–7ù˜ªêî¶
-ËlеÍ{$䢢K¹ÍI)ϵGJml¶R“`AÃ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Ý=–± xs
-‚] 9½"ÙSEKA"$¡þØ=íëÂÁ4Æ5!ô^Ú @£{¹[0 ƒjLÄWXNÔ­-UmýüSÑ´Eµëxô¥Ú¹ `å!"SþèbÆbë!çŒ#飅 ©ÐtÁ"þ«`넘j€BÛÀǸ8É'¡nÓQ¡j yÁ iÙ“qaž]DÛ!\ŠÝ}ÂÎÅŸ§ý½Çz‹úàQ¨k±
-qnÅ ›ñ6jmAï±.²æÂð«<wU!‹ù'€VEuY`zO6½ja[ìÀQ}µ7»•³ÐÊeD”`W*
-}ªùóå©L;MÛf\geàÁc¹,ÖSåƒÐ$þ‡Î–Ekuá]µnÜ´Åoš¡Ö½â. P{óÊã WEWRï>Õ‚ò•^Ã/§üx.ëypZ”ÜÓHô48 dßÝ&<¨w;“à°碛p:`àB硌?Œà }õ¨Í³`È$GúÐaeíËù§CYlж<ãxVàÝ´–¥réÓè;Åš˜×]áÌNL¾ó—.«õç2ê*ÎÒ©ÏšŠDaâ(5¨Uy99žJé §¨:㚀±˜„Iä¼¾ÓßϘˆ(é>„m:@@ºü¾r÷uÕÜÝ!ÚÑM°– èÄÅ/³FÎTH’«FÞ§š7rOenÄœö‡ìÞ}cƒ€ý×õ&Ý<ä¿®5~}˜ÏÝ @!"ö‹4‘!&„L„FW.>ª¿GÓ+ õTã•÷‹ÆàwØÅR¿¥‚%DZ-(ÄÊã€ÕW >3«·m}ý Ë·é©lñþ€~ÇD
-áòcìQ-££BwUüçã‘0ÒE«eùžj<!îBÐ,â„ gðÎÌ@gŶè¤zW1têÅE°O?·,0°Hu9ΩNS›Ûºaá3¯Zì÷*[ÊVÝP ¦£§ÝtGª|­H· p á!Þ¾úçK}}€»ÛH†1ä±iñI!a†ãÆ™=zÀ×ÀXìOóÀ„5}J_ñÓ£öè ÓŒ!Áú€ÏŒùi±Îü@gî=‰_Y{!g“cfv™ÙМq}íéX-˜¨Jà,²+Ÿd{DóêˆôTÒ²ýû\Þ™ç¥ôiëì‹Gãä`‚¶:É»À
-‹=(µ€ÍÑÞbç jo„ú][ú5ìzF¨zKÞ+XŠ ¶²Œ½M™#î™7Bˆ1óÑ k€ºiJ²,´§ œê¶5@}ÜÃLJc)C·îíKöæUé¸t>¡è Ùwµ#Ô ëêÈ4+ä(Žx¢¸Òd‡ aë :}X^®€qw Ó?
-øÚbüîΘ˜¾Í<a~ÔßuùÝ—¦»»äúâ‰R3×0x¬Ë…ÀÄNJëññ½G
-fñ‰©ÿ_M¯endstream
-endobj
-706 0 obj <<
-/Type /Page
-/Contents 707 0 R
-/Resources 705 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 672 0 R
->> endobj
-708 0 obj <<
-/D [706 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-705 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F77 703 0 R /F14 608 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F79 711 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-714 0 obj <<
-/Length 3636
-/Filter /FlateDecode
->>
-stream
-xÚ­ZmÛ6þ¾¿Âè—óµÂwQ—OIšä¶‡K{Iš¢o8hm­-D–¶–œíÞáþûÍpH½Ø´½@‹…(rć3Ï Íg þøÌê„ÉLÍÒL%šq=[n¯Øl co¯¸§Y¢Å˜êåÇ«goŒ˜eIf„™}¼Íef-Ÿ}\ý2õ·ß|ýþz!4›Ëäz¡ ›¿{ñ×Ôó†´ž
-¯¾{÷ææíï_\§jþñæ»w׋”e
-¾¼üíwß¿¾ûpýÛÇo¯^ìW1^)g—ðûÕ/¿±Ù
-üíKdfõì^X³L̶WJËD+)COuõáêŸý„£Q÷iLs0œng  †Ë(g
-t¨RЯâ‰PLôúÕv¤_Π­Ì¬§Býv»|Y®•Ë,±Rf³ñ„Ç|Õ1_%Ç|•J,×bÊø¦^Û¢îhºMA¶Ø})v-½¬ŠÛýz]Ökz­Š/EEÍÛGz6u‘-!(%å,±ÙEÍ Tgç‰&z{ö&ÍF´R'Öh ó# {(Zª“¡)-‰6Õ­e‰±ÌNdûPtmT£pÔü/õÚ5ôÌkzÜWå²ô»ô%¯ögô Ò€YƒþÎ+|LvZã=.«nâÆªy’ÚŒ_਎9OªM’¦LMYÿ¿4ÊÎèM£—°æ’ÞFdgô¨Pø»jßnNñó|û#~Ä7~Ä'Œß ãâ Š[æËÍ9“â …æê’jFdgT¨zÕÔù6v’Á„µ™?Éh"`‹7~AÀ@u,àT‡™N¸0Æu¸.¿þp:Á\ëÎùÓfû§õ­maZ‰ ú“ÖwO…«i»¼Û·GŒ8M°à<ã@uÌøà³$Í„rþ¦l陼T,ˆáÚÍ<eFúrƒ¤/P"†4›¿k:?ÔÓÔûí-ê´Ÿ
-Ôtžw :æ=µXc“Tèæßì·÷;Y•­×SãUþû¾Ø•Á= +XMuò“þê®z)¼_˜PN»x²À
-3¢[
-tÇ, Xp©‚Õ´-šËªÜEæ7ü·æa9yK“¯
-Ôeí¼ã…Ð[ä§ áâ ³/xKŒ†09˜·û²BÛ@_•»`zŒ¯`96X1áåñB8hÛ šÚ =
-¸SHqojŒÉ´ÄýÎ[ øFÉM6=c˜SºZf‹AÙ¤'¢@ýŒñ‰[m#¢JdÁDZãlCI´C
-´ò¶m–%†J‚’°h+
-há½§÷ÖÈ¥?+˜aù< ø z aëÖÓ_îò%…}xuu#”®‰8öEXÝÄË.ÚX5cvb¿x ”žzœç¬h„(t
-—.Œýð:Wêf ÖŒŸðû8ÖÚø¯SýŒ‹ñ”‘‹'Q€]ödg<Dšd²7·ÖI}(§×°aŠ6É—âŽ)C?l.ù%†ë±_[Ñ=4Ôs°ÂTFõ!=¯ÖÍÜÆ6VôO!ësÍ“I“Ô}–‡¹I-ëƒbBŒ} ›ÿ¸)CuÍ;r-»«©IEªsf~ŸïZ‡Ø” 8 ZùÒÝxP»~¤Fo¶J¨P!KRæ5*ŸHáHP•ÝD %דù<³Hqù)'c³Í—‹íJÇ÷Ê>wð¦ÛÞï?­/& FVç¯ÑG©ã(ÂûKÍÛ¼-ÆOZÔËfâ-)\°aZWQb!ï-í¥/°)uĸ%’ã–¼NNÝtá}Œ ¡ïo%;pÜOÒþ¶ìÄq³‰Í´ŒKäéA–Ém;dYáF€]=˜üã±8¬ÂœDBàL_*vQHðqT†Ä'F!Á|ú„„Ó±å
-¾H2¤Oø+2c³XHŸ
-endobj
-713 0 obj <<
-/Type /Page
-/Contents 714 0 R
-/Resources 712 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 717 0 R
-/Annots [ 716 0 R ]
->> endobj
-716 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [120.1376 425.576 176.3563 434.7914]
-/Subtype /Link
-/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
->> endobj
-715 0 obj <<
-/D [713 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-712 0 obj <<
-/Font << /F62 634 0 R /F58 627 0 R /F43 600 0 R /F79 711 0 R /F42 597 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-721 0 obj <<
-/Length 1521
-/Filter /FlateDecode
->>
-stream
-xÚÝXKoÛF¾ëWðЃ„ë}?š“k8‰ÄIc¥(#ÒŠtEÊ®Qä¿wöEQ]©Q…ÚåÎÎÎ~ó̓$ †I„DÒP“(ÑÀD$‹Õ'W°örB‚L…Ò¡ÔOóÉÑ IƒŒ¤2™_ti„µ&É<ÿ8eˆ¡hÀÓóã7§³”
-<½8}?bú ü¹ùÛw§ïgŠOçgoÏ/f©Â†OO^¿›G‰‡uœ¼=qöòÃVÏìÓüõätÞßbxS‚™½Â“Ÿp’Ã…_O0bF‹ä&ch²špÁàŒÅ'Õäbòs¯p°ê¶Ž"G0¢ P:„N¨t„ĵ‰IF™Ã./.³MÕ¥_Š;¸$Çxº®óÅï0}no—¤Ô ­8¶!¨ÛõÕ-½àlp
-[™ù²l=n¿aL«â™Ÿ”—á¿n»¬ªŠÜO³ÖkÜ5cd0
-vv^h
-øc¯žÅ+¥œC0¦ûr¶¢¡Hi¥É:]O¾‹³—¯>¼Û‰(HBR°d¨ñßÙ«±r׋;fžXþ·{íô–ö¸OB¡ åcI˜0È\}C6ˆgۻgY[ÐCƒCˆyB ™aHa@n_Ôþ? fйIL`0ô ‚K ïÕoî§ð@å“QøÀÌq
-í|4…USe_I#‹?Ëî~Ž=ÙM¿;Ž‘§äÅоHñ
-endobj
-720 0 obj <<
-/Type /Page
-/Contents 721 0 R
-/Resources 719 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 717 0 R
->> endobj
-722 0 obj <<
-/D [720 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-126 0 obj <<
-/D [720 0 R /XYZ 56.6929 526.4445 null]
->> endobj
-723 0 obj <<
-/D [720 0 R /XYZ 56.6929 499.14 null]
->> endobj
-724 0 obj <<
-/D [720 0 R /XYZ 56.6929 469.6226 null]
->> endobj
-725 0 obj <<
-/D [720 0 R /XYZ 56.6929 457.6675 null]
->> endobj
-719 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R /F58 627 0 R /F42 597 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-728 0 obj <<
-/Length 2277
-/Filter /FlateDecode
->>
-stream
-xÚXK“Ü6¾ûWô-š*·V"%JÚ[Öɤ¼o•=[[©x‰=­X-õêáÉä× @êÑ{K$’x|
-ùÇÛ¿Ý'â ¢P)‘N~-•Á„Lf‡‡ê·àÝY_GÓßEÉÝþIÓ’0˳§E°„
-ãTXþ«¯º-ME~úð‰÷FSo/ NB™(ÁTÆBÄV4ïŽqEÁ‡n¬O/<EаPBñ Q„Ìo×RþõðþþWj×þ³@y1åY·õp!r<ë‘Ç›¦{˜Iö¤ØLÿÕô<0vÄÜÒ~X„©o£¿š›iYШ—~2Y…‰ã°HYyv­ù…LƒJ:Þ( Þ·ÔÕßÅy`†k׆zPþµ×묤X¨PÆY‹ lÖέ2“8T X›ØNv‘îâäÚŸÓ ¶éˆwY¼ÅŽ5Á#¤l>×MC­òlÊ/ëÍÆíÞš[õȧFíÕŸˆJ:Æ*ƒÝ‚ß²²Èî´.øjZhuüû¡rêIiíH³| t[½å‰'úƒ…]O[µYŽÞ®4öºN¤‡Ð›2ÄÏì”QÜw=5.턨º=uýEv/Ø¡»iܳb
-GIö=+Ê"”‘Ìö–„ZMcÃ*•ʾ¾ÎëZ'eŽ=ŠÂ,ŽÝêík)MzêòëÙßüü0ÃU‡ ÐÈU˜ç©D8¢Áþé@ üòüÇ寕ßÈŽ|2弊0¬ÚnÉCär…o
-éÜäÖ8
-7Ŷíæá¯éw1ã¹CWÎ¢à„ØfǪªnŸ9 æ®.¡Æ_e3ú^b, +^Æ~±œË<ÐæÌcÛ/´H„qÐV$èz\çU>Ò„Õ¿nˆ@ü¥VwÚ+3 26ú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
-Ã@uÝ ëR'@bF¥MMj#-ÉÙ"ÚŸ‰iì°”)Á ˜™†ŸLkz=Z‡N'‰“[>4ŠçS£¼–þ]ÛÔ-³º<˜_ÌË]ǧ‡*Úȹëë?µË”Û³¸è§wqçjA[Ði—Ž0Bë§ï,Tso‚^3“ùã
-Z3&øó@›=—vê¡ÛíÅ‚¯Äú</vûkǛ߻©o^!X4¯Áxê“ÀXxC¢[Ü:€¸èÊPËÞ?à¯éÇ@{·Ãfå!&—3Äà$_Â1Œ\ÑVDc¼ÙÎf–ýoÀ :
-*8m=,»Yذg¿O+i[/+ö½ìùlÚâªý0Ò$òÙã™]q¾™Í¬RtÂ4nQ ç(üÑwò’;±Ï ÀŽIÆ9§;‹¾^KrËëùc4íàËÂ4[â)”¡2÷
-å‘§Z°­½+º¥­˜É7+"Xç*'BOí&ºÄ¶$oœîÙ‚¢ ÿ¤2hT$‡.à–x#¶§+bHT™Á˜Ñå™ù}
-endobj
-727 0 obj <<
-/Type /Page
-/Contents 728 0 R
-/Resources 726 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 717 0 R
-/Annots [ 732 0 R 733 0 R ]
->> endobj
-732 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [470.3398 483.0796 539.579 495.1392]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-733 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [316.7164 471.1244 385.3363 483.1841]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-729 0 obj <<
-/D [727 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-130 0 obj <<
-/D [727 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-730 0 obj <<
-/D [727 0 R /XYZ 85.0394 582.1251 null]
->> endobj
-134 0 obj <<
-/D [727 0 R /XYZ 85.0394 582.1251 null]
->> endobj
-731 0 obj <<
-/D [727 0 R /XYZ 85.0394 543.5676 null]
->> endobj
-138 0 obj <<
-/D [727 0 R /XYZ 85.0394 445.615 null]
->> endobj
-734 0 obj <<
-/D [727 0 R /XYZ 85.0394 406.7709 null]
->> endobj
-142 0 obj <<
-/D [727 0 R /XYZ 85.0394 289.0425 null]
->> endobj
-735 0 obj <<
-/D [727 0 R /XYZ 85.0394 261.2074 null]
->> endobj
-726 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-740 0 obj <<
-/Length 3604
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZYsÛF~ׯÐ[¨*‹¹päM±åR‰ã•´»©™Xƒ
-Rç4-©—Ä„éb¿]eŠlTH"c# €–»ö-ŠÜ@icóS(7I˜yïê•0~ØÅ—‚GÄéXÍ`œÊ(@30Ûñ^h¤h 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
-pB1“TÖ‡IêwfW|Úm·$K9Ý"˜KýåUFŠzy: }Æ!}†=`¸RÎ[kÛ¾`Ê1›Að‹ˆlês#+¹‘•Üèö¤Nn/¦;·E'¶(±ßòwðÚ¸ºãæÇ²8   VÓæR[[Þ—0gÒ1¢ìe¤‡"±Ðn³\ÚÈì4Æ€¬3,ã‘
-“Šâsw¡}O,¹dÛTœÑPùî[ÆÄ ãQ°. ZÎu´Y0þbdïÆY4œÖ²/^±@<¯Xkƒ$îói
-9íz³œrÙk¿d¢´³FøíYœÜ0 HÂX<M„xNþ´3릠õõÜ<ßÝW”öUf”ïÅœqÆhú[°RƨÃa‰ÏGáTØ„8$@^±lh Æà•N0S#8;\ѹpæ¶ÏFÅ>““9£û1;ÄθŸb‘×™_›ÆXÉ›œD¦¨-ù>5õ.Å#ÉüRÌ[8¨bjéRMn´£qï \9”ÝšKS¿Áo«X‹ï§w*1#ïõ{¹tŠwD,ò‰
-üõQk«bƒY[¶+¿øÉäØ!Û7?üÌç´„hŶ(n‹|
-g¯)’²Ôãž)Bɰؽ†`‡¾"ü$ïõѺ¿V‚20/õôvŒÈD1œÎry,s@%MÁÞ,ÌR"Í×vØŒ.,q=ö7ïPòbÙF9ÄiJñó~Å3ažó2JúÞ¼ØáEÃ>û–rôwÃÅÄf²1òQz4cA=qUÍ@±·Î¿
-ZÐ~ü(º0¦•”³ó ³áeå^ºYÁI˜ì¯‹YOI8Æ«”À"Wâ…cèJ)äÓM6BÒp-.°”C}E·Þwú§/‰»tÛÍ=÷Y+èèBtÃ…odë2_ËÃ+c”\F~"”š±9btl`}ÐeÕÇ) Ý7„Ùˆv ¤vjM¥g5E»²>26@ØYÓb·t_ƒZÿ$`\â·šï…8ojLÜ>ìûs.¶ò³NŒ9èA.§™AæÇÚ»’î Mbt
-ºzzs±_š¢ÈC(†HôbŸ"nb‚(‰ü‘úÕ Ç¥u*Ýñí:rÖs¨X™‰¤¿Ÿ-¨V%iÏsiãÐ?x1×I
-endobj
-739 0 obj <<
-/Type /Page
-/Contents 740 0 R
-/Resources 738 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 717 0 R
-/Annots [ 743 0 R 744 0 R ]
->> endobj
-743 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [464.1993 638.9439 511.2325 651.0035]
-/Subtype /Link
-/A << /S /GoTo /D (proposed_standards) >>
->> endobj
-744 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 628.0049 105.4 639.0483]
-/Subtype /Link
-/A << /S /GoTo /D (proposed_standards) >>
->> endobj
-741 0 obj <<
-/D [739 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-146 0 obj <<
-/D [739 0 R /XYZ 56.6929 704.5459 null]
->> endobj
-742 0 obj <<
-/D [739 0 R /XYZ 56.6929 671.1703 null]
->> endobj
-150 0 obj <<
-/D [739 0 R /XYZ 56.6929 515.8828 null]
->> endobj
-745 0 obj <<
-/D [739 0 R /XYZ 56.6929 480.2977 null]
->> endobj
-738 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F79 711 0 R /F57 624 0 R /F58 627 0 R /F56 618 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-749 0 obj <<
-/Length 2227
-/Filter /FlateDecode
->>
-stream
-xÚå]oã6ò=¿ÂØ—ÊEÅ¢>¨æ)ífoS´A»›kè8EfbÝ*’kÉñ¦Eÿû 9¤LÉ´öpOE€h4Î÷ ‡4›Qøc3‘Êóx–å1I(Kfåã=À·œ1CZ¢Ð¥úêöìüMÍr’§Q:»½wx B…`³ÛÅÏÁ×o/¿¿½z7£„1™‡IJƒË×?ÎcÁåÍ×W¯ñÓë›÷¼¹ºœgqpûÏwW€a"N¬³+ßÿíõínÅ/·ßœ]ÝšºÖ0Ê•š¿žýü -À¨oÎ(á¹Hf[x¡„åy4{<‹N’˜s‹©ÏÞŸý00t¾ê¥>ï$\DD™Ç=1÷¹'ÉIÊ#®ÝsÝÌC± X,ª¾j›/à•‹ _J…§ÁjsWW¥²óüM’9ÜÀ<ÊrÐAñéª^2$ åBE†ª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óÍÍ<L)rVOFñi3•¹5O<EZ¦ÆÜL³½Q Æy‚•k ùŒPQ–re°^)Ïr]0Ë¢¾78ó„Lï—:‹Õ[Õ -ÂA½5²ß¶ëªe&éŽhHõ¢… ¦.” _ ªXsšm@K à'±«…46 ŸsWA½‹&)6zÀ™PZ†ƒn../eB+½¦]Éu=gÁ³Þ:•Õ‘éZŠ3¥kkÝ_PTcYK_=îL7-?í§QØ‚„>üÒèaã­IÝ`”鸎šâÑàmg´U9™
-ó6Jgoåý°‘ëJmD‘à†ƒµ1í\Éìð£1>hÄjµÝÖi4êË3>Ñ‚=ŽFoÕlrª7Xþu§Ld•m F™Ð«¡·:Ëúý®(?šÆ²9ä÷Á“#G·Í©.êïr*›#Ø
-œlV¯h(ƒ:ÖZ³Ô¤µ†Z|bZ+h5×S@´
-+®–e_=Jå›Ô5ƒ'Lwõ‡ßì_,° ['LÑY…ìÛI“‘N³qÞ÷?K2ÂãÌNµW¸%™üº)}S’?ì0j÷ÝqŸÙ¥Ï¸Ááx´s`qg·è¾ýòÐé"I``fâøQÉ!ÒG;*ç
-¾ã¤ÿ@Y6•¨í<³£"¢=™“¡à8ÉüfF4FjGM:ê”Ú»ôðFxBàtÆ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ªî^
-ÂjÕ…m¸”ky€níJ‘<Ü‹ÊÑ™âKâh¼Y WU¾+C¥ÜÆp
-wÝaÙkYnÖ®Ò#ò•¼L”·câqñ‰ 'Y9–["Øé”ÄWxfr6¥W»TãÑH=BÊØi^J†;¾œ~^ÖøÓ¼²Œ_=žï+tq¤€ÜÒ2L¸]´6 a“°4)ôµ’®Š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=
-Š&yVnr^
-#Zªôœ÷219Žóì B|ý¥¶PX—‚Eq¢daEhcÚ,ÒèÔ5ª7[ ß–”øfaÖdÊ­ëܺaë«‹B>•îüÕ
-
-endobj
-753 0 obj <<
-/Type /Page
-/Contents 754 0 R
-/Resources 752 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 717 0 R
->> endobj
-755 0 obj <<
-/D [753 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-752 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-758 0 obj <<
-/Length 2227
-/Filter /FlateDecode
->>
-stream
-xÚ¥X[wÛ6~÷¯Ð#u1Á ˜ž>¨¶“¸mÒl¬Ý—¦IILxQx±«ýõ;ƒR¤L7Û]ës0
-ß5"¥.Ò&­ÒšÄDèÚ"°á¿û÷ÄåT\|GÜc‹¹ áÙÒ´Â)`¶c#ifƒó–+á8gl]˜䥰•_£üæ5`¯ °ú§¦Gs¨êIßÚwY’·­ømÚ¶Y¹§Aw¤çf à®uÙè˜Ý
-G3©ŠÓ¦á`ÙÑ3¦Õt{ž3±60¾¦'ž¤Ë„ˆ®y^¼ÉöSï1kD‘“Xs×±H0Fs|"¡ºf…®³üDæ;{¸RŒ ߨÊpt m
-–5~TNo> =ºß7ÏŠ¬¥…±&†‚ÆhÅ¡™gÝÄö—Ò*²ý¡%r›2 r,Q]“hrÉ ’Y³Ä1Ñmоp<kM<òü‰ƒ[ÇK處Øa8åPuy2hÀSbƒú™CBˆ·¨©bô(ïé R¶ADžµíZ’»û¸|å÷úÉ
-k0%+›Î„6¦’8ƒÈF h L¨âÔútl«}­s¿Xy€è¢1§8¾µ=Ñ“<‡ê‚Vßéš
-(ƒ1- Ãâý]ÀÐBÌÆy^=RºCl˜wvCHíÏx)qƒ¬pÁìD`ó'fžÚ”;@}÷~}½zãÓ;2®Ôгïæ’ÖÛêÁ”“0²~­ ëªçÒ#÷2¡:wc8
-j¶PSMTRc×Ìœrâ¨9 9wJCçyq!¥0\çM…j„‚>U…Öײz,‰Â
-hÚ³ <륲:æµÊ+Ýþ0wíQ®-ƒ¨ï4‹‚ 1ƒUR/‚ÔtëAØ+@ÌrͼɕȨPÑsÔ7á0è‘H™\z¶‚"qñK·Ú~î²ômüð;óÅ×î(ÿ÷÷åóu/´¥Rîü§cé¶r£°W
-•Ñ¥æÃ‡è§ªÿ¿ü+#endstream
-endobj
-757 0 obj <<
-/Type /Page
-/Contents 758 0 R
-/Resources 756 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 764 0 R
->> endobj
-759 0 obj <<
-/D [757 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-154 0 obj <<
-/D [757 0 R /XYZ 85.0394 638.3105 null]
->> endobj
-760 0 obj <<
-/D [757 0 R /XYZ 85.0394 600.2421 null]
->> endobj
-158 0 obj <<
-/D [757 0 R /XYZ 85.0394 433.5475 null]
->> endobj
-761 0 obj <<
-/D [757 0 R /XYZ 85.0394 403.0897 null]
->> endobj
-162 0 obj <<
-/D [757 0 R /XYZ 85.0394 351.2066 null]
->> endobj
-762 0 obj <<
-/D [757 0 R /XYZ 85.0394 325.7421 null]
->> endobj
-166 0 obj <<
-/D [757 0 R /XYZ 85.0394 166.6305 null]
->> endobj
-763 0 obj <<
-/D [757 0 R /XYZ 85.0394 141.1659 null]
->> endobj
-756 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F57 624 0 R /F42 597 0 R /F56 618 0 R /F58 627 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-767 0 obj <<
-/Length 2286
-/Filter /FlateDecode
->>
-stream
-xÚ¥YY“Û¸~Ÿ_¡ÚK‹ƒà×>ŒÇcg6»ŽãѦ*µÙJ„$:)“”e%µÿ= 4@‘æp¶¦j„£Ñht7úëل›ȈD)O'qI™œ,·Wt²†¹wWÌÒŽ(R½ž_}ÿ6â“”¤&óÕ€WBh’°É<ÿu
- È 8ÐéüþîÝ,àŒ§tzó—ëóÛЕHàúÍ?fŒ±éõû›Û78õæý=6ÞÞ^Ïâp:ÿåãíýì·ùW·ó^¾áZ¸ÏW¿þF'9åÇ+JDšÈÉ:”°4å“íU(‘¡n¤¼º¿ú{Ïp0k–zuÂ(áΩ”O#©”|¤™’HpÑk…ÏF)è¢Þ‹jçì6
-÷›¬Q¹m«e£:KPãïëºÛ`ëçl¹)*ÕjµÀæb`: xD$èÜì:ß-¬I¢)þÊéBë*Ç1ÜÛe½S8V¯ðì@pòZµÜ73–L-a7cÓ&«Ú]Ýt8²UËMVíÖ.ØÔû2w»âؾU9° YÜ‹&§KGõtƒÍàŒúT¨_ô°·ó3pªéKTGÛnl«S¥ÚmêJÙ¾ê–Ä*id!à'Ó8ém#¬mîªUÝl=ÖQÍÕ´Ø1JÎþU_Ì$(»·_‹¶SÕR=m¡»m¶["¡Œ„ a$ÂhºMÝvÌÃŽ‡„F©´T˜ö’K‰±pB1¹ÈQîøõòEï€-*,)\s§…U]–õ¡×]aµ‘å¹ókçË
-<xÈjÀUaZÆCy$#”J§†*Û‚-ëjå‘=â„G‘ÓÅ¿(å¥ú³‡grF’4„K-(Œ
-¼¢ÿVÇY]ú?'8ò_ã†Îƒ‚Þ•´ŠÊuÝÝfk×n³e°Íå+Ÿã¶öZkÂï~ʾ¿•7ŸÞ¥ûSݲOŸiÆ?å×?üð. ¼»ýþÊïRÃs{ÊO¢½Ô†
-{ÙlWÛG“u޾®Ê£n1hÙ¡v¿Ó\ÛO/Ž8üúîý‚CýnúpÆ[:œð°W8³V•j2ËÄ\Ô_ë O{_è;ˆ(.†_dņßLÿÈÁ¶úX)ŸÝNNqvYo·ª2Žˆì2K¦@Aà€Ï’0–ˆgyž !©%]X™«º
-uSÚ=Q,Ï¥2²ŠiÝ8qìíƒÆú UrÎÇ”ö4]ñÅÝJõà-Ëðg †îÅÀ¼).¤eÝøú‚ Ê}Ï{qô©*
-P )ÝaaíÊX®..é¶e¨@çvaæXµm¶v+Šu…ZŠÍ=‹®¥Ô©ÎKŸŸ—¥át™UØ€­‹ÕÛöþ„fƒ¬³¸¨Q4fÓ»ÕcD8„¦öË%¼Ú—åñ´6¾ÊMHˆOlp=€{Õžs±ÇÔíÅ…ˆ`z_às§.‡=·]³o
-®ËŠ
-G³ÊnwJÚ—¶‚¨
-´Úrx¨zŽ'È4p<„”§\Å ^¯;Ÿw¥$‰x:…!w)7è57‡F”ÑèQ&î! ZNovQØÏ{ÕZM™Û<Z1¸FKáÉL£=EYbka§{l3³¦ ˆÃP»SK $Љ*/Üx#Eq(¼¡¸þ¦bÇŠ©Ë‰¯ €5-úDŸç „µã
-û mÚ’šÓ{6f°±ü¶Èíöø#ìÀpБÔÁ”=¦CÖocliô½®¬U¸ Rã‘_ŽoŽÏ%<›X|Ó±½ÉH8eÐe$mdŸÑl:ƒoAYë¼òÚ$uؾàØÔåc)z¢®ß´rÔˆ{pDN=v²‹Q‚Â7#ó䃚zT0³®ÊFaÀ˜¨
-×7?a#Wzº*´›Y&ý“E8|YÔèIAwîBK  ‡‡•‡S ‘(´ó`ãæèã’BúÑ'Ÿ<\À®¼éô«×Ê•Œ#>`AÎÒð>A(©.€Ò± îw9„ǰ؅ŵǰ1‰X/ÚBÍóŒa¡Þd¦y»I^uK}ílU¬ ŒAui­ÕCÖù°4mÝt[æ¡}ûÑcºˆÇ%XÁØÁ>ì™q.W€ä*÷j†‘8eñ%f×¥<^ÿEÚÊC¶Ý9ðv¯v™ÃzãTVõfÄS^»3Lð%zgiÔ˜é g{äuéÕó^uúŒÝ]Y-ñòðb‰ÜõëtÕç‚…MÐ|ióE<dí%.Ž£<©7©lŽÄyè»Ñ©¾ÑýåxžR¿°K—i–=°ÂUŒÂhüTðÏYʧõþ,¹;dÕÙºËèì!õ¾;Sö>yîêƒj `öœ‡k7í«!T}°«Ëbé+9#@ú’!ècòyöC
-endobj
-766 0 obj <<
-/Type /Page
-/Contents 767 0 R
-/Resources 765 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 764 0 R
-/Annots [ 773 0 R ]
->> endobj
-773 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [389.9997 61.5153 458.6717 73.5749]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update_policies) >>
->> endobj
-768 0 obj <<
-/D [766 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-170 0 obj <<
-/D [766 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-769 0 obj <<
-/D [766 0 R /XYZ 56.6929 748.9393 null]
->> endobj
-174 0 obj <<
-/D [766 0 R /XYZ 56.6929 700.6394 null]
->> endobj
-770 0 obj <<
-/D [766 0 R /XYZ 56.6929 671.7552 null]
->> endobj
-178 0 obj <<
-/D [766 0 R /XYZ 56.6929 470.7895 null]
->> endobj
-771 0 obj <<
-/D [766 0 R /XYZ 56.6929 441.9053 null]
->> endobj
-182 0 obj <<
-/D [766 0 R /XYZ 56.6929 233.8866 null]
->> endobj
-772 0 obj <<
-/D [766 0 R /XYZ 56.6929 205.0024 null]
->> endobj
-765 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F14 608 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-777 0 obj <<
-/Length 3193
-/Filter /FlateDecode
->>
-stream
-xÚ¥Zݓ۶¿¿BoÕÍX üw:s¶Ï‰Ó‰“ÚJ;$”„;±¡H… î|ýë»_à×Ñvf:z
-‹8z'wÙcŒ½»Tä>JîÌ‚³ßÄ`8ïjî(ê'žKnœ×ø:ë(ú„Ãòrðq#iDYÀ¥tKÇÆ*yÙ÷?nÑ—Þü¼ý.ü
-Ôò„Âñ5Ek4éúÕ»÷ox@.ÓOçÊž
-5 ¸!T%Û¥ƒd)Þ$5x…’e±Ç–Hjš ûƒdRÅIüÕí%aæÏŸ¥DÔ]9‰ ;Áã"ï(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Šç`â)
-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×ð®æçÁÆ„é?Å"™?,
-_‰ñÞ<ñQ9,‹ˆ|X½¡ñ
-ý$D<V8¡k¨,?“o AÎâÈ<O¦†¯sr”zôIï±içl¨Yrß5”“CÓÎ&<“M1+Žñ—Dg&0qn¾x"&Ða¦''B_#½£Ð©·Û±pÞªQ(‰²œS)¤Iš.}ŽœÅÞ@Ÿz(Â[´UÙcÐþTÆp`ßœÎàÌ8ØLÂz[ÀsðÔºóØ@ÕÒß8"à/þt¡úÿUüßñþÓ§A”ezø÷Æ4yL‚Lç©
-u§Ã¹äýAž‹þ?ïp;2endstream
-endobj
-776 0 obj <<
-/Type /Page
-/Contents 777 0 R
-/Resources 775 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 764 0 R
->> endobj
-778 0 obj <<
-/D [776 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-186 0 obj <<
-/D [776 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-779 0 obj <<
-/D [776 0 R /XYZ 85.0394 751.9762 null]
->> endobj
-190 0 obj <<
-/D [776 0 R /XYZ 85.0394 588.2109 null]
->> endobj
-780 0 obj <<
-/D [776 0 R /XYZ 85.0394 552.101 null]
->> endobj
-194 0 obj <<
-/D [776 0 R /XYZ 85.0394 373.7735 null]
->> endobj
-781 0 obj <<
-/D [776 0 R /XYZ 85.0394 339.0798 null]
->> endobj
-198 0 obj <<
-/D [776 0 R /XYZ 85.0394 207.963 null]
->> endobj
-782 0 obj <<
-/D [776 0 R /XYZ 85.0394 174.5031 null]
->> endobj
-775 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F11 785 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-788 0 obj <<
-/Length 2920
-/Filter /FlateDecode
->>
-stream
-xÚ­ZYsãÆ~ׯÐCª*‹ã9p:OòJk¯È‰$§*>@”PK4J¡}º§{†
-SäÉù üB…>_ŸÅ‰IlŒã¬ÎîÏþé'µÚ¡A­()´ œª%6!µ$…H6V-OõöBåQ›K£õ®J¢rÕwÄ›sÛ¢[¯wm³(‡¦k©ÓK3<QãðTó¸jÝ´M?lË¡ÛöÔØ-:mJZ´¨¡l«/»-/óÔ¬*êö{×òÚËÓ¶ýºPñ°û™RNQÛ­|ª÷=œ_ÃùAï"¶ãß¡ …‰úz±Û6ÞZú¡vÜÂ{®Ý)pš¶ÂmÖ³÷Ä&ñ˜ˆÏëPËÒîX%ýv¶†¬E¹)ç+îHôÝê¹æ°ÅÀ¦†íEñ¡È¨z"ªr(a¯FI8Á†™î[±Ú$Hl×évOŽÁ- n{æþeTιpÌ%3Q¶/?$ÙÈžtV)ˆŒ’^ßSŸ‰Í©XÄq’sZsÑÙoÅ3G’Uõª~ô6’vM;«ÔœÈTƒŽ
-!u\Øi? è&ÖQ7 5©à¸· Ùžøh=ö땉]P‡ÄoZâ V•ÈÁ½2MP°=5¯y¨ŽêÆ­¤£ù…BïA­
- gµÚÓïE×þ"¥~ÜÑÆ+š†œÆÊ3Y,5`
-^¹ž®[×:n2`¼Îçïî¯î¿½RÂ÷9ôƒ }Ënµê^|àBÒ%ÞÙN‚EIŸ,͉˜7ÃdÅ£X½ôÓ<k$ÂXeØj,>õJTZÀÆr $]o<è¯xÒ|Ô "5o.Óé¶§Ñt–B¸™•ôõ²[朾v‹–Á½­á[j"§û‰Æ/
-Ð(fjS
-}¿Ò«Ý¢®¾
-¨O¥R¸)äû©\_H™|¡´‰ç@0Y*2#5dz@!@àqúÚäN&É Bè©)Vßl›g4 €2ÆÐâRØ/2‘/ÔnŒŒì DZ@a0ïã Û‰ebøµô±ˆÄP>¬
-‹ŸD‘éOÚéˆÆ€ÈkøLfç²örOâ*Tçv#!sWBó†¬=dE¹ižêƒrâ¶l–LœÙÕ -L +Ä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 À†þ©Ûá=
-?$ø5Ãâ
-ÜD –”ÁÒ§ª»@UH¬?¤Ó£5~ÀyŒ®PDÚ(Òxæø}³:„óM2ïà§²‚«`”)Dlüý·½¦r×ñÇ⸀ôœy¤QÁµkå0g"Î<,Á*ŠaÕ,ÖJÄyjŽ.jºvùÜ-û#‡oZ«LB×$}82øD| f<ÿg "ˆ’¤p—g|­’gî
-¨Ñ9r}8›‹.Ò0ßxžO㣠eDètQ?š¬Z= ÄÀ­mfîݺÞwòœ|‡`>ï`úxƒÂo„ϰ›ª&©ÇIºp.e:?¥ÙLOiF:,o^+z4¨>3‰³èëÛûïoþºl!µ.#±d°Ç̃¨üëü8p;5O¨õ4欬c•…×\vñ’5áTM×'¹±:„MÊu¯¦*Pçv?z@šF¸Wì8§ § Ãé÷þUǃê{~mzNÿØ®šO¶b2Ñ×oñm9‹£ü’j(Ç1QA UGá¤,,2—{bNC3ñì³ô[ueÅÓZÊü¥/4r2ÉÜ­rF·Êx_µë3÷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Û
-„Õ<i(#a˜—é–F—ób1å–y7eѤgÌ]0ü. åõâáø¹<7 Ûƒ‰¢5¸¸>ÛŠ˜.YìÇìÜkÑ­Ü›)S)`˜á›=r¡± X8·sÇÁŒN@æ1ßÀ:˜¯L[O£THÔ«£Úâ2í6t´¥¥^­ÝÆÇHXîÕ
-)÷€ Úo³&+‹4§•ß ÒŠìêGÄ„(—6´%³%ªKA±·„¾¡é¡¯Ž•ý8
-Éð%©MÝTp89Š–(šØ\È€ ©áá¿^0vzazi­¼ý1€’ñÁ 
- 6åá˜ÛÆæ¼
-Ê€œøÌÕH³QƳ%6+èÀ8öîw´”Ò
-YèF)ïvÃÇ2ïå„h$ðÁ0Ù"r&OµtŒ$¤Ü¥3D'Þ´¯¶f?A¥a,Ûêöv·*0± FWÊi‚˜7¥õ {&M×´† ,ޝkÚŸªéöÙø@wÈUþàšJþÁƒ`ú_ËüîÕ häº[ê`r:Ò7åÅAu!!ã…‚ÏÄ1] Ø­¨¶ûšÚŠm Ü`EÃó´-cœÔ”ÍW÷ð­“j¼?N˜TÚªô¢ÈÔk2ŒÁKê:ò´Ä*Ñ£ÞYL8,„LˆUËØê UB…º¸þIê‹Ílð)oØ£kð1Iºr‘­Ã–¡Çvež—ç.çò”óAÔc—¯ÙÖr·*£‡}Âðå‚•Ñå½a¦_R\±m¹Œ³yª~’Xø*ˆØ;oC• Eê¶ØÄ„8|Wai¨7€UŠá,žÅ¾ÊÍ|1å8-”oýCùÅp„‚wФÓ:@~\?¹_6ÈKb ïS¿Buãx­‚ìðàÿþ­ðò3j @aÿ„WŸD­R.Zz¬y÷£âµêÿ
-endobj
-794 0 obj <<
-/Type /Page
-/Contents 795 0 R
-/Resources 793 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 764 0 R
-/Annots [ 798 0 R ]
->> endobj
-798 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [377.8384 566.941 436.8266 577.7254]
-/Subtype /Link
-/A << /S /GoTo /D (ipv6addresses) >>
->> endobj
-796 0 obj <<
-/D [794 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-214 0 obj <<
-/D [794 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-797 0 obj <<
-/D [794 0 R /XYZ 85.0394 745.0977 null]
->> endobj
-218 0 obj <<
-/D [794 0 R /XYZ 85.0394 552.7519 null]
->> endobj
-799 0 obj <<
-/D [794 0 R /XYZ 85.0394 524.1722 null]
->> endobj
-222 0 obj <<
-/D [794 0 R /XYZ 85.0394 397.0585 null]
->> endobj
-800 0 obj <<
-/D [794 0 R /XYZ 85.0394 368.4788 null]
->> endobj
-793 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-804 0 obj <<
-/Length 69
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-803 0 obj <<
-/Type /Page
-/Contents 804 0 R
-/Resources 802 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 764 0 R
->> endobj
-805 0 obj <<
-/D [803 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-802 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-808 0 obj <<
-/Length 1920
-/Filter /FlateDecode
->>
-stream
-xÚXO“Û¶¿çSø¨‰‘ÔßcÒm;yÓf:íöÔô@Kôš™ô3¥õÛoÿ
-A®¤Ç ÓIÈ !íÙ9ˆêu2¼ )Špšæ;É*
-®¨kÄI§ˆ =ŽÁ,0¦X O‹­0ÚŠÏ>n–üùøÛv'sÞ4ѽÁ¶¶Çô±àʾrž÷sTÆõ7»ÎÜ.¡Å„(׎žvƒ6í@ò=­:’Œb
-¹,ƒ ³Š‰±gìÇ>¬‡R$æÞ¤w:Qž¥¼uèD<t¢ßcVfcÙƒ)¯ßÓ‚x‚õ+rÈ"‚ò+°˜æ!ÉMH«Î{Ù*LIQ\׺W8hGR:Žn2€%µøÌ[«SYƘ\ÝU#E^À>ÐýþrV®[Ù¦€(f j68+éAe‹ÙÚæ¬ºÕ2koZu1k¾fÉß
-ÕVµ2,Û è_ç³î:ù¯ke—U)¯Å5¡.Þf2g)¯ò2*j£Â‡u(碚Û)/ò<hPCûáìÓR/j(OÆÅ2VPˆûµ"iòh,XˆÌEíÐ$[Öü# ó…Ê 8‰"ËšHá$âˆÔAˆF
-jSlïíùn°+¼²±œ Ç9hÉÞY¢Zy’þ–hJ“60;Kƒ(±šßŽúÔ|žVü¶¨å8XcpQó
-endobj
-807 0 obj <<
-/Type /Page
-/Contents 808 0 R
-/Resources 806 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 813 0 R
->> endobj
-809 0 obj <<
-/D [807 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-226 0 obj <<
-/D [807 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-810 0 obj <<
-/D [807 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-230 0 obj <<
-/D [807 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-811 0 obj <<
-/D [807 0 R /XYZ 85.0394 544.8207 null]
->> endobj
-234 0 obj <<
-/D [807 0 R /XYZ 85.0394 403.9445 null]
->> endobj
-812 0 obj <<
-/D [807 0 R /XYZ 85.0394 368.2811 null]
->> endobj
-806 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-816 0 obj <<
-/Length 69
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-815 0 obj <<
-/Type /Page
-/Contents 816 0 R
-/Resources 814 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 813 0 R
->> endobj
-817 0 obj <<
-/D [815 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-814 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-820 0 obj <<
-/Length 3052
-/Filter /FlateDecode
->>
-stream
-xÚÍË’ã¶ñ>_¡‹+ÚÔÆ›àæä×&냓Ø{³]ŠâŒXK‘²HíxòõéF)Q£MF©ré
-
-Îtl<jt°
-,¨=ôq­<U–bŽnRš¯Ûâ€ø×o‘þ»ï> þ?³ ôT/´ÌòL¢óÿíîç_ùb ±âû;ÎTæÌâ 8
-æ¬ÊŽ€Ÿ!$É2çÜ<³É€1£œ!©3à
-
-â/³a%Ôq:ôj4u„`øö‡Ÿhɸ§µ 8)Ï·É\‡d«¹_¤Ô3žê ¡xtµÛgÖ—]ÏŽ'q«S×l4\Äù‚šŽàœ
-˜A ~MM•d†giPÔö¢¢FتêåKÊ:¡²,ªm^_ר¿c2¥Dê{: l2íi¥júò±Üw´þ)¯¾Â€7<|rl6Œ4†Þtå.ßç=ÁÛP‘¤(»nNQá†ÿ‹ý ã
-ɶh·àãÖÄž¿Cš‘dÀ*ÈlÈ™¡Šâ*¦¿-Bz7©~«¡Õæ°-÷UAËÕØ­°7
-Y h Ò™¿8C@jͦÍk5íµ.Œ>=‡‘øZù£Äçüez
-ï³!†ññÅ1>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
-ø»~‚YŸOLbÊVÃó;,E9:~>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
-endobj
-819 0 obj <<
-/Type /Page
-/Contents 820 0 R
-/Resources 818 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 813 0 R
-/Annots [ 826 0 R ]
->> endobj
-826 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [356.2946 363.7923 412.5133 376.6291]
-/Subtype /Link
-/A << /S /GoTo /D (address_match_lists) >>
->> endobj
-821 0 obj <<
-/D [819 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-238 0 obj <<
-/D [819 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-822 0 obj <<
-/D [819 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-242 0 obj <<
-/D [819 0 R /XYZ 85.0394 479.565 null]
->> endobj
-823 0 obj <<
-/D [819 0 R /XYZ 85.0394 441.8891 null]
->> endobj
-824 0 obj <<
-/D [819 0 R /XYZ 85.0394 424.9629 null]
->> endobj
-825 0 obj <<
-/D [819 0 R /XYZ 85.0394 413.0077 null]
->> endobj
-818 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-830 0 obj <<
-/Length 3528
-/Filter /FlateDecode
->>
-stream
-xÚÍÛr·õ]_Á>…ʘî—dúà$rê4qRG™>$gE®ä“KywiYiûï=¸rw ®”J™éxl€XàààÜÏLfþ™HjfÊp$0³åæÏ®áÛ×'$ÌYÄI‹þ¬/.NÎ^H:3ÈH*gW=Xa­Éìbõó\"‚Nžùý«/¿þéõóSÅç/¿uº Ï_¼üöÜ÷ο=ÿîüÕÅð 33ÿòoϸ8í¿É
-ÎýÍ FÌh1»…cèlsÂC‚3GÖ'?žü#ì}uKsäœ I›-´DTIq|[¿†mCW¤”У]R#I°å ÖˆÒ=K„ê±Dqd´š)
-%ˆ÷ˆµÕ¥ŠÕªÉPˆ2d¬Lûc<ƒƒ&\m×ëí)™ß:R
-1 ;‚¶Â›!A ÿ QDCøŒæHÄ)(¤2=<‘FxFÕPtˆ‚Ƈûæøbú›FòàiòÃe<é/Ïí |PQ>ÐX_¸…²¬ì¹›Ç90PÄ L
-ÉÝß•wã#ðëD‰ý¼ÇZˆpч˜ñŠ ƒVçøU«¬G:€ˆE˜smqE£`¯¶›¢ªl!ðž3¥žî¤ â=G¥
-УR ÏZ›2o›ÀF]qž ¼ñM[Öõ
-æÐ9Ûqp Ç'²#…oÚ·…_·ò¿-ó !ÖcRÎlë‡/ƒÕSÀ¡ÈÐèíZ·Ú9ØÆwº¦¨ÛbÙUÛÚ´år×T~\¥úÒú8ëJ’À+ÌÙ´N)Àê{u*Î{:êAœÐ©>~ëªí¢U-q?Ùõ¬01&æÛº o7[/U5´¬Æ,Zã a“ऄy:Ê$ˆ÷†Y÷¦H›¼½ ÍŸ¢u¦
- j³woEÔ£
-•ȲR;ûè „ Þ­ƒà®´a¾ý}Y‰‡&(ÇTÔ ŽKØj¹Þµ€ŠÍlYýK› 0
-@–Ëò¦+.×Q*çŠõ®ôŸ6ÕõÛÎ^í°çy”¬+ˆ†£1¶Òçl±sÐYná¼;ÿ£
-†ùömµ "VÅ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@%
-c\ðÂÊLò!¾]"M°Ü×™=G¥­©Q>™¦Ë²Mv-fBÛ` Š+Kù`ÁºA‚í é͉³”¾>v]Ž£˜ãi?Ò{dôøgV±8¤Í”é*—)Á<mï¼wÉU±Ò¼'«bõ!¯b ðó–£Â-ØåÉðKïAŠlÈ4@°Þæ¢e ¡dÒA¼Ï+—åš@†­Ÿ‰.ðb@¼,ÒåÍ1KŠŠÊ”ÇhPܲWkšs‚cè6çŒÀÔ“t{Ü5»òÈMcl| 5ô¼ m"–WźÍAbÌÊr¤\¨d{,a…µW¶Ò½Œ.
- C a¨A´ã•?wnB¬ûI—¬$ƒ+0Yj:yh
-
-„é~<B\ôA攜#Iñ
-f«è‡²À3)̤¶{³Ÿàå‚Cè™tWú
-D%8ÄïŠ.^|[Ù¢Îá3 l«Sº•€ýx™ÉÇ|‘¸¿ªð›¾ÙØýÞø›F[¢ù«o?¿)×åÒÿýsçé£]Hþñ¥Ÿûµ¡øök°œÜ³<!H(´ ­»NºySD"Ú9gë²¾¶zöÇ¿£j/EÝ輩Vq¾§ÀrýÆßæ÷ÿuŒ:~ü?¾qÏÖù¶?/W Á‹yöÑÀ¾¯Jû‚°®öú^3¡óS[\ç”ÄX+M^ç[ÿ¤`$
-ºk'QÐ¥=#ã7Mµ)šÊ¥bð3¼3°ï³„UٕͦªË°x¹Làíe—"·öþmt>
-Xða{S6…=!˜«=6ä½Ëåð=$i4mowJæEêkh*Õ4G4×(̽=Y/²A·ázŠè>Ù*¹­vÛtGîóG”é¬íŠÎI°?¯ð!¾E:Hv Q¼"TÄRµíªn×ÅÇSCîÒÀ]¯NZ bS¡ÑUeLÏ]%ÏgìQ´BîíÞªôp_Ó«êëÏŽ½e& h¡%Ÿ~¼ÝŸåL#áýÈ’(&{°|!„¨ñ¦
-àM§7“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ƒ~
-Ý÷„A›o÷MHåk²Š>hj„
-#!Zÿ!úY3ΪޚCU³eð«1TÚýš¥œZRÙ{T”±ëY#úÏF£¹JâË0÷ÖÕG ¹û@Gœ"/ìYèWŸƒ¬"¦h·;vÂ’0xˆ˜=îˆ( X|Ä¡ø`+2ÊI £…s1tê£îÌEpã˜CÝ‚ÅÍXؾ;„»ÉÃH˜Om9Oˆ š¢„= ÀUºci a¯±õœlÝî&L©wº){‚ÛåO4”Ž€¤$€r°ÄcxýÃEàir(˜±®a!jÎÀœµƒÆ‹¶È ê×l÷Ø?é"u³°Ñg×vCÏKÁ£Á1N±ÝÁV‰6lz£8S››ÄX¢˜/NCŸ³AÐ6‰Š#Üg¾Œ±2Êc iíÝ“ U.ó!ÀZ’ªëö©?!k޲g3 ·tN„—º© ÌXQÃ$N½»Ú£É.Ñ@$ë…¼ÜÚFæc9rãÖI:­dšË S¡Pn˜€aZe…‰ôEœk†#”uÑ´Cµ:ðâiA'~¥)/~=C.ñ…p ˆÚŸ{ÝÍ‹} {¿@+9¢>Üô+òÕr `Y–|†Þ"Š&ÇZ0”÷;“fèB!Èø3tc?
-epÄ'Q[€>©ÎTLÏ A %c9Ê೑±ª-ÁR)­–jU<nÚzŽÝ(õ“$ÎFn€l{”ȳä8Ž"Æ!À¡_0S9Fµ õÞUÛªV]}¸‚À²i‹pVé'‘LCÌ4h$PÙòJí'JJ EÄUp4€A¯»&D$”æH´÷Ѫ*S*ÂJ{”‹|àêˆ.úc%‡þºç…ã-h=m*s0,Û9o%6ޝ‹b(ðl°z£­˜ANl…v
-{øTc`§•WÍæ*‰aØ>&˜èj›¤ß“"'°ãлmíêOj»«õlñEÒžx.Õ?ôåU}‹A8÷¾‚Pf'ývÆ'¡“inC•(¡t[pŽ—Ž(ª‹Ì=§ƒç3‹À’j®€°ºeÓBŒ£êL„¦än¸Â¦$\ÓÈ{óÔóàXµuÛ>îwh ÒT0ˆ&¼"Øxf`•Hw'Ö5Þ=5" ÌÌ{ß!ð(¬PÂȆÀ¯hõx•ÆÆí盦~$6æ›ºÒØ:²ÈNqÕÙ>Àýêá@ˆúHUN0Ñ5h«ÃHäÇó
-n÷£#™ôYTâÊã·"A~´Šõ¾³ºI2c'µÆn býò"½–怚vRòI­õ¬;’u=)½d¬\
-0/u u;õ£0e.„yGèí'âk." o;òôf)(zá—»mAÁ‘åš&mcÏVôÁ§z2 7Ñj(ÍŸ(u̬ìí¾ª]íêíŸ]>§ùðHóС¡DTÄf|ïî©D”Br‰PW"ÂÌ>yxÕbÒãp깑®#j^-}[÷Ë`$
-×âüí¿QÇ?™£Ô—YÎÿC
- ÑÏÂ<µL¡ a~ʹû¿õ9ëÿ×kendstream
-endobj
-835 0 obj <<
-/Type /Page
-/Contents 836 0 R
-/Resources 834 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 813 0 R
->> endobj
-837 0 obj <<
-/D [835 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-258 0 obj <<
-/D [835 0 R /XYZ 85.0394 497.0473 null]
->> endobj
-838 0 obj <<
-/D [835 0 R /XYZ 85.0394 468.4726 null]
->> endobj
-262 0 obj <<
-/D [835 0 R /XYZ 85.0394 408.9221 null]
->> endobj
-839 0 obj <<
-/D [835 0 R /XYZ 85.0394 382.8699 null]
->> endobj
-266 0 obj <<
-/D [835 0 R /XYZ 85.0394 310.3501 null]
->> endobj
-840 0 obj <<
-/D [835 0 R /XYZ 85.0394 283.0525 null]
->> endobj
-834 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-844 0 obj <<
-/Length 2301
-/Filter /FlateDecode
->>
-stream
-xÚÍZmoã6þž_! j£k._DRì}J³I.E7í%.‡¶À)2 •%W’“fý ßd9Vì¤ñÁ+¾ ‡ä gž‡tH„ቸ@BQI#Ž ²ÅŽî ïüˆx™Išô¥¾›}<4RH *¢émOW‚p’h:ûe$EcЀG'?^ž]œÿ|u<–ñhzñãåxB9]üpêJçWÇŸ?_'$ádtòÏ㟦§W®Kxß]\~r-Ê}žQzuzvzuzyr:þmúýÑé´ÛK¿3³‘?Ž~ù G3Øö÷G1•ðè*¥h´8Š9C<f,´G×GÿêözíÐAûŒ([mË!r…£ÌðãÇñD`<šÎóƕ·kWhÚ´n]±ºußÔ}²j±Ðe Ö#Ôêð#Jý§Pä¥6F‚•NAŠsº1m˜, 64p5}¯Ë°¨ju7÷cÛMEu—giQ<îšp¹µ—nŸËZßçÕªy²7Pöñ,f=C‚jªP’HeU_ÏuQLšö±
-ì ²"†TrÒÍÌr³¼ðp^§‹EZ?ƒµ L¬Xˆ>
-a扔”ûd[ú3MÞX ;ðµn
-u‡jVG
-M Øk»†9°]øî@îotg^oó›Ç5¹wÓö—I€1Â}$p©ºœe‹ƒK‹,,nÕæEÞ>Ž !£.\[çmæ~êAz@2Ž8gÉ2®ÁŽæ´W3½×ƒ^®ÙH—Ží°Yo=‡2Zˆ‹Ãå*˜RÄŒï1•ˆ$>ü®÷¬Yê,7²6Ø«Á½„¤³èhv9ÈôXrlZrß“®à˜ÃU8ëH
-tÂuVƒt°Î¿ôXЪéjz}q¾Ã]=K*KÜ]
-’1ºÇ]˜!*c-pg½3&x˘FaÙ”Qb 0„úÞæ|h½–{ÄáåÂÑú¯ÇYY§`(“ÞÁ½aÔ¸†À€¦¤õÁ]}KÖ]d@“QBéž”DaOLÄUЇZþ-ÉÂÊ6@ÆV< Xàh¶ZfÀ€/e€‡¨Ä“F[ÊZ_hü×|À£ùÝÜ÷<èuÙ/§*ì11-³T/ íSVb^²˜Üt³¹ò,lCdx8³F\>hL:À3׿'¦çŒ÷à
-6îBn«®¿iW7^eé55Ez?ø&÷Å> ˜dÜMféO‘î¦}³¼ßh'
-tï§Œ˜ß\r®–©^ï0“A\ÝÕ}Óߥehß¾ªƒ@˜ÆJ¸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>\œ}<N¤ásËŽcùüëó÷ßÐHFÓÞ¿=ÿöÇ'Ç©ž_œÿðž†?ž½=ûxöþôì8Îx_
-{^x{þîŒZß~<ùþû“Ç¿\|wtvÑex^ÁäŸG?ýÂgK8öwGœ©Ì™Ù=t8Y&gë#m3Z©8²:útô÷Žà`Ö¿:%?£3N¦Ôr&ËŒ‘# šŒY%•— Z€
-%éXÂ7–ËMÑ4¿®óvqóëªlZ¿6ÙZLÚþý ±0>ð SÆ­qÝä#ú¦ø™sY•mYW4’WKjüØä×EØFí?éÅMÑñÒ/Âe°8Jc—0LX×4Æ´™çMS^WMèУyX_Ö«rA=’*¶Ú:,«ÂDy,ÜĉvîeJs(X°mÅÝü<lu]´aŸ26zÚWžR½1r»)Á
-¨sפ)¥™tÒÕZ_±Žx‚È4‘§æ50%øüd±è–œÖUKÛå½Ã…Ôü™~rú®§`~ЋHY¦Àþqã÷u GP
-Äs“·Ø²^@82b'38‡Ìü% “pt}×—adI–S,iø¾lo&ì@¦Že<‡ Á‚Ñê4¬¹,®jâŽ6*ÃÆ‹È=q`QðK)VMqSÐ[o`,ÍæUüBA–Š-µÀ÷¹_¬Þ½
-4*PBÐ[dÅwV«ú¾XNÊýÀ/ºªqUY]S•4Aêò®\µIY½ÞŽœBh–¦©œ«˜SZ?%vB0¦é8vþ¹·"#¼—Ø^è=´B3¾1&•t‡J ‚1—fr™– ¢¼1†éÈòêaÂj2Å”0&XÍ÷hÁÒVÁanjp¶-bÃÓÚêY`F=ÿ€
-¸±æÿ'2Spj©Åc2Ó"'s¬êªøcB«ê§ÉlÀÌKÉ,渧“Œoì—¡Üc2S‚­/ŽU½ÈWxü? ¸TA|EŸNåüüÃMC”DiȆ¡>æÆ}n€Ed®0Pí}½ùL²j‹ÍU¾(ŽÅ<¾Pu‘gËÚyš‡RèÕ dò<9÷ªÀá$ØÜÓIÆ7öªN[+Õ£æÎSfuW]…‰üɪ™ö‘Ê= !¢)š!¥ú™ =I§8×é ‡¯âüýM‰ÉxÕà©fJ{79*W(B/Böz˜"37ÿT{,+ˆHCË–5 VuK[‚
-_À\Êex#§Ç}þ@&Ã{˶Y—%z¦ÄÀ¤¤D}ªÿFVED®Û›†úÞˆ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Š
-Àgªi¨ˆ[)0¯÷ ó ä­dèoo¤¤Û)é.
-û¡h‚ÄÏaĆ5=óàQîó¼íÍÒ½R•:ƒ*OXpEwÏkG1’Ü•«4 ~ ñª[vH°ŠI¬€x¼9ÜÅ" RΕÜÅ
-[¤`í†À¼ÛPy`}ëc.
-:L+¶VÌü¾\-ýUÙX+oHûWªbù¢ ™^pàÓȱ
-Œ ë¶àÙë×SôbÂ…‚‹²‚„;€}Še¼­ÞÄÊø·r}·Žxdq·AÌ$„$ékœ29¿_R2Üu_m¯ÉŒ/FÈèCÈÏRê)«ƒ„nœ!ê½а,À>Xå)úm ѵ ^ÄýÖ½H&lO0áºÐ¼*u. å°¨}>t‰“Å è’J¼73ݾ  hΉL¯¨¾6&UcÅúÏ*»¿ èY:õå –Msæ{øŒ½a,-½éŒJÓƒNO‰n7±Ü @õ¢¥:ÇP“š}Å
-:>ÿ¼êr.¬Øý“Àè+rgxÉÄå
-°]÷å³é›x ò0…›5`}+²Þèw3`nS̼ÂIý¸9L§`3‡XfL·¯¹Ëiˆá2QH±ò×-A8ñÛû´W@x…"_<âì#}At @¥`ovK
-endobj
-853 0 obj <<
-/Type /Page
-/Contents 854 0 R
-/Resources 852 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 861 0 R
->> endobj
-855 0 obj <<
-/D [853 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-274 0 obj <<
-/D [853 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-856 0 obj <<
-/D [853 0 R /XYZ 85.0394 752.4085 null]
->> endobj
-278 0 obj <<
-/D [853 0 R /XYZ 85.0394 683.64 null]
->> endobj
-857 0 obj <<
-/D [853 0 R /XYZ 85.0394 653.5261 null]
->> endobj
-858 0 obj <<
-/D [853 0 R /XYZ 85.0394 576.1881 null]
->> endobj
-859 0 obj <<
-/D [853 0 R /XYZ 85.0394 564.2329 null]
->> endobj
-282 0 obj <<
-/D [853 0 R /XYZ 85.0394 420.3273 null]
->> endobj
-860 0 obj <<
-/D [853 0 R /XYZ 85.0394 391.7481 null]
->> endobj
-286 0 obj <<
-/D [853 0 R /XYZ 85.0394 295.8129 null]
->> endobj
-718 0 obj <<
-/D [853 0 R /XYZ 85.0394 264.2689 null]
->> endobj
-852 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F57 624 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-864 0 obj <<
-/Length 3271
-/Filter /FlateDecode
->>
-stream
-xÚµZݓ۶¿¿Bº‹Á7ÀøÉqÎ“ž/3í8™O¤$Ž%R)Ÿ¯þïÝÅ)ò>ÚLGåb±Øßâ3?>Ó&1©Hg6U‰f\Ï–» 6[ÃØû h‘hѧúîöâ›wFÌÒ$5ÂÌnW=^.aÎñÙmþin‘\6ûó‡w×ï½ysiÕüöúç— ¡ÙüÝõWÔzóæ§ŸÞÜ\.¸Ó|þöOo~¹½º¡!x|wýá{êIéñÓ›«wW7WÞ^]þ~ûÃÅÕm·–þz9“¸\|úÍrXö,‘©Ó³{xa OS1Û](-­¤Œ=Û‹éöFý§SúëhR%æG*=¬gÔ¸™Ô·N#…ìô­ä”¾#êûÓM±«ÛÔ`ÅüC¶ó-9ÿ>ƒîŠzßÖU{¸än^oi0Ûï·å2k˺úý\aBëD:-g}YF+쨞Yhjg|(sYf5i¢¹àƒYŸÐXGÿÜü#¾8ÿÇb‰k'íÈD&<çIÉ%Õ3z訞‘cÌ åøiNB¬êmMYAs—ÄËîêcKc˺ú1±>ÊjM£Ÿ‹‡%X•XÅÕlÁy’j-zšaú~ ÜÙV€$‡*_¢æX¢¬ 4 Í‹0†r—8Ë»^(\Ï«zb*!À‡¬ l–hˆõ¶™˜N:`­y lÚ¬-vEÕ벡çÞ[qÑÀÀ«‰ÉRžXm¢ÌøB>5l·„8FT÷åvKÌ›"ÌvÜÓ3£G^¬²ã6Œ-®„›¬ªŠð²-›¶¨hsàÕo!<ÛMÆëz—-?“6!ê¼úlDz<«„EK§æ\Ø„Áã+øn•SÙ‚ë_¾[ÖǪ-ûìÐÒзßr¤–óùuE$í¦ Ÿ-³¦xu¹PÜžxfÛ¦&ºû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«¼<Lð7V¯£ÅÝg 1oöŲD%9uIJul¸}qðîXn[ ÔàHÞo/S1¯ilIö™QúeÑðrÃÎÀ
-À1
-ÖÐÑ95övN/;ˆøÙ:~ØÑ´›cèòÒa——ò<ùTR61JñgBžJXzŠã>ä©+È×-1ßeŸI,\Gˆ×r-í³x]7My·Å ’†öNÚù± YEÏâ+äIÊ’06ú=N0'  
-ÁË”OüÒúâ
-L&©•bh
-ž€÷iÊcAAñ„F5 ¾g ùØ^fUè\.©¼Ã0ÒâÆéëhÉ¢=ÂH^4å)ñùºG‡¸*&!—— A)Ì€a¨¢†µ‚®À€ž? | Uðn°mq¬c ™šg%ÙFª®:ô¹%ÎÐÁm¿TlTEÄäícÐz²Ø
-W ËË&Xtß
-OšÅÚäUg aòŠžx‚1e.vµ÷S~d¹çÇBßNÁc<4é$O®å¹
-¾8y¾Û…§×S,Q)3ýÒØ³è6
-{©EbSÊšñþC_.8cˆ]—Ûc4÷±gExùqÈ@ÛS' ·±IƒÑ&µWå¶À„ôzJ"6–ļ@’ï 4Ë*–Ò~“ƒüêÁéX;g"ÞNbÅrª¨¢–`°LUG¿R#ü/EÈx
-áQ`§òPϳöŒz_—‘Ý=&ÂÍ#g›àŒ
-Ãí®¬ "ï• ÙÀÙ‰(梲¢ðu%<=ÂkCaÙgSh7R(‚×Y.=C"÷‡² ¸Å„‚¶»öˆŸ™
-Q–,|››šˆÚg
-çáx—¸_ÐR'Î4l"Á1žÓxªØHã q'•C×ið„¸3@ã©uàâ©SqMž,ž˜"1ýåø ×1¥]añ€Êªý“À鉄óyV¬õ01=âÐÜÊ
-9–huÉcÿ½’:Á?CMÈͺÔþ‡ÿ—uú•²x-ùCu‰rÀ$…*£?ÿh0‹þo'àßendstream
-endobj
-863 0 obj <<
-/Type /Page
-/Contents 864 0 R
-/Resources 862 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 861 0 R
-/Annots [ 866 0 R 867 0 R 872 0 R 873 0 R 874 0 R ]
->> endobj
-866 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 755.8266 256.3816 767.8862]
-/Subtype /Link
-/A << /S /GoTo /D (rndc) >>
->> endobj
-867 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [268.5158 755.8266 332.4306 767.8862]
-/Subtype /Link
-/A << /S /GoTo /D (admin_tools) >>
->> endobj
-872 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [378.2799 116.2526 428.5017 128.3123]
-/Subtype /Link
-/A << /S /GoTo /D (tsig) >>
->> endobj
-873 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [112.234 104.965 168.4527 116.3571]
-/Subtype /Link
-/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
->> endobj
-874 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [75.273 61.5153 131.4917 73.5749]
-/Subtype /Link
-/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
->> endobj
-865 0 obj <<
-/D [863 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-290 0 obj <<
-/D [863 0 R /XYZ 56.6929 441.8384 null]
->> endobj
-868 0 obj <<
-/D [863 0 R /XYZ 56.6929 416.1193 null]
->> endobj
-294 0 obj <<
-/D [863 0 R /XYZ 56.6929 378.9792 null]
->> endobj
-869 0 obj <<
-/D [863 0 R /XYZ 56.6929 348.5817 null]
->> endobj
-298 0 obj <<
-/D [863 0 R /XYZ 56.6929 276.8275 null]
->> endobj
-870 0 obj <<
-/D [863 0 R /XYZ 56.6929 248.1435 null]
->> endobj
-302 0 obj <<
-/D [863 0 R /XYZ 56.6929 167.2435 null]
->> endobj
-871 0 obj <<
-/D [863 0 R /XYZ 56.6929 135.7502 null]
->> endobj
-862 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R /F58 627 0 R /F14 608 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-878 0 obj <<
-/Length 2414
-/Filter /FlateDecode
->>
-stream
-xÚ¥Ù’Û6ò}¾Bš*‹&^ñ“㌽“ÚØÙñ¤ò`»\ Ò°Ìc"RV´›üûv£!qâ©réA@hô}€bÃOÌò$ŠU¡gY¡£$ÉlY_ij ¬½¹¼gá7-Æ»~¼½xþ:•³"*R™În×#\y繘ݮ>Ì_ýë寷W7— ™Äó4º\$i<ÿñúíO)èïÕ»·¯¯ßüvóò2ÓóÛëwo |sõúêæêí««Ë…Èç%cxäÀëë_ÑèÍÍË_~yysùéöç‹«Û—1¿"VÈÈ>ų°ýóE©"Of{˜Ä‘(
-9«/t¢¢D+å!ÕÅû‹ÿ G«îè”ü•GI.³ j5%À¤ˆR%•àí½E&ž¿Î²ÑV‘G…J3À{¾ØÃ)£BJ¸)MÈžÀªŒŠ<ϧ] c”Ž‹4™DºHNØ(WÄEÀ°Q‘$’¹xšSbnª®…‘Ìæ_švßÐÐtô߃4h X†A:oLmÝI9/y“¡•U[›’Ïã.íšò­4+W¶éËõ¡l6t(¸@1ƒS±œ_÷^ÆxçñuÖ±j–‘B‚¤˜-Ç7nWh"öe¨D•ijßÙíW»’Š£Xx!u½ém DÚE¥ è ÐöRäs <v}G‹ÝÙöþÞ0„o%hK0Çž+7 0ç`û²¿÷gœæEäÄŸÏÛ-‰ådnV+¢¥ãýµé—÷$+ ¬§²eU•Drž)y>Ú@; #¢aT6˶&•Áž†aýÞ|µ´vgmC°33°n@ÖG’YͳÁÊ
-°®jÓnAíç é?öÌVç’ë£a˜ÖÙ?yuåR&¬êá¢3ßÇ’IV̲\Mù÷û¶Ç¸£œðíTFRCܶ=îÛ ØX3/(G%R”·`YýÖ A¤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^<b.2´ÎÒ!~,·¶?µ-2ÈO:™¥…ŠtªÓï¶•ãbŒòÜV´Œ£DAf¶QüršŸˆr`¹Pc{aºpì”1¸/´¤‹;KJU™'2tBœ]=pw Šï0Üç ït.;é>Ó{† c4]¤š&"ÒÊo$£!âv¶Æ( RH)Y4P£ÄóªÝl(ò
-ÿçDê*”<1÷´cyošÆVÁä3åÊ> ø'1mZ—o0è!8r(ð¬TQuV ¾b{^ÓÑ숰ÙÕw˜’püòQ( ûïhºkª².A1g>…¡8`¶+ÿkÏFrÆ'“Ì2Ý¡ùŽÇŸ×fYVš¦2€?Õ¯ìv;E×_žßª:òñbL‡˜fÄbZ„KÁ-a
-A¨
-„·¶¡÷fÛ Öáooá¤õ ¼;Q¦DÈKÙ¬ÛàØÊÞíSUU•—e°õ
-&’VIUˆóÚ\)hÚ©Ûì¸
-F¨«8qq¾šmiÑ&qÒ®i×À´>ô'q²F;Ã¥FØK:DóÐcÝa×ÒMp§ ÚS±ð5†OçìQ®Ïrjøá~k¨ÛÀ¤ØµËøî¨{kwýî§µÚö÷íª{FÕ?^^8r ŸS™Ç5œ¹xÂ[ö奘S"\þU±oéT<t3‚»3²<¢fFû´så^€Kƒ aQœø²dpɉº-ŽÒÜ‹t¢m¹*°•]²ÝÞ·{ òÛË
-¤iy‚–€ÿ5´O`ɾö [¢ ‰]±·eP`jî1ÒÂQñÎUÀRk¨…§XÓP|èæ°ò,RBç( vå’N|©¥¹ÉÈŠœÓÔð¾Ú4LÛÃÉ
-L2.­_èÁÀ:
-«ƒRa¼iùDœÔƒsM9 G9î‘lœz|L5·’žLnG×'Q壔z"TàÓLZä^_‹Í7ß[""êa’|›{|YEfåŽÒãªÂGm•J·Hpñvë©:MœüJéñ›ÅÙK]Ûå(õåŒ7­ÏŠ^˜mcC)×-;-É+ Þ§ð @,Â"¨›òƒ*
-endobj
-877 0 obj <<
-/Type /Page
-/Contents 878 0 R
-/Resources 876 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 861 0 R
->> endobj
-879 0 obj <<
-/D [877 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-306 0 obj <<
-/D [877 0 R /XYZ 85.0394 662.5434 null]
->> endobj
-880 0 obj <<
-/D [877 0 R /XYZ 85.0394 634.6304 null]
->> endobj
-310 0 obj <<
-/D [877 0 R /XYZ 85.0394 376.1585 null]
->> endobj
-881 0 obj <<
-/D [877 0 R /XYZ 85.0394 345.4362 null]
->> endobj
-314 0 obj <<
-/D [877 0 R /XYZ 85.0394 136.7105 null]
->> endobj
-882 0 obj <<
-/D [877 0 R /XYZ 85.0394 113.7908 null]
->> endobj
-876 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F77 703 0 R /F42 597 0 R /F57 624 0 R /F56 618 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-885 0 obj <<
-/Length 4116
-/Filter /FlateDecode
->>
-stream
-xÚ­]sã¶ñݿ“—È3C|‘`ïéšÞ¥×6—öê>tÒN†–(™=‰TEÊŠÛéï.v’dûÚŒ.@`±»ØOH\§ð×&K²B×y¡“
-s½Ø^¥×kèûîJð˜¹4úõÝÕ7ï3y]$E&³ë»Õh.›¤ÖŠë»å³,‘É ÌξýáãûßýåÓÛ›\Ïî>üðñf.M:{ÿáï¨õݧ·ßÿöÓÍ\X#fßþöíïÞ}¢®Œçøõ‡¿!HA “~z÷þݧw¿}wó÷»ß]½» {ïW¤
-7òÏ«ÿž^/aÛ¿»JUXs}„—4E!¯·WÚ¨Äh¥<dsõç«?… G½îÓ(ýDšH´:' V1š"É”TŽ€í®¯Û¦Ülž`k*Ÿ•›®Å–mêmݰ¨¶­º®\WíªÇj_÷O<Þ6~xÙðXovÏ•‹Eµë«%õß?,°x(›ÆÏó·Ô¤¡gY­Êƪ;¤<ìo, ZÚ¤7V7«–‰ lb™Á
-âG]ϵΓ\ ¢Ia Ê0U"Ÿ*@eO/}KϺYlËŠ^ÊJB˜Äjë5å6~Ž“J“¢Pñùºjª}éhä«·¼B×—ÛÝ-´•&Š!p#×íþ‰Þp F§Y~Ó2¾§ð9…MOaG¡³Ä*›M)0ÐèîžMË
-•ÚYëĆDLÀ!VÅ”¾t
-~ãÄK€ZY””¢.h[Ç£”žŸ«jG½Š§Þ,é}´¥”%0õŠ%“£oò1I  i–{Êo€òû.A>ž“OˆàX:wföC×Së¾BåFê ßk†ãqÃ'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Ö ï<gŽ2Ü¥ÅìcK ¯ö±=0ß‚{…/Ÿ!LáØofOøMÌÎ’Q¯¬ú¹F_iMoD=h2r¢»”=Vî`gË –ú¢ÏlÕË`³p½àfVXƬ〆Ÿà
-,©Û‡:,Įٮ©oíèÕû$±Nd]ÈBܰ6b ­svdp Cps œÔ,ϳ—|ˆ½MØ´ó H{ª 4R~âv}‹T™ÙB$⼸Sìã,B´xÝԦϒÑó
-ÊÐj)_å< Š/œYurV[:«€bÝ;aHc@Wpl”«3œ$ð‚~;ÄßäÔ¤àåeö$
-ɈŸAÇ¿ÝlH\ “AİØ×÷|ß>òQKÀ£©ŽÔ€
-šV‘_Ø•. •óz‡•%‹*|߯$ã—ÜšWÐ[$²bBp”B™ãÌn…m;^wYö%G\Ô<=±Æäƒª”¼y|¢\õNñߦRްA§ ‡¦¯ùË®Ýro{èçíj~OTÀ¶Â¨ªî¶ôJ˜mº°çù÷7¦DUØ]ZÑãBÂLcÊfªÞ‚CÇAgùs½=l½sÊU¯zçLÒ÷ÕCùXû˜öbòÀÈqÜëšk9ó8îòcDS¾#šÆ8Uu2ǹ´ø}™|Ù˜Ú
-ÞÑ©JVæÜ“ˆžrPdS©ë~q„æ"Ï€ ÚN÷"ë,ÅtË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!<rÀ¹},Ãg5ËåkgÙ–õ&®t@÷â$^þ–%¨êØŽœg"Ï‘)`û/!óê-]d®´…a/γÙEé«’g74× ¬.È›hpb
-ÔB^¤Ï¡d!´—ÛÃa±‹Í"“lHa]œÅ» ‹}”Y 9…4¯Ey*ï1Æõ}ýÚ™VýîSñÚI6í¢ÜÄ¢h "˜¥ò‹æÿû<f<ü…ðQ¿Ð<úÚ—ù…ðÉbóåäú%DgÊŽ§Ê_Ò\f
-sÚ.bãÄS‘ä¹>1ËäÈÂ×XÄDÓ»ŽoÀKwØíÚ=0ðJÆ5|œbp¿/9ÃáÎ`vÎPªÙo)¯ZÍ
-þ9É<hCNØ£ïÞø$‰G üøc;®ˆ‘ÛÔM£Š $ΰXì>&”
-†Žî  8vG¥"©•/EK:Åàóy×b!S¤CD¸Æš4\s¸?ô„™Ä86g£_hp¦R3µfë¸TA ‘ÛPž¡$Çrß ÃÇhXØÔ!oTÇSȉ‘J¿N˜ô8>óIE÷b°)Gg;ðl"ôÄšLõ›€LçÏ_¯‚Ðܪ ò½R¼¾—zS/ªø¥(pÙ<M(U©8§*gKØÝ.˜Peó¤Pö¤ç’Ç©¿“®†£Áex=9å4ãl*z6Õò–Ê.ÍÙƒ¶xùz‚NRðP`À•Ç 0Ì
-Ûé—Õ~!’Ò2&ÿL1òœŠ“ä_°+Æ÷´Ø©0ÅÐÛU{Wý|Í_v=œ¾IFƒ;Üøž¿éi­r‹N‚²°Ir'‹Yx6½«rN[*OT;Ùh+ùv¨v¾…b}nÒÊ€¶ÝÜ+ X? UpWÞ²”Ž„‡¿ÌÁ5Àƒ»
-Ÿíè}¼¾¥°.`P…äü §›×Ã:ô
-£Cž Gɦ¯7í}‰âd3¶^Ð w7JŒÊ¸
-[•=q0÷¾*tý‹´[ë8ªö6ŸÒ<s˜RdzÊîÀZ¾óÝ%„<n+ :ˆ¾ÐÅ00ÌÏ®¤±ÿ]õ¤Z«z¸QK5v‹§bÏ:’kÃ1e(!„S¯*‡ú8Ó;¨ôP§>¯¹ä)ذpsg›ãt™šá¥*åUë¯ Ž·UÒcׂù©¹8ާ¨½4³23_–÷_ŽŽa$–àÀ(=D8t6öÍr×W€€û2j\µN¬åQwgF1gá«ÀÙ<œÍ‡ÞÐä5€&Õl±éøêmé9–>ëoKæv"|ðʇWû¦âA`‘šî[C÷ÄÝí¡g¨¡
- \ U5$B¨ûÚdg±Íâ(•
-endobj
-884 0 obj <<
-/Type /Page
-/Contents 885 0 R
-/Resources 883 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 861 0 R
->> endobj
-886 0 obj <<
-/D [884 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-883 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-889 0 obj <<
-/Length 2466
-/Filter /FlateDecode
->>
-stream
-xÚÍMsÛ6öî_¡é%ôL„àƒ Áô”¦vâÎ6ÙuÝSÛÙ¡%Hæ,Eº$­v§ÿ½ïá)#q:{ÙñAàðð¾¿,þÄÂhÆU‘.ò"eš ½Xí.øb {ï.„?³ ‡–ÓSßÝ]¼ºÎä¢`E&³ÅÝf‚Ë0nŒXÜ­IÞ¾ó÷»«ÛË¥Ô<ÉØåRg<ùîæÃ÷)èçíÇ×7ï~¾}s™§ÉÝÍǾ½º¾º½úðöêr)Œp_z Ÿ¹p}ó·+Z½»}óãon/»ûáâênäeʯà
-ùýâ—ßøb lÿpÁ™*Œ^àƒ3Qr±»Hµb:U*@ꋟ.þ1"œìº«1ùie˜62Pç1ê‚eJ*'À?¾E^]§jr’/–J³"/´;s¨êú "ÙÚk{¿ßn«f‹Ÿ<i÷ÃãÞoµú­í'ë¯)¿ÓÑéÚö=AÊæH‹¡ÚY¿zð‹ÞvŸ¬¿QùóUy^$»vm_Â2Ï’îR˜ÄnK÷»>½TŸÈ™¬ÐZ:Îè1£’mÝÞ—H­IgÈaËñv‘ ‘¼}(›ÆÖ=íªáÁKoj¨’sÆy®á1|c}lÊ]µŠˆ9ULåõðLW GB½ï-3RÄù¢§½ÑŠˆ&p<@‡Öq½”ø”ä:pO㶃ívUcɦå@«ˆ­ÜÚž¾
-Æs%<wîîÒi9"ÃL®Rô¡ÄwS‘Ü[Ûà
-(Øw]´m^âB¡dÂ6Ê÷ÖåàWe³ö{ΰDVLˆé·n·[»f1jˆ1©Öú]yœ>“þÑ®ª_9— ¸SŠÊRf2ÎM²Œ“C È1ý±Â#„(ÁTšþØŠL…¥‹ä~ïTkœ'Iƒí˺>ð±þÈWp¯¯š•!2ÃR9²ú•„”uß^'Æžž$Ðë @¤3
-¾B¸¥ ýBœNŽrÀŸF`uï!Á—i‘%w1›“ª`JféŒÇo²€„[i‡ªmzODyœ? ÁuM+—ODÈC
- ÿÕ+÷®°ºsw -çtž:5 Ϧ\UµÏ6ÀÀü¨<+lñBÕlÚ'Ô´M}<§ âI;¿£FΨ)Ãå‡j‹ŽKD)L êŒê{œ»;¦Ÿ—º/­?+tB¸©0²â¡oœ“2ˆ1ß §P­œ8=
-¨\ǒ¨¶Í†¿ôtµ9£>´4Sú¡ì»þ×vÍ1½Xn^xš\~aQ{{ôÝÙE„Q;Bõ‹þy5­ö]g›!XÓhET1ESFóK!a¢Ä/…w ¹ÌŸ˜ccDïÿožüÕÂjöu=‘È!&ãÀdŠ!?Å”Ÿ¡íû@Ñqx}­õê[l)9Ïâž7=š@×”¡4ÆÐçF2i¨K¢“èhB’ÿyêUº
-í3A¶àÓ¢£º·n¦:6Cψ<—EðR¯ÄÙk+/ê‘$´VšåÐy>3Ú 6Ú<à|ÀÈçzÅ´6b6~Ó¹s9šRà¸Æp¼e˜¤±‚ü|óýKZùù¡nÚÍv‚ ˜Ñ©L­q§ÑǪ:Í@Ú,5Eþ—Èó-WGx;5ÉþÑ‹¯
-è3ÿ ƒÂÿ…é§ùhKÿóÊNÿFLs¦Œ‘ñÆÒ 3‚Š'
-E«ô9åã¿Ôž’þ' µ[Bendstream
-endobj
-888 0 obj <<
-/Type /Page
-/Contents 889 0 R
-/Resources 887 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 861 0 R
-/Annots [ 891 0 R ]
->> endobj
-891 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [173.6261 554.783 242.2981 564.1926]
-/Subtype /Link
-/A << /S /GoTo /D (the_category_phrase) >>
->> endobj
-890 0 obj <<
-/D [888 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-887 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R /F42 597 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-895 0 obj <<
-/Length 2361
-/Filter /FlateDecode
->>
-stream
-xÚÍZÝoÛ8Ï_aìK æñ[Òõ)ÛMzY\Ò^Ö÷°·»(d›Ž…Ê’×”“õ-ö¿’²%G¶Ók
-i8’¿ù¦Ìþ±ÒD§<Ä©$Š25˜,ÎèàÆÞ±À3l˜†m®ïGg»Ò|’Ts=ÍZ²B“„ FÓ_"M89 4zûþöêúÝ¿ï.Îc®ßßž¹¢ÑÕõ?/ýÓ»»‹››‹»ó!K‹ÞþãâÃèòÎé ãûëÛ<%õ½»¼º¼»¼}{yþÛèdzËÑö,íó2*ð ¿ŸýòLáØ?žQ"ÒD á…–¦|°8“J%…h(ÅÙOgÿÚ
-lº©½ø1J¸
-ëßfժÿÕc,‚3ê
-è"p:”‚:ñ6Ѷ3&IR6똚Y¶.ê㊀Á{®öâ lÕÖ&›¢[JíÐDª×¬ÐDÚM¤gžÖ¬èhO ’I³o
-S¿²~ÀfÏ€ÖcÉ«\yÛrÌf²^åu˜îUÖALÚù×_)åÛÕÆëzo‰¬°¿YLGŸŒY†eשeEû
-[ºß*klæÙCîÌG0ý|žò¨Z¿šzŽÿÁKÝÄ»­Îê/öúó¾é5°Ø|l øØøÓí• ’2*÷ ,/Œgú®=Éß½ésR‹áË“òrVy¶a¯ø¿ÞôÁÔµºúîÕ/Ýs¾^ñû&{„%pßXë
-²Âc3£+j¸=ÔP$’ĉ`ýU(ï‘`ï’q\ùp…
-ãMñqp[»þ–ÁU‚ðXóà* }èŸBoÿ¬¢¡º}?º¾ú¹ôëjRG°ó›úÖ“*—ŒÎN$U.%Ii’ª –'±ûÐÉ}ñösj”ö>_
-N•B@SŸ›áÄÛq%Õ‰Ú [ã>ƒ®Ëvd¦ž_ä³T…¯ØtaRšzâcú·u™ 8Cs65P×/ò²!ÏÃkèúÒ'ªK$iT¹ï@ÔSAÂã<Ç|´ºõý
-G2ëéØâ#Á  ç«€¥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ó ”ÀÕÚúÿ
-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+!<MÉ|gWŸ^uyƒo rAÇ¸×øÎ’ñcY4³ºÂ¾Ø¬sL 0Ü@:Œ
-à˜ÓлòQw#Èñ’è?uei†Y ˆ0ì§Õà*–!¥?.Ï’ëLxç=@!§BWK¤ˆdÕÉæ®ÇåÜ Ê$3ÉÐàç’RrÍÖÜ3‘·YÝÖ·Õç±rϤqºSÎþµSždL¦PZNÔV‚|4”Á{å°Œ¸MÕŠJÆylúÎÒ™Á¶¡ $ÔÏ2ÖNÂØàØò²±òi
-ЛJÃ¥Ëü\ý¿Î—Kx<÷u¦&ËW¾
-*<†0R“…Çá>\ãwGê:¨•öE|íÓ†LXšàÆÍc—Å÷ òëL& 豚Cj\ÝÐHI@1X”öýF¬t7Ø•€êQ
-ÓãÜ¥ºÿu†.2fLš ͼ,šÖ¢wH7«_s¬ûÜ•u~yûñ­OÄÿ$,Œ1èߎ=…}"HœýŠÂùv<üåkH`ûÏëe^TîȽ±—y!ÁTóºõâ£j– ¦;R$†Å®ÕÇè ݳwqÔÞÏ­ë—ÛM¾°ÆÆ [Ä ;WGÌŒ?bß®1'Ùf,h•Êk˜T;9Î e˜þ¸žŒ›Í<¾ÜcÈi(‹ÅCûdñÿýò ¬C Akhï¹µ»³†‹|l„NXSG›ëÅ„&×½G¬ƒŸöÐ#ÖÍ>^×V³3ßaR˜£ Í«ø„(µË'gMe µ†R,Q:ŽÔ´¶ÏÝ>6d
-»†–°]Cm1€s].ê᥂¸Ñºð‡kEÔ«™ÝA(ö½L{Q&õ·óÚ„¼tžCMRÑ<4ŠqžÏfvåe¡ €„µ¡v0…Ât:º¼§…ª¦Ñw aVxÐ^«]\$=˜Lp¢€7®ì`öR@L= ±ôtY´­#µ-`ç®QN=å^Ïn:iá‰î:c1í~ü¶Æ3†õg¼ ‡#>¦ÿd$÷02º+ªyCSζ_.ÿ1§ â”G}'”{N(;Å;Äõ
-¬ÝNü*Ÿa3XH¹Þ½3h4máŒÜÒÄóµ‚rÙ(¸/éã΃Á;Ó´ëSmf¤)ç«j\¸ÂÙ2¯*êQQù#È[p¨êõ2÷Øé2°ºìîè¶Aæ]p$—pÊ„k†ÇÜÛªêlU mUFaykRÆ¡ º°÷¹+dž¤³p
-½ÂùNæ›é¸×‘ì"AŸù£êc–מ|^Œ]ÓCºî¨ŽøU».‹Ð‘رó²ýs•uy5åy#?üpqnä­ÊPö¯œ#yÙ­;³UÙ¡¼p&‰o#]¤ç.taámgïÖγeý™†øÍCeô[ÁeK¼û öXÌ­¿eNœÕ÷äf2D©ØÉ÷)¯ÛCiô^Ÿ5_­l5ßþà×K(‰=œóêaÍãû¯S¹àAì”uæ™ÉøX½¥|¹§‡
-‡ub\¿ ð,UÉ›(зÑÞ¿¤q!Iãß­y¿•6þNTÒÂËSÀ»~Ý”ø‹p›¡®‹åf ÈT~ƒ9õopê\q]E9‰JwôL h4´ë³|Þgœu™€¶‹p/œË=ûåÿ°äOZ-ëú·ÍŠ–ï¬ïTÙCµŸkcyÃ]å­ŸÙ²Ë54;ôW»+ú`7»ŠîÍa°ýó …݃~§ð„®Šg
-o-Ó½2G¦HGXÿ? º€_endstream
-endobj
-900 0 obj <<
-/Type /Page
-/Contents 901 0 R
-/Resources 899 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 907 0 R
-/Annots [ 905 0 R 906 0 R ]
->> endobj
-905 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [519.8432 252.798 539.579 264.8576]
-/Subtype /Link
-/A << /S /GoTo /D (lwresd) >>
->> endobj
-906 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 240.8428 118.7265 252.9024]
-/Subtype /Link
-/A << /S /GoTo /D (lwresd) >>
->> endobj
-902 0 obj <<
-/D [900 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-322 0 obj <<
-/D [900 0 R /XYZ 85.0394 451.0558 null]
->> endobj
-903 0 obj <<
-/D [900 0 R /XYZ 85.0394 423.9067 null]
->> endobj
-326 0 obj <<
-/D [900 0 R /XYZ 85.0394 301.4703 null]
->> endobj
-904 0 obj <<
-/D [900 0 R /XYZ 85.0394 271.3564 null]
->> endobj
-899 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-910 0 obj <<
-/Length 1238
-/Filter /FlateDecode
->>
-stream
-xÚ¥Xßs›8~÷_Ácò Uü†»§4uré\Ó;×}j;„­ ŠDbß]ÿ÷“,aƒC<™LFBì~ÚýV»¬l[HþÙ–À vb+Œ=è#Û·’b‚¬•|w;± h…@Wêý|òî&p¬ÆXó¬ƒAE¶5O¿]З]\¾¿¹»ý:»º ½‹ùÝçûKàøèâæîÏ©žÝή>}ºš];òí‹ë?®þšOgúU`0ÞßÝÐ+±^
-]ˆB/6ª*yR˜°2Ø%p ­5êØåä·HàÄúq(Y–¸¡íõÌ7I(õ,'†QÊB¼‘”{”'dw˜•œyXpQÓrµËŵ–×y͸8$}û4¬¡wख¸€¦ZE?.hzJ'¥5I«M’WX¬jŸA“d-
-R¨£'ËMø-m\EÓÑ;œ¯UT-
-(ðÆ|í›bIêAË
-ZÒç &¼’u‡ŒÚ¨ýÌ€D¨Q*%4;J¯ ›*§ ƒfÊ*Ñt
-Þé½ê,q\±­ˆ=FA~Hecù˜hª/ä? ›¬KÌGŸ´äœ$€”x™Ÿ£3ö ?ú)éV1=u##ŽËdÍêîÛA« \¡T–2Û£˜¯ä
-endobj
-909 0 obj <<
-/Type /Page
-/Contents 910 0 R
-/Resources 908 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 907 0 R
->> endobj
-911 0 obj <<
-/D [909 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-330 0 obj <<
-/D [909 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-912 0 obj <<
-/D [909 0 R /XYZ 56.6929 752.2028 null]
->> endobj
-334 0 obj <<
-/D [909 0 R /XYZ 56.6929 693.9224 null]
->> endobj
-913 0 obj <<
-/D [909 0 R /XYZ 56.6929 663.1642 null]
->> endobj
-338 0 obj <<
-/D [909 0 R /XYZ 56.6929 628.9495 null]
->> endobj
-914 0 obj <<
-/D [909 0 R /XYZ 56.6929 601.0964 null]
->> endobj
-908 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F57 624 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-917 0 obj <<
-/Length 1160
-/Filter /FlateDecode
->>
-stream
-xÚµX[sâ6~çWø1tFª.–/Ó§lJÒìt³-¥OÛF±EPklVìÒvÿ{eËÆ6<8Èçûtî:vùÃNÀ ¢¡ëø¡ Ẩ优w\É€Z4¥ÞLßß{Ä aèÏ™Ì\DA€Iüáæî§Û_&£ñ†n<8ÌC7oŸ~´+¡}ܽº|ø}|;ôÝ›Éãû'»<ÝÆ£§»Ñà€aƒ'à ÀýãÏ#ûßÃøöÝ»Ûñðãäí`4ÙÚÒ´#Zòiðá#rbcöÛ‚4 ˜óÙü@‡!q—QÈ\Jë•dðÛà×-aãm mó£dñ[Èü†1vaH|êø,„%´ôàs£¿æY"†ÀCèæûàq¬DžO\Gói"sm׿þP˜löÃ1Rrðu&c°vÁ*^‚e¦t¾GV¬ôåð®ã°ÙP¼)ÈRPR¬¼\Nírý*#·äFÉÿƒÿÓJ¨ ȳ•ŠDÅSXÔˆ¡ífÅûãß’‹
- õCC }—º%ãwå«ÚA†
-9¿gÂÿnÙòc #!=ÉOŽù ´µPF çûl?\M‹wN½Àh‚!ö‘W)ÅN)žÍhr Ó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
-endobj
-916 0 obj <<
-/Type /Page
-/Contents 917 0 R
-/Resources 915 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 907 0 R
->> endobj
-918 0 obj <<
-/D [916 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-915 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-921 0 obj <<
-/Length 3325
-/Filter /FlateDecode
->>
-stream
-xÚ¥]“ã4ò}~EÞÈDkI–-O ; Ç.· uuçÄJâZDZ³³ÃÿýºÕ’?'Å̃äVKÝjõ§>‹àŸÏTÂ#Ì,51SW³Õî&šm`ì«îqi1ÄúâáæÅëDÌ 3‰HfëÁZšEZóÙCþÓ<a‚ÝÂ
-ÑüË·o^ßõã»—·i<¸ûæv!T4}ÿ;ê}õîåwß½|w»àZñù—_¿üþáî %~/îß¼"ˆ¡æÂ¢ïî^ß½»{óåÝí/ßÜÜ=t{î—G7òÛÍO¿D³¶ýÍMĤÑjöãÆˆÙî&V’©XÊ
-H Å’8N©‡­íꑸfƘ'pp¾˜ë‘Ry¼fÀœ”óÆ¶ õŽ{j7e½ÌJê÷Û‚¶Æ6ž/­ŸÐØœzË'jÑÐu¶…ŸvBp—yd´ìàé8µ¢ÞÊÒÉ(…ló±à9Ë$™gؤóU]¡l7ÇCFÒÅ1„”øH”™ß¯ Øníá–ë¹¥‰È‚Aá&›h¦áÏK6….˜þ‰d?ƒµ‚S&Z‘ಬWï©ûúH6[m F¸Ô‡£¡a<жñJ%L+cNìî³cé•î±(Kê¹ã‚‹yVÎRΓ™ç%9ìjÚÒbˆåa<I:,2Úƒ]µõá锲IA¿µ¾N9 MPžèJ$ƤÑjR¨ùc}x_Tú
-@ÒRžœE2JÆÇI'(c28ƒfïmE ¬¡–öRºRM#­3@ìõ;ÆírÎÝ– ÷BŒ 9¸
-ÜÍÑšN3jÓMZž„é™rÇí&¤ ÑÏ$‘ñ{c»_ÄT[A3
-PŸ SvSB›S>„‰æk©w„ð¸-ÐÇà
-BSÝ•¼zn@éEÂ1ÓtßÝg‡¬Lèã”CüÏp¤ $5*„Ž#DÅ%ßÐVÖæ6ÿY.tÐõ±ZáÁeeÑ> '€½ J!ñ Zϳ &ž°û>'çŸd äé‚IÈ<aÊŸ1‰!Öe“è°‹Ö9s*Ï<yÌt?C¼Ãš >òåܰ²ï1yr5 «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
-?¥ÏX\tÅâ<’ó%ÇÝ~ÑßzMŽ3Åãë”;¤sÒc/œ°3ã!mÊÎd2*|4–I"áê˜j ¼ uE%âà>š“yP gK8.®©}¤4
-zEÕ´‡[=?®(i åµ'&M's°i¦MŸ<ÏTùÊëp•//xi•ˆA‚‡Ê¶öjP{}ßwôht­\4Ì7é°n9=b!>çî Â(nþÌ#ž`P{êé'¼E·âb¸äùûœä°LlLO9h#›X̡ҕ|x)7e$°_,ž)d†X—ͤÃrÑÚîð%¡hÚbÕ\2™0‰‰ÀU.:¬ 6F&[†â5óán4°üB›Á¶ ÃÁf@>pÒàÿEëœ#ôasty¨ñA¿\·ß°_§öÄ*jíÇ¢ÅɈ“êjR]z'‚rLž&ãOŸ#‰ï?CufþT¦ò> 1^,ì’Â(ÅâD>“È ±®(LÀr…G‘_P›Z^'&H®nÀÿ$&“~˜¾x!¿šö÷2½_\ÖôN5ítÄÝý´þ:Èßj¬lã÷¯Âí¦½© ›} ¢O¦§÷öIÔ“ë9è²êüÜcð(Rwï~/B‰ânàO.=>d‡‡cõ‚´Žàù‚
-“ü‹CS¼sqI1vï‹R|ØÁæ{Ôì A‘”’4k8êŸI¡· ÐÄÖV~ápÎSÕɪ'zê
-ÕæUï9@ºì<Rx³¿i±‚S:½J¿C:g`\ j–@ q@.4Ї.¾jÿfÙ†áÎ…Fqì\(¾nî÷`øþ!sPÝŒšZŸ’â“çIJ:@Ê}Ûø·K* 'rR™²(>½¤œT&ÄÄTÀŒc¦”¸ÅDqÿCð‹³Ç®Üˆpi6|¯Nä…'üóq ¿ÄOn?MC
-u?;úÛ¿tëˆ Z‹iÕ©f±†E<S(ˆ8:·Eÿ“¸sÖÿOÍÇendstream
-endobj
-920 0 obj <<
-/Type /Page
-/Contents 921 0 R
-/Resources 919 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 907 0 R
->> endobj
-922 0 obj <<
-/D [920 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-342 0 obj <<
-/D [920 0 R /XYZ 56.6929 659.6382 null]
->> endobj
-923 0 obj <<
-/D [920 0 R /XYZ 56.6929 628.8211 null]
->> endobj
-919 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-926 0 obj <<
-/Length 3376
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZÝsÛ6÷_¡é“<1¿
-'vE|\¸¡ÁÃfFÇûý¢ÿÁ)û§ó"ÿO:mòª´
-×là-œÏ[Ò["hY¤œ
-¨õ×´h3>CÔ§óo`ôeªûÊÆ›ueí³†hèÐ/÷K‹0»/k¥Š×#T´³aHþêyÁíþ}ÃÃÐüé:öæu~~¿#«ˆ]Ÿ>?Ý}þ„­}#wçSº£ñö#ˆdþMÙ†¥óÔP:“°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ôù
-ÏlH˜¡¤hô¡¤ä^wºÙV—Ls04ÑùJ£P›ÙITÎ #[¬!7”q)'áêW| Q퉜’BSØÀzSqYz½±þ*ùhb*EV{_A žä<Q_'’«Õ+y5càƒgÑ{]O]9®Ñÿ~tàì]NŽ>x3rµÝŠ%I ö×fVjór"ásR…^7ÔÅsó/š÷Ñb.‰å£†r¸ <fÀçzj”PYúER¦[’©d­&é²h÷{M龤tùx´-oJ}ÉÎÒ[â„HnÉëRß0ç–DÙjm÷ý¥#Ð.&ÊL9£"MÊ©º SO0Ω} 8µ‡î³ßà:êæ­ÏÀVš€¤Îwy‘ŠWž¾©ÆKÂ#öû§órÊ*]›taͽ¶ ˜‹ˆG4E£2;¸‚lŽ[ó}ÄÏY î)Ï ÁF^¶à}ªó¼£ê)Õá¸Ò h·‡S3® ¤ <y™Žj‚='öF|<¡ÑX£JÉh¾Õù¼eºÍÙ•¡-á8rK­·Ü‘ð—\X I¶Q›¶ß…w•ÆðŒ|`a•Q̹
-“YÒnwÊííÕ‹*g§;€"Tá1ce5ÁºÈà”wk:¡Ý™N%ú¦“k*¸~4Ô
-TPsã€B *ÉÅ>ßC@w^öÏÌZ Ñdè\ÙA#*IÉ@ðÍH<Š‘°sQÐ&
-`<G=P¹x|oPJýýt…5k,LXðw"ãï ãçï¤ý¾õ#Š#Ñ…ßP0V’R1
-`ˆ?¡;¨¿©÷ì©'üãMvò%§) ø‘­öb?M€G½ÑÑòà½kEÀ‚æt»†w©xM¼¦§JɸÕö¨2ºÌ‚ŽŠ™ÍôáaæGN¤ðG[}ãÅg³ðÃp^äåtÊë®q¡s?Ó0qT™$­Ýn¶ Øï1íÇçà'"ô 8ŠM^& Å‚@Ó»5Æ/èÖZƒ»z8{™ C&UÇɲœ¯üøŽ£9÷›.?tð‡XÀr;ÇòÿÞëøc¸@buç̯| KKË
-?c놲þ_¬–ÙÒendstream
-endobj
-925 0 obj <<
-/Type /Page
-/Contents 926 0 R
-/Resources 924 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 907 0 R
-/Annots [ 928 0 R ]
->> endobj
-928 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [250.9056 758.4766 324.559 767.8862]
-/Subtype /Link
-/A << /S /GoTo /D (statsfile) >>
->> endobj
-927 0 obj <<
-/D [925 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-346 0 obj <<
-/D [925 0 R /XYZ 85.0394 227.5287 null]
->> endobj
-736 0 obj <<
-/D [925 0 R /XYZ 85.0394 201.8676 null]
->> endobj
-924 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R /F58 627 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-932 0 obj <<
-/Length 3418
-/Filter /FlateDecode
->>
-stream
-xÚÍ]sã¶ñÝ¿Bo•gŽñE‚—Äwu¦¹4Ž34É-Q‰TEÊ>ç×w» H‰’œô:½ñx¸„–Àb¿°“þäÄ&"ÉT6I3#l,íd¶¾Š'ðÛû+É8Q@ŠúX_Þ_}ñ.Q“Ld‰J&÷‹Þ\NÄÎÉÉýüçi"”¸†âéWß}xwûþÇ»·×©™Þß~÷á:R6ž¾»ýÛ AïïÞ~ûíÛ»ëH:+§_ýõíßïoîè§„çøòöÃ×4’ÑãĤw7ïnîn>|usýëý7W7÷Ý^úû•±Æüûêç_ãɶýÍU,tæìä^b!³LMÖWÆjaÖaduõÃÕ÷Ý„½_ý§£ü“±PxuÌ@£{ tRØ,³“Ôf"ÑJ{‹k馋bÖ6ב–fšÏfõÇæeõHCmMÏßëªà‘— Cy5GÀNgu5+ªv›·ÏÔ.‹ÃïÖyYµE•* 4uÀÍ[‚J~æ«Ë|³)*ž³¬hµ9Û¤™µÊï¥YÖÛ%¤¦¸Ìö)_½¡×Ú/ˆPñTl_ðc`N_»¤4Â(•œ8ղȷíC‘·Q˜‰¿0T gMŸxNàËzS,v«Õ ½Îw[ÏI„=Kˆ f°O{J¦·L{¾B®(PÒf·ÙxYM\Å-GÔ_¥©>Øz½.H7ë=y©xZÕÛ5ïáßyÝx( ¿Í½*üÇjæ)Ч÷aŽy±Èw«–^ʆxa]*Ñ"Mó¢ªGØè%AÛQ©©Ö ¼2™à¸ðˆŒ@oËx‚y™¯v›‘u´΀žZ½iË´Fe62ɲÀbz(èÙlŠY‰{/æ4PV„ÚŽ“b0‰‹<•Åó%Ê‚p¶§ £›rÚiÆñ™ì:‰ƒr6-ÙŒ­yCr
-´>/ËÙ’ÈŸå ï
-Ÿ5h>
-8bÆ»v™¡mË9šï@WõC§ÿ}ÒS˜!5é+ä¡7”K_Æ(«Céß‚
-›˜)@€Ô!Ð=ÿÌé±Î°ÎC$ø®
-еœò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ÄÜ
-ƪó-²aÄN H’‹ÞBÛÔpcÑÉùL&”íÌ3øÛ V1΋sÅ©$œO
-Ð(´FÃ\–bÍyô…ž»† :dš
-•˜Ë–‘Κ\°ÉâÄ$„p× aw¯A«òÇʱÕ!¨v]üF«óé¨]"ÒL'C¾mò¦¿3fkBp+(4qG—‘{º`8ÐE¿PmâÀÏÿHþÛì9$¤N‰ xl¯ð°¶;„·ð)~v¼‘£«þŽdvL#ŽÒ>" ù°™Á7þ¬À1¿k?#ñèäÇaâ ™Bãæ¦Öuáß«Ì-ê>lºgxoøÜ NyÀ\k…sYˆKÏ(‰Zët¨$8í¿v Ÿ2ó²ÉV!ë‡îGœÁÁ![Åa:šAòh“dbAúJËWå£:…€TÚl˜þ¹¯=ß{’ú.†¹ _ §ŠÂž"«à|K9žìfÅ“³„KQ)ªçhWÎØólÖ±Ô¤EªÑ ,™êôkïÏúB1©áLÿ'` 2ßÈÔüO¸ GV=&«1&«XdqšœÉýŒ2hþA q³rvú‚ZïbH€a†s"žj”y{²>cÞÅ2pç™;˜FÏš—¢á^fDºä:öì9ÆŸrªGħe•ü„¬2
-M ÐÙº¾‰aLÅœâÕmWLÙÇ#û8§Ÿçý—Cß®Qp¶Ø¡ 7}±(ÁÛ׋"W+E*e2ñRK>Ñø ¤¨u¬´¡)Óaùü?ÿ­ˆJÌ,Ž4 |tJëó‹wX#«ëƒÆ‚‹M2\þ“vz¸ãäÌÔaŠ‘a'ij~ë*×ðkQaZ0§šr½[å-ÉÊY.˜
-ùºªŠïÅÇÒ÷«œï‡5¬(Ÿ¸Ÿ¡§?ܾ¿¿¹ûö ½ñ&éå þºæêvˆä5Ò •:5Ôô¼zác“ ­‡}ŒmÙÍ«:¨ÃÒ>Ceg®gEr褡öꨯ뾎ª˜F« >¹uFÅ–/Äå°‹Õ<š­Jì\)–Ò"ÑàAÏÐaP0Ø,L‰„@u@·ÚÒ¤sÌ?ç<X^ËiŠ©õ¥e_oV¾ÝêËÚ8À_’=#„‡·‰¹kàQœUݹ Z*‰¾Í°èÜôþ:SSêQEŽˆ¯jëûâ§|^p)uƒÞÁéh†“¦‹ÑF$s _‰‡/M/£Ñ/nà3±¢®:öü$·Ïu(ünr¼0´z¡Œš†Á
-« Ê›ïÚeT}œ×x‰a„\0d)âì é1N¶Š…QÚ¼¢é s»˜)»C)9Æ,ð}¯NÃŒ±¡^\ÂÙVäó“)!Ï\|Áé÷±N[d‡åå^7m„w ʦ-gljNEgÙy:¬
-† – îmH‚~¬ìŒ> ¶2„Á
-RÜ‘î„Mý.îŸ}\ÖuÉN›^é´å$oxeU®óU´ådãØÑ¢q$-Ÿ[¿C:&`x´€˜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…¬
-¹&ˆÂﮃģýÁcwÃäÄ8¹“ä‚E‰’v¨þ(ƒù·,ß"%Ró¡:+€íNV ]¬êí‚# {ªÑÔOßPãC0AÊ’¼\ñÖš¬‰›WÓ3­^úË5ôÒm~´)WßH°¡¦eS¯6btxšGFiå5‘¼Näí½aŒÀÕóã*Ÿ€Ë3A›óo۲Ȋvf1e"+˜ñ€°ag¾Wкy a” ì®+´õØr.Ëô؃aÕ
-ˆ=TrféjfíêIÅ’?bÖ´eñÉ@¢D
-{PdçÜ\|˜м90øþeŸ»Ã…&i/t4mCPÞY^u~°"xçT°|Ny.ÊÒ¯Ô‚¸¡ïÂnŠéDü~ øÉs½ûì<&dóAý—}A Ü #ÿ$À«¦Uóì(`Þ×aƒ¶Æ9GÓ(…uƒm'·0tg¦<Ó‚GÇžn§Ð^×Np™³Ž~BI¨Óõ |®\ÆÓ§Ê“
-Îm,—KrKãØßóQXO­×8xOûÝ`AÒ`³³GtX.ÔÁ1ÂÒKÑ̹ˆÄDR›ÿA´"ŠhnêÖ/Ò>¥n|jÛyg9ª£ô(v½S
-|¸øâ˼JIP½¶Ûì ®ãõõF,ÞÕ°¥EWóªÚí˪ÁñÂ-
-bAJAå©ç´Œ]¾\
-^^ŠÍ¶t¡9ÙyKõ>xúZ*´’Éá+pرŒå¢ÇÞ?w`ÒbEÉÅêPôþsâaW„ƒÄ€çæ„q„å9
-A6‚àŸ)¾(4`ɸ²%LWäMÐ7¡`;"ƒ\Ç5añúHËÑ­‹óàf™fXúpìÖñÑ‚h xƒ .»jÑl\tN¼”ŒTÒù0Œ~µ U"œç…
-V\ï7[êFm|«¦1’Gè K êìê‹ÐOFÇjJ‚Ð,Þç1håñÍda4Ǻo±djÇ]¨=œ¢Y¢ÎÝ.„`¡>£ê#œƒ›º‰àl#n¦·ÎçÙ>9S‹€ÎP1Æ5œuF,
-ÕæŒ‘íA0²ªs~ßÀê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
-Ã
-Õ_»'¶J@t¤õ(V¯ò粨º/#û¥ *j~Z•¯_¾ ì¼È\M¯x¬jûYêHͿƺº÷Ÿþ>ùðñ¶‚´ÌZqÜ}X‘˜@òGM"V îW[afHÿ/¢Lendstream
-endobj
-938 0 obj <<
-/Type /Page
-/Contents 939 0 R
-/Resources 937 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 947 0 R
-/Annots [ 941 0 R 942 0 R 943 0 R 944 0 R 945 0 R 946 0 R ]
->> endobj
-936 0 obj <<
-/Type /XObject
-/Subtype /Form
-/FormType 1
-/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/note.pdf)
-/PTEX.PageNumber 1
-/PTEX.InfoDict 948 0 R
-/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
-/BBox [0.00000000 0.00000000 27.00000000 27.00000000]
-/Resources <<
-/ProcSet [ /PDF ]
-/ExtGState <<
-/R4 949 0 R
->>>>
-/Length 950 0 R
-/Filter /FlateDecode
->>
-stream
-xœeU9²,GôûeË@@Q ‡!é¡%bd(dèúʤ—÷ÿ(žÑ¯
-’$¡T¬)ÿ®ïë¯ãïãÇ_¢ýþÏaíÏc‹®½Ú¿G—=ûÌöÓ1ÄF¬lÖ]töö×ãqu‰Ý¦‹÷5š”<8Ç—ý:\;âúãñ‰ü<q¸Í;.\ži2c¶û~ð¶e¸í×qc¸=7Ä+Àg ¯ãã×ctéa³ÙL1ca·cu™šm QOƒ½¥ì-¡{wñ¨¼&kñÄÞ
-¨9xcH
-¤Ï’ÃigÙ¥—ÇáC6uéíÛ&”\Ê GTœ„Méêö–KòlÜ’Fyu|?é%åiÈ¥K”êNÊq{vˆ*êèJE¢]8hÍò¤p0R±ˆ$Á(+Á nÖN¬
-qª„Ñ«ò^ÿï>‹«>÷— .13×…Óƒ!¶3¢SËAÕ”ih¥Å¨Š^…(€<Îm䦽ªšÛÆlLÊâ³ò7Ù
-г2"ïE9~ 
-n*Œ1½÷¨¾x¥Æˆpîâ‹&Xîܧ³±è\íD¤ßä0}#XŒûž˜‹¸À>#^V°¡|2Îi‰9ÊÎr)`˜¢Xh¡Ò& „hb—H°Œe"Ãê
-þrÓGçX5¾ûû8‡´ÕªOª«t–Ô³$Ây°‰—BÒ›ÀÄ5©/¨vp÷o`kA“ôr ±ñœÓ4N.4Žæ
-endobj
-948 0 obj
-<<
-/Producer (AFPL Ghostscript 6.50)
->>
-endobj
-949 0 obj
-<<
-/Type /ExtGState
-/Name /R4
-/TR /Identity
-/OPM 1
-/SM 0.02
-/SA true
->>
-endobj
-950 0 obj
-1049
-endobj
-941 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [182.6146 670.4177 231.8861 682.4773]
-/Subtype /Link
-/A << /S /GoTo /D (notify) >>
->> endobj
-942 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [108.9497 246.9384 182.6031 256.1538]
-/Subtype /Link
-/A << /S /GoTo /D (statsfile) >>
->> endobj
-943 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [293.8042 201.5839 355.0043 213.6435]
-/Subtype /Link
-/A << /S /GoTo /D (server_statement_definition_and_usage) >>
->> endobj
-944 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [395.8905 201.5839 444.6373 213.6435]
-/Subtype /Link
-/A << /S /GoTo /D (incremental_zone_transfers) >>
->> endobj
-945 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [309.3157 170.8346 370.5157 182.8942]
-/Subtype /Link
-/A << /S /GoTo /D (server_statement_definition_and_usage) >>
->> endobj
-946 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [305.9683 140.0853 367.1684 152.1449]
-/Subtype /Link
-/A << /S /GoTo /D (server_statement_definition_and_usage) >>
->> endobj
-940 0 obj <<
-/D [938 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-937 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F84 848 0 R /F56 618 0 R /F14 608 0 R >>
-/XObject << /Im2 936 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-954 0 obj <<
-/Length 3752
-/Filter /FlateDecode
->>
-stream
-xÚ¥Ërã6òî¯ð-rUÄ
-t:eßX–:Êév˜HcÁÀ?›Ú
-›ú·0Ô½ßÇËØBãt(±ðà™¾?ËÈŽ4g… ÆëA Ï
-†‡ºªˆÂ)Äo¶è[â‚d_
-.Å$Éâ²j”NpÅsS®Y4w… J$[b4ô7pÜY“»ËôT¸3å„ FD^Öî-‘À~Ï_gjq¸ÙÛƒ \²ã/û¦mKÛo{[·2DWuB†öVzæœæòEµMõ,úö²¥±ÕôÕZ´ë¥l­W=úîYžK¾+€”õXí'þ”û¢ì³æú¥
-‚8\±Û“ÀëcƒÐ Í"ŠYÄfÑ>µÜÚðÔŒÜ>ý‡¿"×ÄÙ¸}¶MÛ‰]OÇFÛ˜ ÍòT¬ö¦i¡(XºŸZù üvŽžñ…l[Ü…xûžÒ‚„÷O À"€
-q39€p":”ô”;ó‡ƒÅÂá^DUÄò ß#ù™Tø¾ØªB>@‚⇠§ºy©fŸÉâ<EÿˆfB‘=}•e¼†NÝtÜ(ýKÐ"ìîlסe¢C»ƒ™Š`t¢‡bI«LâàT&óÁJÝ̉Bè²FY—-:–7S«Q&ÂÅ6¸©§×2Ì›7¤°&NбqÕ¬8010 F4!/ClÈ ˜×\,#¦fWJ±`#µÜqîzÖô¸hÛ˜Q4!4HFgkìÝØè[?Žßi¨}²äÃãøIô¢1{Q„òD3 <ü,³x.íË(Âþ²ëìnßáuÌF]'¶`kw~èT(T©1ïK… ²TE^‡Pàeõ©l¸·«ró*ò:³ 49=ØUh9àƒEf7…Ì)…‹Ÿ*. ¯
-b6nÉ×0/e#”uãUù Š”!óÒ£pxPŸXì6ªæQ â‹Cͱtv`ÿŠG;+Lwïq#Ê‚L%.#˜O7!ÒÕo܆J•xûX¬ š¬86Öc•œBƒYi‰­G#“Ý:AªÝr¬˜‘(&2ë&'Iäé‘&²ÂšY×<õ{Ô¡Â4”„²¼`‹#VDLÎi
-Ê\°E܇ï(øbÀ”âhJ±€ÈpœU£tåÐ~תš·¬êÒÏŸÜÞ–¢Á8ƒCº!GÇ9(f“S|H;‹5†‰’È#óe
-—€´û†ÝJ&™Wîòx€øbÏì¶Œp{}óõîúCÀp¶|4që³Lô0ÎÅ3Έ «Þ¬Á=ìÄδ,PØœð~È =ïÉ, žlìÿèsKÁVs82y>Ñì‡b´Cœ”ž¥¾kÀc›ð/jÀ#¤·KÀ‰‹nµ]îŠýÞ®—˜Ò
-zà6+¶FÁ,]ví,ZQ| ÐÂeŸÏy{âJ_"ê–G
-`â ?P"Î!Å®Ž#ãÅ^&X»ƒŸæ­v`L)zƒq9 8¥Æ<é{6ÏBÃXu@‡`ÏÅóµlËÁ·žIç ]·…”ªoyHÈ‘z=BVEµê«¢sp†ò›ô™ùbHŽŠWT©ÓXÔtEÖê39;ÀS‰ü#¿YI .r5¸(&6~×2ð¿ £\~‚Ž»l‹Ibg¤‡"|€¬­,±*dƒYŸ.gWv£€l.|×´ü”k‹ìƒ"ÑòÄ¢ç\¡ýH$¦°±HÌf?bTˆ²è^±wºª4=´Vº dŒéš[þ¡"€ô®_!‰)W<Bo>èŒûB…[‹íVX
-"þ,Bp¤Ž—;ÞïÙÞ¶IÒæ1ýnC¥'óLµuÉŽ·»}s(¥+¡r­ÈþqÉÅk<eÛ¸'6Q*!ñ¥Jyè„×®Õ½J¨(‚\#ù‹¤iŒõv(á±((ë«®\ŠäG* ÃŽÞßÝcÍl?‰4 Ú¤Óý% †;óIp¢åÍX‰œBCÄ¡õÚôŒ³•WgÅgØW®Ggi'O¨'>nö"2<nÅ· ò9³ 6òb…ÅìHG„Ók•×Þ]±Ú‚˜Sv&˜Xâ$lbAh=}[vÕ[hpÍ:ÓŽÃ2UjJ÷2\÷»~yÖæ]Ô¤3)!âÂ\Ì$´bÖËÇŽD”åþàè”b[ÐC¼
-Ù½“ŒóOa|t&'ÎðI6ËÞ}©båMåÈÀ eÞ×ÒÛªáè>kƒ•dŠ'ªœ¥*wotºùT1â ‹žì~]K} üÒ‡Ïww×Wî·"{°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<bÙ2­¦cJx¢®ƒKbab…RR"‹"í–ü.¥&¾ä¼cf݈áà²pÉ”ä|UtÅn[Ö~‹§·Ñ/»k•΋¶¨— iÖ#”ÁÆË¼+6 МJ,…µ¦/•²h'„bŒH"£OœX«g¢bTûŽ÷°.è°ÇBŠËçbù}Þž¨1\XœfïXÔjlS'rDþñoÇØlÞ¼teWjøÆ¶oñ®Ò5áêvå²ã¼œZ>ç»|Ù¡ ¼-®ÕœqòzE8í[ÝåïÖ­+v]^2åU³¥1LPˆ¡šõ2‰¶v¨–Û¼%ª&v*Z¹Uðd?6<ñùî|‚—¦n=–EùêŽ µ5[ú¢# .ºC³ûî¼q
-²cðªXçûª£×Üi1°\6n§•ÓY·WãN"ý(^ìÛ|ƒžfóœ¸ÉˆÕñü+lpªÞ‰V[¯Ý,€Iå6ÊXFûOS#cH„ì uü(Û Ri*²$ó¤ÖyYMR‘°™J‚ëÉÖ5St¢„ÚVùk1±!øf¥eôäüïê)BFh«'8‡}SРö@’EŸ¨!ÀƒÐÊ7ÔôJGÝx.Öúø]Fr‚c¥µˆ¢4cnv¬¦S¾Ü^ï¶`;5"wÙó)±8‚‹ÊQnêf7y™0&Kúr›&t¤Y€Eš(bg‚Ä-T:ß;3%¯4\›¼¢ásÓvlßøù‘0·¨]@~€gÙ$x<9É·>ʦî¿~¢Ai^Y3b˜Jµâ)ænÛ¬Jläëõ1ŠÖÃ@)И iÊ¡(Fn}$SN‰ ‘8y©œËЊ­–^ÏÐj—YÈàtM ›ô}ssC:1Ìüò/°‚²jAÃuÏo;F¯Z&x™ öËîò=÷Ayg-“¹óßÒ»M
-Áßâ)ÐíÝ#úœ)C
-ÞÓÚ-ê…SA<Z–UÙ½Æ2¯ üÄK8HÇZ²äðÚ1FNÓm¼ah[vÅâP®
-š]æKÏDÃræ©8ðŠb‡÷2u"²Ú/™Q0†]¾F ºšåÔE4¯.‡±pëeý½¥¡ãÚdóâ/ð5:O„ҭ∩bBâmÂJƒõÖ£'^À-»ÆãT͆>K¦o„Ç$˜§Â8ZñrW>àà™ùø\«’Í
-ñ ¶BNT´-:e+Àmç,:#øè§}G‡²}î/IœiÐ qœŒJ—ïÔû#¤X¿ò·k¥Æ÷ÈjV¿ž&V³\îw¼¢©«7Ú´©§¼@Ö×+zÈmbèw‘‡çrù<ŠÈ$ÈaIÄÅÜÂöÜ•]ÞApcPÍ Åª)ÆèNØÃí9U¡í٨ˮõ•(ðÙâÆÆ‰€„ûrmÓC:_Úx$—*’ŸçJD‰Ê.R H§di'ø‰’˜].iÀc…’&Só
-qDêBƒ^\@ 1–«Xx,©Øü”ÉüŒœŽ0/«™îšòJî°‘=›¡ª÷ˆ‡ôÊ'Tñ°À‡0­#Šû8à¬^S"䦚åµÙsfBÐÆãÓÏ å¶ ß„qäm‰Y6œ*j$5í ›ªyrÍžðGþ¸åUÍd½…[ÅÆeC»rµr¶[Šh
-Rñ-ÿvÿòâx$ÖEéZ°}µC}Hì-d”c½L£-ðVÖç³am•ˆµz'îc˜Ë¥cáíñê‘ÒX›dÑeփؙ@ÞËtÈÅ všD±dpäk&~Ä} £pãIêtX’¼ä
-ÁÂuµ"í†3œU$^Ä„G9Gâ‰FN›(I}&œ…º`Üy¤0˜KÉ ê8%‘°Rû><—@’DZ%i_WxõÔ0_ùJ:Š€¬š_•\”áÏžx\‘ËhO…k\•-ÞÒꌑ/›í6”ÍÉ»í…ØLynfø*æ[±ááUÎvªí®D’Õk»O‡ƒŸO!vOõÀ,‡ƒ›ž >5u·kª÷›aa×k`Ú||
-ÿÎàêk‚üðÙ,&NGô‡ V¡á¦µ‹ =>ÜñL•ƒðËGpk!” ‰fl!†{­d3ÀÅ·Iš…”§Þx†¨~r´ È€E¤õèýÚE›ÔwAa@[âˆ^vÛ)'“¹×Mÿ„4ºÓ÷&£Lž‹ßhwnÃè‰éõšpYó6ñ^i´ÖƽgÚ©> Ä( AÄÏ
-rYp dÇɘuðkqQ¿6)}^DñFƒÞbÂG~èÙÛ Qh~¿5°,sÇW‰™‰õ0‚Ž:L—^}…þ¼¦9F ü˜4ßí±ÀœzÍæ@<ÿÐútÚýñØŠ8÷ggñoÅ&Ü
-™Šg
-j£³áà”õÿÃA'endstream
-endobj
-957 0 obj <<
-/Type /Page
-/Contents 958 0 R
-/Resources 956 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 947 0 R
-/Annots [ 961 0 R 964 0 R ]
->> endobj
-961 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [367.5469 342.5455 428.747 354.4457]
-/Subtype /Link
-/A << /S /GoTo /D (zone_statement_grammar) >>
->> endobj
-964 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [483.4431 140.0267 539.579 152.0863]
-/Subtype /Link
-/A << /S /GoTo /D (address_match_lists) >>
->> endobj
-959 0 obj <<
-/D [957 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-350 0 obj <<
-/D [957 0 R /XYZ 85.0394 576.6195 null]
->> endobj
-960 0 obj <<
-/D [957 0 R /XYZ 85.0394 549.9907 null]
->> endobj
-354 0 obj <<
-/D [957 0 R /XYZ 85.0394 326.4739 null]
->> endobj
-962 0 obj <<
-/D [957 0 R /XYZ 85.0394 302.824 null]
->> endobj
-358 0 obj <<
-/D [957 0 R /XYZ 85.0394 185.8791 null]
->> endobj
-963 0 obj <<
-/D [957 0 R /XYZ 85.0394 162.3886 null]
->> endobj
-956 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-968 0 obj <<
-/Length 3222
-/Filter /FlateDecode
->>
-stream
-xÚµ]“Û¶ñý~…úTÝŒ…_8yrœsr™ÚqÎ×éC’J¢,Ž%R©»¨þ÷.° ˆ¤(3IÏãáX.‹ý†ø$|¢S–f"›˜L1p=Ylo’É'˜ûî†Î, ͺXß<Þ|õ6“Œe©H'«-Ëkùäqùó4e‚Ý…dúæÇ÷oï¿ûçÃë[£¦÷?¾¿ LßÞÿã¡ï^¿{÷úávÆ­æÓ7ß¿þðx÷€S)Ñøæþý·8’áãч»·wwïßÜÝþúøÃÍÝcÜKw¿<‘n#¿Ýüük2Y¶¸I˜Ì¬ž<ÃKÂx–‰ÉöFiÉ´’2Œln>Þü vfý§còSÚ2-T
-’”ÌÊÌŒK™3Ã9 •°4å6JYJ9`9)ç›Mý<ûíPìÃs.X"U烱Å#ÖÈê²³:ç†%<•ýå?îŠEùK’ˆ¢ù[;}^—‹µ³éºnZÍ÷·ÜN ÷,Kœikl>ã@íQ—e•ÃŽüÔ·ï?âì²i˺j˜Ûê@:"ÓL¤VÀ®Fä2Ø ‹à)'Üm~$67Mí°'3i-ËîåÃ2­…Gœ»€º5q×K(+|¶ëb„5+€HWûw]#, Å$qš6o‹mQµ¯cI¤¤ à"oˆ›²uO9­ŸŠý¾\ú“¸È · 3VÆ…ê(~q]f _CY˜d‰¶2 }Àý
-­²ª[:’{…#ŽM,‹U~Ø^ÙÐlOÏ‚Ž¿² ù•×–z±ðªÇÎ\
-9C 6ÿ¹¥‰ Uñ5‚ÿ‹Í’A¾y…äƒLCEî–cíÒ >QB8»ÂTb†²&c– ݷΰ}´ge¦Ï¥wÊ¢`dWìÒ¶X’ {¼ÍÄ´Fœ¢Êç‹KÜ,P~…ÈÞ«­ŽcrÊ8ãZôs—Qå†} îÀc’hóê$ûõ‹¢u™5¤Û‘-t2™>囃÷E
-]“h?…[ˆAÅQ9@±10ÀpØ›ƒûÚNcEÞ‚Ësu…Ï ¡×ò#!Æ8اâ~ÙßwuS„AÜî y4ájÔd—º%}2Y5.Bÿ #÷(a\.IØ”OÎ!«^Ò\81íô¦êW7/mÛ|ñ¹ùš²Û¢F içv&²: .²àÜþÓ‡N(
-è³.þy$:£êQ±pÉ<²b˜²¢ ‚ÓiÚçå¼d X/° Dégšõy@݇õ·uWÞË¢ÍËÍåŒ\e†©Ä¼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•}=Ò<Jþ©¸bJ0mø sëŠ!¬“!xÅYûóÊü‰åúúúk„ž(HÓ!½<Y r:Rž¬D§2uã1Ov/NãÜ“N¨ð…ðD¡ý­“]øÉ5au«Òó‰Ôš¥®ÕÙMÆ(MÈ ‡L!ïïkWG¨g~Ú%\Y¯Ï$³ p
-\žöÍuñe‰Qç-'´ËÿCs©£@Œ/i,I ç-_j,u±.[oÄòÇ dëzs–^ð„3 AçúÒkdížá&)S™,Þ3\)„Oáà±)} zE§t*àR"願ï Aå–ƒ°íáˆ@Þµ#øÔ<—N¯Ã­I>KXܺâ Þ<],œ³Yªú¶‹ÍNÎù””ê§ËÝE—?gycÀ¥Â±«sÂ>
-Ë)ÚšÖ{¼¤¡ç%‘sP& 5QuÙèÝýF¨ñÎÍ” …€oœ:¤LÛLÄûï· .PaÝ»Bi•C<²ÄW(íUªC‚ã çSâG¾PÁ »zï!
-‡°_|Ì)(ÿ¸óG(4§ØE5««‘Ï"nOÐç†Hm¿€´’,µÁÙµùg,Â9ÈŸ¸F¾ÁRÖIÔU|𣔠ÕÆô*t¨ðôébT×Õ5Ã:ê@m!TË$aÆ@ýd‚eÖÚñë±Y¤8ë’ôN§ÇŸàœÜlDÃXÙBT2©…«9ä_Èd ø“$
-N½Ç¤÷€/›à ´mÄRt2(»ƒP1è +<bu0p
-ÁD:ì]õŒ-„±à`æÇA<+uQÂt‹‚jާeÃì÷b´=!k9tŠÁ‚»^ŽöÞó+w›QóL@Ù—˜`ÖÄ|+& A@Ý’”¤EÛ~êÖâ÷| \¼1¤™•L;S&¾Õ€ߘ¢N¤Ì0ÛkÆ «’Á—(=Av§zÔþÆÁ7K¦ˆ¼}ÅÓk¾Äé3Ë„F=¥c€„76,Mh'Á`•oi(:bÅâR†S…ª&4¸èŠÑ¾Ÿ3}%sŸ œ‚˜,Ôxc´qÏþsE·‘Õšuÿ²u(Öm¾X—UZ?¤µi&È.F~I³IÚ5Uƒͱ;hP¿Lýa= \É_ãÁôŒ*8n³ëÜÃLLbOŽƒÅ€1îgÝ>ŽçúKRu¶ÇÙS:Ö‘…\–KÕ« ¨¾ òà€í6E©v¨„VG\‡z¤ëëdФˆ#!ÃP´axBes˧xûÙ¡eéŠj÷wd £+lIOfôטA½WV‹zKúÞutãïêÐÏEŒûOé¨.ýËõ0ÎýÌÀ1~Qï{@Ù‹71ƒT(±Óœ&bÔ[Ù¨|ã.d
-þ Rȉ͘\þé Î:ÏC073`÷qÝ‹i‚à ªã¿ŠÃHð:‡€ÂD³‡—r §•†´=j÷\ú9$ÀSµÿ²ÑAlzFçÜ OÉœ^
-endobj
-967 0 obj <<
-/Type /Page
-/Contents 968 0 R
-/Resources 966 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 947 0 R
-/Annots [ 970 0 R ]
->> endobj
-970 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [369.8158 524.5277 418.5625 536.5873]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update_security) >>
->> endobj
-969 0 obj <<
-/D [967 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-362 0 obj <<
-/D [967 0 R /XYZ 56.6929 355.3526 null]
->> endobj
-971 0 obj <<
-/D [967 0 R /XYZ 56.6929 331.517 null]
->> endobj
-966 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-975 0 obj <<
-/Length 2574
-/Filter /FlateDecode
->>
-stream
-xÚ­YOwÛ8¿çSxO#ï«Xþ—Øž2mÚͼmÚI=‡Ù™9(¶ëU–\ËN&³o¿û%K¶’v·}9ˆ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
-¶[µ| i700…HSÏ?åǦÈ3ÜG=ÕˆÐ;Ù3¢Ð¿·™ÿ.J˜ :Z ¿÷«4’é‚`°È›‚VÁä&Ü%nMÒÎß<I ǽ±wûrW€Óá¸y'4g0r°Éjq]ÅpsÄÜ cY":æz³+ê*hç¯ÓëÔÙ7ùcD
-]?ÂT0"ÏœJ Ò°¬¯¼p
-B6¦˜9Þv 7ýäÎÓéÖj$Àlb†{¿öíÊÊw#dJÕsÝ–õMV)üP#‡0K•tzÒÊí±„ö PBû†ÈÔMõk»®†LÛßP€!tC€võ~vùæW¯a‡ì6oB‚P#}Ðõ¼æ~•Wyh pjˆP¶äÍŠ¨ózó@#òÆö·Ë;—ç¡Ã"¼£RS!MCüøÄ¾ $ ÿ£êI9œÕ†~ß‚8Úõƒý~;]}kè’êóšZXRiOÒÊW»ŽG«¼Ü„¡÷døæU³oÍ*hsþä”ê¸ðCŽk£ØP—0ª`‡]¹bþɇŠ_^ÝQê6B*Z GÌJÌ‘Øu꼪Ô)­K Ã_9G\™wo÷7ÿ˜zÀfÀÓ”Êñ PܲTBÙ”BÓëäXóîW×SÕÿ ’úžçendstream
-endobj
-974 0 obj <<
-/Type /Page
-/Contents 975 0 R
-/Resources 973 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 947 0 R
->> endobj
-976 0 obj <<
-/D [974 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-366 0 obj <<
-/D [974 0 R /XYZ 85.0394 532.5775 null]
->> endobj
-977 0 obj <<
-/D [974 0 R /XYZ 85.0394 507.7956 null]
->> endobj
-370 0 obj <<
-/D [974 0 R /XYZ 85.0394 170.1477 null]
->> endobj
-737 0 obj <<
-/D [974 0 R /XYZ 85.0394 148.8279 null]
->> endobj
-973 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R /F84 848 0 R /F86 980 0 R >>
-/XObject << /Im2 936 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-983 0 obj <<
-/Length 3570
-/Filter /FlateDecode
->>
-stream
-xÚÝZÝoã6Ï_‘·:ÀšÇQ"·Ûl/Åuwo›âp×öA±åX¨-¹–½iÎP_–wÀ…L‘#r8󛥮%üÔµME굿Î|"¬Töz±½’×0öí•bšy$š÷©¾¾¿úËûT_{áS^߯zs9!S×÷ËŸf©Ðâf³w?¼¿ûöÇÏoo²dv÷ñÃÍ\[9{÷·[j}ûùí÷ß¿ý|3WΪٻ¿¾ýtû™†Ržãë»ßP§¿3“~¾}ûùöûۛ_î¿»º½o÷Ò߯’7òÛÕO¿Èë%lû»+)Œwöú ¤PÞëëíUb°‰1±gsõÃÕßÛ {£áÕIù))´Y
-01=:%¬÷ö:³^¤F› À¼Â=
-^9(Ü÷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‚Ü
-^ žJFlÑ»ÁSIÂÖ bˆGØSI‚Wx‹EÂ
-:»ÞÓÎ`ÛÒg­¢rÒ­AJpΩ$༷Ée§Ò§:ïTZª‘xqoc¢œH_Xi&xmDš€G¬~‡êÑ>‚S»™Cõs©…c9X¸<ÃûhÑ4:I’0hA*nÀz¤~èéÔ½­úa ¨ú@¹‹ãž t¦aWDïp|SŒ÷üP,àyÒ¸FÆ€'Ùlê§bI#èñ?DMøØÀ )D#õ(òBƒ«d8†Ù+Ö#3ËÒÄqOËšÖs¡ÂÈÙ¡„e×¼^Ü5ŽÃ®§ì¶ÏY= àÄ7GŽGœÇªæT¢ó5•ªõmAé5ªUR§Õ²û¹« Îää÷4•÷î.–€—±»KÐݯ jÔ‰‡3U6²Ü¶8Óm:W8¨åMÌbBlCEãã±!r­gB™DòÇ|`–dn$3îÄx)Re_(ûô©Î»“–*H§Ÿ
-L}óáêáZ0õ†{Ù Âዢ߻ '¹¤W¢èil9µ' öü'¯D†‰jkß»|ñ+óž7´b8ÍQí;Õd“Q)é”w­²ï uæü¿«›¦|Ø0)d`5ÓËHLâP çÔkQï„TíõGÉ«oë.;ÍfE°ãP/ùêG›ÙC8d süR]…s ´šãnWïá@ʱ •€ «F1=Gnò„ã ÷UÅ5ây
-8Î4‡&‚o¼_„’sÐÿj¬.‚A“KŽÐŠ—ò4ç
-“Í‹5äaÙ÷Ô‚5pmsW™ð*¯D’¥ö2
-ûTçQØR Q#ZuZºÑN$‰Q—¹h©&Ø0£Ï]8 ùàB_¿°]팋'Jv«×ᑾ•ŒEìz`Êì Þß³Ó buppâpEWÈŸ—!ÿ„¿ø…‘ØÙÖ¡
-endobj
-982 0 obj <<
-/Type /Page
-/Contents 983 0 R
-/Resources 981 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 947 0 R
->> endobj
-984 0 obj <<
-/D [982 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-981 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-987 0 obj <<
-/Length 3209
-/Filter /FlateDecode
->>
-stream
-xÚ­Z[sÛ¶~÷¯Ð[å™ÅàcÚ:9î´IŽã>œiû@K´Í‰Dª¢dÅùõÝÅ)A²;=ã —%°Xì~{!ù„ÁŸ83Y¨‰-T®דÙò‚M`îý4Y$ʆT?Ü^|ÿΈI‘F˜Éíý`-—3çøävþûôÇÿ¼ýt{us™ ͦ&¿Ì´aÓ®?üD#ýüøñûë÷¿Ý¼½´jz{ýñ ß\½»º¹úðãÕeÆæð¼+œxàÝõ/WÔzóö×_ßÞ\þyûóÅÕm–áy9“x¿.~ÿ“MæpìŸ/X. §';è°œ…˜,/”–¹VRÆ‘ÅÅç‹ÿö fý£)ùiérí„MPÉ
-PV~Ãj¯«“¿&ÐQ覧´ýa÷Bðß_/Åä§Ž4ž*®œ —öçrjhŽèpP€ýZKfp-Øôùþµ[ìðé¼¥Á¦ÝÐÀ®îiˆ4†¼Ý &Lƒñà$(à¨Ô¥°ZeÐ+¢+ß…U@Iç ºÇv» g$zg§acEŽÊN
-\Àîð°WjlDÅ‹„‹\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 óÁ ^=#ç™é©ÜŒ©
-Ç÷*“{•êhº 
-àë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âTÁª¹ÒœŸ/4y5c
-’ß‘š½¢rõª
-Øÿ»r%µÌ{©r5¤: Ï=ÕÑ]¤âK0 гôT F¾Ë€£tÜyø¥þR%˹uîµ:Ð/$צ‚0·E]í]¯ÿ hàÛ1c´ÖlÆ´X™
-Kí!66pÃ!¯Âº†´„
-PSÉ¡ØS[ϳ'•mç« ýG
-W!•–²/§ƒ_ˆï­áQ¶aYóŠe£~ûÈÊ ¯àF
-Šìi ½§š
-$è¦Â¡!:84hG?»y,ÃäqÌg±81 # ›òÂùz'üBÆþ ®gǺú¡!
->ÎV`6r
-&”avt
-š\?„— 7ƒð²§Oð8R£uqÿÏÕl/x“ó£‚3 ¶àªqsâöT/ðp¼ò¥Óç˜eI­õ
-ìPqÅqÂu‡ß¯t[ìØì—8ζ ŒÇ·Õ\0±ëâ l´üSŸ€6@¨ýÂ{¢3"ïªÚu•‚9“ö_œÙ¶':Þwä…ÁÏ‘Æ÷ŸìAáY‰¸FARLu‡/þçÛå*@äí ç£D=˜h;ŽobÌ‹ŽA½©>ÌO}¯%uŽY%$ÃúW®ÿú[®ý‡nàW¥s'òaÉ
-endobj
-986 0 obj <<
-/Type /Page
-/Contents 987 0 R
-/Resources 985 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 992 0 R
-/Annots [ 991 0 R ]
->> endobj
-991 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [389.4645 148.047 438.2112 160.1067]
-/Subtype /Link
-/A << /S /GoTo /D (configuration_file_elements) >>
->> endobj
-988 0 obj <<
-/D [986 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-374 0 obj <<
-/D [986 0 R /XYZ 85.0394 332.07 null]
->> endobj
-989 0 obj <<
-/D [986 0 R /XYZ 85.0394 307.6688 null]
->> endobj
-378 0 obj <<
-/D [986 0 R /XYZ 85.0394 231.2958 null]
->> endobj
-990 0 obj <<
-/D [986 0 R /XYZ 85.0394 204.4238 null]
->> endobj
-985 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F84 848 0 R /F86 980 0 R /F57 624 0 R >>
-/XObject << /Im2 936 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-995 0 obj <<
-/Length 3216
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sã¶ñÝ¿Bo•g" œ>].¾Ô™ä’úÔö!ÉDQ{©ˆ”}ê¯ï.vÁ‰’{Óñx¸
-ùóî·?Äl lÿx'•={…†dš†³Ý]¤U #¥|Oy÷éîïÝ‚ƒQ7uêü"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èëŒ
-¥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<J™†’¢ß¨—ZÑt¦!#´ùêLãÒ,"p:޵ËÓä³gC¦
-I±bþi@ûSÞÔÇCÆÔþ„J3åÀˆ:H´$l*L盂û+E®Ðô>Çš¼% ¤U £¢¾Ö¯àüè_x"ÐqÈÁã‚­4ǽnË{pð¥MòŠ#wæâ# U›*ˆ('jƒ7Ÿ“҅жõ0ìW)Â0øáLü®•Á%§ Ä›F5ĺnT–'Å—ãzQÖÏ‹)“ÔF*Šn“ÑaMÐ121e‚H‚⎡ÔW¥ªO’RN’°oÕÔeÞæ…œ5Ž\ê1¶Y–ï['4lUk~®8ã¯è*‡8†:²z·q¬Š²h;_š€ï]rZ„÷P#Ïq¦õÒ¤” ”‡Aûß`/ IWö Œîü0'ŸE-ëØCiY¥6Ç*ãÜØÅYúöWTsU—"#ƒ(Õém]b]×¥ë—çj$ôx¤ ΕH@ðSð)wþ‚¥Oç¯U—Jb7é
-]8Õ!ñ”•¤+.v‡‚ÚŸ‹²^Ú¼AsUÚÏKæ/¶<ú%6Ô5]‘sF_T,®W%’ª0U%h+wï½è^]hÜØ³âö:Ïè\-•Ê)>Š0†{Q¬ÎŒÝHãu¬Ý²>²G^)µ¼fíp‹”1oXû
-:¬ ÆY©¦êˆvXX€DB&jàZˆaßnC1=n¯?èÜ\
-€]Q±Ë£â:Ï}ÜŒZ
-WŠC•—7Çý¾>¸r'³>C ÅÅs°‹ix9æëwë21l…a„~‹½Òú„4į’
-á® ·öï. Pg7&‰ïC
-œÙEŠÞãñÙù@M’ B}iÛzàÔÖC|ÅðOˆváµw¸‘¿½Dîá;ÛúÕ!†Ÿ¦ÊÀA"äëÀÝÁù‡ÖÈä¬^08ÔóÚ\Š¿ò '8—#§6 WžT2È[±ál¾± ï•9}j +L ¯mO®Gº²(Ü}ÃñºT'ä_®­#ô×ùœójgŒðßзª»ëù@íý¹_âë îø”\û©8xü}Ô„þÁ?úÿý3¬þ7jQ€³»ò¶&_Œ•'
-ä²¶¬¥
-endobj
-994 0 obj <<
-/Type /Page
-/Contents 995 0 R
-/Resources 993 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 992 0 R
-/Annots [ 998 0 R ]
->> endobj
-998 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [329.7108 477.6902 386.7943 489.7498]
-/Subtype /Link
-/A << /S /GoTo /D (journal) >>
->> endobj
-996 0 obj <<
-/D [994 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-382 0 obj <<
-/D [994 0 R /XYZ 56.6929 607.7231 null]
->> endobj
-997 0 obj <<
-/D [994 0 R /XYZ 56.6929 584.5979 null]
->> endobj
-386 0 obj <<
-/D [994 0 R /XYZ 56.6929 145.2693 null]
->> endobj
-999 0 obj <<
-/D [994 0 R /XYZ 56.6929 119.4941 null]
->> endobj
-993 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1002 0 obj <<
-/Length 2505
-/Filter /FlateDecode
->>
-stream
-xÚ­Y_sÛ8ϧð½)3•Ê¿’8}ÊvÓ^vnÓ»\îiw›Ž5•¥ÔRšfwî»@2eËioÚé¤"AÈ@€æ ÿø¢Ô“F-
-£2͸^,·glqcïϸçISsýt{öú].&3¹È·ëHV™±²ä‹ÛÕoÉÛ¿_üóöòæ<š%yvžêœ%?]]ÿLCŸ·®ß]½ÿÏÍÅy¡’Û«×D¾¹|wysyýöò<奿0_x '&¼»úÇ%µÞß\üúëÅÍù·¿œ]ÞŽ¶Äör&ÑOg¿ýÁ+0û—3–ISêÅtXÆ‹í™Ò2ÓJÊ@iÎþ}ö¯Q`4ê¦ÎíŸÒe¦…Ê©V™Ê >¿Ë,cv--´¤Rã.«Ù]\¸Ë[í†;[ iÝv÷¹j çyžÉR–‹Xú‘#׌2R‚<“¹æS-n7ö<U¬LzPÁî°]$OuÓõÁîÖÝnKä?»Ö3o+Ô¹­Ú¥¥¡¡ê?ö4üD«‚œ×m[í>Ú‘« >Ø*)‹L©€m¨Þª®šÇÏ[“OVèÒÀðÌh-ÿÓÆ¶ÖÙ!‹26u-“Œ[ìèöËC½;çÐ蛹Ѵ 8´²ë걨fçŒúÛº}Æ97¶ê»¶ºküTÿh{jW$ž¦ƒ¤NG_NäUõŒ†¥Þò¾ß¸«R°¤(tXˆ–•eAªº¡êK½}Üb'§Å‰ŽZ#I”Ô‡u<E+&Å Ùyrµ&ÆÞÄ‚*#½‚o)’¶#:AGb(L¬¡qh@ç6¶·ÔôxÀ&! [Ýrù¸ÃÈù¿w²¼YεyÙc®Óž8r¡Žëji_ðD ìêeÓŒ
-?Ì!²-§:Щj3ú¡È÷»ÔeÕRkŒ­žºÝGâM ±¦îj¡3<Ïø™ b É½ŸÍoÁæ%ϸž¹÷)K§>ž>
-qÜhÈïDX',>Žq,—ú(È©Rú$퓊xlQþä3Œœ…
- ‚ë,ªXh©¡” ›÷:BÎwŒp9J¡<
->@¾Ç“[ø_$—G;2¥€kQ–™B¹[ñi8R6ÊqEmgì~áõÕV,~îÀ¤ElUœÆ¢Y¥Šq80%C ÐÅŒ÷¬Î¥peò|.Xb}§Þ>4vkÿ+Ohé‹å9:veŠ,—¹\Äû}g)l–(ãÒ}õõ}Hš?¸£|9*™CE—»]Âê”çpÛ3¸Ko]8î:ðƒç™ð
-€ï|áN6²F§9}ãUg¢ÞïŽA½ÇÏ ÐvŸ¦ƒü
-·çMÔûû "ç~Oá
-öLˆoûA’ c´z±–üÿ­åpÆA&±ÿáŠec§J9¨ˆ
-^B*#LÆ ÿ!¥ÈTX>•
-–)~\!䦑à™2
- V`¶$ð¡„
-,:f
-žñÖjYfº{¶Hùÿ#v`endstream
-endobj
-1001 0 obj <<
-/Type /Page
-/Contents 1002 0 R
-/Resources 1000 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 992 0 R
->> endobj
-1003 0 obj <<
-/D [1001 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-390 0 obj <<
-/D [1001 0 R /XYZ 85.0394 452.263 null]
->> endobj
-1004 0 obj <<
-/D [1001 0 R /XYZ 85.0394 426.0265 null]
->> endobj
-1000 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F84 848 0 R /F57 624 0 R /F86 980 0 R >>
-/XObject << /Im2 936 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1007 0 obj <<
-/Length 3047
-/Filter /FlateDecode
->>
-stream
-xÚµ]sã6î=¿Âo§Ì¬µü%jú´ÝfÛtÚ´ÍææÚ>(¶œhjK©%ov§sÿý
-N“û»×Á‹èñ—áz!Çt‘÷媫šš˜ñï#9âÉš8JŽx:z›=ÖSœQcñ£©<e-†VÛª—”WØ-iÎ6kÆkï›Ãvâû}Qßwè
-ŒX…\îŠnu?åQƒMMlb¿=Å'xÔpI¦Ó1“'nRf±Nµôò®×t9U N”RÇVut‡`ijÙ5Þ`¯}(WjóÊùx2¹Î’h;Ö`0ªø¤RyÂÑ¢$yÆLuÍC³mî>ÍpŸè\Êœ—ÚëÆ½²T9<ö¸‚E :¤àêEfžô¸Œ¿ ÌyÜ)ݱÇƼÇUÇz­àæ º ·˜ñ¸Œõ'GÔ«“$º(@méš¶p¹[ÚDšÕgoL& G¹4Ï2R'qwh=ý®-·ÒšD
-;@ ž%B?•H€ƒ|ca´ŠÁ~›/H0ÅeHr.‘б̀Lö™LÂÅD™/ÇdOñ &Ñ)H-õ˜ÉÓ™„I”ec¸èniΊXH¥ŸÞH¦á=Ö²¥_v8»‘‰!û¬1ƲɬéÀ“'„žEÛVwµËöS2²Ð¬á”Õap°^á/Œl8R«©e 9}Ç0EqÑiWÕÕî°›Û³bÂøêýîÍiËaÄÈÌy•±9 ¢t‰·f-?7
-®£î”(Œ¤9w\m2¯“
-ß"~š|ýšf.ßá7\Á–»Ç%ÐI| œ¦ ¬·_!¥4 }óÝÅA›jï™ÝT  „RÞx†Ò“ð }ãé;ž—ãÈÄÜõ0£¡ö~5ÒÃÐ[*e±ËóYÊžË\ÍIØxµ-Б#øv²~NØòs;¥vVÞ‡–/3–¯XÚ{P“¾~Ryþy¹©ÊM=[nê¹rSS¹É¿-7ùÉM¿PnúÙrÓÏ•›~Jnê%rS/“Ûdƒäx3Þ ‹åw„dr$Ãg~Ø“¯ «Vt½Ušó€žßYIÐäÌOCÆŸÕ POC#ˆ]Ž›©Ã¿‡
-:aœJ\Ì\—ÿ‰€ÕýÝ[Åß®é@ÐLT
-endobj
-1006 0 obj <<
-/Type /Page
-/Contents 1007 0 R
-/Resources 1005 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 992 0 R
-/Annots [ 1010 0 R 1011 0 R ]
->> endobj
-1010 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [213.6732 702.2957 286.8984 714.3554]
-/Subtype /Link
-/A << /S /GoTo /D (rrset_ordering) >>
->> endobj
-1011 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [209.702 621.4019 283.4678 633.4615]
-/Subtype /Link
-/A << /S /GoTo /D (topology) >>
->> endobj
-1008 0 obj <<
-/D [1006 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-394 0 obj <<
-/D [1006 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1009 0 obj <<
-/D [1006 0 R /XYZ 56.6929 750.9506 null]
->> endobj
-1005 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1014 0 obj <<
-/Length 2676
-/Filter /FlateDecode
->>
-stream
-xÚÅZmoÇþ®_AøY„›}I>)¶ì*häVfQIPœÉ“tÈñŽá-«Eÿ{gwvwä‘’›…ßr_fgfgfŸ™›PøÇ&V*œœ'‰¢LM–ë :¹‡±w,Ι§Ióþ¬ï_¿Õ|âˆÓ\Ow=Z–PkÙd±úqúú—^\ÝÎæ\Ñ©&³¹ÒtúÝõÍìqøyýþæíõ»¿Þ^ÎŒœ.®ßß`÷íÕÛ«Û«›×W³9³ŠÁz)œXðöúOWØzw{ù×·³Ÿß_\-:Yúò2*¼ ¿^üø3¬@ìï/(ΪÉ#ü „9Ç'ë ©QRˆÔS^|¸øKG°7–ŽéO K”åfDrTÊ-¸
-ô23M˜P
-:¹mòe|¿]åÛ¢º÷B)Ñ#E's.‰“L"{È+X£Õt½+ÛbSæþ—žngÌNóe¾«§dØÛŸÑî¶U¾Âá¢Â‘,R̪æ1߯±ÇÖÙv|ŒdvM~·+±¯­ñ»¬«Ÿ(å÷»þ~íCŽ£‘'¤¬§õ]\üp‚uЗš1â”âAêM™-×R
-ͦ®šÌJP;]À*³.L0•¶@ß“ÝnáæµWþˆæ%Êpç6mÖæë¼jqËM¾]mƒŒìåÏÚ¢®pF¾—üA‡uGSÆTÈåÎ$• ;†ÃÓÉðÓ³ø5¤ÓïÛ+‰Ñé‡<ÎÏʦÆV;®7kÀ7¤Jº¨·mY4íˆÒ„$”óC}uè½BI¢šF‰±4¸Žmï'ظíù]š>ïÏG·l~HÕ3ñ!_ÆC q }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®»´"
-[I&ۥ
-þ³®ò1 äW•99ºÝ
-xé_!X%¼;Y=ðv}³GjغÄOª=ÔMK"'dY¯_õ
-GÄtŠhÙ-dQ´ÈD†Ÿfwç¹ —§GY†ùš@De€, •@V>fO1||Öûτڿ^–@Õp1nÇRß/‹61˜ˆ,‡Fî‘é õ>†mÒA¶)_\nÐÞ÷Rç$Áf“g—=š}®ª#®…s…(™$„4(,*NõX"mRyCNÕÚ|æ
-ˆÖ½¨ØÆ Étp…Ÿ~Æ­õ—
-ø˜Þ3ÆSS4ȧÓÎ(ôÜùv¤&ÇľÁä|ãÉÓÉÃ1½Û•åSœè_ç­1tTøÅê±o9_ ¦¦ßƒŸån;Ç€b$ZØaŒÞU¿ 7à«u²ÆF'€F³Ûl|ÀõÐ{|( áj&€×UŒl0¯æË¢÷ÇHÂíÁö“¾ý6³õ¢À¨/@çjè ýôtqšsE$©ƒâ´ŠÅéÅŒq7ÝU1ËDJ¨?òEA*(iˆ“æýY§yéfy^J¸íçm[—ºÀ‚%hòìÎݬ‘­ÅÀu$îF÷þcQ—ÕnýÓ5+¶üfYW˜
-,ƒCç2[âîG)nÁÛO‰HQ­Še¨Çb5ÅþUÑdË<RõÔÀQØô>Îú‰*ºx("{£ea¡ÍºÐuó~1V ’T‘`&OŠ÷æu•¯ìÆð–}sP.9Æ ð“6m ðj¬ºCu†ÑxծͿc¼ØÈ>ëݺW9·»qdG™Ùñí5‘”õvc»Ÿ2u陬xÆÔ{³Î˜zšåYgŸçU°›Qƒ–$wîüþݬ¯@Þß,fÌÚÛ”6°Ú-sü]åíc½ýÅÿ
-~]üZˆïyxÓib_”U7žöŠúè%†pýUk‰‰ñ˜Ž¥DÓ4õ÷7Ûǃ—èÇ©îùfÔÛѶ«ƒ:›à‚]÷\ÔKà5¸6êÝvïw‡î7•üË8Oþ½Ìª„ d­Ëa°™š¨¯˜ƒ˜`Á˜®ø§¯ØAÅô®—¬4E™ ‡ÓÛ™…K‚yÚm|G‹h{Õe;E̺7ß43–8)‘ aïdDPw×3wooÒ™7ê8)©ùt4
-q–Û³{w“ÎoÎ ÛˆÍÎï~xÆœçlgU˜±}J³wSß[¤Šú$t=>ˇAÄöîé¸Yw•«®`[TÙ6žº7áMÝ>R…kk|;u1,Ük‹³O]ö˜ç¿ì·ê™Òø%•²3À3bôŠ “g«…/ý+‰=Æ”þÕÅò/±©à™òªPG®ÝŸS³þ‹åL’endstream
-endobj
-1013 0 obj <<
-/Type /Page
-/Contents 1014 0 R
-/Resources 1012 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 992 0 R
-/Annots [ 1016 0 R ]
->> endobj
-1016 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [353.6787 706.9749 427.332 719.0345]
-/Subtype /Link
-/A << /S /GoTo /D (the_sortlist_statement) >>
->> endobj
-1015 0 obj <<
-/D [1013 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-398 0 obj <<
-/D [1013 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-696 0 obj <<
-/D [1013 0 R /XYZ 85.0394 749.9737 null]
->> endobj
-1017 0 obj <<
-/D [1013 0 R /XYZ 85.0394 600.3746 null]
->> endobj
-1018 0 obj <<
-/D [1013 0 R /XYZ 85.0394 588.4195 null]
->> endobj
-402 0 obj <<
-/D [1013 0 R /XYZ 85.0394 240.5427 null]
->> endobj
-1019 0 obj <<
-/D [1013 0 R /XYZ 85.0394 215.3468 null]
->> endobj
-1012 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R /F84 848 0 R /F86 980 0 R >>
-/XObject << /Im2 936 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1022 0 obj <<
-/Length 3569
-/Filter /FlateDecode
->>
-stream
-xÚ¥Z[sÛ¶~÷¯ÐÛ‘g*†¸Ó§4qRwN“Ç휙¶”DY<•(U$íª¿þìbФ(¹N<!.K,°Øýð-(6Iá›(hÇÝÄ8™¨”©Éb{“Nž ïã 2³(4ëJ}óxóæƒæ—8ÍõäqÕË&©µlò¸üyªžÜÂéôÝçOî?þøðöÖÈéãýçO·3®Òé‡ûßQéãÃÛï¿ûp;cV±é»oßþðx÷@]:ŒñÍý§÷ÔâèqaЇ»wwŸÞÝÝþúøÝÍÝc»–îzY*p!¿ßüük:Y²¿»Iᬚ¼@%M˜s|²½‘J$J
-[67_nþÓØéõ¯ŽÙO*›(.5X’'V§rÜÊ,1Œ‘,Ñ’±ÖÊrÔÊQ
-­¼-ÊÙa·««ázYšÂ›ZLºƒž©n¥Ft‹Žn–ªÄIcúÊ×9ZÝâ,Šm³ÅŠ›–Ívž¨c·¢çá–AeW“D•žóCE]õ:«©TTÔí…óß›‚
-Kê]í˜Y_*¯ê@MÓr=­v uG"ó 7™q™iÑ",qJq¿¾l±È÷u¾,¾ÏWY³©ÉÑ
-oñ7”í˜ÉºD0áÀ¶ø:'‰ž!ÁŒÆè 7ͲD9§&IHiÿŠ—
-ëƒÎŽ{i
-; ƒè¸8½—ÂX¡ßè5‹³›ÁZ£•îúJk7°‚I¸±|¢­J“ʯõSÇ
-<ˆ¼*Q‚Ë`Ï·3ͦð?Ÿž…¯Õ`8''Z‚ÃZ
-¤Éï–¤Ò9AB²_ëɾáÍý–OÞï`E“î¢ÂÀ³îÈ~QVv€‹D ˜½–&qÎZ”÷-®»Ýoòm^ÖÞ[±¡¤'â–;Ûg©]­³“®%ÿÙæ°ºv
-Î,JÌ£d
-!Ôyx
-õð±ë0A~Ö}á|ÎÇõ»/êbWÒÜd‡³(…´º7›3Gh¥^™Ãùh8°£ ¼› Y&ÿcN"8¤ctìykÆ_hÓƒ •h¦M€8‘Ž LpAh’zWB> áÐ d{N@ÚÓtºÍþ C+8Mh/*z²”žÇ<;„&Üd¡5tpç¼*\0. (V;pÏ;Ø%ž„´;P­‹í@YS.v%Ä1ˆÅòÚ¯$+ Ú@g/8e™Sa½kTšçxŠ“^¬‡£<.šµ—áü¥)øRôî^¨¨@J\!nŠmAÐŒmÛ]G!~Ãov‹ß¨Xý–¿Ü:~~8G¤SB'Êju»R—á°•j¹\¾:äÕz†ËûŠ&û<Úì¥ëÃñ\66žEò–jy} ­ÔÈz¤±8aoàEl s`\ï1UÀ=jâcjð[‹âe·À@§ÿª³Îâ!›çëì¹ð[+
-Û¬‚csª0îSñLë…Îj“=¹¸i~è嬿4ݹ¨À,õŽH7†a]ob@wýÁ‡"GA_NRòQ²/Æ»®&´8¹šÐ2¶Ó¹ŒmËÎtBߎžÞ^†êm2ãÛÊehmÑVŸùÜ@´uj‘8´O^ÀìpRL÷¹i†ûŒ¡,eÛô\ùfEÞ(ùôi³›{ïb°IÞçl4Ø+§½‡Š'\T$?ƒBÜX”-—¤ ª›95ᤪ >tC˜l²í~Ý#d“kCáÌZ…Ëe·×[+âzÕövĪåiá]rð‹H-9ð #Øu¤îJ]FêVÊoݲ¬fÍr?«Š?ÏP–qàn†¹ëê[©Wô#ƒ°%½26k™—‹‰(x¸Gãöq áV•·$ÔbIO|ÿ5Í›nÍŠÂ\MQRð‚Ÿnb
-°oõ+ÛR–µ—ƒ/ëb±¦aý51C
-
-›
-«<ßôÒ3-sâáÞžË¢Êæ›ÞÈÄ tš0aœ 2P¡-æ<P2 Nä¨É<GòO|Yhãù2¶¯‰CtßkCzdÿሀ±¯A KRe¢—PÀ‘¤t™ã™YÒ¹/1E gþÇ~S,üù µøž"Ì–Kn9ãZ%Æ:Õ'WX`„Öø¡o êÅ:²ìl³‰w E›j±iHJ'¥¾Î¦»R—Ùt+åí¥ úÔÕ‹÷rêµAfDk×N%ˆf_+}¼2¶Uï+ulm£Ëë]³ ûÕûÝ!Üü?ƒÎ=ÈtÇ,³m>rN?H”Ã|’ ç¥Á/±i¼.|$2h9îÇŽL©!\D©Çÿ>Ž!Eñ«pùÈ ÉA^„K‰= ÑM¢y{0cÎêx EP8Ñp¨xî Ï:ö¾·¡Z»eXiù ”}
-­Øf‡ ¿oû]z(ÜTdQP
-ñF•"<éÒIN.”5àµFúÙ' s
-I×~Ð[YUeR§ß!hºdÀg¶¨›pYŒ5Ÿ·R@õHßG4;A„§ W¡ŒÃéo-o¦q˾?\ Ó--<a˜fç¦Y-ÖÞnC怹ÜÜ¿Šl qž¾†l©+È¥:\ïQ‹åÁЉcÀ¾¯jB#ÚÅ|;Ñ×°ÍLïßw‘ÈŒ¡›é › › ›9G7ó:º³vRÇ„êþ}òåîá§»‡±ä@«b€m â|ñË`,Õ‡eø/]™r à ôüè/ÃÌ‚;ÖÁh=aB  øŒ™ë`B`!ø¤¤…L
-œ°„þÿŠÌÔEÓGÓ¢ƒé¢ƒæ¯ CjxåtCÜ?ØEˆ
-_ýIæ›ü¡M£‡åºÒÿ(ÇŒ|ßG: ñ¹Oœi£í ã†Y DRêbàcáæÍD4èžË9à«´—~ºÖ^Ma®%Æ 4m#ö{yº/“&”¸ô;ð-ia0)œ¸’ç‡Pšp˜‘©ÿc5Èhendstream
-endobj
-1021 0 obj <<
-/Type /Page
-/Contents 1022 0 R
-/Resources 1020 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 992 0 R
-/Annots [ 1024 0 R 1026 0 R ]
->> endobj
-1024 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [297.8955 586.6375 347.2449 598.6972]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update) >>
->> endobj
-1026 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 306.9508 116.59 319.0104]
-/Subtype /Link
-/A << /S /GoTo /D (view_statement_grammar) >>
->> endobj
-1023 0 obj <<
-/D [1021 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-406 0 obj <<
-/D [1021 0 R /XYZ 56.6929 374.8758 null]
->> endobj
-1025 0 obj <<
-/D [1021 0 R /XYZ 56.6929 352.4787 null]
->> endobj
-1020 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F84 848 0 R /F57 624 0 R >>
-/XObject << /Im2 936 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1030 0 obj <<
-/Length 2589
-/Filter /FlateDecode
->>
-stream
-xÚÍZëoÛFÿî¿BåKÅã¾—×Onâä4Îã
-×Ëê*]Ry `ࢪ©ƒ¤
-»t$c8Ðà<ÛQÀªáÑÁÿ.úû#gkN¹ÓéðÛ{±"¼Þ9
-Ìöá¶è°eô¬ó.ìk½@ep‘gÛ˜0‘TFN42+ØAуPÞìDlVØp-Mdylöï€æÅ@ËÃŒmR³Ž)« $b±M˜‘BMt öo6óyÞ4#fŽQÒx+¢3à ;Æ ŒÈ*àLðD›%µÿ¼ñ Ž•Ušù©h2îK´T
-ß,ÇP¨tiý17™@qSÌoÆ` ©ÝÔlpaŒÃçüýéÅÅ{ ‚
-iP³®Ê&§nïý8¾¥ïN[_$àÆ¾²¹g÷â"ÚµU ±¤Ñžµúu–‚6) ®‡xRDÉ“Áó#’aÆ~ã“1¢ŽxÆø”¶$q]狼®P2>Éxg|XFã“LôƆ¤XWôZ€GCÀD¥¾Ç¯íhPËlô tjnžÐÏ€ñ¯æÿV?páÉsÚ
-Œ ¡¼¯ë&o„k{h€²ƒïtÖí`q[;Ø‚ÚÁÁÕFÜdèxú½ç¹{
-}³´MŸÐV'†o«+ù-u%Lò«NNå}VáÑw˜º8Ä7ý­(F†o§.¬xuaq[]bØ¥’ŠçÿzõþÝÉÙù³*Û¯–!Çb'’ÚFR'Ïœ´2ŠáÇ"-–›:?Ћ”pjÙ:G‚ªs$5€9¡:˜ÃöGRsØ“R•6n¤ê
-;gÅ0±“ÉÛþ‚ƒpuoð¼«<8蜴½‚;wž}¼. W\ŸYM³¬¤ðbLº®;¢VvÖñô”÷
-¹Ã›´†S‚¯ABqÑÒ¦©æEÿ–Õß3ÓaXµªÚþt¹h—«¤Î)Å
-aƒhkI++žfÎy
-ç\.nM-Ëü6_úñ‹­A_Pr×›:õz…Æî™gxòEÙ™§œŽ°%œ%J„‡8—ÁÌœLVÙG\a:Þ$Ó³Å~ú˜8ˆlŒýÐÂ÷¯cb.ƌń'g>DÂfÇ)4¬ªþÍäÑe!Æcíåqˆ w—oÜ)ŸÀ’t–Ûþ²e¦ézݵVÔä#s‹p¹¾=øAÕzF&„JTdY² Q=ìĢϣ‹XN‹ëÒóšaÖÄNn ¸Å€{ŠJ/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Ï×»³äüƾ;“<g'-‡³¾½9ûÓûT{áS•žßÜp9‘8'Ïo6?/R¡Ä`HoøøþÃw?}º¼ÈÌâæÃ/–Ê&‹÷þrE­ï>]þõ¯—Ÿ.–ÒY¹xûçËo®>ÑPÊ8¾ýðñA<ý=ƒôÓÕû«OWß^]üzóýÙÕMÇË_™hdä·³ŸMÎ7Àö÷g‰ÐÞÙóGè$Bz¯ÎwgÆjaÖ²=»>û[‡p0–ÎÊO&BiÕ©
-Êâ‘ 8Ðÿݶ^¡5XXÚPgfû™Ñ0LÃ’Ñ<™7cÉäìTó‘~Ñ3I/ŒÓŠ99¹<˶¾×‰è™”S䙨-)'{·„ƒ, ÝÂF¬|ï–p^à
-&å<—Z9•Ç©¡yÓªY«ƒc5‰·c©‘RY:Öc»¸%kÛñ i³ŽacŶ>˜f˜×{T´L—²e¦¬­aeûf(‹Ú
-£õmOÃŒg4ª Z/›K퉶ö’Ý·‘Z€tõÄ7ÅÀÌ:Œ¡ø@ÿ#¬ÓaèDÆ
-°™ll¡P"ä4ÕÅÓƒFç•)äu:­‚™Óœoá¬UÙÂØi…6é4‚÷¥™ÀI¹ãÍjí4:%Å_¹¸­Kñ{¾ÃÔ1ÒX2E䀱qÛ?c*½–Êêxw÷Äž¤bײ>äÍ},1¢—ZׇÅ[÷-`ÅC-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‚†
-æ÷Ë4X¶1£š`öþ,ÚwòoÚ¼ åm¢_n$B§™›Ùª˜Ô “ðÚc§tð™Z¹¡Mf]i‘I¾H WÞ…D*‹Ñ
-Õq·¢ËÉu¦ÕúȾ¯âeµªÁš kD9®“Q8Ød$\6މ0ƒT‚,³2RÎj²L93ÑŠgÄ£u⦕ù ©+â(šG™ g È×Ñ%Su>¸ÀW,¥’AîÛѼܳ:ÏjYf„2áEC%ͲR$ÞËW^³J«¢¼>OÏdb6IÕ43›o@HF Aò9KÕÂô´Â&Ó§•À¹z°#ÁBñ9àJxçÜüÓòø¢¤w…1ÿàÂ]šö;cÙÌ%TJ¸þ˜6r]×aØu˜çj+-NÛ‰
-läÄéÌö/!%çúc?£4J2Ž­žâ~ÊGJ¹˜-Œ/·ÿï •%$"±qwÈw»ü@Œ¼qt.ÔyÐb›¾à»­HäÉ4bÍ·Ûú±¡vp"ØØAåYî·<qb±¥¦åp^OE£N ¦R£²|±Me,H …¢ÞÉIš9H+¶,E®>¿öVA*¥æ2B,ÖÅ\…È¢¼{éKK™=wùΠ†Œ
-õìäJ žcQ L¼3è‡ ¸@  ”— ‹?œ²ÙpUÈ8©DJ¹D²ƒwé!TjiÆ™&ÅÄtÏ‹vô¼hb¡pz^4“7E;}StÝÓ'ºó‡bõi „½¯ùÝ2”F€øEȯ9Ŋ¹ZÇB0qéWù²[5VÂ@–¢wDüx5üÄBe‹kÈú¶ùÙBÒ ›ΧõšÏ !#¶Ôä×>ÖJS‘ô–ý5çûŒÿ Á‘ìbΘ@¾ä&©Á €Sm^n›7Ñ}»)šõ¡Œo%Ï~…`-Ô=Ö|µ™fÝšçÍÔfúš’:¢¦çaê¡}&
-
-6«’ô…4¨›¿.8MBNñŽ!ú´G Ù”$“jHE¥‘t’ u³^ ä[wa$Ü)¾H$@tæ<¤äVw2I±” «Ã±¿½ ñ(°qÝ—Àá[&q¿ÍÆÅ­J…vÚñ1¥€ûßAY•†HL®\›ö
-¸ºÄ§c ìä­e'oêÑ£«–ºJwï@0ÀŸr±?®¶åšÚ!Ľhiºr†?üd%?BÖ û嘘otÒíî}ë°åëa
-£ÓR¡^AÀ¢]bžEì…¤ Mo¨U”ñýó§u|iJé»>É_Êø¡­¥F/2ìq.­zãÙçý=Úx]ÜéXQq!æû¡Z‡‚)¡OÆR,Y܇ïÓ,Ê(”žáI¯Âó»;v¥Œæ p^NÝ6¼ú5m޵K¸~`9p„«Z•·ctIx­Ä qÁ}ør2Ðå‘$ñ«r3X\ñ¤øéVQ¹–ü²{údßG¶]AÇo{ì!;¿A_IâÞ}’ävÛMž>}–U¬JV›z:Õt ÎðëŒó²½óÏ}h«->¸ÏÙÒƒ?ünÿ…²ÉÀÃ;5ïHTæð«&‰ByÛô„òøµî)éÿÊ[¨-endstream
-endobj
-1037 0 obj <<
-/Type /Page
-/Contents 1038 0 R
-/Resources 1036 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1035 0 R
-/Annots [ 1040 0 R 1041 0 R 1044 0 R ]
->> endobj
-1040 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [87.6538 396.2754 137.7628 408.335]
-/Subtype /Link
-/A << /S /GoTo /D (tsig) >>
->> endobj
-1041 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [396.1961 286.7149 464.8681 298.7746]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1044 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [432.8521 109.336 481.8988 121.3956]
-/Subtype /Link
-/A << /S /GoTo /D (DNSSEC) >>
->> endobj
-1039 0 obj <<
-/D [1037 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-422 0 obj <<
-/D [1037 0 R /XYZ 56.6929 270.2232 null]
->> endobj
-1042 0 obj <<
-/D [1037 0 R /XYZ 56.6929 241.4762 null]
->> endobj
-426 0 obj <<
-/D [1037 0 R /XYZ 56.6929 160.4328 null]
->> endobj
-1043 0 obj <<
-/D [1037 0 R /XYZ 56.6929 128.8764 null]
->> endobj
-1036 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1047 0 obj <<
-/Length 3050
-/Filter /FlateDecode
->>
-stream
-xÚ­Z[oë6~ϯ0úR8Ö‘x‘Hô)msÚÛ´{šîÛŠLÇ‘%×’“fýï;ÃÊ’#×)ZøAˆÃá77ÊÉ,†_23:Š¥U³ÌªHljž›‹xö
-ºi$V^Z„§H
-lQ¥ƒ…ÿ
-„£‹”@,˜cà Y9Œ$R¦ó›ºë7ËQЍµ+>r¬¶ ŽùLmâo‰Ìkµ'#%cñ‡Ú`*¥õŸÑžÁWDï‰ò°ÑªåÍuùÇ©ts!-  l”Áœ¨Aa«©V~OëKGŸXQQ÷X.Ñ R9Ï9?Û¸b×e»¥X’-zB
-IJ’D·/ް
-ðå}Åmoåz€YßI¥ƒî1KS0Y‰$>‡3ˆé2 ‰N#‘óÏCé ‰›±*«ŒJ4aý=uxø û8Ôúú»êžò°£Ë7A ‚¿ƒ0ö¢Æ¥)a믪¨9÷<ô
-é£{ ìû8>¸Äm¸ áj–Êf_‚5#U¸P6Õ·ÆKõm^û»:É·x2˜tlù~
-A@–õaâÀU%Z L&òxÈ¥˜À8òæ`*û`*é4à Ù×’¨`k~Þ”(Ú@–‰óî@÷‰X/‡?Âï¶9P
-é„8ºDÉ·[Y¬ 1¨§µWPWHP‡.¼–)}}‹3a/H™à o ”Îæÿî™á…^˜°èmÁyµwD–ÌÜÞ›Á…Âñ¼z
-°'Î
-@•ÚóÇ câ²LXÅb©p’Öçô¤'¢¸o%æW
-–æ”J2Ⱦ*vÄÖš‰è¼¹Ì
-¨yCÀ@|LÞNÅ‘ÒýÕÛŸÜjˆp”/âëk7Ô@ÔRRãñgev¹Ýó­ýL’Ë|ÃÇ$Çiô¾å+¬ãºêgÈ­þÂ>.8a×2ŠÒãøxø"ýIHö?~sžü2ýö-M¹óƇT»nöÕ’h®ÙÄ/*ž¼©U»î©Ù}l£?÷Y;‰#ÿ{køûîïýggØ›w8’îû_Aacw¸PIù eYp£k¦„I€asRZæ‹.?l¿^¦œj;ü1€×\±xkbF^û`G0¸c¡Âjö«=}&|Ãwí˜ÿxÛµuíÉOì •$C´Lý-
-ð—,îJgÇ’÷ÿíy)úÿÓ
-endobj
-1046 0 obj <<
-/Type /Page
-/Contents 1047 0 R
-/Resources 1045 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1035 0 R
->> endobj
-1048 0 obj <<
-/D [1046 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-430 0 obj <<
-/D [1046 0 R /XYZ 85.0394 728.7887 null]
->> endobj
-1027 0 obj <<
-/D [1046 0 R /XYZ 85.0394 703.8893 null]
->> endobj
-434 0 obj <<
-/D [1046 0 R /XYZ 85.0394 574.0702 null]
->> endobj
-1049 0 obj <<
-/D [1046 0 R /XYZ 85.0394 543.3965 null]
->> endobj
-1045 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1052 0 obj <<
-/Length 1252
-/Filter /FlateDecode
->>
-stream
-xÚ­XKoÛ8¾ûW9Ù ˆ)Qô”flŠMÚu½§naÈ’œÕÃ)'nœÿ¾”H=-%jø`’ÎÌ÷qfø€ŠÆPÁ&0ä(–c
-}­ÔÏ—¨c½CTÞZÅn”ÑäRÚâKJ OÍ×֚̉öAFoè–,GîHÌÚ",[·6Izï¦~kÌÂàÖe<ŽÕ:F¸e(Z‚\ Ë2ÛÔòüOîUžïd³o§¦ïóȦ«"yW!¡Ò«§¦ÆÎú e?³ }/],ucº)I{•º&Îlëóhx³oBºMx
-¶‘Š/+ñe•fe>
-ymÕQ@¹×“bËR;ÆÆð,ê#}êcQ¥T8ŒîÁ¾Óh®ÒøÌÜ8LnUJ~IÐq­ËÚ5ÀÖCUâTâGƧ¢©IÆ^3—‘h”Y80u¼Ùf êÄá< myá$ì%üàS-VÓâPûň­ÐÐ$K½Æ¦M¶F#‚Å\hZ@·ÁU
-×÷®Áo0ùcDÏ+„VÝ^ÞüæQ?ñ+nÛ¨zÎ0ôÆY60l®D:•ãÃö‘çåãȱëÿQví}endstream
-endobj
-1051 0 obj <<
-/Type /Page
-/Contents 1052 0 R
-/Resources 1050 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1035 0 R
->> endobj
-1053 0 obj <<
-/D [1051 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-438 0 obj <<
-/D [1051 0 R /XYZ 56.6929 516.9892 null]
->> endobj
-965 0 obj <<
-/D [1051 0 R /XYZ 56.6929 489.6463 null]
->> endobj
-1050 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F42 597 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1056 0 obj <<
-/Length 2937
-/Filter /FlateDecode
->>
-stream
-xÚ¥ÙrÛ8òÝ_¡GºjÅ€
-’ð|n¼½º~Ϙœ‡w?__^}øõæÍywW?_3úæâòâæâúÝÅù<ÊlüZ$¼Àpyõ †>ܼùøñÍÍùw?]Ü gŸ7RòŸ³ßþP³ŽýÓ™
-MžÙÙ>T幞­ÏbkBã1õÙíÙ?£YbÒŸ5Yh3N(Ц#FQæ:5³Ôæab´! ®w÷®+Ïç‰RA×o«æá×x:XbEan­&òuÕÌ·år[v«y_­…­Ù­ïËí—ØÜçïc‹F«õÛ§ï_ë{™vu_Í×®ë=ÙSÙ}j·Ÿšö ûû³|šÕ¶\ôíö‰é6®_}jܺd†¹ÎÃ,Ks
-~íÜC9,t0XGƒ)ÄQ<Z'Œd¥ +Ýç †MÙš9Y’Mã™M@j
-r¾ÁÐMnÂT¥'†þÿqù(¯Ö/¸ó)% ç855·q·E/¸‘ŽBcŒ…ÃGa¢t.FG–ÃÊ6#ò4jpIEdw+Ômlƒ®Ü>¢¥é8 V®c¤ãÁ[!‹vóÄTí’1½žËSËv{2'æ‚2É€h_Õ5£îýÔ}]NùBßòýo¶çQ´U!ávýªÝV`€Õ£G5ݾÜvüÁû
-ëÃÂxð4î‡ð¸Vû0¹Þ>1AQ.$­¿¡è8è·à‰ËÁ *'QäÀ€^²G¯¿i·=ã­‘õ›©,GÚ0CÐê^ãF  ÉZ!´Ð‘DB¬\óPŒ¤¨€€Ã
-"
-Ð^ÌJo˜†wÀqøç 俟Ì<{H.=ŠÑÅ( ¥Vì 1~#ïa¹’S(ҒæCâ”g[$?Ñ’Í{«[ð‚Y瘼Kå‡=hE†‚8ÇŸCN”\tï¶=ú­ÂjÌs-¸€¢E
-“9çTÄW ):aý&• ¼€¼><q‚(Á’3ŽðêäPédï¾ñË<µ_•’ož¯
-ucz´èW¥‘Y™4ø÷ŽÌ
- Vˆásn,
-…³Ò“Â 
-Bïß“­Æ¸†ÿ±¾`Ôj$&T‘I¿G¦gy±ÙHÀm¥×0Z‡qžK¯Ñïî¿¥ÕÐPº-@ÆÀqª9üŠéƒR®6œšâ!„
-s2K³L<hÀı/4”—1f¸‚1œóâCÍ è•PbÑÀ(ÉõqðPï„
-o1Ç7ÍsÕd%ã8ðoDOMš*¨²8d0PèÒ>o ZoŠ0®ÄøãwH&ìˆ8…u(ÊÁ4Ij£’b`‰ËC¥U¤ÉóS¾ÎNOÛ]dàãž:»MÂØ Ý7
-+BH†Ë _·y˜¦6R¬Ýµ†ÞŸKônÌ=ÈN*Y—S¦F•ÄÇG:);±Ä”öMGx¯{ÆÀvÐv[2ªŽâB$Å$ÌËû;°äŒèvlã:Fríj}T@ÌK¯“(@+ëi3ð±w÷ÙŠ®FËŠ
-¿oòBáÉEâ|õ…‡虇–àq[½ô-x.ì‰<?‚7dB¹wDæ<HKHkTŸAH)]zßÂWÓúÁëùI¡ÑÍA( ºÏe9ŽA‡æ@êV(UR³ŽLÊA|“cfÿTwÕzµÅ¢áDÀŸOÿ¶!ɺT_|8ŽŒ9œ
-uà|2/úVTûß#𤮈l5Ê$CâóÅÁRÐÙ›mõÈoµÚ4?Û?yf× ¢n.ßEy6Ùá2.‘Ç_BŸÀ+ÃñÔË¡!öXºªŽ‘Ò°Ÿv›¾›ät©°j渉ºMIrÛ›j©sD]¦Iä2MêŸgøò¤DÔ7å¶q5cEÏfôàJÌòÆ#ÕñpåàAí›áÖeó²Ÿ# ?÷H€™àË?þŒlžbmB­èÈ tEšƒ<ým\ ?¯þð/ñ‡ÿ¦C‹•ezhÖŽ<QI˜é<¢,Ô“ÍŸéÃÿd/T£­ÿX‡™endstream
-endobj
-1055 0 obj <<
-/Type /Page
-/Contents 1056 0 R
-/Resources 1054 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1035 0 R
->> endobj
-1057 0 obj <<
-/D [1055 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-442 0 obj <<
-/D [1055 0 R /XYZ 85.0394 636.8504 null]
->> endobj
-1058 0 obj <<
-/D [1055 0 R /XYZ 85.0394 606.7365 null]
->> endobj
-446 0 obj <<
-/D [1055 0 R /XYZ 85.0394 606.7365 null]
->> endobj
-1059 0 obj <<
-/D [1055 0 R /XYZ 85.0394 582.3251 null]
->> endobj
-1060 0 obj <<
-/D [1055 0 R /XYZ 85.0394 582.3251 null]
->> endobj
-1061 0 obj <<
-/D [1055 0 R /XYZ 85.0394 570.37 null]
->> endobj
-1054 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F42 597 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1064 0 obj <<
-/Length 3269
-/Filter /FlateDecode
->>
-stream
-xÚ­ZKsã6¾ûWèºj„àE¨=93ž§2vÖvj·6É–(‹Y‰TDÊŽòë· R|IrvR.ÁFh4¾~bf¬´“ÈjrNfë >y†¾OÂóLk¦i›ë»Ç‹o?9±Ìi&‹Ö\1ãq,&óŸÃ$»„xðþîöãͧŸî¯.#<ÞÜÝ^Neȃ7?\SëÓýÕ—/W÷—S‡"xÿùêÇÇë{ê2~Žïnn?ÅÒãȤ÷ׯï¯oß__þúøýÅõc³—ö~W¸‘ß/~þ•Oæ°íï/8S6'¯ð™°VNÖ:T,ÔJÕ”ÕÅÃÅ?› [½nè˜þ´TÌÈPM¦BÆCyb]ZƒÃº¾)„ea(¢ÞºÓv"8ŠÑ1Ó8ëC £Ö¡XÉlM¢Ð2£`a<“E±}M¶sÔÍ·µjqGS
-Η;¾+Pfă_¤Ô4äRÄÁœˆyŠô–•ôLèñšì©Qôœù/œËç›"%bkÎ,&Z‘w&Ú¤®:/ÖI–£À ÚTfÃP:Ÿ’2+Ö*—vÔ%(<RBù¡Ô#Û–†)kÏTVI•®Ó¼ºœê(Š>£ ÚoÒ‘âck•W­Lº“E¶Y’Óä ˜
-wæVHF¦7ãÚÚ³ÓO%rZ!ºêIòù·Åvd^z‰bÕ7Ý–#S‡š)!e_;ïÀ$¹ ^—Ùl ò‡ÐÌV+l‰ ÙlV{""ðùû.Ýf—"HËš¹Zú#Z¢ó°<Gµœ(þð]û9{I]ÓO{"5|îp]+OÖ)`ÂpÜ,<©Q‚°`D±ß¤Å@ÅÑ#8{VÒF¤†avaC¨/»ŒR[|Âçôž®7Õžš«¬ôL‹ÑsR3)¢7I,™‰l}ÄÎDaZ§A8;iê¼yAõlÒmJD†ÅÖ¨î¦è°•àÁj]8'§á,›t6®ŽVVÒ ÌÒ•3ûÒ®½HgUIÑú°#É÷Íܵ„~Û—@ÀA¬H
-PeW¦µD™圉£ ¢zý0§wv¡£«öÙ2ÉŸQYJz­)'°L^2§t ;•ÕwËàyU<%«10¨c!Î:eY fÝÑMý yµL*Z1+ñxC5„# a04=…qaë06]8Ñ©ã@F °¹"_íîˆl
-x_²YJ”ÀGâ{Ÿv~:è7
-¢ÐéÔŽ)%¸1`•éç¤#ñÏ2­¨AZ™x(ˆâ!Áƒ<MçÔ"Hð€<´ܤ³l±÷}nýf&jwáÎúùŒŽà”„&í,à+3 ç¤ ƒ|O`ðü SúÇR•<I$âÓ©ŠÑÒGnœÊ!DTgó”ÇèYžUj:é`ö HçEá©#¨Õ+2e¥'âÉ 6ñä°+1z9‡o‰‡?àωèÆÖ9KTþåЬ¤ðv)ë…‰fë|Ðw4#eƒ¬¢N€¨ïòc;›7”¡æ(ˆ„²çs¢%ccò“(#1} Æ³S¦©0*X¥'–g áB¶œækZØ4š‡9¼æ1TƒÙÝxnŒEø¬Ï¾¯Iï)a_ΛJÕ=,ìp³UR–Ô¼¹}GÜdg-ýc›TŒÝ‰Y¬7Ù*O]8Â<]$»UUÍ9sÛÞ0¾ü$©î¨`ÇZ™à=JçÖ®äÚOH[ºä
-²±ù˜º\Tapûïw_®nnQ Âø£ÅŽy‘úVî̾XA>ž…?Ulx_]É&ýg³qk¶‡Ïw?ýðaLÛ»G
-àO>¨ã*Y? X¥É‚Zîœa´ƒìžÊσÚjàVu¹¶D„œÐiàóaÓ;ªŸÏ\»tC¨ !—¶¦~oS_¾ù»õÁ[²––M—88žÃ=̹‹ñ¨w±óÿªPÊÆ&íÒb!ÚBƒ‹!AÒ£æ´QLðX7ÞMݬi(^´nîÕ°¼œ
-e®‹$#`àx1À¸ê) Kpû¦¤6Åcl­ñÞ”âc6KïOžaQ¬VÅ+bÂQ}oBk™)Æò~5³zU4?l´‚7º0^í¡)(:lÑCãpÃ*Õ.]fSGwæ³\ÖuôM^¥Û<K5uÄbɣÄâ¡
-" w¯ÖÏšò Ü­Ó9£¢Õ{Œ7ý³bë¬jý^ð’”¾oüV{Hx+¼Ë˜%¥wÎIÄ€ï$ëÊ·»ehò°VÍ2-³âH±Ç­ª drJjJá‰x™S“
-}h$¹çÁø¸öî ˜û¸ŠÌ±7Nß¾Ü<~ã§ü‘:~sÚ@ ÞúB–}Su °Œ-Jv!Ä.“V†1³ÖêÞÉ´Es牢Ä™—d›®¢G@îK¨õKê™'Uò„ŠÆ”œCž¾ÃÛ.7Üs€4[ê…Êö±ÛÔì›m†Ðò3»tÇ”=‹Üe‚‚ )ÿM÷¯Å¡j> hKŸÆ,@ƒãöµOHªX­îó"߯{#,0_¦ûñD]åuzªÜÁa‚iú’®Š ݃a[ žï?_Ý=€=¡A«Ø-Ô®ni]ˆU1+VÔ5k…uš)'V² ¬³9¸‹ˆ£‡QIý‡"3ôà3mGWDÀ{Ö±Kcoaݺ˜ò¬p¨ðý!¯Uë69f@’©(6mb#—/S!CÇÆ@ôÂ;äXµ»òŽÝo$º;\Uu¾h@".À'J-!–@ý‚㙦m®ãq¦ár)ºü)œ?^Tôàn…ïxrõ†kdùrqxÑÜYþ!M{~qž–³mæ/¡¼Cª×FŒK]ŸUý«Rpªù
-ñ¸þ>
-%D°,ÊÊS“æC8¾ÔE2¹« –»§µKc ýa9w6#†·D¥M–D¥Ô¨k¨Rßö—
-`覮  nª6ŽeÿZ¡¾Ü4¶ùšïD÷yšûïù‡%|ÈæÝ{wSd·KwIeƒÛ¢J‰ê±x¥þ@?Ì]˜hω^ÿ€Ì¤0ðÑe…[tðuóãèMÐ|î?»ö*¯,/Ó™¿qûGý gˆˆÌ‘ŒÑḬè<m° ÿ´=`5ƒyAò×1ÊÅxÕ‘fèÏk®32@†Ìl„–Ó–¡©æi•d«ò¨íÚF‹3Á¢ÅtÜrk&\ž€0Ý«l6’J@<‹B{rí†i¸¸ê}AÂHuVïší¡^ÂÏ9x¡éƒÇCzÿÉIíï^|!DàKÿ‡!¶”-Ån¶ä< jöÓûÌ: `óÃH
-endobj
-1063 0 obj <<
-/Type /Page
-/Contents 1064 0 R
-/Resources 1062 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1035 0 R
-/Annots [ 1068 0 R 1069 0 R 1070 0 R 1071 0 R 1072 0 R 1073 0 R ]
->> endobj
-1068 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [284.2769 238.6772 352.9489 250.7369]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1069 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [282.0654 208.0269 350.7374 220.0865]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1070 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [299.7586 177.3766 368.4306 189.4362]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1071 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [184.7318 124.0912 233.4785 134.8756]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update_security) >>
->> endobj
-1072 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [330.7921 92.1656 399.4641 104.2252]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update_policies) >>
->> endobj
-1073 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [401.5962 61.5153 470.2682 73.5749]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1065 0 obj <<
-/D [1063 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-450 0 obj <<
-/D [1063 0 R /XYZ 56.6929 446.1352 null]
->> endobj
-1066 0 obj <<
-/D [1063 0 R /XYZ 56.6929 419.8946 null]
->> endobj
-454 0 obj <<
-/D [1063 0 R /XYZ 56.6929 296.3851 null]
->> endobj
-1067 0 obj <<
-/D [1063 0 R /XYZ 56.6929 270.5629 null]
->> endobj
-1062 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R /F42 597 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1076 0 obj <<
-/Length 3397
-/Filter /FlateDecode
->>
-stream
-xÚµ]oã6ò=¿"èË9@ÍŠ%R¸§ínÒKqÍö’w‡¶Š-'jdɵäÍú~ýÍpHZ_–Z´E˜93ä|Kü2€?~©#„‰¼T‰dQÀ£ËÕö"¸|†¹o.¸ÅY:¤eëëÇ‹¯nbq™°$ñå㦵—fÖüòqýãâý?Þ}ÿx}µQ°ˆÙÕ2ŠƒÅ×·w’ÐÏûw7·ßüpÿîJÉÅãíÇ;ß_ß\ß_ß½¿¾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¨‡-ê<L˜PQüDz8±‹d±ÍÒ2/Ÿ7‡‚žó ò3! ᬳøÄv–€a¤‹–×´cºjòO7՞͋›þ_Uf #a._,Z54¨6–Ëtõ’—Yí§vþ-/,ßû+®Ù*ó¤Rb0RmãˆI¥…åðÃÝ"Á}ó€©
-ÀyË›—±`"е=Õž}ôn@‚NGRY\ô0Z-ÞYöª}C£mjÙ{Êz¼\ñ°CÇÇqðö<È &Íéf y#ìʘ…JD¿‰ÛH°PÄŽÛÖ…¦r—Z®-„.N;K#­!=ë,±7LBÀk‚j‚^¬³Mz(ê†fÁÇH¸„ £ûì(ÊŒ¤œ) ¾¦å
-¥r ’&ÐMíÝ>=^ÖYÙäK›[Z¾;ÎÂ$Dh‰²6ƒÓE0\ä— ïE˜I¸pPžêìסgÏ¥Å#ùéa—ÖæŽÍDáù°…Õ4;vú)s~ƒSäñÍoJ?o©Ò> [Y§Põɲw§Ž¨fa¨mÜCÉ[¾œ/‰tÛáBÆç&¾Ø?5_Œ—/ZûòåKÜ/t•/ìœü ¢aMã2µ5 R,—Ûl[íôH‡°^>)d =:N­`¦ÞQ6r‹Ž´*st u2Z”¨eu/koÒW{Fûì–"oñÑæ…¡„ðV(¼…'MÁ‰]U×ùS‘ÑT¾!($¬9æiAð¶?‘‹õ>·¥L½`80à§,+ Väå+Åd‰jRÔú+iKl
-˜ÌÕvTÅêt»+œ‚8¢'Ù3§s«â°vHi|W·rtUOÊ”c—§–ÙÈ–N€¶J?;aìlà‘ªšÏž6ÖùÀ㱌£Ìáwƒ°Ã%8U%¦éz¬°.Zc‹¤Cù!˱¼^íóÝéD«±B¢X ¤³®ÿä'Œ}«’ƶˆ" „OTGDšÜ?_Òà¾%¬ÇŸv¸/ »:‰…Í,3Þg \>ãQ2sêk†‘án“©„š+ µžÑ°Ö„†9,sCY‘=§(ý²ÂnQ_Õ¢2Ádš¾C¡ßQ´f±®é0ðèÚ*ÂôÙvJLãÊT¾»]AYzøú%/›VÌD<ª-äjK©ÕâÖv\L§Éî0Œàša,]ÒqÌê±°ÁY$.M«è·_\HÛv•aêhÙ€
-9wÈ’D÷šP6~¤>¨¦Öë¡w6¿½²˜6n…Ýþ=ú˜z*¸Ï+W°8 ¢åjaM(—Ã2…Hµ‡Œ~=L›9‹¨ü$a5B¹›6Ç,Š  é¦ÖgFv„‰N‚ÛØù”WB`« ”ÒñoR.ü¤m>@ “FuGj§»Œ¾ä¬jXÒh®\Ýcb5Ñ\¥[îÊ‹EU½š."ò]Ѥ«òÀù%œq,¢º=œ©µ…=ØMž.·þ\áp’RP˜|ΚÆ/)+¦eýFA³&c>]Œg±Ö®2t9ôÈ)˜î¼¯þªCaé§X[XžRVû-æ&rÇad«æ L(Á ,ÏÖg Œ 4Ös…cë¼x¬–àùŽ´ÿ507IÚ!î7ÿ5âÚ?P9ÀmR]Ȧö9v¥ ôŨN‘éÃc†YTOæ¬ÖU†åAbü*Næv¡qK\Û
-cÛÍ{£IrÖp8‹ ~& §uÞp<VÇpšínisð
-endobj
-1075 0 obj <<
-/Type /Page
-/Contents 1076 0 R
-/Resources 1074 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1084 0 R
-/Annots [ 1078 0 R 1079 0 R 1080 0 R 1081 0 R 1082 0 R 1083 0 R ]
->> endobj
-1078 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [259.4835 478.4263 328.1555 490.4859]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1079 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [387.5019 224.9363 456.1739 236.9959]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1080 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [381.9629 194.6431 450.6349 206.7028]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1081 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [398.5803 164.35 467.2523 176.4096]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1082 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [393.0412 134.0568 461.7132 146.1164]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1083 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [255.0796 103.7636 323.7516 115.8233]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1077 0 obj <<
-/D [1075 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1074 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R /F58 627 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1087 0 obj <<
-/Length 2798
-/Filter /FlateDecode
->>
-stream
-xÚµZK“Û6¾Ï¯ÐQS"x`öä8cï¤6N2žÔ’ Ò°,‘
-IÍX©ýñÛ`ƒ)¾”ʸ\c’à§F?>4Ø‚Â?¶P! #-t$‰¢L-VûºØÂ»÷7Ìc‚´Qß>Þ|ý.䋈D!›–,C¨1lñ¸þuNnA]¾ýñûû÷¿<¼¹Õrùxÿã‡Û€+º|wÿŸ;¼{ÿðæ‡Þ<ÜÌ(¶|ûï7?=Þ=à«ÐËøöþÃwØáeDèÃÝ»»‡»oïnüþæî±±¥m/£Âòçͯ¿ÓÅÌþþ†µxJXñÅþF*A”¢nÙÝ|¼ù¹Øz[ýtÐŒ.ÀW}JÑr aDE‘Zh‘PpQ90KѤ]¯ñ.NýM²M³ü–™¥-°¡|²x“Ê$KIÏzF4cáBsC”alD[m*;íå”ý+KmP”q™e²*.ûgœ2=­@ƒРí.Æ1ÐÒÑà~ã:ýú2-$¸“ Òâd „t…i ^c¾º ÕÞŸQ¸,lþls¼Iv;¼ûdíÁ¿¯MŽý«$Ýdù>vQÀxÄ›ò))ðÎ9«êÈ,_ž’Õ¶®bÿ‹?|ßëãþ`×Nep#†Rç#F"¥x¥l™£†µãÄ5‘&TÞ°sl‚ß(å;;à
-`ŸTÍ/ÖÖS[s.½ Z㚆vÅ(ïB£ˆÒÒLó®ç]ƒªÌJ¶Ás¼KÖIy
-ի ѓ҈
- ¼šT£A èÑ!ŒâDÂíèñÑÚ ÷¬m±Ê“ƒ'‚óÑf H‘&”˨Ò˜5*DÒJ$ý¯ 2 ÈMFKÚ–àË|»À›‡–é ~Æô¾\´}u¶Ò¥}¦.u’0h•˜¡B šÑ£'Ë©1N>¹Òð ùZ¨ òÕ¨jüåqZll•‰ƒ";æ+ÛO|€×zF‰5 E7ñED© -þõêÄ7bË…&;­&ˆG qÄ:æN¯ÆÏÞ—;F<ÝSIKb8dµÉÀ¤KƒF¨b|†,
-5÷8k`©Á¤éØ<ÉŸ±¾/÷o°FB AÚdT‘áúÊD£B—Δâ jÂÉCɦs!aÝÑî¥Oœ5 L·.2D@¢îjóE‰3œq¢ÈÍÜ ¸­­è wjüŒúr¯çŽàîb:ÂP*s5wÌÖÌD3Ü©QNÙcaƒk³Ž 7wÖ¶º G hÓ!O$£œwÕy©jƨKM`3fÂqúh3Ì.çèSãg\З{=}$ÐÎd(DìÜvå|%añPÏ,Æ”Ó5ÍÊdsã ,´)nËíÓŃzïÖÁ°
-Ž´èvÿ:©¦gÄEß!'† =J‹3ê>:´M˜ GƒŸ±¹/÷úö\Ä´ïÕàTvmv‘¡Â.œY/5¨žk‹_J ¬.Ú¢ê (Сˆ+ÿ`½ÚÕà PdxÒ`¿bã,œŠLÇÖ©$RãgÌî˽ž%FÃÔ‰i÷7¨9EzÒ&×èRhPJÉεPœ«Q®Ç}’¹Ýä¶x
-Êdï¾»9'ìãσͺÌO}lÝØ¯&¤ÕPN›Ð lèÖ!^w¨hË"O[wÓ¡­kèSLB—,d¦£ØÅüŒŠ}¹Š9eF?)¨s¸›™§ã]£f4éK›æ Ý_Ìp¬…šàXª†÷ç ›<Ûëdã Ð°éÊö?…Àjøå¤: j@ŸnÑ ™I©°«ÐëÔM³f]ÖÝš˜É²[@]N»†O–Ý?ゾÜÑ’ýo’Læ.[NÅ¢AÍ(Ò—6IGWïÑPÌ”amÔ8”ëñ“=A´rp@–Ÿ†Ê0¥åtï5h ÷nƉR0ÇvºòõŒ¸,Ã`½ ™™(àŒŒ¶ “e˜ÇÏØÜ—;¶¡oòBj1íyAažêÚ"LH õ2›Yâ5¨jB<îÊ$ØÇE +¡9èÈå¢-w€5Ð}—°áP*wúz\ZqÉæRg‡‰H¨CÕ1tŠ5~Æä¾Ü«s‘€hÁß´ëkÐŒ=YM"ºp*ÐvdÚJ£óÞ=—DÂlN)]~wJã}²Bý9¬ãÒGî§l—¬’ÁÉ€‚lWSܪôû÷2¬öïáR‡,/ÝŽ¨TËò%ÃfX§Û<ËäÙbÃÞ–OÙºÀ FuÝÂJ¾LnÙ2ÝbÃj—Ø´ô($ÜäÉö©ômvt°¹ÛŸÅÆuc<+»Š6Ô©v_i½ízÞëö¥á*KÝ&éöˆ»ñ~«ôÓÔ¾,s³CHMóik—½ØûÈr“ÊzVu'
-r¬›Ì×¥•Ńû¤áçlPŒûb¯爤<º bYa€kj_|ƒÓKðz„CK„<­ânüÏöþÜ
->áƒ
-­n4$NQ»®FIj@æ±€µquˆã,Ã7'¬_Ôäª:ÌñýÚ¦‰õmgêø†M‚0wÖøp 79¾8F!ùŒÄã$ðŒ>[ûÆ6¢pw“ã‹V€ 5ˤ-Áw’Iwʦ‚! qΡMˆ@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¥³
-†AöM—Bªkjå»Yå/•gmë¦ÜlfNI†ÌX¯N9
-›‹2¥“Ë,µ"2*•',õ+× m¸¨¶Mîn“>­MTÓ÷Ø.€åt NëÁвÚàDÏ›H[™ßiž3šïôd2‹dœd¼ßV™LK©Oú–Ì;4 }>äkÐ_Û_-•‘ÖFõVYI¯Ñ{"¤›2&ÊR䄬ãÊñ¦un¡ºD*¬Å¹{*I”*‘´”üAÙ¾‘Tp-: ¨µ[?]<dtìIJDÆ&fKÁºÉçø’Ú¤Q"’#_òÍ
-!¢­šó; yhq3nHjÖjf3©,Ñ­§:` 4:Jµ¶“XXhdòSÒ’|™áŠoË‹fæ½ xÏ è1·ÉQÙâûŽSP±ÞòâH«5°ÓúØ!MCL@š@añcͼpåö™„¬gðNøE¦(ò5û(Õ‘Ó‚šÀ‘«mÉŒ„á1%$#xóé…×GFéŸñ2 $1„Qý‹ø²ËE1ÒyѪ¼Ä‚¥Éq± ^2p·/ª…¡ÌH(Û7$Ð鹤2øìÐâ«“ÁQƒV+²/rÈæôñ;š;ùÁ›­žXµxoL€n¾@‚d
-!²QæO• îjþ,ÒðêckÉ0ã¼
-F¼wpJV™íÆO%Ù7úGý„8ö.úË„§“ÇTGq
-´?Ÿd˜qV‰Aâì%h•ФøžÄ˜2“pñí…Ê,î.GèB±å™‹ãt]â E`{¡P`õr¬Ç:]¤•¡ H™3º(Î"0hŸãQC `2}¬àI«3/$ݤF_|yRg'/ö[òþ!@®8d ñHf¢)dxqð¯ÓBˆYèùZŒ}á<¤-KÂ÷ŒŽ6 À6µŸÅƒœ?fLlMǘ¡³ ξhý3ò4SuI%ãáÝvyÐjÓ 56UÝ]a†Lßz]½°†@œVYT[¦Ä‘²šîÆ`¬HRCÊ/Õ,– Þ@»âR!'çqVÜ ²€MÙˆþßDª{´ûH#jŠm½ŽÛHš v
-•h4_¶h½ÌG{Y@XÉc˜ÎÇzøÀ¥/‹!”v v‡Åû>ŠÁ¿cøÒ‘¡ެ ²ƒ§¸ÇÀá[÷B$x©UþÉ/\Ø9 ¬^F^n{ßåf·v·mÎ–Ë „ŒZ²ÐÕ7½)ª«0–[v²> "*¹ðî嵕ØqѼ(l¯P뤭Á6»j"é󠦱œQª¥óµ*Íeí
-F÷õ …sÃë¬
-û÷ÿ‘ Cv¢.\Ž åRð Ðw é€j0½–ÔÕžMGof¯ôPÏ+Å<A
-endobj
-1102 0 obj <<
-/Type /Page
-/Contents 1103 0 R
-/Resources 1101 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1084 0 R
-/Annots [ 1109 0 R 1110 0 R ]
->> endobj
-1109 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [341.1654 116.9088 414.8187 128.9684]
-/Subtype /Link
-/A << /S /GoTo /D (the_sortlist_statement) >>
->> endobj
-1110 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [434.6742 116.9088 508.3275 128.9684]
-/Subtype /Link
-/A << /S /GoTo /D (rrset_ordering) >>
->> endobj
-1104 0 obj <<
-/D [1102 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1105 0 obj <<
-/D [1102 0 R /XYZ 85.0394 626.5613 null]
->> endobj
-1106 0 obj <<
-/D [1102 0 R /XYZ 85.0394 614.6062 null]
->> endobj
-462 0 obj <<
-/D [1102 0 R /XYZ 85.0394 327.2191 null]
->> endobj
-1107 0 obj <<
-/D [1102 0 R /XYZ 85.0394 295.1135 null]
->> endobj
-466 0 obj <<
-/D [1102 0 R /XYZ 85.0394 295.1135 null]
->> endobj
-643 0 obj <<
-/D [1102 0 R /XYZ 85.0394 265.2577 null]
->> endobj
-470 0 obj <<
-/D [1102 0 R /XYZ 85.0394 208.5998 null]
->> endobj
-1108 0 obj <<
-/D [1102 0 R /XYZ 85.0394 186.2886 null]
->> endobj
-1111 0 obj <<
-/D [1102 0 R /XYZ 85.0394 99.9723 null]
->> endobj
-1112 0 obj <<
-/D [1102 0 R /XYZ 85.0394 88.0171 null]
->> endobj
-1101 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F77 703 0 R /F57 624 0 R /F42 597 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1115 0 obj <<
-/Length 3081
-/Filter /FlateDecode
->>
-stream
-xÚÍ[_sÛ6÷§Ð#=S±øðÞ\ÇNݦŽOVgr×öé˜YÔ‰´Ü§¿],HQ¶I&µ2çvZ
-'ƒŠñdÊæ‹~®ÂkŒáªLp Úsµþ²–et”÷¤PQ¾Z”YžaCGÜñª¨©rŸ.ïrê«oÒ@¬Öù¢ø“1‘WDðŒöcüüH*¯u‘`¦Èô‰“Ä­V×pmUyçÇ,‚ÐèƒEéË!iuØð2Ön¥
-à³ß0eóE¯´ŒÕq¢ÌØ€~ƒ82Ÿ¿aé$h2,-ª‹[_K¢º$ʲ¸}žåØÓ žÍbªÌoPó±ÏKm™™ˆ.J©O
-j’ð±Uçñb/œ¶^ÑÝ­Š–´~XV ¹UVý
-I¿*—÷ù&|§›ÖÐ)²ø°_üÈðh‘.ü‘‡êlVáæ•€Í’g'V²¼ZlŠ+Ô^lÞ”XaѲ\}$RÚLÒÌ»¢ÊU¾»
-Œf–…ËÞS;­h
-rvN¢À½KƒGÖC  RIÖ
-)¦dº¡ëìâ™ßÀókÕ3ç÷MðÑYcŒƒxO©Ñýg·Ë’}Ýrì1.Ò’ÇÆÅEv*lˆ‹Žà0Š#CïM8U;b“œ³Ï93À¾Îºö
-Ýk[†¡Zwƒ¯8}'­‰…IÆ”J+‚ bÐNE³|½L^˜Å%õR€z›È†zÔ¶ÖŒE}C5Z}ãSã;_
-Û¯a&‰º9„­N 2"Þëi#Š
-¥¯€ò!VŒÚnâ¤íŽn²$-¿bÁh ¬gcoò’˜ âß /áÃ;|VG*Å¢¦„ø­*W5£×@(®|^]5>X5)\Å:>˜5wËçåÙûÏÞã3˜Ëêìÿe,íŠ-Dý°R3eåsKÁ&£øôkÿrcû×+`p¥ë áÃó:‰ñÌþxE=ùÃÎb!h‡uÿ?³Y¦tendstream
-endobj
-1114 0 obj <<
-/Type /Page
-/Contents 1115 0 R
-/Resources 1113 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1084 0 R
->> endobj
-1116 0 obj <<
-/D [1114 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1117 0 obj <<
-/D [1114 0 R /XYZ 56.6929 579.9063 null]
->> endobj
-1118 0 obj <<
-/D [1114 0 R /XYZ 56.6929 567.9511 null]
->> endobj
-1113 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F56 618 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1121 0 obj <<
-/Length 3408
-/Filter /FlateDecode
->>
-stream
-xÚÍZYsã6~÷¯Ð[èªC
-6ÃTžR•–
- ­µ/ES
-e¤ Þ±Ÿg<wÎÛ|0kÞ¥¬÷Nʳ|iÀ¾"@X³¥cƒN±µ¢¡›.A_T N¼^£ÿ Í&$ñ %äŽ{CCtóŒ-b @òwüL
-òâÂþôÛe·LƒÁ*«? x@9œŽœ\ò€ø¶ˆFÇ c㪅ƒ Ø’/ Bë®ByR°·ßÓÕ
-E9þ@ürKM§«ÃÈÎ¥8çØj[¸ NX_ádE6/«Ýïö4Gµÿå.½¢o“‘Cƒ„Nq,ÅÏãD¯J‹À†S¥¼b•‘8߯=¤Ùz’÷¼;XIE>4Þì&õ q3jm[s°pU›US—ù¨ý¾îsô¼¹·Î¹h9}ZÏ8÷Ú
-2Ôñ]ÓË}ˆˆ7lqm‡ï
-
-˜÷wÁÄNoˆœÝ7¥ã
-Âb‹ªÙÃ'àl-Ch4Q<fä é5Tè„‹ÍHlwg/Ð)Êö7Lñ¸­J\©p8‹_Ýì*ÞBo zëÁaØÓ$CÜ­z°ÈÛÀBc„`~ïØq=þ†$õ8 x¨`»Þ(û¬¤è3Ón±¨‡’\wpW
-endobj
-1120 0 obj <<
-/Type /Page
-/Contents 1121 0 R
-/Resources 1119 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1084 0 R
->> endobj
-1122 0 obj <<
-/D [1120 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1123 0 obj <<
-/D [1120 0 R /XYZ 85.0394 552.4093 null]
->> endobj
-1124 0 obj <<
-/D [1120 0 R /XYZ 85.0394 540.4542 null]
->> endobj
-474 0 obj <<
-/D [1120 0 R /XYZ 85.0394 225.1659 null]
->> endobj
-1125 0 obj <<
-/D [1120 0 R /XYZ 85.0394 200.3885 null]
->> endobj
-1119 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F42 597 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1128 0 obj <<
-/Length 2798
-/Filter /FlateDecode
->>
-stream
-xÚÍZ[sÛ¶~÷¯Ð£<ãà~é››8­:“ã¸g2§éMÑ6§©CRqüï»À%Q¶“8s2ž1@\‹o‹€Ø„›(M´ãnbœ$Š25É—Gtru¿±Øæ$5:¶úùòè_¯5Ÿ8â4דËë,K¨µlr9ÿsª‰ Ç Nÿûöüìø„+:}=ûrLHŧ/=}wyv:6ýyvþ
-K&/ßž¿žýòÇÅ鱑ÓËÙÛs,¾8{}vqvþòìø¯ËߎÎ.{•‡ÓbTx}ÿwôç_t2‡ÙývD‰pVMîàƒæŸ,¤DI!RÉâèýÑ¿{ƒÚÐu&F 
-[3”íß·øZ,ÍQú¼ z°ð°7îü#Á+îŒÞè‚;@²Êš®Ì×°}Äï²< ðAº5…Ðõª^{{ š¤¤;Èö[äý–…¹TÑHI‚Ȩĺ]g Ø·ÄMï1BM¯P4t®c&[Üe÷0ß­)áUž‘‰émÝv0ƒ0#‰<
-ÊÛÒ¯…Ö3ˆE ‹=UðÝmYýE<Æ“@1å?½žþ;Kiìx¿
->%«¬l°EˆpäÃmjÞû
-Ô"$>ˆæ (›FIHp”ë¡ùŧ,¬.àÖKšT@ çXØ»_üŽ4Ä×ÔÁƒPzk†ë2)Ât°fÛÔPX¤·ÅbÅÜ·]±l£
-ð¨eYÅîw·Eê3™ÄE¼UMÑj8©Qê˜0øÀŽócam(‚+“@.˜W  -êVÌ‹øis_Á^`œ…¿åU"zŽo.7}®]‰Š¼üH)O#cú‘Rómõb£¤%&«¦¬›²‹ƒ{aíL½ÃH©uØ>Q;(È’z8Ïë»Ô0*ø<|¢LÝ (̳x|ÛÛf˜{ÕsïÓ†%7ŽâϰÈF&’\Ø©°iÁÌ'@¦³\\Ü— :Î)Cÿ½¹†¼G…æ­_>+dŒa6Æ_lPÆî9Ä IvÚ
-Ÿ +EÅ·ŸYžbb(­1Mkn»aX{*Ûç®Ò°¸1–Gf]äizÀ]„“„ú;<$^ËuÛ0 7À×ulï`˜ q
-wp
- ‡š|Ûä<ŒÌþìx,$1ܪwØòVI8ÁZ"X\O»è¸„Žèð'ÀÃÜd8òóâÞ͉1B>††Ó³rî
-endobj
-1127 0 obj <<
-/Type /Page
-/Contents 1128 0 R
-/Resources 1126 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1084 0 R
->> endobj
-1129 0 obj <<
-/D [1127 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1130 0 obj <<
-/D [1127 0 R /XYZ 56.6929 726.9349 null]
->> endobj
-1131 0 obj <<
-/D [1127 0 R /XYZ 56.6929 714.9798 null]
->> endobj
-1132 0 obj <<
-/D [1127 0 R /XYZ 56.6929 546.8104 null]
->> endobj
-1133 0 obj <<
-/D [1127 0 R /XYZ 56.6929 534.8553 null]
->> endobj
-478 0 obj <<
-/D [1127 0 R /XYZ 56.6929 435.1867 null]
->> endobj
-1134 0 obj <<
-/D [1127 0 R /XYZ 56.6929 410.8471 null]
->> endobj
-1135 0 obj <<
-/D [1127 0 R /XYZ 56.6929 210.9925 null]
->> endobj
-1136 0 obj <<
-/D [1127 0 R /XYZ 56.6929 199.0374 null]
->> endobj
-1126 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F57 624 0 R /F42 597 0 R /F56 618 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1139 0 obj <<
-/Length 2707
-/Filter /FlateDecode
->>
-stream
-xÚÍY_sÛ6÷§ÐÃ=P3!
- ö-Mìœ:­SÔ¹›æò@‹°ÅŠTD*Žûéo P¤LÅé%7½ñŒ- `±~ Ї?1ÓŠq™Å³4‹™âBÍÖÛ >»‡±7Âñ„ž)rý´ºøá*‰fË’(™­î²4ãZ‹Ùªx¼úûË·«Ëå<Œ6UƒŸׯ‰’Qóêæújñæ·åËy«ÅÍ5‘——W—ËËëW—óPÈXE @:¿ß\_ÓÕâ—Ëù‡ÕÏ—«~ËÃc .q¿/Þà³N÷óg2Ójö
-úQ¶Øê §Ÿ2¢ö¶ìÜxÝ™{³§û¹ÐÙQÓòRjjuÙµãå[³nê¢}¿RäuAë•s¸¥wûr›ïËêÑÉhA*¨
-Ûüs¹=8nþ¬‡ì©3Tª‹;Õò@R.¹o½‰+.7¸é'f®¸fQ©ohßfdhÎr&Ätɲ/f¬'"ýŒóv Z'ê9»•‹#MÊý› ðS’že¤MF)D&ºÃ5©óŽÚޏ1û숂ȼŠ#Ø£8Bèða¬ _ ûAê=,ÚºUÏ›qaîòCÕ¿Þ( ˜³ xK‡NÊ  żvgÖ%ns}"¨5Ý c ño»ÅSÈ¿§a¨ Ì MÄs†!S"¥€æ•eQ äïT—àQÐ FÊ%DèlrëvÐË©!ýáï–Z
-j‘r €úÇÀ?Êú„s¹DäAÚ”~e’píc´;o”Óá>Øñc°ãÃ`ÇÝY\àðéÕwÊ/ÁP»ßËŽèó¯H«"L§€WáÞOÇ0ø –<X—ViÄâ,;cg + 9IξÄë”™ è‘E¨òÖ‰L‰…ÈèÜÜ25Äá0'’h¾`ÎØÆ¢æp¿9at×8ëÖ-e>ïªr]Zl„ô>˜ÂJJ( àùœow•yAP]¥c¨>4>±‘|;è£ ‚¸·\ÌqŒ*‡Ðó„R1!xÒ—±+5š®3Ï_óÝî˜ëœ/Þ~ŠŸ¯'–ÆÉ‘dГªÔÙiº²©i#w·±
-lVaœècÝã‡öW¶bÁÙû² § bgjfQ ìô€v)9ev4‹Q\F©ŸÈ6Ú;óŒNÍ3rö…B$‹°d·\1.çeýJ`GÈ[?¢E?¹øÈY}¿ÐÄ‘$¬),~: Dõ°_{I*=–š@u»jNk¼øÛ»öÁvÖ††Ç&Mœ›¦uÃEÞåD3ÚájÿÐ0Ú Õ£Úûç)ö\‹µO2LÉÑ¢0”Ø[BU[þå®rè0Ð9ñD"–wÔÒ® cƒâ×ÛäŽs{,Ù-?YìÁsâyдd\YH9Ì
-E ¦4=yÌ>Îã
- 4ñUu„,ë#„´3¿"r,ùÞ ÝáÕ
-Ô ¡4^yÙ•£#öG€XÛ{²£4uyõŠ‚KE=ú¤µCcÀÔn[óñà¿QÀЭ±_w g>ȧï#Xtþsƒ»š°ÉxõGi£?‚}ÔiMu7~ ^WyÛú:º0;\³öO…ôÎ'@çÓ(ÓË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¯ ¡-Žž.ž
-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ÿ
-U.XšÂytª
- T6 §¤%Êf¢ ñ`6ØLÀY X®Êœ(WÅa½ N,ÐqnoʪØ7›-+
-Êk‘¤I¯™«?–þ4:…ùÁ±éý1pj"ІŽ)ä/wÈ2Å£Fu*OªÓÙìêÿ^™Ö7
-?­ýÀʼnª›µ…Yf‡u5¨ªuÇΠŒRüµ…éwV’ð!\l¡lßÒ·¶ÄH}Õ
-Ãów£Éh:D—ÎFÿ\F´v9 æê÷Pú+¾q6ëUÙUo –„âµÉÑa<f©É÷¶lë¬ìÒH¤ 𢴙fÏ{RP9ñ:WO;gà¾Ó@ç ùÿ¤ÿ³ƒ‚®*…B,}×§ÖÆ'ÁbÉf€ m¢la-¢`îŠØÊÐ|FCiö¹qÙD…‘8Ëâ` [Bƒ€Sœ@éÔûàÇÛõQ hAeic~/©#Û“ÍWî ª3¼sŸÚçAsHœ ®~|.îÊý·º…$ßt•b<âþ渙Œ"ª¢Øù gÐg8š *¤'¢ïÍur¼6kqšÞs‘²E ,ø iòáÑÚ'HÞí
-l¢¬ÄÃo„j~ mVéŠ)oHËú…Y›û +•äÊù>¿{äxì@è“iM¯°èðòrʆÓ÷èÌ¡—ç7`/½ru¼ÈA³å„` ¹ÃΧ9w‚3÷Æ  arK#=Ž×¯cmQ¼[1‘ç'/nç,|éÍOÿÀ›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¦*Ç
-`iS¹¼hÛr^ ¹´‡ÍC]l‰¬³uDSéä0k;æ6*ÚfçˆÅÑè¢qÏ<pnè9÷“4+ëŠÜ
-ÄN@iqw]?Ž1 DmYßWÁ…úZ€€d”T^žË!‰AÝÒo×ó¦j‰çCÙ­ÊiádzÊ”ŤÑ~ñ°B¹ÅkÃe^÷Œ$¤¢7cUÙç^6§O$Ê®p'A#"N¹HŽñuèÖ
-¦}ɪÀ|bÁ?fãTD ߣÓ!‘Ñã’NTî͇Í®ÛìüÔÇfGD]¸ãq2™r^d¿dXM¢hû¼ qù »ÖK(@ÁJóc›ƒ¥a3%Ýñ•ŠæÙâßm•µ+bËU?€B‚SÖx¾õÀÆàK–óC|Q §"¾˜I¹-'ÌÄ9f—/톦I„õ!I”\ÈgU°
-ÖÙ#)¥ÙteSgUõèµSÐø²©ªæÁÙN9h„ X&…mŽ4¼nòƒ}±EïTiô°*+$Á1W.W¹art ÀóÁøKŠæð¾t0mÖ´d? ñëà Õ †òDºœRT¹ß¦Ì»‘Ø‚÷<kÑŠñè—þ!…凖H::C¾sþ„Пð[6`[nXl¹]%ã8Itðõr½.òÂSå™’~6q¯aGà‚Å
-Â3V=Ú%k˜€W˜*6sl´Ë©ÜÔ‰Lg{°â§+gŠOW¨ïÏŸ8§<6F'~åýw@]ÔŽu’ œkå© ò%A‚¤Á®äU>ÀG€Óˆ4}æØ­FÀ=gQ»›wÛlѵô*={H‡7ou0Œ…X!NM´Øm £5ø‰HEhôf¢Í0ÛÒ8•\©tWùYKã½æÅ¢\gaüvsèõ劆7Yž;?
-LìñùuÐïŠþ˜Û!5ñز½$ÿÌ,{wwÕ=i·ÙàÌ(Z”Y( xäp¦HËŒ@/‡ðï®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<iüœ§
-òTøJÄa§<ð+ýž„aCo?P !Í)VŶì‚ìÚ=4.ù*`ƒpèpë²zágmÇ6ÚUE;T´œdÌt CaD¨"; «óÁCßá°5@P(ÜC   8áÜŸ ù t@zîì|ÁNš/\þ æ{Xú£î?þȃWƆۗn?  ‹9ødÏJà-:=k±Ó(׃¸×&@H^8æßÿÖG>Œ _$á>¾Ó•£²n±"ûbÒ `NJŽot凙&œŒ¾ôOŸœB¾è¹Ô«¡lþŸ ÜÇÈe!ãôÙËò',ÊóP†ô™0+_€²² ¹{ܼ|a|í.Bh-¨p}‡ä¡#‡/Mý+µP&6ÛŽ.mÇ¿¥/ûzÇÝ]Ñð›Ûë_¦W4úÓž†Fájè‚øþ|v®½Yo?>c·žB^§äÞ¬?ÎïÈä~Åy»'Z¾”u•Q@¤þ®°Ú<6œÓøª=vb_ÖäÍ: A…žk=oN\žlÞ,ж ~Ô–khß¶îÆ¢W6BùûŒ!z¾NkC~ú_üêÃS裼òilm’ö¤zòctæ±`º‰‚¦A“l-~ÔSÜ4ØÚÿ`S ‡Hn’}©ünz;½sÝõl:Ôùʘ±ýýu^úT‚¿` Âãð›añµ+j,ØOünߺl²­§šåIyÔB”“ãûU‡|ƒy¤ò4¶ýYç{ ‹ý—îª>…çN|8 ø-N{({NKs“Io³Ùû9Þ¼¿þøñp¤¢ÊŸâ8˜‚º’„âS³Ñ‹á{ý<üŒm›íÇsyÔ}zL…S¡žLúÄ¥µÉÐá©Fëendstream
-endobj
-1158 0 obj <<
-/Type /Page
-/Contents 1159 0 R
-/Resources 1157 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1149 0 R
->> endobj
-1160 0 obj <<
-/D [1158 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1161 0 obj <<
-/D [1158 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1162 0 obj <<
-/D [1158 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1157 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F14 608 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1165 0 obj <<
-/Length 69
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-1164 0 obj <<
-/Type /Page
-/Contents 1165 0 R
-/Resources 1163 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1149 0 R
->> endobj
-1166 0 obj <<
-/D [1164 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1163 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-1169 0 obj <<
-/Length 1537
-/Filter /FlateDecode
->>
-stream
-xÚ•XÝoÛ6÷_!äÉ*Z¤¾Ûa@š¶[»bØšô©íƒ,Ó¶YÔô7ö¿ïŽGʲ­¶ ‚@Gòøãñ¾iîxðÇ$džŸNœ,ôxèäû™çlaí—7<Aè³0ð}L¬º¡Ÿ°0±ãŽA^ÞÍ–oáE‘»ÍpVûÌ÷îÜ­?ÍovYÝÉfáŠÐ›Ç‹/wïh[Àâ$æ¸Ís܈³€Ç‘Þðòí﯈;¥Ï­Ìû¦èit£ª¶XË&ë
- <0?ˆ„ÅK™ŸÄ‰Æ‹_¸Üó¼ùužË¶`ºF•4x_´…ò”¥‘ˆ ’±45Ðq{HÛ<™D` ôÚg/ô®oÞ·ðåÏp*šgšWÒz¶^ÓÀ‚ù>ëò­•G˜n—u´þ¨zšÊ³ŠˆVš¥¾6˜ÕšˆªÈï«loŽÚ¨†ø6}×eè[Cՠ“{sÎÒ0úâYYªƒ[©®Ø<Nh)ŒXÄ1ìBægxKîBû«—Í$Xvüi` zH þ0spý_ÀU™å÷;UÊ ¨ `‰àO¼h×dU»
-7Ù2{:©”û-Èè‡þ¼h雑­Âhd+‘2-ÈV[¥ÖfÏZfS®ÂY’ÆÖÑȬ£ ´hÉSŠ\BÔ2åãÔ¢Å1ŠGš˜£(œ9ª- ¦‰öE§}/7û—›5½z$·ƒ€á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„Ä£„&#3ùï‹Ó;ð'-‡Tku®éâ}™1Ь¡xHk@«iJW4g™a’Ò¾ÐïW²ù‚íy'úýÊôßQ[ÃÿÆ•MH×Ô@,ä°9Q c“B}cz\ÜÇRZÑ¿k…óbþ€ï
-u¬écÄÁ]¿+“…tÏ”CÈÓbü­*sÔ•É; Âíꇪîk³oŸµP,'Á7…½ÇÕ~9†ñ{dÕãéµÝI‰hq¢+Ö úë;íé>÷‡.iJÆÚ’Ø}àJ¡ë0û< ˜À‰¡½¡<¼§ÑÀ2T!ôUI…íô0tœÚefm%eEGÙºT`ãÓ·˜ûpz]´î¤êVè“ýÂêªù|¯Ž5G@ê„v{¯ß%´L_aë 7uFØî›Û¦h‰ÛÔɼ£[
-endobj
-1168 0 obj <<
-/Type /Page
-/Contents 1169 0 R
-/Resources 1167 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1149 0 R
-/Annots [ 1173 0 R 1174 0 R ]
->> endobj
-1173 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [513.6761 73.4705 539.579 85.5301]
-/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos)>>
->> endobj
-1174 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [84.0431 62.7606 448.7754 72.9224]
-/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos)>>
->> endobj
-1170 0 obj <<
-/D [1168 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-510 0 obj <<
-/D [1168 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1171 0 obj <<
-/D [1168 0 R /XYZ 85.0394 565.4467 null]
->> endobj
-514 0 obj <<
-/D [1168 0 R /XYZ 85.0394 565.4467 null]
->> endobj
-1172 0 obj <<
-/D [1168 0 R /XYZ 85.0394 528.8591 null]
->> endobj
-1167 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F11 785 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1177 0 obj <<
-/Length 3185
-/Filter /FlateDecode
->>
-stream
-xڥ˒Û6ò>_¡ÛJU‡$@Ü›“ÉÁN<ò #qM‘
-£(_¿ÝèEJœ²«Ö>h4èF¿5Á‡ÿÁ"н8 ÓE’J/òƒh‘îüÅÖ~¸ gíÖc¬ï6w÷ïãp‘ziÆ‹Íóˆ–ò|¥‚Å&ÿm™x¡·úcóÓýûÔᆾ…È#Î÷?~úøqCXŠRy2P!£½ýðnŽRì…"Œóô°ùüønŽT
-á åÝÓÝ/ÁѪÝ:ûŽB
-õí™…s4Yñ|.ª `Ï’ø= %³™Œè)åEñ`ZënæÈ ðÒ(r(ŽÎb-%î-r¸\»¢®Ð<DºÜìñUD/3]Ñ`oÊ#ŠÃ‘dôbОÛÎpœÀg}StgZÙò÷XêÌr†zFK©¢Mš¦xÃôq[ÿ…CÐ!£åi_d{B8eI£²8 þàf²å;~Èoåú w†ô6¯+Ϭõc…楖¾Yíø;­É½xâ¥"TäɪŽÅÒ_ö­yîKËg£»Þî6´h5Uºç”ƒ5O†w©Ó¼~& VsɦÞ ú¾-J+\ ­é;˜Èø˜\›ƒ#¬™Œæy_›â¥(ÍŽLâ":R`¨¹øÝ Á•ˆÄ9ãuO(Éœ‘”‘SwKñVAÁõK?™¨Ÿüå¿Wi¸äkûÝδ쬈ՊÄ'Î"æ ¾Î2ðrÚ‡ÕXy®L;L"/UA:±í9›†˜” Qpôö¤4k‘'8sVžÄâýhQüÆðµ,À×ü¥Ç’Aä •:_1ؾ<|ËZç4bQìÕà§|‚¨­¾Ùg)/ "Ç›æ›Â|¡Œ] ¿ÑÍ}¥³"’£‰±@¥„ξ=)’^š nt8œZˆwH“©*sP›aÍ÷_&L‡¢ÍX[B?ü'k¾m[»}“½ïÛæ¾¬3]Þo‹ŠY_ÇiÁ6ìÈ1 £ïŒÂÁ]S(…§
-?r°€c÷fφ1â·8fÍf›„$ ©=¢×UbY[5Ì‘cœÚxƒ9͉cÈýoWH;D¾Uñ9~Ouó…Fìu¦)Ï)*w#BÐMWd}©ù¢9Q5YW7¼cH\p¦ôfƃ‰@A²N4Öé‘ðâ(’Óhòš6‡©§T’Ž\F­$\žë×r1 F•A­À‘å¾ 4è1´ÊÄ:œßJ wí5Š*+ûÜ´Œ äÜí)¾Âœã+ÃÛé‘dX*¡\¾ç8Gœ;^&„Äþ.*M!C+ì]@ m¬ÐKaNè¬çdœ¦^¢Òà[œäRI”¸×(ø<Ìð4—ÁØM±¿û~XÊB€3;Ë_ñRø¸ÎO
-¨Ë|gém§;¾¯=¥ª—ïÁ0Eñ?Ï­¢ø*&í5ù-¼a’‚²lÝVáæ0Ö%ã
-i¸B½=ÄY&J©ZþXŸÐú±Jµ‘4w~4UNù àۀę&úW¸»E€²»9æwèAŸ ›å¨l¶9“e[f#çqPŸj×^[ÁÄ/$‰§yïsórÿ·iê¹TAxI:”8s.Fbš&Ǥ°rh×.&#ä׈‰1±²ÞÍÙ&Ü?ô“QCeô}ÝÌEð‚Ñ€}oºŒ2…®8ÌYªh©ÎExsÉĨߔR·I‚+ð?O3Ü›úþ}_e踾ž,üÜu3¶¤pš„sÍqkU©ïA4Œ¿ÅªRg{T´X'!0£óæé'P`„áŧõP$ÎÄgx«Øw~´ï†ò‰ÊzÇR¶×ÕÎ8¸u¢.Ò´-WQ6Gà¡Î DÊt7ÔnøšC_$‚¶Añ:5+H½Zt@ø•—š£>Í=€r±ž C@v`HÄl—|–…pj «
-Nˆû„.W:hÈ›9­Ï¨±È<‹ÅÀi?€u×áÛæ´¸eh;dà‘³q€^Tƒ}}äì
-‹Ä´>Öe‘çËÆ(ñµ´¬!ð`k†æqîÿLÅPýO['OõÁ8 èèá±[×-ƒ­åÀ÷‹1GZÕÖþÄ~Œ]
-endobj
-1176 0 obj <<
-/Type /Page
-/Contents 1177 0 R
-/Resources 1175 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1149 0 R
->> endobj
-1178 0 obj <<
-/D [1176 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-518 0 obj <<
-/D [1176 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1182 0 obj <<
-/D [1176 0 R /XYZ 56.6929 747.0488 null]
->> endobj
-522 0 obj <<
-/D [1176 0 R /XYZ 56.6929 613.0366 null]
->> endobj
-1183 0 obj <<
-/D [1176 0 R /XYZ 56.6929 586.6546 null]
->> endobj
-526 0 obj <<
-/D [1176 0 R /XYZ 56.6929 473.2336 null]
->> endobj
-1184 0 obj <<
-/D [1176 0 R /XYZ 56.6929 445.9291 null]
->> endobj
-530 0 obj <<
-/D [1176 0 R /XYZ 56.6929 376.148 null]
->> endobj
-972 0 obj <<
-/D [1176 0 R /XYZ 56.6929 340.4845 null]
->> endobj
-1175 0 obj <<
-/Font << /F62 634 0 R /F90 1181 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F77 703 0 R /F58 627 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1187 0 obj <<
-/Length 1975
-/Filter /FlateDecode
->>
-stream
-xÚ¥Û’«Æñý|…ÞÌVY,Ã'ÇÞÛ—].Ÿ­J99yÁH" Œ ƒ”õ×§{ºĉS•Ý5}Ÿ¾MƒØð/6yâQo²"ö“@$›²}l@ûö`ž8‰ü$Ž"xX¡n“(÷“<Ì6Û¥’¯_Þ=~‡›0ðÓ4L6/ûÉVšå~ÅÅæ¥ú‡÷t”'£ú‡m˜^þðÏ—¿’Xìgy&P,
-ÞüžŽúB@)ÙÚ3ý| ‚ð0öŠžôè¤òJí¥×ÝáKö,Ú~‘†);á)bS@Ž )Š…·Sƒ!hÐÍhj<$>=aÏ,ûPwÀ,<Ù4ræ”]E@©;örA­‡aTƒƒ¯uùÊ^œú‘{ê¬:²gƶJ#QXr÷†GÃÃL1‡Ã ÊØ„nÃ,óÆþ¦^£‡ ‰~5¨);µ×¤õ¾û ¹( ,w'“±ƒú\WÌ& ?hr°d´ÞþXw†ÍÙø ®îÀn˱AŠä‰² ÀN]PØŽƒª(¿ºE9ØS¬”CNWÖ}x$—–å¶Ôû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É
-fqd"‰½
-pTÀ4 pјéß©ù^5+“³K™›-“ç9Ì©ª.±ð?]”00%ýüf»¡£àÒ
-Ç '\ÞÝ0 ™YhíŸ#:GqÚNªçÉ5…q¸ŽíÿOºùEºX€BÁÝ Ðe[f€¡ßt¢Èª"B(â,Σ4Έð1H‚ðc(‚Hl<ˆ[Šs¿Ûñ¹KFËꆓ»L¸mB`†^™8Ì{
-­Ýv?v•ÕšÁ>¦ð­ÎÌspÿ
-/o“¥9”,‰Ãà«qP¢ßÐý'À_U$ò‘¦Á€aJ"۟˹–G¨“,_å¹kÈëÊq©‰+b~êÝë>ì)-=ÙH!Àï:Ê®ƒÔ•®æe÷tÔD¥©í‹
-endobj
-1186 0 obj <<
-/Type /Page
-/Contents 1187 0 R
-/Resources 1185 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1196 0 R
-/Annots [ 1194 0 R 1195 0 R ]
->> endobj
-1194 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [348.3486 128.9523 463.9152 141.0119]
-/Subtype/Link/A<</Type/Action/S/URI/URI(mailto:info@isc.org)>>
->> endobj
-1195 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [147.3629 116.9971 364.5484 129.0567]
-/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.isc.org/services/support/)>>
->> endobj
-1188 0 obj <<
-/D [1186 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-534 0 obj <<
-/D [1186 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1189 0 obj <<
-/D [1186 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-538 0 obj <<
-/D [1186 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-1190 0 obj <<
-/D [1186 0 R /XYZ 85.0394 548.3785 null]
->> endobj
-542 0 obj <<
-/D [1186 0 R /XYZ 85.0394 548.3785 null]
->> endobj
-1191 0 obj <<
-/D [1186 0 R /XYZ 85.0394 518.5228 null]
->> endobj
-546 0 obj <<
-/D [1186 0 R /XYZ 85.0394 460.6968 null]
->> endobj
-1192 0 obj <<
-/D [1186 0 R /XYZ 85.0394 425.0333 null]
->> endobj
-550 0 obj <<
-/D [1186 0 R /XYZ 85.0394 260.2468 null]
->> endobj
-1193 0 obj <<
-/D [1186 0 R /XYZ 85.0394 224.698 null]
->> endobj
-1185 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R /F11 785 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1199 0 obj <<
-/Length 69
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-1198 0 obj <<
-/Type /Page
-/Contents 1199 0 R
-/Resources 1197 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1196 0 R
->> endobj
-1200 0 obj <<
-/D [1198 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1197 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-1203 0 obj <<
-/Length 2607
-/Filter /FlateDecode
->>
-stream
-xÚ}ÉrÛ8öž¯ð­éªH! R¤æfËYœ´=.Ë™®šé9@$,aB‘ AÚQý¼ ”ì°S:x ððv@ÑY¿è,Oç¡Z&gÙ2™§a”žû7áÙpßDB“¤jž&JÁd;KU>Oó8;›.rùðæÝ‡$>‹Ãùb§gã^‹l1Oãì¡üOpѶ¦.íóYœ†ÁÅù>3_2Ïò,B¾öÈçÑ"KN9
-ãFâ(™«d ñb1T–2ñ<:ŸEaKßêæ¹2åvoêþ„7š/ÓÔóª6R‘ç=r³|—5<üd]ßtž4ìw†W·kèºÖëÛ+ÙT-çËE¼=ã|ž(ÐíYõ»fØî€G-e9üÇ ìåÁŸaVWaÜæ<
-ÌÖÖµ­· !iNÙ¯š½¶5oõ^ ëƒëÍ^XŠbè:ÜÀ ¼*<}´Ìe£gÛ¿–«6•-to›zÜΈ§õ
-§ºÿ°B%$Á2ßòH4•EÃÛâL‰"G´
-jóÌç¥à³v ,+:»!™N2dV<bˆB „%Ïc‰e¢æç3‡Á¥Ù«$"MÃ,
-T“¥‡RD¡J@ʼnJ([øG†¼›­šº0-JŠ0R >èÂV¶·Æ!›¬ ØüÅòéÛ)Õ¿ØL-d³ë}[™7T*•EdÝš‚ôË™ƒS"ŽfDúƒ!rd÷±€4¬
-Á¢å“oC
-!mg8iP¦üoð?SP­ (®ÐDŽñ04È•ï!¼¿Àzÿ:"èòà윓BiòàK}%õ;QóVöLæù\ñð¤@ =`ò@= |ÞÙHTö>«­š};ˆcgÒ=JD¾:/ ?MÎ1 Wëûlc6
-ÿDï}ðÁ+ýd©µ ƒ{»ÝVx¨ØÇ<
-.8bxÝã)´¢ei}K„(É-0š®`âŸ1„âcÿ<V'„H
-¦¼JW[¾,…{L /cW<€õ‚ßÈÆœU†¨rè¸9È߀"#´ðÿ`Ù1ýáÎY£ÓäQ°ê´Ìî`ï’ò6¢Öû¦‘•Vº«&CýÆöÐÂWYWÁôjÒÈÍ08R\Ÿíž—UCê %bˆpdY;ðÂþ/ô <ñF sJ4P7032€=VqÃÆ™ïƒ}Õ=Ý
-Q}¯¿qÆýiîOq;¸3ºþ6ÍÓàng+]T{Ж£¼÷Óûfc:Ô[¾ÞW ô¢¢, ä—ZÞ,zÏ!ÐRÛ{–Ëî0òSìŽÍ6®WËõöYÄWÖõy`V;±þtét˜Y$=1>"Àõw»Ç{WUYÂÆXçú]S•Œ¾Óôªó¦Ü û‡²
- FÏæé{*úú§3/Å‘÷‚Ÿ¨Ï(ˆòÞpà® Ûjáò­Ìô­¢‡ÂþNŠ<´û½¿O3¹:M30;V¤¶G(F4µÔó’ç;ýd˜hc(„&EÄ 
-endobj
-1202 0 obj <<
-/Type /Page
-/Contents 1203 0 R
-/Resources 1201 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1196 0 R
->> endobj
-1204 0 obj <<
-/D [1202 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-554 0 obj <<
-/D [1202 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1205 0 obj <<
-/D [1202 0 R /XYZ 85.0394 572.1453 null]
->> endobj
-558 0 obj <<
-/D [1202 0 R /XYZ 85.0394 572.1453 null]
->> endobj
-1206 0 obj <<
-/D [1202 0 R /XYZ 85.0394 536.5761 null]
->> endobj
-562 0 obj <<
-/D [1202 0 R /XYZ 85.0394 536.5761 null]
->> endobj
-1207 0 obj <<
-/D [1202 0 R /XYZ 85.0394 506.7869 null]
->> endobj
-1201 0 obj <<
-/Font << /F42 597 0 R /F43 600 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1210 0 obj <<
-/Length 3135
-/Filter /FlateDecode
->>
-stream
-xÚÍZëoã6ÿž¿ÂßÎÖZ¾$‘é]l^M»—æb½C[àd[‰…•%×’“øþú›áz$v²½Mq»‹À|g~3ä ‡âÿù Œ‚È3ˆ
-BÆÃÁlyÀwÐwqÀݘ‘4êŽú09x‰ L$¢Áä¶CKLk>˜Ì28
-løáòÃÇË/nޝ¿û×áH„lø+ ÙñÕ)UÆ?]\œ'g®zsv|zyuCøá(Ž __Ÿ]^þ“ú‘*kZOÎÆ‡¿M¾?8›4lwEãL"Ï¿üòÌAÂïX Pa7F –*”A¨¤ô-ùÁøà ÁN¯º*Î!–çX)1à*
-:»`…&:,q8â ĺH‹tä$ëéÕØ’ަ봘¥T½,nËõ2©³²@ái ˜0´K°ÁH² йöÄîÈ_^ßGD#™Ï×iU¥UG%ðÏâN4eGÅ@R¨À(®,IGFÇ–Ì!×COJëaB ÔÏ…M³šz²yZÔÙ!‡Õ˜H×n<ÈBc³¢N׷ɬ!TÌ©£JëŠJå­£ÔÙláŠi»¾h«å|3Kç~ê«)ŠŠÂ5èp„zl†uI¿°N–guR§T¯fIžLsW»DVŠ´¦-¶©³â Ušx8Y´ Á€¤[©TóÕíÊ
-E+(ïâ{Dš £Žf¤ŠÐlR ó?Ù,©ê*”<ˆe3îBÄ´ i†Ôâ„­ 8#k˜È=F´»Mñab"R±V%ßìàR‹@j)ÜâÇÅv“Æ©“2’–I\­Ï$¶XÓÁÅ=?¨, |=¦ªo Á
-<ßÁ×a ¥ˆÝºßäõ^M b.ß‚C‚W± ŒyÜ·Á–o´"ΆߵF»õÁýÎÓj¶Î¦®†öl wy9õgˆ7ˆfÓ;k¢†j¶H—©[ãÜnDh]–ÝŲö´yçf¥®ëæü„
-BÆ*h6S)èð™xž’»;"z—Ônóü!N‰Ç‘kKš¾</h{ìò‘TAÌA½Ÿá
-BPC,LØwÿÛ,ÏGç€ÙËÍc@ËýŒ>©Ö'GBqwüL×L#°$xE›VŽà
-ã!t½™æÙŒÊ“C#†åªÌË»­ QüXK³·8çQ
-'¾né(ÐfÊD̃Ð(¨0pj:ú<ÆY>WÒh‡^¢¨;ñÛ½ößaóë…<œ‘‘Þ¥Œ¡Æz
-®(
-Çý Ú³‹š
-K°"¥z¬‚tŠÆz1k†QÙUúX¿‘™u˜úzÍ,Œ7 W‹ (аëG÷: v ½v¶¾^ìÖòè„Ù‘¡€òòjrvs~ÛñÉY ¢â²5À—"Ÿ½pµœ¼ZŸÇü¾››8€p¿„¨\òÏŒb
-Iz¼mkV òl¿P]RÕ‹Ø L‘ÇMê»sÖØEŸœ5O¯kpÚ°¸Ÿö"맪ÔVÙVÇ…çyž9o’Üå{…4„yý|zÖ?ÿ¼ÛH\–4»O]‹ÃÃelÑø> ÃaV/ÜÉy}½{–Bõ¯<Ó4/t›-.}z·ó”õuR/ü}³^$nÝe2[dEZ>F·W 6);‰^ÑW.ÖgÉ*™âûÉ–êv7íß dO {‹‚–Nj ™>f”4ÚsE¥úUu„Æ`v0âf妩ïY¯³t¾ë1¨ÜÔ}•ÐcÊM1O`^õÎé "1º y»1(sŸlû¹ë“<©ª¼Is[ã<-—‰§vCIí=éäòô•ôµ :Z`QÏ¡²ði*,76Õ¥©›²)²ß7n¼•ÚÀPj .âÃ]жâŠÐ±€p$â(“Ð0ÀÚN+ª6·ËX€RVíÒ‚'bz=Á!+¢'ïØSöFÄö­q]5óÚ7¨N·µ5{ DÔ™· —ºùCûb'zï(¥ä˜“Qçççgøk›Ò(žð™'¯±÷XØÂ†¢Þ.ÇCAgЕ—)½§ÀfÈî
-«Ø5u“%CÁ®ïY2¶¥lÐX”›|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á
-~ÏI‹ƒ|ò¬p÷YB…ó >,s5Ä
-nëÕÑû÷(wUYÎ7ï³bdUó?®°ö—…Î5“É
-endobj
-1209 0 obj <<
-/Type /Page
-/Contents 1210 0 R
-/Resources 1208 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1196 0 R
-/Annots [ 1218 0 R 1219 0 R ]
->> endobj
-1218 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [401.6435 61.5153 511.2325 73.5749]
-/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>>
->> endobj
-1219 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [55.6967 30.8502 511.2325 44.7979]
-/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>>
->> endobj
-1211 0 obj <<
-/D [1209 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-566 0 obj <<
-/D [1209 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1212 0 obj <<
-/D [1209 0 R /XYZ 56.6929 748.2826 null]
->> endobj
-570 0 obj <<
-/D [1209 0 R /XYZ 56.6929 748.2826 null]
->> endobj
-801 0 obj <<
-/D [1209 0 R /XYZ 56.6929 720.3635 null]
->> endobj
-1213 0 obj <<
-/D [1209 0 R /XYZ 56.6929 647.0664 null]
->> endobj
-1214 0 obj <<
-/D [1209 0 R /XYZ 56.6929 635.1112 null]
->> endobj
-1215 0 obj <<
-/D [1209 0 R /XYZ 56.6929 529.3677 null]
->> endobj
-1216 0 obj <<
-/D [1209 0 R /XYZ 56.6929 517.4125 null]
->> endobj
-574 0 obj <<
-/D [1209 0 R /XYZ 56.6929 180.3481 null]
->> endobj
-1217 0 obj <<
-/D [1209 0 R /XYZ 56.6929 143.7717 null]
->> endobj
-578 0 obj <<
-/D [1209 0 R /XYZ 56.6929 143.7717 null]
->> endobj
-644 0 obj <<
-/D [1209 0 R /XYZ 56.6929 116.6563 null]
->> endobj
-1208 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F11 785 0 R /F77 703 0 R /F57 624 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1222 0 obj <<
-/Length 2590
-/Filter /FlateDecode
->>
-stream
-xÚ­Z[s£8~ϯð£]µV„lmm•c;wwÜ;½³³=ó@Û$¦Úà\æ×ï’@`{j·ò!tÄùÎå“d<pà|†¸¸ˆ9˜ 6‡+gð cwWXÉŒµÐØ”ºy¼º¾õÈ @G¼Áã“1—ßǃÇí×áäáa¾œ-þ=æ 'h4fŽ£{§óõh̽@ P1ä9ÛÅͧÅç»Õäá§_åK¿9Ì™,gòaýåîn¾~œ«ÇÕ|2[,ï@~üp5¬–m~v¨XóW_w[øÂW¢Ï¯ðà dp¸rEÌ¥T÷ì¯ÖW?W£å«]¦bÔGÌ'¼ÃVŒwÙŠÈ£„–¶Š“±0Ï0I‹(¿n¦¢”ùõ;] ¨¤Æ¦X¹
-|·™â²ô˜æ‘ö”K AžÀܽðL©~ì*©*¼‚À^VÕ5xgº»Ák(_$YõËR8þ'Md# “üI;¸Fp¶\wÁçb„=ßmÂw¯àû¼+BÕ59=ŸòBx½1ÃD
-%Åú0=ޱWcA^c!f1±ƒkÕÿ¸Kyš¨Þ_ËØTC«èû®€实±Ì¿bè’L·RÜ`º7é)ÙjÌ™Nå
-U ùÿæ”ïdk¾ÿS¶ÓþýG0æ0¤,Hh©
- êø$lª $Úº{0•/£g0é‹ÎjáfW±
-ô*~>EYí†í9&é.E“d+ ß«æq÷rÿ»ÙUv÷ûíDÂeÀRìv7¤,v×R•Ý}×B¬ª »·u÷ØÝT¾ŽyŸ²áÇè]6jnT¢”Фˆ«¢’²‚AC qÚñ¸^TçKg•‰"ÇgØ@ ^ªK<@:t‡ñUu¢Áð³º;m¿r™ õ‡352ób,_¥¢‘øöáw]ëhùÕ: VÄõF¹Š<ߨïÁ ©§ôŸÄqœnÖ Û>ŸºøÇX§zŒ÷*I¶šqÍ¢—hŸCëóGêäòK$É”ê÷ÇJª"I¾o)ÂVÕµ?žéîödžò*ÈçoE”äçI9?i¦XÊâAþ‰²¼"I^Wb
-²öÉÙR˜y¯:§ªsÊ<.¹œž·sã$c&ÆÏm2§Ëû=0¬jŸü×\û‚ õ—0¥ú]¢’ªO¢|ÒïVÕµKœéîv‰†ò5ìŸôÁßòT³™ äƒÝ!zßy¡ÉsÏw¶Õ6¶e}s«k;`:Ëô˜{ˆr¯ut»Šòô”mT}ZE›4ÛêËÀ¾£Þc\ØŠKÛ ÖB•P… ö©A‹^À–âü ÍËè¾SÎÐ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<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>>
->> endobj
-1225 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [84.0431 756.4942 140.332 767.8862]
-/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>>
->> endobj
-1226 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [507.6985 756.4942 539.579 767.8862]
-/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.ietf.org/rfc/)>>
->> endobj
-1227 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [84.0431 745.1168 199.6097 755.2785]
-/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.ietf.org/rfc/)>>
->> endobj
-1224 0 obj <<
-/D [1221 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1228 0 obj <<
-/D [1221 0 R /XYZ 85.0394 694.0474 null]
->> endobj
-1229 0 obj <<
-/D [1221 0 R /XYZ 85.0394 694.0474 null]
->> endobj
-1230 0 obj <<
-/D [1221 0 R /XYZ 85.0394 660.6469 null]
->> endobj
-1231 0 obj <<
-/D [1221 0 R /XYZ 85.0394 660.6469 null]
->> endobj
-1232 0 obj <<
-/D [1221 0 R /XYZ 85.0394 660.6469 null]
->> endobj
-1233 0 obj <<
-/D [1221 0 R /XYZ 85.0394 654.2654 null]
->> endobj
-1234 0 obj <<
-/D [1221 0 R /XYZ 85.0394 639.5008 null]
->> endobj
-1235 0 obj <<
-/D [1221 0 R /XYZ 85.0394 635.7135 null]
->> endobj
-1236 0 obj <<
-/D [1221 0 R /XYZ 85.0394 620.9489 null]
->> endobj
-1237 0 obj <<
-/D [1221 0 R /XYZ 85.0394 617.1617 null]
->> endobj
-1238 0 obj <<
-/D [1221 0 R /XYZ 85.0394 557.6417 null]
->> endobj
-746 0 obj <<
-/D [1221 0 R /XYZ 85.0394 557.6417 null]
->> endobj
-1239 0 obj <<
-/D [1221 0 R /XYZ 85.0394 557.6417 null]
->> endobj
-1240 0 obj <<
-/D [1221 0 R /XYZ 85.0394 554.1294 null]
->> endobj
-1241 0 obj <<
-/D [1221 0 R /XYZ 85.0394 539.3648 null]
->> endobj
-1242 0 obj <<
-/D [1221 0 R /XYZ 85.0394 535.5776 null]
->> endobj
-1243 0 obj <<
-/D [1221 0 R /XYZ 85.0394 520.813 null]
->> endobj
-1244 0 obj <<
-/D [1221 0 R /XYZ 85.0394 517.0257 null]
->> endobj
-1245 0 obj <<
-/D [1221 0 R /XYZ 85.0394 490.306 null]
->> endobj
-1246 0 obj <<
-/D [1221 0 R /XYZ 85.0394 486.5187 null]
->> endobj
-1247 0 obj <<
-/D [1221 0 R /XYZ 85.0394 471.7541 null]
->> endobj
-1248 0 obj <<
-/D [1221 0 R /XYZ 85.0394 467.9669 null]
->> endobj
-1249 0 obj <<
-/D [1221 0 R /XYZ 85.0394 453.2621 null]
->> endobj
-1250 0 obj <<
-/D [1221 0 R /XYZ 85.0394 449.415 null]
->> endobj
-1251 0 obj <<
-/D [1221 0 R /XYZ 85.0394 377.9399 null]
->> endobj
-1252 0 obj <<
-/D [1221 0 R /XYZ 85.0394 377.9399 null]
->> endobj
-1253 0 obj <<
-/D [1221 0 R /XYZ 85.0394 377.9399 null]
->> endobj
-1254 0 obj <<
-/D [1221 0 R /XYZ 85.0394 374.4276 null]
->> endobj
-1255 0 obj <<
-/D [1221 0 R /XYZ 85.0394 359.7228 null]
->> endobj
-1256 0 obj <<
-/D [1221 0 R /XYZ 85.0394 355.8757 null]
->> endobj
-1257 0 obj <<
-/D [1221 0 R /XYZ 85.0394 331.806 null]
->> endobj
-1258 0 obj <<
-/D [1221 0 R /XYZ 85.0394 325.3687 null]
->> endobj
-1259 0 obj <<
-/D [1221 0 R /XYZ 85.0394 265.8487 null]
->> endobj
-1260 0 obj <<
-/D [1221 0 R /XYZ 85.0394 265.8487 null]
->> endobj
-1261 0 obj <<
-/D [1221 0 R /XYZ 85.0394 265.8487 null]
->> endobj
-1262 0 obj <<
-/D [1221 0 R /XYZ 85.0394 262.3364 null]
->> endobj
-1263 0 obj <<
-/D [1221 0 R /XYZ 85.0394 236.8919 null]
->> endobj
-1264 0 obj <<
-/D [1221 0 R /XYZ 85.0394 231.8294 null]
->> endobj
-1265 0 obj <<
-/D [1221 0 R /XYZ 85.0394 205.1097 null]
->> endobj
-1266 0 obj <<
-/D [1221 0 R /XYZ 85.0394 201.3224 null]
->> endobj
-1267 0 obj <<
-/D [1221 0 R /XYZ 85.0394 141.7069 null]
->> endobj
-1268 0 obj <<
-/D [1221 0 R /XYZ 85.0394 141.7069 null]
->> endobj
-1269 0 obj <<
-/D [1221 0 R /XYZ 85.0394 141.7069 null]
->> endobj
-1270 0 obj <<
-/D [1221 0 R /XYZ 85.0394 138.2901 null]
->> endobj
-1271 0 obj <<
-/D [1221 0 R /XYZ 85.0394 114.2204 null]
->> endobj
-1272 0 obj <<
-/D [1221 0 R /XYZ 85.0394 107.7831 null]
->> endobj
-1273 0 obj <<
-/D [1221 0 R /XYZ 85.0394 93.0186 null]
->> endobj
-1274 0 obj <<
-/D [1221 0 R /XYZ 85.0394 89.2313 null]
->> endobj
-1220 0 obj <<
-/Font << /F62 634 0 R /F57 624 0 R /F11 785 0 R /F43 600 0 R /F77 703 0 R /F42 597 0 R /F56 618 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1277 0 obj <<
-/Length 2680
-/Filter /FlateDecode
->>
-stream
-xÚ¥Z[“Ú:~Ÿ_Á#T¯%ßÉÀÉÉ\–™œs¶’<£WŒMl3Éì¯ß–uA6²È©-Ð¥¥OîOÝjµF.üÐ(0ÁÉ(J|'pQ0J÷Wîh }Ë+$d¦RhªK½¾ú×MˆG‰“„8=¿hsÅŽÇhô¼ù2ž9ž3ÜñûÛ÷Ÿn–«Ùã‡ÿL¦8pÇ_ÝÀÝÏyåéór¹xz^ˆêj1›ßÞ/AM¦Q˜¸ãÙããâ~~û7Y]Õz½xš|{þxµxVËÖ ¹[ó«/ßÜÑžðã•ëxIŒ~BÅuP’àÑþÊ<'ð=O¶äWOWÿVj½íP“ª”ÌÔóð/(4HœÐÞR¨ï™*¥˜B¿¬n®±àoýçEtôIÏ •Ô9vjØGN€£.öl2õP0žß?±‚?^­xÃKYñÂÓ¦ÙË[Vly½ÙQ.ù©LI“•o._„8­^³”Ö{–ÞÃc7q‡1,›A¿ƒjig#—Ç|]‘bSÓ‚@™÷<NNÆBìÏIŒ³_ÃÒ¦\ÓŠÁ¦
-aŠ“n€øÐÜK†à8¼Àª&eaUJ)VQèYXµAk¬ö±Í¬êØŸkÎÆ‚/(Ü ­
-Úð'œõ—¢!«›*[!~wû÷bÅ‹×eÛaO
-1v™—k’óòl³©&(ÓºãÈáÀÀÏé÷üÄñ4è÷¹Õ·åSΡëp˜—iºËÊwÜU|$Å‘To¼ôƃô†Ðâ NP&W
-iÜÆÃÜÚpOÔöÌêÀ+Z—ù‘›öÂÖì°?£ˆ72¡cËJJyËí†MöÕu1­jÞtä[„ n·k›—{’‰™ïÉžòî§·º¡{¡®çDq нd¼rÄd¤ÈhΧhM™5Þ9‚d9´Cò%yË’, ª(ކ)cØùÈ»À±&e!YJ)–±çZX¶Ak4÷±Í<ëØP±»¿Ò)¶BsšÓ­p»í™JÓ²Úðrë²YóÉ¤ïŸ ´¡8p°§³Æ&rÄ!Ü|ÏŠº,D³ô®]`B<RĽ€ßý¹aíEŠ\þ ­a9ýúÊ”3âÔ à„.œµº”…S)%9EÈENmЧ}l3§:¶ÒÇ¢HË 7?¨µ6 ÿ÷´ùYVßE̯îiïÔ'¨xž$xüv
-Þ¿²³C•å’ó8´¼  #;KºÔ0KJêĶœVèKgØF–:Ø+úã˜ñ3m^³î×éeµe-%¦Rw‡<K5Uô=‡²jLŒÕ$“‘É¿¯¸m³!ÚH7âºñÓÑ¥,¤H)EJXLÇ
-­‘ÒÇ6“¢c«“I˜†Ð(?™x¹©ŽiÃ=ÚÓ¼æ5 î0 œ0òü®ò?
-ãx‚i.ï?UwÊúÃ4°0&H.Ù†&e¡AJ©SÉC‘…´FCÛLƒŽ}“ºÎÛX¯µ…ûél>_9³÷.³ßQ7<TÔSö¡ìE¶)¨tBKѸl.[Ý—eó®Çnϳ®fÊâ#Œ=oäaZµTîƒñ}ïB¨©K ®¤NvçY·BŸ?Ã6ÞÁ¾.÷{éÈ”.æ¤!¼t“傸#°ðr{¬4×·¨8gUm C"Ç}ßrL½§´'Áˆ7h|~9qr‰Š“… !¤ˆHåžnÃÕxè›iЀ,¨IòžAüs.0ǸËÅ\Ò@`läËæº®&ñ¸s¾_ûà?<?¼p¿Ö¥,dH©SÖY¢s+´FGÛ̇Ž}¦ûë*ƒ° #½`aîêìТÕ+ÜÂL Aä†àßdœFŠB¿çýúc¡És(‰Ñš4) MRêt‰B‰…&´FSÛL“Žý¹¦Ý[Ï,ÏHMû±]'·e²àêïD¸ï»î È>Ë›³øO^±þb¶TeÛ]ó/Y^QjtO(íR
-Y« Yëó!4.EGSÊ’õͪuÖT­«ã½•B˜5"afô¨pº¹ºCõ`N¶Ø,«²¦Åš÷¢ý޼‰ü¥ÕO_Ÿtì]Šöu) RJÑ!ËÌ
-­ÑØÇ6Ó¨c Bʼo §„®Û­9Ï÷mPbß8gŽtÉ{"Óˆ÷å+Ýë–7ÎM`ñI|AÏš”EÏRê¤çÄf.6hMÏ}l³žul¥Ny5íjûSI62ÈI‘¨Ûó!vè瓞™““ñC•ÕiiÊ-ÀÕkPá®ë øRVO—²(\J$ß7X¡5…÷±Í
-×±Åé\r©Ù:;ÛåÆËî,ÏåSäàA9èr𠢂Éq»#ÅÐÆήâ±·E6¾.5̃’:Ýcý`˜+ô‰‡3l#lu&„¾Ì´±"㸤x; ðÒŠ%Éè+pgJ#`ÇãHóø‰×¦ØÈ?rZÀÙÔ¶be¬ç/FN™¿ˆj KÑÿ°…ûöú­õˆb¸:.fÿ¼~‚ä@Àx!ÎÓ¥,tJ©¶—˜VhÎ>¶™N{¦î=¯ì=‡Œ¼n¤A‰° gzzе6[žñd‡3Æý®­1¶.ä<ö&«t#»u]æ´é'³>Ùþ·¹Iç-~Á}$c-òÙV«ÁÀűƒ.ùUMh˜)¤… úm¸'öûÀFòu`~†áPOªcñb þ—´ÜVä°ËÒV5ÐòÉâECìÄAè/´ÐøÚáo¿BÓ<=mÀ!*LwÇü¿T´> ùÇœfMAÕÕº8‰Ð72p°nÊ"{'ìYâwìy J9ÛEìK¯ŸÀ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^<tã„›.0‰XÓGŸ­¹öBlXúÿ
-endobj
-1276 0 obj <<
-/Type /Page
-/Contents 1277 0 R
-/Resources 1275 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1196 0 R
->> endobj
-1278 0 obj <<
-/D [1276 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1279 0 obj <<
-/D [1276 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1280 0 obj <<
-/D [1276 0 R /XYZ 56.6929 771.5874 null]
->> endobj
-1281 0 obj <<
-/D [1276 0 R /XYZ 56.6929 747.5177 null]
->> endobj
-1282 0 obj <<
-/D [1276 0 R /XYZ 56.6929 741.0838 null]
->> endobj
-1283 0 obj <<
-/D [1276 0 R /XYZ 56.6929 714.364 null]
->> endobj
-1284 0 obj <<
-/D [1276 0 R /XYZ 56.6929 710.5801 null]
->> endobj
-1285 0 obj <<
-/D [1276 0 R /XYZ 56.6929 683.8604 null]
->> endobj
-1286 0 obj <<
-/D [1276 0 R /XYZ 56.6929 680.0765 null]
->> endobj
-1287 0 obj <<
-/D [1276 0 R /XYZ 56.6929 623.4385 null]
->> endobj
-1288 0 obj <<
-/D [1276 0 R /XYZ 56.6929 623.4385 null]
->> endobj
-1289 0 obj <<
-/D [1276 0 R /XYZ 56.6929 623.4385 null]
->> endobj
-1290 0 obj <<
-/D [1276 0 R /XYZ 56.6929 617.0603 null]
->> endobj
-1291 0 obj <<
-/D [1276 0 R /XYZ 56.6929 602.2957 null]
->> endobj
-1292 0 obj <<
-/D [1276 0 R /XYZ 56.6929 598.5118 null]
->> endobj
-1293 0 obj <<
-/D [1276 0 R /XYZ 56.6929 583.8071 null]
->> endobj
-1294 0 obj <<
-/D [1276 0 R /XYZ 56.6929 579.9633 null]
->> endobj
-1295 0 obj <<
-/D [1276 0 R /XYZ 56.6929 565.2586 null]
->> endobj
-1296 0 obj <<
-/D [1276 0 R /XYZ 56.6929 561.4149 null]
->> endobj
-1297 0 obj <<
-/D [1276 0 R /XYZ 56.6929 501.9076 null]
->> endobj
-1298 0 obj <<
-/D [1276 0 R /XYZ 56.6929 501.9076 null]
->> endobj
-1299 0 obj <<
-/D [1276 0 R /XYZ 56.6929 501.9076 null]
->> endobj
-1300 0 obj <<
-/D [1276 0 R /XYZ 56.6929 498.3987 null]
->> endobj
-1301 0 obj <<
-/D [1276 0 R /XYZ 56.6929 483.694 null]
->> endobj
-1302 0 obj <<
-/D [1276 0 R /XYZ 56.6929 479.8502 null]
->> endobj
-1303 0 obj <<
-/D [1276 0 R /XYZ 56.6929 465.0856 null]
->> endobj
-1304 0 obj <<
-/D [1276 0 R /XYZ 56.6929 461.3017 null]
->> endobj
-1305 0 obj <<
-/D [1276 0 R /XYZ 56.6929 446.5371 null]
->> endobj
-1306 0 obj <<
-/D [1276 0 R /XYZ 56.6929 442.7532 null]
->> endobj
-1307 0 obj <<
-/D [1276 0 R /XYZ 56.6929 386.1153 null]
->> endobj
-1308 0 obj <<
-/D [1276 0 R /XYZ 56.6929 386.1153 null]
->> endobj
-1309 0 obj <<
-/D [1276 0 R /XYZ 56.6929 386.1153 null]
->> endobj
-1310 0 obj <<
-/D [1276 0 R /XYZ 56.6929 379.7371 null]
->> endobj
-1311 0 obj <<
-/D [1276 0 R /XYZ 56.6929 355.6674 null]
->> endobj
-1312 0 obj <<
-/D [1276 0 R /XYZ 56.6929 349.2334 null]
->> endobj
-1313 0 obj <<
-/D [1276 0 R /XYZ 56.6929 334.5287 null]
->> endobj
-1314 0 obj <<
-/D [1276 0 R /XYZ 56.6929 330.6849 null]
->> endobj
-1315 0 obj <<
-/D [1276 0 R /XYZ 56.6929 315.9203 null]
->> endobj
-1316 0 obj <<
-/D [1276 0 R /XYZ 56.6929 312.1364 null]
->> endobj
-1317 0 obj <<
-/D [1276 0 R /XYZ 56.6929 297.3719 null]
->> endobj
-1318 0 obj <<
-/D [1276 0 R /XYZ 56.6929 293.5879 null]
->> endobj
-1319 0 obj <<
-/D [1276 0 R /XYZ 56.6929 269.5182 null]
->> endobj
-1320 0 obj <<
-/D [1276 0 R /XYZ 56.6929 263.0843 null]
->> endobj
-1321 0 obj <<
-/D [1276 0 R /XYZ 56.6929 203.5771 null]
->> endobj
-1322 0 obj <<
-/D [1276 0 R /XYZ 56.6929 203.5771 null]
->> endobj
-1323 0 obj <<
-/D [1276 0 R /XYZ 56.6929 203.5771 null]
->> endobj
-1324 0 obj <<
-/D [1276 0 R /XYZ 56.6929 200.0681 null]
->> endobj
-582 0 obj <<
-/D [1276 0 R /XYZ 56.6929 159.3692 null]
->> endobj
-1325 0 obj <<
-/D [1276 0 R /XYZ 56.6929 131.475 null]
->> endobj
-1275 0 obj <<
-/Font << /F62 634 0 R /F43 600 0 R /F56 618 0 R /F42 597 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1328 0 obj <<
-/Length 550
-/Filter /FlateDecode
->>
-stream
-xÚ¥S]oÚ0}ϯðÛ‚´xן±÷ cT0ȤM”i-4 šº_?;†4´t{˜òbû~œsÏ=!ÌG˜æ(Ô ¥;Љ<rÌ NIA7«Ÿx>IŠ4Ö’J”Üvz) J”l—~4›Å“áø[/ ü÷pzÄ‹^Jm̆$øýqÿz<Í£Ùçï®èD“¡»,¾ŽFñ"‰×y Ç“‘I!½UråÅIK»;f9ÿô–+@[3ᕘi%Ð/sL´¦hçqÁ°àŒ^
-oá}iv¢Mé%©SX(^ЊSDÖBÐ3±„Æ’QæÄ2*°^@ÀH4­ï³½rX¦‡]öPWG7å¡vÇþØèbævÝ9f\6Ý °&ºi;Ïn³}öfÕ›˜ÿÇöŸ“Ü@¬³|Â4¦¡Pm+ ¼$«—ˆD
-UÈÄæpb<EAøë‡­=È®H]Æ’c­Ì2›ª÷®f¶>®(*6yýû¬“ðû<ý‘Õ.ã:?Ø*ÂýAùø´Ïïîk‹‚Hh,À¹²6p‹M>áü€bc}ã”NÞ1̪„b
-endobj
-1327 0 obj <<
-/Type /Page
-/Contents 1328 0 R
-/Resources 1326 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1335 0 R
->> endobj
-1329 0 obj <<
-/D [1327 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-586 0 obj <<
-/D [1327 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1330 0 obj <<
-/D [1327 0 R /XYZ 85.0394 752.4085 null]
->> endobj
-1331 0 obj <<
-/D [1327 0 R /XYZ 85.0394 717.7086 null]
->> endobj
-1332 0 obj <<
-/D [1327 0 R /XYZ 85.0394 717.7086 null]
->> endobj
-1333 0 obj <<
-/D [1327 0 R /XYZ 85.0394 717.7086 null]
->> endobj
-1334 0 obj <<
-/D [1327 0 R /XYZ 85.0394 717.7086 null]
->> endobj
-1326 0 obj <<
-/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F14 608 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-875 0 obj
-[590 0 R /Fit]
-endobj
-1336 0 obj <<
-/Type /Encoding
-/Differences [ 0 /.notdef 1/dotaccent/fi/fl/fraction/hungarumlaut/Lslash/lslash/ogonek/ring 10/.notdef 11/breve/minus 13/.notdef 14/Zcaron/zcaron/caron/dotlessi/dotlessj/ff/ffi/ffl/notequal/infinity/lessequal/greaterequal/partialdiff/summation/product/pi/grave/quotesingle/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde 127/.notdef 128/Euro/integral/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl/circumflex/perthousand/Scaron/guilsinglleft/OE/Omega/radical/approxequal 144/.notdef 147/quotedblleft/quotedblright/bullet/endash/emdash/tilde/trademark/scaron/guilsinglright/oe/Delta/lozenge/Ydieresis 160/.notdef 161/exclamdown/cent/sterling/currency/yen/brokenbar/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]
->> endobj
-1180 0 obj <<
-/Length1 1628
-/Length2 8040
-/Length3 532
-/Length 8905
-/Filter /FlateDecode
->>
-stream
-xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä0 00Ì ÝÝÝÝ’‚R"‚´t ÒÈ‹>ïÞûüž³?³?½¿w¾Ìÿ^×Z׺î7¶‡Œ5Ü
-¬‡¹rðpr‹ t´P(ÐWç…C­fL9g0ЇÉ]Á¢
-Äü{fXE
-0Üú÷äè¹aÖÃöOÃoäæìüØã?ûÿxýœÿŒ=ì a.ÌÁAb¡ö™9Y® Ä£ò/z{xœ*Þè—ÖÁ»2#×Dj,ïêÃ8›ÇEµyÍî;Ýoª²n öA™ºÓÁß‹(üèX>ã.3v±ms™W`gÅúϨ¯"›
-rn­êèš—ß¡RŽwð9£_²Ò¹Ð_8=óe4%v>oFÀk(Ù?`LÙ½¼`êú4ð±ûåÃ&9[~ƒ˜;26cLà«|r)Sƒj…×Íl(ßÛ
-b¬Å7ÎßÊçÏVð™h9Žù,¢I‚°RÊ• e®äß·RÆ%=²ìÙ êt›œ(†Ì%³LÇî)®Ž>1Ù¥‘„µ…^Ñ2¼éˆO£Ý %õ‰>•pjÕr{2–ÂwÍ<–g¬™-j—!3cäáakIè,AŒ$ÁLˆÇÆ‹J¯³nöùU»Ïm›Þ‰D3
-~"Å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óöíØœÇŒP~^z•çQ•7˜¿\扯â ÈÛ.|âùúÁèéá™
-¸È÷»Œ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ê
-uÿ'¢µ?s_¯Ð‡öÿŠ˜'u
-BêH—‚?ý
-$OíœàÅ€DÈ
-¶_O®ð -¡;…®u§uªºXÄ[AŒù××¼^L¹ê=_󱑵ħŠfJ—äÌ;7œ1¾,`_q”¾´9›Œx•±tþ”
->C{(©¼Ê°nwð,K ?EÚ7þBq&‚´”jɸˆ·?è¦ú-ŸCØüƒ%¥uXcýøââBïÅ ´;ÁµÜ3höŬ ¶÷Ét(‡„šœì :î´cØ¢>:ƒ‚¯úò‚#ÑǤ_VItSÏ$ëŽ`ø~"ÔܲÜr$ŒU–Y7÷“ø?¢ê¹iâ¯ÉqÅõãÏØISª5ñ4Â…èÑb“EÝêÑÑn›p³ú†-.ä‰ìošå•Hû~B»ÎÂî‚T§Z§Ï_)©OqÓzèß÷>ë˜Ê;­dpI¡rr1ÛA
-öÝPî2Pw]¶u¢èúä»(£ý/޾ªˆ§þßÜ¿~&æ[1¸Aé-KžÚEО5JÃ÷.føzßwi°h“bLñB³ß6ˆ
-ÃÐÙ²¶©HÈ  9^©;¢Ìœp»Ãm%{r7E•€ÏŒµÂE±…ʨ*o,„ó QÞúʭ䦀(ô$íªy{Çgk9©‘5Â1ª0Û˜F3ŒÛ!s0¸4XàŠú#r¥Æ2á\8nqå°Ãs}䮀„s–è5)q…i¹C9ad¼¿`u ^<‰2@´ÄR­×$âÆ³—xº>áÈïž¡wdª‡}Té†×ÎÂËõ€Èøt\1Ü~‚9 ÿ½8ia D9©ì"Ð!gÑßqÝ ùA“ׯøŠ
-»]‚ÄÙªAÓ8ﯙÎd@Iî?_ɽŽbÎJÊ8&1ß’bçy·ÌJü®J_ƒ|¡iïÂC®¡L;¡Æ–=x8"ÆÝù\šGd'—®®ðÖ/B¿ÝÞpRÆ'µsñX'MÂÁd;ŸäÕEûtGmý«†g¾ ¿¨öùWí},¾Ï†Ä›tÓk„fªõžÑ »›&oô/L¿ÇGìü²•âBZmÎOw݉Úñ¼>–¶ü^ÝvšÉŽHk6Œ´­¶DM0¦›}Öda'¨šßo·é˾xWp¼311ïçdϘ9óÅ­Ô§?¯jò>*§¨¦‰Ð:’-+X}7¿$ÏL\œö¦nD™ðì¡ÉX˜vWŠñ=mç¡|'M}„ç‹çÄ_’øÏ£÷rci%Åës܃ ¨ÄÏ,n±±ˆ" 5Ù½6ìÉ6úQèÒõmެöó–à+q®Æ¾ùÃ$ô|Òî]¾öÒñÕäË&æèñ²€Õ„KfVº”DfƒŒåZóbúä`#öZ·<Ò_Ç÷-¦ªÏôª
-_˜lg˜¨Î>«ŠTÂ70¡ðW~—ÛC!<ZüòþÅ#(·3¨bæ:ߨn¢Œè½Ù$ÞÄ‘Îf;®Ì*=ËnÙ†b…ƒ´ÂVE¼Á<öuBgˆÿׯxî×_ò­Ìz—XˆÖ`©Ö4siÝÏAí+<¾ŸãÁE.Q˜ÒQqúÖDõ”ÏÓ$`dlÚ/BŒñY<xŽ%Á„+{æÔ¢´®³N‡­”TøTõ”V3Tj+"}âžÂr}©Xž\L$ÓÇÈš÷ŽEh®Š-xù
->_ŽÎr¦x‰|„ŠúNx‡<7M–/&×gaÅj[²Ë±‹4—À¤ÀÖO–|¾1_JSw{ðÐıDÃP~Ü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>è.<Sâ¢éX3p7«Á~ª"럽Ÿ“lË´ÍÔDQÿfŒ°Ì
-*s"}Y ;Ò‰¢ú{YÌÝÇí]p¶Òݯ€޶Xo³êÙ}
-endobj
-1181 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 67
-/LastChar 85
-/Widths 1337 0 R
-/BaseFont /SPHEIW+URWPalladioL-Bold-Slant_167
-/FontDescriptor 1179 0 R
->> endobj
-1179 0 obj <<
-/Ascent 708
-/CapHeight 672
-/Descent -266
-/FontName /SPHEIW+URWPalladioL-Bold-Slant_167
-/ItalicAngle -9
-/StemV 123
-/XHeight 471
-/FontBBox [-152 -301 1000 935]
-/Flags 4
-/CharSet (/C/D/E/H/I/O/R/S/T/U)
-/FontFile 1180 0 R
->> endobj
-1337 0 obj
-[722 833 611 0 0 833 389 0 0 0 0 0 833 0 0 722 611 667 778 ]
-endobj
-979 0 obj <<
-/Length1 1608
-/Length2 6751
-/Length3 532
-/Length 7596
-/Filter /FlateDecode
->>
-stream
-xÚítuTÔíÖ6Ò’J Cw·ô€ 
-3 383´t‡ ”´„ÒÝ ÒÒ-%)!)ˆä‡>ï9ç]Ïwþzßó×·¾YkÖúí¸¯}í}íûfg1
- €RRRDì
-fgp™™róòòýËó;`ãþÈÍI4Ìà¸ùp‘NŽPæâ|…0öP€- ¨è<ÖÒÓ
-ö‡†3†°û>
-jg‚À¡hô Ì öïéü«OÀëÞÚÉ îþç4òOÖ?9À0h(ÜV€(|SŒ¹©mC þ^-„-
-Äé
-rÊ­4~Ÿå[‚lñI ]’*|vQ$P5(}Uï>±åt¹ªÍ³ÖÓJçlI€îf2x±q·eÝçø(Á»æ/h•Kš´mé¹7®³ˆk..ôhí뀡‘UÎãàGÁÞOn_6—,_ª'Nw¼Áo+¢©É«°(ʲ·¶9b¿ý<áììíîúÔrp»m•ž7=š]Æ—”#Â÷E:½‚¹I¡ç+›`lgI\kp› —ÈüôMõ¢À|ƒ°²
-œ…›±Ø§Ï«Fc³}m½}ä®V‡6Gr\> "KªYIó½1Ÿ·²Ÿ÷9Qg††1„K<O›ÎQî,,ÿxtä’3¹ÂtÐ#¦»è+Õ8+ìǤÈF¾‚¡Ëñê>¬”(æ33óÞ5±§Kí9uæêMæÅ¶¯’–÷O÷‘™÷Å㣛RðsZ1ÆŒ^&}ÐùQ íívRæXnúv†e ^êÛ¤J³T×_+'wßsšßÚ&ŽŸjUH§¹ÿ0Ä~QzNÂí#(êyžJéêAB¢]±\ꞚǼû¼Å‰#¢
-»øã}y{ꔣx$󙹕Ä7ì) –/ˆ„³Îé4»×c§zœïÈjYÔRy°©ûJæ—V‹V¦wß“ó ÚÞÆdêˆô÷Ô·³0øò…i°sOí?¡Ðd˜¹ò@ÏéÞcxL
-çÚ“9q93š¹“Ù10Îd6NÞ”QáW}Þi¢ioRŠäqY"ã¿› &Ù‹²'IU{ö+º#Phq"!Ô}q§t°<>J*KIý s]/wûW3´¡Îú㌜LgŒq~2Ê΃U.{òªÄþ²Ô²LPšPPn
-%5èëÖ,»;e9øüNŠ Y‘ vÅ—/<<vǨqA%EªŠ·Y
-GáÊCÚÅ*¼ä7/*§Åín‹+¤½oèg¼cèÿ jÇ7^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èž<p=i9: sPSk_A8ãÀ¯Ì4د¼#tH$Á›¥®k—f¿‡§7'2̃æä¢XañîÖ:ô”ä¦ò[ãDäfU½•Íß«š²íYóå/õ$´PìHK׋~(¢‹E÷I9)°I­4áüÕæ=©Œã5öVQìºÒ
-hY$7U3~ñ4päáÕLÔ
-U¿ÍChùLð(+G ÞNÒ±˜¸å yB{v€SÐjñpÅʦDÀú´ÐFˆå¬ÞõËþÝýKxŠ|¢[ô‘tU¯™ÞUgkÿ*C‰wt{® Áå;»ïöøÍªÍ%ç‚Ý'×k®DzÓ ±ri;Ìi/[ˆ?–¡zí¾ï‡÷$ƵèÜi“¤Ï+õÎqM­ÆJ:¯V£#NWßÕ}èõ˜{¤lŽ­.NPGIÀ}5ÙéŸ8rè“2–î±"`ÅîpMûspÏ~ÉŸr Õ[âÜ+\øv»•èkIʦEæÑØ./îœN3ÅEÒlÜ9‡f²AÊ“!ü¢µö<qÕ§>›¹Jjÿ˜¸{…öÚ1U÷¼05§lî¸:—ŠÕ­¸”ä&öƒÝ]Ôßû%gÀŠ%ÉëO¶LK¹]ŠT”I¹eÓõ–FAh]A·Ã/@Ú>Pw"d:¹.ë”19M¦àÑ£ðs?Ù¢––~§wøÆÌ°£_ÙV ŽÏ^¯ÓåÝ_ì#ê97¸›6!”UñuŠÞE(ÚÃkj't…×É¿è9ÑSLy¥Ïyîqk·s»ùµ¾Á’yˆFQù¤ [Üëĉåûæ‘>s\N«:òܵ„Ø™³=7ZQØ··B¿gð*ù&¯½Œ}^&¾óDžgçµ|ÿODKoââÕ¯Oþƒ¤£j¤óÅʬ~Ö³Œ_ñådNT_/üd¥×’ÙH*$hç¤2/û-0Òó)Ëÿ ¸’(4æd‰nÿœLõIÊ=·ŠQª¢|kA89Ç»=¯°ãá>kŠv3ROn&Àñ‰ô9DÖ<}£º‚P³Õœ2~„û¸¶wÑ·Q±@HfÝÑ=RUˆ`¹”~k+³x˜’x·Š}Ì;a—r‘­2`å-Å0{ªÎ817™†Ý€)2hô»}hïë õÔÚ+W/5¼zæÖm(³ìxÿ›tŽú9B*«tË[p{•¾ò3\>ŽJï,ä6>à•ð좒
-É7)¬G»ýØÑ±†ùÛ#3/éµåhÈM
-Z²Û¢: äL²%T1ãͨ—¥^‹?BAI_ì¹øŠ\3& …§Í-0ÙySЍW³4¬«·;çæ±û«ˆk U,~уûáNp¾÷Uê¶]RÏìŒ{g|õóÒî8,-’-ë÷síKiØíÒ_zQP¢Y§Ï>3Y«ËÍgAg(æ)„ºkß-µE¤çÂuЍémº.?}&í;!æ&B)ž(;H…uz\J.‡”é²ìQ·óˬŸÑËM:Û{gjÜt|ï¦Öz½ÚŒyfE.:ð“+ÿŠ~z=ŽóJñ¼Á@ÔHÈ:Âû¬º,À:¶ìâ5ôê ¾]؇ðI[í2ñêá×n­Þ/5mêÉ«¸¿-Êä’8\ëã“ãÌȺ)ÓIsN ~{ØE§Ÿ)n[,÷Úix„Ci?éÍÿ)ãTâëu|SÃ5^¦V²…÷èû ü¨HÖ°GîxWÖ"/‹Uí®lF³“ƒ™¨Îý@ÝZ{¤ë;!‘› ±À]¾dOÉ›ñ«²àýa0ØÇ««â}£@Ýä§oºtÍJF:ܺ²8Ê^œ1‘ûl§ªæEéRûošD?÷®=¼»=ÓX#ô
-]‹g<V³-£¦ŒrœBBÅ–ù°\DÍ`>kh ¢.@3‰\§NýVró²C#Ô?Ö¿`죋žÚªJò‘
-ê§›qÚüw…£·ñb
-Ðj¥×‰"̨"Œ 'ËÑ7úׯ‡Ø:W¼¤Fü¤H®b¹j†CV¿UÜLzßìÕ‡OSS\W$?KÍX uçP(îVš#ÒîøÇÌv¶×{ª'Z‰=ìx©oïUë*^„Í›Ú\^OiJdXÜÛÖoQy>lÞ)ˆöó(ÏXäãè÷[nÔGÑ‹®ÝWèq±ÎÿÍ‹³n/²1EÅlæqéF0Ÿ‚õ—¦ìk#BÕibÅÓ‰h>ª
-ʃsdLðén4r¼™¼ Á=äÖ<º<@Úúšg×Ê¶ÉÆ‘*<ã# bowP›$ÖÌç»ÂËlöh¼ŸrevVMRMÐ8t=jÀhqí»±¼bG P¹Cú•32°AöÍf»ïQ)‰•5W¤¹¶ÙŽà×¾€ ½>î‚ÒäÔC.ýR÷f‰9sï,çë„ : ~±+2ö$5è)ª8vM_wç¾Äè>ÉJˆûNn‚”ëäkƒãÀb6²F=kJÿÃÉ%1%c”oYfðkxÒ¶ZzhÛ~¡bÈÚô‘­’ó͈7VÒ®Óìç¢j0·Š«qW;éKsF‡·ÚZ;25߆o›2ÜKÉMšyh|µµÞ ˜{JæÀT\]·B/âfÇ@xP™‡ò|d1£z†Žî›Seå]MtÞSø:WRÊ*ÊŽØ[cñŽð"àPE?îk'ÚÓÆêù²ŒHûÀ#²²£×G®–®/5¿âiËÑÓP [ñ¹Û?1ðßÁm“·»×@ks)j[Q¡1bD"¯‹[kbî%Ö”àbéÞ¾ÄLwðžî–“écʽ¾ÍÝÉÈQî"å$×3Ѓuq²wžõ$GM³þßviJ¾ÔË×d=5g»S–¦þÃsÒ;êiYŽÃý…Rnä®&nÇô;\·ªLÙqÄü˜²Ir™˜íµ½5e¶f""Áµj£èÓÒãdÂFÆ×˜)ûó§¸ïôeQ™²ÏºùH{u׎ÈzÝsš…0æ=q<¨œ\¤Z©ÇûR‡\¾óc;™)‚ƒpt`õV«c‚pãøf“€60±‚]%]çtv…~ýͨ‚¢$ÙÔpœSõÃÐÍéóÂ7mgíq‚2ì¹yßÚ±œL“­ªr ªÁ~y³Û †o¼ú îå~ácìðdùÊöæÕ«“B¨U/‡¬S¬è =g×
-v
-Åõn`ÑSd)-Š…ÕY¤Ch§ÕÍt%-‡ÃÊ
-ãFaàÁHœ1a™ŒƒÍ°.Ç®üØí*¹Ô0y‰FÝ
-Ï6Ý_Uô]#ó±ä
-ŠŽt39‡nßh˜ã ÀÑ0½1¢| =FL§d’æsÙ_Ù£“-"¦‹Ï*³8/©h…—¨ÃçäLrÏ¢·rb¥{›±\&®¼ jÌ I_¾l‰Ï¯ÔB² 2Ýݪ'Þô\E–j“Ðò͈?Kåd—¡·–Î#·È÷!t%)G¬”–Ò¼çF–ß?ϸˆ¼'ùY3{Ä&v(£ÑÅòÌïPA¨¦,‹vä@)!~®RìõôÉ7ЙF®è”{¸ûäº2™ vFéä9"¹nqx§Ä 4þ5;G\tHê!2ìM)­Ä‚E,vµæ-ô¿üý€ÿ'
-ƒt´F='ú?ö-žKendstream
-endobj
-980 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 36
-/LastChar 121
-/Widths 1338 0 R
-/BaseFont /GEALIJ+NimbusSanL-Bold
-/FontDescriptor 978 0 R
->> endobj
-978 0 obj <<
-/Ascent 722
-/CapHeight 722
-/Descent -217
-/FontName /GEALIJ+NimbusSanL-Bold
-/ItalicAngle 0
-/StemV 141
-/XHeight 532
-/FontBBox [-173 -307 1003 949]
-/Flags 4
-/CharSet (/dollar/hyphen/C/D/E/G/I/L/N/O/R/U/a/c/d/e/f/g/i/l/n/o/p/q/r/s/t/u/y)
-/FontFile 979 0 R
->> endobj
-1338 0 obj
-[556 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 722 722 667 0 778 0 278 0 0 611 0 722 778 0 0 722 0 0 722 0 0 0 0 0 0 0 0 0 0 0 556 0 556 611 556 333 611 0 278 0 0 278 0 611 611 611 611 389 556 333 611 0 0 0 556 ]
-endobj
-847 0 obj <<
-/Length1 1166
-/Length2 7568
-/Length3 544
-/Length 8381
-/Filter /FlateDecode
->>
-stream
-xÚízU\›Ûömq§Å‚+(îZ(ÅŠ $8Å -îÖâîRÜÝŠ(ZŠC ”â.åÒ½ÿûì{ö9÷é¾ÝßM¾µæ˜ß˜sŽ5ÖÛÇʨ©Ã- v´„<s„»póñ
- —{\×Ö B
-¿‡­\ pW''Ö† ]V¤Àú¾³ÿ¬
-wtòD@ml]
-$Ôx|¿pƒÀ~Wº§P‚À!ˆû¦Á¿s5­AŠ`¨Ëïqì¶..Nb¼¼NÖ È}Œi͇¸ðrÜ7ªË;:ü&@âþÖLŠ€XÝåÉûOÝìáŽîpïÿ[Cáà?F»:ñêÁ¡Î®ç
-ÿ“|Âý;fqù¢@~
-ññþßßáòñÀP+€%Äæþþf¿C¬ÿÜ«\PÀK È
-ï]sÿàû¯–ú7ü¿ëŸ5ž¹Â`¨Âþ§€{=
-w~ÆÑJüµÝ‡×­U²4îÜ›cO{„ôÎî\p#a(ë<¨Ýê”öÅ4Ù§"‰é
-šÃ¶R/ÑÔÐPBbh#…ÝíEåÚx°ˆI‚‰Q•C©wyj$ÔÅð°ÙÇ=Ô±”É™ÛòžýÊûŒ¥gF¬Rò£Ä:!Žd~tÆß·œ50ièKsËq4¶f8Dɯ÷4”a¾Zb˜SCí
-@»À7Éx*õ—l*Æxõ»ç$åmÄÓ3½r‚~S!J¸.,iŒŠ…ÅÚG;ø¯lKZ¬¯ª†œrUžš:-<éË„×ÏÚ~¯‹˜oå²÷%ÂŒï+Š´ÅCÄ,S%­7 VH0“"ü/:æúñdõ´l¨2ÔÚ”OOkžÑ÷¨¸‘>_©QÓë ×F™3LÀÉ›l´¨WuÎõÚŽ dc×{¾j‡Cëš}Ú$<<® åß5‰r:x °¶ ø'Ç|î†Ô0ˆ“jj?sSª\ Ow“®ØhF §‰èÙî½ì0Ôíö8\Q2±Ø’úüTñqø&/_]4ç –@”·¯ÎÔ[Þúxù¶’-_å³-
-Ÿw?P®œÓ3ñbO©µtª•‰•R"½ …zK¶Mç”|²²z”®¢æbÓÀ^:*ÌÑ)ª!v×¥^x4ÆðÔ\ý¯ ³[¹i½ZJ¬ïÐÄð ©žñVóàãœëÇ  =£›çf¶=Vtg@ù4I,Ô¬}®.ôéEkÚBÎ>¨<>§I®8Ô›jßhC&˜¶)#tðÍåm†ßÛSõ—]sÔæ­NÐ@M?Û¬ëK*¼ò@Ö‚ã•ü—­J{¢ÖþôOæéá+k›¿|Yß^JJ©ó§}cšP«xµ¦_dâåËÅ~{sR˜ƒýÑ| ?S<QN‰ç‹„·äèí°þÝŠ¸Ð‚nºZ¿O‘;'/’“lÉÆ”Ÿ¸;r@o}œÌÎÝû””ˆ³eC˜s8y6H™d5øaÌØ¦|mçûÕma¹”Æ#87½“Ff»Sφäö
-P‰®|Z‰ÆBÒõ:ð}ûK\|?T<©ánÒÅ_[ Œå:ÓM[Hn¹<ø"—V<hUÏ!‹¬KPÐû®dØ£5?¬ë=j VþŠÓáw4Q]ºËY±I@ÉÙVó·Ÿms0hë„;f&u5R–Y‰—‘6ºÅEÍW²ÿñO´9-èjÙ¤ýÆ…t1SB€P I”†j)y
-%;³}«Õ!ù˜R"ÑãMä“´Þ¥O,7-32ŠGbG#á–ôüΖX‚C]´ŒÖ#iý?uŒ£ž
-Ìxª1”)‘>Æc¢ˆ2¤ ¯ Qž¸õ ©4mO¸6u˜¸9[ØŸTq®@۪РMMØi#r™±§žÉ!ÐrtèõGÓŧvsíõ>8­¡ gGÅP0Ynˆb쟣z]¢xÍ"ÍH´äX<öLfòú"Uγ",,Dø¶ÊúUåÉδæÎt š˜¼:Þuß½‘°¸[®]汎  çÒ0@ˆFÚ<‹ëŒœ^PéxѼ¹²±k°0íî|È–&, &£$ô'ÙfÒ§m2WHéfÜßùVGºH8Ci¦cZW‹/)R#ĵ¤1ôíA›ì:žþ\4wmIεGcØh‚çôÖ8(ôòã|¿DÍp)B:[™LjÔ¡pkTÀFÕUNšÍéü†Î –kP‘U '#Ëz9b„œ/E7[èÛ‹(VÚÅ%ÑH‘R'Gj½ÞXsÇ=io"I&ñ£”8`ÅFјúϋֱ(Aé3úè:È‚ýÖä†9kévˆØ8Í+{U˜NEsS9¬)ÓUâ•/´›vU`c¦jVb¬+64¡…#ò†å®m§gôXj0F§ÎNÑvÚï«Jí8?|ü Ñl[]טf~@Í­RÐdíyS²øÂç€ê
-•0ž²Ü™÷.U:„{&û¤?xJ›ZTHHô\¼2Q¼y¹EÆPÔ‰ãÓþʘ¥éµX²›æ(m
-7sïTîT Ò­_2æ%~Ä©kÖÜ3Œ: ZGíÞ•–sœ ±óéš(cœe¬2X.3¹qo"â}-ÂßȃϬò…¸`%v—ºþB’´ªL0Õ†çöõ7¼ /Áó²ª0–ÜçŸiq.ítðÅ…º1w¢s:ÜÍLË »D\h1qYÇÑ‹ ÚÞ4€k¾—!7_S ϘV?“¼#p}í>ãß)BO&´ƒrƒË7Ÿ)¡&Ô&²Ëõåuv/ÑÅÅkéWŒeoG2¤(RôºlÛ¿²Ø2Kn¥*ƒ9Õ Bžõ¼×¶©x¤ŸßUû=œ•p#úŸN&“p÷Iƒ;ï»Dk Cá!aºÝÍ$ŠÞó5Í(BIÉñÏ8¾·ä¨¶Ëy}'œúÊi"º¬Z>‡+Øv®Ç¯‚ÊEM­Ñ±¹EEª¬%ÅŠ†Q¢ UÊÒÒ‹èÓ…^%T‹ç¾Ð¨fýf¨³Œ1ùVGA«@`ÇJ–‹ßÓE T²‡äzR…¨ro-nùŸwódËÍ æ“•¼“Õ-ˆ–÷Œ¼F“TåŒ{*éöFA×r GœWçÐÛ2 ¹xiaq :Oê.«<U6i9#ñæS‹» "W»ú€FŸ¡’:fZän†äŸ®cŒk˜údªl†­;¡†Ñµ{xµ 8XWuMÚÔ$Ï™œ´ã¸âoMN®2ž3MS”:]}:¨Ê~ב—L|årýJrtp¢1½ð« O/¾4HÝÝ_ñ—Õj<ª]h£¬µëHø£˜¨ŠE~u‹ZEýÓtÀ
-ʉŸ¸Ã¾ÌܳBÑ'ŒVÞ¥‚½ þ¾øECÉunŠ”|Q!RsÍÅ~bP˜œ¢ÊÁ]UQÿî Ãý^-“@E ÐÉËwÆ%R£1ù³*õͨ”²u)ˉ}šˆÐ"îž²u0”iJ%JÓqc^GÝrTâÅ£YTìo­N½æBµ'¦Àүʶ­®4ïü˜ÔД’Ÿ¡_(ó¥ƒIòœÖüŸú¾[ ‹O³(Áûc3‚á(&™a—`.qÓm·]ðS\ÞÁãlòX'Æ0eSË« ¿µ
-'ÞÁÝ%·TœnKMõòw-V×§ª¯ß‰”s[¶Û½åÕµý9ÜŠÆ2v‡z¸
-ØF”oýBtM®',ql|J
-S&WÑ-‹Qc”ɰ¯ˆ"㱨¬:¹ïÁ2ØV·l°!r!¼Ô™ÖG§¡d7çâ"Ù1$–õDÇ\[ÓjøQxg]õ^áˆZ=fÑJ¹£ Qð${÷­û"Ýз+ü„VpHÒ‚ûìbäÿÊCÔVpÒz~)oôã\<£vö¥›Œ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ö
-kEtº›‹b
-r“ƒá?ÄwÍÏŠo>ò¯”)<jìò˜¸ )÷‹pÑG¹ØŒ‹Nœ3»n·îkÌ¡°øDu¦…¡ÎºT¤ ˆ|d›LN}45A[“bœFŒ^&±ñ,äQ~«Æ‰L2rrdw="á!·‹ÃšK}|‘·puù5aƃ‰ý5Á2:–5êÆqÕ{ 2wˆ²#}@‰—±Âøö@‡OüŒå ¸ ô-){’TòkàbTŠx^ÖRØJ%~tÒ^©¡ýå¦ s›ç0?&%Ÿð—ÔœžFSõÑDóhd±.wvV€Ç›ËMl=įRÂÙçûõ—§4”\q¡É Ë”Éˈ|iöò9øÖÝ+׺doç3îùµà·æÆ›T<Î *‘žåÏFÊ™ÇUvÈÄJ3y’?È(6è?ñ3ÛdÊO³+—Csuî“æ>pxÏfã0Ô­X®fÚSm± ú$²î‰5·¬¼ë_µÓ¡|ª?WÃKå‡Z+5@Ê"Ùèð_¼û²¼*j_´:¯y¹Ø-÷†Œêk-[)SüŽmЮØÞEÄê¬rê[S`–)¾™Ð‹ñ§WÏuò‘9 °w"3àŽÇFGôÞßgFÚÀBîÇ&×"CkjÃ?½®Èk@™¹É&ŒÇä[ûcI2™§
-]ª>úÀ”¤þÛE1Ûyô½Iåjë$aÐDx!}2ŠÍrÇ`úZL’F—­àí¯–0±—t?{G ˆ¦õ^ðª¢Þ¡ P|1; p]cÔ£_¼þ~ÌKÞ~å¹’%^§Èüq„ñ3¸Ä´³Æ…Ï­VÅo£õ‰Áƒ—8H˜-ߥ5ZÛ‘ÎÙš#žü]“n4˜t=‹ “ôÁ[Jï((ñ˜|Õî~úÔ&¶µ=Oèå wx°üOßTû>zÚÆ˜ÆñTņÊí‡Ç Ï
-2U*¢
-endobj
-848 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 2
-/LastChar 148
-/Widths 1339 0 R
-/BaseFont /VLBJNQ+NimbusSanL-Regu
-/FontDescriptor 846 0 R
->> endobj
-846 0 obj <<
-/Ascent 712
-/CapHeight 712
-/Descent -213
-/FontName /VLBJNQ+NimbusSanL-Regu
-/ItalicAngle 0
-/StemV 85
-/XHeight 523
-/FontBBox [-174 -285 1001 953]
-/Flags 4
-/CharSet (/fi/quoteright/parenleft/parenright/comma/hyphen/period/zero/one/three/five/nine/semicolon/B/C/D/F/I/N/P/R/S/T/U/Y/quoteleft/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright)
-/FontFile 847 0 R
->> endobj
-1339 0 obj
-[500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 222 333 333 0 0 278 333 278 0 556 556 0 556 0 556 0 0 0 556 0 278 0 0 0 0 0 0 667 722 722 0 611 0 0 278 0 0 0 0 722 0 667 0 722 667 611 722 0 0 0 667 0 0 0 0 0 0 222 556 556 500 556 556 278 556 556 222 0 500 222 833 556 556 556 556 333 500 278 556 500 722 500 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 ]
-endobj
-784 0 obj <<
-/Length1 771
-/Length2 1151
-/Length3 532
-/Length 1712
-/Filter /FlateDecode
->>
-stream
-xÚíRkTSW‘ª¡¬òRIÕzX%2yj   b,Þ/‰¹7ä–ä^z¹¤D|PIU–EltÉST”
-«Š@} Ô«0|‘V†°©Z_sÁººJÎüš5çü9ûÛßÙû;ßÙ4HCaáP %&G‚¥R ‡ È3›M¡Ñ‚qXN "'`!à>`µV ¸+
-9
-¤rBkÈ
-¹È0z&©Õ`ýäL°΄ñ,bR8
-l„Ó”šÔ$A•à¿…!mÆ»TŒg’¢€×”L: EBªÖVRXk1²LjùoÈš^<T«V¯•k&ËO9õ—¼\ƒ¨õ¿30M†–€q Å G§Scá·â¤0„h5Ó³B®F"4M g%“½ò-Žd†":ŠD…
-(åêLx
-‡QhºÒ¿)¬8qB\¬Ìû÷¯JFÊ”ˆÒgÀ€ý{*æü“&áˆ$²™l6‡$’ûÝ)yZ31ªÀ M\žã¸\O!‡ˆŒxÀÀ
-Á:
-¿­Ÿî;½½6O\ÝuÌžž¹ÐtdkÇùm§L~Ìá>?—ëxÓOQðG¿9osþ9îT:ñ Ròú©§E9fƒŒµ­×ÙìèF¯Ü/›õP1œ”2ãry{Ûšƒ;îY[3š¼þìùìnÖyûú5÷9ü*êHÑÌÚ[7_=ÉKßÔÙoqøò*¥$—ŸY³ŽùçÝâ«°jÌRsy~Òþg®¯-Ô¶;=é·Mc¹Ôî†Éÿå6]§è¤p¤/¶Ä• VË„³ú\©0›ý=Lq-ÍÒ_gvÓƒ¦÷{$¹¥á±’èÑÇ*]µ Ôþa5T[¸¡-¡U€^,´6¬+pIoèâú—p2šöÒÖ§Ž¿¢ý¶dç̧É/^ô=c¤¶>T<lÜÖõö=˜åå=Lï`Sí¯}aöˆ—«¾ºGˆÃûVÛ5Èi“‚8Á|·›G¿ð´p)÷…ãš}“&xÛlÞ“$ÖÙâ/¡T=ú×¥VãnJhpb_êÙ¨[Þ—ë/T‡¸ÖÎL67‡†V/ižõÍ÷p]è7×I”dª]–‹=ºâªs9.¼‰ñEÇ…>{^ú ýTmn9â³(Ï~hË‚ô]ÌQË ¾¿Ú¨KÕwùÖ4ÿ8oÙ>(*‡±n_úñÚˆÚíýcÁœ½Ç 8v9瞊šP–ãÅ Þ+bÓ³åôvÚ†+u §âÈU©L<>ðlkŠ£Öã†,îÙO6ðü’Ò^÷Y¨Æ°{ÓÃÇ·V.Ú±"tèP3ÄŸ—æ½Ù:Ú¦up7w$ZÐ{ÇLw~ìGƒ[ÎrÖzúÇ}³4 •Zác«Ö1¸ÎÊ([ï]d;0AƒZª4un4ÈÍz9Hžæeq7K]¿—<uGÍ-Æí¡íð«“Õ¥1¬<kïªS>Äš±*!*[*9­^n3ãÎ̱'¥îÖgøæƒ×Âù» ÀÛ•‘ £•þw»'´ù®WFŠ:9³Bª”¾I”íM¯ÌÖëºæe7w—-pªÐ3¼¶žùÄð%÷«ÓƦÍ6óðµ’Hè;[UÇöë®WÃc5œ-±÷ùѸλ÷s‹VS©Ÿ¡Æ¥õcºýõáeÖþ£;/eGXh¾ëã^&.}mS?Ôa[žt˜+tiR45÷\¬*qü8FŒ—E(Úo§lY=,­o<±Ûaç*§¤{naˬ…;7ÿìöxY–¬òë„€óü‚¬˜s¡¼þÀ9ß{..VPJîÉ¡bqÍÁ´{âÞðœç?|
-endobj
-785 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1340 0 R
-/FirstChar 60
-/LastChar 62
-/Widths 1341 0 R
-/BaseFont /XEZXWS+CMMI10
-/FontDescriptor 783 0 R
->> endobj
-783 0 obj <<
-/Ascent 694
-/CapHeight 683
-/Descent -194
-/FontName /XEZXWS+CMMI10
-/ItalicAngle -14.04
-/StemV 72
-/XHeight 431
-/FontBBox [-32 -250 1048 750]
-/Flags 4
-/CharSet (/less/greater)
-/FontFile 784 0 R
->> endobj
-1341 0 obj
-[778 0 778 ]
-endobj
-1340 0 obj <<
-/Type /Encoding
-/Differences [ 0 /.notdef 60/less 61/.notdef 62/greater 63/.notdef]
->> endobj
-710 0 obj <<
-/Length1 1624
-/Length2 5655
-/Length3 532
-/Length 6501
-/Filter /FlateDecode
->>
-stream
-xÚíWgP“붦ˆH•Þ…€é½ÒA¤W„$$¡ƒô^¤)*½Ez¯
-"]št¥H“"Üè¾ûì3ûž_÷œ_wnf’ùÞ÷YëYåYßš »¾‘€aQGÀ1"‚²
-Ä@df0@ˆŠDdddˆ¹
-êàˆÜ114ãåç¿û×Í/€×ŸÖ u€¸±îéc°ÿkG#€q„
-
-µpÁbX2}ƒ¡ H
-…U÷÷›-úÏóï‡@<! âéO\ˆSzf¦Š>§÷ªeg»~o(²°Öøe~@¢Í?=bQ¦Ôö¢2T°nXöò­×Äòç—|«ýít0ž¶TÈN‹ßmÞŽ|Êyî&)þÕ !ëB²Œm³ŸÝ®YH
-›®.½30´.¸¸~k¸I uc÷„7à¶{~
-ä÷wvÇ«éRèJV¡e’ìr¼9ùₜô0˜"Än%Ÿ•MsÒºYìÎUBu¨9‡çͪ¸qæÍì}ÍlÓ} |e±ŸrºE©?G‚ü¯’ÍóEK0&•’O®&œ¾TÒ3©¢—]™7F=«Æo¬ÌS
-8O,llH?I76µTèXD œö³Sè.NwiçD8T¥2u¼ÁÏÔ ÈCiÂUЛAJéTH®gÜöI”1MëM`*o•æ¾ÐbÔõô©¹,V-u4ý†ýCÝÑUOKz‚—âÛë—ëÄä5~%šct]­§h¤²ÛNå¹öÿ Ûö’ñ?‰·ÏÊ*åI“y[qo.oZqO—f4!OòìC'=[b°ëL‡ \ö¬WK+õîI¢
-0…Ødgç•771ô|Ÿ¢‹y¾ÌõºbÓü–u0Æ_røªvùMc®ç¹ÃBÅ\n}HòýÇHyðîµ³p%Èuë@k+…–ß×ÏÔ\|©bû¬ç´ËOª?XçsË,[Õ©EWJaoD’ןÚªÙ‚(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ú<z/gÈlŠår¢g4t&*ÀD‘@(-=V›HÑü"§KÀF§kìqDœ4F—î>á‹ ï¶ù´eöä—ñsç•2´9µrœ%´5“Å%:ø”rBSÛÔ†Çàš¶/BÄ)¯o½ÑäNÜèÖ|ÂvthùL—XÿUš^ðöá÷FŽy
-ÀÛËÏ›ë"±¦­\E‚ñ<\þìa#®0G£Í¾ìÑž÷š¶˜œ ƧW3K2aØ•Ê/Õn$¦y½–î•Þç ùÊ1(µVÓ"bªùº©:¢OÃOò†Ÿ–Ű.(±Šb}ç”i¢Â˜¬ÿqî‡É{+_V®¸Ä´$¥¢P_[QeYjçWZo—¡ÀŠæUYþÇ»®i):q #ÏÙ@öN­³…sèw^—”ŠÖ¬®I)kæ¤Å‘s˲QMµd9^bU·ü½çw£
-÷oŽCÒ^ï'‰¶>ù
-ßX?zóä½ãÁÊñF—òû\𵿖­ÎÆ:Û}|í.Mœ“îL#Ø*ê>~CÊ<Æ“¸R芧æx ê2¾D0ùÜšãæ­Üh<U±n\n:K›øš`9X£9§K@Ø4½` ?‹x;˜" ’Lœùñb¯TíhSþºÖ©"/xý¹\ƒsûÈQÒZ#d¶(ùX@/ÍïŠ.jf#ÏÕùÕõŒ ƒÈ¸ÑD/ù $³s_H|óÔyû­æëä³ë*åµÛÞ!›…9KçdäÌó¸ñoÒ>—gIè0Û„^áÒ% ÃéRÃ~îïQñE¸È~R<™¯—ÆksRÜx¦õ4«œßg‰½V?^ `ÚÖݪ3G6PøAb+aDoU¯ïN—íhø h.Ó FPïÉÃàFñä"}†ü»Š— á º 㜒žêHÿG¯2‡Ä *e&è°Ôóå[CVÆk´ø“ìtùÊœo$ô‡ÄÓ¯­ûÐ< ¯Z ÁéEºð.œd¤˜]KȮ۰ūe«úž\¤Ã£ó.¥õ—ïæ :@Ú55,g|ßæö7úh;6XÄ/>¶"ynö#®¼QóÀ<³{5”–SÐ/8*У‹‹GO JøL©‚¼EzÆÄǪµR¥xÂ]åÁ½œÎ+ñ6ý§ƒ÷ÎÆ`bINÇQˆƒ›§ôý6†„øågÑåîp&Ã8”ËöaKÚdagØ[Ä~¢ÇS/e:¯|¯ñÞæ˜®¡»œY¶šÄÐLnc¶{ÂÏzõ/+åæ_9@irø˜crûó—?VpK[´Áúùp÷ãÌWâi{m¶ÝšÍš^¯ƒkBlïøôô¾ ™™úN‰¼·9˜¶Ë8ƒØdX'E?Šª!6œi<Á·
-MwY}6ŽûV¶Œ—n:÷ymO}€KQNUÁÆ®2¾)õ¼‘A”ɼÆÅ­…H?òês9úóØ‘)ª¦Ïý¥¼O8â­‰`ù£4ýÌÍͽ"/㬂ìÂ>ÂÇfSgL,D Ï\¤¶â2íÓ8MÇÇB3£[~„ûðü¡í)9ú{N»\˜"¯¬ê9AäÍÜBvLœ¿xa1ýÐÙ‡?¦•J§®2ˆÄ‹"]¥ø4wLôn´¼lûÚ¡ï§.|‚ ³®2èEs^Þ=ÒNQã·;\Ð2>“»ÕWlª”›
-ÉZI²L%g}W f±½‘¸»=ñLù’óZÛ‰×ެfž6‡û|vØz½¨ê¤Ù›«™œç«R};·C:)†æ½QßÈ›x» ¾ˆhQ ¤Ç¹Z&âþ±þ6(Õ†i”U·À·³•>ÖõðpÉúP9w1Oêë@Œ#Ú¢Ð\ÂH´èÅ“ˆ²]WúÔùýÁ—¨£ÐtGÓÑ{£ˆÜ
-/%É =Þ0g肞•/Š ³=K%äØï˜méð©_8êZr1OIE¯}}FºæÙ÷Qí0
-ÓKd÷5>£FÇíêN^)+&yä¬>Ki?bKÃþÂ5Ih\ðpX1„¦ ;ñ OÁµýËw•¢:ÙÔãoŽgX÷‘5XË2R²‹£ŸöŒ¼Ôö· ¾9ëȶÇ@‹këtÛ 6~lŠlÖúÊ›§29BÍÊS$ÔÑд¢Ý!œ_4ÿ’‹Ó§GÂXH×rcbé>U&tã”%…àJ6ì dÌ$V{
-ßѦ
-o>‡…~¼GYøüÈuQâ*³AÙŸK ¾ôµ‹«ñ–Å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;âÊ(â
-¥~-1ßÊ·Sí·ÃÔ:Ö©—JZFß”-¦ âJ²FDDµ©›¹â1ËîÓHâÌäÅÖÓ~ì†Þr·ÂCÅS#\iŸ5뫃OË=iåw—3v0|¯†FHFú®Q…k<Œ"X1Ë”vuÔ4–¼¶uèSŒöÀîÛ
-Ú#ÎÝÅ)šjÀMs¤ârruRb&l^5!Í¢W#
-¼RK·=Ž–ùóoú©G–c£m¨fk
-³Ÿ“öÐ^£²P¶yWmnÏÄÄT‹Ë^­ZïÚ]:Ê>9mTl´ô£i¥OäáàÑýlú ±Ê(À•ªûjÊ,µrAAx-fLjpŒ >¬ŽÐþÐ3ú¾3êÔ
-yîoÜlŒàã¹¶_ µ'Õ ÍO.׸µ6}¾Â£×˜^N!Ý´’»ÒvµA±çþð kOg
-Ówí2ëƒ'Î`p+p ¬ã™CÏ?dÃÉ!¸äëõé)§»Å8Ë÷Ó»nübçG®ú•u™€ùw¾jaŸKè\¨§*A䦢3$ÚˆåúŸád‡9ðÖB¶€Á5 ³m({ôTá{~·sF'[‹»zèêæ±Hží:¼“þ"2ÉaÊøàý´ƒ¸KðÒ‹,—‚aQú²¤þ+¿9PáÝÄúÈMU:‰b2Ù œÂ áÆ–€œÉ§mle,sm&,Võ£r—“Gf—nÇßí ¥ú2ÑÅu´SEÈŒÀKG9é ìT\?µì/8—ù
-—
-IÃ%¢§¸ÁMÏ­W[öÉ%ä¢*¿gš]T›®æÅÖX=„~íuÊÌ»Ñi©Xp ÓYÂaE´=pÃõ{ó­›ó޾™É"ö÷¥ F84ÒL”ÆÙžÌ[;ôé‹åŽ~ ¼ãl¸jä!@šjUâŸs5ÌÃO ‘Å7o­\)ÄÈ’±0øzi*‘ƒu[ä Ùxm3È!5œˆ £ x‚
-endobj
-711 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 46
-/LastChar 122
-/Widths 1342 0 R
-/BaseFont /BFFAIL+NimbusMonL-BoldObli
-/FontDescriptor 709 0 R
->> endobj
-709 0 obj <<
-/Ascent 624
-/CapHeight 552
-/Descent -126
-/FontName /BFFAIL+NimbusMonL-BoldObli
-/ItalicAngle -12
-/StemV 103
-/XHeight 439
-/FontBBox [-61 -278 840 871]
-/Flags 4
-/CharSet (/period/a/c/e/i/l/m/n/o/s/v/w/z)
-/FontFile 710 0 R
->> endobj
-1342 0 obj
-[600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 600 0 600 0 600 0 0 0 600 0 0 600 600 600 600 0 0 0 600 0 0 600 600 0 0 600 ]
-endobj
-702 0 obj <<
-/Length1 1630
-/Length2 8144
-/Length3 532
-/Length 9011
-/Filter /FlateDecode
->>
-stream
-xÚíwePœí²-î®Á Npww‡à>ÀÀ
-hàà
-ºÃ¡¿ŽpÊ!Õ×®ðŽdÚ©Û£ˆëIÌå1ñ:–¹M !LŸ+ÏS·×Ö:çñkÏñù È [œÒ¡±Tlü+Û¿-ë•øET×—mÚ<oR[¼Óf0ïw&±½‰2eé²G$QnXß´gÕíÂ_ÙM0¿³­Ë]ûÛv¢^íH•%Ü’(ª»Mðîïp[¸x³ŒÎ¶imæéú‡¿ë' Ú „ÔEÛ¬Ó]ö~!þãømý­g­Rj$¸¤g2¤’Ä¿ïßæBýôQ2í¡8¹ò*Ö!rEºg²Y颺.€ú¡Yœày¢f°‚mÆ™¹@aæt˺—X[Y¶˦’åA$o,çí„Ùš”ÜÝU—w3&´|!| — Ã8¸XÁ⨡
-µÚ4‹î§AmëÁ$‘u]žœ¢ ¤é{þé o)¯v­zÞ·þ°ŠÇ~”0†S¶_EÑä¿XA^Àe#Ì”ŒCš¹þvà§­
-ýƒ¹`Z¤†.,¡®Çsõ *haç"¿ñíéâ 2üE2î$ÏOt:Š« ŸÛ¨C™`öQÄ–ìëñçO¤¶"æ$:lþa8§}îsž©j“vå°yD±^¦ã z—FŽÝ†ˆ©DÏ®BcvgÖ5XØwχ,Ðiu–ŸòD~i|Ó²DR8T‘ð³ý@(åÚþ{7ŽvŽa±Ñz]|vJUånÖ7ý°z -’„Q¡¨o3mïønò¶ÿõò"±ë«Ä(,XFµÞ.¸qK0I4îÇîÄ{¾4{_(ÓLéfÉIˆ*aGÏ]¬]¬jaáv… õªø²!]J
-jEÅÖ*
-Ý–”èíC›ÇO/äÊBEQwÚüEšm˜§/ÞôRų#m ¨ŠçöØ
-o<sW,³âVݘ”43>Jªb¯-ûÏ¥š¯:ÜÒmSÂcòªÄòGµ›½d–ÝÒ±çfÐ ‡ï*7? Œø¹éݦÕáˆú»2œ; ä!X25#ÐjÓ¯*™Zðg‰æ²M¦Û&=N„¡#‰ñô¤—l.gýiŽõŒ'S"œ+€êæíFý=õ1¸nWQ5’F”ÕØ#Äù4]P³sÀ‚Y~ך4Á†Ç®~„ír ݯ¨¨è&K‹F¶òmis–rùÐe'¶“ná}%’,Rñ|ë,ã>aL¦CÁ!0Y1'Ü¥çýüª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Ä"} žŒ"Ô,®ÿØm<n^Ú¯™»F¾*õ’ÝB>o¸Ny\ém<
-~Ç€ŸFš[pcù¢3yŠ˜…Š\ØrJn‚Kµ ú‹ÙváçÔN_1oÞAM¤œ“*‘~à0sæQ@ÚtíÁ~Ȧ.ìó?–µçã’»ÿ˜ûnW¿ mC­åÚÅ‚¯•Rî“CùW&Þ„Ù-’ˆ»[—CxþѧgT`&1|ÑJã—1`~ PVƒs ÙÇ„ Ú)a4»ZÇ[X€ÆF¹”2‡;mS¢ª&ä GÅ*‚b˜Xõê¬ÌyÏë:°íMhÛÔÑÜ-¨‚Þ¦!anPÏÇ”díFÚüÚI·«³J 95ò«‹iYïIôÉúqËñú“=ŸÑÒ~±úMuk°¿„‡dbMTß\4 6ê:Úq-u.Á
-fežÜrßCï£Üvµ~~1«e¥#Zç»×ÍÀ n®hÆÎJ/_Rîd{!ÏԺǤò3ìóðæ÷`¹’„¾%1íc-qlÇÙ‚iW¶tc L{þÂÄkIcl1‡E5Ã6Ѭ 3€wXGZ´/dÖýÞ=“?Â5¨r!>Æh~X ¾2
-×IÙ.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ü
-|Ò‡ b9¢Ý—B”Óeß¡#Ï^+X¤½š^Ô€ã„R|ÿVöàÕâÞ¼ÒDNètúÁQµd¢L¤–²ž3TKâ³°Ñ.ëÚÑÕSÜO3†<—7?¿t—Æ<ôÆè¶?„^K”½û‰ßè€wºÌyÕ…O=ÑaÔ]:»4aNÚYW¦$ñX“S
-sÆ@es‘Xü>¹eéN!I±rÝ<¥ImÓávL^Vc°èé4%ÐvcŒ~ŽuŸÚ:æšÐ(^V©FšÉFÊ„5¦@w:¤ªO!¸Ò:¨M„Páüòonñ=¹/ )‰=D¬™‘x™( ;o•94‡Í‚¹m.Ïÿ&yj:f•…
-ã¯ç´½y5âC̆7’gj óÄâ|ÈÂÚÔ¤à¤ò„[ZÓôÁûòúêFù³‚V"vÏ[´¯'›0¡'Øüˆu‡Haq>æ–‡›äã#‚
-[ê©úɱշÆ#]ðN«³¼6m¥‰8\mm×–æO*Ídœà?Ôd&ùãͼbÀ`›ÂQ EÑöý¸R>™üý‡Âk<7½¢ŸhTª*ñ!þ™ï¹ûXâ%|‰ddu:Ò_'r䕯w–Möaª4¸Í(#在žÜköÓ?% sö)Y~;=N³2€†»F
-ØŸ;Â[·^[VÕG ô…›Ë5a¯Õ<M±kÕ¦1±¼âÜ0°«Áé&%=ösݨÃ8àŽd*vHᓯÜh¦îÇm0²‘¹Ñ5ŸkÞ²±ê"Ÿ¤Çµ©éì¹Ö-w^þbYm(<rq=ÍÆ$fò»Qf?1áùšÖ—æ“|!Ž(]U˜Z²*¹¯êë ýe<®mÒ…œ¡—7Å~·À2ÂC®,0¸úG”ý )ÛùáHÁšCEÅC2ÁL>þ·«Ê/qhÃP៻AxàIèŽòÔ*a‰íŸñýi"ñ”Îèa¦J‚ãU«¿hè6[é¹Î]¶ú£^þ Wœ ­„úž@Ô ú<O#&—)‰fÔ—†Ã¿7EÆ{ö`A#£(ø.‘ÄâW¨J¦½¹}+4zØ4ûuÍ”[1[Èhü] ¯VÒM¬Ãò˜ìy/*ï³›b÷ ÎÎ/ÊèÒšiçWOcFb)-}q‰Ïœ# 6ŠW*Ü¢ï|Ë>ØÁq‚'QÞG«Á.·C—‡¬ö™Õš#ñÕY”…ý !A¦S3çìºâÆe²OÙð<è4ËÕhB\ÎÛ/f–Ѿ39ó6©ÇfžÝ†ÒanÂÁÏ×áá–>Ï€V=Æ]‘ïÈ|zˆ•T°¹ÝH’“=æö+•ÜÐ~áâ>è?¥ðR­M :Öª”¬¯¤1ÕUÓ2jmƒ<ì &oÅ•M<Ã,Aí‹KoLÇ/ ÝžKÅ7™ ¡„<¾Cšì+Í5Êhk£JVY+x°ÀBú€ÛH¬æó§˜W+°
-Ún3!©E:qg^˜½“ çEÉHûK뵋Ùãi¬r°"×$n{G4.ö5b
-C'75¾caÁ¢ãmƒž•å ûZ *œ®ÉÙ @œË¼,A¾‚úqhîA¨øy#³
-1j ÚlÑ&³¤=
-Øcîmë5+ ¨38…y-5*6Ó¼'G†I¡s*Éžš<ªf'&Â÷ç)7+9Si|Ð¿Š·ÖC7¿¦´kEª3¡1/`@;ý‚·ÕØ%T¿h¿÷m UBÉg€Kj2ç3gžE>Én+p×úˆ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È
-B–y´S,¯K.Œ¾ÄJ'7Z¤Ýiõ•®G@QÀn•?—‰†Í_#ppÚ“úëslg°ˆ!PB0ŽÇ0!)ô j«ïY:FŒ›|ƒY Þ +[#’¯f•YÞifýP!`9†„øQ1º*˜¹’οçÿ1›†•Ò»=Iù NeõÉ #˜' g€"C-†óçþ9#Èï³Æ<4Wkë]
-bvÑCª¶<áVÅák…î 4ÛFüÀãó´[OÝ­É›þ(œ6®°Gɹ|ðzCà"å:.B*´
-ÌÇý¦”ït†ˆQF'£•W”‚Jî‹ö¨RZ»å>Õ;v×òu"Bä—,IÆ÷
-?tBVå äÓÒ·&ŸõaðÎÑ3ã?ì‰ðˆz)ýþŠË¬MÜöõÇÈR‹[uY­Êâ™xŽ(ä©rLx¹d0©Ù¹9›—€¹`eîWœŠjÍ`« rëáeÕ0Eg—¬ÀpÛco:,Cú‰–èÓT` T콈l×ÓkŽÊ]5É_oÖÏ
-¿Ø„× óF¶?0PA–ßâeP¼šxoyT×]ƒ ߯ q‚éWëÆóªVüš'ƒ³DŠgªš­µ©’((_«¿ª²*ÉêjÂÉÀhýìÀß,[Rz<™ð<ËXs×;åäÚg&Ú
-¢…~/Œ%뺋 Í_g>êµÓ~ãYbŠ5|
-ËÐÿÁÓ6æ›.æÏcÖ(‰…4Sü4ºÖ. ³îñ à“ò<¯¬ˆ.76Ÿ?õ#»Â oyù£ðc ™2ô2Íû>Úé \‘ðc"l誤çoIk§†²ÇÝ‘Ïs§§+Û¤ßÈ„ÊMðʪìW¯> ÕÅŠJ~à‹“ç—=6óÎ/QP<Ž}%´5*¦²ÍÌà‹r][¸„ìWMfRA¾.¼Ôã·v’ówØøÍÄVn®q»7OçÙ`°W¹(ã#ðmL¢mÚ¬61$"ã”’OãÙ¿
-F ]bI“•C·v0ô]ïsŠ×V*à&Æ:-H<c°1ñõZvO(MDÁ™UnçÖÃMLw¦¼9Ìʘ'f {­‚HòZÆpQ¹e熶c08*k¿^Z¨¤ü”÷« jÒ ®íVÅFDøqÍGLÎL[Þ»@7U92ÇŠ ®•pTæÁ_Š6E{E-”»ì“¡ï–á䨓Ôò‰÷Aé‘E
-ö;)Ó5†90öê8’ÊøïSÏ]m/‚ƒÐ _èìûD"6ÅÐ
-ó/ ¤¤IÝn×ャÃH£J©´Á×í£\^"^?m¸î#ÜÓã­¡]?Âǫ̀ôÍÄ?õ}ŸÔ½ºCCv‰ ØÕÅóØôÉ‹ŽcÄqÙÅÄ 1È‚ÓÏAK–&ÇqJáw‡í¥óðq-²º5{Ü9cú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Ñ"Ý
-GŽ—z¥YÆÂ¹QëкtšI–X˜‡1·Ee#§r}›áŸz±g˜$>ÈÕ­&)׬H1ì¶SdrvëOËx0P(îée¬-ÒM`¢!03ðÜW‰M^®#Yâ
-.„²5ÚþÈÖñ^ž/|†Saï½ ô»ØIvê
-Ý»ê}­€‘D=Tÿéâö·½‡žëÑG]#ÂâuöñçP2ÀÂ,
-ï:/ÿ©Aàéžµ@vô®ž å—þA·žÈFàQ=á'ê²_Z»ÔÙÄη+YS1¹Êƒ”ÞTRcÖì`Qœú}V› v1g1ÒŒŠ$| 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™¹
-rp²ÿëaûûK¦hïìâlâtpüͪ(*þouºX¹ü“ÛøØ›ÿõ4µ7qýgKÿÂþÒüE]Œ€vÎ
-±ªVõ¶ý^Nc_ñõiܬ槕Q¿ÑŠÔ+«ñïPYŸÌôZ#Ûõ½¼6SºßS7Cç0ÂþD¶X>ªO¯Æ¶aÕl¾JüÁøÒŠuwßùöüh¨ÁŽ7n- ª}»›ËÏì¯ò[ùwµ gïèÕËä‡× †¸ºŽïÛ­IZR » ˜Yâu#1¯› t,’‹¤×CMMW•M¬îÓ–$IÁ]•Ð}}™ß×(+X{—üÓHï=s]Ô½í<›Øáb57U‘Ct¸¹# ¹@ ²KCúFúØì¸5Ö0ë
-ƒŽÊ©ˆtÝÊNõ‹æíùu§TþÝ4F¯ä‚™ϸý§:Ù0Ìîz2.‡8Á¤¥"ð@b¹ð:Í(o`Ô¿kM.Z’#ï£2GYŠnplwÌÙm݆øf[8³")Ý-Ì>ØÐÀ"¤¹ú,ï6çš#±VEÿú4Í ÙTÙ ƒ˜êççX}×¹F; yh ȱ½ýx˜!:Á<œ?-p©yó>sd³aEG2 ‰iħØä¢_,Ì:ý¡ÒI“
-È ú€èç“.ª¡Ü^ó!Ozü(~”@½ð¤Ê¨JïŽ ÷(ù)I¡É’!Ë[í¿7O’0 ™(Öê/Êó#?ŸòtssÕï“wÏgWWÂù;í
-ivPS“ ÙL+¥6º:]ø¹à s¡†U²;nü[Þþ¥ºÈ…\F˜+6ØU«Iæ´ÿµ´*mg_^ú3Q;.~ÄHB/׌0w=>>b¦u¨„Ê>D_×$,?z^ŽÄ'dð1QèQïþ®Ä‡:RdDc]ØS
-y­)øM˯ìý>z¦ÓÁ‘,£¸º!6ãã
-d-ãµ!2AnXî}uM#Ek}ÚÛÀ£>ñ´0¥š¥b˜)£9Ëà_dö%ÐþÄd'~}?
-<$Œ^ƒ™yJŠ³Þ·|f¯¡_XÍé65È‹‡xȳT#¢Ê›c˜Fn²äjvb¡"£Dñuô‰ŽÔ7pô¨Þ3kµ¢ÃgnI\Hý•ŽxÅaÙvè#Ýü½ä®ªª Å9ñD“‹.š¾S2Àôõî”a½)m¾Úò~€ûó …â#_ôI\§êë•/»šžÇ¬"ñI4/á°ø¹;øë3  ËÍÄõ?X"M4Óþ0ÿÔžóë:i·áèÿ„X µOTª—‚ 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ø
-ÌŠÚ ø,Å@Hˆ¹´z$¦“¢Rõ„¾®û£6pzñŸZTyûÈ2(†4–²7h®GœÅ‰Ý?5ëË€ 7m›TÞQ¤‚+̇ßG.¬¿sŸ‘7¢ÉnYFV³œÜÛQ$yÄE%û²±Q´…P”‡¹°ÝÜï…Žžb ÿ _0}}rÅZ¥¶ š¦K.…¢ÌUkÎÖ »iÖý MÒwÎûÃä˜ ‚ÊPÁ„Ð’
-ÒÀ^Ò6¾©Þ°´äÀÏqTÑíö® çŸ$@ÆOo‰…¿§ dêVMäáêh‘´B
-ODµóš\ÕåQÝ¥Út‰f»G û*NèlÂò;Ö× y<n‘G£4°»HÆßy ᆣ§…‘ÙÊF -x/þ %³ znj·<Ÿè„­÷ô í ‰ª šR˜*¯xM®Ì6`C¨€qÑÂzýÖóçÑú;þ¨#f\ꊳpÉôâˆ9£ö…¿4ðÕ«är ã%MKÂê·³©3[¯ïm©ð–J)”úகç'ï”oéa} “S\±Š£zÿGtÀàØ
-µùœw¡ƒ Ì´ç+;ž"¶ë¦Ñ?doû‘ööb"!äMeßÙ°°XƒÛ "b ±-`OX‹1Õû_µ²F„ «WaŸï£˜@p+ëakqÛ€ŸÐˆnYôbôóºL¨RÌaóå Çfh#-!”„pe·EŸ¥ìªäÂh-lS–Úq•—;`âB=)vÎ?{wÙh`U“m1Q2X—Y˜õœj‡ú[µ®æ4öZ$DT›ß°Ó5'B~´)2Ï#*pãŠCñ}t¬Akª#òô%ä`)~¨ä½{ZXܱÄÃÇ’@K'‚Ú3Œ…¯QÄüäYÁE›kÔïœÖ€w»îTð³'aH»xÙ^ôÃÛ²ö³›úRÆŽæl帘k%Ǧ‹ÀެßkN¶óš×„~Yy¬Öåwã;™¾ex±xª}Î fÖ†'ñg%·”Kkø“
-ü…ä”÷FT‹K¨âŸ‚øŠRʲŽ[ Ž_n™N>ßÎ2rWìÐc”r…£ã‘mµ%Ç}6 Z_æ6?ë¦VS¡|Y=!j­¬å ÎÿùPÔ¶ÌÅì€Íˆëb޸ʮòu[É¢Ü%f)0ÅÊE6¾7ô§N«E[.©ß<¼ÆÓ,
-ë®o|:o•ÚœÅSŠ%)Õ}ø=™)WÜÔµÑ;¦Í“Øøæ“úm±a εVsJvö@K£áûç(BÂ^àwðg®Ð‰'cÃfBÇ…¼"(Q¦î†÷´sø¬kÿåõƒk¤3N}óx=©ZÍg´¼˜ù?¯…šÉ€—\E¢ŒíoAËLÕ‡õ©Û¹FCcËo÷³¸Ïá€Ò‘îÚ~ÿü…On4G!>Ü-[·,3!E‚VQ¥H¤Hÿǰ
-+¢±'£ë(‘gå]h’ v–i`PÚEÞ…W‰¨¹úmõ'>Më³&#kÃ^z’0†i¹"Qrå>+o ’BP,ºðü R¥ ¯0˜÷—Ü]ý°ùc‡’_´6iY"ëf¶á=µŽpe îìI‹vfê".Ÿ£ËæDáišó„TýL-k,I•:ðkÃæ&ïJŽáóÆfø ”fŠ×Mž- æ,Eˆ,‹bù8#^à0T§L’‡Tvn轸ÿT,5 ÷S> +‹o7ëX¾õ±“¸K«¶CÕTå)#«:
-W£Ì8DB¡ÏUÿ,”…œ'‡n#íÀ‹ªUI“ƒè®œB 
-ÎÓq$Mö—YêqH$Ã…ýuQóë®_¡Eë´½ó: `$ËÄÉ•!‹‰@3^[ůiF@êU›ÈxcmÄ*kâ\yýqj_¯*]U|ë•ð;š:Ýc¬Qz
-j*
-Ô^Óã¦6¼ÕìÀU\{~t
-¨2e¹ð={f´Wdo´@°£Hüd·J ¬‰+z$Õ²Õ(;Vœ¬~]1B\ØLäë{u*ûä èrƒËWƤÍy^ݘ˜Ó\2Æ,´Nƒ ‹ù}Ì3Ý¿Úû|^žM‡Ó]¦
-áÙœ´7S‡zõ¶lܵº"+7Uý dÎÞ2jèá+ ÏÊ"eåc¯/äcà Ã±m¯h:ÙÙåUFñì>Ä&ûk©³=]§¬¨ßîaêÉv)£°®4Ê +pö–fÛ˦ȃâ²o•LdšŽÍV?H%ù¡¬éBi©WO.Gßæ@X¬Ù¬†ÐøÒ‹@jGxô¾±–rƒŠ%}ê0ÿB"jì 4
-cyÑ=—Ó2ÂÊnüžÚî`Ìëá(å9Úv˜t,‚v¤©©äX?r—ýØJH¸Œ›Ámòƒ å’†ðº£Nk9'~µÕAœ Xs{cήz§O9M‡GÒ§]I-þ3‡Õ6Œ°€ã1bµ9ü»:ˆŸ¡
-ÝtÅ çÊzȆ¦ÏÇ3œ—5”Ö<ÝÊU½‰bâånm
-l_:¾
-ÃY_ÂK¬ìüvE\aÐNJðÿÞ¹nèbWo@ü7•öÙ58±£–%\É^
-òÌ%_K ì
-w½Á-Bõ?ïmif‹:¯ í² ŠÔ|ÑŽé.QØ l(è®!mW´»âŸ˜Å>2adQ”ÄpO}UŸN†}¤‹—çäsê2„|97pŸY^½VSz¯‰*ýsŠüä͸Î=¶ù Á ;ݽZ¸k²[lC)Â0ÐÐx·8äý=ÊÕi~°‰Œ÷æ ¦j>ÝÏ cê ^´5»kú¨Û ®¢ð
-Õ8§¥rצT~& ¾}÷+Z?/_Èà£w4E+^o:g’,¸’/f‚Ò MüFœ;xóÝ †—Åà`öÇ‘y´ºù‡Ú÷òD€Õð•MU‰¸ÑµEh&¼¤(ÝnVŒè.lX@ÄôÑ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¾£
-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
-—”tšJ°7ͼû ›¹yéÐjA0/Á ³ bHgnÁ¯'Š€•é?d+lDVmË$;6†º—u™ 9>üAZØÁíšw`MíÙÝF:d”ç‚y³ñ\fË_3e4S
-CÔ„0XWÄQ(8@XKp9ätñHkaìÙ¶[öƒ!׿oT_ N1;aµ<2WN¤øùÕBãAqÉBa@PNYocYÍ\Dç™ô’žÓ …¸ßëö ¡^uCGd¹êU¡RÌè>áëLúƒ¡¾\‹û¦_[³$$ËÓ#¿%,8Kú—ËÀ —ºé?ðZ;RÝèŒT@¾ïÝ­;s|ûÃìÓöYÊ[(T©ž™PLýMJÚ§âÐ×:®C:”P¥qg$)¦)šp4 kÖÀ§B´#¶á×çûsVÁ²!ÁÓ÷ú9ÅÂ|5/…}Ù¸W6:mº“Q7Œ£{PØUA%fBë*N`s´B1ÒMO‡b
-„v‡‡²˜¯ñ! +^×ÞJ{u¢õˆ8Æðl™GÓÉ`S‡„d9ªsiã¼™wnÌäz3ÉÞ}­ì#$ؘŸáÇ´.E‘Û<œÞ]oÀ×}¶À åd“‰CÌ®™§jÈ{ò3¯÷bƱÒÂ$·+6ó(¸ÍÝ%3^E‹Y\~Òˆv/;˜˜ßï–ª%—âŽ.’
-\1$xo«ñ—«zÂH•`öè€üFt©økbL"eŒ"Y²ÚcQ½9O£ÎÂ&&¥- É3íØ9ýz^–‘¥Áh†~‘Ó_ˆ xÃOZr@‰Uâ #1Ôq90½dò«§”-˜=H\2†PÅ^äÝ9jÿšY ŒÞȃ°Dêp4?¢ð¢F y™;:š¿‰þÏ]Y›vÎý12ÿXß¶ï Z˜F‘ê+¨Á+ª’³HÌ•éq·¥óþê— S¶^5nJ,ŸÐ=ØâÄàѯÁVdÙÑ‚ýWÁ^‡„5ÐÓJ<;POSgkÍÅ=Û‚Çj^i
-`‚Õ´¶È·ŽÈ:ã‹ 'ê#&nnv ¿qÿt”êÄæ‰
-ÝKž*gÍ)âM3íålÉ+VÂRa°xÚ·^Ôp«=„j°®¡HQÑ:8CiZ[
-J(˜LÝ
-ÐýÛ¹\g|Æ\ѤÇ/1—«ÂzwîP|MF¦‘ƒBXOèȪUŸâD b³N
-ªõ'M˜CkC Ú„àŒìŽŸÊsÚb‹t&oYy•G%œ+šÏs/'KS8°È¿œf‰_­³(V›tŒðI'ìÚ
-]RÎîà]­ÄÖÔ6h Rû·@3¹9 ¦–P. áYä ’v7êÀ!çbkú26«&¶Ýs8ðd·XåëGâ²¶ Í
-tþZè
-, ,SÄ ³®Û·Q–Ú‡Ý6%€¹·„SCTÛæ0nǽ]r U¸¥Îô ÿ×7u)“q›&Kñáè×D\Oì!Hç‚íÄV¼²¢8‡èä¨ÐM¿Ê-ú o<öž¿þ†îܬ²;¼½:èå9ô“6s:Þ$ùÛ õ}ü9ß[™ÎáÕU=u[h†J ¯ã®`/Ô Å-!¼:G% …R ¾"¯Éç›Ø…¿{føšÃw²rT(Ú<e?
-ÅŒ ò}¸‰2íFz¡;f$Mµ÷KvQJ~4
-ug°{ŠÌ™‘ùjǼ­Q>ýR Cþ 2U9BS×û¨þøDáɈ‚œmhºßa¾Eí¬ÇCøw[fÝQ¬ê_1ð¶
-ã§£<¡žH4Ðé;7F9y¼Ì§@xcד;çUæõ<+sühUÌ-­F$F=©Åòƒ¼»vQº%‡Óò0j1±dÉpQfVë tFçÔq!›5V(ð¹s¼Q—6
-E WÎ^ÌË#ÅwÂWÊö‰·²mý$ïãœ9ž"ãabH¶Ë'B÷Ô"žiØ¥±AËݧå—F‡(È-'ˆÏÕ)ŸÔ38ÝH—ð¢9p Ï«1ç•¥)³Ðûí4&P"tœ{#§ ˆ:’úa@û#¿½ßsÒ¢ñ4:‹â¾%lÊ[PLxUµY¾L‰à'v4ûd)ÿR
-·ãtÛ”I67 ˆ-
-ï3º¢\ïLV´m4ó
-2c
-·î:LH,rÍ̘}”©”ÏmôwqDUp˜¢¦`ï³KÜÂM‘C¸2Ò¨æLëQ{ÐC¬,Ë•ºõtv@þýï$&|Gh­–yšÔ=•€LÂ×þ´9QÞìž/ú¾dÊO
-¥$y{o/ºÊ…-â^ ³7˜ÞÌu7î׿Õ]ÞÕÛ 7K–ö Llœ® èBÉ0ä]Fç Ã.Ȇ•O‘J®B$¨QLJ ‘ IxÖ-€I¨9
-ý +î$aÉÚ ¼MÚÄ17œf
-µ…¬÷TýMŒpqlî^²²jd»¸m]
-ÑL=&†ØÚ稺Y²?·SjJJ}-ôäÀNT ftŸ s %–þ²8—NŒ ÷¢—?³¼B¬ýÐã&~1$*nGTÌ1÷>¬œå4>‹šÁöm¡Jv6õg/Š0¦Î2¤×¶j*ž™¥Ißëã¼é¤Tœ´g»ìr¦Âé‡Ô{vÆP>ý$ez.´r™Âòêc>«y.AžXn7ås"p.w¥Y¶üÁVc°rÆúÄÇ’QN¸ÿ‹)®D?â1œJŽJúwI×9õ €ž´ò3–\æsNçAS*Ö0a gîêv¦EËÕÔª
-ÃÕ³5šQ^­šõÙZfé©4ûå-Ie U“®é
-šÉ,‹^Ì*hÞÔ@k
-ÙOâî¯4*ÐHÛŠå«<Ôš>OïYò™ì˜„_ó×Kßž6ÒóÕ¹“äÁ;áfÐ ft°‰]vÁsò¾x¯»?N¶1…þªYGtìmÐp¥Ó¾ÉtZƉâ‚^¬ ·JHëƒÎE[+Í;þ ØÞ_׆ás·ÚW¾}Â]Ϫ'ÅOÍܓˣøÐ¬ããêd7 ¦‰0Fªkº‘*äýêLk¬ÔE¦ÜXÚ@Ùà#Œ]ËNÆ›y³?}/Ø­ÚÝö»µšqÁ§‡šMO×ÒNП
-î€þ™X
-â*áz^.\¥„!Á“{d¿ÜÐ#ü
-ïH
--|ò0¡÷F¢$ßñGÊÌká{ËâÈÍL–±¨ÀËäýŒÛª‡k[£·3žÐ îF§¦¹äð”Â-kû4•5}Â;²©%Ÿêm&øÉˆ`r}‹¼ ÇZöŸNp±Q†}É |~+±Ú<¶Ð1öŸm*ÌCÃ!̤A©„=í«(OÈnœ¥cã7äG“dÊ}O²º¼óçžê‹T&Ý&ÚpÎZæ2«æ\Y=9xb• ž/PʹK¾âµm@0zõI:ì›`ßAhÃðæq¾g{o÷ ÖA;{Õ`ÓY£º\zÒUuxVè3óxðÛ‰¢¢3Ø­Vb&š m¦G3I §¶„¤Ý1Ž`°Êã>(•X‡¡=xô´¸®N×›ì€èLb”ˆC‚yÆ­G‡^ B[5zÜa¨(Ï:R7Ñ ΜHü­b^ÏV.»(…âKY×÷¤M¨¬y0rôYÅOxÞœ“Ü‹Z¾ƒ4XÝáJ[K/pêٱ傥‰žeÐh˜8ÎS×R]öVa’ƃ|Qh Ú¡ÿî>†2v£O8xÍÕHØåªš:_øÓç§œØGÞ8hùõáyQyáíšßål0ÌÃxñ¶ât× ½<•W°Fôä‰Yä)«Ë’%¦H¯ØÑä冰<–ý&Í—.!l/C2CÉ›ÿÃ’iWMvM´a¯à¢¨ ºÛåòÏ’«€G¯M+ëèr(“
-÷z¦iB‡®”wufX]¹©ô£~n¼N-ã1JtIà³7–›fãm~|GË×è§õE’N¥h­ÿÁ†‘ÿÜÖ1„ÖZE”BôÎ&ÕaÁðÃ_ç€Õ¶ÇÍX¤kÅǠĀ%_, Å¥oCÝÃu´
-ù¹ñmá> ¬$=Þp™i—à
-èÝŽòN½‡©*;€5'®­¾¯lš²^~ÍPó­œ1ý®Ëôƒ¹q[½ zÊhwäºÂêáG: É:JÌ7ƒ…?ÝÙ¢|³D2˹})ÔÍ4æ§„ªF?Îaâ[×’©©eÛKúyÛÜÞX]Ÿp w’“?…Z$­ŠîÛÀÖ¬^ù¶ßu›¾3ˆ| ÚãUi`TîjRÑÜšZkôúŠW4*™º´Rþ.å
-HÇ’#Ñ6aGHÄÖËvx@³öÀþ­ÑȪ/áïba·DI)Rá n®1.ŒxÏS[¾¼m(ß¹I$á(Á!Ý{æið¤ÆÙßuuòûk?–ÿ”_;Â2u9ifï› ïéÞ.WË,ß¼I•r
-·Kæ1š3rÇÖC´žBhŒ/ 7¬-éËíâD™Ø¤Â½3ÇÚô89 ÝÁÁei?ääï‡à)gLÄÐ'ЗDvf¥#|8Ì{êc!¡"M?Æ"Wfßîé5D¤EÕ,˲üŠËÜzät*VõÔ„òp ¥ö7Ñý
-º¶ÏŽmná›Á¹àŒ¹ŠF0„éY)Åšá«Pñ‹6œ0`z)ú…Ý«Èg\¬<ÐãFDQIòl¡_¨(¹XÀÄ.Ìšú¥ÎÛÏÕèU—æâïJ[èhÜîè{”iÐÍî6®"#çÝcî]©%¡î!û1Bá¿^î:ê'\>•«wz¿Škb0 ç®OøñÍ!¬ªc!@¢ìp((‘åÏPCæàüùËóZü;(º›´Ÿ…pSõ‰Ô:®‚tÝîó7å²¥_!ÅZm¸Šý¶¬Î´ Eý¶5 |JZ®DÊC|63^âaµ'ÐϺ)ÞÉßB Õ]¯žZ$•OAž¥€¥·qàvlàê±xh¯ØŒ¾Æ\O@Á\àqc– $úfX›ŒMÿºÝâ Ï—_~ÿ¥Œ;Ñþ™MN¶í/–ÌlŽöŒó bDTh‰·K,¹#To-—Ô‡ç·ÚÐÃ>¼—‡rùˆÏР$&ú"„Q.4éÎÿÖ¿v¡  QXʽ֟ÿžÍÆZ¦|Ï?õ•òL›ï!u¶øZ†w^ vOT˜ÿáKKîŠj*ìKía·iØÖ+TnÚ˜.PÑoÐV-š°ܶæ.Uä:MP  6J·-hé|î›õJãH”jh·UÜáU4|‡†Í ÈlŠ×=F|•ޏRõË’ŒTL<“À>ó‡Hk;ÐØú!×½‹~%g E´·P”Úíf×$Aœ¦‘Gþ°u†Wý‡czfb WÔÅXÚ´Ö\ü |+B›·ñS€­)è7RD¬ós:?y‚Ã-r]þ ½^ónv-Ï]/žVcà·~6•ažBÖ eÃH¸ïòYr£ìË$³°^(„*Œ©cÈ=¶1®waÖn÷ >¿ÈžQSÌ«¯UßÍ ™?œ
-Ó2±_,¬0?$éýœEAíÓ!yyÊ$ð¦Ïœ6{‹1‹'®[+\Á‰3‡ŽŒóàyp)BèÐ ãk3¼Ý(ì08á^,Ánœÿÿ‘^‰{zË0
-PпÜ ¼ST
-þè»ÜÔÕòø9¾ŸØþžÅe´8kô;_¿÷‰³RªLϳ÷7÷rÏ’XÈàðÆZ
-ªjDÒG@œ=ù¢0Vþ23qð8@R‚¢Sx†€ÀˆQšk>Ö˜IÛ»åÆnÕ@ Šœ+7ƒ¥ #xA&
-V°î2»“u=œÕÏ"¨¡ ¥}ŨRpÔG0Ò|Ëÿ°Á÷v¯×ã#Ði¹j3ÍTâè(3Z÷†]ö‰6$áHý.ù2rä"Šñ.Q}Œ[ô(~áa¼ô|·g7LÜëèi GÕzBƒ¤ìò°ôÉy,<ri5¢Ó<øQ°–"ß@X1páJ9¥œÜ{5ÖXOù!Òâ™DŒŸ-ƒÞÒ{ßî|¥Þ‹|õÈ”…;°ßUÃF rEþ÷÷>£–¢€%ÝÞû.îcäG3*Ùºr¢ê.ûÝS²Z°¶¯Üi𥰛‰àò"ë8׊Ê[¬oœæiªÈtB!N²Ma3_#”Ö‘3?z25Q«û%Tb÷‹ºðƒS‰\ ”Ë`DðÌø¹Õ"†Ò»K$šù‘ W»P-$Ô"taâ5í.§œi"2a îÎEg|鞢³‹O-,Œ'²Æ¤ùp|’Ì”‹Ò7rž´­‘€µ‘‹Üä!ðvƒŸÖß0ÕBöy\åqýXkÊ€XƒÆ;my»”(~aŸ›{á|±ob’ØÏÖ­Ùxœ=†¤…` Ö罦(h ö˜85]‰„C¬…ù×UÎu×ÞÃ4
- ?0
-tâï¯tãq·˜þ?pÿ?Áÿ'LlÌŒœ\ìmœ¬áþ”Þendstream
-endobj
-634 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 40
-/LastChar 90
-/Widths 1344 0 R
-/BaseFont /XTDQTY+URWPalladioL-Roma-Slant_167
-/FontDescriptor 632 0 R
->> endobj
-632 0 obj <<
-/Ascent 715
-/CapHeight 680
-/Descent -282
-/FontName /XTDQTY+URWPalladioL-Roma-Slant_167
-/ItalicAngle -9
-/StemV 84
-/XHeight 469
-/FontBBox [-166 -283 1021 943]
-/Flags 4
-/CharSet (/parenleft/parenright/period/one/two/three/four/five/six/seven/eight/nine/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/X/Y/Z)
-/FontFile 633 0 R
->> endobj
-1344 0 obj
-[333 333 0 0 0 0 250 0 0 500 500 500 500 500 500 500 500 500 0 0 0 0 0 0 0 778 611 709 774 611 556 763 832 337 0 726 611 946 831 786 604 786 668 525 613 778 722 0 667 667 667 ]
-endobj
-626 0 obj <<
-/Length1 1606
-/Length2 15226
-/Length3 532
-/Length 16089
-/Filter /FlateDecode
->>
-stream
-xÚí·ePeݲ%
-…»;ww(ܽpw6°qwwwww/ (ܽpw—ÂÝáÕwNß¾÷õ¯îûëÅ[+bÍÌœ#GæÈ9#ÉwaS;c „­3 #3/@dcìâ$og+Ç bgm
-øk䀣 u9ƒìlÅŒœ¼
-’
-tüWƒ¨ÿ™š¿$ŒLíl­=
-F6àß àï cüsÇü¿bl@Öÿ›èÿ¨ü7Ãÿˆ´³Ñß6Ûšÿ•‚™‘ùßF“Èhúälb03²þÛ£ÙÕlMŽÖ [à_-ÿÕF
-ñ½¿Ý¡$ý6;›˜ ½S‘F‡‡9Lq®÷#7ùºÞAæOy«Æk™¬0\™òã)àÚŠ¯Põýè_°ÏÈ𸯪+WX½À4qW%¸3A pÇ‚yçNјŠhÙFƒ´¼òàH«Qûv¡;±0p•]ßt’~xd,Š‹÷xÂÍ6m$ˆ¤bŽè›a»èýa–Qº ÅZCE{˜Í¸V>$zytgC¿ Ëûž~^üZ΢ë—'¿4vÌ¢€œQ(߈¼ÚóE$9>RÛòvJr —Ž!V•Qê-¦  ç]kˆ«#L¹)N[
-Y'L
-Ml%£:Tid„‡
-†{z¼*†ÆO0RÕ[|+uØ<»×xB–)ûµjÃñáÛTK!ëßP.GJ¦ šïHídÏ·Âó‡8ÍÈÝÑìᣮ¨¹)KÔ«£" [ßáØÓz'f?r÷g‡ÏÁ­õûd„» Ë}áY‘’¡žRÞÃþÛÈž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ÿ
-Ôw(ˆ)¸ôèg¾ÜFþRM–”T–VRƒú¡âÕ€ 9«\æÁ r˜.°ׄZÎAÆØRöuaÓ^z¾A}É €1X•¢Ä<”BÅ2Ý)×BöÔÚó–7L}ƒ.DMZÖËçÒÌ¡sìÕzÇ<ï§PÙpK`Û¶—
-d„½-˜vNªÊ:&¬.U~ø
-S–2¶ò¦,|Uº•¹åÿŒ ²]d§ûHÛ±^'Óàrê¥Ñ'Wží¼IëÛË­lžœ‹¯‡ýôÊ0àU\|¬¹.wÑ`7ÐÛå/—êâY쵚ûU¿ð½@'Ã\Û#ÿ¨tÓ"¥ÍSûã†ÖÑ Ö9X³*¶?"D'Ö ótÉ‘mtå
-6¾íè†i#¦‡¨#d]™P8-ÆŒt8ñOÑÇ,«ñæ¿V´Dze< xzÄz
-ÉËh¶*”zT© :ê%Ë×úì±m,0¼Z©“`Šì£ç!(ÐÖ2Y
-<«<Æ;ƒÎdä”4éPйë×¥ß"á§KHe
-¬Ÿþðåg¿ÐžT1‚ŒÙ{§ë³÷<¥·qÒVÍïl—ÎЕÑi„¦¨DäÒ)ìW¾V “{©¬1›
-ºs„ŒÍDÔTQóÖÉ_+y’‡2„æSu•P¾1YÙÑ"®—tI+Œ,r]  ¤'Ü~ÙŠÃüó²-e–´cOKswfÞé¬yòÒƒâÌ’.ËLÿµ_·_Ú•bȼ±ÞõŒCâ¶“Сš¬©%˜î­vNBÄ3Àu®*ó^Ú£e3ÐWE>qßiSgb`ÑÞXpœõ ú~0èu†£ÆBß^ ¨íHßÿó1p}PŠÇ
-ÿ¡QÁ{þ­
-Pä±\7ЇòÝÐBÞz¾–ܶ<
-hÞãBÚ'¡ê{üŸ[gq«JNi9ª J¡ö–”ÍÎBÚ &eš"¡„™G
-0ũ㻢×JïØÄæv
-®t·Té„Ã}5§¯kŸ1öÖ¥¼?Pe;ö•Pö‘rû0ï}Bϼ˜\ˆÉ6ù·ÒšÏ¹äçMI9!Èèm)L(ãÌSŠ›öž™{ÔˆV"X¡…-’?.ESö®žªAÝP! j#HA±}…KXžÌÕ§ÐÉMŠ[¤ã('©m»Ÿ>¾+­›™Q…ºCTmr9ðn«!dØ}û\>KdÚžïËeš»ùØã‚„À¹b¼ôd *Ç£GhU×¹
->3;J¦@ÝÀ¯ÓrZþ@)%È€Êz¤a¨ädèji|µ€) eãCÊuÙ.ƒæqô~l»JöUþ ŽžØóáxf‘n#©[6ú<—¼FL¨Õ‚¢p¦áâþòþttÁo¬‚¡:ks_V]º¨ž*Yº‚ÖS,"ƒTæ{à':¨²Ãêﳓ+xòä½o»äß(!\Z,ÓræÁÚÉŸ ð µµV$n« BA†lmº'U'ž½R›~nØõãç":E›çÎy?ž ‡ ?CÑ<,ê‹DÜ(8Óv}å~õ ìòÙ¼ŸêGF¾nƒU„­]¢6¼ óÈ¡@¦]¹:@¾"¹&~žûÔëâÈm!Ê ê½–B¿™—´¢´
-]éû.@U¥”¹7n0B¹TñÖ€•Ü’ü=²Øü;ApÊ|,êºJ CåD…rÿ}œ_PHqÆ»LO…NEt"†‚©ÛAѲ‚÷&¾½&WáõÔ7j§qÝÄ´Öoºêe--Cª±G.y–æQ12Ò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+%{ <V6KiH|žz:]6•Æåý̧(j›ÀM¾dxÅ]©äh1=[SîKØ{²Y¿×Û3fãï[4HâÀfppï}:´$ŠÖ‘1 `â;Ø8§QŽVê’ÝýIX† ò«ˆ¤üYL^R3‚ŸW:o»é9¾5¾æÃÿÉ#¡ÊSºyØànJ¾w|fjvä|ðý®PRñgž‡°¼äÃ!Šì1¬è¹Ø”9qζ 3™u° œº­ª¥?™l*¼~þ²[q)7Š–%ñ,L­2Û#Šôï[IÒÖÆÂJÏ®B*öç¥6ÙâµÅÀìÝŸ#zç*ûlãoô«âWýr)¿/©Ê»êrBIö…Úäé]›Ê®ß@¾ sL.ƒ6ß!•}º‹É÷E‹šÏrW¹ý ¿ô¦®V*sŠâÊ¨îø»iaŽv|Ýj0=Ø$Q>SÚ¯‘n¾€ûà3µ¨¯¹|Ï‚·#ø2òJ_×Kà?ew5²ò!msZYÝþ³Ûš6·—O,o|iVð”@DOXå¡gg'\ÔQUáÏ‹wƒ§ tÔи7uû]J8IÓ~«]Õgb+©‚±ë­õúZ÷0©ÝæöœÉgp£è½»Í¾÷QöÅÒ+*A¶3M{#ˆ2¡éŸ‹\®þK§Œæx'wÅw÷q‡Ø™³G›Is%ößÕlÕ×ÙYó$;ƒ"d™ˆÞ›3™×Vc:DŸ!H™ØºASöò;ªÄ‚3:¬§µˆ6· ¿+><Æögn% ãïcªKZ¬ ýÒEÓý°¡©
-oöw¡‰Ç÷ LN(Ú–Ç•ë|¦ÙV0f†BckÔ/ÖözåÄò«ÎMüPC‘&§¤sâQOŸîì?`øá
-u€2DZT‡ÿan<øF¢àƒK#ÒÞxpÂä_µB…•’Ä5$(Z£½X÷˜,Çn=F„I1°Sk€/ô¿Ñû’-Ú%6©`Û/XwܸýŒPä°X{]‹{ÁõIê=/uµJLÒ "nÏÖ9 
-ÊnQu}±”ÇËÂo¾ÀxÂO¦ßi“Ÿž„Z”ž¬ùáXßâjøLƒMw®ÝÉ¡þ‰à0߉òÐaàð1͈o®ŒKÔ2û%걓ºîöC·wÕ‹Þ«WI±á‰šæN&`­†[Ë~©à}ã‘ë!–{«-ƒÐKÜQ>µÓ™ÚHh[“+ÊäŠw˜Œ~š ‘o;UK䊋íó¢/¯sö6†>ûþøM7f“wcå wÛƒS^‡ãIÔˆ·œ­‘‘O¡"è£á²N´(*–ñYaZÿnŽš
-/ †¿
-¯)$QF!ËêbVqâ!Š–i× ÛÔáZ4 z³2„«#µùjÆa0Ž¢”½¦wÝ̳ Mx¹c"ve·yäÒ0Ëdao† ˜’|¨äÊÎ |ýªm¯;°”`È$ùúgH÷ôT¼‰K6lºæð°1I§Áü<Mø—Ùî¹A‘†*›Ý´ß4èN]ÐL:òs@ˆv.BBÓØ~©ç0ϽxØÈ¸Œ§´zŸÌ¹1lðhSe@¦¹Kz˜$Aˆ"ÆÀô¢A $Õs‚ݸHªêmªœÒòûÜ™\ð€Èª&¿o¢újt§ã;»ô°Š lñëÒñLÅ –ÞÎÙ ÆòÛÞ¢bòê/Èá‡@°‹Ôp;C¹@˜T¯+,OëBš—UÒæ7v¾µŽó"zÌžƒu¸WÖŠŽ®‰Úƒ6äfôT!m¹dÒ«?¢-gÊsŒÅ¿î•n!yªWƒ¨¡õ…*‚´Û˜d®Ë’Àî¤a‘ð7Àãk¦·nÖdsÈãMU„¼Ž8ðA;²Ÿ‡–œGC¹éâ¿q…”½ïyB –þ|;kßá4\àç¹òNJes æ¶3 ìãdœx1y¼\ø<µè¦>°¯Ì~δ¨ñ¬ &d‰tñ‚Üè>øŒº§ðTÍ”­µq¥|rüꆸ´åxùòr¿jÖÑy„æOä¬-d‘Òä[ºz@z6>"Ò(K)+è¸ Ê]‚éÉëß-Z¿¹ùÁßP£«•O ?.Ÿ7©`ñ §„nºn´ˆ©AÅ
-®K·¶M“‹PÐ-øeóù(,•ÐqšW×,׃ññ£™”¦£W…á觇²H•ª£ën“¼ºUÕq/ßíÇ%–Þqÿ J†tù›á8îe p©SíÊw¥N¶oéÑ!í3ày<Áév…‡~ñ¦g‰ûÓGÃPûÅ•'ëyçÅÙö°ê"б2¦<N[—ŸeD·^¸Ï×C2'!ðœþ…`—åæõ¤Ó.Çiæ’,ÝãI~d¿z`4¤‚+õë5e>¯ge&ü¿ˆh8#u­÷$å†7 ~g¤ ÌÓj7#)¸"ãbø=ËÈÓF7mõÏx|)Ê ¦R+ËY'¢Æ‹f¯
-é0;êÈÞ šGû)¼ÕÝÛ•qòG­‚}¢v7~ýUÌØ{/ª//¶£@¢’BxP ?×㺽v/Ò"¢³¬É–²7~õ¥-°ú¾Yâb²4GáY±Þ\ÛêùÑò:u|?í¥LTj/Ïäœän”…xÞN[³Ö´Yg$<o8ó!¯S庅{–¸¾£“7Bb¤ÖRƒû°)©5Õ‘ 5e'îäuõÄ]ºv&cÀ…oÊÄ8büR š?òré
-GZläÞ¢Åë6}oÛ,“Nxúœ½™§~ãIf7Ù,’y®KuT§Ä‹óˆÞˆ:‘¼ '³é~”*=Ï¥aæ½L šá(ˆ#}AÀ·åÖ•INø™Õqy»±ýQÐBþtSè³í¸Ç
-Oùl_t>»ˆ„Q@·z×À!»Qqf¢Y Îë"Ìãì]/©¦pš¶¢þz¨´ «E¹f‘SÑ”,Y¸!µx·?q¼ÀRœh·×ÚâOÐ`8 Ž÷PÚÑ¡lŽ~ñ¢ª ”HÓVßQk6˜qØ `?'7Àw1²£;Äk§ÕùI…²­™e£
-ÁÊýŠ{Eoa’¥VÖôJŠD¢VØ+çòêqgkSÃúæœÖJ!¾íѹ ‚§š@.¯¡?4÷k¯ÆpHmÉK HÆ`ÅÀgç»C~\þëÔÆ± )m®ðrô©:ã.ÓŒ±þ(pôs° ¶†Yi†u1`kîxÍræN6Ór§‘Ó¾‡‡8êaì%ª?áXhu*‹e²ö×VÒôbÝMcÚí .ä Ü SߟýŠw×ë±AV‚,“gBsEû&·9Ó3÷–òÎöÀ¥[Œ»ÆT*UD-.ô€]¨ô€–'OWsá€TO›¦õ`¡Š»Ù†ÖáÂuþ¾ñFl ©>ØNRȘa»CSÔ—Ÿ¶†ËÆÁdõÜBx½oÌ«·†)Ô›.hþ¬ng¬ûÛöVhNÁ4ýÔ¦zçŒi=÷·ZÁ¸ö‰ÝbáÂóû=™‰¡-í§ç)Cm=Úy«ôÇÅ“SwCðï—9C$~™¤9Ï …Û‡_ÚóWs¸ ù0.n ' ’8_JùïMæ­üÝRÄbI’OîÚë;Ãwh¯“J¬J ´Š^kû³ÅJŽm™ªó‘'i‹lÛüŠßGÀCÿçù#K‰}¢orL-–cƒ9MºNöÊ^âæYj—aíLY&.þˆf$Qžþjõ0Cñɇ\›€®ì³¼kÔ42uR0Ó…µöµ©k)¶¡)–—Í …‚‚Tuº—Æ6°…5ÚÅ(˳«mÀšÇÊõ™¶Ôî^H™¯Ì¯ò,µêiÝò¸:
-SþÅ•ù°?UÆh´Û Æ~‹Ü­³µ´FŽ Ì½¨ ÷`2±Í¾ ø_ÑÛ¥¥†%º%B\aáPbs–’´¯xÛŠÍPßí"2¸'\sïa øçÑõØê
-ùôÀ®ß`&„jsJ·ÝqüÚy»©N¨ªÊ‚a '±ð¾•ìýʤhö\êøÔ<{,üág`™ÁZ±Mãêà7G¤¢œ‚ñ¹ÍÃ5¼tÈŠµΔࢼ'}ÍÈž›¹cU{œœ”ñ’£Ñ8þ» *\þ:X)8ìÆäG4k·D«S ½ </psð8M´vÊ#'®È?Ý(æDœ&jž]RBqf„I+=µ×õ;˜AüÂÛ©4€…Ï3‘«)Ã`&ùÄ.3Sª[‘¾vÒE&Q†üÕ¤Â3$H˜3ÈX)Òö
-Ûfãu¡ÀÐZKÏ¢ÊôG„“ ?î]¢ozNS¥•oNüÖA797mÄÚ¥âFËë
-!üÂlŠÏY™Vß‚-#õÛ"òæ)ê§4|÷4û•¦Ç\£Ù.,u˜XÞçAO¯é8h‘$?³DUŽ$ÐN—ýÀôZO¾h¹)8’]íPlÒó!ÌÖ¦¾óí3„@ÍÿBkjû"qJº„‡›áûÛ>Ä£c¤ùÄþâ<NI×–áä‚b…&yK`à3r€ ‹¶ôfæX:„¡'*?§ºnQ~ÓRÙüÌ¢÷­¿Ãs¦yÞ$Â9{¶Å*+'QÅö*§H(ð›xrPßÞÐFñ`$•†ÔXóþÈÖxÊ ¥ô*$ƒn%Õu{¸‡£Û"Ýft /æ.;FÑ÷·ßà9èf¤û* Ž n5ˆò§\S¨ƒÆ+’Iñ$ÉÆ­ãЩ$ÐÈ~f›hD"°[Ir·»FªÁ>ÂnÆmp¥Z[ÆóžC|ø{}Ͱ†¡P®¦é§
-@á–ŸŽšó‘ŸqJB¬Í×H¬íÅ]¦mš_-Áµd‰[…©ÝG}kÂ'†¹ZñEïJ/2Ž¿I¢Û¼Œ;ÀJ?ЗXÒ²se¥[ñԆص–3—ñ>(ìí,¡’Ó7¿­o­Øc›ŒÆrOã·¨Ó½¹`­Ò^¼>¼aˆË;hŒ¹ÿÙÿå`@HZ a½¥×¶9‘àÕâ¡[Ü ·Å’Øß©UøgéQuz`@ÝD7… 6˜^³&s %qßÕ±%zs‹É«I)Œ—þ[~x4ir:ÿ•Ä5¿‡¼c@'dPí¼+Ê-ußvxØ€F
-‹˜>cîÕ‡¬òš¢úcÓÕVAcB8‰à–à3†(¿Ÿ->2$§‰#ϲf~µÉOR¢}Ì^Ô*ëT¦9Ï^°Q¦òÌ0Ò@§…×õ™Û¡f}O†kÞÜ9ìFÄ«òwÛÍbµËØq„ÂL™§ÇÙ宕NÔuKJL:˜Ü õÚšöÀÎß
---˜TÎÁ?åשּׁ~Ig.äs#IR³1Þdà0säÐl„ë¤)wÜÔC‚5ZêD¡˜A|aK]¾öQŒ)ŠÑßÛ¥fÜ-6wâœÌn¿Ô‘ëZ¬×ñÂe²€KQÊÉ!qäl†ä Ã;¼Â` ¯ˆ«Ýjƒ"àFd’(ñ¹%Ð¥å Ÿ¤­:ìKÐÙÖ»ûúj?ã0GLÝå/—‡ÕsÉmtèŠ7@F.°vš\õ`òƒ_¨à@ó+ß­'9/þ´îQöñ;*œî~¿ˆ\Ý‚°¥ù"@Ãw¥>
-«ñh²°þ;f&õÏý tYPXÉ(ÄÑ—îÿ*ìRâ͋MI.riAÛ³eBapX,&L˜”FÄqOÕi/zÌ-JîÙŽX!|½ôÔ{/¥Êl“”2êL¦›$ôéy¶r×òèt A3È׸„–MT•˹#“Ÿ_«ê±C˜Ä%3(ØBN®fMݱd[ï0i®§¬Þe˜nùÃ,2†•³>Q~Eó“l¤Ñ‡d¥K
-È ¿X¤ô á€S¥M†kh_v.ÊZ°XY–×~dŠZ£þq z3„=pÔÍ*SÈá£.rYÎ8xz¡ªm:è«íƒÂfkl®õ3V°yÇݪ"|pA´q+K¯ìñÄ5ÄÆòX”ñ3³S“K¸8”Xgúy6VœOÉÒÀn‹|@aµ»§Õÿþ\1-óò$jô½·Yâ6IÞåQˆÿ¨Û.†î†!ÿ" Žíë½#kÒŸ@nüšÂ.MV5âÒžpɾT “L$*jsK€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<hpFEž u‹F,p?º°8*ü²z"¼ñ…>«¬¾lfœêð~,¯±Ni`—…Ïg Cž@2|§ãÓ>ú6.ûW˜ï>µ½Ø“M¿+Ÿ $g;µÆñGïÞ—ÆøE×®Ú§qkERãÒÆc{…ŽZ²ÊZd;_Pº· t‡Èû/QOûIàÏg»–%E:)‰7‰‹zz÷Ÿt¸ZúŠ
-É9û×ÖN¨Ó©Þ¶Gn‚‰å”÷,Œó¹ñ:Ÿ5Å=©x¹=Z©¥…»Qò‚Gc]qŒð_¿³—«º'í(åDZþ´î€J®­‚Iç'«_ßÂ:ŸÇHjDõlÝå„,©qØ` G¾¬†\È@éø¦‚œ—éܪðX¢ÈQ<Ñi8ºÄ|#ñ°Åò­õ›O(m£mŸ8½7¸r¯já—"Tày¨ Zì|AúßPqéí [ÈÃù3Vìlî¾ ™VÉlb¼¤.ÛžF ûoŸJ¶ô
-endobj
-627 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 34
-/LastChar 125
-/Widths 1345 0 R
-/BaseFont /EGFRJS+NimbusMonL-Bold
-/FontDescriptor 625 0 R
->> endobj
-625 0 obj <<
-/Ascent 624
-/CapHeight 552
-/Descent -126
-/FontName /EGFRJS+NimbusMonL-Bold
-/ItalicAngle 0
-/StemV 101
-/XHeight 439
-/FontBBox [-43 -278 681 871]
-/Flags 4
-/CharSet (/quotedbl/hyphen/period/slash/zero/one/two/five/six/seven/eight/semicolon/A/B/E/F/G/H/K/M/N/O/R/S/T/W/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 626 0 R
->> endobj
-1345 0 obj
-[600 0 0 0 0 0 0 0 0 0 0 600 600 600 600 600 600 0 0 600 600 600 600 0 0 600 0 0 0 0 0 600 600 0 0 600 600 600 600 0 0 600 0 600 600 600 0 0 600 600 600 0 0 600 0 0 600 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
-endobj
-623 0 obj <<
-/Length1 1612
-/Length2 18185
-/Length3 532
-/Length 19104
-/Filter /FlateDecode
->>
-stream
-xÚ¬·eT^ÝÒ%Š» øƒ»www÷÷w‚»»w‚»»w‚ww½yÏéî¯Ç¹}ÿôý~ì1öªª5kVÍZkìMA¢¤Ê læ`”p°wa`adæ(XÙ™¸‚äìåT€®€¿Fv
-
-Qg ±‹•ƒ½˜±   4ˆM¬¬
-€¨ƒ£§³•…¥ €Z]E“†ŽŽþ¿,ÿ„
-ähkìù7÷_0Gg«ÑpYÙ[üz€3ÐÂØÙÌý…ù‹ýOwþ«NÀÿV½±££­ç¿v;ü+êq°rmÍXXÿæ4uù›ÛÂÊéŸA‘¶7w
-$aå4S²r1µ˜ÛþíÔ¿ìêöf@g[+{à_EÿÕL
-pÊÅÔQ¯ôŽ ÉhB¿n¿ü Öìö6È£ Ç#´“{Q²È_³o—{K†ÎhäK’w–jݫҾš›ŠâNšâžýñ¹îJ!Âák"øÔ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ýÊ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'µ<?†á¯ôü•Èõ\â;†Kgœ‘á “[Ÿî12+ç;†dÕˆ3ñ¼n
-þSÙR÷ex±$z¹„Äg\Ïpuã÷[áÅYUEã ÓœGÆÝ}À¼;LÅ•\tUÇ’Óâ3íAà’àÙ:Æ‚¸©ØÞàµ#.ùz]^¡¯¦ÔT¼½ OB¥Ì%KoÉÍd1Ø»[Mq 7u¨£<“KRÀ1¥j-²Ÿ”LxÔ;Î'Š¬ŽºbîU^¤óÛ§Uq72 q€yОô‡r2-î@˜­<š=Ñ×¹îåIÁ/³íõ<W| {‰/‰-´é61¼­»ªv ?è,TÐŽÊ„=ŋȱڎ+xöFáµÇ5kû`ŒªTæ+– ¹lb³Š}Ö¬ü‡ÚÎlËZ´„-½#¸HаyÈ%;¾ Š™ï #ÏEl0w\ôð䊫¥Í‚a ÜÓ\·ÜQH\?§ÀÞ5N¿8VVÈ&E\Nw?¬‰â|˜Wú³l?ÑÛùÏÂcwæ.LÀëojÐ s„†å^¡£~ÁwŽº:eÕš,A’¿>3é SúÔ»&ŒvÊô«Òî¯ÓkQÓðêF¬6}» Š„üíÞÈÕ¼û£í>d ;ˆ›¶j¨š)æñ1š}16§¢rzsµ™
-ðóOÈÌ€ºö3ÊòsFdÐàÏêþÀ öïÎtº[ëqõŒQ v$yÖÙbw
-_Õ'ÙW/t¥)³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]õ»ð…)}
-3_^ ‡¶š. ’‚…)Éç Šá£ùbK§„pNšÿ
-9’þ!î8IÑ›C r-ÿs[{œP–óe›&~b«I¨/÷­cG@X«â}Q%´ÚkV{=¼{<IÛÙ
-Ú?qŸ6B˜zÐÓjõDqÍë`ãçy3:*íHAvfÉF ênÐMêŠ]T€w1FUe/»ª|¯S¥ ç‘äÉçÐV?—x¤ ¦D7&é¦F!Ò%cqdKÚsYÒëÉå-ÊYÞ}Ӈђ,øQ´Û¯Àú—m-ßµ†O6}—í¬pùÝ<ý)Ûb²Ïàš#*yp,só0ƒÅÞxU€f\±µrü¶…5j«÷WmºÍåV†¯Q²Ÿ4®¾ü™^7½Ä˜o‡g¨ÓŸDÙÑ—æ!ÎÓI_'üx벉—gŒY…-µ}";}xí{”l½ÓˆÆ"Ä(ЯNÞ¨(i@M‘{0ûPåø›E¹b‹ñºÛÂeûà¸ý· ²·Šâ9§O½P²ÙÇ«›®§Ã³Øn¢ÍMÉ´šöÀ 1ÕʪgIÃý…ýó’\îKÊ·ƒBætÞ¬0Ö’Bë13ѽSÝü§žsõ‰™ 0ñUU¢H§: ÁV8§Þ¥(#>H÷0ü "ahâx‘[Z0EvøæzÍÀ¯ qi#Q&û¬i$€?Á^,rP-j&b’ŠÊ‚q Ø•¡1à03œÏÞ7ñbäzI¬|â·Öß­G÷?ï=´÷B`Øm€ŸDÇ6}0i:ÆeÃùUpgŒ-}-§¼~`[ ç=BbW;’«š)FâuÆ,D9ýÂ4ZÅæÈúü±ËêŠ_5¾ó¥£74ª™ö4M¯w#íçNW51ª-?îÅò†Ÿ£+ߎ!±iëêxÐIUñôvdBYB½‰”×
-,°ãzy—øg;Šy¹}ÂÿÌø±UûF¥’­k'Ú¤#È3¾^*
-•W½Š1W\ÁMÞ7ì’)Ò”Èã=ß›¥Ùµ ·`º¬e  ŠAÿú‡g¬µ¥ê˜'(¯Æ¨¼H¿ V€zà´
-R*F/qY ¶Ã÷¼ ö"A±yjat_ȧÅfTEJ}Œ;íUýÊe„s—Dà¾Átµ
-Lþ#ú%L4VWm.„½dlŒ‡`uÜ~¬;K|ìWwºˆ¿B¢ýàqŸÉL,Õà¹ê2âÛDOä¤Ï…ŠªÜï?FôÅ6ɘª$37T:΄M”Ü|û*FÄ‹#b Î-Âç{ýÛ…#CˆÂmbË:V÷Ê`ÏMFSNó|N2y]"cPiY
-w.LKuûzrsàv YõLkôÊx¼Í! ðgÞzW 7)QâM¦°Ü8i¥ÔaëJn ’ÓóÌ
-<à°ƒ>LUÆ4  ¤fpÚZ6½M®'{6üÝühÎv¾sñ–7`ô>â'Ec©ËçÔ8Œ)ŒvND–·;Ó1µ¬Ðô«€1 lœiL‡?FßÞìj`ŒÓ/DX*›úMH•|ª¶xíK:"ñœœ†ýúH™J$¾‘ËV­d|¼’{‡äZ©¬ÐðSÿ;Ü®Ý9îÒc)»âÁ|Qžn^KLæBuîû¬£Òî–“0ü,¤Ðï‚›¹ŸòJÍ^½¬} ÁÅL"wEV+*…–:óohåZ—àøÛ;Òl„Éñ£½zŸY åŒ¼«}ѡ疉¨O†xBùQŽºÏÅ*‡Ö<nWw"¬&ˆD^ªEÑ×¶!‚‹oû@bô¤V –‰µÌ‚u‰æ„ s¹ž5[èµÒ¸¼ÇM׿ÉÛÉêTþTÙ#±¤ãlÑXÄqÂûÁìØ±l=þûôÁ<Ȳ˜ý! ²ÇŽákz:¹o~·ƒÛŠ>+µ÷—¯žX"þ›B©Oi¬a
-«UìúªAŒßDÌü(Ç€5QR«ÒÛ™^ý-5vò×Ëb„º`§[î¢JÎêKÛm-o“%Saã¿sáÐÿÞZÃö¡|œ^ŠþÊã9ŒR´k%¨X³i‰ºpó›åö WÌXÈô‘›¦£5~ôHá(•VnWïç½~ÎÙ…Cî_Fh6“ŠüУD;0OW~½ ¥0^wyr÷Oü­U>?ò»ÌICÔ„üôjC{p“tÿÐôDIåö­Q‚—ê!J¹iBÒ”„–—0)òÊ4w}QjL!=;Îi5”§Ìô>%÷³|jÊ)ÍY%Úß}Vñvï‰ !sfƒÁñ½ýÐùDÒ-(œOw™ ÆöúèÞ]m(ïâ<଩ªeÝ_ ~k§~¤ùLÇGxø_w™£×B‹'ØÁT“ íY2%‚ÏÔG@ßçRÏ;üݶ²“¥4ÔŠ/he_q
-.6НAýoÆ%ßð‘+‘©gœˆÀÛ²ØÅ4%f­æËP1
-½ÉA=Å
- sE]©‰`ò6™=>î8é%ÂÐs>N´žô08òî~ÿµûcUð¤¾Á.5ÆÄ*¬ó8/¤zWt÷
-}r/öewÿ¬É¶וqk鿾ä**'âqùypaˆ'-K?¯ÙÀ–ƒÁØwMA»+²ÒA)u…uô1¬Ÿn…0ĉ»)¾TZ• §^ÐõbØJVíbsÑ`®¢•óäµ>–`$I(qÌø÷Ï¥CÍÝbÊ¥§Å.öBŽð¶/Ø×™Õ¢ß(²-aþ
-¹—¥Ž²*?ŒO,âî N¿$Ý#
-Û{Í6˜«¾·í'Íǰ8ÿšŠèKOå¬eŠ3«Ñ[s …¡Áà<‰–Ï´œt`Húýëu¯ÜØÊ_kŠ Ñaöç{­ ²\óJ$¢ÀmáþùKÒÁ†×~×ïâ¬H,ã§d.ý‘Þê÷ÉË%ú¤™s Öµû+uJõšÐÓ@×^#;¸r„ TÔ…šÝ¸?†sˆ«2ã`ñ
-J½Èðo˜Ðæy‰‚áˆÛ¡9dõváïv¸ü:²Ã¾ ÊISc…öQ1}¤u¢Ш¤×©õ©º¾Ô,#mõp<>ÞGìaF™c›ßß* ‚¿ØÁVÙh4gÅçÃj·¥FÂtšöÞ‰á¿+ÑÚ0§Ï~Ì»ž&±k²àæ‘éoÌø–Öæ(?ÝãäjÍÞè)Üæ!,^š
-ÎjªN§Ì‚¡êZ/(âiÓiÍmáú‡E´r•¿Þ`]© «Ô†-UuܼMøIA ÔæDr)|ò¥9Zvw¢¾2lÕÈ¥⨡gÍfs2ëéÅV|gÐØìÓo³’›ÌŠÎ}Žk:åwéf—FÞ´{çªÙÂ@Vžf#ÙUÞúµ¬Šˆj+·[i!ÊÁG1-¶5\{”ôã0Ò­…ü¦ôÝÖæêëùd”­Hæ Ò ·)Õjëy#ñj5¸ôŸ’LÒèÎQÚA£ug㞥iE7^å‰òæØo¡Hã…B€úÙÚë¥éëуk’)Iï>Á2CeN£©e¾hwLñ‹WI$5>íU£n2úé+çLR'CßF¾] ¬¼ÍªŽ”ùÀø¸
-ÓÇr„>›jì‚é‰é‡f´¸ñ°ëí –Í„Z‰uk&0¯NRÒXÃã'c¤­û~­?…ÖÛ½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[( <J…3Öoòˆ®v‹Þž(0YN3£ÂcçÍ‹Ç'fG$’:“ewwË6A¥8ƒÿâ%ÿµLöîT‘
-›½6(t(³rM¯ÆpŽ®KgEMIúbëv%6 bKA,ôI0ü!Ð=ÃNîÐyjÚÇ:`¼‰ŽêÀYS§ýKñ[ýêþ˸ƒG6°Éðáu_ŒÔ &DI{ÚÛúEƒ™º%É“€Óäê+žiàÄ|FÉ^u˜æÒ¨ú ((T! wì­;/A
-~_Êó-’wûH`ŠÛ
-36ëánˆQyÖ‹ëôrˆû}¡ÓeG;ž[äRÂtCHó,5[ô‡p}sÍÝé†áV(VŽïeXöDòõ(DðOèR~ëCž ~gGòiڽ߾_‰¦:·™×ûŠÈ÷—¿ºéö¨ßĶ•`ìýìëñöÂBÅëׄ€G)zŠ;¥1­ò·ò |–†ŒYëÏég$ôI)wËäVbY©V Õ>]Ú&øK<䄿pðW+xO*c.SÒa”}“œ‘þþF)J~)m‚P^1Þk Tù1¿{_ ];‰‘5¨Sù‹Üâããjð[â™cûMË·têÌ! ªpÓz Sª3y<0âß-iÔ|ò–œ%_oU°~7¥XíÎ,ÊÇÂÚvS_}Ü]LçŽ °½¿zÈ=®ûêšmjæj³'ø‰²•ždZí|ø.²$Õ@=‰ùå–ˆÌw
- ØÚÝ®-ñX¿?¾‘}ÑEµÞÄ)¦…‡!Ö †Žü™³&Âù-èo.‰ånUbÒHV›rjúx¥ÒP´^1,´àõd%%3ƽ.|<ÔçgÓI˜Û+<§0ƒ 5ÛVЗu™¨¡t?ÿ2ö‡Qü!‰@ú,cq!e¸èX:¿6°^ŠÌ¹¾e%eG&Ù&4.³Ž{[Š8u^Þ¼ÿcÉöI¬1¾‰Sã+&wTwe®Fa…ÿJC`‡üjtË ¦zÄétø·^â¹ ãX­.mP®ÆÏ°àòÑ×IÓÎ$þq[M¥%;fH)Þ&•Ž7¥fjúV½Iо2K0^AloH€k9Ùõ.œZÀȻ褴{¤?\„*&¥¢Ñ¡cò#{ÄuÈsuÑ`©Ïœø‰3£¼iÉÓ®™CÁÀ¥³o[ ;Š,mÍ1é?)r·ä£_0žžž~M¦ÔDþòŒoP"XúI‚ø<ªŽÄš¶•4Qr±Ñ—YW7¯ Zä*Ÿ?5T†¸EÉ¥+ÓÙV%Ù@ØdÅeÑ-M7êë®D¾¾$ÁÿE_h/Sìžul<8E¢]'0JüzzÌj:йf\ÖÐøpu”V!ùäT?î—ûò!Öî)êaäùÁîÇát3{íüÐþI»äÙ3¥eµ{^l&vãIÊ>Á«£v“ÖýÃ^–¾M_.@«˜*Æ€áM*DJwˆ}¯8þ”I»A¼¥Aî;­Ü(áT¢#¾¥. ª\bÌJ±¬ô‰d"7NÅ8뿹÷³…ìE$m_8Tâoݨ±ZvQÆ&MŸˆ6cqlê›NU°¸}™µ¥+H§ýðŒxHÄ„GJ¤JT…Ýξ©Ml}@=ÁV&rP‰’Ë™bäN_Ê-€}xŠñYpèŸÔEWÇ8í]eE³-dmÏh C†ýÛj=ÿè(3®–>é¦K #N
-Ópà>¼àèÉL¦!JÂ|?$°Ë h‘`G0oä´ÖÈ9Èý•í¢o†yI€û¥œ^i0+V+z¾'0óT*) )ôòzßyׄfË£R>•
-ßìàÝ'­³ÝBû¢ÉEyc;8ÂVl®?'Å|T¼GÒp´˜´e ååD×Ò÷4îˆ-JG‚…L†ëAù¦ÌáUe~­æŸwƉÙ”4Ønf‡ª×& ‚êÚ‰„ÑÌ Ó4m!Dbô£û ¡šX𰚴߃¨E¼½Çü²ƒ1PVQycáÿü`J¼°i¾"ïSZ¢î`ƒ|LðBú•Q¥f°ZæØ2o¿;øéžK•½x8ÊÙ_v6^¥5R{C0ã&¨Sæ§,YHt=­z!§­:|aÿ°JüÅá
-¤òøïlÑ×ù>Tq­@»È:…~Öõ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£
-çK±le‡MD¥ú¦—ƒG!úÇu5Wå’,:µöùÒÉk6ßx %LÑ·'ëœt/ÄCç䜿râ!•Ò-Á—:–ío£3mg±F8E<>pÂkÜâHn[yÖ€‚Œ=«zÅÙ©êg=:$bÛ&°§Œ.
-3•˜pÑܲWö‡0ÃüÂÌì£VäZÏ^„Ì΄|¸œÅ¡§` ô/_ò,fwµ«¿]îÄ·ú…àüû0 ¶pc9ì®¶|Ú[5ðX*Œ‘tUJ¯¶ÍkÖć¾ob–3ÎYEÎ{Çç¼ ‹†ã„7ÉtíX¥0ÕŽmÐÂxÕ†ö÷Ó Ü¢Â[Ö7`ÌC¬³i¯Ù‰Úµ
-ÏY‹}ÿà¯ÈCÚ5¢8¥>$Þ uh©@[ÿ8­•®êLíjûÐþîbømWò,_ÁÿöÜ×·•&#û%k_º¥êÏ©–$¶6Ôcä®Ä“ÊQ†)w€aÐ)üÖ–èóŃ5:•°Hf(NÙva‚ð/byÒóé|ýï'§°˜ýæLyk¦ÅÌßô4M(2™Ë:ó"÷–D&› ©š‘½Ù}~e&œòU•[Ö4É‚92åôBG(¬2ÁÙ;°4¸‚Jp¶6 6Óž¹X¨Ã€Un[кCaÐNdÆ4£ËüÇI”¬~fä½\¤†øö׿xò¥ÞÓñb,Šó7:ܘ‚Î/ó„¤ÉÁ:_¸|hfp”ëÞO³ÿ~î:··Gû_<–âéä§·—Rr”¿œ 'æ+Ð8ÿ Z</$ò=ĸUoßèz©lZÏl®êÁ‡-iÁ*Á«s+ið÷>"ÖÕ+À¾Fz‘@\æCȃyèȹì ïŠd[…=ßõCÓb ®™Ø@<¸ºñ;*Í’Ug ›.h"+DÜýJ
-¿®îÁùª]=þð>+û§ tEŒ%üQ8v$3 ;øüñÍ¡0 Ÿ(%ã¨ÑóGßõ#~ˆ?ef ò½Óù=EoGKñ=™
-¥Bõ&ä"ÝûipÈ[9l{6¨C˜•*ݳ¸
-é&»ÜÂoø0]þS*(:‚‰Îüí'mn¡ÝòÕWnÉ |Ur²30£à¼Ä¡tI•ßö›m0l×o§©QLÔR,óècʳ‰/Õ>‡QÉcöYUÛã w‰à;•žöz µ½Ží›'çð¿}©Ÿa8Œò’ŠPQß‘·Ïý4‡Báž§5nD'­7ÜmݹJÅ«¬Ä¦9cìa„à^”T P)¯ÍNÊê!¶k*H{RwÃ!-
-“jÿQ$6]ÂÎ׻،õU…ÙI´Ú ÑLÌÎQEÒýwu’å OËôiwïèc¨ä<^_®•XÌx÷ñoù 6âZiÿMmþ†Ÿùå”áƒ_³ÇšÐ~8¬ëÊ eSœbDƒüÄ¡ð»<¦Ý„¡´ï‹ö|·Û"#ŠR:¨¸ŠŠ´`•HÞ:ë×(¤ =ô!üˆ í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,®^.š
-v‹ yIF†ù‡VBcðà-ÒæÅ¼8šFaëòØAJ|ÿ=5>ô³}œ?ÔÒˆ½ XV'ëæ/¾9;kEséjãLÌ|ßã÷;&Ô[û á®ÂÒ_6B¥E¿Ê®¢wÀ—Õ¼v)£™µWåw‡XO;zpAn…‰Šþ»Ö41ŒO>$,_?¿2’›mÀ4e\Ú¶ÀÝýšSÏa ãåPWbeGWý=‚Ûsõ8ülÁ½]x†V’²“5!Ù1S€‚7+ý‚œ´X¼RUûôˆz¦Þ¶¤8;-½Ç0"ôv »§ïp.‰Ä×»B¨õNåyÞÃï§óE^É«»ìÅ%çÞèÙ êÊÕŒâ›çRææ”òïi ¬ML÷É87â诺9ýèî¤NbÝ2t‹WÝsT{´$8˜ë§òüŸ-ÈRÃtGÓh¥ìÈJUSÉU°Kˆ+.´By`Ö-ŠQ3gföÄêüQCp
-c2
-øJGT˜âÿ§:ÿgÂa
- œÝ£Àá²&<"ê¶v| `PÐr‡•þÉï(*È?$ºÁt÷ùG¦Ò=“®ÿŒ·õ:Ã,]9Π,2wAÛÍýGu¤Vä{ÿɉÝ…NÂRWÒF­¯;ÙߣˆiϤUqÕyymõtÐЌ͘<d1b‹ND¥(I0}oŒ¬O@Ñ)méEåª%5´n¢ÞÙ°â–Ÿ „Ó•›Ø-Ö¾hiÔÕ§¨”û|)ÈÑnÿ]:ú›Œ#–À7£“$ž@/4ª\Íy(<Bf¦;z”šSÀ¨×¶ä^3^ö¬ÁýJÁ•6šµ^áñ•îór}µúÍ£¿ÈFs4™>‘F¿}ÑFÀÛÁ‡J¹º’|µÖ¿¸ðZ»l݇\šµr­ü!NTã“LW
-wZéðÑwuɾ{Á÷Ü< Ëb¼ÖÅÇ'Iª0
-?å¶ ÷Ð9ì,ó
-޵a‚BØÇ)“VÝíµl
-Cp?zõ ú+¾¬P\þE8v¿DœÇ<ѪñqNš`wÍÑüûkàC¡QP]š°_œ'ðaÛA<è£y<glÁRÆÊfIg»r$–AÆXEœoŸ{'ÄiÀZÖ´ïX<(£ –²®‘mšŠ7}öÇÿ0\Æ‚ryJgi+‘cׄ=,ð¼{5ͺœGÚ°EuC€ §Ç
-e1ðž6¨ÒT‹‹ìo#ÛS·tЬ3Ã'ãé7+>kÕ¦ sûÿŒ–Á¿ˆöꮪ={mÃÅyÁc~ÿ¶`ÙséÉø9´œßçÀ©2™uIžµ7ˆ á¶Êu‘ôÜ/c"çí~_OIïk8{µ¢¤:¸Ýô‡²(š÷\QßZå5(²îÿr¿óÒÆÈÄf4<W=A±æ!ù$sF¬E‚û$ëz=nÉ}lVJG•XG²a
-ºr”ýW§F»@1“ÛËí§BßCßMdÁê`É#3ç¶—U-±ÿ5e(¿g%ê‚jUÙÊ†ŽµÒ½&?QÖú÷Yô
-Q´Oè!Yè…¸‰ý©‹øžÌzA4`(õm —R¾_üÞãW6µÇA:1<à#EY’‚vª­ÿŠ“ÆlâÁ[–n&ñÇm̱ QO·K7ÿðÖ&0ËázH»/s»éZÄ
-„ 0`I™4#pv
-Eàf›ù*f®[u÷z‰¾!9ü6ÌÙ
-CÒ3ÉwÙ_&'€›ÏìA¿.﫸E ®wð“3e©g±T×ÎŒ!Ý­ÛçC4uº¹už×Å›ý 4Þ7’Õœ±¸2¹¿3½¾„c¶"!4¦ZŸY•›S>Ó¢<€$Lc'occ”÷ÑçgØGwtm†ÉEAË9Ë?,râÃyç…ÁË@ã/€7-PÕYòÄ»¼×HVìçÙ4aý̯ø¼!9²R‡KHàP'áX|Àú[
-]Aîú26ûZSQûuR‡èᲘ¦)95¹¥#²B=S\Ƽõ v·CW×¢)&wÉíâÙY]>Fª¤º0F
-üòãVaï‚-Â}‘#Ô–oÞ>ã·8'…SJ6¨î£’s¹5Bùè,͈®x®*·‘|â¶\T˲PÝ0 œB}±n{ïËPò#í½·/¬o‰.4Vz´cš×ÌÐû_t§ô–¼’ßÉspãMüƒ
-Âý,š«»omž§t~®»MzEåQÒZEƒ5tUàÓógó´iN5u}3ïÌì±ONâiZù
-or)vúm˜„Æf|!¥œ*¹Ö~Â’Y]µ|þF¡œV
-îêõ´ì“&©jåN[N/¸†³ˆ=õÞ~¸kÆ~?Í¢ðH1{Ì)ê++?<rnþ›ò˧{Yb€œ¤ 'é0@¨u–-ä¿ øàðDxÃÂ"‚aaÀæíÀiendstream
-endobj
-624 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 33
-/LastChar 125
-/Widths 1346 0 R
-/BaseFont /FNUUJC+NimbusMonL-Regu
-/FontDescriptor 622 0 R
->> endobj
-622 0 obj <<
-/Ascent 625
-/CapHeight 557
-/Descent -147
-/FontName /FNUUJC+NimbusMonL-Regu
-/ItalicAngle 0
-/StemV 41
-/XHeight 426
-/FontBBox [-12 -237 650 811]
-/Flags 4
-/CharSet (/exclam/quotedbl/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/underscore/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 623 0 R
->> endobj
-1346 0 obj
-[600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 0 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
-endobj
-617 0 obj <<
-/Length1 1620
-/Length2 19156
-/Length3 532
-/Length 20062
-/Filter /FlateDecode
->>
-stream
-xÚ¬zSx¥]·eœTlcÇv%©Ø¶íìØ¶mÛ¨Šm£b£bÛ6»¾ÿïÓ§ŸÓ}Õ}.ö~Þ5Çœcb¬µö¾xɉ”éM쌀bv¶ÎôÌ L\
-´¶³·Ú:ÿ¥øTÎæ@€©…5 ,¯ ))' —SˆmŽ›Pp1²¶0ÈXm€Ô
-Ë(gçü7%€êÿMe†ÿ>‘ÿ$þoø¿EÞÿ?qÿ«FÿÛ!þÿ=Ïÿ•ZÌÅÚZÎÐø¯ ÀÜ1
-Hk
-
-\P3ÏØ©®â%ª«Q¶°sy1*õŸƒð3›Wž®õ;7 K³y²mÇZÉh\HÐçãîäÑ|Àÿ´_˜D®á!)?¬oöër$q0>°±ÏO„<X)
-V¼TC ÝÐÆÕ»ýÈû]…:€n&)‹ãº}°Äk’…ÀUꜹþ®æSM¼^ž“O›@õò.ŽŠå†"5sÝ€ÐV›¿eXšÑÎ I´Üû‹#k•ÚÖ®§alaUÑbPh¬4'Û´~ô2 þy×DEã)
-É{<D¶¤ }[DY¶¤T­±ê-úcØ'Ÿ[z‘.J(›ôb#Ö¹_{—Újå1ãysœÃ
--0ñö® ˆ(É0fö‡óÁ0–\Â9Šüµn3ÿ>J¾™Ê
-Sò¹ °žô9w:%x?RŒ¾÷å9:…œÖÄáöýŠÞ‰Mb*x:lô -1Y+„ -0ÃÂâÒ
-Ú8äWó <'Æ–©läÍM*iÞ3E2
-r &Õ}Yðù0qLW*€2V:ãJÙ™³œ
-9O¥Ýò“O.2&ÀŒp&'¼(5
-r ØàŽ:—UïÃ3;&^ƒ H¾÷Ä¡@\³cöW¥ËĤo9z”ðq£9ÊÂɶÒ]èä´|Í6ّ͸;këá²êäQËÖË”W¯˜›}M;¦ºù“
-nƒ¡”CÓÓÚëíûDÌuU£–¡b½³i»´lÜUšd¼mîRiSgC¡-kÖ;Uõü§3ƒsèº(sT ØÔw{vUˆ?*?Èñ'f27ØÄbLà×I(~o뜫’°P/>³ŠÖ²,9Cæp6ª%"Sš¼ä¿Õ
-ý>Óv¯"žKa†­dLWA¤;a# >ûëöêÍ¢®Ú:¾" )¸-!Ó#Kþ=ñ]õû3¿fö™ † › [ý9‘3Q"mn±`÷Hé-ɦ ‘=]“¤GÇëÎ'*¨j ¦—œ1*\
-Úâ\ô3†JÌtÂD†‚V­¹˜=ŠÛXüh¬‹:L›m8}äœZ¢Z¥UŽâý“kZM<íYáʦ¬b”Žnhuë²fè@–KüT‚GÐ_2žŸ=\kAõÛ;Ÿ¹š@tå|#Žì¸bK]˜ÑÕa1%­• ÓÞÑÑgñ÷½«É®,Ï|ÒKp(À·ê»²“£K ¶z7÷›Xi!P0L#‹
-K™ázŠŽï“ÕOG‚î
-é5[¬xv”C°‹S=ßPWâ±Géšæ­iúaÒ~öäÁy o¿ µþ¬ís@q+@ñ›¯0/<ϵº¸gÆ+útÊEQ”§ÎOƒÉ!qÝãÉ›¾e“Ø;E†èÏð‘#VÃèlµÃwÛ‡¥Y¿ÜºDöâã§7™“m­*<„"É Sé0
-$¦äh]™!î;Ö¦xµ;5rÀDW’GT>—0Nzœý¼ èè8FÃñ;Ó‚ñ-ßFIüëJvë~-bñ¥=`°Êvýlö¸E‚æ!Äímâ/º=ü1Ÿ/ˆÍX)²È<wרߣ¶ã™÷‘/‘Í“ì%mFÔÈøDÉÄÄRߎpHÀÒµÎÍäŒÊ‘ "X9€ãv-Þsçþ æ¢ Ô'ÕžQ›©(Â8ø„˜º“lŒO!âàºBw‹IËd !¸_a§\ünÉýùâH ]«y8û"VºÔìJ\+;£´ñ¦LÖŠ ÚhHõtñ¯^v÷Ý}²p¬|ú•¾<îög—#á5ñ¥;QÛöNW³#M²Ž#í³?Ð_ÀöÐGR¤0\.%B
-À”ö¢+ˆÞ)Á÷Ð?ŽGíL€êd´-1ucÊÅåâzh4${Gg¬Øÿò¾ÆÊ‡­’NÌå¥fdã€U{h%õIí®Ïyö¢˜Iw¯e,á#ooó§–Êù’¬°<ã5quèËîЂsºêJ&ÆŠÙÈ…_+LCi¬Å»oGö"ÑâÕ2þn¿ÆÇjPÁ¸:’¿¶XS0`ÕÔ*‘>Ø“}‹ÏÔ»•…w2øÜÝO1<¡½¹†’Œ8
-+ˆC:S¡€5‡a|°k÷gHƽ´)2t•§©oš5O}ÞÉ({9nŠ5\·iøH@O°·ôŠB‹#"—r;uî?Û܇X©>pŒßú’•SŠÂòq¾Uãt´} õåùb#1,Z±jçX@7¼ •§ÉZ—rc?™”AUäûÖ»+[ä»zÄ+G ÓÖ_ÍÎðv_Mól ‰YKW£ðÌ”‚ 4vÚÖ©.æÛ™@ãÄÄý~´¥Ôx+3Ê
-Wi7í”rU¾µ;a‘
-ž¾\’’‡†@™´DÍ_7w[}æ˜ã£1™dªÓfGÑïÙä’e¸¡cî–\‘Aú”÷G¨ùøã¿ÇØs£â‚|cˆ¶zÅr}¿¡5oÅ_¯Þð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^¦È¥Þ#©ì
-ºR…ÒBnÖÂÏ¾îÆ¿
-y5~Psòí>x7ªU•$峀ݪü´vƈ´5@àƒ³ä¡ïý’8JôF~¨FGÃü‰0¯jiô…q°…Ü€õRVË#»“é ¦mV!‹·ä0B0IÅOا$—Á4à¶]ãNáÙv™Ÿ—³#1z l»,¹ ãÄ5#\û‹zQÜ‹Žïi¬Ö#nÝÕ–¯µ(¾U¨“„fp/¡Esªjˆé^©n6 „.ëÖ^+"®ÏeV¾¢
-8ðÞaí"Œ}9£tÍ\ÿ*÷Ü^"ªs/ü.Äöì0_
-ØÁ({0/“GÖ-m«Ôá>ñÔ‚Üb¹ýQ»ðÖk¦«Ô«sö28¯âªV–Ñþ$JYÒ3ñî—ðZk‹w½¥·BJ¢?mÁ¢`g?%uÓÂÄ9§‰.‘älʤq+4ìcXä_¶=né£fóѸ5­){_Ð'Ëš”sO+Ú¢{~Œ¹#Ï\%5ɸ„êdʺÖZ²¾`•[%UP+âóJ¬~g½U8n( ö £ó·( £Hž7á$m¡D¹µhOëHíW„;hKÈß8φóú †H~Â$+·CO‹-yÿB©˜R"g[¹dIP3(EÙKµSÄcm%==„ÕÅ»ÀrpÔÕRÈ q¥6úà +Ú,ë…4|¿‚ ¯Yì-EI—m4’ªiE+D¨ZD2£BÌ%Hݼ³‘ö£~·ã»]bË 'ò|ŸÞtÿ½¢P)¯…¹'ÆÝ ±¿IÒ/)>€j¸u™T-gí’;l´Ë'ÿ(sQÉd#r¹ÀFá3€m°¨^LuRñom×7ÿ\ _+3‘ñ›‘¢Ä1öXá
-^õÙ´ bš:®Ý~ì
-fÂéN~aŒ?á°¼¦‡·®_"ÎI¨}˜ÇØöµ`u7ñ›9“p°”¿MûKJ¡m
-|•nýÒˆÚXýyaݯℎºé„J‰ÇI^}m èD„·_GN¢¢óÉRs±ì}o†|
-Mö¨Eçe€z§½Ð@ñômú³”ÞÇŨ¶¼+D쇕a<¯‡»A´’– ¦r³S¿ÀóI!/LÕ¯GK^X"âQ¸ê9µ¦›µé‹º
-Nl}MI{kIËJß.¿&ëÆ±ÊŸ˜„èºã«mL²´,\…½´PνᆤyêÑc„MJ/›ÎxÎS,‡ñ4C«uÌJh[Ž0ïoZËëûo=‰XR¯ÒFl0JøÓŸ;ýQ
-0ª‰ø³»À5F%n{zY„v¶näâk‘†,¡œÊ}¬©©ÂåzŠ”Ý/ð)H\
-á ·óGÿ-ãæÄ`öS¢ç¤^wS‹6ÁŸ ù×õÍÔýˆ_h±rà6zó|:èX£«~c&#ôÈîhzó'(Z {+<†r¹P­®ï’8­%·´ "™[n—hsè7ßC'Üo³íV¤æYò›Aè| ÒHn޵ɳ“&<ÆÔâA—„w#ŒNH
-üzdùp»ºÇºû=Ì3j<óòSàìlúÊÖƒÛf|­µæÎ÷eìgûÝ™0±H{4Ê
- Èo÷mxÖ ¼þÒ‚âÌ×åBÍ–9Nhé#Äy»Ò«Ã{ÄÈTŒMmS
-î:Ó¯+1³¼+–ý0§ŽÕ’Ä:[”ð‰d覹,J„ŸÒNE‰Ý Ï q5þ&ÃîVwmÌð¾ß;0´Œà0»’Âóüֺĩd¨¦M ; ÛMM;4²¡>š/£û3/r3¬Å#šÙç¼ø•èwW˜Õh)¡ŒÃ²Ïæ¼³öFlò„ºWR†é^mLÉŒÂ{ðsLF6¨.ûžŠè,¨êz¬·fo
-+ý¯Ü—Û¦@¼kn‡–°‰Ë-ÏvCø +W²žkFV옘r ºË^ø¸ábçvœ»š±¨K?u4ŽP ¢+‘ý—ÃT»¸ÇaÁéçytQ8árj”ôH¸ ¥²b®I5íÀù¼Uù¹Á[صuuH´éêìœHjûµ{Ã">gf'y»[8.¢|¿lA˜$‰æ¨èH!K¿»Tl]²Qã­þßI
-»y¼¯ÈŸùt:Ùå6
-ðš$3:ÁHªËÖx×ÊÐùŸ'O&©>“ús)pCŠê–¤‚埌Ÿ÷dðqøÌûúçlsËçÆÓðž_pUwôûß;^š”ûÀ¤à<“¤TµzŸÁDEdká6]A=5ìƒË "ûDMOò䃛½%[êÓ×*{=F¹"ï£Ã?
-‘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
-¾9¡¶çÜ@Oƒ+'ÔÝ{Us~Íxeoèí×}ÔûhµÙ<rã.
-’/=ÿÀÔèÍD±Rî9œÓd -(‚*’NE畲é^:,SÄÔZR·âj ɺc ]žŽ’´’ø¶V ¬µ=yf§F>Cˆ!AÿqøL•z35G0ÿ3TxY¤ñYS“Ø»äOö–VÆÅ}¦×ºXGˆÈ° vŸ8»úŒgŽŒ‹´ëuZÛ‚ì@ËŽk¤¨éN“ú|›EILœpöêñïDMfG ÏSk‰úºÀWVú›õˆ< é5§ü”Kù iã“#OiÝcäM²RA+Õ\Òuä8/)ˆ3ôžwû›eÈëDñ9æ7 «³‚Ü1µóL8”(µåD:lU Ùg> ‰>ˆ“9°-A–ãÒ
-é3ž¬¼·µ9ŸœJ#iy£LCpøWØJñ¬fHêÐCÚ¢ÀVÑ  é^¤Ç‹oCÔ‰bêb΢Bê7A”$qIË5iÔò`ŸØLtuŠ·ÂÍ:Y‘¨:EÖìò¹fì…žÔ&Μä? FQÈ
-åF¤zÍÜ-E¬%õ@ÄÄ:ƒ}Ñ„dœ­v4KÿÈ«Ùø€  ìîrµßõ¦…!Q<u¬:\ƒ| 79l‚MVþ˜ ªfç·„”
-[‰Wèûáù©>«OæI¾¶C‡KV;%Œä¨ðò%rÚàŠ™"ßj@d+ËÔ5z¢fvrÃÕ¿uõzÆ‘¼Å–=]çÿ êÌ ikðšv)ÝrrÊJ¸
-¥¼¢ÏÉyÓ½¼Þ2Ÿeþh
-,ÏsË(ÙÁ½Á.(s8…›oAΖ¤*êæî¶}‰ý'·—õ*ÈQðUXëjúé›úŸ8æ!õ5*|÷,ÚÜ­GïËopŒˆz´¾¹øÃ£GRê òù«M³t³”–ŸLæ At,­c…Èc¾7]Aèùù¶£ÉN€ºÉ
-(‰ª¢û.t<bÎ2o;ˆ}¾â³±Ãã¤Ib$æ‘"­é[”‹
-Žìdh
-´D¨1a2(iégµ;x{‚7\©A0‚’yyáóäVv¾ªÙ Dâû:MTƒÔ’í)‘rrê7׋?, {œt˜O3q‡©r¥…Û”çÎÕÂLéÄ*ÝûÌò¦°Ã³·¥À1`äuÔ›¹$pÔ…RûmJ
-‚¶=ÆŽÍÉnù-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ë%
-EU¸ò€d+uQꞥz²™j#™f‰«
-ÊË'5lZ)c®wŒë¦éCD(¬G©ãe²µP³´5~PÏi¶L™æd!ɱnO;Ë}i¦$²AbDµ[¶¿o3˜g³!©\#ö³FU¾-Þ¹ÿæí>ú9¤ 2áUÉkûª»¦|óíDIÀÙÞ@ ¡Ä
-»_C¶Mãl@â:}j·@Ý´2¥½Ú²•¿…à9SäfƺyJ-gj"ôøÜû4A±ƒÿ!=Ò]¥õ"/ïäl•N»"ïQE¨û]'œÌ¤O™|…KÄeЧXšcõ»³öûDCïJMÁ“„‚b`úÆÄ¦L$ýš­Á­·™³4"Â-c ®'•–äÇvŒZ•RæêêOÍ/Ø5¾¥lÌÂïkiLÄ Ùf°k9rÆü³š#ª¿'•Õ
-052BÍ6¸~ëϬ*“Þã“׫BL^x¹bÂ~;ý°^0æè Z±!拵Å=>÷1•/µþÁ…Ÿ9y.×›kôÈ ÷=r¼†=Eq‡q·ýçžáБš? ÃMÒ ,:ä§j4rŒ E¸ÅlôÍoÞ¢‡5fBµþFo˜@ÓÒJ1xÚ>véÙ!ùl"Ô> <|qbŠúÇ”›_BŒ=÷úÖÏ#ð4Øvg{ÎŽƒ`#µ“‹ëEB1útȯ _y
-ÐV×p™%V ˜5ÞÒîm08ÂDyTø¤—ûAQe
-.Ú¢6‰Ài¤õ™qUÌGŒOËç”AÙ•B¯ß8¾?‡6Ë5yª4VBô@ý¹ŽIÉõ*'Çïy•È>qѦB-z¿:ÙýW– ÊW‹;_ºdð° «&µ#h™8†ÊŠ®Išëmw÷ Xg =sSi§ÅÄ5ãÈôÓKB?Ó›µTÉÌ]~ð l{ü(Œs`.¦¼o]çè_“3x¼ê_’o9å÷×Z•“ÒêȨd6Ê
-$bðê0eN½™•â­ÉŽÓG2f*Um‡}÷WEySV8!#CŠØ§¯é(¥½óÁ9¿;-Z[3ù*³ôVžüzãa¬ïÆPcÑ
-‡À/Ä‚u‚’í|£.襡=͋¼ÉÄ38:¢•¡j-rç· Ã(¬¨ L8;çFû>´P]bð®NX1ZÅy.ʰ>®®ªгF7”åõÒ÷ý!ù†’½²ú®Y ±¨Ñã?S×ü‹žÃÛ¡)ì­(­ý&GÔ‰]¾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ó¨è©~°ë
-ýqž\Q\²Ã‹±ûÍ—˜lËûâ¸æ­p h]ß,‚Üžúòš¿Â6Í%•¢ð“;‚)¬¼*¡¹ÀÜ'{‡Éõ(ÍÜö\CÈWýÈîÆ¾ýÂÓË
-†bJ6¾öÕûžõpIËÄZõ¶Ãp%}Eœ7*X§ïcáÄOÊòµúf3`#û¯é9 vqñ„§x§p b%c»šÌØ7¨D³¤ùF|X1/§¬ñFÛÌxË./U­Åß4
-ˆ~_È‹õì盽ׂR¬£ U«Ö퟼¿52Wëýà9ZOÚ$aß¶mO¼ësm@ƒÏJ>4¹5Êe3iöÅlê<$ê;4¼&™’ãÄÙОiÖÜtþùê;^1]öÐP½†Ä
-¨p9¹¸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Ð’Ã
-¤ê
-¾Õx;xŽM„}ÌÅȺéf‚øL¶Ãpr6Ë(ÔTà£'ŽãáÜ–½‰Læ‰=¼’cÉDÛ­¡“â-‚¶:àž k„Τ/ýjº‰/®ÙÉŠaÑ¡&©£Î•4#¨–͸ÒÚ‹¦b-ùÜu¸ò]ΚÊi^-6Š¹ÇºCè×Êu} M={ ØÁj"¹/¶Îž\].¼ÜkYèä$U6“ B¤l÷Jß"bÈÊ";„Fuj§&0$¼ò/Äé»c†ÈÌkñéP/¾I”³,[R!&À$µ'¾?Á¥1Öaи¡€f(9 ÿ&œÐò
-EÉÃc9²ÎÄS‡õ<z™,ÿZ^‰»;ôAÃÆÓýÕÙRÞìÕËï³xvvZ6ÿ)~— —sÇéŒm¿ƒ)çÁK͘Ã"¹æhae™MH!Oî1¾ÂyxÅ aà…P£ÌMv]ZÞ…jTH™œ…ÂÍbdù`7ˉlO˜—K›‡h”¸%Ì›uŭ§ë×½'EÙ3ú]ö@ ñƬ‘aÊY‹^ȸ"PÙóÂ(¿*Î8³h[d)yLšOãg°Èž f:Ì>(.&{>AY›uS)/âȈ†óôi‰‹V<èXÞl˾)jÊ22ø~ÁU؆ҰfNmi%:iš~Vò]moòãªkYÞB5òûõêÃ4º8Tq$1òUé¼y§lP6Ö_ó½c^yÝø}·øš£”™ãD6­Ûˇ=Sœ/ƒ‡ªKȶº ‹áÆ#JŒ0âüØoÛÖmf¼9ŽýS&çùÍ:\Ã<ä¢B©"H{f¢y®«Ÿ· d¶uzýØüøD…ŸbÝØ/”¿"ΦU_³µ/!0?Ù”Ìa£zêÙëDÔH¿îBqi›i–Œ`HËöCŤÇLéòñK'oùºæ…–à@(ê×-[„rh–H~BV´Ü4è¡@O€h‚œ±¢¶—ÛÛ/f¦¨–‚p[—È"„ÇzúQòüÐ;­­äš/èN@öµÇ¶æwÒ$é;ÉYP›:r=Ñï9„EÿBx'aËdzI–ᵇ^ÕTäæ‘¨ ¬-Xœ¨ðoOòW<[z9sá›p ß:—¾Ûl~(æ„B²b ø>KƒSÐþ2•ŒûÄšåêx꼄JýX§;{B v
-
-¥&ôÙÝxK”ætªü«*Ã}Eñ($ kbAk²
-Íï!VS@ù¯b;8 ~‡ÛUgžƒ¥ÎŸ“ µ~ÑÆìåÔú<ÂŽ}¸K­¾jﮣj„Þ²’ççIYBÀõ<K®ß°”—ÚQ…”S" Ð<™—ÄÇÈãÚnÙûW-úÕ9ôTæ¹£;4E&x%v˜ˆZ Éô±zÏBð­„¿‘Á;Ž)ÎÈJ…5ÓKÚ(1d¾>ðœ{ûZ„Ì¿ Q>3¬
-®Ã±U ,m;Œê*§Éáèï 7‚§¯¨»×¹n[¡Óˆè¶bÌž þ$”ŸÏid÷cvXqh@ú‚DmÛâÄWÅèôsÃù£í«Ó:
-kÅAž—v|étå@òó0´U]¼Y¨ß©ðYôsÚ÷/þGûôý…ã8pÜÂÙqöÞÎ&ãì¬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­@ ™˜À<xc´á°2Š9L1.Î33µ±¹sWk¨gç@B¯8ßô+£@™Èv~¾”J©“öJ°ûZ€•0ÉDjëœÑ¾õ0õx9(Ç©Þ8× }ñžûð» Ý<#ÃÛƒ®ºX6GG†ßd±œÎ
-lÅŸœ$f_dq_“ÉñøC–C'O§_œ„Í¢z™À7Ͱ5åAƒí`EûKࣃ„>­Ò„rÖ:«Í·ä—ˆ•Ö’"îJìK4åäNϲN^U©çuÃ̼ß!¿|gbTM‡H³™¢" 1WK‹pr)*Ó:ô}øù&X}¿³¼åð¡øúùDÊ’‰‰à†£/ÿ©“€óD-z°,¢L“4G{¨îwN
-Ã磵E˜±Ÿºùxünôqb ßd˜[<ÇfÎ@ߤ»Pª p§vŠ,à ÈY·“›Úˆg”þ½#©Ø¦”üëÈ`…>—âI¼¤®;p»ï“‚ºúÈÞ˜Ôm}*Ð÷î7zžôCDuQÒé”c§„Ë/οcÖ”N~?¾¨À¦Œâ~ Ò®QR__èeýrå
-@¤õÃo_U¡;¤¢æªe?Z*½¿ÚOæËͦcZ¢6zÓ*î
-€mK1”£»ãß:¹<f:µ¦V.sF»øÎN®õÎîÅEQ‡gŒ‹uà,¥vz­!ìuS,ñš#\¥€ª6KѯAÃIá)è˜SX1ïŒ~†‰<& ;Ã] zÜ)ZP=ëN¾Ðºg¼)Qµ°}¼>Õ˜z_#å *’Ðs,b½“o&‰ð]ÎÎì†Ò¬¦{˜±ãxÂZ©–\å.ÉÉq™5í—]Í_ãÓ~w X~˜½UÖ"bg¬%Ì—ÊÉbÙ¶Õ¾VÂ3a¾$þ—ì!íL;ENLãÖ[µô(ÁzŠþÐÞ :\¦oŽìÿÞÉðdþÌn¤j’Pïn‰“Ì{:}*PDvŸw*[ð@9‚
-Ô0a¸­¦û[ßÅräÛ%Ó\qŸž]£÷Àëð|O-FêkÞ‹³€'‰Qö.ÊÂTqëÚĵ¦Îš)RžcÀ¾ôߨDã“V¶¢Ååž5yÔL ùR„wOƒùͳ¬¯ãƲ¹ûx¥óuj2a™ dêMèaÁxö³]&e9õ};ªÄqÜm–íʳì $j´’V¢_yŸ¹6€W 3‚èíRõѹc§EsšN1}œÇ‹”Çžácž!\°­1£,,ᄬ¨\XMÔ›ÖÁ€DÊŸ&ë«~9F=Þ'KJk®
-ÀÝÏói<ÐÿiŒö? ͪ¾endstream
-endobj
-618 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 2
-/LastChar 151
-/Widths 1347 0 R
-/BaseFont /VGVTRI+URWPalladioL-Ital
-/FontDescriptor 616 0 R
->> endobj
-616 0 obj <<
-/Ascent 722
-/CapHeight 693
-/Descent -261
-/FontName /VGVTRI+URWPalladioL-Ital
-/ItalicAngle -9.5
-/StemV 78
-/XHeight 482
-/FontBBox [-170 -305 1010 941]
-/Flags 4
-/CharSet (/fi/parenleft/parenright/comma/hyphen/period/one/two/three/four/five/six/seven/eight/colon/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/W/X/Z/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash)
-/FontFile 617 0 R
->> endobj
-1347 0 obj
-[528 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 333 0 0 250 333 250 0 0 500 500 500 500 500 500 500 500 0 250 0 0 0 0 0 0 722 611 667 778 611 556 722 778 333 0 667 556 944 778 778 611 778 667 556 611 778 0 944 722 0 667 0 0 0 0 0 0 444 463 407 500 389 278 500 500 278 0 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ]
-endobj
-607 0 obj <<
-/Length1 862
-/Length2 1251
-/Length3 532
-/Length 1862
-/Filter /FlateDecode
->>
-stream
-xÚíUkTgnõJÀ+Å€€¸T
-æ2M°hZ 䢘ÊLÈ@’I¢ TpE *TEJ+¥õ‚.R.+
-ž
-rÓ(˜€`E.º¢î€zìÚŸ»¿öìÌŸyŸçùÞï™çýÎùœxA$–„}Q™‚’A&àã´¤ ™JpròÁ`H ²õf §'°”Q
-*cßP;`LŽ›œq“Ÿ
-¿2ç ¥ô]–£€$ˆ€%‹’À
-憆¸¾žë,Ƀ™b³:¨oÕ³5ø¶ÆSÂN%S© .Äß7_üw6ûL&@…ˆ,
- Ñ=
-”˳gÿM-Bð‘Á°
-º:PWjtauZEâgǯÿÅìis¥±Ë´!ì|b"ÜD?¼É!JQ:T¢?»WKŒÑY.ðÚo‰±ÉÈúrü˜åɳ™GËÃrwÓëÉADuJ¦fÞ ×•Cm\Èâ¯õ¶Ìzìî¡oV¬ê_‘ÔlqXh`o=^7Õ×a¾Ø%pŸ‹ãRF× ÓÞ÷—Õ½÷Û–O*¼¼F0zí–‡G”ûf®Ô‰¼Í#Ç¡É{¾h‡NçºiÕxÓ ßi-œ^ÈͪW=°ÏpLwzÔT®šÈL´Møýj¬)ñFÆpvÉÄW\3B½=ûRïumêe=%g÷†:{?»æ»nâgK›]4EQûÜæœ<oÓ}/øç*0ý¥ÁtiYâ“r(¦ø\ýúñqß]X3LÌÞEþ¢úÀ–‡¥´æ¬@˵7»|rž1 h5ɤù+ÏNj΋÷Sˆ#î­×7”ÞÝ-}ÏÂæÛ¯6ñϲ¹ï “ìÆ¾=—bifŽšv†ÝÊ/Cžqæ–Ï—s^"?vj÷p
-³g'Xu¥­¼mÉÞ–ŸÈãdZD]L† ÔÝžU. ‹55Vçi´Ýö¦=úÜx+ƒ¦RˆšOædeóø›Â¾0IÚÖP˜ÊçòÝO*–¡‡V/K5¦qö6=íu}, 2gžj/ K·]©†OÕz»O›²Ê-4pth~ËvØÉÍíâ#iyâøÇ‡s|šÔ÷ÇØw‹F“~Lpé5A¯nÌ›Hô·ÙW&~¤çÖxU—Ù;»<G©Ñ;Þ˜&µE?ïñŠ[DÛÖ·iöqI¹Ûã†x&–ÜrÍ/óäd©Qì·Œö<§#f4&ÿŸ•ºqY“ýc^68¯kùêõcšŸ.Ü¿úG#ÍEÙôí¹ÍˆÛãÕÁK^æ„<je[|óËÉ0㳸ÂéíÆ=®¦[{šð~Qê{éë/‹[Xtñªö¢–ìKjmê¹zÔƒ®ÛygL©òò°²öŠ×J Eœ|0W^Zzò#W-8cp¾WU_×Y3Ñ' ÝÔU}ÌœÆD}G*¼Æ*KÙŸmü5‰®íc=ùe?åeJÇ“š&•]Y(»*ýñø1³¦—Ëy¹-ýÜ>+Í”« ›V=O¹±dz®ë±]½^4uâw•gã‚‘P]J‚§E`TÁåC‹?ÝhX÷B\ôpIBºvà(›˜² ü–aŽÁxÀ.–yK˯&×É<ñkÀÚ#úô´éËŠú/ÕU¬ )ä45ÞaìY4Yÿ,ÅÙðMNÏq®}I÷óc•
-endobj
-608 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1348 0 R
-/FirstChar 13
-/LastChar 110
-/Widths 1349 0 R
-/BaseFont /VAUOWV+CMSY10
-/FontDescriptor 606 0 R
->> endobj
-606 0 obj <<
-/Ascent 750
-/CapHeight 683
-/Descent -194
-/FontName /VAUOWV+CMSY10
-/ItalicAngle -14.035
-/StemV 85
-/XHeight 431
-/FontBBox [-29 -960 1116 775]
-/Flags 4
-/CharSet (/circlecopyrt/bullet/braceleft/braceright/bar/backslash)
-/FontFile 607 0 R
->> endobj
-1349 0 obj
-[1000 0 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 500 0 0 278 0 0 0 500 ]
-endobj
-1348 0 obj <<
-/Type /Encoding
-/Differences [ 0 /.notdef 13/circlecopyrt 14/.notdef 15/bullet 16/.notdef 102/braceleft/braceright 104/.notdef 106/bar 107/.notdef 110/backslash 111/.notdef]
->> endobj
-599 0 obj <<
-/Length1 1616
-/Length2 24746
-/Length3 532
-/Length 25639
-/Filter /FlateDecode
->>
-stream
-xÚ¬ºSek´&š•¶Í•¶mÛ¶mÛvf¥mÛf¥mVªÒ¶}kïÓ§OÇé~êÛ3bþßÀ7þ±VLRBeZA{#S1{;ZF:.€ª’º‚¡¡‰¥½ ­’½­!௘š”TØÉÔÐÅÒÞNÄÐÅ”  nj1501999¡IÂöžN–æ.
-0±tv°1ôüû/˜ƒ“å¿i¸:[Ú™ÿW4
-õÿ¾SÿµSøË½‹Š§ÃßÔþG)²ö&ÿóðнÀ›–‘ @ËÄÁü÷Ê118Y˜}ÿÿbü¯³¬¡‹“¥@ûoÙ Œÿÿ?žÿ:éþ7Q;c{“¦EÙÅÐÎäï€ýOÁ?jcW'§¿¼þ{çÿýŸçGÝÔÔÃÔz}ÅÞ˜;Ä*=+Ã¥#odJD{ Ÿd$Ô¡¬I¥¸0 Ö¾Ï?=âg•ÁG](]ó ×W‡çò™ÃçÕáX?º y_ªéU®/1å¯B¤-².vêà z½2¸Œsõïë%™P-6µÃÝ)E%½Òp¼™.f'ÈëgÊ
-å< (&.ÕÃè25)hTbp§bâßVv*—èTï/o;eÚ0&±º¥Œ¤8FOX5Éávדñ9Ä– ªA àÊü<xâË…×i†y£Ýë*ÐAlyŸU9J’ô(°ÐƒcÆœÝÛÞn e£U&¥»‡Û‡蛇¶Ôœ¥1áÜå\³%Ö)ë]ŸüHÓO6QrB%¤(úkè>·Sog´ mY²mÄl?dEŠL0ç…ÿœæ¿Ô¸Å¤ÍÙl\Õ–lfñm³lvÑ+bžþTê¢Jd‚þâ•*®%ß^÷%Mzú,yGºð¢È¨Nï‰ð,-’ Ó`Êá® Ø'J˜Kn árËÏÅ%?ÙÜ\óÿâÞõý#„-îÌC½Jœn)„¦Á‚…`ªXS“.ôR°ßµPË,Ñ?Ž™·w©&|!Ž|Õfœ9p-¡BÝÕŸ—þBÐ9’ÐÇ1#ÄÙ€‹ —i&®¼Úß= Ň’—cú²LcDvØ·÷GüS >*²)œ&ü9?·»b“Ä);âxˆðpÆò÷<q{¬œ šNبkßÄ^ µNú:v–ˆóO[PÐfkpÛìÓä…&懦ÅnŠNZË,¯#j‹ìeؽ% üî†A°ÜÍBÚ<´ iÌItxÍþSƒçŸˆ›ø¹C0¥ òym)¸ÍË•o¬¿|uM¦C¢˜F±uBmÆÇåIZÇëB¥ƒÝÑ=úë›GŠ×ûµ¶-ûÅÒÂoñ¨&N“N d—âCMwvh¿2 vYòj¢ W*œÆX•_
-£õ¼ÓíøZ
-ÅÓcA¢\k†Ø8+Ff
-%VQ&4«à\ùœÝ¤á×/)ul3ù‹—I]
-˜ã“×ôq¯Û»ÎU÷«V’5¯…ªì¿à!ôù âr¿Žò}( šâ*¥›K r`ܼÝWUi-ÁòCò=Jª”´z`Ë™A9ˆRzí†RDÞå·Zhk‚•µå‘Lþ©±æUñè‘/—R©ZC‰oô¯·‘²o$i¡nôóÁ¡L °ê„{e>«AtãSZøx®
-Xf’W9wðc
-æl®Ù¥èÝ}£AIS ˜çèÕeCkCh Õ":Êâ$nOn‰²î¬ü›T1†õPXÅÎÈ‚«Hͤ» "ä ‹?gìé8ék@Mdùi¿ÖšB\µôÁÍ•#з4Í÷–ç¹tÔ‚©±* ×£+!·_§
-¶Ãp¿I~!½æÀV(®Ž·SXF|3Áq‚åh½Ím~Û Xã3w™úN# ’ L>¯·åí
-D$¹\¨ q ìk[; $å;£W­>wFc)F%‚WF)ˆWJd½‚L›Me©F}qyY÷×¾+¼¸ç³óVRhÉ”¶Úþ¥¸â¤Æs¬[¶ÈªCŠ"ÔÛÒº:-«J™$
-&ÿ%hr½ÚoçLá3ï³°4:®ò¨ç“ë°×6pvh‘«F€Å*±‰ƒTêœWÏÁ ¼ÕÆÆ#®’Š,§~Õ\ÀoØ5¸Øgk¼ÁÐ<7dYiÕʦ|¹ªROØò5z&< Hú½Ü”B(îwâšÕÃp”Õ†A§êžé¯hï…‰’ªZÛeÃÓ¦{äÛ«¢ù}Ë÷ r8±PȈ½WhPÁîŒ ËŸ"=°:³zã>ÖP¼ þ-´mÆfX´ädÄòt´ÊD©Ÿx‚Ìr†u¥‰çP;õj ÓzužØ¼ô¦F "YµІ'–$Y5häâ<<ÄËaÚ![.)ýâfÙL¯s¡Føǘ…ÌÍ þ-KJþÎ~Þ(™Ø™ôi.xˆÚ’øÓcºTQ[ CN^|*TOû;¨:ãEò–NÚ–.›$Çòþõéº=òR€ÙDg1´¡øk¥Œ-ûÑñÚ”c šc²» ˜Ç:ØÐ·‰ôœp¸Â®²:±÷Î PâiÈÅ´Vý Û9*k c-J|ý#$ e öy6?ãgÙ—šNÝÌaÅó3Z×iÑF?$‡Kd4Š:?\ôp¥ðYvŽRp¾_Ñ#Õaä–!/ ‰é6ã˜7(LáöÏj¾ŒÍ­†/Cz=ôõ7WxR„àQrGÈ(/èñ¼ßômãˆ9¶À{‹Âi’©±•f~õhi5ÄRX`²\ãYq ¥.ܦ|ÌFŒÅ6YÚ„ÊõiSXI?ùêT• ú×~Įrl„Rü°±SÆñŸ3„@]½[ÏŽýõ~_Œ r*Œ~Ûp’°7™õÇ2-û±ˆT¬8Ug>^-š=´é5Ö_¯¡oU,Žr¦õWÙª¯1Çû: Ã÷°ÝQÀ°‹klRW&Àüq-î¿\bú›!@ïÞP[þ!0¹ºQ°‚7hh`ª1 ½å4 èÉ_}~Ýz——7u~+
-3ï•r¤Ü×\¹û Hj±Z9ôÛšWò0R1öë<üëJÃBU²æ©6.Èj¯¥SB?ú%ig-š ô" Ózõg-
-»µmF È÷06úgûFíÊ%;'iòºó°0`Í0“s*aÙ¨6 xcAˆðÄW»Û_‡’è{õÖ¬þÔÐ…1‰’6j†
-­ñJñ¶LöP£4R'Ç¡rkuÌ [Xñ1H'°à‘ñ£Û¤Ÿ"‘m¼LÐAÈ{~íë£Q§³Î•‡\%"ÞÔn¿ƒKZÖÕxKiߣƒEÁÅ-\´!ˆ|’ w§©ÊB>
-âœ]qO%¦Ÿ™¼^–
-éæÉçz¸ùëS%¸ªB(\ɤP›<î‚jßuäF4gºË »©_}VÞoJ ¶Œ[†óOLÊaYë)¨vZÏÛR"ó†ôµ4¥%)eÈöüDÁ¥‚˜û ;Ïhúg(—óÏ>’Å“àýßYÝó±‹<¾l¨1y-i•éö`ã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÷
-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˜šÇÄ_°¿#Ö=£÷#ªÒ›»"ž<DAW…9s­,1ËÃUÀ€>/×ïͬävUÅ­oÈÃê`WI3wï[õ<;,¹X¬š£}y¨^%±¤õ©5µˆ]ôO®ej¯¯·a"­›LáÜ]¿Ä8ÀnÕ¨dà©PÏ[œ¢Auï9]m´~sÀŒËó°¬&¹¬Ú{Éóû
-oBší=Ñ¢KÓ·\ôV×±õŒ!ªEö¯î÷Ì«ŽŸ¥ÇýEWÕ’±mB¹_Š$X ¢Jª‘$â¨YL¿¸¶’Æ‚'¯ä½,ê¦'ÈnÃáå¨X¸Y;x*J_gÀåÂíìd²p\b’&“—®p×îšêà¬ìî—?í9{•¦,žýߟh-ã£ÙâYutX
-–Òê¸e$ö$®á-MÖFÅØ…ÝëöýJ|Kü„#?¥®¤ìÈ#‚!Óp'v%`qÊ!žÀy‹œnäÎçN—/+‹.Ì"¬ã@Љ­¢•ým·a•µ‰RÙD9oe É ¤› iHÉVb¿†Ï")Pê`ò]^€Æ¶T®†˜¿†§†- §ÅÛÖÁ Oó³þŒåeFXƒ$ÊS¸Ÿ¯÷kŽŠòÍ™fL¢˜šëʲF‘9‚‰_«õï+Ê‹\™¿¢úƒª¸QÏís‘ʲH§µÈ=ÉŽ±ÿˆ `#
-”—¦e•>KDØ£8ë<^=\üH93Ñ2W‡¡aàÚÃÉø\þAݪˆøZä¨"ú<¦å­O±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µËà<<ZõÛfeC¸–óc¬à¼/9Hoäcóµäþ3K¨ô•?[àXçOµhsë]§Y*“ëƒ5<F2v€²¥¼|¬r{%ÂSì(‰%ºÙ_üy~.¥ÊpìÅæGår›ï–Å ñ:‹&/ì}*û¸P6CC)+XÒ´éüÞGî
-k¯gÚ†ÃâI1J8žœ1÷‰òõNˆßñó÷¦ùèbTÿñÑ#¥YÒT§O¤¨ƒï2;º8Лȃ[@2
-”¤eû”/Æk„Øsã½”“ ëWÀØW-7‘ÙÌ“&Œ ŠÙSÕçY'9üÈm™ó÷úŒI»~Ç9ýɾ!ì-\Œ%h“Z56ys&˜a]¼g"ô¬ ȆOúC™])[EýtBNÊDThÅYI±£²ÈȲ&d-ëd¸q°t!çëìÙ:TÞÖj®›o/\(7B–¬ÆöC ýN²Æº‘”.U-'‡:1íªËaŸ)ƒßÖ½ÞÂÞë^#šÕ õƒKÖ1Ö1Ê5¾Ì§1v%áïz<¾6Í8eâÝëÁîÛA¿nºüzf½$É×Y…\þþÍÜ“O”?-,ʬ´<\ÅÇ/+«S“"\TÓÃiY+†Vz)üìZÂèNdM¿ã›–ó³›ÅG ŒkC\?™^QÅA±DNI»„Ï3›moFªõØœ€Ï=ö[´ÕNÅàRu4x}ªs
-¦}Õà`‹›µ/#’Êì)ó(ôŸÁ— ´fŒg§‰ßhð–;ÛÌsøV2Ú ƒšÚ!T³^ä´²i÷ Ðá©uó@‡e‘ëü“ý*=î<³ùs<¹¸~mIpHèRÕÙ>¾í¿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
-¼ÁjõŒ8^–ScŽ…O¥–"};J¸„1 8—šP£íÝFÁ[²òéMÊqT,ø®}«ó³1YQÍ‹ã$ð'ˆ[_ÜÚ üÄÜ¥l˜VX)¯4’ÍҌÜ)%èyjµý0Oê¼-ª ÄˆÈ¶wÕ:¢¢diËÆ‡mZ·]„ûòB-½_ëd“8¡4Û=ѴúK(÷ãô×Ú±Žÿ!>:*ÒHˆÙÂWæŽ!B¸ýË!Aȱò‡âGù¸8íÃqWA‚?
-øE«µÉØó Ê\
-jGžvCÂÚ,ÿ»â.éø*â QÖlþØóR™äæåU÷Ù;[å]w”‘}{·X~=dðƒ½7¼—æÃ‹y©Ÿ†Lâ¦q4ÇÐûr4Sg$ØE…cø¢Å!q‘F8dS}gìY?èOÚÛ–¯W_ü'¼Î£A9nc?R¿p.?t3G¿ÝþBîÞ×prƒp´Ô¹ÓV«§í¯á|»¹5ÄQEû^Khóð{"²µ·‡ŸÎ²ý®0=ü½NX¤é}±·ÅZõÖRÒs,ûïÁ7ýC&¨ž–×ÁX‚f.ë½1l ú”0âu!–Œì·ýÎSÁ69¨…îl¹Z^îØÏhûiR±oæÊw•¼™"Çý„˜’Ј”.Ò¢; …xb“LôLiÇø}¤CÈú­¶ÈFe‰ÞŸ¨ùŠ¡wG¸¢%à°Ù寃áÞËÛ¯†žxÅÉts9ýwI©Ã¶
-­/h`p¦‚ùЃþ¾nA´JWНC;ÜyúûV¹¡zŽíx웋(ŸêªÞŸ2Iµ‰Vd“7%ÈL«X3u”‚Ô¡\•µñ\¨ÁkœÅÝõ×ÑëVñD`„<òú%#ŠÀC.-Ýw¿U©IAÍ\¿eXÕëʲ¹8¾q4׸¿\Éë»sø?®(P=2r±>¾)—x÷…~Ü¥3dn©å\Û-=âÁ_Iø´ytTl§w`˜»q¯eIÁ4š“é‚°§¹ô[K¬¯dV´ÏW~†å¬­Œ¹¶ø'Î_lûoú7³rÍÈ<¹*Î]?…÷ ù6°·ßIË)òzâÇt‡o$pCt$Ôó_dŽVè@2]FwA ¤‹Ð®Û€¸‡}–ðKÖ·'û~$¥Ï•*€‘þ~… º èax̢㒲¬ \ÏBó©œR]Æÿe´úx( øêådKi7ö…•Øà§l@.q]®É%vò~k5öwð
-$Uù‡:ƒ sŽßHQºš§p¯ìn©"¯‚Nux€yRÂL
-"a¹Âz£t°p[ÅH¯cAq˜h½>þ… ûsö¡i®¡k%lûÖ.›Wz¥"*Gb&øÆB<Aza¾ØXâ«‹\¬Ë#9ÜY »é†vÿò7]î½(\ÚŸô*2÷v
-°ÞQd›vèµw89’9.„[>;häe¸ c\_ë‘Yf`¢ÆZCº$ò5ˆÕn!Ûɦ æÞ¤sx½®ÄrR=*À@:×9ï+Û»%êÓ­fþ
-‚BàuÀT·n*ÏŒ ÜóÙRF”àêkRà? ™mD)ÙÊ$¾Ôô‡6õÆcíØ”ÊŠÊfú[áŠ
-‘HòGNè½W¯¸;¡Máן!ÒPÆAÞò?‘é©ú@ãß}{¿Bß”ZŽŽ2ÐeXk®ÍÑ=&"Òp¯.$Yªûïññœ´é¢q{ónÂ#K÷¼Õß,SÊ×z¥vçSÅ`/r´ÔtUnέ¯¥IàÓé´{y{õ‹¸%—ÃhIËÉ3”27—Ôë¤"YOK Ý~Lƒ&ºA7?¾ð."nzš+Ø´z'î,`J)D—ˆ*ª× OUym‚ `•–  W7Ð!p u6†Æè4âœêq÷9!¯³îÑ3T‘!?9šFÙºÿY %ìär9göó&ÇjÅ-jw­„ ‰µ??˜‚U¶†?3Ýö·5dœ•àÕ).b[yÀë53àí­¶cÄEw yQ}NdIF,kéAŽ…Ù¶`'9¨ÊðôÀϲ…R‹úÚ£?èôî¬lКZ6~N³{þVš‰Ï[Úp³Æz»œJ`Ž¿9ÉT¢cšå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
-§ŠçÍ%Vš›)|CÓîÏ9vÉÓôpXRH.…]ÃÌ ò›øþTu{¾zÖÚ9p†a«hÿ Ž©æµ¨󞽘Q\5KñíÀعQòJØysé±–W?yj,S=¦¥¾jCÃYd…ÂNˆ£¶Y<oò‡Ÿ¨çÝ@Ð.F9-EO,û·#,Ó•5XsÉtµDXW¬,¨
-Л|:²$±pà¡Ô€ÕN4”Öè}|O¨ÈîÜO«„ Òðf^MÌæs*Ü”>HzŠb^Pkè¾ $Ôs1¥\ÂQü[ê`Ƽ$˱ÞÒNr·äæJŸ¾óáv½_ ·»~xu 4“õ¼P&;±¤Ï=ÓÇAÒógÁÂ_ |0™›¾À:ÔqE9®uÜ Ïqr„.aaéeõßÁûì6Ī/ÝûàtvˆË
-ªDÌ1ñÕ ò X¿äzcƒ>2ë4c"fî
-t­Q:ÔÄ|éòýÞ~¾Ÿ/:Øü  U` ì(›ËwzæÖÃÚS3dú@xN%jFîjüÚcZÂè) 8\"}Gˆö—}×ì0!ñÃ/ñŠFÙqhÕL`è_
-†ÊµßhÂĺ3Þ#4RÀ© “ì×›Q&êI([êt
-‡Û6Òú×ë_ ‰kYhJÛœN*A?7ƒƒ~åjØîZ€ás/ä MTÉ:¾ãÃÝò¦³NŒ²¹é+ <í|0N<ûDCÌ2@@Ð"‹Ržâ‚4g*%ZŸóĺk‹y™OÁÕ.ŒZâõ³Ø×7ö<üÎe¼‰å³À’Šp÷^ú…*˜U‚§äfäQÔÏF
-ùf¶Bïô;‹y9ûWu FjÁ ô…Õ2~pls%BUî-ÖŸ^ é”†ß‡‡Ø÷q‡×¹Óv*j9•¬ï®£"›ƒ~¼cR;ôÚ™ØÕà„°™}tkà>9
-=%?“Ž·ðV‰üì?´ë|ÜúHä/§ _«IæˆrCÒioìÓ€±•£ò¢€<'¤tuÌΖÌdÕ«eM~Æ4"žôüO= hTQà xT ^,6§EÈ'C’|“à—-ЗŸA4ˆ#Ì %ŽIù.e›Ò“ŽòYžÞd¶tvó]³ß Dóßã­ø®åtÉÁÚœ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Þ\ ] ¬<W­k;†ïXm
-QÑf+ã9@/h0i‘ý;뀽…Î ßE§YÈFCÛíù¡Ô™Ëþäƒf¾­Aö5[Œ–0—Úñ¬søKláÁ䢣4 0f\ïª]Ç‘¾”û’àY/q!œArÍ ò35K‡¯¾ïMئ½*KšNu°×OçvdúKÆRk¼NÌlÜÍegÁf<™˜×,O ú~’Ï@xm š„[àšÇ«—2£d!õÓÈ…¾„77z–Z¯×8¦çó3Ç:ÔíeS¬”÷#xY&‹º—º=tkÙ”œ¼À.€Ugž\¤†zç8¢ÔçZ¼íZJ
-ïGdÀvÇ@?/ÐÜF𤬨¹CêÔ÷úžD¨ZÆ ‹éµÌ7”»ºÙ扂Ȋê0É"Ñ ñEŠkhµW÷ oT¸t—‡÷Ú‡á¿ówÖSg6;Ò®Yf­1 ²4ñûÆ®-Ñ]£œœøÁêË.bð=ZÁ?Ô*·h2¨÷@f
-ÀË¡Jšu©öaÚÍærsOÎIñ{É«ÓΚh.ŸÂ0Ù®p^ÏD Dz~ZÚ¬ÑÙ}á HàSѯ‘G×µXt‹”úg*(7(ìÑ#pÊšAL”b71а••=ÉkæÎ
-‰ÉðÏ[SQOmGéQO”ùóú*sê9L¢ßcçý7Á.°˜XóØ'ð»h”Ëj*¦DÊsª:èÒMu÷´© $qY°$h“ÍFøñÙFÔV’È 3~ö3¾½þe§!Ö°Ù±íGaùÀ
-™¸8œîLéÅYŸÀ-é§àê… —+²’Ù7ge\!d%ÇçÙ /ì|F››WÀ3͆qD¤ÈúGüʯäŠ%dRºÆ(·½·¼Ð¦†¾…VšL>äÀº©–•ùh´GÉh¯úr¯PGáÒªÚ(_aœSå‹a‰·ê0Ù|ýP_v$kø£Yù%ùœ~‚:\á‚‚É–~NÖCIÂAíÕ]˜¯¿n0» «'‚pu”¢é·|õõ /@ҸȊ
-¥³mÈ*¤tZ®œf‘k™Qr‚ŸiµYéJ–“ríÃ;¶˜”æŽ×uqµlŽ/Í£ëûñQò3ÆNQé[!›`SJ9†v/ú9ï1ѹ¶qã~‘—:‹^º¨˜Q¥žcsö²¹¶tÃò³™AÎmé9
-«ó/¶õ<øvçsK³~¨’mxÒ£€'´…ðîðRûPȆÏé‰= ¢6X7º
-å‚3Ÿ»¶¥+FL{‘¥™É¸Ê{¦›d wE<Ûðöuª¡b~$.› 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™/
-ÍÔ¼¦³ÂØ´VEíRÔ æ¹^ hÊ;2¾'ºîGÂ"òåå㊻¥ÉG‰Ò½’ïÛH £-êí'Ee›_·á•žŽk² ȼ\éÑ,úa+¾Ð¡};½#&Sÿ¦á*²ôhP³Ñ¯sn ·×7o¶EŠbÎÞsî\ô·oÛê`
-ò‚
-â†tãÓˆ'—%CVÓIšb¤–§µë~ç&à!;°ë-GÂÞ YÞœÇê+ÄNä‚b|—AtFÄÅwÇóZ;žÌfíáLÖ#•«µ Zzêdí8žÁ Ê,`Pðª°àògqæó ýhí¾>¾ÆþPÐZ7“:®fìãèrÖΰ¦xÑ]Ôãa‘s~ç»+Vúšu\X`…À䌜÷ǧ”ÖÍÕÏîõ€4+3wQt1ûAYh¯‰/~òÙÉøM‡ô¦øÈ_—³•œi0!šœäjª÷yÙl±‚r€ éED
-蘭(Æ|(h„ÈA½®îÈGs%ÛA’Ã+© Ûb2ý—¼ŠÊÆ·ÍšíhÁó¹)[ǃ¥ Ôµ ︌2¾½¡'ÔÃ,N]¼tâÕå[²u&Ô˜?!&ôP{PÌóÀ´êì0Yͱ=·ºe ÖÁ¸‰‹ûyŽÆ»ZAKÕª}-¬þäs3C:3 ,»€DŸÃ#‡ÒÓ¼°Ÿ)þD°;·Zßj °’êp_$S¢¸=\<8âg(Êî/vSÈÍTõŒ¥¤r Ù ߦ8N‹‡mpl;û|~kPæiÀä?¦ ÁDͦœ1ÜwÆ#EÏ’dï"ñ`S¤!²ÒœC:lCÌô~}WìÙP–3")Z&ýn2ôYp•Ä:Ï~¢rÓu}²6dÅMCO¹¹6+‡$€'@®Mm`Å-º6V^¹SWnwFbJgG¦h_
-¼Ÿ'Ïû¨H³·Âë ä!ªEüñžë£?ßFïíÉs+ØšˆO¢)þç½ð²Ç’×QúSòiãF& v¬¨5ef˜ï2xœÀPÔk»ã±5ekÒ;Êx¿Ï•fa?E–õéè•yMhΣ ºr yìVáå09Âf ¹®ÑÁÈ?Lö²©«’â¾­^爛0è8ðvr·áj;øë{Yèâr¡_›LÐÎ<ë‚6ã‰!týÕÍ㳌+MÆ’$,ËúåIòrJAÏR§9sÄŽH:{ÇRÿ¹•FÜ]Šß[ñB¾ù[^¢Wu¸ÛE ¤89„Õ'ùêâÒIŽyü†ê=º—ÌÒ£6æžê:´:žåGëZ{<ï!ÈLãóUýÁ¯öå¾8)yÁ´²'ÛNWÃð#bžÃ««óXU›þ|>KÞ°_Ñ£(Z¯ûÞYåx™O÷6tB™W³ÈÊZ#Ç ¥Ù.W@£7eÌá=j¶ÇÅ[t›~SØÀf[Þ¿”8#E í´KlkäJIó°ünQ²&»ŸäbeɾdÅb«B˦àJ ³…PçȽ#ïExwö÷W+ü(3  Ü3ß¾ÎâÐ"¶lTƤ%Âç5™“˜ÉÍÌ|¢Î—ùªPk$ã4·‹r{$‹¬ä— è½0 ˜ã1–òÂÈm_—ö\ùfɸ…ìÄäƒïSÚ‡» '93!Åœ,ùÏkÅõ®“ù³§Z`Ì:v÷D)™éŸüJÔÙ³…6<åY¢'°~S渊ØNÝ]öËPNGˆÔ”F]g$p€9K†ûÐ:ÉÊÜ®f­Ù˜N£o/¿Ò§Ð+÷TìxÝgä—J.ì#­^Id—§jè›ð{O†>ÈÝqYãºUj
-Vèp ‡—-,9,©Áz*[5í¶V‰µ}¶ÔµNÛK­`TRøðôÐå}¼Ëº,5®¼S<PÍôŠ£˜8éà2Sr‰ÉòUŸŠ Z_â•RÛc¥CyÌi¼åʵ­cÞûCTò]¢6rÄO`3.²€’Íñ –ïË"hz PKœÎ5³SÜžb9N§’:j‘ŒOÆà5Å7¤i7ô¡¦h9i|žÞ£p¯/ÕësÍOs|“̇MÅD§á Ô@^wöÀ3VÇŽG@EšCµ'´­Yƒ®­‰(e¢ÿ_;óØ (
-Yø—E[ŒOÞê­žMnŸV¬‹Â¦‡Dð‡X7ù7RbŸóöo‚57Mß•y
-fkþŠP¼Œ°á ÀBŽ)3Nå Häš{¶Ç¦e(dŽšã-´‹qÚ¾óƒÿ’ö%©Ë!Ut™îõEÀ·ÅÃe§á¨õOúÄĦKßd&oëdã¤Lo›ƒ×£Hd—MÞj
-”ËÚ Íö+$hpýÛnü¼¯/Uâbõëú$×
-§´Ë¶ðp^þÄ—EÖþBÚfbwþLWw:³Èrš"þ¦UHF³ŠÑ9¢˜”Íf¬£­‚}Ÿj_5)¸palê
-’!c«ý”ý¢F)0ÀðJXÜ|—Y«N¯ÛØ¡ O1:ï¢f2˜³ë¡»ž ï¦Ì+‘L,xÂ9¢Þ¸rQÒ'䘞ˆ˜lÏF~‚æ—Ã?a¾Ý0YZùCÀQ/Èk ã4G“ç+Ž´,´õÔ§‰ÎŠ[
-gñc¦ÕŽ™¡Ü3€ä˜î¸î
-Nïƒ_8B÷Œý±?·¡R¨[œå7Ø\ë!“Û¤QIÜ](äãZ9/!;aßîJ7(d§¹.·òŽíÙ"ÁãP[½ô¯t*ë·ZŸÏu2ÖX¿hrG¢éùÞ¿P¹÷$plñbì%4ªÝù£7-ÿ¬eØ­uLôùôfŸ šZÆw¤–H9»S?à5ùö\¸$$iÄh±Àßj ½}æøè—.3’L—íçv"X£ÇŒKfd”v¿ï[}™<‹âÍÁ,Ô:&—â„)Wßͦ¿¾öHâ¨o·±‰@ꃼZe2Þí1›È÷2ȸA@/ ½Lj¡=Ø-æ©.ò&ŒÔ‘þObw æØ CJ\q¦û6_¼AÅèØJæÖ´ö˜Øë2ÊB÷ ©zhÛúXQ½îò# ETÄÝ*lÊ6×ÖOéþéetX%í$TÉÊȃËrrÙË«³Raµ'p¤›€®Þ½ÐüB:ËbF“•¢õ”«Ú0dieš†¡¬Í|iÄYõÿ6ü dòžsu #EËên³ø…>°‡&¾%TÅÄêâúÔ>¡)TÀ8ì2‹Rà?ì)œñÎJ“F7J ]ÚkúDG‰œ·^ßÂÑ$”mË8?äò›U–ãêw8”dR׎º™þ×)Uªžàa*Ç%n'
-5”û´¦LÀu¬cA‹æ¤(ž¯ÏúÓ/YNRZÕcù˽Ð)€¾¢_M\¼íöú£˜: l#¶Q_DE¶¶ü’yÓ ðL©NlKõß·h„#£3įÎ/Þ>€ºL&?Ê6æÂc
-sìm<ßò“ûöüàÏû@n6“$ZÿbáÌóå•h
-ßÄCù  6#11ß7ÎQb­Üc󨮎ê*„QÖżÿ°H<Z®º„O|í6LDôÏÀ€w¢Íðô¹é…éýL‚øU0?Å ºŸ4òCæ¦Ð\ øÍ ê¬EoDÁú‘ß{hÊä¾bÈ“*yb¢€·ÒËÓi_R½ÀåSZ Vé~ð£%ú’¯d‚t–…<xTÕ¬¸!ˆ‡(ZV¥2ŒÞ|Ò××&ÜÈSÃHX»x.ÌÔY‹°kDH=£ òivR‰ö‡OÙŒ¸É“:Õè& Á#K¶kð0¬Ï¯èCYý
-–|Ú–¨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<<Dgø‚sÆôÅ«fðŽ Ý.YŒC›I@Í/ ‹.¾kÝA•1›Ä4%ù
-0ôCV»(hãÍߨ£Ø‘ôÍL÷ø¤”zs·/Ê·wâŽr²\„1íNkó³«ãI¢úb‚°í˧‰xªå1!Rxižÿ§þþ‹T66»”yBØ,[™f
-øm(m
-=ÿPA8¢R–Ž&}«(òý†Ú¯:¡W0Ì˽xÝÄPSUrôs{Ûžfk‹üYyü±z¢ŠÒn” ÍÛá’šúeäZ€¥L
-VwWØàÏ<ø7ýç»oG‡^pM‡yFÙæ^m<`ué$om2Û¥õ<¦>¬ÞÀÏl$Þ‚ˆgY\î·e]ø‡·‰í¤LH¨V_àó-AhRah—JéÂ2­ÍX\L/ê [ºÚ1qNd„Ì@­µÏÛ÷
-¨ë cR÷aƒ>½x™&¥\—Kº>VG—Gá·oT&Íe'\¥«Ð"9
-÷¿ÏTÊRáÕä´ã—ámñ[©“Ö¢ÈÕoÜTÔr³I,¨ìÚâƒèr“DÒk×.iOGEÃŒïpì} dö¤™È}-wÆNMÛýV«*oðË]|VN×ÉÄÐdIÍ]n[ìJ!&°žc,ÂÙ„~G3^>Ðb&b÷6›$¤qUUø[S K^“€“8U³æ1xâºòq³ÛÆïw …:×=€%¦¥¶äÄF·
-;*¬{Çšª(ÛQ„J54p0PÉ©Ámp®ïÅü­nmà,)XÓOÏs é£Ù™«ÔËÒŒ_È5Pðö_AnygÞP“%ðYYú>r~|vÇÞéÆvý ù4p¥v
-Ò0ÃøNðE»L`À÷%ìë±ðQËš/À{ú.-ävÓoo@W éÒ¯ñ2wCÍÈí$_±NÁ³æq˜FÔfTiu׳Ï5uò¶û¾¼l¼«õ‰à-Xˆ&½²æ'ù€ L©¬ÿÃÏBeZYIgŽïÝ;š!< $B…ýíÁXI±<ƒ”@hš³¬÷DP.·æBúþ­€dö"¢žHÀ½¦©e|B܇K É£û'c~{…±Kí!FfBýÊ>5—ÅË@Ge!¯{Óô^aÐÏë ñR@Í‹N„¤ú£…Q@â`c?èá»ä¦Ý»ÁŒ#Ì/cáôPä²´µêÍÞ=¡±Ÿ/Wgžƒö“ Ã]íµ¹š[ÊŸ 0t¶wpí,øß:œ Œ!*}_›Ï¨œ=ËCiN@“Fk(2‰Æ!¿Ðì´V•Á£Ü¿7š@×Ímãå@Ð$5ÚÜ´V+«ÐqqãÞ fÖˤׄð²:ħirmhѲP&#ãê`Ä/Û¶<Še´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 ̃.ÊÏË7N
-×C&©ü7ÙÖì€ÓåÅ;¨Ý.ô©qF…0W¬tÛ€¸œ&Æ,0þ¯ÆÝx }B¹âáÃÍÃlr²ÁÿCPZ_>Y>÷ñu%ëÓTÁÊè@6%ë»î(_þOÒ[})ì׌#*¶XgËñ{u•8×€.´7Z˜gJ‚Hz Õ
-½»ôúaDz—\n T£î©Ãc¢@ºÍšèU#í´j,*'YimщA­Ø*–WÀ°;šQôÜø A¼ê.ŸcmˆD9Ò>#ÉôÅÿdUÚ¾ÞRÓU=þ”äê1ËPžÿRÇýÉžÀÂŒÇ7 ÉçKpÁ&‹ž¿ØßA4›DP§­¬ã²4äôCðQ?èâ‰
-i7Žk¯¢¦Vúìë1=:—1nÁƒd‰ÄÇbŠê€ñ-þÞ2–R–,*ؼB²:¦È½ WŠãŠ’Ïæ8ªóŽ[MTÄmëA¸Ûr Š
-®?ìÑÈ:Ì>n.¦„Ú…†AWy1ÔÑ3mÕ]}íËd¯‰Ïá¼!yÂú/1½º²6Ⱦž»(…è5ÅßÞ-S©-פlÝHÄÒÙ$øªèÿõ\ú²ÍÚBašÔ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ý£Ö,<B"j·ÞþÓd¥Äi¬S7™ÔS*ÍpeK5Pàfâ õõxîxÇwe5¼±Ô;Ì&áwïY+wc­
-Úܾƒ•˜½j^ÇO³?DkÅÕ(„)¾áãO Ú¾À³—g´àÚÓ¿cŒª(ú}øjJ;ó‚à,*Ìhz{Ž…˜•K¸+;¨(®hn¸‡­1„•êP]Mõ,Nýåq,snÚ€©÷hçõÛEõ™™‘´Æ÷k²êMé`÷j¶È;¥\²\¯]6öÀ©PÁ•YÞ@DÕãáV
-¬|°½ûjãœÙwÝœd^fÈž€©9F<ö$¥½WïCåì<¦fg)½<ËÖ¶ølÝôÆ5Ÿº'æ¶âgà;ºŸ[SM +ý€i¬óJÁ@èaÀâøÌœMjYÜuòQþe³?†9]ÑðK…Õ\ì4« ƒŸëà‹½KŽöíÍ9YäÕí½Tí„L¡oů ‘ÃAQÅÃ[Wo¤,C5m”`~É@ëè.4[®ö‡ÛAÉðFŒ}Ñúò¤Îk­ç~ÜØëiµ@š1klî{–ñ;‹ ~.|xàyÁÏ·A|ËAþêòÅJ©‰dV¡³öî7“`g‡ÚÛ>}$ú릷;Úã5ÒÌZQø$k»o^ËòøC@„Çlª
-L€-²¥ø»¼Jîýý
-¡YÆS4{Ú0…b3ð?°äVf‹±Ò‚"©†¾£:iHß^Áa1`IÊRŠOÊGë½qPÌŽ3†aµæÁ¶ìêÒZ (¾QûÈ´µ*½TÌ~4Wl?tnt49$ºÚÉ-zs^"ΉTŽ ¿ÚLi‹¨'}ãN~)™ØËžIS–+×XC” œï€tsai9£–Óv4êø&O¶ê¾ùš\CV昃ÉZLÞRÈÇHýI½…àV8’ãÚ«#w}Ýá¸û"--xõôLd:ÞÂ9cœBŒÂÙ*ï#»Ã¡áÕô„u ‰¨Ù³)ŸáB¤É®…uÏÎÛoU†LÁÄÙWsÞ×£ö>ÅÉÚéH\"ü…ô›šu0a& † ¸V•Úð¥;T§’›î:¾Ð×'—LÕ=¸‡ Bí;`51&®séUМ`¤‘ øŽºT¸‹¥{
-Ð]ŸXêy‘ß²oÓ€$ð ;ñ^¯ $bМÇ’ƒeR¨õJQ°~ð’½¢h•ƒöjtÁð’£ Aš–ÝHFþŒßæ¦>ù~~ÛŽÂÒ“]Ž3 Îk¥@\-`y-Œì|Šò
-8¨™€¢íuÉu( {¤”ðßÁá*¬Ï‡pr^!Þ¢ë0SQPVÆ;”M°(ÎE0’A æÛ£Ÿq E©¸›sFÍ5Ñ¥·¬XÌÖX;q¡{{ïHäP'Iðmå¨u葅ʲz­~Ì|™Á¦­¤Ê×ì¶»r­ŠŸ2µÕГ(ÚÆDÕ Š·Ž¾Lb`Ån\a#ð-7ÊaÐ@ß™HÙ¶-dØä.`séBÈ‹Å(Óâ‚4æ/gËÏÂ1‹´ˆ¶êC-
-endobj
-600 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 2
-/LastChar 151
-/Widths 1350 0 R
-/BaseFont /ZSDOCT+URWPalladioL-Roma
-/FontDescriptor 598 0 R
->> endobj
-598 0 obj <<
-/Ascent 715
-/CapHeight 680
-/Descent -282
-/FontName /ZSDOCT+URWPalladioL-Roma
-/ItalicAngle 0
-/StemV 84
-/XHeight 469
-/FontBBox [-166 -283 1021 943]
-/Flags 4
-/CharSet (/fi/fl/exclam/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/circumflex/quotedblright/emdash)
-/FontFile 599 0 R
->> endobj
-1350 0 obj
-[605 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 0 500 840 0 278 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 0 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 0 333 0 0 278 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 ]
-endobj
-596 0 obj <<
-/Length1 1614
-/Length2 24485
-/Length3 532
-/Length 25368
-/Filter /FlateDecode
->>
-stream
-xÚ¬zceß³eÙ¶ë–m£Ë¶mÛ¶mWuÙ¶mÛ6»Œ®.×ôïÿ4ñf>ͼ'âìÌÜ+WæÊ½ãÞˆCF¤ L'hbod*foçBÇDÏÈ PURW0´±14±´—¡²·1ü5³Á‘ ;™ºXÚÛ‰º˜rÔMM
-7µ3u2´(¸ÙXd,MíœM©
-ð|I¨
-‘wÈ»8hN‚ôÊà3/Õc¼o—eöÀ´ØÕN¦•ôJ? ðg»Xœ nÿP¸ ‘>; ø§7Æ£w#5¡Ôýº$O>ÿóL1<16:Òw>pŒK“MÆãOà˜‹Ë¯¥Z)ZÝL~Ó‘mÂ{ôÔ*’»RÆ¢)ï0=ã½Ég —\"nsYâ‚{s’?ËçžiE«vY«Ôè€9¡ÇΗ©5{ý‰÷r=Fa‘ŠÚòBLÖÔ—J|‚íuÿáq™ßx&™å2‹r&G-H.‹Û"]pYÝÝÝÜ
- "+0TjêkÉ™”“Œ†yF
-3o¡a³ ìR€Á ¥äËG—$5]Ÿk&”ÈÔ›îª7[ãúÞÛÕ3Üî2R×HŽƒvž>kMt]ËwE*–3¼m–ô»°˜(×5ƒ> ìÛ:¸øJ¼ü;xÏÙúãÌôÆë2àÑÞJìîKéÑTXŠ Ñv…—ÇP¤úJzöJèXëÈ0¨Ê@-œéÇ=$!áFŽÚdÉr ¸Ò*û3JE›1*-Yé
-5=Wx²à¶$_?äÑåŒ6i7ei¸pÄ9ÎA÷ H»æ(»Ñ4@ïêŠRaï†cû •cœ¦Ã™¸ß÷Rž¾Ï¬º/s俤Ux\Wx!’™²–
-ûˆÝ{Y„Í!\®©E.M.û¬BÛ)°÷d)”(Ü}LxÜž s1Ôú~ã^ZˆUø‹t¦íÝ]TV!ò³þ"«ˆêVØ¥ÅBŸ‰òc yGOiEåŸáÉ[1*‡¸8E[¹ähÕï9¸Z˜3q¥MÕ2^¾dмDa—ÌLŒû\ï¶“×G hàºõ¦‚Úr¤ïåXØx·à외[]tWÚ*¢å#îÑfÙ
-<ËnJ;ØW9EÛÛW0Òˆ¨š¡ý=OésmàìPr‚ž!at5nd‰÷GJ—‰ŽsÍï:¨›+|}]›2Bjr¹“Þ14Á© ¾qêE®l=ÎÙqXñEpõÐëLïgß* R-h^è¶ynªÖö«$¿1mcqm›àÍÌGm­` …ð×K𗎲©«t»­e‰åû—´´,‰#7Êc1^Ë XSú33<þÔ‚Q*¤ž´@·‹´ñi 2Äí­kÔȸ70ƒ@9}¥áejÎÐ
-d„Ü)-l ÕZv±uãV Ò‘ÈU¤‡éœÙù¶›náBFöR`i# VGö{Cà
-µ<ćI‰¡ÿ&)õduä.lõÚ…¾UF¯*뛦‡7æÛ–8*²I°m~¾9ÀP‹U¡ÐIûVó(B–)l;߸´JŸÒðQ]ìF¨ñÏ1Jò+î;©³5à"^Er5äg¶Ð ò¦.‹í5ÄéÄùm ¿Ž+[ñCJuM2Þ‰@¥q‘~+á Ûå(c¶öäÝ÷°œX³ þŽ8¾cçz° RŠžØàW+@U<G £»íã4k¨t‰ÜÕÏUcÌ ƒv™DÄkËGÙ’¤ÈÏC—ÝRÀÈcí¬–žÃMuk T»1ê¯c6n陌¡@3;måâò±ã3Î?jÛ—
-ûy›–C¬g›ë¾lñÀ¹>`q¸2'Ô÷éöu3GLiÖÌP‹!Œ ²ý}Æ>$íég“œáœ·íç‚ÖU½½˜.ˆU-”Y2„bIi—Iª@Vóàï¢ø=ú/÷!ÁÈϹ5ä`¨xÏb¨ðrŽeA¸ìö˜:0µ.m¦¸.#3 Ù\ˆ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©]ºü
-.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½}„B
-þ£ÁuâÖW¨ÌÜ|ò h0®&Ÿ#ñ Éúp覻Q ¢Áîjg”Þþ€Òƒ
-¹Œ'µ@O§þKlЭí÷¡‰ŠÆŸ@,Û—š·%¡°„`鸘\,˜3›}y§O’¢Av(˜igísø?/Æ¢ÉÇ1w«rû ñîäÐnfÁ‚ê;+êÙáNïõƒÓé2‡l §Áœúî„]î"¹àᛇ?ÉPl¾^·f˜SÊËq²æøÐuÑR™lkOVöÿ=išA1ØêþìÄ~Iȼ¼÷Ï(ÄXkÂç?[¡ƒ4"Ô <ºeYA/,vÈ•±%sK
-į´^ÑæJ4«KsGØèx8¤õH¯H{s‚Ï+³ûuŠwœ‹ä ”ã¶EÊŒ˜©øzV᫃‚³]ÃÎ+6%ô,ñ%ËZ"3vò;îÇšmçÊi-å:L~NY|Je™ç›¯¢ x*.º¾<Èzíòiw^ª(xw6ôÁu¥v8£½/DÕýˆ*Túøˆô´å˜ÜÍ-‰úøL…µ0[0îßÓƒíÅ·³nÜÁ.yÉ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<zµcé$§¥%¶Í¶pƒ¹&å}UfÍ`4ýÎÇ—Íþ–âløÑç%|·‹ùþ¾Z9}ÞEJS8M‚›¡W…U8¿ŒË$w¿ ¥Þ¬¬—ÞŸ9†êOw<Bì%ü®8~9):)AoÞ¸7ªü­ä«:jð²óð:±£Ù„xJIñ‰Ë¨X«`±eú~އ÷ax^?
-!¨£ë¨…]–Õ•zXYáêàõ%\yÌ캶7Eiç0ˆY#@å¸÷}½Œd [¯)pQÓNøœhp‹]Ï£héFÕà5‰_¡l}ì„3\JÍŒ£“|V(TœàJÈ`/öç}¨³ƒú"-ŠÞÕH+áK!EUé_Œ{GÀÙð¥*®Ž±ä‘ôªýh¼WpbO½¯àXÒ´²öªºÕY¶)G¼—…V(n|rm¬6éC¢9q#˃r8|;Ô^Vü¡løà
-Y
-?ž®Ëm´¢˜^ÝkB°gmpŸÇhAÁ›ã+’½ ¦´ùCºìÛ* ¶‘ÊÌèmiÔYHjÈêo‘©ma¥î¨ÆŸ­´ºÁtPäšP¥i¢‰Ã Gö] Û,[wdbÕ8ì`Hj•¬F(!2"L<ý蔸ÙÌvØä_C8Z¢=|„Àh[œ_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‚לä<OàÀ¦ @¬½*Ý·V†òh
-­F&bÊ_ë8$Þx£§Ë©Ã¤EpPKyuVTe͸H$ët+áÈC0ù“9©!I[ô6[ñãœöŽD)K²su;f–JîEu—û!šâ’ÿC4áÉ 69-úý£*ÁÅ-æu½!Œ±–‘©jM0™é'¨C¨Uä[,6ÒCé›@c=ÌÒ¾æpû³5meX†p>¥Qò{qAb0hºAxô¬eš–G¡ž« ÷·=³^þ•Ø;¶)îtŸ~FjÒÃ÷°&….V’‘bP5Çzj;êü;¼N–åW' ̓3Mçzª~®¤?ú%öRRl{3!¸ýGT˜òýªêbј?ÄOO‡ö?é‘ä4~#ÀLÝš7æ´n¢™hfì÷$¡Tk2­_+šçä[{p¿¥¦Ñ§t±¸s;Eº·øeÙ'ÉsH°]á#e­pÝÚB[NÖ©Ìì9ôŠ~+CK¹’´5vôÏ”¿§Åû$‚rq|xØÃñz˜¥-`)®þÙšî(‚–ÂPªã4·Áq…e•Š©™.\Æ
-·ò4«4é5Tò÷¢uv¶GÜL܈%Z š tÏÆY²éw*žw6Ÿ+¿ m;ÆèfûºlA“]
-OcòÖ†›k<²8ÞCà8
-?
-©çœ.Ñ1FЋd4èõŸDú½åÜüÒª»x+˜ôL½›’jËeÆYîÎ)}hïÌ)Ô…9Õ1$5zü6Åhæ¨dlxMË‘¥]ŽÿF„k§±œ¬Óš¥E]T‹æu¹ÓyEì±ûÜT¨&š(H‰Z­—¢ö³Ž½%ÒánôâÜë#ê…“ jš-¢Í-ÿ1¶ˆ†£iµÝéËõ¬õXbßÄÂxò6Q‡kWPNÇ<0z%ª$A‹\œð²j÷À®HÕ©”Ó"¡°~¾üós¿›éùÀ_íÝ 2mµ9ÐQ€’TB†@tÁTõ£;ËEßWEÌDÌ­ŒguÅ]gÊf)"PÆÖâ1¿í^‰šVÝæI×ÐK‹qùÍÐX ŒÊY€²Âú1Ž» 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#æ›<BR3o°Ð‚¶.×Ò¾²8tEiÄ™h¢x]{*—áª-fÓ´‚.$žÂÅà>Q[ÝèøyE˱éëˆî¯Gj(Ûïh>4±ï3vÇ]«×3…1Ox/n±êψ´Ph| \k±Z/BÛØ;n~ åá*`Ñ,n·¬§CßÓ5‚ó ÑÜßÃû‘aèTq«ý’„,é±®²ð%¨¸¦¸H™˜þ_8²ºlH,ÏÉP?2N'Ë¢Cs32Œµ]•Ôtf… p”-Ϩ,ùï“Û³É
-×ÝÀýr2`cÑ•:ï_ï6ësˆBª
-c[/ì¶}1?ƒ8»ãe§Tº¬lÊ£ÇÉr´Ð–†)ˆ?~%@{$û뤓Ñ_•LrH›¨XòÅz£²á‹¼££N5R?Pâ¦&+û•VÕ¯5t×PF¢×=Œ'SÙÖÆš•âˆ7”Di´ÔÍÌÐø×u¬÷“„Á§ïj¾¨Œ*Æ'mÓåÍF×™9j>"þ ªƒÎZ—©®›k²‚ŠÁ¨ùéCÌÂ\ìżÁ5ÉëòöƒlLÆ£Ú€víE• (Š_‡EW¹ÞOèIBai°…@Ôóþ11šÏ[;„
-mø-³²a£7 ™ˆÑ4yª¦” Š.éw- áÏA&7–æ˜hæØ-syÊýem5ÖÔ¸ÙR—¹Õð™$¥£–1u*Z&‰%6Ù0å!Ù$‡"˜«¸&%‡ÒæÖzMUôG+40\ëGBÝÍßYi”¿¯Ã„Ä€¶MõtÞé1ûi
-˜¥^nè ”íêç•âÎ,ÅŽÓ²:$!¨5]š¼ úuØÍÿò´¢·8“å‹ W"°ˆý¡VN
-Z„1Û÷ ÿêséGe<hˆ-r°-n®õTÂg “„ÖŸÜ9ëZšÀl«zÜ•k²¬•2¥‡…à§+3m¶X&Œ5Hãe,*Vw¢®_d÷¼øjdnÅ”ÍfreƒîL¸nüfI‚[xÓåƒ÷T%Í*pîj¦xKÙ•P¶d¤”¾Ò–f
-Ã,7p“o#ØxpÀÔÄàZ×LÎÌæ(4= Úö]’p×-¦’­×s0‰!±§² ;)‰²†Ó½zK­P°,v“)˜¼6=.½3Œ¥NN4uwÁçkŒÔi?ßÛ‡½ |#ÝIgÓ>³¾’!!\¡»NfM;–ù€y¾u/‰m_L‚{Hàéš41,³ø·YІÈEh+þ¼¡ÿ1ÿÁc¤Kw‰æ@áðB­>sÑX»ÒVücdåªïÄ‹5Ëb7½ÆR¥çEŽ[/Ò†Ôü‘Î
-)<=U|xxtp9Wlz7;B#Jk•ï*$¥:˛ɚ§rSWí»ü¾‚6Ƀ`"ëPÑÙ8f’cDÍ3UO°úOZ5i”ö ›¸¯Z¹³uzÏýåkÒªŸÆû‰Ô8è AiµåD¬Ê¯ÌÌ
-¹J)°•§Ù´0 ×)NÇv*‡ B×ýD:)‡‘>}†rB¯csÏïq\þ%2Òûà<óÐYZ
-Doµ~‘áNÞÍžb…ü÷ ­æ»!µ«u`º3漺ç •E ¹ùÐÇð”‚çR­¾m¹mì?£••
-Ÿ‚„¨Õ¯êF ‡Ü–Ђ
-z®Ìx"q¬\?™Lüú)#¸§˜y ^d1] ÀGó¥­KÝØL·);68Ƨ!i›Jb“<šžôO!™¹n-º’l$ø‚æiÚ Ö†/­
-ÉØ!úzZûE¹¡Ü˜V]‡`ü—½H€'cÝ›Å.æö–b:ßü3Ù ¤#sÀL¥ü­&(ÉÂËsõÉX›èœ2?hv†¿óÌïÀR‰¦Ý‡uZËpdÛO6-ÿ(¬:Im¨àXsièë³Ñ=Û:«OÇEû±êï)­ådÚå_n5~G¾¨íÆØ"6M=‡”Bä|àaá•$t&0c®ŽN,–zQÜ!ÙBþ†Ó -)˜¢½ëò{^¸ƒÞQ3@TÞù™4ïU½G7©æÀ7òyÎ%]öH|½éx\|Ýso§k5k„«º§8çQ]g®êWø·]`h §ͧÂUŒ 5¾yoÆ‘Ä ‘
-¢š~µ9•v7N€¨Þ„J‡ØÜwº€µ´íµ·S*ñ¦×“ç–«,yóîö†ã‡>κüXÎ!M ]ÜAÃÒ (V % ?9s6÷%: +ÜÃhë¹8±Ã2Çœ»Ädñ†’¸ÆbäØ\Ô&PèaåÜS~žE¤ºÃ•P³e}ŒC’37@Ðì=Cù¦9ܰhcW7£v)P½¹3ùx%ì=Q M–ýHÕøÄ žª ™Iú+|W"ÁÚÑöq¿–‰c#}~8ÄldTÔ›#ì‚zŸŠË b8ƒ½ÌàÚ/V}zÑ Eê2eâ ƒÂIyP™!Âp@÷CxKŒK³óì>5A 3…Ê‘–r0صàŵ€?Ž=µ~‰l~lE½ ÚÝÄ>=Æš”,S ð–lö-ok8‡ªâ7}
-æb¶+Mƒ $(-TbaÄnÜÏ€³î¸‡ë7›KæÓËŽê¼`ËØ”!êQÊ—`µ{y±>Ñ:ésHçz¸$-©žY¬|ÄýÁP/[0«'ý–~õ™î!;Þžù
-Åñf!*BJpc3w”Ò¥õ½
-_¥êûRô9>Î1t%¿Y¯ÉIÍefæ%ÕÇtìÁS=·Û;éÇË»â Ófé¢òðÒ?­Ç^|cgGKgËhçÞÓüñæ³ø[ <£ªFö:&Ë¿H28*§ªƒe*ÙYƒ”p>Ÿå‚žq$®!W¤²ÉIÒᆘÍìôµ2'h Õü›eÌ‚¯©ÑðúÀ†\¯E>æ$ü¿Á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
-|Éûw°©ØâjrÉHÒ,É‹Æ,CbE¶—»Þ^èFêÛ9¹çnx,9c¤œãÖxrí“Í$åÈ£˜Ð^òK~_“â¨ö «48
-+ÇRaçÉç²7[BÞºé¥4\faZ€T ¨ÏŒg"”¦¡9¨™_Ûü Cµµ’)µëËÏ ‡8Ÿ]ÛŒ±î}èÀ,??õbÒfÞÑ5MË$_ÿözÞ?=¬
- F]|N—éUÍQÌVá°ÊEšŸk´`ô—Y±fD T‹¾g뉓Äw„Óg"‡ÓZ3<Ýãýøð£ÈZžp Í M>3ίðåñ—2ºÔ7¨ažb8»×éŒ5!‰Ñ~þš‚ ¾dm>Ú¡³^óZ¾7±YijûvV +Ö²¯LL³fúêW‘¬ñExm íˆ/˜Ö39¢N1ÒŠyógõ4R–(,wV:Ív¡³)·…âÃÚx‰y¡þ3éT–V²`mÁ¦oA¼,×Qf*Å
-†ìÓg¤…žVVÔMˆ"óC>”-²™é=$uÖI€å°•p„ Ô䪀]ƒy€
-áSý qÓS¿ª†R.“=©Àô®¸å)léj“%ÕÐ}PˆJ®D‘é=œ¼™–Ïßõ‰¼ØÇ´:4]‡ÔÇ ž¤=ðøsÃuú³ä0A*›Â«mõß¿5Ä%#6ä@¾* æCàK}‡õdƒÖô_?±íÒÑaÑçpZöñj¤F{ªUpþ¶«EAHJÉûµGCåF=f
-wÔ84<õòN!…OÑÑ
-Ü*¢èp^ö}ÿLl QÛÊyÞò0æ[¢-C »=šK\ËÏ]E4ÈÐùëx´¾O^ƒÅZR=á¡ÂiüÆnnÆL´—tžú[­!ÖŽôbkÌ zøCt0p n€òA–Ý
-ÉÚëTÓ:ó%½ó»êó×o~EGvQw—a“Çu!à­ð|"È®]åû2Å[_“Eœ(Û$¤ú±KÊ'lÞ‚l¾R‡è|n8²D®|a/EÃÌ62ØatŒ„RàU`©ÌÚIËÅ«|¨8[d J¸–3Ò–SÖåä9òsÛétiô6jÅÍ©uÂd\þö|ƒ±¡]Ê7`WªŒÉ?¹´RÜð¤ukaØŸSñƒZÂì뛋ÂðÌ‹Wõ?ÕxZJKu`Ò£{žÉ‡?z:RÎ܃u™ÞrZï°æWð\¦ ÐÝB¯Ü$±
-•m›;ÆÖ‚N‘šI‰Ì>0åœ\×ÔÁrÁ–~¿ß¦Wp—|@(’ý$&hdž–mGë¿L‹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Ú</p´žlÅ
-"ˆ§§³±ªn†QÆöš»æuðÕ¥L(¥âŠv0Bo f¢Ü{¸ïÛÖˆ,`,3Ìýá”H¶ÛçÅ×í,°Ÿ\ýýæf‰­_[äÙAL·É<ê}<òZYšŽ¯×ÎQ6§¨Ñ<¨ð¼Æ5¸¸@7:ë=zÎ0É /¢¡§ZGVv9ÏÞ9­ô%çŽüû΋tå1áy¨œ½¡¸­d)稬ª2Nš vï“ÞÆkoö¢@~¶Ï©žä­ö»cµÞð(’/gQMšÉcùüZÞ‡pªÀÖugâ2±tcÀ‚ûcâåwÁÀ‚û"”ñ3džQ0eƒ¸®#8¶W¾‚.¡tøš‰f@¤¶HðÀz+›4í¤?Õ_ù`
-W;«Ä‚üUh&ÕŠÒ¥HSnFi@YüáŠFr¹ûjØ©ô‚üîŒL0æÂú]ˆ<‚V!}–K/iú â uXoJ–{N4YcAC†ÿÛ€/i}hXxQ_²·vS|PIpL‹OÎÄÿ×éÉÂNâÎþ§%ò¢®#q=‹ß˜‘ëÞÊXì¸o^t7eˆ×WTæ4Sö0XÏÖYò€}6Ü›Z²ÈÄ]}rƒÌ:±l:# bkäÝ–aÌý·€®Ï:$œäDDöÌǃêŽO
-³š}±ômCa¨œs¥”—žÀÔ|%«¯bå„ÊÁ®U‰P¤ÑU£3ÊšØ=çäÁὦ½Ü j Ë”“0ÂÀ²Ú/ÕH«’º}Ÿ½'ÒôÃûψW–˜k† ô@k«Fì¨,çl÷Œû[o½­¯åÏ HQÒ‰…< v:Qñ7~to‹ô îÍñˆ”µÏŠaT'cΜֹE8«™É&Ö+¯«exÞÓIþ#êÀK„N¨à;=/mÒ,ŽÞ5êgné*š^D‡S "‰±­pÍq>Ým…’º>à ìöû×ÇãJ@zæxÕÕFW8^
-.@ ü,ñ“`aMJ!λŠ6N‡ú:žØ7y|‘Rä, ,²àMgBˆ·»¦8o¹®(QF ™³nZˆpZª„;¶ƒ¤Ää.«³:‹}ïþí¸<$ÈñÄÙ“†öú¬vdž“IF#ûeyùéëBCâ²¶tÊgìvve] Š|(Ü©½ÞŽÖ2Ç
-"IúvœÝ~ÙuÊ)k˜ˆB­±©R…Vd›}‚Áà,‰$™ØmŸF3S)pŸœOigRD['ù<пi[Ï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Þ¢
-|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
-ïZgUñYÄÙšf8Âôd¿ÜÕ̰ŠkÄÇ‘­Pöd¼ùCSÖèJEAPÖ6ÿÝĸî­$˜ç¥Ç§¤F§Íä0'tÀ¸í•kØ0-öÈ*¯X&ÜÞÎe0ª"Óž`1Ò‘ÿZJPé‰|ϪâŽëH¸Äo¯"0‘y‡Äúyú#gcqê‡ót}_/ ^ÈdkwÜÙíúòÜ×›ã“3ųʶe/oJ„yÍ,½ä!…‘NV§7S£dò=á`ëNа›½7›.5ö_4cå6Ä}|3mÏ ‚¡há9é4Î…c ÄæeG(½¯üª§!Dî§Â‰ë%mëÒI¿lbÿr?¤áoÛTZô=Éé–‡™Ã¦…ñL22–ÏÔW‚b²’BžÕ”1Ó¾=ne AŸ˜ç¾cqaZ *^"MïpØ
-f‰ª^±Ü‹ é¼E..ƒ§úW÷#^ߥ3áÖøfF,þ­œ{L$ÆLÜ#b
-%Ue
-ÖÇÿ$»R‚0 °*kpC›5D$*|º™¼g®yÓà\'\óK[3;pÎH·û¬Bêš<\)Á\K¨mù*ªýùÂýÌââr¹é'É‹ªí³=Fûš°«'d<šgîcŠé'U ¾³ò)2.š9V×Ú›õgö#Ë£b@KÎåUÉ¢*@!ïXw·)2Íö«+¬CYq4¿1ww¾\ò.—Ôd]?Ù'œ¥”c8
-†n|»Aº§D f2=]SÞºž2])ø.¡st£%²pΉ“Wz6kJgýòÇ“ô‡a³ö—‰ù®9y3jžð:¯·®sa³*|Ë—~Þ²A'±j"‚a<tÝÜ¿cžB[ŸË´}!ÃqÛ.tÞ¯ÕŒ£ã¶ƒ3
-ƒË[ÓôÚ¯^dþþÂ()<е€â¬‰fL^:Q+
-*ç+Ë7t±;¶Ý¢ *%:‘Õ]=âï›Ëu'–¸bȦ•@ø¶$®ä“Ns5>7;mjo'õ£NL)H?”ÌsŒÈÔ$aËê×tPf\D:. 3Üí ]0ŒEFöáGÌåëd\W”%mÔÀàWíQÎ1‚Ôé^ȃÂgì/}™ïTJ@f¢”³ìr'
-Ÿ–YBAí¿†ÒŒê§äkÖÁ[„Xé„5ÔOBÌåçŒ;ç0NGGw¶;è‹q
-~êŸch]8-ož¨­`¤÷3oi>ýß" C¸ð*$4üÊVÊÇà-L>?´<²èl7“xxÞŠâƒsÌ™ú sŠÒµÅG
-‹I: "0²sŠ|¯ÕÁí›góij§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‡[
-.òvŒÆ›ãWa°r՜ܔ`Ÿ}ö¿¯ÂýÛwq¹ÙïÖ”‚·0®„i‘%Áüwþ!W¤Ìëe²Ó
-¿£JÄäôÀÈ~ ïbþCñ÷a¼™V£;Ò9Dáö$hGSú‰</Ñ¥ÿ‘)Ƶèl["ŸV±N5Ò«m‡®ÆH©)§âÀ­ŠÐûÏIÐK¸ÖÕ«\U…ïÁ#ÅXa!=*ˆª]!ÁîÞYÃÂídï1šÅ|âe9}âF+$r$SêxÜ”d2Ä“qChŸMH•ÛaÄN¨¹kl˜’?r´š•mnr"CÀÂ8Ô@æõ%<"ɾ@#Û™ÀÓÞâ™ –ÚÈöÀ0ít­Ež”ïû´€šÚ¡MÜ™:ãZÕBL•wÛ{1+(Úéï³´æ8ÿïÕaÐÓ#ËãŽÑOE‚šy ¯ý”lî:¬¿_À­×þË=“ {E‰¶hvî~s2Ѭo¢Æ7u ñdØJü7¶ài˜ñÑ »[ïtQÅ ™ÅèøŒË;pÕKôÂãÃì³Ùì§{´3Óàr^ìI¹Úw°Úç)k%P>]À¼#A97±§ãÈ*Á¡atìm}¶—†mK•8ù6T«Ç}þÖåãÜxò`žüyþÕ\ÈqïN51FA1Â'Œ‘uôÐÅ42î²8ݕ沊° Fô„«Ô¬àCøb&åûlÅ
-.ô.!¯ ùŒl}‹²-ꦚ!Î(®dìQl’ç0(oih7»"âØS ~M¹û<w]óÓË»Tá!±Ú¢$‘6¢þ‚hx}}åPyOÖ”ñÄ.¯ºHƒƒ>¶%úÇõ+°jÐMá¶µ=$,ƒ‰½=öPSÆO>ßʳqa—ïñˆëo"èäËÇt>U¦©Cði‘‚1åÄÀU±l¾Ø ÉB½Wiõã(¼šQí‹Ù».¬@Üÿ ÄñŽš‰49c̤HD–…P=ºÝXt>-š-”ã¸4•öv‰_1E‡1;K-ÏŽØõÆ©É-4iž æ5¿Ó³ƒæ‡ÈÌÞ\Ô†ë1tD‹ÈÄtŽËd6_EófNñŸZ
-…¯oÏà’X³`G ÊŸMjâ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ý;Ð<Pyâ6°™ba]a ~”ÿ¬˜òr¸2–æj âÌi@ç‹Ù­b’“¿ý«M²ìÖ@o“ð)4âéØIM.Ñá}ó´Oqu#Ú­<ko²öžü °ƒ“2N%Ûk¥Žw¾_ÃÓ|·,xr»¼uÁ=…–/SVÊGã¬l¹`³–½ä{íi ¼X\n®^>Ä“œjÒ Ë&Oæng•Ûlý0kôÂ7¢mWÌçO5RŒ0
-ŠÇ½Íè÷å/‘:Ìé5b"=žOæýÕ0Zê›³Ùø¹'sä3âçDç&EÇ
-‘ƒúS¼×¨,î$‚Ñ¢±Í97ÅÖàb+𶡸5f‰ôÍÄEáÄŠ\u’ Ϲs?
-¸ÑàXÎRP*;Výt”ÄùYh.H­ ‘¦P‡mºx¬KÆ2¥¶­^’f²­åå¨t¤Ç´gˆîPsÐ;íÆžÿ|>w…Äv»Úhwò®â€n ÷¯ü×@(áÆzø­³Æ)±GÈû Ðú¹'»ÐÛºäz÷
-ªCð’󬧌¤piÅ2{Oe«pFañp¨“òK¯Áf¤wÍÍF¯×p˜û$ð«—þ£R>,ÈÃð2*ÍpÃÛ@Hd/¿«–e†‘[Ã~“®ä“Ô‹Ëq˜øeˆ ÛvŒëkmÆ{iâñø*@À˜BAY¸9“X±Än©StÞSÖL( J[/ÎtS> üÆ3Ý[מ¢ÿ}×yáõ
-êä;ã¶,¤ 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
-‘pGÌœ'¡véÏ jËN‘D "jÀ=DÆ/¬?õKjNêps÷y Egð¸›âæÑÅÀé¸ eZÊÌÓÉj¸-•0Ýàµ%‚aÄ€%’'ðX ŒÞy˜ ž9˳Õ-AŠ^¢&‡†¡Äú¢|;“õ’ð­[Õƒ¼“x¦Ñëc-£V^ùéïÎ$W‚
-cd(¨[÷[qJDü­5›UÁï¦ùúª“|i‹DÞø£– ¶8ÐÄÎ9_µàé4dað@˜Ÿ P´¼jp-sð}Æ÷FþP³‹3ó#¢•Cø°¯‹ÀÀ«£“TK|å÷lfËZ¬h'B‘@á4u®°8ó]0tƒˆ‚Ÿ·Èr»‹•Å!¦¿Ñ TŽºéør:4xé"&ÅN Œ/S;8gw¿…×Û¦‰*™ÎûTáž “axe4ܧ•>³î@E ƒÉhª…Ê(ˆ·êÃÖ&L}n³‘ƒÉ1rǺj,ƒ©}j¯Ø`í}¦|ÙQì¼¼ ó.òE)KïÝ’|³I4.Î3qÉ-™ÑŽa‰~Ó»š—8Ãd®HÎù¢záá~oÍ•ƒtfž
-®RÁ1æ"+Ob´½ÞnšŸF±¡é’Þù4g?nhO)Õ"AD·â™¥ïŸÜõ×¶auE‰ø–ßl·
-ØNB†@–·üa`laø¯"kÝ =“¿'pr
-3c]MŽ<Z!ÖYЙÖÄÊq̼RüÄ“xìqñm>*9Œz±â{¥ò˜r»¨A®€ÎVÝÁã¤þ칧ǘ¡O–•½¬€K™òLÞ“N¿b ª:"eä%‰zÖ¾˜+°¢ v¯ –=üµ{nváû¸iɳ5@“¥¼ ŽÀQEG}Ò="ÎÊg2¹k}rgÁÎaïÄbF2§«:ôq‘l5eúY[Ûh[Pz
-Õ"W›‚HóoHëg AÐÐYqo!a{In&Ýq7õµÊ´…B„ì©™-‡–¸ ²“ÑÉ@ùïå¿ûïz‡^Âö[ÏŠëN¥ Ê ‰/\Œ«6Å:ê×c·•©àÀ®Dº¶6?i&Ç]ÊÕ#¼Ð‚Æ›d¡&~ 1 ¬çúàˆÚa;ÙzðBì•9|ÄyôÔùõ䢕)²röTÇÈ]ÓuÅ…CäW®iCê««(LjS——VL¬'@벎3ŽPœ2sJƒWŸ’÷/-pxÇåjØ !Ã1WÕ3ûg¯èê­ø;øßïv!Çs8mÝ{¦b µÏTfkŽžý¥]ÂÕþÚ¼þ ä@’èQ§üKþDЃU³øøäܯ Éí£sfàb8äª*neð¿¾=à8XçRâÛ5‰æAD>D?¯[6ènºMeÒÊЪ“Ž\Ì¡Œ@\$ì1‰ìÒ%$¸˜¿Ó‚j)Û±œžhÄßF%²&â}–ž9 ÷»¸nqôM‘棆dŽà5<ƒ(»°äHd´
-ÿm“'èZÿm+‰pÁB"ÊÚO‹a££‘Úàÿa¥ÅCîp7¨Ûw_¬QOuü"’­8ÏΓX£ìì?³F£,  »«VH¤nÈ8ò»‡Ö œ»Œ¯WhHâÍQ6ååõ0bÞwþOäÀG•tÙAz‚ÿr½S{–§ÝrðÃF5'va¿ ƪb…T› »¬ñº´=:I£V‹åc¢pf€ÅFw”™þ¡±šç©‰Øô:î»:·€·^Ϩ„¯¶qzº QVàD~Í‘6‰
-Æ94£ë Fsf‡U…ÞpÃxò¯*N.sžuÒ7#0÷Óc‚HÕ˜ –âYph9ÅUG— Þ¿¯çÖëY:/¾=¶'·2€ùµG³<~ª:™HJë¸p”£0L;µ/$
-ŠÝØfxö7w÷Aꎎ­L¤³íXUòW³.’¼ª’;ÓÓ¡E"Så]FÞÉÊÏ"iòmþò¯Ñ7„ò—Ú+ÝØ¸qŸKÓ™û˜Žz„Œ¼{R?5ùÁ.’ª–).ÄYðñ¡“ÿ’‡èa£öî3Mä¬8; O'ÂÒÃ{(:õ„
-2 _LØÅ£™>÷R¤½¼
-NÜßúú
-Lœ›Ê%…LeÌ¿+1Œ-•*ŒÂ0G70ýo2ˆ…"³ôd°Ç\g¶i7±ÝâsqLÆ7!õòîÏ¢{ßr%tCáòA@òÊý»ÑÕ*k„ï:qÉê“2²)]dÀÒ‚¸ê‚ƒL/j”ª®äQéâ a“H'‘±èñä^¹®˜%ö/ïŽö»Gž¤ò÷»F¬Píù'€.wÉ¢‰ç’‘H=¨>9ŸhxÓ~TÑMÖìÜ‘œ\nÁ¼)¬2ÂÆP¶R7wõ/qiÉ#·gD^&Ñ6JD»‡ùþþµ˜‹VÕz<ƒªÕ!
-6_mŠq'2~‹Ò=aFІþМ²?Ç ¯Z¡._|;l[×OX˜àJÁ+QGýiÜZÉP&Yyf2—<²è•rŒG Ü75·ïá3òŽÃ#z‡FF⨾ãúF4þN¸ü5àcíÚ6P·¡“eä è‡Ék¢œu_KŸ¥°L‹*·éñ0MH¼CrœT>Ü㇟x FÿàRÂB_!äµi¨NÙ%$hâ]tÞ ‰¢èÛîûs¶¼ª=nù<ü¨òÁËY©ÞØîƒQKñ™ÆýgF==ˆ3šöùsCì¶G’Ð!YŠ WaðŠ +·Yà¾]ˆh‘!{â#iŽ»¤"”¯ùù4bwËZ¨X à2&£‘.¿l=b, ¢,Ùl<aâr7à')¬Í‹RQÜ.)ö2—.‘ч¥r×uü)RÖ\-Cà"
-¨{0öÊðeh饑@­s£²çäV>ÔúAœ¦Gôì©5W0!ÒãBîV\Êå6ÔÔëߥåíýŽá;RЭ$øžv(Ó@ÃICM«Çv¹Ì_§/# È
-ÙÌÑ‚§õ±Á¿2å 6ôw’ä{0ëó¬+/6A3C¿X ¬Ÿ?
-¥0©j T™¶„qÚ]¡ÁÂ'DY¸ ö.g¬Âñ¨û ;AJÒ´á¿ÔÍ­[ßÇHûaA@Ôñ ?ÍJµAì»tI•%[Ø­$ Òð³"ɾs™ÿ?÷€ÿ
-endobj
-597 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1336 0 R
-/FirstChar 2
-/LastChar 151
-/Widths 1351 0 R
-/BaseFont /NEGMHA+URWPalladioL-Bold
-/FontDescriptor 595 0 R
->> endobj
-595 0 obj <<
-/Ascent 708
-/CapHeight 672
-/Descent -266
-/FontName /NEGMHA+URWPalladioL-Bold
-/ItalicAngle 0
-/StemV 123
-/XHeight 471
-/FontBBox [-152 -301 1000 935]
-/Flags 4
-/CharSet (/fi/fl/exclam/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/question/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/W/X/Y/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash)
-/FontFile 596 0 R
->> endobj
-1351 0 obj
-[611 611 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 0 500 889 0 278 333 333 444 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 0 0 0 444 747 778 667 722 833 611 556 833 833 389 0 778 611 1000 833 833 611 833 722 611 667 778 0 1000 667 667 667 333 0 333 0 0 0 500 611 444 611 500 389 556 611 333 333 611 333 889 611 556 611 611 389 444 333 611 556 833 500 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ]
-endobj
-601 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1352 0 R
-/Kids [590 0 R 603 0 R 610 0 R 629 0 R 646 0 R 657 0 R]
->> endobj
-672 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1352 0 R
-/Kids [664 0 R 674 0 R 679 0 R 687 0 R 698 0 R 706 0 R]
->> endobj
-717 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1352 0 R
-/Kids [713 0 R 720 0 R 727 0 R 739 0 R 748 0 R 753 0 R]
->> endobj
-764 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1352 0 R
-/Kids [757 0 R 766 0 R 776 0 R 787 0 R 794 0 R 803 0 R]
->> endobj
-813 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1352 0 R
-/Kids [807 0 R 815 0 R 819 0 R 829 0 R 835 0 R 843 0 R]
->> endobj
-861 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1352 0 R
-/Kids [853 0 R 863 0 R 877 0 R 884 0 R 888 0 R 894 0 R]
->> endobj
-907 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1353 0 R
-/Kids [900 0 R 909 0 R 916 0 R 920 0 R 925 0 R 931 0 R]
->> endobj
-947 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1353 0 R
-/Kids [938 0 R 953 0 R 957 0 R 967 0 R 974 0 R 982 0 R]
->> endobj
-992 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1353 0 R
-/Kids [986 0 R 994 0 R 1001 0 R 1006 0 R 1013 0 R 1021 0 R]
->> endobj
-1035 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1353 0 R
-/Kids [1029 0 R 1037 0 R 1046 0 R 1051 0 R 1055 0 R 1063 0 R]
->> endobj
-1084 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1353 0 R
-/Kids [1075 0 R 1086 0 R 1102 0 R 1114 0 R 1120 0 R 1127 0 R]
->> endobj
-1149 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1353 0 R
-/Kids [1138 0 R 1151 0 R 1158 0 R 1164 0 R 1168 0 R 1176 0 R]
->> endobj
-1196 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1354 0 R
-/Kids [1186 0 R 1198 0 R 1202 0 R 1209 0 R 1221 0 R 1276 0 R]
->> endobj
-1335 0 obj <<
-/Type /Pages
-/Count 1
-/Parent 1354 0 R
-/Kids [1327 0 R]
->> endobj
-1352 0 obj <<
-/Type /Pages
-/Count 36
-/Parent 1355 0 R
-/Kids [601 0 R 672 0 R 717 0 R 764 0 R 813 0 R 861 0 R]
->> endobj
-1353 0 obj <<
-/Type /Pages
-/Count 36
-/Parent 1355 0 R
-/Kids [907 0 R 947 0 R 992 0 R 1035 0 R 1084 0 R 1149 0 R]
->> endobj
-1354 0 obj <<
-/Type /Pages
-/Count 7
-/Parent 1355 0 R
-/Kids [1196 0 R 1335 0 R]
->> endobj
-1355 0 obj <<
-/Type /Pages
-/Count 79
-/Kids [1352 0 R 1353 0 R 1354 0 R]
->> endobj
-1356 0 obj <<
-/Type /Outlines
-/First 7 0 R
-/Last 555 0 R
-/Count 9
->> endobj
-587 0 obj <<
-/Title 588 0 R
-/A 585 0 R
-/Parent 575 0 R
-/Prev 583 0 R
->> endobj
-583 0 obj <<
-/Title 584 0 R
-/A 581 0 R
-/Parent 575 0 R
-/Prev 579 0 R
-/Next 587 0 R
->> endobj
-579 0 obj <<
-/Title 580 0 R
-/A 577 0 R
-/Parent 575 0 R
-/Next 583 0 R
->> endobj
-575 0 obj <<
-/Title 576 0 R
-/A 573 0 R
-/Parent 555 0 R
-/Prev 567 0 R
-/First 579 0 R
-/Last 587 0 R
-/Count -3
->> endobj
-571 0 obj <<
-/Title 572 0 R
-/A 569 0 R
-/Parent 567 0 R
->> endobj
-567 0 obj <<
-/Title 568 0 R
-/A 565 0 R
-/Parent 555 0 R
-/Prev 559 0 R
-/Next 575 0 R
-/First 571 0 R
-/Last 571 0 R
-/Count -1
->> endobj
-563 0 obj <<
-/Title 564 0 R
-/A 561 0 R
-/Parent 559 0 R
->> endobj
-559 0 obj <<
-/Title 560 0 R
-/A 557 0 R
-/Parent 555 0 R
-/Next 567 0 R
-/First 563 0 R
-/Last 563 0 R
-/Count -1
->> endobj
-555 0 obj <<
-/Title 556 0 R
-/A 553 0 R
-/Parent 1356 0 R
-/Prev 535 0 R
-/First 559 0 R
-/Last 575 0 R
-/Count -3
->> endobj
-551 0 obj <<
-/Title 552 0 R
-/A 549 0 R
-/Parent 535 0 R
-/Prev 547 0 R
->> endobj
-547 0 obj <<
-/Title 548 0 R
-/A 545 0 R
-/Parent 535 0 R
-/Prev 539 0 R
-/Next 551 0 R
->> endobj
-543 0 obj <<
-/Title 544 0 R
-/A 541 0 R
-/Parent 539 0 R
->> endobj
-539 0 obj <<
-/Title 540 0 R
-/A 537 0 R
-/Parent 535 0 R
-/Next 547 0 R
-/First 543 0 R
-/Last 543 0 R
-/Count -1
->> endobj
-535 0 obj <<
-/Title 536 0 R
-/A 533 0 R
-/Parent 1356 0 R
-/Prev 511 0 R
-/Next 555 0 R
-/First 539 0 R
-/Last 551 0 R
-/Count -3
->> endobj
-531 0 obj <<
-/Title 532 0 R
-/A 529 0 R
-/Parent 511 0 R
-/Prev 519 0 R
->> endobj
-527 0 obj <<
-/Title 528 0 R
-/A 525 0 R
-/Parent 519 0 R
-/Prev 523 0 R
->> endobj
-523 0 obj <<
-/Title 524 0 R
-/A 521 0 R
-/Parent 519 0 R
-/Next 527 0 R
->> endobj
-519 0 obj <<
-/Title 520 0 R
-/A 517 0 R
-/Parent 511 0 R
-/Prev 515 0 R
-/Next 531 0 R
-/First 523 0 R
-/Last 527 0 R
-/Count -2
->> endobj
-515 0 obj <<
-/Title 516 0 R
-/A 513 0 R
-/Parent 511 0 R
-/Next 519 0 R
->> endobj
-511 0 obj <<
-/Title 512 0 R
-/A 509 0 R
-/Parent 1356 0 R
-/Prev 239 0 R
-/Next 535 0 R
-/First 515 0 R
-/Last 531 0 R
-/Count -3
->> endobj
-507 0 obj <<
-/Title 508 0 R
-/A 505 0 R
-/Parent 463 0 R
-/Prev 491 0 R
->> endobj
-503 0 obj <<
-/Title 504 0 R
-/A 501 0 R
-/Parent 491 0 R
-/Prev 499 0 R
->> endobj
-499 0 obj <<
-/Title 500 0 R
-/A 497 0 R
-/Parent 491 0 R
-/Prev 495 0 R
-/Next 503 0 R
->> endobj
-495 0 obj <<
-/Title 496 0 R
-/A 493 0 R
-/Parent 491 0 R
-/Next 499 0 R
->> endobj
-491 0 obj <<
-/Title 492 0 R
-/A 489 0 R
-/Parent 463 0 R
-/Prev 487 0 R
-/Next 507 0 R
-/First 495 0 R
-/Last 503 0 R
-/Count -3
->> endobj
-487 0 obj <<
-/Title 488 0 R
-/A 485 0 R
-/Parent 463 0 R
-/Prev 483 0 R
-/Next 491 0 R
->> endobj
-483 0 obj <<
-/Title 484 0 R
-/A 481 0 R
-/Parent 463 0 R
-/Prev 479 0 R
-/Next 487 0 R
->> endobj
-479 0 obj <<
-/Title 480 0 R
-/A 477 0 R
-/Parent 463 0 R
-/Prev 467 0 R
-/Next 483 0 R
->> endobj
-475 0 obj <<
-/Title 476 0 R
-/A 473 0 R
-/Parent 467 0 R
-/Prev 471 0 R
->> endobj
-471 0 obj <<
-/Title 472 0 R
-/A 469 0 R
-/Parent 467 0 R
-/Next 475 0 R
->> endobj
-467 0 obj <<
-/Title 468 0 R
-/A 465 0 R
-/Parent 463 0 R
-/Next 479 0 R
-/First 471 0 R
-/Last 475 0 R
-/Count -2
->> endobj
-463 0 obj <<
-/Title 464 0 R
-/A 461 0 R
-/Parent 239 0 R
-/Prev 271 0 R
-/First 467 0 R
-/Last 507 0 R
-/Count -6
->> endobj
-459 0 obj <<
-/Title 460 0 R
-/A 457 0 R
-/Parent 443 0 R
-/Prev 455 0 R
->> endobj
-455 0 obj <<
-/Title 456 0 R
-/A 453 0 R
-/Parent 443 0 R
-/Prev 451 0 R
-/Next 459 0 R
->> endobj
-451 0 obj <<
-/Title 452 0 R
-/A 449 0 R
-/Parent 443 0 R
-/Prev 447 0 R
-/Next 455 0 R
->> endobj
-447 0 obj <<
-/Title 448 0 R
-/A 445 0 R
-/Parent 443 0 R
-/Next 451 0 R
->> endobj
-443 0 obj <<
-/Title 444 0 R
-/A 441 0 R
-/Parent 271 0 R
-/Prev 439 0 R
-/First 447 0 R
-/Last 459 0 R
-/Count -4
->> endobj
-439 0 obj <<
-/Title 440 0 R
-/A 437 0 R
-/Parent 271 0 R
-/Prev 435 0 R
-/Next 443 0 R
->> endobj
-435 0 obj <<
-/Title 436 0 R
-/A 433 0 R
-/Parent 271 0 R
-/Prev 431 0 R
-/Next 439 0 R
->> endobj
-431 0 obj <<
-/Title 432 0 R
-/A 429 0 R
-/Parent 271 0 R
-/Prev 427 0 R
-/Next 435 0 R
->> endobj
-427 0 obj <<
-/Title 428 0 R
-/A 425 0 R
-/Parent 271 0 R
-/Prev 423 0 R
-/Next 431 0 R
->> endobj
-423 0 obj <<
-/Title 424 0 R
-/A 421 0 R
-/Parent 271 0 R
-/Prev 419 0 R
-/Next 427 0 R
->> endobj
-419 0 obj <<
-/Title 420 0 R
-/A 417 0 R
-/Parent 271 0 R
-/Prev 415 0 R
-/Next 423 0 R
->> endobj
-415 0 obj <<
-/Title 416 0 R
-/A 413 0 R
-/Parent 271 0 R
-/Prev 343 0 R
-/Next 419 0 R
->> endobj
-411 0 obj <<
-/Title 412 0 R
-/A 409 0 R
-/Parent 343 0 R
-/Prev 407 0 R
->> endobj
-407 0 obj <<
-/Title 408 0 R
-/A 405 0 R
-/Parent 343 0 R
-/Prev 403 0 R
-/Next 411 0 R
->> endobj
-403 0 obj <<
-/Title 404 0 R
-/A 401 0 R
-/Parent 343 0 R
-/Prev 399 0 R
-/Next 407 0 R
->> endobj
-399 0 obj <<
-/Title 400 0 R
-/A 397 0 R
-/Parent 343 0 R
-/Prev 395 0 R
-/Next 403 0 R
->> endobj
-395 0 obj <<
-/Title 396 0 R
-/A 393 0 R
-/Parent 343 0 R
-/Prev 391 0 R
-/Next 399 0 R
->> endobj
-391 0 obj <<
-/Title 392 0 R
-/A 389 0 R
-/Parent 343 0 R
-/Prev 387 0 R
-/Next 395 0 R
->> endobj
-387 0 obj <<
-/Title 388 0 R
-/A 385 0 R
-/Parent 343 0 R
-/Prev 383 0 R
-/Next 391 0 R
->> endobj
-383 0 obj <<
-/Title 384 0 R
-/A 381 0 R
-/Parent 343 0 R
-/Prev 379 0 R
-/Next 387 0 R
->> endobj
-379 0 obj <<
-/Title 380 0 R
-/A 377 0 R
-/Parent 343 0 R
-/Prev 375 0 R
-/Next 383 0 R
->> endobj
-375 0 obj <<
-/Title 376 0 R
-/A 373 0 R
-/Parent 343 0 R
-/Prev 371 0 R
-/Next 379 0 R
->> endobj
-371 0 obj <<
-/Title 372 0 R
-/A 369 0 R
-/Parent 343 0 R
-/Prev 367 0 R
-/Next 375 0 R
->> endobj
-367 0 obj <<
-/Title 368 0 R
-/A 365 0 R
-/Parent 343 0 R
-/Prev 363 0 R
-/Next 371 0 R
->> endobj
-363 0 obj <<
-/Title 364 0 R
-/A 361 0 R
-/Parent 343 0 R
-/Prev 359 0 R
-/Next 367 0 R
->> endobj
-359 0 obj <<
-/Title 360 0 R
-/A 357 0 R
-/Parent 343 0 R
-/Prev 355 0 R
-/Next 363 0 R
->> endobj
-355 0 obj <<
-/Title 356 0 R
-/A 353 0 R
-/Parent 343 0 R
-/Prev 351 0 R
-/Next 359 0 R
->> endobj
-351 0 obj <<
-/Title 352 0 R
-/A 349 0 R
-/Parent 343 0 R
-/Prev 347 0 R
-/Next 355 0 R
->> endobj
-347 0 obj <<
-/Title 348 0 R
-/A 345 0 R
-/Parent 343 0 R
-/Next 351 0 R
->> endobj
-343 0 obj <<
-/Title 344 0 R
-/A 341 0 R
-/Parent 271 0 R
-/Prev 339 0 R
-/Next 415 0 R
-/First 347 0 R
-/Last 411 0 R
-/Count -17
->> endobj
-339 0 obj <<
-/Title 340 0 R
-/A 337 0 R
-/Parent 271 0 R
-/Prev 335 0 R
-/Next 343 0 R
->> endobj
-335 0 obj <<
-/Title 336 0 R
-/A 333 0 R
-/Parent 271 0 R
-/Prev 331 0 R
-/Next 339 0 R
->> endobj
-331 0 obj <<
-/Title 332 0 R
-/A 329 0 R
-/Parent 271 0 R
-/Prev 327 0 R
-/Next 335 0 R
->> endobj
-327 0 obj <<
-/Title 328 0 R
-/A 325 0 R
-/Parent 271 0 R
-/Prev 323 0 R
-/Next 331 0 R
->> endobj
-323 0 obj <<
-/Title 324 0 R
-/A 321 0 R
-/Parent 271 0 R
-/Prev 311 0 R
-/Next 327 0 R
->> endobj
-319 0 obj <<
-/Title 320 0 R
-/A 317 0 R
-/Parent 311 0 R
-/Prev 315 0 R
->> endobj
-315 0 obj <<
-/Title 316 0 R
-/A 313 0 R
-/Parent 311 0 R
-/Next 319 0 R
->> endobj
-311 0 obj <<
-/Title 312 0 R
-/A 309 0 R
-/Parent 271 0 R
-/Prev 307 0 R
-/Next 323 0 R
-/First 315 0 R
-/Last 319 0 R
-/Count -2
->> endobj
-307 0 obj <<
-/Title 308 0 R
-/A 305 0 R
-/Parent 271 0 R
-/Prev 303 0 R
-/Next 311 0 R
->> endobj
-303 0 obj <<
-/Title 304 0 R
-/A 301 0 R
-/Parent 271 0 R
-/Prev 299 0 R
-/Next 307 0 R
->> endobj
-299 0 obj <<
-/Title 300 0 R
-/A 297 0 R
-/Parent 271 0 R
-/Prev 295 0 R
-/Next 303 0 R
->> endobj
-295 0 obj <<
-/Title 296 0 R
-/A 293 0 R
-/Parent 271 0 R
-/Prev 291 0 R
-/Next 299 0 R
->> endobj
-291 0 obj <<
-/Title 292 0 R
-/A 289 0 R
-/Parent 271 0 R
-/Prev 287 0 R
-/Next 295 0 R
->> endobj
-287 0 obj <<
-/Title 288 0 R
-/A 285 0 R
-/Parent 271 0 R
-/Prev 283 0 R
-/Next 291 0 R
->> endobj
-283 0 obj <<
-/Title 284 0 R
-/A 281 0 R
-/Parent 271 0 R
-/Prev 279 0 R
-/Next 287 0 R
->> endobj
-279 0 obj <<
-/Title 280 0 R
-/A 277 0 R
-/Parent 271 0 R
-/Prev 275 0 R
-/Next 283 0 R
->> endobj
-275 0 obj <<
-/Title 276 0 R
-/A 273 0 R
-/Parent 271 0 R
-/Next 279 0 R
->> endobj
-271 0 obj <<
-/Title 272 0 R
-/A 269 0 R
-/Parent 239 0 R
-/Prev 243 0 R
-/Next 463 0 R
-/First 275 0 R
-/Last 443 0 R
-/Count -24
->> endobj
-267 0 obj <<
-/Title 268 0 R
-/A 265 0 R
-/Parent 259 0 R
-/Prev 263 0 R
->> endobj
-263 0 obj <<
-/Title 264 0 R
-/A 261 0 R
-/Parent 259 0 R
-/Next 267 0 R
->> endobj
-259 0 obj <<
-/Title 260 0 R
-/A 257 0 R
-/Parent 243 0 R
-/Prev 247 0 R
-/First 263 0 R
-/Last 267 0 R
-/Count -2
->> endobj
-255 0 obj <<
-/Title 256 0 R
-/A 253 0 R
-/Parent 247 0 R
-/Prev 251 0 R
->> endobj
-251 0 obj <<
-/Title 252 0 R
-/A 249 0 R
-/Parent 247 0 R
-/Next 255 0 R
->> endobj
-247 0 obj <<
-/Title 248 0 R
-/A 245 0 R
-/Parent 243 0 R
-/Next 259 0 R
-/First 251 0 R
-/Last 255 0 R
-/Count -2
->> endobj
-243 0 obj <<
-/Title 244 0 R
-/A 241 0 R
-/Parent 239 0 R
-/Next 271 0 R
-/First 247 0 R
-/Last 259 0 R
-/Count -2
->> endobj
-239 0 obj <<
-/Title 240 0 R
-/A 237 0 R
-/Parent 1356 0 R
-/Prev 227 0 R
-/Next 511 0 R
-/First 243 0 R
-/Last 463 0 R
-/Count -3
->> endobj
-235 0 obj <<
-/Title 236 0 R
-/A 233 0 R
-/Parent 227 0 R
-/Prev 231 0 R
->> endobj
-231 0 obj <<
-/Title 232 0 R
-/A 229 0 R
-/Parent 227 0 R
-/Next 235 0 R
->> endobj
-227 0 obj <<
-/Title 228 0 R
-/A 225 0 R
-/Parent 1356 0 R
-/Prev 131 0 R
-/Next 239 0 R
-/First 231 0 R
-/Last 235 0 R
-/Count -2
->> endobj
-223 0 obj <<
-/Title 224 0 R
-/A 221 0 R
-/Parent 215 0 R
-/Prev 219 0 R
->> endobj
-219 0 obj <<
-/Title 220 0 R
-/A 217 0 R
-/Parent 215 0 R
-/Next 223 0 R
->> endobj
-215 0 obj <<
-/Title 216 0 R
-/A 213 0 R
-/Parent 131 0 R
-/Prev 199 0 R
-/First 219 0 R
-/Last 223 0 R
-/Count -2
->> endobj
-211 0 obj <<
-/Title 212 0 R
-/A 209 0 R
-/Parent 199 0 R
-/Prev 207 0 R
->> endobj
-207 0 obj <<
-/Title 208 0 R
-/A 205 0 R
-/Parent 199 0 R
-/Prev 203 0 R
-/Next 211 0 R
->> endobj
-203 0 obj <<
-/Title 204 0 R
-/A 201 0 R
-/Parent 199 0 R
-/Next 207 0 R
->> endobj
-199 0 obj <<
-/Title 200 0 R
-/A 197 0 R
-/Parent 131 0 R
-/Prev 195 0 R
-/Next 215 0 R
-/First 203 0 R
-/Last 211 0 R
-/Count -3
->> endobj
-195 0 obj <<
-/Title 196 0 R
-/A 193 0 R
-/Parent 131 0 R
-/Prev 191 0 R
-/Next 199 0 R
->> endobj
-191 0 obj <<
-/Title 192 0 R
-/A 189 0 R
-/Parent 131 0 R
-/Prev 155 0 R
-/Next 195 0 R
->> endobj
-187 0 obj <<
-/Title 188 0 R
-/A 185 0 R
-/Parent 155 0 R
-/Prev 183 0 R
->> endobj
-183 0 obj <<
-/Title 184 0 R
-/A 181 0 R
-/Parent 155 0 R
-/Prev 179 0 R
-/Next 187 0 R
->> endobj
-179 0 obj <<
-/Title 180 0 R
-/A 177 0 R
-/Parent 155 0 R
-/Prev 175 0 R
-/Next 183 0 R
->> endobj
-175 0 obj <<
-/Title 176 0 R
-/A 173 0 R
-/Parent 155 0 R
-/Prev 171 0 R
-/Next 179 0 R
->> endobj
-171 0 obj <<
-/Title 172 0 R
-/A 169 0 R
-/Parent 155 0 R
-/Prev 159 0 R
-/Next 175 0 R
->> endobj
-167 0 obj <<
-/Title 168 0 R
-/A 165 0 R
-/Parent 159 0 R
-/Prev 163 0 R
->> endobj
-163 0 obj <<
-/Title 164 0 R
-/A 161 0 R
-/Parent 159 0 R
-/Next 167 0 R
->> endobj
-159 0 obj <<
-/Title 160 0 R
-/A 157 0 R
-/Parent 155 0 R
-/Next 171 0 R
-/First 163 0 R
-/Last 167 0 R
-/Count -2
->> endobj
-155 0 obj <<
-/Title 156 0 R
-/A 153 0 R
-/Parent 131 0 R
-/Prev 151 0 R
-/Next 191 0 R
-/First 159 0 R
-/Last 187 0 R
-/Count -6
->> endobj
-151 0 obj <<
-/Title 152 0 R
-/A 149 0 R
-/Parent 131 0 R
-/Prev 147 0 R
-/Next 155 0 R
->> endobj
-147 0 obj <<
-/Title 148 0 R
-/A 145 0 R
-/Parent 131 0 R
-/Prev 139 0 R
-/Next 151 0 R
->> endobj
-143 0 obj <<
-/Title 144 0 R
-/A 141 0 R
-/Parent 139 0 R
->> endobj
-139 0 obj <<
-/Title 140 0 R
-/A 137 0 R
-/Parent 131 0 R
-/Prev 135 0 R
-/Next 147 0 R
-/First 143 0 R
-/Last 143 0 R
-/Count -1
->> endobj
-135 0 obj <<
-/Title 136 0 R
-/A 133 0 R
-/Parent 131 0 R
-/Next 139 0 R
->> endobj
-131 0 obj <<
-/Title 132 0 R
-/A 129 0 R
-/Parent 1356 0 R
-/Prev 91 0 R
-/Next 227 0 R
-/First 135 0 R
-/Last 215 0 R
-/Count -9
->> endobj
-127 0 obj <<
-/Title 128 0 R
-/A 125 0 R
-/Parent 111 0 R
-/Prev 115 0 R
->> endobj
-123 0 obj <<
-/Title 124 0 R
-/A 121 0 R
-/Parent 115 0 R
-/Prev 119 0 R
->> endobj
-119 0 obj <<
-/Title 120 0 R
-/A 117 0 R
-/Parent 115 0 R
-/Next 123 0 R
->> endobj
-115 0 obj <<
-/Title 116 0 R
-/A 113 0 R
-/Parent 111 0 R
-/Next 127 0 R
-/First 119 0 R
-/Last 123 0 R
-/Count -2
->> endobj
-111 0 obj <<
-/Title 112 0 R
-/A 109 0 R
-/Parent 91 0 R
-/Prev 107 0 R
-/First 115 0 R
-/Last 127 0 R
-/Count -2
->> endobj
-107 0 obj <<
-/Title 108 0 R
-/A 105 0 R
-/Parent 91 0 R
-/Prev 95 0 R
-/Next 111 0 R
->> endobj
-103 0 obj <<
-/Title 104 0 R
-/A 101 0 R
-/Parent 95 0 R
-/Prev 99 0 R
->> endobj
-99 0 obj <<
-/Title 100 0 R
-/A 97 0 R
-/Parent 95 0 R
-/Next 103 0 R
->> endobj
-95 0 obj <<
-/Title 96 0 R
-/A 93 0 R
-/Parent 91 0 R
-/Next 107 0 R
-/First 99 0 R
-/Last 103 0 R
-/Count -2
->> endobj
-91 0 obj <<
-/Title 92 0 R
-/A 89 0 R
-/Parent 1356 0 R
-/Prev 67 0 R
-/Next 131 0 R
-/First 95 0 R
-/Last 111 0 R
-/Count -3
->> endobj
-87 0 obj <<
-/Title 88 0 R
-/A 85 0 R
-/Parent 67 0 R
-/Prev 83 0 R
->> endobj
-83 0 obj <<
-/Title 84 0 R
-/A 81 0 R
-/Parent 67 0 R
-/Prev 79 0 R
-/Next 87 0 R
->> endobj
-79 0 obj <<
-/Title 80 0 R
-/A 77 0 R
-/Parent 67 0 R
-/Prev 75 0 R
-/Next 83 0 R
->> endobj
-75 0 obj <<
-/Title 76 0 R
-/A 73 0 R
-/Parent 67 0 R
-/Prev 71 0 R
-/Next 79 0 R
->> endobj
-71 0 obj <<
-/Title 72 0 R
-/A 69 0 R
-/Parent 67 0 R
-/Next 75 0 R
->> endobj
-67 0 obj <<
-/Title 68 0 R
-/A 65 0 R
-/Parent 1356 0 R
-/Prev 7 0 R
-/Next 91 0 R
-/First 71 0 R
-/Last 87 0 R
-/Count -5
->> endobj
-63 0 obj <<
-/Title 64 0 R
-/A 61 0 R
-/Parent 23 0 R
-/Prev 55 0 R
->> endobj
-59 0 obj <<
-/Title 60 0 R
-/A 57 0 R
-/Parent 55 0 R
->> endobj
-55 0 obj <<
-/Title 56 0 R
-/A 53 0 R
-/Parent 23 0 R
-/Prev 39 0 R
-/Next 63 0 R
-/First 59 0 R
-/Last 59 0 R
-/Count -1
->> endobj
-51 0 obj <<
-/Title 52 0 R
-/A 49 0 R
-/Parent 39 0 R
-/Prev 47 0 R
->> endobj
-47 0 obj <<
-/Title 48 0 R
-/A 45 0 R
-/Parent 39 0 R
-/Prev 43 0 R
-/Next 51 0 R
->> endobj
-43 0 obj <<
-/Title 44 0 R
-/A 41 0 R
-/Parent 39 0 R
-/Next 47 0 R
->> endobj
-39 0 obj <<
-/Title 40 0 R
-/A 37 0 R
-/Parent 23 0 R
-/Prev 35 0 R
-/Next 55 0 R
-/First 43 0 R
-/Last 51 0 R
-/Count -3
->> endobj
-35 0 obj <<
-/Title 36 0 R
-/A 33 0 R
-/Parent 23 0 R
-/Prev 31 0 R
-/Next 39 0 R
->> endobj
-31 0 obj <<
-/Title 32 0 R
-/A 29 0 R
-/Parent 23 0 R
-/Prev 27 0 R
-/Next 35 0 R
->> endobj
-27 0 obj <<
-/Title 28 0 R
-/A 25 0 R
-/Parent 23 0 R
-/Next 31 0 R
->> endobj
-23 0 obj <<
-/Title 24 0 R
-/A 21 0 R
-/Parent 7 0 R
-/Prev 19 0 R
-/First 27 0 R
-/Last 63 0 R
-/Count -6
->> endobj
-19 0 obj <<
-/Title 20 0 R
-/A 17 0 R
-/Parent 7 0 R
-/Prev 15 0 R
-/Next 23 0 R
->> endobj
-15 0 obj <<
-/Title 16 0 R
-/A 13 0 R
-/Parent 7 0 R
-/Prev 11 0 R
-/Next 19 0 R
->> endobj
-11 0 obj <<
-/Title 12 0 R
-/A 9 0 R
-/Parent 7 0 R
-/Next 15 0 R
->> endobj
-7 0 obj <<
-/Title 8 0 R
-/A 5 0 R
-/Parent 1356 0 R
-/Next 67 0 R
-/First 11 0 R
-/Last 23 0 R
-/Count -4
->> endobj
-1357 0 obj <<
-/Names [(Access_Control_Lists) 1172 0 R (Bv9ARM.ch01) 613 0 R (Bv9ARM.ch02) 667 0 R (Bv9ARM.ch03) 682 0 R (Bv9ARM.ch04) 730 0 R (Bv9ARM.ch05) 810 0 R (Bv9ARM.ch06) 822 0 R (Bv9ARM.ch07) 1171 0 R (Bv9ARM.ch08) 1189 0 R (Bv9ARM.ch09) 1205 0 R (Configuration_File_Grammar) 849 0 R (DNSSEC) 782 0 R (Doc-Start) 594 0 R (Setting_TTLs) 1141 0 R (access_control) 963 0 R (acl) 857 0 R (address_match_lists) 827 0 R (admin_tools) 704 0 R (appendix.A) 554 0 R (bibliography) 1217 0 R (boolean_options) 736 0 R (builtin) 1025 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 226 0 R (chapter.6) 238 0 R (chapter.7) 510 0 R (chapter.8) 534 0 R (cite.RFC1034) 1233 0 R (cite.RFC1035) 1235 0 R (cite.RFC1101) 1290 0 R (cite.RFC1123) 1292 0 R (cite.RFC1183) 1270 0 R (cite.RFC1464) 1310 0 R (cite.RFC1535) 1262 0 R (cite.RFC1536) 1264 0 R (cite.RFC1537) 1300 0 R (cite.RFC1591) 1294 0 R (cite.RFC1706) 1272 0 R (cite.RFC1712) 1324 0 R (cite.RFC1713) 1312 0 R (cite.RFC1794) 1314 0 R (cite.RFC1876) 1274 0 R (cite.RFC1886) 1254 0 R (cite.RFC1912) 1302 0 R (cite.RFC1982) 1266 0 R (cite.RFC1995) 1240 0 R (cite.RFC1996) 1242 0 R (cite.RFC2010) 1304 0 R (cite.RFC2052) 1280 0 R (cite.RFC2065) 1256 0 R (cite.RFC2136) 1244 0 R (cite.RFC2137) 1258 0 R (cite.RFC2163) 1282 0 R (cite.RFC2168) 1284 0 R (cite.RFC2181) 1246 0 R (cite.RFC2219) 1306 0 R (cite.RFC2230) 1286 0 R (cite.RFC2240) 1316 0 R (cite.RFC2308) 1248 0 R (cite.RFC2317) 1296 0 R (cite.RFC2345) 1318 0 R (cite.RFC2352) 1320 0 R (cite.RFC2845) 1250 0 R (cite.RFC974) 1237 0 R (cite.id2492354) 1333 0 R (configuration_file_elements) 823 0 R (controls_statement_definition_and_usage) 718 0 R (diagnostic_tools) 655 0 R (dynamic_update) 734 0 R (dynamic_update_policies) 774 0 R (dynamic_update_security) 972 0 R (historical_dns_information) 1212 0 R (id2465864) 614 0 R (id2466744) 615 0 R (id2466798) 619 0 R (id2466807) 620 0 R (id2467648) 690 0 R (id2467665) 691 0 R (id2468484) 635 0 R (id2468627) 637 0 R (id2468647) 638 0 R (id2468664) 999 0 R (id2468955) 639 0 R (id2469040) 642 0 R (id2469114) 649 0 R (id2469205) 652 0 R (id2469226) 653 0 R (id2469245) 654 0 R (id2469274) 660 0 R (id2469306) 661 0 R (id2469332) 662 0 R (id2469364) 668 0 R (id2469388) 669 0 R (id2469399) 670 0 R (id2469481) 671 0 R (id2469490) 677 0 R (id2469521) 684 0 R (id2469537) 685 0 R (id2470116) 694 0 R (id2470121) 695 0 R (id2471306) 723 0 R (id2471318) 724 0 R (id2471731) 745 0 R (id2472292) 761 0 R (id2472308) 762 0 R (id2472342) 763 0 R (id2472358) 769 0 R (id2472366) 770 0 R (id2472406) 771 0 R (id2472458) 772 0 R (id2472502) 779 0 R (id2472516) 780 0 R (id2472633) 781 0 R (id2472699) 790 0 R (id2472766) 791 0 R (id2472909) 792 0 R (id2472933) 797 0 R (id2472992) 799 0 R (id2473012) 800 0 R (id2473180) 811 0 R (id2473387) 824 0 R (id2474020) 832 0 R (id2474046) 833 0 R (id2474140) 838 0 R (id2474155) 839 0 R (id2474184) 840 0 R (id2474329) 850 0 R (id2474694) 856 0 R (id2474736) 858 0 R (id2474862) 860 0 R (id2475131) 868 0 R (id2475146) 869 0 R (id2475169) 870 0 R (id2475190) 871 0 R (id2475261) 880 0 R (id2475456) 881 0 R (id2475508) 882 0 R (id2476201) 897 0 R (id2476729) 903 0 R (id2476870) 904 0 R (id2476933) 912 0 R (id2476977) 913 0 R (id2476992) 914 0 R (id2478674) 934 0 R (id2479741) 960 0 R (id2479792) 962 0 R (id2479971) 971 0 R (id2480128) 977 0 R (id2480722) 989 0 R (id2480738) 990 0 R (id2480976) 997 0 R (id2483475) 1017 0 R (id2483930) 1032 0 R (id2484556) 1042 0 R (id2484673) 1043 0 R (id2484741) 1049 0 R (id2485414) 1058 0 R (id2485420) 1059 0 R (id2485425) 1060 0 R (id2485658) 1066 0 R (id2485689) 1067 0 R (id2486790) 1105 0 R (id2486949) 1107 0 R (id2486967) 1108 0 R (id2486988) 1111 0 R (id2487128) 1117 0 R (id2487779) 1123 0 R (id2487888) 1125 0 R (id2487909) 1130 0 R (id2488198) 1132 0 R (id2488313) 1134 0 R (id2488331) 1135 0 R (id2488705) 1142 0 R (id2488878) 1144 0 R (id2488892) 1145 0 R (id2488984) 1147 0 R (id2489003) 1148 0 R (id2489059) 1154 0 R (id2489122) 1155 0 R (id2489153) 1156 0 R (id2489213) 1161 0 R (id2489545) 1182 0 R (id2489621) 1183 0 R (id2489678) 1184 0 R (id2489885) 1190 0 R (id2489891) 1191 0 R (id2489902) 1192 0 R (id2489920) 1193 0 R (id2490050) 1206 0 R (id2490055) 1207 0 R (id2490243) 1213 0 R (id2490554) 1215 0 R (id2490899) 1229 0 R (id2490901) 1231 0 R (id2490909) 1236 0 R (id2491001) 1232 0 R (id2491025) 1234 0 R (id2491062) 1245 0 R (id2491088) 1247 0 R (id2491113) 1239 0 R (id2491138) 1241 0 R (id2491161) 1243 0 R (id2491217) 1249 0 R (id2491277) 1252 0 R (id2491292) 1253 0 R (id2491331) 1255 0 R (id2491370) 1257 0 R (id2491398) 1260 0 R (id2491406) 1261 0 R (id2491432) 1263 0 R (id2491499) 1265 0 R (id2491536) 1268 0 R (id2491541) 1269 0 R (id2491598) 1271 0 R (id2491636) 1283 0 R (id2491671) 1273 0 R (id2491725) 1279 0 R (id2491765) 1281 0 R (id2491792) 1285 0 R (id2491818) 1288 0 R (id2491826) 1289 0 R (id2491851) 1291 0 R (id2491875) 1293 0 R (id2491896) 1295 0 R (id2491943) 1298 0 R (id2491950) 1299 0 R (id2491976) 1301 0 R (id2492003) 1303 0 R (id2492039) 1305 0 R (id2492078) 1308 0 R (id2492099) 1309 0 R (id2492121) 1311 0 R (id2492146) 1313 0 R (id2492170) 1315 0 R (id2492193) 1317 0 R (id2492238) 1319 0 R (id2492263) 1322 0 R (id2492269) 1323 0 R (id2492342) 1330 0 R (id2492352) 1332 0 R (id2492354) 1334 0 R (incremental_zone_transfers) 742 0 R (internet_drafts) 1325 0 R (ipv6addresses) 801 0 R (journal) 735 0 R (lwresd) 812 0 R (notify) 731 0 R (options) 923 0 R (page.1) 593 0 R (page.10) 689 0 R (page.11) 700 0 R (page.12) 708 0 R (page.13) 715 0 R (page.14) 722 0 R (page.15) 729 0 R (page.16) 741 0 R (page.17) 750 0 R (page.18) 755 0 R (page.19) 759 0 R (page.2) 605 0 R (page.20) 768 0 R (page.21) 778 0 R (page.22) 789 0 R (page.23) 796 0 R (page.24) 805 0 R (page.25) 809 0 R (page.26) 817 0 R (page.27) 821 0 R (page.28) 831 0 R (page.29) 837 0 R (page.3) 612 0 R (page.30) 845 0 R (page.31) 855 0 R (page.32) 865 0 R (page.33) 879 0 R (page.34) 886 0 R (page.35) 890 0 R (page.36) 896 0 R (page.37) 902 0 R (page.38) 911 0 R (page.39) 918 0 R (page.4) 631 0 R (page.40) 922 0 R (page.41) 927 0 R (page.42) 933 0 R (page.43) 940 0 R (page.44) 955 0 R (page.45) 959 0 R (page.46) 969 0 R (page.47) 976 0 R (page.48) 984 0 R (page.49) 988 0 R (page.5) 648 0 R (page.50) 996 0 R (page.51) 1003 0 R (page.52) 1008 0 R (page.53) 1015 0 R (page.54) 1023 0 R (page.55) 1031 0 R (page.56) 1039 0 R (page.57) 1048 0 R (page.58) 1053 0 R (page.59) 1057 0 R (page.6) 659 0 R (page.60) 1065 0 R (page.61) 1077 0 R (page.62) 1088 0 R (page.63) 1104 0 R (page.64) 1116 0 R (page.65) 1122 0 R (page.66) 1129 0 R (page.67) 1140 0 R (page.68) 1153 0 R (page.69) 1160 0 R (page.7) 666 0 R (page.70) 1166 0 R (page.71) 1170 0 R (page.72) 1178 0 R (page.73) 1188 0 R (page.74) 1200 0 R (page.75) 1204 0 R (page.76) 1211 0 R (page.77) 1224 0 R (page.78) 1278 0 R (page.79) 1329 0 R (page.8) 676 0 R (page.9) 681 0 R (proposed_standards) 746 0 R (rfcs) 644 0 R (rndc) 875 0 R (rrset_ordering) 696 0 R (sample_configuration) 683 0 R (section*.1) 1228 0 R (section*.10) 1321 0 R (section*.11) 1331 0 R (section*.2) 1230 0 R (section*.3) 1238 0 R (section*.4) 1251 0 R (section*.5) 1259 0 R (section*.6) 1267 0 R (section*.7) 1287 0 R (section*.8) 1297 0 R (section*.9) 1307 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 154 0 R (section.4.6) 190 0 R (section.4.7) 194 0 R (section.4.8) 198 0 R (section.4.9) 214 0 R (section.5.1) 230 0 R (section.5.2) 234 0 R (section.6.1) 242 0 R (section.6.2) 270 0 R (section.6.3) 462 0 R (section.7.1) 514 0 R (section.7.2) 518 0 R (section.7.3) 530 0 R (section.8.1) 538 0 R (section.8.2) 546 0 R (section.8.3) 550 0 R (section.A.1) 558 0 R (section.A.2) 566 0 R (section.A.3) 574 0 R (server_statement_definition_and_usage) 951 0 R (server_statement_grammar) 1034 0 R (statsfile) 929 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.5.1) 158 0 R (subsection.4.5.2) 170 0 R (subsection.4.5.3) 174 0 R (subsection.4.5.4) 178 0 R (subsection.4.5.5) 182 0 R (subsection.4.5.6) 186 0 R (subsection.4.8.1) 202 0 R (subsection.4.8.2) 206 0 R (subsection.4.8.3) 210 0 R (subsection.4.9.1) 218 0 R (subsection.4.9.2) 222 0 R (subsection.6.1.1) 246 0 R (subsection.6.1.2) 258 0 R (subsection.6.2.1) 274 0 R (subsection.6.2.10) 310 0 R (subsection.6.2.11) 322 0 R (subsection.6.2.12) 326 0 R (subsection.6.2.13) 330 0 R (subsection.6.2.14) 334 0 R (subsection.6.2.15) 338 0 R (subsection.6.2.16) 342 0 R (subsection.6.2.17) 414 0 R (subsection.6.2.18) 418 0 R (subsection.6.2.19) 422 0 R (subsection.6.2.2) 278 0 R (subsection.6.2.20) 426 0 R (subsection.6.2.21) 430 0 R (subsection.6.2.22) 434 0 R (subsection.6.2.23) 438 0 R (subsection.6.2.24) 442 0 R (subsection.6.2.3) 282 0 R (subsection.6.2.4) 286 0 R (subsection.6.2.5) 290 0 R (subsection.6.2.6) 294 0 R (subsection.6.2.7) 298 0 R (subsection.6.2.8) 302 0 R (subsection.6.2.9) 306 0 R (subsection.6.3.1) 466 0 R (subsection.6.3.2) 478 0 R (subsection.6.3.3) 482 0 R (subsection.6.3.4) 486 0 R (subsection.6.3.5) 490 0 R (subsection.6.3.6) 506 0 R (subsection.7.2.1) 522 0 R (subsection.7.2.2) 526 0 R (subsection.8.1.1) 542 0 R (subsection.A.1.1) 562 0 R (subsection.A.2.1) 570 0 R (subsection.A.3.1) 578 0 R (subsection.A.3.2) 582 0 R (subsection.A.3.3) 586 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 162 0 R (subsubsection.4.5.1.2) 166 0 R (subsubsection.6.1.1.1) 250 0 R (subsubsection.6.1.1.2) 254 0 R (subsubsection.6.1.2.1) 262 0 R (subsubsection.6.1.2.2) 266 0 R (subsubsection.6.2.10.1) 314 0 R (subsubsection.6.2.10.2) 318 0 R (subsubsection.6.2.16.1) 346 0 R (subsubsection.6.2.16.10) 382 0 R (subsubsection.6.2.16.11) 386 0 R (subsubsection.6.2.16.12) 390 0 R (subsubsection.6.2.16.13) 394 0 R (subsubsection.6.2.16.14) 398 0 R (subsubsection.6.2.16.15) 402 0 R (subsubsection.6.2.16.16) 406 0 R (subsubsection.6.2.16.17) 410 0 R (subsubsection.6.2.16.2) 350 0 R (subsubsection.6.2.16.3) 354 0 R (subsubsection.6.2.16.4) 358 0 R (subsubsection.6.2.16.5) 362 0 R (subsubsection.6.2.16.6) 366 0 R (subsubsection.6.2.16.7) 370 0 R (subsubsection.6.2.16.8) 374 0 R (subsubsection.6.2.16.9) 378 0 R (subsubsection.6.2.24.1) 446 0 R (subsubsection.6.2.24.2) 450 0 R (subsubsection.6.2.24.3) 454 0 R (subsubsection.6.2.24.4) 458 0 R (subsubsection.6.3.1.1) 470 0 R (subsubsection.6.3.1.2) 474 0 R (subsubsection.6.3.5.1) 494 0 R (subsubsection.6.3.5.2) 498 0 R (subsubsection.6.3.5.3) 502 0 R (table.1.1) 621 0 R (table.1.2) 636 0 R (table.3.1) 692 0 R (table.3.2) 725 0 R (table.6.1) 825 0 R (table.6.10) 1112 0 R (table.6.11) 1118 0 R (table.6.12) 1124 0 R (table.6.13) 1131 0 R (table.6.14) 1133 0 R (table.6.15) 1136 0 R (table.6.16) 1143 0 R (table.6.17) 1146 0 R (table.6.18) 1162 0 R (table.6.2) 851 0 R (table.6.3) 859 0 R (table.6.4) 898 0 R (table.6.5) 935 0 R (table.6.6) 1018 0 R (table.6.7) 1033 0 R (table.6.8) 1061 0 R (table.6.9) 1106 0 R (table.A.1) 1214 0 R (table.A.2) 1216 0 R (the_category_phrase) 892 0 R (the_sortlist_statement) 1009 0 R (topology) 1004 0 R (tsig) 760 0 R (tuning) 1019 0 R (types_of_resource_records_and_when_to_use_them) 643 0 R (view_statement_grammar) 1027 0 R (zone_statement_grammar) 965 0 R (zone_transfers) 737 0 R]
-/Limits [(Access_Control_Lists) (zone_transfers)]
->> endobj
-1358 0 obj <<
-/Kids [1357 0 R]
->> endobj
-1359 0 obj <<
-/Dests 1358 0 R
->> endobj
-1360 0 obj <<
-/Type /Catalog
-/Pages 1355 0 R
-/Outlines 1356 0 R
-/Names 1359 0 R
-/PageMode /UseOutlines
-/OpenAction 589 0 R
->> endobj
-1361 0 obj <<
-/Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
-/CreationDate (D:20051104123603+11'00')
-/PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
->> endobj
-xref
-0 1362
-0000000001 65535 f
-0000000002 00000 f
-0000000003 00000 f
-0000000004 00000 f
-0000000000 00000 f
-0000000009 00000 n
-0000018859 00000 n
-0000483529 00000 n
-0000000054 00000 n
-0000000086 00000 n
-0000018983 00000 n
-0000483457 00000 n
-0000000133 00000 n
-0000000173 00000 n
-0000019108 00000 n
-0000483371 00000 n
-0000000221 00000 n
-0000000273 00000 n
-0000019233 00000 n
-0000483285 00000 n
-0000000321 00000 n
-0000000377 00000 n
-0000023668 00000 n
-0000483175 00000 n
-0000000425 00000 n
-0000000478 00000 n
-0000023792 00000 n
-0000483101 00000 n
-0000000531 00000 n
-0000000572 00000 n
-0000023917 00000 n
-0000483014 00000 n
-0000000625 00000 n
-0000000674 00000 n
-0000024042 00000 n
-0000482927 00000 n
-0000000727 00000 n
-0000000757 00000 n
-0000028190 00000 n
-0000482803 00000 n
-0000000810 00000 n
-0000000861 00000 n
-0000028315 00000 n
-0000482729 00000 n
-0000000919 00000 n
-0000000964 00000 n
-0000028440 00000 n
-0000482642 00000 n
-0000001022 00000 n
-0000001062 00000 n
-0000028565 00000 n
-0000482568 00000 n
-0000001120 00000 n
-0000001162 00000 n
-0000031474 00000 n
-0000482444 00000 n
-0000001215 00000 n
-0000001260 00000 n
-0000031599 00000 n
-0000482383 00000 n
-0000001318 00000 n
-0000001355 00000 n
-0000031724 00000 n
-0000482309 00000 n
-0000001408 00000 n
-0000001463 00000 n
-0000034112 00000 n
-0000482184 00000 n
-0000001509 00000 n
-0000001556 00000 n
-0000034237 00000 n
-0000482110 00000 n
-0000001604 00000 n
-0000001648 00000 n
-0000034362 00000 n
-0000482023 00000 n
-0000001696 00000 n
-0000001735 00000 n
-0000034485 00000 n
-0000481936 00000 n
-0000001783 00000 n
-0000001825 00000 n
-0000034609 00000 n
-0000481849 00000 n
-0000001873 00000 n
-0000001936 00000 n
-0000035645 00000 n
-0000481775 00000 n
-0000001984 00000 n
-0000002034 00000 n
-0000037323 00000 n
-0000481647 00000 n
-0000002080 00000 n
-0000002126 00000 n
-0000037447 00000 n
-0000481534 00000 n
-0000002174 00000 n
-0000002218 00000 n
-0000037572 00000 n
-0000481458 00000 n
-0000002271 00000 n
-0000002323 00000 n
-0000037697 00000 n
-0000481381 00000 n
-0000002377 00000 n
-0000002436 00000 n
-0000040313 00000 n
-0000481290 00000 n
-0000002485 00000 n
-0000002523 00000 n
-0000040564 00000 n
-0000481173 00000 n
-0000002572 00000 n
-0000002618 00000 n
-0000040690 00000 n
-0000481055 00000 n
-0000002672 00000 n
-0000002739 00000 n
-0000043869 00000 n
-0000480976 00000 n
-0000002798 00000 n
-0000002842 00000 n
-0000043995 00000 n
-0000480897 00000 n
-0000002901 00000 n
-0000002949 00000 n
-0000053818 00000 n
-0000480818 00000 n
-0000003003 00000 n
-0000003036 00000 n
-0000057084 00000 n
-0000480686 00000 n
-0000003083 00000 n
-0000003126 00000 n
-0000057210 00000 n
-0000480607 00000 n
-0000003175 00000 n
-0000003205 00000 n
-0000057336 00000 n
-0000480475 00000 n
-0000003254 00000 n
-0000003292 00000 n
-0000057461 00000 n
-0000480410 00000 n
-0000003346 00000 n
-0000003388 00000 n
-0000061908 00000 n
-0000480317 00000 n
-0000003437 00000 n
-0000003496 00000 n
-0000062034 00000 n
-0000480224 00000 n
-0000003545 00000 n
-0000003578 00000 n
-0000068735 00000 n
-0000480092 00000 n
-0000003627 00000 n
-0000003655 00000 n
-0000068861 00000 n
-0000479974 00000 n
-0000003709 00000 n
-0000003778 00000 n
-0000068987 00000 n
-0000479895 00000 n
-0000003837 00000 n
-0000003885 00000 n
-0000069113 00000 n
-0000479816 00000 n
-0000003944 00000 n
-0000003989 00000 n
-0000072115 00000 n
-0000479723 00000 n
-0000004043 00000 n
-0000004111 00000 n
-0000072241 00000 n
-0000479630 00000 n
-0000004165 00000 n
-0000004235 00000 n
-0000072367 00000 n
-0000479537 00000 n
-0000004289 00000 n
-0000004352 00000 n
-0000072493 00000 n
-0000479444 00000 n
-0000004406 00000 n
-0000004461 00000 n
-0000076214 00000 n
-0000479365 00000 n
-0000004515 00000 n
-0000004547 00000 n
-0000076340 00000 n
-0000479272 00000 n
-0000004596 00000 n
-0000004624 00000 n
-0000076465 00000 n
-0000479179 00000 n
-0000004673 00000 n
-0000004705 00000 n
-0000076591 00000 n
-0000479047 00000 n
-0000004754 00000 n
-0000004784 00000 n
-0000080038 00000 n
-0000478968 00000 n
-0000004838 00000 n
-0000004879 00000 n
-0000080163 00000 n
-0000478875 00000 n
-0000004933 00000 n
-0000004975 00000 n
-0000080289 00000 n
-0000478796 00000 n
-0000005029 00000 n
-0000005074 00000 n
-0000082997 00000 n
-0000478678 00000 n
-0000005123 00000 n
-0000005169 00000 n
-0000083123 00000 n
-0000478599 00000 n
-0000005223 00000 n
-0000005283 00000 n
-0000083249 00000 n
-0000478520 00000 n
-0000005337 00000 n
-0000005406 00000 n
-0000086059 00000 n
-0000478387 00000 n
-0000005453 00000 n
-0000005506 00000 n
-0000086185 00000 n
-0000478308 00000 n
-0000005555 00000 n
-0000005611 00000 n
-0000086311 00000 n
-0000478229 00000 n
-0000005660 00000 n
-0000005709 00000 n
-0000090413 00000 n
-0000478096 00000 n
-0000005756 00000 n
-0000005808 00000 n
-0000090539 00000 n
-0000477978 00000 n
-0000005857 00000 n
-0000005908 00000 n
-0000094681 00000 n
-0000477860 00000 n
-0000005962 00000 n
-0000006007 00000 n
-0000094806 00000 n
-0000477781 00000 n
-0000006066 00000 n
-0000006100 00000 n
-0000094931 00000 n
-0000477702 00000 n
-0000006159 00000 n
-0000006207 00000 n
-0000098209 00000 n
-0000477584 00000 n
-0000006261 00000 n
-0000006301 00000 n
-0000098335 00000 n
-0000477505 00000 n
-0000006360 00000 n
-0000006394 00000 n
-0000098461 00000 n
-0000477426 00000 n
-0000006453 00000 n
-0000006501 00000 n
-0000102189 00000 n
-0000477293 00000 n
-0000006550 00000 n
-0000006600 00000 n
-0000105995 00000 n
-0000477214 00000 n
-0000006654 00000 n
-0000006701 00000 n
-0000106121 00000 n
-0000477121 00000 n
-0000006755 00000 n
-0000006815 00000 n
-0000106371 00000 n
-0000477028 00000 n
-0000006869 00000 n
-0000006921 00000 n
-0000106497 00000 n
-0000476935 00000 n
-0000006975 00000 n
-0000007040 00000 n
-0000111147 00000 n
-0000476842 00000 n
-0000007094 00000 n
-0000007145 00000 n
-0000111273 00000 n
-0000476749 00000 n
-0000007199 00000 n
-0000007263 00000 n
-0000111399 00000 n
-0000476656 00000 n
-0000007317 00000 n
-0000007364 00000 n
-0000111525 00000 n
-0000476563 00000 n
-0000007418 00000 n
-0000007478 00000 n
-0000114467 00000 n
-0000476470 00000 n
-0000007532 00000 n
-0000007583 00000 n
-0000114593 00000 n
-0000476338 00000 n
-0000007638 00000 n
-0000007703 00000 n
-0000114719 00000 n
-0000476259 00000 n
-0000007763 00000 n
-0000007810 00000 n
-0000125127 00000 n
-0000476180 00000 n
-0000007870 00000 n
-0000007918 00000 n
-0000128845 00000 n
-0000476087 00000 n
-0000007973 00000 n
-0000008023 00000 n
-0000128971 00000 n
-0000475994 00000 n
-0000008078 00000 n
-0000008141 00000 n
-0000130711 00000 n
-0000475901 00000 n
-0000008196 00000 n
-0000008248 00000 n
-0000130837 00000 n
-0000475808 00000 n
-0000008303 00000 n
-0000008368 00000 n
-0000130963 00000 n
-0000475715 00000 n
-0000008423 00000 n
-0000008475 00000 n
-0000136313 00000 n
-0000475582 00000 n
-0000008530 00000 n
-0000008595 00000 n
-0000140379 00000 n
-0000475503 00000 n
-0000008655 00000 n
-0000008699 00000 n
-0000159492 00000 n
-0000475410 00000 n
-0000008759 00000 n
-0000008798 00000 n
-0000159618 00000 n
-0000475317 00000 n
-0000008858 00000 n
-0000008905 00000 n
-0000159743 00000 n
-0000475224 00000 n
-0000008965 00000 n
-0000009008 00000 n
-0000163657 00000 n
-0000475131 00000 n
-0000009068 00000 n
-0000009107 00000 n
-0000166745 00000 n
-0000475038 00000 n
-0000009167 00000 n
-0000009209 00000 n
-0000166871 00000 n
-0000474945 00000 n
-0000009269 00000 n
-0000009312 00000 n
-0000174775 00000 n
-0000474852 00000 n
-0000009372 00000 n
-0000009419 00000 n
-0000174899 00000 n
-0000474759 00000 n
-0000009479 00000 n
-0000009540 00000 n
-0000178845 00000 n
-0000474666 00000 n
-0000009601 00000 n
-0000009653 00000 n
-0000178971 00000 n
-0000474573 00000 n
-0000009714 00000 n
-0000009767 00000 n
-0000181984 00000 n
-0000474480 00000 n
-0000009828 00000 n
-0000009866 00000 n
-0000185943 00000 n
-0000474387 00000 n
-0000009927 00000 n
-0000009979 00000 n
-0000189321 00000 n
-0000474294 00000 n
-0000010040 00000 n
-0000010084 00000 n
-0000189579 00000 n
-0000474201 00000 n
-0000010145 00000 n
-0000010181 00000 n
-0000194073 00000 n
-0000474108 00000 n
-0000010242 00000 n
-0000010305 00000 n
-0000197229 00000 n
-0000474029 00000 n
-0000010366 00000 n
-0000010415 00000 n
-0000197486 00000 n
-0000473936 00000 n
-0000010470 00000 n
-0000010521 00000 n
-0000197615 00000 n
-0000473843 00000 n
-0000010576 00000 n
-0000010640 00000 n
-0000202325 00000 n
-0000473750 00000 n
-0000010695 00000 n
-0000010752 00000 n
-0000202454 00000 n
-0000473657 00000 n
-0000010807 00000 n
-0000010877 00000 n
-0000206017 00000 n
-0000473564 00000 n
-0000010932 00000 n
-0000010981 00000 n
-0000206146 00000 n
-0000473471 00000 n
-0000011036 00000 n
-0000011098 00000 n
-0000207911 00000 n
-0000473378 00000 n
-0000011153 00000 n
-0000011202 00000 n
-0000211360 00000 n
-0000473260 00000 n
-0000011257 00000 n
-0000011319 00000 n
-0000211489 00000 n
-0000473181 00000 n
-0000011379 00000 n
-0000011418 00000 n
-0000216452 00000 n
-0000473088 00000 n
-0000011478 00000 n
-0000011512 00000 n
-0000216581 00000 n
-0000472995 00000 n
-0000011572 00000 n
-0000011613 00000 n
-0000226764 00000 n
-0000472916 00000 n
-0000011673 00000 n
-0000011725 00000 n
-0000230938 00000 n
-0000472798 00000 n
-0000011774 00000 n
-0000011807 00000 n
-0000231067 00000 n
-0000472680 00000 n
-0000011861 00000 n
-0000011933 00000 n
-0000231195 00000 n
-0000472601 00000 n
-0000011992 00000 n
-0000012036 00000 n
-0000238969 00000 n
-0000472522 00000 n
-0000012095 00000 n
-0000012148 00000 n
-0000242553 00000 n
-0000472429 00000 n
-0000012202 00000 n
-0000012252 00000 n
-0000245916 00000 n
-0000472336 00000 n
-0000012306 00000 n
-0000012344 00000 n
-0000246174 00000 n
-0000472243 00000 n
-0000012398 00000 n
-0000012447 00000 n
-0000246432 00000 n
-0000472111 00000 n
-0000012501 00000 n
-0000012553 00000 n
-0000246561 00000 n
-0000472032 00000 n
-0000012612 00000 n
-0000012664 00000 n
-0000249442 00000 n
-0000471939 00000 n
-0000012723 00000 n
-0000012776 00000 n
-0000249571 00000 n
-0000471860 00000 n
-0000012835 00000 n
-0000012884 00000 n
-0000249700 00000 n
-0000471781 00000 n
-0000012938 00000 n
-0000013018 00000 n
-0000255562 00000 n
-0000471648 00000 n
-0000013065 00000 n
-0000013117 00000 n
-0000255691 00000 n
-0000471569 00000 n
-0000013166 00000 n
-0000013210 00000 n
-0000259402 00000 n
-0000471437 00000 n
-0000013259 00000 n
-0000013321 00000 n
-0000259531 00000 n
-0000471358 00000 n
-0000013375 00000 n
-0000013423 00000 n
-0000259660 00000 n
-0000471279 00000 n
-0000013477 00000 n
-0000013528 00000 n
-0000259789 00000 n
-0000471200 00000 n
-0000013577 00000 n
-0000013624 00000 n
-0000262719 00000 n
-0000471067 00000 n
-0000013671 00000 n
-0000013708 00000 n
-0000262848 00000 n
-0000470949 00000 n
-0000013757 00000 n
-0000013796 00000 n
-0000262977 00000 n
-0000470884 00000 n
-0000013850 00000 n
-0000013928 00000 n
-0000263106 00000 n
-0000470791 00000 n
-0000013977 00000 n
-0000014044 00000 n
-0000263235 00000 n
-0000470712 00000 n
-0000014093 00000 n
-0000014138 00000 n
-0000266737 00000 n
-0000470593 00000 n
-0000014186 00000 n
-0000014218 00000 n
-0000266866 00000 n
-0000470475 00000 n
-0000014267 00000 n
-0000014306 00000 n
-0000266995 00000 n
-0000470410 00000 n
-0000014360 00000 n
-0000014421 00000 n
-0000271002 00000 n
-0000470278 00000 n
-0000014470 00000 n
-0000014527 00000 n
-0000271131 00000 n
-0000470213 00000 n
-0000014581 00000 n
-0000014630 00000 n
-0000271519 00000 n
-0000470095 00000 n
-0000014679 00000 n
-0000014741 00000 n
-0000271648 00000 n
-0000470016 00000 n
-0000014795 00000 n
-0000014850 00000 n
-0000284749 00000 n
-0000469923 00000 n
-0000014904 00000 n
-0000014945 00000 n
-0000285811 00000 n
-0000469844 00000 n
-0000014999 00000 n
-0000015051 00000 n
-0000015405 00000 n
-0000015653 00000 n
-0000015104 00000 n
-0000015527 00000 n
-0000015590 00000 n
-0000466703 00000 n
-0000441039 00000 n
-0000466529 00000 n
-0000439990 00000 n
-0000414055 00000 n
-0000439816 00000 n
-0000467708 00000 n
-0000016305 00000 n
-0000016120 00000 n
-0000015738 00000 n
-0000016242 00000 n
-0000413370 00000 n
-0000411224 00000 n
-0000413206 00000 n
-0000019484 00000 n
-0000018674 00000 n
-0000016390 00000 n
-0000018796 00000 n
-0000018920 00000 n
-0000019045 00000 n
-0000019170 00000 n
-0000410370 00000 n
-0000390012 00000 n
-0000410196 00000 n
-0000019295 00000 n
-0000019358 00000 n
-0000019421 00000 n
-0000389071 00000 n
-0000369672 00000 n
-0000388898 00000 n
-0000368945 00000 n
-0000352561 00000 n
-0000368772 00000 n
-0000024167 00000 n
-0000022985 00000 n
-0000019608 00000 n
-0000023479 00000 n
-0000352026 00000 n
-0000335109 00000 n
-0000351842 00000 n
-0000023542 00000 n
-0000023605 00000 n
-0000023729 00000 n
-0000023854 00000 n
-0000023979 00000 n
-0000023135 00000 n
-0000023328 00000 n
-0000024104 00000 n
-0000231131 00000 n
-0000271712 00000 n
-0000028690 00000 n
-0000027655 00000 n
-0000024291 00000 n
-0000028127 00000 n
-0000028252 00000 n
-0000027805 00000 n
-0000027967 00000 n
-0000028377 00000 n
-0000028502 00000 n
-0000028627 00000 n
-0000043932 00000 n
-0000031848 00000 n
-0000031289 00000 n
-0000028814 00000 n
-0000031411 00000 n
-0000031536 00000 n
-0000031661 00000 n
-0000031785 00000 n
-0000034734 00000 n
-0000033927 00000 n
-0000031959 00000 n
-0000034049 00000 n
-0000034174 00000 n
-0000034299 00000 n
-0000034424 00000 n
-0000034546 00000 n
-0000034671 00000 n
-0000467826 00000 n
-0000035770 00000 n
-0000035460 00000 n
-0000034819 00000 n
-0000035582 00000 n
-0000035707 00000 n
-0000037823 00000 n
-0000037138 00000 n
-0000035868 00000 n
-0000037260 00000 n
-0000037385 00000 n
-0000037509 00000 n
-0000037634 00000 n
-0000037760 00000 n
-0000040816 00000 n
-0000039949 00000 n
-0000037921 00000 n
-0000040250 00000 n
-0000040376 00000 n
-0000040439 00000 n
-0000040501 00000 n
-0000040091 00000 n
-0000040627 00000 n
-0000040753 00000 n
-0000189385 00000 n
-0000044121 00000 n
-0000043684 00000 n
-0000040927 00000 n
-0000043806 00000 n
-0000334582 00000 n
-0000325273 00000 n
-0000334405 00000 n
-0000044058 00000 n
-0000047626 00000 n
-0000047441 00000 n
-0000044245 00000 n
-0000047563 00000 n
-0000324830 00000 n
-0000318031 00000 n
-0000324653 00000 n
-0000051895 00000 n
-0000051505 00000 n
-0000047789 00000 n
-0000051832 00000 n
-0000051647 00000 n
-0000467944 00000 n
-0000106560 00000 n
-0000054068 00000 n
-0000053633 00000 n
-0000052032 00000 n
-0000053755 00000 n
-0000053881 00000 n
-0000053942 00000 n
-0000054005 00000 n
-0000057587 00000 n
-0000056549 00000 n
-0000054192 00000 n
-0000057021 00000 n
-0000057147 00000 n
-0000057273 00000 n
-0000056699 00000 n
-0000056860 00000 n
-0000057398 00000 n
-0000057524 00000 n
-0000140442 00000 n
-0000166934 00000 n
-0000062160 00000 n
-0000061369 00000 n
-0000057685 00000 n
-0000061845 00000 n
-0000061971 00000 n
-0000061519 00000 n
-0000061684 00000 n
-0000062097 00000 n
-0000276260 00000 n
-0000064989 00000 n
-0000064617 00000 n
-0000062310 00000 n
-0000064926 00000 n
-0000064759 00000 n
-0000066145 00000 n
-0000065960 00000 n
-0000065113 00000 n
-0000066082 00000 n
-0000069239 00000 n
-0000068550 00000 n
-0000066243 00000 n
-0000068672 00000 n
-0000068798 00000 n
-0000068924 00000 n
-0000069050 00000 n
-0000069176 00000 n
-0000468062 00000 n
-0000072619 00000 n
-0000071742 00000 n
-0000069376 00000 n
-0000072052 00000 n
-0000072178 00000 n
-0000072304 00000 n
-0000072430 00000 n
-0000072556 00000 n
-0000071884 00000 n
-0000226828 00000 n
-0000076716 00000 n
-0000076029 00000 n
-0000072756 00000 n
-0000076151 00000 n
-0000076277 00000 n
-0000076403 00000 n
-0000076528 00000 n
-0000076653 00000 n
-0000317678 00000 n
-0000315683 00000 n
-0000317515 00000 n
-0000080413 00000 n
-0000079853 00000 n
-0000076853 00000 n
-0000079975 00000 n
-0000080100 00000 n
-0000080226 00000 n
-0000080350 00000 n
-0000083375 00000 n
-0000082633 00000 n
-0000080537 00000 n
-0000082934 00000 n
-0000083060 00000 n
-0000082775 00000 n
-0000083186 00000 n
-0000083312 00000 n
-0000271195 00000 n
-0000083833 00000 n
-0000083648 00000 n
-0000083499 00000 n
-0000083770 00000 n
-0000086437 00000 n
-0000085874 00000 n
-0000083874 00000 n
-0000085996 00000 n
-0000086122 00000 n
-0000086248 00000 n
-0000086374 00000 n
-0000468180 00000 n
-0000086869 00000 n
-0000086684 00000 n
-0000086535 00000 n
-0000086806 00000 n
-0000090790 00000 n
-0000090042 00000 n
-0000086910 00000 n
-0000090350 00000 n
-0000090476 00000 n
-0000090601 00000 n
-0000090664 00000 n
-0000090727 00000 n
-0000090184 00000 n
-0000094744 00000 n
-0000095057 00000 n
-0000094496 00000 n
-0000090888 00000 n
-0000094618 00000 n
-0000094868 00000 n
-0000094994 00000 n
-0000098587 00000 n
-0000098024 00000 n
-0000095194 00000 n
-0000098146 00000 n
-0000098272 00000 n
-0000098398 00000 n
-0000098524 00000 n
-0000101201 00000 n
-0000102440 00000 n
-0000101079 00000 n
-0000098698 00000 n
-0000102126 00000 n
-0000314870 00000 n
-0000306196 00000 n
-0000314698 00000 n
-0000102252 00000 n
-0000102315 00000 n
-0000102378 00000 n
-0000106623 00000 n
-0000105810 00000 n
-0000102592 00000 n
-0000105932 00000 n
-0000106058 00000 n
-0000106182 00000 n
-0000106245 00000 n
-0000106308 00000 n
-0000106434 00000 n
-0000468298 00000 n
-0000111651 00000 n
-0000110085 00000 n
-0000106734 00000 n
-0000111084 00000 n
-0000110259 00000 n
-0000110409 00000 n
-0000111210 00000 n
-0000111336 00000 n
-0000111462 00000 n
-0000111588 00000 n
-0000110567 00000 n
-0000110718 00000 n
-0000110902 00000 n
-0000286325 00000 n
-0000114845 00000 n
-0000114282 00000 n
-0000111788 00000 n
-0000114404 00000 n
-0000114530 00000 n
-0000114656 00000 n
-0000114782 00000 n
-0000119363 00000 n
-0000119178 00000 n
-0000114982 00000 n
-0000119300 00000 n
-0000122390 00000 n
-0000122020 00000 n
-0000119474 00000 n
-0000122327 00000 n
-0000122162 00000 n
-0000125190 00000 n
-0000125379 00000 n
-0000124942 00000 n
-0000122501 00000 n
-0000125064 00000 n
-0000125253 00000 n
-0000125316 00000 n
-0000129097 00000 n
-0000128329 00000 n
-0000125490 00000 n
-0000128782 00000 n
-0000128908 00000 n
-0000129034 00000 n
-0000128479 00000 n
-0000128630 00000 n
-0000468416 00000 n
-0000131089 00000 n
-0000130526 00000 n
-0000129208 00000 n
-0000130648 00000 n
-0000130774 00000 n
-0000130900 00000 n
-0000131026 00000 n
-0000132625 00000 n
-0000132440 00000 n
-0000131200 00000 n
-0000132562 00000 n
-0000136439 00000 n
-0000136128 00000 n
-0000132723 00000 n
-0000136250 00000 n
-0000136376 00000 n
-0000140505 00000 n
-0000140019 00000 n
-0000136563 00000 n
-0000140316 00000 n
-0000140161 00000 n
-0000197293 00000 n
-0000144437 00000 n
-0000144127 00000 n
-0000140629 00000 n
-0000144249 00000 n
-0000144312 00000 n
-0000144374 00000 n
-0000148409 00000 n
-0000151142 00000 n
-0000148227 00000 n
-0000144561 00000 n
-0000151079 00000 n
-0000150045 00000 n
-0000150198 00000 n
-0000150354 00000 n
-0000150538 00000 n
-0000150711 00000 n
-0000150895 00000 n
-0000468534 00000 n
-0000149877 00000 n
-0000149934 00000 n
-0000150023 00000 n
-0000197679 00000 n
-0000155337 00000 n
-0000155152 00000 n
-0000151320 00000 n
-0000155274 00000 n
-0000159869 00000 n
-0000158946 00000 n
-0000155461 00000 n
-0000159429 00000 n
-0000159555 00000 n
-0000159096 00000 n
-0000159681 00000 n
-0000159806 00000 n
-0000159264 00000 n
-0000207975 00000 n
-0000163782 00000 n
-0000163282 00000 n
-0000159980 00000 n
-0000163594 00000 n
-0000163424 00000 n
-0000163720 00000 n
-0000259852 00000 n
-0000166997 00000 n
-0000166560 00000 n
-0000163906 00000 n
-0000166682 00000 n
-0000166808 00000 n
-0000305670 00000 n
-0000297780 00000 n
-0000305497 00000 n
-0000170997 00000 n
-0000170812 00000 n
-0000167162 00000 n
-0000170934 00000 n
-0000175025 00000 n
-0000174397 00000 n
-0000171108 00000 n
-0000174712 00000 n
-0000174836 00000 n
-0000174962 00000 n
-0000174539 00000 n
-0000468652 00000 n
-0000179097 00000 n
-0000178486 00000 n
-0000175190 00000 n
-0000178782 00000 n
-0000178908 00000 n
-0000178628 00000 n
-0000179034 00000 n
-0000182112 00000 n
-0000181794 00000 n
-0000179208 00000 n
-0000181919 00000 n
-0000182047 00000 n
-0000186072 00000 n
-0000185406 00000 n
-0000182278 00000 n
-0000185878 00000 n
-0000186007 00000 n
-0000185561 00000 n
-0000185723 00000 n
-0000189708 00000 n
-0000188941 00000 n
-0000186184 00000 n
-0000189256 00000 n
-0000189087 00000 n
-0000189449 00000 n
-0000189514 00000 n
-0000189643 00000 n
-0000194202 00000 n
-0000193524 00000 n
-0000189874 00000 n
-0000194008 00000 n
-0000193679 00000 n
-0000194137 00000 n
-0000193841 00000 n
-0000206081 00000 n
-0000197742 00000 n
-0000197038 00000 n
-0000194368 00000 n
-0000197164 00000 n
-0000197357 00000 n
-0000197421 00000 n
-0000197550 00000 n
-0000468774 00000 n
-0000202583 00000 n
-0000201630 00000 n
-0000197854 00000 n
-0000202260 00000 n
-0000201795 00000 n
-0000201945 00000 n
-0000202389 00000 n
-0000202518 00000 n
-0000202107 00000 n
-0000206275 00000 n
-0000205826 00000 n
-0000202695 00000 n
-0000205952 00000 n
-0000206210 00000 n
-0000208039 00000 n
-0000207720 00000 n
-0000206387 00000 n
-0000207846 00000 n
-0000211746 00000 n
-0000211169 00000 n
-0000208151 00000 n
-0000211295 00000 n
-0000211424 00000 n
-0000211553 00000 n
-0000211618 00000 n
-0000211683 00000 n
-0000216710 00000 n
-0000215208 00000 n
-0000211858 00000 n
-0000216387 00000 n
-0000216516 00000 n
-0000216645 00000 n
-0000215400 00000 n
-0000215562 00000 n
-0000215724 00000 n
-0000215886 00000 n
-0000216057 00000 n
-0000216227 00000 n
-0000221529 00000 n
-0000220300 00000 n
-0000216822 00000 n
-0000221464 00000 n
-0000220492 00000 n
-0000220655 00000 n
-0000220817 00000 n
-0000220979 00000 n
-0000221139 00000 n
-0000221301 00000 n
-0000468899 00000 n
-0000226892 00000 n
-0000224533 00000 n
-0000221654 00000 n
-0000226699 00000 n
-0000224779 00000 n
-0000224932 00000 n
-0000225094 00000 n
-0000225256 00000 n
-0000225418 00000 n
-0000225580 00000 n
-0000225742 00000 n
-0000225904 00000 n
-0000226066 00000 n
-0000226220 00000 n
-0000226381 00000 n
-0000226536 00000 n
-0000231452 00000 n
-0000230255 00000 n
-0000227017 00000 n
-0000230743 00000 n
-0000230808 00000 n
-0000230873 00000 n
-0000231002 00000 n
-0000231259 00000 n
-0000230411 00000 n
-0000230581 00000 n
-0000231324 00000 n
-0000231388 00000 n
-0000235060 00000 n
-0000234739 00000 n
-0000231577 00000 n
-0000234865 00000 n
-0000234930 00000 n
-0000234995 00000 n
-0000239098 00000 n
-0000238648 00000 n
-0000235159 00000 n
-0000238774 00000 n
-0000238839 00000 n
-0000238904 00000 n
-0000239033 00000 n
-0000242812 00000 n
-0000242102 00000 n
-0000239223 00000 n
-0000242228 00000 n
-0000242293 00000 n
-0000242358 00000 n
-0000242423 00000 n
-0000242488 00000 n
-0000242617 00000 n
-0000242682 00000 n
-0000242747 00000 n
-0000246688 00000 n
-0000245725 00000 n
-0000242937 00000 n
-0000245851 00000 n
-0000245980 00000 n
-0000246045 00000 n
-0000246110 00000 n
-0000246238 00000 n
-0000246302 00000 n
-0000246367 00000 n
-0000246496 00000 n
-0000246624 00000 n
-0000469024 00000 n
-0000249829 00000 n
-0000249251 00000 n
-0000246880 00000 n
-0000249377 00000 n
-0000249506 00000 n
-0000249635 00000 n
-0000249764 00000 n
-0000252798 00000 n
-0000252477 00000 n
-0000250021 00000 n
-0000252603 00000 n
-0000252668 00000 n
-0000252733 00000 n
-0000253251 00000 n
-0000253060 00000 n
-0000252910 00000 n
-0000253186 00000 n
-0000255820 00000 n
-0000254911 00000 n
-0000253293 00000 n
-0000255497 00000 n
-0000255626 00000 n
-0000255755 00000 n
-0000255067 00000 n
-0000255282 00000 n
-0000259916 00000 n
-0000259211 00000 n
-0000255945 00000 n
-0000259337 00000 n
-0000297459 00000 n
-0000288246 00000 n
-0000297273 00000 n
-0000259466 00000 n
-0000259595 00000 n
-0000259724 00000 n
-0000263363 00000 n
-0000262137 00000 n
-0000260081 00000 n
-0000262654 00000 n
-0000262783 00000 n
-0000262912 00000 n
-0000263041 00000 n
-0000263170 00000 n
-0000263299 00000 n
-0000262293 00000 n
-0000262465 00000 n
-0000469149 00000 n
-0000263816 00000 n
-0000263625 00000 n
-0000263475 00000 n
-0000263751 00000 n
-0000267124 00000 n
-0000266546 00000 n
-0000263858 00000 n
-0000266672 00000 n
-0000266801 00000 n
-0000266930 00000 n
-0000267059 00000 n
-0000271776 00000 n
-0000270426 00000 n
-0000267210 00000 n
-0000270937 00000 n
-0000271066 00000 n
-0000271259 00000 n
-0000271324 00000 n
-0000271389 00000 n
-0000271454 00000 n
-0000271583 00000 n
-0000270582 00000 n
-0000270760 00000 n
-0000278658 00000 n
-0000274598 00000 n
-0000271927 00000 n
-0000274772 00000 n
-0000275480 00000 n
-0000274950 00000 n
-0000275128 00000 n
-0000275304 00000 n
-0000275545 00000 n
-0000275610 00000 n
-0000275675 00000 n
-0000275740 00000 n
-0000275805 00000 n
-0000275870 00000 n
-0000275935 00000 n
-0000276000 00000 n
-0000276065 00000 n
-0000276130 00000 n
-0000276195 00000 n
-0000276324 00000 n
-0000276389 00000 n
-0000276454 00000 n
-0000276519 00000 n
-0000276584 00000 n
-0000276648 00000 n
-0000276713 00000 n
-0000276777 00000 n
-0000276842 00000 n
-0000276907 00000 n
-0000276972 00000 n
-0000277037 00000 n
-0000277101 00000 n
-0000277166 00000 n
-0000277231 00000 n
-0000277296 00000 n
-0000277361 00000 n
-0000277426 00000 n
-0000277491 00000 n
-0000277555 00000 n
-0000277620 00000 n
-0000277685 00000 n
-0000277750 00000 n
-0000277815 00000 n
-0000277880 00000 n
-0000277945 00000 n
-0000278010 00000 n
-0000278075 00000 n
-0000278140 00000 n
-0000278205 00000 n
-0000278270 00000 n
-0000278335 00000 n
-0000278400 00000 n
-0000278465 00000 n
-0000278530 00000 n
-0000278594 00000 n
-0000284877 00000 n
-0000281570 00000 n
-0000278809 00000 n
-0000281696 00000 n
-0000281761 00000 n
-0000281826 00000 n
-0000281891 00000 n
-0000281956 00000 n
-0000282021 00000 n
-0000282085 00000 n
-0000282150 00000 n
-0000282215 00000 n
-0000282280 00000 n
-0000282345 00000 n
-0000282410 00000 n
-0000282475 00000 n
-0000282540 00000 n
-0000282605 00000 n
-0000282670 00000 n
-0000282735 00000 n
-0000282800 00000 n
-0000282865 00000 n
-0000282930 00000 n
-0000282995 00000 n
-0000283060 00000 n
-0000283125 00000 n
-0000283190 00000 n
-0000283254 00000 n
-0000283319 00000 n
-0000283384 00000 n
-0000283449 00000 n
-0000283514 00000 n
-0000283579 00000 n
-0000283644 00000 n
-0000283709 00000 n
-0000283774 00000 n
-0000283839 00000 n
-0000283904 00000 n
-0000283969 00000 n
-0000284034 00000 n
-0000284099 00000 n
-0000284164 00000 n
-0000284229 00000 n
-0000284294 00000 n
-0000284359 00000 n
-0000284424 00000 n
-0000284489 00000 n
-0000284554 00000 n
-0000284619 00000 n
-0000284684 00000 n
-0000284813 00000 n
-0000286200 00000 n
-0000285620 00000 n
-0000284989 00000 n
-0000285746 00000 n
-0000285875 00000 n
-0000285940 00000 n
-0000286005 00000 n
-0000286070 00000 n
-0000286135 00000 n
-0000469274 00000 n
-0000286357 00000 n
-0000297701 00000 n
-0000305945 00000 n
-0000315264 00000 n
-0000317923 00000 n
-0000317892 00000 n
-0000325072 00000 n
-0000334868 00000 n
-0000352366 00000 n
-0000369353 00000 n
-0000389635 00000 n
-0000410774 00000 n
-0000413857 00000 n
-0000413627 00000 n
-0000440544 00000 n
-0000467222 00000 n
-0000469354 00000 n
-0000469474 00000 n
-0000469597 00000 n
-0000469686 00000 n
-0000469768 00000 n
-0000483639 00000 n
-0000495601 00000 n
-0000495642 00000 n
-0000495682 00000 n
-0000495816 00000 n
-trailer
-<<
-/Size 1362
-/Root 1360 0 R
-/Info 1361 0 R
-/ID [<398C74303A70323E9600C964366A931D> <398C74303A70323E9600C964366A931D>]
->>
-startxref
-496080
-%%EOF
diff --git a/contrib/bind9/doc/arm/Makefile.in b/contrib/bind9/doc/arm/Makefile.in
deleted file mode 100644
index 88a54e30a5426..0000000000000
--- a/contrib/bind9/doc/arm/Makefile.in
+++ /dev/null
@@ -1,63 +0,0 @@
-# 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
-# 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: Makefile.in,v 1.8.2.2.8.5 2005/05/13 01:22:35 marka Exp $
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-top_srcdir = @top_srcdir@
-
-@BIND9_MAKE_RULES@
-
-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} ${PDFOBJS}
-
-clean::
- rm -f Bv9ARM.aux Bv9ARM.brf Bv9ARM.glo Bv9ARM.idx
- rm -f Bv9ARM.log Bv9ARM.out Bv9ARM.tex Bv9ARM.tex.tmp
-
-docclean manclean maintainer-clean:: clean
- rm -f *.html *.pdf
-
-Bv9ARM.html: Bv9ARM-book.xml
- ${XSLTPROC} --stringparam root.filename Bv9ARM \
- ${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl \
- 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.dvi: Bv9ARM.tex
- rm -f Bv9ARM-book.aux Bv9ARM-book.dvi Bv9ARM-book.log
- ${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
- ${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
- ${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
-
-Bv9ARM.pdf: Bv9ARM.tex
- rm -f Bv9ARM-book.aux Bv9ARM-book.pdf Bv9ARM-book.log
- ${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/arm/README-SGML b/contrib/bind9/doc/arm/README-SGML
deleted file mode 100644
index 8e7bc4ebd8495..0000000000000
--- a/contrib/bind9/doc/arm/README-SGML
+++ /dev/null
@@ -1,329 +0,0 @@
-Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001 Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-The BIND v9 ARM master document is now kept in DocBook XML format.
-
-Version: $Id: README-SGML,v 1.16.206.1 2004/03/06 13:16:14 marka Exp $
-
-The entire ARM is in the single file:
-
- Bv9ARM-book.xml
-
-All of the other documents - HTML, PDF, etc - are generated from this
-master source.
-
-This file attempts to describe what tools are necessary for the
-maintenance of this document as well as the generation of the
-alternate formats of this document.
-
-This file will also spend a very little time describing the XML and
-SGML headers so you can understand a bit what you may need to do to be
-able to work with this document in any fashion other than simply
-editing it.
-
-We will spend almost no time on the actual tags and how to write an
-XML DocBook compliant document. If you are at all familiar with SGML
-or HTML it will be very evident. You only need to know what the tags
-are and how to use them. You can find a good resource either for this
-either online or in printed form:
-
- DocBook: The Definitive Guide
- By Norman Walsh and Leonard Muellner
- ISBN: 156592-580-7
- 1st Edition, October 1999
- Copyright (C) 1999 by O'Reilly & Associates, Inc. All rights reserved.
-
-The book is available online in HTML format:
-
- http://docbook.org/
-
-and buried in:
-
- http://www.nwalsh.com/docbook/defguide/index.html
-
-A lot of useful stuff is at NWalsh's site in general. You may also
-want to look at:
-
- http://www.xml.com/
-
-The BIND v9 ARM is based on the XML 4.0 DocBook DTD. Every XML and
-SGML document begins with a prefix that tells where to find the file
-that describes the meaning and structure of the tags used in the rest
-of the document.
-
-For our XML DocBook 4.0 based document this prefix looks like this:
-
- <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
- "/usr/local/share/xml/dtd/docbook/docbookx.dtd">
-
-This "DOCTYPE" statement has three parts, of which we are only using
-two:
-
-o The highest level term that represents this document (in this case
- it is "book"
-
-o The identifier that tells us which DTD to use. This identifier has
- two parts, the "Formal Public Identifier" (or FPI) and the system
- identifier. In SGML you can have either a FPI or a SYSTEM identifier
- but you have to have at least one of them. In XML you have to have a
- SYSTEM identifier.
-
-FP & SYSTEM identifiers - These are names/lookups for the actual
-DTD. The FPI is a globally unique name that should, on a properly
-configured system, tell you exactly what DTD to use. The SYSTEM
-identifier gives an absolute location for the DTD. In XML these are
-supposed to be properly formatted URL's.
-
-SGML has these things called "catalogs" that are files that map FPI's
-in to actual files. A "catalog" can also be used to remap a SYSTEM
-identifier so you can say something like: "http://www.oasis.org/foo"
-is actually "/usr/local/share/xml/foo.dtd"
-
-When you use various SGML/XML tools they need to be configured to look
-at the same "catalog" files so that as you move from tool to tool they
-all refer to the same DTD for the same document.
-
-We will be spending most of our configuration time making sure our
-tools use the same "catalog" files and that we have the same DTD's
-installed on our machines. XML's requirement of the SYSTEM identifier
-over the FPI will probably lead to more problems as it does not
-guarantee that everyone is using the same DTD.
-
-I did my initial work with the "sgmltools" the XML 4.0 DocBook DTD and
-"jade" or "openjade."
-
-You can get the 4.0 XML DocBook DTD from:
-
- http://www.docbook.org/xml/4.0/
-
-(download the .zip file.) NOTE: We will eventually be changing the
-SYSTEM identifier to the recommended value of:
-
- http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd
-
-NOTE: Under FreeBSD this is the package:
-
- /usr/ports/textproc/docbook-xml
-
-NetBSD instructions are coming soon.
-
-With packages listed below installed under FreeBSD the "catalog" file
-that all the tools refer to at least one is in:
-
- /usr/local/share/sgml/catalog
-
-In order for our SYSTEM identifier for the XML DocBook dtd to be found
-I create a new catalog file at the top of the XML directory created on
-FreeBSD:
-
- /usr/local/share/xml/catalog
-
-This file has one line:
-
- SYSTEM "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" "/usr/local/share/xml/dtd/docbook/docbookx.dtd"
-
-Then in the main "catalog" I have it include this XML catalog:
-
- CATALOG "/usr/local/share/xml/catalog"
-
-
-On your systems you need to replace "/usr/local/share" with your
-prefix root (probably /usr/pkg under NetBSD.)
-
-NOTE: The URL used above is supposed to the be the proper one for this
-XML DocBook DTD... but there is nothing at that URL so you really do
-need the "SYSTEM" identifier mapping in your catalog (or make the
-SYSTEM identifier in your document refer to the real location of the
-file on your local system.)
-
-HOW TO VALIDATE A DOCUMENT:
-
-I use the sgmltools "nsgmls" document validator. Since we are using
-XML we need to use the XML declarations, which are installed as part
-of the modular DSSL style sheets:
-
- nsgmls -sv /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
- Bv9ARM-book.xml
-
-A convenient shell script "validate.sh" is now generated by configure
-to invoke the above command with the correct system-dependent paths.
-
-The SGML tools can be found at:
-
- ftp://ftp.us.sgmltools.org/pub/SGMLtools/v2.0/source/ \
- ftp://ftp.nllgg.nl/pub/SGMLtools/v2.0/source/
-
-FreeBSD package for these is:
-
- /usr/ports/textproc/sgmltools
-
-HOW TO RENDER A DOCUMENT AS HTML or TeX:
-
-o Generate html doc with:
-
- openjade -v -d ./nominum-docbook-html.dsl \
- -t sgml \
- /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
- Bv9ARM-book.xml
-
-A convenient shell script "genhtml.sh" is now generated by configure to
-invoke the above command with the correct system-dependent paths.
-
-On NetBSD there is no port for "openjade" however "jade" does still
-work. However you need to specify the "catalog" file to use for style
-sheets on the command line AND you need to have a default "catalog"
-mapping where to find various DTDs. It seems that "jade" installed out
-of the box on NetBSD does not use a globally defined "catalog" file
-for mapping PUBLIC identifiers in to SYSTEM identifiers.
-
-So you need to have a "catalog" file in your current working directory
-that has in it this: (these are probably more entries than you need!)
-
- CATALOG "/usr/pkg/share/sgml/iso8879/catalog"
- CATALOG "/usr/pkg/share/sgml/docbook/2.4.1/catalog"
- CATALOG "/usr/pkg/share/sgml/docbook/3.0/catalog"
- CATALOG "/usr/pkg/share/sgml/docbook/3.1/catalog"
- CATALOG "/usr/pkg/share/sgml/jade/catalog"
- CATALOG "/usr/local/share/xml/catalog"
-
-(These would all be "/usr/local" on FreeBSD)
-
-So the command for jade on NetBSD will look like this:
-
-jade -v -c /usr/pkg/share/sgml/catalog -t sgml \
- -d ./nominum-docbook-html.dsl \
- /usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
- ./Bv9ARM-book.xml
-
-Furthermore, since the style sheet subset we define has in it a hard
-coded path to the style sheet is based, it is actually generated by
-configure from a .in file so that it will contain the correct
-system-dependent path: where on FreeBSD the second line reads:
-
- <!ENTITY dbstyle SYSTEM "/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
-
-On NetBSD it needs to read:
-
- <!ENTITY dbstyle SYSTEM "/usr/pkg/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
-
-NOTE: This is usually solved by having this style sheet modification
-be installed in a system directory and have it reference the style
-sheet it is based on via a relative path.
-
-o Generate TeX documentation:
-
-openjade -d ./nominum-docbook-print.dsl -t tex -v \
- /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
- Bv9ARM-book.xml
-
-If you have "jade" installed instead of "openjade" then use that as
-the command. There is little difference, openjade has some bug fixes
-and is in more active development.
-
-To convert the resulting TeX file in to a DVI file you need to do:
-
- tex "&jadetex" Bv9ARM-book.tex
-
-You can also directly generate the pdf file via:
-
- pdftex "&pdfjadetex" Bv9ARM-book.tex
-
-The scripts "genpdf.sh" and "gendvi." have been added to simply
-generating the PDF and DVI output. These substitute the correct paths
-of NetBSD & FreeBSD. You still need to have TeX, jadeTeX, and pdfTeX
-installed and configured properly for these to work.
-
-You will need to up both the "pool_size" and "hash_extra" variables in
-your texmf.cnf file and regenerate them. See below.
-
-You can see that I am using a DSSSL style sheet for DocBook. Actually
-two different ones - one for rendering html, and one for 'print'
-media.
-
-NOTE: For HTML we are using a Nominum DSSSL style instead of the
-default one (all it does is change the chunking to the chapter level
-and makes the files end with ".html" instead of ".htm" so far.) If you
-want to use the plain jane DSSSL style sheet replace the:
-
- -d ./nominum-docbook-html.dsl
-
-with
-
- -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl
-
-This style sheet will attempt to reference the one above.
-
-I am currently working on fixing these up so that it works the same on
-our various systems. The main trick is knowing which DTD's and DSSSL
-stylesheets you have installed, installing the right ones, and
-configuring a CATALOG that refers to them in the same way. We will
-probably end up putting our CATALOG's in the same place and then we
-should be able to generate and validate our documents with a minimal
-number of command line arguments.
-
-When running these commands you will get a lot of messages about a
-bunch of general entities not being defined and having no default
-entity. You can ignore those for now.
-
-Also with the style sheets we have and jade as it is you will get
-messages about "xref to title" being unsupported. You can ignore these
-for now as well.
-
-=== Getting the various tools installed on FreeBSD
-(NetBSD coming soon..)
-
-o On freebsd you need to install the following packages:
- o print/teTeX
- o textproc/openjade
- o textproc/docbook
- o textproc/docbook-xml
- o textproc/dsssl-docbook-modular
- o textproc/dtd-catalogs
-
-o on freebsd you need to make some entities visible to the docbook xml
- dtd by making a symlink (can probably be done with a catalog too)
- ln -s /usr/local/share/xml/entity /usr/local/share/xml/dtd/docbook/ent
-
-o you may need to edit /usr/local/share/sgml/catalog and add the line:
-
- CATALOG "/usr/local/share/sgml/openjade/catalog"
-
-o add "hugelatex," Enlarge pool sizes, install the jadetex TeX driver
- file.
-
- cd /usr/local/share/texmf/web2c/
- sudo cp texmf.cnf texmf.cnf.bak
-
- o edit the lines in texmf.cnf with these keys to these values:
-
- main_memory = 1100000
- hash_extra = 15000
- pool_size = 500000
- string_vacancies = 45000
- max_strings = 55000
- pool_free = 47500
- nest_size = 500
- param_size = 1500
- save_size = 5000
- stack_size = 1500
-
- sudo tex -ini -progname=hugelatex -fmt=hugelatex latex.ltx
- sudo texconfig init
- sudo texhash
-
- o For the jadetex macros you will need I recommend you get a more
- current version than what is packaged with openjade or jade.
-
- Checkout http://www.tug.org/applications/jadetex/
-
- Unzip the file you get from there (should be jadetex-2.20 or
- newer.)
-
- In the directory you unzip:
-
- sudo make install
- sudo texhash
-
- NOTE: In the most uptodate "ports" for FreeBSD, jadetext is 2.20+
- so on this platform you should be set as of 2001.01.08.
diff --git a/contrib/bind9/doc/arm/isc.color.gif b/contrib/bind9/doc/arm/isc.color.gif
deleted file mode 100644
index 09c327cca65df..0000000000000
--- a/contrib/bind9/doc/arm/isc.color.gif
+++ /dev/null
Binary files differ
diff --git a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in
deleted file mode 100644
index 33fc938777a4d..0000000000000
--- a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in
+++ /dev/null
@@ -1,148 +0,0 @@
-<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
-<!ENTITY dbstyle SYSTEM "@HTMLSTYLE@" CDATA DSSSL>
-]>
-
-<style-sheet>
-<style-specification use="docbook">
-<style-specification-body>
-
-<!-- ;; your stuff goes here... -->
-
-(define %html-prefix%
- ;; Add the specified prefix to HTML output filenames
- "Bv9ARM.")
-
-(define %use-id-as-filename%
- ;; Use ID attributes as name for component HTML files?
- #t)
-
-(define %root-filename%
- ;; Name for the root HTML document
- "Bv9ARM")
-
-(define %section-autolabel%
- ;; REFENTRY section-autolabel
- ;; PURP Are sections enumerated?
- ;; DESC
- ;; If true, unlabeled sections will be enumerated.
- ;; /DESC
- ;; AUTHOR N/A
- ;; /REFENTRY
- #t)
-
-(define %html-ext%
- ;; REFENTRY html-ext
- ;; PURP Default extension for HTML output files
- ;; DESC
- ;; The default extension for HTML output files.
- ;; /DESC
- ;; AUTHOR N/A
- ;; /REFENTRY
- ".html")
-
-(define nochunks
- ;; REFENTRY nochunks
- ;; PURP Suppress chunking of output pages
- ;; DESC
- ;; If true, the entire source document is formatted as a single HTML
- ;; document and output on stdout.
- ;; (This option can conveniently be set with '-V nochunks' on the
- ;; Jade command line).
- ;; /DESC
- ;; AUTHOR N/A
- ;; /REFENTRY
- #f)
-
-(define rootchunk
- ;; REFENTRY rootchunk
- ;; PURP Make a chunk for the root element when nochunks is used
- ;; DESC
- ;; If true, a chunk will be created for the root element, even though
- ;; nochunks is specified. This option has no effect if nochunks is not
- ;; true.
- ;; (This option can conveniently be set with '-V rootchunk' on the
- ;; Jade command line).
- ;; /DESC
- ;; AUTHOR N/A
- ;; /REFENTRY
- #t)
-
-(define html-index
- ;; REFENTRY html-index
- ;; PURP HTML indexing?
- ;; DESC
- ;; Turns on HTML indexing. If true, then index data will be written
- ;; to the file defined by 'html-index-filename'. This data can be
- ;; collated and turned into a DocBook index with bin/collateindex.pl.
- ;; /DESC
- ;; AUTHOR N/A
- ;; /REFENTRY
- #t)
-
-(define html-manifest
- ;; REFENTRY html-manifest
- ;; PURP Write a manifest?
- ;; DESC
- ;; If not '#f' then the list of HTML files created by the stylesheet
- ;; will be written to the file named by 'html-manifest-filename'.
- ;; /DESC
- ;; AUTHOR N/A
- ;; /REFENTRY
- #t)
-
-(define (chunk-element-list)
- (list (normalize "preface")
- (normalize "chapter")
- (normalize "appendix")
- (normalize "article")
- (normalize "glossary")
- (normalize "bibliography")
- (normalize "index")
- (normalize "colophon")
- (normalize "setindex")
- (normalize "reference")
- (normalize "refentry")
- (normalize "part")
- (normalize "book") ;; just in case nothing else matches...
- (normalize "set") ;; sets are definitely chunks...
- ))
-
-;
-; Add some cell padding to tables so that they don't look so cramped
-; in Netscape.
-;
-; The following definition was cut-and-pasted from dbtable.dsl and the
-; single line containing the word CELLPADDING was added.
-;
-(element tgroup
- (let* ((wrapper (parent (current-node)))
- (frameattr (attribute-string (normalize "frame") wrapper))
- (pgwide (attribute-string (normalize "pgwide") wrapper))
- (footnotes (select-elements (descendants (current-node))
- (normalize "footnote")))
- (border (if (equal? frameattr (normalize "none"))
- '(("BORDER" "0"))
- '(("BORDER" "1"))))
- (width (if (equal? pgwide "1")
- (list (list "WIDTH" ($table-width$)))
- '()))
- (head (select-elements (children (current-node)) (normalize "thead")))
- (body (select-elements (children (current-node)) (normalize "tbody")))
- (feet (select-elements (children (current-node)) (normalize "tfoot"))))
- (make element gi: "TABLE"
- attributes: (append
- '(("CELLPADDING" "3"))
- border
- width
- (if %cals-table-class%
- (list (list "CLASS" %cals-table-class%))
- '()))
- (process-node-list head)
- (process-node-list body)
- (process-node-list feet)
- (make-table-endnotes))))
-
-</style-specification-body>
-</style-specification>
-<external-specification id="docbook" document="dbstyle">
-</style-sheet>
diff --git a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in
deleted file mode 100644
index 511d6c48bc8c5..0000000000000
--- a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in
+++ /dev/null
@@ -1,42 +0,0 @@
-<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
-<!ENTITY dbstyle SYSTEM "@PRINTSTYLE@" CDATA DSSSL>
-]>
-
-
-<style-sheet>
-<style-specification use="docbook">
-<style-specification-body>
-
-<!-- ;; your stuff goes here... -->
-
-(define %generate-book-titlepage% #t)
-
-(define %section-autolabel%
- ;; REFENTRY section-autolabel
- ;; PURP Are sections enumerated?
- ;; DESC
- ;; If true, unlabeled sections will be enumerated.
- ;; /DESC
- ;; AUTHOR N/A
- ;; /REFENTRY
- #t)
-
-;; Margins around cell contents
-;; (define %cals-cell-before-row-margin% 20pt)
-;; (define %cals-cell-after-row-margin% 20pt)
-
-;; seems to be a bug in JadeTeX -- we get a wierd indent on table
-;; cells for the first line only. This is a workaround.
-;; Adam Di Carlo, adam@onshore.com
-(define %cals-cell-before-column-margin% 5pt)
-(define %cals-cell-after-column-margin% 5pt)
-
-;; Inheritable start and end indent for cell contents
-(define %cals-cell-content-start-indent% 5pt)
-(define %cals-cell-content-end-indent% 5pt)
-
-
-</style-specification-body>
-</style-specification>
-<external-specification id="docbook" document="dbstyle">
-</style-sheet>
diff --git a/contrib/bind9/doc/arm/validate.sh.in b/contrib/bind9/doc/arm/validate.sh.in
deleted file mode 100644
index f50d8a09dbda8..0000000000000
--- a/contrib/bind9/doc/arm/validate.sh.in
+++ /dev/null
@@ -1,21 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2004 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,
-# 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: validate.sh.in,v 1.2.206.1 2004/03/06 13:16:14 marka Exp $
-
-nsgmls -sv @SGMLDIR@/docbook/dsssl/modular/dtds/decls/xml.dcl \
- Bv9ARM-book.xml
diff --git a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
deleted file mode 100644
index 1030e5782ef90..0000000000000
--- a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-
-Internet-Draft T. Baba
-Expires: March 11, 2004 NTT Data
- September 11, 2003
-
-
- Requirements for Access Control in Domain Name Systems
- draft-baba-dnsext-acl-reqts-01.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 10 of RFC2026.
-
- 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
-
- Distribution of this memo is unlimited.
-
- This Internet-Draft will expire on March 11, 2004.
-
-Abstract
-
- This document describes the requirements for access control
- mechanisms in the Domain Name System (DNS), which authenticate
- clients and then allow or deny access to resource records in the
- zone according to the access control list (ACL).
-
-1. Introduction
-
- The Domain Name System (DNS) is a hierarchical, distributed, highly
- available database used for bi-directional mapping between domain
- names and IP addresses, for email routing, and for other information
- [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined
- to authenticate the data in DNS and provide key distribution services
- using SIG, KEY, and NXT resource records (RRs) [RFC2535].
-
-
-
-Baba Expires March 11, 2004 [Page 1]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
- At the 28th IETF Meeting in Houston in 1993, DNS security design team
- started a discussion about DNSSEC and agreed to accept the assumption
- that "DNS data is public". Accordingly, confidentiality for queries
- or responses is not provided by DNSSEC, nor are any sort of access
- control lists or other means to differentiate inquirers. However,
- about ten years has passed, access control in DNS has been more
- important than before. Currently, new RRs are proposed to add new
- functionality to DNS such as ENUM [RFC2916]. Such new RRs may
- contain private information. Thus, DNS access control will be
- needed.
-
- Furthermore, with DNS access control mechanism, access from
- unauthorized clients can be blocked when they perform DNS name
- resolution. Thus, for example, Denial of Service (DoS) attacks
- against a server used by a closed user group can be prevented using
- this mechanism if IP address of the server is not revealed by other
- sources.
-
- This document describes the requirements for access control
- mechanisms in DNS.
-
-2. Terminology
-
- AC-aware client
- This is the client that understands the DNS access control
- extensions. This client may be an end host which has a stub
- resolver, or a cashing/recursive name server which has a
- full-service resolver.
-
- AC-aware server
- This is the authoritative name server that understands the DNS
- access control extensions.
-
- ACE
- An Access Control Entry. This is the smallest unit of access
- control policy. It grants or denies a given set of access
- rights to a set of principals. An ACE is a component of an ACL,
- which is associated with a resource.
-
- ACL
- An Access Control List. This contains all of the access control
- policies which are directly associated with a particular
- resource. These policies are expressed as ACEs.
-
- Client
- A program or host which issues DNS requests and accepts its
- responses. A client may be an end host or a cashing/recursive name
- server.
-
-
-
-Baba Expires March 11, 2004 [Page 2]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
- RRset
- All resource records (RRs) having the same NAME, CLASS and TYPE
- are called a Resource Record Set (RRset).
-
-3. Requirements
-
- This section describes the requirements for access control in DNS.
-
-3.1 Authentication
-
-3.1.1 Client Authentication Mechanism
-
- The AC-aware server must identify AC-aware clients based on IP
- address and/or domain name (user ID or host name), and must
- authenticate them using strong authentication mechanism such as
- digital signature or message authentication code (MAC).
-
- SIG(0) RR [RFC2931] contains a domain name associated with sender's
- public key in its signer's name field, and TSIG RR [RFC2845] also
- contains a domain name associated with shared secret key in its key
- name field. Each of these domain names can be a host name or a user
- name, and can be used as a sender's identifier for access control.
- Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
- message authentication. These mechanisms can be used to authenticate
- AC-aware clients.
-
- Server authentication may be also provided.
-
-3.1.2 End-to-End Authentication
-
- In current DNS model, caching/recursive name servers are deployed
- between end hosts and authoritative name servers. Although
- authoritative servers can authenticate caching/recursive name servers
- using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
- For end-to-end authentication, the mechanism for an end host to
- discover the target authoritative name server and directly access to
- it bypassing caching/recursive name servers is needed. For example,
- an end host can get the IP addresses of the authoritative name
- servers by retrieving NS RRs for the zone via local caching/recursive
- name server.
-
- In many enterprise networks, however, there are firewalls that block
- all DNS packets other than those going to/from the particular
- caching/recursive servers. To deal with this problem, one can
- implement packet forwarding function on the caching/recursive servers
- and enable end-to-end authentication via the caching/recursive
- servers.
-
-
-
-
-Baba Expires March 11, 2004 [Page 3]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
-3.1.3 Authentication Key Retrieval
-
- Keys which are used to authenticate clients should be able to be
- automatically retrieved. The KEY RR is used to store a public key
- for a zone or a host that is associated with a domain name. SIG(0)
- RR uses a public key in KEY RR for verifying the signature. If
- DNSSEC is available, the KEY RR would be protected by the SIG RR.
- KEY RR or newly defined RR can be used to automatic key retrieval.
-
-3.2 Confidentiality
-
-3.2.1 Data Encryption
-
- To avoid disclosure to eavesdroppers, the response containing the
- RRsets which are restricted to access from particular users should be
- encrypted. Currently, no encryption mechanism is specified in DNS.
- Therefore, new RRs should be defined for DNS message encryption.
- Instead, IPsec [RFC2401] can be used to provide confidentiality if
- name server and resolver can set up security associations dynamically
- using IPsec API [IPSECAPI] when encryption is required.
-
- In case encryption is applied, entire DNS message including DNS
- header should be encrypted to hide information including error code.
-
- Query encryption may be also provided for hiding query information.
-
-3.2.2 Key Exchange
-
- If DNS message encryption is provided, automatic key exchange
- mechanism should be also provided. [RFC2930] specifies a TKEY RR
- that can be used to establish and delete shared secret keys used by
- TSIG between a client and a server. With minor extensions, TKEY can
- be used to establish shared secret keys used for message encryption.
-
-3.2.3 Caching
-
- The RRset that is restricted to access from particular users must not
- be cached. To avoid caching, the TTL of the RR that is restricted to
- access should be set to zero during transit.
-
-3.3 Access Control
-
-3.3.1 Granularity of Access Control
-
- Control of access on a per-user/per-host granularity must be
- supported. Control of access to individual RRset (not just the
- entire zone) must be also supported. However, SOA, NS, SIG, NXT,
- KEY, and DS RRs must be publicly accessible to avoid unexpected
- results.
-
-
-Baba Expires March 11, 2004 [Page 4]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
-3.3.2 ACL Representation
-
- Access Control List (ACL) format must be standardized so that both
- the primary and secondary AC-aware servers can recognize the same
- ACL. Although ACL may appear in or out of zone data, it must be
- transferred to the secondary AC-aware server with associated zone
- data. It is a good idea to contain ACL in zone data, because ACL can
- be transferred with zone data using existing zone transfer mechanisms
- automatically. However, ACL must not be published except for
- authorized secondary master servers.
-
- In zone data master files, ACL should be specified using TXT RRs or
- newly defined RRs. In each access control entry (ACE), authorized
- entities (host or user) must be described using domain name (host
- name, user name, or IP address in in-addr.arpa/ip6.arpa format).
- There may be other access control attributes such as access time.
-
- It must be possible to create publicly readable entries, which may be
- read even by unauthenticated clients.
-
-3.3.3 Zone/ACL Transfer
-
- As mentioned above, ACL should be transferred from a primary AC-aware
- server to a secondary AC-aware server with associated zone data.
- When an AC-aware server receives a zone/ACL transfer request, the
- server must authenticate the client, and should encrypt the zone
- data and associated ACL during transfer.
-
-3.4 Backward/co-existence Compatibility
-
- Any new protocols to be defined for access control in DNS must be
- backward compatible with existing DNS protocol. AC-aware servers
- must be able to process normal DNS query without authentication, and
- must respond if retrieving RRset is publicly accessible.
-
- Modifications to root/gTLD/ccTLD name servers are not allowed.
-
-4. Security Considerations
-
- This document discusses the requirements for access control
- mechanisms in DNS.
-
-5. Acknowledgements
-
- This work is funded by the Telecommunications Advancement
- Organization of Japan (TAO).
-
- The author would like to thank the members of the NTT DATA network
- security team for their important contribution to this work.
-
-
-Baba Expires March 11, 2004 [Page 5]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
-6. 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.
-
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
- September 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
- RFC 2930, September 2000.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
- [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
- draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
- Progress.
-
-
-Author's Address
-
- Tatsuya Baba
- NTT Data Corporation
- Research and Development Headquarters
- Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
- Tokyo 104-0033, Japan
-
- Tel: +81 3 3523 8081
- Fax: +81 3 3523 8090
- Email: babatt@nttdata.co.jp
-
-
-
-
-
-
-
-
-Baba Expires March 11, 2004 [Page 6]
diff --git a/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt b/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt
deleted file mode 100644
index fffa8a5f20b3d..0000000000000
--- a/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-Network Working Group L. Daigle
-Internet-Draft A. Newton
-Expires: August 15, 2004 VeriSign, Inc.
- February 15, 2004
-
-
- Domain-based Application Service Location Using SRV RRs and the
- Dynamic Delegation Discovery Service (DDDS)
- draft-daigle-napstr-04.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 15, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This memo defines a generalized mechanism for application service
- naming that allows service location without relying on rigid domain
- naming conventions (so-called name hacks). The proposal defines a
- Dynamic Delegation Discovery System (DDDS) Application to map domain
- name, application service name, and application protocol to target
- server and port, dynamically.
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 1]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4
- 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5
- 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5
- 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5
- 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5
- 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6
- 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6
- 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.1 Guidelines for Application Protocol Developers . . . . . . . 7
- 3.1.1 Registration of application service and protocol tags . . . 7
- 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8
- 3.1.3 Server identification and handshake . . . . . . . . . . . . 8
- 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8
- 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9
- 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9
- 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10
- 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
- 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
- 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12
- 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12
- 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14
- 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15
- 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 16
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
- References . . . . . . . . . . . . . . . . . . . . . . . . . 17
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
- A. Application Service Location Application of DDDS . . . . . . 18
- A.1 Application Unique String . . . . . . . . . . . . . . . . . 18
- A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18
- A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18
- A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
- A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
- A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20
- A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20
- A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20
- B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20
- B.1 Finding the first (best) target . . . . . . . . . . . . . . 20
- B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 2]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-1. Introduction
-
- This memo defines a generalized mechanism for application service
- naming that allows service location without relying on rigid domain
- naming conventions (so-called name hacks). The proposal defines a
- Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
- map domain name, application service name, and application protocol
- to target server and port, dynamically.
-
- As discussed in Section 5, existing approaches to using DNS records
- to dynamically determining the current host for a given application
- service are limited in terms of the use cases supported. To address
- some of the limitations, this document defines a DDDS Application to
- map service+protocol+domain to specific server addresses using both
- NAPTR [7] and SRV ([5]) DNS resource records. This can be viewed as
- a more general version of the use of SRV and/or a very restricted
- application of the use of NAPTR resource records.
-
- 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]).
-
-2. Straightforward-NAPTR (S-NAPTR) Specification
-
- The precise details of the specification of this DDDS application are
- given in Appendix A. This section defines the usage of the DDDS
- application.
-
-2.1 Key Terms
-
- An "application service" is a generic term for some type of
- application, indpendent of the protocol that may be used to offer it.
- Each application service will be associated with an IANA-registered
- tag. For example, instant messaging is a type of application
- service, which can be implemented by many different application-layer
- protocols, and the tag "IM" (used as an illustration here) could be
- registered for it.
-
- An "application protocol" is used to implement the application
- service. These are also associated with IANA-registered tags. In
- the case where multiple transports are available for the application,
- separate tags should be defined for each transport.
-
- The intention is that the combination of application service and
- protocol tags should be specific enough that finding a known pair
- (e.g., "IM:ProtC") is sufficient for a client to identify a server
- with which it can communicate.
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 3]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- Some protocols support multiple application services. For example,
- LDAP is an application protocol, and can be found supporting various
- services (e.g., "whitepages", "directory enabled networking", etc).
-
-2.2 S-NAPTR DDDS Application Usage
-
- As outlined in Appendix A, NAPTR records are used to store
- application service+protocol information for a given domain.
- Following the DDDS standard, these records are looked up, and the
- rewrite rules (contained in the NAPTR records) are used to determine
- the successive DNS lookups, until a desirable target is found.
-
- For the rest of this section, refer to the set of NAPTR resource
- records for example.com shown in the figure below.
-
- example.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example.
- IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com.
- IN NAPTR 200 10 "" "IM:protA" "" someisp.example.
- IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com.
-
-
-2.2.1 Ordering and Preference
-
- A client retrieves all of the NAPTR records associated with the
- target domain name (example.com, above). These are to be sorted in
- terms of increasing ORDER, and increasing PREF within each ORDER.
-
-2.2.2 Matching and non-Matching NAPTR Records
-
- Starting with the first sorted NAPTR record, the client examines the
- SERVICE field to find a match. In the case of the S-NAPTR DDDS
- application, that means a SERVICE field that includes the tags for
- the desired application service and a supported application protocol.
-
- If more than one NAPTR record matches, they are processed in
- increasing sort order.
-
-2.2.3 Terminal and Non-Terminal NAPTR Records
-
- A NAPTR record with an empty FLAG field is "non-terminal". That is,
- more NAPTR RR lookups are to be performed. Thus, to process a NAPTR
- record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
- used as the target of the next DNS lookup -- for NAPTR RRs.
-
- In S-NAPTR, the only terminal flags are "S" and "A". These are
- called "terminal" NAPTR lookups because they denote the end of the
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 4]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- DDDS/NAPTR processing rules. In the case of an "S" flag, the
- REPLACEMENT field is used as the target of a DNS query for SRV RRs,
- and normal SRV processing is applied. In the case of an "A" flag, an
- address record is sought for the REPLACEMENT field target (and the
- default protocol port is assumed).
-
-2.2.4 S-NAPTR and Successive Resolution
-
- As shown in the example NAPTR RR set above, it is possible to have
- multiple possible targets for a single application service+protocol
- pair. These are to be pursued in order until a server is
- successfully contacted or all possible matching NAPTR records have
- been successively pursued to terminal lookups and servers contacted.
- That is, a client must backtrack and attempt other resolution paths
- in the case of failure.
-
- "Failure" is declared, and backtracking must be used when
-
- o the designated remote server (host and port) fail to provide
- appropriate security credentials for the *originating* domain
-
- o connection to the designated remote server otherwise fails -- the
- specifics terms of which are defined when an application protocol
- is registered
-
- o the S-NAPTR-designated DNS lookup fails to yield expected results
- -- e.g., no A RR for an "A" target, no SRV record for an "S"
- target, or no NAPTR record with appropriate application service
- and protocol for a NAPTR lookup. Except in the case of the very
- first NAPTR lookup, this last is a configuration error: the fact
- that example.com has a NAPTR record pointing to "bunyip.example"
- for the "WP:Whois++" service and protocol means the administrator
- of example.com believes that service exists. If bunyip.example
- has no "WP:Whois++" NAPTR record, the application client MUST
- backtrack and try the next available "WP:Whois++" option from
- example.com. As there is none, the whole resolution fails.
-
- An application client first queries for the NAPTR RRs for the domain
- of a named application service. The application client MUST select
- one protocol to choose The PREF field of the NAPTR RRs may be used by
- the domain administrator to The first DNS query is for the NAPTR RRs
- in the original target domain (example.com, above).
-
-2.2.5 Clients Supporting Multiple Protocols
-
- In the case of an application client that supports more than one
- protocol for a given application service, it MUST pursue S-NAPTR
- resolution completely for one protocol before trying another.j It MAY
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 5]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- choose which protocol to try first based on its own preference, or
- from the PREF ranking in the first set of NAPTR records (i.e., those
- for the target named domain). However, the chosen protocol MUST be
- listed in that first NAPTR RR set.
-
- That is, what the client MUST NOT do is start looking for one
- protocol, observe that a successive NAPTR RR set supports another of
- its preferred protocols, and continue the S-NAPTR resolution based on
- that protocol. For example, even if someisp.example offers the "IM"
- service with protocol "ProtB", there is no reason to believe it does
- so on behalf of example.com (since there is no such pointer in
- example.com's NAPTR RR set).
-
-3. Guidelines
-
-3.1 Guidelines for Application Protocol Developers
-
- The purpose of S-NAPTR is to provide application standards developers
- with a more powerful framework (than SRV RRs alone) for naming
- service targets, without requiring each application protocol (or
- service) standard to define a separate DDDS application.
-
- Note that this approach is intended specifically for use when it
- makes sense to associate services with particular domain names (e.g.,
- e-mail addresses, SIP addresses, etc). A non-goal is having all
- manner of label mapped into domain names in order to use this.
-
- Specifically not addressed in this document is how to select the
- domain for which the service+protocol is being sought. It is up to
- other conventions to define how that might be used (e.g., instant
- messaging standards can define what domain to use from IM URIs, how
- to step down from foobar.example.com to example.com, and so on, if
- that is applicable).
-
- Although this document proposes a DDDS application that does not use
- all the features of NAPTR resource records, it does not mean to imply
- that DNS resolvers should fail to implement all aspects of the NAPTR
- RR standard. A DDDS application is a client use convention.
-
- The rest of this section outlines the specific elements that protocol
- developers must determine and document in order to make use of S-
- NAPTR.
-
-3.1.1 Registration of application service and protocol tags
-
- Application protocol developers that wish to make use of S-NAPTR must
- make provision to register any relevant application service and
- application protocol tags, as described in Section 6.
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 6]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-3.1.2 Definition of conditions for retry/failure
-
- One other important aspect that must be defined is the expected
- behaviour for interacting with the servers that are reached via S-
- NAPTR. Specifically, under what circumstances should the client
- retry a target that was found via S-NAPTR? What should it consider a
- failure that causes it to return to the S-NAPTR process to determine
- the next serviceable target (a less preferred target)?
-
- For example, if the client gets a "connection refused" from a server,
- should it retry for some (protocol-dependent) period of time? Or,
- should it try the next-preferred target in the S-NAPTR chain of
- resolution? Should it only try the next-preferred target if it
- receives a protocol-specific permanent error message?
-
- The most important thing is to select one expected behaviour and
- document it as part of the use of S-NAPTR.
-
- As noted earlier, failure to provide appropriate credentials to
- identify the server as being authoritative for the original taret
- domain is always considered a failure condition.
-
-3.1.3 Server identification and handshake
-
- As noted in Section 7, use of the DNS for server location increases
- the importance of using protocol-specific handshakes to determine and
- confirm the identity of the server that is eventually reached.
-
- Therefore, application protocol developers using S-NAPTR should
- identify the mechanics of the expected identification handshake when
- the client connects to a server found through S-NAPTR.
-
-3.2 Guidelines for Domain Administrators
-
- Although S-NAPTR aims to provide a "straightforward" application of
- DDDS and use of NAPTR records, it is still possible to create very
- complex chains and dependencies with the NAPTR and SRV records.
-
- Therefore, domain administrators are called upon to use S-NAPTR with
- as much restraint as possible, while still achieving their service
- design goals.
-
- The complete set of NAPTR, SRV and A RRs that are "reachable" through
- the S-NAPTR process for a particular application service can be
- thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR
- or SRV records; each SRV record points to several A record lookups.
- Even though a particular client can "prune" the tree to use only
- those records referring to application protocols supported by the
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 7]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- client, the tree could be quite deep, and retracing the tree to retry
- other targets can become expensive if the tree has many branches.
-
- Therefore,
-
- o Fewer branches is better: for both NAPTR and SRV records, provide
- different targets with varying preferences where appropriate
- (e.g., to provide backup services, etc), but don't look for
- reasons to provide more.
-
- o Shallower is better: avoid using NAPTR records to "rename"
- services within a zone. Use NAPTR records to identify services
- hosted elsewhere (i.e., where you cannot reasonably provide the
- SRV records in your own zone).
-
-
-3.3 Guidelines for Client Software Writers
-
- To properly understand DDDS/NAPTR, an implementor must read [6].
- However, the most important aspect to keep in mind is that, if one
- target fails to work for the application, it is expected that the
- application will continue through the S-NAPTR tree to try the (less
- preferred) alternatives.
-
-4. Illustrations
-
-4.1 Use Cases
-
- The basic intended use cases for which S-NAPTR has been developed
- are:
-
- o Service discovery within a domain. For example, this can be used
- to find the "authoritative" server for some type of service within
- a domain (see the specific example in Section 4.2).
-
- o Multiple protocols. This is increasingly common as new
- application services are defined. This includes the case of
- instant messaging (a service) which can be offered with multiple
- protocols (see Section 4.3).
-
- o Remote hosting. Each of the above use cases applies within the
- administration of a single domain. However, one domain operator
- may elect to engage another organization to provide an application
- service. See Section 4.4 for an example that cannot be served by
- SRV records alone.
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 8]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-4.2 Service Discovery within a Domain
-
- There are occasions when it is useful to be able to determine the
- "authoritative" server for a given application service within a
- domain. This is "discovery", because there is no a priori knowledge
- as to whether or where the service is offered; it is therefore
- important to determine the location and characteristics of the
- offered service.
-
- For example, there is growing discussion of having a generic
- mechanism for locating the keys or certificates associated with
- particular application (servers) operated in (or for) a particular
- domain. Here's a hypothetical case for storing application key or
- certificate data for a given domain. The premise is that some
- credentials registry (CredReg) service has been defined to be a leaf
- node service holding the keys/certs for the servers operated by (or
- for) the domain. Furthermore, it is assumed that more than one
- protocol is available to provide the service for a particular domain.
- This DDDS-based approach is used to find the CredReg server that
- holds the information.
-
- Thus, the set of NAPTR records for thinkingcat.example might look
- like this:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example.
-
- Note that another domain, offering the same application service,
- might offer it using a different set of application protocols:
-
- anotherdomain.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example.
-
-
-4.3 Multiple Protocols
-
- As it stands, there are several different protocols proposed for
- offering "instant message" services. Assuming that "IM" was
- registered as an application service, this DDDS application could be
- used to determine the available services for delivering to a target.
-
- Two particular features of instant messaging should be noted:
-
- 1. gatewaying is expected to bridge communications across protocols
-
- 2. instant messaging servers are likely to be operated out of a
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 9]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- different domain than the instant messaging address, and servers
- of different protocols may be offered by independent
- organizations
-
- For example, "thinkingcat.example" may support its own servers for
- the "ProtA" instant messaging protocol, but rely on outsourcing from
- "example.com" for "ProtC" and "ProtB" servers.
-
- Using this DDDS-based approach, thinkingcat.example can indicate a
- preference ranking for the different types of servers for the instant
- messaging service, and yet the out-sourcer can independently rank the
- preference and ordering of servers. This independence is not
- achievable through the use of SRV records alone.
-
- Thus, to find the IM services for thinkingcat.example, the NAPTR
- records for thinkingcat.example are retrieved:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com.
- IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com.
-
- and then the administrators at example.com can manage the preference
- rankings of the servers they use to support the ProtB service:
-
- _ProtB._tcp.example.com.
- ;; Pref Weight Port Target
- IN SRV 10 0 10001 bigiron.example.com
- IN SRV 20 0 10001 backup.im.example.com
- IN SRV 30 0 10001 nuclearfallout.australia-isp.example
-
-
-4.4 Remote Hosting
-
- In the Instant Message hosting example in Section 4.3, the service
- owner (thinkingcat.example) had to host pointers to the hosting
- service's SRV records in the thinkingcat.example domain.
-
- A better way to approach this is to have one NAPTR RR in the
- thinkingcat.example domain pointing to all the hosted services, and
- the hosting domain has NAPTR records for each service to map them to
- whatever local hosts it chooses (and may change from time to time).
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 10]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com.
-
-
- and then the administrators at example.com can break out the
- individual application protocols and manage the preference rankings
- of the servers they use to support the ProtB service (as before):
-
- thinkingcat.example.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com.
- IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com.
-
-
-
- _ProtC._tcp.example.com.
- ;; Pref Weight Port Target
- IN SRV 10 0 10001 bigiron.example.com
- IN SRV 20 0 10001 backup.im.example.com
- IN SRV 30 0 10001 nuclearfallout.australia-isp.example
-
-
-4.5 Sets of NAPTR RRs
-
- Note that the above sections assumed that there was one service
- available (via S-NAPTR) per domain. Often, that will not be the
- case. Assuming thinkingcat.example had the CredReg service set up as
- described in Section 4.2 and the instant messaging service set up as
- described in Section 4.4, then a client querying for the NAPTR RR set
- from thinkingcat.com would get the following answer:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com.
- IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
-
- Sorting them by increasing "ORDER", the client would look through the
- SERVICE strings to determine if there was a NAPTR RR that matched the
- application service it was looking for, with an application protocol
- it could use. The first (lowest PREF) record that so matched is the
- one the client would use to continue.
-
-4.6 Sample sequence diagram
-
- Consider the example in Section 4.3. Visually, the sequence of steps
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 11]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- required for the client to reach the final server for a "ProtB"
- service for IM for the thinkingcat.example domain is as follows:
-
-
- Client NS for NS for
- thinkingcat.example example.com backup.im.example.com
- | | |
- 1 -------->| | |
- 2 <--------| | |
- 3 ------------------------------>| |
- 4 <------------------------------| |
- 5 ------------------------------>| |
- 6 <------------------------------| |
- 7 ------------------------------>| |
- 8 <------------------------------| |
- 9 ------------------------------------------------->|
- 10 <-------------------------------------------------|
- 11 ------------------------------------------------->|
- 12 <-------------------------------------------------|
- (...)
-
-
-
- 1. the name server (NS) for thinkingcat.example is reached with a
- request for all NAPTR records
-
- 2. the server responds with the NAPTR records shown in Section 4.3.
-
- 3. the second NAPTR record matches the desired criteria; that has an
- "s" flag and a replacement fields of "_ProtB._tcp.example.com".
- So, the client looks up SRV records for that target, ultimately
- making the request of the NS for example.com.
-
- 4. the response includes the SRV records listed in Section 4.3.
-
- 5. the client attempts to reach the server with the lowest PREF in
- the SRV list -- looking up the A record for the SRV record's
- target (bigiron.example.com).
-
- 6. the example.com NS responds with an error message -- no such
- machine!
-
- 7. the client attempts to reach the second server in the SRV list,
- and looks up the A record for backup.im.example.com
-
- 8. the client gets the A record with the IP address for
- backup.im.example.com from example.com's NS.
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 12]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- 9. the client connects to that IP address, on port 10001 (from the
- SRV record), using ProtB over tcp.
-
- 10. the server responds with an "OK" message.
-
- 11. the client uses ProtB to challenge that this server has
- credentials to operate the service for the original domain
- (thinkingcat.example)
-
- 12. the server responds, and the rest is IM.
-
-
-5. Motivation and Discussion
-
- Increasingly, application protocol standards are using domain names
- to identify server targets, and stipulating that clients should look
- up SRV resource records to determine the host and port providing the
- server. This enables a distinction between naming an application
- service target and actually hosting the server. It also increases
- flexibility in hosting the target service:
-
- o the server may be operated by a completely different organization
- without having to list the details of that organization's DNS
- setup (SRVs)
-
- o multiple instances can be set up (e.g., for load balancing or
- secondaries)
-
- o it can be moved from time to time without disrupting clients'
- access, etc.
-
- This is quite useful, but Section 5.1 outlines some of the
- limitations inherent in the approach.
-
- That is, while SRV records can be used to map from a specific service
- name and protocol for a specific domain to a specific server, SRV
- records are limited to one layer of indirection, and are focused on
- server administration rather than on application naming. And, while
- the DDDS specification and use of NAPTR allows multiple levels of
- redirection before locating the target server machine with an SRV
- record, this proposal requires only a subset of NAPTR strictly bound
- to domain names, without making use of the REGEXP field of NAPTR.
- These restrictions make the client's resolution process much more
- predictable and efficient than with some potential uses of NAPTR
- records. This is dubbed "S-NAPTR" -- a "S"traightforward use of
- NAPTR records.
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 13]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-5.1 So, why not just SRV records?
-
- An expected question at this point is: this is so similar in
- structure to SRV records, why are we doing this with DDDS/NAPTR?
-
- Limitations of SRV include:
-
- o SRV provides a single layer of indirection -- the outcome of an
- SRV lookup is a new domain name for which the A RR is to be found.
-
- o the purpose of SRV is focused on individual server administration,
- not application naming: as stated in [5] "The SRV RR allows
- administrators to use several servers for a single domain, to move
- services from host to host with little fuss, and to designate some
- hosts as primary servers for a service and others as backups."
-
- o target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
- "tcp") in a given domain. The definition of these terms implies
- specific things (e.g., that protocol should be one of UDP or TCP)
- without being precise. Restriction to UDP and TCP is insufficient
- for the uses described here.
-
- The basic answer is that SRV records provide mappings from protocol
- names to host and port. The use cases described herein require an
- additional layer -- from some service label to servers that may in
- fact be hosted within different administrative domains. We could
- tweak SRV to say that the next lookup could be something other than
- an address record, but that is more complex than is necessary for
- most applications of SRV.
-
-5.2 So, why not just NAPTR records?
-
- That's a trick question. NAPTR records cannot appear in the wild --
- see [6]. They must be part of a DDDS application.
-
- The purpose here is to define a single, common mechanism (the DDDS
- application) to use NAPTR when all that is desired is simple DNS-
- based location of services. This should be easy for applications to
- use -- some simple IANA registrations and it's done.
-
- Also, NAPTR has very powerful tools for expressing "rewrite" rules.
- That power (==complexity) makes some protocol designers and service
- administrators nervous. The concern is that it can translate into
- unintelligible, noodle-like rule sets that are difficult to test and
- administer.
-
- This proposed DDDS application specifically uses a subset of NAPTR's
- abilities. Only "replacement" expressions are allowed, not "regular
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 14]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- expressions".
-
-6. IANA Considerations
-
- This document calls for 2 IANA registries: one for application
- service tags, and one for application protocol tags.
-
- Application service and protocol tags should be defined in an RFC
- (unless the "x-" experimental form is used, in which case they are
- unregistered). There are no restrictions placed on the tags other
- than that they must conform with the syntax defined below (Appendix
- A.5). The IANA registries should list the tags and the RFC that
- defines their use.
-
-7. Security Considerations
-
- The security of this approach to application service location is only
- as good as the security of the DNS servers along the way. If any of
- them is compromised, bogus NAPTR and SRV records could be inserted to
- redirect clients to unintended destinations. This problem is hardly
- unique to S-NAPTR (or NAPTR in general).
-
- To protect against DNS-vectored attacks, applications should define
- some form of end-to-end authentication to ensure that the correct
- destination has been reached. Many application protocols such as
- HTTPS, BEEP, IMAP, etc... define the necessary handshake mechansims
- to accomplish this task.
-
- The basic mechanism works in the following way:
-
- 1. During some portion of the protocol handshake, the client sends
- to the server the original name of the desired destination (i.e.
- no transformations that may have resulted from NAPTR
- replacements, SRV targets, or CNAME changes). In certain cases
- where the application protocol does not have such a feature but
- TLS may be used, it is possible to use the "server_name" TLS
- extension.
-
- 2. The server sends back to the client a credential with the
- appropriate name. For X.509 certificates, the name would either
- be in the subjectDN or subjectAltName fields. For Kerberos, the
- name would be a service principle name.
-
- 3. Using the matching semantics defined by the application protocol,
- the client compares the name in the credential with the name sent
- to the server.
-
- 4. If the names match, there is reasonable assurance that the
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 15]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- correct end point has been reached.
-
- It is important to note that this document does not define either the
- handshake mechanism, the specific credenential naming fields, nor the
- name matching semantics. Definitions of S-NAPTR for particular
- application protocols MUST define these.
-
-8. Acknowledgements
-
- Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
- discussion and input that has (hopefully!) provoked clarifying
- revisions of this document.
-
-References
-
- [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
- Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [4] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- One: The Comprehensive DDDS", RFC 3401, October 2002.
-
- [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- Three: The Domain Name System (DNS) Database", RFC 3403, October
- 2002.
-
- [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
- 2002.
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 16]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-Authors' Addresses
-
- Leslie Daigle
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
-
-
- Andrew Newton
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- EMail: anewton@verisignlabs.com
-
-Appendix A. Application Service Location Application of DDDS
-
- This section defines the DDDS application, as described in [6].
-
-A.1 Application Unique String
-
- The Application Unique String is domain label for which an
- authoritative server for a particular service is sought.
-
-A.2 First Well Known Rule
-
- The "First Well Known Rule" is identity -- that is, the output of the
- rule is the Application Unique String, the domain label for which the
- authoritative server for a particular service is sought.
-
-A.3 Expected Output
-
- The expected output of this Application is the information necessary
- to connect to authoritative server(s) (host, port, protocol) for an
- application service within a given a given domain.
-
-A.4 Flags
-
- This DDDS Application uses only 2 of the Flags defined for the
- URI/URN Resolution Application ([8]): "S" and "A". No other Flags
- are valid.
-
- Both are for terminal lookups. This means that the Rule is the last
- one and that the flag determines what the next stage should be. The
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 17]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- "S" flag means that the output of this Rule is a domain label for
- which one or more SRV [5] records exist. "A" means that the output
- of the Rule is a domain name and should be used to lookup address
- records for that domain.
-
- Consistent with the DDDS algorithm, if the Flag string is empty the
- next lookup is for another NAPTR record (for the replacement target).
-
-A.5 Service Parameters
-
- Service Parameters for this Application take the form of a string of
- characters that follow this ABNF ([3]):
-
- service-parms = [ [app-service] *(":" app-protocol)]
- app-service = experimental-service / iana-registered-service
- app-protocol = experimental-protocol / iana-registered-protocol
- experimental-service = "x-" 1*30ALPHANUMSYM
- experimental-protocol = "x-" 1*30ALPHANUMSYM
- iana-registered-service = ALPHA *31ALPHANUMSYM
- iana-registered-protocol = ALPHA *31ALPHANUM
- ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
- DIGIT = %x30-39 ; 0-9
- SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
- ALPHANUMSYM = ALPHA / DIGIT / SYM
- ; The app-service and app-protocol tags are limited to 32
- ; characters and must start with an alphabetic character.
- ; The service-parms are considered case-insensitive.
-
- Thus, the Service Parameters may consist of an empty string, just an
- app-service, or an app-service with one or more app-protocol
- specifications separated by the ":" symbol.
-
- Note that this is similar to, but not the same as the syntax used in
- the URI DDDS application ([8]). The DDDS DNS database requires each
- DDDS application to define the syntax of allowable service strings.
- The syntax here is expanded to allow the characters that are valid in
- any URI scheme name (see [1]). Since "+" (the separator used in the
- RFC3404 service parameter string) is an allowed character for URI
- scheme names, ":" is chosen as the separator here.
-
-A.5.1 Application Services
-
- The "app-service" must be a registered service [this will be an IANA
- registry; this is not the IANA port registry, because we want to
- define services for which there is no single protocol, and we don't
- want to use up port space for nothing].
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 18]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-A.5.2 Application Protocols
-
- The protocol identifiers that are valid for the "app-protocol"
- production are any standard, registered protocols [IANA registry
- again -- is this the list of well known/registered ports?].
-
-A.6 Valid Rules
-
- Only substitution Rules are permitted for this application. That is,
- no regular expressions are allowed.
-
-A.7 Valid Databases
-
- At present only one DDDS Database is specified for this Application.
- [7] specifies a DDDS Database that uses the NAPTR DNS resource record
- to contain the rewrite rules. The Keys for this database are encoded
- as domain-names.
-
- The First Well Known Rule produces a domain name, and this is the Key
- that is used for the first lookup -- the NAPTR records for that
- domain are requested.
-
- DNS servers MAY interpret Flag values and use that information to
- include appropriate NAPTR, SRV or A records in the Additional
- Information portion of the DNS packet. Clients are encouraged to
- check for additional information but are not required to do so. See
- the Additional Information Processing section of [7] for more
- information on NAPTR records and the Additional Information section
- of a DNS response packet.
-
-Appendix B. Pseudo pseudocode for S-NAPTR
-
-B.1 Finding the first (best) target
-
- Assuming the client supports 1 protocol for a particular application
- service, the following pseudocode outlines the expected process to
- find the first (best) target for the client, using S-NAPTR.
-
-
- target = [initial domain]
- naptr-done = false
-
- while (not naptr-done)
- {
- NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
- [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
- rr-done = false
- cur-rr = [first NAPTR RR]
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 19]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- while (not rr-done)
- if ([SERVICE field of cur-rr contains desired application
- service and application protocol])
- rr-done = true
- target= [REPLACEMENT target of NAPTR RR]
- else
- cur-rr = [next rr in list]
-
- if (not empty [FLAG in cur-rr])
- naptr-done = true
- }
-
- port = -1
-
- if ([FLAG in cur-rr is "S"])
- {
- SRV-RRset = [DNSlookup of SRV RRs for target]
- [sort SRV-RRset based on PREF]
- target = [target of first RR of SRV-RRset]
- port = [port in first RR of SRV-RRset]
- }
-
- ; now, whether it was an "S" or an "A" in the NAPTR, we
- ; have the target for an A record lookup
-
- host = [DNSlookup of target]
-
- return (host, port)
-
-
-
-B.2 Finding subsequent targets
-
- The pseudocode in Appendix B is crafted to find the first, most
- preferred, host-port pair for a particular application service an
- protocol. If, for any reason, that host-port pair did not work
- (connection refused, application-level error), the client is expected
- to try the next host-port in the S-NAPTR tree.
-
- The pseudocode above does not permit retries -- once complete, it
- sheds all context of where in the S-NAPTR tree it finished.
- Therefore, client software writers could
-
- o entwine the application-specific protocol with the DNS lookup and
- RRset processing described in the pseudocode and continue the S-
- NAPTR processing if the application code fails to connect to a
- located host-port pair;
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 20]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- o use callbacks for the S-NAPTR processing;
-
- o use an S-NAPTR resolution routine that finds *all* valid servers
- for the required application service and protocol from the
- originating domain, and provides them in sorted order for the
- application to try in order.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 21]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 22]
-
diff --git a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt
deleted file mode 100644
index 4a01d91b9a8be..0000000000000
--- a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-
-
-INTERNET-DRAFT Hadmut Danisch
-Category: Experimental Oct 2003
-Expires: Apr 1, 2004
-
- The RMX DNS RR and method for lightweight SMTP sender authorization
- draft-danisch-dns-rr-smtp-03.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 10 of RFC2026.
-
- 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
-
-Abstract
-
- This memo introduces a new authorization scheme for SMTP e-mail
- transport. It is designed to be a simple and robust protection
- against e-mail fraud, spam and worms. It is based solely on
- organisational security mechanisms and does not require but still
- allow use of cryptography. This memo also focuses on security and
- privacy problems and requirements in context of spam defense. In
- contrast to prior versions of the draft a new RR type is not
- required anymore.
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 1]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- Table of Contents
-
-
-1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
-2. Problem and threat description . . . . . . . . . . . . . . . . . 4
- 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4
- 2.1.1 Definition of sender forgery . . . . . . . . . . . 4
- 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5
- 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5
- 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6
- 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6
- 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7
-3. A DNS based sender address verification . . . . . . . . . . . . 7
- 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9
- 3.3. Domain part vs. full sender address . . . . . . . . . . . 9
-4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10
- 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10
- 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11
- 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11
-5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11
- 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11
- 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12
- 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13
- 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14
- 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14
- 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15
- 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15
- 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16
-6. Optional and experimental entry types . . . . . . . . . . . . . 16
- 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16
- 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16
- 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16
- 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17
- 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17
-7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17
- 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17
- 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18
- 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18
- 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18
- 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18
- 7.2.5 Encoding of unused and full query . . . . . . . . . 19
- 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19
-8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19
-
-
-
-Hadmut Danisch Experimental [Page 2]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20
-10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20
- 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20
- 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21
- 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21
-11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
- 11.1. Draft specific considerations . . . . . . . . . . . . . . 22
- 11.1.1 Authentication strength . . . . . . . . . . . . . 22
- 11.1.2 Where Authentication and Authorization end . . . . 22
- 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23
- 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25
- 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25
- 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25
- 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26
- 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26
- 11.2. General Considerations about spam defense . . . . . . . . 27
- 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27
- 11.2.2 Content based Denial of Service attacks . . . . . 27
-12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28
- 12.1. Draft specific considerations . . . . . . . . . . . . . . 28
- 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28
- 12.1.2 Message reception and sender domain . . . . . . . 28
- 12.1.3 Network structure . . . . . . . . . . . . . . . . 29
- 12.1.4 Owner information distribution . . . . . . . . . . 29
- 12.2. General Considerations about spam defense . . . . . . . . 29
- 12.2.1 Content leaking of content filters . . . . . . . . 29
- 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30
-13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30
- 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30
- 13.1.1 Compatibility with old mail receivers . . . . . . 30
- 13.1.2 Compatibility with old mail senders . . . . . . . 30
- 13.1.3 Compatibility with old DNS clients . . . . . . . . 30
- 13.1.4 Compatibility with old DNS servers . . . . . . . . 30
- 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31
-14. General considerations about fighting spam . . . . . . . . . . 31
- 14.1. The economical problem . . . . . . . . . . . . . . . . . 31
- 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32
- 14.3. The network structure problem . . . . . . . . . . . . . . 33
- 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33
- 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33
- 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34
-Implementation and further Information . . . . . . . . . . . . . . . 34
-References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
-Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
-Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 3]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-1. General Issues
-
- 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].
-
-2. Problem and threat description
-
-2.1. Mail sender forgery
-
- The amount of e-mails with forged sender addresses has dramatically
- increased. As a consequence, damages and annoyances caused by such
- e-mails increased as well. In the majority of examined e-mails the
- domain name of the envelope sender address was forged, and the e-
- mail was sent from an IP address which does not belong to a network
- used by the actual owner of the domain.
-
-2.1.1. Definition of sender forgery
-
- As discussions, comments to prior versions of this draft, and
- different approaches to stop forgery showed, different perceptions
- of "mail forgery" exist. For example, there are mechanisms to
- verify e-mail addresses for mailing lists, web servers, or to stop
- spam, which do send a message with a random number to the given
- address and expect the user to send a reply. Here, someone is
- considered to be allowed to use a particular e-mail address, if and
- only if he is able to receive informations sent to this address,
- and is able to reply to such a message. While this definition
- appears to be quite plausible and natural, it can't be used for a
- simple technical solution. Sending back a challenge and expecting a
- reply is simply too much overhead and time delay, and not every
- authorized sender is able or willing to reply (e.g. because he went
- offline or is not a human).
-
- Within the scope of this memo, sender forgery means that the
- initiator of an e-mail transfer (which is the original sender in
- contrast to relays) uses a sender address which he was not
- authorized to use. Being authorized to use an address means that
- the owner (administrator) of the internet domain has given
- permission, i.e. agrees with the use of the address by that
- particular sender. This memo will cover both the permission of the
- full e-mail address and the domain part only for simplicity.
-
- Within context of Internet and SMTP, the sender address usually
- occurs twice, once as the envelope sender address in SMTP, and once
- as the address given in the RFC822 mail header. While the following
- considerations apply to both addresses in principle, it is
- important to stress that both addresses have distinct semantics and
-
-
-
-Hadmut Danisch Experimental [Page 4]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- are not neccessarily the same. The envelope address identifies the
- initiator of the transport, while the header identifies the author
- of the message content. Since this memo deals with the message
- transport only and completely ignores the message content, the
- method should naturally be applied to the envelope sender address.
-
-2.1.2. Spam
-
- A common and well known problem is the dramatic increase of
- unsolicited e-mail, commonly called "spam". Again, the majority of
- examined e-mails had forged sender addresses. The abused domains
- were mainly those of common webmailers as hotmail or yahoo, or
- well-known companies.
-
- Unfortunately, there is no accurate definition of spam availabe
- yet, and neither are the concise technical criterions to filter or
- block spam with technical mechanisms. There are efforts to design
- content based filters, but these filters are expensive in
- calculation time (and sometimes money), and they do not reliably
- provide predictable results. Usually they give false positives
- and/or require user interaction. Content filters in general suffer
- from a design problem described later in this memo. Therefore,
- this proposal does not use the content based approach to block
- spam.
-
- As analysis of spam messages showed, most of spam messages were
- sent with forged envelope sender addresses. This has mainly three
- reasons. The first reason is, that spam senders usually do not
- want to be contacted by e-mail. The second reason is, that they do
- not want to be blacklisted easily. The third reason is, that spam
- is or is going to be unlawful in many countries, and the sender
- does not want to reveal his identity. Therefore, spam is considered
- to be a special case of sender forgery.
-
-2.1.3. E-Mail Worms
-
- Another example of sender forgery is the reproduction of e-mail
- worms. Most worms do choose random sender addresses, e.g. using
- the addresses found in mailboxes on the infected system. In most
- cases analyzed by the author, the e-mails sent by the reproduction
- process can also be categorized as forged, since the infected
- system would under normal circumstances not be authorized to send
- e-mails with such e-mail addresses. So forgery does not require a
- malicious human to be directly involved. This memo covers any kind
- of e-mail sender address forgery, included those generated by
- malicious software.
-
-2.1.4. E-Mail spoofing and fraud
-
-
-
-Hadmut Danisch Experimental [Page 5]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- Forging e-mail sender addresses for fraud or other kinds of
- deception ("human engineering") has also dramatically increased.
- There are many known cases where single or mass e-mails were sent
- with wrong sender addresses, pretending to come from service
- provider, software manufacturers etc., and asking the receiver to
- install any software or patches, or to reply with any confidential
- information. The Internet is becoming more and more a scene of
- crime, and so are it's services, including e-mail. It is obvious
- that crime based on e-mail is eased by the fact that SMTP allows
- arbitrary sender address spoofing.
-
-2.2. Indirect damage caused by forgery
-
- As observed by the author, mass mails and worms with forged sender
- addresses can cause a severe damage for the real owner of the
- abused sender addresses. If a sender A is sending an e-mail to the
- receiver B, pretending to be C by using a sender address of C's
- domain, then C has currently no chance to prevent this, since C's
- machines and software are not involved in any way in the delivery
- process between A and B. B will nevertheless send any error
- messages (virus/spam alert, "no such user", etc.) to C, erroneously
- assuming that the message was sent by C. The author found several
- cases where this flood of error messages caused a severe denial of
- service or a dramatic increase of costs, e.g. when C was
- downloading the e-mail through expensive or low bandwidth
- connections (e.g. modem or mobile phones), or where disk space was
- limited. The author examined mass mailings, where several tens or
- hundreds of thousands of messages were sent to several addresses
- around the world, where these messages caused only annoyance. But
- since several thousands of these addresses were invalid or didn't
- accept the message, the owner of the DNS domain which was abused by
- the spammer to forge sender addresses was flooded for several
- months with thousands of error messages, jamming the e-mail system
- and causing severe costs and damages.
-
- As a consequence, when A sends a message to B, pretending to be C,
- there must be any mechanism to allow C to inform B about the fact,
- that A is not authorized to use C as a sender address. This is what
- this memo is about.
-
-2.3. Technical problem analysis
-
- Why does e-mail forgery actually exist? Because of the lack of the
- Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
- authentication, authorisation, or verification. This protocol was
- designed at a time where security was not an issue. Efforts have
- been made to block forged e-mails by requiring the sender address
- domain part to be resolvable. This method provides protection from
-
-
-
-Hadmut Danisch Experimental [Page 6]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- e-mails with non-existing sender domains, and indeed, for some time
- it blocked most spam e-mails. However, since attackers and spam
- senders began to abuse existing domain names, this method was
- rendered ineffective.
-
-2.4. Shortcomings of cryptographical approaches
-
- At a first glance, the problem of sender address forgery might
- appear to be solvable with cryptographic methods such as challenge
- response authentications or digital signatures. A deeper analysis
- shows that only a small, closed user group could be covered with
- cryptographical methods. Any method used to stop spam forgery must
- be suitable to detect forgery not only for a small number of
- particular addresses, but for all addresses on the world. An
- attacker does not need to know the secrets belonging to a
- particular address. It is sufficient to be able to forge any
- address and thus to know any secret key. Since there are several
- hundreds of millions of users, there will always be a large amount
- of compromised keys, thus spoiling any common cryptographic method.
- Furthermore, cryptography has proven to be far too complicated and
- error prone to be commonly administered and reliably implemented.
- Many e-mail and DNS administrators do not have the knowledge
- required to deal with cryptographic mechanisms. Many legislations
- do not allow the general deployment of cryptography and a directory
- service with public keys. For these reasons, cryptography is
- applicable only to a small and closed group of users, but not to
- all participants of the e-mail service.
-
-3. A DNS based sender address verification
-
-3.1. Overview
-
- To gain improvement in e-mail authenticity while keeping as much
- SMTP compatibility as possible, a method is suggested which doesn't
- change SMTP at all.
-
- The idea is to store informations about how to verify who is
- authorized to transmit e-mails through SMTP with a particular
- sender address (either full address or - for simplicity - only the
- domain part of the address) in a directory service, which is
- currently the DNS. To be precise, the verification consists of two
- steps, the classical pair of authentication and authorization:
-
- The first step is the authentication. While several methods are
- possible to perform authentication (see below), the most important
- and robust method is the verification of the sender's IP address.
- This is done implicitely by TCP/IP and the TCP sequence number. The
- authenticated identity is the IP address. It has to be stressed
-
-
-
-Hadmut Danisch Experimental [Page 7]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- that this TCP/IP "authentication" is a weak authentication and
- vulnerable to several attacks. It is nevertheless sufficient for
- this purpose, especially for blocking spam. It doesn't take any
- implementation and it doesn't cost: It is already there, it is a
- functionality of TCP/IP. An incoming SMTP connection based on
- TCP/IP already carries the sender's IP address without any
- modification of SMTP. See below (section Entry types) for more
- details about authentication methods.
-
- The second step is the authorization. It is based on the identity
- given by the previous authentication step, e.g. the IP address of
- the originator of the incoming SMTP connection, and on the
- envelope sender address. The mechanism proposed in this memo
- answers the question "Is that particular sender (IP address,...)
- allowed to send with that sender address" by querying and
- processing informations stored in a directory service, which is
- DNS.
-
- When the sender has issued the "MAIL FROM:" SMTP command, the
- receiving mail transfer agent (MTA) can - and modern MTAs do -
- perform some authorization checks, e.g. run a local rule database
- or check whether the sender domain is resolvable.
-
- The suggested method is to let the DNS server for the sender domain
- provide informations about who - this means for example which IP
- address - is authorized to use an address or a domain as a part of
- it. After receiving the "MAIL FROM:" SMTP command, the receiving
- MTA can verify, whether e. g. the IP address of the sending MTA is
- authorized to send mails with this domain name. Therefore, a list
- of entries with authorized IP addresses or other informations is
- provided by the authoritative DNS server of that domain. The entry
- types are described in the subsequent chapters. Some of these
- methods are
-
- - An IPv4 or IPv6 network address and mask
- - A fully qualified domain name referring to an A record
- - A fully qualified domain name referring to an APL record
-
- RMX records of these types would look like this:
-
- somedomain.de. IN RMX ipv4:10.0.0.0/8
- rmxtest.de. IN RMX host:relay.provider.com
- danisch.de. IN RMX apl:relays.rackland.de
- relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
-
- where the machine with the example address 213.133.101.23 and the
- machines in the example subnet 1.2.3.0/24 are the only machines
- allowed to send e-mails with an envelope sender address of domain
-
-
-
-Hadmut Danisch Experimental [Page 8]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- danisch.de. Since the APL records do not necessarily belong to the
- same domain or zone table as the RMX records, this easily allows to
- refer to APL records defined by someone else, e.g. the internet
- access or server hosting provider, thus reducing administrative
- overhead to a minimum. In the example given above, the domain
- danisch.de and several other domains are hosted by the service
- provider Rackland. So if the relay structure of Rackland is
- modified, only the zone of rackland.de needs to be modified. The
- domain owners don't need to care about such details.
-
-3.2. Envelope vs. header sender address
-
- Questions were raised why the proposed mechanism is based on the
- envelope sender address, and not on the sender address given in the
- message header. Technically, both can be used. Actually, it makes
- sense to use the envelope address.
-
- In common, the header sender address identifies the author of the
- content, while the envelope sender tells who caused the
- transmission. The approach proposed in this memo is transmission
- based, not content based. We can not authorize the author of a
- message if we don't have contact with him, if the message does not
- already contain a signature. In contrast, the sending MTA is linked
- to an IP address which can be used for authentication. This
- mechanism might not be very strong, but it is available and
- sufficient to solve today's e-mail security problems.
-
- Some people argued that it is the header address and not the sender
- address, which is displayed in common mail readers (MUAs), and
- where the receiver believes the mail comes from. That's true, but
- it doesn't help. There are many cases where the header sender
- differs from the envelope sender for good reasons (see below in the
- consequences chapter for the discussion about relaying). Relaying,
- mailing lists etc. require to replace the sender address used for
- RMX. If this were the header address, the message header would have
- to be modified. This is undesirable.
-
-3.3. Domain part vs. full sender address
-
- Former versions of this draft were limited to the domain part of
- the sender address. The first reason is that it is common and MX-
- like, to lookup only the domain part of an e-mail address in DNS.
- The second reason is, that it was left to the private business of
- the domain administration to handle details of user verification.
- The idea was that the domain administration takes care to verify
- the left part of an e-mail address with an arbitrary method of
- their individual taste. RMX was originally designed to ignore the
- left part of the address and to expect the domain administration to
-
-
-
-Hadmut Danisch Experimental [Page 9]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- take over responsibility for enforcing their policy. If, e.g., a
- spam message arrived and passed the RMX mechanism, it is known to
- be authorized by the domain administration and they can be blamed,
- no matter what is on the left side of the sender address - it's
- their private problem what happens on the left side of the @. By
- far the most of the comments to prior versions of this draft agreed
- with that. A few comments asked for a finer granularity.
-
- And indeed, there is no technical reason against a finer
- granularity. All it takes is a mapping from a given envelope
- sender address to a DNS name, and the RMX lookup for that
- particular e-mail address could be done instead of a lookup for the
- domain part only. However, to my knowledge, most domain
- administrators would not like to provide an RMX entry for every
- single e-mail address. In many cases, this would also overload DNS
- servers.
-
- It is to be discussed how to cover both views. One method could be
- to query the full address, and if no RMX records were found to
- query the domain part only. A different approach would be to query
- the domain part only, and if it's RMX record contain a special
- entry, then a new query for the full address is triggered. A third
- way would be to always query the full address and to leave the
- problem to the wildcard mechanism of DNS. This still has to be
- discussed and will be described in future versions of this draft.
-
-
-
-
-
-
-
-
-
-
-
-4. Mapping of E-Mail addresses to DNS names
-
- To perform the RMX query, a mapping is needed from E-Mail addresses
- to DNS fully qualified domain names.
-
- This chapter is under development and just a first approach.
-
-4.1. Domain part only
-
- Mapping of the domain part is trivial, since the domain part of an
- e-mail address itself is a valid DNS name and does not need
- translation. It might be nevertheless desirable to distinguish the
-
-
-
-Hadmut Danisch Experimental [Page 10]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- RMX entries from other entries, depending of the encoding of the
- records. If the RMX entries are encoded in TXT record types, they
- might collide with other uses of TXT records. It might be
- necessary to prepend the domain part with a special prefix, e.g.
- _rmx. So the e-mail address some.user@example.com could be mapped
- to example.com or _rmx.example.com.
-
-4.2. Full address
-
- Mapping a full address is slightly more difficult. The @ sign must
- be unambiguously translated, and therefore can not be simply
- translated into a dot. The e-mail addresses some.user@example.com
- and some@user.example.com must have different mappings. Therefore,
- the @ sign could be translated into _rmx, implicitely assuming that
- this is not an allowed domain name component of normal domain
- names. Then the rightmost _rmx in the mapped DNS name always
- corresponds to the @ sign. some.user@example.com would e translated
- into some.user._rmx.example.com and can be covered by a wildcard
- entry like *._rmx.example.com.
-
- Character encoding and character sets are still to be discussed.
-
-4.3. Empty address
-
- Unfortunately, SMTP allows empty envelope sender addresses to be
- used for error messages. Empty sender addresses can therefore not
- be prohibited. As observed, a significant amount of spam was sent
- with such an empty sender address. To solve this problem, the host
- name given in the HELO or EHLO command is taken to lookup the RMX
- records instead. This makes sense, since such messages were
- generated by the machine, not a human.
-
-
-
-
-5. Mandatory entry types and their syntax
-
- The entry types described in this section MUST be supported by any
- implementation of this draft.
-
-5.1. Overall structure
-
- Similar to APL, an RMX record is just a concatenation of zero or
- more RMX entries. The entries within one record form an ordered
- rule base as commonly usual in packet filtes and firewall rulesets,
- i. e. they are processed one ofter another until the first entry
- matches. This entry determines the result of the query. Once a
- matching entry is found, the RMX processing is finished.
-
-
-
-Hadmut Danisch Experimental [Page 11]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- For any domain name there should not exist more than a single RMX
- record. Due to the structure of DNS, it is nevertheless possible to
- have more than a single RMX record. Multiple RMX records are
- treated as a single record consisting of the concatenation of all
- records. While the entries in a record are ordered, the records are
- not ordered and may be processed in arbitrary order. If the order
- of the entries matters, it is the zone maintainer's responsibility
- to keep those entries in a single record. For example, there are
- negative entries, which exclude IP addresses from authorization.
- It is important that these entries are processed before positive
- entries giving permission to a wider address range. Since order is
- guaranteed only within a record, corresponding negative and
- positive entries must be put in the same record.
-
- An RMX record may consist of one or more entries, where the entries
- are separated by whitespace. An entry must not contain white space.
- Each entry consists of an optional exclamation sign, a tag, a
- colon, and the entry data:
-
- [!] TAG : ENTRY-SPECIFIC-DATA
-
- If the entry starts with an exclamation sign, the entry is negated.
- See the entry type description below for details.
-
- The TAG is the mnemonic type identifier or the decimal number of
- the entry. The TAG is case-insensitive. It is immediately followed
- by a colon.
-
- The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
- entry type. See description below.
-
- Example:
-
- danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
- ipv4:1.2.3.0/24
-
-5.2. Unused
-
- This is a primitive entry which just says that this sender address
- will never be used as a sender address under any circumstances.
- Example:
-
- testdomain.danisch.de IN RMX unused:
-
-5.3. IPv4 and IPv6 address ranges
-
- These entry types contain a bit sequence representing a CIDR
- address part. If that bit sequence matches the given IP address,
-
-
-
-Hadmut Danisch Experimental [Page 12]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- authorization is granted or denied, depending on the negation flag.
-
- The entry is prepended with the tag "IPv4" or "IPv6". The colon is
- followed with an IPv4 or IPv6 address in standard notation,
- optionally followed by a slash and a mask length. If the negation
- flag is set, then the given address range is excluded. Examples:
-
- danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0
- IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16
- IN RMX !ipv4:1.2.3.4
-
- (Please note that it does not make much sense to use
- RFC1918-Addresses in RMX records, this is just to give a syntax
- example.)
-
-
-5.4. DNS Hostname
-
- This entry type simply contains a regular DNS name, which is to be
- resolved as a host name (fetch the A record or IPv6 equivalent). If
- the given IP address matches the result, authorization is granted
- or denied, depending on the negation flag. It is still to be
- defined how to treat unresolvable entries.
-
- The entry is prepended with the tag "host", followed by a colon and
- the hostname. Examples:
-
- danisch.de IN RMX host:relay.provider.de
- IN RMX !host:badmachine.domain.de apl:relays.domain.de
-
-5.4.1. Road warriors and DynDNS entries
-
- Several people argued against RMX that it would break their
- existing installation which delivers e-mail from dynamically
- assigned IP addresses, because their IP providers didn't assign a
- static address, or because they are a road warrior, plugging their
- notebook in any hotel room on the world.
-
- RMX provides a simple solution. If such a machine has a dynamically
- updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
- the hostname type pointing to this dynamic DNS entry.
-
- The cleaner solution would be to deliver mail the same way as it is
- received: If downloaded by POP from a central relay with a static
- address, where the MX points to, then it would be a good idea to
- deliver e-mail the same way in reverse direction. Unfortunately,
- plain POP does not support uploading yet.
-
-
-
-
-Hadmut Danisch Experimental [Page 13]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-5.5. APL Reference
-
- This entry type simply contains a regular DNS name, which is to be
- resolved as an APL record index (fetch the APL record). If the
- given IP address positively matches the APL, authorization is
- granted. Details of the semantic (espially when the negation bit is
- set) are still to be defined. It is still to be defined how to
- treat unresolvable entries.
-
- The entry is prepended with the tag "host", followed by a colon and
- the hostname. Example:
-
- danisch.de IN RMX apl:relays.rackland.de
-
-5.6. Domain Member
-
- In many cases it is desirable to cover all hosts of a given domain
- with an RMX record without the need to duplicate the list of these
- hosts. This entry type does it (thanks to Eric A. Hall for pointing
- out this entry type). It contains a regular DNS name.
-
- If this entry type is given, a reverse DNS query for the IP address
- of the sending MTA is performed to find its official fully
- qualified domain name. To prevent spoofing, this domain name is
- accepted only if a subsequent address query to the given domain
- name points to exactly the IP address of the sending MTA (the usual
- procedure to verify PTR records).
-
- The entry matches if the fully qualified domain name of the sending
- MTA ends in the given domain. The negation flag works as usual.
-
- The tag for this entry type is "domain". After the colon the domain
- name is given, but might be empty, thus pointing to itself.
- Example:
-
- somedomain.org IN RMX domain:somedomain.org domain:provider.com
-
- would authorize all machines which's hostname can be verified
- through an PTR and A query, and which ends in "somedomain.org" or
- "provider.com".
-
- With such an entry, large companies with different networks can
- easily be covered with just a single and simple RMX entry.
- Obviously, it requires proper PTR records.
-
- As a special shortcut, the DNS name may be empty. In this case the
- domain name of the zone itself is taken. Thus, with a very simple
- entry of the type
-
-
-
-Hadmut Danisch Experimental [Page 14]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- somecompany.com IN RMX domain:
-
- a company could authorize all machines which's IP addresses map to
- DNS names end in somecompany.com, which applies in the majority of
- companies.
-
-
-
-
-5.7. Full Address Query
-
- As described above, RMX records will in most cases apply to the
- domain part of the sender address. In special cases it might be
- desirable to query the RMX record for a particular address. An RMX
- entry of the Full Address Query type may occur in a domain RMX
- record only. It signals that the RMX record for the full address is
- to be fetched and processed.
-
- This entry type does not take arguments. The negation flag is not
- supported. The tag is "full".
-
- If such a full address query is to be performed, the mail address
- must be mapped to a valid and non-ambiguos DNS name. This mapping
- is still to be defined. It is not sufficient to simply replace the
- @ with a dot, because of case sensitivity, character sets, etc. The
- e-mail addresses
-
- john.doe@example.org
- John.Doe@example.org
- john@doe.example.org
-
- must all be mapped to different DNS entries. This entry type might
- vanish in future versions of the draft, depending on the discussion
- about whether to query the domain name part only or the full
- address.
-
-5.8. DNS mapped authorization
-
- As I learned from comments to prior versions of the draft and from
- alternative proposals, many users wish to have a DNS mapped
- authorization table, i. e. the client queries a DNS entry of the
- form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
- Since people wish to have this, RMX will now include such a mapping
- entry. The entry has a parameter giving the DNS domain name where
- to look at. If the parameter is empty, then the same domain is
- taken as for the RMX lookup.
-
- As this is currently under construction and discussion in an IETF
-
-
-
-Hadmut Danisch Experimental [Page 15]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- group, details will be published in future versions of this draft.
-
-5.9. RMX reference
-
- This entry type has no parameters. It means that all those machines
- are authorized, which are pointed to by an MX record.
-
-6. Optional and experimental entry types
-
- The following subsections roughly describe further entry types
- which might not be supported by all implementations and might not
- be allowed in all legislations. These methods might vanish in
- future versions of the draft and are just considerations about what
- to include in RMX and what to not include. The main purpose of this
- section is to start discussion about such entry types.
-
- The disadvantage of the following methods is that they violate the
- basic idea of RMX, i. e. to be simple, robust, easy to implement
- and easy to administer. I personally do not believe that it is a
- good idea or even feasible to implement cryptography for a world
- wide e-mail transfer network. Keep in mind that cryptographic keys
- can be copied. If only <0.1% of cryptographic keys were revealed,
- this completely compromises and spoils RMX. Cryptography is simply
- the wrong tool for the problem RMX is intended to solve. I
- nevertheless like to discuss these methods.
-
-6.1. TLS fingerprint
-
- The sender is considered to be authorized if the message was
- transmitted through SMTP and TLS, and the sender used a certificate
- matching the fingerprint given in the RMX record.
-
-6.2. TLS and LDAP
-
- This means that the receiver should perform an LDAP query for the
- sender address (through the LDAP SRV record or given in the RMX
- record), fetch the X.509 certificate for the sender. The sender is
- considered to be authorized when the message was transmitted
- through SMTP and TLS using this certificate.
-
-6.3. PGP or S/MIME signature
-
- It would be possible to accept a message only if it was signed with
- PGP or S/MIME with a key which's fingerprint is given in the RMX
- record or to be fetched from LDAP or any PGP database. This is
- just for discussion, since it violates the idea of RMX to focus on
- the transport, not on the content. It would also allow replay
- attacks and not cover the envelope sender address or message
-
-
-
-Hadmut Danisch Experimental [Page 16]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- header.
-
-6.4. Transparent Challenge/Response
-
- It would also be possible to implement a challenge-response
- mechanism without modifying the syntax of SMTP. For example, the
- receiving MTA could issue a challenge with it's very first greeting
- message, the sending MTA could hide the response in the HELO
- parameter and when the receiving MTA later learns the sender
- envelope address, it could verify the response based on
- informations in the RMX record.
-
-6.5. SASL Challenge/Response
-
- Modern SMTP implementations already include a SASL mechanisms,
- which easily allows to plugin new authentication mechanisms. While
- common SASL mechanisms require to use a previously shared password,
- a new mechanism could perform a challenge response authentication
- as a SASL method.
-
-
-
-
-
-
-7. Encoding
-
-7.1. Alternative encoding as TXT records
-
- The main objection against the prior versions of this draft was
- that it requires a new RR entry type and upgrading all DNS servers.
-
- Therefore and alternative encoding is proposed. Instead of using a
- new RR type, the TXT record type is used to contain the RMX record.
- The records would simply look as described in the entry type
- chapters above, e.g.
-
- _rmx.danisch.de. IN TXT "apl:relays.rackland.de"
-
- To allow smooth introduction of RMX without the need to immediately
- upgrade all DNS servers, all clients (which have to be newly
- installed anyway) MUST support both the TXT and the RMX records. A
- client has to perform an ANY or a TXT and a RMX query. Servers/zone
- tables may currently use TXT entries but SHOULD use RMX entries in
- future.
-
-7.2. RMX Records
-
-
-
-
-Hadmut Danisch Experimental [Page 17]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-7.2.1. Overall structure
-
- Each entry starts with an octet containting the entry type and the
- negation flag:
-
- +---+---+---+---+---+---+---+---+------
- | N | Entry Type Code | Parameters...
- +---+---+---+---+---+---+---+---+------
-
- N If this bit (MSB) is set, an IP address
- matching this entry is not authorized,
- but explicitely rejected. See entry
- type descriptions for details.
-
- Entry Type A 7bit number simply determining the entry
- type.
-
-
- Currently, entries do not have an explicit length field, the entry
- length is determined implicitely by the entry type. Applications
- are required to abort if an unknown entry type is found, instead of
- skipping unknown entries.
-
-7.2.2. Record encoding
-
- A RMX record is simply a concatenation of RMX entries.
-
-7.2.3. Encoding of IPv4 and IPv6 address ranges
-
- After the entry type tag as described above, one octet follows
- giving the length L of the bit sequence. Then a sequence of exactly
- as many octets follows as needed to carry L bits of information (=
- trunc((L+7)/8) ).
-
- +---+---+---+---+---+---+---+---+
- | N | Entry Type Code (1 or 2) |
- +---+---+---+---+---+---+---+---+
- | Length Field L |
- +---+---+---+---+---+---+---+---+
- | Bit Field |
- / ((L+7)/8) Octets /
- +---+---+---+---+---+---+---+---+
-
-
-7.2.4. Encoding of DNS
-
- After the entry type tag immediately follows a DNS encoded and
- compressed [3] domain name.
-
-
-
-Hadmut Danisch Experimental [Page 18]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- +---+---+---+---+---+---+---+---+
- | N | Entry Type Code (3..5) |
- +---+---+---+---+---+---+---+---+
- | Length Field L |
- +---+---+---+---+---+---+---+---+
- | Encoded DNS |
- / Name as described in RFC1035 /
- +---+---+---+---+---+---+---+---+
-
- In contrast to earlier versions of this draft, the DNS name cannot
- be compressed, since this would cause decompression errors when a
- DNS server is part of the query chain which does not know this
- particular RR type.
-
-7.2.5. Encoding of unused and full query
-
- These entries do not contain parameters and does not allow the
- negation flag. So the encoding is quite simple:
-
- +---+---+---+---+---+---+---+---+
- | 0 | Entry Type Code (6 or 7)|
- +---+---+---+---+---+---+---+---+
-
-
-
-7.2.6. Additional Records
-
- In order to avoid the need of a second query to resolve the given
- host name, a DNS server should enclose the A record for that domain
- name in the additional section of the additional section of the DNS
- reply, if the server happens to be authoritative.
-
- In order to avoid the need of a second query to resolve the given
- host name, a DNS server should enclose the APL record for that
- domain name in the additional section of the additional section of
- the DNS reply, if the server happens to be authoritative.
-
-
-
-8. Message Headers
-
- An RMX query must be followed by any kind of action depending on
- the RMX result. One action might be to reject the message. Another
- action might be to add a header line to the message body, thus
- allowing MUAs and delivery programs to filter or sort messages.
-
- In future, the RMX result might be melted into the Received: header
- line.
-
-
-
-Hadmut Danisch Experimental [Page 19]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- The details of such entries are to be discussed. As a proposal the
- following form is suggested:
-
- X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
-
- where
-
- RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
- "TempFail", "BadData", "Trusted".
-
- ADDRESS is the IP address of the sending machine
-
- HOST is the name of the machine performing the RMX query.
-
- DATE is the date of the query.
-
- MECHANISM is the RMX method used to authorize the sender.
-
-
-
-9. SMTP error messages
-
- If a message is rejected because of RMX records, an error message
- should be issued which explains the details. It is to be discussed
- whether new SMTP error codes are to be defined.
-
-
-10. Message relaying and forwarding
-
-10.1. Problem description
-
- Message forwarding and relaying means that an MTA which received an
- e-mail by SMTP does not deliver it locally, but resends the message
- - usually unchanged except for an additional Received header line
- and maybe the recipient's address rewritten - to the next SMTP MTA.
- Message forwarding is an essential functionality of e-mail
- transport services, for example:
-
- - Message transport from outer MX relay to the intranet
- - Message forwarding and Cc-ing by .forward or .procmail-alike
- mechanisms
- - Mailing list processing
- - Message reception by mail relays with low MX priority,
- usually provided by third parties as a stand-by service
- in case of relay failure or maintenance
- - "Forwarding" and "Bouncing" as a MUA functionality
-
- In all these cases a message is sent by SMTP from a host which is
-
-
-
-Hadmut Danisch Experimental [Page 20]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- not covered by the original sender domain's RMX records. While the
- RMX records would forbid accepting this message, it still must be
- accepted. The following subsections explain how to cope with
- relaying.
-
-10.2. Trusted relaying/forwarding
-
- In some cases the receiving MTA trusts the sending MTA to not fake
- messages and to already have checked the RMX records at message
- reception. As a typical example, a company might have an outer mail
- relay which receives messages from the Internet and checks the RMX
- records. This relay then forwards the messages to the different
- department's mail servers. It does not make sense for these
- department mail servers to check the RMX record, since the RMX
- records have already been checked and - since the message was
- relayed by the outer relay - always would deny the message. In this
- case there is a trust relationship between the department relays
- and the outer relay. So RMX checking is turned off for trusted
- relays. In this example, the department relays would not check
- messages from the outer relay (but for intranet security, they
- could still check RMX records of the other departments sub-domains
- to avoid internal forgery between departments).
-
- Another common example are the low-priority MX relays, which
- receive and cache e-mails when the high-priority relays are down.
- In this case, the high-priority relay would trust the low-priority
- relay to have verified the sender authorization and would not
- perform another RMX verification (which would obviously fail).
-
- When a relay forwards a message to a trusting machine, the envelope
- sender address should remain unchanged.
-
-10.3. Untrusted relaying/forwarding
-
- If the receiving MTA does not trust the forwarding MTA, then there
- is no chance to leave the sender envelope address unchanged. At a
- first glance this might appear impracticable, but this is
- absolutely necessary. If an untrusted MTA could claim to have
- forwarded a message from a foreign sender address, it could have
- forged the message as well. Spammers and forgers would just have to
- act as such a relay.
-
- Therefore, it is required that, when performing untrusted
- forwarding, the envelope sender address has to be replaced by the
- sender address of someone responsible for the relaying mechanism,
- e.g. the owner of the mailing list or the mail address of the user
- who's .forward caused the transmission. It is important to stress
- that untrusted relaying/forwarding means taking over responsibility
-
-
-
-Hadmut Danisch Experimental [Page 21]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- for the message. It is the idea of RMX records to tie
- responsibility to message transmission. Untrusted relaying without
- replacing the sender address would mean to transmit without taking
- responsibility.
-
- The disadvantage is that the original sender address is lost.
- Therefore, whenever a sender address replacement happens, the
- Received-Line must contain the old address. Many of today's MTAs
- already insert the envelope recipient address, but not the sender
- address into the Received header line. It seems reasonable to
- require every Received line to include both the sender and
- recipient address of the incoming SMTP connection.
-
-
-11. Security Considerations
-
-11.1. Draft specific considerations
-
-11.1.1. Authentication strength
-
- It is important to stress, that the suggested method does not
- provide high level security and does not completely prevent forged
- e-mails or spam under any circumstances. It is a robust, but not
- highly reliable and completely secure security mechanism. Keep in
- mind that it is based on DNS, and DNS is not secure today.
- Authorization is based on the IP address. The very same machine
- with the very same IP address could be authorized to send e-mail
- with a given sender address and sending spam at the same time.
- Maybe because several users are logged in. Or because several
- customers use the same relay of the same ISP, where one customer
- could use the sender address of a different customer. It is up to
- the ISP to prevent this or not. Machines can still be hijacked.
- Spammers are also domain owners. They can simply use their own
- domain and authorize themselves. You will always find people on the
- world who do not care about security and open their relays and RMX
- records for others to abuse them. RMX is to be considered as a
- very cheap and simple light weight mechanism, which can
- nevertheless provide a significant improvement in mail security
- against a certain class of attacks, until a successor of SMTP has
- been defined and commonly accepted.
-
-11.1.2. Where Authentication and Authorization end
-
- Previous versions of RMX records did not cover the local part of
- the e-mail address, i.e. what's on the left side of the @ sign.
- This is still to be discussed. Authentication and authorization are
- limited to the sending MTA's IP address. The authentication is
- limited to the TCP functionality, which is sufficient for light
-
-
-
-Hadmut Danisch Experimental [Page 22]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- weight authentication. The RMX records authorize the IP address of
- the sending host only, not the particular sender of the message. So
- if a machine is authorized to use sender addresses of more than a
- single domain, the authentication scheme does not prevent that any
- user on this machine can send with any of these domains. RMX is not
- a substitute for the host security of the involved machines.
-
- The proposed authentication scheme can be seen as a "half way
- authentication": It does not track back an e-mail to the effective
- sender. It tracks only half of the way, i. e. it tracks back to the
- domain and it's DNS administrators who authorized that particular
- sender IP address to use it for sending e-mail. How the party
- responsible for that domain performs user authentication, whom it
- grants access to, how it helds people responsible for abuse, is
- completely left as the private business of those who are in charge
- of that domain. So this draft does not interfere with the domain's
- individual security policy or any legislation about such policies.
- On the other hand, the proposed authentication scheme does not give
- any statement about the nature and quality of the domain's security
- policy. This is an essential feature of the proposal: E-mail
- authentication must be deployed world wide, otherwise it won't do
- the job. Any security scheme interfering with the local
- legislations or the domain's security policy will not be accepted
- and can't effectively deployed. Therefore, the security policy must
- remain the domain's private business, no matter how lousy the
- policy might be.
-
- In order to achieve this and to make use of the only existing world
- wide Internet directory scheme (DNS), the approach of this proposal
- is to just ignore the local part of the sender address (i.e. what's
- left of the @ part) and limit view to the domain part. After all,
- that's what we do anyway when delivering to a given address with
- SMTP.
-
-11.1.3. Vulnerability of DNS
-
- DNS is an essential part of the proposed authentication scheme,
- since it requires any directory service, and DNS is currently the
- only one available. Unfortunately, DNS is vulnerable and can be
- spoofed and poisoned. This flaw is commonly known and weakens many
- network services, but for reasons beyond that draft DNS has not
- been significantly improved yet. After the first version of this
- draft, I received several comments who asked me not to use DNS
- because of its lack of security. I took this into consideration,
- but came to the conclusion that this is unfeasible: Any
- authentication scheme linked to some kind of symbolic identity (in
- this case the domain name) needs some kind of infrastructure and
- trusted assignment. There are basically two ways to do it: Do it
-
-
-
-Hadmut Danisch Experimental [Page 23]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- yourself and trust nobody else, or let someone else do it. There
- are methods to do it the former way, e.g. to give someone some kind
- of authentication information after a first successful e-mail
- exchange, e.g. some kind of cookie or special e-mail address. This
- is certainly interesting and powerful, but it does not solve the
- problem on a world wide scale and is far to complicated and error
- prone for the average user, i. e. 99% of the users.
-
- The latter method to let someone else do the symbolic name
- assignment and create the authentication framework is well known.
- It context of public key cryptography, this is called a Public Key
- Infrastructure (PKI). On of the best known facts about PKIs is
- that, until now, we don't have any covering a significant part of
- the Internet. And we won't have any in near future. The complexity
- is far too high, it is too expensive, and it involves cooperation
- of every single user, which is simply unrealistic and extremely
- error prone. So what do we have we can use? All we have is the DNS
- and the Whois database. And we have countries who don't allow
- cryptography. So the proposal was designed to use DNS without
- cryptography. It does not avoid DNS because of its vulnerability,
- it asks for a better DNS, but accepts the DNS as it is for the
- moment. Currently there are two main threats caused by the DNS
- weakness:
-
- - A spammer/forger could spoof DNS in order to gain false
- authorization to send fake e-mails.
-
- - An attacker could spoof DNS in order to block delivery from
- authorized machines, i. e. perform a Denial of Service attack.
-
- The first one is rather unrealistic, because it would require an
- average spammer to poison a significant part of the DNS servers of
- its victims. A spammer sending messages to one million receipients
- would need to poison at least 1-10% which is 10,000 to 100,000
- receipient's DNS servers. This should be unfeasible in most cases.
-
- In contrast, the second threat is a severe one. If an attacker
- wanted to block messages from one company to another, he just needs
- to poison the recipients DNS server with a wrong RMX record in
- order to make the recipient's SMTP machine reject all messages. And
- this is feasible since the attacker needs to poison only a single
- DNS server. But does this make SMTP more vulnerable? No. Because
- the attacker can already do even more without RMX. By poisoning the
- sender's DNS server with wrong MX records, the attacker can also
- block message delivery or even redirect the messages to the
- attacker's machine, thus preventing any delivery error messages and
- furthermore getting access to the messages.
-
-
-
-
-Hadmut Danisch Experimental [Page 24]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- As a consequence, e-mail delivery by SMTP requires a better DNS
- anyway. The requirements are not significantly expanded by RMX.
-
-11.1.4. Sneaking RMX attack?
-
- While writing a test implementation, a certain kind of attack came
- into my mind. I'm still not sure, whether this attack is possible
- on any DNS server, but I believe it should be mentioned:
-
- Imagine an unauthorized sender is sending a forged mail (e.g.
- spam). At connection time, before querying the RMX record, the
- receiving MTA usually performs a PTR query for the IP address of
- the sending MTA. If the sender has control over the authoritative
- name server for that particular IP address, the sender could give a
- normal PTR answer, but could append a wrong RMX, APL, or A record
- in the additional section of the query. A subsequent RMX query
- could receive wrong DNS data if the DNS server used by the
- receiving MTA accepted those forged records.
-
-11.1.5. Open SMTP relays
-
- Open SMTP relays (i.e. machines who accept any e-mail message from
- anyone and deliver to the world) abused by spammers are a one of
- the main problems of spam defense and sender backtracking. In most
- cases this problem just vanishes because foreign open relay
- machines will not be covered by the RMX records of the forged
- sender address. But there are two special cases:
-
- If the spammer knows about a domain which authorizes this
- particular machine, that domain can be used for forgery. But in
- this case, the IP address of the relay machine and the RMX records
- of the domain track back to the persons responsible. Both can be
- demanded to fix the relay or remove the RMX record for this
- machine. An open relay is a security flaw like leaving the machine
- open for everybody to login and send random mails from inside. Once
- the administrative persons refuse to solve the problem, they can be
- identified as spammers and held responsible.
-
- The second special case is when a domain authorizes all IP
- addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
- this case, open relays don't make things worse. It's up to the
- recipient's MTA to reject mails from domains with loose security
- policies.
-
-11.1.6. Unforged Spam
-
- This proposal does not prevent spam (which is, by the way, not yet
- exactly defined), it prevents forgery. Since spam is against law
-
-
-
-Hadmut Danisch Experimental [Page 25]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- and violates the recipients rights, spam depends on untracability
- of the sender. In practice the sender forges the sender address
- (other cases see below). This proposal is designed to detect such
- forgeries.
-
- However, the RMX approach is rendered ineffective, if the sender
- doesn't forge. If the sender uses just a normal address of it's own
- domain, this is just a plain, normal e-mail, which needs to be let
- through. Since it is up to the human's taste whether this is spam
- or not, there's no technical way to reliably identify this as spam.
- But since the sender domain is known, this domain can be
- blacklisted or legal steps can be gone into.
-
-11.1.7. Reliability of Whois Entries
-
- Once the RMX infrastructure gets deployed, what's the security
- gain? It allows to determine the domain which's DNS zone
- authorized the sending machine. What's that good for? There are
- some immediate uses of the domain name, e.g. in black- and
- whitelisting. But in most cases this is just the starting point of
- further investigations, either performed automatically before
- message acceptance, or manually after spam has been received and
- complainted about.
-
- The next step after determining the domain is determining the
- people responsible for this domain. This can sometimes be achieved
- by querying the Whois databases. Unfortunately, many whois entries
- are useless because they are incomplete, wrong, obsolete, or in
- uncommon languages. Furthermore, there are several formats of
- address informations which make it difficult to automatically
- extract the address. Sometimes the whois entry identifies the
- provider and not the owner of the domain. Whois servers are not
- built for high availability and sometimes unreachable.
-
- Therefore, a mandatory standard is required about the contents and
- the format of whois entries, and the availability of the servers.
- After receiving the MAIL FROM SMTP command with the sender envelope
- address, the receiving MTA could check the RMX record and Whois
- entry. If it doesn't point to a real human, the message could be
- rejected and an error message like "Ask your provider to fix your
- Whois entry" could be issued. Obviously, domain providers must be
- held responsible for wrong entries. It might still be acceptable to
- allow anonymous domains, i. e. domains which don't point to a
- responsible human. But it is the receivers choice to accept e-mails
- from such domains or not.
-
-11.1.8. Hazards for Freedom of Speech
-
-
-
-
-Hadmut Danisch Experimental [Page 26]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- Currently, some governments try to enforce limitations of internet
- traffic in order to cut unwanted content providers from the
- network. Some of these governments try to hide a whole country
- behind firewalls, others try to force Internet providers to poison
- DNS servers with wrong A records for web servers, e.g. one county
- administration in Germany tries to do so. If message reception
- depends on DNS entries, the same governments will try to block not
- only HTTP, but SMTP also.
-
- However, since most MTAs already reject messages from unresolvable
- domain names this is not a new threat.
-
-11.2. General Considerations about spam defense
-
- After discussing security requirements of the proposal, now the
- security advantages of the RMX approach over content based filters
- will be explained. Basically, there are three kinds of content
- filters:
-
- - Those who upload the message or some digest to an external
- third party and ask "Is this spam"?
-
- - Those who download a set of patterns and rules from a third
- party and apply this set to incoming messages in order to
- determine whether it is spam.
-
- - Those who are independent and don't contact any third party,
- but try to learn themselves what is spam and what isn't.
-
-
- The message filters provided by some e-mail service providers are
- usually not a kind of their own, but a combination of the first two
- kinds.
-
-11.2.1. Action vs. reaction
-
- Content filters suffer from a fundamental design problem: They are
- late. They need to see some content of the same kind before in
- order to learn and to block further distribution.
-
- This works for viruses and worms, which redistribute. This doesn't
- work for spam, since spam is usually not redistributed after the
- first delivery. When the filters have learned or downloaded new
- pattern sets, it's too late.
-
- This proposal does not have this problem.
-
-11.2.2. Content based Denial of Service attacks
-
-
-
-Hadmut Danisch Experimental [Page 27]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- All three kinds of content filters, but especially the second and
- the third kind are vulnerable to content based Denial of Service
- attacks.
-
- If some kind of third party (e.g. non-democratic government,
- intellectual property warriors, religious groups, military, secret
- services, patriots, public relation agents, etc.) wants certain
- contents not to be distributed, they could either poison the
- pattern/rule databases or feed wrong sets to particular receivers.
-
- Such pattern/rule sets are the perfect tool for censoring e-mail
- traffic and denial of service attacks by governments and other
- parties, and a similar threat are virus filters. E. g. the content
- industry could demand to teach all virus and spam filters to delete
- all e-mails containing the URL of an MP3 web server outside the
- legislations. Software manufacturers could try to block all e-mails
- containing software license keys, thus trying to make unallowed
- distribution more difficult. Governments could try to block
- distribution of unwanted informations.
-
- This proposal does not have this problem.
-
-
-12. Privacy Considerations
-
- (It was proposed on the 56th IETF meeting to have a privacy section
- in drafts and RFCs.)
-
-12.1. Draft specific considerations
-
-12.1.1. No content leaking
-
- Since the RMX approach doesn't touch the contents of a message in
- any way, there is obviously no way of leaking out any information
- about the content of the message. RMX is based solely on the
- envelope recipient address. However, methods to fix problems not
- covered by RMX might allow content leaking, e.g. if the acceptance
- of a message with an empty sender address requires the reference to
- the message id of an e-mail recently sent, this allows an attacker
- to verify whether a certain message was delivered from there.
-
-12.1.2. Message reception and sender domain
-
- Message delivery triggers RMX and APL requests by the recipient.
- Thus, the admin of the DNS server or an eavesdropper could learn
- that the given machine has just received a message with a sender
- from this address, even if the SMTP traffic itself had been
- encrypted.
-
-
-
-Hadmut Danisch Experimental [Page 28]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- However, most of today's MTAs do query the MX and A records of the
- domain after the MAIL FROM command, so this is not a real new
- threat.
-
-12.1.3. Network structure
-
- Since RMX and its associated APL records provide a complete list of
- all IP addresses of hosts authorized to send messages from this
- address, they do reveal informations about the network structure
- and maybe the lifestyle of the domain owner, since a growing number
- of domains are owned by single persons or families. E.g. the RMX
- records could reveal where someone has his job or spends his time
- at weekends.
-
- If such informations are to be kept secret, it is the user's job to
- not sent e-mails from there and to relay them from non-compromising
- IP addresses.
-
-12.1.4. Owner information distribution
-
- As described above, RMX depends partly on the reliability of the
- whois database entries. It does not make anonymous domains
- impossible, but it requires to keep the database entries "true", i.
- e. if a whois entry does not contain informations about the
- responsible person, this must be unambigously labeled as anonymous.
- It must not contain fake names and addresses to pretend a non-
- existing person. However, since most Internet users on the world
- feel extremely annoyed by spam, they will urge their MTA admin to
- reject messages from anonymous domains. The domain owner will have
- the choice to either remain anonymous but be not able to send e-
- mail to everyone in the world, or to be able but to reveal his
- identity to everyone on the world.
-
- It would be possible to provide whois-like services only to
- recipients of recent messages, but this would make things too
- complicated to be commonly adopted.
-
-12.2. General Considerations about spam defense
-
-12.2.1. Content leaking of content filters
-
- As described above in the Security chapter, there are spam filters
- which inherently allow leakage of the message body. Those filters
- upload either the message body, or in most cases just some kind of
- checksum to a third party, which replies whether this is to be seen
- as spam or not. The idea is to keep a databases of all digests of
- all messages. If a message is sent more often than some threshold,
- it is to be considered as a mass mail and therefore tagged as spam.
-
-
-
-Hadmut Danisch Experimental [Page 29]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- While the digest itself does not reveal the content of the message,
- it perfectly reveals where a particular message has been delivered
- to. If a government finds just a single unwanted message, if a
- software manufacturer finds a single message with a stolen product
- license key, if someone finds a message with unpatriotic content,
- it takes just a single database lookup to get a list of all people
- who received this particular message. Content filters with digest
- upload are the perfect "Big Brother".
-
-12.2.2. Black- and Whitelists
-
- Some proposals against spam are based on a central database of
- white- or blacklisted IP addresses, Sender names, Message IDs or
- whatever. Again, there is a central database which learns who has
- received which e-mail or from which sender with every query. This
- allows tracking relations between persons, which is also a breach
- of privacy.
-
-
-
-13. Deployment Considerations
-
-13.1. Compatibility
-
-13.1.1. Compatibility with old mail receivers
-
- Since the suggested extension doesn't change the SMTP protocol at
- all, it is fully compatible with old mail receivers. They simply
- don't ask for the RMX records and don't perform the check.
-
-13.1.2. Compatibility with old mail senders
-
- Since the SMTP protocol is unchanged and the SMTP sender is not
- involved in the check, the method is fully compatible with old mail
- senders.
-
-13.1.3. Compatibility with old DNS clients
-
- Since the RMX is a new RR, the existing DNS protocol and zone
- informations remain completely untouched.
-
- If RMX is provided as a TXT record instead, it must be ensured that
- no other software is misinterpreting this entry.
-
-13.1.4. Compatibility with old DNS servers
-
- Full compatibility: If the server does not support RMX records, RMX
- in TXT records can be used.
-
-
-
-Hadmut Danisch Experimental [Page 30]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-13.2. Enforcement policy
-
- Obviously, for reasons of backward compatibility and smooth
- introduction of this scheme, RMX records can't be required
- immediately. Domains without RMX records must temporarily be
- treated the same way as they are treated right now, i.e. e-mail
- must be accepted from anywhere. But once the scheme becomes
- sufficiently widespread, mail relays can start to refuse e-mails
- with sender addresses from domains without RMX records, thus
- forcing the owner of the domain to include a statement of
- authorization into the domain's zone table. Domain owners will
- still be free to have an RMX record with a network and mask
- 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
- On the other hand, mail receivers will be free to refuse mails from
- domains without RMX records or RMX records which are too loose.
- Advanced MTAs might have a configuration option to set the maximum
- number of IP addresses authorized to use a domain. E-mails from a
- domain, which's RMX records exceed this limit, would be rejected.
- For example, a relay could reject e-mails from domains which
- authorize more than 8 IP addresses. That allows to accept e-mails
- only from domains with a reasonable security policy.
-
-
-
-14. General considerations about fighting spam
-
- Is there a concise technical solution against spam? Yes.
-
- Will it be deployed? Certainly not.
-
- Why not? Because of the strong non-technical interests of several
- parties against a solution to the problem, as described below.
- Since these are non-technical reasons, they might be beyond the
- scope of such a draft. But since they are the main problems that
- prevent fighting spam, it is unavoidable to address them. This
- chapter exists temporarily only and should support the discussion
- of solutions. It is not supposed to be included in a later RFC.
-
-14.1. The economical problem
-
- As has been recently illustrated in the initial session of the
- IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
- sending spam is a business with significant revenues.
-
- But a much bigger business is selling Anti-Spam software. This is a
- billion dollar market, and it is rapidly growing. Any simple and
- effective solution against spam would defeat revenues and drive
- several companies into bankrupt, would make consultants jobless.
-
-
-
-Hadmut Danisch Experimental [Page 31]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- Therefore, spam is essential for the Anti-Spam business. If there
- is no spam, then no Anti-Spam software can be sold, similar to the
- Anti-Virus business. There are extremely strong efforts to keep
- this market growing. Viruses, Worms, and now spam are just perfect
- to keep this market alive: It is not sufficient to just buy a
- software. Databases need to be updated continuously, thus making
- the cash flow continuously. Have a single, simple, and permanent
- solution to the problem and - boom - this billion dollar market is
- dead.
-
- That's one of the reasons why people are expected to live with
- spam. They have to live with it to make them buy Anti-Spam
- software. Content filters are perfect products to keep this market
- alive.
-
-14.2. The POP problem
-
- Another problem is the history of mail delivery. Once upon a time,
- there used to be very few SMTP relays which handled the e-mail
- traffic of all the world, and everybody was happy with that. Then
- odd things like Personal Computers, which are sometimes switched
- off, portable computers, dynamicly assigned IP addresses, IP access
- from hotel rooms, etc. was invented, and people became unhappy,
- because SMTP does not support delivery to such machines. To make
- them happy again, the Post Office Protocol[4] was invented, which
- turned the last part of message delivery from SMTP's push style
- into a pull style, thus making virtually every computer on the
- world with any random IP address a potential receiver of mails for
- random domains. Unfortunately, only receiving e-mail was covered,
- but sending e-mail was left to SMTP.
-
- The result is that today we have only very few SMTP relays pointed
- to by MX records, but an extreme number of hosts sending e-mail
- with SMTP from any IP address with sender addresses from any
- domain. Mail delivery has become very asymmetric. Insecurity,
- especially forgeability, has become an essential part of mail
- transport.
-
- That problem could easily be fixed: Use protocols which allow
- uploading of messages to be delivered. If a host doesn't receive
- messages by SMTP, it shouldn't deliver by SMTP. Mail delivery
- should go the same way back that incoming mail went in. This is
- not a limitation to those people on the road who plug their
- portable computer in any hotel room's phone plug and use any
- provider. If there is a POP server granting download access from
- anywhere, then the same server should be ready to accept uploading
- of outgoing messages.
-
-
-
-
-Hadmut Danisch Experimental [Page 32]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- But as I saw from the comments on the first version of this draft,
- people religiously insist on sending e-mail with their domain from
- any computer with any IP address in the world, e.g. when visiting a
- friend using her computer. It appears to be impossible to convince
- people that stopping mail forgery requires every one of them to
- give up forging.
-
-14.3. The network structure problem
-
- A subsequent problem is that many organisations failed to implement
- a proper mail delivery structure and heavily based their network on
- this asymmetry. I received harsh comments from Universities who
- were unable to give their network a good structure. While they do
- have a central mail relay for incoming mail to the universities
- domain, they developed a structure where every member of the
- University randomly sends e-mails with that University's domain as
- a sender address from home or everywhere in the world with any
- dynamically assigned IP address from any provider. So this domain
- is to be used from every possible IP address on earth, and they are
- unable to operate any authentication scheme. Furthermore, they were
- unable to understand that such a policy heavily supports spam and
- that they have to expect that people don't accept such e-mails
- anymore once they become blacklisted.
-
- As long as organisations insist on having such policies, spammers
- will have a perfect playground.
-
-14.4. The mentality problem
-
- Another problem is the mentality of many internet users of certain
- countries. I received harsh comments from people who strongly
- insisted on the freedom to send any e-mail with any sender address
- from anywhere, and who heavily refused any kind of authentication
- step or any limitation, because they claimed that this would
- infringe their constitutional "Freedom of speech". They are
- undeviatingly convinced that "Freedom of speech" guarantees their
- right to talk to everybody with any sender address, and that is has
- to be kept the recipient's own problem to sort out what he doesn't
- want to read - on the recipient's expense.
-
- It requires a clear statement that the constitutional "Freedom of
- Speech" does not cover molesting people with unsolicited e-mail
- with forged sender address.
-
-14.5. The identity problem
-
- How does one fight against mail forgery? With authentication. What
- is authentication? In simple words: Making sure that the sender's
-
-
-
-Hadmut Danisch Experimental [Page 33]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- real identity meets the recipients idea of who is the sender, based
- on the sender address which came with the message.
-
- What is identity? It is the main problem. Several countries have
- different ideas of "identity", which turn out to be somehow
- incompatible. In some countries people have identity cards and
- never change their name and birthday. Identities are created by
- human birth, not by identity changes. Other countries do not have
- such a tight idea about identity. People's temporary identity is
- based on nothing more than a driving license and a social security
- number. With this background, it is virtually impossible to create
- a trustworthy PKI covering all Internet users. I learned that it is
- extremely difficult to convince some people to give up random e-
- mail sending.
-
-14.6. The multi-legislation problem
-
- Many proposals about fighting spam are feasible under certain
- legislations only, and are inacceptable under some of the
- legislations. But a world wide applicable method is required.
- That's why the approach to ask everone on the world to sign
- messages with cryptographic keys is not feasible.
-
-
-Implementation and further Information
-
- Further informations and a test implementation are available at
-
- http://www.danisch.de/work/security/antispam.html
- http://www.danisch.de/software/rmx/
-
-
- Additional informations and a technology overview are also
- available at
-
- http://www.mikerubel.org/computers/rmx_records/
-
-
-References
-
-
-
-1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
- els," RFC 2119 (March 1997).
-
-2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
-
-
-
-
-
-Hadmut Danisch Experimental [Page 34]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
- RFC 1035 (November 1987).
-
-4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
- (May 1996).
-
-
-Draft History
-
- 00 Dec 2002
- 01 Apr 2003
- 02 Jun 2003
- 03 Oct 2003
-
-Author's Address
-
- Hadmut Danisch
-
- Tennesseeallee 58
- 76149 Karlsruhe
- Germany
-
- Phone: ++49-721-843004 or ++49-351-4850477
- E-Mail: rfc@danisch.de
-
-Comments
-
- Please send comments to rfc@danisch.de.
-
-Expiry
-
- This drafts expires on Apr 1, 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 35]
-
diff --git a/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt b/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt
deleted file mode 100644
index 7b5e8cc4455ba..0000000000000
--- a/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt
+++ /dev/null
@@ -1,241 +0,0 @@
-
-IETF DNSEXT WG Bill Manning
-draft-dnsext-opcode-discover-02.txt ep.net
- Paul Vixie
- ISC
- 13 Oct 2003
-
-
- The DISCOVER opcode
-
-This document is an Internet-Draft and is subject to all provisions of
-Section 10 of RFC2026.
-
-Comments may be submitted to the group mailing list at "mdns@zocalo.net"
-or the authors.
-
-Distribution of this memo is unlimited.
-
-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.
-
-The capitalized keywords "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
-
-0. Abstract:
-
- The QUERY opcode in the DNS is designed for unicast. With the
- development of multicast capabilities in the DNS, it is desireable
- to have a more robust opcode for server interactions since a single
- request may generate replies from multiple responders. So DISCOVER
- is defined to deal with replies from multiple responders.
-
- As such, this document extends the core DNS specifications to allow
- clients to have a method for coping with replies from multiple
- responders. Use of this new opcode may facilitate DNS operations in
- modern networking topologies. A prototype of the DISCOVER opcode
- was developed during the TBDS project (1999-2000), funded under DARPA
- grant F30602-99-1-0523.
-
-1. Introduction:
-
- This document describes an experimental extension to the DNS to receive
- multiple responses which is the likely result when using DNS that has
- enabled multicast queries. This approach was developed as part of the
- TBDS research project, funded under DARPA grant F30602-99-1-0523. The
- full processing rules used by TBDS are documented here for possible
- incorporation in a future revision of the DNS specification."
-
-2. Method:
-
- DISCOVER works like QUERY except:
-
- 1. it can be sent to a broadcast or multicast destination. QUERY
- isn't defined for non-unicast, and arguably shouldn't be.
-
- 2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
- tuples. TBDS tried to augment this structure as follows:
- <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
- TBDS, it is cleaner to place the SRV question in a separate pass.
-
- 3. if QDCOUNT equals 0 then only servers willing to do recursion should
- answer. Other servers must silently discard the DISCOVER request.
-
- 4. if QDCOUNT is not equal to 0 then only servers who are authoritative
- for the zones named by some QNAME should answer.
-
- 5. responses may echo the request's Question section or leave it blank,
- just like QUERY.
-
- 6. responses have standard Answer, Authority, and Additional sections.
- e.g. the response is the same as that to a QUERY. It is desireable
- that zero content answers not be sent to avoid badly formed or
- unfulfilled requests. Responses should be sent to the unicast
- address of the requester and the source address should reflect
- the unicast address of the responder.
-
- Example usage for gethostby{name,addr}-style requestors:
-
- Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
- ip6.arpa domain.
-
- DISCOVER whether anyone in-scope is authoritative for this zone.
-
- If so, query these authoritative servers for local
- in-addr/ip6 names.
-
- If not, DISCOVER whether there are recursive servers available.
-
- If so, query these recursive servers for local
- in-addr/ip6 names.
-
- So, a node will issue a multicast request with the DISCOVER opcode at
- some particular multicast scope. Then determine, from the replies,
- whether there are any DNS servers which are authoritative (or support
- recursion) for the zone. Replies to DISCOVER requests MUST set the
- Recursion Available (RA) flag in the DNS message header.
-
- It is important to recognize that a requester must be prepared to
- receive multiple replies from multiple responders. We expect that
- there will be a single response per responder.
-
- Once one learns a host's FQDN by the above means, repeat the process
- for discovering the closest enclosing authoritative server of such
- local name.
-
- Cache all NS and A data learned in this process, respecting TTL's.
-
- TBDS usage for SRV requestors:
-
- Do the gethostbyaddr() and gethostbyname() on one's own link-local
- address, using the above process.
-
- Assume that the closest enclosing zone for which an authority server
- answers an in-scope DISCOVER packet is "this host's parent domain".
-
- Compute the SRV name as _service._transport.*.parentdomain.
-
- This is a change to the definition as defined in RFC 1034.
- A wildcard label ("*") in the QNAME used in a DNS message with
- opcode DISCOVER SHOULD be evaluated with special rules. The
- wildcard matches any label for which the DNS server data is
- authoritative. For example 'x.*.example.com.' would match
- 'x.y.example.com.' and 'x.yy.example.com.' provided that the
- server was authoritative for 'example.com.' In this particular
- case, we suggest the follwing considerations be made:
-
- getservbyname() can be satisfied by issuing a request with
- this computed SRV name. This structure can be
- populated by values returned from a request as follows:
-
- s_name The name of the service, "_service" without the
- preceding underscore.
- s_aliases The names returned in the SRV RRs in replies
- to the query.
- s_port The port number in the SRV RRs replies to the
- query. If these port numbers disagree - one
- of the port numbers is chosen, and only those
- names which correspond are returned.
- s_proto The transport protocol from named by the
- "_transport" label, without the preceding
- underscore.
-
- Send SRV query for this name to discovered local authoritative servers.
-
- Usage for disconnected networks with no authoritative servers:
-
- Hosts should run a "stub server" which acts as though its FQDN is a
- zone name. Computed SOA gives the host's FQDN as MNAME, "." as the
- ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
- and the other timers. Compute NS as the host's FQDN. Compute the
- glue as the host's link-local address. Or Hosts may run a
- "DNS stub server" which acts as though its FQDN is a zone name. The
- rules governing the behavior of this stub server are given elsewhere
- [1] [2].
-
- Such stub servers should answer DISCOVER packets for its zone, and
- will be found by the iterative "discover closest enclosing authority
- server" by DISCOVER clients, either in the gethostbyname() or SRV
- cases described above. Note that stub servers only answer with
- zone names which exactly match QNAME's, not with zone names which
- are owned by QNAME's.
-
- The main deviation from the DNS[3][4] model is that a host (like, say, a
- printer offering LPD services) has a DNS server which answers authoritatively
- for something which hasn't been delegated to it. However, the only way that
- such DNS servers can be discovered is with a new opcode, DISCOVER, which
- is explicitly defined to discover undelegated zones for tightly scoped
- purposes. Therefore this isn't officially a violation of DNS's coherency
- principles. In some cases a responder to DISCOVER may not be traditional
- DNS software, it could be special purpose software.
-
-3. IANA Considerations
-
- As a new opcode, the IANA will need to assign a numeric value
- for the memnonic. The last OPCODE assigned was "5", for UPDATE.
- Test implementations have used OPCODE "6".
-
-4. Security Considerations
-
- No new security considerations are known to be introduced with any new
- opcode, however using multicast for service discovery has the potential
- for denial of service, primarly from flooding attacks. It may also be
- possible to enable deliberate misconfiguration of clients simply by
- running a malicious DNS resolver that claims to be authoritative for
- things that it is not. One possible way to mitigate this effect is by
- use of credentials, such as CERT resource records within an RR set.
- The TBDS project took this approach.
-
-5. Attribution:
-
- This material was generated in discussions on the mdns mailing list
-hosted by Zocalo in March 2000. Updated by discussion in September/October
-2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
-Erik Guttman, Bill Manning and Paul Vixie were active contributors.
-
-6. Author's Address
-
- Bill Manning
- PO 12317
- Marina del Rey, CA. 90295
- +1.310.322.8102
- bmanning@karoshi.com
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 779 7001
- <vixie@isc.org>
-
-7. References
-
-Informational References:
-
-[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
- draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
-
-[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
- draft-manning-dnsext-mdns-00.txt, August 2000. Expired.
-
-Normative References:
-[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- RFC 1034, November 1987.
-[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
- RFC 1035, November 1987
-
- ----------------------------EOL-----------------------
-
diff --git a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
deleted file mode 100644
index 224e7ad1697e2..0000000000000
--- a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
+++ /dev/null
@@ -1,240 +0,0 @@
-Internet Engineering Task Force Alain Durand
-INTERNET-DRAFT SUN Microsystems
-Feb 21, 2003
-Expires Aug 2, 2003
-
-
-
- Dynamic reverse DNS for IPv6
- <draft-durand-dnsop-dynreverse-00.txt>
-
-
-
-Status of this memo
-
-
- This memo provides information to the Internet community. It does
- not specify an Internet standard of any kind. This memo is in full
- conformance with all provisions of Section 10 of RFC2026 [RFC2026].
-
- 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
-
- This document describes a method to dynamically generate PTR records
- and corresponding A or AAAA records when the reverse path DNS tree is
- not populated.
-
- A special domain dynrev.arpa. is reserved for that purpose.
-
-
-1. Introduction
-
- In IPv4, the reverse path tree of the DNS under in-addr.arpa.
- although not perfectly maintained, is still mostly usable and its
- existence is important for a number of applications that relies on
- its existence and decent status. Some applications performs some
- (very) weak security checks based on it. Mail relays relies on it for
- some anti-spams checks an some FTP server will not let you in unless
- your IP address resolve properly with a PTR record.
-
- IPv6 addresses being much longer (and cumbersome) than IPv4
- addresses, it is to fear that the reverse path tree under ip6.arpa.
- would not be as well maintained. Also, tools like 6to4, Isatap and
- others have made creative use of the 128 bits of an IPv6 address to
- automatically embed an IPv4 address to enable seamless connection to
- the IPv6 Internet. However, no provision has been made to make sure
- the reverse path tree gets automatically updated as well for those
- new IPv6 addresses. One step furter, RFC3041 describes a mechanism
- to basically use random bits in the bottom part of an IPv6 address to
- preserver anonymity. If those addresses are to resolve in the reverse
- path tree, it obviously has to be with anonymous data as well.
- Another point to note is that home customer ISPs in IPv4 have a
- current practice to pre-populate the reverse path tree with names
- automatically derived from the IP addresses. This practice is no
- longer possible in IPv6, where IP address allocation is not dense as
- it is the case in IPv4. The mere size of typical customer allocation
- (2^48 according to the recommendation of RFC3177) makes it
- impossible.
-
- Applications that check the existence of PTR records usually follow
- this by checking if the name pointed by the PTR resolve in a A (or
- AAAA for IPv6) that match the original IP address. Thus the forward
- path tree must also include the corresponding data.
-
- One simple approach of this problem is to simply declare the usage of
- the reverse path DNS as described above obsolete. The author believe
- this is too strong an approach for now.
-
- Similarly, a completely different approach would be to deprecate the
- usage of DNS for the reverse tree altogether and replace it by
- something inspired from ICMP name-info messages. The author believes
- that this approached is an important departure from the current
- practise and thus not very realistic. Also, there are some concerns
- about the the security implications of this method as any node could
- easily impersonate any name. This approach would fundamentally change
- the underlying assumption of "I trust what has been put in the DNS by
- the local administrators" to "I trust what has been configured on
- each machine I query directly".
-
-
-
-2. Dynamic record generation
-
- If static pre-population of the tree is not possible anymore and data
- still need to be returned to applications using getnameinfo(), the
- alternative is dynamic record generation. This can be done is two
- places: in the DNS servers responsible for the allocated space (/64
- or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the
- sub resolver library or the recursive DNS server).
-
- 2.1. On the resolver side.
-
- The resolver, either in the recursive DNS server or in the stub
- library could theoretically generate this data.
-
- In case DNSsec is in place, the recursive DNS server would have to
- pretend these records are authentic.
-
- If the synthesis is done in the stub-resolver library, no record
- needs to be actually generated, only the right information needs to
- be passed to getnameinfo() and getaddrinfo(). If the synthesis is
- done in the recursive DNS server, no modification is required to
- existing stub resolvers.
-
-
-2.2. On the server side.
-
- PTR records could be generated automatically by the server
- responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
- prefixes or basically anything in between) when static data is not
- available.
-
- There could be impact on DNSsec as the zone or some parts of the zone
- may need to be resigned each time a DNS query is made for an
- unpopulated address. This can be seen as a DOS attack on a DNSsec
- zone, so server side synthesis is not recommended if DNSsec is
- deployed.
-
-
-
-3. Synthesis
-
- The algorithm is simple: Do the normal queries. If the query returns
- No such domain, replace this answer by the synthetized one if
- possible.
-
-3.1. PTR synthesis
-
- The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
- where [X] is any valid DNS name.
-
- The fact that the synthetized PTR points to the dynrev.arpa. domain
- is an indication to the applications that this record has been
- dynamically generated.
-
-
-3.2. A synthesis
-
- If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
- record for the string [X].dynrev.arpa. which value is d.c.b.a. with
- a,b,c & d being integer [0..255]
-
-
-3.3. AAAA synthesis
-
- If [X] is in the form
- a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
- addr.arpa, one can synthetized a AAAA record for the string
- [X].dynrev.arpa. which value is
- FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
- a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
-
-
-3.4. Server side synthesis
-
- If synthesis is done on the server side, PTR could be set not to use
- the dynrev.arpa domain but the local domain name instead. It culd be
- for instance dynrev.mydomain.com.
-
- Note also that server side synthesis is not incompatible with
- resolver side synthesis.
-
-
-
-4. IANA considerations
-
- The dynrev.arpa. domain is reserved for the purpose of this document.
-
-
-
-5. Security considerations
-
- Section 2. discusses the the interactions with DNSsec.
-
-
-
-6. Authors addresses
-
- Alain Durand
- SUN Microsystems, Inc
- 17, Network Circle
- UMPK17-202
- Menlo Park, CA 94025
- USA
- Mail: Alain.Durand@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt
deleted file mode 100644
index fa41e7635e2f6..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories
-Expires: February 2006 August 2005
-
-
-
- Domain Name System (DNS) IANA Considerations
- ------ ---- ------ ----- ---- --------------
- <draft-ietf-dnsext-2929bis-01.txt>
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this draft is unlimited. It is intended to become
- the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
- DNS Working Group mailing list <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
- Internet Assigned Number Authority (IANA) parameter assignment
- considerations are given for the allocation of Domain Name System
- (DNS) classes, RR types, operation codes, error codes, RR header
- bits, and AFSDB subtypes.
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DNS Query/Response Headers..............................3
- 2.1 One Spare Bit?.........................................4
- 2.2 Opcode Assignment......................................4
- 2.3 RCODE Assignment.......................................5
- 3. DNS Resource Records....................................6
- 3.1 RR TYPE IANA Considerations............................7
- 3.1.1 DNS TYPE Allocation Policy...........................8
- 3.1.2 Special Note on the OPT RR...........................9
- 3.1.3 The AFSDB RR Subtype Field...........................9
- 3.2 RR CLASS IANA Considerations...........................9
- 3.3 RR NAME Considerations................................11
- 4. Security Considerations................................11
-
- Appendix: Changes from RFC 2929...........................12
-
- Copyright and Disclaimer..................................13
- Normative References......................................13
- Informative References....................................14
-
- Authors Addresses.........................................16
- Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-1. Introduction
-
- The Domain Name System (DNS) provides replicated distributed secure
- hierarchical databases which hierarchically store "resource records"
- (RRs) under domain names. DNS data is structured into CLASSes and
- zones which can be independently maintained. See [RFC 1034, 1035,
- 2136, 2181, 4033] familiarity with which is assumed.
-
- This document provides, either directly or by reference, general IANA
- parameter assignment considerations applying across DNS query and
- response headers and all RRs. There may be additional IANA
- considerations that apply to only a particular RR type or
- query/response opcode. See the specific RFC defining that RR type or
- query/response opcode for such considerations if they have been
- defined, except for AFSDB RR considerations [RFC 1183] which are
- included herein. This RFC obsoletes [RFC 2929].
-
- IANA currently maintains a web page of DNS parameters. See
- <http://www.iana.org/numbers.htm>.
-
- "IETF Standards Action", "IETF Consensus", "Specification Required",
- and "Private Use" are as defined in [RFC 2434].
-
-
-
-2. DNS Query/Response Headers
-
- The header for DNS queries and responses contains field/bits in the
- following diagram taken from [RFC 2136, 2929]:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT/ZOCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT/PRCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT/UPCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- The ID field identifies the query and is echoed in the response so
- they can be matched.
-
- The QR bit indicates whether the header is for a query or a response.
-
-
-D. Eastlake 3rd [Page 3]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
- only in queries or only in responses, depending on the bit. However,
- many DNS implementations copy the query header as the initial value
- of the response header without clearing bits. Thus any attempt to
- use a "query" bit with a different meaning in a response or to define
- a query meaning for a "response" bit is dangerous given existing
- implementation. Such meanings may only be assigned by an IETF
- Standards Action.
-
- The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
- authority count (NSCOUNT), and additional information count (ARCOUNT)
- express the number of records in each section for all opcodes except
- Update. These fields have the same structure and data type for
- Update but are instead the counts for the zone (ZOCOUNT),
- prerequisite (PRCOUNT), update (UPCOUNT), and additional information
- (ARCOUNT) sections.
-
-
-
-2.1 One Spare Bit?
-
- There have been ancient DNS implementations for which the Z bit being
- on in a query meant that only a response from the primary server for
- a zone is acceptable. It is believed that current DNS
- implementations ignore this bit.
-
- Assigning a meaning to the Z bit requires an IETF Standards Action.
-
-
-
-2.2 Opcode Assignment
-
- Currently DNS OpCodes are assigned as follows:
-
- OpCode Name Reference
-
- 0 Query [RFC 1035]
- 1 IQuery (Inverse Query, Obsolete) [RFC 3425]
- 2 Status [RFC 1035]
- 3 available for assignment
- 4 Notify [RFC 1996]
- 5 Update [RFC 2136]
- 6-15 available for assignment
-
- New OpCode assignments require an IETF Standards Action as modified
- by [RFC 4020].
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-2.3 RCODE Assignment
-
- It would appear from the DNS header above that only four bits of
- RCODE, or response/error code are available. However, RCODEs can
- appear not only at the top level of a DNS response but also inside
- OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
- The OPT RR provides an eight bit extension resulting in a 12 bit
- RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
-
- Error codes appearing in the DNS header and in these three RR types
- all refer to the same error code space with the single exception of
- error code 16 which has a different meaning in the OPT RR from its
- meaning in other contexts. See table below.
-
- RCODE Name Description Reference
- Decimal
- Hexadecimal
- 0 NoError No Error [RFC 1035]
- 1 FormErr Format Error [RFC 1035]
- 2 ServFail Server Failure [RFC 1035]
- 3 NXDomain Non-Existent Domain [RFC 1035]
- 4 NotImp Not Implemented [RFC 1035]
- 5 Refused Query Refused [RFC 1035]
- 6 YXDomain Name Exists when it should not [RFC 2136]
- 7 YXRRSet RR Set Exists when it should not [RFC 2136]
- 8 NXRRSet RR Set that should exist does not [RFC 2136]
- 9 NotAuth Server Not Authoritative for zone [RFC 2136]
- 10 NotZone Name not contained in zone [RFC 2136]
- 11 - 15 Available for assignment
- 16 BADVERS Bad OPT Version [RFC 2671]
- 16 BADSIG TSIG Signature Failure [RFC 2845]
- 17 BADKEY Key not recognized [RFC 2845]
- 18 BADTIME Signature out of time window [RFC 2845]
- 19 BADMODE Bad TKEY Mode [RPC 2930]
- 20 BADNAME Duplicate key name [RPF 2930]
- 21 BADALG Algorithm not supported [RPF 2930]
-
- 22 - 3,840
- 0x0016 - 0x0F00 Available for assignment
-
- 3,841 - 4,095
- 0x0F01 - 0x0FFF Private Use
-
- 4,096 - 65,534
- 0x1000 - 0xFFFE Available for assignment
-
- 65,535
- 0xFFFF Reserved, can only be allocated by an IETF
- Standards Action.
-
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- Since it is important that RCODEs be understood for interoperability,
- assignment of new RCODE listed above as "available for assignment"
- requires an IETF Consensus.
-
-
-
-3. DNS Resource Records
-
- All RRs have the same top level format shown in the figure below
- taken from [RFC 1035]:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / /
- / NAME /
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- NAME is an owner name, i.e., the name of the node to which this
- resource record pertains. NAMEs are specific to a CLASS as described
- in section 3.2. NAMEs consist of an ordered sequence of one or more
- labels each of which has a label type [RFC 1035, 2671].
-
- TYPE is a two octet unsigned integer containing one of the RR TYPE
- codes. See section 3.1.
-
- CLASS is a two octet unsigned integer containing one of the RR CLASS
- codes. See section 3.2.
-
- TTL is a four octet (32 bit) bit unsigned integer that specifies the
- number of seconds that the resource record may be cached before the
- source of the information should again be consulted. Zero is
- interpreted to mean that the RR can only be used for the transaction
- in progress.
-
- RDLENGTH is an unsigned 16 bit integer that specifies the length in
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- octets of the RDATA field.
-
- RDATA is a variable length string of octets that constitutes the
- resource. The format of this information varies according to the TYPE
- and in some cases the CLASS of the resource record.
-
-
-
-3.1 RR TYPE IANA Considerations
-
- There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
- and MetaTYPEs.
-
- Data TYPEs are the primary means of storing data. QTYPES can only be
- used in queries. Meta-TYPEs designate transient data associated with
- an particular DNS message and in some cases can also be used in
- queries. Thus far, data TYPEs have been assigned from 1 upwards plus
- the block from 100 through 103 while Q and Meta Types have been
- assigned from 255 downwards except for the OPT Meta-RR which is
- assigned TYPE 41. There have been DNS implementations which made
- caching decisions based on the top bit of the bottom byte of the RR
- TYPE.
-
- There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
- [RFC 2845], and TKEY [RFC 2930].
-
- There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
- AXFR, and IXFR.
-
- Considerations for the allocation of new RR TYPEs are as follows:
-
- Decimal
- Hexadecimal
-
- 0
- 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
- 2535] and in other circumstances and must never be allocated
- for ordinary use.
-
- 1 - 127
- 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
- TYPEs by the DNS TYPE Allocation Policy as specified in
- section 3.1.1.
-
- 128 - 255
- 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
- Meta TYPEs by the DNS TYPE Allocation Policy as specified in
- section 3.1.1.
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- 256 - 32,767
- 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
- TYPE Allocation Policy as specified in section 3.1.1.
-
- 32,768 - 65,279
- 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
- 65,280 - 65534
- 0xFF00 - 0xFFFE - Private Use.
-
- 65,535
- 0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-
-3.1.1 DNS TYPE Allocation Policy
-
- Parameter values specified above as assigned based on DNS TYPE
- Allocation Policy. That is, Expert Review with the additional
- requirement that the review be based on a complete template as
- specified below which has been posted for three weeks to the
- namedroppers@ops.ietf.org mailing list.
-
- Partial or draft templates may be posted with the intend of
- soliciting feedback.
-
-
- DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
-
- Date:
-
- Name and email of originator:
-
- Pointer to internet-draft or other document giving a detailed
- description of the protocol use of the new RR Type:
-
- What need is the new RR TYPE intended to fix?
-
- What existing RR TYPE(s) come closest to filling that need and why are
- they unsatisfactory?
-
- Does the proposed RR TYPR require special handling within the DNS
- different from an Unknown RR TYPE?
-
- Comments:
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-3.1.2 Special Note on the OPT RR
-
- The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
- primary purpose is to extend the effective field size of various DNS
- fields including RCODE, label type, OpCode, flag bits, and RDATA
- size. In particular, for resolvers and servers that recognize it, it
- extends the RCODE field from 4 to 12 bits.
-
-
-
-3.1.3 The AFSDB RR Subtype Field
-
- The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
- RDATA field structure as the MX RR but the 16 bit unsigned integer
- field at the beginning of the RDATA is interpreted as a subtype as
- follows:
-
- Decimal
- Hexadecimal
-
- 0
- 0x0000 - Allocation requires IETF Standards Action.
-
- 1
- 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
-
- 2
- 0x0002 - DCE/NCA root cell directory node [RFC 1183].
-
- 3 - 65,279
- 0x0003 - 0xFEFF - Allocation by IETF Consensus.
-
- 65,280 - 65,534
- 0xFF00 - 0xFFFE - Private Use.
-
- 65,535
- 0xFFFF - Reserved, allocation requires IETF Standards Action.
-
-
-
-3.2 RR CLASS IANA Considerations
-
- DNS CLASSes have been little used but constitute another dimension of
- the DNS distributed database. In particular, there is no necessary
- relationship between the name space or root servers for one CLASS and
- those for another CLASS. The same name can have completely different
- meanings in different CLASSes; however, the label types are the same
- and the null label is usable only as root in every CLASS. However,
- as global networking and DNS have evolved, the IN, or Internet, CLASS
- has dominated DNS use.
-
-
-D. Eastlake 3rd [Page 9]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- There are two subcategories of DNS CLASSes: normal data containing
- classes and QCLASSes that are only meaningful in queries or updates.
-
- The current CLASS assignments and considerations for future
- assignments are as follows:
-
- Decimal
- Hexadecimal
-
- 0
- 0x0000 - Reserved, assignment requires an IETF Standards Action.
-
- 1
- 0x0001 - Internet (IN).
-
- 2
- 0x0002 - Available for assignment by IETF Consensus as a data CLASS.
-
- 3
- 0x0003 - Chaos (CH) [Moon 1981].
-
- 4
- 0x0004 - Hesiod (HS) [Dyer 1987].
-
- 5 - 127
- 0x0005 - 0x007F - available for assignment by IETF Consensus for data
- CLASSes only.
-
- 128 - 253
- 0x0080 - 0x00FD - available for assignment by IETF Consensus for
- QCLASSes only.
-
- 254
- 0x00FE - QCLASS None [RFC 2136].
-
- 255
- 0x00FF - QCLASS Any [RFC 1035].
-
- 256 - 32,767
- 0x0100 - 0x7FFF - Assigned by IETF Consensus.
-
- 32,768 - 65,279
- 0x8000 - 0xFEFF - Assigned based on Specification Required as defined
- in [RFC 2434].
-
- 65,280 - 65,534
- 0xFF00 - 0xFFFE - Private Use.
-
- 65,535
- 0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-D. Eastlake 3rd [Page 10]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-3.3 RR NAME Considerations
-
- DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
- NAME is "ROOT" which is the zero length label. By definition, the
- null or ROOT label can not be used for any other NAME purpose.
-
- At the present time, there are two categories of label types, data
- labels and compression labels. Compression labels are pointers to
- data labels elsewhere within an RR or DNS message and are intended to
- shorten the wire encoding of NAMEs. The two existing data label
- types are sometimes referred to as Text and Binary. Text labels can,
- in fact, include any octet value including zero value octets but most
- current uses involve only [US-ASCII]. For retrieval, Text labels are
- defined to treat ASCII upper and lower case letter codes as matching
- [insensitive]. Binary labels are bit sequences [RFC 2673]. The
- Binary label type is Experimental [RFC 3363].
-
- IANA considerations for label types are given in [RFC 2671].
-
- NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
- 1981] CLASSes are essentially for local use. The IN or Internet
- CLASS is thus the only DNS CLASS in global use on the Internet at
- this time.
-
- A somewhat out-of-date description of name allocation in the IN Class
- is given in [RFC 1591]. Some information on reserved top level
- domain names is in BCP 32 [RFC 2606].
-
-
-
-4. Security Considerations
-
- This document addresses IANA considerations in the allocation of
- general DNS parameters, not security. See [RFC 4033, 4034, 4035] for
- secure DNS considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 11]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-Appendix: Changes from RFC 2929
-
- RFC Editor: This Appendix should be deleted for publication.
-
- Changes from RFC 2929 to this draft:
-
- 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
- Allocation Policy" and add the specification of that policy. Change
- some remaining "IETF Standards Action" allocation requirements to say
- "as modified by [RFC 4020]".
-
- 2. Updated various RFC references.
-
- 3. Mentioned that the Binary label type is now Experimental and
- IQuery is Obsolete.
-
- 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
- IETF Standards Action required.
-
- 5. Add an IANA allocation policy for the AFSDB RR Subtype field.
-
- 6. Addition of reference to case insensitive draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 12]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Normative References
-
- [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
- Specifications", STD 13, RFC 1035, November 1987.
-
- [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
- Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
-
- [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
- Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
- [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
- [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
- RFC 2673, August 1999.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
-
-D. Eastlake 3rd [Page 13]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", September 2000.
-
- [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
- Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
- the Domain Name System (DNS)", RFC 3363, August 2002.
-
- [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
- 2002.
-
- [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
- Standards Track Code Points", BCP 100, RFC 4020, February 2005.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
- X3.4, American National Standards Institute: New York, 1968.
-
-
-
-Informative References
-
- [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
- Technical Plan - Name Service, April 1987,
-
- [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
- Institute of Technology Artificial Intelligence Laboratory, June
- 1981.
-
- [RFC 1591] - Postel, J., "Domain Name System Structure and
- Delegation", RFC 1591, March 1994.
-
- [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
- "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
- September 2000.
-
- [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
- Names", RFC 2606, June 1999.
-
- [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
-
-
-D. Eastlake 3rd [Page 14]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
- work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 15]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-Authors Addresses
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554 (w)
- email: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires February 2006.
-
- Its file name is draft-ietf-dnsext-2929bis-01.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 16]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
deleted file mode 100644
index f0ce70ab1c997..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-
-INTERNET-DRAFT Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc.
- November 2002
-
-
- DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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
-
- In the Domain Name System, zone data is replicated among
- authoritative DNS servers by means of the "zone transfer" protocol,
- also known as the "AXFR" protocol. This memo clarifies, updates, and
- adds missing detail to the original AXFR protocol specification in
- RFC1034.
-
-1. Introduction
-
- The original definition of the DNS zone transfer protocol consists of
- a single paragraph in [RFC1034] section 4.3.5 and some additional
- notes in [RFC1035] section 6.3. It is not sufficiently detailed to
- serve as the sole basis for constructing interoperable
- implementations. This document is an attempt to provide a more
- complete definition of the protocol. Where the text in RFC1034
- conflicts with existing practice, the existing practice has been
- codified in the interest of interoperability.
-
-
-
-
-Expires May 2003 [Page 1]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- 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. The zone transfer request
-
- To initiate a zone transfer, the slave server sends a zone transfer
- request to the master server over a reliable transport such as TCP.
- The form of this request is specified in sufficient detail in RFC1034
- and needs no further clarification.
-
- Implementers are advised that one server implementation in widespread
- use sends AXFR requests where the TCP message envelope size exceeds
- the DNS request message size by two octets.
-
-3. The zone transfer response
-
- If the master server is unable or unwilling to provide a zone
- transfer, it MUST respond with a single DNS message containing an
- appropriate RCODE other than NOERROR. If the master is not
- authoritative for the requested zone, the RCODE SHOULD be 9
- (NOTAUTH).
-
- Slave servers should note that some master server implementations
- will simply close the connection when denying the slave access to the
- zone. Therefore, slaves MAY interpret an immediate graceful close of
- the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
- If a zone transfer can be provided, the master server sends one or
- more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
- The zone data in a zone transfer response is a sequence of answer
- RRs. These RRs are transmitted in the answer section(s) of one or
- more DNS response messages.
-
- The AXFR protocol definition in RFC1034 does not make a clear
- distinction between response messages and answer RRs. Historically,
- DNS servers always transmitted a single answer RR per message. This
- encoding is wasteful due to the overhead of repeatedly sending DNS
- message headers and the loss of domain name compression
- opportunities. To improve efficiency, some newer servers support a
- mode where multiple RRs are transmitted in a single DNS response
- message.
-
- A master MAY transmit multiple answer RRs per response message up to
- the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003 [Page 2]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- DNS message size. In the case of a small zone, this can cause the
- entire transfer to be transmitted in a single response message.
-
- Slaves MUST accept messages containing any number of answer RRs. For
- compatibility with old slaves, masters that support sending multiple
- answers per message SHOULD be configurable to revert to the
- historical mode of one answer per message, and the configuration
- SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
- RFC1034 does not specify the contents of the DNS message header of
- the zone transfer response messages. The header of each message MUST
- be as follows:
-
- ID Copy from request
- QR 1
- OPCODE QUERY
- AA 1, but MAY be 0 when RCODE is not NOERROR
- TC 0
- RD Copy from request, or 0
- RA Set according to availability of recursion, or 0
- Z 0
- AD 0
- CD 0
- RCODE NOERROR on success, error code otherwise
-
- The slave MUST check the RCODE in each message and abort the transfer
- if it is not NOERROR. It SHOULD check the ID of the first message
- received and abort the transfer if it does not match the ID of the
- request. The ID SHOULD be ignored in subsequent messages, and fields
- other than RCODE and ID SHOULD be ignored in all messages, to ensure
- interoperability with certain older implementations which transmit
- incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
- Zone transfer responses are not subject to any kind of additional
- section processing or automatic inclusion of SIG records. SIG RRs in
- the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
- RFC1034 does not specify whether zone transfer response messages have
- a question section or not. The initial message of a zone transfer
- response SHOULD have a question section identical to that in the
- request. Subsequent messages SHOULD NOT have a question section,
- though the final message MAY. The receiving slave server MUST accept
-
-
-
-Expires May 2003 [Page 3]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- any combination of messages with and without a question section.
-
-3.5. The authority section
-
- The master server MUST transmit messages with an empty authority
- section. Slaves MUST ignore any authority section contents they may
- receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
- The additional section MAY contain additional RRs such as transaction
- signatures. The slave MUST ignore any unexpected RRs in the
- additional section. It MUST NOT treat additional section RRs as zone
- data.
-
-4. Zone data
-
- The purpose of the zone transfer mechanism is to exactly replicate at
- each slave the set of RRs associated with a particular zone at its
- primary master. An RR is associated with a zone by being loaded from
- the master file of that zone at the primary master server, or by some
- other, equivalent method for configuring zone data.
-
- This replication shall be complete and unaltered, regardless of how
- many and which intermediate masters/slaves are involved, and
- regardless of what other zones those intermediate masters/slaves do
- or do not serve, and regardless of what data may be cached in
- resolvers associated with the intermediate masters/slaves.
-
- Therefore, in a zone transfer the master MUST send exactly those
- records that are associated with the zone, whether or not their owner
- names would be considered to be "in" the zone for purposes of
- resolution, and whether or not they would be eligible for use as glue
- in responses. The transfer MUST NOT include any RRs that are not
- associated with the zone, such as RRs associated with zones other
- than the one being transferred or present in the cache of the local
- resolver, even if their owner names are in the zone being transferred
- or are pointed to by NS records in the zone being transferred.
-
- The slave MUST associate the RRs received in a zone transfer with the
- specific zone being transferred, and maintain that association for
- purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
- RFC1034 states that "The first and last messages must contain the
- data for the top authoritative node of the zone". This is not
- consistent with existing practice. All known master implementations
-
-
-
-Expires May 2003 [Page 4]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- send, and slave implementations expect to receive, the zone's SOA RR
- as the first and last record of the transfer.
-
- Therefore, the quoted sentence is hereby superseded by the sentence
- "The first and last RR transmitted must be the SOA record of the
- zone".
-
- The initial and final SOA record MUST be identical, with the possible
- exception of case and compression. In particular, they MUST have the
- same serial number. The slave MUST consider the transfer to be
- complete when, and only when, it has received the message containing
- the second SOA record.
-
- The transmission order of all other RRs in the zone is undefined.
- Each of them SHOULD be transmitted only once, and slaves MUST ignore
- any duplicate RRs received.
-
-6. Security Considerations
-
- The zone transfer protocol as defined in [RFC1034] and clarified by
- this memo does not have any built-in mechanisms for the slave to
- securely verify the identity of the master server and the integrity
- of the transferred zone data. The use of a cryptographic mechanism
- for ensuring authenticity and integrity, such as TSIG [RFC2845],
- IPSEC, or TLS, is RECOMMENDED.
-
- The zone transfer protocol allows read-only public access to the
- complete zone data. Since data in the DNS is public by definition,
- this is generally acceptable. Sites that wish to avoid disclosing
- their full zone data MAY restrict zone transfer access to authorized
- slaves.
-
- These clarifications are not believed to themselves introduce any new
- security problems, nor to solve any existing ones.
-
-Acknowledgements
-
- Many people have contributed input and commentary to earlier versions
- of this document, including but not limited to Bob Halley, Dan
- Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
- Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
- Trenholme, and Brian Wellington.
-
-References
-
- [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
- November 1987.
-
-
-
-
-Expires May 2003 [Page 5]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- [RFC1035] - Domain Names - Implementation and Specifications, P.
- Mockapetris, November 1987.
-
- [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
- S. Bradner, BCP 14, March 1997.
-
- [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
- Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
- Andreas Gustafsson
- Nominum Inc.
- 2385 Bay Rd
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
-
- Email: gson@nominum.com
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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
-
-
-
-Expires May 2003 [Page 6]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003 [Page 7]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
deleted file mode 100644
index 09776618f2ae3..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
+++ /dev/null
@@ -1,561 +0,0 @@
-
-
-DNSEXT M. Stapp
-Internet-Draft Cisco Systems, Inc.
-Expires: January 14, 2005 T. Lemon
- A. Gustafsson
- Nominum, Inc.
- July 16, 2004
-
-
- A DNS RR for Encoding DHCP Information (DHCID RR)
- <draft-ietf-dnsext-dhcid-rr-08.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 January 14, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-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]
- proposes storing client identifiers in the DNS to unambiguously
-
-
-
-Stapp, et al. Expires January 14, 2005 [Page 1]
-
-Internet-Draft The DHCID RR July 2004
-
-
- 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 January 14, 2005 [Page 2]
-
-Internet-Draft The DHCID RR July 2004
-
-
-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 January 14, 2005 [Page 3]
-
-Internet-Draft The DHCID RR July 2004
-
-
-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 January 14, 2005 [Page 4]
-
-Internet-Draft The DHCID RR July 2004
-
-
- 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 January 14, 2005 [Page 5]
-
-Internet-Draft The DHCID RR July 2004
-
-
-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 January 14, 2005 [Page 6]
-
-Internet-Draft The DHCID RR July 2004
-
-
- 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 January 14, 2005 [Page 7]
-
-Internet-Draft The DHCID RR July 2004
-
-
-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 January 14, 2005 [Page 8]
-
-Internet-Draft The DHCID RR July 2004
-
-
-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 January 14, 2005 [Page 9]
-
-Internet-Draft The DHCID RR July 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.
-
-
-
-
-Stapp, et al. Expires January 14, 2005 [Page 10]
-
-
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
deleted file mode 100644
index 2cd972473d0c0..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt
+++ /dev/null
@@ -1,562 +0,0 @@
-
-
-
-
-DNSEXT M. Stapp
-Internet-Draft Cisco Systems, Inc.
-Expires: August 13, 2005 T. Lemon
- A. Gustafsson
- Nominum, Inc.
- February 9, 2005
-
-
- A DNS RR for Encoding DHCP Information (DHCID RR)
- <draft-ietf-dnsext-dhcid-rr-09.txt>
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 13, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- It is possible for multiple DHCP clients to attempt to update the
- same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
- the clients themselves perform the DNS updates, conflicts can arise.
- To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 1]
-
-Internet-Draft The DHCID RR February 2005
-
-
- proposes storing client identifiers in the DNS to unambiguously
- associate domain names with the DHCP clients to which they refer.
- This memo defines a distinct RR type for this purpose for use by DHCP
- clients and servers, the "DHCID" RR.
-
-Table of Contents
-
- 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4
- 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4
- 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4
- 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4
- 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
- 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6
- 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8
- 9.2 Informative References . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 2]
-
-Internet-Draft The DHCID RR February 2005
-
-
-1. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [2].
-
-2. Introduction
-
- A set of procedures to allow DHCP [7] clients and servers to
- automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
- in "Resolution of DNS Name Conflicts" [1].
-
- Conflicts can arise if multiple DHCP clients wish to use the same DNS
- name. To resolve such conflicts, "Resolution of DNS Name Conflicts"
- [1] proposes storing client identifiers in the DNS to unambiguously
- associate domain names with the DHCP clients using them. In the
- interest of clarity, it is preferable for this DHCP information to
- use a distinct RR type. This memo defines a distinct RR for this
- purpose for use by DHCP clients or servers, the "DHCID" RR.
-
- In order to avoid exposing potentially sensitive identifying
- information, the data stored is the result of a one-way MD5 [5] hash
- computation. The hash includes information from the DHCP client's
- REQUEST message as well as the domain name itself, so that the data
- stored in the DHCID RR will be dependent on both the client
- identification used in the DHCP protocol interaction and the domain
- name. This means that the DHCID RDATA will vary if a single client
- is associated over time with more than one name. This makes it
- difficult to 'track' a client as it is associated with various domain
- names.
-
- The MD5 hash algorithm has been shown to be weaker than the SHA-1
- algorithm; it could therefore be argued that SHA-1 is a better
- choice. However, SHA-1 is significantly slower than MD5. A
- successful attack of MD5's weakness does not reveal the original data
- that was used to generate the signature, but rather provides a new
- set of input data that will produce the same signature. Because we
- are using the MD5 hash to conceal the original data, the fact that an
- attacker could produce a different plaintext resulting in the same
- MD5 output is not significant concern.
-
-3. The DHCID RR
-
- The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
- DHCID RR is only defined in the IN class. DHCID RRs cause no
- additional section processing. The DHCID RR is not a singleton type.
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 3]
-
-Internet-Draft The DHCID RR February 2005
-
-
-3.1 DHCID RDATA format
-
- The RDATA section of a DHCID RR in transmission contains RDLENGTH
- bytes of binary data. The format of this data and its interpretation
- by DHCP servers and clients are described below.
-
- DNS software should consider the RDATA section to be opaque. DHCP
- clients or servers use the DHCID RR to associate a DHCP client's
- identity with a DNS name, so that multiple DHCP clients and servers
- may deterministically perform dynamic DNS updates to the same zone.
- From the updater's perspective, the DHCID resource record RDATA
- consists of a 16-bit identifier type, in network byte order, followed
- by one or more bytes representing the actual identifier:
-
- < 16 bits > DHCP identifier used
- < n bytes > MD5 digest
-
-
-3.2 DHCID Presentation Format
-
- In DNS master files, the RDATA is represented as a single block in
- base 64 encoding identical to that used for representing binary data
- in RFC 2535 [8]. The data may be divided up into any number of white
- space separated substrings, down to single base 64 digits, which are
- concatenated to form the complete RDATA. These substrings can span
- lines using the standard parentheses.
-
-3.3 The DHCID RR Type Codes
-
- The DHCID RR Type Code specifies what data from the DHCP client's
- request was used as input into the hash function. The type codes are
- defined in a registry maintained by IANA, as specified in Section 7.
- The initial list of assigned values for the type code is:
-
- 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
- 0x0001 = The data portion from a DHCPv4 client's Client Identifier
- option [9].
- 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
- client's Client Identifier option [10] or the DUID field from a
- DHCPv4 client's Client Identifier option [12]).
-
- 0x0003 - 0xfffe = Available to be assigned by IANA.
-
- 0xffff = RESERVED
-
-3.4 Computation of the RDATA
-
- The DHCID RDATA is formed by concatenating the two type bytes with
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 4]
-
-Internet-Draft The DHCID RR February 2005
-
-
- some variable-length identifying data.
-
- < type > < data >
-
- The RDATA for all type codes other than 0xffff, which is reserved for
- future expansion, is formed by concatenating the two type bytes and a
- 16-byte MD5 hash value. The input to the hash function is defined to
- be:
-
- data = MD5(< identifier > < FQDN >)
-
- The FQDN is represented in the buffer in unambiguous canonical form
- as described in RFC 2535 [8], section 8.1. The type code and the
- identifier are related as specified in Section 3.3: the type code
- describes the source of the identifier.
-
- When the updater is using the client's link-layer address as the
- identifier, the first two bytes of the DHCID RDATA MUST be zero. To
- generate the rest of the resource record, the updater computes a
- one-way hash using the MD5 algorithm across a buffer containing the
- client's network hardware type, link-layer address, and the FQDN
- data. Specifically, the first byte of the buffer contains the
- network hardware type as it appeared in the DHCP 'htype' field of the
- client's DHCPREQUEST message. All of the significant bytes of the
- chaddr field in the client's DHCPREQUEST message follow, in the same
- order in which the bytes appear in the DHCPREQUEST message. The
- number of significant bytes in the 'chaddr' field is specified in the
- 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified
- above, follows.
-
- When the updater is using the DHCPv4 Client Identifier option sent by
- the client in its DHCPREQUEST message, the first two bytes of the
- DHCID RR MUST be 0x0001, in network byte order. The rest of the
- DHCID RR MUST contain the results of computing an MD5 hash across the
- payload of the option, followed by the FQDN. The payload of the
- option consists of the bytes of the option following the option code
- and length.
-
- When the updater is using the DHCPv6 DUID sent by the client in its
- REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
- in network byte order. The rest of the DHCID RR MUST contain the
- results of computing an MD5 hash across the payload of the option,
- followed by the FQDN. The payload of the option consists of the
- bytes of the option following the option code and length.
-
-3.5 Examples
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 5]
-
-Internet-Draft The DHCID RR February 2005
-
-
-3.5.1 Example 1
-
- A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
- Ethernet MAC address 01:02:03:04:05:06 using domain name
- "client.example.com" uses the client's link-layer address to identify
- the client. The DHCID RDATA is composed by setting the two type
- bytes to zero, and performing an MD5 hash computation across a buffer
- containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
- address, and the domain name (represented as specified in
- Section 3.4).
-
- client.example.com. A 10.0.0.1
- client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
-
-
-3.5.2 Example 2
-
- A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
- included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
- in its DHCP request. The server updates the name "chi.example.com"
- on the client's behalf, and uses the DHCP client identifier option
- data as input in forming a DHCID RR. The DHCID RDATA is formed by
- setting the two type bytes to the value 0x0001, and performing an MD5
- hash computation across a buffer containing the seven bytes from the
- client-id option and the FQDN (represented as specified in
- Section 3.4).
-
- chi.example.com. A 10.0.12.99
- chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
-
-
-4. Use of the DHCID RR
-
- This RR MUST NOT be used for any purpose other than that detailed in
- "Resolution of DNS Name Conflicts" [1]. Although this RR contains
- data that is opaque to DNS servers, the data must be consistent
- across all entities that update and interpret this record.
- Therefore, new data formats may only be defined through actions of
- the DHC Working Group, as a result of revising [1].
-
-5. Updater Behavior
-
- The data in the DHCID RR allows updaters to determine whether more
- than one DHCP client desires to use a particular FQDN. This allows
- site administrators to establish policy about DNS updates. The DHCID
- RR does not establish any policy itself.
-
- Updaters use data from a DHCP client's request and the domain name
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 6]
-
-Internet-Draft The DHCID RR February 2005
-
-
- that the client desires to use to compute a client identity hash, and
- then compare that hash to the data in any DHCID RRs on the name that
- they wish to associate with the client's IP address. If an updater
- discovers DHCID RRs whose RDATA does not match the client identity
- that they have computed, the updater SHOULD conclude that a different
- client is currently associated with the name in question. The
- updater SHOULD then proceed according to the site's administrative
- policy. That policy might dictate that a different name be selected,
- or it might permit the updater to continue.
-
-6. Security Considerations
-
- The DHCID record as such does not introduce any new security problems
- into the DNS. In order to avoid exposing private information about
- DHCP clients to public scrutiny, a one-way hash is used to obscure
- all client information. In order to make it difficult to 'track' a
- client by examining the names associated with a particular hash
- value, the FQDN is included in the hash computation. Thus, the RDATA
- is dependent on both the DHCP client identification data and on each
- FQDN associated with the client.
-
- Administrators should be wary of permitting unsecured DNS updates to
- zones which are exposed to the global Internet. Both DHCP clients
- and servers SHOULD use some form of update authentication (e.g., TSIG
- [11]) when performing DNS updates.
-
-7. IANA Considerations
-
- IANA is requested to allocate an RR type number for the DHCID record
- type.
-
- This specification defines a new number-space for the 16-bit type
- codes associated with the DHCID RR. IANA is requested to establish a
- registry of the values for this number-space.
-
- Three initial values are assigned in Section 3.3, and the value
- 0xFFFF is reserved for future use. New DHCID RR type codes are
- tentatively assigned after the specification for the associated type
- code, published as an Internet Draft, has received expert review by a
- designated expert. The final assignment of DHCID RR type codes is
- through Standards Action, as defined in RFC 2434 [6].
-
-8. Acknowledgements
-
- Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
- Ralph Droms for their review and suggestions.
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 7]
-
-Internet-Draft The DHCID RR February 2005
-
-
-9. References
-
-9.1 Normative References
-
- [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
- DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
- 1992.
-
- [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-9.2 Informative References
-
- [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
- [8] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 2132, March 1997.
-
- [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
- Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
- for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 8]
-
-Internet-Draft The DHCID RR February 2005
-
-
-Authors' Addresses
-
- Mark Stapp
- Cisco Systems, Inc.
- 1414 Massachusetts Ave.
- Boxborough, MA 01719
- USA
-
- Phone: 978.936.1535
- Email: mjs@cisco.com
-
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- Email: mellon@nominum.com
-
-
- Andreas Gustafsson
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- Email: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 9]
-
-Internet-Draft The DHCID RR February 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 10]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
deleted file mode 100644
index 438e8008a4c77..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
+++ /dev/null
@@ -1,1397 +0,0 @@
-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-2535typecode-change-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
deleted file mode 100644
index bcc2b4ec516e0..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+++ /dev/null
@@ -1,442 +0,0 @@
-
-
-INTERNET-DRAFT Samuel Weiler
-Expires: June 2004 December 15, 2003
-Updates: RFC 2535, [DS]
-
- Legacy Resolver Compatibility for Delegation Signer
- draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 10 of RFC2026.
-
- 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
-
- Comments should be sent to the author or to the DNSEXT WG mailing
- list: namedroppers@ops.ietf.org
-
-Abstract
-
- As the DNS Security (DNSSEC) specifications have evolved, the
- syntax and semantics of the DNSSEC resource records (RRs) have
- changed. Many deployed nameservers understand variants of these
- semantics. Dangerous interactions can occur when a resolver that
- understands an earlier version of these semantics queries an
- authoritative server that understands the new delegation signer
- semantics, including at least one failure scenario that will cause
- an unsecured zone to be unresolvable. This document changes the
- type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
- avoid those interactions.
-
-Changes between 05 and 06:
-
- Signifigantly reworked the IANA section -- went back to one
- algorithm registry.
-
- Removed Diffie-Hellman from the list of zone-signing algorithms
- (leaving only DSA, RSA/SHA-1, and private algorithms).
-
- Added a DNSKEY flags field registry.
-
-Changes between 04 and 05:
-
- IESG approved publication.
-
- Cleaned up an internal reference in the acknowledgements section.
-
- Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
-
- Changed the names of both new registries. Added algorithm
- mnemonics to the new zone signing algorithm registry. Minor
- rewording in the IANA section for clarity.
-
- Cleaned up formatting of references. Replaced unknown-rr draft
- references with RFC3597. Bumped DS version number.
-
-Changes between 03 and 04:
-
- Clarified that RRSIG(0) may be defined by standards action.
-
- Created a new algorithm registry and renamed the old algorithm
- registry for SIG(0) only. Added references to the appropriate
- crypto algorithm and format specifications.
-
- Several minor rephrasings.
-
-Changes between 02 and 03:
-
- KEY (as well as SIG) retained for SIG(0) use only.
-
-Changes between 01 and 02:
-
- SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
-
- Domain names embedded in NSECs and RRSIGs are not compressible and
- are not downcased. Added unknown-rrs reference (as informative).
-
- Simplified the last paragraph of section 3 (NSEC doesn't always
- signal a negative answer).
-
- Changed the suggested type code assignments.
-
- Added 2119 reference.
-
- Added definitions of "unsecure delegation" and "unsecure referral",
- since they're not clearly defined elsewhere.
-
- Moved 2065 to informative references, not normative.
-
-1. Introduction
-
- The DNSSEC protocol has been through many iterations whose syntax
- and semantics are not completely compatible. This has occurred as
- part of the ordinary process of proposing a protocol, implementing
- it, testing it in the increasingly complex and diverse environment
- of the Internet, and refining the definitions of the initial
- Proposed Standard. In the case of DNSSEC, the process has been
- complicated by DNS's criticality and wide deployment and the need
- to add security while minimizing daily operational complexity.
-
- A weak area for previous DNS specifications has been lack of detail
- in specifying resolver behavior, leaving implementors largely on
- their own to determine many details of resolver function. This,
- combined with the number of iterations the DNSSEC spec has been
- through, has resulted in fielded code with a wide variety of
- behaviors. This variety makes it difficult to predict how a
- protocol change will be handled by all deployed resolvers. The
- risk that a change will cause unacceptable or even catastrophic
- failures makes it difficult to design and deploy a protocol change.
- One strategy for managing that risk is to structure protocol
- changes so that existing resolvers can completely ignore input that
- might confuse them or trigger undesirable failure modes.
-
- This document addresses a specific problem caused by Delegation
- Signer's [DS] introduction of new semantics for the NXT RR that are
- incompatible with the semantics in RFC 2535 [RFC2535]. Answers
- provided by DS-aware servers can trigger an unacceptable failure
- mode in some resolvers that implement RFC 2535, which provides a
- great disincentive to sign zones with DS. The changes defined in
- this document allow for the incremental deployment of DS.
-
-1.1 Terminology
-
- In this document, the term "unsecure delegation" means any
- delegation for which no DS record appears at the parent. An
- "unsecure referral" is an answer from the parent containing an NS
- RRset and a proof that no DS record exists for that name.
-
- 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 The Problem
-
- Delegation Signer introduces new semantics for the NXT RR that are
- incompatible with the semantics in RFC 2535. In RFC 2535, NXT
- records were only required to be returned as part of a
- non-existence proof. With DS, an unsecure referral returns, in
- addition to the NS, a proof of non-existence of a DS RR in the form
- of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
- to interpret a response with both an NS and an NXT in the authority
- section, RCODE=0, and AA=0. Some widely deployed 2535-aware
- resolvers interpret any answer with an NXT as a proof of
- non-existence of the requested record. This results in unsecure
- delegations being invisible to 2535-aware resolvers and violates
- the basic architectural principle that DNSSEC must do no harm --
- the signing of zones must not prevent the resolution of unsecured
- delegations.
-
-2. Possible Solutions
-
- This section presents several solutions that were considered.
- Section 3 describes the one selected.
-
-2.1. Change SIG, KEY, and NXT type codes
-
- To avoid the problem described above, legacy (RFC2535-aware)
- resolvers need to be kept from seeing unsecure referrals that
- include NXT records in the authority section. The simplest way to
- do that is to change the type codes for SIG, KEY, and NXT.
-
- The obvious drawback to this is that new resolvers will not be able
- to validate zones signed with the old RRs. This problem already
- exists, however, because of the changes made by DS, and resolvers
- that understand the old RRs (and have compatibility issues with DS)
- are far more prevalent than 2535-signed zones.
-
-2.2. Change a subset of type codes
-
- The observed problem with unsecure referrals could be addressed by
- changing only the NXT type code or another subset of the type codes
- that includes NXT. This has the virtue of apparent simplicity, but
- it risks introducing new problems or not going far enough. It's
- quite possible that more incompatibilities exist between DS and
- earlier semantics. Legacy resolvers may also be confused by seeing
- records they recognize (SIG and KEY) while being unable to find
- NXTs. Although it may seem unnecessary to fix that which is not
- obviously broken, it's far cleaner to change all of the type codes
- at once. This will leave legacy resolvers and tools completely
- blinded to DNSSEC -- they will see only unknown RRs.
-
-2.3. Replace the DO bit
-
- Another way to keep legacy resolvers from ever seeing DNSSEC
- records with DS semantics is to have authoritative servers only
- send that data to DS-aware resolvers. It's been proposed that
- assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
- called "DA"), and having authoritative servers send DNSSEC data
- only in response to queries with the DA bit set, would accomplish
- this. This bit would presumably supplant the DO bit described in
- RFC 3225.
-
- This solution is sufficient only if all 2535-aware resolvers zero
- out EDNS0 flags that they don't understand. If one passed through
- the DA bit unchanged, it would still see the new semantics, and it
- would probably fail to see unsecure delegations. Since it's
- impractical to know how every DNS implementation handles unknown
- EDNS0 flags, this is not a universal solution. It could, though,
- be considered in addition to changing the RR type codes.
-
-2.4. Increment the EDNS version
-
- Another possible solution is to increment the EDNS version number
- as defined in RFC 2671 [RFC2671], on the assumption that all
- existing implementations will reject higher versions than they
- support, and retain the DO bit as the signal for DNSSEC awareness.
- This approach has not been tested.
-
-2.5. Do nothing
-
- There is a large deployed base of DNS resolvers that understand
- DNSSEC as defined by the standards track RFC 2535 and RFC 2065
- and, due to under specification in those documents, interpret any
- answer with an NXT as a non-existence proof. So long as that is
- the case, zone owners will have a strong incentive to not sign any
- zones that contain unsecure delegations, lest those delegations be
- invisible to such a large installed base. This will dramatically
- slow DNSSEC adoption.
-
- Unfortunately, without signed zones there's no clear incentive for
- operators of resolvers to upgrade their software to support the new
- version of DNSSEC, as defined in [DS]. Historical data suggests
- that resolvers are rarely upgraded, and that old nameserver code
- never dies.
-
- Rather than wait years for resolvers to be upgraded through natural
- processes before signing zones with unsecure delegations,
- addressing this problem with a protocol change will immediately
- remove the disincentive for signing zones and allow widespread
- deployment of DNSSEC.
-
-3. Protocol changes
-
- This document changes the type codes of SIG, KEY, and NXT. This
- approach is the cleanest and safest of those discussed above,
- largely because the behavior of resolvers that receive unknown type
- codes is well understood. This approach has also received the most
- testing.
-
- To avoid operational confusion, it's also necessary to change the
- mnemonics for these RRs. DNSKEY will be the replacement for KEY,
- with the mnemonic indicating that these keys are not for
- application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
- will replace SIG, and NSEC (Next SECure) will replace NXT. These
- new types completely replace the old types, except that SIG(0)
- [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
-
- The new types will have exactly the same syntax and semantics as
- specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
- the following:
-
- 1) Consistent with [RFC3597], domain names embedded in
- RRSIG and NSEC RRs MUST NOT be compressed,
-
- 2) Embedded domain names in RRSIG and NSEC RRs are not downcased
- for purposes of DNSSEC canonical form and ordering nor for
- equality comparison, and
-
- 3) An RRSIG with a type-covered field of zero has undefined
- semantics. The meaning of such a resource record may only be
- defined by IETF Standards Action.
-
- If a resolver receives the old types, it SHOULD treat them as
- unknown RRs and SHOULD NOT assign any special meaning to them or
- give them any special treatment. It MUST NOT use them for DNSSEC
- validations or other DNS operational decision making. For example,
- a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
- validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone,
- they MUST NOT receive special treatment. As an example, if a SIG
- is included in a signed zone, there MUST be an RRSIG for it.
- Authoritative servers may wish to give error messages when loading
- zones containing SIG or NXT records (KEY records may be included
- for SIG(0) or TKEY).
-
- As a clarification to previous documents, some positive responses,
- particularly wildcard proofs and unsecure referrals, will contain
- NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
- negative answers merely because they contain an NSEC.
-
-4. IANA Considerations
-
-4.1 DNS Resource Record Types
-
- This document updates the IANA registry for DNS Resource Record
- Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
- DNSKEY RRs, respectively.
-
- Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
- TKEY [RFC2930] use only.
-
- Type 30 (NXT) should be marked as Obsolete.
-
-4.2 DNS Security Algorithm Numbers
-
- To allow zone signing (DNSSEC) and transaction security mechanisms
- (SIG(0) and TKEY) to use different sets of algorithms, the existing
- "DNS Security Algorithm Numbers" registry is modified to include
- the applicability of each algorithm. Specifically, two new columns
- are added to the registry, showing whether each algorithm may be
- used for zone signing, transaction security mechanisms, or both.
- Only algorithms usable for zone signing may be used in DNSKEY,
- RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG
- may be used in SIG and KEY RRs.
-
- All currently defined algorithms remain usable for transaction
- security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private
- algorithms (types 253 and 254) may be used for zone signing. Note
- that the registry does not contain the requirement level of each
- algorithm, only whether or not an algorithm may be used for the
- given purposes. For example, RSA/MD5, while allowed for
- transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
-
- Additionally, the presentation format algorithm mnemonics from
- RFC2535 Section 7 are added to the registry. This document assigns
- RSA/SHA-1 the mnemonic RSASHA1.
-
- As before, assignment of new algorithms in this registry requires
- IETF Standards Action. Additionally, modification of algorithm
- mnemonics or applicability requires IETF Standards Action.
- Documents defining a new algorithm must address the applicability
- of the algorithm and should assign a presentation mnemonic to the
- algorithm.
-
-4.3 DNSKEY Flags
-
- Like the KEY resource record, DNSKEY contains a 16-bit flags field.
- This document creates a new registry for the DNSKEY flags field.
-
- Initially, this registry only contains an assignment for bit 7 (the
- ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
- Standards Action.
-
-4.4 DNSKEY Protocol Octet
-
- Like the KEY resource record, DNSKEY contains an eight bit protocol
- field. The only defined value for this field is 3 (DNSSEC). No
- other values are allowed, hence no IANA registry is needed for this
- field.
-
-5. Security Considerations
-
- The changes introduced here do not materially affect security.
- The implications of trying to use both new and legacy types
- together are not well understood, and attempts to do so would
- probably lead to unintended and dangerous results.
-
- Changing type codes will leave code paths in legacy resolvers that
- are never exercised. Unexercised code paths are a frequent source
- of security holes, largely because those code paths do not get
- frequent scrutiny.
-
- Doing nothing, as described in section 2.5, will slow DNSSEC
- deployment. While this does not decrease security, it also fails
- to increase it.
-
-6. Normative references
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [DS] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-15.txt, work in
- progress, June 2003.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
- System (DNS)", RFC 2436, March 1999.
-
- [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
- Domain Name System (DNS)", RFC 2539, March 1999.
-
- [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
- Domain Name System (DNS)", RFC 3110, May 2001.
-
-7. Informative References
-
- [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
- Extensions", RFC 2065, January 1997.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
- [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
- "Domain Name System (DNS) IANA Considerations", BCP 42,
- RFC 2929, September 2000.
-
- [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
- Resource Record (RR)", RFC 3445, December 2002.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
- Record (RR) Types", RFC 3597, September 2003.
-
-8. Acknowledgments
-
- The changes introduced here and the analysis of alternatives had
- many contributors. With apologies to anyone overlooked, those
- include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
- Lewis, Bill Manning, and Suzanne Woolf.
-
- Thanks to Jakob Schlyter and Mark Andrews for identifying the
- incompatibility described in section 1.2.
-
- In addition to the above, the author would like to thank Scott
- Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
- comments.
-
-9. Author's Address
-
- Samuel Weiler
- SPARTA, Inc.
- 7075 Samuel Morse Drive
- Columbia, MD 21046
- USA
- weiler@tislabs.com
-
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
deleted file mode 100644
index 3a800f98880d3..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-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
deleted file mode 100644
index ee03583a1306d..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-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-intro-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
deleted file mode 100644
index 0783e7b26e146..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
+++ /dev/null
@@ -1,1457 +0,0 @@
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: January 13, 2005 R. Austein
- ISC
- M. Larson
- VeriSign
- D. Massey
- USC/ISI
- S. Rose
- NIST
- July 15, 2004
-
-
- DNS Security Introduction and Requirements
- draft-ietf-dnsext-dnssec-intro-11
-
-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 January 13, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- The Domain Name System Security Extensions (DNSSEC) add data origin
- authentication and data integrity to the Domain Name System. This
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 1]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
- 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
- group of documents that collectively describe DNSSEC.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
- 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8
- 3.1 Data Origin Authentication and Data Integrity . . . . . . 8
- 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9
- 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11
- 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12
- 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14
- 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15
- 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16
- 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16
- 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16
- 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17
- 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18
- 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
- 12. Security Considerations . . . . . . . . . . . . . . . . . . 20
- 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
- 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
- 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
- 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
- Intellectual Property and Copyright Statements . . . . . . . . 26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 2]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-1. Introduction
-
- This document introduces the Domain Name System Security Extensions
- (DNSSEC). This document and its two companion documents
- ([I-D.ietf-dnsext-dnssec-records] and
- [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
- security extensions defined in RFC 2535 [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. Section 3 and Section 4 describe
- the capabilities and limitations of the security extensions in
- greater detail. Section 5 discusses the scope of the document set.
- Section 6, Section 7, Section 8, and Section 9 discuss the effect
- that these security extensions will have on resolvers, stub
- resolvers, zones and name servers.
-
- This document and its two companions update and obsolete RFCs 2535
- [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
- [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
- [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but
- does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
- [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
- of 3226 [RFC3226] (dealing with DNSSEC).
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 3]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-2. Definitions of Important DNSSEC Terms
-
- This section defines a number of terms used in this document set.
- Since 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, then come back to
- this section.
-
- Authentication Chain: An alternating sequence of DNSKEY RRsets and 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." as well as 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 which 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.
-
- 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).
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 4]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
- 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
- [I-D.ietf-dnsext-dnssec-records]). 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 which will sign other zone data. Local
- policy may require the zone signing key to 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.
-
- Non-Validating Security-Aware Stub Resolver: A security-aware stub
- resolver which 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 which sends DNS queries, receives DNS
- responses, and is capable of establishing an appropriately secured
- channel to a security-aware recursive name server which 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 which
- 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.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 5]
-
-
- Security-Aware Recursive Name Server: An entity which acts in both
- the security-aware name server and security-aware resolver roles.
- A more cumbersome equivalent phrase would be "a security-aware
- name server which offers recursive service".
-
- Security-Aware Resolver: An entity acting in the role of a resolver
- (defined in section 2.4 of [RFC1034]) which understands the DNS
- security extensions defined in this document set. In particular,
- a security-aware resolver is an entity which 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]) which 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.
-
- Security-Oblivious <anything>: An <anything> that is not
- "security-aware".
-
- Signed Zone: A zone whose RRsets are signed and which contains
- properly constructed DNSKEY, RRSIG, 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 need 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 which 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.
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 6]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
- Validating Stub Resolver: A less tedious term for a validating
- security-aware stub resolver.
-
- 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. Expires January 13, 2005 [Page 7]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-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 (RRSIG, DNSKEY, DS and NSEC) and two
- new message header bits (CD and 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 DO 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 [I-D.ietf-dnsext-dns-threats].
-
-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 do so. To discover a public key reliably
- via DNS resolution, the target key itself needs to be signed by
- either a configured authentication key or another key that has been
- 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,
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 8]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
- 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
- key 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 resolver has been configured
- with the hash of a key rather than the key itself, the resolver may
- need 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 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, or 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.
-
-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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 9]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
- 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
- via 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, as well
- as listing the types of RRsets present at existing names. Each NSEC
- record is signed and authenticated using the mechanisms described in
- Section 3.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 10]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-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
- [RFC3007]. Message authentication schemes described in [RFC2845] and
- [RFC2931] address security operations that pertain to these
- transactions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 11]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-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 these 4 states:
-
- Secure: The validating resolver has a trust anchor, a chain of trust
- and is able to verify all the signatures in the response.
-
- 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. That indicates that subsequent
- branches in the tree are provably insecure. A validating resolver
- may have local policy to mark parts of the domain space as
- insecure.
-
- Bogus: The validating resolver has a trust anchor and there is a
- secure delegation which is indicating that subsidiary data will be
- signed, but the response fails to validate due to one or more
- reasons: missing signatures, expired signatures, signatures with
- unsupported algorithms, data missing which the relevant NSEC RR
- says should be present, and so forth.
-
- Indeterminate: There is no trust anchor which 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
- [I-D.ietf-dnsext-dnssec-protocol]).
-
- 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 [I-D.ietf-dnsext-dnssec-protocol]).
-
- 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.
-
- 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 12]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 13]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-6. Resolver Considerations
-
- A security-aware resolver needs 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
- 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 device which acts as a proxy for DNS, and if the recursive name
- server or proxy 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 device that includes a DNS proxy which is not
- security-aware, the security-aware resolver may find it difficult or
- impossible to obtain or validate signed DNS data.
-
- 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, but should also allow for the possibility that the
- security-aware resolver's own clock is wrong. Thus, a security-aware
- resolver which is part of a security-aware recursive name server will
- need to pay careful attention to the DNSSEC "checking disabled" (CD)
- bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid
- blocking valid signatures from getting through to other
- security-aware resolvers which are clients of this recursive name
- server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
- recursive server handles queries with the CD bit set.
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 14]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-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 which 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
- 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 full security-aware resolver.
-
- Even a security-oblivious stub resolver may get some 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 real choice but to
- place itself at the mercy of the recursive name servers that it uses,
- since 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) or
- TSIG would suffice, as would appropriate use of IPsec, and 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 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 which 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 a trust relationship
- between the zone administrator and the stub resolver itself.
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 15]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-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, which establish a validity period for the
- signatures and the zone data the signatures cover.
-
-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 or not the resolver is security-aware.
-
- The inception and expiration fields in the RRSIG RR
- [I-D.ietf-dnsext-dnssec-records], 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 which 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 in turn will 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 transfers operations.
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 16]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-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 which have signaled their willingness to receive such
- records via use of the DO bit in the EDNS header, subject to message
- size limitations. Since 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.
-
- 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
- updated, so the private key corresponding to the zone signing key
- will have to be kept online. This is an example of a situation where
- the ability to separate the zone's DNSKEY RRset into zone signing
- key(s) and key signing key(s) may be useful, since 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).
-
- DNSSEC, by itself, is not enough to protect the integrity of an
- entire zone during zone transfer operations, since 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).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 17]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-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
- which form the core of the DNS security extensions:
- 1. DNS Security Introduction and Requirements (this document)
- 2. Resource Records for DNS Security Extensions
- [I-D.ietf-dnsext-dnssec-records]
- 3. Protocol Modifications for the DNS Security Extensions
- [I-D.ietf-dnsext-dnssec-protocol]
-
- 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.
-
- The "Transaction Authentication Protocol" document set refers to the
- group of documents that deal with DNS message authentication,
- including secret key establishment and verification. While not
- 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 the use of DNS in the storage and
- distribution of certificates [RFC2538].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 18]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-11. IANA Considerations
-
- This overview document introduces no new IANA considerations. Please
- see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
- IANA considerations introduced by DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 19]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-12. Security Considerations
-
- This document introduces the 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 document discusses the capabilities and
- 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 which the resolver is only able to obtain through a
- recursive name server which 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, 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 which perform these checks on its behalf and also to
- attacks on its communication with those security-aware recursive name
- 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, since 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 20]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
- consume resources in a security-aware name server which 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.
-
- DNSSEC does not provide confidentiality, due to a deliberate design
- choice.
-
- 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. While not an attack on the DNS
- itself, this 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 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 must be used to protect zone transfer
- operations.
-
- Please see [I-D.ietf-dnsext-dnssec-records] and
- [I-D.ietf-dnsext-dnssec-protocol] for additional security
- considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 21]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-13. Acknowledgements
-
- This document was created from the input and ideas of the members of
- the DNS Extensions Working Group. While explicitly listing everyone
- who has contributed during the decade during which DNSSEC has been
- under development would be an impossible task, 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, 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 22]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-14. References
-
-14.1 Normative References
-
- [I-D.ietf-dnsext-dnssec-protocol]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
- progress), May 2004.
-
- [I-D.ietf-dnsext-dnssec-records]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "Resource Records for DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-08 (work in progress),
- May 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.
-
- [RFC2535] Eastlake, 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.
-
- [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.
-
-14.2 Informative References
-
- [I-D.ietf-dnsext-dns-threats]
- Atkins, D. and R. Austein, "Threat Analysis Of The Domain
- Name System", draft-ietf-dnsext-dns-threats-07 (work in
- progress), April 2004.
-
- [I-D.ietf-dnsext-nsec-rdata]
- Schlyter, J., "DNSSEC NSEC RDATA Format",
- draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
- 2004.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 23]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
- [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, D. and O. Gudmundsson, "Storing Certificates in
- the Domain Name System (DNS)", RFC 2538, March 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.
-
- [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.
-
- [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", RFC 3755, April 2004.
-
- [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
- Entry Point Flag", RFC 3757, April 2004.
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 24]
-
-Internet-Draft DNSSEC Introduction and Requirements July 2004
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB 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
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.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. Expires January 13, 2005 [Page 25]
-
-Internet-Draft DNSSEC Introduction and Requirements July 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.
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 26]
-
-
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
deleted file mode 100644
index f7abddc43e4a6..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 17e28e8286e2e..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-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-protocol-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
deleted file mode 100644
index 5728b35c9ba53..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
+++ /dev/null
@@ -1,3193 +0,0 @@
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: January 13, 2005 M. Larson
- VeriSign
- R. Austein
- ISC
- D. Massey
- USC/ISI
- S. Rose
- NIST
- July 15, 2004
-
-
- Protocol Modifications for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-protocol-07
-
-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 January 13, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document is part of a family of documents which describe the DNS
- Security Extensions (DNSSEC). The DNS Security Extensions are a
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 1]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- collection of new resource records and protocol modifications which
- 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 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.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Background and Related Documents . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10
- 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 . . . . . . . . . . . . . . . . . 18
- 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 . . . . . . . . . . . . . . . . . 20
- 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 . . . . . . . . . . . . . . . . 23
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 2]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23
- 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 Using an RRSIG RR . . . . . . . . 27
- 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28
- 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28
- 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30
- 5.3.4 Authenticating A Wildcard Expanded RRset Positive
- Response . . . . . . . . . . . . . . . . . . . . . . . 31
- 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31
- 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32
- 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
- 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
- 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
- A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39
- B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45
- B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45
- B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46
- B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47
- B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48
- B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49
- B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50
- B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51
- B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52
- C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54
- C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54
- C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54
- C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55
- C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55
- C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55
- C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55
- C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56
- C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56
- C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56
- Intellectual Property and Copyright Statements . . . . . . . . 57
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 3]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) are a collection of new resource
- records and protocol modifications which 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 to handle signed zones. Section 4
- describes the behavior of entities which include security-aware
- resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
- to authenticate a response.
-
-1.1 Background and Related Documents
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in [RFC1034] and [RFC1035].
-
- This document is part of a family of documents that define DNSSEC.
- An introduction to DNSSEC and definition of common terms can be found
- in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be
- familiar with this document. A definition of the DNSSEC resource
- records can be found in [I-D.ietf-dnsext-dnssec-records].
-
-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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 4]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-2. Zone Signing
-
- DNSSEC introduces the concept of signed zones. A signed zone
- includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
- the rules specified in Section 2.1, Section 2.2, Section 2.3 and
- Section 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 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.
-
-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 [I-D.ietf-dnsext-dnssec-records]. 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
- [I-D.ietf-dnsext-dnssec-records]).
-
-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 all of 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 5]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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; and
- 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 [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
- multiple RRSIG RRs associated with it.
-
- An RRSIG RR itself MUST NOT be signed, since 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 which 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 [I-D.ietf-dnsext-dnssec-records].
-
- 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 names nodes which 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.
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 6]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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
- 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 is
- only visible during the zone signing process, because NSEC RRsets are
- authoritative data, and are therefore signed, thus any owner name
- which 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 which is present in the child's
- apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
- by the corresponding private key.
-
- 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. Other types
- MUST NOT be present at that name.
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 7]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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
- 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 wishes 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 8]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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.
-
- The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
- 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 [RFC3226].
-
- A security-aware name server which 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. Since 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 which 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. 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
- As long as the response is always consistent for each query to the
- name server.
-
- 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 Section 3.1.6,
- Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
- on the behavior of these bits.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 9]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- A security aware name server which 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;
- 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 the semantics of which 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 need 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 need 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 10]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If
- this happens, the name server MUST NOT set the TC bit solely
- because these RRSIG RRs didn't fit.
-
-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 any
- other information that would be placed in the additional section.
- The name server SHOULD NOT include the DNSKEY RRset unless there is
- enough space in the response message for both the DNSKEY RRset and
- its associated RRSIG RR(s). If there is not enough space to include
- these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
- NOT set the TC bit solely because these RRs didn't fit (see Section
- 3.1.1).
-
-3.1.3 Including NSEC RRs In a Response
-
- When responding to a query that has the DO bit set, a security-aware
- authoritative name server for a signed zone MUST include NSEC RRs in
- each of the following cases:
-
- No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
- but does not contain any RRsets that exactly match <SNAME, SCLASS,
- STYPE>.
-
- Name Error: The zone does not contain any RRsets that match <SNAME,
- SCLASS> either exactly or via wildcard name expansion.
-
- Wildcard Answer: The zone does not contain any RRsets that exactly
- match <SNAME, SCLASS> but does contain an RRset that matches
- <SNAME, SCLASS, STYPE> via wildcard name expansion.
-
- Wildcard No Data: The zone does not contain any RRsets that exactly
- match <SNAME, SCLASS>, does contain one or more RRsets that match
- <SNAME, SCLASS> via wildcard name expansion, but does not contain
- any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
- expansion.
-
- In each of these cases, the name server includes NSEC RRs in the
- response to prove that an exact match for <SNAME, SCLASS, STYPE> was
- not present in the zone and that the response that the name server is
- returning is correct given the data that are in the zone.
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 11]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-3.1.3.1 Including NSEC RRs: No Data Response
-
- If the zone contains RRsets matching <SNAME, SCLASS> but contains no
- RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
- include the NSEC RR for <SNAME, SCLASS> along with its associated
- RRSIG RR(s) in the Authority section of the response (see Section
- 3.1.1). If space does not permit inclusion of the NSEC RR or its
- associated RRSIG RR(s), the name server MUST set the TC bit (see
- Section 3.1.1).
-
- Since the search name exists, wildcard name expansion does not apply
- to this query, and a single signed NSEC RR suffices to prove the
- requested RR type does not exist.
-
-3.1.3.2 Including NSEC RRs: Name Error Response
-
- If the zone does not contain any RRsets matching <SNAME, SCLASS>
- either exactly or via wildcard name expansion, then the name server
- MUST include the following NSEC RRs in the Authority section, along
- with their associated RRSIG RRs:
- o An NSEC RR proving that there is no exact match for <SNAME,
- SCLASS>; and
- o An NSEC RR proving that the zone contains no RRsets that would
- match <SNAME, SCLASS> via wildcard name expansion.
-
- In some cases a single NSEC RR may prove both of these points, in
- that case 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
- which is not the owner name for any RRset but which 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 which exactly match <SNAME,
- SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
- STYPE> via wildcard name expansion, the name server MUST include the
- wildcard-expanded answer and the corresponding wildcard-expanded
- RRSIG RRs in the Answer section, and MUST include in the Authority
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 12]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- section an NSEC RR and associated RRSIG RR(s) proving that the zone
- does not contain a closer match for <SNAME, SCLASS>. If space does
- not permit inclusion of the answer, NSEC and RRSIG RRs, the name
- server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.4 Including NSEC RRs: Wildcard No Data Response
-
- This case is a combination of the previous cases. The zone does not
- contain an exact match for <SNAME, SCLASS>, and while the zone does
- contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
- none of those RRsets match 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 which matched <SNAME, SCLASS> via wildcard
- expansion; and
- o An NSEC RR proving that there are no RRsets in the zone which
- would have been a closer match for <SNAME, SCLASS>.
-
- In some cases a single NSEC RR may prove both of these points, in
- which case 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 needs to locate an NSEC RR
- which 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 which would have held
- the nonexistent RRsets matching SNAME. The algorithm below is
- written for clarity, not efficiency.
-
- To find the NSEC which proves that no RRsets matching name N exist in
- the zone Z which would have held them, construct sequence S
- consisting of the owner names of every RRset in Z, sorted into
- canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate
- names. Find the name M which 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 which proves that no RRsets exist with owner name N.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 13]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- The algorithm for finding the NSEC RR which 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 which
- proves that RRsets with any other owner name do not exist: the part
- that's missing is how to determine the name of the nonexistent
- 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 which 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. The name server MUST
- place the NS RRset before the DS RRset and its associated RRSIG
- RR(s).
-
- If no DS RRset is present at the delegation point, the name server
- MUST return both the NSEC RR which 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, since 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.
-
- 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).
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 14]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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; and
- o the name server is authoritative for the child zone; and
- o the name server is not authoritative for the parent zone; and
- 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 of 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 meets 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 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 15]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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, since the NSEC RR in the child zone's apex will always
- indicate the presence of the child zone's SOA RR while 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 zone transfers of
- the parent zone, while 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, while 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, since 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 while
- 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.
-
- 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, but 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 16]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- NOT do so unless this behavior has been configured explicitly.
-
- A security-aware name server which 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 [I-D.ietf-dnsext-dnssec-intro], a security-aware
- recursive name server is an entity which 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 which
- implements the security-aware name server role and the code which
- implements the security-aware resolver role, respectively.
-
- The resolver side follows the usual rules for caching and negative
- caching which 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 sense of the CD bit to the resolver side along with the rest
- of an initiating query, so that the resolver side will know whether
- or not 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 17]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 which matches an entry in the
- resolver side's BAD cache, the name server side's response depends on
- the sense 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
- which are capable of performing their own signature verification
- checks while protecting clients which 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 which may not apply equally to the recursive name
- server and the client which 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 which the recursive name
- server does not share. In such cases, "protecting" a client which 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 backwards compatibility, a recursive name server MAY set
- the AD bit when a response includes unsigned CNAME RRs if those CNAME
- RRs demonstrably could have been synthesized from an authentic DNAME
- RR which 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.
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 18]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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
- advertise the supported message size using the "sender's UDP payload
- size" field in the EDNS OPT pseudo-RR. A security-aware resolver
- MUST handle fragmented UDP packets correctly regardless of whether
- any such fragmented packets were received via IPv4 or IPv6. Please
- see [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 which instructed the security-aware
- resolver not to perform validation for this query; or
- o Validation for this query has been disabled by local policy.
-
- 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.
-
- When attempting to retrieve missing NSEC RRs which 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 19]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 of 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 or not 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.
-
- Bogus: An RRset for which the resolver believes that it ought to be
- able to establish a chain of trust but is unable to do so, either
- due to signatures that for some reason fail to validate or due to
- missing data which 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 or not the RRset should be signed, because 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 20]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 covers key material that is updated in a
- secure manner. This secure manner could be through physical media, a
- key exchange protocol, or some other out of band means.
-
-4.5 Response Caching
-
- A security-aware resolver SHOULD cache each response as a single
- atomic entry containing the entire answer, including the named RRset
- and any associated DNSSEC RRs. The resolver SHOULD discard the
- entire atomic entry when any of the RRs contained in it expire. In
- most cases the appropriate cache index for the atomic entry will be
- the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
- form described in Section 3.1.3.2 the appropriate cache index will be
- the double <QNAME,QCLASS>.
-
- The reason for these recommendations is that, between the initial
- query and the expiration of the data from the cache, the
- authoritative data might have been changed (for example, via dynamic
- update).
-
- 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 which follow this
- recommendation will have a more consistent view of the namespace.
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 21]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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 which blindly copy
- header bits which 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 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.
- 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 which implement a BAD cache MUST take steps to prevent the
- cache from being useful as a denial-of-service attack amplifier. In
- particular:
- o Since RRsets which fail to validate do not have trustworthy TTLs,
- the implementation MUST assign a TTL. This TTL SHOULD be small,
- in order to mitigate the effect of caching the results of an
- attack.
- o In order to prevent caching of a transient validation failure
- (which might be the result of an attack), resolvers SHOULD track
- queries that result in validation failures, and SHOULD only answer
- from the BAD cache after the number of times that responses to
- queries for that particular <QNAME, QTYPE, QCLASS> have failed to
- validate exceeds a threshold value.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 22]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 which 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.
-
-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 which
- invoked it but is not required to do so. A non-validating stub
- resolver that wishes to do this will need to set the DO bit in
- receive DNSSEC RRs from the recursive name server.
-
- A validating security-aware stub resolver MUST set the DO bit, since
- 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 requested by the application layer,
- since 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,
- since 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 which would be acceptable to the
- stub resolver's local policy.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 23]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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
- which 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, so as a practical matter there
- may be little practical value to 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, since, by definition, the
- stub resolver performs its own signature validation regardless of the
- setting of the AD bit.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 24]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-5. Authenticating DNS Responses
-
- In order 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 anchors 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 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 using an initial key,
- the resolver MUST:
- 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
- RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
- (DNSKEY RDATA bit 7) set.
- 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 using an
- initial DNSKEY RR, delegations from that zone can be authenticated
- 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.
-
- Once the resolver has authenticated a zone's apex DNSKEY RRset,
- 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. 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
- that lacks the appropriate DNSSEC RRs, whether due to configuration
- issues such as an upstream security-oblivious recursive name server
- that accidentally interferes with DNSSEC RRs or due to a deliberate
- attack in which an adversary forges a response, strips DNSSEC RRs
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 25]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 [I-D.ietf-dnsext-dnssec-intro]) 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 the validator to 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. A strong cryptographic digest algorithm
- ensures that an adversary can not easily 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);
- 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 hashed using the digest algorithm specified in the
- DS RR's Digest Type field, results in a digest value that matches
- the Digest field of the DS RR; and
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 26]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 can not 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, since 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.
-
- 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 Using 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 27]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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. Section 5.3.1, Section
- 5.3.2, and Section 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.
-
- 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, 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 28]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- Section 5.3.1, the validator needs 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
-
- 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 29]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- RRset.
-
- The canonical forms for names and RRsets are defined in
- [I-D.ietf-dnsext-dnssec-records].
-
- 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
- RRset 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 since only the child NSEC RRs will
- specify 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, and 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 also 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.
-
-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).
- [I-D.ietf-dnsext-dnssec-records] 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 by trying each matching public key until
- the validator either succeeds in validating the signature or runs out
- of keys to try.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 30]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 needs to test these RRSIG
- RRs, and determines 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.
-
-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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 31]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 [I-D.ietf-dnsext-dnssec-records], 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 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
- 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 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. See also Section
- 4.7 on caching responses that do not validate.
-
-5.6 Authentication Example
-
- Appendix C shows an example the authentication process.
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 32]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-6. IANA Considerations
-
- [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
- considerations introduced by DNSSEC. The 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 33]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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 [I-D.ietf-dnsext-dnssec-intro] for terminology and general
- security considerations related to DNSSEC; see
- [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
- DNSSEC resource record types.
-
- 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 which 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 Section 3.2.2 and Section 4.9 for further discussion.
-
- The protocol described in this document attempts to extend the
- benefits of DNSSEC to security-oblivious stub resolvers. However,
- since 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 need to pay close attention to the
- behavior of the applications which 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 34]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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. While explicitly listing everyone who has
- contributed during the decade during which DNSSEC has been under
- development would be an impossible task,
- [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
- participants who were kind enough to comment on these documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 35]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-9. References
-
-9.1 Normative References
-
- [I-D.ietf-dnsext-dnssec-intro]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
- 2004.
-
- [I-D.ietf-dnsext-dnssec-records]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "Resource Records for DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-08 (work in progress),
- May 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.
-
- [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.
-
- [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.
-
-9.2 Informative References
-
- [I-D.ietf-dnsext-nsec-rdata]
- Schlyter, J., "DNSSEC NSEC RDATA Format",
- draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 36]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 2004.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [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.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Rob Austein
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- EMail: sra@isc.org
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 37]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.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. Expires January 13, 2005 [Page 38]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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. Expires January 13, 2005 [Page 39]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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. Expires January 13, 2005 [Page 40]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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. Expires January 13, 2005 [Page 41]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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. Expires January 13, 2005 [Page 42]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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. Expires January 13, 2005 [Page 43]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 which 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 44]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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
- 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 45]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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= )
-
-
-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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 46]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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)
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 47]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- ;; 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.
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 48]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- ;; 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 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 49]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- ;; 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= )
-
- ;; 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 which 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 50]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- 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 (
- 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
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 51]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- ;; 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
- 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 which was mistakenly sent
- to a name server for the child zone.
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 52]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- ;; 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
- FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
- Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
- SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
- jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
- ;; Additional
- ;; (empty)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 53]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
-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 section Appendix B.1 returned an MX RRset for
- "x.w.example.com". The corresponding RRSIG indicates 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 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 the logical
- order is presented for clarity and an implementation may choose to
- construct the authentication as referrals are received or may choose
- 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 an configured DNSKEY RR for the
- root zone (or a configured DS RR for the root zone). The resolver
- checks this configured DNSKEY RR is present in the root DNSKEY RRset
- (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this
- DNSKEY RR has signed the root DNSKEY RRset and 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 the resolver may need 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 54]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- matching "example" DNSKEY is found, the resolver checks this DNSKEY
- RR has signed the "example" DNSKEY RRset and the signature lifetime
- is valid. If all 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 authenticated 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 validates the signature as described
- above.
-
-C.2 Name Error
-
- The query in section Appendix B.2 returned NSEC RRs that prove 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 section Appendix B.3 returned an NSEC RR that proves 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 section 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 this DNSKEY
- RR has signed the "a.example" DNSKEY RRset and 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 section Appendix B.5 returned a referral to an unsigned
- "b.example." zone. The NSEC proves that no authentication leads from
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 55]
-
-Internet-Draft DNSSEC Protocol Modifications July 2004
-
-
- "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 section Appendix B.6 returned an answer that was
- produced as a result of wildcard expansion. The RRset expanded as
- the similar to The corresponding RRSIG indicates the MX RRset was
- signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
- 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 2 indicates the answer the
- result of wildcard expansion since 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 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 section Appendix B.7 returned NSEC RRs that prove 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 section 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 the answer is
- from the child . Queries for the "example" DS RRset should be sent
- to the parent servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 56]
-
-Internet-Draft DNSSEC Protocol Modifications July 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.
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 57]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
deleted file mode 100644
index 79a17284357cf..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
+++ /dev/null
@@ -1,1849 +0,0 @@
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: January 13, 2005 R. Austein
- ISC
- M. Larson
- VeriSign
- D. Massey
- USC/ISI
- S. Rose
- NIST
- July 15, 2004
-
-
- Resource Records for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-records-09
-
-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 January 13, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document is part of a family of documents that describes the DNS
- Security Extensions (DNSSEC). The DNS Security Extensions are a
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 1]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Background and Related Documents . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
- 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5
- 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5
- 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5
- 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6
- 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6
- 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6
- 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6
- 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6
- 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7
- 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8
- 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8
- 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9
- 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9
- 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9
- 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10
- 3.1.5 Signature Expiration and Inception Fields . . . . . . 10
- 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10
- 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11
- 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11
- 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12
- 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12
- 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14
- 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14
- 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14
- 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15
- 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 16
- 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 16
- 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 16
- 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18
- 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18
- 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19
- 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19
- 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 2]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19
- 5.2 Processing of DS RRs When Validating Responses . . . . . . 19
- 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20
- 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 20
- 6. Canonical Form and Order of Resource Records . . . . . . . . . 21
- 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21
- 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 21
- 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 22
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26
- 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
- A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29
- A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29
- A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29
- A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30
- B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31
- B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32
- Intellectual Property and Copyright Statements . . . . . . . . 33
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 3]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) introduce four new DNS resource
- record types: DNSKEY, RRSIG, NSEC, and 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
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in [RFC1034], [RFC1035] and subsequent RFCs that update
- them: [RFC2136], [RFC2181] and [RFC2308].
-
- This document is part of a family of documents that define the DNS
- security extensions. The DNS security extensions (DNSSEC) are a
- collection of resource records and DNS protocol modifications that
- add source authentication and data integrity to the Domain Name
- System (DNS). An introduction to DNSSEC and definitions of common
- terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is
- assumed to be familiar with this document. A description of DNS
- protocol modifications can be found in
- [I-D.ietf-dnsext-dnssec-protocol].
-
- This document defines the DNSSEC resource records.
-
-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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 4]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-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 [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
- authoritative RRsets using a private key and stores the corresponding
- public key in a DNSKEY RR. A resolver can then use the public key to
- authenticate signatures covering the RRsets in the zone.
-
- 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. Expires January 13, 2005 [Page 5]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- intended to be to 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 a DNSKEY RR with
- the SEP bit set would also need the Zone Key flag set in order to
- legally be able to generate signatures. 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 reception.
-
-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 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 are 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,
- or 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. Expires January 13, 2005 [Page 6]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 7]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-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 [I-D.ietf-dnsext-dnssec-protocol]. 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] that 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.
-
- 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 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.
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 8]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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.
-
-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 if 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 need to reconstruct the original owner name in order
- to validate the signature. [I-D.ietf-dnsext-dnssec-protocol]
- describes how to use the Labels field to reconstruct the original
- owner name.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 9]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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 generating or verifying the signature.
-
-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.
- [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
- TTL field value to reconstruct the original TTL.
-
-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.
-
- Signature Expiration and Inception field values are in POSIX.1 time
- format: 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 which can be expressed by this format without
- wrapping is approximately 136 years. An RRSIG RR can have an
- Expiration field value which 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.
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 10]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-3.1.7 The Signer's Name Field
-
- The Signer's Name field value identifies the owner name of the DNSKEY
- RR which 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:
-
- 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 11]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- canonical form; and
-
- The RRset MUST be sorted in canonical order.
-
- See Section 6.2 and Section 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 a 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.
-
- 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 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 hours notation (00-23);
- mm is the minute (00-59); and
- SS is the second (00-59).
-
- 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:
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 12]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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
- 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
- indicate 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 this signature can be
- authenticated using an example.com zone DNSKEY RR whose algorithm is
- 5 and key tag is 2642.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 13]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-4. The NSEC Resource Record
-
- The NSEC resource record lists two separate things: the next owner
- name (in the canonical ordering of the zone) which contains
- authoritative data or a delegation point NS RRset, and the set of RR
- types present at the NSEC RR's owner name. The complete set of NSEC
- RRs in a zone both indicate 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 [I-D.ietf-dnsext-dnssec-protocol].
-
- 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] that
- 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 a CNAME resource record in a signed zone.
-
- See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone
- signer determines precisely which NSEC RRs it needs 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].
-
-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) which 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 14]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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 not authoritative for the given zone (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 which 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.
-
- 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,
- 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, since they do not
- 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
- NSEC RR's owner name. Trailing zero octets not specified MUST be
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 15]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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 purposes of generating NSEC RRs. Wildcard owner names
- appear in the Next Domain Name field without any wildcard expansion.
- [I-D.ietf-dnsext-dnssec-protocol] 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
- as described in [RFC3597] (section 5) MUST be used.
-
-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 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:
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 16]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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 could
- be used to prove there is no AAAA record associated with
- alfa.example.com. Authenticated denial of existence is discussed in
- [I-D.ietf-dnsext-dnssec-protocol].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 17]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-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
- [I-D.ietf-dnsext-dnssec-protocol].
-
- 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
- "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
- [I-D.ietf-dnsext-dnssec-protocol].
-
- 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 one
- octet Algorithm field, a one 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 /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 18]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-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.
-
-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 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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 19]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC
- zone key, the DS RR (and 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.
-
- 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.
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 20]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-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 to construct and verify RRSIG RRs.
-
-6.1 Canonical DNS Name Order
-
- For 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 upper case
- US-ASCII letters are treated as if they were lower case US-ASCII
- letters.
-
- 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
- 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 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;
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 21]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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.
-
-6.3 Canonical RR Ordering Within An RRset
-
- For 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 where 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, the implementation 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), the implementation MUST remove all but
- one of the duplicate RR(s) for purposes of calculating the canonical
- form of the RRset.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 22]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-7. IANA Considerations
-
- This document introduces no new IANA considerations, because 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 which are (or once were) related to DNSSEC.
-
- Please refer to [I-D.ietf-dnsext-dnssec-protocol] 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 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. See Appendix A
- for a full listing of the DNS Security Algorithm Numbers entries
- at the time of writing and their status of use in DNSSEC.
-
- [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] re-assigned 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
- 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 an assignment for bit 7 (the ZONE bit)
- and a reservation for bit 15 for the Secure Entry Point flag (SEP
- bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by
- IETF Standards Action.
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 23]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-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 [I-D.ietf-dnsext-dnssec-intro]
- and [I-D.ietf-dnsext-dnssec-protocol] for additional security
- considerations related to the use of these records.
-
- The DS record points to a DNSKEY RR 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 such 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 which 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 which uses only the key tag to select a DNSKEY RR
- might select the wrong public key in some circumstances.
-
- 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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 24]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-9. Acknowledgments
-
- 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. While explicitly listing everyone who has
- contributed during the decade during which DNSSEC has been under
- development would be an impossible task,
- [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
- participants who were kind enough to comment on these documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 25]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-10. References
-
-10.1 Normative References
-
- [I-D.ietf-dnsext-dnssec-intro]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
- 2004.
-
- [I-D.ietf-dnsext-dnssec-protocol]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
- progress), May 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.
-
- [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.
-
- [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.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
- Name System (DNS)", RFC 3110, May 2001.
-
- [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 26]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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", RFC 3755, April 2004.
-
- [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
- Entry Point Flag", RFC 3757, April 2004.
-
-10.2 Informative References
-
- [I-D.ietf-dnsext-nsec-rdata]
- Schlyter, J., "DNSSEC NSEC RDATA Format",
- draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
- 2004.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 27]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.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. Expires January 13, 2005 [Page 28]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-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.
-
- 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 used 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 RFC 2537 NOT RECOMMENDED
- 2 Diffie-Hellman [DH] n RFC 2539 -
- 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL
- 4 Elliptic Curve [ECC] TBA -
- 5 RSA/SHA-1 [RSASHA1] y RFC 3110 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.
-
-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
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 29]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- 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 -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 30]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
-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.
-
- 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.
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 31]
-
-Internet-Draft DNSSEC Resource Records July 2004
-
-
- /*
- * 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;
- }
-
-
-B.1 Key Tag for Algorithm 1 (RSA/MD5)
-
- The key tag for algorithm 1 (RSA/MD5) is defined differently than 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. Expires January 13, 2005 [Page 32]
-
-Internet-Draft DNSSEC Resource Records July 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.
-
-
-
-
-Arends, et al. Expires January 13, 2005 [Page 33]
-
-
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
deleted file mode 100644
index dd8cbf0682e04..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
+++ /dev/null
@@ -1,839 +0,0 @@
-
-DNS Extensions Working Group R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 25, 2005 P. Koch
- DENIC eG
- J. Schlyter
- NIC-SE
- February 21, 2005
-
-
- Evaluating DNSSEC Transition Mechanisms
- draft-ietf-dnsext-dnssec-trans-02.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 25, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document collects and summarizes different proposals for
- alternative and additional strategies for authenticated denial in DNS
- responses, evaluates these proposals and gives a recommendation for a
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 1]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- way forward.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
- 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
- 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
- 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5
- 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
- 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
- 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
- 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
- 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
- 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9
- 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
- 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10
- 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11
- 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
- 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
- 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
- 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
- 5.2 Informative References . . . . . . . . . . . . . . . . . . 13
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 2]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-1. Introduction
-
- This report shall document the process of dealing with the NSEC
- walking problem late in the Last Call for
- [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
- I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion
- that took place in the DNSEXT WG during the first half of June 2004
- as well as some additional ideas that came up subsequently.
-
- This is an edited excerpt of the chairs' mail to the WG:
- The working group consents on not including NSEC-alt in the
- DNSSEC-bis documents. The working group considers to take up
- "prevention of zone enumeration" as a work item.
- There may be multiple mechanisms to allow for co-existence with
- DNSSEC-bis. The chairs allow the working group a little over a
- week (up to June 12, 2004) to come to consensus on a possible
- modification to the document to enable gentle rollover. If that
- consensus cannot be reached the DNSSEC-bis documents will go out
- as-is.
-
- To ease the process of getting consensus, a summary of the proposed
- solutions and analysis of the pros and cons were written during the
- weekend.
-
- This summary includes:
-
- An inventory of the proposed mechanisms to make a transition to
- future work on authenticated denial of existence.
- List the known Pros and Cons, possibly provide new arguments, and
- possible security considerations of these mechanisms.
- Provide a recommendation on a way forward that is least disruptive
- to the DNSSEC-bis specifications as they stand and keep an open
- path to other methods for authenticated denial of existence.
-
- The descriptions of the proposals in this document are coarse and do
- not cover every detail necessary for implementation. In any case,
- documentation and further study is needed before implementaion and/or
- deployment, including those which seem to be solely operational in
- nature.
-
-2. Transition Mechanisms
-
- In the light of recent discussions and past proposals, we have found
- several ways to allow for transition to future expansion of
- authenticated denial. We tried to illuminate the paths and pitfalls
- in these ways forward. Some proposals lead to a versioning of
- DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
- proposals are 'clean' but may cause delay, while again others may be
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 3]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- plain hacks.
-
- Some paths do not introduce versioning, and might require the current
- DNSSEC-bis documents to be fully updated to allow for extensions to
- authenticated denial mechanisms. Other paths introduce versioning
- and do not (or minimally) require DNSSEC-bis documents to be updated,
- allowing DNSSEC-bis to be deployed, while future versions can be
- drafted independent from or partially depending on DNSSEC-bis.
-
-2.1 Mechanisms With Need of Updating DNSSEC-bis
-
- Mechanisms in this category demand updates to the DNSSEC-bis document
- set.
-
-2.1.1 Dynamic NSEC Synthesis
-
- This proposal assumes that NSEC RRs and the authenticating RRSIG will
- be generated dynamically to just cover the (non existent) query name.
- The owner name is (the) one preceding the name queried for, the Next
- Owner Name Field has the value of the Query Name Field + 1 (first
- successor in canonical ordering). A separate key (the normal ZSK or
- a separate ZSK per authoritative server) would be used for RRSIGs on
- NSEC RRs. This is a defense against enumeration, though it has the
- presumption of online signing.
-
-2.1.1.1 Coexistence and Migration
-
- There is no change in interpretation other then that the next owner
- name might or might not exist.
-
-2.1.1.2 Limitations
-
- This introduces an unbalanced cost between query and response
- generation due to dynamic generation of signatures.
-
-2.1.1.3 Amendments to DNSSEC-bis
-
- The current DNSSEC-bis documents might need to be updated to indicate
- that the next owner name might not be an existing name in the zone.
- This is not a real change to the spec since implementers have been
- warned not to synthesize with previously cached NSEC records. A
- specific bit to identify the dynamic signature generating key might
- be useful as well, to prevent it from being used to fake positive
- data.
-
-2.1.1.4 Cons
-
- Unbalanced cost is a ground for DDoS. Though this protects against
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 4]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- enumeration, it is not really a path for versioning.
-
-2.1.1.5 Pros
-
- Hardly any amendments to DNSSEC-bis.
-
-2.1.2 Add Versioning/Subtyping to Current NSEC
-
- This proposal introduces versioning for the NSEC RR type (a.k.a.
- subtyping) by adding a (one octet) version field to the NSEC RDATA.
- Version number 0 is assigned to the current (DNSSEC-bis) meaning,
- making this an 'Must Be Zero' (MBZ) for the to be published docset.
-
-2.1.2.1 Coexistence and Migration
-
- Since the versioning is done inside the NSEC RR, different versions
- may coexist. However, depending on future methods, that may or may
- not be useful inside a single zone. Resolvers cannot ask for
- specific NSEC versions but may be able to indicate version support by
- means of a to be defined EDNS option bit.
-
-2.1.2.2 Limitations
-
- There are no technical limitations, though it will cause delay to
- allow testing of the (currently unknown) new NSEC interpretation.
-
- Since the versioning and signaling is done inside the NSEC RR, future
- methods will likely be restricted to a single RR type authenticated
- denial (as opposed to e.g. NSEC-alt, which currently proposes three
- RR types).
-
-2.1.2.3 Amendments to DNSSEC-bis
-
- Full Update of the current DNSSEC-bis documents to provide for new
- fields in NSEC, while specifying behavior in case of unknown field
- values.
-
-2.1.2.4 Cons
-
- Though this is a clean and clear path without versioning DNSSEC, it
- takes some time to design, gain consensus, update the current
- dnssec-bis document, test and implement a new authenticated denial
- record.
-
-2.1.2.5 Pros
-
- Does not introduce an iteration to DNSSEC while providing a clear and
- clean migration strategy.
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 5]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.1.3 Type Bit Map NSEC Indicator
-
- Bits in the type-bit-map are reused or allocated to signify the
- interpretation of NSEC.
-
- This proposal assumes that future extensions make use of the existing
- NSEC RDATA syntax, while it may need to change the interpretation of
- the RDATA or introduce an alternative denial mechanism, invoked by
- the specific type-bit-map-bits.
-
-2.1.3.1 Coexistence and migration
-
- Old and new NSEC meaning could coexist, depending how the signaling
- would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR
- types are available as well as those covering meta/query types or
- types to be specifically allocated.
-
-2.1.3.2 Limitations
-
- This mechanism uses an NSEC field that was not designed for that
- purpose. Similar methods were discussed during the Opt-In discussion
- and the Silly-State discussion.
-
-2.1.3.3 Amendments to DNSSEC-bis
-
- The specific type-bit-map-bits must be allocated and they need to be
- specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
- interpretation. Also, behaviour of the resolver and validator must
- be documented in case unknown values are encountered for the MBZ
- field. Currently the protocol document specifies that the validator
- MUST ignore the setting of the NSEC and the RRSIG bits, while other
- bits are only used for the specific purpose of the type-bit-map field
-
-2.1.3.4 Cons
-
- The type-bit-map was not designed for this purpose. It is a
- straightforward hack. Text in protocol section 5.4 was put in
- specially to defend against this usage.
-
-2.1.3.5 Pros
-
- No change needed to the on-the-wire protocol as specified in the
- current docset.
-
-2.1.4 New Apex Type
-
- This introduces a new Apex type (parallel to the zone's SOA)
- indicating the DNSSEC version (or authenticated denial) used in or
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 6]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- for this zone.
-
-2.1.4.1 Coexistence and Migration
-
- Depending on the design of this new RR type multiple denial
- mechanisms may coexist in a zone. Old validators will not understand
- and thus ignore the new type, so interpretation of the new NSEC
- scheme may fail, negative responses may appear 'bogus'.
-
-2.1.4.2 Limitations
-
- A record of this kind is likely to carry additional
- feature/versioning indications unrelated to the current question of
- authenticated denial.
-
-2.1.4.3 Amendments to DNSSEC-bis
-
- The current DNSSEC-bis documents need to be updated to indicate that
- the absence of this type indicates dnssec-bis, and that the (mere)
- presence of this type indicated unknown versions.
-
-2.1.4.4 Cons
-
- The only other 'zone' or 'apex' record is the SOA record. Though
- this proposal is not new, it is yet unknown how it might fulfill
- authenticated denial extensions. This new RR type would only provide
- for a generalized signaling mechanism, not the new authenticated
- denial scheme. Since it is likely to be general in nature, due to
- this generality consensus is not to be reached soon.
-
-2.1.4.5 Pros
-
- This approach would allow for a lot of other per zone information to
- be transported or signaled to both (slave) servers and resolvers.
-
-2.1.5 NSEC White Lies
-
- This proposal disables one part of NSEC (the pointer part) by means
- of a special target (root, apex, owner, ...), leaving intact only the
- ability to authenticate denial of existence of RR sets, not denial of
- existence of domain names (NXDOMAIN). It may be necessary to have
- one working NSEC to prove the absence of a wildcard.
-
-2.1.5.1 Coexistence and Migration
-
- The NSEC target can be specified per RR, so standard NSEC and 'white
- lie' NSEC can coexist in a zone. There is no need for migration
- because no versioning is introduced or intended.
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 7]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.1.5.2 Limitations
-
- This proposal breaks the protocol and is applicable to certain types
- of zones only (no wildcard, no deep names, delegation only). Most of
- the burden is put on the resolver side and operational consequences
- are yet to be studied.
-
-2.1.5.3 Amendments to DNSSEC-bis
-
- The current DNSSEC-bis documents need to be updated to indicate that
- the NXDOMAIN responses may be insecure.
-
-2.1.5.4 Cons
-
- Strictly speaking this breaks the protocol and doesn't fully fulfill
- the requirements for authenticated denial of existence. Security
- implications need to be carefully documented: search path problems
- (forged denial of existence may lead to wrong expansion of non-FQDNs
- [RFC1535]) and replay attacks to deny existence of records.
-
-2.1.5.5 Pros
-
- Hardly any amendments to DNSSEC-bis. Operational "trick" that is
- available anyway.
-
-2.1.6 NSEC Optional via DNSSKEY Flag
-
- A new DNSKEY may be defined to declare NSEC optional per zone.
-
-2.1.6.1 Coexistence and Migration
-
- Current resolvers/validators will not understand the Flag bit and
- will have to treat negative responses as bogus. Otherwise, no
- migration path is needed since NSEC is simply turned off.
-
-2.1.6.2 Limitations
-
- NSEC can only be made completely optional at the cost of being unable
- to prove unsecure delegations (absence of a DS RR [RFC3658]). A next
- to this approach would just disable authenticated denial for
- non-existence of nodes.
-
-2.1.6.3 Amendments to DNSSEC-bis
-
- New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
- be specified in the light of absence of authenticated denial.
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 8]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.1.6.4 Cons
-
- Doesn't fully meet requirements. Operational consequences to be
- studied.
-
-2.1.6.5 Pros
-
- Official version of the "trick" presented in (8). Operational
- problems can be addressed during future work on validators.
-
-2.1.7 New Answer Pseudo RR Type
-
- A new pseudo RR type may be defined that will be dynamically created
- (and signed) by the responding authoritative server. The RR in the
- response will cover the QNAME, QCLASS and QTYPE and will authenticate
- both denial of existence of name (NXDOMAIN) or RRset.
-
-2.1.7.1 Coexistence and Migration
-
- Current resolvers/validators will not understand the pseudo RR and
- will thus not be able to process negative responses so testified. A
- signaling or solicitation method would have to be specified.
-
-2.1.7.2 Limitations
-
- This method can only be used with online keys and online signing
- capacity.
-
-2.1.7.3 Amendments to DNSSEC-bis
-
- Signaling method needs to be defined.
-
-2.1.7.4 Cons
-
- Keys have to be held and processed online with all security
- implications. An additional flag for those keys identifying them as
- online or negative answer only keys should be considered.
-
-2.1.7.5 Pros
-
- Expands DNSSEC authentication to the RCODE.
-
-2.1.8 SIG(0) Based Authenticated Denial
-
-
-2.1.8.1 Coexistence and Migration
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 9]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.1.8.2 Limitations
-
-
-2.1.8.3 Amendments to DNSSEC-bis
-
-
-2.1.8.4 Cons
-
-
-2.1.8.5 Pros
-
-
-2.2 Mechanisms Without Need of Updating DNSSEC-bis
-
-2.2.1 Partial Type-code and Signal Rollover
-
- Carefully crafted type code/signal rollover to define a new
- authenticated denial space that extends/replaces DNSSEC-bis
- authenticated denial space. This particular path is illuminated by
- Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
- posted to <namedroppers@ops.ietf.org> 2004-06-02.
-
-2.2.1.1 Coexistence and Migration
-
- To protect the current resolver for future versions, a new DNSSEC-OK
- bit must be allocated to make clear it does or does not understand
- the future version. Also, a new DS type needs to be allocated to
- allow differentiation between a current signed delegation and a
- 'future' signed delegation. Also, current NSEC needs to be rolled
- into a new authenticated denial type.
-
-2.2.1.2 Limitations
-
- None.
-
-2.2.1.3 Amendments to DNSSEC-bis
-
- None.
-
-2.2.1.4 Cons
-
- It is cumbersome to carefully craft an TCR that 'just fits'. The
- DNSSEC-bis protocol has many 'borderline' cases that needs special
- consideration. It might be easier to do a full TCR, since a few of
- the types and signals need upgrading anyway.
-
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 10]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.2.1.5 Pros
-
- Graceful adoption of future versions of NSEC, while there are no
- amendments to DNSSEC-bis.
-
-2.2.2 A Complete Type-code and Signal Rollover
-
- A new DNSSEC space is defined which can exist independent of current
- DNSSEC-bis space.
-
- This proposal assumes that all current DNSSEC type-codes
- (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
- future versions of DNSSEC. Any future version of DNSSEC has its own
- types to allow for keys, signatures, authenticated denial, etcetera.
-
-2.2.2.1 Coexistence and Migration
-
- Both spaces can co-exist. They can be made completely orthogonal.
-
-2.2.2.2 Limitations
-
- None.
-
-2.2.2.3 Amendments to DNSSEC-bis
-
- None.
-
-2.2.2.4 Cons
-
- With this path we abandon the current DNSSEC-bis. Though it is easy
- to role specific well-known and well-tested parts into the re-write,
- once deployment has started this path is very expensive for
- implementers, registries, registrars and registrants as well as
- resolvers/users. A TCR is not to be expected to occur frequently, so
- while a next generation authenticated denial may be enabled by a TCR,
- it is likely that that TCR will only be agreed upon if it serves a
- whole basket of changes or additions. A quick introduction of
- NSEC-ng should not be expected from this path.
-
-2.2.2.5 Pros
-
- No amendments/changes to current DNSSEC-bis docset needed. It is
- always there as last resort.
-
-2.2.3 Unknown Algorithm in RRSIG
-
- This proposal assumes that future extensions make use of the existing
- NSEC RDATA syntax, while it may need to change the interpretation of
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 11]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- the RDATA or introduce an alternative denial mechanism, invoked by
- the specific unknown signing algorithm. The different interpretation
- would be signaled by use of different signature algorithms in the
- RRSIG records covering the NSEC RRs.
-
- When an entire zone is signed with a single unknown algorithm, it
- will cause implementations that follow current dnssec-bis documents
- to treat individual RRsets as unsigned.
-
-2.2.3.1 Coexistence and migration
-
- Old and new NSEC RDATA interpretation or known and unknown Signatures
- can NOT coexist in a zone since signatures cover complete (NSEC)
- RRSets.
-
-2.2.3.2 Limitations
-
- Validating resolvers agnostic of new interpretation will treat the
- NSEC RRset as "not signed". This affects wildcard and non-existence
- proof, as well as proof for (un)secured delegations. Also, all
- positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
- insecure/bogus to an old validator.
-
- The algorithm version space is split for each future version of
- DNSSEC. Violation of the 'modular components' concept. We use the
- 'validator' to protect the 'resolver' from unknown interpretations.
-
-2.2.3.3 Amendments to DNSSEC-bis
-
- None.
-
-2.2.3.4 Cons
-
- The algorithm field was not designed for this purpose. This is a
- straightforward hack.
-
-2.2.3.5 Pros
-
- No amendments/changes to current DNSSEC-bis docset needed.
-
-3. Recommendation
-
- The authors recommend that the working group commits to and starts
- work on a partial TCR, allowing graceful transition towards a future
- version of NSEC. Meanwhile, to accomodate the need for an
- immediately, temporary, solution against zone-traversal, we recommend
- On-Demand NSEC synthesis.
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 12]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- This approach does not require any mandatory changes to DNSSEC-bis,
- does not violate the protocol and fulfills the requirements. As a
- side effect, it moves the cost of implementation and deployment to
- the users (zone owners) of this mechanism.
-
-4. Acknowledgements
-
- The authors would like to thank Sam Weiler and Mark Andrews for their
- input and constructive comments.
-
-5. References
-
-5.1 Normative References
-
- [I-D.ietf-dnsext-dnssec-intro]
- Arends, R., Austein, R., Massey, D., Larson, M. and S.
- Rose, "DNS Security Introduction and Requirements",
- Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
- 2004.
-
- [I-D.ietf-dnsext-dnssec-protocol]
- Arends, R., "Protocol Modifications for the DNS Security
- Extensions",
- Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
- October 2004.
-
- [I-D.ietf-dnsext-dnssec-records]
- Arends, R., "Resource Records for the DNS Security
- Extensions",
- Internet-Draft draft-ietf-dnsext-dnssec-records-11,
- October 2004.
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
-5.2 Informative References
-
- [RFC1535] Gavron, E., "A Security Problem and Proposed Correction
- With Widely Deployed DNS Software", RFC 1535, October
- 1993.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 13]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- RFC 2535, March 1999.
-
- [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
- June 1999.
-
- [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
- (RR)", RFC 3658, December 2003.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Brouwerijstraat 1
- Enschede 7523 XC
- The Netherlands
-
- Phone: +31 53 4850485
- Email: roy.arends@telin.nl
-
-
- Peter Koch
- DENIC eG
- Wiesenh"uttenplatz 26
- Frankfurt 60329
- Germany
-
- Phone: +49 69 27235 0
- Email: pk@DENIC.DE
-
-
- Jakob Schlyter
- NIC-SE
- Box 5774
- Stockholm SE-114 87
- Sweden
-
- Email: jakob@nic.se
- URI: http://www.nic.se/
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 14]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 15]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
deleted file mode 100644
index 2cdcdb16c920b..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT ECC Keys in the DNS
-Expires: January 2006 July 2005
-
-
-
- Elliptic Curve KEYs in the DNS
- -------- ----- ---- -- --- ---
- <draft-ietf-dnsext-ecc-key-07.txt>
-
- Richard C. Schroeppel
- Donald Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNS mailing list <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for storing elliptic curve cryptographic keys and
- signatures in the Domain Name System is specified.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-
-
-R. Schroeppel, et al [Page 1]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-Acknowledgement
-
- The assistance of Hilarie K. Orman in the production of this document
- is greatfully acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Acknowledgement............................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Elliptic Curve Data in Resource Records.................3
- 3. The Elliptic Curve Equation.............................9
- 4. How do I Compute Q, G, and Y?..........................10
- 5. Elliptic Curve SIG Resource Records....................11
- 6. Performance Considerations.............................13
- 7. Security Considerations................................13
- 8. IANA Considerations....................................13
- Copyright and Disclaimer..................................14
-
- Informational References..................................15
- Normative Refrences.......................................15
-
- Author's Addresses........................................16
- Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 2]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. The DNS has been extended to include digital
- signatures and cryptographic keys as described in [RFC 4033, 4034,
- 4035].
-
- This document describes how to store elliptic curve cryptographic
- (ECC) keys and signatures in the DNS so they can be used for a
- variety of security purposes. Familiarity with ECC cryptography is
- assumed [Menezes].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Elliptic Curve Data in Resource Records
-
- Elliptic curve public keys are stored in the DNS within the RDATA
- portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
- structure shown below.
-
- The research world continues to work on the issue of which is the
- best elliptic curve system, which finite field to use, and how to
- best represent elements in the field. So, representations are
- defined for every type of finite field, and every type of elliptic
- curve. The reader should be aware that there is a unique finite
- field with a particular number of elements, but many possible
- representations of that field and its elements. If two different
- representations of a field are given, they are interconvertible with
- a tedious but practical precomputation, followed by a fast
- computation for each field element to be converted. It is perfectly
- reasonable for an algorithm to work internally with one field
- representation, and convert to and from a different external
- representation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 3]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S M -FMT- A B Z|
- +-+-+-+-+-+-+-+-+
- | LP |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | P (length determined from LP) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LF |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | F (length determined from LF) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEG |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGI |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGJ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | TRDV |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | H (length determined from LH) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LK |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | K (length determined from LK) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LQ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Q (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | A (length determined from LA) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | ALTA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LB |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | B (length determined from LB) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LC |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | C (length determined from LC) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LG |
-
-
-R. Schroeppel, et al [Page 4]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | G (length determined from LG) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LY |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Y (length determined from LY) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- SMFMTABZ is a flags octet as follows:
-
- S = 1 indicates that the remaining 7 bits of the octet selects
- one of 128 predefined choices of finite field, element
- representation, elliptic curve, and signature parameters.
- MFMTABZ are omitted, as are all parameters from LP through G.
- LY and Y are retained.
-
- If S = 0, the remaining parameters are as in the picture and
- described below.
-
- M determines the type of field underlying the elliptic curve.
-
- M = 0 if the field is a GF[2^N] field;
-
- M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
-
- FMT is a three bit field describing the format of the field
- representation.
-
- FMT = 0 for a (mod P) field.
- > 0 for an extension field, either GF[2^D] or GF[P^D].
- The degree D of the extension, and the field polynomial
- must be specified. The field polynomial is always monic
- (leading coefficient 1.)
-
- FMT = 1 The field polynomial is given explicitly; D is implied.
-
- If FMT >=2, the degree D is given explicitly.
-
- = 2 The field polynomial is implicit.
- = 3 The field polynomial is a binomial. P>2.
- = 4 The field polynomial is a trinomial.
- = 5 The field polynomial is the quotient of a trinomial by a
- short polynomial. P=2.
- = 6 The field polynomial is a pentanomial. P=2.
-
- Flags A and B apply to the elliptic curve parameters.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 5]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- A = 1 When P>=5, the curve parameter A is negated. If P=2, then
- A=1 indicates that the A parameter is special. See the
- ALTA parameter below, following A. The combination A=1,
- P=3 is forbidden.
-
- B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
- then B=1 indicates an alternate elliptic curve equation is
- used. When P=2 and B=1, an additional curve parameter C
- is present.
-
- The Z bit SHOULD be set to zero on creation of an RR and MUST be
- ignored when processing an RR (when S=0).
-
- Most of the remaining parameters are present in some formats and
- absent in others. The presence or absence of a parameter is
- determined entirely by the flags. When a parameter occurs, it is in
- the order defined by the picture.
-
- Of the remaining parameters, PFHKQABCGY are variable length. When
- present, each is preceded by a one-octet length field as shown in the
- diagram above. The length field does not include itself. The length
- field may have values from 0 through 110. The parameter length in
- octets is determined by a conditional formula: If LL<=64, the
- parameter length is LL. If LL>64, the parameter length is 16 times
- (LL-60). In some cases, a parameter value of 0 is sensible, and MAY
- be represented by an LL value of 0, with the data field omitted. A
- length value of 0 represents a parameter value of 0, not an absent
- parameter. (The data portion occupies 0 space.) There is no
- requirement that a parameter be represented in the minimum number of
- octets; high-order 0 octets are allowed at the front end. Parameters
- are always right adjusted, in a field of length defined by LL. The
- octet-order is always most-significant first, least-significant last.
- The parameters H and K may have an optional sign bit stored in the
- unused high-order bit of their length fields.
-
- LP defines the length of the prime P. P must be an odd prime. The
- parameters LP,P are present if and only if the flag M=1. If M=0, the
- prime is 2.
-
- LF,F define an explicit field polynomial. This parameter pair is
- present only when FMT = 1. The length of a polynomial coefficient is
- ceiling(log2 P) bits. Coefficients are in the numerical range
- [0,P-1]. The coefficients are packed into fixed-width fields, from
- higher order to lower order. All coefficients must be present,
- including any 0s and also the leading coefficient (which is required
- to be 1). The coefficients are right justified into the octet string
- of length specified by LF, with the low-order "constant" coefficient
- at the right end. As a concession to storage efficiency, the higher
- order bits of the leading coefficient may be elided, discarding high-
- order 0 octets and reducing LF. The degree is calculated by
-
-
-R. Schroeppel, et al [Page 6]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- determining the bit position of the left most 1-bit in the F data
- (counting the right most bit as position 0), and dividing by
- ceiling(log2 P). The division must be exact, with no remainder. In
- this format, all of the other degree and field parameters are
- omitted. The next parameters will be LQ,Q.
-
- If FMT>=2, the degree of the field extension is specified explicitly,
- usually along with other parameters to define the field polynomial.
-
- DEG is a two octet field that defines the degree of the field
- extension. The finite field will have P^DEG elements. DEG is
- present when FMT>=2.
-
- When FMT=2, the field polynomial is specified implicitly. No other
- parameters are required to define the field; the next parameters
- present will be the LQ,Q pair. The implicit field poynomial is the
- lexicographically smallest irreducible (mod P) polynomial of the
- correct degree. The ordering of polynomials is by highest-degree
- coefficients first -- the leading coefficient 1 is most important,
- and the constant term is least important. Coefficients are ordered
- by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
- degree D is X^D (which is not irreducible). The next is X^D+1, which
- is sometimes irreducible, followed by X^D-1, which isn't. Assuming
- odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
- X, X^D + X + 1, X^D + X - 1, etc.
-
- When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
- odd. The polynomial is determined by the degree and the low order
- term K. Of all the field parameters, only the LK,K parameters are
- present. The high-order bit of the LK octet stores on optional sign
- for K; if the sign bit is present, the field polynomial is X^DEG - K.
-
- When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
- K. When P=2, the H and K parameters are implicitly 1, and are
- omitted from the representation. Only DEG and DEGH are present; the
- next parameters are LQ,Q. When P>2, then LH,H and LK,K are
- specified. Either or both of LH, LK may contain a sign bit for its
- parameter.
-
- When FMT=5, then P=2 (only). The field polynomial is the exact
- quotient of a trinomial divided by a small polynomial, the trinomial
- divisor. The small polynomial is right-adjusted in the two octet
- field TRDV. DEG specifies the degree of the field. The degree of
- TRDV is calculated from the position of the high-order 1 bit. The
- trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
- DEGH is 0, the middle term is omitted from the trinomial. The
- quotient must be exact, with no remainder.
-
- When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
- with the degrees of the middle terms given by the three 2-octet
-
-
-R. Schroeppel, et al [Page 7]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
- X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
- > DEGJ > 0.
-
- DEGH, DEGI, DEGJ are two-octet fields that define the degree of
- a term in a field polynomial. DEGH is present when FMT = 4,
- 5, or 6. DEGI and DEGJ are present only when FMT = 6.
-
- TRDV is a two-octet right-adjusted binary polynomial of degree <
- 16. It is present only for FMT=5.
-
- LH and H define the H parameter, present only when FMT=4 and P
- is odd. The high bit of LH is an optional sign bit for H.
-
- LK and K define the K parameter, present when FMT = 3 or 4, and
- P is odd. The high bit of LK is an optional sign bit for K.
-
- The remaining parameters are concerned with the elliptic curve and
- the signature algorithm.
-
- LQ defines the length of the prime Q. Q is a prime > 2^159.
-
- In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
- member of the pair is an element from the finite field defined
- earlier. The length field defines a long octet string. Field
- elements are represented as (mod P) polynomials of degree < DEG, with
- DEG or fewer coefficients. The coefficients are stored from left to
- right, higher degree to lower, with the constant term last. The
- coefficients are represented as integers in the range [0,P-1]. Each
- coefficient is allocated an area of ceiling(log2 P) bits. The field
- representation is right-justified; the "constant term" of the field
- element ends at the right most bit. The coefficients are fitted
- adjacently without regard for octet boundaries. (Example: if P=5,
- three bits are used for each coefficient. If the field is GF[5^75],
- then 225 bits are required for the coefficients, and as many as 29
- octets may be needed in the data area. Fewer octets may be used if
- some high-order coefficients are 0.) If a flag requires a field
- element to be negated, each non-zero coefficient K is replaced with
- P-K. To save space, 0 bits may be removed from the left end of the
- element representation, and the length field reduced appropriately.
- This would normally only happen with A,B,C, because the designer
- chose curve parameters with some high-order 0 coefficients or bits.
-
- If the finite field is simply (mod P), then the field elements are
- simply numbers (mod P), in the usual right-justified notation. If
- the finite field is GF[2^D], the field elements are the usual right-
- justified polynomial basis representation.
-
-
-
-
-
-R. Schroeppel, et al [Page 8]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- LA,A is the first parameter of the elliptic curve equation.
- When P>=5, the flag A = 1 indicates A should be negated (mod
- P). When P=2 (indicated by the flag M=0), the flag A = 1
- indicates that the parameter pair LA,A is replaced by the two
- octet parameter ALTA. In this case, the parameter A in the
- curve equation is x^ALTA, where x is the field generator.
- Parameter A often has the value 0, which may be indicated by
- LA=0 (with no A data field), and sometimes A is 1, which may
- be represented with LA=1 and a data field of 1, or by setting
- the A flag and using an ALTA value of 0.
-
- LB,B is the second parameter of the elliptic curve equation.
- When P>=5, the flag B = 1 indicates B should be negated (mod
- P). When P=2 or 3, the flag B selects an alternate curve
- equation.
-
- LC,C is the third parameter of the elliptic curve equation,
- present only when P=2 (indicated by flag M=0) and flag B=1.
-
- LG,G defines a point on the curve, of order Q. The W-coordinate
- of the curve point is given explicitly; the Z-coordinate is
- implicit.
-
- LY,Y is the user's public signing key, another curve point of
- order Q. The W-coordinate is given explicitly; the Z-
- coordinate is implicit. The LY,Y parameter pair is always
- present.
-
-
-
-3. The Elliptic Curve Equation
-
- (The coordinates of an elliptic curve point are named W,Z instead of
- the more usual X,Y to avoid confusion with the Y parameter of the
- signing key.)
-
- The elliptic curve equation is determined by the flag octet, together
- with information about the prime P. The primes 2 and 3 are special;
- all other primes are treated identically.
-
- If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
- + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
- If A and/or B is negative (i.e., in the range from P/2 to P), and
- P>=5, space may be saved by putting the sign bit(s) in the A and B
- bits of the flags octet, and the magnitude(s) in the parameter
- fields.
-
- If M=1 and P=3, the B flag has a different meaning: it specifies an
- alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
- the right-hand-side is different. When P=3, this equation is more
-
-
-R. Schroeppel, et al [Page 9]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- commonly used.
-
- If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
- A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
- parameter can often be 0 or 1, or be chosen as a single-1-bit value.
- The flag B is used to select an alternate curve equation, Z^2 + C*Z =
- W^3 + A*W + B. This is the only time that the C parameter is used.
-
-
-
-4. How do I Compute Q, G, and Y?
-
- The number of points on the curve is the number of solutions to the
- curve equation, + 1 (for the "point at infinity"). The prime Q must
- divide the number of points. Usually the curve is chosen first, then
- the number of points is determined with Schoof's algorithm. This
- number is factored, and if it has a large prime divisor, that number
- is taken as Q.
-
- G must be a point of order Q on the curve, satisfying the equation
-
- Q * G = the point at infinity (on the elliptic curve)
-
- G may be chosen by selecting a random [RFC 1750] curve point, and
- multiplying it by (number-of-points-on-curve/Q). G must not itself
- be the "point at infinity"; in this astronomically unlikely event, a
- new random curve point is recalculated.
-
- G is specified by giving its W-coordinate. The Z-coordinate is
- calculated from the curve equation. In general, there will be two
- possible Z values. The rule is to choose the "positive" value.
-
- In the (mod P) case, the two possible Z values sum to P. The smaller
- value is less than P/2; it is used in subsequent calculations. In
- GF[P^D] fields, the highest-degree non-zero coefficient of the field
- element Z is used; it is chosen to be less than P/2.
-
- In the GF[2^N] case, the two possible Z values xor to W (or to the
- parameter C with the alternate curve equation). The numerically
- smaller Z value (the one which does not contain the highest-order 1
- bit of W (or C)) is used in subsequent calculations.
-
- Y is specified by giving the W-coordinate of the user's public
- signature key. The Z-coordinate value is determined from the curve
- equation. As with G, there are two possible Z values; the same rule
- is followed for choosing which Z to use.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 10]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- During the key generation process, a random [RFC 1750] number X must
- be generated such that 1 <= X <= Q-1. X is the private key and is
- used in the final step of public key generation where Y is computed
- as
-
- Y = X * G (as points on the elliptic curve)
-
- If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
- in the (mod P) case, or the high-order non-zero coefficient of Z >
- P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
- GF[2^N] case), then X must be replaced with Q-X. This will
- correspond to the correct Z-coordinate.
-
-
-
-5. Elliptic Curve SIG Resource Records
-
- The signature portion of an RR RDATA area when using the EC
- algorithm, for example in the RRSIG and SIG [RFC records] RRs is
- shown below.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | R, (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | S, (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- R and S are integers (mod Q). Their length is specified by the LQ
- field of the corresponding KEY RR and can also be calculated from the
- SIG RR's RDLENGTH. They are right justified, high-order-octet first.
- The same conditional formula for calculating the length from LQ is
- used as for all the other length fields above.
-
- The data signed is determined as specified in [RFC 2535]. Then the
- following steps are taken where Q, P, G, and Y are as specified in
- the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two
- different messages with the same K. K should be chosen from a
- very large space: If an opponent learns a K value for a single
- signature, the user's signing key is compromised, and a forger
- can sign arbitrary messages. There is no harm in signing the
- same message multiple times with the same key or different
- keys.)
-
- R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
-
-
-R. Schroeppel, et al [Page 11]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- as an integer, and reduced (mod Q). (R must not be 0. In
- this astronomically unlikely event, generate a new random K
- and recalculate R.)
-
- S = ( K^(-1) * (hash + X*R) ) mod Q.
-
- S must not be 0. In this astronomically unlikely event, generate a
- new random K and recalculate R and S.
-
- If S > Q/2, set S = Q - S.
-
- The pair (R,S) is the signature.
-
- Another party verifies the signature as follows:
-
- Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
- valid EC sigature.
-
- hash = SHA-1 ( data )
-
- Sinv = S^(-1) mod Q.
-
- U1 = (hash * Sinv) mod Q.
-
- U2 = (R * Sinv) mod Q.
-
- (U1 * G + U2 * Y) is computed on the elliptic curve.
-
- V = (the W-coordinate of this point) interpreted as an integer
- and reduced (mod Q).
-
- The signature is valid if V = R.
-
- The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
- (R,Q-S) would be valid signatures for the same data. Note that a
- signature that is valid for hash(data) is also valid for
- hash(data)+Q or hash(data)-Q, if these happen to fall in the range
- [0,2^160-1]. It's believed to be computationally infeasible to
- find data that hashes to an assigned value, so this is only a
- cosmetic blemish. The blemish can be eliminated by using Q >
- 2^160, at the cost of having slightly longer signatures, 42 octets
- instead of 40.
-
- We must specify how a field-element E ("the W-coordinate") is to be
- interpreted as an integer. The field-element E is regarded as a
- radix-P integer, with the digits being the coefficients in the
- polynomial basis representation of E. The digits are in the ragne
- [0,P-1]. In the two most common cases, this reduces to "the
- obvious thing". In the (mod P) case, E is simply a residue mod P,
- and is taken as an integer in the range [0,P-1]. In the GF[2^D]
-
-
-R. Schroeppel, et al [Page 12]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- case, E is in the D-bit polynomial basis representation, and is
- simply taken as an integer in the range [0,(2^D)-1]. For other
- fields GF[P^D], it's necessary to do some radix conversion
- arithmetic.
-
-
-
- 6. Performance Considerations
-
- Elliptic curve signatures use smaller moduli or field sizes than
- RSA and DSA. Creation of a curve is slow, but not done very often.
- Key generation is faster than RSA or DSA.
-
- DNS implementations have been optimized for small transfers,
- typically less than 512 octets including DNS overhead. Larger
- transfers will perform correctly and and extensions have been
- standardized to make larger transfers more efficient [RFC 2671].
- However, it is still advisable at this time to make reasonable
- efforts to minimize the size of RR sets stored within the DNS
- consistent with adequate security.
-
-
-
- 7. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- Some specific key generation considerations are given in the body
- of this document.
-
-
-
- 8. IANA Considerations
-
- The key and signature data structures defined herein correspond to
- the value 4 in the Algorithm number field of the IANA registry
-
- Assignment of meaning to the remaining ECC data flag bits or to
- values of ECC fields outside the ranges for which meaning in
- defined in this document requires an IETF consensus as defined in
- [RFC 2434].
-
-
-
-
-
-R. Schroeppel, et al [Page 13]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Copyright and Disclaimer
-
- Copyright (C) The Internet Society 2005. This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
- This document and the information contained herein are provided on
- an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
- EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
- THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
- ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
- PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 14]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Informational References
-
- [RFC 1034] - P. Mockapetris, "Domain names - concepts and
- facilities", 11/01/1987.
-
- [RFC 1035] - P. Mockapetris, "Domain names - implementation and
- specification", 11/01/1987.
-
- [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
- August 1999.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
- S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
- S. Rose, "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June
- 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", 1996, John Wiley and Sons
-
- [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
- Cryptosystems", 1993 Kluwer.
-
- [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
- Curves", 1986, Springer Graduate Texts in mathematics #106.
-
-
-
- Normative Refrences
-
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997.
-
- [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", October 1998.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
- S. Rose, "Resource Records for the DNS Security Extensions", RFC
- 4034, March 2005.
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 15]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Author's Addresses
-
- Rich Schroeppel
- 500 S. Maple Drive
- Woodland Hills, UT 84653 USA
-
- Telephone: +1-505-844-9079(w)
- Email: rschroe@sandia.gov
-
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-786-7554 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
- Expiration and File Name
-
- This draft expires in January 2006.
-
- Its file name is draft-ietf-dnsext-ecc-key-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 16]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt
deleted file mode 100644
index 4cfd417804d3d..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt
+++ /dev/null
@@ -1,639 +0,0 @@
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-Clarifies STD0013 Motorola Laboratories
-Expires December 2004 July 2004
-
-
-
- Domain Name System (DNS) Case Insensitivity Clarification
- ------ ---- ------ ----- ---- ------------- -------------
- <draft-ietf-dnsext-insensitive-04.txt>
-
- Donald E. Eastlake 3rd
-
-
-
-Status of This Document
-
- 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.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group at namedroppers@ops.ietf.org.
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. 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
-
- 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 should not have any interoperability
- consequences.
-
-
-
-
-
-
-
-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, and Scott Seligman are gratefully
- acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................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.................................7
-
- Copyright and Disclaimer...................................9
- Normative References.......................................9
- Informative References....................................10
- -02 to -03 Changes........................................10
- -03 to -04 Changes........................................11
- Author's Address..........................................11
- Expiration and File Name..................................11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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.
-
- 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.
-
- One typographic convention for octets that do not correspond to an
-
-
-D. Eastlake 3rd [Page 3]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- 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 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
- terms were "majuscule" and "minuscule".)
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- 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 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].)
-
- 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.
-
-
-
-
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-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 input 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 may retain
- the case first input for such a label or allow new input to override
- the old case or even maintain separate copies preserving the input
- case.
-
- For example, if data with owner name "foo.bar.example" is input 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" or the actual input case could be preserved.
- Thus later retrieval of data stored under "xyz.bar.example" in this
- case can easily return data with "xyz.BAR.example". The same
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- considerations apply when inputting multiple data records with owner
- names differing only in case. For example, if an "A" record is stored
- as the first resourced record 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.
-
- 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.
-
-
-
-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
- 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 8 of [RFC 2535].
- 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
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- 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 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.
-
-
-
-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 2535] - D. Eastlake, "Domain Name System Security Extensions",
- March 1999.
-
- [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.
-
- [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
-
- [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 3454] - P. Hoffman, M. Blanchet, "Preparation of
- Internationalized String ("stringprep")", December 2002.
-
- [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)", March 2003.
-
- [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
- for Internationalized Domain Names (IDN)", March 2003.
-
- [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
- for Internationalized Domain Names in Applications (IDNA)", March
- 2003.
-
- [UNICODE] - The Unicode Consortium, "The Unicode Standard",
- <http://www.unicode.org/unicode/standard/standard.html>.
-
-
-
--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.
-
-
-
-D. Eastlake 3rd [Page 10]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
--03 to -04 Changes
-
- The following changes were made between draft version -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.
-
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-786-7554 (w)
- +1 508-634-2066 (h)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires December 2004.
-
- Its file name is draft-ietf-dnsext-insensitive-04.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 11]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt
deleted file mode 100644
index 1c4c3f635e378..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt
+++ /dev/null
@@ -1,754 +0,0 @@
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-Updates RFC 1034, 1035 Motorola Laboratories
-Expires January 2006 July 2005
-
-
-
- Domain Name System (DNS) Case Insensitivity Clarification
- ------ ---- ------ ----- ---- ------------- -------------
- <draft-ietf-dnsext-insensitive-06.txt>
-
- Donald E. Eastlake 3rd
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group at namedroppers@ops.ietf.org.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-Abstract
-
- Domain Name System (DNS) names are "case insensitive". This document
- explains exactly what that means and provides a clear specification
- of the rules. This clarification updates RFCs 1034 and 1035.
-
-
-D. Eastlake 3rd [Page 1]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Acknowledgements
-
- The contributions to this document of Rob Austein, Olafur
- Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
- Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
- are gratefully acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Copyright Notice...........................................1
- Abstract...................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Case Insensitivity of DNS Labels........................3
- 2.1 Escaping Unusual DNS Label Octets......................3
- 2.2 Example Labels with Escapes............................4
- 3. Name Lookup, Label Types, and CLASS.....................4
- 3.1 Original DNS Label Types...............................5
- 3.2 Extended Label Type Case Insensitivity Considerations..5
- 3.3 CLASS Case Insensitivity Considerations................5
- 4. Case on Input and Output................................6
- 4.1 DNS Output Case Preservation...........................6
- 4.2 DNS Input Case Preservation............................6
- 5. Internationalized Domain Names..........................7
- 6. Security Considerations.................................8
-
- Copyright and Disclaimer...................................9
- Normative References.......................................9
- Informative References....................................10
-
- Changes Between Draft Version.............................11
- -02 to -03 Changes........................................11
- -03 to -04 Changes........................................11
- -04 to -05 Changes........................................11
- -05 to -06 Changes........................................12
-
- Author's Address..........................................13
- Expiration and File Name..................................13
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. Each node in the DNS tree has a name consisting of
- zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
- case insensitive fashion. This document clarifies the meaning of
- "case insensitive" for the DNS. This clarification updates RFCs 1034
- and 1035 [STD 13].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Case Insensitivity of DNS Labels
-
- DNS was specified in the era of [ASCII]. DNS names were expected to
- look like most host names or Internet email address right halves (the
- part after the at-sign, "@") or be numeric as in the in-addr.arpa
- part of the DNS name space. For example,
-
- foo.example.net.
- aol.com.
- www.gnu.ai.mit.edu.
- or 69.2.0.192.in-addr.arpa.
-
- Case varied alternatives to the above would be DNS names like
-
- Foo.ExamplE.net.
- AOL.COM.
- WWW.gnu.AI.mit.EDU.
- or 69.2.0.192.in-ADDR.ARPA.
-
- However, the individual octets of which DNS names consist are not
- limited to valid ASCII character codes. They are 8-bit bytes and all
- values are allowed. Many applications, however, interpret them as
- ASCII characters.
-
-
-
-2.1 Escaping Unusual DNS Label Octets
-
- In Master Files [STD 13] and other human readable and writable ASCII
- contexts, an escape is needed for the byte value for period (0x2E,
- ".") and all octet values outside of the inclusive range of 0x21
- ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
- the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
-
-
-
-D. Eastlake 3rd [Page 3]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- One typographic convention for octets that do not correspond to an
- ASCII printing graphic is to use a back-slash followed by the value
- of the octet as an unsigned integer represented by exactly three
- decimal digits.
-
- The same convention can be used for printing ASCII characters so that
- they will be treated as a normal label character. This includes the
- back-slash character used in this convention itself which can be
- expressed as \092 or \\ and the special label separator period (".")
- which can be expressed as and \046 or \. respectively. It is
- advisable to avoid using a backslash to quote an immediately
- following non-printing ASCII character code to avoid implementation
- difficulties.
-
- A back-slash followed by only one or two decimal digits is undefined.
- A back-slash followed by four decimal digits produces two octets, the
- first octet having the value of the first three digits considered as
- a decimal number and the second octet being the character code for
- the fourth decimal digit.
-
-
-
-2.2 Example Labels with Escapes
-
- The first example below shows embedded spaces and a period (".")
- within a label. The second one show a 5-octet label where the second
- octet has all bits zero, the third is a backslash, and the fourth
- octet has all bits one.
-
- Donald\032E\.\032Eastlake\0323rd.example.
- and a\000\\\255z.example.
-
-
-
-3. Name Lookup, Label Types, and CLASS
-
- The original DNS design decision was made that comparisons on name
- lookup for DNS queries should be case insensitive [STD 13]. That is
- to say, a lookup string octet with a value in the inclusive range of
- 0x41 to 0x5A, the upper case ASCII letters, MUST match the identical
- value and also match the corresponding value in the inclusive range
- 0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet
- with a lower case ASCII letter value MUST similarly match the
- identical value and also match the corresponding value in the upper
- case ASCII letter range.
-
- (Historical Note: the terms "upper case" and "lower case" were
- invented after movable type. The terms originally referred to the
- two font trays for storing, in partitioned areas, the different
- physical type elements. Before movable type, the nearest equivalent
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- terms were "majuscule" and "minuscule".)
-
- One way to implement this rule would be, when comparing octets, to
- subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
- before the comparison. Such an operation is commonly known as "case
- folding" but implementation via case folding is not required. Note
- that the DNS case insensitivity does NOT correspond to the case
- folding specified in [iso-8859-1] or [iso-8859-2]. For example, the
- octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
- contexts, where they are interpreted as the upper and lower case
- version of "Y" with an acute accent, they might.
-
-
-
-3.1 Original DNS Label Types
-
- DNS labels in wire-encoded names have a type associated with them.
- The original DNS standard [RFC 1035] had only two types. ASCII
- labels, with a length of from zero to 63 octets, and indirect (or
- compression) labels which consist of an offset pointer to a name
- location elsewhere in the wire encoding on a DNS message. (The ASCII
- label of length zero is reserved for use as the name of the root node
- of the name tree.) ASCII labels follow the ASCII case conventions
- described herein and, as stated above, can actually contain arbitrary
- byte values. Indirect labels are, in effect, replaced by the name to
- which they point which is then treated with the case insensitivity
- rules in this document.
-
-
-
-3.2 Extended Label Type Case Insensitivity Considerations
-
- DNS was extended by [RFC 2671] to have additional label type numbers
- available. (The only such type defined so far is the BINARY type [RFC
- 2673] which is now Experimental [RFC 3363].)
-
- The ASCII case insensitivity conventions only apply to ASCII labels,
- that is to say, label type 0x0, whether appearing directly or invoked
- by indirect labels.
-
-
-
-3.3 CLASS Case Insensitivity Considerations
-
- As described in [STD 13] and [RFC 2929], DNS has an additional axis
- for data location called CLASS. The only CLASS in global use at this
- time is the "IN" or Internet CLASS.
-
- The handling of DNS label case is not CLASS dependent. With the
- original design of DNS, it was intended that a recursive DNS resolver
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- be able to handle new CLASSes that were unknown at the time of its
- implementation. This requires uniform handling of label case
- insensitivity. Should it become desireable, for example, to allocate
- a CLASS with "case sensitive ASCII labels" for example, it would be
- necessary to allocate a new label type for these labels.
-
-
-
-4. Case on Input and Output
-
- While ASCII label comparisons are case insensitive, [STD 13] says
- case MUST be preserved on output, and preserved when convenient on
- input. However, this means less than it would appear since the
- preservation of case on output is NOT required when output is
- optimized by the use of indirect labels, as explained below.
-
-
-
-4.1 DNS Output Case Preservation
-
- [STD 13] views the DNS namespace as a node tree. ASCII output is as
- if a name was marshaled by taking the label on the node whose name is
- to be output, converting it to a typographically encoded ASCII
- string, walking up the tree outputting each label encountered, and
- preceding all labels but the first with a period ("."). Wire output
- follows the same sequence but each label is wire encoded and no
- periods inserted. No "case conversion" or "case folding" is done
- during such output operations, thus "preserving" case. However, to
- optimize output, indirect labels may be used to point to names
- elsewhere in the DNS answer. In determining whether the name to be
- pointed to, for example the QNAME, is the "same" as the remainder of
- the name being optimized, the case insensitive comparison specified
- above is done. Thus such optimization may easily destroy the output
- preservation of case. This type of optimization is commonly called
- "name compression".
-
-
-
-4.2 DNS Input Case Preservation
-
- Originally, DNS data came from an ASCII Master File as defined in
- [STD 13] or a zone transfer. DNS Dynamic update and incremental zone
- transfers [RFC 1995] have been added as a source of DNS data [RFC
- 2136, 3007]. When a node in the DNS name tree is created by any of
- such inputs, no case conversion is done. Thus the case of ASCII
- labels is preserved if they are for nodes being created. However,
- when a name label is input for a node that already exist in DNS data
- being held, the situation is more complex. Implementations are free
- to retain the case first loaded for such a label or allow new input
- to override the old case or even maintain separate copies preserving
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- the input case.
-
- For example, if data with owner name "foo.bar.example" is loaded and
- then later data with owner name "xyz.BAR.example" is input, the name
- of the label on the "bar.example" node, i.e. "bar", might or might
- not be changed to "BAR" in the DNS stored data or the actual input
- case could be preserved. Thus later retrieval of data stored under
- "xyz.bar.example" in this case can return all data with
- "xyz.BAR.example" or all data with "xyz.bar.example" or even, when
- more than one RR is being returned, a mixture of these two cases.
- This last case is unlikely because optimization of answer length
- through indirect labels tends to cause only copy of the name tail
- ("bar.example" or "BAR.example") to be used for all returned RRs.
- Note that none of this has any effect on the number of completeness
- of the RR set returned, only on the case of the names in the RR set
- returned.
-
- The same considerations apply when inputting multiple data records
- with owner names differing only in case. For example, if an "A"
- record is the first resourced record stored under owner name
- "xyz.BAR.example" and then a second "A" record is stored under
- "XYZ.BAR.example", the second MAY be stored with the first (lower
- case initial label) name or the second MAY override the first so that
- only an upper case initial label is retained or both capitalizations
- MAY be kept in the DNS stored data. In any case, a retrieval with
- either capitalization will retrieve all RRs with either
- capitalization.
-
- Note that the order of insertion into a server database of the DNS
- name tree nodes that appear in a Master File is not defined so that
- the results of inconsistent capitalization in a Master File are
- unpredictable output capitalization.
-
-
-
-5. Internationalized Domain Names
-
- A scheme has been adopted for "internationalized domain names" and
- "internationalized labels" as described in [RFC 3490, 3454, 3491, and
- 3492]. It makes most of [UNICODE] available through a separate
- application level transformation from internationalized domain name
- to DNS domain name and from DNS domain name to internationalized
- domain name. Any case insensitivity that internationalized domain
- names and labels have varies depending on the script and is handled
- entirely as part of the transformation described in [RFC 3454] and
- [RFC 3491] which should be seen for further details. This is not a
- part of the DNS as standardized in STD 13.
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-6. Security Considerations
-
- The equivalence of certain DNS label types with case differences, as
- clarified in this document, can lead to security problems. For
- example, a user could be confused by believing two domain names
- differing only in case were actually different names.
-
- Furthermore, a domain name may be used in contexts other than the
- DNS. It could be used as a case sensitive index into some data base
- or file system. Or it could be interpreted as binary data by some
- integrity or authentication code system. These problems can usually
- be handled by using a standardized or "canonical" form of the DNS
- ASCII type labels, that is, always mapping the ASCII letter value
- octets in ASCII labels to some specific pre-chosen case, either upper
- case or lower case. An example of a canonical form for domain names
- (and also a canonical ordering for them) appears in Section 6 of [RFC
- 4034]. See also [RFC 3597].
-
- Finally, a non-DNS name may be stored into DNS with the false
- expectation that case will always be preserved. For example, although
- this would be quite rare, on a system with case sensitive email
- address local parts, an attempt to store two "RP" records that
- differed only in case would probably produce unexpected results that
- might have security implications. That is because the entire email
- address, including the possibly case sensitive local or left hand
- part, is encoded into a DNS name in a readable fashion where the case
- of some letters might be changed on output as described above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Normative References
-
- [ASCII] - ANSI, "USA Standard Code for Information Interchange",
- X3.4, American National Standards Institute: New York, 1968.
-
- [RFC 1034, 1035] - See [STD 13].
-
- [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
- 1996.
-
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997.
-
- [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
-
- [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
- Update", November 2000.
-
- [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
- draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
-
- [RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [STD 13]
- - P. Mockapetris, "Domain names - concepts and facilities", RFC
- 1034, November 1987.
- - P. Mockapetris, "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
-
-
-
-D. Eastlake 3rd [Page 9]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Informative References
-
- [ISO 8859-1] - International Standards Organization, Standard for
- Character Encodings, Latin-1.
-
- [ISO 8859-2] - International Standards Organization, Standard for
- Character Encodings, Latin-2.
-
- [RFC 1591] - J. Postel, "Domain Name System Structure and
- Delegation", March 1994.
-
- [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
- June 1999.
-
- [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
- Name System (DNS) IANA Considerations", September 2000.
-
- [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
- 1999.
-
- [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
- August 1999.
-
- [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
- Foo", 1 April 2001.
-
- [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
- Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
- the Domain Name System (DNS)", RFC 3363, August 2002.
-
- [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
- Internationalized String ("stringprep")", December 2002.
-
- [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)", March 2003.
-
- [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
- for Internationalized Domain Names (IDN)", March 2003.
-
- [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
- for Internationalized Domain Names in Applications (IDNA)", March
- 2003.
-
- [UNICODE] - The Unicode Consortium, "The Unicode Standard",
- <http://www.unicode.org/unicode/standard/standard.html>.
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Changes Between Draft Version
-
- RFC Editor: The following summaries of changes between draft versions
- are to be removed before publication.
-
-
-
--02 to -03 Changes
-
- The following changes were made between draft version -02 and -03:
-
- 1. Add internationalized domain name section and references.
-
- 2. Change to indicate that later input of a label for an existing DNS
- name tree node may or may not be normalized to the earlier input or
- override it or both may be preserved.
-
- 3. Numerous minor wording changes.
-
-
-
--03 to -04 Changes
-
- The following changes were made between draft versions -03 and -04:
-
- 1. Change to conform to the new IPR, Copyright, etc., notice
- requirements.
-
- 2. Change in some section headers for clarity.
-
- 3. Drop section on wildcards.
-
- 4. Add emphasis on loss of case preservation due to name compression.
-
- 5. Add references to RFCs 1995 and 3092.
-
-
-
--04 to -05 Changes
-
- The following changes were made between draft versions -04 and -05:
-
- 1. More clearly state that this draft updates RFCs 1034, 1035 [STD
- 13].
-
- 2. Add informative references to ISO 8859-1 and ISO 8859-2.
-
- 3. Fix hyphenation and capitalization nits.
-
-
-
-
-D. Eastlake 3rd [Page 11]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
--05 to -06 Changes
-
- The following changes were made between draft version -05 and -06.
-
- 1. Add notation to the RFC Editor that the draft version change
- summaries are to be removed before RFC publication.
-
- 2. Additional text explaining why labe case insensitivity is CLASS
- independent.
-
- 3. Changes and additional text clarifying that the fact that
- inconsistent case in data loaded into DNS may result in
- unpredicatable or inconsistent case in DNS storage but has no effect
- on the completeness of RR sets retrieved.
-
- 4. Add reference to [RFC 3363] and update reference to [RFC 2535] to
- be to [RFC 4034].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 12]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-786-7554 (w)
-
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires January 2006.
-
- Its file name is draft-ietf-dnsext-insensitive-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 13]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt
deleted file mode 100644
index 123d3cc096118..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt
+++ /dev/null
@@ -1,335 +0,0 @@
-
-DNS Extensions Working Group J. Schlyter
-Internet-Draft August 24, 2004
-Expires: February 22, 2005
-
-
- RFC 3597 Interoperability Report
- draft-ietf-dnsext-interop3597-01.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 3667.
-
- 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 22, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This memo documents the result from the RFC 3597 (Handling of Unknown
- DNS Resource Record Types) interoperability testing.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires February 22, 2005 [Page 1]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
-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 . . . . . . . . . . . . . . . . . . . 3
- 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
- 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- Normative References . . . . . . . . . . . . . . . . . . . . . 4
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
- A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
- Intellectual Property and Copyright Statements . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires February 22, 2005 [Page 2]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
-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 for
- compliance of RFC 3597:
-
- DNSJava 1.6.4
- ISC BIND 8.4.5rc4
- ISC BIND 9.3.0rc2
- 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)
-
-3. Tests
-
-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.
-
-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
-
-
-
-Schlyter Expires February 22, 2005 [Page 3]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
- 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.
-
-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 February 22, 2005 [Page 4]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
-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 February 22, 2005 [Page 5]
-
-Internet-Draft RFC 3597 Interoperability Report August 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 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.
-
-
-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.
-
-
-
-
-Schlyter Expires February 22, 2005 [Page 6]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt
deleted file mode 100644
index 160afc356a07d..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-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-keyrr-key-signing-flag-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
deleted file mode 100644
index 6bffb70423f4e..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-DNS Extensions O. Kolkman
-Internet-Draft RIPE NCC
-Expires: June 17, 2004 J. Schlyter
-
- E. Lewis
- ARIN
- December 18, 2003
-
-
- DNSKEY RR Secure Entry Point Flag
- draft-ietf-dnsext-keyrr-key-signing-flag-12
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 June 17, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- With the Delegation Signer (DS) resource record the concept of a
- public key acting as a secure entry point has been introduced. During
- exchanges of public keys with the parent there is a need to
- differentiate secure entry point keys from other public keys in the
- DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is
- defined to indicate that DNSKEY is to be used as a secure entry
- point. 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
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 1]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- be used in the DNS verification protocol. This document updates RFC
- 2535 and RFC 3445.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4
- 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5
- 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
- 7. Internationalization Considerations . . . . . . . . . . . . . . 6
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
- Normative References . . . . . . . . . . . . . . . . . . . . . . 7
- Informative References . . . . . . . . . . . . . . . . . . . . . 7
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
- Intellectual Property and Copyright Statements . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 2]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
-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.
-
- 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.
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 3]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- 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 RFC2119 [1].
-
-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
-
-
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 4]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- This document assigns the 15'th bit in the flags field as the secure
- entry point (SEP) bit. If the 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.
-
- 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.
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 5]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- 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.
-
-6. IANA Considerations
-
- The flag bits in the DNSKEY RR are assigned by IETF consensus and
- registered in the DNSKEY Flags registry (created by [4]). This
- document assigns the 15th bit in the DNSKEY RR 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.
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 6]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- This document saw the light during a workshop on DNSSEC operations
- hosted by USC/ISI in August 2002.
-
-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", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
- in progress), October 2003.
-
-Informative References
-
- [5] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-15 (work in progress), June
- 2003.
-
- [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
- Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-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
- Karl Gustavsgatan 15
- Goteborg SE-411 25
- Sweden
-
- EMail: jakob@schlyter.se
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 7]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- 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. Expires June 17, 2004 [Page 8]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
-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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 9]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 10]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt
deleted file mode 100644
index 8dcacc8bb9ec2..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt
+++ /dev/null
@@ -1,1559 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group Levon Esibov
-INTERNET-DRAFT Bernard Aboba
-Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-33.txt> Microsoft
-18 July 2004
-
-
- Linklocal Multicast Name Resolution (LLMNR)
-
- 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 January 2, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2004. All rights reserved.
-
-Abstract
-
- Today, with the rise of home networking, there are an increasing
- number of ad-hoc networks operating without a Domain Name System
- (DNS) server. 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.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-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 ................................. 8
- 2.3 Responder behavior .............................. 8
- 2.4 Unicast queries ................................. 11
- 2.5 Off-link detection .............................. 11
- 2.6 Responder responsibilities ...................... 12
- 2.7 Retransmission and jitter ....................... 13
- 2.8 DNS TTL ......................................... 13
- 2.9 Use of the authority and additional sections .... 14
-3. Usage model ........................................... 14
- 3.1 LLMNR configuration ............................. 15
-4. Conflict resolution ................................... 16
- 4.1 Considerations for multiple interfaces .......... 18
- 4.2 API issues ...................................... 19
-5. Security considerations ............................... 20
- 5.1 Scope restriction ............................... 20
- 5.2 Usage restriction ............................... 21
- 5.3 Cache and port separation ....................... 22
- 5.4 Authentication .................................. 22
-6. IANA considerations ................................... 22
-7. References ............................................ 22
- 7.1 Normative References ............................ 22
- 7.2 Informative References .......................... 23
-Acknowledgments .............................................. 24
-Authors' Addresses ........................................... 25
-Intellectual Property Statement .............................. 25
-Disclaimer of Validity ....................................... 26
-Full Copyright Statement ..................................... 26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which utilizes 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. These include
- scenarios in which hosts are not configured with the address of a DNS
- server, where configured DNS servers do not reply to a query, or
- where they respond with errors, 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. The
- assumption is that if a network has a gateway, then 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 networking scenarios,
- or where no DNS server is available that is authoritative for the
- names of local hosts, and can support dynamic DNS, such as in
- wireless hotspots.
-
- 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.
-
- 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.
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-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 address is considered reachable over a link if either an ARP or
- neighbor discovery cache entry exists for the address on the 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.
-
-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. IPv4 administratively scoped multicast usage is specified
- in "Administratively Scoped IP Multicast" [RFC2365]. 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 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 to verify the uniqueness of names as described in Section 4.
- This document does not specify how names are chosen or configured.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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.
-
- An LLMNR sender may send a request for any name. However, by
- default, LLMNR requests SHOULD be sent only when one of the following
- conditions are met:
-
- [1] No manual or automatic DNS configuration has been
- performed. If an interface has been configured with DNS
- server address(es), then LLMNR SHOULD NOT be used as the
- primary name resolution mechanism on that interface, although
- it MAY be used as a name resolution mechanism of last resort.
-
- [2] DNS servers do not respond.
-
- [3] DNS servers respond to a DNS query with RCODE=3
- (Authoritative Name Error) or RCODE=0, and an empty
- answer section.
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] DNS servers are not configured or do not respond to a
- DNS query, or respond with RCODE=3, or RCODE=0 and an
- empty answer section.
-
- [b] An LLMNR sender sends an LLMNR query to the link-scope
- multicast address(es) defined in Section 2, unless a
- unicast query is indicated. A sender SHOULD send LLMNR
- queries for PTR RRs via unicast, 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.
-
- Further details of sender and responder behavior are provided in the
- sections that follow.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-2.1. LLMNR packet format
-
- LLMNR utilizes 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 permitted by the link
- MTU.
-
-2.1.1. LLMNR header format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
- 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 | Z|TC| Z| 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.
-
-QR A one bit field that specifies whether this message is an LLMNR
- query (0), or an LLMNR response (1).
-
-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.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-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 an LLMNR response,
- then the sender MAY use the response if it contains all necessary
- information, or the sender MAY 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.
-
-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 RCODE MUST be zero, and is
- ignored by the responder. 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 preferrable to
- not sending a response, since it enables errors to be diagnosed.
-
- 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
- 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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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.
-
-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, SRV, etc.) to the link-scope multicast address.
-
- As described in Section 2.4, a sender may also send a unicast query.
- Sections 2 and 3 describe the circumstances in which LLMNR queries
- may be sent.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope or in the event no positive non-null responses exist for
- the transmitted query. If no positive response is received, a
- resolver treats it 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).
-
- 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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- responder has another RR as well; 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
- 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 10.1.1.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 10.1.1.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.1.1.10.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.
- 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:
-
-[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 SHOULD 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.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-[e] Responders MUST NOT respond using cached data.
-
-[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 MAY 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.
-
- 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.".
-
- In this example (unless this limitation is introduced) 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. In this example
- a host "child.foo.example.com." would send a dynamic update for the
- NS and glue A record to "foo.example.com.", but this approach
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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).
-
-2.5. "Off link" detection
-
- For IPv4, an "on link" address is defined as a link-local address
- [IPv4Link] or an address whose prefix belongs to a subnet on the
- local link. For IPv6 [RFC2460] an "on link" address is either a
- link-local address, defined in [RFC2373], or an address whose prefix
- belongs to a subnet on the local link.
-
- A sender MUST select a source address for LLMNR queries that is "on
- link". The destination address of an LLMNR query MUST be a link-
- scope multicast address or an "on link" unicast address.
-
- A responder MUST select a source address for responses that is "on
- link". The destination address of an LLMNR response MUST be an "on
- link" 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.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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 Rendezvous.
-
- 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.
- In particular:
-
- [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.
-
- Routable addresses MUST be included first in the response, if
- available. This encourages use of routable address(es) for
- establishment of new connections.
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-2.7. Retransmission and jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query and how long to collect responses
- to an LLMNR query.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender MAY repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it.
- Retransmission of UDP queries SHOULD NOT be attempted more than 3
- times. Where LLMNR queries are sent using TCP, retransmission is
- handled by the transport layer.
-
- Because an LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
- collect all possible responses, rather than considering the multicast
- query answered after the first response is received. 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.
-
- An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
- for each transmission. It is suggested that the computation of
- LLMNR_TIMEOUT be based on the response times for earlier LLMNR
- queries sent on the same interface.
-
- For example, the algorithms described in RFC 2988 [RFC2988]
- (including exponential backoff) compute an RTO, which is used as the
- value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial
- RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum
- RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the
- maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
-
- Recommended values are an initial RTO of 1 second, a minimum RTO of
- 200ms, and a maximum RTO of 5 seconds. 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 100
- ms. This delay MAY be avoided by responders responding with RRs
- which they have previously determined to be UNIQUE (see Section 4 for
- details).
-
-2.8. DNS TTL
-
- The responder should use a pre-configured TTL value in the records
- returned 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.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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 owner name of this SOA record MUST be equal to the
- query name.
-
- Responders SHOULD NOT perform DNS additional section processing,
- except as required for EDNS0 and DNSSEC.
-
- 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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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
- 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 linklocal 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 AAAA RR queries
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3),
- then it will not be possible to resolve the names of IPv6-only hosts.
- In this situation, LLMNR over IPv6 can be used for local name
- resolution.
-
- 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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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
- 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.
-
- Unless unconfigured hosts periodically retry configuration, an outage
- in the DNS configuration mechanism will result in hosts continuing to
- use LLMNR even once the outage is repaired. Since LLMNR only enables
- linklocal name resolution, this represents an unnecessary degradation
- in capabilities. As a result, it is recommended that hosts without a
- configured DNS server periodically attempt to obtain DNS
- configuration. For example, where DHCP is used for DNS
- configuration, [RFC2131] recommends a maximum retry interval of 64
- seconds. In the absence of other guidance, a default retry interval
- of one (1) minute is RECOMMENDED.
-
-4. Conflict resolution
-
- The sender MUST anticipate receiving multiple replies to the same
- LLMNR query, in the event that several LLMNR enabled computers
- receive the query and respond with valid answers. When this occurs,
- the responses may first be concatenated, and then treated in the same
- manner that multiple RRs received from the same DNS server would; the
- sender perceives no inherent conflict in the receipt of multiple
- responses.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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. Resource records for which the latter queries
- are submitted are referred as UNIQUE throughout this document. The
- uniqueness of a resource record depends on a nature of the name in
- the query and type of the query. For example it is expected that:
-
- - multiple hosts may respond to a query for an SRV type record
- - multiple hosts may respond to a query for an A or AAAA type
- record for a cluster name (assigned to multiple hosts in
- the cluster)
- - only a single host may respond to a query for an A or AAAA
- type record for a name.
-
- Every responder that responds to an LLMNR query AND includes a UNIQUE
- record in the response:
-
- [1] MUST verify that there is no other host within the
- scope of the LLMNR query propagation that can return
- a resource record for the same name, type and class.
-
- [2] MUST NOT include a UNIQUE resource record in the
- response without having verified its uniqueness.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface should have its own independent LLMNR
- cache. For each UNIQUE resource record in a given interface's
- configuration, the host MUST verify resource record uniqueness on
- that interface. To accomplish this, the host MUST send an LLMNR
- query for each UNIQUE resource record.
-
- By default, a host SHOULD be configured to behave as though all RRs
- are UNIQUE. 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 the LLMNR queries on an interface
- enabled for transmission and reception of IP traffic
- - is configured to respond to the LLMNR queries using additional
- UNIQUE resource records
- - detects that an interface is connected and is usable
- (e.g. an IEEE 802 hardware link-state change indicating
- that a cable was attached or completion of authentication
- (and if needed, association) with a wireless base station
- or adhoc network
-
- When a host that has a UNIQUE record receives an LLMNR query for that
- record, the host MUST respond. After the client receives a response,
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- it MUST check whether the response arrived on an interface different
- from the one on which the query was sent. If the response arrives on
- a different interface, the client can use the UNIQUE resource record
- in response to LLMNR queries. If not, then it MUST NOT use the
- UNIQUE resource record in response to LLMNR queries.
-
- The name conflict detection mechanism doesn't prevent name conflicts
- when previously partitioned segments are connected by a bridge. In
- order to minimize the chance of conflicts in such a situation, it is
- recommended that steps be taken to ensure name uniqueness. For
- example, the name could be chosen randomly from a large pool of
- potential names, or the name could be assigned via a process designed
- to guarantee uniqueness.
-
- When name conflicts are detected, they SHOULD be logged. 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.
-
-4.1. 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.
-
- 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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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
- 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 unicast 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.2. 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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- 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 by nature a peer-to-peer name resolution protocol. It is
- therefore inherently more vulnerable than DNS, since existing DNS
- security mechanisms are difficult to apply to LLMNR. While tools
- exist to alllow an attacker to spoof a response to a DNS query,
- spoofing a response to an LLMNR query is easier since the query is
- sent to a link-scope multicast address, where every host on the
- logical link will be made aware of it.
-
- In order to address the security vulnerabilities, the following
- mechanisms are contemplated:
-
- [1] Scope restrictions.
- [2] Usage restrictions.
- [3] Cache and port separation.
- [4] Authentication.
-
- These techniques are described in the following sections.
-
-5.1. Scope restriction
-
- With LLMNR it is possible that hosts will allocate conflicting names
- for a period of time, or that attackers will attempt to deny service
- to other hosts by allocating the same name. Such attacks also allow
- hosts to receive packets destined for other hosts.
-
- Since LLMNR is typically deployed in situations where no trust model
- can be assumed, it is likely that LLMNR queries and responses will be
- unauthenticated. In the absence of authentication, LLMNR reduces the
- exposure to such threats by utilizing UDP queries sent to a link-
- scope multicast address, as well as setting the TTL (IPv4) or Hop
- Limit (IPv6) fields to one (1) on TCP queries and responses.
-
- Using a TTL of one (1) to set up a TCP connection in order to send a
- unicast LLMNR query reduces the likelihood of both denial of service
- attacks and spoofed responses. Checking that an LLMNR query is sent
- to a link-scope multicast address should prevent spoofing of
- multicast queries by off-link attackers.
-
- While this limits the ability of off-link attackers to spoof LLMNR
- queries and responses, it does not eliminate it. For example, it is
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- possible for an attacker to spoof a response to a frequent 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.
-
- When LLMNR queries are sent to a link-scope multicast address, 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.
-
- Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
- one in an LLMNR UDP response may enable denial of service attacks
- across the Internet. However, since LLMNR responders only respond to
- queries for which they are authoritative, and LLMNR does not provide
- wildcard query support, it is believed that this threat is minimal.
-
- There also are scenarios such as public "hotspots" where 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 home network, while wireless
- attackers may reside outside the home. Link-layer security can be of
- assistance against these threats if it is available.
-
-5.2. Usage restriction
-
- As noted in Sections 2 and 3, LLMNR is intended for usage in a
- limited set of scenarios.
-
- If an LLMNR query is sent whenever a DNS server does not respond in a
- timely way, then an attacker can poison the LLMNR cache by responding
- to the query with incorrect information. To some extent, these
- vulnerabilities exist today, since DNS response spoofing tools are
- available that can allow an attacker to respond to a query more
- quickly than a distant DNS server.
-
- 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.
-
- The vulnerability is more serious if LLMNR is given higher priority
- than DNS among the enabled name resolution mechanisms. In such a
- configuration, 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,
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
- eliminating the benefits of cache separation. As a result, LLMNR is
- only used as a name resolution mechanism of last resort.
-
-5.3. 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.
-
-5.4. Authentication
-
- LLMNR implementations may not support DNSSEC or TSIG, and as a
- result, responses to LLMNR queries may be unauthenticated. If
- authentication is desired, and a pre-arranged security configuration
- is possible, then IPsec ESP with a null-transform MAY be used to
- authenticate LLMNR responses. 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.
-
-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. References
-
-7.1. Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-[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.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 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.
-
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
- Timer", RFC 2988, November 2000.
-
-7.2. Informative References
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- 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.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-[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.
-
-[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.
-
-[IPV4Link]
- Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of IPv4 Link-Local Addresses", Internet draft (work in
- progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May
- 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
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[NodeInfo]
- Crawford, M., "IPv6 Node Information Queries", Internet draft
- (work in progress), draft-ietf-ipn-gwg-icmp-name-
- lookups-09.txt, May 2002.
-
-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, Stuart Cheshire, Randy Bush,
- Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik
- Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik
- Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill,
- Keith Moore and Markku Savela.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-Authors' Addresses
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
- 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
-
-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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 18 July 2004
-
-
-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.
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 26]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt
deleted file mode 100644
index 5de6e85ecf65e..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt
+++ /dev/null
@@ -1,1740 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group Bernard Aboba
-INTERNET-DRAFT Dave Thaler
-Category: Standards Track Levon Esibov
-<draft-ietf-dnsext-mdns-43.txt> Microsoft Corporation
-29 August 2005
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005.
-
-Abstract
-
- The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
- name resolution in scenarios in which conventional DNS name
- resolution is not possible. LLMNR supports all current and future
- DNS formats, types and classes, while operating on a separate port
- from DNS, and with a distinct resolver cache. Since LLMNR only
- operates on the local link, it cannot be considered a substitute for
- DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name Resolution Using LLMNR ........................... 4
- 2.1 LLMNR Packet Format ............................. 6
- 2.2 Sender Behavior ................................. 9
- 2.3 Responder Behavior .............................. 10
- 2.4 Unicast Queries and Responses ................... 12
- 2.5 Off-link Detection .............................. 13
- 2.6 Responder Responsibilities ...................... 13
- 2.7 Retransmission and Jitter ....................... 14
- 2.8 DNS TTL ......................................... 15
- 2.9 Use of the Authority and Additional Sections .... 15
-3. Usage model ........................................... 16
- 3.1 LLMNR Configuration ............................. 17
-4. Conflict Resolution ................................... 18
- 4.1 Uniqueness Verification ......................... 19
- 4.2 Conflict Detection and Defense .................. 20
- 4.3 Considerations for Multiple Interfaces .......... 21
- 4.4 API issues ...................................... 22
-5. Security Considerations ............................... 22
- 5.1 Denial of Service ............................... 23
- 5.2 Spoofing ...............,........................ 23
- 5.3 Authentication .................................. 24
- 5.4 Cache and Port Separation ....................... 25
-6. IANA considerations ................................... 25
-7. Constants ............................................. 25
-8. References ............................................ 25
- 8.1 Normative References ............................ 25
- 8.2 Informative References .......................... 26
-Acknowledgments .............................................. 27
-Authors' Addresses ........................................... 28
-Intellectual Property Statement .............................. 28
-Disclaimer of Validity ....................................... 29
-Copyright Statement .......................................... 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which is based on the DNS packet format and supports all current and
- future DNS formats, types and classes. LLMNR operates on a separate
- port from the Domain Name System (DNS), with a distinct resolver
- cache.
-
- The goal of LLMNR is to enable name resolution in scenarios in which
- conventional DNS name resolution is not possible. Usage scenarios
- (discussed in more detail in Section 3.1) include situations in which
- hosts are not configured with the address of a DNS server; where the
- DNS server is unavailable or unreachable; where there is no DNS
- server authoritative for the name of a host, or where the
- authoritative DNS server does not have the desired RRs, as described
- in Section 2.
-
- Since LLMNR only operates on the local link, it cannot be considered
- a substitute for DNS. Link-scope multicast addresses are used to
- prevent propagation of LLMNR traffic across routers, potentially
- flooding the network. LLMNR queries can also be sent to a unicast
- address, as described in Section 2.4.
-
- Propagation of LLMNR packets on the local link is considered
- sufficient to enable name resolution in small networks. In such
- networks, if a network has a gateway, then typically the network is
- able to provide DNS server configuration. Configuration issues are
- discussed in Section 3.1.
-
- In the future, it may be desirable to consider use of multicast name
- resolution with multicast scopes beyond the link-scope. This could
- occur if LLMNR deployment is successful, the need arises for
- multicast name resolution beyond the link-scope, or multicast routing
- becomes ubiquitous. For example, expanded support for multicast name
- resolution might be required for mobile ad-hoc networks.
-
- Once we have experience in LLMNR deployment in terms of
- administrative issues, usability and impact on the network, it will
- be possible to reevaluate which multicast scopes are appropriate for
- use with multicast name resolution. IPv4 administratively scoped
- multicast usage is specified in "Administratively Scoped IP
- Multicast" [RFC2365].
-
- Service discovery in general, as well as discovery of DNS servers
- using LLMNR in particular, is outside of the scope of this document,
- as is name resolution over non-multicast capable media.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-1.1. Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
- and "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-Positively Resolved
- Responses with RCODE set to zero are referred to in this document
- as "positively resolved".
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An LLMNR responder considers one of its addresses reachable over a
- link if it will respond to an ARP or Neighbor Discovery query for
- that address received on that link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-UNIQUE
- There are some scenarios when multiple responders may respond to
- the same query. There are other scenarios when only one responder
- may respond to a query. Names for which only a single responder is
- anticipated are referred to as UNIQUE. Name uniqueness is
- configured on the responder, and therefore uniqueness verification
- is the responder's responsibility.
-
-2. Name Resolution Using LLMNR
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS. LLMNR queries are sent to and received on
- port 5355. The IPv4 link-scope multicast address a given responder
- listens to, and to which a sender sends queries, is 224.0.0.252. The
- IPv6 link-scope multicast address a given responder listens to, and
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
-
- Typically a host is configured as both an LLMNR sender and a
- responder. A host MAY be configured as a sender, but not a
- responder. However, a host configured as a responder MUST act as a
- sender, if only to verify the uniqueness of names as described in
- Section 4. This document does not specify how names are chosen or
- configured. This may occur via any mechanism, including DHCPv4
- [RFC2131] or DHCPv6 [RFC3315].
-
- LLMNR usage MAY be configured manually or automatically on a per
- interface basis. By default, LLMNR responders SHOULD be enabled on
- all interfaces, at all times. Enabling LLMNR for use in situations
- where a DNS server has been configured will result in a change in
- default behavior without a simultaneous update to configuration
- information. Where this is considered undesirable, LLMNR SHOULD NOT
- be enabled by default, so that hosts will neither listen on the link-
- scope multicast address, nor will they send queries to that address.
-
- By default, LLMNR queries MAY be sent only when one of the following
- conditions are met:
-
- [1] No manual or automatic DNS configuration has been performed.
- If DNS server address(es) have been configured, then LLMNR
- SHOULD NOT be used as the primary name resolution mechanism,
- although it MAY be used as a secondary name resolution
- mechanism. A dual stack host SHOULD attempt to reach DNS
- servers overall protocols on which DNS server address(es) are
- configured, prior to sending LLMNR queries. For dual stack
- hosts configured with DNS server address(es) for one protocol
- but not another, this inplies that DNS queries SHOULD be sent
- over the protocol configured with a DNS server, prior to
- sending LLMNR queries.
-
- [2] All attempts to resolve the name via DNS on all interfaces
- have failed after exhausting the searchlist. This can occur
- because DNS servers did not respond, or because they
- responded to DNS queries with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section. Where a
- single resolver call generates DNS queries for A and AAAA RRs,
- an implementation MAY choose not to send LLMNR queries if any
- of the DNS queries is successful. An LLMNR query SHOULD only
- be sent for the originally requested name; a searchlist
- is not used to form additional LLMNR queries.
-
- While these conditions are necessary for sending an LLMNR query, they
- are not sufficient. While an LLMNR sender MAY send a query for any
- name, it also MAY impose additional conditions on sending LLMNR
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- queries. For example, a sender configured with a DNS server MAY send
- LLMNR queries only for unqualified names and for fully qualified
- domain names within configured zones.
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] DNS servers are not configured or attempts to resolve the
- name via DNS have failed, after exhausting the searchlist.
- Also, the name to be queried satisfies the restrictions
- imposed by the implementation.
-
- [b] An LLMNR sender sends an LLMNR query to the link-scope
- multicast address(es), unless a unicast query is indicated,
- as specified in Section 2.4.
-
- [c] A responder responds to this query only if it is authoritative
- for the domain name in the query. A responder responds to a
- multicast query by sending a unicast UDP response to the sender.
- Unicast queries are responded to as indicated in Section 2.4.
-
- [d] Upon reception of the response, the sender processes it.
-
- The sections that follow provide further details on sender and
- responder behavior.
-
-2.1. LLMNR Packet Format
-
- LLMNR is based on the DNS packet format defined in [RFC1035] Section
- 4 for both queries and responses. LLMNR implementations SHOULD send
- UDP queries and responses only as large as are known to be
- permissible without causing fragmentation. When in doubt a maximum
- packet size of 512 octets SHOULD be used. LLMNR implementations MUST
- accept UDP queries and responses as large as the smaller of the link
- MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
- octets for the header, VLAN tag and CRC).
-
-2.1.1. LLMNR Header Format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value. For advice on generation of pseudo-random values, please
- consult [RFC1750].
-
-QR Query/Response. A one bit field, which if set indicates that the
- message is an LLMNR response; if clear then the message is an LLMNR
- query.
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-C Conflict. When set within a request, the 'C'onflict bit indicates
- that a sender has received multiple LLMNR responses to this query.
- In an LLMNR response, if the name is considered UNIQUE, then the
- 'C' bit is clear, otherwise it is set. LLMNR senders do not
- retransmit queries with the 'C' bit set. Responders MUST NOT
- respond to LLMNR queries with the 'C' bit set, but may start the
- uniqueness verification process, as described in Section 4.2.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set in an LLMNR response,
- then the sender SHOULD discard the response and resend the LLMNR
- query over TCP using the unicast address of the responder as the
- destination address. See [RFC2181] and Section 2.4 of this
- specification for further discussion of the TC bit.
-
-T Tentative. The 'T'entative bit is set in a response if the
- responder is authoritative for the name, but has not yet verified
- the uniqueness of the name. A responder MUST ignore the 'T' bit in
- a query, if set. A response with the 'T' bit set is silently
- discarded by the sender, except if it is a uniqueness query, in
- which case a conflict has been detected and a responder MUST
- resolve the conflict as described in Section 4.1.
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the sender MUST set RCODE to zero;
- the responder ignores the RCODE and assumes it to be zero. The
- response to a multicast LLMNR query MUST have RCODE set to zero. A
- sender MUST silently discard an LLMNR response with a non-zero
- RCODE sent in response to a multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferable to not
- sending a response, since it enables errors to be diagnosed.
- Errors include those defined in [RFC2845], such as BADSIG(16),
- BADKEY(17) and BADTIME(18).
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9. LLMNR
- responders MUST silently discard LLMNR queries with NSCOUNT not
- equal to zero.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender Behavior
-
- A sender MAY send an LLMNR query for any legal resource record type
- (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
- As described in Section 2.4, a sender MAY also send a unicast query.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope. If no response is received, a resolver treats it as a
- response that the name does not exist (RCODE=3 is returned). A
- sender can handle duplicate responses by discarding responses with a
- source IP address and ID field that duplicate a response already
- received.
-
- When multiple valid LLMNR responses are received with the 'C' bit
- set, they SHOULD be concatenated and treated in the same manner that
- multiple RRs received from the same DNS server would be. However,
- responses with the 'C' bit set SHOULD NOT be concatenated with
- responses with the 'C' bit clear; instead, only the responses with
- the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
- received along with error response(s), then the error responses are
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- silently discarded.
-
- If error responses are received from both DNS and LLMNR, then the
- lowest RCODE value should be returned. For example, if either DNS or
- LLMNR receives a response with RCODE=0, then this should returned to
- the caller.
-
- Since the responder may order the RRs in the response so as to
- indicate preference, the sender SHOULD preserve ordering in the
- response to the querying application.
-
-2.3. Responder Behavior
-
- An LLMNR response MUST be sent to the sender via unicast.
-
- Upon configuring an IP address, responders typically will synthesize
- corresponding A, AAAA and PTR RRs so as to be able to respond to
- LLMNR queries for these RRs. An SOA RR is synthesized only when a
- responder has another RR in addition to the SOA RR; the SOA RR MUST
- NOT be the only RR that a responder has. However, in general whether
- RRs are manually or automatically created is an implementation
- decision.
-
- For example, a host configured to have computer name "host1" and to
- be a member of the "example.com" domain, and with IPv4 address
- 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.2.0.192.in-addr.arpa. IN PTR host1.
- IN PTR host1.example.com.
-
- 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
- ip6.arpa IN PTR host1. (line split for formatting reasons)
- IN PTR host1.example.com.
-
- An LLMNR responder might be further manually configured with the name
- of a local mail server with an MX RR included in the "host1." and
- "host1.example.com." records.
-
- In responding to queries:
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
- address(es) defined in Section 2, and on UDP and TCP port 5355 on
- the unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses MUST always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups, with the exception of queries with the 'C' bit
- set, which do not elicit a response.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-[e] Responders MUST NOT respond using data from the LLMNR or DNS
- resolver cache.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it MUST respond with
- RCODE=0 and an empty answer section, if the type of query does not
- match a RR that the responder has.
-
- As an example, a host configured to respond to LLMNR queries for the
- name "foo.example.com." is authoritative for the name
- "foo.example.com.". On receiving an LLMNR query for an A RR with the
- name "foo.example.com." the host authoritatively responds with A
- RR(s) that contain IP address(es) in the RDATA of the resource
- record. If the responder has a AAAA RR, but no A RR, and an A RR
- query is received, the responder would respond with RCODE=0 and an
- empty answer section.
-
- In conventional DNS terminology a DNS server authoritative for a zone
- is authoritative for all the domain names under the zone apex except
- for the branches delegated into separate zones. Contrary to
- conventional DNS terminology, an LLMNR responder is authoritative
- only for the zone apex.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- For example the host "foo.example.com." is not authoritative for the
- name "child.foo.example.com." unless the host is configured with
- multiple names, including "foo.example.com." and
- "child.foo.example.com.". As a result, "foo.example.com." cannot
- reply to an LLMNR query for "child.foo.example.com." with RCODE=3
- (authoritative name error). The purpose of limiting the name
- authority scope of a responder is to prevent complications that could
- be caused by coexistence of two or more hosts with the names
- representing child and parent (or grandparent) nodes in the DNS tree,
- for example, "foo.example.com." and "child.foo.example.com.".
-
- Without the restriction on authority an LLMNR query for an A resource
- record for the name "child.foo.example.com." would result in two
- authoritative responses: RCODE=3 (authoritative name error) received
- from "foo.example.com.", and a requested A record - from
- "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
- hosts could perform a dynamic update of the parent (or grandparent)
- zone with a delegation to a child zone; for example a host
- "child.foo.example.com." could send a dynamic update for the NS and
- glue A record to "foo.example.com.". However, this approach
- significantly complicates implementation of LLMNR and would not be
- acceptable for lightweight hosts.
-
-2.4. Unicast Queries and Responses
-
- Unicast queries SHOULD be sent when:
-
- [a] A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
-
- [b] The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-
- Unicast LLMNR queries MUST be done using TCP and the responses MUST
- be sent using the same TCP connection as the query. Senders MUST
- support sending TCP queries, and responders MUST support listening
- for TCP queries. If the sender of a TCP query receives a response to
- that query not using TCP, the response MUST be silently discarded.
-
- Unicast UDP queries MUST be silently discarded.
-
- If TCP connection setup cannot be completed in order to send a
- unicast TCP query, this is treated as a response that no records of
- the specified type and class exist for the specified name (it is
- treated the same as a response with RCODE=0 and an empty answer
- section).
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-2.5. "Off link" Detection
-
- A sender MUST select a source address for LLMNR queries that is
- assigned on the interface on which the query is sent. The
- destination address of an LLMNR query MUST be a link-scope multicast
- address or a unicast address.
-
- A responder MUST select a source address for responses that is
- assigned on the interface on which the query was received. The
- destination address of an LLMNR response MUST be a unicast address.
-
- On receiving an LLMNR query, the responder MUST check whether it was
- sent to a LLMNR multicast addresses defined in Section 2. If it was
- sent to another multicast address, then the query MUST be silently
- discarded.
-
- Section 2.4 discusses use of TCP for LLMNR queries and responses. In
- composing an LLMNR query using TCP, the sender MUST set the Hop Limit
- field in the IPv6 header and the TTL field in the IPv4 header of the
- response to one (1). The responder SHOULD set the TTL or Hop Limit
- settings on the TCP listen socket to one (1) so that SYN-ACK packets
- will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
- prevents an incoming connection from off-link since the sender will
- not receive a SYN-ACK from the responder.
-
- For UDP queries and responses, the Hop Limit field in the IPv6 header
- and the TTL field in the IPV4 header MAY be set to any value.
- However, it is RECOMMENDED that the value 255 be used for
- compatibility with Apple Bonjour [Bonjour].
-
- Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and
- IP_MULTICAST_TTL socket options are used to set the TTL of
- outgoing unicast and multicast packets. The IP_RECVTTL socket
- option is available on some platforms to retrieve the IPv4 TTL of
- received packets with recvmsg(). [RFC2292] specifies similar
- options for setting and retrieving the IPv6 Hop Limit.
-
-2.6. Responder Responsibilities
-
- It is the responsibility of the responder to ensure that RRs returned
- in LLMNR responses MUST only include values that are valid on the
- local interface, such as IPv4 or IPv6 addresses valid on the local
- link or names defended using the mechanism described in Section 4.
- IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
- addresses are defined in [RFC2373]. In particular:
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- [a] If a link-scope IPv6 address is returned in a AAAA RR,
- that address MUST be valid on the local link over which
- LLMNR is used.
-
- [b] If an IPv4 address is returned, it MUST be reachable
- through the link over which LLMNR is used.
-
- [c] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be resolvable on the local
- link over which LLMNR is used.
-
- Where multiple addresses represent valid responses to a query, the
- order in which the addresses are returned is as follows:
-
- [d] If the source address of the query is a link-scope address,
- then the responder SHOULD include a link-scope address first
- in the response, if available.
-
- [e] If the source address of the query is a routable address,
- then the responder MUST include a routable address first
- in the response, if available.
-
-2.7. Retransmission and Jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query. An LLMNR sender SHOULD either
- estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
- high initial timeout. Suggested constants are described in Section
- 7.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender SHOULD repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it,
- while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR
- query SHOULD NOT be sent more than three times.
-
- Where LLMNR queries are sent using TCP, retransmission is handled by
- the transport layer. Queries with the 'C' bit set MUST be sent using
- multicast UDP and MUST NOT be retransmitted.
-
- An LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
- has been received, or if it is necessary to collect all potential
- responses, such as if a uniqueness verification query is being made.
- Otherwise an LLMNR sender SHOULD consider a multicast query answered
- after the first response is received, if that response has the 'C'
- bit clear.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- However, if the first response has the 'C' bit set, then the sender
- SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
- responses. When multiple valid answers are received, they may first
- be concatenated, and then treated in the same manner that multiple
- RRs received from the same DNS server would. A unicast query sender
- considers the query answered after the first response is received, so
- that it only waits for LLMNR_TIMEOUT if no response has been
- received.
-
- Since it is possible for a response with the 'C' bit clear to be
- followed by a response with the 'C' bit set, an LLMNR sender SHOULD
- be prepared to process additional responses for the purposes of
- conflict detection and LLMNR_TIMEOUT estimation, even after it has
- considered a query answered.
-
- In order to avoid synchronization, the transmission of each LLMNR
- query and response SHOULD delayed by a time randomly selected from
- the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
- responders responding with names which they have previously
- determined to be UNIQUE (see Section 4 for details).
-
-2.8. DNS TTL
-
- The responder should insert a pre-configured TTL value in the records
- returned in an LLMNR response. A default value of 30 seconds is
- RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
- networks), the TTL value may need to be reduced.
-
- Due to the TTL minimalization necessary when caching an RRset, all
- TTLs in an RRset MUST be set to the same value.
-
-2.9. Use of the Authority and Additional Sections
-
- Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
- concept of delegation. In LLMNR, the NS resource record type may be
- stored and queried for like any other type, but it has no special
- delegation semantics as it does in the DNS. Responders MAY have NS
- records associated with the names for which they are authoritative,
- but they SHOULD NOT include these NS records in the authority
- sections of responses.
-
- Responders SHOULD insert an SOA record into the authority section of
- a negative response, to facilitate negative caching as specified in
- [RFC2308]. The TTL of this record is set from the minimum of the
- MINIMUM field of the SOA record and the TTL of the SOA itself, and
- indicates how long a resolver may cache the negative answer. The
- owner name of the SOA record (MNAME) MUST be set to the query name.
- The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- by senders. Negative responses without SOA records SHOULD NOT be
- cached.
-
- In LLMNR, the additional section is primarily intended for use by
- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
- senders MAY only include pseudo RR-types in the additional section of
- a query; unless the 'C' bit is set, responders MUST ignore the
- additional section of queries containing other RR types.
-
- In queries where the 'C' bit is set, the sender SHOULD include the
- conflicting RRs in the additional section. Since conflict
- notifications are advisory, responders SHOULD log information from
- the additional section, but otherwise MUST ignore the additional
- section.
-
- Senders MUST NOT cache RRs from the authority or additional section
- of a response as answers, though they may be used for other purposes
- such as negative caching.
-
-3. Usage Model
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. This
- document does not specify any changes to DNS resolver behavior, such
- as searchlist processing or retransmission/failover policy. However,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
- significant fraction of DNS queries do not receive a response, or
- result in negative responses due to missing inverse mappings or NS
- records that point to nonexistent or inappropriate hosts. This has
- the potential to result in a large number of unnecessary LLMNR
- queries.
-
- [RFC1536] describes common DNS implementation errors and fixes. If
- the proposed fixes are implemented, unnecessary LLMNR queries will be
- reduced substantially, and so implementation of [RFC1536] is
- recommended.
-
- For example, [RFC1536] Section 1 describes issues with retransmission
- and recommends implementation of a retransmission policy based on
- round trip estimates, with exponential backoff. [RFC1536] Section 4
- describes issues with failover, and recommends that resolvers try
- another server when they don't receive a response to a query. These
- policies are likely to avoid unnecessary LLMNR queries.
-
- [RFC1536] Section 3 describes zero answer bugs, which if addressed
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- will also reduce unnecessary LLMNR queries.
-
- [RFC1536] Section 6 describes name error bugs and recommended
- searchlist processing that will reduce unnecessary RCODE=3
- (authoritative name) errors, thereby also reducing unnecessary LLMNR
- queries.
-
-3.1. LLMNR Configuration
-
- Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
- possible for a dual stack host to be configured with the address of a
- DNS server over IPv4, while remaining unconfigured with a DNS server
- suitable for use over IPv6.
-
- In these situations, a dual stack host will send AAAA queries to the
- configured DNS server over IPv4. However, an IPv6-only host
- unconfigured with a DNS server suitable for use over IPv6 will be
- unable to resolve names using DNS. Automatic IPv6 DNS configuration
- mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
- deployed, and not all DNS servers support IPv6. Therefore lack of
- IPv6 DNS configuration may be a common problem in the short term, and
- LLMNR may prove useful in enabling link-local name resolution over
- IPv6.
-
- Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
- IPv6-only hosts may not be configured with a DNS server. Where there
- is no DNS server authoritative for the name of a host or the
- authoritative DNS server does not support dynamic client update over
- IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
- be able to do DNS dynamic update, and other hosts will not be able to
- resolve its name.
-
- For example, if the configured DNS server responds to a AAAA RR query
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
- RCODE=0 and an empty answer section, then a AAAA RR query sent using
- LLMNR over IPv6 may be successful in resolving the name of an
- IPv6-only host on the local link.
-
- Similarly, if a DHCPv4 server is available providing DNS server
- configuration, and DNS server(s) exist which are authoritative for
- the A RRs of local hosts and support either dynamic client update
- over IPv4 or DHCPv4-based dynamic update, then the names of local
- IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
- DNS server is authoritative for the names of local hosts, or the
- authoritative DNS server(s) do not support dynamic update, then LLMNR
- enables linklocal name resolution over IPv4.
-
- Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- configure LLMNR on an interface. The LLMNR Enable Option, described
- in [LLMNREnable], can be used to explicitly enable or disable use of
- LLMNR on an interface. The LLMNR Enable Option does not determine
- whether or in which order DNS itself is used for name resolution.
- The order in which various name resolution mechanisms should be used
- can be specified using the Name Service Search Option (NSSO) for DHCP
- [RFC2937], using the LLMNR Enable Option code carried in the NSSO
- data.
-
- It is possible that DNS configuration mechanisms will go in and out
- of service. In these circumstances, it is possible for hosts within
- an administrative domain to be inconsistent in their DNS
- configuration.
-
- For example, where DHCP is used for configuring DNS servers, one or
- more DHCP servers can fail. As a result, hosts configured prior to
- the outage will be configured with a DNS server, while hosts
- configured after the outage will not. Alternatively, it is possible
- for the DNS configuration mechanism to continue functioning while
- configured DNS servers fail.
-
- An outage in the DNS configuration mechanism may result in hosts
- continuing to use LLMNR even once the outage is repaired. Since
- LLMNR only enables linklocal name resolution, this represents a
- degradation in capabilities. As a result, hosts without a configured
- DNS server may wish to periodically attempt to obtain DNS
- configuration if permitted by the configuration mechanism in use. In
- the absence of other guidance, a default retry interval of one (1)
- minute is RECOMMENDED.
-
-4. Conflict Resolution
-
- By default, a responder SHOULD be configured to behave as though its
- name is UNIQUE on each interface on which LLMNR is enabled. However,
- it is also possible to configure multiple responders to be
- authoritative for the same name. For example, multiple responders
- MAY respond to a query for an A or AAAA type record for a cluster
- name (assigned to multiple hosts in the cluster).
-
- To detect duplicate use of a name, an administrator can use a name
- resolution utility which employs LLMNR and lists both responses and
- responders. This would allow an administrator to diagnose behavior
- and potentially to intervene and reconfigure LLMNR responders who
- should not be configured to respond to the same name.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-4.1. Uniqueness Verification
-
- Prior to sending an LLMNR response with the 'T' bit clear, a
- responder configured with a UNIQUE name MUST verify that there is no
- other host within the scope of LLMNR query propagation that is
- authoritative for the same name on that interface.
-
- Once a responder has verified that its name is UNIQUE, if it receives
- an LLMNR query for that name, with the 'C' bit clear, it MUST
- respond, with the 'T' bit clear. Prior to verifying that its name is
- UNIQUE, a responder MUST set the 'T' bit in responses.
-
- Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive
- during sleep)
- - is configured to respond to LLMNR queries on an interface
- enabled for transmission and reception of IP traffic
- - is configured to respond to LLMNR queries using additional
- UNIQUE resource records
- - verifies the acquisition of a new IP address and configuration
- on an interface
-
- To verify uniqueness, a responder MUST send an LLMNR query with the
- 'C' bit clear, over all protocols on which it responds to LLMNR
- queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
- uniqueness of a name by sending a query for the name with type='ANY'.
-
- If no response is received, the sender retransmits the query, as
- specified in Section 2.7. If a response is received, the sender MUST
- check if the source address matches the address of any of its
- interfaces; if so, then the response is not considered a conflict,
- since it originates from the sender. To avoid triggering conflict
- detection, a responder that detects that it is connected to the same
- link on multiple interfaces SHOULD set the 'C' bit in responses.
-
- If a response is received with the 'T' bit clear, the responder MUST
- NOT use the name in response to LLMNR queries received over any
- protocol (IPv4 or IPv6). If a response is received with the 'T' bit
- set, the responder MUST check if the source IP address in the
- response, interpreted as an unsigned integer, is less than the source
- IP address in the query. If so, the responder MUST NOT use the name
- in response to LLMNR queries received over any protocol (IPv4 or
- IPv6). For the purpose of uniqueness verification, the contents of
- the answer section in a response is irrelevant.
-
- Periodically carrying out uniqueness verification in an attempt to
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- detect name conflicts is not necessary, wastes network bandwidth, and
- may actually be detrimental. For example, if network links are
- joined only briefly, and are separated again before any new
- communication is initiated, temporary conflicts are benign and no
- forced reconfiguration is required. LLMNR responders SHOULD NOT
- periodically attempt uniqueness verification.
-
-4.2. Conflict Detection and Defense
-
- Hosts on disjoint network links may configure the same name for use
- with LLMNR. If these separate network links are later joined or
- bridged together, then there may be multiple hosts which are now on
- the same link, trying to use the same name.
-
- In order to enable ongoing detection of name conflicts, when an LLMNR
- sender receives multiple LLMNR responses to a query, it MUST check if
- the 'C' bit is clear in any of the responses. If so, the sender
- SHOULD send another query for the same name, type and class, this
- time with the 'C' bit set, with the potentially conflicting resource
- records included in the additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict before acting on it. A
- responder receiving a query with the 'C' bit set MUST NOT respond.
-
- If the query is for a UNIQUE name, then the responder MUST send its
- own query for the same name, type and class, with the 'C' bit clear.
- If a response is received, the sender MUST check if the source
- address matches the address of any of its interfaces; if so, then the
- response is not considered a conflict, since it originates from the
- sender. To avoid triggering conflict detection, a responder that
- detects that it is connected to the same link on multiple interfaces
- SHOULD set the 'C' bit in responses.
-
- An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
- log them. Upon detecting a conflict, an LLMNR responder MUST
- immediately stop using the conflicting name in response to LLMNR
- queries received over any supported protocol, if the source IP
- address in the response, interpreted as an unsigned integer, is less
- than the source IP address in the uniqueness verification query.
-
- After stopping the use of a name, the responder MAY elect to
- configure a new name. However, since name reconfiguration may be
- disruptive, this is not required, and a responder may have been
- configured to respond to multiple names so that alternative names may
- already be available. A host that has stopped the use of a name may
- attempt uniqueness verification again after the expiration of the TTL
- of the conflicting response.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-4.3. Considerations for Multiple Interfaces
-
- A multi-homed host may elect to configure LLMNR on only one of its
- active interfaces. In many situations this will be adequate.
- However, should a host need to configure LLMNR on more than one of
- its active interfaces, there are some additional precautions it MUST
- take. Implementers who are not planning to support LLMNR on multiple
- interfaces simultaneously may skip this section.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface maintains its own independent LLMNR
- resolver cache, containing the responses to LLMNR queries.
-
- A multi-homed host checks the uniqueness of UNIQUE records as
- described in Section 4. The situation is illustrated in figure 1.
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
- In this situation, the multi-homed myhost will probe for, and defend,
- its host name on both interfaces. A conflict will be detected on one
- interface, but not the other. The multi-homed myhost will not be
- able to respond with a host RR for "myhost" on the interface on the
- right (see Figure 1). The multi-homed host may, however, be
- configured to use the "myhost" name on the interface on the left.
-
- Since names are only unique per-link, hosts on different links could
- be using the same name. If an LLMNR client sends requests over
- multiple interfaces, and receives replies from more than one, the
- result returned to the client is defined by the implementation. The
- situation is illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
- If host myhost is configured to use LLMNR on both interfaces, it will
- send LLMNR queries on both interfaces. When host myhost sends a
- query for the host RR for name "A" it will receive a response from
- hosts on both interfaces.
-
- Host myhost cannot distinguish between the situation shown in Figure
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
- This illustrates that the proposed name conflict resolution mechanism
- does not support detection or resolution of conflicts between hosts
- on different links. This problem can also occur with DNS when a
- multi-homed host is connected to two different networks with
- separated name spaces. It is not the intent of this document to
- address the issue of uniqueness of names within DNS.
-
-4.4. API Issues
-
- [RFC2553] provides an API which can partially solve the name
- ambiguity problem for applications written to use this API, since the
- sockaddr_in6 structure exposes the scope within which each scoped
- address exists, and this structure can be used for both IPv4 (using
- v4-mapped IPv6 addresses) and IPv6 addresses.
-
- Following the example in Figure 2, an application on 'myhost' issues
- the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
- ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
- interfaces and the resolver library will return a list containing
- multiple addrinfo structures, each with an associated sockaddr_in6
- structure. This list will thus contain the IPv4 and IPv6 addresses
- of both hosts responding to the name 'A'. Link-local addresses will
- have a sin6_scope_id value that disambiguates which interface is used
- to reach the address. Of course, to the application, Figures 2 and 3
- are still indistinguishable, but this API allows the application to
- communicate successfully with any address in the list.
-
-5. Security Considerations
-
- LLMNR is a peer-to-peer name resolution protocol designed for use on
- the local link. While LLMNR limits the vulnerability of responders
- to off-link senders, it is possible for an off-link responder to
- reach a sender.
-
- In scenarios such as public "hotspots" attackers can be present on
- the same link. These threats are most serious in wireless networks
- such as 802.11, since attackers on a wired network will require
- physical access to the network, while wireless attackers may mount
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- attacks from a distance. Link-layer security such as [IEEE-802.11i]
- can be of assistance against these threats if it is available.
-
- This section details security measures available to mitigate threats
- from on and off-link attackers.
-
-5.1. Denial of Service
-
- Attackers may take advantage of LLMNR conflict detection by
- allocating the same name, denying service to other LLMNR responders
- and possibly allowing an attacker to receive packets destined for
- other hosts. By logging conflicts, LLMNR responders can provide
- forensic evidence of these attacks.
-
- An attacker may spoof LLMNR queries from a victim's address in order
- to mount a denial of service attack. Responders setting the IPv6 Hop
- Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
- response may be able to reach the victim across the Internet.
-
- While LLMNR responders only respond to queries for which they are
- authoritative and LLMNR does not provide wildcard query support, an
- LLMNR response may be larger than the query, and an attacker can
- generate multiple responses to a query for a name used by multiple
- responders. A sender may protect itself against unsolicited
- responses by silently discarding them as rapidly as possible.
-
-5.2. Spoofing
-
- LLMNR is designed to prevent reception of queries sent by an off-link
- attacker. LLMNR requires that responders receiving UDP queries check
- that they are sent to a link-scope multicast address. However, it is
- possible that some routers may not properly implement link-scope
- multicast, or that link-scope multicast addresses may leak into the
- multicast routing system. To prevent successful setup of TCP
- connections by an off-link sender, responders receiving a TCP SYN
- reply with a TCP SYN-ACK with TTL set to one (1).
-
- While it is difficult for an off-link attacker to send an LLMNR query
- to a responder, it is possible for an off-link attacker to spoof a
- response to a query (such as an A or AAAA query for a popular
- Internet host), and by using a TTL or Hop Limit field larger than one
- (1), for the forged response to reach the LLMNR sender. Since the
- forged response will only be accepted if it contains a matching ID
- field, choosing a pseudo-random ID field within queries provides some
- protection against off-link responders.
-
- Since LLMNR queries can be sent when DNS server(s) do not respond, an
- attacker can execute a denial of service attack on the DNS server(s)
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- and then poison the LLMNR cache by responding to an LLMNR query with
- incorrect information. As noted in "Threat Analysis of the Domain
- Name System (DNS)" [RFC3833] these threats also exist with DNS, since
- DNS response spoofing tools are available that can allow an attacker
- to respond to a query more quickly than a distant DNS server.
- However, while switched networks or link layer security may make it
- difficult for an on-link attacker to snoop unicast DNS queries,
- multicast LLMNR queries are propagated to all hosts on the link,
- making it possible for an on-link attacker to spoof LLMNR responses
- without having to guess the value of the ID field in the query.
-
- Since LLMNR queries are sent and responded to on the local-link, an
- attacker will need to respond more quickly to provide its own
- response prior to arrival of the response from a legitimate
- responder. If an LLMNR query is sent for an off-link host, spoofing
- a response in a timely way is not difficult, since a legitimate
- response will never be received.
-
- Limiting the situations in which LLMNR queries are sent, as described
- in Section 2, is the best protection against these attacks. If LLMNR
- is given higher priority than DNS among the enabled name resolution
- mechanisms, a denial of service attack on the DNS server would not be
- necessary in order to poison the LLMNR cache, since LLMNR queries
- would be sent even when the DNS server is available. In addition,
- the LLMNR cache, once poisoned, would take precedence over the DNS
- cache, eliminating the benefits of cache separation. As a result,
- LLMNR is only used as a name resolution mechanism of last resort.
-
-5.3. Authentication
-
- LLMNR is a peer-to-peer name resolution protocol, and as a result,
- it is often deployed in situations where no trust model can be
- assumed. This makes it difficult to apply existing DNS security
- mechanisms to LLMNR.
-
- LLMNR does not support "delegated trust" (CD or AD bits). As a
- result, unless LLMNR senders are DNSSEC aware, it is not feasible to
- use DNSSEC [RFC4033] with LLMNR.
-
- If authentication is desired, and a pre-arranged security
- configuration is possible, then the following security mechanisms may
- be used:
-
-[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
- [RFC2931] security mechanisms. "DNS Name Service based on Secure
- Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
- the use of TSIG to secure LLMNR responses, based on group keys.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[b] IPsec ESP with a null-transform MAY be used to authenticate unicast
- LLMNR queries and responses or LLMNR responses to multicast
- queries. In a small network without a certificate authority, this
- can be most easily accomplished through configuration of a group
- pre-shared key for trusted hosts.
-
- Where these mechanisms cannot be supported, responses to LLMNR
- queries may be unauthenticated.
-
-5.4. Cache and Port Separation
-
- In order to prevent responses to LLMNR queries from polluting the DNS
- cache, LLMNR implementations MUST use a distinct, isolated cache for
- LLMNR on each interface. The use of separate caches is most
- effective when LLMNR is used as a name resolution mechanism of last
- resort, since this minimizes the opportunities for poisoning the
- LLMNR cache, and decreases reliance on it.
-
- LLMNR operates on a separate port from DNS, reducing the likelihood
- that a DNS server will unintentionally respond to an LLMNR query.
-
-6. IANA Considerations
-
- This specification creates one new name space: the reserved bits in
- the LLMNR header. These are allocated by IETF Consensus, in
- accordance with BCP 26 [RFC2434].
-
- LLMNR requires allocation of port 5355 for both TCP and UDP.
-
- LLMNR requires allocation of link-scope multicast IPv4 address
- 224.0.0.252, as well as link-scope multicast IPv6 address
- FF02:0:0:0:0:0:1:3.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
- 100 ms (IEEE 802 media, including IEEE 802.11)
-
-8. References
-
-8.1. Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-8.2. Informative References
-
-[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
- (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
- June 2005.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-[IEEE-802.11i]
- Institute of Electrical and Electronics Engineers, "Supplement
- to Standard for Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements - Part 11:
- Wireless LAN Medium Access Control (MAC) and Physical Layer
- (PHY) Specifications: Specification for Enhanced Security",
- IEEE 802.11i, July 2004.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
- Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
- Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
- 2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirement", RFC 4033, March
- 2005.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-Acknowledgments
-
- This work builds upon original work done on multicast DNS by Bill
- Manning and Bill Woodcock. Bill Manning's work was funded under
- DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
- their contribution to the current specification. Constructive input
- has also been received from Mark Andrews, Rob Austein, Randy Bush,
- Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
- Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
- Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
- Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
- St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- EMail: bernarda@microsoft.com
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 703 8835
- EMail: dthaler@microsoft.com
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 28]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 29]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
deleted file mode 100644
index cc3c276b99a72..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
+++ /dev/null
@@ -1,2072 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 5b6d655297e8e..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
+++ /dev/null
@@ -1,464 +0,0 @@
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: January 2006 July 2005
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-06.txt>
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method of encoding US Government Digital Signature
- Algorithm keying and signature information for use in the Domain Name
- System is specified.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DSA Keying Information..................................3
- 3. DSA Signature Information...............................4
- 4. Performance Considerations..............................4
- 5. Security Considerations.................................5
- 6. IANA Considerations.....................................5
- Copyright and Disclaimer...................................5
-
- Normative References.......................................7
- Informative References.....................................7
-
- Authors Address............................................8
- Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additional work is underway which would
- require the storage of keying and signature information in the DNS.
-
- This document describes how to encode US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
- When DSA public keys are stored in the DNS, the structure of the
- relevant part of the RDATA part of the RR being used is the fields
- listed below in the order given.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- Field Size
- ----- ----
- T 1 octet
- Q 20 octets
- P 64 + T*8 octets
- G 64 + T*8 octets
- Y 64 + T*8 octets
-
- As described in [FIPS 186-2] and [Schneier], T is a key size
- parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
- is greater than 8 is reserved and the remainder of the data may have
- a different format in that case.) Q is a prime number selected at
- key generation time such that 2**159 < Q < 2**160. Thus Q is always
- 20 octets long and, as with all other fields, is stored in "big-
- endian" network order. P, G, and Y are calculated as directed by the
- [FIPS 186-2] key generation algorithm [Schneier]. P is in the range
- 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
- and Y are quantities modulo P and so can be up to the same length as
- P and are allocated fixed size fields with the same number of octets
- as P.
-
- During the key generation process, a random number X must be
- generated such that 1 <= X <= Q-1. X is the private key and is used
- in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd [Page 3]
-
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
- The portion of the RDATA area used for US Digital Signature Algorithm
- signature information is shown below with fields in the order they
- are listed and the contents of each multi-octet field in "big-endian"
- network order.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- First, the data signed must be determined. Then the following steps
- are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
- specified in the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate a random K such that 0 < K < Q.
-
- R = ( G**K mod P ) mod Q
-
- S = ( K**(-1) * (hash + X*R) ) mod Q
-
- For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
- 3174].
-
- Since Q is 160 bits long, R and S can not be larger than 20 octets,
- which is the space allocated.
-
- T is copied from the public key. It is not logically necessary in
- the SIG but is present so that values of T > 8 can more conveniently
- be used as an escape for extended versions of DSA or other algorithms
- as later standardized.
-
-
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 3110] and DSA. With sufficient pre-computation, signature generation
- with DSA is faster than RSA. Key generation is also faster for DSA.
- However, signature verification is an order of magnitude slower than
- RSA when the RSA public exponent is chosen to be small, as is
- recommended for some applications.
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying and/or signature
- inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
- current DSA standard may limit the security of DSA. For particular
- applications, implementors are encouraged to consider the range of
- available algorithms and key sizes.
-
- DSA assumes the ability to frequently generate high quality random
- numbers. See [random] for guidance. DSA is designed so that if
- biased rather than random numbers are used, high bandwidth covert
- channels are possible. See [Schneier] and more recent research. The
- leakage of an entire DSA private key in only two DSA signatures has
- been demonstrated. DSA provides security only if trusted
- implementations, including trusted random number generation, are
- used.
-
-
-
-6. IANA Considerations
-
- Allocation of meaning to values of the T parameter that are not
- defined herein (i.e., > 8 ) requires an IETF standards actions. It
- is intended that values unallocated herein be used to cover future
- extensions of the DSS standard.
-
-
-
-Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative References
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, 11/01/1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, 11/01/1987.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS)", D. Eastlake 3rd. May 2001.
-
- [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
- Jones, September 2001.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [Schneier] - "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C" (second edition), Bruce Schneier,
- 1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Authors Address
-
- Donald E. Eastlake 3rd
- Motorola Labortories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in January 2006.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
deleted file mode 100644
index 2ec9dbec512ec..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-Network Working Group S. Josefsson
-Internet-Draft August 30, 2005
-Expires: March 3, 2006
-
-
- Storing Certificates in the Domain Name System (DNS)
- draft-ietf-dnsext-rfc2538bis-04
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 3, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- Cryptographic public keys are frequently published and their
- authenticity demonstrated by certificates. A CERT resource record
- (RR) is defined so that such certificates and related certificate
- revocation lists can be stored in the Domain Name System (DNS).
-
- This document obsoletes RFC 2538.
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 1]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
- 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4
- 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5
- 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
- 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
- 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
- 3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9
- 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
- 3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
- 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10
- 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
- Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 2]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-1. Introduction
-
- Public keys are frequently published in the form of a certificate and
- their authenticity is commonly demonstrated by certificates and
- related certificate revocation lists (CRLs). A certificate is a
- binding, through a cryptographic digital signature, of a public key,
- a validity interval and/or conditions, and identity, authorization,
- or other information. A certificate revocation list is a list of
- certificates that are revoked, and incidental information, all signed
- by the signer (issuer) of the revoked certificates. Examples are
- X.509 certificates/CRLs in the X.500 directory system or OpenPGP
- certificates/revocations used by OpenPGP software.
-
- Section 2 below specifies a CERT resource record (RR) for the storage
- of certificates in the Domain Name System [1] [2].
-
- Section 3 discusses appropriate owner names for CERT RRs.
-
- Sections 4, 5, and 6 below cover performance, IANA, and security
- considerations, respectively.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [3].
-
-
-2. The CERT Resource Record
-
- The CERT resource record (RR) has the structure given below. Its RR
- type code is 37.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | type | key tag |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | algorithm | /
- +---------------+ certificate or CRL /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
- The type field is the certificate type as defined in section 2.1
- below.
-
- The key tag field is the 16 bit value computed for the key embedded
- in the certificate, using the RRSIG Key Tag algorithm described in
- Appendix B of [10]. This field is used as an efficiency measure to
- pick which CERT RRs may be applicable to a particular key. The key
-
-
-
-Josefsson Expires March 3, 2006 [Page 3]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- tag can be calculated for the key in question and then only CERT RRs
- with the same key tag need be examined. However, the key must always
- be transformed to the format it would have as the public key portion
- of a DNSKEY RR before the key tag is computed. This is only possible
- if the key is applicable to an algorithm (and limits such as key size
- limits) defined for DNS security. If it is not, the algorithm field
- MUST BE zero and the tag field is meaningless and SHOULD BE zero.
-
- The algorithm field has the same meaning as the algorithm field in
- DNSKEY and RRSIG RRs [10], except that a zero algorithm field
- indicates the algorithm is unknown to a secure DNS, which may simply
- be the result of the algorithm not having been standardized for
- DNSSEC.
-
-2.1. Certificate Type Values
-
- The following values are defined or reserved:
-
- Value Mnemonic Certificate Type
- ----- -------- ----------------
- 0 reserved
- 1 PKIX X.509 as per PKIX
- 2 SPKI SPKI certificate
- 3 PGP OpenPGP packet
- 4 IPKIX The URL of an X.509 data object
- 5 ISPKI The URL of an SPKI certificate
- 6 IPGP The URL of an OpenPGP packet
- 7-252 available for IANA assignment
- 253 URI URI private
- 254 OID OID private
- 255-65534 available for IANA assignment
- 65535 reserved
-
- The PKIX type is reserved to indicate an X.509 certificate conforming
- to the profile being defined by the IETF PKIX working group. The
- certificate section will start with a one-byte unsigned OID length
- and then an X.500 OID indicating the nature of the remainder of the
- certificate section (see 2.3 below). (NOTE: X.509 certificates do
- not include their X.500 directory type designating OID as a prefix.)
-
- The SPKI type is reserved to indicate the SPKI certificate format
- [13], for use when the SPKI documents are moved from experimental
- status.
-
- The PGP type indicates an OpenPGP packet as described in [6] and its
- extensions and successors. Two uses are to transfer public key
- material and revocation signatures. The data is binary, and MUST NOT
- be encoded into an ASCII armor. An implementation SHOULD process
-
-
-
-Josefsson Expires March 3, 2006 [Page 4]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- transferable public keys as described in section 10.1 of [6], but it
- MAY handle additional OpenPGP packets.
-
- The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
- content that would have been in the "certificate, CRL or URL" field
- of the corresponding (PKIX, SPKI or PGP) packet types. These types
- are known as "indirect". These packet types MUST be used when the
- content is too large to fit in the CERT RR, and MAY be used at the
- implementer's discretion. They SHOULD NOT be used where the entire
- UDP packet would have fit in 512 bytes.
-
- The URI private type indicates a certificate format defined by an
- absolute URI. The certificate portion of the CERT RR MUST begin with
- a null terminated URI [5] and the data after the null is the private
- format certificate itself. The URI SHOULD be such that a retrieval
- from it will lead to documentation on the format of the certificate.
- Recognition of private certificate types need not be based on URI
- equality but can use various forms of pattern matching so that, for
- example, subtype or version information can also be encoded into the
- URI.
-
- The OID private type indicates a private format certificate specified
- by an ISO OID prefix. The certificate section will start with a one-
- byte unsigned OID length and then a BER encoded OID indicating the
- nature of the remainder of the certificate section. This can be an
- X.509 certificate format or some other format. X.509 certificates
- that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
- type, not the OID private type. Recognition of private certificate
- types need not be based on OID equality but can use various forms of
- pattern matching such as OID prefix.
-
-2.2. Text Representation of CERT RRs
-
- The RDATA portion of a CERT RR has the type field as an unsigned
- decimal integer or as a mnemonic symbol as listed in section 2.1
- above.
-
- The key tag field is represented as an unsigned decimal integer.
-
- The algorithm field is represented as an unsigned decimal integer or
- a mnemonic symbol as listed in [10].
-
- The certificate / CRL portion is represented in base 64 [14] and may
- be divided up into any number of white space separated substrings,
- down to single base 64 digits, which are concatenated to obtain the
- full signature. These substrings can span lines using the standard
- parenthesis.
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 5]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- Note that the certificate / CRL portion may have internal sub-fields,
- but these do not appear in the master file representation. For
- example, with type 254, there will be an OID size, an OID, and then
- the certificate / CRL proper. But only a single logical base 64
- string will appear in the text representation.
-
-2.3. X.509 OIDs
-
- OIDs have been defined in connection with the X.500 directory for
- user certificates, certification authority certificates, revocations
- of certification authority, and revocations of user certificates.
- The following table lists the OIDs, their BER encoding, and their
- length-prefixed hex format for use in CERT RRs:
-
- id-at-userCertificate
- = { joint-iso-ccitt(2) ds(5) at(4) 36 }
- == 0x 03 55 04 24
- id-at-cACertificate
- = { joint-iso-ccitt(2) ds(5) at(4) 37 }
- == 0x 03 55 04 25
- id-at-authorityRevocationList
- = { joint-iso-ccitt(2) ds(5) at(4) 38 }
- == 0x 03 55 04 26
- id-at-certificateRevocationList
- = { joint-iso-ccitt(2) ds(5) at(4) 39 }
- == 0x 03 55 04 27
-
-
-3. Appropriate Owner Names for CERT RRs
-
- It is recommended that certificate CERT RRs be stored under a domain
- name related to their subject, i.e., the name of the entity intended
- to control the private key corresponding to the public key being
- certified. It is recommended that certificate revocation list CERT
- RRs be stored under a domain name related to their issuer.
-
- Following some of the guidelines below may result in the use in DNS
- names of characters that require DNS quoting which is to use a
- backslash followed by the octal representation of the ASCII code for
- the character (e.g., \000 for NULL).
-
- The choice of name under which CERT RRs are stored is important to
- clients that perform CERT queries. In some situations, the clients
- may not know all information about the CERT RR object it wishes to
- retrieve. For example, a client may not know the subject name of an
- X.509 certificate, or the e-mail address of the owner of an OpenPGP
- key. Further, the client might only know the hostname of a service
- that uses X.509 certificates or the Key ID of an OpenPGP key.
-
-
-
-Josefsson Expires March 3, 2006 [Page 6]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- Therefore, two owner name guidelines are defined: content-based owner
- names and purpose-based owner names. A content-based owner name is
- derived from the content of the CERT RR data; for example, the
- Subject field in an X.509 certificate or the User ID field in OpenPGP
- keys. A purpose-based owner name is a name that a client retrieving
- CERT RRs MUST already know; for example, the host name of an X.509
- protected service or the Key ID of an OpenPGP key. The content-based
- and purpose-based owner name MAY be the same; for example, when a
- client looks up a key based on the From: address of an incoming
- e-mail.
-
- Implementations SHOULD use the purpose-based owner name guidelines
- described in this document, and MAY use CNAMEs of content-based owner
- names (or other names), pointing to the purpose-based owner name.
-
-3.1. Content-based X.509 CERT RR Names
-
- Some X.509 versions permit multiple names to be associated with
- subjects and issuers under "Subject Alternate Name" and "Issuer
- Alternate Name". For example, X.509v3 has such Alternate Names with
- an ASN.1 specification as follows:
-
- GeneralName ::= CHOICE {
- otherName [0] INSTANCE OF OTHER-NAME,
- rfc822Name [1] IA5String,
- dNSName [2] IA5String,
- x400Address [3] EXPLICIT OR-ADDRESS.&Type,
- directoryName [4] EXPLICIT Name,
- ediPartyName [5] EDIPartyName,
- uniformResourceIdentifier [6] IA5String,
- iPAddress [7] OCTET STRING,
- registeredID [8] OBJECT IDENTIFIER
- }
-
- The recommended locations of CERT storage are as follows, in priority
- order:
- 1. If a domain name is included in the identification in the
- certificate or CRL, that should be used.
- 2. If a domain name is not included but an IP address is included,
- then the translation of that IP address into the appropriate
- inverse domain name should be used.
- 3. If neither of the above is used, but a URI containing a domain
- name is present, that domain name should be used.
- 4. If none of the above is included but a character string name is
- included, then it should be treated as described for OpenPGP
- names below.
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 7]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- 5. If none of the above apply, then the distinguished name (DN)
- should be mapped into a domain name as specified in [4].
-
- Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
- DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
- string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
- uri <https://www.secure.john-doe.com:8080/>. The storage locations
- recommended, in priority order, would be
- 1. john-doe.com,
- 2. www.secure.john-doe.com, and
- 3. Doe.com.xy.
-
- Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
- L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
- domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
- (c) string "James Hacker <hacker@mail.widget.foo.example>". The
- storage locations recommended, in priority order, would be
- 1. widget.foo.example,
- 2. 201.13.251.10.in-addr.arpa, and
- 3. hacker.mail.widget.foo.example.
-
-3.2. Purpose-based X.509 CERT RR Names
-
- Due to the difficulty for clients that do not already possess a
- certificate to reconstruct the content-based owner name, purpose-
- based owner names are recommended in this section. Recommendations
- for purpose-based owner names vary per scenario. The following table
- summarizes the purpose-based X.509 CERT RR owner name guidelines for
- use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
-
- Scenario Owner name
- ------------------ ----------------------------------------------
- S/MIME Certificate Standard translation of an RFC 2822 email
- address. Example: An S/MIME certificate for
- "postmaster@example.org" will use a standard
- hostname translation of the owner name,
- "postmaster.example.org".
-
- TLS Certificate Hostname of the TLS server.
-
- IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4
- or IPv6 addresses, the fully qualified domain
- name in the appropriate reverse domain.
-
- An alternate approach for IPSEC is to store raw public keys [15].
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 8]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-3.3. Content-based OpenPGP CERT RR Names
-
- OpenPGP signed keys (certificates) use a general character string
- User ID [6]. However, it is recommended by OpenPGP that such names
- include the RFC 2822 [8] email address of the party, as in "Leslie
- Example <Leslie@host.example>". If such a format is used, the CERT
- should be under the standard translation of the email address into a
- domain name, which would be leslie.host.example in this case. If no
- RFC 2822 name can be extracted from the string name, no specific
- domain name is recommended.
-
- If a user has more than one email address, the CNAME type can be used
- to reduce the amount of data stored in the DNS. Example:
-
- $ORIGIN example.org.
- smith IN CERT PGP 0 0 <OpenPGP binary>
- john.smith IN CNAME smith
- js IN CNAME smith
-
-3.4. Purpose-based OpenPGP CERT RR Names
-
- Applications that receive an OpenPGP packet containing encrypted or
- signed data but do not know the email address of the sender will have
- difficulties constructing the correct owner name and cannot use the
- content-based owner name guidelines. However, these clients commonly
- know the key fingerprint or the Key ID. The key ID is found in
- OpenPGP packets, and the key fingerprint is commonly found in
- auxilliary data that may be available. In this case, use of an owner
- name identical to the key fingerprint and the key ID expressed in
- hexadecimal [14] is recommended. Example:
-
- $ORIGIN example.org.
- 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
- F835EDA21E94B565716F IN CERT PGP ...
- B565716F IN CERT PGP ...
-
- If the same key material is stored for several owner names, the use
- of CNAME may be used to avoid data duplication. Note that CNAME is
- not always applicable, because it maps one owner name to the other
- for all purposes, which may be sub-optimal when two keys with the
- same Key ID are stored.
-
-3.5. Owner names for IPKIX, ISPKI, and IPGP
-
- These types are stored under the same owner names, both purpose- and
- content-based, as the PKIX, SPKI and PGP types.
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 9]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-4. Performance Considerations
-
- Current Domain Name System (DNS) implementations are optimized for
- small transfers, typically not more than 512 bytes including
- overhead. While larger transfers will perform correctly and work is
- underway to make larger transfers more efficient, it is still
- advisable at this time to make every reasonable effort to minimize
- the size of certificates stored within the DNS. Steps that can be
- taken may include using the fewest possible optional or extension
- fields and using short field values for necessary variable length
- fields.
-
- The RDATA field in the DNS protocol may only hold data of size 65535
- octets (64kb) or less. This means that each CERT RR MUST NOT contain
- more than 64kb of payload, even if the corresponding certificate or
- certificate revocation list is larger. This document addresses this
- by defining "indirect" data types for each normal type.
-
-
-5. Contributors
-
- The majority of this document is copied verbatim from RFC 2538, by
- Donald Eastlake 3rd and Olafur Gudmundsson.
-
-
-6. Acknowledgements
-
- Thanks to David Shaw and Michael Graff for their contributions to
- earlier works that motivated, and served as inspiration for, this
- document.
-
- This document was improved by suggestions and comments from Olivier
- Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
- Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is
- incomplete. We apologize to anyone we left out.
-
-
-7. Security Considerations
-
- By definition, certificates contain their own authenticating
- signature. Thus, it is reasonable to store certificates in non-
- secure DNS zones or to retrieve certificates from DNS with DNS
- security checking not implemented or deferred for efficiency. The
- results MAY be trusted if the certificate chain is verified back to a
- known trusted key and this conforms with the user's security policy.
-
- Alternatively, if certificates are retrieved from a secure DNS zone
- with DNS security checking enabled and are verified by DNS security,
-
-
-
-Josefsson Expires March 3, 2006 [Page 10]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- the key within the retrieved certificate MAY be trusted without
- verifying the certificate chain if this conforms with the user's
- security policy.
-
- If an organization chooses to issue certificates for it's employees,
- placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
- is in use, it is possible for someone to enumerate all employees of
- the organization. This is usually not considered desirable, for the
- same reason enterprise phone listings are not often publicly
- published and are even mark confidential.
-
- When the URI type is used, it should be understood that it introduces
- an additional indirection that may allow for a new attack vector.
- One method to secure that indirection is to include a hash of the
- certificate in the URI itself.
-
- CERT RRs are not used by DNSSEC [9], so there are no security
- considerations related to CERT RRs and securing the DNS itself.
-
- If DNSSEC is used, then the non-existence of a CERT RR and,
- consequently, certificates or revocation lists can be securely
- asserted. Without DNSSEC, this is not possible.
-
-
-8. IANA Considerations
-
- Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
- only be assigned by an IETF standards action [7]. This document
- assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate
- types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
- based on RFC documentation of the certificate type. The availability
- of private types under 0x00FD and 0x00FE should satisfy most
- requirements for proprietary or private types.
-
- The CERT RR reuses the DNS Security Algorithm Numbers registry. In
- particular, the CERT RR requires that algorithm number 0 remain
- reserved, as described in Section 2. The IANA is directed to
- reference the CERT RR as a user of this registry and value 0, in
- particular.
-
-
-9. Changes since RFC 2538
-
- 1. Editorial changes to conform with new document requirements,
- including splitting reference section into two parts and
- updating the references to point at latest versions, and to add
- some additional references.
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 11]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- 2. Improve terminology. For example replace "PGP" with "OpenPGP",
- to align with RFC 2440.
- 3. In section 2.1, clarify that OpenPGP public key data are binary,
- not the ASCII armored format, and reference 10.1 in RFC 2440 on
- how to deal with OpenPGP keys, and acknowledge that
- implementations may handle additional packet types.
- 4. Clarify that integers in the representation format are decimal.
- 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
- terminology. Improve reference for Key Tag Algorithm
- calculations.
- 6. Add examples that suggest use of CNAME to reduce bandwidth.
- 7. In section 3, appended the last paragraphs that discuss
- "content-based" vs "purpose-based" owner names. Add section 3.2
- for purpose-based X.509 CERT owner names, and section 3.4 for
- purpose-based OpenPGP CERT owner names.
- 8. Added size considerations.
- 9. The SPKI types has been reserved, until RFC 2692/2693 is moved
- from the experimental status.
- 10. Added indirect types IPKIX, ISPKI, and IPGP.
-
-
-Appendix A. Copying conditions
-
- Regarding the portion of this document that was written by Simon
- Josefsson ("the author", for the remainder of this section), the
- author makes no guarantees and is not responsible for any damage
- resulting from its use. The author grants irrevocable permission to
- anyone to use, modify, and distribute it in any way that does not
- diminish the rights of anyone else to use, modify, and distribute it,
- provided that redistributed derivative works do not contain
- misleading author or version information. Derivative works need not
- be licensed under similar terms.
-
-
-10. References
-
-10.1. Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
-
-
-
-Josefsson Expires March 3, 2006 [Page 12]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
- January 1998.
-
- [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
- "OpenPGP Message Format", RFC 2440, November 1998.
-
- [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
- [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-10.2. Informative References
-
- [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
- RFC 2246, January 1999.
-
- [12] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
- and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
- September 1999.
-
- [14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
- RFC 3548, July 2003.
-
- [15] Richardson, M., "A Method for Storing IPsec Keying Material in
- DNS", RFC 4025, March 2005.
-
- [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
- (S/MIME) Version 3.1 Message Specification", RFC 3851,
- July 2004.
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 13]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-Author's Address
-
- Simon Josefsson
-
- Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 14]
-
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 15]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
deleted file mode 100644
index 5e6cb1d09e2af..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: January 2006 July 2005
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-06.txt>
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for encoding Diffie-Hellman keys in the Domain
- Name System is specified.
-
-
-
-Copyright
-
- Copyright (C) The Internet Society 2005.
-
-
-
-D. Eastlake 3rd [Page 1]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
- and Hemma Prafullchandra. In addition, the following persons
- provided useful comments that were incorporated into the predecessor
- of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright..................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 1.1 About This Document....................................3
- 1.2 About Diffie-Hellman...................................3
- 2. Encoding Diffie-Hellman Keying Information..............4
- 3. Performance Considerations..............................5
- 4. IANA Considerations.....................................5
- 5. Security Considerations.................................5
- Copyright and Disclaimer...................................5
-
- Normative References.......................................7
- Informative Refences.......................................7
-
- Author Address.............................................8
- Expiration and File Name...................................8
-
- Appendix A: Well known prime/generator pairs...............9
- A.1. Well-Known Group 1: A 768 bit prime..................9
- A.2. Well-Known Group 2: A 1024 bit prime.................9
- A.3. Well-Known Group 3: A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- similar information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additonal work is underway which would use
- the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier, RFC 2631].
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Thus Diffie-
- Hellman is inherently a key agreement algorithm. As a result, no
- format is defined for Diffie-Hellman "signature information". For
- example, assume that two parties have local secrets "i" and "j".
- Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
- key is the pair p and g, which must be the same for the parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
-
-
-D. Eastlake 3rd [Page 3]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
- When Diffie-Hellman keys appear within the RDATA portion of a RR,
- they are encoded as shown below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | prime length (or flag) | prime (p) (or special) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / prime (p) (variable length) | generator length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | generator (g) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | public value length | public value (variable length)/
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / public value (g^i mod p) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Prime length is the length of the Diffie-Hellman prime (p) in bytes
- if it is 16 or greater. Prime contains the binary representation of
- the Diffie-Hellman prime with most significant byte first (i.e., in
- network order). If "prime length" field is 1 or 2, then the "prime"
- field is actually an unsigned index into a table of 65,536
- prime/generator pairs and the generator length SHOULD be zero. See
- Appedix A for defined table entries and Section 4 for information on
- allocating additional table entries. The meaning of a zero or 3
- through 15 value for "prime length" is reserved.
-
- Generator length is the length of the generator (g) in bytes.
- Generator is the binary representation of generator with most
- significant byte first. PublicValueLen is the Length of the Public
- Value (g**i (mod p)) in bytes. PublicValue is the binary
- representation of the DH public value with most significant byte
- first.
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient. But
- it is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying information consistent
- with adequate security.
-
-
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus as defined in [RFC 2434].
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action. [RFC 2539], the
- Proposed Standard predecessor of this document, assigned 0x0001
- through 0x0002. This document additionally assigns 0x0003. Pairs
- number 0s0800 through 0xBFFF can be assigned based on RFC
- documentation. Pairs number 0xC000 through 0xFFFF are available for
- private use and are not centrally coordinated. Use of such private
- pairs outside of a closed environment may result in conflicts and/or
- security failures.
-
-
-
-5. Security Considerations
-
- Keying information retrieved from the DNS should not be trusted
- unless (1) it has been securely obtained from a secure resolver or
- independently verified by the user and (2) this secure resolver and
- secure obtainment or independent verification conform to security
- policies acceptable to the user. As with all cryptographic
- algorithms, evaluating the necessary strength of the key is important
- and dependent on security policy.
-
- In addition, the usual Diffie-Hellman key strength considerations
- apply. (p-1)/2 should also be prime, g should be primitive mod p, p
- should be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
- in RFCs", T. Narten, H. Alvestrand, October 1998.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative Refences
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, November 1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, November 1987.
-
- [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Author Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in January 2006.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
- These numbers are copied from the IPSEC effort where the derivation of
- these values is more fully explained and additional information is
- available.
- Richard Schroeppel performed all the mathematical and computational
- work for this appendix.
-
-
-
-A.1. Well-Known Group 1: A 768 bit prime
-
- The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
- decimal value is
- 155251809230070893513091813125848175563133404943451431320235
- 119490296623994910210725866945387659164244291000768028886422
- 915080371891804634263272761303128298374438082089019628850917
- 0691316593175367469551763119843371637221007210577919
-
- Prime modulus: Length (32 bit words): 24, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2: A 1024 bit prime
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its decimal value is
- 179769313486231590770839156793787453197860296048756011706444
- 423684197180216158519368947833795864925541502180565485980503
- 646440548199239100050792877003355816639229553136239076508735
- 759914822574862575007425302077447712589550957937778424442426
- 617334727629299387668709205606050270810842907692932019128194
- 467627007
-
- Prime modulus: Length (32 bit words): 32, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-D. Eastlake 3rd [Page 9]
-
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3: A 1536 bit prime
-
- The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
- Its decimal value is
- 241031242692103258855207602219756607485695054850245994265411
- 694195810883168261222889009385826134161467322714147790401219
- 650364895705058263194273070680500922306273474534107340669624
- 601458936165977404102716924945320037872943417032584377865919
- 814376319377685986952408894019557734611984354530154704374720
- 774996976375008430892633929555996888245787241299381012913029
- 459299994792636526405928464720973038494721168143446471443848
- 8520940127459844288859336526896320919633919
-
- Prime modulus Length (32 bit words): 48, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
- C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
- 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
- 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
deleted file mode 100644
index 0af13c616f998..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
+++ /dev/null
@@ -1,755 +0,0 @@
-
-
-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-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt
deleted file mode 100644
index c5c3b84ba3d55..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group Yuji Kamite
-INTERNET-DRAFT NTT Communications
-<draft-ietf-dnsext-tkey-renewal-mode-04.txt> Masaya Nakayama
-Expires: Aug. 2004 The University of Tokyo
- Feb. 2004
-
-
-
-
- TKEY Secret Key Renewal Mode
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- 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
-
- 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
- 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.
-
-
-
-
-
-
-
-
-Kamite, et. al. [Page 1]
-
-INTERNET-DRAFT Feb. 2004
-
-
- 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 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 21
-11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. [Page 2]
-
-INTERNET-DRAFT Feb. 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. [Page 3]
-
-INTERNET-DRAFT Feb. 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. [Page 4]
-
-INTERNET-DRAFT Feb. 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. [Page 5]
-
-INTERNET-DRAFT Feb. 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. [Page 6]
-
-INTERNET-DRAFT Feb. 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. [Page 7]
-
-INTERNET-DRAFT Feb. 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. [Page 8]
-
-INTERNET-DRAFT Feb. 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. [Page 9]
-
-INTERNET-DRAFT Feb. 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. [Page 10]
-
-INTERNET-DRAFT Feb. 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. [Page 11]
-
-INTERNET-DRAFT Feb. 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. [Page 12]
-
-INTERNET-DRAFT Feb. 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. [Page 13]
-
-INTERNET-DRAFT Feb. 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. [Page 14]
-
-INTERNET-DRAFT Feb. 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. [Page 15]
-
-INTERNET-DRAFT Feb. 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. [Page 16]
-
-INTERNET-DRAFT Feb. 2004
-
-
- hosts want to send queries, but it is possible.
-
- When one of two servers tries to send Renewal requests, it MUST
- protect old secrets that it has partially revoked and prevent it from
- being refreshed by any requests from the other server (i.e., it must
- lock the old secret during the process of renewal). While the server
- is sending Renewal requests and waiting responses, it ignores the
- other server's Renewal requests.
-
- Therefore, servers might fail to change secrets by means of their own
- requests to others. After failure they will try to resend, but they
- should wait for random delays by the next retries. If they get any
- Renewal requests from others while they are waiting, their shared
- keys may be refreshed, then they do not need to send any Renewal
- requests now for themselves.
-
-
-6. Key Name Considerations
-
- Since both servers and clients have only to distinguish new secrets
- and old ones, keys' names do not need to be specified strictly.
- However, it is recommended that some serial number or key generation
- time be added to the name and that the names of keys between the same
- pair of hosts should have some common labels among their keys. For
- example, suppose A.example.com. and B.example.com. share the key
- "<serial number>.A.example.com.B.example.com." such as
- "10010.A.example.com.B.example.com.". After key renewal, they change
- their secret and name into "10011.A.example.com.B.example.com."
-
- Servers and clients must be able to use keys properly for each query.
- Because TSIG secret keys themselves do not have any particular IDs to
- be distinguished and would be identified by their names and
- algorithm, it must be understood correctly what keys are refreshed.
-
-
-7. Example Usage of Secret Key Renewal Mode
-
- This is an example of Renewal mode usage where a Server,
- server.example.com, and a Client, client.exmple.com have an initial
- shared secret key named "00.client.example.com.server.example.com".
-
- (1) The time values for key
- "00.client.example.com.server.example.com" was set as follows:
- Inception Time is at 1:00, Expiry Limit is at 21:00.
-
- (2) At Server, renewal time has been set: Partial Revocation Time
- is at 20:00.
-
-
-
-
-Kamite, et. al. [Page 17]
-
-INTERNET-DRAFT Feb. 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. [Page 18]
-
-INTERNET-DRAFT Feb. 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. [Page 19]
-
-INTERNET-DRAFT Feb. 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. [Page 20]
-
-INTERNET-DRAFT Feb. 2004
-
-
-10. Acknowledgement
-
- The authors would like to thank Olafur Gudmundsson, whose helpful
- input and comments contributed greatly to this document.
-
-
-11. References
-
-[RFC2104]
- H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
- Authentication", RFC2104, February 1997.
-
-[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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. [Page 21]
-
-INTERNET-DRAFT Feb. 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. [Page 22]
-
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
deleted file mode 100644
index 9c73c68befdc4..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
+++ /dev/null
@@ -1,1292 +0,0 @@
-
-
-
-
-
-DNS Extensions Yuji Kamite
-Internet-Draft NTT Communications
-Expires: April 15, 2005 Masaya Nakayama
- The University of Tokyo
- October 14, 2004
-
-
-
- TKEY Secret Key Renewal Mode
- draft-ietf-dnsext-tkey-renewal-mode-05
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on April 15, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004).
-
-Abstract
-
- This document defines a new mode in TKEY and proposes an atomic
- method for changing secret keys used for TSIG periodically.
- Originally, TKEY provides methods of setting up shared secrets other
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 1]
-
-INTERNET-DRAFT October 2004
-
-
- than manual exchange, but it cannot control timing of key renewal
- very well though it can add or delete shared keys separately. This
- proposal is a systematical key renewal procedure intended for
- preventing signing DNS messages with old and non-safe keys
- permanently.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4
- 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4
- 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5
- 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5
- 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6
- 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7
- 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7
- 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7
- 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8
- 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8
- 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
- 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10
- 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10
- 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
- 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11
- 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12
- 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13
- 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14
- 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
- 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15
- 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15
- 4.2 Authentication Methods Considerations . . . . . . . . . . 15
- 5. Special Considerations for Two Servers' Case . . . . . . . . 16
- 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16
- 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17
- 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
- 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
- 11.2 Informative References . . . . . . . . . . . . . . . . . . 21
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
- Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 2]
-
-INTERNET-DRAFT October 2004
-
-
-1. Introduction
-
- TSIG [RFC2845] provides DNS message integrity and the
- request/transaction authentication by means of message authentication
- codes (MAC). TSIG is a practical solution in view of calculation
- speed and availability. However, TSIG does not have exchanging
- mechanism of shared secret keys between server and resolver, and
- administrators might have to exchange secret keys manually. TKEY
- [RFC2930] is introduced to solve such problem and it can exchange
- secrets for TSIG via networks.
-
- In various modes of TKEY, a server and a resolver can add or delete a
- secret key be means of TKEY message exchange. However, the existing
- TKEY does not care fully about the management of keys which became
- too old, or dangerous after long time usage.
-
- It is ideal that the number of secret which a pair of hosts share
- should be limited only one, because having too many keys for the same
- purpose might not only be a burden to resolvers for managing and
- distinguishing according to servers to query, but also does not seem
- to be safe in terms of storage and protection against attackers.
- Moreover, perhaps holding old keys long time might give attackers
- chances to compromise by scrupulous calculation.
-
- Therefore, when a new shared secret is established by TKEY, the
- previous old secret should be revoked immediately. To accomplish
- this, DNS servers must support a protocol for key renewal. This
- document specifies procedure to refresh secret keys between two hosts
- which is defined within the framework of TKEY, and it is called "TKEY
- Secret Key Renewal Mode".
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
- "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-
-1.1. Defined Words
-
- * Inception Time: Beginning of the shared secret key lifetime. This
- value is determined when the key is generated.
-
- * Expiry Limit: Time limit of the key's validity. This value is
- determined when a new key is generated. After Expiry Limit, server
- and client (resolver) must not authenticate TSIG signed with the key.
- Therefore, Renewal to the next key should be carried out before
- Expiry Limit.
-
- * Partial Revocation Time: Time when server judges the key is too old
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 3]
-
-INTERNET-DRAFT October 2004
-
-
- and must be updated. It must be between Inception Time and Expiry
- Limit. This value is determined by server freely following its
- security policy. e.g., If the time from Inception to Partial
- Revocation is short, renewal will be carried out more often, which
- might be safer.
-
- * Revocation Time: Time when the key becomes invalid and can be
- removed. This value is not determined in advance because it is the
- actual time when revocation is completed.
-
- * Adoption Time: Time when the new key is adopted as the next key
- formally. After Adoption, the key is valid and server and client can
- generate or verify TSIG making use of it. Adoption Time also means
- the time when it becomes possible to remove the previous key, so
- Revocation and Adoption are usually done at the same time.
-
-
- Partial
- Inception Revocation Revocation Expiry Limit
- | | | |
- |----------------|- - - - - - >>|- (revoked) -|
- | | | |
- previous key | | |
- |- - - -|-------------------->> time
- | | new key
- Inception Adoption
-
-
-1.2. New Format and Assigned Numbers
-
- TSIG
- ERROR = (PartialRevoke), TBD
-
- TKEY
- Mode = (server assignment for key renewal), TBD
- Mode = (Diffie-Hellman exchange for key renewal), TBD
- Mode = (resolver assignment for key renewal), TBD
- Mode = (key adoption), TBD
-
-
-1.3. Overview of Secret Key Renewal Mode
-
- When a server receives a query from a client signed with a TSIG key,
- It always checks if the present time is within the range of usage
- duration it considers safe. If it is judged that the key is too old,
- i.e., after Partial Revocation Time, the server comes to be in
- Partial Revocation state about the key, and this key is called
- partially revoked.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 4]
-
-INTERNET-DRAFT October 2004
-
-
- In this state, if a client sends a normal query (e.g., question about
- A RR) other than TKEY Renewal request with TSIG signed with the old
- key, the server returns an error message to notify that the time to
- renew has come. This is called "PartialRevoke" error message. It is
- server's choice whether it returns PartialRevoke or not. If and only
- if the server is ready for changing its own key, it decides to return
- PartialRevoke.
-
- The client which got this error is able to notice that it is
- necessary to refresh the secret. To make a new shared secret, it
- sends a TKEY Renewal request, in which several keying methods are
- available. It can make use of TSIG authentication signed with the
- partially revoked key mentioned above.
-
- After new secret establishment, the client sends a TKEY Adoption
- request for renewal confirmation. This can also be authenticated with
- the partially revoked key. If this is admitted by the server, the new
- key is formally adopted, and at the same time the corresponding old
- secret is invalidated. Then the client can send the first query again
- signed with the new key.
-
- Key renewal procedure is executed based on two-phase commit
- mechanism. The first phase is the TKEY Renewal request and its
- response, which means preparatory confirmation for key update. The
- second phase is Adoption request and its response. If the server gets
- request and client receives the response successfully, they can
- finish renewal process. If any error happens and renewal process
- fails during these phases, client should roll back to the beginning
- of the first phase, and send TKEY Renewal request again. This
- rollback can be done until the Expiry Limit of the key.
-
-
-2. Shared Secret Key Renewal
-
- Suppose a server and a client agree to change their TSIG keys
- periodically. Key renewal procedure is defined between two hosts.
-
-2.1. Key Usage Time Check
-
- Whenever a server receives a query with TSIG and can find a key that
- is used for signing it, the server checks its Inception Time, Partial
- Revocation Time and Expiry Limit (this information is usually
- memorized by the server).
-
- When the present time is before Inception Time, the server MUST NOT
- verify TSIG with the key, and server acts the same way as when the
- key used by the client is not recognized. It follows [RFC2845] 4.5.1.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 5]
-
-INTERNET-DRAFT October 2004
-
-
- When the present time is equal to Inception Time, or between
- Inception Time and Partial Revocation Time, the behavior of the
- server is the same as when a valid key is found. It follows [RFC2845]
- 4.5.2 and 4.5.3.
-
- When the present time is the same as the Partial Revocation Time, or
- between the Partial Revocation Time and Expiry Limit, the server
- comes to be in Partial Revocation state about the TSIG key and
- behaves according to the next section.
-
- When the present time is the same as the Expiry Time or after it, the
- server MUST NOT verify TSIG with the key, and returns error messages
- in the same way as when the key used by the client is not recognized.
- It follows [RFC2845] 4.5.1.
-
-
-2.2. Partial Revocation
-
- In Partial Revocation state, we say the server has partially revoked
- the key and the key has become a "partially revoked key".
-
- If server has received a query signed with the partially revoked key
- for TKEY Renewal request (See section 2.3.) or Key Adoption request
- (See section 2.4.), then server does proper process following each
- specification. If it is for TKEY key deletion request ([RFC2930]
- 4.2), server MAY process usual deletion operation defined therein.
-
- If server receives other types of query signed with the partially
- revoked key, and both the corresponding MAC and signed TIME are
- verified, then server begins returning answer whose TSIG error code
- is "PartialRevoke" (See section 9.). Server MUST randomly but with
- increasing frequency return PartialRevoke when in the Partial
- Revocation state.
-
- Server can decide when it actually sends PartialRevoke, checking if
- it is appropriate time for renewal. Server MUST NOT return
- PartialRevoke if this is apart long lived TSIG transaction (such as
- AXFR) that started before the Partial Revocation Time.
-
- If the client receives PartialRevoke and understands it, then it MUST
- retry the query with the old key unless a new key has been adopted.
- Client SHOULD start the process to renew the TSIG key. For key
- renewal procedure, see details in Section 2.3 and 2.4.
-
- PartialRevoke period (i.e., time while server returns PartialRevoke
- randomely) SHOULD be small, say 2-5% of key lifetime. This is
- server's choice.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 6]
-
-INTERNET-DRAFT October 2004
-
-
- Server MUST keep track of clients ignoring PartialRevoke, thus
- indicating ignorance of this TKEY mode.
-
- PartialRevoke error messages have the role to inform clients of the
- keys' partial revocation and urge them to send TKEY Renewal requests.
- These error responses MUST be signed with those partial revoked keys
- if the queries are signed with them. They are sent only when the
- signing keys are found to be partially revoked. If the MAC of TSIG
- cannot be verified with the partially revoked keys, servers MUST NOT
- return PartialRevoke error with MAC, but MUST return another error
- such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
- words, a server informs its key's partial revocation only when the
- MAC in the received query is valid.
-
-
-2.3. Key Renewal Message Exchange
-
-2.3.1. Query for Key Renewal
-
- If a client has received a PartialRevoke error and authenticated the
- response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
- this document, we call it Renewal request, too.) to the server. The
- request MUST be signed with TSIG or SIG(0) [RFC2931] for
- authentication. If TSIG is selected, the client can sign it with the
- partial revoked key.
-
- Key Renewal can use one of several keying methods which is indicated
- in "Mode" field of TKEY RR, and its message structure is dependent on
- that method.
-
-
-2.3.2. Response for Key Renewal
-
- The server which has received Key Renewal request first tries to
- verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
- verified with the partially revoked key, the request MUST be
- authenticated.
-
- After authentication, server must check existing old key's validity.
- If the partially revoked key indicated in the request TKEY's OldName
- and OldAlgorithm field (See section 2.3.4.) does not exist at the
- server, "BADKEY" [RFC2845] is given in Error field for response. If
- any other error happens, server returns appropriate error messages
- following the specification described in section 2.5. If there are no
- errors, server returns a Key Renewal answer. This answer MUST be
- signed with TSIG or SIG(0) for authentication.
-
- When this answer is successfully returned and no error is detected by
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 7]
-
-INTERNET-DRAFT October 2004
-
-
- client, a new shared secret can be established. The details of
- concrete keying procedure are given in the section 2.5.
-
- Note:
- Sometimes Adoption message and new Renewal request will cross on
- the wire. In this case the newly generated key Adoption message is
- resent.
-
-
-2.3.3. Attributes of Generated Key
-
- As a result of this message exchange, client comes to know the newly
- generated key's attributes such as key's name, Inception Time and
- Expiry Limit. They are decided by the server and told to the client;
- in particular, however, once the server has decided Expiry Limit and
- returned a response, it should obey the decision as far as it can. In
- other words, they SHOULD NOT change time values for checking Expiry
- Limit in the future without any special reason, such as security
- issue like "Emergency Compulsory Revocation" described in section 8.
-
- On the other hand, Partial Revocation Time of this generated key is
- not decided based on the request, and not informed to the client. The
- server can determine any value as long as it is between Inception
- Time and Expiry Limit. However, the period from Inception to Partial
- Revocation SHOULD be fixed as the server side's configuration or be
- set the same as the corresponding old key's one.
-
- Note:
- Even if client sends Key Renewal request though the key described
- in OldName has not been partially revoked yet, server does renewal
- processes. At the moment when the server accepts such requests
- with valid authentication, it MUST forcibly consider the key is
- already partially revoked, that is, the key's Partial Revocation
- Time must be changed into the present time (i.e., the time when
- the server receives the request).
-
-
-2.3.4. TKEY RR structure
-
- TKEY RR for Key Renewal message has the structure given below. In
- principle, format and definition for each field follows [RFC2930].
- Note that each keying scheme sometimes needs different interpretation
- of RDATA field; for detail, see section 2.5.
-
- Field Type Comment
- ------- ------ -------
- NAME domain used for a new key, see below
- TYPE u_int16_t (defined in [RFC2930])
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 8]
-
-INTERNET-DRAFT October 2004
-
-
- CLASS u_int16_t (defined in [RFC2930])
- TTL u_int32_t (defined in [RFC2930])
- RDLEN u_int16_t (defined in [RFC2930])
- RDATA:
- Algorithm: domain algorithm for a new key
- Inception: u_int32_t about the keying material
- Expiration: u_int32_t about the keying material
- Mode: u_int16_t scheme for key agreement
- see section 9.
- Error: u_int16_t see description below
- Key Size: u_int16_t see description below
- Key Data: octet-stream
- Other Size: u_int16_t (defined in [RFC2930])
- size of other data
- Other Data: newly defined: see description below
-
-
- For "NAME" field, both non-root and root name are allowed. It may
- be used for a new key's name in the same manner as [RFC2930] 2.1.
-
- "Algorithm" specifies which algorithm is used for agreed keying
- material, which is used for identification of the next key.
-
- "Inception" and "Expiration" are used for the valid period of
- keying material. The meanings differ somewhat according to whether
- the message is request or answer, and its keying scheme.
-
- "Key Data" has different meanings according to keying schemes.
-
- "Mode" field stores the value in accordance with the keying method,
- and see section 2.5. Servers and clients supporting TKEY Renewal
- method MUST implement "Diffie-Hellman exchange for key renewal"
- scheme. All other modes are OPTIONAL.
-
- "Error" is an extended RCODE which includes "PartialRevoke" value
- too. See section 9.
-
- "Other Data" field has the structure given below. They describe
- attributes of the key to be renewed.
-
- in Other Data filed:
-
- Field Type Comment
- ------- ------ -------
- OldNAME domain name of the old key
- OldAlgorithm domain algorithm of the old key
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 9]
-
-INTERNET-DRAFT October 2004
-
-
- "OldName" indicates the name of the previous key (usually,
- this is partially revoked key's name that client noticed by
- PartialRevoke answer from server), and "OldAlogirthm"
- indicates its algorithm.
-
-
-2.4. Key Adoption
-
-2.4.1. Query for Key Adoption
-
- After receiving a TKEY Renewal answer, the client gets the same
- secret as the server. Then, it sends a TKEY Adoption request. The
- request's question section's QNAME field is the same as the NAME
- filed of TKEY written below. In additional section, there is one TKEY
- RR that has the structure and values described below.
-
- "NAME" field is the new key's name to be adopted which was already
- generated by Renewal message exchange. "Algorithm" is its
- algorithm. "Inception" means the key's Inception Time, and
- "Expiration" means Expiry Limit.
-
- "Mode" field is the value of "key adoption". See section 9.
-
- "Other Data" field in Adoption has the same structure as that of
- Renewal request message. "OldName" means the previous old key, and
- "OldAlogirthm" means its algorithm.
-
- Key Adoption request MUST be signed with TSIG or SIG(0) for
- authentication. The client can sign TSIG with the previous key. Note
- that until Adoption is finished, the new key is treated as invalid,
- thus it cannot be used for authentication immediately.
-
-
-2.4.2. Response for Key Adoption
-
- The server which has received Adoption request, it verifies TSIG or
- SIG(0) accompanying it. If the TSIG is signed with the partially
- revoked key and can be verified, the message MUST be authenticated.
-
- If the next new key indicated by the request TKEY's "NAME" is not
- present at the server, BADNAME [RFC2845] is given in Error field and
- the error message is returned.
-
- If the next key exists but it has not been adopted formally yet, the
- server confirms the previous key's existence indicated by the
- "OldName" and "OldAlgorithm" field. If it succeeds, the server
- executes Adoption of the next key and Revocation of the previous key.
- Response message duplicates the request's TKEY RR with NOERROR,
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 10]
-
-INTERNET-DRAFT October 2004
-
-
- including "OldName" and "OldAlgorithm" that indicate the revoked key.
-
- If the next key exists but it is already adopted, the server returns
- a response message regardless of the substance of the request TKEY's
- "OldName". In this response, Response TKEY RR has the same data as
- the request's one except as to its "Other Data" that is changed into
- null (i.e., "Other Size" is zero), which is intended for telling the
- client that the previous key name was ignored, and the new key is
- already available.
-
- Client sometimes has to retry Adoption request. Suppose the client
- sent request signed with the partially revoked key, but its response
- did not return successfully (e.g., due to the drop of UDP packet).
- Client will probably retry Adoption request; however, the request
- will be refused in the form of TSIG "BADKEY" error because the
- previous key was already revoked. In this case, client will
- retransmit Adoption request signed with the next key, and expect a
- response which has null "Other Data" for confirming the completion of
- renewal.
-
-
-2.5. Keying Schemes
-
- In Renewal message exchanges, there are no limitations as to which
- keying method is actually used. The specification of keying
- algorithms is independent of the general procedure of Renewal that is
- described in section 2.3.
-
- Now this document specifies three algorithms in this section, but
- other future documents can make extensions defining other methods.
-
-
-2.5.1. DH Exchange for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.1. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as keying material
- computation, are the exactly same as the specification of [RFC2930]
- 4.1.
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. KEY RR is
- the client's Diffie-Hellman public key [RFC2539].
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 11]
-
-INTERNET-DRAFT October 2004
-
-
- TKEY "Mode" field stores the value of "DH exchange for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3. If
- any incompatible DH key is found in the request, "BADKEY"
- [RFC2845] is given in Error field for response. "FORMERR" is given
- if the query included no DH KEY.
-
- If there are no errors, the server processes a response according
- to Diffie-Hellman algorithm and returns the answer. In this
- answer, there is one TKEY RR in answer section and KEY RR(s) in
- additional section.
-
- As long as no error has occurred, all values of TKEY are equal to
- that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
- Inception, Expiration, Key Size and Key Data.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
- TKEY "Key Data" is used as an additional nonce, following
- [RFC2930] 4.1.
-
- The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
- the additional section and a server Diffie-Hellman KEY RR will
- also be present in the answer section, following [RFC2930] 4.1.
-
-
-2.5.2. Server Assigned Keying for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.4. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as secret encrypting
- method, are the exactly same as the specification of [RFC2930] 4.4.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 12]
-
-INTERNET-DRAFT October 2004
-
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. KEY RR is
- used in encrypting the response.
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "server assignment for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is provided following the specification of
- [RFC2930] 4.4.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3.
- "FORMERR" is given if the query specified no encryption key.
-
- If there are no errors, the server response contains one TKEY RR
- in the answer section, and echoes the KEY RR provided in the query
- in the additional information section.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
- TKEY "Key Data" is the assigned keying data encrypted under the
- public key in the resolver provided KEY RR, which is the same as
- [RFC2930] 4.4.
-
-
-2.5.3. Resolver Assigned Keying for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.5. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as secret encrypting
- method, are the exactly same as the specification of [RFC2930] 4.5.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 13]
-
-INTERNET-DRAFT October 2004
-
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. TKEY RR
- has the encrypted keying material and KEY RR is the server public
- key used to encrypt the data.
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "resolver assignment for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is the encrypted keying material.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3.
- "FORMERR" is given if the server does not have the corresponding
- private key for the KEY RR that was shown sin the request.
-
- If there are no errors, the server returns a response. The
- response contains a TKEY RR in the answer section to tell the
- shared key's name and its usage time values.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
-
-2.6. Considerations about Non-compliant Hosts
-
- Key Renewal requests and responses must be exchanged between hosts
- which can understand them and do proper processes. PartialRevoke
- error messages will be only ignored if they should be returned to
- non-compliant hosts.
-
- Note that server does not inform actively the necessity of renewal to
- clients, but inform it as responses invoked by client's query.
- Server needs not care whether the PartialRevoke errors has reached
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 14]
-
-INTERNET-DRAFT October 2004
-
-
- client or not. If client has not received yet because of any reasons
- such as packet drops, it will resend the queries, and finally will be
- able to get PartialRevoke information.
-
-
-3. Secret Storage
-
- Every server keeps all secrets and attached information, e.g.,
- Inception Time, Expiry Limit, etc. safely to be able to recover from
- unexpected stop. To accomplish this, formally adopted keys SHOULD be
- memorized not only on memory, but also be stored in the form of some
- files. It will become more secure if they are stored in ecrypted
- form.
-
-
-4. Compulsory Key Revocation
-
-4.1. Compulsory Key Revocation by Server
-
- There is a rare but possible case that although servers have already
- partially revoked keys, clients do not try to send any Renewal
- requests. If this state continues, in the future it will become the
- time of Expiry Limit. After Expiry Limit, the keys will be expired
- and completely removed, so this is called Compulsory Key Revocation
- by server.
-
- If Expiry Limit is too distant from the Partial Revocation Time, then
- even though very long time passes, clients will be able to refresh
- secrets only if they add TSIG signed with those old partially revoked
- keys into requests, which is not safe.
-
- On the other hand, if Expiry Limit is too close to Partial Revocation
- Time, perhaps clients might not be able to notice their keys' Partial
- Revocation by getting "PartialRevoke" errors.
-
- Therefore, servers should set proper Expiry Limit to their keys,
- considering both their keys' safety, and enough time for clients to
- send requests and process renewal.
-
-
-4.2. Authentication Methods Considerations
-
- It might be ideal to provide both SIG(0) and TSIG as authentication
- methods. For example:
-
- A client and a server start SIG(0) authentication at first, to
- establish TSIG shared keys by means of "Query for Diffie-Hellman
- Exchanged Keying" as described in [RFC2930] 4.1. Once they get
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 15]
-
-INTERNET-DRAFT October 2004
-
-
- shared secret, they keep using TSIG for queries and responses.
- After a while the server returns a "ParitalRevoke" error and they
- begin a key renewal process. Both TSIG signed with partially
- revoked keys and SIG(0) are okay for authentication, but TSIG would
- be easier to use considering calculation efficiency.
-
- Suppose now client is halted for long time with some reason.
- Because server does not execute any renewal process, it will
- finally do Compulsory Revocation. Even if client restarts and sends
- a key Renewal request, it will fail because old key is already
- deleted at server.
-
- At this moment, however, if client also uses SIG(0) as another
- authentication method, it can make a new shared key again and
- recover successfully by sending "Query for Diffie-Hellman Exchanged
- Keying" with SIG(0).
-
-
-5. Special Considerations for Two servers' Case
-
- This section refers to the case where both hosts are DNS servers
- which can act as full resolvers as well and using one shared key
- only. If one server (called Server A) wants to refresh a shared key
- (called "Key A-B"), it will await a TKEY Renewal request from the
- other server (called Server B). However, perhaps Server A wants to
- refresh the key right now.
-
- In this case, Server A is allowed to send a Renewal request to Server
- B, if Server A knows the Key A-B is too old and wants to renew it
- immediately.
-
- Note that the initiative in key renewal belongs to Server A because
- it can notice the Partial Revocation Time and decide key renewal. If
- Server B has information about Partial Revocation Time as well, it
- can also decide for itself to send Renewal request to Server A.
- However, it is not essential for both two servers have information
- about key renewal timing.
-
-5.1. To Cope with Collisions of Renewal Requests
-
- At least one of two hosts which use Key Renewal must know their key
- renewal information such as Partial Revocation Time. It is okay that
- both hosts have it.
-
- Provided that both two servers know key renewal timing information,
- there is possibility for them to begin partial revocation and sending
- Renewal requests to each other at the same time. Such collisions will
- not happen so often because Renewal requests are usually invoked when
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 16]
-
-INTERNET-DRAFT October 2004
-
-
- hosts want to send queries, but it is possible.
-
- When one of two servers tries to send Renewal requests, it MUST
- protect old secrets that it has partially revoked and prevent it from
- being refreshed by any requests from the other server (i.e., it must
- lock the old secret during the process of renewal). While the server
- is sending Renewal requests and waiting responses, it ignores the
- other server's Renewal requests.
-
- Therefore, servers might fail to change secrets by means of their own
- requests to others. After failure they will try to resend, but they
- should wait for random delays by the next retries. If they get any
- Renewal requests from others while they are waiting, their shared
- keys may be refreshed, then they do not need to send any Renewal
- requests now for themselves.
-
-
-6. Key Name Considerations
-
- Since both servers and clients have only to distinguish new secrets
- and old ones, keys' names do not need to be specified strictly.
- However, it is recommended that some serial number or key generation
- time be added to the name and that the names of keys between the same
- pair of hosts should have some common labels among their keys. For
- example, suppose A.example.com. and B.example.com. share the key
- "<serial number>.A.example.com.B.example.com." such as
- "10010.A.example.com.B.example.com.". After key renewal, they change
- their secret and name into "10011.A.example.com.B.example.com."
-
- Servers and clients must be able to use keys properly for each query.
- Because TSIG secret keys themselves do not have any particular IDs to
- be distinguished and would be identified by their names and
- algorithm, it must be understood correctly what keys are refreshed.
-
-
-7. Example Usage of Secret Key Renewal Mode
-
- This is an example of Renewal mode usage where a Server,
- server.example.com, and a Client, client.exmple.com have an initial
- shared secret key named "00.client.example.com.server.example.com".
-
- (1) The time values for key
- "00.client.example.com.server.example.com" was set as follows:
- Inception Time is at 1:00, Expiry Limit is at 21:00.
-
- (2) At Server, renewal time has been set: Partial Revocation Time
- is at 20:00.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 17]
-
-INTERNET-DRAFT October 2004
-
-
- (3) Suppose the present time is 19:55. If Client sends a query
- signed with key "00.client.example.com.server.example.com" to ask
- the IP address of "www.example.com", finally it will get a proper
- answer from Server with valid TSIG (NOERROR).
-
- (4) At 20:05. Client sends a query to ask the IP address of
- "www2.example.com". It is signed with key
- "00.client.example.com.server.example.com". Server returns an
- answer for the IP address. However, server has begun retuning
- PartialRevoke Error randomely. This answer includes valid TSIG MAC
- signed with "00.client.example.com.server.example.com", and its
- Error Code indicates PartialRevoke. Client understands that the
- current key is partially revoked.
-
- (5) At 20:06. Client sends a Renewal request to Server. This
- request is signed with key
- "00.client.example.com.server.example.com". It includes data such
- as:
-
- Question Section:
- QNAME = 01.client.example.com. (Client can set this freely)
- TYPE = TKEY
-
- Additional Section:
- 01.client.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (DH exchange for key renewal)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
- Additional Section also contains a KEY RR for DH and a TSIG RR.
-
- (6) As soon as Server receives this request, it verifies TSIG. It
- is signed with the partially revoked key
- "00.client.example.com.server.example.com". and Server accepts the
- request. It creates a new key by Diffie-Hellman calculation and
- returns an answer which includes data such as:
-
- Answer Section:
- 01.client.example.com.server.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (DH exchange for key renewal)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 18]
-
-INTERNET-DRAFT October 2004
-
-
- Answer Section also contains KEY RRs for DH.
-
- Additional Section also contains a TSIG RR.
- This response is signed with key
- "00.client.example.com.server.example.com" without error.
-
- At the same time, Server decides to set the Partial Revocation Time
- of this new key "01.client.example.com.server.example.com." as next
- day's 15:00.
-
- (7) Client gets the response and checks TSIG MAC, and calculates
- Diffie-Hellman. It will get a new key, and it has been named
- "01.client.example.com.server.example.com" by Server.
-
- (8) At 20:07. Client sends an Adoption request to Server. This
- request is signed with the previous key
- "00.client.example.com.server.example.com". It includes:
-
- Question Section:
- QNAME = 01.client.example.com.server.example.com.
- TYPE = TKEY
-
- Additional Section:
- 01.client.example.com.server.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (key adoption)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
- Additional Section also contains a TSIG RR.
-
- (9) Server verifies the query's TSIG. It is signed with the
- previous key and authenticated. It returns a response whose TKEY RR
- is the same as the request's one. The response is signed with key
- "00.client.example.com.server.example.com.". As soon as the
- response is sent, Server revokes and removes the previous key. At
- the same time, key "01.client.example.com.server.example.com." is
- validated.
-
- (10) Client acknowledges the success of Adoption by receiving the
- response. Then, it retries to send an original question about
- "www2.example.com". It is signed with the adopted key
- "01.client.example.com.server.example.com", so Server authenticates
- it and returns an answer.
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 19]
-
-INTERNET-DRAFT October 2004
-
-
- (11) This key is used until next day's 15:00. After that, it will
- be partially revoked again.
-
-
-8. Security Considerations
-
- This document considers about how to refresh shared secret. Secret
- changed by this method is used at servers in support of TSIG
- [RFC2845].
-
- [RFC2104] says that current attacks to HMAC do not indicate a
- specific recommended frequency for key changes but periodic key
- refreshment is a fundamental security practice that helps against
- potential weaknesses of the function and keys, and limits the damage
- of an exposed key. TKEY Secret Key Renewal provides the method of
- periodical key refreshment.
-
- In TKEY Secret Key Renewal, clients need to send two requests
- (Renewal and Adoption) and spend time to finish their key renewal
- processes. Thus the usage period of secrets should be considered
- carefully based on both TKEY processing performance and security.
-
- This document specifies the procedure of periodical key renewal, but
- actually there is possibility for servers to have no choice other
- than revoking their secret keys immediately especially when the keys
- are found to be compromised by attackers. This is called "Emergency
- Compulsory Revocation". For example, suppose the original Expiry
- Limit was set at 21:00, Partial Revocation Time at 20:00 and
- Inception Time at 1:00. if at 11:00 the key is found to be
- compromised, the server sets Expiry Limit forcibly to be 11:00 or
- before it.
-
- Consequently, once Compulsory Revocation (See section 4.) is carried
- out, normal renewal process described in this document cannot be done
- any more as far as the key is concerned. However, after such
- accidents happened, the two hosts are able to establish secret keys
- and begin renewal procedure only if they have other (non-compromised)
- shared TSIG keys or safe SIG(0) keys for the authentication of
- initial secret establishment such as Diffie-Hellman Exchanged Keying.
-
-
-9. IANA Considerations
-
- IANA needs to allocate a value for "DH exchange for key renewal",
- "server assignment for key renewal", "resolver assignment for key
- renewal" and "key adoption" in the mode filed of TKEY. It also needs
- to allocate a value for "PartialRevoke" from the extended RCODE
- space.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 20]
-
-INTERNET-DRAFT October 2004
-
-
-10. Acknowledgements
-
- The authors would like to thank Olafur Gudmundsson, whose helpful
- input and comments contributed greatly to this document.
-
-
-11. References
-
-11.1. Normative References
-
-[RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
-[RFC2539]
- D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", RFC 2539, March 1999.
-
-[RFC2845]
- Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
- May 2000.
-
-[RFC2930]
- D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
- RFC 2930, September 2000.
-
-[RFC2931]
- D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
- )", RFC 2931, September 2000.
-
-11.2. Informative References
-
-[RFC2104]
- H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
- Authentication", RFC2104, February 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 21]
-
-INTERNET-DRAFT October 2004
-
-
-Authors' Addresses
-
- Yuji Kamite
- NTT Communications Corporation
- Tokyo Opera City Tower
- 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
- 163-1421, Japan
- EMail: y.kamite@ntt.com
-
-
- Masaya Nakayama
- Information Technology Center, The University of Tokyo
- 2-11-16 Yayoi, Bunkyo-ku, Tokyo
- 113-8658, Japan
- EMail: nakayama@nc.u-tokyo.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 22]
-
-INTERNET-DRAFT October 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 23]
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
deleted file mode 100644
index b5aaad2b85993..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
+++ /dev/null
@@ -1,1501 +0,0 @@
-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
deleted file mode 100644
index df702b41ec982..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-
-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-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
deleted file mode 100644
index 1133b0c87d49e..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
+++ /dev/null
@@ -1,466 +0,0 @@
-
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-UPDATES RFC 2845 Motorola Laboratories
-Expires: February 2005 August 2004
-
-
- HMAC SHA TSIG Algorithm Identifiers
- ---- --- ---- --------- -----------
- <draft-ietf-dnsext-tsig-sha-00.txt>
-
-
-Status of This Document
-
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- or will be disclosed, and any of which I become aware will be
- disclosed, in accordance with RFC 3668.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- Use of the TSIG DNS resource record requires specification of a
- cryptographic message authentication code. Currently identifiers
- have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
- This document standardizes identifiers for additional HMAC SHA TSIG
- algorithms and standardizes how to specify the truncation of HMAC
- values.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2004. 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
-
- 4. IANA Considerations.....................................6
- 5. Security Considerations.................................6
- 6. Copyright and Disclaimer................................6
-
- 7. Normative References....................................7
- 8. Informative References..................................7
-
- Authors Address............................................8
- Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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-1, 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 sha224] with 224, 256, 384, and 512
- bits, may be preferred in some case. Use of TSIG between a DNS
- resolver and server is by mutual agreement. That agreement can
- include the support of additional algorithms.
-
- For completeness in relation to HMAC based algorithms, the current
- HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below.
- Implementations which support TSIG MUST implement HMAC MD5, SHOULD
- implement HMAC SHA-1, and MAY implement gss-tsig and the other
- algorithms listed below.
-
- Mandatory HMAC-MD5.SIG-ALG.REG.INT
- Recommended hmac-sha1
- Optional hmac-sha224
- Optional hmac-sha256
- Optional hamc-sha384
- Optional hmac-sha512
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
- In some cases, it is reasonable to truncate the output of HMAC and
- use the truncated value for authentication. HMAC SHA-1 truncated to
- 96 bits is an optional 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.
-
- The specification for TSIG handling is changed as follows:
-
- 1. If The "MAC size" field is larger than the HMAC output length or
- is zero: 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 the "MAC size" field equals the HMAC output length: Operation
- is as described in [RFC 2845].
-
- 3. If the "MAC size" field is less than the HMAC output length but is
- not zero: This is sent when the signer has truncated the HMAC
- output 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.
-
- TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12
- octets) and MAY implement any or all other truncations valid under
- case 3 above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-4. IANA Considerations
-
- This document, on approval for publication as a standards track RFC,
- registers the new TSIG algorithm identifiers listed in Section 2 with
- IANA.
-
-
-
-5. Security Considerations
-
- For all of the message authentication code algorithms listed herein,
- those producing longer values are believed to be stronger; however,
- while there are 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 force. See [RFC 2104] which recommends
- that ah HMAC never be truncated to less than half its length nor to
- less than 80 bits (10 octets).
-
- See also the Security Considerations section of [RFC 2845].
-
-
-
-6. Copyright and Disclaimer
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-7. Normative References
-
- [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal
- Information Processing Standard, Draft, 1 August 2002.
-
- [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 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R.
- Housley, December 2003, work in progress, draft-ietf-pkix-
- sha224-*.txt.
-
-
-
-8. Informative References.
-
- [FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information
- Processing Standard, 17 April 1995.
-
- [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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Authors Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554 (w)
- +1-508-634-2066 (h)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in February 2005.
-
- Its file name is draft-ietf-dnsext-tsig-sha-00.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-
-
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
deleted file mode 100644
index a59595f5901da..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-UPDATES RFC 2845 Motorola Laboratories
-Expires: December 2005 June 2005
-
-
- HMAC SHA TSIG Algorithm Identifiers
- ---- --- ---- --------- -----------
- <draft-ietf-dnsext-tsig-sha-04.txt>
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- Use of the TSIG DNS resource record requires specification of a
- cryptographic message authentication code. Currently identifiers
- have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
- This document standardizes identifiers and implementation
- requirements for additional HMAC SHA TSIG algorithms and standardizes
- how to specify and handle the truncation of HMAC values.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-D. Eastlake 3rd [Page 1]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
-
- 2. Algorithms and Identifiers..............................4
-
- 3. Specifying Truncation...................................5
- 3.1 Truncation Specification...............................5
-
- 4. TSIG Policy Provisions and Truncation Error.............7
-
- 5. IANA Considerations.....................................8
- 6. Security Considerations.................................8
- 6. Copyright and Disclaimer................................8
-
- 7. Normative References....................................9
- 8. Informative References..................................9
-
- Author's Address..........................................10
- Expiration and File Name..................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
- [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
- authenticate DNS queries and responses. This RR contains a domain
- name syntax data item which names the authentication algorithm used.
- [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
- authentication codes using the HMAC [RFC 2104] algorithm with the MD5
- [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
- identifier for TSIG authentication where the cryptographic operations
- are delegated to GSS [RFC 3645].
-
- In Section 2, this document specifies additional names for TSIG
- authentication algorithms based on US NIST SHA algorithms and HMAC
- and specifies the implementation requirements for those algorithms.
-
- In Section 3, this document specifies the meaning of inequality
- between the normal output size of the specified hash function and the
- length of MAC (message authentication code) data given in the TSIG
- RR. In particular, it specifies that a shorter length field value
- specifies truncation and a longer length field is an error.
-
- In Section 4, policy restrictions and implications related to
- truncation and a new error code to indicate truncation shorter than
- permitted by policy are described and specified.
-
- The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
- defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 3]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
- TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
- queries and responses. They are intended to be efficient symmetric
- authentication codes based on a shared secret. (Asymmetric signatures
- can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
- can be used for transaction signatures.) Used with a strong hash
- function, HMAC [RFC 2104] provides a way to calculate such symmetric
- authentication codes. The only specified HMAC based TSIG algorithm
- identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
- The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
- compared with the 128 bits for MD5, and additional hash algorithms in
- the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
- and 512 bits, may be preferred in some cases particularly since
- increasingly successful cryptanalytic attacks are being made on the
- shorter hashes. Use of TSIG between a DNS resolver and server is by
- mutual agreement. That agreement can include the support of
- additional algorithms and may specify policies as to which algorithms
- and truncations are acceptable subject to the restrication and
- guidelines in Section 3 and 4 below.
-
- The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the
- table below for convenience. Implementations which support TSIG MUST
- also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig
- and the other algorithms listed below.
-
- Mandatory HMAC-MD5.SIG-ALG.REG.INT
- Mandatory hmac-sha1
- Optional hmac-sha224
- Mandatory hmac-sha256
- Optional hamc-sha384
- Optional hmac-sha512
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
- When space is at a premium and the strength of the full length of an
- HMAC is not needed, it is reasonable to truncate the HMAC output and
- use the truncated value for authentication. HMAC SHA-1 truncated to
- 96 bits is an option available in several IETF protocols including
- IPSEC and TLS.
-
- The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
- size of the MAC field in octets. But [RFC 2845] does not specify what
- to do if this MAC size differs from the length of the output of HMAC
- for a particular hash function. Truncation is indicated by a MAC size
- less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
- The specification for TSIG handling is changed as follows:
-
- 1. If "MAC size" field is greater than HMAC output length:
- This case MUST NOT be generated and if received MUST cause the
- packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
- 2. If "MAC size" field equals HMAC output length:
- Operation is as described in [RFC 2845] with the entire output
- HMAC output present.
-
- 3. "MAC size" field is less than HMAC output length but greater than
- that specified in case 4 below:
- This is sent when the signer has truncated the HMAC output to
- an allowable length, as described in RFC 2104, taking initial
- octets and discarding trailing octets. TSIG truncation can only be
- to an integral number of octets. On receipt of a packet with
- truncation thus indicated, the locally calculated MAC is similarly
- truncated and only the truncated values compared for
- authentication. The request MAC used when calculating the TSIG MAC
- for a reply is the trucated request MAC.
-
- 4. "MAC size" field is less than the larger of 10 (octets) and half
- the length of the hash function in use:
- With the exception of certain TSIG error messages described in
- RFC 2845 section 3.2 where it is permitted that the MAC size be
- zero, this case MUST NOT be generated and if received MUST cause
- the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
- size limit for this case can also, for the hash functions
- mentioned in this document, be stated as less than half the hash
- function length for hash functions other than MD5 and less than 10
- octets for MD5.
-
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
- SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Policy Provisions and Truncation Error
-
- Use of TSIG is by mutual agreement between a resolver and server.
- Implicit in such "agreement" are policies as to acceptable keys and
- algorithms and, with the extensions in this doucment, truncations. In
- particular note the following:
-
- Such policies MAY require the rejection of TSIGs even though they
- use an algorithm for which implementation is mandatory.
-
- When a policy calls for the acceptance of a TSIG with a particular
- algorithm and a particular non-zero amount of trunction it SHOULD
- also permit the use of that algorithm with lesser truncation (a
- longer MAC) up to the full HMAC output.
-
- Regardless of a lower acceptable truncated MAC length specified by
- policy, a reply SHOULD be sent with a MAC at least as long as that in
- the corresponding request unless the request specified a MAC length
- longer than the HMAC output.
-
- Implementations permitting policies with multiple acceptable
- algorithms and/or truncations SHOULD permit this list to be ordered
- by presumed strength and SHOULD allow different truncations for the
- same algorithm to be treatred as spearate entities in this list. When
- so implemented, policies SHOULD accept a presumed stronger algorithm
- and truncation than the minimum strength required by the policy.
-
- If a TSIG is received with truncation which is permitted under
- Section 3 above but the MAC is too short for the policy in force, an
- RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
- This document, on approval for publication as a standards track RFC,
- (1) registers the new TSIG algorithm identifiers listed in Section 2
- with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22
- suggested].
-
-
-
-
-6. Security Considerations
-
- For all of the message authentication code algorithms listed herein,
- those producing longer values are believed to be stronger; however,
- while there have been some arguments that mild truncation can
- strengthen a MAC by reducing the information available to an
- attacker, excessive truncation clearly weakens authentication by
- reducing the number of bits an attacker has to try to brute force
- [RFC 2104].
-
- Significant progress has been made recently in cryptanalysis of hash
- function of the type used herein, all of which ultimately derive from
- the design of MD4. While the results so far should not effect HMAC,
- the stronger SHA-1 and SHA-256 algorithms are being made mandatory
- due to caution.
-
- See the Security Considerations section of [RFC 2845]. See also the
- Security Considerations section of [RFC 2104] from which the limits
- on truncation in this RFC were taken.
-
-
-
-6. Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-7. Normative References
-
- [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
- Federal Information Processing Standard, with Change Notice 1,
- February 2004.
-
- [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
- 1321, April 1992.
-
- [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104, February 1997.
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
-
-
-8. Informative References.
-
- [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
- Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
- 1 (SHA1)", RFC 3174, September 2001.
-
- [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
- J., and R. Hall, "Generic Security Service Algorithm for Secret Key
- Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
- 2003.
-
- [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
- September 2004,
-
- [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
- (SHA)", work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 9]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554 (w)
-
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in December 2005.
-
- Its file name is draft-ietf-dnsext-tsig-sha-04.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt
deleted file mode 100644
index d65fa7104251c..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt
+++ /dev/null
@@ -1,1010 +0,0 @@
-
-
-
-
-
-
-dnsext Working Group B. Halley
-Internet Draft Nominum
-Expiration Date: March 2004
- E. Lewis
- ARIN
-
- September 2003
-
-
- Clarifying the Role of Wild Card Domains
- in the Domain Name System
-
-
- draft-ietf-dnsext-wcard-clarify-02.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 10 of RFC2026.
-
- 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.
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
-Abstract
-
- The definition of wild cards is recast from the original in RFC 1034,
- in words that are more specific and in line with RFC 2119. This
- document is meant to supplement the definition in RFC 1034 and to
- alter neither the spirit nor intent of that definition.
-
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 1]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
-Table of Contents
-
- Abstract ................................................ 1
- 1 Introduction ............................................ 2
- 1.1 Document Limits ......................................... 3
- 1.2 Existence ............................................... 4
- 1.3 An Example .............................................. 4
- 1.4 Empty Non-terminals ..................................... 5
- 1.5 Terminology ............................................. 6
- 2 Defining the Wild Card Domain Name ...................... 7
- 3 Defining Existence ...................................... 8
- 4 Impact of a Wild Card In a Query or in RDATA ............ 8
- 5 Impact of a Wild Card Domain On a Response .............. 9
- 6 Considerations with Special Types ....................... 12
- 6.1 SOA RR's at a Wild Card Domain Name ..................... 12
- 6.2 NS RR's at a Wild Card Domain Name ...................... 12
- 6.3 CNAME RR's at a Wild Card Domain Name ................... 13
- 6.4 DNAME RR's at a Wild Card Domain Name ................... 13
- 7 Security Considerations ................................. 14
- 8 References .............................................. 14
- 9 Others Contributing to This Document .................... 14
- 10 Editors ................................................. 15
- Appendix A: Subdomains of Wild Card Domain Names ........ 16
- Full Copyright Statement ................................ 18
- Acknowledgement ......................................... 18
-
-
-
-
-1. Introduction
-
- The first section of this document will give a crisp overview of what
- is begin defined, as well as the motivation rewording of an original
- document and making a change to bring the specification in line with
- implementations. Examples are included to help orient the reader.
-
- Wild card domain names are defined in Section 4.3.3. of RFC 1034 as
- "instructions for synthesizing RRs." [RFC1034]. The meaning of this
- is that a specific, special domain name is used to construct
- responses in instances in which the query name is not otherwise
- represented in a zone.
-
- A wild card domain name has a specific range of influence on query
- names (QNAMEs) within a given class, which is rooted at the domain
- name containing the wild card label, and is limited by explicit
- entries, zone cuts and empty non-terminal domains (see section 1.3 of
- this document).
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 2]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- Note that a wild card domain name has no special impact on the search
- for a query type (QTYPE). If a domain name is found that matches the
- QNAME (exact or a wild card) but the QTYPE is not found at that
- point, the proper response is that there is no data available. The
- search does not continue on to seek other wild cards that might match
- the QTYPE. To illustrate, a wild card owning an MX RR does not
- 'cover' other names in the zone that own an A RR. There are certain
- special case RR types that will be singled out for discussion, the
- SOA RR, NS RR, CNAME RR, and DNAME RR.
-
- Why is this document needed? Empirical evidence suggests that the
- words in RFC 1034 are not clear enough. There exist a number of
- implementations that have strayed (each differently) from that
- definition. There also exists a misconception of operators that the
- wild card can be used to add a specific RR type to all names, such as
- the MX RR example cited above. This document is also needed as input
- to efforts to extend DNS, such as the DNS Security Extensions [RFC
- 2535]. Lack of a clear base specification has proven to result in
- extension documents that have unpredictable consequences. (This is
- true in general, not just for DNS.)
-
- Another reason this clarification is needed is to answer questions
- regarding authenticated denial of existence, a service introduced in
- the DNS Security Extensions [RFC 2535]. Prior to the work leading up
- to this document, it had been feared that a large number of proof
- records (NXTs) might be needed in each reply because of the unknown
- number of potential wild card domains that were thought to be
- applicable. One outcome of this fear is a now discontinued document
- solving a problem that is now known not to exist. I.e., this
- clarification has the impact of defending against unwarranted
- protocol surgery. It is not "yet another" effort to just rewrite the
- early specifications for the sake of purity.
-
- Although the effort to define the DNS Security Extensions has
- prompted this document, the clarifications herein relate to basic DNS
- only. No DNS Security Extensions considerations are mentioned in the
- document.
-
-1.1. Document Limits
-
- This document limits itself to reinforcing the concepts in RFC 1034.
- In the effort to do this, a few issues have been discussed that
- change parts of what is in RFC 1034. The discussions have been held
- within the DNS Extensions Working Group.
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 3]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- Briefly, the issues raised include:
- - The lack of clarity in the definition of domain name existence
- - Implications of a wild card domain name owning any of the
- following resource record sets: DNAME [RFC 2672], CNAME, NS, and
- SOA
- - Whether RFC 1034 meant to allow special processing of CNAME RR's
- owned by wild card domain names
-
-1.2. Existence
-
- The notion that a domain name 'exists' will arise numerous times in
- this discussion. RFC 1034 raises the issue of existence in a number
- of places, usually in reference to non-existence and often in
- reference to processing involving wild card domain names. RFC 1034
- contains algorithms that describe how domain names impact the
- preparation of an answer and does define wild cards as a means of
- synthesizing answers. Because of this a discussion on wild card
- domain names has to start with the issue of existence.
-
- To help clarify the topic of wild cards, a positive definition of
- existence is needed. Complicating matters, though, is the
- realization that existence is relative. To an authoritative server,
- a domain name exists if the domain name plays a role following the
- algorithms of preparing a response. To a resolver, a domain name
- exists if there is any data available corresponding to the name. The
- difference between the two is the synthesis of records according to a
- wild card.
-
- For the purposes of this document, the point of view of an
- authoritative server is adopted. A domain name is said to exist if
- it plays a role in the execution of the algorithms in RFC 1034.
-
-1.3. An Example
-
- For example, consider this wild card domain name: *.example. Any
- query name under example. is a candidate to be matched (answered) by
- this wild card, i.e., to have an response returned that is
- synthesized from the wild card's RR sets. Although any name is a
- candidate, not all queries will match.
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 4]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- To further illustrate this, consider this zone:
-
- $ORIGIN example.
- @ IN SOA
- NS
- NS
- * TXT "this is a wild card"
- MX 10 mailhost.example.
- host1 A 10.0.0.1
- _ssh._tcp.host1 SRV
- _ssh._tcp.host2 SRV
- subdel NS
-
-
- The following queries would be synthesized from the wild card:
-
- 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 '*'
-
- The following queries would not be synthesized from the wild card:
-
- QNAME=host1.example., QTYPE=MX, QCLASS=IN
- because host1.example. exists
- QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
- because _tcp.host1.example. exists (without data)
- QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
- because host2.example. exists (without data)
- QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
- because subdel.example. exists and is a zone cut
-
- To the server, the following domains are considered to exist in the
- zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2,
- _ssh._tcp.host2, and subdel. To a resolver, many more domains appear
- to exist via the synthesis of the wild card.
-
-1.4. Empty Non-terminals
-
- Empty non-terminals are domain names that own no data but have
- subdomains. This is defined 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.
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 5]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- The parenthesized "which may be empty" specifies that empty non-
- terminals are explicitly recognized. According to the definition of
- existence in this document, empty non-terminals do exist at the
- server.
-
- Carefully 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 [RFC 1035]. 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, this is not the intent of the original
- document.
-
- RFC1034's wording is to be clarified by adding the following
- paragraph:
-
- A node is considered to have an impact on the algorithms of
- 4.3.2 if it is a leaf node with any resource sets or an interior
- node, with or without a resource set, that has a subdomain that
- is a leaf node with a resource set. A QNAME and QCLASS matching
- an existing node never results in a response return code of
- authoritative name error.
-
- The terminology in the above paragraph is chosen to remain as close
- to that in the original document. The term "with" is a alternate
- form for "owning" in this case, hence "a leaf node owning resources
- sets, or an interior node, owning or not owning any resource set,
- that has a leaf node owning a resource set as a subdomain," is the
- proper interpretation of the middle sentence.
-
- As an aside, an "authoritative name error" has been called NXDOMAIN
- in some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic
- assigned to such an error by at least one implementation of DNS. As
- this mnemonic is specific to implementations, it is avoided in the
- remainder of this document.
-
-1.5. 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 the document entitled
- "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
-
- Requirements are denoted by paragraphs that begin with with the
- following convention: 'R'<sect>.<count>.
-
-
-
-Halley & Lewis [Expires March 2004] [Page 6]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- Quotations of RFC 1034 (as has already been done once above) are
- denoted by a '#' in the leftmost column.
-
-2. Defining the Wild Card Domain Name
-
- A wild card domain name is defined by having the initial label be:
-
- 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
- This defines domain names that may play a role in being a wild card,
- that is, being a source for synthesized answers. Domain names
- conforming to this definition that appear in queries and RDATA
- sections do not have any special role. These cases will be described
- in more detail in following sections.
-
- R2.1 A domain name that is to be interpreted as a wild card MUST
- begin with a label of '0000 0001 0010 1010' in binary.
-
- The first octet is the normal label type and length for a 1 octet
- long label, the second octet is the ASCII representation [RFC 20] for
- the '*' character. In RFC 1034, ASCII encoding is assumed to be the
- character encoding.
-
- In the master file formats used in RFCs, a "*" is a legal
- representation for the wild card label. Even if the "*" is escaped,
- it is still interpreted as the wild card when it is the only
- character in the label.
-
- R2.2 A server MUST treat a wild card domain name as the basis of
- synthesized answers regardless of any "escape" sequences in the
- input format.
-
- RFC 1034 and RFC 1035 ignore the case in which a domain name might be
- "the*.example.com." The interpretation is that this domain name in a
- zone would only match queries for "the*.example.com" and not have any
- other role.
-
- Note: By virtue of this definition, a wild card domain name may have
- a subdomain. The subdomain (or sub-subdomain) itself may also be a
- wild card. E.g., *.*.example. is a wild card, so is *.sub.*.example.
- More discussion on this is given in Appendix A.
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 7]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
-3. Defining Existence
-
- As described in the Introduction, a precise definition of existence
- is needed.
-
- R3.1 An authoritative server MUST treat a domain name as existing
- during the execution of the algorithms in RFC 1034 when the
- domain name conforms to the following definition. A domain name
- is defined to exist if the domain name owns data and/or has a
- subdomain that exists.
-
- Note that at a zone boundary, the domain name owns data, including
- the NS RR set. At the delegating server, the NS RR set is not
- authoritative, but that is of no consequence here. The domain name
- owns data, therefore, it exists.
-
- R3.2 An authoritative server MUST treat a domain name that has
- neither a resource record set nor an existing subdomain as non-
- existent when executing the algorithm in section 4.3.2. of RFC
- 1034.
-
- A note on terminology. A domain transcends zones, i.e., all DNS data
- is in the root domain but segmented into zones of control. In this
- document, there are references to a "domain name" in the context of
- existing "in a zone." In this usage, a domain name is the root of a
- domain, not the entire domain. The domain's root point is said to
- "exist in a zone" if the zone is authoritative for the name. RR sets
- existing in a domain need not be owned by the domain's root domain
- name, but are owned by other domain names in the domain.
-
-4. Impact of a Wild Card In a Query or in RDATA
-
- When a wild card domain name appears in a question, e.g., the query
- name is "*.example.", the response in no way differs from any other
- query. In other words, the wild card label in a QNAME has no special
- meaning, and query processing will proceed using '*' as a literal
- query name.
-
- R4.1 A wild card domain name acting as a QNAME MUST be treated as any
- other QNAME, there MUST be no special processing accorded it.
-
- If a wild card domain name appears in the RDATA of a CNAME RR or any
- other RR that has a domain name in it, the same rule applies. In the
- instance of a CNAME RR, the wild card domain name is used in the same
- manner of as being the original QNAME. For other RR's, rules vary
- regarding what is done with the domain name(s) appearing in them, in
- no case does the wild card hold special meaning.
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 8]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- R4.2 A wild card domain name appearing in any RR's RDATA MUST be
- treated as any other domain name in that situation, there MUST
- be no special processing accorded it.
-
-5. Impact of a Wild Card Domain On a Response
-
- The description of how wild cards impact response generation is in
- RFC 1034, 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 wild card.
- The algorithm is directly quoted in lines that begin with a '#' sign.
- Commentary is interleaved.
-
- There is a documentation issue deserving some explanation. The
- algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo
- code, i.e., it's steps are not intended to be followed in strict
- order. The "algorithm" is a suggestion. As such, in step 3, parts
- a, b, and c, do not have to be implemented in that order.
-
- Another issue needing explanation is that RFC 1034 is a full
- standard. There is another RFC, RFC 2672, which makes, or proposes
- an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME
- RR. RFC 2672 is a proposed standard. The dilemma in writing these
- clarifications is knowing which document is the one being clarified.
- Fortunately, the difference between RFC 1034 and RFC 2672 is not
- significant with respect to wild card synthesis, so this document
- will continue to state that it is clarifying RFC 1034. If RFC 2672
- progresses along the standards track, it will need to refer to
- modifying RFC 1034's algorithm as amended here.
-
- The context of part 'c' is that the search is progressing label by
- label through the QNAME. (Note that the data being searched is the
- authoritative data in the server, the cache is searched in step 4.)
- Step 3's part 'a' covers the case that the QNAME has been matched in
- full, regardless of the presence of a CNAME RR. Step 'b' covers
- crossing a cut point, resulting in a referral. All that is left is
- to look for the wild card.
-
- Step 3 of the algorithm also assumes that the search is looking in
- the zone closest to the answer, i.e., in the same class as QCLASS and
- as close to the authority as possible on this server. If the zone is
- not the authority, then a referral is given, possibly one indicating
- lameness.
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 9]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if a
-# the "*" label exists.
-
- The above paragraph refers to finding the domain name that exists in
- the zone and that most encloses the QNAME. Such a domain name will
- mark the boundary of candidate wild card domain names that might be
- used to synthesize an answer. (Remember that at this point, if the
- most enclosing name is the same as the QNAME, part 'a' would have
- recorded an exact match.) The existence of the enclosing name means
- that no wild card name higher in the tree is a candidate to answer
- the query.
-
- Once the closest enclosing node is identified, there's the matter of
- what exists below it. It may have subdomains, but none will be
- closer to the QNAME. One of the subdomains just might be a wild
- card. If it exists, this is the only wild card eligible to be used
- to synthesize an answer for the query. Even if the closest enclosing
- node conforms to the syntax rule in section 2 for being a wild card
- domain name, the closest enclosing node is not eligible to be a
- source of a synthesized answer.
-
- The only wild card domain name that is a candidate to synthesize an
- answer will be the "*" subdomain of the closest enclosing domain
- name. Three possibilities can happen. The "*" subdomain does not
- exist, the "*" subdomain does but does not have an RR set of the same
- type as the QTYPE, or it exists and has the desired RR set.
-
- For the sake of brevity, the closest enclosing node can be referred
- to as the "closest encloser." The closest encloser is the most
- important concept in this clarification. Describing the closest
- encloser is a bit tricky, but it is an easy concept.
-
- To find the closest encloser, you have to first locate the zone that
- is the authority for the query name. This eliminates the need to be
- concerned that the closest encloser is a cut point. In addition, we
- can assume too that the query name does not exist, hence the closest
- encloser is not equal to the query name. We can assume away these
- two cases because they are handled in steps 2, 3a and 3b of section
- 4.3.2.'s algorithm.
-
- What is left is to identify the existing domain name that would have
- been up the tree (closer to the root) from the query name. Knowing
- that an exact match is impossible, if there is a "*" label descending
- from the unique closest encloser, this is the one and only wild card
- from which an answer can be synthesized for the query.
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 10]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- To illustrate, using the example in section 1.2 of this document, the
- following chart shows QNAMEs and the closest enclosers. In
- Appendix A there is another chart showing unusual cases.
-
- QNAME Closest Encloser Wild Card Source
- host3.example. example. *.example.
- _telnet._tcp.host1.example. _tcp.host1.example. no wild card
- _telnet._tcp.host2.example. host2.example. no wild card
- _telnet._tcp.host3.example. example. *.example.
- _chat._udp.host3.example. example. *.example.
-
- Note that host1.subdel.example. is in a subzone, so the search for it
- ends in a referral in part 'b', thus does not enter into finding a
- closest encloser.
-
- The fact that a closest encloser will be the only superdomain that
- can have a candidate wild card will have an impact when it comes to
- designing authenticated denial of existence proofs.
-
-# 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.
-
- The above passage says that if there is not even a wild card domain
- name to match at this point (failing to find an explicit answer
- elsewhere), we are to return an authoritative name error at this
- point. If we were following a CNAME, the specification is unclear,
- but seems to imply that a no error return code is appropriate, with
- just the CNAME RR (or sequence of CNAME RRs) in the answer section.
-
-# 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.
-
- This final paragraph covers the role of the QTYPE in the process.
- Note that if no resource record set matches the QTYPE the result is
- that no data is copied, but the search still ceases ("Go to step
- 6."). In the following section, a suggested change is made to this,
- under the heading "CNAME RRs at a Wild Card Domain Name."
-
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 11]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
-6. Considerations with Special Types
-
- For the purposes of this section, "special" means that a record
- induces processing at the server beyond simple lookup. The special
- types in this section are SOA, NS, CNAME, and DNAME. SOA is special
- because it is used as a zone marker and has an impact on step 2 of
- the algorithm in 4.3.2. NS denotes a cut point and has an impact on
- step 3b. CNAME redirects the query and is mentioned in steps 3a and
- 3b. DNAME is a "CNAME generator."
-
-6.1. SOA RR's at a Wild Card Domain Name
-
- If the owner of an SOA record conforms to the basic rules of owning
- an SOA RR (meaning it is the apex of a zone) the impact on the search
- algorithm is not in section 3c (where records are synthesized) as
- would be expected. The impact is really in step 2 of the algorithm,
- the choice of zone.
-
- We are no longer talking about whether or not an SOA RR can be
- synthesized in a response because we are shifting attention to step
- 2. We are now talking about what it means for a name server to
- synthesize a zone for a response. To date, no implementation has
- done this. Thinking ahead though, anyone choosing to pursue this
- would have to be aware that a server would have to be able to
- distinguish between queries for data it will have to synthesize and
- queries that ought to be treated as if they were prompted by a lame
- delegation.
-
- It is not a protocol error to have an SOA RR owned by a wild card
- domain name, just as it is not an error to have zone name be
- syntactically equivalent to a domain name. However, this situation
- requires careful consideration of how a server chooses the
- appropriate zone for an answer. And an SOA RR is not able to be
- synthesized as in step 3c.
-
-6.2. NS RR's at a Wild Card Domain Name
-
- Complimentary to the issue of an SOA RR owned by a wild card domain
- name is the issue of NS RR's owned by a wild card domain name. In
- this instance, each machine being referred to in the RDATA of the NS
- RR has to be able to understand the impact of this on step 2, the
- choosing of the authoritative zone.
-
- Referring to the same machine in such a NS RR will probably not work
- well. This is because the server may become confused as to whether
- the query name ought to be answered by the zone owning the NS RR in
- question or a synthesized zone. (It isn't known in advance that the
- query name will invoke the wild card synthesis.)
-
-
-
-Halley & Lewis [Expires March 2004] [Page 12]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- The status of other RR's owned by a wild card domain name is the same
- as if the owner name was not a wild card domain name. I.e., when
- there is a NS RR at a wild card domain name, other records are
- treated as being below the zone cut.
-
- Is it not a protocol error to have a NS RR owned by a wild card
- domian name, complimentary to the case of a SOA RR. However, for
- this to work, an implementation has to know how to synthesize a zone.
-
-6.3. CNAME RR's at a Wild Card Domain Name
-
- The issue of CNAME RR's owned by wild card domain names has prompted
- a suggested change to the last paragraph of step 3c of the algorithm
- in 4.3.2. The changed text is this:
-
- If the "*" label does exist and if the data at the node is a
- CNAME and QTYPE doesn't match CNAME, copy the CNAME RR into the
- answer section of the response, set the owner of the CNAME RR to
- be QNAME, and then change QNAME to the canonical name in the
- CNAME RR, and go back to step 1.
-
- If the "*" label does exist and either QTYPE is CNAME or the
- data at the node is not a CNAME, then 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.
-
- Apologies if the above isn't clear, but an attempt was made to stitch
- together the passage using just the phrases in section 3a and 3c of
- the algorithm so as to preserve the original flavor.
-
- In case the passage as suggested isn't clear enough, the intent is to
- make "landing" at a wild card name and finding a CNAME the same as if
- this happened as a result of a direct match. I.e., Finding a CNAME
- at the name matched in step 3c is supposed to have the same impact as
- finding the CNAME in step 3a.
-
-6.4. DNAME RR's at a Wild Card Domain Name
-
- The specification of the DNAME RR, which is at the proposed level of
- standardization, is not as mature as the full standard in RFC 1034.
- Because of this, or the reason for this is, there appears to be a
- host of issues with that definition and it's rewrite of the algorithm
- in 4.3.2. For the time being, when it comes to wild card processing
- issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME
- at a wild card domain name is effectively the same as a CNAME at a
- wild card domain name.
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 13]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
-7. 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.
-
-8. References
-
- Normative References
-
- [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
-
- [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
- Nov-01-1987
-
- [RFC 1035] Domain Names - Implementation and Specification, P.V
- Mockapetris, Nov-01-1987
-
- [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
- Bradner, March 1997
-
- Informative References
-
- [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
- Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
-
- [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
-
- [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999
-
-9. Others Contributing to This Document
-
- Others who have directly caused text to appear in the document: Paul
- Vixie and Olaf Kolkman. Many others have indirect influences on the
- content.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 14]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
-10. Editors
-
- Name: Bob Halley
- Affiliation: Nominum, Inc.
- Address: 2385 Bay Road, Redwood City, CA 94063 USA
- Phone: +1-650-381-6016
- EMail: Bob.Halley@nominum.com
-
- Name: Edward Lewis
- Affiliation: ARIN
- Address: 3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA
- Phone: +1-703-227-9854
- Email: edlewis@arin.net
-
- Comments on this document can be sent to the editors or the mailing
- list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 15]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
-Appendix A: Subdomains of Wild Card Domain Names
-
- In reading the definition of section 2 carefully, it is possible to
- rationalize unusual names as legal. In the example given,
- *.example. could have subdomains of *.sub.*.example. and even the
- more direct *.*.example. (The implication here is that these domain
- names own explicit resource records sets.) Although defining these
- names is not easy to justify, it is important that implementions
- account for the possibility. This section will give some further
- guidence on handling these names.
-
- The first thing to realize is that by all definitions, subdomains of
- wild card domain names are legal. In analyzing them, one realizes
- that they cause no harm by their existence. Because of this, they
- are allowed to exist, i.e., there are no special case rules made to
- disallow them. The reason for not preventing these names is that the
- prevention would just introduce more code paths to put into
- implementations.
-
- The concept of "closest enclosing" existing names is important to
- keep in mind. It is also important to realize that a wild card
- domain name can be a closest encloser of a query name. For example,
- if *.*.example. is defined in a zone, and the query name is
- a.*.example., then the closest enclosing domain name is *.example.
- Keep in mind that the closest encloser is not eligible to be a source
- of synthesized answers, just the subdomain of it that has the first
- label "*".
-
- To illustrate this, the following chart shows some matches. Assume
- that the names *.example., *.*.example., and *.sub.*.example. are
- defined in the zone.
-
- QNAME Closest Encloser Wild Card Source
- a.example. example. *.example.
- b.a.example. example. *.example.
- a.*.example. *.example. *.*.example.
- b.a.*.example. *.example. *.*.example.
- b.a.*.*.example. *.*.example. no wild card
- a.sub.*.example. sub.*.example. *.sub.*.example.
- b.a.sub.*.example. sub.*.example. *.sub.*.example.
- a.*.sub.*.example. *.sub.*.example. no wild card
- *.a.example. example. *.example.
- a.sub.b.example. example. *.example.
-
- Recall that the closest encloser itself cannot be the wild card.
- Therefore the match for b.a.*.*.example. has no applicable wild card.
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 16]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
- Finally, if a query name is sub.*.example., any answer available will
- come from an exact name match for sub.*.example. No wild card
- synthesis is performed in this case.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 17]
-
-Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society 2003. All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis [Expires March 2004] [Page 18]
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
deleted file mode 100644
index fad88aedaba9a..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt
+++ /dev/null
@@ -1,956 +0,0 @@
-DNSEXT Working Group E. Lewis
-INTERNET DRAFT NeuStar
-Expiration Date: January 6, 2006 July 6, 2005
-Updates RFC 1034, RFC 2672
-
- The Role of Wildcards
- in the Domain Name System
- draft-ietf-dnsext-wcard-clarify-08.txt
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that
- any applicable patent or other IPR claims of which he or she is
- aware have been or will be disclosed, and any of which he or she
- becomes aware will be disclosed, in accordance with Section 6 of
- BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This Internet-Draft will expire on January 6, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This is an update to the wildcard definition of RFC 1034. The
- interaction with wildcards and CNAME is changed, an error
- condition removed, and the words defining some concepts central
- to wildcards are changed. The overall goal is not to change
- wildcards, but to refine the definition of RFC 1034.
-
-Table of Contents
-
-1. Introduction
-1.1 Motivation
-1.2 The Original Definition
-1.3 Roadmap to This Document
-1.3.1 New Terms
-1.3.2 Changed Text
-1.3.3 Considerations with Special Types
-1.4 Standards Terminology
-2. Wildcard Syntax
-2.1 Identifying a Wildcard
-2.1.1 Wild Card Domain Name and Asterisk Label
-2.1.2 Asterisks and Other Characters
-2.1.3 Non-terminal Wild Card Domain Names
-2.2 Existence Rules
-2.2.1 An Example
-2.2.2 Empty Non-terminals
-2.2.3 Yet Another Definition of Existence
-2.3 When is a Wild Card Domain Name Not Special
-3. Impact of a Wild Card Domain Name On a Response
-3.1 Step 2
-3.2 Step 3
-3.3 Part 'c'
-3.3.1 Closest Encloser and the Source of Synthesis
-3.3.2 Closest Encloser and Source of Synthesis Examples
-3.3.3 Type Matching
-4. Considerations with Special Types
-4.1 SOA RRSet at a Wild Card Domain Name
-4.2 NS RRSet at a Wild Card Domain Name
-4.2.1 Discarded Notions
-4.3 CNAME RRSet at a Wild Card Domain Name
-4.4 DNAME RRSet at a Wild Card Domain Name
-4.5 SRV RRSet at a Wild Card Domain Name
-4.6 DS RRSet at a Wild Card Domain Name
-4.7 NSEC RRSet at a Wild Card Domain Name
-4.8 RRSIG at a Wild Card Domain Name
-4.9 Empty Non-terminal Wild Card Domain Name
-5. Security Considerations
-6. IANA Considerations
-7. References
-8. Editor
-9. Others Contributing to the Document
-10. Trailing Boilerplate
-
-1. Introduction
-
- In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
- synthesis of answers from special resource records called
- wildcards. The definition in RFC 1034 is incomplete and has
- proven to be confusing. This document describes the wildcard
- synthesis by adding to the discussion and making limited
- modifications. Modifications are made to close inconsistencies
- that have led to interoperability issues. This description
- does not expand the service intended by the original definition.
-
- Staying within the spirit and style of the original documents,
- this document avoids specifying rules for DNS implementations
- regarding wildcards. The intention is to only describe what is
- needed for interoperability, not restrict implementation choices.
- In addition, consideration is given to minimize any backwards
- compatibility issues with implementations that comply with RFC
- 1034's definition.
-
- This document is focused on the concept of wildcards as defined
- in RFC 1034. Nothing is implied regarding alternative means of
- synthesizing resource record sets, nor are alternatives discussed.
-
-1.1 Motivation
-
- Many DNS implementations diverge, in different ways, from the
- original definition of wildcards. Although there is clearly a
- need to clarify the original documents in light of this alone,
- the impetus for this document lay in the engineering of the DNS
- security extensions [RFC4033]. With an unclear definition of
- wildcards the design of authenticated denial became entangled.
-
- This document is intended to limit its changes, documenting only
- those based on implementation experience, and to remain as close
- to the original document as possible. To reinforce that this
- document is meant to clarify and adjust and not redefine wildcards,
- relevant sections of RFC 1034 are repeated verbatim to facilitate
- comparison of the old and new text.
-
-1.2 The Original Definition
-
- The defintion of the wildcard concept is comprised by the
- documentation of the algorithm by which a name server prepares
- a response (in RFC 1034's section 4.3.2) and the way in which
- a resource record (set) is identified as being a source of
- synthetic data (section 4.3.3).
-
- This is the definition of the term "wildcard" as it appears in
- RFC 1034, section 4.3.3.
-
-# In the previous algorithm, special treatment was given to RRs with
-# owner names starting with the label "*". Such RRs are called
-# wildcards. Wildcard RRs can be thought of as instructions for
-# synthesizing RRs. When the appropriate conditions are met, the name
-# server creates RRs with an owner name equal to the query name and
-# contents taken from the wildcard RRs.
-
- This passage follows the algorithm in which the term wildcard
- is first used. In this definition, wildcard refers to resource
- records. In other usage, wildcard has referred to domain names,
- and it has been used to describe the operational practice of
- relying on wildcards to generate answers. It is clear from this
- that there is a need to define clear and unambiguous terminology
- in the process of discussing wildcards.
-
- The mention of the use of wildcards in the preparation of a
- response is contained in step 3c of RFC 1034's section 4.3.2
- entitled "Algorithm." Note that "wildcard" does not appear in
- the algorithm, instead references are made to the "*" label.
- The portion of the algorithm relating to wildcards is
- deconstructed in detail in section 3 of this document, this is
- the beginning of the relevant portion of the "Algorithm."
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if [...]
-# the "*" label exists.
-
- The scope of this document is the RFC 1034 definition of
- wildcards and the implications of updates to those documents,
- such as DNSSEC. Alternate schemes for synthesizing answers are
- not considered. (Note that there is no reference listed. No
- document is known to describe any alternate schemes, although
- there has been some mention of them in mailing lists.)
-
-1.3 Roadmap to This Document
-
- This document accomplishes these three items.
- o Defines new terms
- o Makes minor changes to avoid conflicting concepts
- o Describes the actions of certain resource records as wildcards
-
-1.3.1 New Terms
-
- To help in discussing what resource records are wildcards, two
- terms will be defined - "asterisk label" and "wild card domain
- name". These are defined in section 2.1.1.
-
- To assist in clarifying the role of wildcards in the name server
- algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
- encloser" are defined. These definitions are in section 3.3.2.
- "Label match" is defined in section 3.2.
-
- The new terms are used to make discussions of wildcards clearer.
- Terminology doesn't directly have an impact on implementations.
-
-1.3.2 Changed Text
-
- The definition of "existence" is changed superficially. This
- change will not be apparent to implementations; it is needed to
- make descriptions more precise. The change appears in section
- 2.2.3.
-
- RFC 1034, section 4.3.3., seems to prohibit having two asterisk
- labels in a wildcard owner name. With this document the
- restriction is removed entirely. This change and its implications
- are in section 2.1.3.
-
- The actions when a source of synthesis owns a CNAME RR are
- changed to mirror the actions if an exact match name owns a
- CNAME RR. This is an addition to the words in RFC 1034,
- section 4.3.2, step 3, part c. The discussion of this is in
- section 3.3.3.
-
- Only the latter change represents an impact to implementations.
- The definition of existence is not a protocol impact. The change
- to the restriction on names is unlikely to have an impact, as
- RFC 1034 contained no specification on when and how to enforce the
- restriction.
-
-1.3.3 Considerations with Special Types
-
- This document describes semantics of wildcard RRSets for
- "interesting" types as well as empty non-terminal wildcards.
- Understanding these situations in the context of wildcards has
- been clouded because these types incur special processing if
- they are the result of an exact match. This discussion is in
- section 4.
-
- These discussions do not have an implementation impact, they cover
- existing knowledge of the types, but to a greater level of detail.
-
-1.4 Standards Terminology
-
- This document does not use terms as defined in "Key words for use
- in RFCs to Indicate Requirement Levels." [RFC2119]
-
- Quotations of RFC 1034 are denoted by a '#' in the leftmost
- column. References to section "4.3.2" are assumed to refer
- to RFC 1034's section 4.3.2, simply titled "Algorithm."
-
-2. Wildcard Syntax
-
- The syntax of a wildcard is the same as any other DNS resource
- record, across all classes and types. The only significant
- feature is the owner name.
-
- Because wildcards are encoded as resource records with special
- names, they are included in zone transfers and incremental zone
- transfers[RFC1995] just as non-wildcard resource records are.
- This feature has been underappreciated until discussions on
- alternative approaches to wildcards appeared on mailing lists.
-
-2.1 Identifying a Wildcard
-
- To provide a more accurate description of wildcards, the
- definition has to start with a discussion of the domain names
- that appear as owners. Two new terms are needed, "Asterisk
- Label" and "Wild Card Domain Name."
-
-2.1.1 Wild Card Domain Name and Asterisk Label
-
- A "wild card domain name" is defined by having its initial
- (i.e., left-most or least significant) label be, in binary format:
-
- 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
- The first octet is the normal label type and length for a 1 octet
- long label, the second octet is the ASCII representation [RFC20]
- for the '*' character.
-
- A descriptive name of a label equaling that value is an "asterisk
- label."
-
- RFC 1034's definition of wildcard would be "a resource record
- owned by a wild card domain name."
-
-2.1.2 Asterisks and Other Characters
-
- No label values other than that in section 2.1.1 are asterisk
- labels, hence names beginning with other labels are never wild
- card domain names. Labels such as 'the*' and '**' are not
- asterisk labels so these labels do not start wild card domain
- names.
-
-2.1.3 Non-terminal Wild Card Domain Names
-
- In section 4.3.3, the following is stated:
-
-# .......................... The owner name of the wildcard RRs is of
-# the form "*.<anydomain>", where <anydomain> is any domain name.
-# <anydomain> should not contain other * labels......................
-
- The restriction is now removed. The original documentation of it
- is incomplete and the restriction does not serve any purpose given
- years of operational experience.
-
- There are three possible reasons for putting the restriction in
- place, but none of the three has held up over time. One is
- that the restriction meant that there would never be subdomains
- of wild card domain names, but the restriciton as stated still
- permits "example.*.example." for instance. Another is that
- wild card domain names are not intended to be empty non-terminals,
- but this situation does not disrupt the algorithm in 4.3.2.
- Finally, "nested" wild card domain names are not ambiguous once
- the concept of the closest encloser had been documented.
-
- A wild card domain name can have subdomains. There is no need
- to inspect the subdomains to see if there is another asterisk
- label in any subdomain.
-
- A wild card domain name can be an empty non-terminal. (See the
- upcoming sections on empty non-terminals.) In this case, any
- lookup encountering it will terminate as would any empty
- non-terminal match.
-
-2.2 Existence Rules
-
- The notion that a domain name 'exists' is mentioned in the
- definition of wildcards. In section 4.3.3 of RFC 1034:
-
-# Wildcard RRs do not apply:
-#
-...
-# - When the query name or a name between the wildcard domain and
-# the query name is know[n] to exist. For example, if a wildcard
-
- "Existence" is therefore an important concept in the understanding
- of wildcards. Unfortunately, the definition of what exists, in RFC
- 1034, is unlcear. So, in sections 2.2.2. and 2.2.3, another look is
- taken at the definition of existence.
-
-2.2.1 An Example
-
- To illustrate what is meant by existence consider this complete
- zone:
-
- $ORIGIN example.
- example. 3600 IN SOA <SOA RDATA>
- example. 3600 NS ns.example.com.
- example. 3600 NS ns.example.net.
- *.example. 3600 TXT "this is a wild card"
- *.example. 3600 MX 10 host1.example.
- sub.*.example. 3600 TXT "this is not a wild card"
- host1.example. 3600 A 192.0.4.1
- _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
- _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
- subdel.example. 3600 NS ns.example.com.
- subdel.example. 3600 NS ns.example.net.
-
- A look at the domain names in a tree structure is helpful:
-
- |
- -------------example------------
- / / \ \
- / / \ \
- / / \ \
- * host1 host2 subdel
- | | |
- | | |
- sub _tcp _tcp
- | |
- | |
- _ssh _ssh
-
- The following responses would be synthesized from one of the
- wildcards in the zone:
-
- QNAME=host3.example. QTYPE=MX, QCLASS=IN
- the answer will be a "host3.example. IN MX ..."
-
- QNAME=host3.example. QTYPE=A, QCLASS=IN
- the answer will reflect "no error, but no data"
- because there is no A RR set at '*.example.'
-
- QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
- the answer will be "foo.bar.example. IN TXT ..."
- because bar.example. does not exist, but the wildcard
- does.
-
- The following responses would not be synthesized from any of the
- wildcards in the zone:
-
- QNAME=host1.example., QTYPE=MX, QCLASS=IN
- because host1.example. exists
-
- QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
- because sub.*.example. exists
-
- QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
- because _tcp.host1.example. exists (without data)
-
- QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
- because subdel.example. exists (and is a zone cut)
-
- QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
- because *.example. exists
-
- The final example highlights one common misconception about
- wildcards. A wildcard "blocks itself" in the sense that a
- wildcard does not match its own subdomains. I.e. "*.example."
- does not match all names in the "example." zone, it fails to
- match the names below "*.example." To cover names under
- "*.example.", another wild card domain name is needed -
- "*.*.example." - which covers all but it's own subdomains.
-
-2.2.2 Empty Non-terminals
-
- Empty non-terminals [RFC2136, Section 7.16] are domain names
- that own no resource records but have subdomains that do. In
- section 2.2.1, "_tcp.host1.example." is an example of a empty
- non-terminal name. Empty non-terminals are introduced by this
- text in section 3.1 of RFC 1034:
-
-# The domain name space is a tree structure. Each node and leaf on
-# the tree corresponds to a resource set (which may be empty). The
-# domain system makes no distinctions between the uses of the
-# interior nodes and leaves, and this memo uses the term "node" to
-# refer to both.
-
- The parenthesized "which may be empty" specifies that empty non-
- terminals are explicitly recognized, and that empty non-terminals
- "exist."
-
- Pedantically reading the above paragraph can lead to an
- interpretation that all possible domains exist - up to the
- suggested limit of 255 octets for a domain name [RFC1035].
- For example, www.example. may have an A RR, and as far as is
- practically concerned, is a leaf of the domain tree. But the
- definition can be taken to mean that sub.www.example. also
- exists, albeit with no data. By extension, all possible domains
- exist, from the root on down.
-
- As RFC 1034 also defines "an authoritative name error indicating
- that the name does not exist" in section 4.3.1, so this apparently
- is not the intent of the original definition, justifying the
- need for an updated definition in the next section.
-
-2.2.3 Yet Another Definition of Existence
-
- RFC1034's wording is fixed by the following paragraph:
-
- The domain name space is a tree structure. Nodes in the tree
- either own at least one RRSet and/or have descendants that
- collectively own at least one RRSet. A node may exist with no
- RRSets only if it has descendents that do, this node is an empty
- non-terminal.
-
- A node with no descendants is a leaf node. Empty leaf nodes do
- not exist.
-
- Note that at a zone boundary, the domain name owns data,
- including the NS RR set. In the delegating zone, the NS RR
- set is not authoritative, but that is of no consequence here.
- The domain name owns data, therefore, it exists.
-
-2.3 When is a Wild Card Domain Name Not Special
-
- When a wild card domain name appears in a message's query section,
- no special processing occurs. An asterisk label in a query name
- only matches a single, corresponding asterisk label in the
- existing zone tree when the 4.3.2 algorithm is being followed.
-
- When a wild card domain name appears in the resource data of a
- record, no special processing occurs. An asterisk label in that
- context literally means just an asterisk.
-
-3. Impact of a Wild Card Domain Name On a Response
-
- RFC 1034's description of how wildcards impact response
- generation is in its section 4.3.2. That passage contains the
- algorithm followed by a server in constructing a response.
- Within that algorithm, step 3, part 'c' defines the behavior of
- the wildcard.
-
- The algorithm in section 4.3.2. is not intended to be pseudo-code,
- i.e., its steps are not intended to be followed in strict order.
- The "algorithm" is a suggested means of implementing the
- requirements. As such, in step 3, parts a, b, and c, do not have
- to be implemented in that order, provided that the result of the
- implemented code is compliant with the protocol's specification.
-
-3.1 Step 2
-
- Step 2 of the section 4.3.2 reads:
-
-# 2. Search the available zones for the zone which is the nearest
-# ancestor to QNAME. If such a zone is found, go to step 3,
-# otherwise step 4.
-
- In this step, the most appropriate zone for the response is
- chosen. The significance of this step is that it means all of
- step 3 is being performed within one zone. This has significance
- when considering whether or not an SOA RR can be ever be used for
- synthesis.
-
-3.2 Step 3
-
- Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
- But the beginning of the step is important and needs explanation.
-
-# 3. Start matching down, label by label, in the zone. The
-# matching process can terminate several ways:
-
- The word 'matching' refers to label matching. The concept
- is based in the view of the zone as the tree of existing names.
- The query name is considered to be an ordered sequence of
- labels - as if the name were a path from the root to the owner
- of the desired data. (Which it is - 3rd paragraph of RFC 1034,
- section 3.1.)
-
- The process of label matching a query name ends in exactly one of
- three choices, the parts 'a', 'b', and 'c'. Either the name is
- found, the name is below a cut point, or the name is not found.
-
- Once one of the parts is chosen, the other parts are not
- considered. (E.g., do not execute part 'c' and then change
- the execution path to finish in part 'b'.) The process of label
- matching is also done independent of the query type (QTYPE).
-
- Parts 'a' and 'b' are not an issue for this clarification as they
- do not relate to record synthesis. Part 'a' is an exact match
- that results in an answer, part 'b' is a referral.
-
-3.3 Part 'c'
-
- The context of part 'c' is that the process of label matching the
- labels of the query name has resulted in a situation in which
- there is no corresponding label in the tree. It is as if the
- lookup has "fallen off the tree."
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if [...]
-# the "*" label exists.
-
- To help describe the process of looking 'to see if [...] the "*"
- label exists' a term has been coined to describe the last domain
- (node) matched. The term is "closest encloser."
-
-3.3.1 Closest Encloser and the Source of Synthesis
-
- The closest encloser is the node in the zone's tree of existing
- domain names that has the most labels matching the query name
- (consecutively, counting from the root label downward). Each match
- is a "label match" and the order of the labels is the same.
-
- The closest encloser is, by definition, an existing name in the
- zone. The closest encloser might be an empty non-terminal or even
- be a wild card domain name itself. In no circumstances is the
- closest encloser to be used to synthesize records for the current
- query.
-
- The source of synthesis is defined in the context of a query
- process as that wild card domain name immediately descending
- from the closest encloser, provided that this wild card domain
- name exists. "Immediately descending" means that the source
- of synthesis has a name of the form:
- <asterisk label>.<closest encloser>.
- A source of synthesis does not guarantee having a RRSet to use
- for synthesis. The source of synthesis could be an empty
- non-terminal.
-
- If the source of synthesis does not exist (not on the domain
- tree), there will be no wildcard synthesis. There is no search
- for an alternate.
-
- The important concept is that for any given lookup process, there
- is at most one place at which wildcard synthetic records can be
- obtained. If the source of synthesis does not exist, the lookup
- terminates, the lookup does not look for other wildcard records.
-
-3.3.2 Closest Encloser and Source of Synthesis Examples
-
- To illustrate, using the example zone in section 2.2.1 of this
- document, the following chart shows QNAMEs and the closest
- enclosers.
-
- QNAME Closest Encloser Source of Synthesis
- host3.example. example. *.example.
- _telnet._tcp.host1.example. _tcp.host1.example. no source
- _telnet._tcp.host2.example. host2.example. no source
- _telnet._tcp.host3.example. example. *.example.
- _chat._udp.host3.example. example. *.example.
- foobar.*.example. *.example. no source
-
-3.3.3 Type Matching
-
- RFC 1034 concludes part 'c' with this:
-
-# If the "*" label does not exist, check whether the name
-# we are looking for is the original QNAME in the query
-# or a name we have followed due to a CNAME. If the name
-# is original, set an authoritative name error in the
-# response and exit. Otherwise just exit.
-#
-# If the "*" label does exist, match RRs at that node
-# against QTYPE. If any match, copy them into the answer
-# section, but set the owner of the RR to be QNAME, and
-# not the node with the "*" label. Go to step 6.
-
- The final paragraph covers the role of the QTYPE in the lookup
- process.
-
- Based on implementation feedback and similarities between step
- 'a' and step 'c' a change to this passage has been made.
-
- The change is to add the following text to step 'c' prior to the
- instructions to "go to step 6":
-
- If the data at the source of synthesis is a CNAME, and
- QTYPE doesn't match CNAME, copy the CNAME RR into the
- answer section of the response changing the owner name
- to the QNAME, change QNAME to the canonical name in the
- CNAME RR, and go back to step 1.
-
- This is essentially the same text in step a covering the
- processing of CNAME RRSets.
-
-4. Considerations with Special Types
-
- Sections 2 and 3 of this document discuss wildcard synthesis
- with respect to names in the domain tree and ignore the impact
- of types. In this section, the implication of wildcards of
- specific types are discussed. The types covered are those
- that have proven to be the most difficult to understand. The
- types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
- "none," i.e., empty non-terminal wild card domain names.
-
-4.1 SOA RRSet at a Wild Card Domain Name
-
- A wild card domain name owning an SOA RRSet means that the
- domain is at the root of the zone (apex). The domain can not
- be a source of synthesis because that is, by definition, a
- descendent node (of the closest encloser) and a zone apex is
- at the top of the zone.
-
- Although a wild card domain name owning an SOA RRSet can never
- be a source of synthesis, there is no reason to forbid the
- ownership of an SOA RRSet.
-
- E.g., given this zone:
- $ORIGIN *.example.
- @ 3600 IN SOA <SOA RDATA>
- 3600 NS ns1.example.com.
- 3600 NS ns1.example.net.
- www 3600 TXT "the www txt record"
-
- A query for www.*.example.'s TXT record would still find the
- "the www txt record" answer. The reason is that the asterisk
- label only becomes significant when section's 4.3.2, step 3
- part 'c' in in effect.
-
- Of course, there would need to be a delegation in the parent
- zone, "example." for this to work too. This is covered in the
- next section.
-
-4.2 NS RRSet at a Wild Card Domain Name
-
- With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
- in place, the semantics of a wild card domain name owning an
- NS RRSet has come to be poorly defined. The dilemma relates to
- a conflict between the rules for synthesis in part 'c' and the
- fact that the resulting synthesis generates a record for which
- the zone is not authoritative. In a DNSSEC signed zone, the
- mechanics of signature management (generation and inclusion
- in a message) become unclear.
-
- After some lengthy discussions, there has been no clear "best
- answer" on how to document the semantics of such a situation.
- Barring such records from the DNS would require definition of
- rules for that, as well as introducing a restriction on records
- that were once legal. Allowing such records and amending the
- process of signature management would entail complicating the
- DNSSEC definition.
-
- There is one more ingredient to the discussion, that being the
- utility of a wild card domain name owned NS RRSet. Although
- there are cases of this use, it is an operational rarity.
- Expending effort to close this topic has proven to be an
- exercise in diminishing returns.
-
- In summary, there is no definition given for wild card domain
- names owning an NS RRSet. The semantics are left undefined until
- there is a clear need to have a set defined, and until there is
- a clear direction to proceed. Operationally, inclusion of wild
- card NS RRSets in a zone is discouraged, but not barred.
-
-4.2.1 Discarded Notions
-
- Prior to DNSSEC, a wild card domain name owning a NS RRSet
- appeared to be workable, and there are some instances in which
- it is found in deployments using implementations that support
- this. Continuing to allow this in the specificaion is not
- tenable with DNSSEC. The reason is that the synthesis of the
- NS RRSet is being done in a zone that has delegated away the
- responsibility for the name. This "unauthorized" synthesis is
- not a problem for the base DNS protocol, but DNSSEC, in affirming
- the authorization model for DNS exposes the problem.
-
- Outright banning of wildcards of type NS is also untenable as
- the DNS protocol does not define how to handle "illegal" data.
- Implementations may choose not to load a zone, but there is no
- protocol definition. The lack of the definition is complicated
- by having to cover dynamic update [RFC 2136], zone transfers,
- as well as loading at the master server. The case of a client
- (resolver, cacheing server) getting a wildcard of type NS in
- a reply would also have to be considered.
-
- Given the daunting challenge of a complete definition of how to
- ban such records, dealing with existing implementations that
- permit the records today is a further complication. There are
- uses of wild card domain name owning NS RRSets.
-
- One compromise proposed would have redefined wildcards of type
- NS to not be used in synthesis, this compromise fell apart
- because it would have required significant edits to the DNSSEC
- signing and validation work. (Again, DNSSEC catches
- unauthorized data.)
-
- With no clear consensus forming on the solution to this dilemma,
- and the realization that wildcards of type NS are a rarity in
- operations, the best course of action is to leave this open-ended
- until "it matters."
-
-4.3 CNAME RRSet at a Wild Card Domain Name
-
- The issue of a CNAME RRSet owned by a wild card domain name has
- prompted a suggested change to the last paragraph of step 3c of
- the algorithm in 4.3.2. The changed text appears in section
- 3.3.3 of this document.
-
-4.4 DNAME RRSet at a Wild Card Domain Name
-
- Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
- represents a threat to the coherency of the DNS and is to be
- avoided or outright rejected. Such a DNAME RRSet represents
- non-deterministic synthesis of rules fed to different caches.
- As caches are fed the different rules (in an unpredictable
- manner) the caches will cease to be coherent. ("As caches
- are fed" refers to the storage in a cache of records obtained
- in responses by recursive or iterative servers.)
-
- For example, assume one cache, responding to a recursive
- request, obtains the record:
- "a.b.example. DNAME foo.bar.example.net."
- and another cache obtains:
- "b.example. DNAME foo.bar.example.net."
- both generated from the record:
- "*.example. DNAME foo.bar.example.net."
- by an authoritative server.
-
- The DNAME specification is not clear on whether DNAME records
- in a cache are used to rewrite queries. In some interpretations,
- the rewrite occurs, in some, it is not. Allowing for the
- occurrence of rewriting, queries for "sub.a.b.example. A" may
- be rewritten as "sub.foo.bar.tld. A" by the former caching
- server and may be rewritten as "sub.a.foo.bar.tld. A" by the
- latter. Coherency is lost, an operational nightmare ensues.
-
- Another justification for banning or avoiding wildcard DNAME
- records is the observation that such a record could synthesize
- a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
- There is a restriction in the DNAME definition that no domain
- exist below a DNAME-owning domain, hence, the wildcard DNAME
- is not to be permitted.
-
-4.5 SRV RRSet at a Wild Card Domain Name
-
- The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
- definition of the record, there is some confusion over the term
- "Name." The definition reads as follows:
-
-# The format of the SRV RR
-...
-# _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-...
-# Name
-# The domain this RR refers to. The SRV RR is unique in that the
-# name one searches for is not this name; the example near the end
-# shows this clearly.
-
- Do not confuse the definition "Name" with the owner name. I.e.,
- once removing the _Service and _Proto labels from the owner name
- of the SRV RRSet, what remains could be a wild card domain name
- but this is immaterial to the SRV RRSet.
-
- E.g., If an SRV record is:
- _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
-
- *.example is a wild card domain name and although it it the Name
- of the SRV RR, it is not the owner (domain name). The owner
- domain name is "_foo._udp.*.example." which is not a wild card
- domain name.
-
- The confusion is likely based on the mixture of the specification
- of the SRV RR and the description of a "use case."
-
-4.6 DS RRSet at a Wild Card Domain Name
-
- A DS RRSet owned by a wild card domain name is meaningless and
- harmless. This statement is made in the context that an NS RRSet
- at a wild card domain name is undefined. At a non-delegation
- point, a DS RRSet has no value (no corresponding DNSKEY RRSet
- will be used in DNSSEC validation). If there is a synthesized
- DS RRSet, it alone will not be very useful as it exists in the
- context of a delegation point.
-
-4.7 NSEC RRSet at a Wild Card Domain Name
-
- Wild card domain names in DNSSEC signed zones will have an NSEC
- RRSet. Synthesis of these records will only occur when the
- query exactly matches the record. Synthesized NSEC RR's will not
- be harmful as they will never be used in negative caching or to
- generate a negative response.
-
-4.8 RRSIG at a Wild Card Domain Name
-
- RRSIG records will be present at a wild card domain name in a
- signed zone, and will be synthesized along with data sought in a
- query. The fact that the owner name is synthesized is not a
- problem as the label count in the RRSIG will instruct the
- verifying code to ignore it.
-
-4.9 Empty Non-terminal Wild Card Domain Name
-
- If a source of synthesis is an empty non-terminal, then the
- response will be one of no error in the return code and no RRSet
- in the answer section.
-
-5. Security Considerations
-
- This document is refining the specifications to make it more
- likely that security can be added to DNS. No functional
- additions are being made, just refining what is considered
- proper to allow the DNS, security of the DNS, and extending
- the DNS to be more predictable.
-
-6. IANA Considerations
-
- None.
-
-7. References
-
- Normative References
-
- [RFC20] ASCII Format for Network Interchange, V.G. Cerf,
- Oct-16-1969
-
- [RFC1034] Domain Names - Concepts and Facilities,
- P.V. Mockapetris, Nov-01-1987
-
- [RFC1035] Domain Names - Implementation and Specification, P.V
- Mockapetris, Nov-01-1987
-
- [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
-
- [RFC2119] Key Words for Use in RFCs to Indicate Requirement
- Levels, S Bradner, March 1997
-
- [RFC2181] Clarifications to the DNS Specification, R. Elz and
- R. Bush, July 1997
-
- [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
- M. Andrews, March 1998
-
- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
- August 1999.
-
- [RFC2782] A DNS RR for specifying the location of services (DNS
- SRV), A. Gulbrandsen, et.al., February 2000
-
- [RFC4033] DNS Security Introduction and Requirements, R. Arends,
- et.al., March 2005
-
- [RFC4034] Resource Records for the DNS Security Extensions,
- R. Arends, et.al., March 2005
-
- [RFC4035] Protocol Modifications for the DNS Security Extensions,
- R. Arends, et.al., March 2005
-
- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
- August 1999
-
- Informative References
-
- [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
- P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
- April 1997
-
-8. Editor
-
- Name: Edward Lewis
- Affiliation: NeuStar
- Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
- Phone: +1-571-434-5468
- Email: ed.lewis@neustar.biz
-
- Comments on this document can be sent to the editor or the mailing
- list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-9. Others Contributing to the Document
-
- This document represents the work of a large working group. The
- editor merely recorded the collective wisdom of the working group.
-
-10. Trailing Boilerplate
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided
- on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
- HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
- SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
- WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
- ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
- INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of
- any Intellectual Property Rights or other rights that might
- be claimed to pertain to the implementation or use of the
- technology described in this document or the extent to which
- any license under such rights might or might not be available;
- nor does it represent that it has made any independent effort
- to identify any such rights. Information on the procedures
- with respect to rights in RFC documents can be found in BCP 78
- and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the
- use of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR
- repository at http://www.ietf.org/ipr. The IETF invites any
- interested party to bring to its attention any copyrights,
- patents or patent applications, or other proprietary rights
- that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-Expiration
-
- This document expires on or about January 6, 2006.
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt
deleted file mode 100644
index e9943015e4e97..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt
+++ /dev/null
@@ -1,1120 +0,0 @@
-
-
-DNS Operations M. Larson
-Internet-Draft P. Barber
-Expires: August 16, 2004 VeriSign
- February 16, 2004
-
-
- Observed DNS Resolution Misbehavior
- draft-ietf-dnsop-bad-dns-res-02
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 16, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This Internet-Draft describes DNS name server and resolver behavior
- that results in a significant query volume sent to the root and
- top-level domain (TLD) name servers. In some cases we recommend
- minor additions to the DNS protocol specification and corresponding
- changes in name server implementations 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.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 1]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- document are to be interpreted as described in RFC 2119 [1].
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Observed name server misbehavior . . . . . . . . . . . . . 4
- 2.1 Aggressive requerying for delegation information . . . . . 4
- 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 5
- 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 5
- 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 6
- 2.3 Inability to follow multiple levels of out-of-zone glue . 6
- 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 7
- 2.4 Aggressive retransmission when fetching glue . . . . . . . 7
- 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8
- 2.5 Aggressive retransmission behind firewalls . . . . . . . . 8
- 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8
- 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 9
- 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 10
- 2.7 Name server records with zero TTL . . . . . . . . . . . . 10
- 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11
- 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 11
- 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11
- 2.9 Queries for domain names resembling IP addresses . . . . . 12
- 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 12
- 2.10 Misdirected recursive queries . . . . . . . . . . . . . . 12
- 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13
- 2.11 Suboptimal name server selection algorithm . . . . . . . . 13
- 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13
- 3. IANA considerations . . . . . . . . . . . . . . . . . . . 15
- 4. Security considerations . . . . . . . . . . . . . . . . . 16
- 5. Internationalization considerations . . . . . . . . . . . 17
- Normative References . . . . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
- Intellectual Property and Copyright Statements . . . . . . 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 2]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
-1. Introduction
-
- Observation of query traffic received by two root name servers and
- the thirteen com/net TLD name servers has revealed that a large
- proportion of the total traffic often consists of "requeries". A
- requery is the same question (<qname, qtype, qclass>) asked
- repeatedly at an unexpectedly high rate. We have observed requeries
- from both a single IP address and multiple IP addresses.
-
- By analyzing requery events we have found that the cause of the
- duplicate traffic is almost always a deficient name server, stub
- resolver and/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 glue records must be followed, and aggressive retry by stub
- resolvers and/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. Some of the changes recommended affect the core DNS protocol
- specification, described principally in RFC 1034 [2], RFC 1035 [3]
- and RFC 2181 [4].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 3]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
-2. Observed name server 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 a recursive name server
- 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 that 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.
-
- 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 recursive name server implementation immediately queries
- a "com" zone name server for the "example.com" NS RRset to verify it
- has the proper delegation information. This name server
- 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 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 a recursive name server 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 is pointless: this query to the parent would come so quickly
- on the heels of the referral that it would be almost certain to
- contain the same list of name servers. The chance of discovering any
- new information is slim.
-
- The other possibility is that the recursive name server successfully
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 4]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- 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 [4], 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 recursing name server 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 and/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, with servers that are 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.
-
-2.1.1 Recommendation
-
- Name servers offering recursion 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 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 [5].
-
-
-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 a subset of a zone's name servers being
- unavailable or misconfigured. Different failure modes have different
- expected durations. Some symptoms indicate problems that are
- potentially transient: 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
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 5]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- 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.
-
-2.2.1 Recommendation
-
- Recursive name servers SHOULD cache name servers that they discover
- are not authoritative for zones delegated to them (i.e. lame
- servers). Lame servers MUST be cached against the specific query
- tuple <zone name, class, server IP address>. Zone name can be
- derived from the owner name of the NS record that was 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.
-
-2.3 Inability to follow multiple levels of out-of-zone glue
-
- Some recursive name server implementations are unable to follow more
- than one level of out-of-zone glue. 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.
-
- A name server processing a recursive query for "www.foo.example" must
- follow two levels of indirection, first obtaining address records for
- "ns1.test.example.net" and/or "ns2.test.example.net" in order to
- obtain address records for "ns1.example.com" and/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
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 6]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- top-level domains (gTLDs) become active. We anticipate many zones in
- the new gTLDs will use name servers in other gTLDs, increasing the
- amount of inter-zone glue.
-
-2.3.1 Recommendation
-
- Clearly constructing a delegation that relies on multiple levels of
- out-of-zone glue is not a good administrative practice. This issue
- could be mitigated with an operational injunction in an RFC to
- refrain from construction of such delegations. In our opinion the
- practice is widespread enough to merit clarifications to the DNS
- protocol specification to permit it on a limited basis.
-
- Name servers offering recursion SHOULD be able to handle at least
- three levels of indirection resulting from out-of-zone glue.
-
-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 A records for every NS record in the
- authority section. If necessary, the name server issues multiple
- queries of its own to obtain any missing A 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 a server will not
- generate any queries of its own. Instead it answers non-recursive
- queries from resolvers looking for information in zones it serves.
- With glue fetching enabled, however, an authoritative server will
- generate queries whenever it needs to look up an unknown address
- record to complete the additional section of a response.
-
- We have observed situations where a glue-fetching name server can
- send queries that reach other name servers, but apparently is
- prevented from receiving the responses. For example, perhaps the
- name server is authoritative-only and therefore its administrators
- expect it to receive only queries. Perhaps unaware of glue fetching
- and presuming that the name server will generate no queries, its
- administrators place the name server behind a network device that
- prevents it from receiving responses. If this is the case, all
- glue-fetching queries will go answered.
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 7]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- We have observed name server implementations that retry excessively
- when glue-fetching queries are unanswered. A single com/net name
- server has received hundreds of queries per second from a single name
- server. 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, a
- recursive name server 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 traffic is improperly
- filtered in this manner. Stub resolvers in the organization could be
- configured to query multiple name servers. Consider the case where a
- stub resolver queries a filtered name server first. This name server
- sends one or more queries whose replies are filtered, so it can't
- respond to the stub resolver, which times out. The resolver
- retransmits to a 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 has a very
- aggressive retransmission schedule, including simultaneous queries to
- multiple name servers, which could explain how such a situation could
- persist without being detected.
-
-2.5.1 Recommendation
-
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 8]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- The most obvious recommendation is that administrators should take
- care not to place recursive name servers behind a firewall that
- prohibits queries to pass through but not the resulting replies.
-
- Name servers 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. A recursive name server
- attempting to resolve A 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
- information is correct in the "com" zone.) The recursive name server
- 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" A record in the answer section
- and, typically, the "example.com" NS records in the authority section
- and, if space in the message remains, glue A records in the
- additional section. According to Section 5.4 of RFC 2181 [4], 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 displaces the
- "example.com" NS RRset received moments ago from the "com"
- 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 server to attempt to use the incorrect NS records and
- so the server will try to resolve the nonexistent names
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 9]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- "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 recursive server cannot reach any "example.com" name
- servers. Therefore attempts to resolve these names result in A
- record queries to the "com' authoritative servers. Queries for such
- obviously bogus glue A 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 is in the zone. But any in-zone name server
- should have a corresponding glue A record also in the zone. An
- authoritative name server should report an error when a zone's NS
- record references an in-zone name server without a corresponding glue
- A record.
-
-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 a recursive name
- server 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
- 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 recursive name servers throughout the Internet to cache the NS
- RRset for a long period of time, a low TTL is reasonable.
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 10]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
-2.7.1 Recommendation
-
- Because of the additional load placed on a zone's parent's
- authoritative servers imposed by a zero TTL on a zone's NS RRset,
- under such circumstances authoritative name servers should issue a
- warning when loading a zone or refuse to load the zone altogether.
-
-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
- is the lowest zone in the name space. The closest enclosing zone
- 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 involves working up the name
- space tree and sending repeated UPDATE messages until success. For
- example, consider an agent attempting to add an A 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 reasonable question is why the algorithm proceeds with
- sending updates all the way to TLD and root name servers. In
- enterprise DNS architectures with an "internal root" design, there
- could conceivably be private, non-public TLD or root zones that would
- be the appropriate target for a dynamic update. However, we question
- if designing an algorithm to accommodate these limited cases is worth
- the load it places on the public DNS in the form of unnecessary
- UPDATE messages.
-
-2.8.1 Recommendation
-
- Dynamic update agents should not attempt to send UPDATE messages to
- authoritative servers for TLD zones or the root zone by default. If
- this functionality is supported, it should be require specific action
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 11]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- by a user to be enabled.
-
-2.9 Queries for domain names resembling IP addresses
-
- The root name servers receive a significant number of A record
- queries where the qname is an IP 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. A recursive
- name server 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
- bandwidth. One possibility is for recursive name server
- implementations to produce the Name Error response directly. We
- suggest that implementors consider the option of synthesizing Name
- Error responses at the recursive name server. The server could claim
- authority for synthesized TLD zones corresponding to the first octet
- of every possible IP address, e.g. 1., 2., through 255. This
- behavior could be configurable in the (probably unlikely) event that
- numeric TLDs are ever put into use.
-
- Another option is to delegate these numeric TLDs from the root zone
- to a separate set of servers to absorb the traffic. The "blackhole
- servers" used by the 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.
-
-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 offer 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
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 12]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- 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 (supposedly) recursive name server is
- configured in a stub resolver using an interactive user interface,
- the resolver could send a test query to verify that the server
- supports recursion (i.e., 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 underspecified, 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.
-
- Some deficiencies cause significant operational impact and are
- therefore worth mentioning here. One of these is name server
- selection by a recursive name server. When a recursive name server
- 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.
-
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 13]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- 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.
- 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. A
- recursive name server 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 August 16, 2004 [Page 14]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
-3. IANA considerations
-
- There are no new IANA considerations introduced by this
- Internet-Draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 15]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
-4. Security considerations
-
- Name server and resolver misbehaviors identical or similar to those
- discussed in this document expose the root and TLD name servers to
- increased risk of both intentional and unintentional denial of
- service.
-
- 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 August 16, 2004 [Page 16]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
-5. Internationalization considerations
-
- We do not believe this document introduces any new
- internationalization considerations to the DNS protocol
- specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 17]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
-Normative 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] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
- 2308, March 1998.
-
- [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
- 1997.
-
- [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
- Lear, "Address Allocation for Private Internets", BCP 5, RFC
- 1918, February 1996.
-
- [8] <http://www.as112.net>
-
-
-Authors' Addresses
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Piet Barber
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: pbarber@verisign.com
-
-
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 18]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
-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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 19]
-
-Internet-Draft Observed DNS Resolution Misbehavior February 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 16, 2004 [Page 20]
-
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
deleted file mode 100644
index a56969e57f667..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt
+++ /dev/null
@@ -1,1176 +0,0 @@
-
-
-
-DNS Operations M. Larson
-Internet-Draft P. Barber
-Expires: January 18, 2006 VeriSign
- July 17, 2005
-
-
- Observed DNS Resolution Misbehavior
- draft-ietf-dnsop-bad-dns-res-04
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on January 18, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This memo describes DNS iterative resolver behavior that results in a
- significant query volume sent to the root and top-level domain (TLD)
- name servers. We offer implementation advice to iterative resolver
- developers to alleviate these unnecessary queries. The
- recommendations made in this document are a direct byproduct of
- observation and analysis of abnormal query traffic patterns seen at
- two of the thirteen root name servers and all thirteen com/net TLD
- name servers.
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 1]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [1].
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 A note about terminology in this memo . . . . . . . . . . 3
- 2. Observed iterative resolver misbehavior . . . . . . . . . . 5
- 2.1 Aggressive requerying for delegation information . . . . . 5
- 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6
- 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 7
- 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7
- 2.3 Inability to follow multiple levels of indirection . . . . 8
- 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9
- 2.4 Aggressive retransmission when fetching glue . . . . . . . 9
- 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10
- 2.5 Aggressive retransmission behind firewalls . . . . . . . . 10
- 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11
- 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 11
- 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12
- 2.7 Name server records with zero TTL . . . . . . . . . . . . 12
- 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13
- 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 13
- 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14
- 2.9 Queries for domain names resembling IPv4 addresses . . . . 14
- 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14
- 2.10 Misdirected recursive queries . . . . . . . . . . . . . 15
- 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 15
- 2.11 Suboptimal name server selection algorithm . . . . . . . 15
- 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 16
- 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 17
- 4. Security considerations . . . . . . . . . . . . . . . . . . 18
- 5. Internationalization considerations . . . . . . . . . . . . 19
- 6. Informative References . . . . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
- Intellectual Property and Copyright Statements . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 2]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-1. Introduction
-
- Observation of query traffic received by two root name servers and
- the thirteen com/net TLD name servers has revealed that a large
- proportion of the total traffic often consists of "requeries". A
- requery is the same question (<QNAME, QTYPE, QCLASS>) asked
- repeatedly at an unexpectedly high rate. We have observed requeries
- from both a single IP address and multiple IP addresses (i.e., the
- same query received simultaneously from multiple IP addresses).
-
- By analyzing requery events we have found that the cause of the
- duplicate traffic is almost always a deficient iterative resolver,
- stub resolver or application implementation combined with an
- operational anomaly. The implementation deficiencies we have
- identified to date include well-intentioned recovery attempts gone
- awry, insufficient caching of failures, early abort when multiple
- levels of indirection must be followed, and aggressive retry by stub
- resolvers or applications. Anomalies that we have seen trigger
- requery events include lame delegations, unusual glue records, and
- anything that makes all authoritative name servers for a zone
- unreachable (DoS attacks, crashes, maintenance, routing failures,
- congestion, etc.).
-
- In the following sections, we provide a detailed explanation of the
- observed behavior and recommend changes that will reduce the requery
- rate. None of the changes recommended affects the core DNS protocol
- specification; instead, this document consists of guidelines to
- implementors of iterative resolvers.
-
-1.1 A note about terminology in this memo
-
- To recast an old saying about standards, the nice thing about DNS
- terms is that there are so many of them to choose from. Writing or
- talking about DNS can be difficult and cause confusion resulting from
- a lack of agreed-upon terms for its various components. Further
- complicating matters are implementations that combine multiple roles
- into one piece of software, which makes naming the result
- problematic. An example is the entity that accepts recursive
- queries, issues iterative queries as necessary to resolve the initial
- recursive query, caches responses it receives, and which is also able
- to answer questions about certain zones authoritatively. This entity
- is an iterative resolver combined with an authoritative name server
- and is often called a "recursive name server" or a "caching name
- server".
-
- This memo is concerned principally with the behavior of iterative
- resolvers, which are typically found as part of a recursive name
- server. This memo uses the more precise term "iterative resolver",
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 3]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- because the focus is usually on that component. In instances where
- the name server role of this entity requires mentioning, this memo
- uses the term "recursive name server". As an example of the
- difference, the name server component of a recursive name server
- receives DNS queries and the iterative resolver component sends
- queries.
-
- The advent of IPv6 requires mentioning AAAA records as well as A
- records when discussing glue. To avoid continuous repetition and
- qualification, this memo uses the general term "address record" to
- encompass both A and AAAA records when a particular situation is
- relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 4]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-2. Observed iterative resolver misbehavior
-
-2.1 Aggressive requerying for delegation information
-
- There can be times when every name server in a zone's NS RRset is
- unreachable (e.g., during a network outage), unavailable (e.g., the
- name server process is not running on the server host) or
- misconfigured (e.g., the name server is not authoritative for the
- given zone, also known as "lame"). Consider an iterative resolver
- that attempts to resolve a query for a domain name in such a zone and
- discovers that none of the zone's name servers can provide an answer.
- We have observed a recursive name server implementation whose
- iterative resolver then verifies the zone's NS RRset in its cache by
- querying for the zone's delegation information: it sends a query for
- the zone's NS RRset to one of the parent zone's name servers. (Note
- that queries with QTYPE=NS are not required by the standard
- resolution algorithm described in section 4.3.2 of RFC 1034 [2].
- These NS queries represent this implementation's addition to that
- algorithm.)
-
- For example, suppose that "example.com" has the following NS RRset:
-
- example.com. IN NS ns1.example.com.
- example.com. IN NS ns2.example.com.
-
- Upon receipt of a query for "www.example.com" and assuming that
- neither "ns1.example.com" nor "ns2.example.com" can provide an
- answer, this iterative resolver implementation immediately queries a
- "com" zone name server for the "example.com" NS RRset to verify it
- has the proper delegation information. This implementation performs
- this query to a zone's parent zone for each recursive query it
- receives that fails because of a completely unresponsive set of name
- servers for the target zone. Consider the effect when a popular zone
- experiences a catastrophic failure of all its name servers: now every
- recursive query for domain names in that zone sent to this recursive
- name server implementation results in a query to the failed zone's
- parent name servers. On one occasion when several dozen popular
- zones became unreachable, the query load on the com/net name servers
- increased by 50%.
-
- We believe this verification query is not reasonable. Consider the
- circumstances: When an iterative resolver is resolving a query for a
- domain name in a zone it has not previously searched, it uses the
- list of name servers in the referral from the target zone's parent.
- If on its first attempt to search the target zone, none of the name
- servers in the referral is reachable, a verification query to the
- parent would be pointless: this query to the parent would come so
- quickly on the heels of the referral that it would be almost certain
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 5]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- to contain the same list of name servers. The chance of discovering
- any new information is slim.
-
- The other possibility is that the iterative resolver successfully
- contacts one of the target zone's name servers and then caches the NS
- RRset from the authority section of a response, the proper behavior
- according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
- the target zone is more trustworthy than delegation information from
- the parent zone. If, while processing a subsequent recursive query,
- the iterative resolver discovers that none of the name servers
- specified in the cached NS RRset is available or authoritative,
- querying the parent would be wrong. An NS RRset from the parent zone
- would now be less trustworthy than data already in the cache.
-
- For this query of the parent zone to be useful, the target zone's
- entire set of name servers would have to change AND the former set of
- name servers would have to be deconfigured or decommissioned AND the
- delegation information in the parent zone would have to be updated
- with the new set of name servers, all within the TTL of the target
- zone's NS RRset. We believe this scenario is uncommon:
- administrative best practices dictate that changes to a zone's set of
- name servers happen gradually when at all possible, with servers
- removed from the NS RRset left authoritative for the zone as long as
- possible. The scenarios that we can envision that would benefit from
- the parent requery behavior do not outweigh its damaging effects.
-
- This section should not be understood to claim that all queries to a
- zone's parent are bad. In some cases, such queries are not only
- reasonable but required. Consider the situation when required
- information, such as the address of a name server (i.e., the address
- record corresponding to the RDATA of an NS record), has timed out of
- an iterative resolver's cache before the corresponding NS record. If
- the name of the name server is below the apex of the zone, then the
- name server's address record is only available as glue in the parent
- zone. For example, consider this NS record:
-
- example.com. IN NS ns.example.com.
-
- If a cache has this NS record but not the address record for
- "ns.example.com", it is unable to contact the "example.com" zone
- directly and must query the "com" zone to obtain the address record.
- Note, however, that such a query would not have QTYPE=NS according to
- the standard resolution algorithm.
-
-2.1.1 Recommendation
-
- An iterative resolver MUST NOT send a query for the NS RRset of a
- non-responsive zone to any of the name servers for that zone's parent
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 6]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- zone. For the purposes of this injunction, a non-responsive zone is
- defined as a zone for which every name server listed in the zone's NS
- RRset:
-
- 1. is not authoritative for the zone (i.e., lame), or,
-
- 2. returns a server failure response (RCODE=2), or,
-
- 3. is dead or unreachable according to section 7.2 of RFC 2308 [4].
-
-
-2.2 Repeated queries to lame servers
-
- Section 2.1 describes a catastrophic failure: when every name server
- for a zone is unable to provide an answer for one reason or another.
- A more common occurrence is when a subset of a zone's name servers
- are unavailable or misconfigured. Different failure modes have
- different expected durations. Some symptoms indicate problems that
- are potentially transient; for example, various types of ICMP
- unreachable messages because a name server process is not running or
- a host or network is unreachable, or a complete lack of a response to
- a query. Such responses could be the result of a host rebooting or
- temporary outages; these events don't necessarily require any human
- intervention and can be reasonably expected to be temporary.
-
- Other symptoms clearly indicate a condition requiring human
- intervention, such as lame server: if a name server is misconfigured
- and not authoritative for a zone delegated to it, it is reasonable to
- assume that this condition has potential to last longer than
- unreachability or unresponsiveness. Consequently, repeated queries
- to known lame servers are not useful. In this case of a condition
- with potential to persist for a long time, a better practice would be
- to maintain a list of known lame servers and avoid querying them
- repeatedly in a short interval.
-
- It should also be noted, however, that some authoritative name server
- implementations appear to be lame only for queries of certain types
- as described in RFC 4074 [5]. In this case, it makes sense to retry
- the "lame" servers for other types of queries, particularly when all
- known authoritative name servers appear to be "lame".
-
-2.2.1 Recommendation
-
- Iterative resolvers SHOULD cache name servers that they discover are
- not authoritative for zones delegated to them (i.e. lame servers).
- If this caching is performed, lame servers MUST be cached against the
- specific query tuple <zone name, class, server IP address>. Zone
- name can be derived from the owner name of the NS record that was
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 7]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- referenced to query the name server that was discovered to be lame.
- Implementations that perform lame server caching MUST refrain from
- sending queries to known lame servers based on a time interval from
- when the server is discovered to be lame. A minimum interval of
- thirty minutes is RECOMMENDED.
-
- An exception to this recommendation occurs if all name servers for a
- zone are marked lame. In that case, the iterative resolver SHOULD
- temporarily ignore the servers' lameness status and query one or more
- servers. This behavior is a workaround for the type-specific
- lameness issue described in the previous section.
-
- Implementors should take care not to make lame server avoidance logic
- overly broad: note that a name server could be lame for a parent zone
- but not a child zone, e.g., lame for "example.com" but properly
- authoritative for "sub.example.com". Therefore a name server should
- not be automatically considered lame for subzones. In the case
- above, even if a name server is known to be lame for "example.com",
- it should be queried for QNAMEs at or below "sub.example.com" if an
- NS record indicates it should be authoritative for that zone.
-
-2.3 Inability to follow multiple levels of indirection
-
- Some iterative resolver implementations are unable to follow
- sufficient levels of indirection. For example, consider the
- following delegations:
-
- foo.example. IN NS ns1.example.com.
- foo.example. IN NS ns2.example.com.
-
- example.com. IN NS ns1.test.example.net.
- example.com. IN NS ns2.test.example.net.
-
- test.example.net. IN NS ns1.test.example.net.
- test.example.net. IN NS ns2.test.example.net.
-
- An iterative resolver resolving the name "www.foo.example" must
- follow two levels of indirection, first obtaining address records for
- "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
- address records for "ns1.example.com" or "ns2.example.com" in order
- to query those name servers for the address records of
- "www.foo.example". While this situation may appear contrived, we
- have seen multiple similar occurrences and expect more as new generic
- top-level domains (gTLDs) become active. We anticipate many zones in
- new gTLDs will use name servers in existing gTLDs, increasing the
- number of delegations using out-of-zone name servers.
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 8]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-2.3.1 Recommendation
-
- Clearly constructing a delegation that relies on multiple levels of
- indirection is not a good administrative practice. However, the
- practice is widespread enough to require that iterative resolvers be
- able to cope with it. Iterative resolvers SHOULD be able to handle
- arbitrary levels of indirection resulting from out-of-zone name
- servers. Iterative resolvers SHOULD implement a level-of-effort
- counter to avoid loops or otherwise performing too much work in
- resolving pathological cases.
-
- A best practice that avoids this entire issue of indirection is to
- name one or more of a zone's name servers in the zone itself. For
- example, if the zone is named "example.com", consider naming some of
- the name servers "ns{1,2,...}.example.com" (or similar).
-
-2.4 Aggressive retransmission when fetching glue
-
- When an authoritative name server responds with a referral, it
- includes NS records in the authority section of the response.
- According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
- server should also "put whatever addresses are available into the
- additional section, using glue RRs if the addresses are not available
- from authoritative data or the cache." Some name server
- implementations take this address inclusion a step further with a
- feature called "glue fetching". A name server that implements glue
- fetching attempts to include address records for every NS record in
- the authority section. If necessary, the name server issues multiple
- queries of its own to obtain any missing address records.
-
- Problems with glue fetching can arise in the context of
- "authoritative-only" name servers, which only serve authoritative
- data and ignore requests for recursion. Such an entity will not
- normally generate any queries of its own. Instead it answers non-
- recursive queries from iterative resolvers looking for information in
- zones it serves. With glue fetching enabled, however, an
- authoritative server invokes an iterative resolver to look up an
- unknown address record to complete the additional section of a
- response.
-
- We have observed situations where the iterative resolver of a glue-
- fetching name server can send queries that reach other name servers,
- but is apparently prevented from receiving the responses. For
- example, perhaps the name server is authoritative-only and therefore
- its administrators expect it to receive only queries and not
- responses. Perhaps unaware of glue fetching and presuming that the
- name server's iterative resolver will generate no queries, its
- administrators place the name server behind a network device that
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 9]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- prevents it from receiving responses. If this is the case, all glue-
- fetching queries will go answered.
-
- We have observed name server implementations whose iterative
- resolvers retry excessively when glue-fetching queries are
- unanswered. A single com/net name server has received hundreds of
- queries per second from a single such source. Judging from the
- specific queries received and based on additional analysis, we
- believe these queries result from overly aggressive glue fetching.
-
-2.4.1 Recommendation
-
- Implementers whose name servers support glue fetching SHOULD take
- care to avoid sending queries at excessive rates. Implementations
- SHOULD support throttling logic to detect when queries are sent but
- no responses are received.
-
-2.5 Aggressive retransmission behind firewalls
-
- A common occurrence and one of the largest sources of repeated
- queries at the com/net and root name servers appears to result from
- resolvers behind misconfigured firewalls. In this situation, an
- iterative resolver is apparently allowed to send queries through a
- firewall to other name servers, but not receive the responses. The
- result is more queries than necessary because of retransmission, all
- of which are useless because the responses are never received. Just
- as with the glue-fetching scenario described in Section 2.4, the
- queries are sometimes sent at excessive rates. To make matters
- worse, sometimes the responses, sent in reply to legitimate queries,
- trigger an alarm on the originator's intrusion detection system. We
- are frequently contacted by administrators responding to such alarms
- who believe our name servers are attacking their systems.
-
- Not only do some resolvers in this situation retransmit queries at an
- excessive rate, but they continue to do so for days or even weeks.
- This scenario could result from an organization with multiple
- recursive name servers, only a subset of whose iterative resolvers'
- traffic is improperly filtered in this manner. Stub resolvers in the
- organization could be configured to query multiple recursive name
- servers. Consider the case where a stub resolver queries a filtered
- recursive name server first. The iterative resolver of this
- recursive name server sends one or more queries whose replies are
- filtered, so it can't respond to the stub resolver, which times out.
- Then the stub resolver retransmits to a recursive name server that is
- able to provide an answer. Since resolution ultimately succeeds the
- underlying problem might not be recognized or corrected. A popular
- stub resolver implementation has a very aggressive retransmission
- schedule, including simultaneous queries to multiple recursive name
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 10]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- servers, which could explain how such a situation could persist
- without being detected.
-
-2.5.1 Recommendation
-
- The most obvious recommendation is that administrators SHOULD take
- care not to place iterative resolvers behind a firewall that allows
- queries to pass through but not the resulting replies.
-
- Iterative resolvers SHOULD take care to avoid sending queries at
- excessive rates. Implementations SHOULD support throttling logic to
- detect when queries are sent but no responses are received.
-
-2.6 Misconfigured NS records
-
- Sometimes a zone administrator forgets to add the trailing dot on the
- domain names in the RDATA of a zone's NS records. Consider this
- fragment of the zone file for "example.com":
-
- $ORIGIN example.com.
- example.com. 3600 IN NS ns1.example.com ; Note missing
- example.com. 3600 IN NS ns2.example.com ; trailing dots
-
- The zone's authoritative servers will parse the NS RDATA as
- "ns1.example.com.example.com" and "ns2.example.com.example.com" and
- return NS records with this incorrect RDATA in responses, including
- typically the authority section of every response containing records
- from the "example.com" zone.
-
- Now consider a typical sequence of queries. An iterative resolver
- attempting to resolve address records for "www.example.com" with no
- cached information for this zone will query a "com" authoritative
- server. The "com" server responds with a referral to the
- "example.com" zone, consisting of NS records with valid RDATA and
- associated glue records. (This example assumes that the
- "example.com" zone delegation information is correct in the "com"
- zone.) The iterative resolver caches the NS RRset from the "com"
- server and follows the referral by querying one of the "example.com"
- authoritative servers. This server responds with the
- "www.example.com" address record in the answer section and,
- typically, the "example.com" NS records in the authority section and,
- if space in the message remains, glue address records in the
- additional section. According to Section 5.4 of RFC 2181 [3], NS
- records in the authority section of an authoritative answer are more
- trustworthy than NS records from the authority section of a non-
- authoritative answer. Thus the "example.com" NS RRset just received
- from the "example.com" authoritative server overrides the
- "example.com" NS RRset received moments ago from the "com"
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 11]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- authoritative server.
-
- But the "example.com" zone contains the erroneous NS RRset as shown
- in the example above. Subsequent queries for names in "example.com"
- will cause the iterative resolver to attempt to use the incorrect NS
- records and so it will try to resolve the nonexistent names
- "ns1.example.com.example.com" and "ns2.example.com.example.com". In
- this example, since all of the zone's name servers are named in the
- zone itself (i.e., "ns1.example.com.example.com" and
- "ns2.example.com.example.com" both end in "example.com") and all are
- bogus, the iterative resolver cannot reach any "example.com" name
- servers. Therefore attempts to resolve these names result in address
- record queries to the "com" authoritative servers. Queries for such
- obviously bogus glue address records occur frequently at the com/net
- name servers.
-
-2.6.1 Recommendation
-
- An authoritative server can detect this situation. A trailing dot
- missing from an NS record's RDATA always results by definition in a
- name server name that exists somewhere under the apex of the zone the
- NS record appears in. Note that further levels of delegation are
- possible, so a missing trailing dot could inadvertently create a name
- server name that actually exists in a subzone.
-
- An authoritative name server SHOULD issue a warning when one of a
- zone's NS records references a name server below the zone's apex when
- a corresponding address record does not exist in the zone AND there
- are no delegated subzones where the address record could exist.
-
-2.7 Name server records with zero TTL
-
- Sometimes a popular com/net subdomain's zone is configured with a TTL
- of zero on the zone's NS records, which prohibits these records from
- being cached and will result in a higher query volume to the zone's
- authoritative servers. The zone's administrator should understand
- the consequences of such a configuration and provision resources
- accordingly. A zero TTL on the zone's NS RRset, however, carries
- additional consequences beyond the zone itself: if an iterative
- resolver cannot cache a zone's NS records because of a zero TTL, it
- will be forced to query that zone's parent's name servers each time
- it resolves a name in the zone. The com/net authoritative servers do
- see an increased query load when a popular com/net subdomain's zone
- is configured with a TTL of zero on the zone's NS records.
-
- A zero TTL on an RRset expected to change frequently is extreme but
- permissible. A zone's NS RRset is a special case, however, because
- changes to it must be coordinated with the zone's parent. In most
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 12]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- zone parent/child relationships we are aware of, there is typically
- some delay involved in effecting changes. Further, changes to the
- set of a zone's authoritative name servers (and therefore to the
- zone's NS RRset) are typically relatively rare: providing reliable
- authoritative service requires a reasonably stable set of servers.
- Therefore an extremely low or zero TTL on a zone's NS RRset rarely
- makes sense, except in anticipation of an upcoming change. In this
- case, when the zone's administrator has planned a change and does not
- want iterative resolvers throughout the Internet to cache the NS
- RRset for a long period of time, a low TTL is reasonable.
-
-2.7.1 Recommendation
-
- Because of the additional load placed on a zone's parent's
- authoritative servers resulting from a zero TTL on a zone's NS RRset,
- under such circumstances authoritative name servers SHOULD issue a
- warning when loading a zone.
-
-2.8 Unnecessary dynamic update messages
-
- The UPDATE message specified in RFC 2136 [6] allows an authorized
- agent to update a zone's data on an authoritative name server using a
- DNS message sent over the network. Consider the case of an agent
- desiring to add a particular resource record. Because of zone cuts,
- the agent does not necessarily know the proper zone to which the
- record should be added. The dynamic update process requires that the
- agent determine the appropriate zone so the UPDATE message can be
- sent to one of the zone's authoritative servers (typically the
- primary master as specified in the zone's SOA MNAME field).
-
- The appropriate zone to update is the closest enclosing zone, which
- cannot be determined only by inspecting the domain name of the record
- to be updated, since zone cuts can occur anywhere. One way to
- determine the closest enclosing zone entails walking up the name
- space tree by sending repeated UPDATE messages until success. For
- example, consider an agent attempting to add an address record with
- the name "foo.bar.example.com". The agent could first attempt to
- update the "foo.bar.example.com" zone. If the attempt failed, the
- update could be directed to the "bar.example.com" zone, then the
- "example.com" zone, then the "com" zone, and finally the root zone.
-
- A popular dynamic agent follows this algorithm. The result is many
- UPDATE messages received by the root name servers, the com/net
- authoritative servers, and presumably other TLD authoritative
- servers. A valid question is why the algorithm proceeds to send
- updates all the way to TLD and root name servers. This behavior is
- not entirely unreasonable: in enterprise DNS architectures with an
- "internal root" design, there could conceivably be private, non-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 13]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- public TLD or root zones that would be the appropriate targets for a
- dynamic update.
-
- A significant deficiency with this algorithm is that knowledge of a
- given UPDATE message's failure is not helpful in directing future
- UPDATE messages to the appropriate servers. A better algorithm would
- be to find the closest enclosing zone by walking up the name space
- with queries for SOA or NS rather than "probing" with UPDATE
- messages. Once the appropriate zone is found, an UPDATE message can
- be sent. In addition, the results of these queries can be cached to
- aid in determining closest enclosing zones for future updates. Once
- the closest enclosing zone is determined with this method, the update
- will either succeed or fail and there is no need to send further
- updates to higher-level zones. The important point is that walking
- up the tree with queries yields cacheable information, whereas
- walking up the tree by sending UPDATE messages does not.
-
-2.8.1 Recommendation
-
- Dynamic update agents SHOULD send SOA or NS queries to progressively
- higher-level names to find the closest enclosing zone for a given
- name to update. Only after the appropriate zone is found should the
- client send an UPDATE message to one of the zone's authoritative
- servers. Update clients SHOULD NOT "probe" using UPDATE messages by
- walking up the tree to progressively higher-level zones.
-
-2.9 Queries for domain names resembling IPv4 addresses
-
- The root name servers receive a significant number of A record
- queries where the QNAME looks like an IPv4 address. The source of
- these queries is unknown. It could be attributed to situations where
- a user believes an application will accept either a domain name or an
- IP address in a given configuration option. The user enters an IP
- address, but the application assumes any input is a domain name and
- attempts to resolve it, resulting in an A record lookup. There could
- also be applications that produce such queries in a misguided attempt
- to reverse map IP addresses.
-
- These queries result in Name Error (RCODE=3) responses. An iterative
- resolver can negatively cache such responses, but each response
- requires a separate cache entry, i.e., a negative cache entry for the
- domain name "192.0.2.1" does not prevent a subsequent query for the
- domain name "192.0.2.2".
-
-2.9.1 Recommendation
-
- It would be desirable for the root name servers not to have to answer
- these queries: they unnecessarily consume CPU resources and network
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 14]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- bandwidth. A possible solution is to delegate these numeric TLDs
- from the root zone to a separate set of servers to absorb the
- traffic. The "black hole servers" used by the AS 112 Project [8],
- which are currently delegated the in-addr.arpa zones corresponding to
- RFC 1918 [7] private use address space, would be a possible choice to
- receive these delegations. Of course, the proper and usual root zone
- change procedures would have to be followed to make such a change to
- the root zone.
-
-2.10 Misdirected recursive queries
-
- The root name servers receive a significant number of recursive
- queries (i.e., queries with the RD bit set in the header). Since
- none of the root servers offers recursion, the servers' response in
- such a situation ignores the request for recursion and the response
- probably does not contain the data the querier anticipated. Some of
- these queries result from users configuring stub resolvers to query a
- root server. (This situation is not hypothetical: we have received
- complaints from users when this configuration does not work as
- hoped.) Of course, users should not direct stub resolvers to use
- name servers that do not offer recursion, but we are not aware of any
- stub resolver implementation that offers any feedback to the user
- when so configured, aside from simply "not working".
-
-2.10.1 Recommendation
-
- When the IP address of a name server that supposedly offers recursion
- is configured in a stub resolver using an interactive user interface,
- the resolver could send a test query to verify that the server indeed
- supports recursion (i.e., verify that the response has the RA bit set
- in the header). The user could be immediately notified if the server
- is non-recursive.
-
- The stub resolver could also report an error, either through a user
- interface or in a log file, if the queried server does not support
- recursion. Error reporting SHOULD be throttled to avoid a
- notification or log message for every response from a non-recursive
- server.
-
-2.11 Suboptimal name server selection algorithm
-
- An entire document could be devoted to the topic of problems with
- different implementations of the recursive resolution algorithm. The
- entire process of recursion is woefully under specified, requiring
- each implementor to design an algorithm. Sometimes implementors make
- poor design choices that could be avoided if a suggested algorithm
- and best practices were documented, but that is a topic for another
- document.
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 15]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- Some deficiencies cause significant operational impact and are
- therefore worth mentioning here. One of these is name server
- selection by an iterative resolver. When an iterative resolver wants
- to contact one of a zone's authoritative name servers, how does it
- choose from the NS records listed in the zone's NS RRset? If the
- selection mechanism is suboptimal, queries are not spread evenly
- among a zone's authoritative servers. The details of the selection
- mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1 Recommendation
-
- This list is not conclusive, but reflects the changes that would
- produce the most impact in terms of reducing disproportionate query
- load among a zone's authoritative servers. I.e., these changes would
- help spread the query load evenly.
-
- o Do not make assumptions based on NS RRset order: all NS RRs SHOULD
- be treated equally. (In the case of the "com" zone, for example,
- most of the root servers return the NS record for "a.gtld-
- servers.net" first in the authority section of referrals.
- Apparently as a result, this server receives disproportionately
- more traffic than the other 12 authoritative servers for "com".)
-
- o Use all NS records in an RRset. (For example, we are aware of
- implementations that hard-coded information for a subset of the
- root servers.)
-
- o Maintain state and favor the best-performing of a zone's
- authoritative servers. A good definition of performance is
- response time. Non-responsive servers can be penalized with an
- extremely high response time.
-
- o Do not lock onto the best-performing of a zone's name servers. An
- iterative resolver SHOULD periodically check the performance of
- all of a zone's name servers to adjust its determination of the
- best-performing one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 16]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-3. IANA considerations
-
- There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 17]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-4. Security considerations
-
- The iterative resolver misbehavior discussed in this document exposes
- the root and TLD name servers to increased risk of both intentional
- and unintentional denial of service attacks.
-
- We believe that implementation of the recommendations offered in this
- document will reduce the amount of unnecessary traffic seen at root
- and TLD name servers, thus reducing the opportunity for an attacker
- to use such queries to his or her advantage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 18]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-5. Internationalization considerations
-
- There are no new internationalization considerations introduced by
- this memo.
-
-6. Informative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
- [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
- Queries for IPv6 Addresses", RFC 4074, May 2005.
-
- [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
- Lear, "Address Allocation for Private Internets", BCP 5,
- RFC 1918, February 1996.
-
- [8] <http://www.as112.net>
-
-
-Authors' Addresses
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- Email: mlarson@verisign.com
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 19]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- Piet Barber
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- Email: pbarber@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 20]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 21]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
deleted file mode 100644
index 04815175fdbab..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
+++ /dev/null
@@ -1,1344 +0,0 @@
-
-DNSOP O. Kolkman
-Internet-Draft RIPE NCC
-Expires: August 30, 2004 R. Gieben
- NLnet Labs
- March 2004
-
-
- DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-01.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 30, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document describes a set of practices for operating a DNSSEC
- aware environment. The target audience is zone administrators
- deploying DNSSEC that need a guide to help them chose appropriate
- values for DNSSEC parameters. It also discusses operational matters
- such as key rollovers, KSK and ZSK considerations and related
- matters.
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 1]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3
- 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3
- 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4
- 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5
- 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1 Motivations for the KSK and ZSK Functions . . . . . . . . 7
- 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8
- 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8
- 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8
- 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9
- 3.3.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10
- 3.3.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 13
- 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 14
- 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
- 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
- 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16
- 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 16
- 5.1 Initial Key Exchanges and Parental Policies
- Considerations . . . . . . . . . . . . . . . . . . . . . . 16
- 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 16
- 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 17
- 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 17
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
- 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
- A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
- B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 20
- C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 20
- D. Document Details and Changes . . . . . . . . . . . . . . . . . 22
- D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22
- D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22
- Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 2]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-1. Introduction
-
- During workshops and early operational deployment tests, operators
- and system administrators gained experience about operating DNSSEC
- aware DNS services. 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 represented '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: It begins with
- discussing some of the considerations with respect to timing
- parameters of DNS in relation to DNSSEC (Section 2). Aspects of key
- management such as key rollover schemes are described in Section 3.
- Emergency rollover considerations are addressed in Section 4. 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 [5] language does not apply.
-
-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
- [Ref to Schneider?]). 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
- used in key-exchanges.
-
-1.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, which may cause
- entire (sub)domains to become invisible to verifying clients. The
- administrators of secured zones have to realise 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,
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 3]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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, during which
- period clients may be fetching data from caching non-authoritative
- servers. For the verifying clients it is important that data from
- secured 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 the fact that the key has been
- stolen, must be made.
-
- The zone administrator will have to make a tradeoff between keeping
- the chain of trust intact -thereby allowing for attacks with the
- compromised key- or to deliberately break the chain of trust thereby
- making secured subdomains invisible to security aware resolvers. Also
- see Section 4.
-
-2. Time in DNSSEC
-
- Without DNSSEC all times in DNS are relative. The SOA's refresh,
- retry and expiration timers are counters that are used to determine
- the time elapsed after a slave server syncronised (or tried to
- syncronise) with a master server. The Time to Live (TTL) value and
- the SOA minimum TTL parameter [6] are used to determine how long a
- forwarder should cache data after it has been fetched from an
- authoritative server. 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.
-
-2.1 Time Definitions
-
- In this document we will be using a number of time related terms.
- Within the context of this document 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.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 4]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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. If a signature is published at time T0 and a
- new signature is published at time T1, the signature
- publication period is T1 - T0.
- If all signatures are refreshed at zone (re)signing then the
- signature publication period is equal signature validity
- period.
- o "Maximum/Minimum Zone TTL"
- The maximum or minimum value of all the TTLs in a zone.
-
-2.2 Time Considerations
-
- Because of the expiration of signatures, one should consider the
- following.
- o The Maximum Zone TTL of your zone data should 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. As a
- result query load on authoritative servers would peak at
- signature expiration time.
- 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 The signature publication period should 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 The Minimum zone TTL should be long enough to both fetch and
- verify all the RRs in the authentication chain.
- 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 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.
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 5]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- We have seen events where data needed for verification of an
- authentication chain had expired from caches.
- We suggest the TTL on DNSKEY and DSs to be between ten minutes
- and one hour. We recommend zone administrators to chose TTLs
- longer than half a minute.
- [Editor's Note: this observation could be implementation
- specific. We are not sure if we should leave this item]
- o Slave servers will need to be able to fetch newly signed zones
- well before the data expires from your zone.
- 'Better no answers than bad answers.'
- If a properly implemented slave server is not able to contact a
- master server for an extended period the data will at some
- point expire and the slave server will not hand out any data.
- 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 signaturs, is
- that non-secure resolvers will continue to be able to resolve
- data served by the particular slave servers. Security aware
- resolvers will experience problems.
- 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 suggest that operators of nameservers with slave zones
- develop 'watch dogs' to spot upcoming signature expirations in
- slave zones, 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 and load a valid zone? All these arguments are
- not DNSSEC specific.
-
-3. Keys
-
- In the DNSSEC protocol there is only one type of key, the zone key.
- With this key, the data in a zone is signed.
-
- To make zone re-signing and key rollovers 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 RRs 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 parents
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 6]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- and potentially for configuration as trusted anchors - the so called
- Secure Entry Point keys (SEP). In this document we assume a
- one-to-one mapping between KSK and SEP keys and we assume the SEP
- flag [4] to be set on KSKs.
-
-3.1 Motivations for the KSK and ZSK Functions
-
- Differentiating between the KSK to ZSK functions has several
- advantages:
-
- o Making the KSK stronger (i.e. using more bits in the key material)
- has little operational impact since it is only used to sign a
- small fraction of the zone data.
- o As the KSK is only used to sign a keyset, which is most probably
- updated less frequently than other data in the zone, it can be
- stored separately from (and thus in a safer location than) the
- ZSK.
- o A KSK can be used for longer periods.
- o No parent/child interaction is required when ZSKs are updated.
-
- The KSK is used less than ZSK, once a keyset is signed with the KSK
- all the keys in the keyset can be used as ZSK. If a ZSK is
- compromised, it can be simply dropped from the keyset. The new keyset
- 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 e.g. a value of 256 and a key signing key has 257.
-
- 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 relatively
- short "Signature Validity Periods". That is, Signature Validity
- Periods of the order of days.
-
- The key-signing key is only to be used to sign the Key RR set from
- the zone apex. If a key-signing key is to be rolled over, there will
- be interactions with parties other than the zone administrator such
- as the registry of the parent zone or administrators of verifying
- resolvers that have the particular key configured as trusted entry
- points. Hence, the "Key Usage Time" 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 to plan for a "Key
- Usage Time" of the order of a few months so that a key rollover
- remains an operational routine.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 7]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-3.2 Key Security Considerations
-
- Keys in DNSSEC have a number of parameters which should all be chosen
- with care, the most important once are: size, algorithm and the key
- validity period (its lifetime).
-
-3.2.1 Key Validity Period
-
- RFC2541 [2] describes a number of considerations with respect to the
- security of keys. The document deals with the generation, lifetime,
- size and storage of private keys.
-
- In Section 3 of RFC2541 [2] there are some suggestions for a key
- validity period: 13 months for long-lived keys and 36 days for
- transaction keys but suggestions for key sizes are not made.
-
- If we say long-lived keys are key-signing keys and transactions keys
- are zone-signing keys, 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
- replaced.
-
-3.2.2 Key Algorithm
-
- We recommend you choose RSA/SHA-1 as the preferred algorithm for the
- key. RSA has been developed in an open and transparent manner. As the
- patent on RSA expired in 2001, its use is now also free. 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.
-
-3.2.3 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 [9] 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 cryptosystems. For
- details we refer to the original paper.
-
- [Editor's Note: DSA???]
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 8]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- Year RSA Key Sizes Elliptic Curve Key Size
- 2000 952 132
- 2001 990 135
- 2002 1028 139
- 2003 1068 140
- 2004 1108 143
-
- 2005 1149 147
- 2006 1191 148
- 2007 1235 152
- 2008 1279 155
- 2009 1323 157
-
-
- 2010 1369 160
- 2011 1416 163
- 2012 1464 165
- 2013 1513 168
- 2014 1562 172
-
- 2015 1613 173
- 2016 1664 177
- 2017 1717 180
- 2018 1771 181
- 2019 1825 185
-
-
- 2020 1881 188
- 2021 1937 190
- 2022 1995 193
- 2023 2054 197
- 2024 2113 198
-
- 2025 2174 202
- 2026 2236 205
- 2027 2299 207
- 2028 2362 210
- 2029 2427 213
-
- For example, should you wish your key to last three years from 2003,
- check the RSA keysize values for 2006 in this table. In this case
- 1191.
-
-3.3 Key Rollovers
-
- Key rollovers are a fact of life when using DNSSEC. A DNSSEC key
- cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone
- administrators who are in the process of rolling their keys have to
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 9]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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.
-
- To appreciate the situation one could think of a number of
- authoritative servers that may not be instantaneously running the
- same version of a zone and a security aware non-recursive resolver
- that sits behind security aware caching forwarders.
-
- Note that KSK rollovers and ZSK rollovers are different. A zone-key
- rollover can be handled in two different ways: pre-publish (Section
- Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The
- pre-publish technique works because the key-signing key stays the
- same during this ZSK rollover. With this KSK a cache is able to
- validate the new keyset of a zone. With a KSK rollover a cache can
- not validate the new keyset, because it does not trust the new KSK.
-
- [Editors note: This needs more verbose explanation, nobody will
- appreciate the situation just yet. Help with text and examples is
- appreciated]
-
-3.3.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
- keysets or newly generated signatures can be verified with the keys
- still in caches. One schema uses double signatures, it is described
- in Section 3.3.1.2, the other uses key pre-publication (Section
- 3.3.1.1). The pros, cons and recommendations are described in Section
- 3.3.1.3.
-
-3.3.1.1 Pre-publish Keyset 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 "prepublish
- rollover". We recommend this method because it has advantages in the
- case of 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
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 10]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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 keyset. 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
- keyset. This equates to two times the Maximum Zone TTL.
- roll: At the rollover stage (SOA serial 1) 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 keyset. 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 keyset 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 keyset, now only
- containing 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 August 30, 2004 [Page 11]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- normal roll after 2nd roll 2nd after
-
- SOA0 SOA2 SOA3 SOA4 SOA5
- RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5)
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12
- DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13
- RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(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.
-
- This scheme has the benefit that the key that is intended for future
- use: immediately during an emergency rollover assuming that the
- private key was stored in a physically secure manner.
-
-3.3.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, this will take at least the
- maximum Zone TTL .
-
- 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.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 12]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
- into the keyset 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 keyset, now only
- containing DNSKEY 11, is resigned with DNSKEY 1.
-
- At every instance the data from the previous version of the zone can
- be verified with the key from the current version and vice verse. 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.
- 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.
-
-3.3.1.3 Pros and Cons of the Schemes
-
- Prepublish-keyset rollover: This rollover does not involve signing
- the zone data twice. Instead, just before the actual rollover, the
- new key is published in the keyset and thus available for
- cryptanalysis attacks. A small disavantage is that this process
- requires four steps. Also the prepublish scheme will not work for
- KSKs as explained in Section 3.3.
- 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.
-
-3.3.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 keyset) in
- caches can be verified with a new keyset and vice versa.
-
- Since only the keyset is signed with a KSK, zone size considerations
- do not apply.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 13]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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 parents zone, the zone administrator
- has to wait at least TTL_DS to make sure that the old DS RR has
- expired from distant caches.
- 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. St John [The
- draft has expired] proposed a mechanism where using an established
- trust relation, the interaction can be performed in-band. In this
- mechanism there are periods where there are two DS RRs at the parent.
-
- [Editors note: We probably need to mention more]
-
-4. 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.
-
- [Editors note: We are much in favor of a rollover tactic that keeps
- the authentication chain intact as long as possible. This means that
- one has to take all the regular rollover properties into account.]
-
- 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:
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 14]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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 the hardest to update.)
- While an authentication chain to your compromised key exists, your
- name-space is vulnerable to abuse by the malicious key holder (i.e.
- the owner of the compromised key). Zone operators have to make a
- 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 will usually be localised in the
- Internet topology.
-
-
-4.1 KSK Compromise
-
- When the KSK has been compromised the parent must be notified as soon
- as possible using secure means. The keyset 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 been updated with 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 out of band and secure notify mechanism to contact a
- parent is needed in this case.
-
-4.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 minimises such problems.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 15]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-4.3 Compromises of Keys Anchored in Resolvers
-
- A key can also be pre-configured in resolvers. If DNSSEC is rolled
- out as planned the root key should be pre-configured in every secure
- aware resolver on the planet. [Editors Note: add more about
- authentication of a newly received resolver key]
-
- If trust-anchor keys are compromised, the resolvers using these keys
- 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.
-
-5. Parental Policies
-
-5.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 authorisation
- mechanisms used during a key exchange should be as strong as the
- authentication and authorisation mechanisms used for the exchange of
- delegation information between parent and child.
-
- 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 [4] to select the proper key from a
- DNSSEC keyset; 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 child will not become bogus 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 by a tool. The parent can not be sure whether the DNSKEY
- RRs have been spoofed.
-
-5.2 Storing Keys So Hashes Can Be Regenerated
-
- When designing a registry system one should consider if the DNSKEYs
- and/or the corresponding DSs are stored. Storing DNSKEYs will help
- during troubleshooting while the overhead of calculating 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 may also help with troubleshooting.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 16]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-5.3 Security Lameness Checks
-
- Security Lameness is defined as what happens when a parent has a DS
- Resource Record 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 would render 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. by removing a DS RR) will
- take time to propagate through the DNS.
-
-5.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 minimises 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
- lifetimes longer than 2 days. We recommend the minimum for a DS
- signature validity period to be a few days.
-
- The maximum signature lifetime of the DS record depends on how long
- child zones are willing to be vulnerable after a key compromise. We
- consider a signature validity period of around one week to be a good
- compromise between the operational constraints of the parent and
- minimising damage for the child.
-
-6. Security Considerations
-
- DNSSEC adds data integrity to the DNS. This document tries to assess
- considerations to operate 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.
-
-7. Acknowledgments
-
- We, the folk mentioned as authors, only acted as editors. 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 where the original
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 17]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- contributors of the ideas we would like to acknowledge people who
- where actively involved in the compilation of this document. In
- random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,
- Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier
- Courtay, Sam Weiler.
-
- Emma Bretherick and Adrian Bedford corrected many of the spelling and
- style issues.
-
- Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
-8. References
-
-8.1 Normative References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Eastlake, D., "DNS Security Operational Considerations", RFC
- 2541, March 1999.
-
- [3] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
- (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
- in progress), February 2003.
-
-8.2 Informative References
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
- 2308, March 1998.
-
- [7] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-13 (work in progress), March
- 2003.
-
- [8] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in
- progress), March 2003.
-
- [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",
- The Journal of Cryptology 14 (255-293), 2001.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 18]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-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.
-
- 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 i.e. should not be
- exposed to parties not-authorised to do the actual signing.
- 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.
- KSK: A Key-Signing Key (KSK) is a key that is used exclusively for
- signing the apex keyset. The fact that a key is a KSK is only
- relevant to the signing tool.
- 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.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 19]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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.
- Anchored Key: A DNSKEY configured in resolvers around the globe. This
- Key is hard to update, hence the term anchored.
- Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked
- "Bogus" when a signature of a RRset does not validate against the
- DNSKEY. Even if the key itself was not marked Bogus. A cache may
- choose to cache Bogus data for various reasons.
- Singing the Zone File: The term used for the event where an
- administrator joyfully signs its zone file while producing melodic
- sound patterns.
- 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 distant caches
- here follows the "HOWTO". [WES: has some comments about this]
- Key notation:
- Step 0: The preparation: Create two keys and publish both in your
- keyset. 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.
- 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.
- 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.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 20]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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 :
-
-
- example.net. 600 IN SOA ns.example.net. ernie.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 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC
- 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.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 21]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- bZMjoZ3bHjnEz0nIsPMM... )
-
- ...
-
-
- is reduced to the following represenation:
-
- 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.
-
- $Header: /var/cvs/dnssec-key/
- draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12
- 08:29:11 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
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 22]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 23]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 24]
-
-
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
deleted file mode 100644
index a5d0d6079a707..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt
+++ /dev/null
@@ -1,1736 +0,0 @@
-
-
-
-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
deleted file mode 100644
index bcd0d14e4b54f..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
+++ /dev/null
@@ -1,396 +0,0 @@
-
-
-
-
-
-
-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-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
deleted file mode 100644
index 42c3c0b7c7e39..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
+++ /dev/null
@@ -1,1321 +0,0 @@
-
-DNS Operations WG
-Internet-Draft J. Jeong (ed.)
- ETRI
-
-Expires: January 2005 18 July 2004
-
-
- IPv6 Host Configuration of DNS Server Information Approaches
- draft-ietf-dnsop-ipv6-dns-configuration-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 we become aware will be disclosed, in accordance
- with RFC3668.
-
- 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, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-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 four deployment scenarios considering multi-solution
- resolution. Therefore, this document will give the audience a
-
-
-
-Jeong, et al. Expires - January 2005 [Page 1]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- guideline of IPv6 DNS configuration to select approaches suitable
- for their host DNS configuration.
-
-Table of Contents
-
- 1. Introduction...................................................3
- 2. Terminology....................................................3
- 3. IPv6 DNS Configuration Approaches..............................3
- 3.1 RA Option..................................................3
- 3.1.1 Advantages...........................................4
- 3.1.2 Disadvantages........................................5
- 3.1.3 Observations.........................................5
- 3.2 DHCPv6 Option..............................................6
- 3.2.1 Advantages...........................................7
- 3.2.2 Disadvantages........................................8
- 3.2.3 Observations.........................................9
- 3.3 Well-known Anycast Addresses...............................9
- 3.3.1 Advantages...........................................9
- 3.3.2 Disadvantages.......................................10
- 3.3.3 Observations........................................10
- 4. Interworking among IPv6 DNS Configuration Approaches..........11
- 5. Deployment Scenarios..........................................12
- 5.1 ISP Network...............................................12
- 5.1.1 RA Option Approach..................................12
- 5.1.2 DHCPv6 Option Approach..............................13
- 5.1.3 Well-known Addresses Approach.......................13
- 5.2 Enterprise Network........................................14
- 5.3 3GPP Network..............................................14
- 5.3.1 Currently Available Mechanisms and Recommendations..15
- 5.3.2 RA Extension........................................16
- 5.3.3 Stateless DHCPv6....................................16
- 5.3.4 Well-known Addresses................................17
- 5.3.5 Recommendations.....................................17
- 5.4 Unmanaged Network.........................................18
- 5.4.1 Case A: Gateway does not provide IPv6 at all........18
- 5.4.2 Case B: A dual-stack gateway connected to a dual-stack
- ISP.........................................18
- 5.4.3 Case C: A dual-stack gateway connected to an IPv4-only
- ISP.........................................19
- 5.4.4 Case D: A gateway connected to an IPv6-only ISP.....19
- 6. Security Considerations.......................................19
- 7. Acknowledgements..............................................19
- 8. Normative References..........................................20
- 9. Informative References........................................20
- 10. Authors' Addresses...........................................21
- Intellectual Property Statement..................................23
- Full Copyright Statement.........................................23
- Acknowledgement..................................................24
-
-
-Jeong, et al. Expires - January 2005 [Page 2]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
-
-1. Introduction
-
- Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
- Autoconfiguration provide ways to configure either fixed or mobile
- nodes with one or more IPv6 addresses, default routes and some
- other parameters [3][4]. To support 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 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 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 approaches suitable for IPv6 host configuration of recursive
- DNS server.
-
-2. Terminology
-
- This document uses the terminology described in [3]-[9]. In
- addition, a new term is defined below:
-
- Recursive DNS Server (RDNSS) A Recursive DNS Server is a name
- server that offers the recursive
- service of DNS name resolution.
-
-3. IPv6 DNS Configuration Approaches
-
- In this section, the operational attributes of three solutions are
- described in detail.
-
-3.1 RA Option
-
- RA approach is to define a new ND option called 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,
- etc. An IPv6 host can configure the IPv6 addresses of one or more
-
-
-Jeong, et al. Expires - January 2005 [Page 3]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- RDNSSes via RA message periodically sent by 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 address can be
- performed manually by operator or other ways, such as automatic
- configuration through DHCPv6 client running on the router. When
- advertising more than one RDNSS options, an RA message includes as
- many RDNSS options as RDNSSes. Through ND protocol and RDNSS
- option along with 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, RA approach performs
- poorly in some wireless environments where RA message is used for
- IPv6 address autoconfiguration, such as WLAN networks.
-
- The RA approach is useful in some non-WLAN mobile environments
- where the addresses of the RDNSSes are changing because the RA
- option includes a lifetime field. 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, lifetime would seem to make matters a bit more
- complex. Instead of just writing 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 RDNSS option, allows
- IPv6 hosts to select primary RDNSS among several RDNSSes; this can
- be used for load balancing of RDNSSes [8].
-
-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 multi-
- point (i.e., Ethernet LANs), etc. RFC2461 [3] states, however,
- that there may be some link type on which ND is not possible; on
- such a link, some other mechanism will be needed for DNS
- configuration.
-
- 3) All of the information a host needs to run basic Internet
- applications such as email, the web, ftp, etc., can be performed
-
-
-Jeong, et al. Expires - January 2005 [Page 4]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- with the addition of this option to ND and address auto-
- configuration. 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). 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, 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 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 that are common to all clients on a subnet would be easy
- to define. This includes things like NTP servers, SIP servers, etc.
-
-3.1.2 Disadvantages
-
- 1) ND is mostly implemented in kernel part of operating system.
- Therefore, if ND supports the configuration of some additional
- services, such as DNS, NTP and SIP servers, ND should be extended
- in kernel part. DHCPv6, however, has more flexibility for
- extension of service discovery because it is an application layer
- protocol.
-
- 2) The current ND framework should be modified due to the
- synchronization between another ND cache for RDNSSes in kernel
- space and DNS configuration file in user space. Because it is
- unacceptable to write and rewrite 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 necessary 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
- by RA option.
-
-3.1.3 Observations
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 5]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- The proposed RDNSS RA option along with IPv6 ND and Auto-
- configuration allows a host to obtain all of the information it
- needs to access basic Internet services like the web, email, ftp,
- etc. This is preferable in environments where hosts use RAs to
- autoconfigure their addresses and all 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. Environments like this include 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]. Environments like this are most likely
- 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
- 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
-
-
-Jeong, et al. Expires - January 2005 [Page 6]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- 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 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.
-
- 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.
-
-
-
-Jeong, et al. Expires - January 2005 [Page 7]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- 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 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.
-
-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 message, 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.
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 8]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
-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
-
- First of all, the well-known anycast addresses approach is much
- different from that discussed in IPv6 Working Group in the past.
-
- The approach with well-known anycast addresses is to set 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). 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.
-
- It should be noted that "anycast" in this memo is simpler than that
- of RFC1546 [11] and RFC3513 [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, 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 to have multiple RDNSSes sharing an anycast
- address on a single link.
-
-3.3.1 Advantages
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 9]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- The basic advantage of the well-known addresses approach is that it
- uses no transport mechanism. Thus,
- 1) There is no delay to get response and no further delay by packet
- losses.
-
- 2) The approach can be combined with any other configuration
- mechanisms including but not limited to factory default
- configuration, RA-based approach and DHCP based approach.
-
- 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 access 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 configuration effort of users.
-
- Redundancy by multiple RDNSSes is better provided by multiple
- servers having different anycast addresses than multiple servers
- sharing 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 boundary between RDNSSes may be fixed (redundancy is still
- provided by multiple addresses) or change dynamically. DNS packets
-
-
-Jeong, et al. Expires - January 2005 [Page 10]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- 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 RFC1546 [11]
- and RFC3513 [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 RFC2461 [3] and RFC3513 [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 RFC3513 [12]) address of packets of
- UDP and TCP responses. With TCP, if 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.
-
-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, O (Other stateful
- configuration) flag in RA message can be used [8]. 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
- configuration effort on servers by using the well-known addresses
- as the default configuration. Moreover, clients preconfigured with
- well-known anycast addresses can be further configured to use other
- approaches to override the well-known addresses, if configuration
- information from other approaches are available. That is, all the
- clients should have the well-known anycast addresses preconfigured,
- in the case where there are no other mechanisms available. In
- order to fly anycast approach with the other solutions, there are
- three options.
-
- The first option is that well-known addresses are used as last
- resort, when an IPv6 host can not get RDNSS information through RA
- and DHCP. The well-known anycast addresses have to be pre-
- configured in IPv6 hosts' resolver configuration files.
-
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 11]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- The second is that an IPv6 host can configure well-known addresses
- as the most preferable in its configuration file even though either
- RA option or DHCP option is available.
-
- The last is that the well-known anycast addresses can be set in RA
- or DHCP configuration to reduce configuration effort of users.
- According to either RA or DHCP mechanism, the well-known addresses
- can be obtained by 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.
-
-5. Deployment Scenarios
-
- Regarding DNS configuration on the IPv6 host, several mechanisms
- have 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 of 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
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 12]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- 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 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 message.
-
-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]. DHCPv6 DNS option
- is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6-
- lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6
- implementation. DHCP is a client-server model protocol, so ISP 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 Addresses Approach
-
- Well-known anycast addresses approach is also a feasible and simple
- mechanism for ISP [9]. The use of well-known anycast addresses
-
-
-Jeong, et al. Expires - January 2005 [Page 13]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- 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 enterprise network can get network prefixes from 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 of IPv6 hosts as RDNSS. RDNSS configuration in enterprise
- network can be performed like in Section 4, in which three
- approaches can be used together.
-
- IPv6 host can decide which approach is or may be used in its subnet
- with O flag in RA message [8]. As the first option in Section 4,
- well-known anycast addresses can be used as a last resort when
- RDNSS information can not be obtained through either RA option or
- DHCP option. This case needs IPv6 hosts to preconfigure the well-
- known anycast addresses in their DNS configuration files.
-
- When the enterprise prefers well-known anycast approach to the
- others, IPv6 hosts should preconfigure the well-known anycast
- addresses like in the first option.
-
- The last option, 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 through either 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
-
- 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). 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].
-
-
-
-Jeong, et al. Expires - January 2005 [Page 14]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- In 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 can not be assumed that (s)he has simultaneously
- 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.
-
- 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., Wireless LAN (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 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,
-
-
-Jeong, et al. Expires - January 2005 [Page 15]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- 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 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 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 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.
-
-
-
-Jeong, et al. Expires - January 2005 [Page 16]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- 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 an existing
- router already, and it is 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.
-
- 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
- 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.
-
- a) 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: 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
-
-
-
-Jeong, et al. Expires - January 2005 [Page 17]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- It is suggested that a lightweight, stateless DNS configuration
- mechanism is specified as soon as possible. From 3GPP UE's and
- networks' point of view, 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.
-
-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, can not 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).
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 18]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
-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.
-
-5.4.4 Case D: A gateway connected to an IPv6-only ISP
-
- This is similar to Case B.
-
-6. Security Considerations
-
- As security requirements depend solely on applications and are
- different application by application, there can be no generic
- requirement defined at higher IP or lower application layer of 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 scenario [19], where cryptographic security is
- required for applications, 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 auto-
- configuration 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 local environment is secure enough that
- information from local autoconfiguration server has acceptable
- security even without cryptographic security. Thus, communication
- between a local DNS client and a local DNS server has the
- acceptable security.
-
- For security considerations of each approach, refer to the
- corresponding drafts [5]-[9].
-
-7. Acknowledgements
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 19]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- This draft has greatly benefited from inputs by David Meyer, Rob
- Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
- Christian Huitema, and Thomas Narten. The authors appreciate their
- contribution.
-
-8. Normative References
-
- [1] S. Bradner, "Intellectual Property Rights in IETF Technology",
- RFC 3668, February 2004.
-
- [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February
- 2004.
-
- [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for
- IP Version 6 (IPv6)", RFC 2461, December 1998.
-
- [4] S. Thomson and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC 2462, December 1998.
-
- [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [6] R. Droms, "Stateless Dynamic Host Configuration Protocol
- (DHCP) Service for IPv6", RFC 3736, April 2004.
-
- [7] R. Droms et al., "DNS Configuration options for Dynamic Host
- Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
- 2003.
-
-9. Informative References
-
- [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS
- Discovery based on Router Advertisement", draft-jeong-dnsop-
- ipv6-dns-discovery-02.txt, July 2004.
-
- [9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta-
- preconfigured-dns-01.txt, February 2004.
-
- [10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft-
- ietf-dhc-lifetime-00.txt, March 2004.
-
- [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting
- Service", RFC 1546, November 1993.
-
- [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
- Addressing Architecture", RFC 3513, April 2003.
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 20]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
- into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-
- 02.txt, April 2004.
-
- [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-
- ietf-send-ndopt-05.txt, April 2004.
-
- [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages",
- RFC 3118, June 2001.
-
- [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft-
- ietf-v6ops-ent-scenarios-01.txt, February 2004.
-
- [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host
- Configuration Protocol (DHCP) version 6", RFC 3633, December
- 2003.
-
- [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP
- Standards", RFC 3314, September 2002.
-
- [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks",
- RFC 3574, August 2003.
-
- [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP
- Networks", draft-ietf-v6ops-3gpp-analysis-09.txt, March 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] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering
- Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless-
- dhcpv6-renumbering-00.txt, March 2004.
-
- [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition
- Scenarios", RFC 3750, April 2004.
-
-10. Authors' Addresses
-
- Jaehoon Paul Jeong, Editor
- ETRI / PEC
- 161 Gajeong-dong, Yuseong-gu
- Daejeon 305-350
- Korea
-
-
-
-Jeong, et al. Expires - January 2005 [Page 21]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- Phone: +82 42 860 1664
- Fax: +82 42 861 5404
- EMail: paul@etri.re.kr
-
- Ralph Droms
- Cisco Systems
- 1414 Massachusetts Ave.
- Boxboro, MA 01719
- USA
-
- Phone: +1 978 936 1674
- EMail: rdroms@cisco.com
-
- Robert M. Hinden
- Nokia
- 313 Fairchild Drive
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 625 2004
- EMail: bob.hinden@nokia.com
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter Street
- Redwood City, CA 94043
- USA
-
- EMail: Ted.Lemon@nominum.com
-
- Masataka Ohta
- Graduate School of Information Science and Engineering
- 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, Paldal-gu, Suwon
- Gyeonggi-Do
- Korea
-
- Phone: +82 31 200 4508
-
-
-Jeong, et al. Expires - January 2005 [Page 22]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- EMail: soohong.park@samsung.com
-
- Suresh Satapati
- Cisco Systems, Inc.
- San Jose, CA 95134
- USA
-
- EMail: satapati@cisco.com
-
- Juha Wiljakka
- Nokia
- Visiokatu 3
- FIN-33720 TAMPERE
- Finland
-
- Phone: +358 7180 48372
- EMail: juha.wiljakka@nokia.com
-
-Intellectual Property Statement
-
- The following intellectual property notice is copied from RFC3668,
- Section 5.
-
- 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.
-
-Full Copyright Statement
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 23]
-
-Internet-Draft IPv6 Host Configuration of DNS Server July 2004
-
-
- The following copyright notice is copied from RFC3667, Section 5.4.
- It describes the applicable copyright for this document.
-
- 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong, et al. Expires - January 2005 [Page 24]
-
-
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
deleted file mode 100644
index bf2afcdfb3ac6..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+++ /dev/null
@@ -1,1848 +0,0 @@
-
-
-
-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-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
deleted file mode 100644
index b14f711d5314a..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
+++ /dev/null
@@ -1,1969 +0,0 @@
-
-
-DNS Operations WG A. Durand
-Internet-Draft SUN Microsystems, Inc.
-Expires: February 7, 2005 J. Ihren
- Autonomica
- P. Savola
- CSC/FUNET
- August 9, 2004
-
-
-
- Operational Considerations and Issues with IPv6 DNS
- draft-ietf-dnsop-ipv6-dns-issues-09.txt
-
-
-Status of this Memo
-
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
- This Internet-Draft will expire on February 7, 2005.
-
-
-Copyright Notice
-
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-
-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
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 1]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- service provisioning and for DNS resolver IPv6 support,
- 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 . . . . . . 8
- 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 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
- 4.4.1 Description of Additional Data Scenarios . . . . . . . 10
- 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11
- 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12
- 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13
- 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13
- 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14
- 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15
- 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16
- 6. Considerations about Forward DNS Updating . . . . . . . . . . 16
- 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
- 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17
- 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18
- 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18
- 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19
- 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19
- 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20
- 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21
- 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22
- 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22
- 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
- 10. Security Considerations . . . . . . . . . . . . . . . . . . 22
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 2]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
- 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
- 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
- A. Site-local Addressing Considerations for DNS . . . . . . . . . 28
- B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28
- Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 3]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
-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 site-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 February 7, 2005 [Page 4]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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
- [I-D.ietf-dnsop-ipv6-transport-guidelines] 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 February 7, 2005 [Page 5]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
-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
- [I-D.ietf-ipv6-deprecate-site-local], and are only discussed 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.ietf-dnsop-dontpublish-unreachable].
-
-
-2.2 Temporary Addresses
-
-
- Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
- "privacy addresses") use a random number as the interface identifier.
- Publishing (useful) DNS records relating to such addresses 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
- [I-D.moore-6to4-dns], some more applicable than the others.
-
-
- 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, above, 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. This is why only
- 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.
-
-
- Note that it does not seem feasible to provide reverse DNS with
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 6]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- another automatic tunneling mechanism, 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 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
- [I-D.ietf-dnsop-misbehavior-against-aaaa]: 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.
-
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 7]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
-4. Recommendations for Service Provisioning using DNS
-
-
- When names are added in the DNS to facilitate a service, there are
- 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
-
-
- When a node provides multiple services which should not be
- fate-sharing, or might support different IP versions, one should keep
- them logically separate in the DNS. 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 should 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.)
-
-
- This is a good practice with IPv4 as well, because it provides more
- flexibility and enables easier migration of services from one host to
- another. A specific reason why this is relevant for IPv6 is that the
- different services may have a different level of IPv6 support -- that
- is, one node providing multiple services might want to enable just
- one service to be IPv6-visible while keeping some others as
- IPv4-only, improving flexibility.
-
-
-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 be either added to "service.example.com", or added
- separately under a different name, e.g., in a sub-domain, like,
- "service.ipv6.example.com".
-
-
- These two methods have different characteristics. Using a different
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 8]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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
- if the service offered using both protocols is of roughly equal
- quality, using the appropriate metrics for the service (e.g.,
- latency, throughput, low packet loss, general reliability, etc.) --
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 9]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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
- [I-D.savola-v6ops-6bone-mess].
-
-
-4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
-
-
-4.4.1 Description of Additional Data Scenarios
-
-
- Consider the case where the query name is so long, the number of the
- additional records is so high, or for other reasons that the entire
- response would not fit in a single UDP packet. In some cases, the
- responder truncates the response with the TC bit being set (leading
- to a retry with TCP), in order for the querier to get the entire
- response later.
-
-
- There are two kinds of additional data:
-
-
- 1. glue, i.e., "critical" additional data; this must be included in
- all scenarios, with all the RRsets as possible, 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. This data must
- never cause setting of the TC bit.
-
-
- The responding server can algorithmically determine which type the
- additional data is by checking whether it's at or below a zone cut.
-
-
- Meanwhile, 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.
-
-
- An example of the "courtesy" additional data is A/AAAA records in
- conjunction of MX records as shown in Section 4.5; an example of the
- "critical" additional data is shown below (where getting both the A
- and AAAA RRsets is critical):
-
-
- 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, some or all of it
- need to be removed [RFC2181]; if some is left in the response, the
- issue is which data should be retained. When there is too much
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 10]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- critical additional data, TC bit will have to be set, and some or all
- of it need to be removed; if some is left in the response, the issue
- is which data should be retained.
-
-
- If the implementation decides to keep as much data as possible, 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.
-
-
- 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.
-
-
-4.4.2 Discussion of the Problems
-
-
- As noted above, the temptation for omitting only some of the
- additional data based on the transport of the query could be
- problematic. In particular, there appears to be little justification
- for doing so in the case of "courtesy" data.
-
-
- However, with critical additional data, the alternatives are either
- returning nothing (and requiring a retry with TCP) or returning
- something (possibly obviating the need for a retry with TCP). 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.
-
-
- 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 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.
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 11]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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, 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.
-
-
-4.5 The Use of TTL for IPv4 and IPv6 RRs
-
-
- In the previous section, we discussed a danger with queries,
- potentially leading to omitting RRsets from the additional section;
- this could happen to both critical and "courtesy" additional data.
- This section discusses another problem with the latter, leading to
- omitting RRsets in cached data, highlighted in the IPv4/IPv6
- environment.
-
-
- The behaviour of DNS caching when different TTL values are used for
- different RRsets of the same name requires explicit discussion. For
- example, let's consider a part of a zone:
-
-
- 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
-
-
- 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. So, there are
- three cases about returning records for the MX in the additional
- section:
-
-
- 1. We get back no A or AAAA RRsets: this is the simplest case,
- because then we have to query which information is required
- explicitly, guaranteeing that we get all the information we're
- interested in.
-
-
- 2. We get back all the RRsets: this is an optimization as there is
- no need to perform more queries, causing lower latency. However,
- it is impossible to guarantee that in fact we would always get
- back all the records (the only way to ensure that is to send a
- AAAA query for the name after getting the cached reply with A
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 12]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- records or vice versa).
-
-
- 3. We only get back A or AAAA RRsets even if both existed: this is
- indistinguishable from the previous case, and may have problems
- at least in certain environments as described in the previous
- section.
-
-
- As the third case was considered in the previous section, we assume
- we get back both A and AAAA records of foo.example.com, or the stub
- resolver explicitly asks, in two separate queries, both A and AAAA
- records.
-
-
- 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. The behaviour in
- this scenario is unspecified.
-
-
- To simplify the situation, it might help to use the same TTL for all
- the resource record sets referring to the same name, unless there is
- a particular reason for not doing so. However, there are some
- scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
- a different strategy is preferable.
-
-
- Thus, applications that use the response should not rely on a
- particular TTL configuration. For example, even if an application
- gets a response that only has the A record in the example described
- above, it should be still aware that there could be a AAAA record for
- "foo.example.com". That is, the application should try to fetch the
- missing records itself if it needs the record.
-
-
-4.6 IPv6 Transport Guidelines for DNS Servers
-
-
- As described in Section 1.3 and
- [I-D.ietf-dnsop-ipv6-transport-guidelines], 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.
-
-
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 13]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
-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
- 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
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 14]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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 [I-D.ietf-v6ops-application-transition].
-
-
- 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
- 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
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 15]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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
- [I-D.ietf-dnsop-ipv6-transport-guidelines], 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 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
- 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.
-
-
-
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 16]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
-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
- 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
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 17]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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
- 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 to the reverse DNS, as justified and described in
- [I-D.ietf-ipseckey-rr].
-
-
- 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
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 18]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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, 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. (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 unfeasible.
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 19]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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
- [I-D.ietf-send-cga] (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.
-
-
-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
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 20]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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
- 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.
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 21]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
-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.durand-v6ops-natpt-dns-alg-issues].
- 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
- 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
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 22]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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 which 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-02 (work in
- progress), July 2004.
-
-
- [I-D.ietf-dnsop-ipv6-transport-guidelines]
- Durand, A. and J. Ihren, "DNS IPv6 transport operational
- guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02
- (work in progress), March 2004.
-
-
- [I-D.ietf-dnsop-misbehavior-against-aaaa]
- Morishita, Y. and T. Jinmei, "Common Misbehavior against
- DNS Queries for IPv6 Addresses",
- draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
- progress), April 2004.
-
-
- [I-D.ietf-ipv6-deprecate-site-local]
- Huitema, C. and B. Carpenter, "Deprecating Site Local
- Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work
- in progress), March 2004.
-
-
- [I-D.ietf-v6ops-application-transition]
- Shin, M., "Application Aspects of IPv6 Transition",
- draft-ietf-v6ops-application-transition-03 (work in
- progress), June 2004.
-
-
- [I-D.ietf-v6ops-renumbering-procedure]
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 23]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- Baker, F., Lear, E. and R. Droms, "Procedures for
- Renumbering an IPv6 Network without a Flag Day",
- draft-ietf-v6ops-renumbering-procedure-01 (work in
- progress), July 2004.
-
-
- [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.
-
-
- [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)
- 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.
-
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 24]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- [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.
-
-
-11.2 Informative References
-
-
- [I-D.durand-v6ops-natpt-dns-alg-issues]
- Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
- draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
- progress), February 2003.
-
-
- [I-D.huitema-v6ops-teredo]
- Huitema, C., "Teredo: Tunneling IPv6 over UDP through
- NATs", draft-huitema-v6ops-teredo-02 (work in progress),
- June 2004.
-
-
- [I-D.huston-6to4-reverse-dns]
- Huston, G., "6to4 Reverse DNS",
- draft-huston-6to4-reverse-dns-02 (work in progress), April
- 2004.
-
-
- [I-D.ietf-dhc-ddns-resolution]
- Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
- Clients", draft-ietf-dhc-ddns-resolution-07 (work in
- progress), July 2004.
-
-
- [I-D.ietf-dhc-fqdn-option]
- Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
- draft-ietf-dhc-fqdn-option-07 (work in progress), July
- 2004.
-
-
- [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-08 (work in progress), July
- 2004.
-
-
- [I-D.ietf-dnsop-bad-dns-res]
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 25]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- Larson, M. and P. Barber, "Observed DNS Resolution
- Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
- progress), July 2004.
-
-
- [I-D.ietf-dnsop-dontpublish-unreachable]
- Hazel, P., "IP Addresses that should never appear in the
- public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
- (work in progress), February 2002.
-
-
- [I-D.ietf-dnsop-inaddr-required]
- Senie, D., "Requiring DNS IN-ADDR Mapping",
- draft-ietf-dnsop-inaddr-required-05 (work in progress),
- April 2004.
-
-
- [I-D.ietf-ipseckey-rr]
- Richardson, M., "A method for storing IPsec keying
- material in DNS", draft-ietf-ipseckey-rr-11 (work in
- progress), July 2004.
-
-
- [I-D.ietf-ipv6-unique-local-addr]
- Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
- Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
- progress), June 2004.
-
-
- [I-D.ietf-send-cga]
- Aura, T., "Cryptographically Generated Addresses (CGA)",
- draft-ietf-send-cga-06 (work in progress), April 2004.
-
-
- [I-D.ietf-v6ops-3gpp-analysis]
- Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
- Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
- progress), May 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-04
- (work in progress), July 2004.
-
-
- [I-D.ietf-v6ops-onlinkassumption]
- Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
- On-Link Assumption Considered Harmful",
- draft-ietf-v6ops-onlinkassumption-02 (work in progress),
- May 2004.
-
-
- [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.
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 26]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- [I-D.jeong-dnsop-ipv6-dns-discovery]
- Jeong, J., "IPv6 DNS Discovery based on Router
- Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02
- (work in progress), July 2004.
-
-
- [I-D.moore-6to4-dns]
- Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
- in progress), October 2002.
-
-
- [I-D.ohta-preconfigured-dns]
- Ohta, M., "Preconfigured DNS Server Addresses",
- draft-ohta-preconfigured-dns-01 (work in progress),
- February 2004.
-
-
- [I-D.savola-v6ops-6bone-mess]
- Savola, P., "Moving from 6bone to IPv6 Internet",
- draft-savola-v6ops-6bone-mess-01 (work in progress),
- November 2002.
-
-
- [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.
-
-
-
-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 February 7, 2005 [Page 27]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- 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. Site-local Addressing Considerations for DNS
-
-
- As site-local addressing has been deprecated, the considerations for
- site-local addressing are discussed briefly here. Unique local
- addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
- as a replacement, but being work-in-progress, it is not considered
- further.
-
-
- The interactions with DNS come in two flavors: forward and reverse
- DNS.
-
-
- To actually use site-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 site-local addresses must not be published in the public DNS.
-
-
- To faciliate reverse DNS (if desired) with site-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
- site-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.
-
-
-Appendix B. Issues about Additional Data or TTL
-
-
- [[ note to the RFC-editor: remove this section upon publication. ]]
-
-
- This appendix tries to describe the apparent rought consensus about
- additional data and TTL issues (sections 4.4 and 4.5), and present
- questions when there appears to be no consensus. The point of
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 28]
-Internet-Draft Considerations and Issues with IPv6 DNS August 2004
-
-
-
- recording them here is to focus the discussion and get feedback.
-
-
- Resolved:
-
-
- a. If some critical additional data RRsets wouldn't fit, you set the
- TC bit even if some RRsets did fit.
-
-
- b. If some courtesy additional data RRsets wouldn't fit, you never
- set the TC bit, but rather remove (at least some of) the courtesy
- RRsets.
-
-
- c. DNS servers should implement sanity checks on the resulting glue,
- e.g., to disable circular dependencies. Then the responding
- servers can use at-or-below-a-zone-cut criterion to determine
- whether the additional data is critical or not.
-
-
- Open issues (at least):
-
-
- 1. if some critical additional data RRsets would fit, but some
- wouldn't, and TC has to be set (see above), should one rather
- remove the additional data that did fit, keep it, or leave
- unspecified?
-
-
- 2. if some courtesy additional data RRsets would fit, but some
- wouldn't, and some will have to be removed from the response (no
- TC is set, see above), what to do -- remove all courtesy RRsets,
- keep all that fit, or leave unspecified?
-
-
- 3. is it acceptable to use the transport used in the DNS query as a
- hint which records to keep if not removing all the RRsets, if: a)
- having to decide which critical additional data to keep, or b)
- having to decide which courtesy additional data to keep?
-
-
- 4. (this issue was discussed in section 4.5) if one RRset has TTL of
- 100 seconds, and another the TTL of 300 seconds, what should the
- caching server do after 100 seconds? Keep returning just one
- RRset when returning additional data, or discard the other RRset
- from the cache?
-
-
- 5. how do we move forward from here? If we manage to get to some
- form of consensus, how do we record it: a) just in
- draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational
- category only!), b) a separate BCP or similar by DNSEXT WG(?),
- clarifying and giving recommendations, c) something else, what?
-
-
-
-
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 29]
-Internet-Draft Considerations and Issues with IPv6 DNS August 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.
-
-
-
-
-
-Durand, et al. Expires February 7, 2005 [Page 30] \ No newline at end of file
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
deleted file mode 100644
index 1276f9f91d62f..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
+++ /dev/null
@@ -1,1682 +0,0 @@
-
-
-
-
-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-ipv6-transport-guidelines-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
deleted file mode 100644
index b2e2341be9f16..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
+++ /dev/null
@@ -1,300 +0,0 @@
-Internet Engineering Task Force A.Durand
-INTERNET-DRAFT SUN Microsystems,inc.
-November, 24, 2003 J. Ihren
-Expires May 25, 2004 Autonomica
-
-
- DNS IPv6 transport operational guidelines
- <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
-
-
-
-Status of this Memo
-
- This memo provides information to the Internet community. It does not
- specify an Internet standard of any kind. This memo is in full
- conformance with all provisions of Section 10 of RFC2026
-
- 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
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-
-Abstract
-
- This memo provides guidelines and Best Current Practice to operate
- DNS in a world where queries and responses are carried in a mixed
- environment of IPv4 and IPv6 networks.
-
-
-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.
-
-
-1. Terminology
-
- The phrase "IPv4 name server" indicates a name server available over
- IPv4 transport. It does not imply anything about what DNS data is
- served. Likewise, "IPv6 name server" indicates a name server
- available over IPv6 transport. The phrase "dual-stack DNS server"
- indicates a DNS 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.
-
- 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 [2119].
-
-
-2. Introduction to the Problem of Name Space Fragmentation:
- following the referral chain
-
- The caching resolver that tries to look up a name starts out at the
- root, and follows referrals until it is referred to a nameserver that
- is authoritative for the name. If somewhere down the chain of
- referrals it is referred to a nameserver that is only accessible over
- an unavailable type of transport, a traditional nameserver 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
- nameservers for certain nodes are only accessible over a certain
- transport. What is feared is that a node using only a particular
- version of IP, 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
- through a "translator", i.e. they have to use a second 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 old legacy IPv4 name servers
- having to switch to a forwarding configuration.
-
- However, the second situation will not arise in a foreseeable time.
- Instead, it is expected that the transition will be from IPv4 only to
- a mixture of IPv4 and IPv6, with DNS data of theoretically three
- categories depending on whether it 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 as quickly as possible
- becomes the norm. 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. I.e. during transition it is not
- acceptable to break the name space that we presently have available
- for IPv4-only hosts.
-
-
-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.
-
- 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 DNS server SHOULD be either IPv4-only or dual
- stack,
- - every single DNS zone SHOULD be served by at least one IPv4
- reachable DNS server.
-
- This rules out IPv6-only DNS servers performing full recursion and
- DNS zones served only by IPv6-only DNS servers. However, one could
- very well design a configuration where a chain of IPv6 only DNS
- servers forward queries to a set of dual stack DNS servers actually
- performing those recursive queries. This approach could be revisited
- if/when translation techniques between IPv4 and IPv6 were to be
- widely deployed.
-
- In order to help enforcing the second point, the optional operational
- 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
-
- Being a critical piece of the Internet infrastructure, the DNS is a
- potential value target and thus should be protected. Great care
- should be taken not to weaken the security of DNS while introducing
- IPv6 operation.
-
- Keeping the DNS name space from fragmenting is a critical thing for
- the availability and the operation of the Internet; this memo
- addresses this issue by clear and simple operational guidelines.
-
- The RECOMMENDED guidelines are compatible with the operation of
- DNSSEC and do not introduce any new security issues.
-
-
-6. Author Addresses
-
- Alain Durand
- SUN Microsystems, Inc
- 17 Network circle UMPK17-202
- Menlo Park, CA, 94025
- USA
- Mail: Alain.Durand@sun.com
-
- Johan Ihren
- Autonomica
- Bellmansgatan 30
- SE-118 47 Stockholm, Sweden
- Mail: johani@autonomica.se
-
-
-7. Normative References
-
- [2119] Bradner, S., "Key Words for Use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-8. Full Copyright Statement
-
- "Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
deleted file mode 100644
index 2311ee6c18a01..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
+++ /dev/null
@@ -1,391 +0,0 @@
-
-DNSOP G. Guette
-Internet-Draft IRISA / INRIA
-Expires: February 5, 2005 O. Courtay
- Thomson R&D
- August 7, 2004
-
-
- Requirements for Automated Key Rollover in DNSSEC
- draft-ietf-dnsop-key-rollover-requirements-01.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 February 5, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). 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 in an automated rollover process.
- This document is essentially about key rollover, the rollover of
- another Resource Record present at delegation point (NS RR) is also
- discussed.
-
-
-
-
-
-Guette & Courtay Expires February 5, 2005 [Page 1]
-
-Internet-Draft Automated Rollover Requirements August 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
- 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Messages authentication and information exchanged . . . . . . 4
- 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
- 6. Other Resource Record concerned by automatic rollover . . . . 5
- 7. Security consideration . . . . . . . . . . . . . . . . . . . . 5
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
- 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
- Intellectual Property and Copyright Statements . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Guette & Courtay Expires February 5, 2005 [Page 2]
-
-Internet-Draft Automated Rollover Requirements August 2004
-
-
-1. Introduction
-
- The DNS security extensions (DNSSEC) [4][8][7][9] 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
- rollover process is necessary for large zones because there are too
- many changes to handle a manual administration.
-
- 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 are 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 the design of messages
- of automated key rollover process and focusses on interaction between
- parent and child zone.
-
-2. The Key Rollover Process
-
- Key rollover consists in 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.
-
- In a ZSK rollover, all changes are local to the zone that renews its
- key: there is no need to contact other zones (e.g., parent zone) to
- propagate the performed changes because a ZSK has no associated DS
- record in the parent zone.
-
- In a KSK rollover, new DS RR(s) must be created and stored in the
- parent zone. In consequence, the child zone must contact its parent
- zone and must notify it about the KSK change(s).
-
- Manual key rollover exists and works [3]. The key rollover is built
- from two parts of different nature:
- o An algorithm that generates new keys and signs the zone file. It
- could be local to the zone
- o The interaction between parent and child zones
-
- One example of manual key rollover is:
-
-
-
-
-Guette & Courtay Expires February 5, 2005 [Page 3]
-
-Internet-Draft Automated Rollover Requirements August 2004
-
-
- o The child zone creates a new KSK
- o The child zone waits for the creation of the DS RR in its parent
- zone
- o The child zone deletes the old key.
-
- In manual rollover, communications are managed by the zone
- administrators and the security of these communications is out of
- scope of DNSSEC.
-
- Automated key rollover should use a secure communication between
- parent and child zones. This document concentrates on defining
- interactions between entities present in key rollover process.
-
-3. Basic Requirements
-
- The main constraint to respect during a key rollover is that the
- chain of trust MUST be preserved, even if a resolver retrieves some
- RRs from recursive cache server. Every RR MUST be verifiable at any
- time, every RRs exchanged during the rollover should be authenticated
- and their integrity should be guaranteed.
-
- 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.
-
-4. Messages authentication and information exchanged
-
- Every exchanged message MUST be authenticated and the authentication
- tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC
- request with verifiable SIG records.
-
- Once the changes related to a KSK are made in a child zone, this zone
- MUST notify its parent zone in order to create the new DS RR and
- store this DS RR in parent zone file.
-
- The parent zone MUST receive all the child keys that needs the
- creation of associated DS RRs in the parent zone.
-
- Some errors could occur during transmission between child zone and
- parent zone. Key rollover solution MUST be fault tolerant, i.e. at
- any time the rollover MUST be in a consistent state and all RRs MUST
- be verifiable, even if an error occurs. That is to say that it MUST
- remain a valid chain of trust.
-
-
-
-
-Guette & Courtay Expires February 5, 2005 [Page 4]
-
-Internet-Draft Automated Rollover Requirements August 2004
-
-
-5. Emergency Rollover
-
- A key of a zone might be compromised and this key MUST be changed as
- soon as possible. Fast changes could 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 we want to no one
- can use the compromised key to spoof DNS data.
-
- In case of emergency rollover, the administrators of parent and child
- zones should create new key(s) and DS RR(s) as fast as possible in
- order to reduce the time the chain of trust is broken.
-
-6. Other Resource Record concerned by automatic rollover
-
- NS records are also present at delegation point, so when the child
- zone renews some NS RR, the corresponding records at delegation point
- in parent zone (glue) MUST be updated. NS records are concerned by
- rollover and this rollover could be automated too. In this case,
- when the child zone notifies its parent zone that some NS records
- have been changed, the parent zone MUST verify that these NS records
- are present in child zone before doing any changes in its own zone
- file. This allows to avoid inconsistency between NS records at
- delegation point and NS records present in the child zone.
-
-7. Security consideration
-
- This document describes requirements to design an automated key
- rollover in DNSSEC based on DNSSEC security. In the same way, as
- plain DNSSEC, the automatic key rollover contains no mechanism
- protecting against denial of service (DoS). The security level
- obtain after an automatic key rollover, is the security level
- provided by DNSSEC.
-
-8. Acknowledgments
-
- The authors want to acknowledge Francis Dupont, Mohsen Souissi,
- Bernard Cousin, Bertrand L‰onard and members of IDsA project for
- their contribution to this document.
-
-9 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.
-
-
-
-
-Guette & Courtay Expires February 5, 2005 [Page 5]
-
-Internet-Draft Automated Rollover Requirements August 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] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [7] Arends, R., "Resource Records for the DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-09 (work in progress), July
- 2004.
-
- [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
- "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004.
-
- [9] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in
- progress), July 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
-
-
-
-
-
-Guette & Courtay Expires February 5, 2005 [Page 6]
-
-Internet-Draft Automated Rollover Requirements August 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.
-
-
-
-
-Guette & Courtay Expires February 5, 2005 [Page 7]
-
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
deleted file mode 100644
index 6bece56182cf3..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
+++ /dev/null
@@ -1,389 +0,0 @@
-
-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-misbehavior-against-aaaa-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
deleted file mode 100644
index 1094275d3e40a..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-
-IETF DNSOP Working Group Y. Morishita
-Internet-Draft JPRS
-Expires: July 11, 2004 T. Jinmei
- Toshiba
- January 11, 2004
-
-
- Common Misbehavior against DNS Queries for IPv6 Addresses
- draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 11, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- There is some known misbehavior of DNS authoritative servers when
- they are queried for AAAA resource records. Such behavior can block
- IPv4 communication which should actually be available, cause a
- significant delay in name resolution, or even make a denial of
- service attack. This memo describes details of the known cases and
- discusses the effect of the cases.
-
-1. Introduction
-
- Many DNS clients (resolvers) that support IPv6 first search for AAAA
- Resource Records (RRs) of a target host name, and then for A RRs of
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 1]
-
-Internet-Draft Common Misbehavior against AAAA Queries January 2004
-
-
- 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. In the following
- sections, this memo describes some typical cases of the 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 even 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, and so the problem for the other cases is
- relatively minor.
-
-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 as well as 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 not a AAAA RR
- for a host name. Then the server should return a response to a query
- for a AAAA RR of the name with the RCODE being 0 (indicating no
- error) and with an empty answer section [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
- does not have a AAAA RR (but may have other types of RRs), and thus
- can improve the response time to further queries for a 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.
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 2]
-
-Internet-Draft Common Misbehavior against AAAA Queries January 2004
-
-
-4.1 Return NXDOMAIN
-
- This type of server returns a response with the RCODE being 3
- (NXDOMAIN) to a query for a AAAA RR, indicating it does not have any
- RRs of any type for the queried name.
-
- 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 as a fatal
- error in name resolution.
-
- There have been several known examples of this behavior, but all the
- examples that the authors know have changed their behavior as of this
- writing.
-
-4.2 Return NOTIMP
-
- Other authoritative servers return a response with the RCODE being 4
- (NOTIMP), indicating the servers do not support the requested type of
- query.
-
- This case is 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.
-
- In this case, the caching server 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 SERVFAIL or FORMERR would cause the same effect, though the
- authors have not seen such implementations yet.
-
-4.3 Return a Broken Response
-
- Another different type of authoritative servers returns broken
- responses to AAAA queries. A known behavior of this category is to
- return a response whose RR type is AAAA, but the length of the RDATA
- is 4 bytes. The 4-byte data looks like the IPv4 address of the
- queried host name. That is, the RR in the answer section would be
- described like this:
-
- www.bad.example. 600 IN AAAA 192.0.2.1
-
- which is, of course, bogus (or at least meaningless).
-
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 3]
-
-Internet-Draft Common Misbehavior against AAAA Queries January 2004
-
-
- A widely deployed caching server implementation transparently returns
- the broken response (as well as caches it) to the stub resolver.
- Another known server implementation parses the response by
- themselves, and sends a separate response with the RCODE being 2
- (SERVFAIL).
-
- 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.4 Make Lame Delegation
-
- Some authoritative servers respond to AAAA queries in a way causing
- lame delegation. In this case the parent zone specifies that the
- authoritative server should have the authority of a zone, but the
- server does 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 return a response with the
- RCODE being 2 (SERVFAIL) 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 the RCODE being SERVFAIL, since all the servers are
- known to be "lame."
-
- There is also an implementation that relaxes the behavior a little
- bit. It basically tries to avoid using the lame server, but still
- 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 SERVFAIL. However, this still causes redundant AAAA
- queries as explained in the previous sections.
-
-4.5 Ignore Queries for AAAA
-
- Some authoritative severs seem to ignore queries for a AAAA RR,
- causing a delay at the stub resolver to fall back to a query for an A
- RR. This behavior may even cause a fatal timeout at the resolver.
-
-
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 4]
-
-Internet-Draft Common Misbehavior against AAAA Queries January 2004
-
-
-5. Security Considerations
-
- The CERT/CC pointed out that the response with NXDOMAIN described in
- Section 4.1 can be used for a denial of service attack [2]. The same
- argument applies to the case of "lame delegation" described in
- Section 4.4 with a certain type of caching server.
-
-6. Acknowledgements
-
- Erik Nordmark encouraged the authors to publish this document as an
- Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary
- version of this document. Pekka Savola carefully reviewed a previous
- version and provided detailed comments.
-
-Informative References
-
- [1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
- 1034, November 1987.
-
- [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from
- AAAA queries could cause denial-of-service conditions", March
- 2003, <http://www.kb.cert.org/vuls/id/714121>.
-
-
-Authors' Addresses
-
- MORISHITA Orange Yasuhiro
- Research and Development Department, Japan Registry Service Co.,Ltd.
- Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi
- Chiyoda-ku, Tokyo 101-0052
- 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
-
-Appendix A. Live Examples
-
- In this appendix, we show concrete implementations and domain names
- that may cause problematic cases so that the behavior can be
- reproduced in a practical environment. The examples are for
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 5]
-
-Internet-Draft Common Misbehavior against AAAA Queries January 2004
-
-
- informational purposes only, and the authors do not intend to accuse
- any implementations or zone administrators.
-
- The behavior described in Section 4.2 (return NOTIMP) can be found by
- looking for a AAAA RR of www.css.vtext.com at 66.174.3.4.
-
- The behavior described in Section 4.3 (broken responses) can be seen
- by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an
- alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior
- can be found with the name "vip.alt.ihp.sony.co.jp," an alias of
- "www.sony.co.jp," at 210.139.255.204.
-
- The behavior described in Section 4.4 (lame delegation) can be found
- by querying for a AAAA RR of "www.ual.com" at 209.87.113.4.
-
- The behavior described in Section 4.5 (ignore queries) can be seen by
- trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an
- alias of "ad.jp.doubleclick.net," at 210.153.90.9.
-
- Many authoritative server implementations show the expected behavior
- described in Section 3. Some DNS load balancers reportedly have a
- problematic behavior shown in Section 4, but the authors do not have
- a concrete example. The CERT/CC provides a list of implementations
- that behave as described in Section 4.1 [2].
-
- The BIND9 caching server implementation is an example of the latter
- cases described in Section 4.3 and Section 4.4, respectively. The
- BIND8 caching server implementation is an example of the former case
- described in Section 4.3. As for the issue shown in Section 4.4,
- BIND8 caching servers prior to 8.3.5 show the behavior described as
- the former case in this section. The versions 8.3.5 and later of
- BIND8 caching server behave like the BIND9 caching server
- implementation with this matter.
-
- Regarding resolver implementations, the authors are only familiar
- with the ones derived from the BIND implementation. These
- implementations always fall back regardless of the RCODE; NXDOMAIN,
- NOTIMP, or SERVFAIL. It even falls back when getting a broken
- response. However, the behavior does not help the situation in the
- NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also
- causes a fatal error at the resolver side if the resolver is using
- some older versions of BIND8 caching server.
-
- The authors hear that a stub resolver routine implemented in some web
- browsers interprets the broken response described in Section 4.3 as a
- fatal error and does not fall back to A queries. However, we have not
- confirmed this information.
-
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 6]
-
-Internet-Draft Common Misbehavior against AAAA Queries January 2004
-
-
-Appendix B. Change History
-
- Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are:
-
- o Made a separate appendix and moved live examples to appendix so
- that we can remove them when this document is (ever) officially
- published.
-
- o Revised some live examples based on the recent status.
-
- o Noted in introduction that the misbehavior is not specific to AAAA
- and that this document still concentrates on the AAAA case.
-
- o Changed the section title of "delegation loop" to "lame
- delegation" in order to reflect the essential point of the issue.
- Wording on this matter was updated accordingly.
-
- o Updated the Acknowledgements list.
-
- o Changed the reference category from normative to informative (this
- is an informational document after all).
-
- o Changed the draft name to an IETF dnsop working group document (as
- agreed).
-
- o Applied several editorial fixes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 7]
-
-Internet-Draft Common Misbehavior against AAAA Queries January 2004
-
-
-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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 8]
-
-Internet-Draft Common Misbehavior against AAAA Queries January 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morishita & Jinmei Expires July 11, 2004 [Page 9]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt
deleted file mode 100644
index f6ece88210345..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt
+++ /dev/null
@@ -1,485 +0,0 @@
- DNSOP Working Group Paul Vixie, ISC (Ed.)
- INTERNET-DRAFT Akira Kato, WIDE
- <draft-ietf-dnsop-respsize-01.txt> July, 2004
-
-
- DNS Response Size Issues
-
-
- 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 we are aware have been or will be disclosed, and any of which
- we 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.
-
-
- Copyright Notice
-
-
- Copyright (C) The Internet Society (2003-2004). 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 2004 [Page 1]
- INTERNET-DRAFT June 2003 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 was 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 present
- and what was omitted. If a retry using TCP is needed, the total cost of
- the transaction is much higher.
-
-
- 2.3. RRsets are never sent partially, so if truncation occurs, entire
- RRsets are omitted. Note that the authority section consists of a
- single RRset. It is absolutely essential that truncation not occur in
- the authority section.
-
-
-
-
-
-
-
-
- Expires December 2004 [Page 2]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- 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, without considering whether the omitted
- data was actually necessary.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires December 2004 [Page 3]
- INTERNET-DRAFT June 2003 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 2004 [Page 4]
- INTERNET-DRAFT June 2003 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 13 13 0
- common name, average case: msg:303 nsaddr#13 (green)
- common name, worst case: msg:495 nsaddr# 1 (red)
- uncommon name, average case: msg:457 nsaddr# 3 (orange)
- uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
- % perl respsize.pl 13 13 2
- common name, average case: msg:303 nsaddr#11 (orange)
- common name, worst case: msg:495 nsaddr# 1 (red)
- uncommon name, average case: msg:457 nsaddr# 2 (orange)
- uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
-
-
- (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.
-
-
- 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 more 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 assuming that additional-data truncation
- is undesirable in the average case.
-
-
-
-
- Expires December 2004 [Page 5]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- 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 -w
-
-
- $asize = 2+2+2+4+2+4;
- $aaaasize = 2+2+2+4+2+16;
- ($nns, $na, $naaaa) = @ARGV;
- test("common", "average", common_name_average($nns),
- $na, $naaaa);
- test("common", "worst", common_name_worst($nns),
- $na, $naaaa);
- test("uncommon", "average", uncommon_name_average($nns),
- $na, $naaaa);
- test("uncommon", "worst", uncommon_name_worst($nns),
- $na, $naaaa);
- exit 0;
-
-
- sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_;
- my $nglue = numglue($msg, $na, $naaaa);
- printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n",
- $namekind, $casekind,
- $msg, ($msg > 512) ? "(*)" : " ",
- $nglue, ($nglue == $na + $naaaa) ? "green"
- : ($nglue >= 2) ? "orange"
- : "red";
- }
-
-
- sub pnum { my ($num, $tot) = @_;
- return sprintf "%3d%s",
- }
-
-
- sub numglue { my ($msg, $na, $naaaa) = @_;
- my $space = ($msg > 512) ? 0 : (512 - $msg);
- my $num = 0;
-
-
- while ($space && ($na || $naaaa )) {
- if ($na) {
- if ($space >= $asize) {
- $space -= $asize;
-
-
-
-
- Expires December 2004 [Page 6]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- $num++;
- }
- $na--;
- }
- if ($naaaa) {
- if ($space >= $aaaasize) {
- $space -= $aaaasize;
- $num++;
- }
- $naaaa--;
- }
- }
- return $num;
- }
-
-
- sub msgsize { my ($qname, $nns, $nsns) = @_;
- return 12 + # header
- $qname+2+2 + # query
- 0 + # answer
- $nns * (4+2+2+4+2+$nsns); # authority
- }
-
-
- sub average_case { my ($nns, $nsns) = @_;
- return msgsize(64, $nns, $nsns);
- }
-
-
- sub worst_case { my ($nns, $nsns) = @_;
- return msgsize(256, $nns, $nsns);
- }
-
-
- sub common_name_average { my ($nns) = @_;
- return 15 + average_case($nns, 2);
- }
-
-
- sub common_name_worst { my ($nns) = @_;
- return 15 + worst_case($nns, 2);
- }
-
-
- sub uncommon_name_average { my ($nns) = @_;
- return average_case($nns, 15);
- }
-
-
- sub uncommon_name_worst { my ($nns) = @_;
- return worst_case($nns, 15);
- }
-
-
-
-
- Expires December 2004 [Page 7]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- 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 (2003-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.
-
-
- 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 2004 [Page 8] \ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt
deleted file mode 100644
index 63fe2de521ae6..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt
+++ /dev/null
@@ -1,480 +0,0 @@
-
-
-
-
-
-
- DNSOP Working Group Paul Vixie, ISC
- INTERNET-DRAFT Akira Kato, WIDE
- <draft-ietf-dnsop-respsize-02.txt> July 2005
-
- DNS Response Size Issues
-
- Status of this Memo
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-
- Abstract
-
- With a mandated default minimum maximum message size of 512 octets,
- the DNS protocol presents some special problems for zones wishing to
- expose a moderate or high number of authority servers (NS RRs). This
- document explains the operational issues caused by, or related to
- this response size limit.
-
-
-
-
-
-
- Expires December 2005 [Page 1]
-
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- 1 - Introduction and Overview
-
- 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
- octets. Even though this limitation was due to the required minimum UDP
- reassembly limit for IPv4, it is a hard DNS protocol limit and is not
- implicitly relaxed by changes in transport, for example to IPv6.
-
- 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
- responses by mutual agreement of the requestor and responder. However,
- deployment of EDNS0 cannot be expected to reach every Internet resolver
- in the short or medium term. The 512 octet message size limit remains
- in practical effect at this time.
-
- 1.3. Since DNS responses include a copy of the request, the space
- available for response data is somewhat less than the full 512 octets.
- For negative responses, there is rarely a space constraint. For
- positive and delegation responses, though, every octet must be carefully
- and sparingly allocated. This document specifically addresses
- delegation response sizes.
-
- 2 - Delegation Details
-
- 2.1. A delegation response will include the following elements:
-
- Header Section: fixed length (12 octets)
- Question Section: original query (name, class, type)
- Answer Section: (empty)
- Authority Section: NS RRset (nameserver names)
- Additional Section: A and AAAA RRsets (nameserver addresses)
-
- 2.2. If the total response size would exceed 512 octets, and if the data
- that would not fit belonged in the question, answer, or authority
- section, then the TC bit will be set (indicating truncation) which may
- cause the requestor to retry using TCP, depending on what information
- was desired and what information was omitted. If a retry using TCP is
- needed, the total cost of the transaction is much higher. (See [RFC1123
- 6.1.3.2] for details on the protocol requirement that UDP be attempted
- before falling back to TCP.)
-
- 2.3. RRsets are never sent partially unless truncation occurs, in which
- case the final apparent RRset in the final nonempty section must be
- considered "possibly damaged". With or without truncation, the glue
- present in the additional data section should be considered "possibly
- incomplete", and requestors should be prepared to re-query for any
- damaged or missing RRsets. For multi-transport name or mail services,
-
-
-
- Expires December 2005 [Page 2]
-
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
- RRset is present.
-
- 2.4. DNS label compression allows a domain name to be instantiated only
- once per DNS message, and then referenced with a two-octet "pointer"
- from other locations in that same DNS message. If all nameserver names
- in a message are similar (for example, all ending in ".ROOT-
- SERVERS.NET"), then more space will be available for uncompressable data
- (such as nameserver addresses).
-
- 2.5. The query name can be as long as 255 characters of presentation
- data, which can be up to 256 octets of network data. In this worst case
- scenario, the question section will be 260 octets in size, which would
- leave only 240 octets for the authority and additional sections (after
- deducting 12 octets for the fixed length header.)
-
- 2.6. Average and maximum question section sizes can be predicted by the
- zone owner, since they will know what names actually exist, and can
- measure which ones are queried for most often. For cost and performance
- reasons, the majority of requests should be satisfied without truncation
- or TCP retry.
-
- 2.7. Requestors who deliberately send large queries to force truncation
- are only increasing their own costs, and cannot effectively attack the
- resources of an authority server since the requestor would have to retry
- using TCP to complete the attack. An attack that always used TCP would
- have a lower cost.
-
- 2.8. The minimum useful number of address records is two, since with
- only one address, the probability that it would refer to an unreachable
- server is too high. Truncation which occurs after two address records
- have been added to the additional data section is therefore less
- operationally significant than truncation which occurs earlier.
-
- 2.9. The best case is no truncation. This is because many requestors
- will retry using TCP by reflex, or will automatically re-query for
- RRsets that are "possibly truncated", without considering whether the
- omitted data was actually necessary.
-
- 2.10. Each added NS RR for a zone will add a minimum of between 16 and
- 44 octets to every untruncated referral or negative response from the
- zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
- and 28 octets for an AAAA RR), in addition to whatever space is taken by
- the nameserver name (NS NSDNAME and A/AAAA owner name).
-
-
-
-
- Expires December 2005 [Page 3]
-
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- 3 - Analysis
-
- 3.1. An instrumented protocol trace of a best case delegation response
- follows. Note that 13 servers are named, and 13 addresses are given.
- This query was artificially designed to exactly reach the 512 octet
- limit.
-
- ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
- ;; QUERY SECTION:
- ;; [23456789.123456789.123456789.\
- 123456789.123456789.123456789.com A IN] ;; @80
-
- ;; AUTHORITY SECTION:
- com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
- com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
- com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
- com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
- com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
- com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
- com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
- com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
- com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
- com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
- com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
- com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
- com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
-
- ;; ADDITIONAL SECTION:
- A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
- B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
- C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
- D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
- E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
- F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
- G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
- H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
- I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
- J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
- K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
- L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
- M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
-
- ;; MSG SIZE sent: 80 rcvd: 512
-
-
-
-
-
- Expires December 2005 [Page 4]
-
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- 3.2. For longer query names, the number of address records supplied will
- be lower. Furthermore, it is only by using a common parent name (which
- is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
- fit. The following output from a response simulator demonstrates these
- properties:
-
- % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
- a.dns.br requires 10 bytes
- b.dns.br requires 4 bytes
- c.dns.br requires 4 bytes
- d.dns.br requires 4 bytes
- # of NS: 4
- For maximum size query (255 byte):
- if only A is considered: # of A is 4 (green)
- if A and AAAA are condered: # of A+AAAA is 3 (yellow)
- if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
- For average size query (64 byte):
- if only A is considered: # of A is 4 (green)
- if A and AAAA are condered: # of A+AAAA is 4 (green)
- if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
- % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
- ns-ext.isc.org requires 16 bytes
- ns.psg.com requires 12 bytes
- ns.ripe.net requires 13 bytes
- ns.eu.int requires 11 bytes
- # of NS: 4
- For maximum size query (255 byte):
- if only A is considered: # of A is 4 (green)
- if A and AAAA are condered: # of A+AAAA is 3 (yellow)
- if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
- For average size query (64 byte):
- if only A is considered: # of A is 4 (green)
- if A and AAAA are condered: # of A+AAAA is 4 (green)
- if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
- (Note: The response simulator program is shown in Section 5.)
-
- Here we use the term "green" if all address records could fit, or
- "orange" if two or more could fit, or "red" if fewer than two could fit.
- It's clear that without a common parent for nameserver names, much space
- would be lost. For these examples we use an average/common name size of
- 15 octets, befitting our assumption of GTLD-SERVERS.NET as our common
- parent name.
-
-
-
-
- Expires December 2005 [Page 5]
-
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- We're assuming an average query name size of 64 since that is the
- typical average maximum size seen in trace data at the time of this
- writing. If Internationalized Domain Name (IDN) or any other technology
- which results in larger query names be deployed significantly in advance
- of EDNS, then new measurements and new estimates will have to be made.
-
- 4 - Conclusions
-
- 4.1. The current practice of giving all nameserver names a common parent
- (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
- responses and allows for more nameservers to be enumerated than would
- otherwise be possible. (Note that in this case it is wise to serve the
- common parent domain's zone from the same servers that are named within
- it, in order to limit external dependencies when all your eggs are in a
- single basket.)
-
- 4.2. Thirteen (13) seems to be the effective maximum number of
- nameserver names usable traditional (non-extended) DNS, assuming a
- common parent domain name, and given that response truncation is
- undesirable as an average case, and assuming mostly IPv4-only
- reachability (only A RRs exist, not AAAA RRs).
-
- 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
- prototypical delegation that currently contains thirteen (13) IPv4
- nameserver addresses (A RRs) for thirteen (13) nameserver names under a
- common parent, would not have a significant negative operational impact
- on the domain name system.
-
- 5 - Source Code
-
- #!/usr/bin/perl
- #
- # SYNOPSIS
- # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
- # if all queries are assumed to have zone suffux, such as "jp" in
- # JP TLD servers, specify it in -z option
- #
- use strict;
- use Getopt::Std;
- my ($sz_msg) = (512);
- my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
- my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
- my (%namedb, $name, $nssect, %opts, $optz);
- my $n_ns = 0;
-
-
-
-
- Expires December 2005 [Page 6]
-
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- getopt('z', opts);
- if (defined($opts{'z'})) {
- server_name_len($opts{'z'}); # just register it
- }
-
- foreach $name (@ARGV) {
- my $len;
- $n_ns++;
- $len = server_name_len($name);
- print "$name requires $len bytes\n";
- $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len;
- }
- print "# of NS: $n_ns\n";
- arsect(255, $nssect, $n_ns, "maximum");
- arsect(64, $nssect, $n_ns, "average");
-
- sub server_name_len {
- my ($name) = @_;
- my (@labels, $len, $n, $suffix);
-
- $name =~ tr/A-Z/a-z/;
- @labels = split(/./, $name);
- $len = length(join('.', @labels)) + 2;
- for ($n = 0; $#labels >= 0; $n++, shift @labels) {
- $suffix = join('.', @labels);
- return length($name) - length($suffix) + $sz_ptr
- if (defined($namedb{$suffix}));
- $namedb{$suffix} = 1;
- }
- return $len;
- }
-
- sub arsect {
- my ($sz_query, $nssect, $n_ns, $cond) = @_;
- my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
- $ansect = $sz_query + 1 + $sz_type + $sz_class;
- $space = $sz_msg - $sz_header - $ansect - $nssect;
- $n_a = atmost(int($space / $sz_rr_a), $n_ns);
- $n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
- $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns);
- printf "For %s size query (%d byte):\n", $cond, $sz_query;
- printf "if only A is considered: ";
- printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
- printf "if A and AAAA are condered: ";
- printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
-
-
-
- Expires December 2005 [Page 7]
-
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- printf "if prefer_glue A is assumed: ";
- printf "# of A is %d, # of AAAA is %d (%s)\n",
- $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
- }
-
- sub judge {
- my ($n, $n_ns) = @_;
- return "green" if ($n >= $n_ns);
- return "yellow" if ($n >= 2);
- return "orange" if ($n == 1);
- return "red";
- }
-
- sub atmost {
- my ($a, $b) = @_;
- return 0 if ($a < 0);
- return $b if ($a > $b);
- return $a;
- }
-
- Security Considerations
-
- The recommendations contained in this document have no known security
- implications.
-
- IANA Considerations
-
- This document does not call for changes or additions to any IANA
- registry.
-
- IPR Statement
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except as
- set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
- IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
- Expires December 2005 [Page 8]
-
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- Authors' Addresses
-
- Paul Vixie
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 423 1301
- vixie@isc.org
-
- Akira Kato
- University of Tokyo, Information Technology Center
- 2-11-16 Yayoi Bunkyo
- Tokyo 113-8658, JAPAN
- +81 3 5841 2750
- kato@wide.ad.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires December 2005 [Page 9]
- \ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt
deleted file mode 100644
index b593c57179e33..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-Network Working Group S. Woolf
-Internet-Draft Internet Systems Consortium, Inc.
-Expires: January 16, 2005 D. Conrad
- Nominum, Inc.
- July 18, 2004
-
-
- Identifying an Authoritative Name `Server
- draft-ietf-dnsop-serverid-02
-
-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 January 16, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-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
- query would be useful, particularly as a diagnostic aid. Existing ad
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 1]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
- 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 disadvantasges, and to
- characterize an improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 2]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-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 January 16, 2005 [Page 3]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-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 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 (e.g., as generated by tools such
- as "traceroute"), etc., can end up going to a different server than
- that which receives the DNS queries.
-
- 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 January 16, 2005 [Page 4]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-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 re-
- definable string which defaults to the version of the server
- responding.
-
-3.1 Advantages
-
- There are several valuable attributes to this mechanism, which
- account for its usefulness.
- 1. This 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. It is simple to configure. An administrator can easily turn on
- this feature and control the results of the relevant query.
- 3. 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.
- 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
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 5]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
- 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 anyway. 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 January 16, 2005 [Page 6]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-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.
- 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 January 16, 2005 [Page 7]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-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 January 16, 2005 [Page 8]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-6. Security Considerations
-
- Providing identifying information as to which server is responding
- 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 January 16, 2005 [Page 9]
-
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-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 draft 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 January 16, 2005 [Page 10]
-
-Internet-Draft Identifying an Authoritative Name `Server July 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.
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 11]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt
deleted file mode 100644
index 242aa9ea62969..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-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/draft/draft-ietf-enum-e164-gstn-np-05.txt b/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
deleted file mode 100644
index 3353b3bb423f3..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
+++ /dev/null
@@ -1,1588 +0,0 @@
-
- Mark Foster
-Internet Draft Tom McGarry
-Document: <draft-ietf-enum-e164-gstn-np-05.txt> James Yu
- NeuStar, Inc.
-Category: Informational June 24, 2002
-
-
- Number Portability in the GSTN: An Overview
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026 [RFC].
-
- 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 (2002). All rights reserved.
-
-
- Abstract
-
- This document provides an overview of E.164 telephone number
- portability (NP) in the Global Switched Telephone Network (GSTN).
- NP is a regulatory imperative seeking to liberalize local telephony
- service competition, by enabling end-users to retain telephone
- numbers while changing service providers. NP changes the
- fundamental nature of a dialed E.164 number from a hierarchical
- physical routing address to a virtual address, thereby requiring the
- transparent translation of the later to the former. In addition,
- there are various regulatory constraints that establish relevant
- parameters for NP implementation, most of which are not network
- technology specific. Consequently, the implementation of NP
- behavior consistent with applicable regulatory constraints, as well
- as the need for interoperation with the existing GSTN NP
- implementations, are relevant topics for numerous areas of IP
- telephony work-in-progress at IETF.
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 1]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
-
- Table of Contents
-
- 1. Introduction ............................................... 2
- 2. Abbreviations and Acronyms ................................. 4
- 3. Types of Number Portability ................................ 5
- 4. Service Provider Number Portability Schemes ................ 7
- 4.1 All Call Query (ACQ) .................................. 7
- 4.2 Query on Release (QoR) ................................ 8
- 4.3 Call Dropback ......................................... 9
- 4.4 Onward Routing (OR) ................................... 9
- 4.5 Comparisons of the Four Schemes ....................... 10
- 5. Database Queries in the NP Environment ..................... 11
- 5.1 U.S. and Canada ....................................... 12
- 5.2 Europe ................................................ 13
- 6. Call Routing in the NP Environment ......................... 14
- 6.1 U.S. and Canada ....................................... 14
- 6.2 Europe ................................................ 15
- 7. NP Implementations for Geographic E.164 Numbers ............ 17
- 8. Number Conservation Method Enabled By NP ................... 20
- 8.1 Block Pooling ......................................... 20
- 8.2 ITN Pooling ........................................... 21
- 9. Potential Implications ..................................... 21
- 10. Security Considerations .................................... 24
- 11. IANA Considerations ........................................ 24
- 12. Normative References ....................................... 24
- 13. Informative References ..................................... 25
- 14. Acknowledgement ............................................ 25
- 15. AuthorsË Addresses ......................................... 25
-
-
-
-1. Introduction
-
- This document provides an overview of E.164 telephone number
- portability in the Global Switched Telephone Network (GSTN). There
- are considered to be three types of number portability (NP): service
- provider portability (SPNP), location portability (not to be
- confused with terminal mobility), and service portability.
-
- Service provider portability (SPNP), the focus of the present draft,
- is a regulatory imperative in many countries seeking to liberalize
- telephony service competition, especially local service.
- Historically, local telephony service (as compared to long distance
- or international service) has been regulated as a utility-like form
- of service. While a number of countries had begun liberalization
- (e.g. privatization, de-regulation, or re-regulation) some years
- ago, the advent of NP is relatively recent (since ~1995).
-
- E.164 numbers can be non-geographic and geographic numbers. Non-
- geographic numbers do not reveal the locations information of those
- numbers. Geographic E.164 numbers were intentionally designed as
- hierarchical routing addresses which could systematically be digit-
- analyzed to ascertain the country, serving network provider, serving
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 2]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- end-office switch, and specific line of the called party. As such,
- without NP a subscriber wishing to change service providers would
- incur a number change as a consequence of being served off of a
- different end-office switch operated by the new service provider.
- The cost and convenience impact to the subscriber of changing
- numbers is seen as barrier to competition. Hence NP has become
- associated with GSTN infrastructure enhancements associated with a
- competitive environment driven by regulatory directives.
-
- Forms of SPNP have been deployed or are being deployed widely in the
- GSTN in various parts of the world, including the U.S., Canada,
- Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong).
- Other regions, such as South America (e.g. Brazil) are actively
- considering it.
-
- Implementation of NP within a national telephony infrastructure
- entails potentially significant changes to numbering administration,
- network element signaling, call routing and processing, billing,
- service management, and other functions.
-
- NP changes the fundamental nature of a dialed E.164 number from a
- hierarchical physical routing address to a virtual address. NP
- implementations attempt to encapsulate the impacts to the GSTN and
- make NP transparent to subscribers by incorporating a translation
- function to map a dialed, potentially ported E.164 address, into a
- network routing address (either a number prefix or another E.164
- address) which can be hierarchically routed.
-
- This is roughly analogous to the use of network address translation
- on IP addresses to enable IP address portability by containing the
- impact of the address change to the edge of the network and retain
- the use of CIDR blocks in the core which can be route aggregated by
- the network service provider to the rest of the internet.
-
- NP bifurcates the historical role of a subscriberËs E.164 address
- into two or more data elements (a dialed or virtual address, and a
- network routing address) that must be made available to network
- elements through an NP translations database, carried by forward
- call signaling, and recorded on call detail records. Not only is
- call processing and routing affected, but also so is SS7/C7
- messaging. A number of TCAP-based SS7 messaging sets utilize an
- E.164 address as an application-level network element address in the
- global title address (GTA) field of the SCCP message header.
- Consequently, SS7/C7 signaling transfer points (STPs) and gateways
- need to be able to perform n-digit global title translation (GTT) to
- translate a dialed E.164 address into its network address
- counterpart via the NP database.
-
- In addition, there are various national regulatory constraints that
- establish relevant parameters for NP implementation, most of which
- are not network technology specific. Consequently, implementations
- of NP behavior in IP telephony consistent with applicable regulatory
- constraints, as well as the need for interoperation with the
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 3]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- existing GSTN NP implementations, are relevant topics for numerous
- areas of IP telephony work-in-progress at IETF.
-
- This document describes three types of number portability and the
- four schemes that have been standardized to support SPNP for
- geographic E.164 numbersspecifically. Following that, specific
- information regarding the call routing and database query
- implementations are described for several regions (North American
- and Europe) and industries (wireless vs. wireline). The Number
- Portability Database (NPDB) interfaces and the call routing schemes
- that are used in the North America and Europe are described to show
- the variety of standards that may be implemented worldwide. A
- glance of the NP implementations worldwide is provided. Number
- pooling is briefly discussed to show how NP is being enhanced in the
- U.S. to conserve North American area codes. The conclusion briefly
- touches the potential impacts of NP on IP & Telecommunications
- Interoperability. Appendix A provides some specific technical and
- regulatory information on NP in North America. Appendix B describes
- the number portability administration process that manages the
- number portability database in North America.
-
-
-2. Abbreviations and Acronyms
-
- ACQ All Call Query
- AIN Advanced Intelligent Network
- AMPS Advanced Mobile Phone System
- ANSI American National Standards Institute
- CDMA Code Division Multiple Access
- CdPA Called Party Address
- CdPN Called Party Number
- CH Code Holder
- CMIP Common Management Information Protocol
- CS1 Capability Set 1
- CS2 Capability Set 2
- DN Directory Number
- DNS Domain Name System
- ETSI European Technical Standards Institute
- FCI Forward Call Indicator
- GAP Generic Address Parameter
- GMSC Gateway Mobile Services Switching Center or Gateway Mobile
- Switching Center
- GSM Global System for Mobile Communications
- GSTN Global Switched Telephone Network
- GW Gateways
- HLR Home Location Register
- IAM Initial Address Message
- IETF Internet Engineering Task Force
- ILNP Interim LNP
- IN Intelligent Network
- INAP Intelligent Network Application Part
- INP Interim NP
- IP Internet Protocol
- IS-41 Interim Standards Number 41
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 4]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- ISDN Integrated Services Digital Network
- ISUP ISDN User Part
- ITN Individual Telephony Number
- ITU International Telecommunication Union
- ITU-TS ITU-Telecommunication Sector
- LDAP Lightweight Directory Access Protocol
- LEC Local Exchange Carrier
- LERG Local Exchange Routing Guide
- LNP Local Number Portability
- LRN Location Routing Number
- MAP Mobile Application Part
- MNP Mobile Number Portability
- MSRN Mobile Station Roaming Number
- MTP Message Transfer Part
- NANP North American Numbering Plan
- NP Number Portability
- NPDB Number Portability Database
- NRN Network Routing Number
- OR Onward Routing
- OSS Operation Support System
- PCS Personal Communication Services
- PNTI Ported Number Translation Indicator
- PODP Public Office Dialing Plan
- PUC Public Utility Commission
- QoR Query on Release
- RN Routing Number
- RTP Return to Pivot
- SCCP Signaling Connection Control Part
- SCP Service Control Point
- SIP Session Initiation Protocol
- SMR Special Mobile Radio
- SMS Service Management System
- SPNP Service Provider Number Portability
- SRF Signaling Relaying Function
- SRI Send Routing Information
- SS7 Signaling System Number 7
- STP Signaling Transfer Point
- TCAP Transaction Capabilities Application Part
- TDMA Time Division Multiple Access
- TN Telephone Number
- TRIP Telephony Routing Information Protocol
- URL Universal Resource Locator
- U.S. United States
-
-
-3. Types of Number Portability
-
- As there are several types of E.164 numbers (telephone numbers, or
- just TN) in the GSTN, there are correspondingly several types of
- E.164 NP in the GSTN. First there are so-call non-geographic E.164
- numbers, commonly used for service-specific applications such as
- freephone (800 or 0800). Portability of these numbers is called
- non-geographic number portability (NGNP). NGNP, for example, was
- deployed in the U.S. in 1986-92.
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 5]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
-
- Geographic number portability, which includes traditional fixed or
- wireline numbers as well as mobile numbers which are allocated out
- of geographic number range prefixes, is called NP or GNP or in the
- U.S. local number portability (LNP).
-
- Number portability allows the telephony subscribers in the Global
- Switched Telephone Network (GSTN) to keep their phone numbers when
- they change their service providers or subscribed services, or when
- they move to a new location.
-
- The ability to change the service provider while keeping the same
- phone number is called service provider portability (SPNP) also
- known as "operator portability."
-
- The ability to change the subscriberËs fixed service location while
- keeping the same phone number is called location portability.
-
- The ability to change the subscribed services (e.g., from the plain
- old telephone service to Integrated Services Digital Network (ISDN)
- services) while keeping the same phone number is called service
- portability. Another aspect of service portability is to allow the
- subscribers to enjoy the subscribed services in the same way when
- they roam outside their home networks as is supported by the
- cellular/wireless networks.
-
- In addition, mobile number portability (MNP) refers to specific NP
- implementation in mobile networks either as part of a broader NP
- implementation in the GSTN or on a stand-alone basis. Where
- interoperation of LNP and MNP is supported, service portability
- between fixed and mobile service types is possible.
-
- At present, SPNP has been the primary form of NP deployed due to its
- relevance in enabling local service competition.
-
- Also in use in the GSTN are the terms interim NP (INP) or Interim
- LNP (ILNP) and true NP. Interim NP usually refers to the use of
- remote call forwarding-like measures to forward calls to ported
- numbers through the donor network to the new service network. These
- are considered interim relative to true NP, which seeks to remove
- the donor network or old service provider from the call or signaling
- path altogether. Often the distinction between interim and true NP
- is a national regulatory matter relative to the
- technical/operational requirements imposed on NP in that country.
-
- Implementations of true NP in certain countries (e.g. U.S., Canada,
- Spain, Belgium, Denmark) may pose specific requirements for IP
- telephony implementations as a result of regulatory and industry
- requirements for providing call routing and signaling independent of
- the donor network or last previous serving network.
-
-
-
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 6]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
-
-4. Service Provider Number Portability Schemes
-
- Four schemes can be used to support service provider portability and
- are briefly described below. But first, some further terms are
- introduced.
-
- The donor network is the network that first assigned a telephone
- number (e.g., TN +1-202-533-1234) to a subscriber, out of a number
- range administratively (e.g., +1 202-533) assigned to it. The
- current service provider (new SP) or new serving network is the
- network that currently serves the ported number. The old serving
- network (or old SP) is the network that previously served the ported
- number before the number was ported to the new serving network.
- Since a TN can port a number of times, the old SP is not necessarily
- the same as the donor network, except for the first time the TN
- ports away, or if the TN ports back into the donor network and away
- again. While the new SP and old SP roles are transitory as a TN
- ports around, the donor network is always the same for any
- particular TN based on the service provider to whom the subtending
- number range was administratively assigned. See the discussion
- below on number pooling, as this enhancement to NP further
- bifurcates the role of donor network into two (the number range or
- code holder network, and the block holder network).
-
- To simplify the illustration, all the transit networks are ignored,
- the originating or donor network is the one that performs the
- database queries or call redirection, and the dialed directory
- number (TN) has been ported out of the donor network before.
-
- It is assumed that the old serving network, the new serving network
- and the donor network are different networks so as to show which
- networks are involved in call handling and routing and database
- queries in each of four schemes. Please note that the port of the
- number (process of moving it from one network to another) happened
- prior to the call setup and is not included in the call steps.
- Information carried in the signaling messages to support each of the
- four schemes is not discussed to simplify the explanation.
-
-
-4.1 All Call Query (ACQ)
-
- Figure 1 shows the call steps for the ACQ scheme. Those call steps
- are as follows:
-
- (1) The Originating Network receives a call from the caller and
- sends a query to a centrally administered Number Portability
- Database (NPDB), a copy of which is usually resident on a
- network element within its network or through a third party
- provider.
- (2) The NPDB returns the routing number associated with the dialed
- directory number. The routing number is discussed later in
- Section 6.
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 7]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- (3) The Originating Network uses the routing number to route the
- call to the new serving network.
-
-
- +-------------+ +-----------+ Number +-----------+
- | Centralized | | New Serv. | ported | Old Serv. |
- | NPDB | +-------->| Network |<------------| Network |
- +-------------+ | +-----------+ +-----------+
- ^ | |
- | | |
- 1| | 3.|
- | | 2. |
- | | |
- | v |
- +----------+ | +----------+ +----------+
- | Orig. |------+ | Donor | | Internal |
- | Network | | Network | | NPDB |
- +----------+ +----------+ +----------+
-
-
- Figure 1 - All Call Query (ACQ) Scheme.
-
-
-4.2 Query on Release (QoR)
-
- Figure 2 shows the call steps for the QoR scheme. Those call steps
- are as follows:
-
-
- +-------------+ +-----------+ Number +-----------+
- | Centralized | | New Serv. | ported | Old Serv. |
- | NPDB | | Network |<------------| Network |
- +-------------+ +-----------+ +-----------+
- ^ | ^
- | | 4. |
- 3.| | 5. |
- | | +----------------------+
- | | |
- | v |
- +----------+ 2. +----------+ +----------+
- | Orig. |<---------------| Donor | | Internal |
- | Network |--------------->| Network | | NPDB |
- +----------+ 1. +----------+ +----------+
-
-
- Figure 2 - Query on Release (QoR) Scheme.
-
- (1) The Originating Network receives a call from the caller and
- routes the call to the donor network.
- (2) The donor network releases the call and indicates that the
- dialed directory number has been ported out of that switch.
- (3) The Originating Network sends a query to its copy of the
- centrally administered NPDB.
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 8]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- (4) The NPDB returns the routing number associated with the dialed
- directory number.
- (5) The Originating Network uses the routing number to route the
- call to the new serving network.
-
-
-4.3 Call Dropback
-
- Figure 3 shows the call steps for the Dropback scheme. This scheme
- is also known as "Return to Pivot (RTP)." Those call steps are as
- follows:
-
- (1) The Originating Network receives a call from the caller and
- routes the call to the donor network.
- (2) The donor network detects that the dialed directory number has
- been ported out of the donor switch and checks with an internal
- network-specific NPDB.
- (3) The internal NPDB returns the routing number associated with the
- dialed directory number.
- (4) The donor network releases the call by providing the routing
- number.
- (5) The Originating Network uses the routing number to route the
- call to the new serving network.
-
- +-------------+ +-----------+ Number +-----------+
- | Centralized | | New Serv. | porting | Old Serv. |
- | NPDB | | Network |<------------| Network |
- +-------------+ +-----------+ +-----------+
- /\
- |
- 5. |
- +------------------------+
- |
- |
- +----------+ 4. +----------+ 3. +----------+
- | Orig. |<---------------| Donor |<----------| Internal |
- | Network |--------------->| Network |---------->| NPDB |
- +----------+ 1. +----------+ 2. +----------+
-
-
- Figure 3 - Dropback Scheme.
-
-
-4.4 Onward Routing (OR)
-
- Figure 4 shows the call steps for the OR scheme. Those call steps
- are as follows:
-
- (1) The Originating Network receives a call from the caller and
- routes the call to the donor network.
- (2) The donor network detects that the dialed directory number has
- been ported out of the donor switch and checks with an internal
- network-specific NPDB.
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 9]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- (3) The internal NPDB returns the routing number associated with the
- dialed directory number.
- (4) The donor network uses the routing number to route the call to
- the new serving network.
-
-
- +-------------+ +-----------+ Number +-----------+
- | Centralized | | New Serv. | porting | Old Serv. |
- | NPDB | | Network |<------------| Network |
- +-------------+ +-----------+ +-----------+
- /\
- |
- 4.|
- |
- +----------+ +----------+ 3. +----------+
- | Orig. | | Donor |<----------| Internal |
- | Network |--------------->| Network |---------->| NPDB |
- +----------+ 1. +----------+ 2. +----------+
-
-
- Figure 4 - Onward Routing (OR) Scheme.
-
-4.5 Comparisons of the Four Schemes
-
- Only the ACQ scheme does not involve the donor network when routing
- the call to the new serving network of the dialed ported number.
- The other three schemes involve call setup to or signaling with the
- donor network.
-
- Only the OR scheme requires the setup of two physical call segments,
- one from the Originating Network to the donor network and the other
- from the donor network to the new serving network. The OR scheme is
- the least efficient in terms of using the network transmission
- facilities. The QoR and Dropback schemes set up calls to the donor
- network first but release the call back to the Originating Network
- that then initiates a new call to the Current Serving Network. For
- the QoR and Dropback schemes, circuits are still reserved one by one
- between the Originating Network and the donor network when the
- Originating Network sets up the call towards the donor network.
- Those circuits are released one by one when the call is released
- from the donor network back to the Originating Network. The ACQ
- scheme is the most efficient in terms of using the switching and
- transmission facilities for the call.
-
- Both the ACQ and QoR schemes involve Centralized NPDBs for the
- Originating Network to retrieve the routing information.
- Centralized NPDB means that the NPDB contains ported number
- information from multiple networks. This is in contrast to the
- internal network-specific NPDB that is used for the Dropback and OR
- schemes. The internal NPDB only contains information about the
- numbers that were ported out of the donor network. The internal
- NPDB can be a stand-alone database that contains information about
- all or some ported-out numbers from the donor network. It can also
- reside on the donor switch and only contains information about those
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 10]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- numbers ported out of the donor switch. In that case, no query to a
- stand-alone internal NPDB is required. The donor switch for a
- particular phone number is the switch to which the number range is
- assigned from which that phone number was originally assigned.
-
- For example, number ranges in the North American Numbering Plan
- (NANP) are usually assigned in the form of central office codes (CO
- codes) comprising a six-digit prefix formatted as a NPA+NXX. Thus a
- switch serving +1-202-533 would typically serve +1-202-533-0000
- through +1-202-533-9999. In major cities, switches usually host
- several CO codes. NPA stands for Numbering Plan Area that is also
- known as the area code. It is three-digit long and has the format
- of NXX where N is any digit from 2 to 9 and X is any digit from 0 to
- 9. NXX in the NPA+NXX format is known as the office code that has
- the same format as the NPA. When a NPA+NXX code is set as
- Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a
- "portable NPA+NXX" code.
-
- Similarly, in other national E.164 numbering plans, number ranges
- cover a contiguous range of numbers within that range. Once a
- number within that range has ported away from the donor network, all
- numbers in that range are considered potentially ported and should
- be queried in the NPDB.
-
- The ACQ scheme has two versions. One version is for the Originating
- Network to always query the NPDB when a call is received from the
- caller regardless whether the dialed directory number belongs to any
- number range that is portable or has at least one number ported out.
- The other version is to check whether the dialed directory number
- belongs to any number range that is portable or has at least one
- number ported out. If yes, an NPDB query is sent. If not, no NPDB
- query is sent. The former performs better when there are many
- portable number ranges. The latter performs better when there are
- not too many portable number ranges at the expense of checking every
- call to see whether NPDB query is needed. The latter ACQ scheme is
- similar to the QoR scheme except that the QoR scheme uses call setup
- and relies on the donor network to indicate "number ported out"
- before launching the NPDB query.
-
-
-5. Database Queries in the NP Environment
-
- As indicated earlier, the ACQ and QoR schemes require that a switch
- query the NPDB for routing information. Various standards have been
- defined for the switch-to-NPDB interface. Those interfaces with
- their protocol stacks are briefly described below. The term "NPDB"
- is used for a stand-alone database that may support just one or some
- or all of the interfaces mentioned below. The NPDB query contains
- the dialed directory number and the NPDB response contains the
- routing number. There are certainly other information that is sent
- in the query and response. The primary interest is to get the
- routing number from the NPDB to the switch for call routing.
-
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 11]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
-5.1 U.S. and Canada
-
- One of the following five NPDB interfaces can be used to query an
- NPDB:
-
- (a) Advanced Intelligent Network (AIN) using the American National
- Standards Institute (ANSI) version of the Intelligent Network
- Application Part (INAP) [ANSI SS] [ANSI DB]. The INAP is
- carried on top of the protocol stack that includes the (ANSI)
- Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling
- Connection Control Part (SCCP), and ANSI Transaction
- Capabilities Application Part (TCAP). This interface can be
- used by the wireline or wireless switches, is specific to the NP
- implementation in North America, and is modeled on the Public
- Office Dialing Plan (PODP) trigger defined in the Advanced
- Intelligent Network (AIN) 0.1 call model.
-
- (b) Intelligent Network (IN), which is similar to the one used for
- querying the 800 databases. The IN protocol is carried on top
- of the protocol stack that includes the ANSI MTP Levels 1
- through 3, ANSI SCCP, and ANSI TCAP. This interface can be used
- by the wireline or wireless switches.
-
- (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the
- protocol stack that includes the ANSI MTP Levels 1 through 3,
- ANSI SCCP, and ANSI TCAP. This interface can be used by the IS-
- 41 based cellular/Personal Communication Services (PCS) wireless
- switches (e.g., AMPS, TDMA and CDMA). Cellular systems use
- spectrum at 800 MHz range and PCS systems use spectrum at 1900
- MHz range.
-
- (d) Global System for Mobile Communication Mobile Application Part
- (GSM MAP) [GSM], which is carried on top of the protocol stack
- that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and
- International Telecommunication Union - Telecommunication Sector
- (ITU-TS) TCAP. It can be used by the PCS1900 wireless switches
- that are based on the GSM technologies. GSM is a series of
- wireless standards defined by the European Telecommunications
- Standards Institute (ETSI).
-
- (e) ISUP triggerless translation. NP translations are performed
- transparently to the switching network by the signaling network
- (e.g. Signaling Transfer Points (STPs) or signaling gateways).
- ISUP IAM messages are examined to determine if the CdPN field
- has already been translated, and if not, an NPDB query is
- performed, and the appropriate parameters in the IAM message
- modified to reflect the results of the translation. The
- modified IAM message is forwarded by the signaling node on to
- the designated DPC in a transparent manner to continue call
- setup. The NPDB can be integrated with the signaling node or be
- accessed via an API locally or by a query to a remote NPDB using
- a proprietary protocol or the schemes described above.
-
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 12]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- Wireline switches have the choice of using either (a), (b), or (e).
- IS-41 based wireless switches have the choice of using (a), (b),
- (c), or (e). PCS1900 wireless switches have the choice of using
- (a), (b), (d), or (e). In the United States, service provider
- portability will be supported by both the wireline and wireless
- systems, not only within the wireline or wireless domain but also
- across the wireline/wireless boundary. However, this is not true in
- Europe where service provider portability is usually supported only
- within the wireline or wireless domain, not across the
- wireline/wireless boundary due to explicit use of service-specific
- number range prefixes. The reason is to avoid caller confusion
- about the call charge. GSM systems in Europe are assigned
- distinctive destination network codes, and the caller pays a higher
- charge when calling a GSM directory number.
-
-
-5.2 Europe
-
- One of the following two interfaces can be used to query an NPDB:
-
- (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is
- carried on top of the protocol stack that includes the ITU-TS
- MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP.
-
- (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is
- carried on top of the protocol stack that includes the ITU-TS
- MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP,
- and ITU-TS TCAP.
-
- Wireline switches have the choice of using either (a) or (b);
- however, all the implementations in Europe so far are based on CS1.
- As indicated earlier that number portability in Europe does not go
- across the wireline/wireless boundary. The wireless switches can
- also use (a) or (b) to query the NPDBs if those NPDBs contains
- ported wireless directory numbers. The term "Mobile Number
- Portability (MNP)" is used for the support of service provider
- portability by the GSM networks in Europe.
-
- In most, if not all, cases in Europe, the calls to the wireless
- directory numbers are routed to the wireless donor network first.
- Over there, an internal NPDB is queried to determine whether the
- dialed wireless directory number has been ported out or not. In
- this case, the interface to the internal NPDB is not subject to
- standardization.
-
- MNP in Europe can also be supported via MNP Signaling Relay Function
- (MNP-SRF). Again, an internal NPDB or a database integrated at the
- MNP-SRF is used to modify the SCCP Called Party Address parameter in
- the GSM MAP messages so that they can be re-directed to the wireless
- serving network. Call routing involving MNP will be explained in
- Section 6.2.
-
-
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 13]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
-6. Call Routing in the NP Environment
-
- This section discusses the call routing after the routing
- information has been retrieved either through an NPDB query or an
- internal database lookup at the donor switch, or from the Integrated
- Services Digital Network User Part (ISUP) signaling message (e.g.,
- for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it
- is the Originating Network that has the routing information and is
- ready to route the call. For the OR scheme, it is the donor network
- that has the routing information and is ready to route the call.
-
- A number of triggering schemes may be employed that determine where
- in the call path the NPDB query is performed. In the U.S. an ŸN-1÷
- policy is used, which essentially says that for domestic calls, the
- originating local carriers performs the query, otherwise, the long
- distance carrier is expected to. To ensure independence of the
- actual trigger policy employed in any one carrier, forward call
- signaling is used to flag that an NPDB query has already been
- performed and to therefore suppress any subsequent NP triggers that
- may be encountered in downstream switches, in downstream networks.
- This allows the earliest able network in the call path to perform
- the query without introducing additional costs and call setup delays
- were redundant queries performed downstream.
-
-
-6.1 U.S. and Canada
-
- In the U.S. and Canada, a ten-digit North American Numbering Plan
- (NANP) number called Location Routing Number (LRN) is assigned to
- every switch involved in NP. In the NANP, a switch is not reachable
- unless it has a unique number range (CO code) assigned to it.
- Consequently, the LRN for a switch is always assigned out of a CO
- code that is assigned to that switch.
-
- The LRN assigned to a switch currently serving a particular ported
- telephone number is returned as the network routing address in the
- NPDB response. The service portability scheme that was adopted in
- the North America is very often referred to as the LRN scheme or
- method.
-
- LRN serves as a network address for terminating calls served off
- that switch using ported numbers. The LRN is assigned by the switch
- operator using any of the unique CO codes (NPA+NXX) assigned to that
- switch. The LRN is considered a non-dialable address, as the same
- 10-digit number value may be assigned to a line on that switch. A
- switch may have more than one LRN.
-
- During call routing/processing, a switch performs an NPDB query to
- obtain the LRN associated with the dialed directory number. NPDB
- queries are performed for all the dialed directory numbers whose
- NPA+NXX codes are marked as portable NPA+NXX at that switch. When
- formulating the ISUP Initial Address Message (IAM) to be sent to the
- next switch, the switch puts the ten-digit LRN in the ISUP Called
- Party Number (CdPN) parameter and the originally dialed directory
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 14]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- number in the ISUP Generic Address parameter (GAP). A new code in
- the GAP was defined to indicate that the address information in the
- GAP is the dialed directory number. A new bit in the ISUP Forward
- Call Indicator (FCI) parameter, the Ported Number Translation
- Indicator (PNTI) bit, is set to imply that NPDB query has already
- been performed. All the switches in the downstream will not perform
- the NPDB query if the PNTI bit is set.
-
- When the terminating switch receives the IAM and sees the PNTI bit
- in the FCI parameter set and its own LRN in the CdPN parameter, it
- retrieves the originally dialed directory number from the GAP and
- uses the dialed directory number to terminate the call.
-
- A dialed directory number with a portable NPA+NXX does not imply
- that directory number has been ported. The NPDBs currently do not
- store records for non-ported directory numbers. In that case, the
- NPDB will return the same dialed directory number instead of the
- LRN. The switch will then set the PNTI bit but keep the dialed
- directory number in the CdPN parameter.
-
- In the real world environment, the Originating Network is not always
- the one that performs the NPDB query. For example, it is usually
- the long distance carriers that query the NPDBs for long distance
- calls. In that case, the Originating Network operated by the local
- exchange carrier (LEC) simply routes the call to the long distance
- carrier that is to handle that call. A wireless network acting as
- the Originating Network can also route the call to the
- interconnected local exchange carrier network if it does not want to
- support the NPDB interface at its mobile switches.
-
-
-6.2 Europe
-
- In some European countries, a routing number is prefixed to the
- dialed directory number. The ISUP CdPN parameter in the IAM will
- contain the routing prefix and the dialed directory number. For
- example, United Kingdom uses routing prefixes with the format of
- 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks
- use the information in the ISUP CdPN parameter to route the call to
- the New/Current Serving Network.
-
- The routing prefix can identify the Current Serving Network or the
- Current Serving Switch of a ported number. For the former case,
- another query to the "internal" NPDB at the Current Serving Network
- is required to identify the Current Serving Switch before routing
- the call to that switch. This shields the Current Serving Switch
- information for a ported number from the other networks at the
- expense of an additional NPDB query. Another routing number, may be
- meaningful within the Current Serving Network, will replace the
- previously prefixed routing number in the ISUP CdPN parameter. For
- the latter case, the call is routed to the Current Serving Switch
- without an additional NPDB query.
-
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 15]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- When the terminating switch receives the IAM and sees its own
- routing prefix in the CdPN parameter, it retrieves the originally
- dialed directory number after the routing prefix, and uses the
- dialed directory number to terminate the call.
-
- The call routing example described above shows one of the three
- methods that can be used to transport the Directory Number (DN) and
- the Routing Number (RN) in the ISUP IAM message. In addition, some
- other information may be added/modified as is listed in the ETSI 302
- 097 document [ETSIISUP], which is based on the ITU-T Recommendation
- Q.769.1 [ITUISUP]. The three methods and the enhancements in the
- ISUP to support number portability are briefly described below
-
- (a) Two separate parameters with the CdPN parameter containing the
- RN and a new Called Directory Number (CdDN) parameter containing
- the DN. A new value for the Nature of Address (NOA) indicator in
- the CdPN parameter is defined to indicate that the RN is in the
- CdPN parameter. The switches use the CdPN parameter to route the
- call as is done today.
-
- (b) Two separate parameters with the CdPN parameter containing the
- DN and a new Network Routing Number (NRN) parameter containing
- the RN. This method requires that the switches use the NRN
- parameter to route the call.
-
- (c) Concatenated parameter with the CdPN parameter containing the RN
- plus the DN. A new Nature of Address (NOA) indicator in the CdPN
- parameter is defined to indicate that the RN is concatenated with
- the DN in the CdPN parameter. Some countries may not use new NOA
- value because the routing prefix does not overlap with the dialed
- directory numbers. But if the routing prefix overlaps with the
- dialed directory numbers, a new NOA value must be assigned. For
- example, Spain uses "XXXXXX" as the routing prefix to identify
- the new serving network and uses a new NOA value of 126.
-
- There is also a network option to add a new ISUP parameter called
- Number Portability Forwarding Information parameter. This parameter
- has a four-bit Number Portability Status Indicator field that can
- provide an indication whether number portability query is done for
- the called directory number and whether the called directory number
- is ported or not if the number portability query is done.
-
- Please note that all those NP enhancements for a ported number can
- only be used in the country that defined them. This is because
- number portability is supported within a nation. Within each
- nation, the telecommunications industry or the regulatory bodies can
- decide which method or methods to use. Number portability related
- parameters and coding are usually not passed across the national
- boundaries unless the interconnection agreements allow that. For
- example, a UK routing prefix can only be used in UK, and would cause
- routing problem if it appears outside UK.
-
-
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 16]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- As indicated earlier, an originating wireless network can query the
- NPDB and concatenate the RN with DN in the CdPN parameter and route
- the call directly to the Current Serving Network.
-
- If NPDBs do not contain information about the wireless directory
- numbers, the call, originated from either a wireline or a wireless
- network, will be routed to the Wireless donor network. Over there,
- an internal NPDB is queried to retrieve the RN that then is
- concatenated with the DN in the CdPN parameter.
-
- There are several ways of realizing MNP. When MNP-SRF is supported,
- the Gateway Mobile Services Switching Center (GMSC) at the wireless
- donor network, when receiving a call from the wireline network, can
- send the GSM MAP Send Routing Information (SRI) message to the MNP-
- SRF. The MNP-SRF interrogates an internal or integrated NPDB for
- the RN of the MNP-SRF of the wireless Current Serving Network and
- prefixes the RN to the dialed wireless directory number in the
- global title address information in the SCCP Called Party Address
- (CdPA) parameter. This SRI message will be routed to the MNP-SRF of
- the wireless Current Serving Network, which then responds with an
- acknowledgement by providing the RN plus the dialed wireless
- directory number as the Mobile Station Roaming Number (MSRN). The
- GMSC of the wireless donor network formulates the ISUP IAM with the
- RN plus the dialed wireless directory number in the CdPN parameter
- and routes the call to the wireless Current Serving Network. A GMSC
- of the wireless Current Serving Network receives the call and sends
- an SRI message to the associated MNP-SRF where the global title
- address information of the SCCP CdPA parameter contains only the
- dialed wireless directory number. The MNP-SRF then replaces the
- global title address information in the SCCP CdPA parameter with the
- address information associated with a Home Location Register (HLR)
- that hosts the dialed wireless directory number and forwards the
- message to that HLR after verifying that the dialed wireless
- directory number is a ported-in number. The HLR then returns an
- acknowledgement by providing an MSRN for the GMSC to route the call
- to the MSC that currently serves the mobile station that is
- associated with the dialed wireless directory number. Please see
- [MNP] for details and additional scenarios.
-
-
-7. NP Implementations for Geographic E.164 Numbers
-
- This section shows the known SPNP implementations worldwide.
-
- +-------------+----------------------------------------------------+
- + Country + SPNP Implementation +
- +-------------+----------------------------------------------------+
- + Argentina + Analyzing operative viability now. Will determine +
- + + whether portability should be made obligatory +
- + + after a technical solution has been determined. +
- +-------------+----------------------------------------------------+
- + Australia + NP supported by wireline operators since 11/30/99. +
- + + NP among wireless operators in March/April 2000, +
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 17]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- + + but may be delayed to 1Q01. The access provider +
- + + or long distance provider has the obligation to +
- + + route the call to the correct destination. The +
- + + donor network is obligated to maintain and make +
- + + available a register of numbers ported away from +
- + + its network. Telstra uses onward routing via an +
- + + on-switch solution. +
- +-------------+----------------------------------------------------+
- + Austria + Uses onward routing at the donor network. Routing +
- + + prefix is "86xx" where "xx" identifies the +
- + + recipient network. +
- +-------------+----------------------------------------------------+
- + Belgium + ACQ selected by the industry. Routing prefix is +
- + + "Cxxxx" where "xxxx" identifies the recipient +
- + + switch. Another routing prefix is "C00xx" with "xx"+
- + + identifying the recipient network. Plan to use NOA+
- + + to identify concatenated numbers and abandon the +
- + + hexadecimal routing prefix. +
- +-------------+----------------------------------------------------+
- + Brazil + Considering NP for wireless users. +
- +-------------+----------------------------------------------------+
- + Chile + There has been discussions lately on NP. +
- +-------------+----------------------------------------------------+
- + Colombia + There was an Article 3.1 on NP to support NP prior +
- + + to December 31, 1999 when NP became technically +
- + + possible. Regulator has not yet issued regulations +
- + + concerning this matter. +
- +-------------+----------------------------------------------------+
- + Denmark + Uses ACQ. Routing number not passed between +
- + + operators; however, NOA is set to "112" to +
- + + indicate "ported number." QoR can be used based +
- + + on bilateral agreements. +
- +-------------+----------------------------------------------------+
- + Finland + Uses ACQ. Routing prefix is "1Dxxy" where "xxy" +
- + + identifies the recipient network and service type. +
- +-------------+----------------------------------------------------+
- + France + Uses onward routing. Routing prefix is "Z0xxx" +
- + + where "xxx" identifies the recipient switch. +
- +-------------+----------------------------------------------------+
- + Germany + The originating network needs to do necessary +
- + + rerouting. Operators decide their own solution(s).+
- + + Deutsche Telekom uses ACQ. Routing prefix is +
- + + "Dxxx" where "xxx" identifies the recipient +
- + + network. +
- +-------------+----------------------------------------------------+
- + Hong Kong + Recipient network informs other networks about +
- + + ported-in numbers. Routing prefix is "14x" where +
- + + "14x" identifies the recipient network, or a +
- + + routing number of "4x" plus 7 or 8 digits is used +
- + + where "4x" identifies the recipient network and +
- + + the rest of digits identify the called party. +
- +-------------+----------------------------------------------------+
- + Ireland + Operators choose their own solution but use onward +
- + + routing now. Routing prefix is "1750" as the intra-+
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 18]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- + + network routing code (network-specific) and +
- + + "1752xxx" to "1759xxx" for GNP where "xxx" +
- + + identifies the recipient switch. +
- +-------------+----------------------------------------------------+
- + Italy + Uses onward routing. Routing prefix is "C600xxxxx" +
- + + where "xxxxx" identifies the recipient switch. +
- + + Telecom Italia uses IN solution and other operators+
- + + use on-switch solution. +
- +-------------+----------------------------------------------------+
- + Japan + Uses onward routing. Donor switch uses IN to get +
- + + routing number. +
- +-------------+----------------------------------------------------+
- + Mexico + NP is considered in the Telecom law; however, the +
- + + regulator (Cofetel) or the new local entrants have +
- + + started no initiatives on this process. +
- +-------------+----------------------------------------------------+
- + Netherlands + Operators decide NP scheme to use. Operators have +
- + + chosen ACQ or QoR. KPN implemented IN solution +
- + + similar to U.S. solution. Routing prefix is not +
- + + passed between operators. +
- +-------------+----------------------------------------------------+
- + Norway + OR for short-term and ACQ for long-term. QoR is +
- + + optional. Routing prefix can be "xxx" with NOA=8, +
- + + or "142xx" with NOA=3 where "xxx" or "xx" +
- + + identifies the recipient network. +
- +------------ +----------------------------------------------------+
- + Peru + Wireline NP may be supported in 2001. +
- +-------------+----------------------------------------------------+
- + Portugal + No NP today. +
- +-------------+----------------------------------------------------+
- + Spain + Uses ACQ. Telefonica uses QoR within its network. +
- + + Routing prefix is "xxyyzz" where "xxyyzz" +
- + + identifies the recipient network. NOA is set to +
- + + 126. +
- +-------------+----------------------------------------------------+
- + Sweden + Standardized the ACQ but OR for operators without +
- + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" +
- + + with NOA=3 where "xxx" identifies the recipient +
- + + network. But operators decide NP scheme to use. +
- + + Telia uses onward routing between operators. +
- +-------------+----------------------------------------------------+
- + Switzerland + Uses OR now and QoR in 2001. Routing prefix is +
- + + "980xxx" where "xxx" identifies the recipient +
- + + network. +
- +-------------+----------------------------------------------------+
- + UK + Uses onward routing. Routing prefix is "5xxxxx" +
- + + where "xxxxx" identifies the recipient switch. NOA +
- + + is 126. BT uses the dropback scheme in some parts +
- + + of its network. +
- +-------------+----------------------------------------------------+
- + US + Uses ACQ. "Location Routing Number (LRN)" is used +
- + + in the Called Party Number parameter. Called party+
- + + number is carried in the Generic Address Parameter +
- + + Use a PNTI indicator in the Forward Call Indicator +
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 19]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- + + parameter to indicate that NPDB dip has been +
- + + performed. +
- +-------------+----------------------------------------------------+
-
-
-8. Number Conservation Methods Enabled by NP
-
- In addition to porting numbers NP provides the ability for number
- administrators to assign numbering resources to operators in smaller
- increments. Today it is common for numbering resources to be
- assigned to telephone operators in a large block of consecutive
- telephone numbers (TNs). For example, in North America each of
- these blocks contains 10,000 TNs and is of the format NXX+0000 to
- NXX+9999. Operators are assigned a specific NXX, or block. That
- operator is referred to as the block holder. In that block there
- are 10,000 TNs with line numbers ranging from 0000 to 9999.
-
- Instead of assigning an entire block to the operator NP allows the
- administrator to assign a sub-block or even an individual telephone
- number. This is referred to as block pooling and individual
- telephone number (ITN) pooling, respectively.
-
-
-8.1 Block Pooling
-
- Block Pooling refers to the process whereby the number administrator
- assigns a range of numbers defined by a logical sub-block of the
- existing block. Using North America as an example, block pooling
- would allow the administrator to assign sub-blocks of 1,000 TNs to
- multiple operators. That is, NXX+0000 to NXX+0999 can be assigned
- to operator A, NXX+1000 to NXX+1999 can be assigned to operator B,
- NXX-2000 to 2999 can be assigned to operator C, etc. In this
- example block pooling divides one block of 10,000 TNs into ten
- blocks of 1,000 TNs.
-
- Porting the sub-blocks from the block holder enables block pooling.
- Using the example above operator A is the block holder, as well as,
- the holder of the first sub-block, NXX+0000 to NXX+0999. The second
- sub-block, NXX+1000 to NXX+1999, is ported from operator A to
- operator B. The third sub-block, NXX+2000 to NXX+2999, is ported
- from operator A to operator C, and so on. NP administrative
- processes and call processing will enable proper and efficient
- routing.
-
- From a number administration and NP administration perspective block
- pooling introduces a new concept, that of the sub-block holder.
- Block pooling requires coordination between the number
- administrator, the NP administrator, the block holder, and the sub-
- block holder. Block pooling must be implemented in a manner that
- allows for NP within the sub-blocks. Each TN can have a different
- serving operator, sub-block holder, and block holder.
-
-
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 20]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
-8.2 ITN Pooling
-
- ITN pooling refers to the process whereby the number administrator
- assigns individual telephone numbers to operators. Using the North
- American example, one block of 10,000 TNs can be divided into 10,000
- ITNs. ITN is more commonly deployed in freephone services.
-
- In ITN the block is not assigned to an operator but to a central
- administrator. The administrator then assigns ITNs to operators.
- NP administrative processes and call processing will enable proper
- and efficient routing.
-
-
-9. Potential Implications
-
- There are three general areas of impact to IP telephony work-in-
- progress at IETF:
-
- - Interoperation between NP in GSTN and IP telephony
- - NP implementation or emulation in IP telephony
- - Interconnection to NP administrative environment
-
- A good understanding of how number portability is supported in the
- GSTN is important when addressing the interworking issues between
- IP-based networks and the GSTN. This is especially important when
- the IP-based network needs to route the calls to the GSTN. As shown
- in Section 5, there are a variety of standards with various protocol
- stacks for the switch-to-NPDB interface. Not only that, the
- national variations of the protocol standards make it very
- complicated to deal with in a global environment. If an entity in
- the IP-based network needs to query those existing NPDBs for routing
- number information to terminate the calls to the destination GSTN,
- it would be impractical, if not an impossible, job for that entity
- to support all those interface standards to access the NPDBs in many
- countries.
-
- Several alternatives may address this particular problem. One
- alternative is to use certain entities in the IP-based networks for
- dealing with NP query, similar to the International Switches that
- are used in the GSTN to interwork different national ISUP
- variations. This will force signaling information associated with
- the calls to certain NP-capable networks in the terminating GSTN to
- be routed to those IP entities that support the NP functions. Those
- IP entities then query the NPDBs in the terminating country. This
- will limit the number of NPDB interfaces that certain IP entities
- need to support. Another alternative can be to define a "common"
- interface to be supported by all the NPDBs so that all the IP
- entities use that standardized protocol to query them. The
- existing NPDBs can support this additional interface, or new NPDBs
- can be deployed that contain the same information but support the
- common IP interface. The candidates for such a common interface
- include Lightweight Directory Access Protocol (LDAP) and SIP
- [SIP](e.g., using the SIP redirection capability). Certainly
-
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 21]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- another possibility is to use interworking function to convert from
- one protocol to another.
-
- IP-based networks can handle the domestic calls between two GSTNs.
- If the originating GSTN has performed NPDB query, SIP will need to
- transport and make use of some of the ISUP signaling information
- even if ISUP signaling may be encapsulated in SIP. Also, IP-based
- networks may perform the NPDB queries, as the N-1 carrier. In that
- case, SIP also needs to transport the NP related information while
- the call is being routed to the destination GSTN. There are three
- pieces of NP related information that SIP needs to transport. They
- are 1) the called directory number, 2) a routing number, and 3) a
- NPDB dip indicator. The NPDB dip indicator is needed so that the
- terminating GSTN will not perform another NPDB dip. The routing
- number is needed so that it is used to route the call to the
- destination network or switch in the destination GSTN. The called
- directory number is needed so that the terminating GSTN switch can
- terminate the call. When the routing number is present, the NPDB
- dip indicator may not be present because there are cases where
- routing number is added for routing the call even if NP is not
- involved. One issue is how to transport the NP related information
- via SIP. The SIP Universal Resource Locator (URL) is one mechanism.
- Another better choice may be to add an extension to the "tel" URL
- [TEL] that is also supported by SIP. Please see [TELNP] for the
- proposed extensions to the "tel" URL to support NP and freephone
- service. Those extensions to the "tel" URL will be automatically
- supported by SIP because they can be carried as the optional
- parameters in the user portion of the "sip" URL.
-
- For a called directory number that belongs to a country that
- supports NP, and if the IP-based network is to perform the NPDB
- query, the logical step is to perform the NPDB dip first to retrieve
- the routing number and use that routing number to select the correct
- IP telephony gateways that can reach the serving switch that serves
- the called directory number. Therefore, if the "rn" parameter is
- present in the "tel" URL or sip URL in the SIP INVITE message, it
- instead of the called directory number should be used for making
- routing decisions assuming that no other higher priority routing-
- related parameters such as the Ÿcic÷ are present. If "rn" is not
- present, then the dialed directory number can be used as the routing
- number for making routing decisions.
-
- Telephony Routing Information Protocol (TRIP) [TRIP] is a policy
- driven inter-administrative domain protocol for advertising the
- reachability of telephony destinations between location servers, and
- for advertising attributes of the routes to those destinations.
- With the NP in mind, it is very important to know that it is the
- routing number, if present, not the called directory number that
- should be used to check against the TRIP tables for making the
- routing decisions.
-
- Overlap signaling exists in the GSTN today. For a call routing from
- the originating GSTN to the IP-based network that involves overlap
- signaling, NP will impact the call processing within the IP-based
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 22]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- networks if they must deal with the overlap signaling. The entities
- in the IP-based networks that are to retrieve the NP information
- (e.g., the routing number) must collect a complete called directory
- number information before retrieving the NP information for a ported
- number. Otherwise, the information retrieval won't be successful.
- This is an issue for the IP-based networks if the originating GSTN
- does not handle the overlap signaling by collecting the complete
- called directory number.
-
- The IETF enum working group is defining the use of Domain Name
- System (DNS) for identifying available services associated with a
- particular E.164 number [ENUM]. [ENUMPO] outlines the principles
- for the operation of a telephone number service that resolves
- telephone numbers into Internet domain name addresses and service-
- specific directory discovery. [ENUMPO] implements a three-level
- approach where the first level is the mapping of the telephone
- number delegation tree to the authority to which the number has been
- delegated, the second level is the provision of the requested DNS
- resource records from a service registrar, and the third level is
- the provision of service specific data from the service provider
- itself. NP certainly must be considered at the first level because
- the telephony service providers do not "own" or control the
- telephone numbers under the NP environment; therefore, they may not
- be the proper entities to have the authority for a given E.164
- number. Not only that, there is a regulatory requirement on NP in
- some countries that the donor network should not be relied on to
- reach the delegated authority during the DNS process . The
- delegated authority for a given E.164 number is likely to be an
- entity designated by the end user that owns/controls a specific
- telephone number or one that is designated by the service registrar.
-
- Since the telephony service providers may have the need to use ENUM
- for their network-related services (e.g., map an E.164 number to a
- HLR Identifier in the wireless networks), their ENUM records must be
- collocated with those of the telephony subscribers. If that is the
- case, NP will impact ENUM when a telephony subscriber who has ENUM
- service changes the telephony service provider. This is because
- that the ENUM records from the new telephony service provider must
- replace those from the old telephony service provider. To avoid the
- NP impact on ENUM, it is recommended that the telephony service
- providers use a different domain tree for their network-related
- service. For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a
- domain tree different from e164.arpa should be used for Ÿcarrier÷
- ENUM.
-
- The IP-based networks also may need to support some forms of number
- portability in the future if E.164 numbers [E164] are assigned to
- the IP-based end users. One method is to assign a GSTN routing
- number for each IP-based network domain or entity in a NP-capable
- country. This may increase the number of digits in the routing
- number to incorporate the IP entities and impact the existing
- routing in the GSTN. Another method is to associate each IP entity
- with a particular GSTN gateway. At that particular GSTN gateway,
- the called directory number then is used to locate the IP-entity
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 23]
-
-Number Portability in the GSTN: An Overview June 24, 2002
-
- that serves that dialed directory number. Yet, another method can
- be to assign a special routing number so that the call to an end
- user currently served by an IP entity is routed to the nearest GSTN
- gateway. The called directory number then is used to locate the IP-
- entity that serves that dialed directory number. A mechanism can be
- developed or used for the IP-based network to locate the IP entity
- that serves a particular dialed directory number. Many other types
- of networks use E.164 numbers to identify the end users or terminals
- in those networks. Number portability among GSTN, IP-based network
- and those various types of networks may also need to be supported in
- the future.
-
-
-10. Security Considerations
-
- This document does not raise any security issues.
-
-
-11. IANA Considerations
-
- This document introduces no new values for IANA registration.
-
-
-12. Normative References
-
- [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability -
- Operator Services Switching Systems," April 1999.
-
- [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability -
- Switching Systems," April 1999.
-
- [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability
- Database and Global Title Translation," April 1999.
-
- [CS1] ITU-T Q-series Recommendations - Supplement 4, "Number
- portability Capability set 1 requirements for service provider
- portability (All call query and onward routing)," May 1998.
-
- [CS2] ITU-T Q-series Recommendations - Supplement 5, "Number
- portability -Capability set 2 requirements for service provider
- portability (Query on release and Dropback)," March 1999.
-
- [E164] ITU-T Recommendation E.164, "The International Public
- Telecommunications Numbering Plan," 1997.
-
- [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916.
-
- [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital
- Network (ISDN); Signalling System No.7 (SS7); ISDN User Part
- (ISUP); Enhancement for support of Number Portability (NP)
- [ITU-T Recommendation Q.769.1 (2000), modified]
-
- [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase
- 2+); Mobile Application Part (MAP) specification".
-
-Foster,McGarry,Yu Expired on December 23, 2002 [Page 24]
-
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
-
- [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for
- Wireless Number Portability Phase II (December 1998)"Number
- Portability Network Support," April 1998.
-
- [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 -
- ISDN User Part Enhancements for the Support of Number
- Portability," December 1999.
-
- [MNP] ETSI EN 301 716 (2000-10) European Standard
- (Telecommunications series) Digital cellular telecommunications
- system (Phase 2+); Support of Mobile Number Portability (MNP);
- Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0
- Release 1998).
-
- [RFC] Scott Bradner, RFC2026, "The Internet Standards Process --
- Revision 3," October 1996.
-
-
-13. Informative References
-
- [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific
- Provisioning: Principles of Operations," draft-ietf-enum-
- operation-02.txt, February 23, 2001.
-
- [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP:
- Session Initiation Protocol," February 27, 2002.
-
- [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis-
- 04.txt, "URIs for Telephone Calls," May 24, 2002.
-
- [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL
- to support Number Portability and Freephone Service," June 14,
- 2002.
-
- [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony
- Routing Information Protocol (TRIP)," January 2002.
-
-
-14. Acknowledgment
-
- The authors would like to thank Monika Muench for providing
- information on ISUP and MNP.
-
-
-15. Authors' Addresses
-
- Mark D. Foster
- NeuStar, Inc.
- 1120 Vermont Avenue, NW,
- Suite 400
- Washington, D.C. 20005
- United States
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 25]
-
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
-
- Phone: +1-202-533-2800
- Fax: +1-202-533-2987
- Email: mark.foster@neustar.biz
-
- Tom McGarry
- NeuStar, Inc.
- 1120 Vermont Avenue, NW,
- Suite 400
- Washington, D.C. 20005
- United States
-
- Phone: +1-202-533-2810
- Fax: +1-202-533-2987
- Email: tom.mcgarry@neustar.biz
-
- James Yu
- NeuStar, Inc.
- 1120 Vermont Avenue, NW,
- Suite 400
- Washington, D.C. 20005
- United States
-
- Phone: +1-202-533-2814
- Fax: +1-202-533-2987
- Email: james.yu@neustar.biz
-
-
-
-Full Copyright Statement
-
- "Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
-
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 26]
-
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 27]
- \ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt b/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt
deleted file mode 100644
index 423a119f39f8b..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt
+++ /dev/null
@@ -1,951 +0,0 @@
-
-
-IPSECKEY WG M. Richardson
-Internet-Draft SSW
-|Expires: August 1, 2004 February 2004
-
-
- A Method for Storing IPsec Keying Material in DNS
-| draft-ietf-ipseckey-rr-09.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 1, 2004.
-
-Copyright Notice
-
-| Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-| This document describes a new resource record for 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 establishing an IPsec
-| tunnel with the entity in question.
-
- This record replaces the functionality of the sub-type #1 of the KEY
- Resource Record, which has been obsoleted by RFC3445.
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 1]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-| 1.2 Use of reverse (in-addr.arpa) map . . . . . . . . . . . . . . 3
-| 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3
-| 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 5
-| 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5
-| 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5
-| 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . . 5
-| 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . . 6
-| 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6
-| 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 6
-| 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 8
-| 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 8
-| 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
-| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
-| 4.1 Active attacks against unsecured IPSECKEY resource records . . 10
-| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
-| 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 13
-| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
-| Normative references . . . . . . . . . . . . . . . . . . . . . 15
-| Non-normative references . . . . . . . . . . . . . . . . . . . 16
-| Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
-| Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 2]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-1. Introduction
-
- It postulated that there is an end system desiring to establish an
- IPsec tunnel with some remote entity on the network. This system,
- having only a DNS name of some kind (forward, reverse or even
- user@FQDN) needs a public key to authenticate the remote entity. It
- also desires some guidance about whether to contact the entity
- directly, or whether to contact another entity, as the gateway to
- that desired entity.
-
- The IPSECKEY RR provides a storage mechanism for such items as the
- public key, and the gateway information.
-
- The type number for the IPSECKEY RR is TBD.
-
-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) 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 RFC2119 [7].
-
-|1.2 Use of reverse (in-addr.arpa) map
-
-| Often a security gateway will only have access to the IP address to
-| which communication is desired. It will not know the forward name.
-| As such, it will frequently be the case that the IP address will be
-| used an index into the reverse map.
-
-| The lookup is done in the usual fashion as for PTR records. The IP
-| address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
-| under the .arpa. zone. Any CNAMEs or DNAMEs found SHOULD be
-| followed.
-
-| Note: even when the IPsec function is the end-host, often only the
-| application will know the forward name used. While 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
-
-
-
-|Richardson Expires August 1, 2004 [Page 3]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
- 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 the need to rollover keys.
-
- This resource record is class independent.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 4]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-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.
-
- 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. This is interpreted in
- the same way as the PREFERENCE field described in section 3.3.9 of
- RFC1035 [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 RFC1035 [2]).
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 5]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-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 RFC2536 [10]
-
- 2 A RSA key is present, in the format defined in RFC3110 [11]
-
-
-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 RFC1035
- [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 RFC3596
- [13]. 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 RFC1035 [2]. Compression MUST NOT be used.
-
-2.6 RDATA format - public keys
-
- Both of 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 of 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 RR.
-
- 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
-
-
-
-|Richardson Expires August 1, 2004 [Page 6]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
- for the corresponding algorithm. The algorithm must still be
- designated for use by IPSECKEY, and an IPSECKEY algorithm type number
- (which might be different than the DNSSEC algorithm number) must be
- assigned to it.
-
- The DSA key format is defined in RFC2536 [10]
-
- The RSA key format is defined in RFC3110 [11], with the following
- changes:
-
- The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
- modulus to 2552 bits in length. RFC3110 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 imposed by the two-
- octet length encoding. This length extension is applicable only to
- IPSECKEY and not to KEY RRs.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 7]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-3. Presentation formats
-
-3.1 Representation of IPSECKEY RRs
-
- IPSECKEY RRs may appear in a zone data master file. The precedence,
- gateway type and algorithm and gateway fields are REQUIRED. The
- base64 encoded public key block is OPTIONAL; if not present, then the
- public key field of the resource record MUST be construed as being
- 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 RFC3548 [6] Section 5.2.
-
- The general presentation for the record as 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== )
-
- 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== )
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 8]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
- 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== )
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 9]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-4. Security Considerations
-
- This entire memo pertains to the provision of public keying material
- for use by key management protocols such as ISAKMP/IKE (RFC2407) [8].
-
- 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 for defense
- against both active and passive attacks.
-
- Any derivative standard that makes use of this resource record MUST
- carefully document their trust model, and why the trust model of
- DNSSEC is appropriate, if that is the secure channel 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.
-
- The first kind of active attack is when the attacker replaces the
- keying material with either a key under its control or with garbage.
-
- If the attacker is not able to mount a subsequent man-in-the-middle
- attack on the IKE negotiation after replacing the public key, then
- this will result in a denial of service, as the authenticator used by
- IKE would fail.
-
- If the attacker is able to both to mount active attacks against DNS
- and is also in a position to perform a man-in-the-middle attack on
- IKE and IPsec negotiations, then the attacker will be in a position
- 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 in order for this to succeed.
-
- The second kind of active attack is one in which the attacker
- replaces the the gateway address to point to a node under the
- attacker's control. The attacker can then either replace the public
-
-
-
-|Richardson Expires August 1, 2004 [Page 10]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
- key or remove it, thus providing an IPSECKEY record of its own to
- match the gateway address.
-
- This later form creates a simple man-in-the-middle 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.
-
- Note that the man-in-the-middle can not 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 have already created a policy expecting ciphertext.
- Thus, the attacker will need to intercept traffic from both sides.
- In some cases, the attacker may be able to accomplish the full
- intercept by use of Network Addresss/Port Translation (NAT/NAPT)
- technology.
-
-| Note that risk of a man-in-the-middle attack mediated by the IPSECKEY
-| RR only applies to cases where the gateway field of the IPSECKEY RR
-| indicates a different entity than the owner name of the IPSECKEY RR.
-
-| An active attack on the DNS that caused the wrong IP address to be
-| retrieved (via forged A RR), and therefore the wrong QNAME to be
-| queried would also result in a man-in-the-middle attack. This
-| situation exists independantly of whether or not the IPSECKEY RR is
-| used.
-
-| In cases where 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 11]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-5. IANA Considerations
-
- This document updates the IANA Registry for DNS Resource Record Types
- by assigning type X 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.
-
- Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3
- through 255 can be assigned by IETF Consensus (see RFC2434 [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
- RFC2434 [5]).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 12]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-6. Intellectual Property Claims
-
- 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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 13]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-7. Acknowledgments
-
- My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
- Austein, and Olafur Gurmundsson who reviewed this document carefully.
- Additional thanks to Olafur Gurmundsson for a reference
- implementation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 14]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-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] Eastlake, 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 15]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-Non-normative references
-
- [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [8] Piper, D., "The Internet IP Security Domain of Interpretation
- for ISAKMP", RFC 2407, November 1998.
-
- [9] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
- (DNS)", RFC 2536, March 1999.
-
- [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
- [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record (RR)", RFC 3445, December 2002.
-
- [13] 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 Expires August 1, 2004 [Page 16]
-
-|Internet-Draft Storing IPsec keying material in DNS February 2004
-
-
-Full Copyright Statement
-
-| Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson Expires August 1, 2004 [Page 17]
diff --git a/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
deleted file mode 100644
index 2d5c87eb3caa8..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
+++ /dev/null
@@ -1,1200 +0,0 @@
-
-
-
-
-
-
-IPv6 Working Group John Loughney (ed)
-Internet-Draft Nokia
- January 14, 2004
-
-Expires: July 14, 2004
-
-
-
- IPv6 Node Requirements
- draft-ietf-ipv6-node-requirements-08.txt
-
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 (2003). All Rights Reserved.
-
-Abstract
-
- This document defines requirements for IPv6 nodes. It is expected
- that IPv6 will be deployed in a wide range of devices and situations.
- Specifying the requirements for IPv6 nodes allows IPv6 to function
- well and interoperate in a large number of situations and
- deployments.
-
-
-
-
-
-Loughney (editor) February 16, 2004 [Page 1]
-
-
-
-
-
-Internet-Draft
-
-
-Table of Contents
-
- 1. Introduction
- 1.1 Requirement Language
- 1.2 Scope of this Document
- 1.3 Description of IPv6 Nodes
- 2. Abbreviations Used in This Document
- 3. Sub-IP Layer
- 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
- 3.2 IP version 6 over PPP - RFC2472
- 3.3 IPv6 over ATM Networks - RFC2492
- 4. IP Layer
- 4.1 Internet Protocol Version 6 - RFC2460
- 4.2 Neighbor Discovery for IPv6 - RFC2461
- 4.3 Path MTU Discovery & Packet Size
- 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
- 4.5 Addressing
- 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
- 5. Transport and DNS
- 5.1 Transport Layer
- 5.2 DNS
- 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- 6. IPv4 Support and Transition
- 6.1 Transition Mechanisms
- 7. Mobility
- 8. Security
- 8.1 Basic Architecture
- 8.2 Security Protocols
- 8.3 Transforms and Algorithms
- 8.4 Key Management Methods
- 9. Router Functionality
- 9.1 General
- 10. Network Management
- 10.1 MIBs
- 11. Security Considerations
- 12. References
- 12.1 Normative
- 12.2 Non-Normative
- 13. Authors and Acknowledgements
- 14. Editor's Address
- Notices
-
-
-
-
-
-
-
-
-
-
-Loughney (editor) February 16, 2004 [Page 2]
-
-
-
-
-
-Internet-Draft
-
-
-1. Introduction
-
- The goal of this document is to define the common functionality
- required from both IPv6 hosts and routers. Many IPv6 nodes will
- implement optional or additional features, but all IPv6 nodes can be
- expected to implement the mandatory requirements listed in this
- document.
-
- This document tries to avoid discussion of protocol details, and
- references RFCs for this purpose. In case of any conflicting text,
- this document takes less precedence than the normative RFCs, unless
- additional clarifying text is included in this document.
-
- Although the document points to different specifications, it should
- be noted that in most cases, the granularity of requirements are
- smaller than a single specification, as many specifications define
- multiple, independent pieces, some of which may not be mandatory.
-
- As it is not always possible for an implementer to know the exact
- usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
- that they should adhere to Jon Postel's Robustness Principle:
-
- Be conservative in what you do, be liberal in what you accept from
- others [RFC-793].
-
-1.1 Requirement Language
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC-2119].
-
-1.2 Scope of this Document
-
- IPv6 covers many specifications. It is intended that IPv6 will be
- deployed in many different situations and environments. Therefore,
- it is important to develop the requirements for IPv6 nodes, in order
- to ensure interoperability.
-
- This document assumes that all IPv6 nodes meet the minimum
- requirements specified here.
-
-1.3 Description of IPv6 Nodes
-
- From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we
- have the following definitions:
-
- Description of an IPv6 Node
-
-
-
-
-Loughney (editor) February 16, 2004 [Page 3]
-
-
-
-
-
-Internet-Draft
-
-
- - a device that implements IPv6
-
- Description of an IPv6 router
-
- - a node that forwards IPv6 packets not explicitly addressed to
- itself.
-
- Description of an IPv6 Host
-
- - any node that is not a router.
-
-2. Abbreviations Used in This Document
-
- ATM Asynchronous Transfer Mode
-
- AH Authentication Header
-
- DAD Duplicate Address Detection
-
- ESP Encapsulating Security Payload
-
- ICMP Internet Control Message Protocol
-
- IKE Internet Key Exchange
-
- MIB Management Information Base
-
- MLD Multicast Listener Discovery
-
- MTU Maximum Transfer Unit
-
- NA Neighbor Advertisement
-
- NBMA Non-Broadcast Multiple Access
-
- ND Neighbor Discovery
-
- NS Neighbor Solicitation
-
- NUD Neighbor Unreachability Detection
-
- PPP Point-to-Point Protocol
-
- PVC Permanent Virtual Circuit
-
- SVC Switched Virtual Circuit
-
-3. Sub-IP Layer
-
-
-
-Loughney (editor) February 16, 2004 [Page 4]
-
-
-
-
-
-Internet-Draft
-
-
- An IPv6 node must include support for one or more IPv6 link-layer
- specifications. Which link-layer specifications are included will
- depend upon what link-layers are supported by the hardware available
- on the system. It is possible for a conformant IPv6 node to support
- IPv6 on some of its interfaces and not on others.
-
- As IPv6 is run over new layer 2 technologies, it is expected that new
- specifications will be issued. This section highlights some major
- layer 2 technologies and is not intended to be complete.
-
-3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
-
- Nodes supporting IPv6 over Ethernet interfaces MUST implement
- Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
-
-3.2 IP version 6 over PPP - RFC2472
-
- Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-
- 2472].
-
-3.3 IPv6 over ATM Networks - RFC2492
-
- Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
- Networks [RFC-2492]. Additionally, RFC 2492 states:
-
- A minimally conforming IPv6/ATM driver SHALL support the PVC mode
- of operation. An IPv6/ATM driver that supports the full SVC mode
- SHALL also support PVC mode of operation.
-
-4. IP Layer
-
-4.1 Internet Protocol Version 6 - RFC2460
-
- The Internet Protocol Version 6 is specified in [RFC-2460]. This
- specification MUST be supported.
-
- Unrecognized options in Hop-by-Hop Options or Destination Options
- extensions MUST be processed as described in RFC 2460.
-
- The node MUST follow the packet transmission rules in RFC 2460.
-
- Nodes MUST always be able to send, receive and process fragment
- headers. All conformant IPv6 implementations MUST be capable of
- sending and receving IPv6 packets; forwarding functionality MAY be
- supported
-
- RFC 2460 specifies extension headers and the processing for these
- headers.
-
-
-
-Loughney (editor) February 16, 2004 [Page 5]
-
-
-
-
-
-Internet-Draft
-
-
- A full implementation of IPv6 includes implementation of the
- following extension headers: Hop-by-Hop Options, Routing (Type 0),
- Fragment, Destination Options, Authentication and Encapsulating
- Security Payload. [RFC-2460]
-
- An IPv6 node MUST be able to process these headers. It should be
- noted that there is some discussion about the use of Routing Headers
- and possible security threats [IPv6-RH] caused by them.
-
-4.2 Neighbor Discovery for IPv6 - RFC2461
-
- Neighbor Discovery SHOULD be supported. RFC 2461 states:
-
- "Unless specified otherwise (in a document that covers operating
- IP over a particular link type) this document applies to all link
- types. However, because ND uses link-layer multicast for some of
- its services, it is possible that on some link types (e.g., NBMA
- links) alternative protocols or mechanisms to implement those
- services will be specified (in the appropriate document covering
- the operation of IP over a particular link type). The services
- described in this document that are not directly dependent on
- multicast, such as Redirects, Next-hop determination, Neighbor
- Unreachability Detection, etc., are expected to be provided as
- specified in this document. The details of how one uses ND on
- NBMA links is an area for further study."
-
- Some detailed analysis of Neighbor Discovery follows:
-
- Router Discovery is how hosts locate routers that reside on an
- attached link. Router Discovery MUST be supported for
- implementations.
-
- Prefix Discovery is how hosts discover the set of address prefixes
- that define which destinations are on-link for an attached link.
- Prefix discovery MUST be supported for implementations. Neighbor
- Unreachability Detection (NUD) MUST be supported for all paths
- between hosts and neighboring nodes. It is not required for paths
- between routers. However, when a node receives a unicast Neighbor
- Solicitation (NS) message (that may be a NUD's NS), the node MUST
- respond to it (i.e. send a unicast Neighbor Advertisement).
-
- Duplicate Address Detection MUST be supported on all links supporting
- link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take
- place on all unicast addresses).
-
- A host implementation MUST support sending Router Solicitations.
-
- Receiving and processing Router Advertisements MUST be supported for
-
-
-
-Loughney (editor) February 16, 2004 [Page 6]
-
-
-
-
-
-Internet-Draft
-
-
- host implementations. The ability to understand specific Router
- Advertisement options is dependent on supporting the specification
- where the RA is specified.
-
- Sending and Receiving Neighbor Solicitation (NS) and Neighbor
- Advertisement (NA) MUST be supported. NS and NA messages are required
- for Duplicate Address Detection (DAD).
-
- Redirect functionality SHOULD be supported. If the node is a router,
- Redirect functionality MUST be supported.
-
-4.3 Path MTU Discovery & Packet Size
-
-4.3.1 Path MTU Discovery - RFC1981
-
- Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
- implementations MAY choose to not support it and avoid large packets.
- The rules in RFC 2460 MUST be followed for packet fragmentation and
- reassembly.
-
-4.3.2 IPv6 Jumbograms - RFC2675
-
- IPv6 Jumbograms [RFC-2675] MAY be supported.
-
-4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
-
- ICMPv6 [RFC-2463] MUST be supported.
-
-4.5 Addressing
-
-4.5.1 IP Version 6 Addressing Architecture - RFC3513
-
- The IPv6 Addressing Architecture [RFC-3513] MUST be supported.
-
-4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462
-
- IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
- This specification MUST be supported for nodes that are hosts.
-
- Nodes that are routers MUST be able to generate link local addresses
- as described in RFC 2462 [RFC-2462].
-
- From 2462:
-
- The autoconfiguration process specified in this document applies
- only to hosts and not routers. Since host autoconfiguration uses
- information advertised by routers, routers will need to be
- configured by some other means. However, it is expected that
-
-
-
-Loughney (editor) February 16, 2004 [Page 7]
-
-
-
-
-
-Internet-Draft
-
-
- routers will generate link-local addresses using the mechanism
- described in this document. In addition, routers are expected to
- successfully pass the Duplicate Address Detection procedure
- described in this document on all addresses prior to assigning
- them to an interface.
-
- Duplicate Address Detection (DAD) MUST be supported.
-
-4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041
-
- Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
- SHOULD be supported. It is recommended that this behavior be
- configurable on a connection basis within each application when
- available. It is noted that a number of applications do not work
- with addresses generated with this method, while other applications
- work quite well with them.
-
-4.5.4 Default Address Selection for IPv6 - RFC3484
-
- The rules specified in the Default Address Selection for IPv6 [RFC-
- 3484] document MUST be implemented. It is expected that IPv6 nodes
- will need to deal with multiple addresses.
-
-4.5.5 Stateful Address Autoconfiguration
-
- Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
- 3315] is the standard stateful address configuration protocol; see
- section 5.3 for DHCPv6 support.
-
- Nodes which do not support Stateful Address Autoconfiguration may be
- unable to obtain any IPv6 addresses aside from link-local addresses
- when it receives a router advertisement with the 'M' flag (Managed
- address configuration) set and which contains no prefixes advertised
- for Stateless Address Autoconfiguration (see section 4.5.2).
- Additionally, such nodes will be unable to obtain other configuration
- information such as the addresses of DNS servers when it is connected
- to a link over which the node receives a router advertisement in
- which the 'O' flag ("Other stateful configuration") is set.
-
-4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
-
- Nodes that need to join multicast groups SHOULD implement MLDv2
- [MLDv2]. However, if the node has applications, which only need
- support for Any- Source Multicast [RFC3569], the node MAY implement
- MLDv1 [MLDv1] instead. If the node has applications, which need
- support for Source- Specific Multicast [RFC3569, SSMARCH], the node
- MUST support MLDv2 [MLDv2].
-
-
-
-
-Loughney (editor) February 16, 2004 [Page 8]
-
-
-
-
-
-Internet-Draft
-
-
- When MLD is used, the rules in "Source Address Selection for the
- Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
- followed.
-
-5. Transport Layer and DNS
-
-5.1 Transport Layer
-
-5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147
-
- This specification MUST be supported if jumbograms are implemented
- [RFC- 2675].
-
-5.2 DNS
-
- DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
- and [RFC-3596] MAY be supported. Not all nodes will need to resolve
- names. All nodes that need to resolve names SHOULD implement stub-
- resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
- support for:
-
- - AAAA type Resource Records [RFC-3596];
- - reverse addressing in ip6.arpa using PTR records [RFC-3152];
- - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
- octets.
-
- Those nodes are RECOMMENDED to support DNS security extentions
- [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT].
-
- Those nodes are NOT RECOMMENDED to support the experimental A6 and
- DNAME Resource Records [RFC-3363].
-
-5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732
-
- RFC 2732 MUST be supported if applications on the node use URL's.
-
-5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315
-
-5.3.1 Managed Address Configuration
-
- Those IPv6 Nodes that use DHCP for address assignment initiate DHCP
- to obtain IPv6 addresses and other configuration information upon
- receipt of a Router Advertisement with the 'M' flag set, as described
- in section 5.5.3 of RFC 2462. In addition, in the absence of a
- router, those IPv6 Nodes that use DHCP for address assignment MUST
- initiate DHCP to obtain IPv6 addresses and other configuration
- information, as described in section 5.5.2 of RFC 2462. Those IPv6
- nodes that do not use DHCP for address assignment can ignore the 'M'
-
-
-
-Loughney (editor) February 16, 2004 [Page 9]
-
-
-
-
-
-Internet-Draft
-
-
- flag in Router Advertisements.
-
-5.3.2 Other Configuration Information
-
- Those IPv6 Nodes that use DHCP to obtain other configuration
- information initiate DHCP for other configuration information upon
- receipt of a Router Advertisement with the 'O' flag set, as described
- in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP
- for other configuration information can ignore the 'O' flag in Router
- Advertisements.
-
- An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to
- obtain other configuration information.
-
-6. IPv4 Support and Transition
-
- IPv6 nodes MAY support IPv4.
-
-6.1 Transition Mechanisms
-
-6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893
-
- If an IPv6 node implements dual stack and tunneling, then RFC2893
- MUST be supported.
-
- RFC 2893 is currently being updated.
-
-7. Mobile IP
-
- The Mobile IPv6 [MIPv6] specification defines requirements for the
- following types of nodes:
-
- - mobile nodes
- - correspondent nodes with support for route optimization
- - home agents
- - all IPv6 routers
-
- Hosts MAY support mobile node functionality described in Section 8.5
- of [MIPv6], including support of generic packet tunneling [RFC-2473]
- and secure home agent communications [MIPv6-HASEC].
-
- Hosts SHOULD support route optimization requirements for
- correspondent nodes described in Section 8.2 of [MIPv6].
-
- Routers SHOULD support the generic mobility-related requirements for
- all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY
- support the home agent functionality described in Section 8.4 of
- [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC].
-
-
-
-Loughney (editor) February 16, 2004 [Page 10]
-
-
-
-
-
-Internet-Draft
-
-
-8. Security
-
- This section describes the specification of IPsec for the IPv6 node.
-
-8.1 Basic Architecture
-
- Security Architecture for the Internet Protocol [RFC-2401] MUST be
- supported. RFC-2401 is being updated by the IPsec Working Group.
-
-8.2 Security Protocols
-
- ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported.
- RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group.
-
-
-8.3 Transforms and Algorithms
-
- Current IPsec RFCs specify the support of certain transforms and
- algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96.
- The requirements for these are discussed first, and then additional
- algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed.
-
- NULL encryption algorithm [RFC-2410] MUST be supported for providing
- integrity service and also for debugging use.
-
- The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD
- NOT be supported. Security issues related to the use of DES are
- discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as
- required by the existing IPsec RFCs, but as it is currently viewed as
- an inherently weak algorithm, and no longer fulfills its intended
- role.
-
- The NULL authentication algorithm [RFC-2406] MUST be supported within
- ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC-
- 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP,
- described in [RFC-2403] MUST be supported. An implementer MUST refer
- to Keyed- Hashing for Message Authentication [RFC-2104].
-
- 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
- and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES-
- CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected
- to be a widely available, secure algorithm that is required for
- interoperability. It is not required by the current IPsec RFCs, but
- is expected to become required in the future.
-
- In addition to the above requirements, "Cryptographic Algorithm
- Implementation Requirements For ESP And AH" [CRYPTREQ] contains the
- current set of mandatory to implement algorithms for ESP and AH as
-
-
-
-Loughney (editor) February 16, 2004 [Page 11]
-
-
-
-
-
-Internet-Draft
-
-
- well as specifying algorithms that should be implemented because they
- may be promoted to mandatory at some future time. It is RECOMMENDED
- that IPv6 nodes conform to the requirements in this document.
-
-8.4 Key Management Methods
-
- Manual keying MUST be supported.
-
- IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
- traffic. Where key refresh, anti-replay features of AH and ESP, or
- on- demand creation of Security Associations (SAs) is required,
- automated keying MUST be supported. Note that the IPsec WG is working
- on the successor to IKE [IKE2]. Key management methods for multicast
- traffic are also being worked on by the MSEC WG.
-
- "Cryptographic Algorithms for use in the Internet Key Exchange
- Version 2" [IKEv2ALGO] defines the current set of mandatory to
- implement algorithms for use of IKEv2 as well as specifying
- algorithms that should be implemented because they made be promoted
- to mandatory at some future time. It is RECOMMENDED that IPv6 nodes
- implementing IKEv2 conform to the requirements in this
- document.
-
-9. Router-Specific Functionality
-
- This section defines general host considerations for IPv6 nodes that
- act as routers. Currently, this section does not discuss routing-
- specific requirements.
-
-9.1 General
-
-9.1.1 IPv6 Router Alert Option - RFC2711
-
-
- The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
- Hop Header that is used in conjunction with some protocols (e.g.,
- RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will
- need to be implemented whenever protocols that mandate its usage are
- implemented. See Section 4.6.
-
-9.1.2 Neighbor Discovery for IPv6 - RFC2461
-
- Sending Router Advertisements and processing Router Solicitation MUST
- be supported.
-
-10. Network Management
-
- Network Management MAY be supported by IPv6 nodes. However, for IPv6
-
-
-
-Loughney (editor) February 16, 2004 [Page 12]
-
-
-
-
-
-Internet-Draft
-
-
- nodes that are embedded devices, network management may be the only
- possibility to control these nodes.
-
-10.1 Management Information Base Modules (MIBs)
-
- The following two MIBs SHOULD be supported by nodes that support an
- SNMP agent.
-
-10.1.1 IP Forwarding Table MIB
-
- IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes
- that support an SNMP agent.
-
-10.1.2 Management Information Base for the Internet Protocol (IP)
-
- IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an
- SNMP agent.
-
-11. Security Considerations
-
- This draft does not affect the security of the Internet, but
- implementations of IPv6 are expected to support a minimum set of
- security features to ensure security on the Internet. "IP Security
- Document Roadmap" [RFC-2411] is important for everyone to read.
-
- The security considerations in RFC2460 describe the following:
-
- The security features of IPv6 are described in the Security
- Architecture for the Internet Protocol [RFC-2401].
-
-12. References
-
-12.1 Normative
-
- [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa-
- tion Requirements For ESP And AH", draft-ietf-ipsec-
- esp-ah-algorithms-01.txt, January 2004.
-
- [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the
- Internet Key Exchange Version 2", draft-ietf-ipsec-
- ikev2-algorithms-04.txt, Work in Progress.
-
- [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6
- Service", draft- ietf-dhc-dhcpv6-stateless-00.txt,
- Work in Progress.
-
- [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support
- in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in
-
-
-
-Loughney (editor) February 16, 2004 [Page 13]
-
-
-
-
-
-Internet-Draft
-
-
- progress.
-
- [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec
- to Protect Mobile IPv6 Signaling between Mobile Nodes
- and Home Agents", draft-ietf- mobileip-mipv6-ha-
- ipsec-06.txt, Work in Progress.
-
- [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version
- 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in
- Progress.
-
- [RFC-1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU
- Discovery for IP version 6", RFC 1981, August 1996.
-
- [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table
- MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in
- Progress.
-
- [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the
- Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-
- update-07.txt, Work in progress.
-
- [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "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-2401] Kent, S. and Atkinson, R., "Security Architecture for
- the Internet Protocol", RFC 2401, November 1998.
-
- [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication
- Header", RFC 2402, November 1998.
-
- [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within
- ESP and AH", RFC 2403, November 1998.
-
- [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
- within ESP and AH", RFC 2404, November 1998.
-
- [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
- Algorithm With Explicit IV", RFC 2405, November 1998.
-
- [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security
-
-
-
-Loughney (editor) February 16, 2004 [Page 14]
-
-
-
-
-
-Internet-Draft
-
-
- Protocol (ESP)", RFC 2406, November 1998.
-
- [RFC-2407] Piper, D., "The Internet IP Security Domain of
- Interpretation for ISAKMP", RFC 2407, November 1998.
-
- [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner,
- J., "Internet Security Association and Key Management
- Protocol (ISAKMP)", RFC 2408, November 1998.
-
- [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key
- Exchange (IKE)", RFC 2409, November 1998.
-
- [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm
- and Its Use With IPsec", RFC 2410, November 1998.
-
- [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
- Algorithms", RFC 2451, November 1998.
-
- [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver-
- sion 6 (IPv6) Specification", RFC 2460, December 1998.
-
- [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor
- Discovery for IP Version 6 (IPv6)", RFC 2461, December
- 1998.
-
- [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address
- Autoconfiguration", RFC 2462.
-
- [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro-
- tocol Version 6 (IPv6)", RFC 2463, December 1998.
-
- [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
- 2472, December 1998.
-
- [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling
- in IPv6 Specification", RFC 2473, December 1998. Xxx
- add
-
- [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast
- Listener Discovery (MLD) for IPv6", RFC 2710, October
- 1999.
-
- [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert
- Option", RFC 2711, October 1999.
-
-
-
-
-Loughney (editor) February 16, 2004 [Page 15]
-
-
-
-
-
-Internet-Draft
-
-
- [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for
- Stateless Address Autoconfiguration in IPv6", RFC
- 3041, January 2001.
-
- [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August
- 2001.
-
- [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol
- for IPv6 (DHCPv6)", RFC 3315, July 2003.
-
- [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver-
- sion 6 (IPv6) Addresses in the Domain Name System
- (DNS)", RFC 3363, August 2002.
-
- [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC
- 3484, February 2003.
-
- [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing
- Architecture", RFC 3513, April 2003.
-
- [RFC-3590] Haberman, B., "Source Address Selection for the Multi-
- cast Listener Discovery (MLD) Protocol", RFC 3590,
- September 2003.
-
- [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP
- version 6", RFC 3596, October 2003.
-
- [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use
- with IPsec", RFC 3602, September 2003.
-
-12.2 Non-Normative
-
- [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast",
- draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in
- Progress.
-
- [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of
- DES-like cryptosystems", Journal of Cryptology Vol 4, Jan
- 1991.
-
- [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
-
- [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without
- Strong Integrity", Proceedings of the 32nd IETF, Danvers,
- MA, April 1995.
-
- [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser-
- vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in
-
-
-
-Loughney (editor) February 16, 2004 [Page 16]
-
-
-
-
-
-Internet-Draft
-
-
- Progress.
-
- [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
- S., "DNS Security Introduction and Requirements" draft-
- ietf-dnsext-dnssec-intro- 06.txt, Work in Progress.
-
- [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
- S., "Resource Records for the DNS Security Extensions",
- draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro-
- gress.
-
- [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
- S., "Protocol Modifications for the DNS Security Exten-
- sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work
- in Progress.
-
- [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto-
- col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress.
-
- [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home
- Address Options", draft-savola-ipv6-rh-ha-security-
- 03.txt, Work in Progress, March 2002.
-
- [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu-
- rity Threats and Counter-Measures; In Proceedings "Sympo-
- sium on Network and Distributed System Security", Febru-
- ary 1995, pp.2-16.
-
- [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793,
- August 1980.
-
- [RFC-1034] Mockapetris, P., "Domain names - concepts and facili-
- ties", RFC 1034, November 1987.
-
- [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147,
- May 1997.
-
- [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and
- S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC
- 2205, September 1997.
-
- [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
- Networks", RFC 2462, December 1998.
-
- [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over
- ATM Networks", RFC 2492, January 1999.
-
- [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6
-
-
-
-Loughney (editor) February 16, 2004 [Page 17]
-
-
-
-
-
-Internet-Draft
-
-
- Jumbograms", RFC 2675, August 1999.
-
- [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
- IPv6 Addresses in URL's", RFC 2732, December 1999.
-
- [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
- "Textual Conventions for Internet Network Addresses", RFC
- 2851, June 2000.
-
- [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for
- IPv6 Hosts and Routers", RFC 2893, August 2000.
-
- [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific
- Multicast (SSM)", RFC 3569, July 2003.
-
- [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
- draft-ietf- ssm-arch-03.txt, Work in Progress.
-
-13. Authors and Acknowledgements
-
- This document was written by the IPv6 Node Requirements design team:
-
- Jari Arkko
- [jari.arkko@ericsson.com]
-
- Marc Blanchet
- [marc.blanchet@viagenie.qc.ca]
-
- Samita Chakrabarti
- [samita.chakrabarti@eng.sun.com]
-
- Alain Durand
- [alain.durand@sun.com]
-
- Gerard Gastaud
- [gerard.gastaud@alcatel.fr]
-
- Jun-ichiro itojun Hagino
- [itojun@iijlab.net]
-
- Atsushi Inoue
- [inoue@isl.rdc.toshiba.co.jp]
-
- Masahiro Ishiyama
- [masahiro@isl.rdc.toshiba.co.jp]
-
- John Loughney
- [john.loughney@nokia.com]
-
-
-
-Loughney (editor) February 16, 2004 [Page 18]
-
-
-
-
-
-Internet-Draft
-
-
- Rajiv Raghunarayan
- [raraghun@cisco.com]
-
- Shoichi Sakane
- [shouichi.sakane@jp.yokogawa.com]
-
- Dave Thaler
- [dthaler@windows.microsoft.com]
-
- Juha Wiljakka
- [juha.wiljakka@Nokia.com]
-
- The authors would like to thank Ran Atkinson, Jim Bound, Brian Car-
- penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten,
- Juha Ollila and Pekka Savola for their comments.
-
-14. Editor's Contact Information
-
- Comments or questions regarding this document should be sent to the
- IPv6 Working Group mailing list (ipv6@ietf.org) or to:
-
- John Loughney
- Nokia Research Center
- Itamerenkatu 11-13
- 00180 Helsinki
- Finland
-
- Phone: +358 50 483 6242
- Email: John.Loughney@Nokia.com
-
-Notices
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to per-
- tain 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 standards-track and standards-
- related documentation can be found in BCP-11. Copies of claims of
- rights made available for publication 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 implementors or users of this specification can be obtained from
- the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
-
-
-
-Loughney (editor) February 16, 2004 [Page 19]
-
-
-
-
-
-Internet-Draft
-
-
- rights, which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Loughney (editor) February 16, 2004 [Page 20]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt b/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt
deleted file mode 100644
index a272d81b0a608..0000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt
+++ /dev/null
@@ -1,614 +0,0 @@
-Secure Shell Working Group J. Schlyter
-Internet-Draft OpenSSH
-Expires: March 5, 2004 W. Griffin
- SPARTA
- September 5, 2003
-
-
- Using DNS to Securely Publish SSH Key Fingerprints
- draft-ietf-secsh-dns-05.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 5, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document describes a method to verify SSH host keys using
- DNSSEC. The document defines a new DNS resource record that contains
- a standard SSH key fingerprint.
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 1]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3
- 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3
- 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4
- 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4
- 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5
- 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5
- 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5
- 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6
- 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
- Normative References . . . . . . . . . . . . . . . . . . . . 8
- Informational References . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
- A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 2]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
-1. Introduction
-
- The SSH [6] protocol provides secure remote login and other secure
- network services over an insecure network. The security of the
- connection relies on the server authenticating itself to the client
- as well as the user authenticating itself to the server.
-
- If a connection is established to a server whose public key is not
- already known to the client, a fingerprint of the key is presented to
- the user for verification. If the user decides that the fingerprint
- is correct and accepts the key, the key is saved locally and used for
- verification for all following connections. While some
- security-conscious users verify the fingerprint out-of-band before
- accepting the key, many users blindly accept the presented key.
-
- The method described here can provide out-of-band verification by
- looking up a fingerprint of the server public key in the DNS [1][2]
- and using DNSSEC [5] to verify the lookup.
-
- In order to distribute the fingerprint using DNS, this document
- defines a new DNS resource record, "SSHFP", to carry the fingerprint.
-
- Basic understanding of the DNS system [1][2] and the DNS security
- extensions [5] is assumed by 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 [3].
-
-2. SSH Host Key Verification
-
-2.1 Method
-
- Upon connection to a SSH server, the SSH client MAY look up the SSHFP
- resource record(s) for the host it is connecting to. If the
- algorithm and fingerprint of the key received from the SSH server
- match the algorithm and fingerprint of one of the SSHFP resource
- record(s) returned from DNS, the client MAY accept the identity of
- the server.
-
-2.2 Implementation Notes
-
- Client implementors SHOULD provide a configurable policy used to
- select the order of methods used to verify a host key. This document
- defines one method: Fingerprint storage in DNS. Another method
- defined in the SSH Architecture [6] uses local files to store keys
- for comparison. Other methods that could be defined in the future
- might include storing fingerprints in LDAP or other databases. A
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 3]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
- configurable policy will allow administrators to determine which
- methods they want to use and in what order the methods should be
- prioritized. This will allow administrators to determine how much
- trust they want to place in the different methods.
-
- One specific scenario for having a configurable policy is where
- clients do not use fully qualified host names to connect to servers.
- In this scenario, the implementation SHOULD verify the host key
- against a local database before verifying the key via the fingerprint
- returned from DNS. This would help prevent an attacker from injecting
- a DNS search path into the local resolver and forcing the client to
- connect to a different host.
-
-2.3 Fingerprint Matching
-
- The public key and the SSHFP resource record are matched together by
- comparing algorithm number and fingerprint.
-
- The public key algorithm and the SSHFP algorithm number MUST
- match.
-
- A message digest of the public key, using the message digest
- algorithm specified in the SSHFP fingerprint type, MUST match the
- SSHFP fingerprint.
-
-
-2.4 Authentication
-
- A public key verified using this method MUST NOT be trusted if the
- SSHFP resource record (RR) used for verification was not
- authenticated by a trusted SIG RR.
-
- Clients that do validate the DNSSEC signatures themselves SHOULD use
- standard DNSSEC validation procedures.
-
- Clients that do not validate the DNSSEC signatures themselves MUST
- use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
- between themselves and the entity performing the signature
- validation.
-
-3. The SSHFP Resource Record
-
- The SSHFP resource record (RR) is used to store a fingerprint of a
- SSH public host key that is associated with a Domain Name System
- (DNS) name.
-
- The RR type code for the SSHFP RR is TBA.
-
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 4]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
-3.1 The SSHFP RDATA Format
-
- The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
- type and the fingerprint of the public host key.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | algorithm | fp type | /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
- / /
- / fingerprint /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1.1 Algorithm Number Specification
-
- This algorithm number octet describes the algorithm of the public
- key. The following values are assigned:
-
- Value Algorithm name
- ----- --------------
- 0 reserved
- 1 RSA
- 2 DSS
-
- Reserving other types requires IETF consensus [4].
-
-3.1.2 Fingerprint Type Specification
-
- The fingerprint type octet describes the message-digest algorithm
- used to calculate the fingerprint of the public key. The following
- values are assigned:
-
- Value Fingerprint type
- ----- ----------------
- 0 reserved
- 1 SHA-1
-
- Reserving other types requires IETF consensus [4].
-
- For interoperability reasons, as few fingerprint types as possible
- should be reserved. The only reason to reserve additional types is
- to increase security.
-
-3.1.3 Fingerprint
-
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 5]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
- The fingerprint is calculated over the public key blob as described
- in [7].
-
- The message-digest algorithm is presumed to produce an opaque octet
- string output which is placed as-is in the RDATA fingerprint field.
-
-3.2 Presentation Format of the SSHFP RR
-
- The RDATA of the presentation format of the SSHFP resource record
- consists of two numbers (algorithm and fingerprint type) followed by
- the fingerprint itself presented in hex, e.g:
-
- host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
- The use of mnemonics instead of numbers is not allowed.
-
-4. Security Considerations
-
- Currently, the amount of trust a user can realistically place in a
- server key is proportional to the amount of attention paid to
- verifying that the public key presented actually corresponds to the
- private key of the server. If a user accepts a key without verifying
- the fingerprint with something learned through a secured channel, the
- connection is vulnerable to a man-in-the-middle attack.
-
- The overall security of using SSHFP for SSH host key verification is
- dependent on the security policies of the SSH host administrator and
- DNS zone administrator (in transferring the fingerprint), detailed
- aspects of how verification is done in the SSH implementation, and in
- the client's diligence in accessing the DNS in a secure manner.
-
- One such aspect is in which order fingerprints are looked up (e.g.
- first checking local file and then SSHFP). We note that in addition
- to protecting the first-time transfer of host keys, SSHFP can
- optionally be used for stronger host key protection.
-
- If SSHFP is checked first, new SSH host keys may be distributed by
- replacing the corresponding SSHFP in DNS.
-
- If SSH host key verification can be configured to require SSHFP,
- SSH host key revocation can be implemented by removing the
- corresponding SSHFP from DNS.
-
- As stated in Section 2.2, we recommend that SSH implementors provide
- a policy mechanism to control the order of methods used for host key
- verification. One specific scenario for having a configurable policy
- is where clients use unqualified host names to connect to servers. In
- this case, we recommend that SSH implementations check the host key
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 6]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
- against a local database before verifying the key via the fingerprint
- returned from DNS. This would help prevent an attacker from injecting
- a DNS search path into the local resolver and forcing the client to
- connect to a different host.
-
- A different approach to solve the DNS search path issue would be for
- clients to use a trusted DNS search path, i.e., one not acquired
- through DHCP or other autoconfiguration mechanisms. Since there is no
- way with current DNS lookup APIs to tell whether a search path is
- from a trusted source, the entire client system would need to be
- configured with this trusted DNS search path.
-
- Another dependency is on the implementation of DNSSEC itself. As
- stated in Section 2.4, we mandate the use of secure methods for
- lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
- is especially important if SSHFP is to be used as a basis for host
- key rollover and/or revocation, as described above.
-
- Since DNSSEC only protects the integrity of the host key fingerprint
- after it is signed by the DNS zone administrator, the fingerprint
- must be transferred securely from the SSH host administrator to the
- DNS zone administrator. This could be done manually between the
- administrators or automatically using secure DNS dynamic update [11]
- between the SSH server and the nameserver. We note that this is no
- different from other key enrollment situations, e.g. a client sending
- a certificate request to a certificate authority for signing.
-
-5. IANA Considerations
-
- IANA needs to allocate a RR type code for SSHFP from the standard RR
- type space (type 44 requested).
-
- IANA needs to open a new registry for the SSHFP RR type for public
- key algorithms. Defined types are:
-
- 0 is reserved
- 1 is RSA
- 2 is DSA
-
- Adding new reservations requires IETF consensus [4].
-
- IANA needs to open a new registry for the SSHFP RR type for
- fingerprint types. Defined types are:
-
- 0 is reserved
- 1 is SHA-1
-
- Adding new reservations requires IETF consensus [4].
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 7]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
-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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
- [5] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
- Lehtinen, "SSH Protocol Architecture",
- draft-ietf-secsh-architecture-14 (work in progress), July 2003.
-
- [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
- Lehtinen, "SSH Transport Layer Protocol",
- draft-ietf-secsh-transport-16 (work in progress), July 2003.
-
-Informational References
-
- [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
- Roadmap", RFC 2411, November 1998.
-
- [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [10] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 8]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
-Authors' Addresses
-
- Jakob Schlyter
- OpenSSH
- 812 23rd Avenue SE
- Calgary, Alberta T2G 1N8
- Canada
-
- EMail: jakob@openssh.com
- URI: http://www.openssh.com/
-
-
- Wesley Griffin
- SPARTA
- 7075 Samuel Morse Drive
- Columbia, MD 21046
- USA
-
- EMail: wgriffin@sparta.com
- URI: http://www.sparta.com/
-
-Appendix A. Acknowledgements
-
- The authors gratefully acknowledge, in no particular order, the
- contributions of the following persons:
-
- Martin Fredriksson
-
- Olafur Gudmundsson
-
- Edward Lewis
-
- Bill Sommerfeld
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 9]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
-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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 10]
-
-Internet-Draft DNS and SSH Fingerprints September 2003
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires March 5, 2004 [Page 11]
-
diff --git a/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
deleted file mode 100644
index 3578d2a15eb86..0000000000000
--- a/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
+++ /dev/null
@@ -1,519 +0,0 @@
-
-Internet Draft Johan Ihren
-draft-ihren-dnsext-threshold-validation-00.txt Autonomica
-February 2003
-Expires in six months
-
-
- Threshold Validation:
-
- A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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
-
- This memo documents a proposal for a different method of validation
- for DNSSEC aware resolvers. The key change is that by changing from
- a model of one Key Signing Key, KSK, at a time to multiple KSKs it
- will be possible to increase the aggregated trust in the signed
- keys by leveraging from the trust associated with the different
- signees.
-
- By having multiple keys to chose from validating resolvers get the
- opportunity to use local policy to reflect actual trust in
- different keys. For instance, it is possible to trust a single,
- particular key ultimately, while requiring multiple valid
- signatures by less trusted keys for validation to succeed.
- Furthermore, with multiple KSKs there are additional redundancy
- benefits available since it is possible to roll over different KSKs
- at different times which may make rollover scenarios easier to
- manage.
-
-Contents
-
- 1. Terminology
- 2. Introduction and Background
-
- 3. Trust in DNSSEC Keys
- 3.1. Key Management, Split Keys and Trust Models
- 3.2. Trust Expansion: Authentication versus Authorization
-
- 4. Proposed Semantics for Signing the KEY Resource Record
- Set
- 4.1. Packet Size Considerations
-
- 5. Proposed Use of Multiple "Trusted Keys" in a Validating
- Resolver
- 5.1. Not All Possible KSKs Need to Be Trusted
- 5.2. Possible to do Threshold Validation
- 5.3. Not All Trusted Keys Will Be Available
-
- 6. Additional Benefits from Having Multiple KSKs
- 6.1. More Robust Key Rollovers
- 6.2. Evaluation of Multiple Key Distribution Mechanisms
-
- 7. Security Considerations
- 8. IANA Considerations.
- 9. References
- 9.1. Normative.
- 9.2. Informative.
- 10. Acknowledgments.
- 11. Authors' Address
-
-
-1. Terminology
-
- The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
- and "MAY" in this document are to be interpreted as described in
- RFC 2119.
-
- The term "zone" refers to the unit of administrative control in the
- Domain Name System. "Name server" denotes a DNS name server that is
- authoritative (i.e. knows all there is to know) for a DNS zone,
- typically the root zone. A "resolver", is a DNS "client", i.e. an
- entity that sends DNS queries to authoritative nameservers and
- interpret the results. A "validating resolver" is a resolver that
- attempts to perform DNSSEC validation on data it retrieves by doing
- DNS lookups.
-
-
-2. Introduction and Background
-
- From a protocol perspective there is no real difference between
- different keys in DNSSEC. They are all just keys. However, in
- actual use there is lots of difference. First and foremost, most
- DNSSEC keys have in-band verification. I.e. the keys are signed by
- some other key, and this other key is in its turn also signed by
- yet another key. This way a "chain of trust" is created. Such
- chains have to end in what is referred to as a "trusted key" for
- validation of DNS lookups to be possible.
-
- A "trusted key" is a the public part of a key that the resolver
- acquired by some other means than by looking it up in DNS. The
- trusted key has to be explicitly configured.
-
- A node in the DNS hierarchy that issues such out-of-band "trusted
- keys" is called a "security apex" and the trusted key for that apex
- is the ultimate source of trust for all DNS lookups within that
- entire subtree.
-
- DNSSEC is designed to be able to work with more than on security
- apex. These apexes will all share the problem of how to distribute
- their "trusted keys" in a way that provides validating resolvers
- confidence in the distributed keys.
-
- Maximizing that confidence is crucial to the usefulness of DNSSEC
- and this document tries to address this issue.
-
-
-3. Trust in DNSSEC Keys
-
- In the end the trust that a validating resolver will be able to put
- in a key that it cannot validate within DNSSEC will have to be a
- function of
-
- * trust in the key issuer, aka the KSK holder
-
- * trust in the distribution method
-
- * trust in extra, out-of-band verification
-
- The KSK holder needs to be trusted not to accidentally lose private
- keys in public places. Furthermore it needs to be trusted to
- perform correct identification of the ZSK holders in case they are
- separate from the KSK holder itself.
-
- The distribution mechanism can be more or less tamper-proof. If the
- key holder publishes the public key, or perhaps just a secure
- fingerprint of the key in a major newspaper it may be rather
- difficult to tamper with. A key acquired that way may be easier to
- trust than if it had just been downloaded from a web page.
-
- Out-of-band verification can for instance be the key being signed
- by a certificate issued by a known Certificate Authority that the
- resolver has reason to trust.
-
-3.1. Simplicity vs Trust
-
- The fewer keys that are in use the simpler the key management
- becomes. Therefore increasing the number of keys should only be
- considered when the complexity is not the major concern. A perfect
- example of this is the distinction between so called Key Signing
- Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
- overall complexity but simplifies real life operations and was an
- overall gain since operational simplification was considered to be
- a more crucial issue than the added complexity.
-
- In the case of a security apex there are additional issues to
- consider, among them
-
- * maximizing trust in the KSK received out-of-band
-
- * authenticating the legitimacy of the ZSKs used
-
- In some cases this will be easy, since the same entity will manage
- both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
- similar to a self-signed certificate). In some environments it will
- be possible to get the trusted key installed in the resolver end by
- decree (this would seem to be a likely method within corporate and
- government environments).
-
- In other cases, however, this will possibly not be sufficient. In
- the case of the root zone this is obvious, but there may well be
- other cases.
-
-3.2. Expanding the "Trust Base"
-
- For a security apex where the ZSKs and KSK are not held by the same
- entity the KSK will effectively authenticate the identity of
- whoever does real operational zone signing. The amount of trust
- that the data signed by a ZSK will get is directly dependent on
- whether the end resolver trusts the KSK or not, since the resolver
- has no OOB access to the public part of the ZSKs (for practical
- reasons).
-
- Since the KSK holder is distinct from the ZSK holder the obvious
- question is whether it would then be possible to further improve
- the situation by using multiple KSK holders and thereby expanding
- the trust base to the union of that available to each individual
- KSK holder. "Trust base" is an invented term intended to signify
- the aggregate of Internet resolvers that will eventually choose to
- trust a key issued by a particular KSK holder.
-
- A crucial issue when considering trust expansion through addition
- of multiple KSK holders is that the KSK holders are only used to
- authenticate the ZSKs used for signing the zone. I.e. the function
- performed by the KSK is basically:
-
- "This is indeed the official ZSK holder for this zone,
- I've verified this fact to the best of my abilitites."
-
- Which can be thought of as similar to the service of a public
- notary. I.e. the point with adding more KSK holders is to improve
- the public trust in data signed by the ZSK holders by improving the
- strength of available authentication.
-
- Therefore adding more KSK holders, each with their own trust base,
- is by definition a good thing. More authentication is not
- controversial. On the contrary, when it comes to authentication,
- the more the merrier.
-
-
-4. Proposed Semantics for Signing the KEY Resource Record Set
-
- In DNSSEC according to RFC2535 all KEY Resource Records are used to
- sign all authoritative data in the zone, including the KEY RRset
- itself, since RFC2535 makes no distinction between Key Signing
- Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS]
- it is possible to change this to the KEY RRset being signed with
- all KSKs and ZSKs but the rest of the zone only being signed by the
- ZSKs.
-
- This proposal changes this one step further, by recommending that
- the KEY RRset is only signed by the Key Signing Keys, KSK, and
- explicitly not by the Zone Signing Keys, ZSK. The reason for this
- is to maximize the amount of space in the DNS response packet that
- is available for additional KSKs and signatures thereof. The rest
- of the authoritative zone contents are as previously signed by only
- the ZSKs.
-
-4.1. Packet Size Considerations
-
- The reason for the change is to keep down the size of the aggregate
- of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
- perform validation of data below a security apex. For DNSSEC data
- to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
- set, and therefore the allowed packet size can be assumed to be at
- least the EDNS0 minimum of 4000 bytes.
-
- When querying for KEY + SIG(KEY) for "." (the case that is assumed
- to be most crucial) the size of the response packet after the
- change to only sign the KEY RR with the KSKs break down into a
- rather large space of possibilities. Here are a few examples for
- the possible alternatives for different numbers of KSKs and ZSKs
- for some different key lengths (all RSA keys, with a public
- exponent that is < 254). This is all based upon the size of the
- response for the particular example of querying for
-
- ". KEY IN"
-
- with a response of entire KEY + SIG(KEY) with the authority and
- additional sections empty:
-
- ZSK/768 and KSK/1024 (real small)
- Max 12 KSK + 3 ZSK at 3975
- 10 KSK + 8 ZSK at 3934
- 8 KSK + 13 ZSK at 3893
-
- ZSK/768 + KSK/1280
- MAX 10 KSK + 2 ZSK at 3913
- 8 KSK + 9 ZSK at 3970
- 6 KSK + 15 ZSK at 3914
-
- ZSK/768 + KSK/1536
- MAX 8 KSK + 4 ZSK at 3917
- 7 KSK + 8 ZSK at 3938
- 6 KSK + 12 ZSK at 3959
-
- ZSK/768 + KSK/2048
- MAX 6 KSK + 5 ZSK at 3936
- 5 KSK + 10 ZSK at 3942
-
- ZSK/1024 + KSK/1024
- MAX 12 KSK + 2 ZSK at 3943
- 11 KSK + 4 ZSK at 3930
- 10 KSK + 6 ZSK at 3917
- 8 KSK + 10 ZSK at 3891
-
- ZSK/1024 + KSK/1536
- MAX 8 KSK + 3 ZSK at 3900
- 7 KSK + 6 ZSK at 3904
- 6 KSK + 9 ZSK at 3908
-
- ZSK/1024 + KSK/2048
- MAX 6 KSK + 4 ZSK at 3951
- 5 KSK + 8 ZSK at 3972
- 4 KSK + 12 ZSK at 3993
-
- Note that these are just examples and this document is not making
- any recommendations on suitable choices of either key lengths nor
- number of different keys employed at a security apex.
-
- This document does however, based upon the above figures, make the
- recommendation that at a security apex that expects to distribute
- "trusted keys" the KEY RRset should only be signed with the KSKs
- and not with the ZSKs to keep the size of the response packets
- down.
-
-
-5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
-
- In DNSSEC according to RFC2535[RFC2535] validation is the process
- of tracing a chain of signatures (and keys) upwards through the DNS
- hierarchy until a "trusted key" is reached. If there is a known
- trusted key present at a security apex above the starting point
- validation becomes an exercise with a binary outcome: either the
- validation succeeds or it fails. No intermediate states are
- possible.
-
- With multiple "trusted keys" (i.e. the KEY RRset for the security
- apex signed by multiple KSKs) this changes into a more complicated
- space of alternatives. From the perspective of complexity that may
- be regarded as a change for the worse. However, from a perspective
- of maximizing available trust the multiple KSKs add value to the
- system.
-
-5.1. Possible to do Threshold Validation
-
- With multiple KSKs a new option that opens for the security
- concious resolver is to not trust a key individually. Instead the
- resolver may decide to require the validated signatures to exceed a
- threshold. For instance, given M trusted keys it is possible for
- the resolver to require N-of-M signatures to treat the data as
- validated.
-
- I.e. with the following pseudo-configuration in a validating
- resolver
-
- security-apex "." IN {
- keys { ksk-1 .... ;
- ksk-2 .... ;
- ksk-3 .... ;
- ksk-4 .... ;
- ksk-5 .... ;
- };
- validation {
- # Note that ksk-4 is not present below
- keys { ksk-1; ksk-2; ksk-3; ksk-5; };
- # 3 signatures needed with 4 possible keys, aka 75%
- needed-signatures 3;
- };
- };
-
- we configure five trusted keys for the root zone, but require two
- valid signatures for the top-most KEY for validation to
- succeed. I.e. threshold validation does not force multiple
- signatures on the entire signature chain, only on the top-most
- signature, closest to the security apex for which the resolver has
- trusted keys.
-
-5.2. Not All Trusted Keys Will Be Available
-
- With multiple KSKs held and managed by separate entities the end
- resolvers will not always manage to get access to all possible
- trusted keys. In the case of just a single KSK this would be fatal
- to validation and necessary to avoid at whatever cost. But with
- several fully trusted keys available the resolver can decide to
- trust several of them individually. An example based upon more
- pseudo-configuration:
-
- security-apex "." IN {
- keys { ksk-1 .... ;
- ksk-2 .... ;
- ksk-3 .... ;
- ksk-4 .... ;
- ksk-5 .... ;
- };
- validation {
- # Only these two keys are trusted independently
- keys { ksk-1; ksk-4; };
- # With these keys a single signature is sufficient
- needed-signatures 1;
- };
- };
-
- Here we have the same five keys and instruct the validating
- resolver to fully trust data that ends up with just one signature
- from by a fully trusted key.
-
- The typical case where this will be useful is for the case where
- there is a risk of the resolver not catching a rollover event by
- one of the KSKs. By doing rollovers of different KSKs with
- different schedules it is possible for a resolver to "survive"
- missing a rollover without validation breaking. This improves
- overall robustness from a management point of view.
-
-5.3. Not All Possible KSKs Need to Be Trusted
-
- With just one key available it simply has to be trusted, since that
- is the only option available. With multiple KSKs the validating
- resolver immediately get the option of implementing a local policy
- of only trusting some of the possible keys.
-
- This local policy can be implemented either by simply not
- configuring keys that are not trusted or, possibly, configure them
- but specify to the resolver that certain keys are not to be
- ultimately trusted alone.
-
-
-6. Additional Benefits from Having Multiple KSKs
-
-6.1. More Robust Key Rollovers
-
- With only one KSK the rollover operation will be a delicate
- operation since the new trusted key needs to reach every validating
- resolver before the old key is retired. For this reason it is
- expected that long periods of overlap will be needed.
-
- With multiple KSKs this changes into a system where different
- "series" of KSKs can have different rollover schedules, thereby
- changing from one "big" rollover to several "smaller" rollovers.
-
- If the resolver trusts several of the available keys individually
- then even a failure to track a certain rollover operation within
- the overlap period will not be fatal to validation since the other
- available trusted keys will be sufficient.
-
-6.2. Evaluation of Multiple Key Distribution Mechanisms
-
- Distribution of the trusted keys for the DNS root zone is
- recognized to be a difficult problem that ...
-
- With only one trusted key, from one single "source" to distribute
- it will be difficult to evaluate what distribution mechanism works
- best. With multiple KSKs, held by separate entitites it will be
- possible to measure how large fraction of the resolver population
- that is trusting what subsets of KSKs.
-
-
-7. Security Considerations
-
- From a systems perspective the simplest design is arguably the
- best, i.e. one single holder of both KSK and ZSKs. However, if that
- is not possible in all cases a more complex scheme is needed where
- additional trust is injected by using multiple KSK holders, each
- contributing trust, then there are only two alternatives
- available. The first is so called "split keys", where a single key
- is split up among KSK holders, each contributing trust. The second
- is the multiple KSK design outlined in this proposal.
-
- Both these alternatives provide for threshold mechanisms. However
- split keys makes the threshold integral to the key generating
- mechanism (i.e. it will be a property of the keys how many
- signatures are needed). In the case of multiple KSKs the threshold
- validation is not a property of the keys but rather local policy in
- the validating resolver. A benefit from this is that it is possible
- for different resolvers to use different trust policies. Some may
- configure threshold validation requiring multiple signatures and
- specific keys (optimizing for security) while others may choose to
- accept a single signature from a larger set of keys (optimizing for
- redundancy). Since the security requirements are different it would
- seem to be a good idea to make this choice local policy rather than
- global policy.
-
- Furthermore, a clear issue for validating resolvers will be how to
- ensure that they track all rollover events for keys they
- trust. Even with operlap during the rollover (which is clearly
- needed) there is still a need to be exceedingly careful not to miss
- any rollovers (or fail to acquire a new key) since without this
- single key validation will fail. With multiple KSKs this operation
- becomes more robust, since different KSKs may roll at different
- times according to different rollover schedules and losing one key,
- for whatever reason, will not be crucial unless the resolver
- intentionally chooses to be completely dependent on that exact key.
-
-8. IANA Considerations.
-
- NONE.
-
-
-9. References
-
-9.1. Normative.
-
- [RFC2535] Domain Name System Security Extensions. D. Eastlake.
- March 1999.
-
- [RFC3090] DNS Security Extension Clarification on Zone Status.
- E. Lewis. March 2001.
-
-
-9.2. Informative.
-
- [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS). D. Eastlake 3rd. May 2001.
-
- [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad.
- December 2001.
-
- [DS] Delegation Signer Resource Record.
- O. Gudmundsson. October 2002. Work In Progress.
-
-10. Acknowledgments.
-
- Bill Manning came up with the original idea of moving complexity
- from the signing side down to the resolver in the form of threshold
- validation. I've also had much appreciated help from (in no
- particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
- Olaf Kolkman.
-
-
-11. Authors' Address
-Johan Ihren
-Autonomica AB
-Bellmansgatan 30
-SE-118 47 Stockholm, Sweden
-johani@autonomica.se
diff --git a/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt b/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt
deleted file mode 100644
index d857cd95806bd..0000000000000
--- a/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt
+++ /dev/null
@@ -1,295 +0,0 @@
-
-
-
-Internet Engineering Task Force Akira Kato, WIDE
-INTERNET-DRAFT Paul Vixie, ISC
-Expires: August 24, 2003 February 24, 2003
-
-
- Operational Guidelines for "local" zones in the DNS
- draft-kato-dnsop-local-zones-00.txt
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-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.''
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-Distribution of this memo is unlimited.
-
-The internet-draft will expire in 6 months. The date of expiration will
-be August 24, 2003.
-
-
-Abstract
-
-A large number of DNS queries regarding to the "local" zones are sent
-over the Internet in every second. This memo describes operational
-guidelines to reduce the unnecessary DNS traffic as well as the load of
-the Root DNS Servers.
-
-1. Introduction
-
-While it has yet been described in a RFC, .local is used to provide a
-local subspace of the DNS tree. Formal delegation process has not been
-completed for this TLD. In spite of this informal status, .local has
-been used in many installations regardless of the awareness of the
-users. Usually, the local DNS servers are not authoritative to the
-.local domain, they end up to send queries to the Root DNS Servers.
-
-There are several other DNS zones which describe the "local"
-information. .localhost has been used to describe the localhost for
-more than a couple of decades and virtually all of the DNS servers are
-configured authoritative for .localhost and its reverse zone .127.in-
-
-
-KATO Expires: August 24, 2003 [Page 1]
-
-
-DRAFT DNS local zones February 2003
-
-addr.arpa. However, there are other "local" zones currently used in the
-Internet or Intranets connected to the Internet through NATs or similar
-devices.
-
-At a DNS server of an university in Japan, half of the DNS queries sent
-to one of the 13 Root DNS Servers were regarding to the .local. At
-another DNS Server running in one of the Major ISPs in Japan, the 1/4
-were .local. If those "local" queries are able to direct other DNS
-servers than Root, or they can be resolved locally, it contributes the
-reduction of the Root DNS Servers.
-
-2. Rationale
-
-Any DNS queries regarding to "local" names should not be sent to the DNS
-servers on the Internet.
-
-3. Operational Guidelines
-
-Those queries should be processed at the DNS servers internal to each
-site so that the severs respond with NXDOMAIN rather than sending
-queries to the DNS servers outside.
-
-The "local" names have common DNS suffixes which are listed below:
-
-3.1. Local host related zones:
-
-Following two zones are described in [Barr, 1996] and .localhost is also
-defined in [Eastlake, 1999] .
-
- o .localhost
- o .127.in-addr.arpa
-
-
-Following two zones are for the loopback address in IPv6 [Hinden, 1998]
-. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
-2001] , the old TLD .int has been used for this purpose for years
-[Thomson, 1995] and many implementations still use .int. So it is
-suggested that both zones should be provided for each IPv6 reverse
-lookup zone for a while.
-
- o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
- o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
-
-
-3.2. Locally created name space
-
-While the use of .local has been proposed in several Internet-Drafts, it
-has not been described in any Internet documents with formal status.
-However, the amount of the queries for .local is much larger than
-others, it is suggested to resolve the following zone locally:
-
-
-
-
-KATO Expires: August 24, 2003 [Page 2]
-
-
-DRAFT DNS local zones February 2003
-
- o .local
-
-
-
-3.3. Private or site-local addresses
-
-The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
-local addresses [Hinden, 1998] should be resolved locally:
-
- o 10.in-addr.arpa
- o 16.172.in-addr.arpa
- o 17.172.in-addr.arpa
- o 18.172.in-addr.arpa
- o 19.172.in-addr.arpa
- o 20.172.in-addr.arpa
- o 21.172.in-addr.arpa
- o 22.172.in-addr.arpa
- o 23.172.in-addr.arpa
- o 24.172.in-addr.arpa
- o 25.172.in-addr.arpa
- o 26.172.in-addr.arpa
- o 27.172.in-addr.arpa
- o 28.172.in-addr.arpa
- o 29.172.in-addr.arpa
- o 30.172.in-addr.arpa
- o 31.172.in-addr.arpa
- o 168.192.in-addr.arpa
- o c.e.f.ip6.int
- o d.e.f.ip6.int
- o e.e.f.ip6.int
- o f.e.f.ip6.int
- o c.e.f.ip6.arpa
- o d.e.f.ip6.arpa
- o e.e.f.ip6.arpa
- o f.e.f.ip6.arpa
-
-
-3.4. Link-local addresses
-
-The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
-1998] should be resolved locally:
-
- o 254.169.in-addr.arpa
- o 8.e.f.ip6.int
- o 9.e.f.ip6.int
- o a.e.f.ip6.int
- o b.e.f.ip6.int
- o 8.e.f.ip6.arpa
- o 9.e.f.ip6.arpa
- o a.e.f.ip6.arpa
- o b.e.f.ip6.arpa
-
-
-
-KATO Expires: August 24, 2003 [Page 3]
-
-
-DRAFT DNS local zones February 2003
-
-4. Suggestions to developers
-
-4.1. Suggestions to DNS software implementors
-
-In order to avoid unnecessary traffic, it is suggested that DNS software
-implementors provide configuration templates or default configurations
-so that the names described in the previous section are resolved locally
-rather than sent to other DNS servers in the Internet.
-
-4.2. Suggestions to developers of NATs or similar devices
-
-There are many NAT or similar devices available in the market.
-Regardless of the availability of DNS Servers in those devices, it is
-suggested that those devices are able to filter the DNS traffic or
-respond to the DNS traffic related to "local" zones by configuration
-regardless of its ability of DNS service. It is suggested that this
-functionality is activated by default.
-
-5. IANA Consideration
-
-While .local TLD has yet defined officially, there are substantial
-queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
-traffic sent to the Root DNS Servers are related to the .local zone.
-Therefore, while it is not formally defined, it is suggested that IANA
-delegates .local TLD to an organization.
-
-The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
-address and the link-local address. It has several DNS server instances
-around the world by using BGP Anycast [Hardie, 2002] . So the AS112
-Project is one of the candidates to host the .local TLD.
-
-Authors' addresses
-
- Akira Kato
- The University of Tokyo, Information Technology Center
- 2-11-16 Yayoi Bunkyo
- Tokyo 113-8658, JAPAN
- Tel: +81 3-5841-2750
- Email: kato@wide.ad.jp
-
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063, USA
- Tel: +1 650-779-7001
- Email: vixie@isc.org
-
-
-
-
-
-
-
-KATO Expires: August 24, 2003 [Page 4]
-
-
-DRAFT DNS local zones February 2003
-
-References
-
-To be filled
-
-References
-
-Barr, 1996.
-D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
-(February 1996).
-
-Eastlake, 1999.
-D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
-
-Hinden, 1998.
-R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
-RFC2373 (July 1998).
-
-Bush, 2001.
-R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
-
-Thomson, 1995.
-S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
-RFC1886 (December 1995).
-
-Rekhter, 1996.
-Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
-"Address Allocation for Private Internets" in RFC1918 (February 1996).
-
-IANA, 2002.
-IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
-
-Vixie, .
-P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
-
-Hardie, 2002.
-T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
-Addresses" in RFC3258 (April 2002).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-KATO Expires: August 24, 2003 [Page 5]
-
diff --git a/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
deleted file mode 100644
index f9eaf268194f7..0000000000000
--- a/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
+++ /dev/null
@@ -1,1830 +0,0 @@
-
-
-
- INTERNET-DRAFT S. Daniel Park
- Expires: October 2003 Syam Madanapalli
- File: SAMSUNG Electronics
- draft-park-ipv6-extensions-dns-pnp-00.txt April 2003
-
-
-
-
- IPv6 Extensions for DNS Plug and Play
-
-
-
- Status of This Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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
-
- This document proposes automatic configuration of domain name (FQDN)
- for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as
- a part of IPv6 plug and play feature. 6DNAC allows the automatic
- registration of domain name and corresponding IPv6 Addresses with
- the DNS server. In order to provide 6DNAC function, Neighbor Discovery
- Protocol [2461] will be used. Moreover, 6DNAC does not require any
- changes to the existing DNS system.
-
-
- Table of Contents
-
- 1. Introduction ............................................. 3
- 2. Terminology .............................................. 3
- 3. 6DNAC Design Principles .................................. 4
- 4. 6DNAC Overview ........................................... 4
- 5. 6DNAC Requirements ....................................... 5
- 5.1. 6DANR Client Requirements ................................ 5
- 5.2. 6DNAC Server Requirements ................................ 6
-
-Park & Madanapalli Expires October 2003 [Page 1]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- 6. 6DNAC Messages and Option Formats ........................ 6
- 6.1. Router Advertisement (RA) Message Format ................. 6
- 6.2. Neighbor Solicitation (NS) Message Format ................ 7
- 6.3. Neighbor Advertisement (NA) Message Format ............... 8
- 6.4. Option Formats ........................................... 8
- 6.4.1. DNS Zone Suffix Information Option Format ................ 8
- 6.4.2. Domain Name (FQDN) Option Format ......................... 9
- 6.4.3. Router Alert Option for 6DNAC ............................ 10
- 7. 6DNAC Operation .......................................... 10
- 7.1. 6DNAC Network Topology ................................... 11
- 7.2. 6DNAC Operational Scenarios .............................. 12
- 7.2.1. Domain Name Registration-Success Case .................... 12
- 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14
- 7.2.3. Domain Name Registration-Defend Case ..................... 16
- 7.2.4. Domain Name Registration in Retry Mode ................... 19
- 7.2.5. Domain Name Registration when DAD Fails .................. 20
- 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22
- 7.3.1. Sending Router Advertisement Messages .................... 22
- 7.3.2. Processing Router Advertisement Messages ................. 22
- 7.3.3. FQDN Lifetime expiry ..................................... 23
- 7.3.4. Host Naming Algorithm .................................... 23
- 7.4. Duplicate Domain Name Detection .......................... 23
- 7.4.1. DAD with All Nodes Multicast Address ..................... 24
- 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24
- 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24
- 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25
- 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25
- 7.4.1.5. Pros and Cons ............................................ 25
- 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25
- 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25
- 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26
- 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26
- 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26
- 7.4.2.5. Pros and Cons ............................................ 26
- 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26
- 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26
- 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26
- 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27
- 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27
- 7.4.3.5. Pros and Cons ............................................ 27
- 7.4.4. Retry Mode for Re-registering Domain Name ................ 27
- 7.5. Domain Name Registration ................................. 27
- 8. Security Consideration ................................... 27
- 9. IANA Consideration ....................................... 28
- 10. Acknowledgement .......................................... 28
- 11. Intellectual Property .................................... 28
- 12. Copyright ................................................ 28
- 13. References ............................................... 29
- 14. Author's Addresses ....................................... 30
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 2]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- 1. Introduction
-
- Today, most networks use DNS[1034][1035] for convenience. In case of
- IPv6, DNS is more important element because of IPv6 long addresses
- which are difficult to remember. In addition, small networks like home
- networks using IPv6, should be able to make network easily without
- manual configuration. Also, these small networks may not have DHCP
- Server, DNS Server etc. that are used to configure the network. This
- document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure
- for generating and registering the Domain Name and IPv6 addresses with
- the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are
- required to implement lightweight functions specified in this document.
- 6DNAC can be applied to all defined IPv6 unicast addresses except Link
- local IPv6 addresses, viz: Site-local and Global addresses.
-
- 6DNAC uses Neighbor Discovery Protocol [2461] with new additions
- (defined in section 6) and DAD procedures for generating and
- registering the Domain Name with the DNS server automatically.
-
-
- 2. Terminology
-
- 6DNAC - IPv6 Domain Name Auto Configuration. It can provide
- IPv6 hosts with Domain Name Generation and
- Registration automatically.
-
- 6DNAC Client - An IPv6 node that can generate its own unique Domain
- Name. Section 3 identifies the new requirements that
- 6DNAC places on an IPv6 node to be a 6DNAC node.
-
- 6DNAC Server - An IPv6 node that can collect and registrate Domain
- Name and IPv6 addresses automatically. 6DNAC server
- uses the information from the DAD operation messages
- with newly defined options for the registration of the
- Domain Name and IPv6 Addresses. Section 3 identifies
- the new requirements that 6DNAC places on an IPv6
- node to be a 6DNAC server. Also 6DNAC server can have
- various other functions depending on network
- environment and the network operator. For instance
- 6DNAC Server can acts as a Gateway as well Home Server
- in Home Networks.
-
- DAD - Duplicate Address Detection (is defined [2461])
-
- DFQDND - Duplicate Domain Name Detection
-
- FQDN - Fully Qualified Domain Name - FQDN and Domain Name are
- used interchangeably in this document.
-
- NA - Neighbor Advertisement message (is defined [2461])
-
- NS - Neighbor Solicitation message (is defined [2461])
-
- RA - Router Advertisement message (is defined [2461])
-
- SLAAC - Stateless Address Autoconfiguration [2462].
-
-Park & Madanapalli Expires October 2003 [Page 3]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- 3. 6DNAC Design Principles
-
- This section discusses the design principles of 6DNAC mechanism.
-
- 1. The new procedures for plug and play DNS should not cause changes
- to existing DNS system. 6DNAC requires lightweight functions to be
- implemented only at the client side of the DNS system, and uses the
- existing DDNS UPDATE [2136] to communicate with DNS Servers.
-
- 2. Introducing a new protocol will always introduce new problems.
- 6DNAC uses the existing protocols NDP [2461] with minor extensions
- for generating and registering the domain name automatically
- without defining a new protocol
-
- 3. Reusing proven and well understood design principles/patterns
- will always yield a robust system. 6DNAC is based on IPv6 Address
- Auotoconfiguration principle, where routers advertise the prefix
- and host adds the interface ID to the prefix and forms the IPv6
- address. Domain Name (FQDN) also contains two parts: host name
- and DNS zone suffix. Routers can advertise the DNS zone suffix
- on a particular link in Router Advertisements (RA Messages) and
- hosts can prefix their preferred host name to the DNS zone suffix
- and form the fully qualified domain name. Also the detection of
- duplicate domain name is similar to Duplicate Address Detection
- (DAD) and can be part of DAD operation itself.
-
-
- 4. 6DNAC Overview
-
- 6DNAC proposes minor extensions to NDP [2461] for automatic generation
- and registration of domain name with the DNS server. It introduces two
- new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone
- Suffix option is carried in Router Advertisement (RA) messages for
- notifying IPv6 nodes about the valid DNS Zone Suffix on the link and
- FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement
- (NA) messages to detect duplicate domain name. 6DNAC consists of two
- components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the
- domain name based on DNS Zone Suffix using Host Naming Algorithm (see
- section 7.3.1) and 6DNAC Server collects and registers the DNS
- information with the DNS Server on behalf of 6DNAC Clients.
-
- The automatic configuration of domain name using 6DNAC consists of
- three parts.
-
- - DNS Zone Suffix Discovery and FQDN Construction:
-
- IPv6 Nodes collect DNS Zone Suffix information from Router
- Advertisements and constructs FQDN by prefixing host name to the
- DNS Zone Suffix. The IPv6 Nodes are required to implement Host
- Naming Algorithm for generating host part of the FQDN in the
- absence of administrator.
-
- Generation of node's FQDN within the node itself has advantages. Nodes
- can provide forward and reverse name lookups independent of the DNS
- System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain
- Name is some thing that is owned by the node.
-
-Park & Madanapalli Expires October 2003 [Page 4]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- - Duplicate Domain Name Detection
-
- All nodes are expected to go for DAD for all new IPv6 unicast
- addresses, regardless of whether they are obtained through
- stateful, stateless or manual configuration. 6DNAC uses the DAD
- messages with new option for carrying the Domain Name along with
- the new IPv6 Address. 6DNAC Server captures this information and
- updates DNS Server provided that the IPv6 Address and its domain
- name are not duplicate. If the domain name is already in use,
- the 6DNAC server replies to the sender with FQDN Option in NA
- message indicating that the domain name is duplicate. Then the
- node is expected to generate another domain name using host
- naming algorithm and go for DAD. This time the DAD is only for
- duplicate domain name detection (DFQDND). In order to avoid
- confusion with the normal NDP processing, the target address
- field of the NS message must carry the unspecified address
- in retry mode. This can be repeated depending on number of
- retries defined by the administrator in the host naming algorithm.
-
-
- - Domain Name Registration
-
- 6DNAC Server detects the DNS information (IPv6 Address and
- corresponding FQDN) from DAD/DFQDND messages and updates DNS
- Server using existing protocol DDNS UPDATE [2136] provided that
- the IPv6 Address and its domain name are not duplicate.
-
- If an IPv6 Address is duplicate, the IPv6 node cannot perform
- stateless address autoconfiguration repeatedly. Unlike IPv6 stateless
- address autoconfiguration, 6DNAC allows the automatic configuration of
- domain name repeatedly if the domain name is duplicate depending on
- number of retries defined by the administrator in the host naming
- algorithm.
-
-
- 5. 6DNAC Requirements
-
- Depending on the 6DNAC functionality, the IPv6 nodes implement, they
- are called either 6DNAC Clients or 6DNAC Servers. The following
- sections lists the requirements that the 6DNAC Client and 6DNAC server
- must support.
-
-
- 5.1. 6DANC Client Requirements
-
- - 6DNAC Client must recognize and process the following NDP
- extensions
-
- - DNS Zone Suffix option in RA messages for generating its
- domain name (FQDN).
-
- - Domain Name option in NS and NA messages for detecting
- the duplicate domain name
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 5]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- - It must generate its domain name (FQDN) based on the DNS
- suffix that it got from the router advertisement. And it must
- have a host naming algorithm for generating the host part of
- the FQDN.
-
- - If NA message is received with unspecified target address and
- FQDN option, then the node must treat that the domain is
- duplicate.
-
-
- 5.2. 6DNAC Server Requirements
-
- - 6DNAC Server must recognize and process the following NDP
- extensions
-
- - If the 6DNAC Server is a router on the link, then it
- must advertise DNS Zone Suffix option in RA messages
- for hosts to generate their domain name (FQDN).
-
- - FQDN option in NS messages for detecting new DNS
- information for of nodes on the link for which it
- must update the AAAA RR and PTR RR in DNS Server.
-
- - FQDN option in NA messages for notifying duplicate
- domain name with unspecified target address.
-
- - 6DNAC server must update the DNS Server (both AAAA RR and
- PTR RR) dynamically using DDNS UPDATE [2136].
-
- - 6DNAC server must cache this (newly detected) FQDN, Link
- Layer Address, and IPv6 Address information, so that it can
- decide whether it really needs to update DNS Server or not,
- to avoid redundant updates. This information will also be
- used for notifying the duplicate domain name.
-
-
- 6. 6DNAC Messages and Option Formats
-
- In order to achieve the plug and play DNS, 6DNAC proposes new
- extensions to the NDP [2461]. This section specifies the new
- additions to NDP messages and formats of new options.
-
-
- 6.1. Router Advertisement (RA) Message Format
-
- Routers send out Router Advertisement (RA) message periodically, or
- in response to a Router Solicitation. 6DNAC does not modify the format
- of the RA message, but proposes new option (DNS Zone Suffix Information)
- to be carried in RA messages.
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 6]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | Checksum |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Cur Hop Limit |M|O| Reserved | Router Lifetime |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reachable Time |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Retrans Timer |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Options ... |
- / /
- | DNS Zone Suffix Information |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- <Figure: 1 RA message>
-
-
-
- 6.2. Neighbor Solicitation (NS) Message Format
-
- 6DNAC does not modify the format of the Neighbor Solicitation (NS)
- message, but proposes new option (FQDN Option) to be carried in NS
- messages. When a node is going for DAD, the node must include FQDN
- option in NS message to participate in plug and play DNS. If the
- node is going for Explicit Detection of Duplicate Domain Name, the
- node must use FQDN option in NS message and unspecified address in
- the target address field.
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | Checksum |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + Target Address +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Options ... |
- / /
- | Domain Name |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- <Figure: 2 NS message>
-
-Park & Madanapalli Expires October 2003 [Page 7]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- 6.3. Neighbor Advertisement (NA) Message Format
-
- 6DNAC does not modify the format of the Neighbor Advertisement (NA)
- message, but proposes new option (FQDN Option) to be carried in NA
- messages. 6DNAC Server sends NA message with FQDN option to 6DNAC
- Client that is performing duplicate domain name detection in case
- the domain name found to be duplicate.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | Checksum |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |R|S|O| Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + Target Address +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Options ... |
- / /
- | FQDN Option |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- <Figure: 3 NA message>
-
-
- 6.4 Option Formats
-
- 6.4.1. DNS Zone Suffix Information Option Format
-
- IPv6 nodes require DNS Zone Suffix for constructing their FQDN.
- 6DNAC introduces new option for routers to advertise the DNS Zone
- Suffix Information for IPv6 nodes on the link. The suffix information
- should be configured into routers manually.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Valid Lifetime |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- / DNS Zone Suffix /
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- <Figure: 4 DNS Zone Suffix Information>
-
-Park & Madanapalli Expires October 2003 [Page 8]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- Type [TBD]
-
- Length 8-bit unsigned integer. The length of the option
- (including the type and length fields) in units of
- 8 octets.
-
- Reserved This field is unused. It must be initialized to zero
- by the sender and must be ignored by the receiver.
-
- Valid Life Time 32-bit signed integer. The maximum time, in
- seconds, over which this suffix is valid. Nodes
- should treat this as the life time for their domain
- name. Nodes should contact the source of this
- information before expiry of this time interval.
- A value of all one bits (0xFFFFFFFF) represents
- infinity.
-
- DNS Zone Suffix The suffix part of the FQDN. The data in the DNS
- Zone Suffix field should be encoded according to
- DNS encoding rules specified in [1035].
-
-
-
- 6.4.2. Domain Name (FQDN) Option Format
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Valid Lifetime |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + FQDN Target Address +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- / Domain Name /
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- <Figure: 5 FQDN Information>
-
- Type [TBD]
-
- Length 8-bit unsigned integer. The length of the option
- (including the type and length fields) in units
- of 8 octets. It must be greater than 3.
-
-
-
-Park & Madanapalli Expires October 2003 [Page 9]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- Reserved This field is unused. It must be initialized to
- zero by the sender and must be ignored by the
- receiver.
-
- Valid Life Time 32-bit signed integer. The maximum time, in
- seconds, over which this domain name is valid
- 6DNAC should deregister this domain name at
- the expiry of this interval. 6DNAC clients
- should send updates by the expiry of this
- interval. A value of all one bits (0xFFFFFFFF)
- represents infinity.
-
- FQDN Target Address The Address for which the FQDN maps to. It
- should be same as Target Address field of the
- NS message in case of DAD & duplicate FQDN are
- running in parallel.
-
- Domain Name The domain name (FQDN) of the node. The data in
- the domain name should be encoded according to
- DNS encoding rules specified in [1035].
-
-
- 6.4.3. Router Alert Option for 6DNAC
-
- Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop
- Header for using in NDP messages. The presence of this option in NS
- message informs the router that this NS message is carrying Domain
- Name information and must be processed by the 6DNAC Server on the router.
- 6DNAC Clients can use this option for sending DAD packets instead
- of addressing the DAD packets to the all-nodes multicast address
- when 6DNAC Server is implemented on router.
-
- The Router Alert option has the following format:
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Length = 2
-
- Values are registered and maintained by the IANA. For 6DNAC, the
- value has to be assigned by IANA.
-
- Further information about this option can be obtained from
- IPv6 Router Alert Option [2711].
-
-
- 7. 6DNAC Operation
-
- 6DNAC provides mechanisms for automatic generation of domain name
- and registering it with the DNS Server for IPv6 nodes. 6DNAC consists
- of two components: 6DNAC Client and 6DNAC Server. All nodes that want
- to participate in plug and play DNS are required to implement 6DNAC
- Client functionality, and one of the IPv6 nodes is required to
- implement 6DNAC Server functionality. The IPv6 node that implements
- the 6DNAC Server functionality must know the location of the DNS
- Server and must be a trusted node to send DDNS UPDATE [2136] messages.
-
-Park & Madanapalli Expires October 2003 [Page 10]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- 7.1. 6DNAC Network Topology
-
- This section identifies the possible locations for the 6DNAC Server.
- Note that, all nodes are required to implement 6DNAC Client
- functionality for constructing the domain name from the DNS Zone
- Suffix Information advertised by the router. Figure 6 illustrates
- IPv6 host (H4) implementing 6DNAC Server functionality. In this case
- H4 can serve only one link (that it belongs to) for automatic
- registration of domain name. H4 must observe the DAD packets on the
- link to detect the DNS information, this requires all nodes on the
- link must belong to same solicited node multicast address. In general,
- this may not be the case. So the node that is going for DAD must use
- all nodes multicast address for DAD packets, so that the 6DNAC Server
- (H4) can observe the DAD packets, detects IPv6 address and
- corresponding domain name, checks if this domain name is duplicate
- and finally registers the domain name with the DNS Server.
-
-
- 6DNAC Server
- +---+ +---+ +----------+
- | H1| | H4|<--- DDNS UPDATE --->|DNS Server|
- +-+-+ +-+-+ +----+-----+
- | | +----+ +---/
- | | | | /
- ---+-----+-----------+-----+-----------+ R1 +-----+
- | | | |
- | | +----+
- +-+-+ +-+-+
- | H2| | H3|
- +---+ +---+
-
-
- H1, H2, H3 - 6DNAC Clients
- H4 - 6DNAC Server
- R1 - Router
-
-
- <Figure: 6 Example of 6DNAC Topology>
-
-
- Figure 7 shows the 6DNAC Server implemented on a router R1. In this
- case a single 6DNAC server can serve multiple links for automatic
- configuration of the domain name. This topology also has flexibility
- of using DAD packets with Router Alert option instead of sending DAD
- packets to all nodes multicast address. The routers are required to
- process all the packets with Router Alert option as per [2711].
-
- In case of Home Networks, R1 is will acts as a Home Gateway (CPE)
- connected to ISP. R1 delegates the prefix from the ISP edge router.
- After delegating the prefix the CPE can advertise the DNS Zone suffix
- along with the prefix information to the nodes on the links to which
- the router is connected to. Note that the R1 must be configured with
- the DNS Zone suffix Information manually.
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 11]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- +---+ +---+
- | H3+ | H4|
- +-+-+ +-+-+
- | |
- | LINK2 |
- +---+ ---+--------+--+-- +----------+
- | H1| | |DNS Server|
- +-+-+ | +----+-----+
- | +--+-+ -------/
- | LINK 1 | | /
- ---+-----+------------------+ R1 +---------+
- | | | DDNS UPDATE
- | +----+
- +-+-+ 6DNAC Server
- | H2|
- +---+
-
-
- H1, H2 - 6DNAC Clients on Link1
- H3, H4 - 6DNAC Clients on Link2
- R1 - Router with 6DNAC Server, serving both Link1 and Link2
-
-
- <Figure: 7 Example of 6DNAC Server serving multiple links>
-
-
- 7.2. 6DNAC Operational Scenarios
-
- This section provides message sequence charts for various 6DNAC
- operational scenarios assuming that the 6DNAC Server is implemented
- on a router. All the scenarios assume that the normal boot up time
- stateless address autoconfiguration of Link Local address derived
- from the Interface Identifier has been completed successfully. And
- it is also assumed that the router is already configured with the
- DNS Zone Suffix Information.
-
-
- Legend:
-
- 6DNAC-A, B, C : 6DNAC Clients
- 6DNAC-S : 6DNAC Server/Router
- DAD : Duplicate Address Detection
- DFQDND : Duplicate Domain Name Detection
- DNS-S : DNS Server
-
-
- 7.2.1. Domain Name Registration-Successful Case
-
- This scenario starts when a 6DNAC Client receives RA message with
- DNS Zone Suffix and other parameters including address prefix as
- specified in NDP [2461] and wants configure its IPv6 address (Global
- or Site Local) and domain name. It is Assumed that the
- DupAddrDetectTransmits is set to 1.
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 12]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- +---------+ +---------+ +---------+
- | 6DNAC-C | | 6DNAC-S | | DNS-S |
- +----+----+ +----+----+ +----+----+
- | | |
- | RA with | |
- | DNS Suffix Opt | |
- |<---------------| |
- | #1 | |
- |---+ | |
- Construct |#2 | |
- FQDN | | |
- |<--+ | |
-DAD/DFQDND Starts | |
- | | |
- | | |
- | NS With | |
- | FQDN Opt | |
- |--------------->| |
- | #3 | |
- | | |
- | |------+ |
- | Create FQDN | #4 |
- | <FQDN,C> | |
- | |<-----+ |
- | | |
- | | Register FQDN |
- | |--------------->|
- | | #5 |
- | #6 | |
- |--------+ | |
- No Response | | |
- DFQDND-Success | | |
- |<-------+ | |
- | | |
- | | |
- v V v
-
-
- <Figure: 8 Domain Name Generation and Registration>
-
-
- #1. 6DNAC Server (Router) sends out router advertisement with DNS
- Suffix information along with other parameters as specified in
- NDP [2461].
-
- #2. 6DNAC Client processes the router advertisement and constructs
- the FQDN by prefixing hostname to the DNS Zone Suffix. It also
- constructs IPv6 address from the autoconfiguration prefix
- information option.
-
- #3. 6DNAC Client starts duplicate address & FQDN detection for the
- IPv6 address & FQDN constructed and sends out a Neighbor
- Solicitation message with FQDN option.
-
- Note that the DAD packets must be addressed to all nodes multicast
- address if Router Alert option is not used.
-
-Park & Madanapalli Expires October 2003 [Page 13]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- #4. 6DNAC Server processes the Neighbor Solicitation message sent by
- 6DNAC Client as part of duplicate FQDN detection procedure and
- creates a FQDN entry in its FQDN Cache (assuming that there is no
- entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client.
-
- #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
- through the existing protocol DDNS UPDATE.
-
- #6. 6DNAC Client times out and observes that there is no response to
- defend its duplicate FQDN detection procedure and the node is
- successful in configuring its domain name.
-
- Note that, Stateless Address Autoconfiguration DAD procedure is not
- depicted in the following message sequence chart, which simultaneously
- happens along with duplicate FQDN detection.
-
-
- 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2
-
- This scenario starts when a 6DNAC Client receives RA message with
- DNS Zone Suffix and other parameters including address prefix as
- specified in NDP [2461] and wants configure its IPv6 address (Global
- or Site Local) and domain name. The node is configured with
- DupAddrDetectTransmits = 2 for reliability in delivering DAD messages.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 14]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- +---------+ +---------+ +---------+
- | 6DNAC-C | | 6DNAC-S | | DNS-S |
- +----+----+ +----+----+ +----+----+
- | | |
- | RA with | |
- | DNS Suffix Opt | |
- |<---------------| |
- | #1 | |
- |---+ | |
- Construct |#2 | |
- FQDN | | |
- |<--+ | |
-DAD/DFQDND Starts | |
- | | |
- | | |
- | NS With | |
- | FQDN Opt | |
- |--------------->| |
- | #3 | |
- | | |
- | |------+ |
- | Create FQDN | #4 |
- | <FQDN,C> | |
- | |<-----+ |
- | | |
- | | Register FQDN |
- | |--------------->|
- | | #5 |
- | NS With | |
- | FQDN Opt | |
- |--------------->| |
- | #6 | |
- | | |
- | Lookup FQDN |
- | Entry exists |
- | |------+ |
- | Ignore | #7 |
- | |<-----+ |
- | #8 | |
- |--------+ | |
- No Response | | |
- DFQDND-Success | | |
- |<-------+ | |
- | | |
- | | |
- v V v
-
-
-
- <Figure: 9 Verification of duplicated Domain Name>
-
-
- Steps from #1 to #5 are same as that of scenario.7.2.1.
-
- #6. 6DNAC Client sends out second Neighbor Solicitation message with
- FQDN option as part of duplicate FQDN detection.
-
-Park & Madanapalli Expires October 2003 [Page 15]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- #7. 6DNAC Server receives and observes that the FQDN Cache exactly
- matches with that of the NS information and ignores the NS message.
-
- #8. 6DNAC Client times out and observes that there is no response to
- defend its duplicate FQDN detection procedure and the node is
- successful in configuring its domain name..
-
-
- 7.2.3. Domain Name Registration-Defend Case
-
- This scenario starts when two 6DNAC Client receive RA message with
- DNS Zone Suffix and other parameters including address prefix as
- specified in NDP [2461] and both the nodes want configure their IPv6
- address (Global or Site Local) and domain name. In this scenario both
- the nodes want to have same domain name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 16]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
-
- +---------+ +---------+ +---------+ +---------+
- | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S |
- +----+----+ +----+----+ +----+----+ +----+----+
- | | | |
- | RA with | RA with | |
- | DNS Suffix Opt | DNS Suffix Opt | |
- |<---------------|--------------->| |
- | #1 | #1 | |
- |---+ | |---+ |
- Construct | #2 | Construct | #2 |
- FQDN | | FQDN | |
- |<--+ | |<--+ |
- DAD/DFQDND Starts | DAD/DFQDND Starts |
- | | <DELAYED> |
- | | | |
- | NS with | | |
- | FQDN Opt | | |
- |--------------->| | |
- | #3 | | |
- | No Entry | |
- | |------+ | |
- | Create FQDN | #4 | |
- | <FQDN,A> | | |
- | |<-----+ | |
- | | | |
- | | Register FQDN #5 |
- | |-------------------------------->|
- | | | |
- | | NS with | |
- | | FQDN Opt | |
- | |<---------------| |
- | | #6 | |
- | |------+ | |
- | FQDN is in use| | |
- | Defend DFQDND| #7 | |
- | |<-----+ | |
- | | | |
- | | NA with | |
- | | D-flag Set | |
- | |--------------->| |
- | | #8 | |
- |------+ | |---+ |
- No Response | #9 | Enter | #10 |
- DFQDND Success| | Retry Mode| |
- |<-----+ | |<--+ |
- | | | |
- v v v v
-
-
- <Figure: 10 Multiple Hosts Requesting Same Domain Name>
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 17]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- #1. 6DNAC Server (Router) sends out router advertisement with DNS
- Suffix information.
-
- #2. 6DNAC Clients A&B process the router advertisement and construct
- their FQDN by prefixing hostname to the DNS Zone Suffix. They
- also construct IPv6 address from the autoconfiguration prefix
- information option.
-
- When each host is trying to go for DAD, all hosts must have
- random delay to avoid the traffic congestion according to [2461].
- So here it is assumed that 6DNAC Client-A starts DAD first and
- 6DNAC Client-B starts DAD later.
-
- #3. 6DNAC Client-A starts duplicate address & FQDN detection for the
- IPv6 address & FQDN constructed and sends out a Neighbor
- Solicitation message with FQDN option.
-
- #4. 6DNAC Server processes the Neighbor Solicitation message sent by
- 6DNAC Client-A as part of duplicate FQDN detection procedure and
- creates a FQDN entry in its FQDN Cache (assuming that there is no
- entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A.
-
- #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
- through the existing protocol DDNS UPDATE.
-
- #6. 6DNAC Client-B starts duplicate address & FQDN detection for the
- IPv6 address & FQDN constructed and sends out a Neighbor Solicitation
- message with FQDN option.
-
- #7. 6DNAC Server processes the Neighbor Solicitation message sent by
- 6DNAC Client-B as part of duplicate FQDN detection procedure and
- finds that the domain name is already in use by the 6DNAC Client-A.
- Hence, concludes to defend the duplicate FQDN detection of 6DNAC
- Client-B.
-
- #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN
- option to 6DNAC Client-B to defend its duplicate FQDN detection.
-
- #9. 6DNAC Client-A times out and observes that there is no response to
- defend its duplicate FQDN detection procedure and the node is
- successful in configuring its domain name.
-
- #10. 6DNAC Client-B observes that there is a NA with FQDN option
- indicating that the domain name is duplicate and enters Retry
- Mode. In retry mode, 6DNAC Client constructs another FQDN based
- on Host Naming Algorithm. The number of retries is defined by the
- administrator and must be a configurable value.
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 18]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- 7.2.4. Domain Name Registration in Retry Mode
-
- Pre-Conditions:
-
- 1. Duplicate Address Detection has succeeded
- 2. Duplicate FQDN Detection FAILED
- 3. FQDN is the first FQDN one constructed and FAILED
- 4. FQDN2 is the second FQDN to be constructed
- 5. The Neighbor Solicitation in the 'Retry Mode'
- carries unspecified address in its target field (NS*).
-
- +---------+ +---------+ +---------+
- | 6DNAC-C | | 6DNAC-S | | DNS-S |
- +----+----+ +----+----+ +----+----+
- | | |
- |--------+ | |
- Construct | #1 | |
- new FQDN2 | | |
- |<-------+ | |
- | | |
- DFQDND Restarts | |
- | | |
- | | |
- | NS* With | |
- | FQDN Opt | |
- |--------------->| |
- | #2 | |
- | | |
- | No Entry |
- | |------+ |
- | Create FQDN | #3 |
- | <FQDN2,C> | |
- | |<-----+ |
- | | |
- | | Register FQDN2 |
- | |--------------->|
- | | #4 |
- | | |
- |--------+ | |
- No Response | #5 | |
- DFQDND-Success | | |
- |<-------+ | |
- | | |
- v V v
-
-
- <Figure: 11 Regeneration of Domain Name>
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 19]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm,
- the DNS Zone Suffix, and it is FQDN2.
- #2. It then starts Duplicate Detection only for Domain Name. 6DNAC
- Client sends out NS with FQDN option and unspecified target
- address.
-
- #3. 6DNAC Server processes the Retry Mode NS message and finds that
- the FQDN2 is not in use and creates Cache entry as <FQDN2, C>.
-
- #4. It then starts registration procedures with the DNS Server.
-
- #5. Meanwhile, 6DNAC Client timesout and observes that there is no
- defending NA for its DFQDND NS sent out and successfully
- configures its domain name.
-
-
- 7.2.5. Domain Name Registration when DAD Fails
-
- Duplicate domain name detection and subsequent registration starts
- if and only if the DAD for IPv6 address succeeds. If the DAD for
- IPv6 address fails then no actions are taken for domain name. When
- DAD fails for stateless address autoconfiguration, then the domain
- configuration starts only when the address has been configured using
- Stateful Address Configuration methods and the node is going on DAD
- for this address.
-
- This scenario starts when a 6DNAC Client receives RA message with
- DNS Zone Suffix and other parameters including address prefix as
- specified in NDP [2461] and wants configure its IPv6 address (Global
- or Site Local) and domain name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 20]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- +---------+ +---------+ +---------+ +---------+
- | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S |
- +----+----+ +----+----+ +----+----+ +----+----+
- | | | |
- | | | |
- | RA with | | |
- | DNS Suffix Opt | | |
- |<---------------| | |
- | #1 | | |
- |-----+ | | |
- Construct | | | |
- FQDN& | #2 | | |
- IPv6 Addr | | | |
- |<----+ | | |
- DAD/DFQDND Starts | | |
- | | | |
- | | | |
- | NS with | | |
- | FQDN Opt | | |
- |--------------->+--------------->| |
- | #3 | #3 | |
- | No Entry | |
- | |------+ | |
- | Create FQDN | | |
- | <FQDN,A> | #4 | |
- | |<-----+ | |
- | | | |
- | | |------+ |
- | | My IPv6 Addr| #5 |
- | | |<-----+ |
- | | Defend DAD | |
- | | with NA | |
- |<---------------+<---------------| |
- | #6 | #6 | |
- | Entry | |
- | |------+ | |
- | Delete FQDN | #7 | |
- | |<-----+ | |
- | | | |
- |----+ | | |
- DAD Failed | #8 | | |
- Stop DFQDND | | | |
- |<---+ | | |
- | | | |
- v v v v
-
- <Figure: 12 DAD failure>
-
- #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A.
-
- #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and
- FQDN as per Host Naming Algorithm.
-
- #3. It then starts Duplicate address & FQDN Detection, for the newly
- constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS
- with FQDN option.
-
-Park & Madanapalli Expires October 2003 [Page 21]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
- #4. 6DNAC Server processes the DAD/DFQDND NS message and finds
- that there is no entry for the FQDN in its cache. And,
- creates Cache entry as <FQDN, A> and starts a Registration
- timer with RegistrationWaitTime seconds.
-
- #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is
- in its unicast address list.
-
- #6. It then starts defending DAD by sending NA to all-nodes multicast.
-
- #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A.
- And, deletes its FQDN Cache entry <FQDN,A>.
-
- #8. 6DNAC Client gets defending DAD-NA and desists from DAD.
- And also, stops Duplicate FQDN Detection as well.
- At this point the address must be configured using stateful
- methods and the domain name registration starts with the DAD
- for the newly constructed IPv6 address.
-
- 7.3. DNS Zone Suffix Discovery and FQDN Construction
-
- 7.3.1. Sending Router Advertisement Messages
-
- Routers send out Router Advertisement message periodically,
- or in response to a Router Solicitation. Router should include
- the DNS Zone Suffix Option in their advertisements. If the DNS
- Zone Suffix changes (similar to Site Renumbering), then it should
- advertise the Old Zone Suffix with zero Valid Lifetime and New
- Zone Suffix with proper non-zero Valid Lifetime. In any other
- case, a router should not send this option twice in a single
- router advertisement.
-
- 7.3.2. Processing Router Advertisement Messages
-
- For each DNS Zone Suffix Option in Router Advertisement,
-
- a. 6DNAC node stores the Zone Suffix information in its local
- database. Also, constructs FQDN as per Host Naming Algorithm.
-
- b. If the node has not configured FQDN yet,
-
- 1. If the node is going to perform DAD for either Site local or
- Global Address, then it should include FQDN option to perform
- Duplicate FQDN Detection in parallel with DAD.
-
- 2. If the node has already got either Site local or Global
- address, then it should send out NS with FQDN option and
- unspecified target address to perform Duplicate FQDN
- Detection.
-
- c. If the node has already configured FQDN, and if the
- advertisement carries two DNS Zone Suffix Options,
- First DNS Zone Suffix should match with the configured FQDN
- Suffix and its Valid Lifetime must be zero. Second DNS Zone
-
-
-
-Park & Madanapalli Expires October 2003 [Page 22]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
- Suffix should have non-zero Valid Lifetime. In this case, the
- node constructs new FQDN based on the new DNS Zone Suffix (from
- second DNS Zone Suffix option), and perform Duplicate FQDN
- Detection with unspecified target address. Also, it should
- overwrite the old FQDN with the newly constructed FQDN.
-
-
- 7.3.3. FQDN Lifetime expiry
-
- 6DNAC Server:
- It should delete the FQDN cache entry and should de-register from
- the DNS Server.
-
- 6DNAC Client:
- It should send update to 6DNAC Server by restarting the Duplicate
- FQDN Detection.
-
- 7.3.4. Host Naming Algorithm
-
- A node constructs FQDN by combining DNS Zone Suffix and the hostname
- as depicted in the following diagram.
-
- +------------------+----------------------------------+
- | Host Name | Advertised Suffix |
- +------------------+----------------------------------+
-
- <Figure 13: Fully Qualified Domain Name format>
-
- A node can choose Host Name using any of the following methods:
-
- a. String form of random number generated from the Interface
- Identifier.
-
- b. List of configured Host Names provided by the administrator.
-
-
- The number of retries must be specified in this algorithm in
- case of domain name duplication.
-
-
- 7.4. Duplicate Domain Name Detection
-
- The procedure for detecting duplicated FQDNs uses Neighbor
- Solicitation and Advertisement messages as described below.
-
- If a duplicate FQDN is detected during the procedure, the
- FQDN cannot be assigned to the node.
-
- An FQDN on which the DFQDND Procedure is applied is said
- to be tentative until the procedure has completed successfully.
- A tentative FQDN is not considered "assigned to the node" in the
- traditional sense. That is, the node must accept Neighbor
- Advertisement message containing the tentative FQDN in the FQDN
- Option.
-
-
-Park & Madanapalli Expires October 2003 [Page 23]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
- It should also be noted that DFQDN must be performed prior to
- registering with DNS Server to prevent multiple nodes from using
- the same FQDN simultaneously. All the Duplicate Address Detection
- Neighbor Solicitation messages must carry Source Link Layer Address
- Option as specified in NDP [2461].
-
- The detection of duplicate FQDN can be achieved through one of the
- following three types of procedures.
-
- 1. DAD with All Nodes Multicast Address
- 2. DAD with Router Alert Option for 6DNAC.
- 3. Explicit Detection of Duplicate Domain Name
-
- Even though three solutions are listed, authors prefer only one
- procedure to be followed in future based on further analysis and
- comments received from others.
-
- 7.4.1. DAD with All Nodes Multicast Address
-
- 7.4.1.1. Sending Neighbor Solicitation Messages
-
- 6DNAC Client sends Neighbor Solicitation Messages as part
- of Duplicate Address Detection SLAAC [2462] with the following
- extra information and modifications:
-
- a. Include FQDN Option in the DAD Neighbor Solicitation Message
- b. Destination Address is set to All Nodes Multicast Address
-
- There may be a case where DAD has succeeded but DFQDND is in Retry
- Mode. In such case, the Neighbor Solicitation must carry unspecified
- address in the ICMP target address field and new domain name in FQDN
- option to re-try the registration of the domain name.
-
- 7.4.1.2. Processing Neighbor Solicitation Messages
-
- 6DNAC Clients must ignore the FQDN option found in any of the
- neighbor solicitation messages.
-
- 6DNAC Server processes FQDN Option found in the Duplicate Address
- Detection Neighbor Solicitation Messages as described below:
-
- Lookup FQDN Cache for the domain name in FQDN Option.
-
- If the entry exists and
- i. Link Layer Address matches with SLLA option, this is the case,
- where node has changed its IPv6 address or updating the valid
- life time. 6DNAC Server updates its cache and also updates DNS
- Server using DDNS-UPDATE. If there is no change in IPv6 address
- or life time then no updates are sent to the DNS server.
-
- ii. Link Layer Address differs with SLLA option, defend the duplicate
- FQDN Detection by sending Neighbor Advertisement Message as
- described in $7.4.1.3$.
-
-
-
-Park & Madanapalli Expires October 2003 [Page 24]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
- else,
- Lookup FQDN Cache for the Link Layer Address in SLLA Option.
-
- If the entry exists, update the FQDN Cache and update DNS Server
- using DDNS-UPDATE. This is the case, where node has changed its
- domain name (similar to Site Re-numbering).
-
- If then entry does not exists, then it means that this is the new
- registration. It must create a cache entry and start Registration
-
- timer with RegistrationWaitTime. At the expiry of the Registration
- timer, it should update DNS Server with DDNS-UPDATE.
-
- 7.4.1.3. Sending Neighbor Advertisement Messages
-
- 6DNAC Server sends Neighbor Advertisement Messages as part
- of Duplicate Address Detection SLAAC [2462] with the FQDN Option
- in Neighbor Advertisement message to defend duplicate FQDN
- detection.
-
- There may be the case where defending of duplicate address detection
- is not required but defending of FQDN is required. In such instance,
- the defending Neighbor Advertisement must carry FQDN and unspecified
- address in the ICMP target address field.
-
- 7.4.1.4. Processing Neighbor Advertisement Messages
-
- 6DNAC Server must ignore the any FQDN option found any of
- the neighbor advertisement messages. If the Neighbor Advertisement
- is a DAD defending, then it must delete its FQDN Cache entry created
- on the reception of DAD Neighbor Solicitation message.
-
- When 6DNAC Clients gets the duplicate address detection neighbor
- advertisement messages with FQDN option set it means that its
- duplicate FQDN detection failed and enters Retry Mode.
-
- 7.4.1.5. Pros and Cons
-
- The advantage of this procedure is that it does not need any
- extension header options to be included. The disadvantage of this
- procedure is that, it needs change in the existing DAD procedure.
- The change is only that the DAD neighbor solicitations are to be
- addressed to all nodes multicast address instead of solicited
- node multicast address. The another disadvantage is that, it needs
- the existence of Duplicate Address Detection Procedure to
- perform duplicate FQDN detection.
-
- 7.4.2. DAD with Router Alert Option for 6DNAC
-
- 7.4.2.1. Sending Neighbor Solicitation Messages
-
- 6DNAC Client sends Neighbor Solicitation Messages as part
- of Duplicate Address Detection SLAAC [2462] with the following
- extra information:
-
-
-Park & Madanapalli Expires October 2003 [Page 25]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
- a. Include Hop-by-Hop extension Header with Router Alert Option
- for 6DNAC as described in IPv6 Router Alert Option[2711].
-
- b. Include FQDN Option in the DAD Neighbor Solicitation Message
-
- 7.4.2.2. Processing Neighbor Solicitation Messages
-
- This is same as described in $7.4.1.2$.
-
- 7.4.2.3. Sending Neighbor Advertisement Messages
-
- This is same as described in $7.4.1.3$.
-
- 7.4.2.4. Processing Neighbor Advertisement Messages
-
- This is same as described in $7.4.1.4$.
-
- 7.4.2.5. Pros and Cons
-
- The advantage of this procedure is that it does not disturb
- the existing implementation and their way of processing the
- packets. The disadvantage is that, it needs the existence
- of Duplicate Address Detection Procedure to perform duplicate
- FQDN detection. Another disadvantage is that this procedure
- requires 6DNAC Server functionality to be implemented on Router.
- However, in this case 6DNAC Server can serve multiple links.
-
- 7.4.3. Explicit Detection of Duplicate Domain Name
-
- In this procedure Duplicate FQDN Detection starts after completion
- of successful Site local or Global Address configuration.
-
- 7.4.3.1. Sending Neighbor Solicitation Messages
-
- 6DNAC Client sends Neighbor Solicitation Messages as part
- of Duplicate FQDN Detection with the following information:
-
- a. Include FQDN Option in the Neighbor Solicitation Message
-
- b. Destination Address is set to All Nodes Multicast Address
- or uses Router Alert Option for 6DNAC, when 6DNAC Server is
- implemented on router.
-
- c. Target Address is set to Unspecified Address
-
- d. Other fields are set as per DAD SLAAC [2462].
-
- 7.4.3.2. Processing Neighbor Solicitation Messages
-
- This is same as described in $7.4.1.2$.
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 26]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
- 7.4.3.3. Sending Neighbor Advertisement Messages
-
- This is same as described in $7.4.1.3$.
-
- 7.4.3.4. Processing Neighbor Advertisement Messages
-
- This is same as described in $7.4.1.4$.
-
- 7.4.3.5. Pros and Cons
-
- The advantage of this procedure is that it does not need the
- existing duplicate address detection procedure. This is introduced
- as the DAD procedure is found to be redundant in when IPv6 addresses
- are constructed from the interface ID [DIID].
-
- Note that, if 6DNAC Clients know the address of 6DNAC Server then
- they can directly send DFQDND-NS to 6DNAC Server.
-
- 7.4.4. Retry Mode for Re-registering Domain Name
-
- In retry mode, nodes construct new FQDN as per Host Naming Algorithm.
- Then they restart Duplicate FQDN Detection as described in $7.4.3$.
-
-
- 7.5. Domain Name Registration
-
- 6DNAC Server must be an authenticated to update the DNS Server.
- 6DNAC Server must also be configured with the DNS Server
- information.
-
- 6DNAC Server detects the DNS information (IPv6 Address and
- corresponding FQDN) from DAD/DFQDND messages and caches the
- information. It also have an associated Registration Timer with
- RegistrationWaitTime to wait for the successful completion of
- DFQDND and update DNS Server using existing protocol DDNS UPDATE
- [2136].
-
-
- 8. Security Consideration
-
- If someone wants to hijack correct Domain Name registration, they
- could send a NS message with incorrect or same Domain Name to the
- 6DNAC server repeatedly and server would start the Domain Name
- registration through above mechanism, which is a security hole.
- As described in [2461], a host can check validity of NDP messages.
- If the NDP message include an IP Authentication Header, the message
- authenticates correctly. For DNS UPDATE processing, secure DNS
- Dynamic Update is described in [3007].
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 27]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
- 9. IANA Consideration
-
- Values in the Router Alert Option are registered and maintained by
- IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is
- required to assign the Type values for DNS Zone Suffix Information
- option and FADN option.
-
-
- 10. Acknowledgement
-
- Special thanks are due to Badrinarayana N.S. and Christian Huitema for
- many helpful suggestions and revisions.
-
-
- 11. Intellectual Property
-
- The following notice is copied from RFC 2026 [Bradner, 1996],
- Section 10.4, and describes the position of the IETF concerning
- intellectual property claims made against this document.
-
- 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 other 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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
- 12. Copyright
-
- The following copyright notice is copied from RFC 2026 [Bradner,
- 1996], Section 10.4, and describes the applicable copyright for this
- document.
-
- Copyright (C) The Internet Society July 12, 2001. All Rights
- Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
-
-Park & Madanapalli Expires October 2003 [Page 28]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However, this
-
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
- 13. References
-
- [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [2460] Deering, S. abd R. Hinden, "Internet Protocol,
- Version 6 (IPv6) Specification", RFC 2460,
- December 1998.
-
- [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
- Discovery for IP version 6(IPv6)", RFC 2461, December
- 1998.
-
- [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto-
- Configuration", RFC 2462, December 1998.
-
- [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option",
- RFC 2711, October 1999.
-
- [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND
- FACILITIES", RFC 1034, November 1987.
-
- [1035] P. Mockapetris, "Domain Names - Implementation and
- Specification" RFC 1035, November 1987.
-
- [2136] P. Vixie et al., "Dynamic Updates in the Domain Name
- System (DNS UPDATE)", RFC2136, April 1997.
-
- [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
-
-
-Park & Madanapalli Expires October 2003 [Page 29]
-
-INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
-
-
- [DIID] yokohama-dad-vs-diid.pdf
- at http://playground.sun.com/ipng/presentations/July2002/
-
- [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf-
- dnsop-ipv6-dns-issues-00.txt, work in progress.
-
- [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix
- delegation", draft-ietf-ipv6-prefix-delegation-
- requirement-01.txt, work in progress.
-
- [Autoreg] H. Kitamura, "Domain Name Auto-Registration for
- Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name-
- auto-reg-00.txt, work in progress.
-
- [NIQ] Matt Crawford, "IPv6 Node Information Queries", <draft-
- ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress.
-
-
- 14. Author's Addresses
-
- Soohong Daniel Park
- Mobile Platform Laboratory, SAMSUNG Electronics, KOREA
- Phone: +82-31-200-3728
- Email:soohong.park@samsung.com
-
- Syam Madanapalli
- Network Systems Division, SAMSUNG India Software Operations, INDIA
- Phone: +91-80-5550555
- Email:syam@samsung.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli Expires October 2003 [Page 30]
diff --git a/contrib/bind9/doc/draft/update b/contrib/bind9/doc/draft/update
deleted file mode 100644
index 6ac20904ab20f..0000000000000
--- a/contrib/bind9/doc/draft/update
+++ /dev/null
@@ -1,46 +0,0 @@
-#!/bin/sh
-commit=
-for i
-do
- z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
- if test -n "$z"
- then
- i="$z"
- fi
- if test -f "$i"
- then
- continue
- fi
- pat=`echo "$i" | sed 's/...txt/??.txt/'`
- old=`echo $pat 2> /dev/null`
- if test "X$old" != "X$pat"
- then
- newer=0
- for j in $old
- do
- if test $j ">" $i
- then
- newer=1
- fi
- done
- if test $newer = 1
- then
- continue;
- fi
- fi
- if fetch "http://www.ietf.org/internet-drafts/$i"
- then
- cvs add "$i"
- if test "X$old" != "X$pat"
- then
- rm $old
- cvs delete $old
- commit="$commit $old"
- fi
- commit="$commit $i"
- fi
-done
-if test -n "$commit"
-then
- cvs commit -m "new draft" $commit
-fi
diff --git a/contrib/bind9/doc/misc/Makefile.in b/contrib/bind9/doc/misc/Makefile.in
deleted file mode 100644
index 81f13beee5cef..0000000000000
--- a/contrib/bind9/doc/misc/Makefile.in
+++ /dev/null
@@ -1,36 +0,0 @@
-# Copyright (C) 2004 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,
-# 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: Makefile.in,v 1.1.12.3 2004/03/08 09:04:25 marka Exp $
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-top_srcdir = @top_srcdir@
-
-@BIND9_MAKE_RULES@
-
-PERL = @PERL@
-
-MANOBJS = options
-
-doc man:: ${MANOBJS}
-
-docclean manclean maintainer-clean::
- rm -f options
-
-options: ../../bin/tests/cfg_test
- ../../bin/tests/cfg_test --named --grammar | \
- ${PERL} ${srcdir}/format-options.pl >options || \
- rm -f options
diff --git a/contrib/bind9/doc/misc/dnssec b/contrib/bind9/doc/misc/dnssec
deleted file mode 100644
index 79d91cf971a98..0000000000000
--- a/contrib/bind9/doc/misc/dnssec
+++ /dev/null
@@ -1,84 +0,0 @@
-Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000-2002 Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-DNSSEC Release Notes
-
-This document summarizes the state of the DNSSEC implementation in
-this release of BIND9.
-
-
-OpenSSL Library Required
-
-To support DNSSEC, BIND 9 must be linked with version 0.9.6e or newer of
-the OpenSSL library. As of BIND 9.2, the library is no longer
-included in the distribution - it must be provided by the operating
-system or installed separately.
-
-To build BIND 9 with OpenSSL, use "configure --with-openssl". If
-the OpenSSL library is installed in a nonstandard location, you can
-specify a path as in "configure --with-openssl=/var".
-
-
-Key Generation and Signing
-
-The tools for generating DNSSEC keys and signatures are now in the
-bin/dnssec directory. Documentation for these programs can be found
-in doc/arm/Bv9ARM.4.html and the man pages.
-
-The random data used in generating DNSSEC keys and signatures comes
-from either /dev/random (if the OS supports it) or keyboard input.
-Alternatively, a device or file containing entropy/random data can be
-specified.
-
-
-Serving Secure Zones
-
-When acting as an authoritative name server, BIND9 includes KEY, SIG
-and NXT records in responses as specified in RFC2535 when the request
-has the DO flag set in the query.
-
-
-Secure Resolution
-
-Basic support for validation of DNSSEC signatures in responses has
-been implemented but should still be considered experimental.
-
-When acting as a caching name server, BIND9 is capable of performing
-basic DNSSEC validation of positive as well as nonexistence responses.
-This functionality is enabled by including a "trusted-keys" clause
-in the configuration file, containing the top-level zone key of the
-the DNSSEC tree.
-
-Validation of wildcard responses is not currently supported. In
-particular, a "name does not exist" response will validate
-successfully even if it does not contain the NXT records to prove the
-nonexistence of a matching wildcard.
-
-Proof of insecure status for insecure zones delegated from secure
-zones works when the zones are completely insecure. Privately
-secured zones delegated from secure zones will not work in all cases,
-such as when the privately secured zone is served by the same server
-as an ancestor (but not parent) zone.
-
-Handling of the CD bit in queries is now fully implemented. Validation
-is not attempted for recursive queries if CD is set.
-
-
-Secure Dynamic Update
-
-Dynamic update of secure zones has been implemented, but may not be
-complete. Affected NXT and SIG records are updated by the server when
-an update occurs. Advanced access control is possible using the
-"update-policy" statement in the zone definition.
-
-
-Secure Zone Transfers
-
-BIND 9 does not implement the zone transfer security mechanisms of
-RFC2535 section 5.6, and we have no plans to implement them in the
-future as we consider them inferior to the use of TSIG or SIG(0) to
-ensure the integrity of zone transfers.
-
-
-$Id: dnssec,v 1.14.2.6.4.4 2004/03/08 09:04:25 marka Exp $
diff --git a/contrib/bind9/doc/misc/format-options.pl b/contrib/bind9/doc/misc/format-options.pl
deleted file mode 100644
index 5f0975ade820f..0000000000000
--- a/contrib/bind9/doc/misc/format-options.pl
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/usr/bin/perl
-#
-# Copyright (C) 2004 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,
-# 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: format-options.pl,v 1.1.206.1 2004/03/06 13:16:19 marka Exp $
-
-print <<END;
-
-This is a summary of the named.conf options supported by
-this version of BIND 9.
-
-END
-
-# Break long lines
-while (<>) {
- s/\t/ /g;
- if (length >= 79) {
- m!^( *)!;
- my $indent = $1;
- s!^(.{0,75}) (.*)$!\1\n$indent \2!;
- }
- print;
-}
diff --git a/contrib/bind9/doc/misc/ipv6 b/contrib/bind9/doc/misc/ipv6
deleted file mode 100644
index dd96cd27a337c..0000000000000
--- a/contrib/bind9/doc/misc/ipv6
+++ /dev/null
@@ -1,113 +0,0 @@
-Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001 Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-Currently, there are multiple interesting problems with ipv6
-implementations on various platforms. These problems range from not
-being able to use ipv6 with bind9 (or in particular the ISC socket
-library, contained in libisc) to listen-on lists not being respected,
-to strange warnings but seemingly correct behavior of named.
-
-COMPILE-TIME ISSUES
--------------------
-
-The socket library requires a certain level of support from the
-operating system. In particular, it must follow the advanced ipv6
-socket API to be usable. The systems which do not follow this will
-currently not get any warnings or errors, but ipv6 will simply not
-function on them.
-
-These systems currently include, but are not limited to:
-
- AIX 3.4 (with ipv6 patches)
-
-
-RUN-TIME ISSUES
----------------
-
-In the original drafts of the ipv6 RFC documents, binding an ipv6
-socket to the ipv6 wildcard address would also cause the socket to
-accept ipv4 connections and datagrams. When an ipv4 packet is
-received on these systems, it is mapped into an ipv6 address. For
-example, 1.2.3.4 would be mapped into ::ffff:1.2.3.4. The intent of
-this mapping was to make transition from an ipv4-only application into
-ipv6 easier, by only requiring one socket to be open on a given port.
-
-Later, it was discovered that this was generally a bad idea. For one,
-many firewalls will block connection to 1.2.3.4, but will let through
-::ffff:1.2.3.4. This, of course, is bad. Also, access control lists
-written to accept only ipv4 addresses were suddenly ignored unless
-they were rewritten to handle the ipv6 mapped addresses as well.
-
-Partly because of these problems, the latest IPv6 API introduces an
-explicit knob (the "IPV6_V6ONLY" socket option ) to turn off the ipv6
-mapped address usage.
-
-In bind9, we first check if both the advanced API and the IPV6_V6ONLY
-socket option are available. If both of them are available, bind9
-named will bind to the ipv6 wildcard port for both TCP and UDP.
-Otherwise named will make a warning and try to bind to all available
-ipv6 addresses separately.
-
-In any case, bind9 named binds to specific addresses for ipv4 sockets.
-
-The followings are historical notes when we always bound to the ipv6
-wildcard port regardless of the availability of the API support.
-These problems should not happen with the closer checks above.
-
-
-IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail
----------------------------------------------------------------
-
-The only OS which seems to do this is (some kernel versions of) linux.
-If an ipv6 socket is bound to the ipv6 wildcard socket, and a specific
-ipv4 socket is later bound (say, to 1.2.3.4 port 53) the ipv4 binding
-will fail.
-
-What this means to bind9 is that the application will log warnings
-about being unable to bind to a socket because the address is already
-in use. Since the ipv6 socket will accept ipv4 packets and map them,
-however, the ipv4 addresses continue to function.
-
-The effect is that the config file listen-on directive will not be
-respected on these systems.
-
-
-IPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed
-----------------------------------------------------------------
-
-In this case, the system allows opening an ipv6 wildcard address
-socket and then binding to a more specific ipv4 address later. An
-example of this type of system is Digital Unix with ipv6 patches
-applied.
-
-What this means to bind9 is that the application will respect
-listen-on in regards to ipv4 sockets, but it will use mapped ipv6
-addresses for any that do not match the listen-on list. This, in
-effect, makes listen-on useless for these machines as well.
-
-
-IPV6 Sockets Do Not Accept IPV4
--------------------------------
-
-On these systems, opening an IPV6 socket does not implicitly open any
-ipv4 sockets. An example of these systems are NetBSD-current with the
-latest KAME patch, and other systems which use the latest KAME patches
-as their ipv6 implementation.
-
-On these systems, listen-on is fully functional, as the ipv6 socket
-only accepts ipv6 packets, and the ipv4 sockets will handle the ipv4
-packets.
-
-
-RELEVANT RFCs
--------------
-
-3513: Internet Protocol Version 6 (IPv6) Addressing Architecture
-
-3493: Basic Socket Interface Extensions for IPv6
-
-3542: Advanced Sockets Application Program Interface (API) for IPv6
-
-
-$Id: ipv6,v 1.5.206.4 2004/08/10 04:28:15 jinmei Exp $
diff --git a/contrib/bind9/doc/misc/migration b/contrib/bind9/doc/misc/migration
deleted file mode 100644
index af9fccb221e37..0000000000000
--- a/contrib/bind9/doc/misc/migration
+++ /dev/null
@@ -1,255 +0,0 @@
-Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
- BIND 8 to BIND 9 Migration Notes
-
-BIND 9 is designed to be mostly upwards compatible with BIND 8, but
-there is still a number of caveats you should be aware of when
-upgrading an existing BIND 8 installation to use BIND 9.
-
-
-1. Configuration File Compatibility
-
-1.1. Unimplemented Options and Changed Defaults
-
-BIND 9 supports most, but not all of the named.conf options of BIND 8.
-For a complete list of implemented options, see doc/misc/options.
-
-If your named.conf file uses an unimplemented option, named will log a
-warning message. A message is also logged about each option whose
-default has changed unless the option is set explicitly in named.conf.
-
-The default of the "transfer-format" option has changed from
-"one-answer" to "many-answers". If you have slave servers that do not
-understand the many-answers zone transfer format (e.g., BIND 4.9.5 or
-older) you need to explicitly specify "transfer-format one-answer;" in
-either the options block or a server statement.
-
-1.2. Handling of Configuration File Errors
-
-In BIND 9, named refuses to start if it detects an error in
-named.conf. Earlier versions would start despite errors, causing the
-server to run with a partial configuration. Errors detected during
-subsequent reloads do not cause the server to exit.
-
-Errors in master files do not cause the server to exit, but they
-do cause the zone not to load.
-
-1.3. Logging
-
-The set of logging categories in BIND 9 is different from that
-in BIND 8. If you have customised your logging on a per-category
-basis, you need to modify your logging statement to use the
-new categories.
-
-Another difference is that the "logging" statement only takes effect
-after the entire named.conf file has been read. This means that when
-the server starts up, any messages about errors in the configuration
-file are always logged to the default destination (syslog) when the
-server first starts up, regardless of the contents of the "logging"
-statement. In BIND 8, the new logging configuration took effect
-immediately after the "logging" statement was read.
-
-1.4. Notify messages and Refresh queries
-
-The source address and port for these is now controlled by
-"notify-source" and "transfer-source", respectively, rather that
-query-source as in BIND 8.
-
-1.5. Multiple Classes.
-
-Multiple classes have to be put into explicit views for each class.
-
-
-2. Zone File Compatibility
-
-2.1. Strict RFC1035 Interpretation of TTLs in Zone Files
-
-BIND 9 strictly complies with the RFC1035 and RFC2308 rules regarding
-omitted TTLs in zone files. Omitted TTLs are replaced by the value
-specified with the $TTL directive, or by the previous explicit TTL if
-there is no $TTL directive.
-
-If there is no $TTL directive and the first RR in the file does not
-have an explicit TTL field, the zone file is illegal according to
-RFC1035 since the TTL of the first RR is undefined. Unfortunately,
-BIND 4 and many versions of BIND 8 accept such files without warning
-and use the value of the SOA MINTTL field as a default for missing TTL
-values.
-
-BIND 9.0 and 9.1 completely refused to load such files. BIND 9.2
-emulates the nonstandard BIND 4/8 SOA MINTTL behaviour and loads the
-files anyway (provided the SOA is the first record in the file), but
-will issue the warning message "no TTL specified; using SOA MINTTL
-instead".
-
-To avoid problems, we recommend that you use a $TTL directive in each
-zone file.
-
-2.2. Periods in SOA Serial Numbers Deprecated
-
-Some versions of BIND allow SOA serial numbers with an embedded
-period, like "3.002", and convert them into integers in a rather
-unintuitive way. This feature is not supported by BIND 9; serial
-numbers must be integers.
-
-2.3. Handling of Unbalanced Quotes
-
-TXT records with unbalanced quotes, like 'host TXT "foo', were not
-treated as errors in some versions of BIND. If your zone files
-contain such records, you will get potentially confusing error
-messages like "unexpected end of file" because BIND 9 will interpret
-everything up to the next quote character as a literal string.
-
-2.4. Handling of Line Breaks
-
-Some versions of BIND accept RRs containing line breaks that are not
-properly quoted with parentheses, like the following SOA:
-
- @ IN SOA ns.example. hostmaster.example.
- ( 1 3600 1800 1814400 3600 )
-
-This is not legal master file syntax and will be treated as an error
-by BIND 9. The fix is to move the opening parenthesis to the first
-line.
-
-2.5. Unimplemented BIND 8 Extensions
-
-$GENERATE: The "$$" construct for getting a literal $ into a domain
-name is deprecated. Use \$ instead.
-
-2.6. TXT records are no longer automatically split.
-
-Some versions of BIND accepted strings in TXT RDATA consisting of more
-than 255 characters and silently split them to be able to encode the
-strings in a protocol conformant way. You may now see errors like this
- dns_rdata_fromtext: local.db:119: ran out of space
-if you have TXT RRs with too longs strings. Make sure to split the
-string in the zone data file at or before a single one reaches 255
-characters.
-
-3. Interoperability Impact of New Protocol Features
-
-3.1. EDNS0
-
-BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size. It
-also sets an EDNS flag bit in queries to indicate that it wishes to
-receive DNSSEC responses; this flag bit usage is not yet standardised,
-but we hope it will be.
-
-Most older servers that do not support EDNS0, including prior versions
-of BIND, will send a FORMERR or NOTIMP response to these queries.
-When this happens, BIND 9 will automatically retry the query without
-EDNS0.
-
-Unfortunately, there exists at least one non-BIND name server
-implementation that silently ignores these queries instead of sending
-an error response. Resolving names in zones where all or most
-authoritative servers use this server will be very slow or fail
-completely. We have contacted the manufacturer of the name server in
-case, and they are working on a solution.
-
-When BIND 9 communicates with a server that does support EDNS0, such as
-another BIND 9 server, responses of up to 4096 bytes may be
-transmitted as a single UDP datagram which is subject to fragmentation
-at the IP level. If a firewall incorrectly drops IP fragments, it can
-cause resolution to slow down dramatically or fail.
-
-3.2. Zone Transfers
-
-Outgoing zone transfers now use the "many-answers" format by default.
-This format is not understood by certain old versions of BIND 4.
-You can work around this problem using the option "transfer-format
-one-answer;", but since these old versions all have known security
-problems, the correct fix is to upgrade the slave servers.
-
-Zone transfers to Windows 2000 DNS servers sometimes fail due to a
-bug in the Windows 2000 DNS server where DNS messages larger than
-16K are not handled properly. Obtain the latest service pack for
-Windows 2000 from Microsoft to address this issue. In the meantime,
-the problem can be worked around by setting "transfer-format one-answer;".
-http://support.microsoft.com/default.aspx?scid=kb;en-us;297936
-
-4. Unrestricted Character Set
-
-BIND 9 does not restrict the character set of domain names - it is
-fully 8-bit clean in accordance with RFC2181 section 11.
-
-It is strongly recommended that hostnames published in the DNS follow
-the RFC952 rules, but BIND 9 will not enforce this restriction.
-
-Historically, some applications have suffered from security flaws
-where data originating from the network, such as names returned by
-gethostbyaddr(), are used with insufficient checking and may cause a
-breach of security when containing unexpected characters; see
-<http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers.html>
-for details. Some earlier versions of BIND attempt to protect these
-flawed applications from attack by discarding data containing
-characters deemed inappropriate in host names or mail addresses, under
-the control of the "check-names" option in named.conf and/or "options
-no-check-names" in resolv.conf. BIND 9 provides no such protection;
-if applications with these flaws are still being used, they should
-be upgraded.
-
-
-5. Server Administration Tools
-
-5.1 Ndc Replaced by Rndc
-
-The "ndc" program has been replaced by "rndc", which is capable of
-remote operation. Unlike ndc, rndc requires a configuration file.
-The easiest way to generate a configuration file is to run
-"rndc-confgen -a"; see the man pages for rndc(8), rndc-confgen(8),
-and rndc.conf(5) for details.
-
-5.2. Nsupdate Differences
-
-The BIND 8 implementation of nsupdate had an undocumented feature
-where an update request would be broken down into multiple requests
-based upon the discovered zones that contained the records. This
-behaviour has not been implemented in BIND 9. Each update request
-must pertain to a single zone, but it is still possible to do multiple
-updates in a single invocation of nsupdate by terminating each update
-with an empty line or a "send" command.
-
-
-6. No Information Leakage between Zones
-
-BIND 9 stores the authoritative data for each zone in a separate data
-structure, as recommended in RFC1035 and as required by DNSSEC and
-IXFR. When a BIND 9 server is authoritative for both a child zone and
-its parent, it will have two distinct sets of NS records at the
-delegation point: the authoritative NS records at the child's apex,
-and a set of glue NS records in the parent.
-
-BIND 8 was unable to properly distinguish between these two sets of NS
-records and would "leak" the child's NS records into the parent,
-effectively causing the parent zone to be silently modified: responses
-and zone transfers from the parent contained the child's NS records
-rather than the glue configured into the parent (if any). In the case
-of children of type "stub", this behaviour was documented as a feature,
-allowing the glue NS records to be omitted from the parent
-configuration.
-
-Sites that were relying on this BIND 8 behaviour need to add any
-omitted glue NS records, and any necessary glue A records, to the
-parent zone.
-
-Although stub zones can no longer be used as a mechanism for injecting
-NS records into their parent zones, they are still useful as a way of
-directing queries for a given domain to a particular set of name
-servers.
-
-
-7. Umask not Modified
-
-The BIND 8 named unconditionally sets the umask to 022. BIND 9 does
-not; the umask inherited from the parent process remains in effect.
-This may cause files created by named, such as journal files, to be
-created with different file permissions than they did in BIND 8. If
-necessary, the umask should be set explicitly in the script used to
-start the named process.
-
-
-$Id: migration,v 1.37.2.3.2.3 2004/11/22 22:33:09 marka Exp $
diff --git a/contrib/bind9/doc/misc/migration-4to9 b/contrib/bind9/doc/misc/migration-4to9
deleted file mode 100644
index fa75bacb7013d..0000000000000
--- a/contrib/bind9/doc/misc/migration-4to9
+++ /dev/null
@@ -1,57 +0,0 @@
-Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2001 Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-$Id: migration-4to9,v 1.3.206.1 2004/03/06 13:16:19 marka Exp $
-
- BIND 4 to BIND 9 Migration Notes
-
-To transition from BIND 4 to BIND 9 you first need to convert your
-configuration file to the new format. There is a conversion tool in
-contrib/named-bootconf that allows you to do this.
-
- named-bootconf.sh < /etc/named.boot > /etc/named.conf
-
-BIND 9 uses a system assigned port for the UDP queries it makes rather
-than port 53 that BIND 4 uses. This may conflict with some firewalls.
-The following directives in /etc/named.conf allows you to specify
-a port to use.
-
- query-source address * port 53;
- transfer-source * port 53;
- notify-source * port 53;
-
-BIND 9 no longer uses the minimum field to specify the TTL of records
-without a explicit TTL. Use the $TTL directive to specify a default TTL
-before the first record without a explicit TTL.
-
- $TTL 3600
- @ IN SOA ns1.example.com. hostmaster.example.com. (
- 2001021100
- 7200
- 1200
- 3600000
- 7200 )
-
-BIND 9 does not support multiple CNAMEs with the same owner name.
-
- Illegal:
- www.example.com. CNAME host1.example.com.
- www.example.com. CNAME host2.example.com.
-
-BIND 9 does not support "CNAMEs with other data" with the same owner name,
-ignoring the DNSSEC records (SIG, NXT, KEY) that BIND 4 did not support.
-
- Illegal:
- www.example.com. CNAME host1.example.com.
- www.example.com. MX 10 host2.example.com.
-
-BIND 9 is less tolerant of errors in master files, so check your logs and
-fix any errors reported. The named-checkzone program can also be to check
-master files.
-
-Outgoing zone transfers now use the "many-answers" format by default.
-This format is not understood by certain old versions of BIND 4.
-You can work around this problem using the option "transfer-format
-one-answer;", but since these old versions all have known security
-problems, the correct fix is to upgrade the slave servers.
diff --git a/contrib/bind9/doc/misc/options b/contrib/bind9/doc/misc/options
deleted file mode 100644
index 01546b72644ce..0000000000000
--- a/contrib/bind9/doc/misc/options
+++ /dev/null
@@ -1,386 +0,0 @@
-
-This is a summary of the named.conf options supported by
-this version of BIND 9.
-
-options {
- avoid-v4-udp-ports { <port>; ... };
- avoid-v6-udp-ports { <port>; ... };
- blackhole { <address_match_element>; ... };
- coresize <size>;
- datasize <size>;
- deallocate-on-exit <boolean>; // obsolete
- directory <quoted_string>;
- dump-file <quoted_string>;
- fake-iquery <boolean>; // obsolete
- files <size>;
- has-old-clients <boolean>; // obsolete
- heartbeat-interval <integer>;
- host-statistics <boolean>; // not implemented
- host-statistics-max <integer>; // 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>;
- multiple-cnames <boolean>; // obsolete
- named-xfer <quoted_string>; // obsolete
- pid-file ( <quoted_string> | none );
- port <integer>;
- querylog <boolean>;
- recursing-file <quoted_string>;
- random-device <quoted_string>;
- recursive-clients <integer>;
- serial-queries <integer>; // obsolete
- 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>;
- treat-cr-as-space <boolean>; // obsolete
- use-id-pool <boolean>; // obsolete
- use-ixfr <boolean>;
- version ( <quoted_string> | none );
- flush-zones-on-shutdown <boolean>;
- allow-recursion { <address_match_element>; ... };
- allow-v6-synthesis { <address_match_element>; ... }; // obsolete
- 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>;
- fetch-glue <boolean>; // obsolete
- 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>;
- allow-query { <address_match_element>; ... };
- allow-transfer { <address_match_element>; ... };
- allow-update-forwarding { <address_match_element>; ... };
- 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> ]; ... };
- dialup <dialuptype>;
- forward ( first | only );
- forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
- [ port <integer> ]; ... };
- ixfr-from-differences <boolean>;
- maintain-ixfr-base <boolean>; // obsolete
- max-ixfr-log-size <size>; // obsolete
- 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> | * ) ];
- 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>;
-};
-
-controls {
- inet ( <ipv4_address> | <ipv6_address> | * ) [ port ( <integer> | *
- ) ] allow { <address_match_element>; ... } [ keys { <string>; ... } ];
- unix <unsupported>; // not implemented
-};
-
-acl <string> { <address_match_element>; ... };
-
-masters <string> [ port <integer> ] { ( <masters> | <ipv4_address> [port
- <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
-
-logging {
- channel <string> {
- file <log_file>;
- syslog <optional_facility>;
- null;
- stderr;
- severity <log_severity>;
- print-time <boolean>;
- print-severity <boolean>;
- print-category <boolean>;
- };
- category <string> { <string>; ... };
-};
-
-view <string> <optional_class> {
- match-clients { <address_match_element>; ... };
- match-destinations { <address_match_element>; ... };
- match-recursive-only <boolean>;
- key <string> {
- algorithm <string>;
- secret <string>;
- };
- zone <string> <optional_class> {
- type ( master | slave | stub | hint | forward |
- delegation-only );
- allow-update { <address_match_element>; ... };
- file <quoted_string>;
- ixfr-base <quoted_string>; // obsolete
- ixfr-tmp-file <quoted_string>; // obsolete
- masters [ port <integer> ] { ( <masters> | <ipv4_address>
- [port <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
- pubkey <integer> <integer> <integer> <quoted_string>; //
- obsolete
- update-policy { ( grant | deny ) <string> ( name |
- subdomain | wildcard | self ) <string> <rrtypelist>; ... };
- database <string>;
- delegation-only <boolean>;
- check-names ( fail | warn | ignore );
- allow-query { <address_match_element>; ... };
- allow-transfer { <address_match_element>; ... };
- allow-update-forwarding { <address_match_element>; ... };
- 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> ]; ... };
- dialup <dialuptype>;
- forward ( first | only );
- forwarders [ port <integer> ] { ( <ipv4_address> |
- <ipv6_address> ) [ port <integer> ]; ... };
- ixfr-from-differences <boolean>;
- maintain-ixfr-base <boolean>; // obsolete
- max-ixfr-log-size <size>; // obsolete
- 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> | * ) ];
- 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>;
- };
- server <netaddr> {
- bogus <boolean>;
- provide-ixfr <boolean>;
- request-ixfr <boolean>;
- support-ixfr <boolean>; // obsolete
- transfers <integer>;
- transfer-format ( many-answers | one-answer );
- keys <server_key>;
- edns <boolean>;
- transfer-source ( <ipv4_address> | * ) [ port ( <integer> |
- * ) ];
- transfer-source-v6 ( <ipv6_address> | * ) [ port (
- <integer> | * ) ];
- };
- trusted-keys { <string> <integer> <integer> <integer>
- <quoted_string>; ... };
- allow-recursion { <address_match_element>; ... };
- allow-v6-synthesis { <address_match_element>; ... }; // obsolete
- 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>;
- fetch-glue <boolean>; // obsolete
- 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>;
- allow-query { <address_match_element>; ... };
- allow-transfer { <address_match_element>; ... };
- allow-update-forwarding { <address_match_element>; ... };
- 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> ]; ... };
- dialup <dialuptype>;
- forward ( first | only );
- forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
- [ port <integer> ]; ... };
- ixfr-from-differences <boolean>;
- maintain-ixfr-base <boolean>; // obsolete
- max-ixfr-log-size <size>; // obsolete
- 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> | * ) ];
- 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>;
-};
-
-lwres {
- listen-on [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
- [ port <integer> ]; ... };
- view <string> <optional_class>;
- search { <string>; ... };
- ndots <integer>;
-};
-
-key <string> {
- algorithm <string>;
- secret <string>;
-};
-
-zone <string> <optional_class> {
- type ( master | slave | stub | hint | forward | delegation-only );
- allow-update { <address_match_element>; ... };
- file <quoted_string>;
- ixfr-base <quoted_string>; // obsolete
- ixfr-tmp-file <quoted_string>; // obsolete
- masters [ port <integer> ] { ( <masters> | <ipv4_address> [port
- <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
- pubkey <integer> <integer> <integer> <quoted_string>; // obsolete
- update-policy { ( grant | deny ) <string> ( name | subdomain |
- wildcard | self ) <string> <rrtypelist>; ... };
- database <string>;
- delegation-only <boolean>;
- check-names ( fail | warn | ignore );
- allow-query { <address_match_element>; ... };
- allow-transfer { <address_match_element>; ... };
- allow-update-forwarding { <address_match_element>; ... };
- 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> ]; ... };
- dialup <dialuptype>;
- forward ( first | only );
- forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
- [ port <integer> ]; ... };
- ixfr-from-differences <boolean>;
- maintain-ixfr-base <boolean>; // obsolete
- max-ixfr-log-size <size>; // obsolete
- 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> | * ) ];
- 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>;
-};
-
-server <netaddr> {
- bogus <boolean>;
- provide-ixfr <boolean>;
- request-ixfr <boolean>;
- support-ixfr <boolean>; // obsolete
- transfers <integer>;
- transfer-format ( many-answers | one-answer );
- keys <server_key>;
- edns <boolean>;
- transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
- transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-};
-
-trusted-keys { <string> <integer> <integer> <integer> <quoted_string>; ... };
-
diff --git a/contrib/bind9/doc/misc/rfc-compliance b/contrib/bind9/doc/misc/rfc-compliance
deleted file mode 100644
index 6a3fac12f96ee..0000000000000
--- a/contrib/bind9/doc/misc/rfc-compliance
+++ /dev/null
@@ -1,62 +0,0 @@
-Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2001 Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-$Id: rfc-compliance,v 1.3.206.1 2004/03/06 13:16:20 marka Exp $
-
-BIND 9 is striving for strict compliance with IETF standards. We
-believe this release of BIND 9 complies with the following RFCs, with
-the caveats and exceptions listed in the numbered notes below. Note
-that a number of these RFCs do not have the status of Internet
-standards but are proposed or draft standards, experimental RFCs,
-or Best Current Practice (BCP) documents.
-
- RFC1034
- RFC1035 [1] [2]
- RFC1123
- RFC1183
- RFC1535
- RFC1536
- RFC1706
- RFC1712
- RFC1750
- RFC1876
- RFC1982
- RFC1995
- RFC1996
- RFC2136
- RFC2163
- RFC2181
- RFC2230
- RFC2308
- RFC2535 [3] [4]
- RFC2536
- RFC2537
- RFC2538
- RFC2539
- RFC2671
- RFC2672
- RFC2673
- RFC2782
- RFC2915
- RFC2930
- RFC2931 [5]
- RFC3007
-
-
-[1] Queries to zones that have failed to load return SERVFAIL rather
-than a non-authoritative response. This is considered a feature.
-
-[2] CLASS ANY queries are not supported. This is considered a feature.
-
-[3] Wildcard records are not supported in DNSSEC secure zones.
-
-[4] Servers authoritative for secure zones being resolved by BIND 9
-must support EDNS0 (RFC2671), and must return all relevant SIGs and
-NXTs in responses rather than relying on the resolving server to
-perform separate queries for missing SIGs and NXTs.
-
-[5] When receiving a query signed with a SIG(0), the server will only
-be able to verify the signature if it has the key in its local
-authoritative data; it will not do recursion or validation to
-retrieve unknown keys.
diff --git a/contrib/bind9/doc/misc/roadmap b/contrib/bind9/doc/misc/roadmap
deleted file mode 100644
index 72021b82f662c..0000000000000
--- a/contrib/bind9/doc/misc/roadmap
+++ /dev/null
@@ -1,47 +0,0 @@
-Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001 Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-$Id: roadmap,v 1.1.206.1 2004/03/06 13:16:20 marka Exp $
-
-Road Map to the BIND 9 Source Tree
-
-bin/named The name server. This relies heavily on the
- libraries in lib/isc and lib/dns.
- client.c Handling of incoming client requests
- query.c Query processing
-bin/rndc The remote name daemon control program
-bin/dig The "dig" program
-bin/dnssec The DNSSEC signer and other DNSSEC tools
-bin/nsupdate The "nsupdate" program
-bin/tests Test suites and miscellaneous test programs
-bin/tests/system System tests; see bin/tests/system/README
-lib/dns The DNS library
- resolver.c The "full resolver" (performs recursive lookups)
- validator.c The DNSSEC validator
- db.c The database interface
- sdb.c The simple database interface
- rbtdb.c The red-black tree database
-lib/dns/rdata Routines for handling the various RR types
-lib/dns/sec Cryptographic libraries for DNSSEC
-lib/isc The ISC library
- task.c Task library
- unix/socket.c Unix implementation of socket library
-lib/isccfg Routines for reading and writing ISC-style
- configuration files like named.conf and rndc.conf
-lib/isccc The command channel library, used by rndc.
-lib/tests Support code for the test suites.
-lib/lwres The lightweight resolver library.
-doc/draft Current internet-drafts pertaining to the DNS
-doc/rfc RFCs pertaining to the DNS
-doc/misc Miscellaneous documentation
-doc/arm The BIND 9 Administrator Reference Manual
-doc/man Man pages
-contrib Contributed and other auxiliary code
-contrib/idn/mdnkit The multilingual domain name evaluation kit
-contrib/sdb Sample drivers for the simple database interface
-make Makefile fragments, used by configure
-
-The library interfaces are mainly documented in the form of comments
-in the header files. For example, the task subsystem is documented in
-lib/isc/include/isc/task.h
diff --git a/contrib/bind9/doc/misc/sdb b/contrib/bind9/doc/misc/sdb
deleted file mode 100644
index 0de0ab8943c6f..0000000000000
--- a/contrib/bind9/doc/misc/sdb
+++ /dev/null
@@ -1,169 +0,0 @@
-Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001 Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-Using the BIND 9 Simplified Database Interface
-
-This document describes the care and feeding of the BIND 9 Simplified
-Database Interface, which allows you to extend BIND 9 with new ways
-of obtaining the data that is published as DNS zones.
-
-
-The Original BIND 9 Database Interface
-
-BIND 9 has a well-defined "back-end database interface" that makes it
-possible to replace the component of the name server responsible for
-the storage and retrieval of zone data, called the "database", on a
-per-zone basis. The default database is an in-memory, red-black-tree
-data structure commonly referred to as "rbtdb", but it is possible to
-write drivers to support any number of alternative database
-technologies such as in-memory hash tables, application specific
-persistent on-disk databases, object databases, or relational
-databases.
-
-The original BIND 9 database interface defined in <dns/db.h> is
-designed to efficiently support the full set of database functionality
-needed by a name server that implements the complete DNS protocols,
-including features such as zone transfers, dynamic update, and DNSSEC.
-Each of these aspects of name server operations places its own set of
-demands on the data store, with the result that the database API is
-quite complex and contains operations that are highly specific to the
-DNS. For example, data are stored in a binary format, the name space
-is tree structured, and sets of data records are conceptually
-associated with DNSSEC signature sets. For these reasons, writing a
-driver using this interface is a highly nontrivial undertaking.
-
-
-The Simplified Database Interface
-
-Many BIND users wish to provide access to various data sources through
-the DNS, but are not necessarily interested in completely replacing
-the in-memory "rbt" database or in supporting features like dynamic
-update, DNSSEC, or even zone transfers.
-
-Often, all you want is limited, read-only DNS access to an existing
-system. For example, you may have an existing relational database
-containing hostname/address mappings and wish to provide forvard and
-reverse DNS lookups based on this information. Or perhaps you want to
-set up a simple DNS-based load balancing system where the name server
-answers queries about a single DNS name with a dynamically changing
-set of A records.
-
-BIND 9.1 introduced a new, simplified database interface, or "sdb",
-which greatly simplifies the writing of drivers for these kinds of
-applications.
-
-
-The sdb Driver
-
-An sdb driver is an object module, typically written in C, which is
-linked into the name server and registers itself with the sdb
-subsystem. It provides a set of callback functions, which also serve
-to advertise its capabilities. When the name server receives DNS
-queries, invokes the callback functions to obtain the data to respond
-with.
-
-Unlike the full database interface, the sdb interface represents all
-domain names and resource records as ASCII text.
-
-
-Writing an sdb Driver
-
-When a driver is registered, it specifies its name, a list of callback
-functions, and flags.
-
-The flags specify whether the driver wants to use relative domain
-names where possible.
-
-The callback functions are as follows. The only one that must be
-defined is lookup().
-
- - create(zone, argc, argv, driverdata, dbdata)
- Create a database object for "zone".
-
- - destroy(zone, driverdata, dbdata)
- Destroy the database object for "zone".
-
- - lookup(zone, name, dbdata, lookup)
- Return all the records at the domain name "name".
-
- - authority(zone, dbdata, lookup)
- Return the SOA and NS records at the zone apex.
-
- - allnodes(zone, dbdata, allnodes)
- Return all data in the zone, for zone transfers.
-
-For more detail about these functions and their parameters, see
-bind9/lib/dns/include/dns/sdb.h. For example drivers, see
-bind9/contrib/sdb.
-
-
-Rebuilding the Server
-
-The driver module and header file must be copied to (or linked into)
-the bind9/bin/named and bind9/bin/named/include directories
-respectively, and must be added to the DBDRIVER_OBJS and DBDRIVER_SRCS
-lines in bin/named/Makefile.in (e.g. for the timedb sample sdb driver,
-add timedb.c to DBDRIVER_SRCS and timedb.@O@ to DBDRIVER_OBJS). If
-the driver needs additional header files or libraries in nonstandard
-places, the DBDRIVER_INCLUDES and DBDRIVER_LIBS lines should also be
-updated.
-
-Calls to dns_sdb_register() and dns_sdb_unregister() (or wrappers,
-e.g. timedb_init() and timedb_clear() for the timedb sample sdb
-driver) must be inserted into the server, in bind9/bin/named/main.c.
-Registration should be in setup(), before the call to
-ns_server_create(). Unregistration should be in cleanup(),
-after the call to ns_server_destroy(). A #include should be added
-corresponding to the driver header file.
-
-You should try doing this with one or more of the sample drivers
-before attempting to write a driver of your own.
-
-
-Configuring the Server
-
-To make a zone use a new database driver, specify a "database" option
-in its "zone" statement in named.conf. For example, if the driver
-registers itself under the name "acmedb", you might say
-
- zone "foo.com" {
- database "acmedb";
- };
-
-You can pass arbitrary arguments to the create() function of the
-driver by adding any number of whitespace-separated words after the
-driver name:
-
- zone "foo.com" {
- database "acmedb -mode sql -connect 10.0.0.1";
- };
-
-
-Hints for Driver Writers
-
- - If a driver is generating data on the fly, it probably should
- not implement the allnodes() function, since a zone transfer
- will not be meaningful. The allnodes() function is more relevant
- with data from a database.
-
- - The authority() function is necessary if and only if the lookup()
- function will not add SOA and NS records at the zone apex. If
- SOA and NS records are provided by the lookup() function,
- the authority() function should be NULL.
-
- - When a driver is registered, an opaque object can be provided. This
- object is passed into the database create() and destroy() functions.
-
- - When a database is created, an opaque object can be created that
- is associated with that database. This object is passed into the
- lookup(), authority(), and allnodes() functions, and is
- destroyed by the destroy() function.
-
-
-Future Directions
-
-A future release may support dynamic loading of sdb drivers.
-
-
-$Id: sdb,v 1.5.206.1 2004/03/06 13:16:20 marka Exp $
diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index
deleted file mode 100644
index 5c588db930169..0000000000000
--- a/contrib/bind9/doc/rfc/index
+++ /dev/null
@@ -1,103 +0,0 @@
- 952: DOD INTERNET HOST TABLE SPECIFICATION
-1032: DOMAIN ADMINISTRATORS GUIDE
-1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
-1034: DOMAIN NAMES - CONCEPTS AND FACILITIES
-1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-1101: DNS Encoding of Network Names and Other Types
-1122: Requirements for Internet Hosts -- Communication Layers
-1123: Requirements for Internet Hosts -- Application and Support
-1183: New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT)
-1348: DNS NSAP RRs
-1535: A Security Problem and Proposed Correction
- With Widely Deployed DNS Software
-1536: Common DNS Implementation Errors and Suggested Fixes
-1537: Common DNS Data File Configuration Errors
-1591: Domain Name System Structure and Delegation
-1611: DNS Server MIB Extensions
-1612: DNS Resolver MIB Extensions
-1706: DNS NSAP Resource Records
-1712: DNS Encoding of Geographical Location
-1750: Randomness Recommendations for Security
-1876: A Means for Expressing Location Information in the Domain Name System
-1886: DNS Extensions to support IP version 6
-1982: Serial Number Arithmetic
-1995: Incremental Zone Transfer in DNS
-1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
-2052: A DNS RR for specifying the location of services (DNS SRV)
-2104: HMAC: Keyed-Hashing for Message Authentication
-2119: Key words for use in RFCs to Indicate Requirement Levels
-2133: Basic Socket Interface Extensions for IPv6
-2136: Dynamic Updates in the Domain Name System (DNS UPDATE)
-2137: Secure Domain Name System Dynamic Update
-2163: Using the Internet DNS to Distribute MIXER
- Conformant Global Address Mapping (MCGAM)
-2168: Resolution of Uniform Resource Identifiers using the Domain Name System
-2181: Clarifications to the DNS Specification
-2230: Key Exchange Delegation Record for the DNS
-2308: Negative Caching of DNS Queries (DNS NCACHE)
-2317: Classless IN-ADDR.ARPA delegation
-2373: IP Version 6 Addressing Architecture
-2374: An IPv6 Aggregatable Global Unicast Address Format
-2375: IPv6 Multicast Address Assignments
-2418: IETF Working Group Guidelines and Procedures
-2535: Domain Name System Security Extensions
-2536: DSA KEYs and SIGs in the Domain Name System (DNS)
-2537: RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
-2538: Storing Certificates in the Domain Name System (DNS)
-2539: Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
-2540: Detached Domain Name System (DNS) Information
-2541: DNS Security Operational Considerations
-2553: Basic Socket Interface Extensions for IPv6
-2671: Extension Mechanisms for DNS (EDNS0)
-2672: Non-Terminal DNS Name Redirection
-2673: Binary Labels in the Domain Name System
-2782: A DNS RR for specifying the location of services (DNS SRV)
-2825: A Tangled Web: Issues of I18N, Domain Names, and the
- Other Internet protocols
-2826: IAB Technical Comment on the Unique DNS Root
-2845: Secret Key Transaction Authentication for DNS (TSIG)
-2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering
-2915: The Naming Authority Pointer (NAPTR) DNS Resource Record
-2929: Domain Name System (DNS) IANA Considerations
-2930: Secret Key Establishment for DNS (TKEY RR)
-2931: DNS Request and Transaction Signatures ( SIG(0)s )
-3007: Secure Domain Name System (DNS) Dynamic Update
-3008: Domain Name System Security (DNSSEC) Signing Authority
-3071: Reflections on the DNS, RFC 1591, and Categories of Domains
-3090: DNS Security Extension Clarification on Zone Status
-3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
-3123: A DNS RR Type for Lists of Address Prefixes (APL RR)
-3152: Delegation of IP6.ARPA
-3197: Applicability Statement for DNS MIB Extensions
-3225: Indicating Resolver Support of DNSSEC
-3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements
-3258: Distributing Authoritative Name Servers via Shared Unicast Addresses
-3363: Representing Internet Protocol version 6 (IPv6)
- Addresses in the Domain Name System (DNS)
-3364: Tradeoffs in Domain Name System (DNS) Support
- for Internet Protocol version 6 (IPv6)
-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)
-3493: Basic Socket Interface Extensions for IPv6
-3513: Internet Protocol Version 6 (IPv6) Addressing Architecture
-3596: DNS Extensions to Support IP Version 6
-3597: Handling of Unknown DNS Resource Record (RR) Types
-3645: Generic Security Service Algorithm for
- 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/rfc1032.txt b/contrib/bind9/doc/rfc/rfc1032.txt
deleted file mode 100644
index 0e82721cee712..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1032.txt
+++ /dev/null
@@ -1,781 +0,0 @@
-Network Working Group M. Stahl
-Request for Comments: 1032 SRI International
- November 1987
-
-
- DOMAIN ADMINISTRATORS GUIDE
-
-
-STATUS OF THIS MEMO
-
- This memo describes procedures for registering a domain with the
- Network Information Center (NIC) of Defense Data Network (DDN), and
- offers guidelines on the establishment and administration of a domain
- in accordance with the requirements specified in RFC-920. It is
- intended for use by domain administrators. This memo should be used
- in conjunction with RFC-920, which is an official policy statement of
- the Internet Activities Board (IAB) and the Defense Advanced Research
- Projects Agency (DARPA). Distribution of this memo is unlimited.
-
-BACKGROUND
-
- Domains are administrative entities that provide decentralized
- management of host naming and addressing. The domain-naming system
- is distributed and hierarchical.
-
- The NIC is designated by the Defense Communications Agency (DCA) to
- provide registry services for the domain-naming system on the DDN and
- DARPA portions of the Internet.
-
- As registrar of top-level and second-level domains, as well as
- administrator of the root domain name servers on behalf of DARPA and
- DDN, the NIC is responsible for maintaining the root server zone
- files and their binary equivalents. In addition, the NIC is
- responsible for administering the top-level domains of "ARPA," "COM,"
- "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
- becomes feasible for other appropriate organizations to assume those
- responsibilities.
-
- It is recommended that the guidelines described in this document be
- used by domain administrators in the establishment and control of
- second-level domains.
-
-THE DOMAIN ADMINISTRATOR
-
- The role of the domain administrator (DA) is that of coordinator,
- manager, and technician. If his domain is established at the second
- level or lower in the tree, the DA must register by interacting with
- the management of the domain directly above his, making certain that
-
-
-
-Stahl [Page 1]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- his domain satisfies all the requirements of the administration under
- which his domain would be situated. To find out who has authority
- over the name space he wishes to join, the DA can ask the NIC
- Hostmaster. Information on contacts for the top-level and second-
- level domains can also be found on line in the file NETINFO:DOMAIN-
- CONTACTS.TXT, which is available from the NIC via anonymous FTP.
-
- The DA should be technically competent; he should understand the
- concepts and procedures for operating a domain server, as described
- in RFC-1034, and make sure that the service provided is reliable and
- uninterrupted. It is his responsibility or that of his delegate to
- ensure that the data will be current at all times. As a manager, the
- DA must be able to handle complaints about service provided by his
- domain name server. He must be aware of the behavior of the hosts in
- his domain, and take prompt action on reports of problems, such as
- protocol violations or other serious misbehavior. The administrator
- of a domain must be a responsible person who has the authority to
- either enforce these actions himself or delegate them to someone
- else.
-
- Name assignments within a domain are controlled by the DA, who should
- verify that names are unique within his domain and that they conform
- to standard naming conventions. He furnishes access to names and
- name-related information to users both inside and outside his domain.
- He should work closely with the personnel he has designated as the
- "technical and zone" contacts for his domain, for many administrative
- decisions will be made on the basis of input from these people.
-
-THE DOMAIN TECHNICAL AND ZONE CONTACT
-
- A zone consists of those contiguous parts of the domain tree for
- which a domain server has complete information and over which it has
- authority. A domain server may be authoritative for more than one
- zone. The domain technical/zone contact is the person who tends to
- the technical aspects of maintaining the domain's name server and
- resolver software, and database files. He keeps the name server
- running, and interacts with technical people in other domains and
- zones to solve problems that affect his zone.
-
-POLICIES
-
- Domain or host name choices and the allocation of domain name space
- are considered to be local matters. In the event of conflicts, it is
- the policy of the NIC not to get involved in local disputes or in the
- local decision-making process. The NIC will not act as referee in
- disputes over such matters as who has the "right" to register a
- particular top-level or second-level domain for an organization. The
- NIC considers this a private local matter that must be settled among
-
-
-
-Stahl [Page 2]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- the parties involved prior to their commencing the registration
- process with the NIC. Therefore, it is assumed that the responsible
- person for a domain will have resolved any local conflicts among the
- members of his domain before registering that domain with the NIC.
- The NIC will give guidance, if requested, by answering specific
- technical questions, but will not provide arbitration in disputes at
- the local level. This policy is also in keeping with the distributed
- hierarchical nature of the domain-naming system in that it helps to
- distribute the tasks of solving problems and handling questions.
-
- Naming conventions for hosts should follow the rules specified in
- RFC-952. From a technical standpoint, domain names can be very long.
- Each segment of a domain name may contain up to 64 characters, but
- the NIC strongly advises DAs to choose names that are 12 characters
- or fewer, because behind every domain system there is a human being
- who must keep track of the names, addresses, contacts, and other data
- in a database. The longer the name, the more likely the data
- maintainer is to make a mistake. Users also will appreciate shorter
- names. Most people agree that short names are easier to remember and
- type; most domain names registered so far are 12 characters or fewer.
-
- Domain name assignments are made on a first-come-first-served basis.
- The NIC has chosen not to register individual hosts directly under
- the top-level domains it administers. One advantage of the domain
- naming system is that administration and data maintenance can be
- delegated down a hierarchical tree. Registration of hosts at the
- same level in the tree as a second-level domain would dilute the
- usefulness of this feature. In addition, the administrator of a
- domain is responsible for the actions of hosts within his domain. We
- would not want to find ourselves in the awkward position of policing
- the actions of individual hosts. Rather, the subdomains registered
- under these top-level domains retain the responsibility for this
- function.
-
- Countries that wish to be registered as top-level domains are
- required to name themselves after the two-letter country code listed
- in the international standard ISO-3166. In some cases, however, the
- two-letter ISO country code is identical to a state code used by the
- U.S. Postal Service. Requests made by countries to use the three-
- letter form of country code specified in the ISO-3166 standard will
- be considered in such cases so as to prevent possible conflicts and
- confusion.
-
-
-
-
-
-
-
-
-
-Stahl [Page 3]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
-HOW TO REGISTER
-
- Obtain a domain questionnaire from the NIC hostmaster, or FTP the
- file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
-
- Fill out the questionnaire completely. Return it via electronic mail
- to HOSTMASTER@SRI-NIC.ARPA.
-
- The APPENDIX to this memo contains the application form for
- registering a top-level or second-level domain with the NIC. It
- supersedes the version of the questionnaire found in RFC-920. The
- application should be submitted by the person administratively
- responsible for the domain, and must be filled out completely before
- the NIC will authorize establishment of a top-level or second-level
- domain. The DA is responsible for keeping his domain's data current
- with the NIC or with the registration agent with which his domain is
- registered. For example, the CSNET and UUCP managements act as
- domain filters, processing domain applications for their own
- organizations. They pass pertinent information along periodically to
- the NIC for incorporation into the domain database and root server
- files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
- outlines this procedure. It is highly recommended that the DA review
- this information periodically and provide any corrections or
- additions. Corrections should be submitted via electronic mail.
-
-WHICH DOMAIN NAME?
-
- The designers of the domain-naming system initiated several general
- categories of names as top-level domain names, so that each could
- accommodate a variety of organizations. The current top-level
- domains registered with the DDN Network Information Center are ARPA,
- COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
- domains. To join one of these, a DA needs to be aware of the purpose
- for which it was intended.
-
- "ARPA" is a temporary domain. It is by default appended to the
- names of hosts that have not yet joined a domain. When the system
- was begun in 1984, the names of all hosts in the Official DoD
- Internet Host Table maintained by the NIC were changed by adding
- of the label ".ARPA" in order to accelerate a transition to the
- domain-naming system. Another reason for the blanket name changes
- was to force hosts to become accustomed to using the new style
- names and to modify their network software, if necessary. This
- was done on a network-wide basis and was directed by DCA in DDN
- Management Bulletin No. 22. Hosts that fall into this domain will
- eventually move to other branches of the domain tree.
-
-
-
-
-
-Stahl [Page 4]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- "COM" is meant to incorporate subdomains of companies and
- businesses.
-
- "EDU" was initiated to accommodate subdomains set up by
- universities and other educational institutions.
-
- "GOV" exists to act as parent domain for subdomains set up by
- government agencies.
-
- "MIL" was initiated to act as parent to subdomains that are
- developed by military organizations.
-
- "NET" was introduced as a parent domain for various network-type
- organizations. Organizations that belong within this top-level
- domain are generic or network-specific, such as network service
- centers and consortia. "NET" also encompasses network
- management-related organizations, such as information centers and
- operations centers.
-
- "ORG" exists as a parent to subdomains that do not clearly fall
- within the other top-level domains. This may include technical-
- support groups, professional societies, or similar organizations.
-
- One of the guidelines in effect in the domain-naming system is that a
- host should have only one name regardless of what networks it is
- connected to. This implies, that, in general, domain names should
- not include routing information or addresses. For example, a host
- that has one network connection to the Internet and another to BITNET
- should use the same name when talking to either network. For a
- description of the syntax of domain names, please refer to Section 3
- of RFC-1034.
-
-VERIFICATION OF DATA
-
- The verification process can be accomplished in several ways. One of
- these is through the NIC WHOIS server. If he has access to WHOIS,
- the DA can type the command "whois domain <domain name><return>".
- The reply from WHOIS will supply the following: the name and address
- of the organization "owning" the domain; the name of the domain; its
- administrative, technical, and zone contacts; the host names and
- network addresses of sites providing name service for the domain.
-
-
-
-
-
-
-
-
-
-
-Stahl [Page 5]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- Example:
-
- @whois domain rice.edu<Return>
-
- Rice University (RICE-DOM)
- Advanced Studies and Research
- Houston, TX 77001
-
- Domain Name: RICE.EDU
-
- Administrative Contact:
- Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834
- Technical Contact, Zone Contact:
- Riffle, Vicky R. (VRR) rif@RICE.EDU
- (713) 527-8101 ext 3844
-
- Domain servers:
-
- RICE.EDU 128.42.5.1
- PENDRAGON.CS.PURDUE.EDU 128.10.2.5
-
-
- Alternatively, the DA can send an electronic mail message to
- SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the
- DA should type "whois domain <domain name>". The requested
- information will be returned via electronic mail. This method is
- convenient for sites that do not have access to the NIC WHOIS
- service.
-
- The initial application for domain authorization should be submitted
- via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The
- questionnaire described in the appendix may be used or a separate
- application can be FTPed from host SRI-NIC.ARPA. The information
- provided by the administrator will be reviewed by hostmaster
- personnel for completeness. There will most likely be a few
- exchanges of correspondence via electronic mail, the preferred method
- of communication, prior to authorization of the domain.
-
-HOW TO GET MORE INFORMATION
-
- An informational table of the top-level domains and their root
- servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
- NIC.ARPA. This table can be obtained by FTPing the file.
- Alternatively, the information can be acquired by opening a TCP or
- UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
- and invoking the command "ALL-DOM".
-
-
-
-
-
-Stahl [Page 6]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- The following online files, all available by FTP from SRI-NIC.ARPA,
- contain pertinent domain information:
-
- - NETINFO:DOMAINS.TXT, a table of all top-level domains and the
- network addresses of the machines providing domain name
- service for them. It is updated each time a new top-level
- domain is approved.
-
- - NETINFO:DOMAIN-INFO.TXT contains a concise list of all
- top-level and second-level domain names registered with the
- NIC and is updated monthly.
-
- - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
- top level and second-level domains, but includes the
- administrative, technical and zone contacts for each as well.
-
- - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
- completed before registering a top-level or second-level
- domain.
-
- For either general or specific information on the domain system, do
- one or more of the following:
-
- 1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
-
- 2. Call the toll-free NIC hotline at (800) 235-3155
-
- 3. Use FTP to get background RFCs and other files maintained
- online at the NIC. Some pertinent RFCs are listed below in
- the REFERENCES section of this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl [Page 7]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
-REFERENCES
-
- The references listed here provide important background information
- on the domain-naming system. Path names of the online files
- available via anonymous FTP from the SRI-NIC.ARPA host are noted in
- brackets.
-
- 1. Defense Communications Agency DDN Defense Communications
- System, DDN Management Bulletin No. 22, Domain Names
- Transition, March 1984.
- [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
-
- 2. Defense Communications Agency DDN Defense Communications
- System, DDN Management Bulletin No. 32, Phase I of the Domain
- Name Implementation, January 1987.
- [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
-
- 3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
- Server", RFC-953, DDN Network Information Center, SRI
- International, October 1985. [ RFC:RFC953.TXT ]
-
- 4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
- Internet Host Table Specification", RFC-952, DDN Network
- Information Center, SRI International, October 1985.
- [ RFC:RFC952.TXT ]
-
- 5. ISO, "Codes for the Representation of Names of Countries",
- ISO-3166, International Standards Organization, May 1981.
- [ Not online ]
-
- 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
- Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ]
-
- 7. Lottor, M.K., "Domain Administrators Operations Guide",
- RFC-1033, DDN Network Information Center, SRI International,
- July 1987. [ RFC:RFC1033.TXT ]
-
- 8. Mockapetris, P., "Domain Names - Concepts and Facilities",
- RFC-1034, USC Information Sciences Institute, October 1987.
- [ RFC:RFC1034.TXT ]
-
- 9. Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC-1035, USC Information Sciences Institute,
- October 1987. [ RFC:RFC1035.TXT ]
-
- 10. Mockapetris, P., "The Domain Name System", Proceedings of the
- IFIP 6.5 Working Conference on Computer Message Services,
- Nottingham, England, May 1984. Also as ISI/RS-84-133, June
-
-
-
-Stahl [Page 8]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- 1984. [ Not online ]
-
- 11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
- Design for Distributed Systems", Proceedings of the Seventh
- International Conference on Computer Communication, October
- 30 to November 3 1984, Sidney, Australia. Also as
- ISI/RS-84-132, June 1984. [ Not online ]
-
- 12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
- CSNET-CIC, BBN Laboratories, January 1986.
- [ RFC:RFC974.TXT ]
-
- 13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
- USC Information Sciences Institute, November 1983.
- [ RFC:RFC881.TXT ]
-
- 14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
- USC Information Sciences Institute, May 1986.
- [ RFC:RFC1010.TXT ]
-
- 15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
- SRI, November 1987.
- [ RFC:RFC1020.TXT ]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl [Page 9]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
-APPENDIX
-
- The following questionnaire may be FTPed from SRI-NIC.ARPA as
- NETINFO:DOMAIN-TEMPLATE.TXT.
-
- ---------------------------------------------------------------------
-
- To establish a domain, the following information must be sent to the
- NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
-
- NOTE: The key people must have electronic mailboxes and NIC
- "handles," unique NIC database identifiers. If you have access to
- "WHOIS", please check to see if you are registered and if so, make
- sure the information is current. Include only your handle and any
- changes (if any) that need to be made in your entry. If you do not
- have access to "WHOIS", please provide all the information indicated
- and a NIC handle will be assigned.
-
- (1) The name of the top-level domain to join.
-
- For example: COM
-
- (2) The NIC handle of the administrative head of the organization.
- Alternately, the person's name, title, mailing address, phone number,
- organization, and network mailbox. This is the contact point for
- administrative and policy questions about the domain. In the case of
- a research project, this should be the principal investigator.
-
- For example:
-
- Administrator
-
- Organization The NetWorthy Corporation
- Name Penelope Q. Sassafrass
- Title President
- Mail Address The NetWorthy Corporation
- 4676 Andrews Way, Suite 100
- Santa Clara, CA 94302-1212
- Phone Number (415) 123-4567
- Net Mailbox Sassafrass@ECHO.TNC.COM
- NIC Handle PQS
-
- (3) The NIC handle of the technical contact for the domain.
- Alternately, the person's name, title, mailing address, phone number,
- organization, and network mailbox. This is the contact point for
- problems concerning the domain or zone, as well as for updating
- information about the domain or zone.
-
-
-
-
-Stahl [Page 10]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- For example:
-
- Technical and Zone Contact
-
- Organization The NetWorthy Corporation
- Name Ansel A. Aardvark
- Title Executive Director
- Mail Address The NetWorthy Corporation
- 4676 Andrews Way, Suite 100
- Santa Clara, CA. 94302-1212
- Phone Number (415) 123-6789
- Net Mailbox Aardvark@ECHO.TNC.COM
- NIC Handle AAA2
-
- (4) The name of the domain (up to 12 characters). This is the name
- that will be used in tables and lists associating the domain with the
- domain server addresses. [While, from a technical standpoint, domain
- names can be quite long (programmers beware), shorter names are
- easier for people to cope with.]
-
- For example: TNC
-
- (5) A description of the servers that provide the domain service for
- translating names to addresses for hosts in this domain, and the date
- they will be operational.
-
- A good way to answer this question is to say "Our server is
- supplied by person or company X and does whatever their standard
- issue server does."
-
- For example: Our server is a copy of the one operated by
- the NIC; it will be installed and made operational on
- 1 November 1987.
-
- (6) Domains must provide at least two independent servers for the
- domain. Establishing the servers in physically separate locations
- and on different PSNs is strongly recommended. A description of the
- server machine and its backup, including
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl [Page 11]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- (a) Hardware and software (using keywords from the Assigned
- Numbers RFC).
-
- (b) Host domain name and network addresses (which host on which
- network for each connected network).
-
- (c) Any domain-style nicknames (please limit your domain-style
- nickname request to one)
-
- For example:
-
- - Hardware and software
-
- VAX-11/750 and UNIX, or
- IBM-PC and MS-DOS, or
- DEC-1090 and TOPS-20
-
- - Host domain names and network addresses
-
- BAR.FOO.COM 10.9.0.193 on ARPANET
-
- - Domain-style nickname
-
- BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
-
- (7) Planned mapping of names of any other network hosts, other than
- the server machines, into the new domain's naming space.
-
- For example:
-
- BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
- BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
- BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
-
-
- (8) An estimate of the number of hosts that will be in the domain.
-
- (a) Initially
- (b) Within one year
- (c) Two years
- (d) Five years.
-
- For example:
-
- (a) Initially = 50
- (b) One year = 100
- (c) Two years = 200
- (d) Five years = 500
-
-
-
-Stahl [Page 12]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- (9) The date you expect the fully qualified domain name to become
- the official host name in HOSTS.TXT.
-
- Please note: If changing to a fully qualified domain name (e.g.,
- FOO.BAR.COM) causes a change in the official host name of an
- ARPANET or MILNET host, DCA approval must be obtained beforehand.
- Allow 10 working days for your requested changes to be processed.
-
- ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites
- should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
- further instructions.
-
- (10) Please describe your organization briefly.
-
- For example: The NetWorthy Corporation is a consulting
- organization of people working with UNIX and the C language in an
- electronic networking environment. It sponsors two technical
- conferences annually and distributes a bimonthly newsletter.
-
- ---------------------------------------------------------------------
-
- This example of a completed application corresponds to the examples
- found in the companion document RFC-1033, "Domain Administrators
- Operations Guide."
-
- (1) The name of the top-level domain to join.
-
- COM
-
- (2) The NIC handle of the administrative contact person.
-
- NIC Handle JAKE
-
- (3) The NIC handle of the domain's technical and zone
- contact person.
-
- NIC Handle DLE6
-
- (4) The name of the domain.
-
- SRI
-
- (5) A description of the servers.
-
- Our server is the TOPS20 server JEEVES supplied by ISI; it
- will be installed and made operational on 1 July 1987.
-
-
-
-
-
-Stahl [Page 13]
-
-RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
-
-
- (6) A description of the server machine and its backup:
-
- (a) Hardware and software
-
- DEC-1090T and TOPS20
- DEC-2065 and TOPS20
-
- (b) Host domain name and network address
-
- KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
- STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
-
- (c) Domain-style nickname
-
- None
-
- (7) Planned mapping of names of any other network hosts, other than
- the server machines, into the new domain's naming space.
-
- SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
- SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
-
- (8) An estimate of the number of hosts that will be directly within
- this domain.
-
- (a) Initially = 50
- (b) One year = 100
- (c) Two years = 200
- (d) Five years = 500
-
- (9) A date when you expect the fully qualified domain name to become
- the official host name in HOSTS.TXT.
-
- 31 September 1987
-
- (10) Brief description of organization.
-
- SRI International is an independent, nonprofit, scientific
- research organization. It performs basic and applied research
- for government and commercial clients, and contributes to
- worldwide economic, scientific, industrial, and social progress
- through research and related services.
-
-
-
-
-
-
-
-
-
-Stahl [Page 14]
-
diff --git a/contrib/bind9/doc/rfc/rfc1033.txt b/contrib/bind9/doc/rfc/rfc1033.txt
deleted file mode 100644
index 37029fd9ae01a..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1033.txt
+++ /dev/null
@@ -1,1229 +0,0 @@
-Network Working Group M. Lottor
-Request For Comments: 1033 SRI International
- November 1987
-
-
- DOMAIN ADMINISTRATORS OPERATIONS GUIDE
-
-
-
-STATUS OF THIS MEMO
-
- This RFC provides guidelines for domain administrators in operating a
- domain server and maintaining their portion of the hierarchical
- database. Familiarity with the domain system is assumed.
- Distribution of this memo is unlimited.
-
-ACKNOWLEDGMENTS
-
- This memo is a formatted collection of notes and excerpts from the
- references listed at the end of this document. Of particular mention
- are Paul Mockapetris and Kevin Dunlap.
-
-INTRODUCTION
-
- A domain server requires a few files to get started. It will
- normally have some number of boot/startup files (also known as the
- "safety belt" files). One section will contain a list of possible
- root servers that the server will use to find the up-to-date list of
- root servers. Another section will list the zone files to be loaded
- into the server for your local domain information. A zone file
- typically contains all the data for a particular domain. This guide
- describes the data formats that can be used in zone files and
- suggested parameters to use for certain fields. If you are
- attempting to do anything advanced or tricky, consult the appropriate
- domain RFC's for more details.
-
- Note: Each implementation of domain software may require different
- files. Zone files are standardized but some servers may require
- other startup files. See the appropriate documentation that comes
- with your software. See the appendix for some specific examples.
-
-ZONES
-
- A zone defines the contents of a contiguous section of the domain
- space, usually bounded by administrative boundaries. There will
- typically be a separate data file for each zone. The data contained
- in a zone file is composed of entries called Resource Records (RRs).
-
-
-
-
-Lottor [Page 1]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- You may only put data in your domain server that you are
- authoritative for. You must not add entries for domains other than
- your own (except for the special case of "glue records").
-
- A domain server will probably read a file on start-up that lists the
- zones it should load into its database. The format of this file is
- not standardized and is different for most domain server
- implementations. For each zone it will normally contain the domain
- name of the zone and the file name that contains the data to load for
- the zone.
-
-ROOT SERVERS
-
- A resolver will need to find the root servers when it first starts.
- When the resolver boots, it will typically read a list of possible
- root servers from a file.
-
- The resolver will cycle through the list trying to contact each one.
- When it finds a root server, it will ask it for the current list of
- root servers. It will then discard the list of root servers it read
- from the data file and replace it with the current list it received.
-
- Root servers will not change very often. You can get the names of
- current root servers from the NIC.
-
- FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
- NIC@SRI-NIC.ARPA.
-
- As of this date (June 1987) they are:
-
- SRI-NIC.ARPA 10.0.0.51 26.0.0.73
- C.ISI.EDU 10.0.0.52
- BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
- A.ISI.EDU 26.3.0.103
-
-RESOURCE RECORDS
-
- Records in the zone data files are called resource records (RRs).
- They are specified in RFC-883 and RFC-973. An RR has a standard
- format as shown:
-
- <name> [<ttl>] [<class>] <type> <data>
-
- The record is divided into fields which are separated by white space.
-
- <name>
-
- The name field defines what domain name applies to the given
-
-
-
-Lottor [Page 2]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- RR. In some cases the name field can be left blank and it will
- default to the name field of the previous RR.
-
- <ttl>
-
- TTL stands for Time To Live. It specifies how long a domain
- resolver should cache the RR before it throws it out and asks a
- domain server again. See the section on TTL's. If you leave
- the TTL field blank it will default to the minimum time
- specified in the SOA record (described later).
-
- <class>
-
- The class field specifies the protocol group. If left blank it
- will default to the last class specified.
-
- <type>
-
- The type field specifies what type of data is in the RR. See
- the section on types.
-
- <data>
-
- The data field is defined differently for each type and class
- of data. Popular RR data formats are described later.
-
- The domain system does not guarantee to preserve the order of
- resource records. Listing RRs (such as multiple address records) in
- a certain order does not guarantee they will be used in that order.
-
- Case is preserved in names and data fields when loaded into the name
- server. All comparisons and lookups in the name server are case
- insensitive.
-
- Parenthesis ("(",")") are used to group data that crosses a line
- boundary.
-
- A semicolon (";") starts a comment; the remainder of the line is
- ignored.
-
- The asterisk ("*") is used for wildcarding.
-
- The at-sign ("@") denotes the current default domain name.
-
-
-
-
-
-
-
-
-Lottor [Page 3]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
-NAMES
-
- A domain name is a sequence of labels separated by dots.
-
- Domain names in the zone files can be one of two types, either
- absolute or relative. An absolute name is the fully qualified domain
- name and is terminated with a period. A relative name does not
- terminate with a period, and the current default domain is appended
- to it. The default domain is usually the name of the domain that was
- specified in the boot file that loads each zone.
-
- The domain system allows a label to contain any 8-bit character.
- Although the domain system has no restrictions, other protocols such
- as SMTP do have name restrictions. Because of other protocol
- restrictions, only the following characters are recommended for use
- in a host name (besides the dot separator):
-
- "A-Z", "a-z", "0-9", dash and underscore
-
-TTL's (Time To Live)
-
- It is important that TTLs are set to appropriate values. The TTL is
- the time (in seconds) that a resolver will use the data it got from
- your server before it asks your server again. If you set the value
- too low, your server will get loaded down with lots of repeat
- requests. If you set it too high, then information you change will
- not get distributed in a reasonable amount of time. If you leave the
- TTL field blank, it will default to what is specified in the SOA
- record for the zone.
-
- Most host information does not change much over long time periods. A
- good way to set up your TTLs would be to set them at a high value,
- and then lower the value if you know a change will be coming soon.
- You might set most TTLs to anywhere between a day (86400) and a week
- (604800). Then, if you know some data will be changing in the near
- future, set the TTL for that RR down to a lower value (an hour to a
- day) until the change takes place, and then put it back up to its
- previous value.
-
- Also, all RRs with the same name, class, and type should have the
- same TTL value.
-
-CLASSES
-
- The domain system was designed to be protocol independent. The class
- field is used to identify the protocol group that each RR is in.
-
- The class of interest to people using TCP/IP software is the class
-
-
-
-Lottor [Page 4]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- "Internet". Its standard designation is "IN".
-
- A zone file should only contain RRs of the same class.
-
-TYPES
-
- There are many defined RR types. For a complete list, see the domain
- specification RFCs. Here is a list of current commonly used types.
- The data for each type is described in the data section.
-
- Designation Description
- ==========================================
- SOA Start Of Authority
- NS Name Server
-
- A Internet Address
- CNAME Canonical Name (nickname pointer)
- HINFO Host Information
- WKS Well Known Services
-
- MX Mail Exchanger
-
- PTR Pointer
-
-SOA (Start Of Authority)
-
- <name> [<ttl>] [<class>] SOA <origin> <person> (
- <serial>
- <refresh>
- <retry>
- <expire>
- <minimum> )
-
- The Start Of Authority record designates the start of a zone. The
- zone ends at the next SOA record.
-
- <name> is the name of the zone.
-
- <origin> is the name of the host on which the master zone file
- resides.
-
- <person> is a mailbox for the person responsible for the zone. It is
- formatted like a mailing address but the at-sign that normally
- separates the user from the host name is replaced with a dot.
-
- <serial> is the version number of the zone file. It should be
- incremented anytime a change is made to data in the zone.
-
-
-
-
-Lottor [Page 5]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- <refresh> is how long, in seconds, a secondary name server is to
- check with the primary name server to see if an update is needed. A
- good value here would be one hour (3600).
-
- <retry> is how long, in seconds, a secondary name server is to retry
- after a failure to check for a refresh. A good value here would be
- 10 minutes (600).
-
- <expire> is the upper limit, in seconds, that a secondary name server
- is to use the data before it expires for lack of getting a refresh.
- You want this to be rather large, and a nice value is 3600000, about
- 42 days.
-
- <minimum> is the minimum number of seconds to be used for TTL values
- in RRs. A minimum of at least a day is a good value here (86400).
-
- There should only be one SOA record per zone. A sample SOA record
- would look something like:
-
- @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
- 45 ;serial
- 3600 ;refresh
- 600 ;retry
- 3600000 ;expire
- 86400 ) ;minimum
-
-
-NS (Name Server)
-
- <domain> [<ttl>] [<class>] NS <server>
-
- The NS record lists the name of a machine that provides domain
- service for a particular domain. The name associated with the RR is
- the domain name and the data portion is the name of a host that
- provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide
- name lookup service for the domain COM then the following entries
- would be used:
-
- COM. NS SRI-NIC.ARPA.
- NS C.ISI.EDU.
-
- Note that the machines providing name service do not have to live in
- the named domain. There should be one NS record for each server for
- a domain. Also note that the name "COM" defaults for the second NS
- record.
-
- NS records for a domain exist in both the zone that delegates the
- domain, and in the domain itself.
-
-
-
-Lottor [Page 6]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
-GLUE RECORDS
-
- If the name server host for a particular domain is itself inside the
- domain, then a 'glue' record will be needed. A glue record is an A
- (address) RR that specifies the address of the server. Glue records
- are only needed in the server delegating the domain, not in the
- domain itself. If for example the name server for domain SRI.COM was
- KL.SRI.COM, then the NS record would look like this, but you will
- also need to have the following A record.
-
- SRI.COM. NS KL.SRI.COM.
- KL.SRI.COM. A 10.1.0.2
-
-
-A (Address)
-
- <host> [<ttl>] [<class>] A <address>
-
- The data for an A record is an internet address in dotted decimal
- form. A sample A record might look like:
-
- SRI-NIC.ARPA. A 10.0.0.51
-
- There should be one A record for each address of a host.
-
-CNAME ( Canonical Name)
-
- <nickname> [<ttl>] [<class>] CNAME <host>
-
- The CNAME record is used for nicknames. The name associated with the
- RR is the nickname. The data portion is the official name. For
- example, a machine named SRI-NIC.ARPA may want to have the nickname
- NIC.ARPA. In that case, the following RR would be used:
-
- NIC.ARPA. CNAME SRI-NIC.ARPA.
-
- There must not be any other RRs associated with a nickname of the
- same class.
-
- Nicknames are also useful when a host changes it's name. In that
- case, it is usually a good idea to have a CNAME pointer so that
- people still using the old name will get to the right place.
-
-
-
-
-
-
-
-
-
-Lottor [Page 7]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
-HINFO (Host Info)
-
- <host> [<ttl>] [<class>] HINFO <hardware> <software>
-
- The HINFO record gives information about a particular host. The data
- is two strings separated by whitespace. The first string is a
- hardware description and the second is software. The hardware is
- usually a manufacturer name followed by a dash and model designation.
- The software string is usually the name of the operating system.
-
- Official HINFO types can be found in the latest Assigned Numbers RFC,
- the latest of which is RFC-1010. The Hardware type is called the
- Machine name and the Software type is called the System name.
-
- Some sample HINFO records:
-
- SRI-NIC.ARPA. HINFO DEC-2060 TOPS20
- UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX
-
-
-WKS (Well Known Services)
-
- <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
-
- The WKS record is used to list Well Known Services a host provides.
- WKS's are defined to be services on port numbers below 256. The WKS
- record lists what services are available at a certain address using a
- certain protocol. The common protocols are TCP or UDP. A sample WKS
- record for a host offering the same services on all address would
- look like:
-
- Official protocol names can be found in the latest Assigned Numbers
- RFC, the latest of which is RFC-1010.
-
- SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP
- WKS 10.0.0.51 UDP TIME
- WKS 26.0.0.73 TCP TELNET FTP SMTP
- WKS 26.0.0.73 UDP TIME
-
-MX (Mail Exchanger) (See RFC-974 for more details.)
-
- <name> [<ttl>] [<class>] MX <preference> <host>
-
- MX records specify where mail for a domain name should be delivered.
- There may be multiple MX records for a particular name. The
- preference value specifies the order a mailer should try multiple MX
- records when delivering mail. Zero is the highest preference.
- Multiple records for the same name may have the same preference.
-
-
-
-Lottor [Page 8]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- A host BAR.FOO.COM may want its mail to be delivered to the host
- PO.FOO.COM and would then use the MX record:
-
- BAR.FOO.COM. MX 10 PO.FOO.COM.
-
- A host BAZ.FOO.COM may want its mail to be delivered to one of three
- different machines, in the following order:
-
- BAZ.FOO.COM. MX 10 PO1.FOO.COM.
- MX 20 PO2.FOO.COM.
- MX 30 PO3.FOO.COM.
-
- An entire domain of hosts not connected to the Internet may want
- their mail to go through a mail gateway that knows how to deliver
- mail to them. If they would like mail addressed to any host in the
- domain FOO.COM to go through the mail gateway they might use:
-
- FOO.COM. MX 10 RELAY.CS.NET.
- *.FOO.COM. MX 20 RELAY.CS.NET.
-
- Note that you can specify a wildcard in the MX record to match on
- anything in FOO.COM, but that it won't match a plain FOO.COM.
-
-IN-ADDR.ARPA
-
- The structure of names in the domain system is set up in a
- hierarchical way such that the address of a name can be found by
- tracing down the domain tree contacting a server for each label of
- the name. Because of this 'indexing' based on name, there is no easy
- way to translate a host address back into its host name.
-
- In order to do the reverse translation easily, a domain was created
- that uses hosts' addresses as part of a name that then points to the
- data for that host. In this way, there is now an 'index' to hosts'
- RRs based on their address. This address mapping domain is called
- IN-ADDR.ARPA. Within that domain are subdomains for each network,
- based on network number. Also, for consistency and natural
- groupings, the 4 octets of a host number are reversed.
-
- For example, the ARPANET is net 10. That means there is a domain
- called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at
- 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
- (who's address is 10.0.0.51). Since the NIC is also on the MILNET
- (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
- ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format
- of these special pointers is defined below along with the examples
- for the NIC.
-
-
-
-
-Lottor [Page 9]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
-PTR
-
- <special-name> [<ttl>] [<class>] PTR <name>
-
- The PTR record is used to let special names point to some other
- location in the domain tree. They are mainly used in the IN-
- ADDR.ARPA records for translation of addresses to names. PTR's
- should use official names and not aliases.
-
- For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
- would have the following records in the respective zone files for net
- 10 and net 26:
-
- 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
- 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
-
-GATEWAY PTR's
-
- The IN-ADDR tree is also used to locate gateways on a particular
- network. Gateways have the same kind of PTR RRs as hosts (as above)
- but in addition they have other PTRs used to locate them by network
- number alone. These records have only 1, 2, or 3 octets as part of
- the name depending on whether they are class A, B, or C networks,
- respectively.
-
- Lets take the SRI-CSL gateway for example. It connects 3 different
- networks, one class A, one class B and one class C. It will have the
- standard RR's for a host in the CSL.SRI.COM zone:
-
- GW.CSL.SRI.COM. A 10.2.0.2
- A 128.18.1.1
- A 192.12.33.2
-
- Also, in 3 different zones (one for each network), it will have one
- of the following number to name translation pointers:
-
- 2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
- 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
- 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
-
- In addition, in each of the same 3 zones will be one of the following
- gateway location pointers:
-
- 10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
- 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
- 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
-
-
-
-
-
-Lottor [Page 10]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
-INSTRUCTIONS
-
- Adding a subdomain.
-
- To add a new subdomain to your domain:
-
- Setup the other domain server and/or the new zone file.
-
- Add an NS record for each server of the new domain to the zone
- file of the parent domain.
-
- Add any necessary glue RRs.
-
- Adding a host.
-
- To add a new host to your zone files:
-
- Edit the appropriate zone file for the domain the host is in.
-
- Add an entry for each address of the host.
-
- Optionally add CNAME, HINFO, WKS, and MX records.
-
- Add the reverse IN-ADDR entry for each host address in the
- appropriate zone files for each network the host in on.
-
- Deleting a host.
-
- To delete a host from the zone files:
-
- Remove all the hosts' resource records from the zone file of
- the domain the host is in.
-
- Remove all the hosts' PTR records from the IN-ADDR zone files
- for each network the host was on.
-
- Adding gateways.
-
- Follow instructions for adding a host.
-
- Add the gateway location PTR records for each network the
- gateway is on.
-
- Deleting gateways.
-
- Follow instructions for deleting a host.
-
- Also delete the gateway location PTR records for each network
-
-
-
-Lottor [Page 11]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- the gateway was on.
-
-COMPLAINTS
-
- These are the suggested steps you should take if you are having
- problems that you believe are caused by someone else's name server:
-
-
- 1. Complain privately to the responsible person for the domain. You
- can find their mailing address in the SOA record for the domain.
-
- 2. Complain publicly to the responsible person for the domain.
-
- 3. Ask the NIC for the administrative person responsible for the
- domain. Complain. You can also find domain contacts on the NIC in
- the file NETINFO:DOMAIN-CONTACTS.TXT
-
- 4. Complain to the parent domain authorities.
-
- 5. Ask the parent authorities to excommunicate the domain.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 12]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
-EXAMPLE DOMAIN SERVER DATABASE FILES
-
- The following examples show how zone files are set up for a typical
- organization. SRI will be used as the example organization. SRI has
- decided to divided their domain SRI.COM into a few subdomains, one
- for each group that wants one. The subdomains are CSL and ISTC.
-
- Note the following interesting items:
-
- There are both hosts and domains under SRI.COM.
-
- CSL.SRI.COM is both a domain name and a host name.
-
- All the domains are serviced by the same pair of domain servers.
-
- All hosts at SRI are on net 128.18 except hosts in the CSL domain
- which are on net 192.12.33. Note that a domain does not have to
- correspond to a physical network.
-
- The examples do not necessarily correspond to actual data in use
- by the SRI domain.
-
- SRI Domain Organization
-
- +-------+
- | COM |
- +-------+
- |
- +-------+
- | SRI |
- +-------+
- |
- +----------++-----------+
- | | |
- +-------+ +------+ +-------+
- | CSL | | ISTC | | Hosts |
- +-------+ +------+ +-------+
- | |
- +-------+ +-------+
- | Hosts | | Hosts |
- +-------+ +-------+
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 13]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- [File "CONFIG.CMD". Since bootstrap files are not standardized, this
- file is presented using a pseudo configuration file syntax.]
-
- load root server list from file ROOT.SERVERS
- load zone SRI.COM. from file SRI.ZONE
- load zone CSL.SRI.COM. from file CSL.ZONE
- load zone ISTC.SRI.COM. from file ISTC.ZONE
- load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE
- load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 14]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- [File "ROOT.SERVERS". Again, the format of this file is not
- standardized.]
-
- ;list of possible root servers
- SRI-NIC.ARPA 10.0.0.51 26.0.0.73
- C.ISI.EDU 10.0.0.52
- BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
- A.ISI.EDU 26.3.0.103
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 15]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- [File "SRI.ZONE"]
-
- SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
- 870407 ;serial
- 1800 ;refresh every 30 minutes
- 600 ;retry every 10 minutes
- 604800 ;expire after a week
- 86400 ;default of an hour
- )
-
- SRI.COM. NS KL.SRI.COM.
- NS STRIPE.SRI.COM.
- MX 10 KL.SRI.COM.
-
- ;SRI.COM hosts
-
- KL A 10.1.0.2
- A 128.18.10.6
- MX 10 KL.SRI.COM.
-
- STRIPE A 10.4.0.2
- STRIPE A 128.18.10.4
- MX 10 STRIPE.SRI.COM.
-
- NIC CNAME SRI-NIC.ARPA.
-
- Blackjack A 128.18.2.1
- HINFO VAX-11/780 UNIX
- WKS 128.18.2.1 TCP TELNET FTP
-
- CSL A 192.12.33.2
- HINFO FOONLY-F4 TOPS20
- WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER
- MX 10 CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 16]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- [File "CSL.ZONE"]
-
- CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
- 870330 ;serial
- 1800 ;refresh every 30 minutes
- 600 ;retry every 10 minutes
- 604800 ;expire after a week
- 86400 ;default of a day
- )
-
- CSL.SRI.COM. NS KL.SRI.COM.
- NS STRIPE.SRI.COM.
- A 192.12.33.2
-
- ;CSL.SRI.COM hosts
-
- A CNAME CSL.SRI.COM.
- B A 192.12.33.3
- HINFO FOONLY-F4 TOPS20
- WKS 192.12.33.3 TCP TELNET FTP SMTP
- GW A 10.2.0.2
- A 192.12.33.1
- A 128.18.1.1
- HINFO PDP-11/23 MOS
- SMELLY A 192.12.33.4
- HINFO IMAGEN IMAGEN
- SQUIRREL A 192.12.33.5
- HINFO XEROX-1100 INTERLISP
- VENUS A 192.12.33.7
- HINFO SYMBOLICS-3600 LISPM
- HELIUM A 192.12.33.30
- HINFO SUN-3/160 UNIX
- ARGON A 192.12.33.31
- HINFO SUN-3/75 UNIX
- RADON A 192.12.33.32
- HINFO SUN-3/75 UNIX
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 17]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- [File "ISTC.ZONE"]
-
- ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
- 870406 ;serial
- 1800 ;refresh every 30 minutes
- 600 ;retry every 10 minutes
- 604800 ;expire after a week
- 86400 ;default of a day
- )
-
- ISTC.SRI.COM. NS KL.SRI.COM.
- NS STRIPE.SRI.COM.
- MX 10 SPAM.ISTC.SRI.COM.
-
- ; ISTC hosts
-
- joyce A 128.18.4.2
- HINFO VAX-11/750 UNIX
- bozo A 128.18.0.6
- HINFO SUN UNIX
- sundae A 128.18.0.11
- HINFO SUN UNIX
- tsca A 128.18.0.201
- A 10.3.0.2
- HINFO VAX-11/750 UNIX
- MX 10 TSCA.ISTC.SRI.COM.
- tsc CNAME tsca
- prmh A 128.18.0.203
- A 10.2.0.51
- HINFO PDP-11/44 UNIX
- spam A 128.18.4.3
- A 10.2.0.107
- HINFO VAX-11/780 UNIX
- MX 10 SPAM.ISTC.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 18]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- [File "SRINET.ZONE"]
-
- 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
- 870406 ;serial
- 1800 ;refresh every 30 minutes
- 600 ;retry every 10 minutes
- 604800 ;expire after a week
- 86400 ;default of a day
- )
-
- 18.128.IN-ADDR.ARPA. NS KL.SRI.COM.
- NS STRIPE.SRI.COM.
- PTR GW.CSL.SRI.COM.
-
- ; SRINET [128.18.0.0] Address Translations
-
- ; SRI.COM Hosts
- 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.
-
- ; ISTC.SRI.COM Hosts
- 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM.
- 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM.
- 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM.
- 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM.
- 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM.
- 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM.
-
- ; CSL.SRI.COM Hosts
- 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 19]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
- [File "SRI-CSL-NET.ZONE"]
-
- 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
- 870404 ;serial
- 1800 ;refresh every 30 minutes
- 600 ;retry every 10 minutes
- 604800 ;expire after a week
- 86400 ;default of a day
- )
-
- 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM.
- NS STRIPE.SRI.COM.
- PTR GW.CSL.SRI.COM.
-
- ; SRI-CSL-NET [192.12.33.0] Address Translations
-
- ; SRI.COM Hosts
- 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM.
-
- ; CSL.SRI.COM Hosts
- 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
- 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM.
- 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM.
- 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM.
- 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM.
- 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM.
- 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM.
- 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 20]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
-APPENDIX
-
- BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
- UNIX
-
- This section describes two BIND implementation specific files; the
- boot file and the cache file. BIND has other options, files, and
- specifications that are not described here. See the Name Server
- Operations Guide for BIND for details.
-
- The boot file for BIND is usually called "named.boot". This
- corresponds to file "CONFIG.CMD" in the example section.
-
- --------------------------------------------------------
- cache . named.ca
- primary SRI.COM SRI.ZONE
- primary CSL.SRI.COM CSL.ZONE
- primary ISTC.SRI.COM ISTC.ZONE
- primary 18.128.IN-ADDR.ARPA SRINET.ZONE
- primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE
- --------------------------------------------------------
-
- The cache file for BIND is usually called "named.ca". This
- corresponds to file "ROOT.SERVERS" in the example section.
-
- -------------------------------------------------
- ;list of possible root servers
- . 1 IN NS SRI-NIC.ARPA.
- NS C.ISI.EDU.
- NS BRL-AOS.ARPA.
- NS C.ISI.EDU.
- ;and their addresses
- SRI-NIC.ARPA. A 10.0.0.51
- A 26.0.0.73
- C.ISI.EDU. A 10.0.0.52
- BRL-AOS.ARPA. A 192.5.25.82
- A 192.5.22.82
- A 128.20.1.2
- A.ISI.EDU. A 26.3.0.103
- -------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 21]
-
-RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
-
-
-REFERENCES
-
- [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
- Department of Electrical Engineering and Computer Sciences,
- University of California, Berkeley, California.
-
- [2] Partridge, C., "Mail Routing and the Domain System", RFC-974,
- CSNET CIC BBN Laboratories, January 1986.
-
- [3] Mockapetris, P., "Domains Names - Concepts and Facilities",
- RFC-1034, USC/Information Sciences Institute, November 1987.
-
- [4] Mockapetris, P., "Domain Names - Implementations Specification",
- RFC-1035, USC/Information Sciences Institute, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor [Page 22]
-
diff --git a/contrib/bind9/doc/rfc/rfc1034.txt b/contrib/bind9/doc/rfc/rfc1034.txt
deleted file mode 100644
index 55cdb21fe6529..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1034.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group P. Mockapetris
-Request for Comments: 1034 ISI
-Obsoletes: RFCs 882, 883, 973 November 1987
-
-
- DOMAIN NAMES - CONCEPTS AND FACILITIES
-
-
-
-1. STATUS OF THIS MEMO
-
-This RFC is an introduction to the Domain Name System (DNS), and omits
-many details which can be found in a companion RFC, "Domain Names -
-Implementation and Specification" [RFC-1035]. That RFC assumes that the
-reader is familiar with the concepts discussed in this memo.
-
-A subset of DNS functions and data types constitute an official
-protocol. The official protocol includes standard queries and their
-responses and most of the Internet class data formats (e.g., host
-addresses).
-
-However, the domain system is intentionally extensible. Researchers are
-continuously proposing, implementing and experimenting with new data
-types, query types, classes, functions, etc. Thus while the components
-of the official protocol are expected to stay essentially unchanged and
-operate as a production service, experimental behavior should always be
-expected in extensions beyond the official protocol. Experimental or
-obsolete features are clearly marked in these RFCs, and such information
-should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical. Distribution of this memo is unlimited.
-
-2. INTRODUCTION
-
-This RFC introduces domain style names, their use for Internet mail and
-host address support, and the protocols and servers used to implement
-domain name facilities.
-
-2.1. The history of domain names
-
-The impetus for the development of the domain system was growth in the
-Internet:
-
- - Host name to address mappings were maintained by the Network
- Information Center (NIC) in a single file (HOSTS.TXT) which
- was FTPed by all hosts [RFC-952, RFC-953]. The total network
-
-
-
-Mockapetris [Page 1]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- bandwidth consumed in distributing a new version by this
- scheme is proportional to the square of the number of hosts in
- the network, and even when multiple levels of FTP are used,
- the outgoing FTP load on the NIC host is considerable.
- Explosive growth in the number of hosts didn't bode well for
- the future.
-
- - The network population was also changing in character. The
- timeshared hosts that made up the original ARPANET were being
- replaced with local networks of workstations. Local
- organizations were administering their own names and
- addresses, but had to wait for the NIC to change HOSTS.TXT to
- make changes visible to the Internet at large. Organizations
- also wanted some local structure on the name space.
-
- - The applications on the Internet were getting more
- sophisticated and creating a need for general purpose name
- service.
-
-
-The result was several ideas about name spaces and their management
-[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a
-common thread was the idea of a hierarchical name space, with the
-hierarchy roughly corresponding to organizational structure, and names
-using "." as the character to mark the boundary between hierarchy
-levels. A design using a distributed database and generalized resources
-was described in [RFC-882, RFC-883]. Based on experience with several
-implementations, the system evolved into the scheme described in this
-memo.
-
-The terms "domain" or "domain name" are used in many contexts beyond the
-DNS described here. Very often, the term domain name is used to refer
-to a name with structure indicated by dots, but no relation to the DNS.
-This is particularly true in mail addressing [Quarterman 86].
-
-2.2. DNS design goals
-
-The design goals of the DNS influence its structure. They are:
-
- - The primary goal is a consistent name space which will be used
- for referring to resources. In order to avoid the problems
- caused by ad hoc encodings, names should not be required to
- contain network identifiers, addresses, routes, or similar
- information as part of the name.
-
- - The sheer size of the database and frequency of updates
- suggest that it must be maintained in a distributed manner,
- with local caching to improve performance. Approaches that
-
-
-
-Mockapetris [Page 2]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- attempt to collect a consistent copy of the entire database
- will become more and more expensive and difficult, and hence
- should be avoided. The same principle holds for the structure
- of the name space, and in particular mechanisms for creating
- and deleting names; these should also be distributed.
-
- - Where there tradeoffs between the cost of acquiring data, the
- speed of updates, and the accuracy of caches, the source of
- the data should control the tradeoff.
-
- - The costs of implementing such a facility dictate that it be
- generally useful, and not restricted to a single application.
- We should be able to use names to retrieve host addresses,
- mailbox data, and other as yet undetermined information. All
- data associated with a name is tagged with a type, and queries
- can be limited to a single type.
-
- - Because we want the name space to be useful in dissimilar
- networks and applications, we provide the ability to use the
- same name space with different protocol families or
- management. For example, host address formats differ between
- protocols, though all protocols have the notion of address.
- The DNS tags all data with a class as well as the type, so
- that we can allow parallel use of different formats for data
- of type address.
-
- - We want name server transactions to be independent of the
- communications system that carries them. Some systems may
- wish to use datagrams for queries and responses, and only
- establish virtual circuits for transactions that need the
- reliability (e.g., database updates, long transactions); other
- systems will use virtual circuits exclusively.
-
- - The system should be useful across a wide spectrum of host
- capabilities. Both personal computers and large timeshared
- hosts should be able to use the system, though perhaps in
- different ways.
-
-2.3. Assumptions about usage
-
-The organization of the domain system derives from some assumptions
-about the needs and usage patterns of its user community and is designed
-to avoid many of the the complicated problems found in general purpose
-database systems.
-
-The assumptions are:
-
- - The size of the total database will initially be proportional
-
-
-
-Mockapetris [Page 3]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- to the number of hosts using the system, but will eventually
- grow to be proportional to the number of users on those hosts
- as mailboxes and other information are added to the domain
- system.
-
- - Most of the data in the system will change very slowly (e.g.,
- mailbox bindings, host addresses), but that the system should
- be able to deal with subsets that change more rapidly (on the
- order of seconds or minutes).
-
- - The administrative boundaries used to distribute
- responsibility for the database will usually correspond to
- organizations that have one or more hosts. Each organization
- that has responsibility for a particular set of domains will
- provide redundant name servers, either on the organization's
- own hosts or other hosts that the organization arranges to
- use.
-
- - Clients of the domain system should be able to identify
- trusted name servers they prefer to use before accepting
- referrals to name servers outside of this "trusted" set.
-
- - Access to information is more critical than instantaneous
- updates or guarantees of consistency. Hence the update
- process allows updates to percolate out through the users of
- the domain system rather than guaranteeing that all copies are
- simultaneously updated. When updates are unavailable due to
- network or host failure, the usual course is to believe old
- information while continuing efforts to update it. The
- general model is that copies are distributed with timeouts for
- refreshing. The distributor sets the timeout value and the
- recipient of the distribution is responsible for performing
- the refresh. In special situations, very short intervals can
- be specified, or the owner can prohibit copies.
-
- - In any system that has a distributed database, a particular
- name server may be presented with a query that can only be
- answered by some other server. The two general approaches to
- dealing with this problem are "recursive", in which the first
- server pursues the query for the client at another server, and
- "iterative", in which the server refers the client to another
- server and lets the client pursue the query. Both approaches
- have advantages and disadvantages, but the iterative approach
- is preferred for the datagram style of access. The domain
- system requires implementation of the iterative approach, but
- allows the recursive approach as an option.
-
-
-
-
-
-Mockapetris [Page 4]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-The domain system assumes that all data originates in master files
-scattered through the hosts that use the domain system. These master
-files are updated by local system administrators. Master files are text
-files that are read by a local name server, and hence become available
-through the name servers to users of the domain system. The user
-programs access name servers through standard programs called resolvers.
-
-The standard format of master files allows them to be exchanged between
-hosts (via FTP, mail, or some other mechanism); this facility is useful
-when an organization wants a domain, but doesn't want to support a name
-server. The organization can maintain the master files locally using a
-text editor, transfer them to a foreign host which runs a name server,
-and then arrange with the system administrator of the name server to get
-the files loaded.
-
-Each host's name servers and resolvers are configured by a local system
-administrator [RFC-1033]. For a name server, this configuration data
-includes the identity of local master files and instructions on which
-non-local master files are to be loaded from foreign servers. The name
-server uses the master files or copies to load its zones. For
-resolvers, the configuration data identifies the name servers which
-should be the primary sources of information.
-
-The domain system defines procedures for accessing the data and for
-referrals to other name servers. The domain system also defines
-procedures for caching retrieved data and for periodic refreshing of
-data defined by the system administrator.
-
-The system administrators provide:
-
- - The definition of zone boundaries.
-
- - Master files of data.
-
- - Updates to master files.
-
- - Statements of the refresh policies desired.
-
-The domain system provides:
-
- - Standard formats for resource data.
-
- - Standard methods for querying the database.
-
- - Standard methods for name servers to refresh local data from
- foreign name servers.
-
-
-
-
-
-Mockapetris [Page 5]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-2.4. Elements of the DNS
-
-The DNS has three major components:
-
- - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
- specifications for a tree structured name space and data
- associated with the names. Conceptually, each node and leaf
- of the domain name space tree names a set of information, and
- query operations are attempts to extract specific types of
- information from a particular set. A query names the domain
- name of interest and describes the type of resource
- information that is desired. For example, the Internet
- uses some of its domain names to identify hosts; queries for
- address resources return Internet host addresses.
-
- - NAME SERVERS are server programs which hold information about
- the domain tree's structure and set information. A name
- server may cache structure or set information about any part
- of the domain tree, but in general a particular name server
- has complete information about a subset of the domain space,
- and pointers to other name servers that can be used to lead to
- information from any part of the domain tree. Name servers
- know the parts of the domain tree for which they have complete
- information; a name server is said to be an AUTHORITY for
- these parts of the name space. Authoritative information is
- organized into units called ZONEs, and these zones can be
- automatically distributed to the name servers which provide
- redundant service for the data in a zone.
-
- - RESOLVERS are programs that extract information from name
- servers in response to client requests. Resolvers must be
- able to access at least one name server and use that name
- server's information to answer a query directly, or pursue the
- query using referrals to other name servers. A resolver will
- typically be a system routine that is directly accessible to
- user programs; hence no protocol is necessary between the
- resolver and the user program.
-
-These three components roughly correspond to the three layers or views
-of the domain system:
-
- - From the user's point of view, the domain system is accessed
- through a simple procedure or OS call to a local resolver.
- The domain space consists of a single tree and the user can
- request information from any section of the tree.
-
- - From the resolver's point of view, the domain system is
- composed of an unknown number of name servers. Each name
-
-
-
-Mockapetris [Page 6]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- server has one or more pieces of the whole domain tree's data,
- but the resolver views each of these databases as essentially
- static.
-
- - From a name server's point of view, the domain system consists
- of separate sets of local information called zones. The name
- server has local copies of some of the zones. The name server
- must periodically refresh its zones from master copies in
- local files or foreign name servers. The name server must
- concurrently process queries that arrive from resolvers.
-
-In the interests of performance, implementations may couple these
-functions. For example, a resolver on the same machine as a name server
-might share a database consisting of the the zones managed by the name
-server and the cache managed by the resolver.
-
-3. DOMAIN NAME SPACE and RESOURCE RECORDS
-
-3.1. Name space specifications and terminology
-
-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.
-
-Each node has a label, which is zero to 63 octets in length. Brother
-nodes may not have the same label, although the same label can be used
-for nodes which are not brothers. One label is reserved, and that is
-the null (i.e., zero length) label used for the root.
-
-The domain name of a node is the list of the labels on the path from the
-node to the root of the tree. By convention, the labels that compose a
-domain name are printed or read left to right, from the most specific
-(lowest, farthest from the root) to the least specific (highest, closest
-to the root).
-
-Internally, programs that manipulate domain names should represent them
-as sequences of labels, where each label is a length octet followed by
-an octet string. Because all domain names end at the root, which has a
-null string for a label, these internal representations can use a length
-byte of zero to terminate a domain name.
-
-By convention, domain names can be stored with arbitrary case, but
-domain name comparisons for all present domain functions are done in a
-case-insensitive manner, assuming an ASCII character set, and a high
-order zero bit. This means that you are free to create a node with
-label "A" or a node with label "a", but not both as brothers; you could
-refer to either using "a" or "A". When you receive a domain name or
-
-
-
-Mockapetris [Page 7]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-label, you should preserve its case. The rationale for this choice is
-that we may someday need to add full binary domain names for new
-services; existing services would not be changed.
-
-When a user needs to type a domain name, the length of each label is
-omitted and the labels are separated by dots ("."). Since a complete
-domain name ends with the root label, this leads to a printed form which
-ends in a dot. We use this property to distinguish between:
-
- - a character string which represents a complete domain name
- (often called "absolute"). For example, "poneria.ISI.EDU."
-
- - a character string that represents the starting labels of a
- domain name which is incomplete, and should be completed by
- local software using knowledge of the local domain (often
- called "relative"). For example, "poneria" used in the
- ISI.EDU domain.
-
-Relative names are either taken relative to a well known origin, or to a
-list of domains used as a search list. Relative names appear mostly at
-the user interface, where their interpretation varies from
-implementation to implementation, and in master files, where they are
-relative to a single origin domain name. The most common interpretation
-uses the root "." as either the single origin or as one of the members
-of the search list, so a multi-label relative name is often one where
-the trailing dot has been omitted to save typing.
-
-To simplify implementations, the total number of octets that represent a
-domain name (i.e., the sum of all label octets and label lengths) is
-limited to 255.
-
-A domain is identified by a domain name, and consists of that part of
-the domain name space that is at or below the domain name which
-specifies the domain. A domain is a subdomain of another domain if it
-is contained within that domain. This relationship can be tested by
-seeing if the subdomain's name ends with the containing domain's name.
-For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
-
-3.2. Administrative guidelines on use
-
-As a matter of policy, the DNS technical specifications do not mandate a
-particular tree structure or rules for selecting labels; its goal is to
-be as general as possible, so that it can be used to build arbitrary
-applications. In particular, the system was designed so that the name
-space did not have to be organized along the lines of network
-boundaries, name servers, etc. The rationale for this is not that the
-name space should have no implied semantics, but rather that the choice
-of implied semantics should be left open to be used for the problem at
-
-
-
-Mockapetris [Page 8]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-hand, and that different parts of the tree can have different implied
-semantics. For example, the IN-ADDR.ARPA domain is organized and
-distributed by network and host address because its role is to translate
-from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
-1002] are flat because that is appropriate for that application.
-
-However, there are some guidelines that apply to the "normal" parts of
-the name space used for hosts, mailboxes, etc., that will make the name
-space more uniform, provide for growth, and minimize problems as
-software is converted from the older host table. The political
-decisions about the top levels of the tree originated in RFC-920.
-Current policy for the top levels is discussed in [RFC-1032]. MILNET
-conversion issues are covered in [RFC-1031].
-
-Lower domains which will eventually be broken into multiple zones should
-provide branching at the top of the domain so that the eventual
-decomposition can be done without renaming. Node labels which use
-special characters, leading digits, etc., are likely to break older
-software which depends on more restrictive choices.
-
-3.3. Technical guidelines on use
-
-Before the DNS can be used to hold naming information for some kind of
-object, two needs must be met:
-
- - A convention for mapping between object names and domain
- names. This describes how information about an object is
- accessed.
-
- - RR types and data formats for describing the object.
-
-These rules can be quite simple or fairly complex. Very often, the
-designer must take into account existing formats and plan for upward
-compatibility for existing usage. Multiple mappings or levels of
-mapping may be required.
-
-For hosts, the mapping depends on the existing syntax for host names
-which is a subset of the usual text representation for domain names,
-together with RR formats for describing host addresses, etc. Because we
-need a reliable inverse mapping from address to host name, a special
-mapping for addresses into the IN-ADDR.ARPA domain is also defined.
-
-For mailboxes, the mapping is slightly more complex. The usual mail
-address <local-part>@<mail-domain> is mapped into a domain name by
-converting <local-part> into a single label (regardles of dots it
-contains), converting <mail-domain> into a domain name using the usual
-text format for domain names (dots denote label breaks), and
-concatenating the two to form a single domain name. Thus the mailbox
-
-
-
-Mockapetris [Page 9]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
-HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this
-design also must take into account the scheme for mail exchanges [RFC-
-974].
-
-The typical user is not concerned with defining these rules, but should
-understand that they usually are the result of numerous compromises
-between desires for upward compatibility with old usage, interactions
-between different object definitions, and the inevitable urge to add new
-features when defining the rules. The way the DNS is used to support
-some object is often more crucial than the restrictions inherent in the
-DNS.
-
-3.4. Example name space
-
-The following figure shows a part of the current domain name space, and
-is used in many examples in this RFC. Note that the tree is a very
-small subset of the actual name space.
-
- |
- |
- +---------------------+------------------+
- | | |
- MIL EDU ARPA
- | | |
- | | |
- +-----+-----+ | +------+-----+-----+
- | | | | | | |
- BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
- |
- +--------+------------------+---------------+--------+
- | | | | |
- UCI MIT | UDEL YALE
- | ISI
- | |
- +---+---+ |
- | | |
- LCS ACHILLES +--+-----+-----+--------+
- | | | | | |
- XX A C VAXA VENERA Mockapetris
-
-In this example, the root domain has three immediate subdomains: MIL,
-EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named
-XX.LCS.MIT.EDU. All of the leaves are also domains.
-
-3.5. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-
-
-
-Mockapetris [Page 10]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-for constructing domain names. The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822. When creating a new host name,
-the old rules for HOSTS.TXT should be followed. This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case. That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names. They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen. There are also some
-restrictions on the length. Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
-
-3.6. Resource Records
-
-A domain name identifies a node. Each node has a set of resource
-
-
-
-Mockapetris [Page 11]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-information, which may be empty. The set of resource information
-associated with a particular name is composed of separate resource
-records (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.
-
-When we talk about a specific RR, we assume it has the following:
-
-owner which is the domain name where the RR is found.
-
-type which is an encoded 16 bit value that specifies the type
- of the resource in this resource record. Types refer to
- abstract resources.
-
- This memo uses the following types:
-
- A a host address
-
- CNAME identifies the canonical name of an
- alias
-
- HINFO identifies the CPU and OS used by a host
-
- MX identifies a mail exchange for the
- domain. See [RFC-974 for details.
-
- NS
- the authoritative name server for the domain
-
- PTR
- a pointer to another part of the domain name space
-
- SOA
- identifies the start of a zone of authority]
-
-class which is an encoded 16 bit value which identifies a
- protocol family or instance of a protocol.
-
- This memo uses the following classes:
-
- IN the Internet system
-
- CH the Chaos system
-
-TTL which is the time to live of the RR. This field is a 32
- bit integer in units of seconds, an is primarily used by
- resolvers when they cache RRs. The TTL describes how
- long a RR can be cached before it should be discarded.
-
-
-
-
-Mockapetris [Page 12]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-RDATA which is the type and sometimes class dependent data
- which describes the resource:
-
- A For the IN class, a 32 bit IP address
-
- For the CH class, a domain name followed
- by a 16 bit octal Chaos address.
-
- CNAME a domain name.
-
- MX a 16 bit preference value (lower is
- better) followed by a host name willing
- to act as a mail exchange for the owner
- domain.
-
- NS a host name.
-
- PTR a domain name.
-
- SOA several fields.
-
-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 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 zone where the
-data originates. While short TTLs can be used to minimize caching, and
-a zero TTL prohibits caching, the realities 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 of
-binary strings and domain names. The domain names are frequently used
-as "pointers" to other data in the DNS.
-
-3.6.1. 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 this memo, we adopt a style similar to that used
-
-
-
-Mockapetris [Page 13]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-in master files 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 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 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 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.
-
-3.6.2. Aliases and canonical names
-
-In existing systems, hosts and other resources often have several names
-that identify the same resource. For example, the names C.ISI.EDU and
-USC-ISIC.ARPA both identify the same host. Similarly, in the case of
-mailboxes, many organizations provide many names that actually go to the
-same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
-
-
-
-Mockapetris [Page 14]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-and PVM@ISI.EDU all go to the same mailbox (although the mechanism
-behind this is somewhat complicated).
-
-Most of these systems have a notion that one of the equivalent set of
-names is the canonical or primary name and all others are aliases.
-
-The domain system provides such a feature using the canonical name
-(CNAME) RR. A CNAME RR identifies its owner name as an alias, and
-specifies the corresponding canonical name in the RDATA section of the
-RR. 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.
-
-CNAME RRs cause special action in DNS software. When a name server
-fails to find a desired RR in the resource set associated with the
-domain name, it checks to see if the resource set consists of a CNAME
-record with a matching class. If so, the name server includes the CNAME
-record in the response and restarts the query at the domain name
-specified in the data field of the CNAME record. The one exception to
-this rule is that queries which match the CNAME type are not restarted.
-
-For example, suppose a name server was processing a query with for USC-
-ISIC.ARPA, asking for type A information, and had the following resource
-records:
-
- USC-ISIC.ARPA IN CNAME C.ISI.EDU
-
- C.ISI.EDU IN A 10.0.0.52
-
-Both of these RRs would be returned in the response to the type A query,
-while a type CNAME or * query should return just the CNAME.
-
-Domain names in RRs which point at another name should always point at
-the primary name and not the alias. This avoids extra indirections in
-accessing information. For example, the address to name RR for the
-above host should be:
-
- 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
-
-rather than pointing at USC-ISIC.ARPA. Of course, by the robustness
-principle, domain software should not fail when presented with CNAME
-chains or loops; CNAME chains should be followed and CNAME loops
-signalled as an error.
-
-3.7. Queries
-
-Queries are messages which may be sent to a name server to provoke a
-
-
-
-Mockapetris [Page 15]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-response. In the Internet, queries are carried in UDP datagrams or over
-TCP connections. The response by the name server either answers the
-question posed in the query, refers the requester to another set of name
-servers, or signals some error condition.
-
-In general, the user does not generate queries directly, but instead
-makes a request to a resolver which in turn sends one or more queries to
-name servers and deals with the error conditions and referrals that may
-result. Of course, the possible questions which can be asked in a query
-does shape the kind of service a resolver can provide.
-
-DNS queries and responses are carried in a standard message format. The
-message format has a header containing a number of fixed fields which
-are always present, and four sections which carry query parameters and
-RRs.
-
-The most important field in the header is a four bit field called an
-opcode which separates different queries. Of the possible 16 values,
-one (standard query) is part of the official protocol, two (inverse
-query and status query) are options, one (completion) is obsolete, and
-the rest are unassigned.
-
-The four sections are:
-
-Question Carries the query name and other query parameters.
-
-Answer Carries RRs which directly answer the query.
-
-Authority Carries RRs which describe other authoritative servers.
- May optionally carry the SOA RR for the authoritative
- data in the answer section.
-
-Additional Carries RRs which may be helpful in using the RRs in the
- other sections.
-
-Note that the content, but not the format, of these sections varies with
-header opcode.
-
-3.7.1. Standard queries
-
-A standard query specifies a target domain name (QNAME), query type
-(QTYPE), and query class (QCLASS) and asks for RRs which match. This
-type of query makes up such a vast majority of DNS queries that we use
-the term "query" to mean standard query unless otherwise specified. The
-QTYPE and QCLASS fields are each 16 bits long, and are a superset of
-defined types and classes.
-
-
-
-
-
-Mockapetris [Page 16]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-The QTYPE field may contain:
-
-<any type> matches just that type. (e.g., A, PTR).
-
-AXFR special zone transfer QTYPE.
-
-MAILB matches all mail box related RRs (e.g. MB and MG).
-
-* matches all RR types.
-
-The QCLASS field may contain:
-
-<any class> matches just that class (e.g., IN, CH).
-
-* matches aLL RR classes.
-
-Using the query domain name, QTYPE, and QCLASS, the name server looks
-for matching RRs. In addition to relevant records, the name server may
-return RRs that point toward a name server that has the desired
-information or RRs that are expected to be useful in interpreting the
-relevant RRs. For example, a name server that doesn't have the
-requested information may know a name server that does; a name server
-that returns a domain name in a relevant RR may also return the RR that
-binds that domain name to an address.
-
-For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
-ask the resolver for mail information about ISI.EDU, resulting in a
-query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer
-section would be:
-
- ISI.EDU. MX 10 VENERA.ISI.EDU.
- MX 10 VAXA.ISI.EDU.
-
-while the additional section might be:
-
- VAXA.ISI.EDU. A 10.2.0.27
- A 128.9.0.33
- VENERA.ISI.EDU. A 10.1.0.52
- A 128.9.0.32
-
-Because the server assumes that if the requester wants mail exchange
-information, it will probably want the addresses of the mail exchanges
-soon afterward.
-
-Note that the QCLASS=* construct requires special interpretation
-regarding authority. Since a particular name server may not know all of
-the classes available in the domain system, it can never know if it is
-authoritative for all classes. Hence responses to QCLASS=* queries can
-
-
-
-Mockapetris [Page 17]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-never be authoritative.
-
-3.7.2. Inverse queries (Optional)
-
-Name servers may also support inverse queries that map a particular
-resource to a domain name or domain names that have that resource. For
-example, while a standard query might map a domain name to a SOA RR, the
-corresponding inverse query might map the SOA RR back to the domain
-name.
-
-Implementation of this service is optional in a name server, but all
-name servers must at least be able to understand an inverse query
-message and return a not-implemented error response.
-
-The domain system cannot guarantee the completeness or uniqueness of
-inverse queries because the domain system is organized by domain name
-rather than by host address or any other resource type. Inverse queries
-are primarily useful for debugging and database maintenance activities.
-
-Inverse queries may not return the proper TTL, and do not indicate cases
-where the identified RR is one of a set (for example, one address for a
-host having multiple addresses). Therefore, the RRs returned in inverse
-queries should never be cached.
-
-Inverse queries are NOT an acceptable method for mapping host addresses
-to host names; use the IN-ADDR.ARPA domain instead.
-
-A detailed discussion of inverse queries is contained in [RFC-1035].
-
-3.8. Status queries (Experimental)
-
-To be defined.
-
-3.9. Completion queries (Obsolete)
-
-The optional completion services described in RFCs 882 and 883 have been
-deleted. Redesigned services may become available in the future, or the
-opcodes may be reclaimed for other use.
-
-4. NAME SERVERS
-
-4.1. Introduction
-
-Name servers are the repositories of information that make up the domain
-database. The database is divided up into sections called zones, which
-are distributed among the name servers. While name servers can have
-several optional functions and sources of data, the essential task of a
-name server is to answer queries using data in its zones. By design,
-
-
-
-Mockapetris [Page 18]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-name servers can answer queries in a simple manner; the response can
-always be generated using only local data, and either contains the
-answer to the question or a referral to other name servers "closer" to
-the desired information.
-
-A given zone will be available from several name servers to insure its
-availability in spite of host or communication link failure. By
-administrative fiat, we require every zone to be available on at least
-two servers, and many zones have more redundancy than that.
-
-A given name server will typically support one or more zones, but this
-gives it authoritative information about only a small section of the
-domain tree. It may also have some cached non-authoritative data about
-other parts of the tree. The name server marks its responses to queries
-so that the requester can tell whether the response comes from
-authoritative data or not.
-
-4.2. How the database is divided into zones
-
-The domain database is partitioned in two ways: by class, and by "cuts"
-made in the name space between nodes.
-
-The class partition is simple. The database for any class is organized,
-delegated, and maintained separately from all other classes. Since, by
-convention, the name spaces are the same for all classes, the separate
-classes can be thought of as an array of parallel namespace trees. Note
-that the data attached to nodes will be different for these different
-parallel classes. The most common reasons for creating a new class are
-the necessity for a new data format for existing types or a desire for a
-separately managed version of the existing name space.
-
-Within a class, "cuts" in the name space can be made between any two
-adjacent nodes. After all cuts are made, each group of connected name
-space is a separate zone. The zone is said to be authoritative for all
-names in the connected region. Note that the "cuts" in the name space
-may be in different places for different classes, the name servers may
-be different, etc.
-
-These rules mean that every zone has at least one node, and hence domain
-name, for which it is authoritative, and all of the nodes in a
-particular zone are connected. Given, the tree structure, every zone
-has a highest node which is closer to the root than any other node in
-the zone. The name of this node is often used to identify the zone.
-
-It would be possible, though not particularly useful, to partition the
-name space so that each domain name was in a separate zone or so that
-all nodes were in a single zone. Instead, the database is partitioned
-at points where a particular organization wants to take over control of
-
-
-
-Mockapetris [Page 19]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-a subtree. Once an organization controls its own zone it can
-unilaterally change the data in the zone, grow new tree sections
-connected to the zone, delete existing nodes, or delegate new subzones
-under its zone.
-
-If the organization has substructure, it may want to make further
-internal partitions to achieve nested delegations of name space control.
-In some cases, such divisions are made purely to make database
-maintenance more convenient.
-
-4.2.1. Technical considerations
-
-The data that describes a zone has four major parts:
-
- - Authoritative data for all nodes within the zone.
-
- - Data that defines the top node of the zone (can be thought of
- as part of the authoritative data).
-
- - Data that describes delegated subzones, i.e., cuts around the
- bottom of the zone.
-
- - Data that allows access to name servers for subzones
- (sometimes called "glue" data).
-
-All of this data is expressed in the form of RRs, so a zone can be
-completely described in terms of a set of RRs. Whole zones can be
-transferred between name servers by transferring the RRs, either carried
-in a series of messages or by FTPing a master file which is a textual
-representation.
-
-The authoritative data for a zone is simply all of the RRs attached to
-all of the nodes from the top node of the zone down to leaf nodes or
-nodes above cuts around the bottom edge of the zone.
-
-Though logically part of the authoritative data, the RRs that describe
-the top node of the zone are especially important to the zone's
-management. These RRs are of two types: name server RRs that list, one
-per RR, all of the servers for the zone, and a single SOA RR that
-describes zone management parameters.
-
-The RRs that describe cuts around the bottom of the zone are NS RRs that
-name the servers for the subzones. Since the cuts are between nodes,
-these RRs are NOT part of the authoritative data of the zone, and should
-be exactly the same as the corresponding RRs in the top node of the
-subzone. Since name servers are always associated with zone boundaries,
-NS RRs are only found at nodes which are the top node of some zone. In
-the data that makes up a zone, NS RRs are found at the top node of the
-
-
-
-Mockapetris [Page 20]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-zone (and are authoritative) and at cuts around the bottom of the zone
-(where they are not authoritative), but never in between.
-
-One of the goals of the zone structure is that any zone have all the
-data required to set up communications with the name servers for any
-subzones. That is, parent zones have all the information needed to
-access servers for their children zones. The NS RRs that name the
-servers for subzones are often not enough for this task since they name
-the servers, but do not give their addresses. In particular, if the
-name of the name server is itself in the subzone, we could be faced with
-the situation where the NS RRs tell us that in order to learn a name
-server's address, we should contact the server using the address we wish
-to learn. To fix this problem, a zone contains "glue" RRs which are not
-part of the authoritative data, and are address RRs for the servers.
-These RRs are only necessary if the name server's name is "below" the
-cut, and are only used as part of a referral response.
-
-4.2.2. Administrative considerations
-
-When some organization wants to control its own domain, the first step
-is to identify the proper parent zone, and get the parent zone's owners
-to agree to the delegation of control. While there are no particular
-technical constraints dealing with where in the tree this can be done,
-there are some administrative groupings discussed in [RFC-1032] which
-deal with top level organization, and middle level zones are free to
-create their own rules. For example, one university might choose to use
-a single zone, while another might choose to organize by subzones
-dedicated to individual departments or schools. [RFC-1033] catalogs
-available DNS software an discusses administration procedures.
-
-Once the proper name for the new subzone is selected, the new owners
-should be required to demonstrate redundant name server support. Note
-that there is no requirement that the servers for a zone reside in a
-host which has a name in that domain. In many cases, a zone will be
-more accessible to the internet at large if its servers are widely
-distributed rather than being within the physical facilities controlled
-by the same organization that manages the zone. For example, in the
-current DNS, one of the name servers for the United Kingdom, or UK
-domain, is found in the US. This allows US hosts to get UK data without
-using limited transatlantic bandwidth.
-
-As the last installation step, the delegation NS RRs and glue RRs
-necessary to make the delegation effective should be added to the parent
-zone. The administrators of both zones should insure that the NS and
-glue RRs which mark both sides of the cut are consistent and remain so.
-
-4.3. Name server internals
-
-
-
-
-Mockapetris [Page 21]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-4.3.1. Queries and responses
-
-The principal activity of name servers is to answer standard queries.
-Both the query and its response are carried in a standard message format
-which is described in [RFC-1035]. The query contains a QTYPE, QCLASS,
-and QNAME, which describe the types and classes of desired information
-and the name of interest.
-
-The way that the name server answers the query depends upon whether it
-is operating in recursive mode or not:
-
- - The simplest mode for the server is non-recursive, since it
- can answer queries using only local information: the response
- contains an error, the answer, or a referral to some other
- server "closer" to the answer. All name servers must
- implement non-recursive queries.
-
- - The simplest mode for the client is recursive, since in this
- mode the name server acts in the role of a resolver and
- returns either an error or the answer, but never referrals.
- This service is optional in a name server, and the name server
- may also choose to restrict the clients which can use
- recursive mode.
-
-Recursive service is helpful in several situations:
-
- - a relatively simple requester that lacks the ability to use
- anything other than a direct answer to the question.
-
- - a request that needs to cross protocol or other boundaries and
- can be sent to a server which can act as intermediary.
-
- - a network where we want to concentrate the cache rather than
- having a separate cache for each client.
-
-Non-recursive service is appropriate if the requester is capable of
-pursuing referrals and interested in information which will aid future
-requests.
-
-The use of recursive mode is limited to cases where both the client and
-the name server agree to its use. The agreement is negotiated through
-the use of two bits in query and response messages:
-
- - The recursion available, or RA bit, is set or cleared by a
- name server in all responses. The bit is true if the name
- server is willing to provide recursive service for the client,
- regardless of whether the client requested recursive service.
- That is, RA signals availability rather than use.
-
-
-
-Mockapetris [Page 22]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- - Queries contain a bit called recursion desired or RD. This
- bit specifies specifies whether the requester wants recursive
- service for this query. Clients may request recursive service
- from any name server, though they should depend upon receiving
- it only from servers which have previously sent an RA, or
- servers which have agreed to provide service through private
- agreement or some other means outside of the DNS protocol.
-
-The recursive mode occurs when a query with RD set arrives at a server
-which is willing to provide recursive service; the client can verify
-that recursive mode was used by checking that both RA and RD are set in
-the reply. Note that the name server should never perform recursive
-service unless asked via RD, since this interferes with trouble shooting
-of name servers and their databases.
-
-If recursive service is requested and available, the recursive response
-to a query will be one of the following:
-
- - The answer to the query, possibly preface by one or more CNAME
- RRs that specify aliases encountered on the way to an answer.
-
- - A name error indicating that the name does not exist. This
- may include CNAME RRs that indicate that the original query
- name was an alias for a name which does not exist.
-
- - A temporary error indication.
-
-If recursive service is not requested or is not available, the non-
-recursive response will be one of the following:
-
- - An authoritative name error indicating that the name does not
- exist.
-
- - A temporary error indication.
-
- - Some combination of:
-
- RRs that answer the question, together with an indication
- whether the data comes from a zone or is cached.
-
- A referral to name servers which have zones which are closer
- ancestors to the name than the server sending the reply.
-
- - RRs that the name server thinks will prove useful to the
- requester.
-
-
-
-
-
-
-Mockapetris [Page 23]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-4.3.2. Algorithm
-
-The actual algorithm used by the name server will depend on the local OS
-and data structures used to store RRs. The following algorithm assumes
-that the RRs are organized in several tree structures, one for each
-zone, and another for the cache:
-
- 1. Set or clear the value of recursion available in the response
- depending on whether the name server is willing to provide
- recursive service. If recursive service is available and
- requested via the RD bit in the query, go to step 5,
- otherwise step 2.
-
- 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.
-
- 3. Start matching down, label by label, in the zone. The
- matching process can terminate several ways:
-
- a. If the whole of QNAME is matched, we have found the
- node.
-
- If the data at the node is a CNAME, and QTYPE doesn't
- match CNAME, copy the CNAME RR into the answer section
- of the response, change QNAME to the canonical name in
- the CNAME RR, and go back to step 1.
-
- Otherwise, copy all RRs which match QTYPE into the
- answer section and go to step 6.
-
- b. If a match would take us out of the authoritative data,
- we have a referral. This happens when we encounter a
- node with NS RRs marking cuts along the bottom of a
- zone.
-
- Copy the NS RRs for the subzone into the authority
- section of the reply. Put whatever addresses are
- available into the additional section, using glue RRs
- if the addresses are not available from authoritative
- data or the cache. Go to step 4.
-
- c. If at some label, a match is impossible (i.e., the
- corresponding label does not exist), look to see if a
- the "*" label exists.
-
- If the "*" label does not exist, check whether the name
- we are looking for is the original QNAME in the query
-
-
-
-Mockapetris [Page 24]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- 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.
-
- 4. Start matching down in the cache. If QNAME is found in the
- cache, copy all RRs attached to it that match QTYPE into the
- answer section. If there was no delegation from
- authoritative data, look for the best one from the cache, and
- put it in the authority section. Go to step 6.
-
- 5. Using the local resolver or a copy of its algorithm (see
- resolver section of this memo) to answer the query. Store
- the results, including any intermediate CNAMEs, in the answer
- section of the response.
-
- 6. Using local data only, attempt to add other RRs which may be
- useful to the additional section of the query. Exit.
-
-4.3.3. Wildcards
-
-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 facility is most often used to create a zone which will be used to
-forward mail from the Internet to some other mail system. The general
-idea is that any name in that zone which is presented to server in a
-query will be assumed to exist, with certain properties, unless explicit
-evidence exists to the contrary. Note that the use of the term zone
-here, instead of domain, is intentional; such defaults do not propagate
-across zone boundaries, although a subzone may choose to achieve that
-appearance by setting up similar defaults.
-
-The contents of the wildcard RRs follows the usual rules and formats for
-RRs. The wildcards in the zone have an owner name that controls the
-query names they will match. The owner name of the wildcard RRs is of
-the form "*.<anydomain>", where <anydomain> is any domain name.
-<anydomain> should not contain other * labels, and should be in the
-authoritative data of the zone. The wildcards potentially apply to
-descendants of <anydomain>, but not to <anydomain> itself. Another way
-
-
-
-Mockapetris [Page 25]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-to look at this is that the "*" label always matches at least one whole
-label and sometimes more, but always whole labels.
-
-Wildcard RRs do not apply:
-
- - When the query is in another zone. That is, delegation cancels
- the wildcard defaults.
-
- - When the query name or a name between the wildcard domain and
- the query name is know to exist. For example, if a wildcard
- RR has an owner name of "*.X", and the zone also contains RRs
- attached to B.X, the wildcards would apply to queries for name
- Z.X (presuming there is no explicit information for Z.X), but
- not to B.X, A.B.X, or X.
-
-A * label appearing in a query name has no special effect, but can be
-used to test for wildcards in an authoritative zone; such a query is the
-only way to get a response containing RRs with an owner name with * in
-it. The result of such a query should not be cached.
-
-Note that the contents of the wildcard RRs are not modified when used to
-synthesize RRs.
-
-To illustrate the use of wildcard RRs, suppose a large company with a
-large, non-IP/TCP, network wanted to create a mail gateway. If the
-company was called X.COM, and IP/TCP capable gateway machine was called
-A.X.COM, the following RRs might be entered into the COM zone:
-
- X.COM MX 10 A.X.COM
-
- *.X.COM MX 10 A.X.COM
-
- A.X.COM A 1.2.3.4
- A.X.COM MX 10 A.X.COM
-
- *.A.X.COM MX 10 A.X.COM
-
-This would cause any MX query for any domain name ending in X.COM to
-return an MX RR pointing at A.X.COM. Two wildcard RRs are required
-since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
-subtree by the explicit data for A.X.COM. Note also that the explicit
-MX data at X.COM and A.X.COM is required, and that none of the RRs above
-would match a query name of XX.COM.
-
-4.3.4. Negative response caching (Optional)
-
-The DNS provides an optional service which allows name servers to
-distribute, and resolvers to cache, negative results with TTLs. For
-
-
-
-Mockapetris [Page 26]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-example, a name server can distribute a TTL along with a name error
-indication, and a resolver receiving such information is allowed to
-assume that the name does not exist during the TTL period without
-consulting authoritative data. Similarly, a resolver can make a query
-with a QTYPE which matches multiple types, and cache the fact that some
-of the types are not present.
-
-This feature can be particularly important in a system which implements
-naming shorthands that use search lists beacuse a popular shorthand,
-which happens to require a suffix toward the end of the search list,
-will generate multiple name errors whenever it is used.
-
-The method is that a name server may add an SOA RR to the additional
-section of a response when that response is authoritative. The SOA must
-be that of the zone which was the source of the authoritative data in
-the answer section, or name error if applicable. The MINIMUM field of
-the SOA controls the length of time that the negative result may be
-cached.
-
-Note that in some circumstances, the answer section may contain multiple
-owner names. In this case, the SOA mechanism should only be used for
-the data which matches QNAME, which is the only authoritative data in
-this section.
-
-Name servers and resolvers should never attempt to add SOAs to the
-additional section of a non-authoritative response, or attempt to infer
-results which are not directly stated in an authoritative response.
-There are several reasons for this, including: cached information isn't
-usually enough to match up RRs and their zone names, SOA RRs may be
-cached due to direct SOA queries, and name servers are not required to
-output the SOAs in the authority section.
-
-This feature is optional, although a refined version is expected to
-become part of the standard protocol in the future. Name servers are
-not required to add the SOA RRs in all authoritative responses, nor are
-resolvers required to cache negative results. Both are recommended.
-All resolvers and recursive name servers are required to at least be
-able to ignore the SOA RR when it is present in a response.
-
-Some experiments have also been proposed which will use this feature.
-The idea is that if cached data is known to come from a particular zone,
-and if an authoritative copy of the zone's SOA is obtained, and if the
-zone's SERIAL has not changed since the data was cached, then the TTL of
-the cached data can be reset to the zone MINIMUM value if it is smaller.
-This usage is mentioned for planning purposes only, and is not
-recommended as yet.
-
-
-
-
-
-Mockapetris [Page 27]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-4.3.5. Zone maintenance and transfers
-
-Part of the job of a zone administrator is to maintain the zones at all
-of the name servers which are authoritative for the zone. When the
-inevitable changes are made, they must be distributed to all of the name
-servers. While this distribution can be accomplished using FTP or some
-other ad hoc procedure, the preferred method is the zone transfer part
-of the DNS protocol.
-
-The general model of automatic zone transfer or refreshing is that one
-of the name servers is the master or primary for the zone. Changes are
-coordinated at the primary, typically by editing a master file for the
-zone. After editing, the administrator signals the master server to
-load the new zone. The other non-master or secondary servers for the
-zone periodically check for changes (at a selectable interval) and
-obtain new zone copies when changes have been made.
-
-To detect changes, secondaries just check the SERIAL field of the SOA
-for the zone. In addition to whatever other changes are made, the
-SERIAL field in the SOA of the zone is always advanced whenever any
-change is made to the zone. The advancing can be a simple increment, or
-could be based on the write date and time of the master file, etc. The
-purpose is to make it possible to determine which of two copies of a
-zone is more recent by comparing serial numbers. Serial number advances
-and comparisons use sequence space arithmetic, so there is a theoretic
-limit on how fast a zone can be updated, basically that old copies must
-die out before the serial number covers half of its 32 bit range. In
-practice, the only concern is that the compare operation deals properly
-with comparisons around the boundary between the most positive and most
-negative 32 bit numbers.
-
-The periodic polling of the secondary servers is controlled by
-parameters in the SOA RR for the zone, which set the minimum acceptable
-polling intervals. The parameters are called REFRESH, RETRY, and
-EXPIRE. Whenever a new zone is loaded in a secondary, the secondary
-waits REFRESH seconds before checking with the primary for a new serial.
-If this check cannot be completed, new checks are started every RETRY
-seconds. The check is a simple query to the primary for the SOA RR of
-the zone. If the serial field in the secondary's zone copy is equal to
-the serial returned by the primary, then no changes have occurred, and
-the REFRESH interval wait is restarted. If the secondary finds it
-impossible to perform a serial check for the EXPIRE interval, it must
-assume that its copy of the zone is obsolete an discard it.
-
-When the poll shows that the zone has changed, then the secondary server
-must request a zone transfer via an AXFR request for the zone. The AXFR
-may cause an error, such as refused, but normally is answered by a
-sequence of response messages. The first and last messages must contain
-
-
-
-Mockapetris [Page 28]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-the data for the top authoritative node of the zone. Intermediate
-messages carry all of the other RRs from the zone, including both
-authoritative and non-authoritative RRs. The stream of messages allows
-the secondary to construct a copy of the zone. Because accuracy is
-essential, TCP or some other reliable protocol must be used for AXFR
-requests.
-
-Each secondary server is required to perform the following operations
-against the master, but may also optionally perform these operations
-against other secondary servers. This strategy can improve the transfer
-process when the primary is unavailable due to host downtime or network
-problems, or when a secondary server has better network access to an
-"intermediate" secondary than to the primary.
-
-5. RESOLVERS
-
-5.1. Introduction
-
-Resolvers are programs that interface user programs to domain name
-servers. In the simplest case, a resolver receives a request from a
-user program (e.g., mail programs, TELNET, FTP) in the form of a
-subroutine call, system call etc., and returns the desired information
-in a form compatible with the local host's data formats.
-
-The resolver is located on the same machine as the program that requests
-the resolver's services, but it may need to consult name servers on
-other hosts. Because a resolver may need to consult several name
-servers, or may have the requested information in a local cache, the
-amount of time that a resolver will take to complete can vary quite a
-bit, from milliseconds to several seconds.
-
-A very important goal of the resolver is to eliminate network delay and
-name server load from most requests by answering them from its cache of
-prior results. It follows that caches which are shared by multiple
-processes, users, machines, etc., are more efficient than non-shared
-caches.
-
-5.2. Client-resolver interface
-
-5.2.1. Typical functions
-
-The client interface to the resolver is influenced by the local host's
-conventions, but the typical resolver-client interface has three
-functions:
-
- 1. Host name to host address translation.
-
- This function is often defined to mimic a previous HOSTS.TXT
-
-
-
-Mockapetris [Page 29]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- based function. Given a character string, the caller wants
- one or more 32 bit IP addresses. Under the DNS, it
- translates into a request for type A RRs. Since the DNS does
- not preserve the order of RRs, this function may choose to
- sort the returned addresses or select the "best" address if
- the service returns only one choice to the client. Note that
- a multiple address return is recommended, but a single
- address may be the only way to emulate prior HOSTS.TXT
- services.
-
- 2. Host address to host name translation
-
- This function will often follow the form of previous
- functions. Given a 32 bit IP address, the caller wants a
- character string. The octets of the IP address are reversed,
- used as name components, and suffixed with "IN-ADDR.ARPA". A
- type PTR query is used to get the RR with the primary name of
- the host. For example, a request for the host name
- corresponding to IP address 1.2.3.4 looks for PTR RRs for
- domain name "4.3.2.1.IN-ADDR.ARPA".
-
- 3. General lookup function
-
- This function retrieves arbitrary information from the DNS,
- and has no counterpart in previous systems. The caller
- supplies a QNAME, QTYPE, and QCLASS, and wants all of the
- matching RRs. This function will often use the DNS format
- for all RR data instead of the local host's, and returns all
- RR content (e.g., TTL) instead of a processed form with local
- quoting conventions.
-
-When the resolver performs the indicated function, it usually has one of
-the following results to pass back to the client:
-
- - One or more RRs giving the requested data.
-
- In this case the resolver returns the answer in the
- appropriate format.
-
- - A name error (NE).
-
- This happens when the referenced name does not exist. For
- example, a user may have mistyped a host name.
-
- - A data not found error.
-
- This happens when the referenced name exists, but data of the
- appropriate type does not. For example, a host address
-
-
-
-Mockapetris [Page 30]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- function applied to a mailbox name would return this error
- since the name exists, but no address RR is present.
-
-It is important to note that the functions for translating between host
-names and addresses may combine the "name error" and "data not found"
-error conditions into a single type of error return, but the general
-function should not. One reason for this is that applications may ask
-first for one type of information about a name followed by a second
-request to the same name for some other type of information; if the two
-errors are combined, then useless queries may slow the application.
-
-5.2.2. Aliases
-
-While attempting to resolve a particular request, the resolver may find
-that the name in question is an alias. For example, the resolver might
-find that the name given for host name to address translation is an
-alias when it finds the CNAME RR. If possible, the alias condition
-should be signalled back from the resolver to the client.
-
-In most cases a resolver simply restarts the query at the new name when
-it encounters a CNAME. However, when performing the general function,
-the resolver should not pursue aliases when the CNAME RR matches the
-query type. This allows queries which ask whether an alias is present.
-For example, if the query type is CNAME, the user is interested in the
-CNAME RR itself, and not the RRs at the name it points to.
-
-Several special conditions can occur with aliases. Multiple levels of
-aliases should be avoided due to their lack of efficiency, but should
-not be signalled as an error. Alias loops and aliases which point to
-non-existent names should be caught and an error condition passed back
-to the client.
-
-5.2.3. Temporary failures
-
-In a less than perfect world, all resolvers will occasionally be unable
-to resolve a particular request. This condition can be caused by a
-resolver which becomes separated from the rest of the network due to a
-link failure or gateway problem, or less often by coincident failure or
-unavailability of all servers for a particular domain.
-
-It is essential that this sort of condition should not be signalled as a
-name or data not present error to applications. This sort of behavior
-is annoying to humans, and can wreak havoc when mail systems use the
-DNS.
-
-While in some cases it is possible to deal with such a temporary problem
-by blocking the request indefinitely, this is usually not a good choice,
-particularly when the client is a server process that could move on to
-
-
-
-Mockapetris [Page 31]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-other tasks. The recommended solution is to always have temporary
-failure as one of the possible results of a resolver function, even
-though this may make emulation of existing HOSTS.TXT functions more
-difficult.
-
-5.3. Resolver internals
-
-Every resolver implementation uses slightly different algorithms, and
-typically spends much more logic dealing with errors of various sorts
-than typical occurances. This section outlines a recommended basic
-strategy for resolver operation, but leaves details to [RFC-1035].
-
-5.3.1. Stub resolvers
-
-One option for implementing a resolver is to move the resolution
-function out of the local machine and into a name server which supports
-recursive queries. This can provide an easy method of providing domain
-service in a PC which lacks the resources to perform the resolver
-function, or can centralize the cache for a whole local network or
-organization.
-
-All that the remaining stub needs is a list of name server addresses
-that will perform the recursive requests. This type of resolver
-presumably needs the information in a configuration file, since it
-probably lacks the sophistication to locate it in the domain database.
-The user also needs to verify that the listed servers will perform the
-recursive service; a name server is free to refuse to perform recursive
-services for any or all clients. The user should consult the local
-system administrator to find name servers willing to perform the
-service.
-
-This type of service suffers from some drawbacks. Since the recursive
-requests may take an arbitrary amount of time to perform, the stub may
-have difficulty optimizing retransmission intervals to deal with both
-lost UDP packets and dead servers; the name server can be easily
-overloaded by too zealous a stub if it interprets retransmissions as new
-requests. Use of TCP may be an answer, but TCP may well place burdens
-on the host's capabilities which are similar to those of a real
-resolver.
-
-5.3.2. Resources
-
-In addition to its own resources, the resolver may also have shared
-access to zones maintained by a local name server. This gives the
-resolver the advantage of more rapid access, but the resolver must be
-careful to never let cached information override zone data. In this
-discussion the term "local information" is meant to mean the union of
-the cache and such shared zones, with the understanding that
-
-
-
-Mockapetris [Page 32]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-authoritative data is always used in preference to cached data when both
-are present.
-
-The following resolver algorithm assumes that all functions have been
-converted to a general lookup function, and uses the following data
-structures to represent the state of a request in progress in the
-resolver:
-
-SNAME the domain name we are searching for.
-
-STYPE the QTYPE of the search request.
-
-SCLASS the QCLASS of the search request.
-
-SLIST a structure which describes the name servers and the
- zone which the resolver is currently trying to query.
- This structure keeps track of the resolver's current
- best guess about which name servers hold the desired
- information; it is updated when arriving information
- changes the guess. This structure includes the
- equivalent of a zone name, the known name servers for
- the zone, the known addresses for the name servers, and
- history information which can be used to suggest which
- server is likely to be the best one to try next. The
- zone name equivalent is a match count of the number of
- labels from the root down which SNAME has in common with
- the zone being queried; this is used as a measure of how
- "close" the resolver is to SNAME.
-
-SBELT a "safety belt" structure of the same form as SLIST,
- which is initialized from a configuration file, and
- lists servers which should be used when the resolver
- doesn't have any local information to guide name server
- selection. The match count will be -1 to indicate that
- no labels are known to match.
-
-CACHE A structure which stores the results from previous
- responses. Since resolvers are responsible for
- discarding old RRs whose TTL has expired, most
- implementations convert the interval specified in
- arriving RRs to some sort of absolute time when the RR
- is stored in the cache. Instead of counting the TTLs
- down individually, the resolver just ignores or discards
- old RRs when it runs across them in the course of a
- search, or discards them during periodic sweeps to
- reclaim the memory consumed by old RRs.
-
-
-
-
-
-Mockapetris [Page 33]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-5.3.3. Algorithm
-
-The top level algorithm has four steps:
-
- 1. See if the answer is in local information, and if so return
- it to the client.
-
- 2. Find the best servers to ask.
-
- 3. Send them queries until one returns a response.
-
- 4. Analyze the response, either:
-
- a. if the response answers the question or contains a name
- error, cache the data as well as returning it back to
- the client.
-
- b. if the response contains a better delegation to other
- servers, cache the delegation information, and go to
- step 2.
-
- c. if the response shows a CNAME and that is not the
- answer itself, cache the CNAME, change the SNAME to the
- canonical name in the CNAME RR and go to step 1.
-
- d. if the response shows a servers failure or other
- bizarre contents, delete the server from the SLIST and
- go back to step 3.
-
-Step 1 searches the cache for the desired data. If the data is in the
-cache, it is assumed to be good enough for normal use. Some resolvers
-have an option at the user interface which will force the resolver to
-ignore the cached data and consult with an authoritative server. This
-is not recommended as the default. If the resolver has direct access to
-a name server's zones, it should check to see if the desired data is
-present in authoritative form, and if so, use the authoritative data in
-preference to cached data.
-
-Step 2 looks for a name server to ask for the required data. The
-general strategy is to look for locally-available name server RRs,
-starting at SNAME, then the parent domain name of SNAME, the
-grandparent, and so on toward the root. Thus if SNAME were
-Mockapetris.ISI.EDU, this step would look for NS RRs for
-Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
-These NS RRs list the names of hosts for a zone at or above SNAME. Copy
-the names into SLIST. Set up their addresses using local data. It may
-be the case that the addresses are not available. The resolver has many
-choices here; the best is to start parallel resolver processes looking
-
-
-
-Mockapetris [Page 34]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-for the addresses while continuing onward with the addresses which are
-available. Obviously, the design choices and options are complicated
-and a function of the local host's capabilities. The recommended
-priorities for the resolver designer are:
-
- 1. Bound the amount of work (packets sent, parallel processes
- started) so that a request can't get into an infinite loop or
- start off a chain reaction of requests or queries with other
- implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
- SOME DATA.
-
- 2. Get back an answer if at all possible.
-
- 3. Avoid unnecessary transmissions.
-
- 4. Get the answer as quickly as possible.
-
-If the search for NS RRs fails, then the resolver initializes SLIST from
-the safety belt SBELT. The basic idea is that when the resolver has no
-idea what servers to ask, it should use information from a configuration
-file that lists several servers which are expected to be helpful.
-Although there are special situations, the usual choice is two of the
-root servers and two of the servers for the host's domain. The reason
-for two of each is for redundancy. The root servers will provide
-eventual access to all of the domain space. The two local servers will
-allow the resolver to continue to resolve local names if the local
-network becomes isolated from the internet due to gateway or link
-failure.
-
-In addition to the names and addresses of the servers, the SLIST data
-structure can be sorted to use the best servers first, and to insure
-that all addresses of all servers are used in a round-robin manner. The
-sorting can be a simple function of preferring addresses on the local
-network over others, or may involve statistics from past events, such as
-previous response times and batting averages.
-
-Step 3 sends out queries until a response is received. The strategy is
-to cycle around all of the addresses for all of the servers with a
-timeout between each transmission. In practice it is important to use
-all addresses of a multihomed host, and too aggressive a retransmission
-policy actually slows response when used by multiple resolvers
-contending for the same name server and even occasionally for a single
-resolver. SLIST typically contains data values to control the timeouts
-and keep track of previous transmissions.
-
-Step 4 involves analyzing responses. The resolver should be highly
-paranoid in its parsing of responses. It should also check that the
-response matches the query it sent using the ID field in the response.
-
-
-
-Mockapetris [Page 35]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-The ideal answer is one from a server authoritative for the query which
-either gives the required data or a name error. The data is passed back
-to the user and entered in the cache for future use if its TTL is
-greater than zero.
-
-If the response shows a delegation, the resolver should check to see
-that the delegation is "closer" to the answer than the servers in SLIST
-are. This can be done by comparing the match count in SLIST with that
-computed from SNAME and the NS RRs in the delegation. If not, the reply
-is bogus and should be ignored. If the delegation is valid the NS
-delegation RRs and any address RRs for the servers should be cached.
-The name servers are entered in the SLIST, and the search is restarted.
-
-If the response contains a CNAME, the search is restarted at the CNAME
-unless the response has the data for the canonical name or if the CNAME
-is the answer itself.
-
-Details and implementation hints can be found in [RFC-1035].
-
-6. A SCENARIO
-
-In our sample domain space, suppose we wanted separate administrative
-control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might
-allocate name servers as follows:
-
-
- |(C.ISI.EDU,SRI-NIC.ARPA
- | A.ISI.EDU)
- +---------------------+------------------+
- | | |
- MIL EDU ARPA
- |(SRI-NIC.ARPA, |(SRI-NIC.ARPA, |
- | A.ISI.EDU | C.ISI.EDU) |
- +-----+-----+ | +------+-----+-----+
- | | | | | | |
- BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
- |
- +--------+------------------+---------------+--------+
- | | | | |
- UCI MIT | UDEL YALE
- |(XX.LCS.MIT.EDU, ISI
- |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
- +---+---+ | A.ISI.EDU)
- | | |
- LCS ACHILLES +--+-----+-----+--------+
- | | | | | |
- XX A C VAXA VENERA Mockapetris
-
-
-
-
-Mockapetris [Page 36]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-In this example, the authoritative name server is shown in parentheses
-at the point in the domain tree at which is assumes control.
-
-Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
-A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The
-EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers
-may have zones which are contiguous or disjoint. In this scenario,
-C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU
-has contiguous zones at the root and MIL domains, but also has a non-
-contiguous zone at ISI.EDU.
-
-6.1. C.ISI.EDU name server
-
-C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
-class, and would have zones for these domains. The zone data for the
-root domain might be:
-
- . IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
- 870611 ;serial
- 1800 ;refresh every 30 min
- 300 ;retry every 5 min
- 604800 ;expire after a week
- 86400) ;minimum of a day
- NS A.ISI.EDU.
- NS C.ISI.EDU.
- NS SRI-NIC.ARPA.
-
- MIL. 86400 NS SRI-NIC.ARPA.
- 86400 NS A.ISI.EDU.
-
- EDU. 86400 NS SRI-NIC.ARPA.
- 86400 NS C.ISI.EDU.
-
- SRI-NIC.ARPA. A 26.0.0.73
- A 10.0.0.51
- MX 0 SRI-NIC.ARPA.
- HINFO DEC-2060 TOPS20
-
- ACC.ARPA. A 26.6.0.65
- HINFO PDP-11/70 UNIX
- MX 10 ACC.ARPA.
-
- USC-ISIC.ARPA. CNAME C.ISI.EDU.
-
- 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
- 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA.
- 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
- 52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU.
-
-
-
-Mockapetris [Page 37]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
-
- A.ISI.EDU. 86400 A 26.3.0.103
- C.ISI.EDU. 86400 A 10.0.0.52
-
-This data is represented as it would be in a master file. Most RRs are
-single line entries; the sole exception here is the SOA RR, which uses
-"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
-Since the class of all RRs in a zone must be the same, only the first RR
-in a zone need specify the class. When a name server loads a zone, it
-forces the TTL of all authoritative RRs to be at least the MINIMUM field
-of the SOA, here 86400 seconds, or one day. The NS RRs marking
-delegation of the MIL and EDU domains, together with the glue RRs for
-the servers host addresses, are not part of the authoritative data in
-the zone, and hence have explicit TTLs.
-
-Four RRs are attached to the root node: the SOA which describes the root
-zone and the 3 NS RRs which list the name servers for the root. The
-data in the SOA RR describes the management of the zone. The zone data
-is maintained on host SRI-NIC.ARPA, and the responsible party for the
-zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400
-second minimum TTL, which means that all authoritative data in the zone
-has at least that TTL, although higher values may be explicitly
-specified.
-
-The NS RRs for the MIL and EDU domains mark the boundary between the
-root zone and the MIL and EDU zones. Note that in this example, the
-lower zones happen to be supported by name servers which also support
-the root zone.
-
-The master file for the EDU zone might be stated relative to the origin
-EDU. The zone data for the EDU domain might be:
-
- EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
- 870729 ;serial
- 1800 ;refresh every 30 minutes
- 300 ;retry every 5 minutes
- 604800 ;expire after a week
- 86400 ;minimum of a day
- )
- NS SRI-NIC.ARPA.
- NS C.ISI.EDU.
-
- UCI 172800 NS ICS.UCI
- 172800 NS ROME.UCI
- ICS.UCI 172800 A 192.5.19.1
- ROME.UCI 172800 A 192.5.19.31
-
-
-
-
-Mockapetris [Page 38]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- ISI 172800 NS VAXA.ISI
- 172800 NS A.ISI
- 172800 NS VENERA.ISI.EDU.
- VAXA.ISI 172800 A 10.2.0.27
- 172800 A 128.9.0.33
- VENERA.ISI.EDU. 172800 A 10.1.0.52
- 172800 A 128.9.0.32
- A.ISI 172800 A 26.3.0.103
-
- UDEL.EDU. 172800 NS LOUIE.UDEL.EDU.
- 172800 NS UMN-REI-UC.ARPA.
- LOUIE.UDEL.EDU. 172800 A 10.0.0.96
- 172800 A 192.5.39.3
-
- YALE.EDU. 172800 NS YALE.ARPA.
- YALE.EDU. 172800 NS YALE-BULLDOG.ARPA.
-
- MIT.EDU. 43200 NS XX.LCS.MIT.EDU.
- 43200 NS ACHILLES.MIT.EDU.
- XX.LCS.MIT.EDU. 43200 A 10.0.0.44
- ACHILLES.MIT.EDU. 43200 A 18.72.0.8
-
-Note the use of relative names here. The owner name for the ISI.EDU. is
-stated using a relative name, as are two of the name server RR contents.
-Relative and absolute domain names may be freely intermixed in a master
-
-6.2. Example standard queries
-
-The following queries and responses illustrate name server behavior.
-Unless otherwise noted, the queries do not have recursion desired (RD)
-in the header. Note that the answers to non-recursive queries do depend
-on the server being asked, but do not depend on the identity of the
-requester.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 39]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
-
-The query would look like:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY |
- +---------------------------------------------------+
- Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
- +---------------------------------------------------+
- Answer | <empty> |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-The response from C.ISI.EDU would be:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
- +---------------------------------------------------+
- Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
- | 86400 IN A 10.0.0.51 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-The header of the response looks like the header of the query, except
-that the RESPONSE bit is set, indicating that this message is a
-response, not a query, and the Authoritative Answer (AA) bit is set
-indicating that the address RRs in the answer section are from
-authoritative data. The question section of the response matches the
-question section of the query.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 40]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-If the same query was sent to some other server which was not
-authoritative for SRI-NIC.ARPA, the response might be:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY,RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
- +---------------------------------------------------+
- Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 |
- | 1777 IN A 26.0.0.73 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-This response is different from the previous one in two ways: the header
-does not have AA set, and the TTLs are different. The inference is that
-the data did not come from a zone, but from a cache. The difference
-between the authoritative TTL and the TTL here is due to aging of the
-data in a cache. The difference in ordering of the RRs in the answer
-section is not significant.
-
-6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
-
-A query similar to the previous one, but using a QTYPE of *, would
-receive the following response from C.ISI.EDU:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
- +---------------------------------------------------+
- Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
- | A 10.0.0.51 |
- | MX 0 SRI-NIC.ARPA. |
- | HINFO DEC-2060 TOPS20 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 41]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-If a similar query was directed to two name servers which are not
-authoritative for SRI-NIC.ARPA, the responses might be:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
- +---------------------------------------------------+
- Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 |
- | A 10.0.0.51 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-and
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
- +---------------------------------------------------+
- Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-Neither of these answers have AA set, so neither response comes from
-authoritative data. The different contents and different TTLs suggest
-that the two servers cached data at different times, and that the first
-server cached the response to a QTYPE=A query and the second cached the
-response to a HINFO query.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 42]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
-
-This type of query might be result from a mailer trying to look up
-routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
-The response from C.ISI.EDU would be:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX |
- +---------------------------------------------------+
- Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.|
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
- | A 10.0.0.51 |
- +---------------------------------------------------+
-
-This response contains the MX RR in the answer section of the response.
-The additional section contains the address RRs because the name server
-at C.ISI.EDU guesses that the requester will need the addresses in order
-to properly use the information carried by the MX.
-
-6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
-
-C.ISI.EDU would reply to this query with:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS |
- +---------------------------------------------------+
- Answer | <empty> |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-The only difference between the response and the query is the AA and
-RESPONSE bits in the header. The interpretation of this response is
-that the server is authoritative for the name, and the name exists, but
-no RRs of type NS are present there.
-
-6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
-
-If a user mistyped a host name, we might see this type of query.
-
-
-
-Mockapetris [Page 43]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-C.ISI.EDU would answer it with:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE |
- +---------------------------------------------------+
- Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A |
- +---------------------------------------------------+
- Answer | <empty> |
- +---------------------------------------------------+
- Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. |
- | 870611 1800 300 604800 86400 |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-This response states that the name does not exist. This condition is
-signalled in the response code (RCODE) section of the header.
-
-The SOA RR in the authority section is the optional negative caching
-information which allows the resolver using this response to assume that
-the name will not exist for the SOA MINIMUM (86400) seconds.
-
-6.2.6. QNAME=BRL.MIL, QTYPE=A
-
-If this query is sent to C.ISI.EDU, the reply would be:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A |
- +---------------------------------------------------+
- Answer | <empty> |
- +---------------------------------------------------+
- Authority | MIL. 86400 IN NS SRI-NIC.ARPA. |
- | 86400 NS A.ISI.EDU. |
- +---------------------------------------------------+
- Additional | A.ISI.EDU. A 26.3.0.103 |
- | SRI-NIC.ARPA. A 26.0.0.73 |
- | A 10.0.0.51 |
- +---------------------------------------------------+
-
-This response has an empty answer section, but is not authoritative, so
-it is a referral. The name server on C.ISI.EDU, realizing that it is
-not authoritative for the MIL domain, has referred the requester to
-servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
-for the MIL domain.
-
-
-
-
-
-Mockapetris [Page 44]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
-
-The response to this query from A.ISI.EDU would be:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
- +---------------------------------------------------+
- Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
- | C.ISI.EDU. 86400 IN A 10.0.0.52 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-Note that the AA bit in the header guarantees that the data matching
-QNAME is authoritative, but does not say anything about whether the data
-for C.ISI.EDU is authoritative. This complete reply is possible because
-A.ISI.EDU happens to be authoritative for both the ARPA domain where
-USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
-found.
-
-If the same query was sent to C.ISI.EDU, its response might be the same
-as shown above if it had its own address in its cache, but might also
-be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 45]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
- +---------------------------------------------------+
- Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
- +---------------------------------------------------+
- Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
- | NS A.ISI.EDU. |
- | NS VENERA.ISI.EDU. |
- +---------------------------------------------------+
- Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
- | 172800 A 128.9.0.33 |
- | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
- | 172800 A 128.9.0.32 |
- | A.ISI.EDU. 172800 A 26.3.0.103 |
- +---------------------------------------------------+
-
-This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
-plus a referral to the name servers for ISI.EDU. This sort of reply
-isn't very likely given that the query is for the host name of the name
-server being asked, but would be common for other aliases.
-
-6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
-
-If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
-be:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
- +---------------------------------------------------+
- Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
-server doesn't attempt to look up anything for C.ISI.EDU. (Except
-possibly for the additional section.)
-
-6.3. Example resolution
-
-The following examples illustrate the operations a resolver must perform
-for its client. We assume that the resolver is starting without a
-
-
-
-Mockapetris [Page 46]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-cache, as might be the case after system boot. We further assume that
-the system is not one of the hosts in the data and that the host is
-located somewhere on net 26, and that its safety belt (SBELT) data
-structure has the following information:
-
- Match count = -1
- SRI-NIC.ARPA. 26.0.0.73 10.0.0.51
- A.ISI.EDU. 26.3.0.103
-
-This information specifies servers to try, their addresses, and a match
-count of -1, which says that the servers aren't very close to the
-target. Note that the -1 isn't supposed to be an accurate closeness
-measure, just a value so that later stages of the algorithm will work.
-
-The following examples illustrate the use of a cache, so each example
-assumes that previous requests have completed.
-
-6.3.1. Resolve MX for ISI.EDU.
-
-Suppose the first request to the resolver comes from the local mailer,
-which has mail for PVM@ISI.EDU. The mailer might then ask for type MX
-RRs for the domain name ISI.EDU.
-
-The resolver would look in its cache for MX RRs at ISI.EDU, but the
-empty cache wouldn't be helpful. The resolver would recognize that it
-needed to query foreign servers and try to determine the best servers to
-query. This search would look for NS RRs for the domains ISI.EDU, EDU,
-and the root. These searches of the cache would also fail. As a last
-resort, the resolver would use the information from the SBELT, copying
-it into its SLIST structure.
-
-At this point the resolver would need to pick one of the three available
-addresses to try. Given that the resolver is on net 26, it should
-choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would
-then send off a query of the form:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 47]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY |
- +---------------------------------------------------+
- Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
- +---------------------------------------------------+
- Answer | <empty> |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-The resolver would then wait for a response to its query or a timeout.
-If the timeout occurs, it would try different servers, then different
-addresses of the same servers, lastly retrying addresses already tried.
-It might eventually receive a reply from SRI-NIC.ARPA:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
- +---------------------------------------------------+
- Answer | <empty> |
- +---------------------------------------------------+
- Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
- | NS A.ISI.EDU. |
- | NS VENERA.ISI.EDU.|
- +---------------------------------------------------+
- Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
- | 172800 A 128.9.0.33 |
- | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
- | 172800 A 128.9.0.32 |
- | A.ISI.EDU. 172800 A 26.3.0.103 |
- +---------------------------------------------------+
-
-The resolver would notice that the information in the response gave a
-closer delegation to ISI.EDU than its existing SLIST (since it matches
-three labels). The resolver would then cache the information in this
-response and use it to set up a new SLIST:
-
- Match count = 3
- A.ISI.EDU. 26.3.0.103
- VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
- VENERA.ISI.EDU. 10.1.0.52 128.9.0.32
-
-A.ISI.EDU appears on this list as well as the previous one, but that is
-purely coincidental. The resolver would again start transmitting and
-waiting for responses. Eventually it would get an answer:
-
-
-
-Mockapetris [Page 48]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
- +---------------------------------------------------+
- Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. |
- | MX 20 VAXA.ISI.EDU. |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
- | 172800 A 128.9.0.33 |
- | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
- | 172800 A 128.9.0.32 |
- +---------------------------------------------------+
-
-The resolver would add this information to its cache, and return the MX
-RRs to its client.
-
-6.3.2. Get the host name for address 26.6.0.65
-
-The resolver would translate this into a request for PTR RRs for
-65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the
-resolver would look for foreign servers to ask. No servers would match,
-so it would use SBELT again. (Note that the servers for the ISI.EDU
-domain are in the cache, but ISI.EDU is not an ancestor of
-65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
-
-Since this request is within the authoritative data of both servers in
-SBELT, eventually one would return:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 49]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +---------------------------------------------------+
- Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
- +---------------------------------------------------+
- Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-6.3.3. Get the host address of poneria.ISI.EDU
-
-This request would translate into a type A request for poneria.ISI.EDU.
-The resolver would not find any cached data for this name, but would
-find the NS RRs in the cache for ISI.EDU when it looks for foreign
-servers to ask. Using this data, it would construct a SLIST of the
-form:
-
- Match count = 3
-
- A.ISI.EDU. 26.3.0.103
- VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
- VENERA.ISI.EDU. 10.1.0.52
-
-A.ISI.EDU is listed first on the assumption that the resolver orders its
-choices by preference, and A.ISI.EDU is on the same network.
-
-One of these servers would answer the query.
-
-7. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena
- Technical Plan - Name Service, April 1987, version 1.9.
-
- Describes the fundamentals of the Hesiod name service.
-
-[IEN-116] J. Postel, "Internet Name Server", IEN-116,
- USC/Information Sciences Institute, August 1979.
-
- A name service obsoleted by the Domain Name System, but
- still in use.
-
-
-
-
-
-
-
-
-Mockapetris [Page 50]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
- Networks",Communications of the ACM, October 1986,
- volume 29, number 10.
-
-[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
- Information Center, SRI International, December 1977.
-
-[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
- USC/Information Sciences Institute, September 1981.
-
-[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
- September 1981.
-
- Suggests introduction of a hierarchy in place of a flat
- name space for the Internet.
-
-[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
- USC/Information Sciences Institute, February 1982.
-
-[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
- Internet Host Table Specification", RFC-810, Network
- Information Center, SRI International, March 1982.
-
- Obsolete. See RFC-952.
-
-[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
- Server", RFC-811, Network Information Center, SRI
- International, March 1982.
-
- Obsolete. See RFC-953.
-
-[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
- Network Information Center, SRI International, March
- 1982.
-
-[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
- Internet User Applications", RFC-819, Network
- Information Center, SRI International, August 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
- USC/Information Sciences Institute, August 1980.
-
-
-
-
-Mockapetris [Page 51]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
- RFC-830, Network Information Center, SRI International,
- October 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-882] P. Mockapetris, "Domain names - Concepts and
- Facilities," RFC-882, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-883] P. Mockapetris, "Domain names - Implementation and
- Specification," RFC-883, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
- RFC-920, USC/Information Sciences Institute
- October 1984.
-
- Explains the naming scheme for top level domains.
-
-[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
- Table Specification", RFC-952, SRI, October 1985.
-
- Specifies the format of HOSTS.TXT, the host/address
- table replaced by the DNS.
-
-[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
- RFC-953, SRI, October 1985.
-
- This RFC contains the official specification of the
- hostname server protocol, which is obsoleted by the DNS.
- This TCP based protocol accesses information stored in
- the RFC-952 format, and is used to obtain copies of the
- host table.
-
-[RFC-973] P. Mockapetris, "Domain System Changes and
- Observations", RFC-973, USC/Information Sciences
- Institute, January 1986.
-
- Describes changes to RFC-882 and RFC-883 and reasons for
- them. Now obsolete.
-
-
-
-
-
-Mockapetris [Page 52]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-[RFC-974] C. Partridge, "Mail routing and the domain system",
- RFC-974, CSNET CIC BBN Labs, January 1986.
-
- Describes the transition from HOSTS.TXT based mail
- addressing to the more powerful MX system used with the
- domain system.
-
-[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Concepts and Methods",
- RFC-1001, March 1987.
-
- This RFC and RFC-1002 are a preliminary design for
- NETBIOS on top of TCP/IP which proposes to base NetBIOS
- name service on top of the DNS.
-
-[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Detailed
- Specifications", RFC-1002, March 1987.
-
-[RFC-1010] J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
- USC/Information Sciences Institute, May 1987
-
- Contains socket numbers and mnemonics for host names,
- operating systems, etc.
-
-[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
- November 1987.
-
- Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032] M. K. Stahl, "Establishing a Domain - Guidelines for
- Administrators", RFC-1032, November 1987.
-
- Describes the registration policies used by the NIC to
- administer the top level domains and delegate subzones.
-
-[RFC-1033] M. K. Lottor, "Domain Administrators Operations Guide",
- RFC-1033, November 1987.
-
- A cookbook for domain administrators.
-
-[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
- Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
- Describes a name service for CSNET which is independent
- from the DNS and DNS use in the CSNET.
-
-
-
-
-
-Mockapetris [Page 53]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
-Index
-
- A 12
- Absolute names 8
- Aliases 14, 31
- Authority 6
- AXFR 17
-
- Case of characters 7
- CH 12
- CNAME 12, 13, 31
- Completion queries 18
-
- Domain name 6, 7
-
- Glue RRs 20
-
- HINFO 12
-
- IN 12
- Inverse queries 16
- Iterative 4
-
- Label 7
-
- Mailbox names 9
- MX 12
-
- Name error 27, 36
- Name servers 5, 17
- NE 30
- Negative caching 44
- NS 12
-
- Opcode 16
-
- PTR 12
-
- QCLASS 16
- QTYPE 16
-
- RDATA 13
- Recursive 4
- Recursive service 22
- Relative names 7
- Resolvers 6
- RR 12
-
-
-
-
-Mockapetris [Page 54]
-
-RFC 1034 Domain Concepts and Facilities November 1987
-
-
- Safety belt 33
- Sections 16
- SOA 12
- Standard queries 22
-
- Status queries 18
- Stub resolvers 32
-
- TTL 12, 13
-
- Wildcards 25
-
- Zone transfers 28
- Zones 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 55]
-
diff --git a/contrib/bind9/doc/rfc/rfc1035.txt b/contrib/bind9/doc/rfc/rfc1035.txt
deleted file mode 100644
index b1a9bf5a94b66..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1035.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group P. Mockapetris
-Request for Comments: 1035 ISI
- November 1987
-Obsoletes: RFCs 882, 883, 973
-
- DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-
-
-1. STATUS OF THIS MEMO
-
-This RFC describes the details of the domain system and protocol, and
-assumes that the reader is familiar with the concepts discussed in a
-companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
-
-The domain system is a mixture of functions and data types which are an
-official protocol and functions and data types which are still
-experimental. Since the domain system is intentionally extensible, new
-data types and experimental behavior should always be expected in parts
-of the system beyond the official protocol. The official protocol parts
-include standard queries, responses and the Internet class RR data
-formats (e.g., host addresses). Since the previous RFC set, several
-definitions have changed, so some previous definitions are obsolete.
-
-Experimental or obsolete features are clearly marked in these RFCs, and
-such information should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical. Distribution of this memo is unlimited.
-
- Table of Contents
-
- 1. STATUS OF THIS MEMO 1
- 2. INTRODUCTION 3
- 2.1. Overview 3
- 2.2. Common configurations 4
- 2.3. Conventions 7
- 2.3.1. Preferred name syntax 7
- 2.3.2. Data Transmission Order 8
- 2.3.3. Character Case 9
- 2.3.4. Size limits 10
- 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
- 3.1. Name space definitions 10
- 3.2. RR definitions 11
- 3.2.1. Format 11
- 3.2.2. TYPE values 12
- 3.2.3. QTYPE values 12
- 3.2.4. CLASS values 13
-
-
-
-Mockapetris [Page 1]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 3.2.5. QCLASS values 13
- 3.3. Standard RRs 13
- 3.3.1. CNAME RDATA format 14
- 3.3.2. HINFO RDATA format 14
- 3.3.3. MB RDATA format (EXPERIMENTAL) 14
- 3.3.4. MD RDATA format (Obsolete) 15
- 3.3.5. MF RDATA format (Obsolete) 15
- 3.3.6. MG RDATA format (EXPERIMENTAL) 16
- 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
- 3.3.8. MR RDATA format (EXPERIMENTAL) 17
- 3.3.9. MX RDATA format 17
- 3.3.10. NULL RDATA format (EXPERIMENTAL) 17
- 3.3.11. NS RDATA format 18
- 3.3.12. PTR RDATA format 18
- 3.3.13. SOA RDATA format 19
- 3.3.14. TXT RDATA format 20
- 3.4. ARPA Internet specific RRs 20
- 3.4.1. A RDATA format 20
- 3.4.2. WKS RDATA format 21
- 3.5. IN-ADDR.ARPA domain 22
- 3.6. Defining new types, classes, and special namespaces 24
- 4. MESSAGES 25
- 4.1. Format 25
- 4.1.1. Header section format 26
- 4.1.2. Question section format 28
- 4.1.3. Resource record format 29
- 4.1.4. Message compression 30
- 4.2. Transport 32
- 4.2.1. UDP usage 32
- 4.2.2. TCP usage 32
- 5. MASTER FILES 33
- 5.1. Format 33
- 5.2. Use of master files to define zones 35
- 5.3. Master file example 36
- 6. NAME SERVER IMPLEMENTATION 37
- 6.1. Architecture 37
- 6.1.1. Control 37
- 6.1.2. Database 37
- 6.1.3. Time 39
- 6.2. Standard query processing 39
- 6.3. Zone refresh and reload processing 39
- 6.4. Inverse queries (Optional) 40
- 6.4.1. The contents of inverse queries and responses 40
- 6.4.2. Inverse query and response example 41
- 6.4.3. Inverse query processing 42
-
-
-
-
-
-
-Mockapetris [Page 2]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 6.5. Completion queries and responses 42
- 7. RESOLVER IMPLEMENTATION 43
- 7.1. Transforming a user request into a query 43
- 7.2. Sending the queries 44
- 7.3. Processing responses 46
- 7.4. Using the cache 47
- 8. MAIL SUPPORT 47
- 8.1. Mail exchange binding 48
- 8.2. Mailbox binding (Experimental) 48
- 9. REFERENCES and BIBLIOGRAPHY 50
- Index 54
-
-2. INTRODUCTION
-
-2.1. Overview
-
-The goal of domain names is to provide a mechanism for naming resources
-in such a way that the names are usable in different hosts, networks,
-protocol families, internets, and administrative organizations.
-
-From the user's point of view, domain names are useful as arguments to a
-local agent, called a resolver, which retrieves information associated
-with the domain name. Thus a user might ask for the host address or
-mail information associated with a particular domain name. To enable
-the user to request a particular type of information, an appropriate
-query type is passed to the resolver with the domain name. To the user,
-the domain tree is a single information space; the resolver is
-responsible for hiding the distribution of data among name servers from
-the user.
-
-From the resolver's point of view, the database that makes up the domain
-space is distributed among various name servers. Different parts of the
-domain space are stored in different name servers, although a particular
-data item will be stored redundantly in two or more name servers. The
-resolver starts with knowledge of at least one name server. When the
-resolver processes a user query it asks a known name server for the
-information; in return, the resolver either receives the desired
-information or a referral to another name server. Using these
-referrals, resolvers learn the identities and contents of other name
-servers. Resolvers are responsible for dealing with the distribution of
-the domain space and dealing with the effects of name server failure by
-consulting redundant databases in other servers.
-
-Name servers manage two kinds of data. The first kind of data held in
-sets called zones; each zone is the complete database for a particular
-"pruned" subtree of the domain space. This data is called
-authoritative. A name server periodically checks to make sure that its
-zones are up to date, and if not, obtains a new copy of updated zones
-
-
-
-Mockapetris [Page 3]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-from master files stored locally or in another name server. The second
-kind of data is cached data which was acquired by a local resolver.
-This data may be incomplete, but improves the performance of the
-retrieval process when non-local data is repeatedly accessed. Cached
-data is eventually discarded by a timeout mechanism.
-
-This functional structure isolates the problems of user interface,
-failure recovery, and distribution in the resolvers and isolates the
-database update and refresh problems in the name servers.
-
-2.2. Common configurations
-
-A host can participate in the domain name system in a number of ways,
-depending on whether the host runs programs that retrieve information
-from the domain system, name servers that answer queries from other
-hosts, or various combinations of both functions. The simplest, and
-perhaps most typical, configuration is shown below:
-
- Local Host | Foreign
- |
- +---------+ +----------+ | +--------+
- | | user queries | |queries | | |
- | User |-------------->| |---------|->|Foreign |
- | Program | | Resolver | | | Name |
- | |<--------------| |<--------|--| Server |
- | | user responses| |responses| | |
- +---------+ +----------+ | +--------+
- | A |
- cache additions | | references |
- V | |
- +----------+ |
- | cache | |
- +----------+ |
-
-User programs interact with the domain name space through resolvers; the
-format of user queries and user responses is specific to the host and
-its operating system. User queries will typically be operating system
-calls, and the resolver and its cache will be part of the host operating
-system. Less capable hosts may choose to implement the resolver as a
-subroutine to be linked in with every program that needs its services.
-Resolvers answer user queries with information they acquire via queries
-to foreign name servers and the local cache.
-
-Note that the resolver may have to make several queries to several
-different foreign name servers to answer a particular user query, and
-hence the resolution of a user query may involve several network
-accesses and an arbitrary amount of time. The queries to foreign name
-servers and the corresponding responses have a standard format described
-
-
-
-Mockapetris [Page 4]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-in this memo, and may be datagrams.
-
-Depending on its capabilities, a name server could be a stand alone
-program on a dedicated machine or a process or processes on a large
-timeshared host. A simple configuration might be:
-
- Local Host | Foreign
- |
- +---------+ |
- / /| |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
-
-Here a primary name server acquires information about one or more zones
-by reading master files from its local file system, and answers queries
-about those zones that arrive from foreign resolvers.
-
-The DNS requires that all zones be redundantly supported by more than
-one name server. Designated secondary servers can acquire zones and
-check for updates from the primary server using the zone transfer
-protocol of the DNS. This configuration is shown below:
-
- Local Host | Foreign
- |
- +---------+ |
- / /| |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
- A |maintenance | +--------+
- | +------------|->| |
- | queries | |Foreign |
- | | | Name |
- +------------------|--| Server |
- maintenance responses | +--------+
-
-In this configuration, the name server periodically establishes a
-virtual circuit to a foreign name server to acquire a copy of a zone or
-to check that an existing copy has not changed. The messages sent for
-
-
-
-Mockapetris [Page 5]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-these maintenance activities follow the same form as queries and
-responses, but the message sequences are somewhat different.
-
-The information flow in a host that supports all aspects of the domain
-name system is shown below:
-
- Local Host | Foreign
- |
- +---------+ +----------+ | +--------+
- | | user queries | |queries | | |
- | User |-------------->| |---------|->|Foreign |
- | Program | | Resolver | | | Name |
- | |<--------------| |<--------|--| Server |
- | | user responses| |responses| | |
- +---------+ +----------+ | +--------+
- | A |
- cache additions | | references |
- V | |
- +----------+ |
- | Shared | |
- | database | |
- +----------+ |
- A | |
- +---------+ refreshes | | references |
- / /| | V |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
- A |maintenance | +--------+
- | +------------|->| |
- | queries | |Foreign |
- | | | Name |
- +------------------|--| Server |
- maintenance responses | +--------+
-
-The shared database holds domain space data for the local name server
-and resolver. The contents of the shared database will typically be a
-mixture of authoritative data maintained by the periodic refresh
-operations of the name server and cached data from previous resolver
-requests. The structure of the domain data and the necessity for
-synchronization between name servers and resolvers imply the general
-characteristics of this database, but the actual format is up to the
-local implementor.
-
-
-
-
-Mockapetris [Page 6]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Information flow can also be tailored so that a group of hosts act
-together to optimize activities. Sometimes this is done to offload less
-capable hosts so that they do not have to implement a full resolver.
-This can be appropriate for PCs or hosts which want to minimize the
-amount of new network code which is required. This scheme can also
-allow a group of hosts can share a small number of caches rather than
-maintaining a large number of separate caches, on the premise that the
-centralized caches will have a higher hit ratio. In either case,
-resolvers are replaced with stub resolvers which act as front ends to
-resolvers located in a recursive server in one or more name servers
-known to perform that service:
-
- Local Hosts | Foreign
- |
- +---------+ |
- | | responses |
- | Stub |<--------------------+ |
- | Resolver| | |
- | |----------------+ | |
- +---------+ recursive | | |
- queries | | |
- V | |
- +---------+ recursive +----------+ | +--------+
- | | queries | |queries | | |
- | Stub |-------------->| Recursive|---------|->|Foreign |
- | Resolver| | Server | | | Name |
- | |<--------------| |<--------|--| Server |
- +---------+ responses | |responses| | |
- +----------+ | +--------+
- | Central | |
- | cache | |
- +----------+ |
-
-In any case, note that domain components are always replicated for
-reliability whenever possible.
-
-2.3. Conventions
-
-The domain system has several conventions dealing with low-level, but
-fundamental, issues. While the implementor is free to violate these
-conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
-ALL behavior observed from other hosts.
-
-2.3.1. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-for constructing domain names. The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-
-
-
-Mockapetris [Page 7]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822. When creating a new host name,
-the old rules for HOSTS.TXT should be followed. This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case. That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names. They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen. There are also some
-restrictions on the length. Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
-
-2.3.2. Data Transmission Order
-
-The order of transmission of the header and data described in this
-document is resolved to the octet level. Whenever a diagram shows a
-
-
-
-Mockapetris [Page 8]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-group of octets, the order of transmission of those octets is the normal
-order in which they are read in English. For example, in the following
-diagram, the octets are transmitted in the order they are numbered.
-
- 0 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 1 | 2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 3 | 4 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 5 | 6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Whenever an octet represents a numeric quantity, the left most bit in
-the diagram is the high order or most significant bit. That is, the bit
-labeled 0 is the most significant bit. For example, the following
-diagram represents the value 170 (decimal).
-
- 0 1 2 3 4 5 6 7
- +-+-+-+-+-+-+-+-+
- |1 0 1 0 1 0 1 0|
- +-+-+-+-+-+-+-+-+
-
-Similarly, whenever a multi-octet field represents a numeric quantity
-the left most bit of the whole field is the most significant bit. When
-a multi-octet quantity is transmitted the most significant octet is
-transmitted first.
-
-2.3.3. Character Case
-
-For all parts of the DNS that are part of the official protocol, all
-comparisons between character strings (e.g., labels, domain names, etc.)
-are done in a case-insensitive manner. At present, this rule is in
-force throughout the domain system without exception. However, future
-additions beyond current usage may need to use the full binary octet
-capabilities in names, so attempts to store domain names in 7-bit ASCII
-or use of special bytes to terminate labels, etc., should be avoided.
-
-When data enters the domain system, its original case should be
-preserved whenever possible. In certain circumstances this cannot be
-done. For example, if two RRs are stored in a database, one at x.y and
-one at X.Y, they are actually stored at the same place in the database,
-and hence only one casing would be preserved. The basic rule is that
-case can be discarded only when data is used to define structure in a
-database, and two names are identical when compared in a case
-insensitive manner.
-
-
-
-
-Mockapetris [Page 9]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Loss of case sensitive data must be minimized. Thus while data for x.y
-and X.Y may both be stored under a single location x.y or X.Y, data for
-a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
-general, this preserves the case of the first label of a domain name,
-but forces standardization of interior node labels.
-
-Systems administrators who enter data into the domain database should
-take care to represent the data they supply to the domain system in a
-case-consistent manner if their system is case-sensitive. The data
-distribution system in the domain system will ensure that consistent
-representations are preserved.
-
-2.3.4. Size limits
-
-Various objects and parameters in the DNS have size limits. They are
-listed below. Some could be easily changed, others are more
-fundamental.
-
-labels 63 octets or less
-
-names 255 octets or less
-
-TTL positive values of a signed 32 bit number.
-
-UDP messages 512 octets or less
-
-3. DOMAIN NAME SPACE AND RR DEFINITIONS
-
-3.1. Name space definitions
-
-Domain names in messages are expressed in terms of a sequence of labels.
-Each label is represented as a one octet length field followed by that
-number of octets. Since every domain name ends with the null label of
-the root, a domain name is terminated by a length byte of zero. The
-high order two bits of every length octet must be zero, and the
-remaining six bits of the length field limit the label to 63 octets or
-less.
-
-To simplify implementations, the total length of a domain name (i.e.,
-label octets and label length octets) is restricted to 255 octets or
-less.
-
-Although labels can contain any 8 bit values in octets that make up a
-label, it is strongly recommended that labels follow the preferred
-syntax described elsewhere in this memo, which is compatible with
-existing host naming conventions. Name servers and resolvers must
-compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
-with zero parity. Non-alphabetic codes must match exactly.
-
-
-
-Mockapetris [Page 10]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.2. RR definitions
-
-3.2.1. Format
-
-All RRs have the same top level format shown below:
-
- 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 /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-where:
-
-NAME an owner name, i.e., the name of the node to which this
- resource record pertains.
-
-TYPE two octets containing one of the RR TYPE codes.
-
-CLASS two octets containing one of the RR CLASS codes.
-
-TTL a 32 bit signed integer that specifies the time interval
- that the resource record may be cached before the source
- of the information should again be consulted. Zero
- values are interpreted to mean that the RR can only be
- used for the transaction in progress, and should not be
- cached. For example, SOA records are always distributed
- with a zero TTL to prohibit caching. Zero values can
- also be used for extremely volatile data.
-
-RDLENGTH an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
-
-
-Mockapetris [Page 11]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-RDATA a variable length string of octets that describes the
- resource. The format of this information varies
- according to the TYPE and CLASS of the resource record.
-
-3.2.2. TYPE values
-
-TYPE fields are used in resource records. Note that these types are a
-subset of QTYPEs.
-
-TYPE value and meaning
-
-A 1 a host address
-
-NS 2 an authoritative name server
-
-MD 3 a mail destination (Obsolete - use MX)
-
-MF 4 a mail forwarder (Obsolete - use MX)
-
-CNAME 5 the canonical name for an alias
-
-SOA 6 marks the start of a zone of authority
-
-MB 7 a mailbox domain name (EXPERIMENTAL)
-
-MG 8 a mail group member (EXPERIMENTAL)
-
-MR 9 a mail rename domain name (EXPERIMENTAL)
-
-NULL 10 a null RR (EXPERIMENTAL)
-
-WKS 11 a well known service description
-
-PTR 12 a domain name pointer
-
-HINFO 13 host information
-
-MINFO 14 mailbox or mail list information
-
-MX 15 mail exchange
-
-TXT 16 text strings
-
-3.2.3. QTYPE values
-
-QTYPE fields appear in the question part of a query. QTYPES are a
-superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
-following QTYPEs are defined:
-
-
-
-Mockapetris [Page 12]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-AXFR 252 A request for a transfer of an entire zone
-
-MAILB 253 A request for mailbox-related records (MB, MG or MR)
-
-MAILA 254 A request for mail agent RRs (Obsolete - see MX)
-
-* 255 A request for all records
-
-3.2.4. CLASS values
-
-CLASS fields appear in resource records. The following CLASS mnemonics
-and values are defined:
-
-IN 1 the Internet
-
-CS 2 the CSNET class (Obsolete - used only for examples in
- some obsolete RFCs)
-
-CH 3 the CHAOS class
-
-HS 4 Hesiod [Dyer 87]
-
-3.2.5. QCLASS values
-
-QCLASS fields appear in the question section of a query. QCLASS values
-are a superset of CLASS values; every CLASS is a valid QCLASS. In
-addition to CLASS values, the following QCLASSes are defined:
-
-* 255 any class
-
-3.3. Standard RRs
-
-The following RR definitions are expected to occur, at least
-potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
-will be used in all classes, and have the same format in all classes.
-Because their RDATA format is known, all domain names in the RDATA
-section of these RRs may be compressed.
-
-<domain-name> is a domain name represented as a series of labels, and
-terminated by a label with zero length. <character-string> is a single
-length octet followed by that number of characters. <character-string>
-is treated as binary information, and can be up to 256 characters in
-length (including the length octet).
-
-
-
-
-
-
-
-
-Mockapetris [Page 13]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.1. CNAME RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / CNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CNAME A <domain-name> which specifies the canonical or primary
- name for the owner. The owner name is an alias.
-
-CNAME RRs cause no additional section processing, but name servers may
-choose to restart the query at the canonical name in certain cases. See
-the description of name server logic in [RFC-1034] for details.
-
-3.3.2. HINFO RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / CPU /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / OS /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CPU A <character-string> which specifies the CPU type.
-
-OS A <character-string> which specifies the operating
- system type.
-
-Standard values for CPU and OS can be found in [RFC-1010].
-
-HINFO records are used to acquire general information about a host. The
-main use is for protocols such as FTP that can use special procedures
-when talking between machines or operating systems of the same type.
-
-3.3.3. MB RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has the
- specified mailbox.
-
-
-
-Mockapetris [Page 14]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-MB records cause additional section processing which looks up an A type
-RRs corresponding to MADNAME.
-
-3.3.4. MD RDATA format (Obsolete)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has a mail
- agent for the domain which should be able to deliver
- mail for the domain.
-
-MD records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MD is obsolete. See the definition of MX and [RFC-974] for details of
-the new scheme. The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 0.
-
-3.3.5. MF RDATA format (Obsolete)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has a mail
- agent for the domain which will accept mail for
- forwarding to the domain.
-
-MF records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MF is obsolete. See the definition of MX and [RFC-974] for details ofw
-the new scheme. The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 10.
-
-
-
-
-
-
-
-Mockapetris [Page 15]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.6. MG RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MGMNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MGMNAME A <domain-name> which specifies a mailbox which is a
- member of the mail group specified by the domain name.
-
-MG records cause no additional section processing.
-
-3.3.7. MINFO RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RMAILBX /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EMAILBX /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-RMAILBX A <domain-name> which specifies a mailbox which is
- responsible for the mailing list or mailbox. If this
- domain name names the root, the owner of the MINFO RR is
- responsible for itself. Note that many existing mailing
- lists use a mailbox X-request for the RMAILBX field of
- mailing list X, e.g., Msgroup-request for Msgroup. This
- field provides a more general mechanism.
-
-
-EMAILBX A <domain-name> which specifies a mailbox which is to
- receive error messages related to the mailing list or
- mailbox specified by the owner of the MINFO RR (similar
- to the ERRORS-TO: field which has been proposed). If
- this domain name names the root, errors should be
- returned to the sender of the message.
-
-MINFO records cause no additional section processing. Although these
-records can be associated with a simple mailbox, they are usually used
-with a mailing list.
-
-
-
-
-
-
-
-
-Mockapetris [Page 16]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.8. MR RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / NEWNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NEWNAME A <domain-name> which specifies a mailbox which is the
- proper rename of the specified mailbox.
-
-MR records cause no additional section processing. The main use for MR
-is as a forwarding entry for a user who has moved to a different
-mailbox.
-
-3.3.9. MX RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PREFERENCE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EXCHANGE /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PREFERENCE A 16 bit integer which specifies the preference given to
- this RR among others at the same owner. Lower values
- are preferred.
-
-EXCHANGE A <domain-name> which specifies a host willing to act as
- a mail exchange for the owner name.
-
-MX records cause type A additional section processing for the host
-specified by EXCHANGE. The use of MX RRs is explained in detail in
-[RFC-974].
-
-3.3.10. NULL RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / <anything> /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Anything at all may be in the RDATA field so long as it is 65535 octets
-or less.
-
-
-
-
-Mockapetris [Page 17]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-NULL records cause no additional section processing. NULL RRs are not
-allowed in master files. NULLs are used as placeholders in some
-experimental extensions of the DNS.
-
-3.3.11. NS RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / NSDNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NSDNAME A <domain-name> which specifies a host which should be
- authoritative for the specified class and domain.
-
-NS records cause both the usual additional section processing to locate
-a type A record, and, when used in a referral, a special search of the
-zone in which they reside for glue information.
-
-The NS RR states that the named host should be expected to have a zone
-starting at owner name of the specified class. Note that the class may
-not indicate the protocol family which should be used to communicate
-with the host, although it is typically a strong hint. For example,
-hosts which are name servers for either Internet (IN) or Hesiod (HS)
-class information are normally queried using IN class protocols.
-
-3.3.12. PTR RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / PTRDNAME /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PTRDNAME A <domain-name> which points to some location in the
- domain name space.
-
-PTR records cause no additional section processing. These RRs are used
-in special domains to point to some other location in the domain space.
-These records are simple data, and don't imply any special processing
-similar to that performed by CNAME, which identifies aliases. See the
-description of the IN-ADDR.ARPA domain for an example.
-
-
-
-
-
-
-
-
-Mockapetris [Page 18]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.13. SOA RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RNAME /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | SERIAL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | REFRESH |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RETRY |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | EXPIRE |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | MINIMUM |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MNAME The <domain-name> of the name server that was the
- original or primary source of data for this zone.
-
-RNAME A <domain-name> which specifies the mailbox of the
- person responsible for this zone.
-
-SERIAL The unsigned 32 bit version number of the original copy
- of the zone. Zone transfers preserve this value. This
- value wraps and should be compared using sequence space
- arithmetic.
-
-REFRESH A 32 bit time interval before the zone should be
- refreshed.
-
-RETRY A 32 bit time interval that should elapse before a
- failed refresh should be retried.
-
-EXPIRE A 32 bit time value that specifies the upper limit on
- the time interval that can elapse before the zone is no
- longer authoritative.
-
-
-
-
-
-Mockapetris [Page 19]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-MINIMUM The unsigned 32 bit minimum TTL field that should be
- exported with any RR from this zone.
-
-SOA records cause no additional section processing.
-
-All times are in units of seconds.
-
-Most of these fields are pertinent only for name server maintenance
-operations. However, MINIMUM is used in all query operations that
-retrieve RRs from a zone. Whenever a RR is sent in a response to a
-query, the TTL field is set to the maximum of the TTL field from the RR
-and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
-bound on the TTL field for all RRs in a zone. Note that this use of
-MINIMUM should occur when the RRs are copied into the response and not
-when the zone is loaded from a master file or via a zone transfer. The
-reason for this provison is to allow future dynamic update facilities to
-change the SOA RR with known semantics.
-
-
-3.3.14. TXT RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / TXT-DATA /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-TXT-DATA One or more <character-string>s.
-
-TXT RRs are used to hold descriptive text. The semantics of the text
-depends on the domain where it is found.
-
-3.4. Internet specific RRs
-
-3.4.1. A RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADDRESS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS A 32 bit Internet address.
-
-Hosts that have multiple Internet addresses will have multiple A
-records.
-
-
-
-
-
-Mockapetris [Page 20]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-A records cause no additional section processing. The RDATA section of
-an A line in a master file is an Internet address expressed as four
-decimal numbers separated by dots without any imbedded spaces (e.g.,
-"10.2.0.52" or "192.0.5.6").
-
-3.4.2. WKS RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADDRESS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PROTOCOL | |
- +--+--+--+--+--+--+--+--+ |
- | |
- / <BIT MAP> /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS An 32 bit Internet address
-
-PROTOCOL An 8 bit IP protocol number
-
-<BIT MAP> A variable length bit map. The bit map must be a
- multiple of 8 bits long.
-
-The WKS record is used to describe the well known services supported by
-a particular protocol on a particular internet address. The PROTOCOL
-field specifies an IP protocol number, and the bit map has one bit per
-port of the specified protocol. The first bit corresponds to port 0,
-the second to port 1, etc. If the bit map does not include a bit for a
-protocol of interest, that bit is assumed zero. The appropriate values
-and mnemonics for ports and protocols are specified in [RFC-1010].
-
-For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
-25 (SMTP). If this bit is set, a SMTP server should be listening on TCP
-port 25; if zero, SMTP service is not supported on the specified
-address.
-
-The purpose of WKS RRs is to provide availability information for
-servers for TCP and UDP. If a server supports both TCP and UDP, or has
-multiple Internet addresses, then multiple WKS RRs are used.
-
-WKS RRs cause no additional section processing.
-
-In master files, both ports and protocols are expressed using mnemonics
-or decimal numbers.
-
-
-
-
-Mockapetris [Page 21]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.5. IN-ADDR.ARPA domain
-
-The Internet uses a special domain to support gateway location and
-Internet address to host mapping. Other classes may employ a similar
-strategy in other domains. The intent of this domain is to provide a
-guaranteed method to perform host address to host name mapping, and to
-facilitate queries to locate all gateways on a particular network in the
-Internet.
-
-Note that both of these services are similar to functions that could be
-performed by inverse queries; the difference is that this part of the
-domain name space is structured according to address, and hence can
-guarantee that the appropriate data can be located without an exhaustive
-search of the domain space.
-
-The domain begins at IN-ADDR.ARPA and has a substructure which follows
-the Internet addressing structure.
-
-Domain names in the IN-ADDR.ARPA domain are defined to have up to four
-labels in addition to the IN-ADDR.ARPA suffix. Each label represents
-one octet of an Internet address, and is expressed as a character string
-for a decimal value in the range 0-255 (with leading zeros omitted
-except in the case of a zero octet which is represented by a single
-zero).
-
-Host addresses are represented by domain names that have all four labels
-specified. Thus data for Internet address 10.2.0.52 is located at
-domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
-read, allows zones to be delegated which are exactly one network of
-address space. For example, 10.IN-ADDR.ARPA can be a zone containing
-data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
-MILNET. Address nodes are used to hold pointers to primary host names
-in the normal domain space.
-
-Network numbers correspond to some non-terminal nodes at various depths
-in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
-2, or 3 octets. Network nodes are used to hold pointers to the primary
-host names of gateways attached to that network. Since a gateway is, by
-definition, on more than one network, it will typically have two or more
-network nodes which point at it. Gateways will also have host level
-pointers at their fully qualified addresses.
-
-Both the gateway pointers at network nodes and the normal host pointers
-at full address nodes use the PTR RR to point back to the primary domain
-names of the corresponding hosts.
-
-For example, the IN-ADDR.ARPA domain will contain information about the
-ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
-
-
-
-Mockapetris [Page 22]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
-gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
-GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
-and a name GW.LCS.MIT.EDU, the domain database would contain:
-
- 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
- 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
-
-Thus a program which wanted to locate gateways on net 10 would originate
-a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It
-would receive two RRs in response:
-
- 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
-
-The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
-GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
-these gateways.
-
-A resolver which wanted to find the host name corresponding to Internet
-host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
-QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
-
- 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
-
-Several cautions apply to the use of these services:
- - Since the IN-ADDR.ARPA special domain and the normal domain
- for a particular host or gateway will be in different zones,
- the possibility exists that that the data may be inconsistent.
-
- - Gateways will often have two names in separate domains, only
- one of which can be primary.
-
- - Systems that use the domain database to initialize their
- routing tables must start with enough gateway information to
- guarantee that they can access the appropriate name server.
-
- - The gateway data only reflects the existence of a gateway in a
- manner equivalent to the current HOSTS.TXT file. It doesn't
- replace the dynamic availability information from GGP or EGP.
-
-
-
-Mockapetris [Page 23]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.6. Defining new types, classes, and special namespaces
-
-The previously defined types and classes are the ones in use as of the
-date of this memo. New definitions should be expected. This section
-makes some recommendations to designers considering additions to the
-existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
-forum where general discussion of design issues takes place.
-
-In general, a new type is appropriate when new information is to be
-added to the database about an existing object, or we need new data
-formats for some totally new object. Designers should attempt to define
-types and their RDATA formats that are generally applicable to all
-classes, and which avoid duplication of information. New classes are
-appropriate when the DNS is to be used for a new protocol, etc which
-requires new class-specific data formats, or when a copy of the existing
-name space is desired, but a separate management domain is necessary.
-
-New types and classes need mnemonics for master files; the format of the
-master files requires that the mnemonics for type and class be disjoint.
-
-TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
-respectively.
-
-The present system uses multiple RRs to represent multiple values of a
-type rather than storing multiple values in the RDATA section of a
-single RR. This is less efficient for most applications, but does keep
-RRs shorter. The multiple RRs assumption is incorporated in some
-experimental work on dynamic update methods.
-
-The present system attempts to minimize the duplication of data in the
-database in order to insure consistency. Thus, in order to find the
-address of the host for a mail exchange, you map the mail domain name to
-a host name, then the host name to addresses, rather than a direct
-mapping to host address. This approach is preferred because it avoids
-the opportunity for inconsistency.
-
-In defining a new type of data, multiple RR types should not be used to
-create an ordering between entries or express different formats for
-equivalent bindings, instead this information should be carried in the
-body of the RR and a single type used. This policy avoids problems with
-caching multiple types and defining QTYPEs to match multiple types.
-
-For example, the original form of mail exchange binding used two RR
-types one to represent a "closer" exchange (MD) and one to represent a
-"less close" exchange (MF). The difficulty is that the presence of one
-RR type in a cache doesn't convey any information about the other
-because the query which acquired the cached information might have used
-a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
-
-
-
-Mockapetris [Page 24]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-service used a single type (MX) with a "preference" value in the RDATA
-section which can order different RRs. However, if any MX RRs are found
-in the cache, then all should be there.
-
-4. MESSAGES
-
-4.1. Format
-
-All communications inside of the domain protocol are carried in a single
-format called a message. The top level format of message is divided
-into 5 sections (some of which are empty in certain cases) shown below:
-
- +---------------------+
- | Header |
- +---------------------+
- | Question | the question for the name server
- +---------------------+
- | Answer | RRs answering the question
- +---------------------+
- | Authority | RRs pointing toward an authority
- +---------------------+
- | Additional | RRs holding additional information
- +---------------------+
-
-The header section is always present. The header includes fields that
-specify which of the remaining sections are present, and also specify
-whether the message is a query or a response, a standard query or some
-other opcode, etc.
-
-The names of the sections after the header are derived from their use in
-standard queries. The question section contains fields that describe a
-question to a name server. These fields are a query type (QTYPE), a
-query class (QCLASS), and a query domain name (QNAME). The last three
-sections have the same format: a possibly empty list of concatenated
-resource records (RRs). The answer section contains RRs that answer the
-question; the authority section contains RRs that point toward an
-authoritative name server; the additional records section contains RRs
-which relate to the query, but are not strictly answers for the
-question.
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 25]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-4.1.1. Header section format
-
-The header contains the following fields:
-
- 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 | 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
- the corresponding reply and can be used by the requester
- to match up replies to outstanding queries.
-
-QR A one bit field that specifies whether this message is a
- query (0), or a response (1).
-
-OPCODE A four bit field that specifies kind of query in this
- message. This value is set by the originator of a query
- and copied into the response. The values are:
-
- 0 a standard query (QUERY)
-
- 1 an inverse query (IQUERY)
-
- 2 a server status request (STATUS)
-
- 3-15 reserved for future use
-
-AA Authoritative Answer - this bit is valid in responses,
- and specifies that the responding name server is an
- authority for the domain name in question section.
-
- Note that the contents of the answer section may have
- multiple owner names because of aliases. The AA bit
-
-
-
-Mockapetris [Page 26]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- corresponds to the name which matches the query name, or
- the first owner name in the answer section.
-
-TC TrunCation - specifies that this message was truncated
- due to length greater than that permitted on the
- transmission channel.
-
-RD Recursion Desired - this bit may be set in a query and
- is copied into the response. If RD is set, it directs
- the name server to pursue the query recursively.
- Recursive query support is optional.
-
-RA Recursion Available - this be is set or cleared in a
- response, and denotes whether recursive query support is
- available in the name server.
-
-Z Reserved for future use. Must be zero in all queries
- and responses.
-
-RCODE Response code - this 4 bit field is set as part of
- responses. The values have the following
- interpretation:
-
- 0 No error condition
-
- 1 Format error - The name server was
- unable to interpret the query.
-
- 2 Server failure - The name server was
- unable to process this query due to a
- problem with the name server.
-
- 3 Name Error - Meaningful only for
- responses from an authoritative name
- server, this code signifies that the
- domain name referenced in the query does
- not exist.
-
- 4 Not Implemented - The name server does
- not support the requested kind of query.
-
- 5 Refused - The name server refuses to
- perform the specified operation for
- policy reasons. For example, a name
- server may not wish to provide the
- information to the particular requester,
- or a name server may not wish to perform
- a particular operation (e.g., zone
-
-
-
-Mockapetris [Page 27]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- transfer) for particular data.
-
- 6-15 Reserved for future use.
-
-QDCOUNT an unsigned 16 bit integer specifying the number of
- entries in the question section.
-
-ANCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the answer section.
-
-NSCOUNT an unsigned 16 bit integer specifying the number of name
- server resource records in the authority records
- section.
-
-ARCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the additional records section.
-
-4.1.2. Question section format
-
-The question section is used to carry the "question" in most queries,
-i.e., the parameters that define what is being asked. The section
-contains QDCOUNT (usually 1) entries, each of the following format:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / QNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QTYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QCLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-QNAME a domain name represented as a sequence of labels, where
- each label consists of a length octet followed by that
- number of octets. The domain name terminates with the
- zero length octet for the null label of the root. Note
- that this field may be an odd number of octets; no
- padding is used.
-
-QTYPE a two octet code which specifies the type of the query.
- The values for this field include all codes valid for a
- TYPE field, together with some more general codes which
- can match more than one type of RR.
-
-
-
-Mockapetris [Page 28]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-QCLASS a two octet code that specifies the class of the query.
- For example, the QCLASS field is IN for the Internet.
-
-4.1.3. Resource record format
-
-The answer, authority, and additional sections all share the same
-format: a variable number of resource records, where the number of
-records is specified in the corresponding count field in the header.
-Each resource record has the following format:
- 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 /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NAME a domain name to which this resource record pertains.
-
-TYPE two octets containing one of the RR type codes. This
- field specifies the meaning of the data in the RDATA
- field.
-
-CLASS two octets which specify the class of the data in the
- RDATA field.
-
-TTL a 32 bit unsigned integer that specifies the time
- interval (in seconds) that the resource record may be
- cached before it should be discarded. Zero values are
- interpreted to mean that the RR can only be used for the
- transaction in progress, and should not be cached.
-
-
-
-
-
-Mockapetris [Page 29]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-RDLENGTH an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
-RDATA a variable length string of octets that describes the
- resource. The format of this information varies
- according to the TYPE and CLASS of the resource record.
- For example, the if the TYPE is A and the CLASS is IN,
- the RDATA field is a 4 octet ARPA Internet address.
-
-4.1.4. Message compression
-
-In order to reduce the size of messages, the domain system utilizes a
-compression scheme which eliminates the repetition of domain names in a
-message. In this scheme, an entire domain name or a list of labels at
-the end of a domain name is replaced with a pointer to a prior occurance
-of the same name.
-
-The pointer takes the form of a two octet sequence:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | 1 1| OFFSET |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The first two bits are ones. This allows a pointer to be distinguished
-from a label, since the label must begin with two zero bits because
-labels are restricted to 63 octets or less. (The 10 and 01 combinations
-are reserved for future use.) The OFFSET field specifies an offset from
-the start of the message (i.e., the first octet of the ID field in the
-domain header). A zero offset specifies the first byte of the ID field,
-etc.
-
-The compression scheme allows a domain name in a message to be
-represented as either:
-
- - a sequence of labels ending in a zero octet
-
- - a pointer
-
- - a sequence of labels ending with a pointer
-
-Pointers can only be used for occurances of a domain name where the
-format is not class specific. If this were not the case, a name server
-or resolver would be required to know the format of all RRs it handled.
-As yet, there are no such cases, but they may occur in future RDATA
-formats.
-
-If a domain name is contained in a part of the message subject to a
-length field (such as the RDATA section of an RR), and compression is
-
-
-
-Mockapetris [Page 30]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-used, the length of the compressed name is used in the length
-calculation, rather than the length of the expanded name.
-
-Programs are free to avoid using pointers in messages they generate,
-although this will reduce datagram capacity, and may cause truncation.
-However all programs are required to understand arriving messages that
-contain pointers.
-
-For example, a datagram might need to use the domain names F.ISI.ARPA,
-FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
-message, these domain names might be represented as:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 20 | 1 | F |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 22 | 3 | I |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 24 | S | I |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 26 | 4 | A |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 28 | R | P |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 30 | A | 0 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 40 | 3 | F |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 42 | O | O |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 44 | 1 1| 20 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 64 | 1 1| 26 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 92 | 0 | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The domain name for F.ISI.ARPA is shown at offset 20. The domain name
-FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
-concatenate a label for FOO to the previously defined F.ISI.ARPA. The
-domain name ARPA is defined at offset 64 using a pointer to the ARPA
-component of the name F.ISI.ARPA at 20; note that this pointer relies on
-ARPA being the last label in the string at 20. The root domain name is
-
-
-
-Mockapetris [Page 31]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-defined by a single octet of zeros at 92; the root domain name has no
-labels.
-
-4.2. Transport
-
-The DNS assumes that messages will be transmitted as datagrams or in a
-byte stream carried by a virtual circuit. While virtual circuits can be
-used for any DNS activity, datagrams are preferred for queries due to
-their lower overhead and better performance. Zone refresh activities
-must use virtual circuits because of the need for reliable transfer.
-
-The Internet supports name server access using TCP [RFC-793] on server
-port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
-port 53 (decimal).
-
-4.2.1. UDP usage
-
-Messages sent using UDP user server port 53 (decimal).
-
-Messages carried by UDP are restricted to 512 bytes (not counting the IP
-or UDP headers). Longer messages are truncated and the TC bit is set in
-the header.
-
-UDP is not acceptable for zone transfers, but is the recommended method
-for standard queries in the Internet. Queries sent using UDP may be
-lost, and hence a retransmission strategy is required. Queries or their
-responses may be reordered by the network, or by processing in name
-servers, so resolvers should not depend on them being returned in order.
-
-The optimal UDP retransmission policy will vary with performance of the
-Internet and the needs of the client, but the following are recommended:
-
- - The client should try other servers and server addresses
- before repeating a query to a specific address of a server.
-
- - The retransmission interval should be based on prior
- statistics if possible. Too aggressive retransmission can
- easily slow responses for the community at large. Depending
- on how well connected the client is to its expected servers,
- the minimum retransmission interval should be 2-5 seconds.
-
-More suggestions on server selection and retransmission policy can be
-found in the resolver section of this memo.
-
-4.2.2. TCP usage
-
-Messages sent over TCP connections use server port 53 (decimal). The
-message is prefixed with a two byte length field which gives the message
-
-
-
-Mockapetris [Page 32]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-length, excluding the two byte length field. This length field allows
-the low-level processing to assemble a complete message before beginning
-to parse it.
-
-Several connection management policies are recommended:
-
- - The server should not block other activities waiting for TCP
- data.
-
- - The server should support multiple connections.
-
- - The server should assume that the client will initiate
- connection closing, and should delay closing its end of the
- connection until all outstanding client requests have been
- satisfied.
-
- - If the server needs to close a dormant connection to reclaim
- resources, it should wait until the connection has been idle
- for a period on the order of two minutes. In particular, the
- server should allow the SOA and AXFR request sequence (which
- begins a refresh operation) to be made on a single connection.
- Since the server would be unable to answer queries anyway, a
- unilateral close or reset may be used instead of a graceful
- close.
-
-5. MASTER FILES
-
-Master files are text files that contain RRs in text form. Since the
-contents of a zone can be expressed in the form of a list of RRs a
-master file is most often used to define a zone, though it can be used
-to list a cache's contents. Hence, this section first discusses the
-format of RRs in a master file, and then the special considerations when
-a master file is used to create a zone in some name server.
-
-5.1. Format
-
-The format of these files is a sequence of entries. Entries are
-predominantly line-oriented, though parentheses can be used to continue
-a list of items across a line boundary, and text literals can contain
-CRLF within the text. Any combination of tabs and spaces act as a
-delimiter between the separate items that make up an entry. The end of
-any line in the master file can end with a comment. The comment starts
-with a ";" (semicolon).
-
-The following entries are defined:
-
- <blank>[<comment>]
-
-
-
-
-Mockapetris [Page 33]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- $ORIGIN <domain-name> [<comment>]
-
- $INCLUDE <file-name> [<domain-name>] [<comment>]
-
- <domain-name><rr> [<comment>]
-
- <blank><rr> [<comment>]
-
-Blank lines, with or without comments, are allowed anywhere in the file.
-
-Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
-followed by a domain name, and resets the current origin for relative
-domain names to the stated name. $INCLUDE inserts the named file into
-the current file, and may optionally specify a domain name that sets the
-relative domain name origin for the included file. $INCLUDE may also
-have a comment. Note that a $INCLUDE entry never changes the relative
-origin of the parent file, regardless of changes to the relative origin
-made within the included file.
-
-The last two forms represent RRs. If an entry for an RR begins with a
-blank, then the RR is assumed to be owned by the last stated owner. If
-an RR entry begins with a <domain-name>, then the owner name is reset.
-
-<rr> contents take one of the following forms:
-
- [<TTL>] [<class>] <type> <RDATA>
-
- [<class>] [<TTL>] <type> <RDATA>
-
-The RR begins with optional TTL and class fields, followed by a type and
-RDATA field appropriate to the type and class. Class and type use the
-standard mnemonics, TTL is a decimal integer. Omitted class and TTL
-values are default to the last explicitly stated values. Since type and
-class mnemonics are disjoint, the parse is unique. (Note that this
-order is different from the order used in examples and the order used in
-the actual RRs; the given order allows easier parsing and defaulting.)
-
-<domain-name>s make up a large share of the data in the master file.
-The labels in the domain name are expressed as character strings and
-separated by dots. Quoting conventions allow arbitrary characters to be
-stored in domain names. Domain names that end in a dot are called
-absolute, and are taken as complete. Domain names which do not end in a
-dot are called relative; the actual domain name is the concatenation of
-the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
-an argument to the master file loading routine. A relative name is an
-error when no origin is available.
-
-
-
-
-
-Mockapetris [Page 34]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-<character-string> is expressed in one or two ways: as a contiguous set
-of characters without interior spaces, or as a string beginning with a "
-and ending with a ". Inside a " delimited string any character can
-occur, except for a " itself, which must be quoted using \ (back slash).
-
-Because these files are text files several special encodings are
-necessary to allow arbitrary data to be loaded. In particular:
-
- of the root.
-
-@ A free standing @ is used to denote the current origin.
-
-\X where X is any character other than a digit (0-9), is
- used to quote that character so that its special meaning
- does not apply. For example, "\." can be used to place
- a dot character in a label.
-
-\DDD where each D is a digit is the octet corresponding to
- the decimal number described by DDD. The resulting
- octet is assumed to be text and is not checked for
- special meaning.
-
-( ) Parentheses are used to group data that crosses a line
- boundary. In effect, line terminations are not
- recognized within parentheses.
-
-; Semicolon is used to start a comment; the remainder of
- the line is ignored.
-
-5.2. Use of master files to define zones
-
-When a master file is used to load a zone, the operation should be
-suppressed if any errors are encountered in the master file. The
-rationale for this is that a single error can have widespread
-consequences. For example, suppose that the RRs defining a delegation
-have syntax errors; then the server will return authoritative name
-errors for all names in the subzone (except in the case where the
-subzone is also present on the server).
-
-Several other validity checks that should be performed in addition to
-insuring that the file is syntactically correct:
-
- 1. All RRs in the file should have the same class.
-
- 2. Exactly one SOA RR should be present at the top of the zone.
-
- 3. If delegations are present and glue information is required,
- it should be present.
-
-
-
-Mockapetris [Page 35]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 4. Information present outside of the authoritative nodes in the
- zone should be glue information, rather than the result of an
- origin or similar error.
-
-5.3. Master file example
-
-The following is an example file which might be used to define the
-ISI.EDU zone.and is loaded with an origin of ISI.EDU:
-
-@ IN SOA VENERA Action\.domains (
- 20 ; SERIAL
- 7200 ; REFRESH
- 600 ; RETRY
- 3600000; EXPIRE
- 60) ; MINIMUM
-
- NS A.ISI.EDU.
- NS VENERA
- NS VAXA
- MX 10 VENERA
- MX 20 VAXA
-
-A A 26.3.0.103
-
-VENERA A 10.1.0.52
- A 128.9.0.32
-
-VAXA A 10.2.0.27
- A 128.9.0.33
-
-
-$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
-
-Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
-
- MOE MB A.ISI.EDU.
- LARRY MB A.ISI.EDU.
- CURLEY MB A.ISI.EDU.
- STOOGES MG MOE
- MG LARRY
- MG CURLEY
-
-Note the use of the \ character in the SOA RR to specify the responsible
-person mailbox "Action.domains@E.ISI.EDU".
-
-
-
-
-
-
-
-Mockapetris [Page 36]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-6. NAME SERVER IMPLEMENTATION
-
-6.1. Architecture
-
-The optimal structure for the name server will depend on the host
-operating system and whether the name server is integrated with resolver
-operations, either by supporting recursive service, or by sharing its
-database with a resolver. This section discusses implementation
-considerations for a name server which shares a database with a
-resolver, but most of these concerns are present in any name server.
-
-6.1.1. Control
-
-A name server must employ multiple concurrent activities, whether they
-are implemented as separate tasks in the host's OS or multiplexing
-inside a single name server program. It is simply not acceptable for a
-name server to block the service of UDP requests while it waits for TCP
-data for refreshing or query activities. Similarly, a name server
-should not attempt to provide recursive service without processing such
-requests in parallel, though it may choose to serialize requests from a
-single client, or to regard identical requests from the same client as
-duplicates. A name server should not substantially delay requests while
-it reloads a zone from master files or while it incorporates a newly
-refreshed zone into its database.
-
-6.1.2. Database
-
-While name server implementations are free to use any internal data
-structures they choose, the suggested structure consists of three major
-parts:
-
- - A "catalog" data structure which lists the zones available to
- this server, and a "pointer" to the zone data structure. The
- main purpose of this structure is to find the nearest ancestor
- zone, if any, for arriving standard queries.
-
- - Separate data structures for each of the zones held by the
- name server.
-
- - A data structure for cached data. (or perhaps separate caches
- for different classes)
-
-All of these data structures can be implemented an identical tree
-structure format, with different data chained off the nodes in different
-parts: in the catalog the data is pointers to zones, while in the zone
-and cache data structures, the data will be RRs. In designing the tree
-framework the designer should recognize that query processing will need
-to traverse the tree using case-insensitive label comparisons; and that
-
-
-
-Mockapetris [Page 37]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-in real data, a few nodes have a very high branching factor (100-1000 or
-more), but the vast majority have a very low branching factor (0-1).
-
-One way to solve the case problem is to store the labels for each node
-in two pieces: a standardized-case representation of the label where all
-ASCII characters are in a single case, together with a bit mask that
-denotes which characters are actually of a different case. The
-branching factor diversity can be handled using a simple linked list for
-a node until the branching factor exceeds some threshold, and
-transitioning to a hash structure after the threshold is exceeded. In
-any case, hash structures used to store tree sections must insure that
-hash functions and procedures preserve the casing conventions of the
-DNS.
-
-The use of separate structures for the different parts of the database
-is motivated by several factors:
-
- - The catalog structure can be an almost static structure that
- need change only when the system administrator changes the
- zones supported by the server. This structure can also be
- used to store parameters used to control refreshing
- activities.
-
- - The individual data structures for zones allow a zone to be
- replaced simply by changing a pointer in the catalog. Zone
- refresh operations can build a new structure and, when
- complete, splice it into the database via a simple pointer
- replacement. It is very important that when a zone is
- refreshed, queries should not use old and new data
- simultaneously.
-
- - With the proper search procedures, authoritative data in zones
- will always "hide", and hence take precedence over, cached
- data.
-
- - Errors in zone definitions that cause overlapping zones, etc.,
- may cause erroneous responses to queries, but problem
- determination is simplified, and the contents of one "bad"
- zone can't corrupt another.
-
- - Since the cache is most frequently updated, it is most
- vulnerable to corruption during system restarts. It can also
- become full of expired RR data. In either case, it can easily
- be discarded without disturbing zone data.
-
-A major aspect of database design is selecting a structure which allows
-the name server to deal with crashes of the name server's host. State
-information which a name server should save across system crashes
-
-
-
-Mockapetris [Page 38]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-includes the catalog structure (including the state of refreshing for
-each zone) and the zone data itself.
-
-6.1.3. Time
-
-Both the TTL data for RRs and the timing data for refreshing activities
-depends on 32 bit timers in units of seconds. Inside the database,
-refresh timers and TTLs for cached data conceptually "count down", while
-data in the zone stays with constant TTLs.
-
-A recommended implementation strategy is to store time in two ways: as
-a relative increment and as an absolute time. One way to do this is to
-use positive 32 bit numbers for one type and negative numbers for the
-other. The RRs in zones use relative times; the refresh timers and
-cache data use absolute times. Absolute numbers are taken with respect
-to some known origin and converted to relative values when placed in the
-response to a query. When an absolute TTL is negative after conversion
-to relative, then the data is expired and should be ignored.
-
-6.2. Standard query processing
-
-The major algorithm for standard query processing is presented in
-[RFC-1034].
-
-When processing queries with QCLASS=*, or some other QCLASS which
-matches multiple classes, the response should never be authoritative
-unless the server can guarantee that the response covers all classes.
-
-When composing a response, RRs which are to be inserted in the
-additional section, but duplicate RRs in the answer or authority
-sections, may be omitted from the additional section.
-
-When a response is so long that truncation is required, the truncation
-should start at the end of the response and work forward in the
-datagram. Thus if there is any data for the authority section, the
-answer section is guaranteed to be unique.
-
-The MINIMUM value in the SOA should be used to set a floor on the TTL of
-data distributed from a zone. This floor function should be done when
-the data is copied into a response. This will allow future dynamic
-update protocols to change the SOA MINIMUM field without ambiguous
-semantics.
-
-6.3. Zone refresh and reload processing
-
-In spite of a server's best efforts, it may be unable to load zone data
-from a master file due to syntax errors, etc., or be unable to refresh a
-zone within the its expiration parameter. In this case, the name server
-
-
-
-Mockapetris [Page 39]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-should answer queries as if it were not supposed to possess the zone.
-
-If a master is sending a zone out via AXFR, and a new version is created
-during the transfer, the master should continue to send the old version
-if possible. In any case, it should never send part of one version and
-part of another. If completion is not possible, the master should reset
-the connection on which the zone transfer is taking place.
-
-6.4. Inverse queries (Optional)
-
-Inverse queries are an optional part of the DNS. Name servers are not
-required to support any form of inverse queries. If a name server
-receives an inverse query that it does not support, it returns an error
-response with the "Not Implemented" error set in the header. While
-inverse query support is optional, all name servers must be at least
-able to return the error response.
-
-6.4.1. The contents of inverse queries and responses Inverse
-queries reverse the mappings performed by standard query operations;
-while a standard query maps a domain name to a resource, an inverse
-query maps a resource to a domain name. For example, a standard query
-might bind a domain name to a host address; the corresponding inverse
-query binds the host address to a domain name.
-
-Inverse queries take the form of a single RR in the answer section of
-the message, with an empty question section. The owner name of the
-query RR and its TTL are not significant. The response carries
-questions in the question section which identify all names possessing
-the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
-about all of the domain name space, the response can never be assumed to
-be complete. Thus inverse queries are primarily useful for database
-management and debugging activities. Inverse queries are NOT an
-acceptable method of mapping host addresses to host names; use the IN-
-ADDR.ARPA domain instead.
-
-Where possible, name servers should provide case-insensitive comparisons
-for inverse queries. Thus an inverse query asking for an MX RR of
-"Venera.isi.edu" should get the same response as a query for
-"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
-produce the same result as an inverse query for "IBM-pc unix". However,
-this cannot be guaranteed because name servers may possess RRs that
-contain character strings but the name server does not know that the
-data is character.
-
-When a name server processes an inverse query, it either returns:
-
- 1. zero, one, or multiple domain names for the specified
- resource as QNAMEs in the question section
-
-
-
-Mockapetris [Page 40]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 2. an error code indicating that the name server doesn't support
- inverse mapping of the specified resource type.
-
-When the response to an inverse query contains one or more QNAMEs, the
-owner name and TTL of the RR in the answer section which defines the
-inverse query is modified to exactly match an RR found at the first
-QNAME.
-
-RRs returned in the inverse queries cannot be cached using the same
-mechanism as is used for the replies to standard queries. One reason
-for this is that a name might have multiple RRs of the same type, and
-only one would appear. For example, an inverse query for a single
-address of a multiply homed host might create the impression that only
-one address existed.
-
-6.4.2. Inverse query and response example The overall structure
-of an inverse query for retrieving the domain name that corresponds to
-Internet address 10.1.0.52 is shown below:
-
- +-----------------------------------------+
- Header | OPCODE=IQUERY, ID=997 |
- +-----------------------------------------+
- Question | <empty> |
- +-----------------------------------------+
- Answer | <anyname> A IN 10.1.0.52 |
- +-----------------------------------------+
- Authority | <empty> |
- +-----------------------------------------+
- Additional | <empty> |
- +-----------------------------------------+
-
-This query asks for a question whose answer is the Internet style
-address 10.1.0.52. Since the owner name is not known, any domain name
-can be used as a placeholder (and is ignored). A single octet of zero,
-signifying the root, is usually used because it minimizes the length of
-the message. The TTL of the RR is not significant. The response to
-this query might be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 41]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- +-----------------------------------------+
- Header | OPCODE=RESPONSE, ID=997 |
- +-----------------------------------------+
- Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
- +-----------------------------------------+
- Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
- +-----------------------------------------+
- Authority | <empty> |
- +-----------------------------------------+
- Additional | <empty> |
- +-----------------------------------------+
-
-Note that the QTYPE in a response to an inverse query is the same as the
-TYPE field in the answer section of the inverse query. Responses to
-inverse queries may contain multiple questions when the inverse is not
-unique. If the question section in the response is not empty, then the
-RR in the answer section is modified to correspond to be an exact copy
-of an RR at the first QNAME.
-
-6.4.3. Inverse query processing
-
-Name servers that support inverse queries can support these operations
-through exhaustive searches of their databases, but this becomes
-impractical as the size of the database increases. An alternative
-approach is to invert the database according to the search key.
-
-For name servers that support multiple zones and a large amount of data,
-the recommended approach is separate inversions for each zone. When a
-particular zone is changed during a refresh, only its inversions need to
-be redone.
-
-Support for transfer of this type of inversion may be included in future
-versions of the domain system, but is not supported in this version.
-
-6.5. Completion queries and responses
-
-The optional completion services described in RFC-882 and RFC-883 have
-been deleted. Redesigned services may become available in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 42]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-7. RESOLVER IMPLEMENTATION
-
-The top levels of the recommended resolver algorithm are discussed in
-[RFC-1034]. This section discusses implementation details assuming the
-database structure suggested in the name server implementation section
-of this memo.
-
-7.1. Transforming a user request into a query
-
-The first step a resolver takes is to transform the client's request,
-stated in a format suitable to the local OS, into a search specification
-for RRs at a specific name which match a specific QTYPE and QCLASS.
-Where possible, the QTYPE and QCLASS should correspond to a single type
-and a single class, because this makes the use of cached data much
-simpler. The reason for this is that the presence of data of one type
-in a cache doesn't confirm the existence or non-existence of data of
-other types, hence the only way to be sure is to consult an
-authoritative source. If QCLASS=* is used, then authoritative answers
-won't be available.
-
-Since a resolver must be able to multiplex multiple requests if it is to
-perform its function efficiently, each pending request is usually
-represented in some block of state information. This state block will
-typically contain:
-
- - A timestamp indicating the time the request began.
- The timestamp is used to decide whether RRs in the database
- can be used or are out of date. This timestamp uses the
- absolute time format previously discussed for RR storage in
- zones and caches. Note that when an RRs TTL indicates a
- relative time, the RR must be timely, since it is part of a
- zone. When the RR has an absolute time, it is part of a
- cache, and the TTL of the RR is compared against the timestamp
- for the start of the request.
-
- Note that using the timestamp is superior to using a current
- time, since it allows RRs with TTLs of zero to be entered in
- the cache in the usual manner, but still used by the current
- request, even after intervals of many seconds due to system
- load, query retransmission timeouts, etc.
-
- - Some sort of parameters to limit the amount of work which will
- be performed for this request.
-
- The amount of work which a resolver will do in response to a
- client request must be limited to guard against errors in the
- database, such as circular CNAME references, and operational
- problems, such as network partition which prevents the
-
-
-
-Mockapetris [Page 43]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- resolver from accessing the name servers it needs. While
- local limits on the number of times a resolver will retransmit
- a particular query to a particular name server address are
- essential, the resolver should have a global per-request
- counter to limit work on a single request. The counter should
- be set to some initial value and decremented whenever the
- resolver performs any action (retransmission timeout,
- retransmission, etc.) If the counter passes zero, the request
- is terminated with a temporary error.
-
- Note that if the resolver structure allows one request to
- start others in parallel, such as when the need to access a
- name server for one request causes a parallel resolve for the
- name server's addresses, the spawned request should be started
- with a lower counter. This prevents circular references in
- the database from starting a chain reaction of resolver
- activity.
-
- - The SLIST data structure discussed in [RFC-1034].
-
- This structure keeps track of the state of a request if it
- must wait for answers from foreign name servers.
-
-7.2. Sending the queries
-
-As described in [RFC-1034], the basic task of the resolver is to
-formulate a query which will answer the client's request and direct that
-query to name servers which can provide the information. The resolver
-will usually only have very strong hints about which servers to ask, in
-the form of NS RRs, and may have to revise the query, in response to
-CNAMEs, or revise the set of name servers the resolver is asking, in
-response to delegation responses which point the resolver to name
-servers closer to the desired information. In addition to the
-information requested by the client, the resolver may have to call upon
-its own services to determine the address of name servers it wishes to
-contact.
-
-In any case, the model used in this memo assumes that the resolver is
-multiplexing attention between multiple requests, some from the client,
-and some internally generated. Each request is represented by some
-state information, and the desired behavior is that the resolver
-transmit queries to name servers in a way that maximizes the probability
-that the request is answered, minimizes the time that the request takes,
-and avoids excessive transmissions. The key algorithm uses the state
-information of the request to select the next name server address to
-query, and also computes a timeout which will cause the next action
-should a response not arrive. The next action will usually be a
-transmission to some other server, but may be a temporary error to the
-
-
-
-Mockapetris [Page 44]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-client.
-
-The resolver always starts with a list of server names to query (SLIST).
-This list will be all NS RRs which correspond to the nearest ancestor
-zone that the resolver knows about. To avoid startup problems, the
-resolver should have a set of default servers which it will ask should
-it have no current NS RRs which are appropriate. The resolver then adds
-to SLIST all of the known addresses for the name servers, and may start
-parallel requests to acquire the addresses of the servers when the
-resolver has the name, but no addresses, for the name servers.
-
-To complete initialization of SLIST, the resolver attaches whatever
-history information it has to the each address in SLIST. This will
-usually consist of some sort of weighted averages for the response time
-of the address, and the batting average of the address (i.e., how often
-the address responded at all to the request). Note that this
-information should be kept on a per address basis, rather than on a per
-name server basis, because the response time and batting average of a
-particular server may vary considerably from address to address. Note
-also that this information is actually specific to a resolver address /
-server address pair, so a resolver with multiple addresses may wish to
-keep separate histories for each of its addresses. Part of this step
-must deal with addresses which have no such history; in this case an
-expected round trip time of 5-10 seconds should be the worst case, with
-lower estimates for the same local network, etc.
-
-Note that whenever a delegation is followed, the resolver algorithm
-reinitializes SLIST.
-
-The information establishes a partial ranking of the available name
-server addresses. Each time an address is chosen and the state should
-be altered to prevent its selection again until all other addresses have
-been tried. The timeout for each transmission should be 50-100% greater
-than the average predicted value to allow for variance in response.
-
-Some fine points:
-
- - The resolver may encounter a situation where no addresses are
- available for any of the name servers named in SLIST, and
- where the servers in the list are precisely those which would
- normally be used to look up their own addresses. This
- situation typically occurs when the glue address RRs have a
- smaller TTL than the NS RRs marking delegation, or when the
- resolver caches the result of a NS search. The resolver
- should detect this condition and restart the search at the
- next ancestor zone, or alternatively at the root.
-
-
-
-
-
-Mockapetris [Page 45]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- - If a resolver gets a server error or other bizarre response
- from a name server, it should remove it from SLIST, and may
- wish to schedule an immediate transmission to the next
- candidate server address.
-
-7.3. Processing responses
-
-The first step in processing arriving response datagrams is to parse the
-response. This procedure should include:
-
- - Check the header for reasonableness. Discard datagrams which
- are queries when responses are expected.
-
- - Parse the sections of the message, and insure that all RRs are
- correctly formatted.
-
- - As an optional step, check the TTLs of arriving data looking
- for RRs with excessively long TTLs. If a RR has an
- excessively long TTL, say greater than 1 week, either discard
- the whole response, or limit all TTLs in the response to 1
- week.
-
-The next step is to match the response to a current resolver request.
-The recommended strategy is to do a preliminary matching using the ID
-field in the domain header, and then to verify that the question section
-corresponds to the information currently desired. This requires that
-the transmission algorithm devote several bits of the domain ID field to
-a request identifier of some sort. This step has several fine points:
-
- - Some name servers send their responses from different
- addresses than the one used to receive the query. That is, a
- resolver cannot rely that a response will come from the same
- address which it sent the corresponding query to. This name
- server bug is typically encountered in UNIX systems.
-
- - If the resolver retransmits a particular request to a name
- server it should be able to use a response from any of the
- transmissions. However, if it is using the response to sample
- the round trip time to access the name server, it must be able
- to determine which transmission matches the response (and keep
- transmission times for each outgoing message), or only
- calculate round trip times based on initial transmissions.
-
- - A name server will occasionally not have a current copy of a
- zone which it should have according to some NS RRs. The
- resolver should simply remove the name server from the current
- SLIST, and continue.
-
-
-
-
-Mockapetris [Page 46]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-7.4. Using the cache
-
-In general, we expect a resolver to cache all data which it receives in
-responses since it may be useful in answering future client requests.
-However, there are several types of data which should not be cached:
-
- - When several RRs of the same type are available for a
- particular owner name, the resolver should either cache them
- all or none at all. When a response is truncated, and a
- resolver doesn't know whether it has a complete set, it should
- not cache a possibly partial set of RRs.
-
- - Cached data should never be used in preference to
- authoritative data, so if caching would cause this to happen
- the data should not be cached.
-
- - The results of an inverse query should not be cached.
-
- - The results of standard queries where the QNAME contains "*"
- labels if the data might be used to construct wildcards. The
- reason is that the cache does not necessarily contain existing
- RRs or zone boundary information which is necessary to
- restrict the application of the wildcard RRs.
-
- - RR data in responses of dubious reliability. When a resolver
- receives unsolicited responses or RR data other than that
- requested, it should discard it without caching it. The basic
- implication is that all sanity checks on a packet should be
- performed before any of it is cached.
-
-In a similar vein, when a resolver has a set of RRs for some name in a
-response, and wants to cache the RRs, it should check its cache for
-already existing RRs. Depending on the circumstances, either the data
-in the response or the cache is preferred, but the two should never be
-combined. If the data in the response is from authoritative data in the
-answer section, it is always preferred.
-
-8. MAIL SUPPORT
-
-The domain system defines a standard for mapping mailboxes into domain
-names, and two methods for using the mailbox information to derive mail
-routing information. The first method is called mail exchange binding
-and the other method is mailbox binding. The mailbox encoding standard
-and mail exchange binding are part of the DNS official protocol, and are
-the recommended method for mail routing in the Internet. Mailbox
-binding is an experimental feature which is still under development and
-subject to change.
-
-
-
-
-Mockapetris [Page 47]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-The mailbox encoding standard assumes a mailbox name of the form
-"<local-part>@<mail-domain>". While the syntax allowed in each of these
-sections varies substantially between the various mail internets, the
-preferred syntax for the ARPA Internet is given in [RFC-822].
-
-The DNS encodes the <local-part> as a single label, and encodes the
-<mail-domain> as a domain name. The single label from the <local-part>
-is prefaced to the domain name from <mail-domain> to form the domain
-name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
-NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
-<local-part> contains dots or other special characters, its
-representation in a master file will require the use of backslash
-quoting to ensure that the domain name is properly encoded. For
-example, the mailbox Action.domains@ISI.EDU would be represented as
-Action\.domains.ISI.EDU.
-
-8.1. Mail exchange binding
-
-Mail exchange binding uses the <mail-domain> part of a mailbox
-specification to determine where mail should be sent. The <local-part>
-is not even consulted. [RFC-974] specifies this method in detail, and
-should be consulted before attempting to use mail exchange support.
-
-One of the advantages of this method is that it decouples mail
-destination naming from the hosts used to support mail service, at the
-cost of another layer of indirection in the lookup function. However,
-the addition layer should eliminate the need for complicated "%", "!",
-etc encodings in <local-part>.
-
-The essence of the method is that the <mail-domain> is used as a domain
-name to locate type MX RRs which list hosts willing to accept mail for
-<mail-domain>, together with preference values which rank the hosts
-according to an order specified by the administrators for <mail-domain>.
-
-In this memo, the <mail-domain> ISI.EDU is used in examples, together
-with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
-ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
-route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
-VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
-addresses.
-
-8.2. Mailbox binding (Experimental)
-
-In mailbox binding, the mailer uses the entire mail destination
-specification to construct a domain name. The encoded domain name for
-the mailbox is used as the QNAME field in a QTYPE=MAILB query.
-
-Several outcomes are possible for this query:
-
-
-
-Mockapetris [Page 48]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 1. The query can return a name error indicating that the mailbox
- does not exist as a domain name.
-
- In the long term, this would indicate that the specified
- mailbox doesn't exist. However, until the use of mailbox
- binding is universal, this error condition should be
- interpreted to mean that the organization identified by the
- global part does not support mailbox binding. The
- appropriate procedure is to revert to exchange binding at
- this point.
-
- 2. The query can return a Mail Rename (MR) RR.
-
- The MR RR carries new mailbox specification in its RDATA
- field. The mailer should replace the old mailbox with the
- new one and retry the operation.
-
- 3. The query can return a MB RR.
-
- The MB RR carries a domain name for a host in its RDATA
- field. The mailer should deliver the message to that host
- via whatever protocol is applicable, e.g., b,SMTP.
-
- 4. The query can return one or more Mail Group (MG) RRs.
-
- This condition means that the mailbox was actually a mailing
- list or mail group, rather than a single mailbox. Each MG RR
- has a RDATA field that identifies a mailbox that is a member
- of the group. The mailer should deliver a copy of the
- message to each member.
-
- 5. The query can return a MB RR as well as one or more MG RRs.
-
- This condition means the the mailbox was actually a mailing
- list. The mailer can either deliver the message to the host
- specified by the MB RR, which will in turn do the delivery to
- all members, or the mailer can use the MG RRs to do the
- expansion itself.
-
-In any of these cases, the response may include a Mail Information
-(MINFO) RR. This RR is usually associated with a mail group, but is
-legal with a MB. The MINFO RR identifies two mailboxes. One of these
-identifies a responsible person for the original mailbox name. This
-mailbox should be used for requests to be added to a mail group, etc.
-The second mailbox name in the MINFO RR identifies a mailbox that should
-receive error messages for mail failures. This is particularly
-appropriate for mailing lists when errors in member names should be
-reported to a person other than the one who sends a message to the list.
-
-
-
-Mockapetris [Page 49]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-New fields may be added to this RR in the future.
-
-
-9. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
- Technical Plan - Name Service, April 1987, version 1.9.
-
- Describes the fundamentals of the Hesiod name service.
-
-[IEN-116] J. Postel, "Internet Name Server", IEN-116,
- USC/Information Sciences Institute, August 1979.
-
- A name service obsoleted by the Domain Name System, but
- still in use.
-
-[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
- Communications of the ACM, October 1986, volume 29, number
- 10.
-
-[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
- Information Center, SRI International, December 1977.
-
-[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
- USC/Information Sciences Institute, September 1981.
-
-[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
- September 1981.
-
- Suggests introduction of a hierarchy in place of a flat
- name space for the Internet.
-
-[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
- USC/Information Sciences Institute, February 1982.
-
-[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
- Internet Host Table Specification", RFC-810, Network
- Information Center, SRI International, March 1982.
-
- Obsolete. See RFC-952.
-
-[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
- Server", RFC-811, Network Information Center, SRI
- International, March 1982.
-
-
-
-
-Mockapetris [Page 50]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- Obsolete. See RFC-953.
-
-[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
- Network Information Center, SRI International, March
- 1982.
-
-[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
- Internet User Applications", RFC-819, Network
- Information Center, SRI International, August 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
- RFC-830, Network Information Center, SRI International,
- October 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-882] P. Mockapetris, "Domain names - Concepts and
- Facilities," RFC-882, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-883] P. Mockapetris, "Domain names - Implementation and
- Specification," RFC-883, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
- RFC-920, USC/Information Sciences Institute,
- October 1984.
-
- Explains the naming scheme for top level domains.
-
-[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
- Table Specification", RFC-952, SRI, October 1985.
-
- Specifies the format of HOSTS.TXT, the host/address
- table replaced by the DNS.
-
-
-
-
-
-Mockapetris [Page 51]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
- RFC-953, SRI, October 1985.
-
- This RFC contains the official specification of the
- hostname server protocol, which is obsoleted by the DNS.
- This TCP based protocol accesses information stored in
- the RFC-952 format, and is used to obtain copies of the
- host table.
-
-[RFC-973] P. Mockapetris, "Domain System Changes and
- Observations", RFC-973, USC/Information Sciences
- Institute, January 1986.
-
- Describes changes to RFC-882 and RFC-883 and reasons for
- them.
-
-[RFC-974] C. Partridge, "Mail routing and the domain system",
- RFC-974, CSNET CIC BBN Labs, January 1986.
-
- Describes the transition from HOSTS.TXT based mail
- addressing to the more powerful MX system used with the
- domain system.
-
-[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Concepts and Methods",
- RFC-1001, March 1987.
-
- This RFC and RFC-1002 are a preliminary design for
- NETBIOS on top of TCP/IP which proposes to base NetBIOS
- name service on top of the DNS.
-
-[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Detailed
- Specifications", RFC-1002, March 1987.
-
-[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
- USC/Information Sciences Institute, May 1987.
-
- Contains socket numbers and mnemonics for host names,
- operating systems, etc.
-
-[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
- November 1987.
-
- Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
- Administrators", RFC-1032, November 1987.
-
-
-
-Mockapetris [Page 52]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- Describes the registration policies used by the NIC to
- administer the top level domains and delegate subzones.
-
-[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
- RFC-1033, November 1987.
-
- A cookbook for domain administrators.
-
-[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
- Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
- Describes a name service for CSNET which is independent
- from the DNS and DNS use in the CSNET.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 53]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Index
-
- * 13
-
- ; 33, 35
-
- <character-string> 35
- <domain-name> 34
-
- @ 35
-
- \ 35
-
- A 12
-
- Byte order 8
-
- CH 13
- Character case 9
- CLASS 11
- CNAME 12
- Completion 42
- CS 13
-
- Hesiod 13
- HINFO 12
- HS 13
-
- IN 13
- IN-ADDR.ARPA domain 22
- Inverse queries 40
-
- Mailbox names 47
- MB 12
- MD 12
- MF 12
- MG 12
- MINFO 12
- MINIMUM 20
- MR 12
- MX 12
-
- NS 12
- NULL 12
-
- Port numbers 32
- Primary server 5
- PTR 12, 18
-
-
-
-Mockapetris [Page 54]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- QCLASS 13
- QTYPE 12
-
- RDATA 12
- RDLENGTH 11
-
- Secondary server 5
- SOA 12
- Stub resolvers 7
-
- TCP 32
- TXT 12
- TYPE 11
-
- UDP 32
-
- WKS 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 55]
-
diff --git a/contrib/bind9/doc/rfc/rfc1101.txt b/contrib/bind9/doc/rfc/rfc1101.txt
deleted file mode 100644
index 66c9d8b813b35..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1101.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Mockapetris
-Request for Comments: 1101 ISI
-Updates: RFCs 1034, 1035 April 1989
-
-
- DNS Encoding of Network Names and Other Types
-
-
-1. STATUS OF THIS MEMO
-
- This RFC proposes two extensions to the Domain Name System:
-
- - A specific method for entering and retrieving RRs which map
- between network names and numbers.
-
- - Ideas for a general method for describing mappings between
- arbitrary identifiers and numbers.
-
- The method for mapping between network names and addresses is a
- proposed standard, the ideas for a general method are experimental.
-
- This RFC assumes that the reader is familiar with the DNS [RFC 1034,
- RFC 1035] and its use. The data shown is for pedagogical use and
- does not necessarily reflect the real Internet.
-
- Distribution of this memo is unlimited.
-
-2. INTRODUCTION
-
- The DNS is extensible and can be used for a virtually unlimited
- number of data types, name spaces, etc. New type definitions are
- occasionally necessary as are revisions or deletions of old types
- (e.g., MX replacement of MD and MF [RFC 974]), and changes described
- in [RFC 973]. This RFC describes changes due to the general need to
- map between identifiers and values, and a specific need for network
- name support.
-
- Users wish to be able to use the DNS to map between network names and
- numbers. This need is the only capability found in HOSTS.TXT which
- is not available from the DNS. In designing a method to do this,
- there were two major areas of concern:
-
- - Several tradeoffs involving control of network names, the
- syntax of network names, backward compatibility, etc.
-
- - A desire to create a method which would be sufficiently
- general to set a good precedent for future mappings,
- for example, between TCP-port names and numbers,
-
-
-
-Mockapetris [Page 1]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- autonomous system names and numbers, X.500 Relative
- Distinguished Names (RDNs) and their servers, or whatever.
-
- It was impossible to reconcile these two areas of concern for network
- names because of the desire to unify network number support within
- existing IP address to host name support. The existing support is
- the IN-ADDR.ARPA section of the DNS name space. As a result this RFC
- describes one structure for network names which builds on the
- existing support for host names, and another family of structures for
- future yellow pages (YP) functions such as conversions between TCP-
- port numbers and mnemonics.
-
- Both structures are described in following sections. Each structure
- has a discussion of design issues and specific structure
- recommendations.
-
- We wish to avoid defining structures and methods which can work but
- do not because of indifference or errors on the part of system
- administrators when maintaining the database. The WKS RR is an
- example. Thus, while we favor distribution as a general method, we
- also recognize that centrally maintained tables (such as HOSTS.TXT)
- are usually more consistent though less maintainable and timely.
- Hence we recommend both specific methods for mapping network names,
- addresses, and subnets, as well as an instance of the general method
- for mapping between allocated network numbers and network names.
- (Allocation is centrally performed by the SRI Network Information
- Center, aka the NIC).
-
-3. NETWORK NAME ISSUES AND DISCUSSION
-
- The issues involved in the design were the definition of network name
- syntax, the mappings to be provided, and possible support for similar
- functions at the subnet level.
-
-3.1. Network name syntax
-
- The current syntax for network names, as defined by [RFC 952] is an
- alphanumeric string of up to 24 characters, which begins with an
- alpha, and may include "." and "-" except as first and last
- characters. This is the format which was also used for host names
- before the DNS. Upward compatibility with existing names might be a
- goal of any new scheme.
-
- However, the present syntax has been used to define a flat name
- space, and hence would prohibit the same distributed name allocation
- method used for host names. There is some sentiment for allowing the
- NIC to continue to allocate and regulate network names, much as it
- allocates numbers, but the majority opinion favors local control of
-
-
-
-Mockapetris [Page 2]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- network names. Although it would be possible to provide a flat space
- or a name space in which, for example, the last label of a domain
- name captured the old-style network name, any such approach would add
- complexity to the method and create different rules for network names
- and host names.
-
- For these reasons, we assume that the syntax of network names will be
- the same as the expanded syntax for host names permitted in [HR].
- The new syntax expands the set of names to allow leading digits, so
- long as the resulting representations do not conflict with IP
- addresses in decimal octet form. For example, 3Com.COM and 3M.COM
- are now legal, although 26.0.0.73.COM is not. See [HR] for details.
-
- The price is that network names will get as complicated as host
- names. An administrator will be able to create network names in any
- domain under his control, and also create network number to name
- entries in IN-ADDR.ARPA domains under his control. Thus, the name
- for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
- network.MIL., depending on the preferences of the owner.
-
-3.2. Mappings
-
- The desired mappings, ranked by priority with most important first,
- are:
-
- - Mapping a IP address or network number to a network name.
-
- This mapping is for use in debugging tools and status displays
- of various sorts. The conversion from IP address to network
- number is well known for class A, B, and C IP addresses, and
- involves a simple mask operation. The needs of other classes
- are not yet defined and are ignored for the rest of this RFC.
-
- - Mapping a network name to a network address.
-
- This facility is of less obvious application, but a
- symmetrical mapping seems desirable.
-
- - Mapping an organization to its network names and numbers.
-
- This facility is useful because it may not always be possible
- to guess the local choice for network names, but the
- organization name is often well known.
-
- - Similar mappings for subnets, even when nested.
-
- The primary application is to be able to identify all of the
- subnets involved in a particular IP address. A secondary
-
-
-
-Mockapetris [Page 3]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- requirement is to retrieve address mask information.
-
-3.3. Network address section of the name space
-
- The network name syntax discussed above can provide domain names
- which will contain mappings from network names to various quantities,
- but we also need a section of the name space, organized by network
- and subnet number to hold the inverse mappings.
-
- The choices include:
-
- - The same network number slots already assigned and delegated
- in the IN-ADDR.ARPA section of the name space.
-
- For example, 10.IN-ADDR.ARPA for class A net 10,
- 2.128.IN-ADDR.ARPA for class B net 128.2, etc.
-
- - Host-zero addresses in the IN-ADDR.ARPA tree. (A host field
- of all zero in an IP address is prohibited because of
- confusion related to broadcast addresses, et al.)
-
- For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
- 0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc. Like the
- first scheme, it uses in-place name space delegations to
- distribute control.
-
- The main advantage of this scheme over the first is that it
- allows convenient names for subnets as well as networks. A
- secondary advantage is that it uses names which are not in use
- already, and hence it is possible to test whether an
- organization has entered this information in its domain
- database.
-
- - Some new section of the name space.
-
- While this option provides the most opportunities, it creates
- a need to delegate a whole new name space. Since the IP
- address space is so closely related to the network number
- space, most believe that the overhead of creating such a new
- space is overwhelming and would lead to the WKS syndrome. (As
- of February, 1989, approximately 400 sections of the
- IN-ADDR.ARPA tree are already delegated, usually at network
- boundaries.)
-
-
-
-
-
-
-
-
-Mockapetris [Page 4]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
-4. SPECIFICS FOR NETWORK NAME MAPPINGS
-
- The proposed solution uses information stored at:
-
- - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
- addresses. The same method is used for subnets in a nested
- fashion. For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
-
- Two types of information are stored here: PTR RRs which point
- to the network name in their data sections, and A RRs, which
- are present if the network (or subnet) is subnetted further.
- If a type A RR is present, then it has the address mask as its
- data. The general form is:
-
- <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
- <reversed-host-zero-number>.IN-ADDR.ARPA. A <subnet-mask>
-
- For example:
-
- 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
-
- or
-
- 0.0.2.128.IN-ADDR.ARPA. PTR cmu-net.cmu.edu.
- A 255.255.255.0
-
- In general, this information will be added to an existing
- master file for some IN-ADDR.ARPA domain for each network
- involved. Similar RRs can be used at host-zero subnet
- entries.
-
- - Names which are network names.
-
- The data stored here is PTR RRs pointing at the host-zero
- entries. The general form is:
-
- <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
-
- For example:
-
- ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
-
- or
-
- isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
-
- In general, this information will be inserted in the master
- file for the domain name of the organization; this is a
-
-
-
-Mockapetris [Page 5]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- different file from that which holds the information below
- IN-ADDR.ARPA. Similar PTR RRs can be used at subnet names.
-
- - Names corresponding to organizations.
-
- The data here is one or more PTR RRs pointing at the
- IN-ADDR.ARPA names corresponding to host-zero entries for
- networks.
-
- For example:
-
- ISI.EDU. PTR 0.0.9.128.IN-ADDR.ARPA.
-
- MCC.COM. PTR 0.167.5.192.IN-ADDR.ARPA.
- PTR 0.168.5.192.IN-ADDR.ARPA.
- PTR 0.169.5.192.IN-ADDR.ARPA.
- PTR 0.0.62.128.IN-ADDR.ARPA.
-
-4.1. A simple example
-
- The ARPANET is a Class A network without subnets. The RRs which
- would be added, assuming the ARPANET.ARPA was selected as a network
- name, would be:
-
- ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
-
- ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
-
- 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
-
- The first RR states that the organization named ARPA owns net 10 (It
- might also own more network numbers, and these would be represented
- with an additional RR per net.) The second states that the network
- name ARPANET.ARPA. maps to net 10. The last states that net 10 is
- named ARPANET.ARPA.
-
- Note that all of the usual host and corresponding IN-ADDR.ARPA
- entries would still be required.
-
-4.2. A complicated, subnetted example
-
- The ISI network is 128.9, a class B number. Suppose the ISI network
- was organized into two levels of subnet, with the first level using
- an additional 8 bits of address, and the second level using 4 bits,
- for address masks of x'FFFFFF00' and X'FFFFFFF0'.
-
- Then the following RRs would be entered in ISI's master file for the
- ISI.EDU zone:
-
-
-
-Mockapetris [Page 6]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- ; Define network entry
- isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
-
- ; Define first level subnets
- div1-subnet.isi.edu. PTR 0.1.9.128.IN-ADDR.ARPA.
- div2-subnet.isi.edu. PTR 0.2.9.128.IN-ADDR.ARPA.
-
- ; Define second level subnets
- inc-subsubnet.isi.edu. PTR 16.2.9.128.IN-ADDR.ARPA.
-
- in the 9.128.IN-ADDR.ARPA zone:
-
- ; Define network number and address mask
- 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
- A 255.255.255.0 ;aka X'FFFFFF00'
-
- ; Define one of the first level subnet numbers and masks
- 0.1.9.128.IN-ADDR.ARPA. PTR div1-subnet.isi.edu.
- A 255.255.255.240 ;aka X'FFFFFFF0'
-
- ; Define another first level subnet number and mask
- 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
- A 255.255.255.240 ;aka X'FFFFFFF0'
-
- ; Define second level subnet number
- 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
-
- This assumes that the ISI network is named isi-net.isi.edu., first
- level subnets are named div1-subnet.isi.edu. and div2-
- subnet.isi.edu., and a second level subnet is called inc-
- subsubnet.isi.edu. (In a real system as complicated as this there
- would be more first and second level subnets defined, but we have
- shown enough to illustrate the ideas.)
-
-4.3. Procedure for using an IP address to get network name
-
- Depending on whether the IP address is class A, B, or C, mask off the
- high one, two, or three bytes, respectively. Reverse the octets,
- suffix IN-ADDR.ARPA, and do a PTR query.
-
- For example, suppose the IP address is 10.0.0.51.
-
- 1. Since this is a class A address, use a mask x'FF000000' and
- get 10.0.0.0.
-
- 2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
-
- 3. Do a PTR query. Get back
-
-
-
-Mockapetris [Page 7]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
-
- 4. Conclude that the network name is "ARPANET.ARPA."
-
- Suppose that the IP address is 128.9.2.17.
-
- 1. Since this is a class B address, use a mask of x'FFFF0000'
- and get 128.9.0.0.
-
- 2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
-
- 3. Do a PTR query. Get back
-
- 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu
-
- 4. Conclude that the network name is "isi-net.isi.edu."
-
-4.4. Procedure for finding all subnets involved with an IP address
-
- This is a simple extension of the IP address to network name method.
- When the network entry is located, do a lookup for a possible A RR.
- If the A RR is found, look up the next level of subnet using the
- original IP address and the mask in the A RR. Repeat this procedure
- until no A RR is found.
-
- For example, repeating the use of 128.9.2.17.
-
- 1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
- Retrieve:
-
- 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
- A 255.255.255.0
-
- 2. Since an A RR was found, repeat using mask from RR
- (255.255.255.0), constructing a query for
- 0.2.9.128.IN-ADDR.ARPA. Retrieve:
-
- 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
- A 255.255.255.240
-
- 3. Since another A RR was found, repeat using mask
- 255.255.255.240 (x'FFFFFFF0'). constructing a query for
- 16.2.9.128.IN-ADDR.ARPA. Retrieve:
-
- 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
-
- 4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
- are no more subnet levels.
-
-
-
-Mockapetris [Page 8]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
-5. YP ISSUES AND DISCUSSION
-
- The term "Yellow Pages" is used in almost as many ways as the term
- "domain", so it is useful to define what is meant herein by YP. The
- general problem to be solved is to create a method for creating
- mappings from one kind of identifier to another, often with an
- inverse capability. The traditional methods are to search or use a
- precomputed index of some kind.
-
- Searching is impractical when the search is too large, and
- precomputed indexes are possible only when it is possible to specify
- search criteria in advance, and pay for the resources necessary to
- build the index. For example, it is impractical to search the entire
- domain tree to find a particular address RR, so we build the IN-
- ADDR.ARPA YP. Similarly, we could never build an Internet-wide index
- of "hosts with a load average of less than 2" in less time than it
- would take for the data to change, so indexes are a useless approach
- for that problem.
-
- Such a precomputed index is what we mean by YP, and we regard the
- IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
- Although a single, centrally-managed YP for well-known values such as
- TCP-port is desirable, we regard organization-specific YPs for, say,
- locally defined TCP ports as a natural extension, as are combinations
- of YPs using search lists to merge the two.
-
- In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
- 1010], it is clear that there are several mappings which might be of
- value. For example:
-
- <assigned-network-name> <==> <IP-address>
- <autonomous-system-id> <==> <number>
- <protocol-id> <==> <number>
- <port-id> <==> <number>
- <ethernet-type> <==> <number>
- <public-data-net> <==> <IP-address>
-
- Following the IN-ADDR example, the YP takes the form of a domain tree
- organized to optimize retrieval by search key and distribution via
- normal DNS rules. The name used as a key must include:
-
- 1. A well known origin. For example, IN-ADDR.ARPA is the
- current IP-address to host name YP.
-
- 2. A "from" data type. This identifies the input type of the
- mapping. This is necessary because we may be mapping
- something as anonymous as a number to any number of
- mnemonics, etc.
-
-
-
-Mockapetris [Page 9]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- 3. A "to" data type. Since we assume several symmetrical
- mnemonic <==> number mappings, this is also necessary.
-
- This ordering reflects the natural scoping of control, and hence the
- order of the components in a domain name. Thus domain names would be
- of the form:
-
- <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
-
- To make this work, we need to define well-know strings for each of
- these metavariables, as well as encoding rules for converting a
- <from-value> into a domain name. We might define:
-
- <YP-origin> :=YP
- <from-data-type>:=TCP-port | IN-ADDR | Number |
- Assigned-network-number | Name
- <to-data-type> :=<from-data-type>
-
- Note that "YP" is NOT a valid country code under [ISO 3166] (although
- we may want to worry about the future), and the existence of a
- syntactically valid <to-data-type>.<from-data-type> pair does not
- imply that a meaningful mapping exists, or is even possible.
-
- The encoding rules might be:
-
- TCP-port Six character alphanumeric
-
- IN-ADDR Reversed 4-octet decimal string
-
- Number decimal integer
-
- Assigned-network-number
- Reversed 4-octet decimal string
-
- Name Domain name
-
-6. SPECIFICS FOR YP MAPPINGS
-
-6.1. TCP-PORT
-
- $origin Number.TCP-port.YP.
-
- 23 PTR TELNET.TCP-port.Number.YP.
- 25 PTR SMTP.TCP-port.Number.YP.
-
- $origin TCP-port.Number.YP.
-
- TELNET PTR 23.Number.TCP-port.YP.
-
-
-
-Mockapetris [Page 10]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- SMTP PTR 25.Number.TCP-port.YP.
-
- Thus the mapping between 23 and TELNET is represented by a pair of
- PTR RRs, one for each direction of the mapping.
-
-6.2. Assigned networks
-
- Network numbers are assigned by the NIC and reported in "Internet
- Numbers" RFCs. To create a YP, the NIC would set up two domains:
-
- Name.Assigned-network-number.YP and Assigned-network-number.YP
-
- The first would contain entries of the form:
-
- $origin Name.Assigned-network-number.YP.
-
- 0.0.0.4 PTR SATNET.Assigned-network-number.Name.YP.
- 0.0.0.10 PTR ARPANET.Assigned-network-number.Name.YP.
-
- The second would contain entries of the form:
-
- $origin Assigned-network-number.Name.YP.
-
- SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
- ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
-
- These YPs are not in conflict with the network name support described
- in the first half of this RFC since they map between ASSIGNED network
- names and numbers, not those allocated by the organizations
- themselves. That is, they document the NIC's decisions about
- allocating network numbers but do not automatically track any
- renaming performed by the new owners.
-
- As a practical matter, we might want to create both of these domains
- to enable users on the Internet to experiment with centrally
- maintained support as well as the distributed version, or might want
- to implement only the allocated number to name mapping and request
- organizations to convert their allocated network names to the network
- names described in the distributed model.
-
-6.3. Operational improvements
-
- We could imagine that all conversion routines using these YPs might
- be instructed to use "YP.<local-domain>" followed by "YP." as a
- search list. Thus, if the organization ISI.EDU wished to define
- locally meaningful TCP-PORT, it would define the domains:
-
- <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
-
-
-
-Mockapetris [Page 11]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- We could add another level of indirection in the YP lookup, defining
- the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
- YP tree, rather than being the YP tree directly. This would enable
- entries of the form:
-
- IN-ADDR.Netname.YP. PTR IN-ADDR.ARPA.
-
- to splice in YPs from other origins or existing spaces.
-
- Another possibility would be to shorten the RDATA section of the RRs
- which map back and forth by deleting the origin. This could be done
- either by allowing the domain name in the RDATA portion to not
- identify a real domain name, or by defining a new RR which used a
- simple text string rather than a domain name.
-
- Thus, we might replace
-
- $origin Assigned-network-number.Name.YP.
-
- SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
- ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
-
- with
-
- $origin Assigned-network-number.Name.YP.
-
- SATNET. PTR 0.0.0.4.
- ARPANET. PTR 0.0.0.10.
-
- or
-
- $origin Assigned-network-number.Name.YP.
-
- SATNET. PTT "0.0.0.4"
- ARPANET. PTT "0.0.0.10"
-
- where PTT is a new type whose RDATA section is a text string.
-
-7. ACKNOWLEDGMENTS
-
- Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
- ideas in this RFC. Numerous contributions, criticisms, and
- compromises were produced in the IETF Domain working group and the
- NAMEDROPPERS mailing list.
-
-
-
-
-
-
-
-Mockapetris [Page 12]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
-8. REFERENCES
-
- [HR] Braden, B., editor, "Requirements for Internet Hosts",
- RFC in preparation.
-
- [ISO 3166] ISO, "Codes for the Representation of Names of
- Countries", 1981.
-
- [RFC 882] Mockapetris, P., "Domain names - Concepts and
- Facilities", RFC 882, USC/Information Sciences Institute,
- November 1983.
-
- Superseded by RFC 1034.
-
- [RFC 883] Mockapetris, P.,"Domain names - Implementation and
- Specification", RFC 883, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by RFC 1035.
-
- [RFC 920] Postel, J. and J. Reynolds, "Domain Requirements", RFC
- 920, October 1984.
-
- Explains the naming scheme for top level domains.
-
- [RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
- Host Table Specification", RFC 952, SRI, October 1985.
-
- Specifies the format of HOSTS.TXT, the host/address table
- replaced by the DNS
-
- [RFC 973] Mockapetris, P., "Domain System Changes and
- Observations", RFC 973, USC/Information Sciences
- Institute, January 1986.
-
- Describes changes to RFCs 882 and 883 and reasons for
- them.
-
- [RFC 974] Partridge, C., "Mail routing and the domain system", RFC
- 974, CSNET CIC BBN Labs, January 1986.
-
- Describes the transition from HOSTS.TXT based mail
- addressing to the more powerful MX system used with the
- domain system.
-
-
-
-
-
-
-
-Mockapetris [Page 13]
-
-RFC 1101 DNS Encoding of Network Names and Other Types April 1989
-
-
- [RFC 997] Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
- USC/Information Sciences Institute, March 1987
-
- Contains network numbers, autonomous system numbers, etc.
-
- [RFC 1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
- 1010, USC/Information Sciences Institute, May 1987
-
- Contains socket numbers and mnemonics for host names,
- operating systems, etc.
-
-
- [RFC 1034] Mockapetris, P., "Domain names - Concepts and
- Facilities", RFC 1034, USC/Information Sciences
- Institute, November 1987.
-
- Introduction/overview of the DNS.
-
- [RFC 1035] Mockapetris, P., "Domain names - Implementation and
- Specification", RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- DNS implementation instructions.
-
-Author's Address:
-
- Paul Mockapetris
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA 90292
-
- Phone: (213) 822-1511
-
- Email: PVM@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 14]
- \ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1122.txt b/contrib/bind9/doc/rfc/rfc1122.txt
deleted file mode 100644
index c14f2e50a319d..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1122.txt
+++ /dev/null
@@ -1,6844 +0,0 @@
-
-
-
-
-
-
-Network Working Group Internet Engineering Task Force
-Request for Comments: 1122 R. Braden, Editor
- October 1989
-
-
- Requirements for Internet Hosts -- Communication Layers
-
-
-Status of This Memo
-
- This RFC is an official specification for the Internet community. It
- incorporates by reference, amends, corrects, and supplements the
- primary protocol standards documents relating to hosts. Distribution
- of this document is unlimited.
-
-Summary
-
- This is one RFC of a pair that defines and discusses the requirements
- for Internet host software. This RFC covers the communications
- protocol layers: link layer, IP layer, and transport layer; its
- companion RFC-1123 covers the application and support protocols.
-
-
-
- Table of Contents
-
-
-
-
- 1. INTRODUCTION ............................................... 5
- 1.1 The Internet Architecture .............................. 6
- 1.1.1 Internet Hosts .................................... 6
- 1.1.2 Architectural Assumptions ......................... 7
- 1.1.3 Internet Protocol Suite ........................... 8
- 1.1.4 Embedded Gateway Code ............................. 10
- 1.2 General Considerations ................................. 12
- 1.2.1 Continuing Internet Evolution ..................... 12
- 1.2.2 Robustness Principle .............................. 12
- 1.2.3 Error Logging ..................................... 13
- 1.2.4 Configuration ..................................... 14
- 1.3 Reading this Document .................................. 15
- 1.3.1 Organization ...................................... 15
- 1.3.2 Requirements ...................................... 16
- 1.3.3 Terminology ....................................... 17
- 1.4 Acknowledgments ........................................ 20
-
- 2. LINK LAYER .................................................. 21
- 2.1 INTRODUCTION ........................................... 21
-
-
-
-Internet Engineering Task Force [Page 1]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- 2.2 PROTOCOL WALK-THROUGH .................................. 21
- 2.3 SPECIFIC ISSUES ........................................ 21
- 2.3.1 Trailer Protocol Negotiation ...................... 21
- 2.3.2 Address Resolution Protocol -- ARP ................ 22
- 2.3.2.1 ARP Cache Validation ......................... 22
- 2.3.2.2 ARP Packet Queue ............................. 24
- 2.3.3 Ethernet and IEEE 802 Encapsulation ............... 24
- 2.4 LINK/INTERNET LAYER INTERFACE .......................... 25
- 2.5 LINK LAYER REQUIREMENTS SUMMARY ........................ 26
-
- 3. INTERNET LAYER PROTOCOLS .................................... 27
- 3.1 INTRODUCTION ............................................ 27
- 3.2 PROTOCOL WALK-THROUGH .................................. 29
- 3.2.1 Internet Protocol -- IP ............................ 29
- 3.2.1.1 Version Number ............................... 29
- 3.2.1.2 Checksum ..................................... 29
- 3.2.1.3 Addressing ................................... 29
- 3.2.1.4 Fragmentation and Reassembly ................. 32
- 3.2.1.5 Identification ............................... 32
- 3.2.1.6 Type-of-Service .............................. 33
- 3.2.1.7 Time-to-Live ................................. 34
- 3.2.1.8 Options ...................................... 35
- 3.2.2 Internet Control Message Protocol -- ICMP .......... 38
- 3.2.2.1 Destination Unreachable ...................... 39
- 3.2.2.2 Redirect ..................................... 40
- 3.2.2.3 Source Quench ................................ 41
- 3.2.2.4 Time Exceeded ................................ 41
- 3.2.2.5 Parameter Problem ............................ 42
- 3.2.2.6 Echo Request/Reply ........................... 42
- 3.2.2.7 Information Request/Reply .................... 43
- 3.2.2.8 Timestamp and Timestamp Reply ................ 43
- 3.2.2.9 Address Mask Request/Reply ................... 45
- 3.2.3 Internet Group Management Protocol IGMP ........... 47
- 3.3 SPECIFIC ISSUES ........................................ 47
- 3.3.1 Routing Outbound Datagrams ........................ 47
- 3.3.1.1 Local/Remote Decision ........................ 47
- 3.3.1.2 Gateway Selection ............................ 48
- 3.3.1.3 Route Cache .................................. 49
- 3.3.1.4 Dead Gateway Detection ....................... 51
- 3.3.1.5 New Gateway Selection ........................ 55
- 3.3.1.6 Initialization ............................... 56
- 3.3.2 Reassembly ........................................ 56
- 3.3.3 Fragmentation ..................................... 58
- 3.3.4 Local Multihoming ................................. 60
- 3.3.4.1 Introduction ................................. 60
- 3.3.4.2 Multihoming Requirements ..................... 61
- 3.3.4.3 Choosing a Source Address .................... 64
- 3.3.5 Source Route Forwarding ........................... 65
-
-
-
-Internet Engineering Task Force [Page 2]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- 3.3.6 Broadcasts ........................................ 66
- 3.3.7 IP Multicasting ................................... 67
- 3.3.8 Error Reporting ................................... 69
- 3.4 INTERNET/TRANSPORT LAYER INTERFACE ..................... 69
- 3.5 INTERNET LAYER REQUIREMENTS SUMMARY .................... 72
-
- 4. TRANSPORT PROTOCOLS ......................................... 77
- 4.1 USER DATAGRAM PROTOCOL -- UDP .......................... 77
- 4.1.1 INTRODUCTION ...................................... 77
- 4.1.2 PROTOCOL WALK-THROUGH ............................. 77
- 4.1.3 SPECIFIC ISSUES ................................... 77
- 4.1.3.1 Ports ........................................ 77
- 4.1.3.2 IP Options ................................... 77
- 4.1.3.3 ICMP Messages ................................ 78
- 4.1.3.4 UDP Checksums ................................ 78
- 4.1.3.5 UDP Multihoming .............................. 79
- 4.1.3.6 Invalid Addresses ............................ 79
- 4.1.4 UDP/APPLICATION LAYER INTERFACE ................... 79
- 4.1.5 UDP REQUIREMENTS SUMMARY .......................... 80
- 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP ................... 82
- 4.2.1 INTRODUCTION ...................................... 82
- 4.2.2 PROTOCOL WALK-THROUGH ............................. 82
- 4.2.2.1 Well-Known Ports ............................. 82
- 4.2.2.2 Use of Push .................................. 82
- 4.2.2.3 Window Size .................................. 83
- 4.2.2.4 Urgent Pointer ............................... 84
- 4.2.2.5 TCP Options .................................. 85
- 4.2.2.6 Maximum Segment Size Option .................. 85
- 4.2.2.7 TCP Checksum ................................. 86
- 4.2.2.8 TCP Connection State Diagram ................. 86
- 4.2.2.9 Initial Sequence Number Selection ............ 87
- 4.2.2.10 Simultaneous Open Attempts .................. 87
- 4.2.2.11 Recovery from Old Duplicate SYN ............. 87
- 4.2.2.12 RST Segment ................................. 87
- 4.2.2.13 Closing a Connection ........................ 87
- 4.2.2.14 Data Communication .......................... 89
- 4.2.2.15 Retransmission Timeout ...................... 90
- 4.2.2.16 Managing the Window ......................... 91
- 4.2.2.17 Probing Zero Windows ........................ 92
- 4.2.2.18 Passive OPEN Calls .......................... 92
- 4.2.2.19 Time to Live ................................ 93
- 4.2.2.20 Event Processing ............................ 93
- 4.2.2.21 Acknowledging Queued Segments ............... 94
- 4.2.3 SPECIFIC ISSUES ................................... 95
- 4.2.3.1 Retransmission Timeout Calculation ........... 95
- 4.2.3.2 When to Send an ACK Segment .................. 96
- 4.2.3.3 When to Send a Window Update ................. 97
- 4.2.3.4 When to Send Data ............................ 98
-
-
-
-Internet Engineering Task Force [Page 3]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- 4.2.3.5 TCP Connection Failures ...................... 100
- 4.2.3.6 TCP Keep-Alives .............................. 101
- 4.2.3.7 TCP Multihoming .............................. 103
- 4.2.3.8 IP Options ................................... 103
- 4.2.3.9 ICMP Messages ................................ 103
- 4.2.3.10 Remote Address Validation ................... 104
- 4.2.3.11 TCP Traffic Patterns ........................ 104
- 4.2.3.12 Efficiency .................................. 105
- 4.2.4 TCP/APPLICATION LAYER INTERFACE ................... 106
- 4.2.4.1 Asynchronous Reports ......................... 106
- 4.2.4.2 Type-of-Service .............................. 107
- 4.2.4.3 Flush Call ................................... 107
- 4.2.4.4 Multihoming .................................. 108
- 4.2.5 TCP REQUIREMENT SUMMARY ........................... 108
-
- 5. REFERENCES ................................................. 112
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 4]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
-1. INTRODUCTION
-
- This document is one of a pair that defines and discusses the
- requirements for host system implementations of the Internet protocol
- suite. This RFC covers the communication protocol layers: link
- layer, IP layer, and transport layer. Its companion RFC,
- "Requirements for Internet Hosts -- Application and Support"
- [INTRO:1], covers the application layer protocols. This document
- should also be read in conjunction with "Requirements for Internet
- Gateways" [INTRO:2].
-
- These documents are intended to provide guidance for vendors,
- implementors, and users of Internet communication software. They
- represent the consensus of a large body of technical experience and
- wisdom, contributed by the members of the Internet research and
- vendor communities.
-
- This RFC enumerates standard protocols that a host connected to the
- Internet must use, and it incorporates by reference the RFCs and
- other documents describing the current specifications for these
- protocols. It corrects errors in the referenced documents and adds
- additional discussion and guidance for an implementor.
-
- For each protocol, this document also contains an explicit set of
- requirements, recommendations, and options. The reader must
- understand that the list of requirements in this document is
- incomplete by itself; the complete set of requirements for an
- Internet host is primarily defined in the standard protocol
- specification documents, with the corrections, amendments, and
- supplements contained in this RFC.
-
- A good-faith implementation of the protocols that was produced after
- careful reading of the RFC's and with some interaction with the
- Internet technical community, and that followed good communications
- software engineering practices, should differ from the requirements
- of this document in only minor ways. Thus, in many cases, the
- "requirements" in this RFC are already stated or implied in the
- standard protocol documents, so that their inclusion here is, in a
- sense, redundant. However, they were included because some past
- implementation has made the wrong choice, causing problems of
- interoperability, performance, and/or robustness.
-
- This document includes discussion and explanation of many of the
- requirements and recommendations. A simple list of requirements
- would be dangerous, because:
-
- o Some required features are more important than others, and some
- features are optional.
-
-
-
-Internet Engineering Task Force [Page 5]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- o There may be valid reasons why particular vendor products that
- are designed for restricted contexts might choose to use
- different specifications.
-
- However, the specifications of this document must be followed to meet
- the general goal of arbitrary host interoperation across the
- diversity and complexity of the Internet system. Although most
- current implementations fail to meet these requirements in various
- ways, some minor and some major, this specification is the ideal
- towards which we need to move.
-
- These requirements are based on the current level of Internet
- architecture. This document will be updated as required to provide
- additional clarifications or to include additional information in
- those areas in which specifications are still evolving.
-
- This introductory section begins with a brief overview of the
- Internet architecture as it relates to hosts, and then gives some
- general advice to host software vendors. Finally, there is some
- guidance on reading the rest of the document and some terminology.
-
- 1.1 The Internet Architecture
-
- General background and discussion on the Internet architecture and
- supporting protocol suite can be found in the DDN Protocol
- Handbook [INTRO:3]; for background see for example [INTRO:9],
- [INTRO:10], and [INTRO:11]. Reference [INTRO:5] describes the
- procedure for obtaining Internet protocol documents, while
- [INTRO:6] contains a list of the numbers assigned within Internet
- protocols.
-
- 1.1.1 Internet Hosts
-
- A host computer, or simply "host," is the ultimate consumer of
- communication services. A host generally executes application
- programs on behalf of user(s), employing network and/or
- Internet communication services in support of this function.
- An Internet host corresponds to the concept of an "End-System"
- used in the OSI protocol suite [INTRO:13].
-
- An Internet communication system consists of interconnected
- packet networks supporting communication among host computers
- using the Internet protocols. The networks are interconnected
- using packet-switching computers called "gateways" or "IP
- routers" by the Internet community, and "Intermediate Systems"
- by the OSI world [INTRO:13]. The RFC "Requirements for
- Internet Gateways" [INTRO:2] contains the official
- specifications for Internet gateways. That RFC together with
-
-
-
-Internet Engineering Task Force [Page 6]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- the present document and its companion [INTRO:1] define the
- rules for the current realization of the Internet architecture.
-
- Internet hosts span a wide range of size, speed, and function.
- They range in size from small microprocessors through
- workstations to mainframes and supercomputers. In function,
- they range from single-purpose hosts (such as terminal servers)
- to full-service hosts that support a variety of online network
- services, typically including remote login, file transfer, and
- electronic mail.
-
- A host is generally said to be multihomed if it has more than
- one interface to the same or to different networks. See
- Section 1.1.3 on "Terminology".
-
- 1.1.2 Architectural Assumptions
-
- The current Internet architecture is based on a set of
- assumptions about the communication system. The assumptions
- most relevant to hosts are as follows:
-
- (a) The Internet is a network of networks.
-
- Each host is directly connected to some particular
- network(s); its connection to the Internet is only
- conceptual. Two hosts on the same network communicate
- with each other using the same set of protocols that they
- would use to communicate with hosts on distant networks.
-
- (b) Gateways don't keep connection state information.
-
- To improve robustness of the communication system,
- gateways are designed to be stateless, forwarding each IP
- datagram independently of other datagrams. As a result,
- redundant paths can be exploited to provide robust service
- in spite of failures of intervening gateways and networks.
-
- All state information required for end-to-end flow control
- and reliability is implemented in the hosts, in the
- transport layer or in application programs. All
- connection control information is thus co-located with the
- end points of the communication, so it will be lost only
- if an end point fails.
-
- (c) Routing complexity should be in the gateways.
-
- Routing is a complex and difficult problem, and ought to
- be performed by the gateways, not the hosts. An important
-
-
-
-Internet Engineering Task Force [Page 7]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- objective is to insulate host software from changes caused
- by the inevitable evolution of the Internet routing
- architecture.
-
- (d) The System must tolerate wide network variation.
-
- A basic objective of the Internet design is to tolerate a
- wide range of network characteristics -- e.g., bandwidth,
- delay, packet loss, packet reordering, and maximum packet
- size. Another objective is robustness against failure of
- individual networks, gateways, and hosts, using whatever
- bandwidth is still available. Finally, the goal is full
- "open system interconnection": an Internet host must be
- able to interoperate robustly and effectively with any
- other Internet host, across diverse Internet paths.
-
- Sometimes host implementors have designed for less
- ambitious goals. For example, the LAN environment is
- typically much more benign than the Internet as a whole;
- LANs have low packet loss and delay and do not reorder
- packets. Some vendors have fielded host implementations
- that are adequate for a simple LAN environment, but work
- badly for general interoperation. The vendor justifies
- such a product as being economical within the restricted
- LAN market. However, isolated LANs seldom stay isolated
- for long; they are soon gatewayed to each other, to
- organization-wide internets, and eventually to the global
- Internet system. In the end, neither the customer nor the
- vendor is served by incomplete or substandard Internet
- host software.
-
- The requirements spelled out in this document are designed
- for a full-function Internet host, capable of full
- interoperation over an arbitrary Internet path.
-
-
- 1.1.3 Internet Protocol Suite
-
- To communicate using the Internet system, a host must implement
- the layered set of protocols comprising the Internet protocol
- suite. A host typically must implement at least one protocol
- from each layer.
-
- The protocol layers used in the Internet architecture are as
- follows [INTRO:4]:
-
-
- o Application Layer
-
-
-
-Internet Engineering Task Force [Page 8]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- The application layer is the top layer of the Internet
- protocol suite. The Internet suite does not further
- subdivide the application layer, although some of the
- Internet application layer protocols do contain some
- internal sub-layering. The application layer of the
- Internet suite essentially combines the functions of the
- top two layers -- Presentation and Application -- of the
- OSI reference model.
-
- We distinguish two categories of application layer
- protocols: user protocols that provide service directly
- to users, and support protocols that provide common system
- functions. Requirements for user and support protocols
- will be found in the companion RFC [INTRO:1].
-
- The most common Internet user protocols are:
-
- o Telnet (remote login)
- o FTP (file transfer)
- o SMTP (electronic mail delivery)
-
- There are a number of other standardized user protocols
- [INTRO:4] and many private user protocols.
-
- Support protocols, used for host name mapping, booting,
- and management, include SNMP, BOOTP, RARP, and the Domain
- Name System (DNS) protocols.
-
-
- o Transport Layer
-
- The transport layer provides end-to-end communication
- services for applications. There are two primary
- transport layer protocols at present:
-
- o Transmission Control Protocol (TCP)
- o User Datagram Protocol (UDP)
-
- TCP is a reliable connection-oriented transport service
- that provides end-to-end reliability, resequencing, and
- flow control. UDP is a connectionless ("datagram")
- transport service.
-
- Other transport protocols have been developed by the
- research community, and the set of official Internet
- transport protocols may be expanded in the future.
-
- Transport layer protocols are discussed in Chapter 4.
-
-
-
-Internet Engineering Task Force [Page 9]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- o Internet Layer
-
- All Internet transport protocols use the Internet Protocol
- (IP) to carry data from source host to destination host.
- IP is a connectionless or datagram internetwork service,
- providing no end-to-end delivery guarantees. Thus, IP
- datagrams may arrive at the destination host damaged,
- duplicated, out of order, or not at all. The layers above
- IP are responsible for reliable delivery service when it
- is required. The IP protocol includes provision for
- addressing, type-of-service specification, fragmentation
- and reassembly, and security information.
-
- The datagram or connectionless nature of the IP protocol
- is a fundamental and characteristic feature of the
- Internet architecture. Internet IP was the model for the
- OSI Connectionless Network Protocol [INTRO:12].
-
- ICMP is a control protocol that is considered to be an
- integral part of IP, although it is architecturally
- layered upon IP, i.e., it uses IP to carry its data end-
- to-end just as a transport protocol like TCP or UDP does.
- ICMP provides error reporting, congestion reporting, and
- first-hop gateway redirection.
-
- IGMP is an Internet layer protocol used for establishing
- dynamic host groups for IP multicasting.
-
- The Internet layer protocols IP, ICMP, and IGMP are
- discussed in Chapter 3.
-
-
- o Link Layer
-
- To communicate on its directly-connected network, a host
- must implement the communication protocol used to
- interface to that network. We call this a link layer or
- media-access layer protocol.
-
- There is a wide variety of link layer protocols,
- corresponding to the many different types of networks.
- See Chapter 2.
-
-
- 1.1.4 Embedded Gateway Code
-
- Some Internet host software includes embedded gateway
- functionality, so that these hosts can forward packets as a
-
-
-
-Internet Engineering Task Force [Page 10]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- gateway would, while still performing the application layer
- functions of a host.
-
- Such dual-purpose systems must follow the Gateway Requirements
- RFC [INTRO:2] with respect to their gateway functions, and
- must follow the present document with respect to their host
- functions. In all overlapping cases, the two specifications
- should be in agreement.
-
- There are varying opinions in the Internet community about
- embedded gateway functionality. The main arguments are as
- follows:
-
- o Pro: in a local network environment where networking is
- informal, or in isolated internets, it may be convenient
- and economical to use existing host systems as gateways.
-
- There is also an architectural argument for embedded
- gateway functionality: multihoming is much more common
- than originally foreseen, and multihoming forces a host to
- make routing decisions as if it were a gateway. If the
- multihomed host contains an embedded gateway, it will
- have full routing knowledge and as a result will be able
- to make more optimal routing decisions.
-
- o Con: Gateway algorithms and protocols are still changing,
- and they will continue to change as the Internet system
- grows larger. Attempting to include a general gateway
- function within the host IP layer will force host system
- maintainers to track these (more frequent) changes. Also,
- a larger pool of gateway implementations will make
- coordinating the changes more difficult. Finally, the
- complexity of a gateway IP layer is somewhat greater than
- that of a host, making the implementation and operation
- tasks more complex.
-
- In addition, the style of operation of some hosts is not
- appropriate for providing stable and robust gateway
- service.
-
- There is considerable merit in both of these viewpoints. One
- conclusion can be drawn: an host administrator must have
- conscious control over whether or not a given host acts as a
- gateway. See Section 3.1 for the detailed requirements.
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 11]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- 1.2 General Considerations
-
- There are two important lessons that vendors of Internet host
- software have learned and which a new vendor should consider
- seriously.
-
- 1.2.1 Continuing Internet Evolution
-
- The enormous growth of the Internet has revealed problems of
- management and scaling in a large datagram-based packet
- communication system. These problems are being addressed, and
- as a result there will be continuing evolution of the
- specifications described in this document. These changes will
- be carefully planned and controlled, since there is extensive
- participation in this planning by the vendors and by the
- organizations responsible for operations of the networks.
-
- Development, evolution, and revision are characteristic of
- computer network protocols today, and this situation will
- persist for some years. A vendor who develops computer
- communication software for the Internet protocol suite (or any
- other protocol suite!) and then fails to maintain and update
- that software for changing specifications is going to leave a
- trail of unhappy customers. The Internet is a large
- communication network, and the users are in constant contact
- through it. Experience has shown that knowledge of
- deficiencies in vendor software propagates quickly through the
- Internet technical community.
-
- 1.2.2 Robustness Principle
-
- At every layer of the protocols, there is a general rule whose
- application can lead to enormous benefits in robustness and
- interoperability [IP:1]:
-
- "Be liberal in what you accept, and
- conservative in what you send"
-
- Software should be written to deal with every conceivable
- error, no matter how unlikely; sooner or later a packet will
- come in with that particular combination of errors and
- attributes, and unless the software is prepared, chaos can
- ensue. In general, it is best to assume that the network is
- filled with malevolent entities that will send in packets
- designed to have the worst possible effect. This assumption
- will lead to suitable protective design, although the most
- serious problems in the Internet have been caused by
- unenvisaged mechanisms triggered by low-probability events;
-
-
-
-Internet Engineering Task Force [Page 12]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- mere human malice would never have taken so devious a course!
-
- Adaptability to change must be designed into all levels of
- Internet host software. As a simple example, consider a
- protocol specification that contains an enumeration of values
- for a particular header field -- e.g., a type field, a port
- number, or an error code; this enumeration must be assumed to
- be incomplete. Thus, if a protocol specification defines four
- possible error codes, the software must not break when a fifth
- code shows up. An undefined code might be logged (see below),
- but it must not cause a failure.
-
- The second part of the principle is almost as important:
- software on other hosts may contain deficiencies that make it
- unwise to exploit legal but obscure protocol features. It is
- unwise to stray far from the obvious and simple, lest untoward
- effects result elsewhere. A corollary of this is "watch out
- for misbehaving hosts"; host software should be prepared, not
- just to survive other misbehaving hosts, but also to cooperate
- to limit the amount of disruption such hosts can cause to the
- shared communication facility.
-
- 1.2.3 Error Logging
-
- The Internet includes a great variety of host and gateway
- systems, each implementing many protocols and protocol layers,
- and some of these contain bugs and mis-features in their
- Internet protocol software. As a result of complexity,
- diversity, and distribution of function, the diagnosis of
- Internet problems is often very difficult.
-
- Problem diagnosis will be aided if host implementations include
- a carefully designed facility for logging erroneous or
- "strange" protocol events. It is important to include as much
- diagnostic information as possible when an error is logged. In
- particular, it is often useful to record the header(s) of a
- packet that caused an error. However, care must be taken to
- ensure that error logging does not consume prohibitive amounts
- of resources or otherwise interfere with the operation of the
- host.
-
- There is a tendency for abnormal but harmless protocol events
- to overflow error logging files; this can be avoided by using a
- "circular" log, or by enabling logging only while diagnosing a
- known failure. It may be useful to filter and count duplicate
- successive messages. One strategy that seems to work well is:
- (1) always count abnormalities and make such counts accessible
- through the management protocol (see [INTRO:1]); and (2) allow
-
-
-
-Internet Engineering Task Force [Page 13]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- the logging of a great variety of events to be selectively
- enabled. For example, it might useful to be able to "log
- everything" or to "log everything for host X".
-
- Note that different managements may have differing policies
- about the amount of error logging that they want normally
- enabled in a host. Some will say, "if it doesn't hurt me, I
- don't want to know about it", while others will want to take a
- more watchful and aggressive attitude about detecting and
- removing protocol abnormalities.
-
- 1.2.4 Configuration
-
- It would be ideal if a host implementation of the Internet
- protocol suite could be entirely self-configuring. This would
- allow the whole suite to be implemented in ROM or cast into
- silicon, it would simplify diskless workstations, and it would
- be an immense boon to harried LAN administrators as well as
- system vendors. We have not reached this ideal; in fact, we
- are not even close.
-
- At many points in this document, you will find a requirement
- that a parameter be a configurable option. There are several
- different reasons behind such requirements. In a few cases,
- there is current uncertainty or disagreement about the best
- value, and it may be necessary to update the recommended value
- in the future. In other cases, the value really depends on
- external factors -- e.g., the size of the host and the
- distribution of its communication load, or the speeds and
- topology of nearby networks -- and self-tuning algorithms are
- unavailable and may be insufficient. In some cases,
- configurability is needed because of administrative
- requirements.
-
- Finally, some configuration options are required to communicate
- with obsolete or incorrect implementations of the protocols,
- distributed without sources, that unfortunately persist in many
- parts of the Internet. To make correct systems coexist with
- these faulty systems, administrators often have to "mis-
- configure" the correct systems. This problem will correct
- itself gradually as the faulty systems are retired, but it
- cannot be ignored by vendors.
-
- When we say that a parameter must be configurable, we do not
- intend to require that its value be explicitly read from a
- configuration file at every boot time. We recommend that
- implementors set up a default for each parameter, so a
- configuration file is only necessary to override those defaults
-
-
-
-Internet Engineering Task Force [Page 14]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- that are inappropriate in a particular installation. Thus, the
- configurability requirement is an assurance that it will be
- POSSIBLE to override the default when necessary, even in a
- binary-only or ROM-based product.
-
- This document requires a particular value for such defaults in
- some cases. The choice of default is a sensitive issue when
- the configuration item controls the accommodation to existing
- faulty systems. If the Internet is to converge successfully to
- complete interoperability, the default values built into
- implementations must implement the official protocol, not
- "mis-configurations" to accommodate faulty implementations.
- Although marketing considerations have led some vendors to
- choose mis-configuration defaults, we urge vendors to choose
- defaults that will conform to the standard.
-
- Finally, we note that a vendor needs to provide adequate
- documentation on all configuration parameters, their limits and
- effects.
-
-
- 1.3 Reading this Document
-
- 1.3.1 Organization
-
- Protocol layering, which is generally used as an organizing
- principle in implementing network software, has also been used
- to organize this document. In describing the rules, we assume
- that an implementation does strictly mirror the layering of the
- protocols. Thus, the following three major sections specify
- the requirements for the link layer, the internet layer, and
- the transport layer, respectively. A companion RFC [INTRO:1]
- covers application level software. This layerist organization
- was chosen for simplicity and clarity.
-
- However, strict layering is an imperfect model, both for the
- protocol suite and for recommended implementation approaches.
- Protocols in different layers interact in complex and sometimes
- subtle ways, and particular functions often involve multiple
- layers. There are many design choices in an implementation,
- many of which involve creative "breaking" of strict layering.
- Every implementor is urged to read references [INTRO:7] and
- [INTRO:8].
-
- This document describes the conceptual service interface
- between layers using a functional ("procedure call") notation,
- like that used in the TCP specification [TCP:1]. A host
- implementation must support the logical information flow
-
-
-
-Internet Engineering Task Force [Page 15]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- implied by these calls, but need not literally implement the
- calls themselves. For example, many implementations reflect
- the coupling between the transport layer and the IP layer by
- giving them shared access to common data structures. These
- data structures, rather than explicit procedure calls, are then
- the agency for passing much of the information that is
- required.
-
- In general, each major section of this document is organized
- into the following subsections:
-
- (1) Introduction
-
- (2) Protocol Walk-Through -- considers the protocol
- specification documents section-by-section, correcting
- errors, stating requirements that may be ambiguous or
- ill-defined, and providing further clarification or
- explanation.
-
- (3) Specific Issues -- discusses protocol design and
- implementation issues that were not included in the walk-
- through.
-
- (4) Interfaces -- discusses the service interface to the next
- higher layer.
-
- (5) Summary -- contains a summary of the requirements of the
- section.
-
-
- Under many of the individual topics in this document, there is
- parenthetical material labeled "DISCUSSION" or
- "IMPLEMENTATION". This material is intended to give
- clarification and explanation of the preceding requirements
- text. It also includes some suggestions on possible future
- directions or developments. The implementation material
- contains suggested approaches that an implementor may want to
- consider.
-
- The summary sections are intended to be guides and indexes to
- the text, but are necessarily cryptic and incomplete. The
- summaries should never be used or referenced separately from
- the complete RFC.
-
- 1.3.2 Requirements
-
- In this document, the words that are used to define the
- significance of each particular requirement are capitalized.
-
-
-
-Internet Engineering Task Force [Page 16]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- These words are:
-
- * "MUST"
-
- This word or the adjective "REQUIRED" means that the item
- is an absolute requirement of the specification.
-
- * "SHOULD"
-
- This word or the adjective "RECOMMENDED" means that there
- may exist valid reasons in particular circumstances to
- ignore this item, but the full implications should be
- understood and the case carefully weighed before choosing
- a different course.
-
- * "MAY"
-
- This word or the adjective "OPTIONAL" means that this item
- is truly optional. One vendor may choose to include the
- item because a particular marketplace requires it or
- because it enhances the product, for example; another
- vendor may omit the same item.
-
-
- An implementation is not compliant if it fails to satisfy one
- or more of the MUST requirements for the protocols it
- implements. An implementation that satisfies all the MUST and
- all the SHOULD requirements for its protocols is said to be
- "unconditionally compliant"; one that satisfies all the MUST
- requirements but not all the SHOULD requirements for its
- protocols is said to be "conditionally compliant".
-
- 1.3.3 Terminology
-
- This document uses the following technical terms:
-
- Segment
- A segment is the unit of end-to-end transmission in the
- TCP protocol. A segment consists of a TCP header followed
- by application data. A segment is transmitted by
- encapsulation inside an IP datagram.
-
- Message
- In this description of the lower-layer protocols, a
- message is the unit of transmission in a transport layer
- protocol. In particular, a TCP segment is a message. A
- message consists of a transport protocol header followed
- by application protocol data. To be transmitted end-to-
-
-
-
-Internet Engineering Task Force [Page 17]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- end through the Internet, a message must be encapsulated
- inside a datagram.
-
- IP Datagram
- An IP datagram is the unit of end-to-end transmission in
- the IP protocol. An IP datagram consists of an IP header
- followed by transport layer data, i.e., of an IP header
- followed by a message.
-
- In the description of the internet layer (Section 3), the
- unqualified term "datagram" should be understood to refer
- to an IP datagram.
-
- Packet
- A packet is the unit of data passed across the interface
- between the internet layer and the link layer. It
- includes an IP header and data. A packet may be a
- complete IP datagram or a fragment of an IP datagram.
-
- Frame
- A frame is the unit of transmission in a link layer
- protocol, and consists of a link-layer header followed by
- a packet.
-
- Connected Network
- A network to which a host is interfaced is often known as
- the "local network" or the "subnetwork" relative to that
- host. However, these terms can cause confusion, and
- therefore we use the term "connected network" in this
- document.
-
- Multihomed
- A host is said to be multihomed if it has multiple IP
- addresses. For a discussion of multihoming, see Section
- 3.3.4 below.
-
- Physical network interface
- This is a physical interface to a connected network and
- has a (possibly unique) link-layer address. Multiple
- physical network interfaces on a single host may share the
- same link-layer address, but the address must be unique
- for different hosts on the same physical network.
-
- Logical [network] interface
- We define a logical [network] interface to be a logical
- path, distinguished by a unique IP address, to a connected
- network. See Section 3.3.4.
-
-
-
-
-Internet Engineering Task Force [Page 18]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- Specific-destination address
- This is the effective destination address of a datagram,
- even if it is broadcast or multicast; see Section 3.2.1.3.
-
- Path
- At a given moment, all the IP datagrams from a particular
- source host to a particular destination host will
- typically traverse the same sequence of gateways. We use
- the term "path" for this sequence. Note that a path is
- uni-directional; it is not unusual to have different paths
- in the two directions between a given host pair.
-
- MTU
- The maximum transmission unit, i.e., the size of the
- largest packet that can be transmitted.
-
-
- The terms frame, packet, datagram, message, and segment are
- illustrated by the following schematic diagrams:
-
- A. Transmission on connected network:
- _______________________________________________
- | LL hdr | IP hdr | (data) |
- |________|________|_____________________________|
-
- <---------- Frame ----------------------------->
- <----------Packet -------------------->
-
-
- B. Before IP fragmentation or after IP reassembly:
- ______________________________________
- | IP hdr | transport| Application Data |
- |________|____hdr___|__________________|
-
- <-------- Datagram ------------------>
- <-------- Message ----------->
- or, for TCP:
- ______________________________________
- | IP hdr | TCP hdr | Application Data |
- |________|__________|__________________|
-
- <-------- Datagram ------------------>
- <-------- Segment ----------->
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 19]
-
-
-
-
-RFC1122 INTRODUCTION October 1989
-
-
- 1.4 Acknowledgments
-
- This document incorporates contributions and comments from a large
- group of Internet protocol experts, including representatives of
- university and research labs, vendors, and government agencies.
- It was assembled primarily by the Host Requirements Working Group
- of the Internet Engineering Task Force (IETF).
-
- The Editor would especially like to acknowledge the tireless
- dedication of the following people, who attended many long
- meetings and generated 3 million bytes of electronic mail over the
- past 18 months in pursuit of this document: Philip Almquist, Dave
- Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
- Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
- John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
- Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
- (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
-
- In addition, the following people made major contributions to the
- effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
- (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
- Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
- John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
- Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
- (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
- Technology), and Mike StJohns (DCA). The following also made
- significant contributions to particular areas: Eric Allman
- (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
- (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
- (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
- (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
- Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
- (Toronto).
-
- We are grateful to all, including any contributors who may have
- been inadvertently omitted from this list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 20]
-
-
-
-
-RFC1122 LINK LAYER October 1989
-
-
-2. LINK LAYER
-
- 2.1 INTRODUCTION
-
- All Internet systems, both hosts and gateways, have the same
- requirements for link layer protocols. These requirements are
- given in Chapter 3 of "Requirements for Internet Gateways"
- [INTRO:2], augmented with the material in this section.
-
- 2.2 PROTOCOL WALK-THROUGH
-
- None.
-
- 2.3 SPECIFIC ISSUES
-
- 2.3.1 Trailer Protocol Negotiation
-
- The trailer protocol [LINK:1] for link-layer encapsulation MAY
- be used, but only when it has been verified that both systems
- (host or gateway) involved in the link-layer communication
- implement trailers. If the system does not dynamically
- negotiate use of the trailer protocol on a per-destination
- basis, the default configuration MUST disable the protocol.
-
- DISCUSSION:
- The trailer protocol is a link-layer encapsulation
- technique that rearranges the data contents of packets
- sent on the physical network. In some cases, trailers
- improve the throughput of higher layer protocols by
- reducing the amount of data copying within the operating
- system. Higher layer protocols are unaware of trailer
- use, but both the sending and receiving host MUST
- understand the protocol if it is used.
-
- Improper use of trailers can result in very confusing
- symptoms. Only packets with specific size attributes are
- encapsulated using trailers, and typically only a small
- fraction of the packets being exchanged have these
- attributes. Thus, if a system using trailers exchanges
- packets with a system that does not, some packets
- disappear into a black hole while others are delivered
- successfully.
-
- IMPLEMENTATION:
- On an Ethernet, packets encapsulated with trailers use a
- distinct Ethernet type [LINK:1], and trailer negotiation
- is performed at the time that ARP is used to discover the
- link-layer address of a destination system.
-
-
-
-Internet Engineering Task Force [Page 21]
-
-
-
-
-RFC1122 LINK LAYER October 1989
-
-
- Specifically, the ARP exchange is completed in the usual
- manner using the normal IP protocol type, but a host that
- wants to speak trailers will send an additional "trailer
- ARP reply" packet, i.e., an ARP reply that specifies the
- trailer encapsulation protocol type but otherwise has the
- format of a normal ARP reply. If a host configured to use
- trailers receives a trailer ARP reply message from a
- remote machine, it can add that machine to the list of
- machines that understand trailers, e.g., by marking the
- corresponding entry in the ARP cache.
-
- Hosts wishing to receive trailer encapsulations send
- trailer ARP replies whenever they complete exchanges of
- normal ARP messages for IP. Thus, a host that received an
- ARP request for its IP protocol address would send a
- trailer ARP reply in addition to the normal IP ARP reply;
- a host that sent the IP ARP request would send a trailer
- ARP reply when it received the corresponding IP ARP reply.
- In this way, either the requesting or responding host in
- an IP ARP exchange may request that it receive trailer
- encapsulations.
-
- This scheme, using extra trailer ARP reply packets rather
- than sending an ARP request for the trailer protocol type,
- was designed to avoid a continuous exchange of ARP packets
- with a misbehaving host that, contrary to any
- specification or common sense, responded to an ARP reply
- for trailers with another ARP reply for IP. This problem
- is avoided by sending a trailer ARP reply in response to
- an IP ARP reply only when the IP ARP reply answers an
- outstanding request; this is true when the hardware
- address for the host is still unknown when the IP ARP
- reply is received. A trailer ARP reply may always be sent
- along with an IP ARP reply responding to an IP ARP
- request.
-
- 2.3.2 Address Resolution Protocol -- ARP
-
- 2.3.2.1 ARP Cache Validation
-
- An implementation of the Address Resolution Protocol (ARP)
- [LINK:2] MUST provide a mechanism to flush out-of-date cache
- entries. If this mechanism involves a timeout, it SHOULD be
- possible to configure the timeout value.
-
- A mechanism to prevent ARP flooding (repeatedly sending an
- ARP Request for the same IP address, at a high rate) MUST be
- included. The recommended maximum rate is 1 per second per
-
-
-
-Internet Engineering Task Force [Page 22]
-
-
-
-
-RFC1122 LINK LAYER October 1989
-
-
- destination.
-
- DISCUSSION:
- The ARP specification [LINK:2] suggests but does not
- require a timeout mechanism to invalidate cache entries
- when hosts change their Ethernet addresses. The
- prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
- has significantly increased the likelihood that cache
- entries in hosts will become invalid, and therefore
- some ARP-cache invalidation mechanism is now required
- for hosts. Even in the absence of proxy ARP, a long-
- period cache timeout is useful in order to
- automatically correct any bad ARP data that might have
- been cached.
-
- IMPLEMENTATION:
- Four mechanisms have been used, sometimes in
- combination, to flush out-of-date cache entries.
-
- (1) Timeout -- Periodically time out cache entries,
- even if they are in use. Note that this timeout
- should be restarted when the cache entry is
- "refreshed" (by observing the source fields,
- regardless of target address, of an ARP broadcast
- from the system in question). For proxy ARP
- situations, the timeout needs to be on the order
- of a minute.
-
- (2) Unicast Poll -- Actively poll the remote host by
- periodically sending a point-to-point ARP Request
- to it, and delete the entry if no ARP Reply is
- received from N successive polls. Again, the
- timeout should be on the order of a minute, and
- typically N is 2.
-
- (3) Link-Layer Advice -- If the link-layer driver
- detects a delivery problem, flush the
- corresponding ARP cache entry.
-
- (4) Higher-layer Advice -- Provide a call from the
- Internet layer to the link layer to indicate a
- delivery problem. The effect of this call would
- be to invalidate the corresponding cache entry.
- This call would be analogous to the
- "ADVISE_DELIVPROB()" call from the transport layer
- to the Internet layer (see Section 3.4), and in
- fact the ADVISE_DELIVPROB routine might in turn
- call the link-layer advice routine to invalidate
-
-
-
-Internet Engineering Task Force [Page 23]
-
-
-
-
-RFC1122 LINK LAYER October 1989
-
-
- the ARP cache entry.
-
- Approaches (1) and (2) involve ARP cache timeouts on
- the order of a minute or less. In the absence of proxy
- ARP, a timeout this short could create noticeable
- overhead traffic on a very large Ethernet. Therefore,
- it may be necessary to configure a host to lengthen the
- ARP cache timeout.
-
- 2.3.2.2 ARP Packet Queue
-
- The link layer SHOULD save (rather than discard) at least
- one (the latest) packet of each set of packets destined to
- the same unresolved IP address, and transmit the saved
- packet when the address has been resolved.
-
- DISCUSSION:
- Failure to follow this recommendation causes the first
- packet of every exchange to be lost. Although higher-
- layer protocols can generally cope with packet loss by
- retransmission, packet loss does impact performance.
- For example, loss of a TCP open request causes the
- initial round-trip time estimate to be inflated. UDP-
- based applications such as the Domain Name System are
- more seriously affected.
-
- 2.3.3 Ethernet and IEEE 802 Encapsulation
-
- The IP encapsulation for Ethernets is described in RFC-894
- [LINK:3], while RFC-1042 [LINK:4] describes the IP
- encapsulation for IEEE 802 networks. RFC-1042 elaborates and
- replaces the discussion in Section 3.4 of [INTRO:2].
-
- Every Internet host connected to a 10Mbps Ethernet cable:
-
- o MUST be able to send and receive packets using RFC-894
- encapsulation;
-
- o SHOULD be able to receive RFC-1042 packets, intermixed
- with RFC-894 packets; and
-
- o MAY be able to send packets using RFC-1042 encapsulation.
-
-
- An Internet host that implements sending both the RFC-894 and
- the RFC-1042 encapsulations MUST provide a configuration switch
- to select which is sent, and this switch MUST default to RFC-
- 894.
-
-
-
-Internet Engineering Task Force [Page 24]
-
-
-
-
-RFC1122 LINK LAYER October 1989
-
-
- Note that the standard IP encapsulation in RFC-1042 does not
- use the protocol id value (K1=6) that IEEE reserved for IP;
- instead, it uses a value (K1=170) that implies an extension
- (the "SNAP") which can be used to hold the Ether-Type field.
- An Internet system MUST NOT send 802 packets using K1=6.
-
- Address translation from Internet addresses to link-layer
- addresses on Ethernet and IEEE 802 networks MUST be managed by
- the Address Resolution Protocol (ARP).
-
- The MTU for an Ethernet is 1500 and for 802.3 is 1492.
-
- DISCUSSION:
- The IEEE 802.3 specification provides for operation over a
- 10Mbps Ethernet cable, in which case Ethernet and IEEE
- 802.3 frames can be physically intermixed. A receiver can
- distinguish Ethernet and 802.3 frames by the value of the
- 802.3 Length field; this two-octet field coincides in the
- header with the Ether-Type field of an Ethernet frame. In
- particular, the 802.3 Length field must be less than or
- equal to 1500, while all valid Ether-Type values are
- greater than 1500.
-
- Another compatibility problem arises with link-layer
- broadcasts. A broadcast sent with one framing will not be
- seen by hosts that can receive only the other framing.
-
- The provisions of this section were designed to provide
- direct interoperation between 894-capable and 1042-capable
- systems on the same cable, to the maximum extent possible.
- It is intended to support the present situation where
- 894-only systems predominate, while providing an easy
- transition to a possible future in which 1042-capable
- systems become common.
-
- Note that 894-only systems cannot interoperate directly
- with 1042-only systems. If the two system types are set
- up as two different logical networks on the same cable,
- they can communicate only through an IP gateway.
- Furthermore, it is not useful or even possible for a
- dual-format host to discover automatically which format to
- send, because of the problem of link-layer broadcasts.
-
- 2.4 LINK/INTERNET LAYER INTERFACE
-
- The packet receive interface between the IP layer and the link
- layer MUST include a flag to indicate whether the incoming packet
- was addressed to a link-layer broadcast address.
-
-
-
-Internet Engineering Task Force [Page 25]
-
-
-
-
-RFC1122 LINK LAYER October 1989
-
-
- DISCUSSION
- Although the IP layer does not generally know link layer
- addresses (since every different network medium typically has
- a different address format), the broadcast address on a
- broadcast-capable medium is an important special case. See
- Section 3.2.2, especially the DISCUSSION concerning broadcast
- storms.
-
- The packet send interface between the IP and link layers MUST
- include the 5-bit TOS field (see Section 3.2.1.6).
-
- The link layer MUST NOT report a Destination Unreachable error to
- IP solely because there is no ARP cache entry for a destination.
-
- 2.5 LINK LAYER REQUIREMENTS SUMMARY
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION| | | |T|T|e
---------------------------------------------------|-------|-|-|-|-|-|--
- | | | | | | |
-Trailer encapsulation |2.3.1 | | |x| | |
-Send Trailers by default without negotiation |2.3.1 | | | | |x|
-ARP |2.3.2 | | | | | |
- Flush out-of-date ARP cache entries |2.3.2.1|x| | | | |
- Prevent ARP floods |2.3.2.1|x| | | | |
- Cache timeout configurable |2.3.2.1| |x| | | |
- Save at least one (latest) unresolved pkt |2.3.2.2| |x| | | |
-Ethernet and IEEE 802 Encapsulation |2.3.3 | | | | | |
- Host able to: |2.3.3 | | | | | |
- Send & receive RFC-894 encapsulation |2.3.3 |x| | | | |
- Receive RFC-1042 encapsulation |2.3.3 | |x| | | |
- Send RFC-1042 encapsulation |2.3.3 | | |x| | |
- Then config. sw. to select, RFC-894 dflt |2.3.3 |x| | | | |
- Send K1=6 encapsulation |2.3.3 | | | | |x|
- Use ARP on Ethernet and IEEE 802 nets |2.3.3 |x| | | | |
-Link layer report b'casts to IP layer |2.4 |x| | | | |
-IP layer pass TOS to link layer |2.4 |x| | | | |
-No ARP cache entry treated as Dest. Unreach. |2.4 | | | | |x|
-
-
-
-
-
-Internet Engineering Task Force [Page 26]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
-3. INTERNET LAYER PROTOCOLS
-
- 3.1 INTRODUCTION
-
- The Robustness Principle: "Be liberal in what you accept, and
- conservative in what you send" is particularly important in the
- Internet layer, where one misbehaving host can deny Internet
- service to many other hosts.
-
- The protocol standards used in the Internet layer are:
-
- o RFC-791 [IP:1] defines the IP protocol and gives an
- introduction to the architecture of the Internet.
-
- o RFC-792 [IP:2] defines ICMP, which provides routing,
- diagnostic and error functionality for IP. Although ICMP
- messages are encapsulated within IP datagrams, ICMP
- processing is considered to be (and is typically implemented
- as) part of the IP layer. See Section 3.2.2.
-
- o RFC-950 [IP:3] defines the mandatory subnet extension to the
- addressing architecture.
-
- o RFC-1112 [IP:4] defines the Internet Group Management
- Protocol IGMP, as part of a recommended extension to hosts
- and to the host-gateway interface to support Internet-wide
- multicasting at the IP level. See Section 3.2.3.
-
- The target of an IP multicast may be an arbitrary group of
- Internet hosts. IP multicasting is designed as a natural
- extension of the link-layer multicasting facilities of some
- networks, and it provides a standard means for local access
- to such link-layer multicasting facilities.
-
- Other important references are listed in Section 5 of this
- document.
-
- The Internet layer of host software MUST implement both IP and
- ICMP. See Section 3.3.7 for the requirements on support of IGMP.
-
- The host IP layer has two basic functions: (1) choose the "next
- hop" gateway or host for outgoing IP datagrams and (2) reassemble
- incoming IP datagrams. The IP layer may also (3) implement
- intentional fragmentation of outgoing datagrams. Finally, the IP
- layer must (4) provide diagnostic and error functionality. We
- expect that IP layer functions may increase somewhat in the
- future, as further Internet control and management facilities are
- developed.
-
-
-
-Internet Engineering Task Force [Page 27]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- For normal datagrams, the processing is straightforward. For
- incoming datagrams, the IP layer:
-
- (1) verifies that the datagram is correctly formatted;
-
- (2) verifies that it is destined to the local host;
-
- (3) processes options;
-
- (4) reassembles the datagram if necessary; and
-
- (5) passes the encapsulated message to the appropriate
- transport-layer protocol module.
-
- For outgoing datagrams, the IP layer:
-
- (1) sets any fields not set by the transport layer;
-
- (2) selects the correct first hop on the connected network (a
- process called "routing");
-
- (3) fragments the datagram if necessary and if intentional
- fragmentation is implemented (see Section 3.3.3); and
-
- (4) passes the packet(s) to the appropriate link-layer driver.
-
-
- A host is said to be multihomed if it has multiple IP addresses.
- Multihoming introduces considerable confusion and complexity into
- the protocol suite, and it is an area in which the Internet
- architecture falls seriously short of solving all problems. There
- are two distinct problem areas in multihoming:
-
- (1) Local multihoming -- the host itself is multihomed; or
-
- (2) Remote multihoming -- the local host needs to communicate
- with a remote multihomed host.
-
- At present, remote multihoming MUST be handled at the application
- layer, as discussed in the companion RFC [INTRO:1]. A host MAY
- support local multihoming, which is discussed in this document,
- and in particular in Section 3.3.4.
-
- Any host that forwards datagrams generated by another host is
- acting as a gateway and MUST also meet the specifications laid out
- in the gateway requirements RFC [INTRO:2]. An Internet host that
- includes embedded gateway code MUST have a configuration switch to
- disable the gateway function, and this switch MUST default to the
-
-
-
-Internet Engineering Task Force [Page 28]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- non-gateway mode. In this mode, a datagram arriving through one
- interface will not be forwarded to another host or gateway (unless
- it is source-routed), regardless of whether the host is single-
- homed or multihomed. The host software MUST NOT automatically
- move into gateway mode if the host has more than one interface, as
- the operator of the machine may neither want to provide that
- service nor be competent to do so.
-
- In the following, the action specified in certain cases is to
- "silently discard" a received datagram. This means that the
- datagram will be discarded without further processing and that the
- host will not send any ICMP error message (see Section 3.2.2) as a
- result. However, for diagnosis of problems a host SHOULD provide
- the capability of logging the error (see Section 1.2.3), including
- the contents of the silently-discarded datagram, and SHOULD record
- the event in a statistics counter.
-
- DISCUSSION:
- Silent discard of erroneous datagrams is generally intended
- to prevent "broadcast storms".
-
- 3.2 PROTOCOL WALK-THROUGH
-
- 3.2.1 Internet Protocol -- IP
-
- 3.2.1.1 Version Number: RFC-791 Section 3.1
-
- A datagram whose version number is not 4 MUST be silently
- discarded.
-
- 3.2.1.2 Checksum: RFC-791 Section 3.1
-
- A host MUST verify the IP header checksum on every received
- datagram and silently discard every datagram that has a bad
- checksum.
-
- 3.2.1.3 Addressing: RFC-791 Section 3.2
-
- There are now five classes of IP addresses: Class A through
- Class E. Class D addresses are used for IP multicasting
- [IP:4], while Class E addresses are reserved for
- experimental use.
-
- A multicast (Class D) address is a 28-bit logical address
- that stands for a group of hosts, and may be either
- permanent or transient. Permanent multicast addresses are
- allocated by the Internet Assigned Number Authority
- [INTRO:6], while transient addresses may be allocated
-
-
-
-Internet Engineering Task Force [Page 29]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- dynamically to transient groups. Group membership is
- determined dynamically using IGMP [IP:4].
-
- We now summarize the important special cases for Class A, B,
- and C IP addresses, using the following notation for an IP
- address:
-
- { <Network-number>, <Host-number> }
-
- or
- { <Network-number>, <Subnet-number>, <Host-number> }
-
- and the notation "-1" for a field that contains all 1 bits.
- This notation is not intended to imply that the 1-bits in an
- address mask need be contiguous.
-
- (a) { 0, 0 }
-
- This host on this network. MUST NOT be sent, except as
- a source address as part of an initialization procedure
- by which the host learns its own IP address.
-
- See also Section 3.3.6 for a non-standard use of {0,0}.
-
- (b) { 0, <Host-number> }
-
- Specified host on this network. It MUST NOT be sent,
- except as a source address as part of an initialization
- procedure by which the host learns its full IP address.
-
- (c) { -1, -1 }
-
- Limited broadcast. It MUST NOT be used as a source
- address.
-
- A datagram with this destination address will be
- received by every host on the connected physical
- network but will not be forwarded outside that network.
-
- (d) { <Network-number>, -1 }
-
- Directed broadcast to the specified network. It MUST
- NOT be used as a source address.
-
- (e) { <Network-number>, <Subnet-number>, -1 }
-
- Directed broadcast to the specified subnet. It MUST
- NOT be used as a source address.
-
-
-
-Internet Engineering Task Force [Page 30]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- (f) { <Network-number>, -1, -1 }
-
- Directed broadcast to all subnets of the specified
- subnetted network. It MUST NOT be used as a source
- address.
-
- (g) { 127, <any> }
-
- Internal host loopback address. Addresses of this form
- MUST NOT appear outside a host.
-
- The <Network-number> is administratively assigned so that
- its value will be unique in the entire world.
-
- IP addresses are not permitted to have the value 0 or -1 for
- any of the <Host-number>, <Network-number>, or <Subnet-
- number> fields (except in the special cases listed above).
- This implies that each of these fields will be at least two
- bits long.
-
- For further discussion of broadcast addresses, see Section
- 3.3.6.
-
- A host MUST support the subnet extensions to IP [IP:3]. As
- a result, there will be an address mask of the form:
- {-1, -1, 0} associated with each of the host's local IP
- addresses; see Sections 3.2.2.9 and 3.3.1.1.
-
- When a host sends any datagram, the IP source address MUST
- be one of its own IP addresses (but not a broadcast or
- multicast address).
-
- A host MUST silently discard an incoming datagram that is
- not destined for the host. An incoming datagram is destined
- for the host if the datagram's destination address field is:
-
- (1) (one of) the host's IP address(es); or
-
- (2) an IP broadcast address valid for the connected
- network; or
-
- (3) the address for a multicast group of which the host is
- a member on the incoming physical interface.
-
- For most purposes, a datagram addressed to a broadcast or
- multicast destination is processed as if it had been
- addressed to one of the host's IP addresses; we use the term
- "specific-destination address" for the equivalent local IP
-
-
-
-Internet Engineering Task Force [Page 31]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- address of the host. The specific-destination address is
- defined to be the destination address in the IP header
- unless the header contains a broadcast or multicast address,
- in which case the specific-destination is an IP address
- assigned to the physical interface on which the datagram
- arrived.
-
- A host MUST silently discard an incoming datagram containing
- an IP source address that is invalid by the rules of this
- section. This validation could be done in either the IP
- layer or by each protocol in the transport layer.
-
- DISCUSSION:
- A mis-addressed datagram might be caused by a link-
- layer broadcast of a unicast datagram or by a gateway
- or host that is confused or mis-configured.
-
- An architectural goal for Internet hosts was to allow
- IP addresses to be featureless 32-bit numbers, avoiding
- algorithms that required a knowledge of the IP address
- format. Otherwise, any future change in the format or
- interpretation of IP addresses will require host
- software changes. However, validation of broadcast and
- multicast addresses violates this goal; a few other
- violations are described elsewhere in this document.
-
- Implementers should be aware that applications
- depending upon the all-subnets directed broadcast
- address (f) may be unusable on some networks. All-
- subnets broadcast is not widely implemented in vendor
- gateways at present, and even when it is implemented, a
- particular network administration may disable it in the
- gateway configuration.
-
- 3.2.1.4 Fragmentation and Reassembly: RFC-791 Section 3.2
-
- The Internet model requires that every host support
- reassembly. See Sections 3.3.2 and 3.3.3 for the
- requirements on fragmentation and reassembly.
-
- 3.2.1.5 Identification: RFC-791 Section 3.2
-
- When sending an identical copy of an earlier datagram, a
- host MAY optionally retain the same Identification field in
- the copy.
-
-
-
-
-
-
-Internet Engineering Task Force [Page 32]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- DISCUSSION:
- Some Internet protocol experts have maintained that
- when a host sends an identical copy of an earlier
- datagram, the new copy should contain the same
- Identification value as the original. There are two
- suggested advantages: (1) if the datagrams are
- fragmented and some of the fragments are lost, the
- receiver may be able to reconstruct a complete datagram
- from fragments of the original and the copies; (2) a
- congested gateway might use the IP Identification field
- (and Fragment Offset) to discard duplicate datagrams
- from the queue.
-
- However, the observed patterns of datagram loss in the
- Internet do not favor the probability of retransmitted
- fragments filling reassembly gaps, while other
- mechanisms (e.g., TCP repacketizing upon
- retransmission) tend to prevent retransmission of an
- identical datagram [IP:9]. Therefore, we believe that
- retransmitting the same Identification field is not
- useful. Also, a connectionless transport protocol like
- UDP would require the cooperation of the application
- programs to retain the same Identification value in
- identical datagrams.
-
- 3.2.1.6 Type-of-Service: RFC-791 Section 3.2
-
- The "Type-of-Service" byte in the IP header is divided into
- two sections: the Precedence field (high-order 3 bits), and
- a field that is customarily called "Type-of-Service" or
- "TOS" (low-order 5 bits). In this document, all references
- to "TOS" or the "TOS field" refer to the low-order 5 bits
- only.
-
- The Precedence field is intended for Department of Defense
- applications of the Internet protocols. The use of non-zero
- values in this field is outside the scope of this document
- and the IP standard specification. Vendors should consult
- the Defense Communication Agency (DCA) for guidance on the
- IP Precedence field and its implications for other protocol
- layers. However, vendors should note that the use of
- precedence will most likely require that its value be passed
- between protocol layers in just the same way as the TOS
- field is passed.
-
- The IP layer MUST provide a means for the transport layer to
- set the TOS field of every datagram that is sent; the
- default is all zero bits. The IP layer SHOULD pass received
-
-
-
-Internet Engineering Task Force [Page 33]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- TOS values up to the transport layer.
-
- The particular link-layer mappings of TOS contained in RFC-
- 795 SHOULD NOT be implemented.
-
- DISCUSSION:
- While the TOS field has been little used in the past,
- it is expected to play an increasing role in the near
- future. The TOS field is expected to be used to
- control two aspects of gateway operations: routing and
- queueing algorithms. See Section 2 of [INTRO:1] for
- the requirements on application programs to specify TOS
- values.
-
- The TOS field may also be mapped into link-layer
- service selectors. This has been applied to provide
- effective sharing of serial lines by different classes
- of TCP traffic, for example. However, the mappings
- suggested in RFC-795 for networks that were included in
- the Internet as of 1981 are now obsolete.
-
- 3.2.1.7 Time-to-Live: RFC-791 Section 3.2
-
- A host MUST NOT send a datagram with a Time-to-Live (TTL)
- value of zero.
-
- A host MUST NOT discard a datagram just because it was
- received with TTL less than 2.
-
- The IP layer MUST provide a means for the transport layer to
- set the TTL field of every datagram that is sent. When a
- fixed TTL value is used, it MUST be configurable. The
- current suggested value will be published in the "Assigned
- Numbers" RFC.
-
- DISCUSSION:
- The TTL field has two functions: limit the lifetime of
- TCP segments (see RFC-793 [TCP:1], p. 28), and
- terminate Internet routing loops. Although TTL is a
- time in seconds, it also has some attributes of a hop-
- count, since each gateway is required to reduce the TTL
- field by at least one.
-
- The intent is that TTL expiration will cause a datagram
- to be discarded by a gateway but not by the destination
- host; however, hosts that act as gateways by forwarding
- datagrams must follow the gateway rules for TTL.
-
-
-
-
-Internet Engineering Task Force [Page 34]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- A higher-layer protocol may want to set the TTL in
- order to implement an "expanding scope" search for some
- Internet resource. This is used by some diagnostic
- tools, and is expected to be useful for locating the
- "nearest" server of a given class using IP
- multicasting, for example. A particular transport
- protocol may also want to specify its own TTL bound on
- maximum datagram lifetime.
-
- A fixed value must be at least big enough for the
- Internet "diameter," i.e., the longest possible path.
- A reasonable value is about twice the diameter, to
- allow for continued Internet growth.
-
- 3.2.1.8 Options: RFC-791 Section 3.2
-
- There MUST be a means for the transport layer to specify IP
- options to be included in transmitted IP datagrams (see
- Section 3.4).
-
- All IP options (except NOP or END-OF-LIST) received in
- datagrams MUST be passed to the transport layer (or to ICMP
- processing when the datagram is an ICMP message). The IP
- and transport layer MUST each interpret those IP options
- that they understand and silently ignore the others.
-
- Later sections of this document discuss specific IP option
- support required by each of ICMP, TCP, and UDP.
-
- DISCUSSION:
- Passing all received IP options to the transport layer
- is a deliberate "violation of strict layering" that is
- designed to ease the introduction of new transport-
- relevant IP options in the future. Each layer must
- pick out any options that are relevant to its own
- processing and ignore the rest. For this purpose,
- every IP option except NOP and END-OF-LIST will include
- a specification of its own length.
-
- This document does not define the order in which a
- receiver must process multiple options in the same IP
- header. Hosts sending multiple options must be aware
- that this introduces an ambiguity in the meaning of
- certain options when combined with a source-route
- option.
-
- IMPLEMENTATION:
- The IP layer must not crash as the result of an option
-
-
-
-Internet Engineering Task Force [Page 35]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- length that is outside the possible range. For
- example, erroneous option lengths have been observed to
- put some IP implementations into infinite loops.
-
- Here are the requirements for specific IP options:
-
-
- (a) Security Option
-
- Some environments require the Security option in every
- datagram; such a requirement is outside the scope of
- this document and the IP standard specification. Note,
- however, that the security options described in RFC-791
- and RFC-1038 are obsolete. For DoD applications,
- vendors should consult [IP:8] for guidance.
-
-
- (b) Stream Identifier Option
-
- This option is obsolete; it SHOULD NOT be sent, and it
- MUST be silently ignored if received.
-
-
- (c) Source Route Options
-
- A host MUST support originating a source route and MUST
- be able to act as the final destination of a source
- route.
-
- If host receives a datagram containing a completed
- source route (i.e., the pointer points beyond the last
- field), the datagram has reached its final destination;
- the option as received (the recorded route) MUST be
- passed up to the transport layer (or to ICMP message
- processing). This recorded route will be reversed and
- used to form a return source route for reply datagrams
- (see discussion of IP Options in Section 4). When a
- return source route is built, it MUST be correctly
- formed even if the recorded route included the source
- host (see case (B) in the discussion below).
-
- An IP header containing more than one Source Route
- option MUST NOT be sent; the effect on routing of
- multiple Source Route options is implementation-
- specific.
-
- Section 3.3.5 presents the rules for a host acting as
- an intermediate hop in a source route, i.e., forwarding
-
-
-
-Internet Engineering Task Force [Page 36]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- a source-routed datagram.
-
- DISCUSSION:
- If a source-routed datagram is fragmented, each
- fragment will contain a copy of the source route.
- Since the processing of IP options (including a
- source route) must precede reassembly, the
- original datagram will not be reassembled until
- the final destination is reached.
-
- Suppose a source routed datagram is to be routed
- from host S to host D via gateways G1, G2, ... Gn.
- There was an ambiguity in the specification over
- whether the source route option in a datagram sent
- out by S should be (A) or (B):
-
- (A): {>>G2, G3, ... Gn, D} <--- CORRECT
-
- (B): {S, >>G2, G3, ... Gn, D} <---- WRONG
-
- (where >> represents the pointer). If (A) is
- sent, the datagram received at D will contain the
- option: {G1, G2, ... Gn >>}, with S and D as the
- IP source and destination addresses. If (B) were
- sent, the datagram received at D would again
- contain S and D as the same IP source and
- destination addresses, but the option would be:
- {S, G1, ...Gn >>}; i.e., the originating host
- would be the first hop in the route.
-
-
- (d) Record Route Option
-
- Implementation of originating and processing the Record
- Route option is OPTIONAL.
-
-
- (e) Timestamp Option
-
- Implementation of originating and processing the
- Timestamp option is OPTIONAL. If it is implemented,
- the following rules apply:
-
- o The originating host MUST record a timestamp in a
- Timestamp option whose Internet address fields are
- not pre-specified or whose first pre-specified
- address is the host's interface address.
-
-
-
-
-Internet Engineering Task Force [Page 37]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- o The destination host MUST (if possible) add the
- current timestamp to a Timestamp option before
- passing the option to the transport layer or to
- ICMP for processing.
-
- o A timestamp value MUST follow the rules given in
- Section 3.2.2.8 for the ICMP Timestamp message.
-
-
- 3.2.2 Internet Control Message Protocol -- ICMP
-
- ICMP messages are grouped into two classes.
-
- *
- ICMP error messages:
-
- Destination Unreachable (see Section 3.2.2.1)
- Redirect (see Section 3.2.2.2)
- Source Quench (see Section 3.2.2.3)
- Time Exceeded (see Section 3.2.2.4)
- Parameter Problem (see Section 3.2.2.5)
-
-
- *
- ICMP query messages:
-
- Echo (see Section 3.2.2.6)
- Information (see Section 3.2.2.7)
- Timestamp (see Section 3.2.2.8)
- Address Mask (see Section 3.2.2.9)
-
-
- If an ICMP message of unknown type is received, it MUST be
- silently discarded.
-
- Every ICMP error message includes the Internet header and at
- least the first 8 data octets of the datagram that triggered
- the error; more than 8 octets MAY be sent; this header and data
- MUST be unchanged from the received datagram.
-
- In those cases where the Internet layer is required to pass an
- ICMP error message to the transport layer, the IP protocol
- number MUST be extracted from the original header and used to
- select the appropriate transport protocol entity to handle the
- error.
-
- An ICMP error message SHOULD be sent with normal (i.e., zero)
- TOS bits.
-
-
-
-Internet Engineering Task Force [Page 38]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- An ICMP error message MUST NOT be sent as the result of
- receiving:
-
- * an ICMP error message, or
-
- * a datagram destined to an IP broadcast or IP multicast
- address, or
-
- * a datagram sent as a link-layer broadcast, or
-
- * a non-initial fragment, or
-
- * a datagram whose source address does not define a single
- host -- e.g., a zero address, a loopback address, a
- broadcast address, a multicast address, or a Class E
- address.
-
- NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
- ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
-
- DISCUSSION:
- These rules will prevent the "broadcast storms" that have
- resulted from hosts returning ICMP error messages in
- response to broadcast datagrams. For example, a broadcast
- UDP segment to a non-existent port could trigger a flood
- of ICMP Destination Unreachable datagrams from all
- machines that do not have a client for that destination
- port. On a large Ethernet, the resulting collisions can
- render the network useless for a second or more.
-
- Every datagram that is broadcast on the connected network
- should have a valid IP broadcast address as its IP
- destination (see Section 3.3.6). However, some hosts
- violate this rule. To be certain to detect broadcast
- datagrams, therefore, hosts are required to check for a
- link-layer broadcast as well as an IP-layer broadcast
- address.
-
- IMPLEMENTATION:
- This requires that the link layer inform the IP layer when
- a link-layer broadcast datagram has been received; see
- Section 2.4.
-
- 3.2.2.1 Destination Unreachable: RFC-792
-
- The following additional codes are hereby defined:
-
- 6 = destination network unknown
-
-
-
-Internet Engineering Task Force [Page 39]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- 7 = destination host unknown
-
- 8 = source host isolated
-
- 9 = communication with destination network
- administratively prohibited
-
- 10 = communication with destination host
- administratively prohibited
-
- 11 = network unreachable for type of service
-
- 12 = host unreachable for type of service
-
- A host SHOULD generate Destination Unreachable messages with
- code:
-
- 2 (Protocol Unreachable), when the designated transport
- protocol is not supported; or
-
- 3 (Port Unreachable), when the designated transport
- protocol (e.g., UDP) is unable to demultiplex the
- datagram but has no protocol mechanism to inform the
- sender.
-
- A Destination Unreachable message that is received MUST be
- reported to the transport layer. The transport layer SHOULD
- use the information appropriately; for example, see Sections
- 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
- that has its own mechanism for notifying the sender that a
- port is unreachable (e.g., TCP, which sends RST segments)
- MUST nevertheless accept an ICMP Port Unreachable for the
- same purpose.
-
- A Destination Unreachable message that is received with code
- 0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
- routing transient and MUST therefore be interpreted as only
- a hint, not proof, that the specified destination is
- unreachable [IP:11]. For example, it MUST NOT be used as
- proof of a dead gateway (see Section 3.3.1).
-
- 3.2.2.2 Redirect: RFC-792
-
- A host SHOULD NOT send an ICMP Redirect message; Redirects
- are to be sent only by gateways.
-
- A host receiving a Redirect message MUST update its routing
- information accordingly. Every host MUST be prepared to
-
-
-
-Internet Engineering Task Force [Page 40]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- accept both Host and Network Redirects and to process them
- as described in Section 3.3.1.2 below.
-
- A Redirect message SHOULD be silently discarded if the new
- gateway address it specifies is not on the same connected
- (sub-) net through which the Redirect arrived [INTRO:2,
- Appendix A], or if the source of the Redirect is not the
- current first-hop gateway for the specified destination (see
- Section 3.3.1).
-
- 3.2.2.3 Source Quench: RFC-792
-
- A host MAY send a Source Quench message if it is
- approaching, or has reached, the point at which it is forced
- to discard incoming datagrams due to a shortage of
- reassembly buffers or other resources. See Section 2.2.3 of
- [INTRO:2] for suggestions on when to send Source Quench.
-
- If a Source Quench message is received, the IP layer MUST
- report it to the transport layer (or ICMP processing). In
- general, the transport or application layer SHOULD implement
- a mechanism to respond to Source Quench for any protocol
- that can send a sequence of datagrams to the same
- destination and which can reasonably be expected to maintain
- enough state information to make this feasible. See Section
- 4 for the handling of Source Quench by TCP and UDP.
-
- DISCUSSION:
- A Source Quench may be generated by the target host or
- by some gateway in the path of a datagram. The host
- receiving a Source Quench should throttle itself back
- for a period of time, then gradually increase the
- transmission rate again. The mechanism to respond to
- Source Quench may be in the transport layer (for
- connection-oriented protocols like TCP) or in the
- application layer (for protocols that are built on top
- of UDP).
-
- A mechanism has been proposed [IP:14] to make the IP
- layer respond directly to Source Quench by controlling
- the rate at which datagrams are sent, however, this
- proposal is currently experimental and not currently
- recommended.
-
- 3.2.2.4 Time Exceeded: RFC-792
-
- An incoming Time Exceeded message MUST be passed to the
- transport layer.
-
-
-
-Internet Engineering Task Force [Page 41]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- DISCUSSION:
- A gateway will send a Time Exceeded Code 0 (In Transit)
- message when it discards a datagram due to an expired
- TTL field. This indicates either a gateway routing
- loop or too small an initial TTL value.
-
- A host may receive a Time Exceeded Code 1 (Reassembly
- Timeout) message from a destination host that has timed
- out and discarded an incomplete datagram; see Section
- 3.3.2 below. In the future, receipt of this message
- might be part of some "MTU discovery" procedure, to
- discover the maximum datagram size that can be sent on
- the path without fragmentation.
-
- 3.2.2.5 Parameter Problem: RFC-792
-
- A host SHOULD generate Parameter Problem messages. An
- incoming Parameter Problem message MUST be passed to the
- transport layer, and it MAY be reported to the user.
-
- DISCUSSION:
- The ICMP Parameter Problem message is sent to the
- source host for any problem not specifically covered by
- another ICMP message. Receipt of a Parameter Problem
- message generally indicates some local or remote
- implementation error.
-
- A new variant on the Parameter Problem message is hereby
- defined:
- Code 1 = required option is missing.
-
- DISCUSSION:
- This variant is currently in use in the military
- community for a missing security option.
-
- 3.2.2.6 Echo Request/Reply: RFC-792
-
- Every host MUST implement an ICMP Echo server function that
- receives Echo Requests and sends corresponding Echo Replies.
- A host SHOULD also implement an application-layer interface
- for sending an Echo Request and receiving an Echo Reply, for
- diagnostic purposes.
-
- An ICMP Echo Request destined to an IP broadcast or IP
- multicast address MAY be silently discarded.
-
-
-
-
-
-
-Internet Engineering Task Force [Page 42]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- DISCUSSION:
- This neutral provision results from a passionate debate
- between those who feel that ICMP Echo to a broadcast
- address provides a valuable diagnostic capability and
- those who feel that misuse of this feature can too
- easily create packet storms.
-
- The IP source address in an ICMP Echo Reply MUST be the same
- as the specific-destination address (defined in Section
- 3.2.1.3) of the corresponding ICMP Echo Request message.
-
- Data received in an ICMP Echo Request MUST be entirely
- included in the resulting Echo Reply. However, if sending
- the Echo Reply requires intentional fragmentation that is
- not implemented, the datagram MUST be truncated to maximum
- transmission size (see Section 3.3.3) and sent.
-
- Echo Reply messages MUST be passed to the ICMP user
- interface, unless the corresponding Echo Request originated
- in the IP layer.
-
- If a Record Route and/or Time Stamp option is received in an
- ICMP Echo Request, this option (these options) SHOULD be
- updated to include the current host and included in the IP
- header of the Echo Reply message, without "truncation".
- Thus, the recorded route will be for the entire round trip.
-
- If a Source Route option is received in an ICMP Echo
- Request, the return route MUST be reversed and used as a
- Source Route option for the Echo Reply message.
-
- 3.2.2.7 Information Request/Reply: RFC-792
-
- A host SHOULD NOT implement these messages.
-
- DISCUSSION:
- The Information Request/Reply pair was intended to
- support self-configuring systems such as diskless
- workstations, to allow them to discover their IP
- network numbers at boot time. However, the RARP and
- BOOTP protocols provide better mechanisms for a host to
- discover its own IP address.
-
- 3.2.2.8 Timestamp and Timestamp Reply: RFC-792
-
- A host MAY implement Timestamp and Timestamp Reply. If they
- are implemented, the following rules MUST be followed.
-
-
-
-
-Internet Engineering Task Force [Page 43]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- o The ICMP Timestamp server function returns a Timestamp
- Reply to every Timestamp message that is received. If
- this function is implemented, it SHOULD be designed for
- minimum variability in delay (e.g., implemented in the
- kernel to avoid delay in scheduling a user process).
-
- The following cases for Timestamp are to be handled
- according to the corresponding rules for ICMP Echo:
-
- o An ICMP Timestamp Request message to an IP broadcast or
- IP multicast address MAY be silently discarded.
-
- o The IP source address in an ICMP Timestamp Reply MUST
- be the same as the specific-destination address of the
- corresponding Timestamp Request message.
-
- o If a Source-route option is received in an ICMP Echo
- Request, the return route MUST be reversed and used as
- a Source Route option for the Timestamp Reply message.
-
- o If a Record Route and/or Timestamp option is received
- in a Timestamp Request, this (these) option(s) SHOULD
- be updated to include the current host and included in
- the IP header of the Timestamp Reply message.
-
- o Incoming Timestamp Reply messages MUST be passed up to
- the ICMP user interface.
-
- The preferred form for a timestamp value (the "standard
- value") is in units of milliseconds since midnight Universal
- Time. However, it may be difficult to provide this value
- with millisecond resolution. For example, many systems use
- clocks that update only at line frequency, 50 or 60 times
- per second. Therefore, some latitude is allowed in a
- "standard value":
-
- (a) A "standard value" MUST be updated at least 15 times
- per second (i.e., at most the six low-order bits of the
- value may be undefined).
-
- (b) The accuracy of a "standard value" MUST approximate
- that of operator-set CPU clocks, i.e., correct within a
- few minutes.
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 44]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- 3.2.2.9 Address Mask Request/Reply: RFC-950
-
- A host MUST support the first, and MAY implement all three,
- of the following methods for determining the address mask(s)
- corresponding to its IP address(es):
-
- (1) static configuration information;
-
- (2) obtaining the address mask(s) dynamically as a side-
- effect of the system initialization process (see
- [INTRO:1]); and
-
- (3) sending ICMP Address Mask Request(s) and receiving ICMP
- Address Mask Reply(s).
-
- The choice of method to be used in a particular host MUST be
- configurable.
-
- When method (3), the use of Address Mask messages, is
- enabled, then:
-
- (a) When it initializes, the host MUST broadcast an Address
- Mask Request message on the connected network
- corresponding to the IP address. It MUST retransmit
- this message a small number of times if it does not
- receive an immediate Address Mask Reply.
-
- (b) Until it has received an Address Mask Reply, the host
- SHOULD assume a mask appropriate for the address class
- of the IP address, i.e., assume that the connected
- network is not subnetted.
-
- (c) The first Address Mask Reply message received MUST be
- used to set the address mask corresponding to the
- particular local IP address. This is true even if the
- first Address Mask Reply message is "unsolicited", in
- which case it will have been broadcast and may arrive
- after the host has ceased to retransmit Address Mask
- Requests. Once the mask has been set by an Address
- Mask Reply, later Address Mask Reply messages MUST be
- (silently) ignored.
-
- Conversely, if Address Mask messages are disabled, then no
- ICMP Address Mask Requests will be sent, and any ICMP
- Address Mask Replies received for that local IP address MUST
- be (silently) ignored.
-
- A host SHOULD make some reasonableness check on any address
-
-
-
-Internet Engineering Task Force [Page 45]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- mask it installs; see IMPLEMENTATION section below.
-
- A system MUST NOT send an Address Mask Reply unless it is an
- authoritative agent for address masks. An authoritative
- agent may be a host or a gateway, but it MUST be explicitly
- configured as a address mask agent. Receiving an address
- mask via an Address Mask Reply does not give the receiver
- authority and MUST NOT be used as the basis for issuing
- Address Mask Replies.
-
- With a statically configured address mask, there SHOULD be
- an additional configuration flag that determines whether the
- host is to act as an authoritative agent for this mask,
- i.e., whether it will answer Address Mask Request messages
- using this mask.
-
- If it is configured as an agent, the host MUST broadcast an
- Address Mask Reply for the mask on the appropriate interface
- when it initializes.
-
- See "System Initialization" in [INTRO:1] for more
- information about the use of Address Mask Request/Reply
- messages.
-
- DISCUSSION
- Hosts that casually send Address Mask Replies with
- invalid address masks have often been a serious
- nuisance. To prevent this, Address Mask Replies ought
- to be sent only by authoritative agents that have been
- selected by explicit administrative action.
-
- When an authoritative agent receives an Address Mask
- Request message, it will send a unicast Address Mask
- Reply to the source IP address. If the network part of
- this address is zero (see (a) and (b) in 3.2.1.3), the
- Reply will be broadcast.
-
- Getting no reply to its Address Mask Request messages,
- a host will assume there is no agent and use an
- unsubnetted mask, but the agent may be only temporarily
- unreachable. An agent will broadcast an unsolicited
- Address Mask Reply whenever it initializes, in order to
- update the masks of all hosts that have initialized in
- the meantime.
-
- IMPLEMENTATION:
- The following reasonableness check on an address mask
- is suggested: the mask is not all 1 bits, and it is
-
-
-
-Internet Engineering Task Force [Page 46]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- either zero or else the 8 highest-order bits are on.
-
- 3.2.3 Internet Group Management Protocol IGMP
-
- IGMP [IP:4] is a protocol used between hosts and gateways on a
- single network to establish hosts' membership in particular
- multicast groups. The gateways use this information, in
- conjunction with a multicast routing protocol, to support IP
- multicasting across the Internet.
-
- At this time, implementation of IGMP is OPTIONAL; see Section
- 3.3.7 for more information. Without IGMP, a host can still
- participate in multicasting local to its connected networks.
-
- 3.3 SPECIFIC ISSUES
-
- 3.3.1 Routing Outbound Datagrams
-
- The IP layer chooses the correct next hop for each datagram it
- sends. If the destination is on a connected network, the
- datagram is sent directly to the destination host; otherwise,
- it has to be routed to a gateway on a connected network.
-
- 3.3.1.1 Local/Remote Decision
-
- To decide if the destination is on a connected network, the
- following algorithm MUST be used [see IP:3]:
-
- (a) The address mask (particular to a local IP address for
- a multihomed host) is a 32-bit mask that selects the
- network number and subnet number fields of the
- corresponding IP address.
-
- (b) If the IP destination address bits extracted by the
- address mask match the IP source address bits extracted
- by the same mask, then the destination is on the
- corresponding connected network, and the datagram is to
- be transmitted directly to the destination host.
-
- (c) If not, then the destination is accessible only through
- a gateway. Selection of a gateway is described below
- (3.3.1.2).
-
- A special-case destination address is handled as follows:
-
- * For a limited broadcast or a multicast address, simply
- pass the datagram to the link layer for the appropriate
- interface.
-
-
-
-Internet Engineering Task Force [Page 47]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- * For a (network or subnet) directed broadcast, the
- datagram can use the standard routing algorithms.
-
- The host IP layer MUST operate correctly in a minimal
- network environment, and in particular, when there are no
- gateways. For example, if the IP layer of a host insists on
- finding at least one gateway to initialize, the host will be
- unable to operate on a single isolated broadcast net.
-
- 3.3.1.2 Gateway Selection
-
- To efficiently route a series of datagrams to the same
- destination, the source host MUST keep a "route cache" of
- mappings to next-hop gateways. A host uses the following
- basic algorithm on this cache to route a datagram; this
- algorithm is designed to put the primary routing burden on
- the gateways [IP:11].
-
- (a) If the route cache contains no information for a
- particular destination, the host chooses a "default"
- gateway and sends the datagram to it. It also builds a
- corresponding Route Cache entry.
-
- (b) If that gateway is not the best next hop to the
- destination, the gateway will forward the datagram to
- the best next-hop gateway and return an ICMP Redirect
- message to the source host.
-
- (c) When it receives a Redirect, the host updates the
- next-hop gateway in the appropriate route cache entry,
- so later datagrams to the same destination will go
- directly to the best gateway.
-
- Since the subnet mask appropriate to the destination address
- is generally not known, a Network Redirect message SHOULD be
- treated identically to a Host Redirect message; i.e., the
- cache entry for the destination host (only) would be updated
- (or created, if an entry for that host did not exist) for
- the new gateway.
-
- DISCUSSION:
- This recommendation is to protect against gateways that
- erroneously send Network Redirects for a subnetted
- network, in violation of the gateway requirements
- [INTRO:2].
-
- When there is no route cache entry for the destination host
- address (and the destination is not on the connected
-
-
-
-Internet Engineering Task Force [Page 48]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- network), the IP layer MUST pick a gateway from its list of
- "default" gateways. The IP layer MUST support multiple
- default gateways.
-
- As an extra feature, a host IP layer MAY implement a table
- of "static routes". Each such static route MAY include a
- flag specifying whether it may be overridden by ICMP
- Redirects.
-
- DISCUSSION:
- A host generally needs to know at least one default
- gateway to get started. This information can be
- obtained from a configuration file or else from the
- host startup sequence, e.g., the BOOTP protocol (see
- [INTRO:1]).
-
- It has been suggested that a host can augment its list
- of default gateways by recording any new gateways it
- learns about. For example, it can record every gateway
- to which it is ever redirected. Such a feature, while
- possibly useful in some circumstances, may cause
- problems in other cases (e.g., gateways are not all
- equal), and it is not recommended.
-
- A static route is typically a particular preset mapping
- from destination host or network into a particular
- next-hop gateway; it might also depend on the Type-of-
- Service (see next section). Static routes would be set
- up by system administrators to override the normal
- automatic routing mechanism, to handle exceptional
- situations. However, any static routing information is
- a potential source of failure as configurations change
- or equipment fails.
-
- 3.3.1.3 Route Cache
-
- Each route cache entry needs to include the following
- fields:
-
- (1) Local IP address (for a multihomed host)
-
- (2) Destination IP address
-
- (3) Type(s)-of-Service
-
- (4) Next-hop gateway IP address
-
- Field (2) MAY be the full IP address of the destination
-
-
-
-Internet Engineering Task Force [Page 49]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- host, or only the destination network number. Field (3),
- the TOS, SHOULD be included.
-
- See Section 3.3.4.2 for a discussion of the implications of
- multihoming for the lookup procedure in this cache.
-
- DISCUSSION:
- Including the Type-of-Service field in the route cache
- and considering it in the host route algorithm will
- provide the necessary mechanism for the future when
- Type-of-Service routing is commonly used in the
- Internet. See Section 3.2.1.6.
-
- Each route cache entry defines the endpoints of an
- Internet path. Although the connecting path may change
- dynamically in an arbitrary way, the transmission
- characteristics of the path tend to remain
- approximately constant over a time period longer than a
- single typical host-host transport connection.
- Therefore, a route cache entry is a natural place to
- cache data on the properties of the path. Examples of
- such properties might be the maximum unfragmented
- datagram size (see Section 3.3.3), or the average
- round-trip delay measured by a transport protocol.
- This data will generally be both gathered and used by a
- higher layer protocol, e.g., by TCP, or by an
- application using UDP. Experiments are currently in
- progress on caching path properties in this manner.
-
- There is no consensus on whether the route cache should
- be keyed on destination host addresses alone, or allow
- both host and network addresses. Those who favor the
- use of only host addresses argue that:
-
- (1) As required in Section 3.3.1.2, Redirect messages
- will generally result in entries keyed on
- destination host addresses; the simplest and most
- general scheme would be to use host addresses
- always.
-
- (2) The IP layer may not always know the address mask
- for a network address in a complex subnetted
- environment.
-
- (3) The use of only host addresses allows the
- destination address to be used as a pure 32-bit
- number, which may allow the Internet architecture
- to be more easily extended in the future without
-
-
-
-Internet Engineering Task Force [Page 50]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- any change to the hosts.
-
- The opposing view is that allowing a mixture of
- destination hosts and networks in the route cache:
-
- (1) Saves memory space.
-
- (2) Leads to a simpler data structure, easily
- combining the cache with the tables of default and
- static routes (see below).
-
- (3) Provides a more useful place to cache path
- properties, as discussed earlier.
-
-
- IMPLEMENTATION:
- The cache needs to be large enough to include entries
- for the maximum number of destination hosts that may be
- in use at one time.
-
- A route cache entry may also include control
- information used to choose an entry for replacement.
- This might take the form of a "recently used" bit, a
- use count, or a last-used timestamp, for example. It
- is recommended that it include the time of last
- modification of the entry, for diagnostic purposes.
-
- An implementation may wish to reduce the overhead of
- scanning the route cache for every datagram to be
- transmitted. This may be accomplished with a hash
- table to speed the lookup, or by giving a connection-
- oriented transport protocol a "hint" or temporary
- handle on the appropriate cache entry, to be passed to
- the IP layer with each subsequent datagram.
-
- Although we have described the route cache, the lists
- of default gateways, and a table of static routes as
- conceptually distinct, in practice they may be combined
- into a single "routing table" data structure.
-
- 3.3.1.4 Dead Gateway Detection
-
- The IP layer MUST be able to detect the failure of a "next-
- hop" gateway that is listed in its route cache and to choose
- an alternate gateway (see Section 3.3.1.5).
-
- Dead gateway detection is covered in some detail in RFC-816
- [IP:11]. Experience to date has not produced a complete
-
-
-
-Internet Engineering Task Force [Page 51]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- algorithm which is totally satisfactory, though it has
- identified several forbidden paths and promising techniques.
-
- * A particular gateway SHOULD NOT be used indefinitely in
- the absence of positive indications that it is
- functioning.
-
- * Active probes such as "pinging" (i.e., using an ICMP
- Echo Request/Reply exchange) are expensive and scale
- poorly. In particular, hosts MUST NOT actively check
- the status of a first-hop gateway by simply pinging the
- gateway continuously.
-
- * Even when it is the only effective way to verify a
- gateway's status, pinging MUST be used only when
- traffic is being sent to the gateway and when there is
- no other positive indication to suggest that the
- gateway is functioning.
-
- * To avoid pinging, the layers above and/or below the
- Internet layer SHOULD be able to give "advice" on the
- status of route cache entries when either positive
- (gateway OK) or negative (gateway dead) information is
- available.
-
-
- DISCUSSION:
- If an implementation does not include an adequate
- mechanism for detecting a dead gateway and re-routing,
- a gateway failure may cause datagrams to apparently
- vanish into a "black hole". This failure can be
- extremely confusing for users and difficult for network
- personnel to debug.
-
- The dead-gateway detection mechanism must not cause
- unacceptable load on the host, on connected networks,
- or on first-hop gateway(s). The exact constraints on
- the timeliness of dead gateway detection and on
- acceptable load may vary somewhat depending on the
- nature of the host's mission, but a host generally
- needs to detect a failed first-hop gateway quickly
- enough that transport-layer connections will not break
- before an alternate gateway can be selected.
-
- Passing advice from other layers of the protocol stack
- complicates the interfaces between the layers, but it
- is the preferred approach to dead gateway detection.
- Advice can come from almost any part of the IP/TCP
-
-
-
-Internet Engineering Task Force [Page 52]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- architecture, but it is expected to come primarily from
- the transport and link layers. Here are some possible
- sources for gateway advice:
-
- o TCP or any connection-oriented transport protocol
- should be able to give negative advice, e.g.,
- triggered by excessive retransmissions.
-
- o TCP may give positive advice when (new) data is
- acknowledged. Even though the route may be
- asymmetric, an ACK for new data proves that the
- acknowleged data must have been transmitted
- successfully.
-
- o An ICMP Redirect message from a particular gateway
- should be used as positive advice about that
- gateway.
-
- o Link-layer information that reliably detects and
- reports host failures (e.g., ARPANET Destination
- Dead messages) should be used as negative advice.
-
- o Failure to ARP or to re-validate ARP mappings may
- be used as negative advice for the corresponding
- IP address.
-
- o Packets arriving from a particular link-layer
- address are evidence that the system at this
- address is alive. However, turning this
- information into advice about gateways requires
- mapping the link-layer address into an IP address,
- and then checking that IP address against the
- gateways pointed to by the route cache. This is
- probably prohibitively inefficient.
-
- Note that positive advice that is given for every
- datagram received may cause unacceptable overhead in
- the implementation.
-
- While advice might be passed using required arguments
- in all interfaces to the IP layer, some transport and
- application layer protocols cannot deduce the correct
- advice. These interfaces must therefore allow a
- neutral value for advice, since either always-positive
- or always-negative advice leads to incorrect behavior.
-
- There is another technique for dead gateway detection
- that has been commonly used but is not recommended.
-
-
-
-Internet Engineering Task Force [Page 53]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- This technique depends upon the host passively
- receiving ("wiretapping") the Interior Gateway Protocol
- (IGP) datagrams that the gateways are broadcasting to
- each other. This approach has the drawback that a host
- needs to recognize all the interior gateway protocols
- that gateways may use (see [INTRO:2]). In addition, it
- only works on a broadcast network.
-
- At present, pinging (i.e., using ICMP Echo messages) is
- the mechanism for gateway probing when absolutely
- required. A successful ping guarantees that the
- addressed interface and its associated machine are up,
- but it does not guarantee that the machine is a gateway
- as opposed to a host. The normal inference is that if
- a Redirect or other evidence indicates that a machine
- was a gateway, successful pings will indicate that the
- machine is still up and hence still a gateway.
- However, since a host silently discards packets that a
- gateway would forward or redirect, this assumption
- could sometimes fail. To avoid this problem, a new
- ICMP message under development will ask "are you a
- gateway?"
-
- IMPLEMENTATION:
- The following specific algorithm has been suggested:
-
- o Associate a "reroute timer" with each gateway
- pointed to by the route cache. Initialize the
- timer to a value Tr, which must be small enough to
- allow detection of a dead gateway before transport
- connections time out.
-
- o Positive advice would reset the reroute timer to
- Tr. Negative advice would reduce or zero the
- reroute timer.
-
- o Whenever the IP layer used a particular gateway to
- route a datagram, it would check the corresponding
- reroute timer. If the timer had expired (reached
- zero), the IP layer would send a ping to the
- gateway, followed immediately by the datagram.
-
- o The ping (ICMP Echo) would be sent again if
- necessary, up to N times. If no ping reply was
- received in N tries, the gateway would be assumed
- to have failed, and a new first-hop gateway would
- be chosen for all cache entries pointing to the
- failed gateway.
-
-
-
-Internet Engineering Task Force [Page 54]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- Note that the size of Tr is inversely related to the
- amount of advice available. Tr should be large enough
- to insure that:
-
- * Any pinging will be at a low level (e.g., <10%) of
- all packets sent to a gateway from the host, AND
-
- * pinging is infrequent (e.g., every 3 minutes)
-
- Since the recommended algorithm is concerned with the
- gateways pointed to by route cache entries, rather than
- the cache entries themselves, a two level data
- structure (perhaps coordinated with ARP or similar
- caches) may be desirable for implementing a route
- cache.
-
- 3.3.1.5 New Gateway Selection
-
- If the failed gateway is not the current default, the IP
- layer can immediately switch to a default gateway. If it is
- the current default that failed, the IP layer MUST select a
- different default gateway (assuming more than one default is
- known) for the failed route and for establishing new routes.
-
- DISCUSSION:
- When a gateway does fail, the other gateways on the
- connected network will learn of the failure through
- some inter-gateway routing protocol. However, this
- will not happen instantaneously, since gateway routing
- protocols typically have a settling time of 30-60
- seconds. If the host switches to an alternative
- gateway before the gateways have agreed on the failure,
- the new target gateway will probably forward the
- datagram to the failed gateway and send a Redirect back
- to the host pointing to the failed gateway (!). The
- result is likely to be a rapid oscillation in the
- contents of the host's route cache during the gateway
- settling period. It has been proposed that the dead-
- gateway logic should include some hysteresis mechanism
- to prevent such oscillations. However, experience has
- not shown any harm from such oscillations, since
- service cannot be restored to the host until the
- gateways' routing information does settle down.
-
- IMPLEMENTATION:
- One implementation technique for choosing a new default
- gateway is to simply round-robin among the default
- gateways in the host's list. Another is to rank the
-
-
-
-Internet Engineering Task Force [Page 55]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- gateways in priority order, and when the current
- default gateway is not the highest priority one, to
- "ping" the higher-priority gateways slowly to detect
- when they return to service. This pinging can be at a
- very low rate, e.g., 0.005 per second.
-
- 3.3.1.6 Initialization
-
- The following information MUST be configurable:
-
- (1) IP address(es).
-
- (2) Address mask(s).
-
- (3) A list of default gateways, with a preference level.
-
- A manual method of entering this configuration data MUST be
- provided. In addition, a variety of methods can be used to
- determine this information dynamically; see the section on
- "Host Initialization" in [INTRO:1].
-
- DISCUSSION:
- Some host implementations use "wiretapping" of gateway
- protocols on a broadcast network to learn what gateways
- exist. A standard method for default gateway discovery
- is under development.
-
- 3.3.2 Reassembly
-
- The IP layer MUST implement reassembly of IP datagrams.
-
- We designate the largest datagram size that can be reassembled
- by EMTU_R ("Effective MTU to receive"); this is sometimes
- called the "reassembly buffer size". EMTU_R MUST be greater
- than or equal to 576, SHOULD be either configurable or
- indefinite, and SHOULD be greater than or equal to the MTU of
- the connected network(s).
-
- DISCUSSION:
- A fixed EMTU_R limit should not be built into the code
- because some application layer protocols require EMTU_R
- values larger than 576.
-
- IMPLEMENTATION:
- An implementation may use a contiguous reassembly buffer
- for each datagram, or it may use a more complex data
- structure that places no definite limit on the reassembled
- datagram size; in the latter case, EMTU_R is said to be
-
-
-
-Internet Engineering Task Force [Page 56]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- "indefinite".
-
- Logically, reassembly is performed by simply copying each
- fragment into the packet buffer at the proper offset.
- Note that fragments may overlap if successive
- retransmissions use different packetizing but the same
- reassembly Id.
-
- The tricky part of reassembly is the bookkeeping to
- determine when all bytes of the datagram have been
- reassembled. We recommend Clark's algorithm [IP:10] that
- requires no additional data space for the bookkeeping.
- However, note that, contrary to [IP:10], the first
- fragment header needs to be saved for inclusion in a
- possible ICMP Time Exceeded (Reassembly Timeout) message.
-
- There MUST be a mechanism by which the transport layer can
- learn MMS_R, the maximum message size that can be received and
- reassembled in an IP datagram (see GET_MAXSIZES calls in
- Section 3.4). If EMTU_R is not indefinite, then the value of
- MMS_R is given by:
-
- MMS_R = EMTU_R - 20
-
- since 20 is the minimum size of an IP header.
-
- There MUST be a reassembly timeout. The reassembly timeout
- value SHOULD be a fixed value, not set from the remaining TTL.
- It is recommended that the value lie between 60 seconds and 120
- seconds. If this timeout expires, the partially-reassembled
- datagram MUST be discarded and an ICMP Time Exceeded message
- sent to the source host (if fragment zero has been received).
-
- DISCUSSION:
- The IP specification says that the reassembly timeout
- should be the remaining TTL from the IP header, but this
- does not work well because gateways generally treat TTL as
- a simple hop count rather than an elapsed time. If the
- reassembly timeout is too small, datagrams will be
- discarded unnecessarily, and communication may fail. The
- timeout needs to be at least as large as the typical
- maximum delay across the Internet. A realistic minimum
- reassembly timeout would be 60 seconds.
-
- It has been suggested that a cache might be kept of
- round-trip times measured by transport protocols for
- various destinations, and that these values might be used
- to dynamically determine a reasonable reassembly timeout
-
-
-
-Internet Engineering Task Force [Page 57]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- value. Further investigation of this approach is
- required.
-
- If the reassembly timeout is set too high, buffer
- resources in the receiving host will be tied up too long,
- and the MSL (Maximum Segment Lifetime) [TCP:1] will be
- larger than necessary. The MSL controls the maximum rate
- at which fragmented datagrams can be sent using distinct
- values of the 16-bit Ident field; a larger MSL lowers the
- maximum rate. The TCP specification [TCP:1] arbitrarily
- assumes a value of 2 minutes for MSL. This sets an upper
- limit on a reasonable reassembly timeout value.
-
- 3.3.3 Fragmentation
-
- Optionally, the IP layer MAY implement a mechanism to fragment
- outgoing datagrams intentionally.
-
- We designate by EMTU_S ("Effective MTU for sending") the
- maximum IP datagram size that may be sent, for a particular
- combination of IP source and destination addresses and perhaps
- TOS.
-
- A host MUST implement a mechanism to allow the transport layer
- to learn MMS_S, the maximum transport-layer message size that
- may be sent for a given {source, destination, TOS} triplet (see
- GET_MAXSIZES call in Section 3.4). If no local fragmentation
- is performed, the value of MMS_S will be:
-
- MMS_S = EMTU_S - <IP header size>
-
- and EMTU_S must be less than or equal to the MTU of the network
- interface corresponding to the source address of the datagram.
- Note that <IP header size> in this equation will be 20, unless
- the IP reserves space to insert IP options for its own purposes
- in addition to any options inserted by the transport layer.
-
- A host that does not implement local fragmentation MUST ensure
- that the transport layer (for TCP) or the application layer
- (for UDP) obtains MMS_S from the IP layer and does not send a
- datagram exceeding MMS_S in size.
-
- It is generally desirable to avoid local fragmentation and to
- choose EMTU_S low enough to avoid fragmentation in any gateway
- along the path. In the absence of actual knowledge of the
- minimum MTU along the path, the IP layer SHOULD use
- EMTU_S <= 576 whenever the destination address is not on a
- connected network, and otherwise use the connected network's
-
-
-
-Internet Engineering Task Force [Page 58]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- MTU.
-
- The MTU of each physical interface MUST be configurable.
-
- A host IP layer implementation MAY have a configuration flag
- "All-Subnets-MTU", indicating that the MTU of the connected
- network is to be used for destinations on different subnets
- within the same network, but not for other networks. Thus,
- this flag causes the network class mask, rather than the subnet
- address mask, to be used to choose an EMTU_S. For a multihomed
- host, an "All-Subnets-MTU" flag is needed for each network
- interface.
-
- DISCUSSION:
- Picking the correct datagram size to use when sending data
- is a complex topic [IP:9].
-
- (a) In general, no host is required to accept an IP
- datagram larger than 576 bytes (including header and
- data), so a host must not send a larger datagram
- without explicit knowledge or prior arrangement with
- the destination host. Thus, MMS_S is only an upper
- bound on the datagram size that a transport protocol
- may send; even when MMS_S exceeds 556, the transport
- layer must limit its messages to 556 bytes in the
- absence of other knowledge about the destination
- host.
-
- (b) Some transport protocols (e.g., TCP) provide a way to
- explicitly inform the sender about the largest
- datagram the other end can receive and reassemble
- [IP:7]. There is no corresponding mechanism in the
- IP layer.
-
- A transport protocol that assumes an EMTU_R larger
- than 576 (see Section 3.3.2), can send a datagram of
- this larger size to another host that implements the
- same protocol.
-
- (c) Hosts should ideally limit their EMTU_S for a given
- destination to the minimum MTU of all the networks
- along the path, to avoid any fragmentation. IP
- fragmentation, while formally correct, can create a
- serious transport protocol performance problem,
- because loss of a single fragment means all the
- fragments in the segment must be retransmitted
- [IP:9].
-
-
-
-
-Internet Engineering Task Force [Page 59]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- Since nearly all networks in the Internet currently
- support an MTU of 576 or greater, we strongly recommend
- the use of 576 for datagrams sent to non-local networks.
-
- It has been suggested that a host could determine the MTU
- over a given path by sending a zero-offset datagram
- fragment and waiting for the receiver to time out the
- reassembly (which cannot complete!) and return an ICMP
- Time Exceeded message. This message would include the
- largest remaining fragment header in its body. More
- direct mechanisms are being experimented with, but have
- not yet been adopted (see e.g., RFC-1063).
-
- 3.3.4 Local Multihoming
-
- 3.3.4.1 Introduction
-
- A multihomed host has multiple IP addresses, which we may
- think of as "logical interfaces". These logical interfaces
- may be associated with one or more physical interfaces, and
- these physical interfaces may be connected to the same or
- different networks.
-
- Here are some important cases of multihoming:
-
- (a) Multiple Logical Networks
-
- The Internet architects envisioned that each physical
- network would have a single unique IP network (or
- subnet) number. However, LAN administrators have
- sometimes found it useful to violate this assumption,
- operating a LAN with multiple logical networks per
- physical connected network.
-
- If a host connected to such a physical network is
- configured to handle traffic for each of N different
- logical networks, then the host will have N logical
- interfaces. These could share a single physical
- interface, or might use N physical interfaces to the
- same network.
-
- (b) Multiple Logical Hosts
-
- When a host has multiple IP addresses that all have the
- same <Network-number> part (and the same <Subnet-
- number> part, if any), the logical interfaces are known
- as "logical hosts". These logical interfaces might
- share a single physical interface or might use separate
-
-
-
-Internet Engineering Task Force [Page 60]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- physical interfaces to the same physical network.
-
- (c) Simple Multihoming
-
- In this case, each logical interface is mapped into a
- separate physical interface and each physical interface
- is connected to a different physical network. The term
- "multihoming" was originally applied only to this case,
- but it is now applied more generally.
-
- A host with embedded gateway functionality will
- typically fall into the simple multihoming case. Note,
- however, that a host may be simply multihomed without
- containing an embedded gateway, i.e., without
- forwarding datagrams from one connected network to
- another.
-
- This case presents the most difficult routing problems.
- The choice of interface (i.e., the choice of first-hop
- network) may significantly affect performance or even
- reachability of remote parts of the Internet.
-
-
- Finally, we note another possibility that is NOT
- multihoming: one logical interface may be bound to multiple
- physical interfaces, in order to increase the reliability or
- throughput between directly connected machines by providing
- alternative physical paths between them. For instance, two
- systems might be connected by multiple point-to-point links.
- We call this "link-layer multiplexing". With link-layer
- multiplexing, the protocols above the link layer are unaware
- that multiple physical interfaces are present; the link-
- layer device driver is responsible for multiplexing and
- routing packets across the physical interfaces.
-
- In the Internet protocol architecture, a transport protocol
- instance ("entity") has no address of its own, but instead
- uses a single Internet Protocol (IP) address. This has
- implications for the IP, transport, and application layers,
- and for the interfaces between them. In particular, the
- application software may have to be aware of the multiple IP
- addresses of a multihomed host; in other cases, the choice
- can be made within the network software.
-
- 3.3.4.2 Multihoming Requirements
-
- The following general rules apply to the selection of an IP
- source address for sending a datagram from a multihomed
-
-
-
-Internet Engineering Task Force [Page 61]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- host.
-
- (1) If the datagram is sent in response to a received
- datagram, the source address for the response SHOULD be
- the specific-destination address of the request. See
- Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
- section of [INTRO:1] for more specific requirements on
- higher layers.
-
- Otherwise, a source address must be selected.
-
- (2) An application MUST be able to explicitly specify the
- source address for initiating a connection or a
- request.
-
- (3) In the absence of such a specification, the networking
- software MUST choose a source address. Rules for this
- choice are described below.
-
-
- There are two key requirement issues related to multihoming:
-
- (A) A host MAY silently discard an incoming datagram whose
- destination address does not correspond to the physical
- interface through which it is received.
-
- (B) A host MAY restrict itself to sending (non-source-
- routed) IP datagrams only through the physical
- interface that corresponds to the IP source address of
- the datagrams.
-
-
- DISCUSSION:
- Internet host implementors have used two different
- conceptual models for multihoming, briefly summarized
- in the following discussion. This document takes no
- stand on which model is preferred; each seems to have a
- place. This ambivalence is reflected in the issues (A)
- and (B) being optional.
-
- o Strong ES Model
-
- The Strong ES (End System, i.e., host) model
- emphasizes the host/gateway (ES/IS) distinction,
- and would therefore substitute MUST for MAY in
- issues (A) and (B) above. It tends to model a
- multihomed host as a set of logical hosts within
- the same physical host.
-
-
-
-Internet Engineering Task Force [Page 62]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- With respect to (A), proponents of the Strong ES
- model note that automatic Internet routing
- mechanisms could not route a datagram to a
- physical interface that did not correspond to the
- destination address.
-
- Under the Strong ES model, the route computation
- for an outgoing datagram is the mapping:
-
- route(src IP addr, dest IP addr, TOS)
- -> gateway
-
- Here the source address is included as a parameter
- in order to select a gateway that is directly
- reachable on the corresponding physical interface.
- Note that this model logically requires that in
- general there be at least one default gateway, and
- preferably multiple defaults, for each IP source
- address.
-
- o Weak ES Model
-
- This view de-emphasizes the ES/IS distinction, and
- would therefore substitute MUST NOT for MAY in
- issues (A) and (B). This model may be the more
- natural one for hosts that wiretap gateway routing
- protocols, and is necessary for hosts that have
- embedded gateway functionality.
-
- The Weak ES Model may cause the Redirect mechanism
- to fail. If a datagram is sent out a physical
- interface that does not correspond to the
- destination address, the first-hop gateway will
- not realize when it needs to send a Redirect. On
- the other hand, if the host has embedded gateway
- functionality, then it has routing information
- without listening to Redirects.
-
- In the Weak ES model, the route computation for an
- outgoing datagram is the mapping:
-
- route(dest IP addr, TOS) -> gateway, interface
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 63]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- 3.3.4.3 Choosing a Source Address
-
- DISCUSSION:
- When it sends an initial connection request (e.g., a
- TCP "SYN" segment) or a datagram service request (e.g.,
- a UDP-based query), the transport layer on a multihomed
- host needs to know which source address to use. If the
- application does not specify it, the transport layer
- must ask the IP layer to perform the conceptual
- mapping:
-
- GET_SRCADDR(remote IP addr, TOS)
- -> local IP address
-
- Here TOS is the Type-of-Service value (see Section
- 3.2.1.6), and the result is the desired source address.
- The following rules are suggested for implementing this
- mapping:
-
- (a) If the remote Internet address lies on one of the
- (sub-) nets to which the host is directly
- connected, a corresponding source address may be
- chosen, unless the corresponding interface is
- known to be down.
-
- (b) The route cache may be consulted, to see if there
- is an active route to the specified destination
- network through any network interface; if so, a
- local IP address corresponding to that interface
- may be chosen.
-
- (c) The table of static routes, if any (see Section
- 3.3.1.2) may be similarly consulted.
-
- (d) The default gateways may be consulted. If these
- gateways are assigned to different interfaces, the
- interface corresponding to the gateway with the
- highest preference may be chosen.
-
- In the future, there may be a defined way for a
- multihomed host to ask the gateways on all connected
- networks for advice about the best network to use for a
- given destination.
-
- IMPLEMENTATION:
- It will be noted that this process is essentially the
- same as datagram routing (see Section 3.3.1), and
- therefore hosts may be able to combine the
-
-
-
-Internet Engineering Task Force [Page 64]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- implementation of the two functions.
-
- 3.3.5 Source Route Forwarding
-
- Subject to restrictions given below, a host MAY be able to act
- as an intermediate hop in a source route, forwarding a source-
- routed datagram to the next specified hop.
-
- However, in performing this gateway-like function, the host
- MUST obey all the relevant rules for a gateway forwarding
- source-routed datagrams [INTRO:2]. This includes the following
- specific provisions, which override the corresponding host
- provisions given earlier in this document:
-
- (A) TTL (ref. Section 3.2.1.7)
-
- The TTL field MUST be decremented and the datagram perhaps
- discarded as specified for a gateway in [INTRO:2].
-
- (B) ICMP Destination Unreachable (ref. Section 3.2.2.1)
-
- A host MUST be able to generate Destination Unreachable
- messages with the following codes:
-
- 4 (Fragmentation Required but DF Set) when a source-
- routed datagram cannot be fragmented to fit into the
- target network;
-
- 5 (Source Route Failed) when a source-routed datagram
- cannot be forwarded, e.g., because of a routing
- problem or because the next hop of a strict source
- route is not on a connected network.
-
- (C) IP Source Address (ref. Section 3.2.1.3)
-
- A source-routed datagram being forwarded MAY (and normally
- will) have a source address that is not one of the IP
- addresses of the forwarding host.
-
- (D) Record Route Option (ref. Section 3.2.1.8d)
-
- A host that is forwarding a source-routed datagram
- containing a Record Route option MUST update that option,
- if it has room.
-
- (E) Timestamp Option (ref. Section 3.2.1.8e)
-
- A host that is forwarding a source-routed datagram
-
-
-
-Internet Engineering Task Force [Page 65]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- containing a Timestamp Option MUST add the current
- timestamp to that option, according to the rules for this
- option.
-
- To define the rules restricting host forwarding of source-
- routed datagrams, we use the term "local source-routing" if the
- next hop will be through the same physical interface through
- which the datagram arrived; otherwise, it is "non-local
- source-routing".
-
- o A host is permitted to perform local source-routing
- without restriction.
-
- o A host that supports non-local source-routing MUST have a
- configurable switch to disable forwarding, and this switch
- MUST default to disabled.
-
- o The host MUST satisfy all gateway requirements for
- configurable policy filters [INTRO:2] restricting non-
- local forwarding.
-
- If a host receives a datagram with an incomplete source route
- but does not forward it for some reason, the host SHOULD return
- an ICMP Destination Unreachable (code 5, Source Route Failed)
- message, unless the datagram was itself an ICMP error message.
-
- 3.3.6 Broadcasts
-
- Section 3.2.1.3 defined the four standard IP broadcast address
- forms:
-
- Limited Broadcast: {-1, -1}
-
- Directed Broadcast: {<Network-number>,-1}
-
- Subnet Directed Broadcast:
- {<Network-number>,<Subnet-number>,-1}
-
- All-Subnets Directed Broadcast: {<Network-number>,-1,-1}
-
- A host MUST recognize any of these forms in the destination
- address of an incoming datagram.
-
- There is a class of hosts* that use non-standard broadcast
- address forms, substituting 0 for -1. All hosts SHOULD
-_________________________
-*4.2BSD Unix and its derivatives, but not 4.3BSD.
-
-
-
-
-Internet Engineering Task Force [Page 66]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- recognize and accept any of these non-standard broadcast
- addresses as the destination address of an incoming datagram.
- A host MAY optionally have a configuration option to choose the
- 0 or the -1 form of broadcast address, for each physical
- interface, but this option SHOULD default to the standard (-1)
- form.
-
- When a host sends a datagram to a link-layer broadcast address,
- the IP destination address MUST be a legal IP broadcast or IP
- multicast address.
-
- A host SHOULD silently discard a datagram that is received via
- a link-layer broadcast (see Section 2.4) but does not specify
- an IP multicast or broadcast destination address.
-
- Hosts SHOULD use the Limited Broadcast address to broadcast to
- a connected network.
-
-
- DISCUSSION:
- Using the Limited Broadcast address instead of a Directed
- Broadcast address may improve system robustness. Problems
- are often caused by machines that do not understand the
- plethora of broadcast addresses (see Section 3.2.1.3), or
- that may have different ideas about which broadcast
- addresses are in use. The prime example of the latter is
- machines that do not understand subnetting but are
- attached to a subnetted net. Sending a Subnet Broadcast
- for the connected network will confuse those machines,
- which will see it as a message to some other host.
-
- There has been discussion on whether a datagram addressed
- to the Limited Broadcast address ought to be sent from all
- the interfaces of a multihomed host. This specification
- takes no stand on the issue.
-
- 3.3.7 IP Multicasting
-
- A host SHOULD support local IP multicasting on all connected
- networks for which a mapping from Class D IP addresses to
- link-layer addresses has been specified (see below). Support
- for local IP multicasting includes sending multicast datagrams,
- joining multicast groups and receiving multicast datagrams, and
- leaving multicast groups. This implies support for all of
- [IP:4] except the IGMP protocol itself, which is OPTIONAL.
-
-
-
-
-
-
-Internet Engineering Task Force [Page 67]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- DISCUSSION:
- IGMP provides gateways that are capable of multicast
- routing with the information required to support IP
- multicasting across multiple networks. At this time,
- multicast-routing gateways are in the experimental stage
- and are not widely available. For hosts that are not
- connected to networks with multicast-routing gateways or
- that do not need to receive multicast datagrams
- originating on other networks, IGMP serves no purpose and
- is therefore optional for now. However, the rest of
- [IP:4] is currently recommended for the purpose of
- providing IP-layer access to local network multicast
- addressing, as a preferable alternative to local broadcast
- addressing. It is expected that IGMP will become
- recommended at some future date, when multicast-routing
- gateways have become more widely available.
-
- If IGMP is not implemented, a host SHOULD still join the "all-
- hosts" group (224.0.0.1) when the IP layer is initialized and
- remain a member for as long as the IP layer is active.
-
- DISCUSSION:
- Joining the "all-hosts" group will support strictly local
- uses of multicasting, e.g., a gateway discovery protocol,
- even if IGMP is not implemented.
-
- The mapping of IP Class D addresses to local addresses is
- currently specified for the following types of networks:
-
- o Ethernet/IEEE 802.3, as defined in [IP:4].
-
- o Any network that supports broadcast but not multicast,
- addressing: all IP Class D addresses map to the local
- broadcast address.
-
- o Any type of point-to-point link (e.g., SLIP or HDLC
- links): no mapping required. All IP multicast datagrams
- are sent as-is, inside the local framing.
-
- Mappings for other types of networks will be specified in the
- future.
-
- A host SHOULD provide a way for higher-layer protocols or
- applications to determine which of the host's connected
- network(s) support IP multicast addressing.
-
-
-
-
-
-
-Internet Engineering Task Force [Page 68]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- 3.3.8 Error Reporting
-
- Wherever practical, hosts MUST return ICMP error datagrams on
- detection of an error, except in those cases where returning an
- ICMP error message is specifically prohibited.
-
- DISCUSSION:
- A common phenomenon in datagram networks is the "black
- hole disease": datagrams are sent out, but nothing comes
- back. Without any error datagrams, it is difficult for
- the user to figure out what the problem is.
-
- 3.4 INTERNET/TRANSPORT LAYER INTERFACE
-
- The interface between the IP layer and the transport layer MUST
- provide full access to all the mechanisms of the IP layer,
- including options, Type-of-Service, and Time-to-Live. The
- transport layer MUST either have mechanisms to set these interface
- parameters, or provide a path to pass them through from an
- application, or both.
-
- DISCUSSION:
- Applications are urged to make use of these mechanisms where
- applicable, even when the mechanisms are not currently
- effective in the Internet (e.g., TOS). This will allow these
- mechanisms to be immediately useful when they do become
- effective, without a large amount of retrofitting of host
- software.
-
- We now describe a conceptual interface between the transport layer
- and the IP layer, as a set of procedure calls. This is an
- extension of the information in Section 3.3 of RFC-791 [IP:1].
-
-
- * Send Datagram
-
- SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
- => result )
-
- where the parameters are defined in RFC-791. Passing an Id
- parameter is optional; see Section 3.2.1.5.
-
-
- * Receive Datagram
-
- RECV(BufPTR, prot
- => result, src, dst, SpecDest, TOS, len, opt)
-
-
-
-
-Internet Engineering Task Force [Page 69]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- All the parameters are defined in RFC-791, except for:
-
- SpecDest = specific-destination address of datagram
- (defined in Section 3.2.1.3)
-
- The result parameter dst contains the datagram's destination
- address. Since this may be a broadcast or multicast address,
- the SpecDest parameter (not shown in RFC-791) MUST be passed.
- The parameter opt contains all the IP options received in the
- datagram; these MUST also be passed to the transport layer.
-
-
- * Select Source Address
-
- GET_SRCADDR(remote, TOS) -> local
-
- remote = remote IP address
- TOS = Type-of-Service
- local = local IP address
-
- See Section 3.3.4.3.
-
-
- * Find Maximum Datagram Sizes
-
- GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
-
- MMS_R = maximum receive transport-message size.
- MMS_S = maximum send transport-message size.
- (local, remote, TOS defined above)
-
- See Sections 3.3.2 and 3.3.3.
-
-
- * Advice on Delivery Success
-
- ADVISE_DELIVPROB(sense, local, remote, TOS)
-
- Here the parameter sense is a 1-bit flag indicating whether
- positive or negative advice is being given; see the
- discussion in Section 3.3.1.4. The other parameters were
- defined earlier.
-
-
- * Send ICMP Message
-
- SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
- -> result
-
-
-
-Internet Engineering Task Force [Page 70]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- (Parameters defined in RFC-791).
-
- Passing an Id parameter is optional; see Section 3.2.1.5.
- The transport layer MUST be able to send certain ICMP
- messages: Port Unreachable or any of the query-type
- messages. This function could be considered to be a special
- case of the SEND() call, of course; we describe it separately
- for clarity.
-
-
- * Receive ICMP Message
-
- RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
-
- (Parameters defined in RFC-791).
-
- The IP layer MUST pass certain ICMP messages up to the
- appropriate transport-layer routine. This function could be
- considered to be a special case of the RECV() call, of
- course; we describe it separately for clarity.
-
- For an ICMP error message, the data that is passed up MUST
- include the original Internet header plus all the octets of
- the original message that are included in the ICMP message.
- This data will be used by the transport layer to locate the
- connection state information, if any.
-
- In particular, the following ICMP messages are to be passed
- up:
-
- o Destination Unreachable
-
- o Source Quench
-
- o Echo Reply (to ICMP user interface, unless the Echo
- Request originated in the IP layer)
-
- o Timestamp Reply (to ICMP user interface)
-
- o Time Exceeded
-
-
- DISCUSSION:
- In the future, there may be additions to this interface to
- pass path data (see Section 3.3.1.3) between the IP and
- transport layers.
-
-
-
-
-
-Internet Engineering Task Force [Page 71]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- 3.5 INTERNET LAYER REQUIREMENTS SUMMARY
-
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
- | | | | | | |
-Implement IP and ICMP |3.1 |x| | | | |
-Handle remote multihoming in application layer |3.1 |x| | | | |
-Support local multihoming |3.1 | | |x| | |
-Meet gateway specs if forward datagrams |3.1 |x| | | | |
-Configuration switch for embedded gateway |3.1 |x| | | | |1
- Config switch default to non-gateway |3.1 |x| | | | |1
- Auto-config based on number of interfaces |3.1 | | | | |x|1
-Able to log discarded datagrams |3.1 | |x| | | |
- Record in counter |3.1 | |x| | | |
- | | | | | | |
-Silently discard Version != 4 |3.2.1.1 |x| | | | |
-Verify IP checksum, silently discard bad dgram |3.2.1.2 |x| | | | |
-Addressing: | | | | | | |
- Subnet addressing (RFC-950) |3.2.1.3 |x| | | | |
- Src address must be host's own IP address |3.2.1.3 |x| | | | |
- Silently discard datagram with bad dest addr |3.2.1.3 |x| | | | |
- Silently discard datagram with bad src addr |3.2.1.3 |x| | | | |
-Support reassembly |3.2.1.4 |x| | | | |
-Retain same Id field in identical datagram |3.2.1.5 | | |x| | |
- | | | | | | |
-TOS: | | | | | | |
- Allow transport layer to set TOS |3.2.1.6 |x| | | | |
- Pass received TOS up to transport layer |3.2.1.6 | |x| | | |
- Use RFC-795 link-layer mappings for TOS |3.2.1.6 | | | |x| |
-TTL: | | | | | | |
- Send packet with TTL of 0 |3.2.1.7 | | | | |x|
- Discard received packets with TTL < 2 |3.2.1.7 | | | | |x|
- Allow transport layer to set TTL |3.2.1.7 |x| | | | |
- Fixed TTL is configurable |3.2.1.7 |x| | | | |
- | | | | | | |
-IP Options: | | | | | | |
- Allow transport layer to send IP options |3.2.1.8 |x| | | | |
- Pass all IP options rcvd to higher layer |3.2.1.8 |x| | | | |
-
-
-
-Internet Engineering Task Force [Page 72]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- IP layer silently ignore unknown options |3.2.1.8 |x| | | | |
- Security option |3.2.1.8a| | |x| | |
- Send Stream Identifier option |3.2.1.8b| | | |x| |
- Silently ignore Stream Identifer option |3.2.1.8b|x| | | | |
- Record Route option |3.2.1.8d| | |x| | |
- Timestamp option |3.2.1.8e| | |x| | |
-Source Route Option: | | | | | | |
- Originate & terminate Source Route options |3.2.1.8c|x| | | | |
- Datagram with completed SR passed up to TL |3.2.1.8c|x| | | | |
- Build correct (non-redundant) return route |3.2.1.8c|x| | | | |
- Send multiple SR options in one header |3.2.1.8c| | | | |x|
- | | | | | | |
-ICMP: | | | | | | |
- Silently discard ICMP msg with unknown type |3.2.2 |x| | | | |
- Include more than 8 octets of orig datagram |3.2.2 | | |x| | |
- Included octets same as received |3.2.2 |x| | | | |
- Demux ICMP Error to transport protocol |3.2.2 |x| | | | |
- Send ICMP error message with TOS=0 |3.2.2 | |x| | | |
- Send ICMP error message for: | | | | | | |
- - ICMP error msg |3.2.2 | | | | |x|
- - IP b'cast or IP m'cast |3.2.2 | | | | |x|
- - Link-layer b'cast |3.2.2 | | | | |x|
- - Non-initial fragment |3.2.2 | | | | |x|
- - Datagram with non-unique src address |3.2.2 | | | | |x|
- Return ICMP error msgs (when not prohibited) |3.3.8 |x| | | | |
- | | | | | | |
- Dest Unreachable: | | | | | | |
- Generate Dest Unreachable (code 2/3) |3.2.2.1 | |x| | | |
- Pass ICMP Dest Unreachable to higher layer |3.2.2.1 |x| | | | |
- Higher layer act on Dest Unreach |3.2.2.1 | |x| | | |
- Interpret Dest Unreach as only hint |3.2.2.1 |x| | | | |
- Redirect: | | | | | | |
- Host send Redirect |3.2.2.2 | | | |x| |
- Update route cache when recv Redirect |3.2.2.2 |x| | | | |
- Handle both Host and Net Redirects |3.2.2.2 |x| | | | |
- Discard illegal Redirect |3.2.2.2 | |x| | | |
- Source Quench: | | | | | | |
- Send Source Quench if buffering exceeded |3.2.2.3 | | |x| | |
- Pass Source Quench to higher layer |3.2.2.3 |x| | | | |
- Higher layer act on Source Quench |3.2.2.3 | |x| | | |
- Time Exceeded: pass to higher layer |3.2.2.4 |x| | | | |
- Parameter Problem: | | | | | | |
- Send Parameter Problem messages |3.2.2.5 | |x| | | |
- Pass Parameter Problem to higher layer |3.2.2.5 |x| | | | |
- Report Parameter Problem to user |3.2.2.5 | | |x| | |
- | | | | | | |
- ICMP Echo Request or Reply: | | | | | | |
- Echo server and Echo client |3.2.2.6 |x| | | | |
-
-
-
-Internet Engineering Task Force [Page 73]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- Echo client |3.2.2.6 | |x| | | |
- Discard Echo Request to broadcast address |3.2.2.6 | | |x| | |
- Discard Echo Request to multicast address |3.2.2.6 | | |x| | |
- Use specific-dest addr as Echo Reply src |3.2.2.6 |x| | | | |
- Send same data in Echo Reply |3.2.2.6 |x| | | | |
- Pass Echo Reply to higher layer |3.2.2.6 |x| | | | |
- Reflect Record Route, Time Stamp options |3.2.2.6 | |x| | | |
- Reverse and reflect Source Route option |3.2.2.6 |x| | | | |
- | | | | | | |
- ICMP Information Request or Reply: |3.2.2.7 | | | |x| |
- ICMP Timestamp and Timestamp Reply: |3.2.2.8 | | |x| | |
- Minimize delay variability |3.2.2.8 | |x| | | |1
- Silently discard b'cast Timestamp |3.2.2.8 | | |x| | |1
- Silently discard m'cast Timestamp |3.2.2.8 | | |x| | |1
- Use specific-dest addr as TS Reply src |3.2.2.8 |x| | | | |1
- Reflect Record Route, Time Stamp options |3.2.2.6 | |x| | | |1
- Reverse and reflect Source Route option |3.2.2.8 |x| | | | |1
- Pass Timestamp Reply to higher layer |3.2.2.8 |x| | | | |1
- Obey rules for "standard value" |3.2.2.8 |x| | | | |1
- | | | | | | |
- ICMP Address Mask Request and Reply: | | | | | | |
- Addr Mask source configurable |3.2.2.9 |x| | | | |
- Support static configuration of addr mask |3.2.2.9 |x| | | | |
- Get addr mask dynamically during booting |3.2.2.9 | | |x| | |
- Get addr via ICMP Addr Mask Request/Reply |3.2.2.9 | | |x| | |
- Retransmit Addr Mask Req if no Reply |3.2.2.9 |x| | | | |3
- Assume default mask if no Reply |3.2.2.9 | |x| | | |3
- Update address mask from first Reply only |3.2.2.9 |x| | | | |3
- Reasonableness check on Addr Mask |3.2.2.9 | |x| | | |
- Send unauthorized Addr Mask Reply msgs |3.2.2.9 | | | | |x|
- Explicitly configured to be agent |3.2.2.9 |x| | | | |
- Static config=> Addr-Mask-Authoritative flag |3.2.2.9 | |x| | | |
- Broadcast Addr Mask Reply when init. |3.2.2.9 |x| | | | |3
- | | | | | | |
-ROUTING OUTBOUND DATAGRAMS: | | | | | | |
- Use address mask in local/remote decision |3.3.1.1 |x| | | | |
- Operate with no gateways on conn network |3.3.1.1 |x| | | | |
- Maintain "route cache" of next-hop gateways |3.3.1.2 |x| | | | |
- Treat Host and Net Redirect the same |3.3.1.2 | |x| | | |
- If no cache entry, use default gateway |3.3.1.2 |x| | | | |
- Support multiple default gateways |3.3.1.2 |x| | | | |
- Provide table of static routes |3.3.1.2 | | |x| | |
- Flag: route overridable by Redirects |3.3.1.2 | | |x| | |
- Key route cache on host, not net address |3.3.1.3 | | |x| | |
- Include TOS in route cache |3.3.1.3 | |x| | | |
- | | | | | | |
- Able to detect failure of next-hop gateway |3.3.1.4 |x| | | | |
- Assume route is good forever |3.3.1.4 | | | |x| |
-
-
-
-Internet Engineering Task Force [Page 74]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- Ping gateways continuously |3.3.1.4 | | | | |x|
- Ping only when traffic being sent |3.3.1.4 |x| | | | |
- Ping only when no positive indication |3.3.1.4 |x| | | | |
- Higher and lower layers give advice |3.3.1.4 | |x| | | |
- Switch from failed default g'way to another |3.3.1.5 |x| | | | |
- Manual method of entering config info |3.3.1.6 |x| | | | |
- | | | | | | |
-REASSEMBLY and FRAGMENTATION: | | | | | | |
- Able to reassemble incoming datagrams |3.3.2 |x| | | | |
- At least 576 byte datagrams |3.3.2 |x| | | | |
- EMTU_R configurable or indefinite |3.3.2 | |x| | | |
- Transport layer able to learn MMS_R |3.3.2 |x| | | | |
- Send ICMP Time Exceeded on reassembly timeout |3.3.2 |x| | | | |
- Fixed reassembly timeout value |3.3.2 | |x| | | |
- | | | | | | |
- Pass MMS_S to higher layers |3.3.3 |x| | | | |
- Local fragmentation of outgoing packets |3.3.3 | | |x| | |
- Else don't send bigger than MMS_S |3.3.3 |x| | | | |
- Send max 576 to off-net destination |3.3.3 | |x| | | |
- All-Subnets-MTU configuration flag |3.3.3 | | |x| | |
- | | | | | | |
-MULTIHOMING: | | | | | | |
- Reply with same addr as spec-dest addr |3.3.4.2 | |x| | | |
- Allow application to choose local IP addr |3.3.4.2 |x| | | | |
- Silently discard d'gram in "wrong" interface |3.3.4.2 | | |x| | |
- Only send d'gram through "right" interface |3.3.4.2 | | |x| | |4
- | | | | | | |
-SOURCE-ROUTE FORWARDING: | | | | | | |
- Forward datagram with Source Route option |3.3.5 | | |x| | |1
- Obey corresponding gateway rules |3.3.5 |x| | | | |1
- Update TTL by gateway rules |3.3.5 |x| | | | |1
- Able to generate ICMP err code 4, 5 |3.3.5 |x| | | | |1
- IP src addr not local host |3.3.5 | | |x| | |1
- Update Timestamp, Record Route options |3.3.5 |x| | | | |1
- Configurable switch for non-local SRing |3.3.5 |x| | | | |1
- Defaults to OFF |3.3.5 |x| | | | |1
- Satisfy gwy access rules for non-local SRing |3.3.5 |x| | | | |1
- If not forward, send Dest Unreach (cd 5) |3.3.5 | |x| | | |2
- | | | | | | |
-BROADCAST: | | | | | | |
- Broadcast addr as IP source addr |3.2.1.3 | | | | |x|
- Receive 0 or -1 broadcast formats OK |3.3.6 | |x| | | |
- Config'ble option to send 0 or -1 b'cast |3.3.6 | | |x| | |
- Default to -1 broadcast |3.3.6 | |x| | | |
- Recognize all broadcast address formats |3.3.6 |x| | | | |
- Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6 |x| | | | |
- Silently discard link-layer-only b'cast dg's |3.3.6 | |x| | | |
- Use Limited Broadcast addr for connected net |3.3.6 | |x| | | |
-
-
-
-Internet Engineering Task Force [Page 75]
-
-
-
-
-RFC1122 INTERNET LAYER October 1989
-
-
- | | | | | | |
-MULTICAST: | | | | | | |
- Support local IP multicasting (RFC-1112) |3.3.7 | |x| | | |
- Support IGMP (RFC-1112) |3.3.7 | | |x| | |
- Join all-hosts group at startup |3.3.7 | |x| | | |
- Higher layers learn i'face m'cast capability |3.3.7 | |x| | | |
- | | | | | | |
-INTERFACE: | | | | | | |
- Allow transport layer to use all IP mechanisms |3.4 |x| | | | |
- Pass interface ident up to transport layer |3.4 |x| | | | |
- Pass all IP options up to transport layer |3.4 |x| | | | |
- Transport layer can send certain ICMP messages |3.4 |x| | | | |
- Pass spec'd ICMP messages up to transp. layer |3.4 |x| | | | |
- Include IP hdr+8 octets or more from orig. |3.4 |x| | | | |
- Able to leap tall buildings at a single bound |3.5 | |x| | | |
-
-Footnotes:
-
-(1) Only if feature is implemented.
-
-(2) This requirement is overruled if datagram is an ICMP error message.
-
-(3) Only if feature is implemented and is configured "on".
-
-(4) Unless has embedded gateway functionality or is source routed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 76]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- UDP October 1989
-
-
-4. TRANSPORT PROTOCOLS
-
- 4.1 USER DATAGRAM PROTOCOL -- UDP
-
- 4.1.1 INTRODUCTION
-
- The User Datagram Protocol UDP [UDP:1] offers only a minimal
- transport service -- non-guaranteed datagram delivery -- and
- gives applications direct access to the datagram service of the
- IP layer. UDP is used by applications that do not require the
- level of service of TCP or that wish to use communications
- services (e.g., multicast or broadcast delivery) not available
- from TCP.
-
- UDP is almost a null protocol; the only services it provides
- over IP are checksumming of data and multiplexing by port
- number. Therefore, an application program running over UDP
- must deal directly with end-to-end communication problems that
- a connection-oriented protocol would have handled -- e.g.,
- retransmission for reliable delivery, packetization and
- reassembly, flow control, congestion avoidance, etc., when
- these are required. The fairly complex coupling between IP and
- TCP will be mirrored in the coupling between UDP and many
- applications using UDP.
-
- 4.1.2 PROTOCOL WALK-THROUGH
-
- There are no known errors in the specification of UDP.
-
- 4.1.3 SPECIFIC ISSUES
-
- 4.1.3.1 Ports
-
- UDP well-known ports follow the same rules as TCP well-known
- ports; see Section 4.2.2.1 below.
-
- If a datagram arrives addressed to a UDP port for which
- there is no pending LISTEN call, UDP SHOULD send an ICMP
- Port Unreachable message.
-
- 4.1.3.2 IP Options
-
- UDP MUST pass any IP option that it receives from the IP
- layer transparently to the application layer.
-
- An application MUST be able to specify IP options to be sent
- in its UDP datagrams, and UDP MUST pass these options to the
- IP layer.
-
-
-
-Internet Engineering Task Force [Page 77]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- UDP October 1989
-
-
- DISCUSSION:
- At present, the only options that need be passed
- through UDP are Source Route, Record Route, and Time
- Stamp. However, new options may be defined in the
- future, and UDP need not and should not make any
- assumptions about the format or content of options it
- passes to or from the application; an exception to this
- might be an IP-layer security option.
-
- An application based on UDP will need to obtain a
- source route from a request datagram and supply a
- reversed route for sending the corresponding reply.
-
- 4.1.3.3 ICMP Messages
-
- UDP MUST pass to the application layer all ICMP error
- messages that it receives from the IP layer. Conceptually
- at least, this may be accomplished with an upcall to the
- ERROR_REPORT routine (see Section 4.2.4.1).
-
- DISCUSSION:
- Note that ICMP error messages resulting from sending a
- UDP datagram are received asynchronously. A UDP-based
- application that wants to receive ICMP error messages
- is responsible for maintaining the state necessary to
- demultiplex these messages when they arrive; for
- example, the application may keep a pending receive
- operation for this purpose. The application is also
- responsible to avoid confusion from a delayed ICMP
- error message resulting from an earlier use of the same
- port(s).
-
- 4.1.3.4 UDP Checksums
-
- A host MUST implement the facility to generate and validate
- UDP checksums. An application MAY optionally be able to
- control whether a UDP checksum will be generated, but it
- MUST default to checksumming on.
-
- If a UDP datagram is received with a checksum that is non-
- zero and invalid, UDP MUST silently discard the datagram.
- An application MAY optionally be able to control whether UDP
- datagrams without checksums should be discarded or passed to
- the application.
-
- DISCUSSION:
- Some applications that normally run only across local
- area networks have chosen to turn off UDP checksums for
-
-
-
-Internet Engineering Task Force [Page 78]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- UDP October 1989
-
-
- efficiency. As a result, numerous cases of undetected
- errors have been reported. The advisability of ever
- turning off UDP checksumming is very controversial.
-
- IMPLEMENTATION:
- There is a common implementation error in UDP
- checksums. Unlike the TCP checksum, the UDP checksum
- is optional; the value zero is transmitted in the
- checksum field of a UDP header to indicate the absence
- of a checksum. If the transmitter really calculates a
- UDP checksum of zero, it must transmit the checksum as
- all 1's (65535). No special action is required at the
- receiver, since zero and 65535 are equivalent in 1's
- complement arithmetic.
-
- 4.1.3.5 UDP Multihoming
-
- When a UDP datagram is received, its specific-destination
- address MUST be passed up to the application layer.
-
- An application program MUST be able to specify the IP source
- address to be used for sending a UDP datagram or to leave it
- unspecified (in which case the networking software will
- choose an appropriate source address). There SHOULD be a
- way to communicate the chosen source address up to the
- application layer (e.g, so that the application can later
- receive a reply datagram only from the corresponding
- interface).
-
- DISCUSSION:
- A request/response application that uses UDP should use
- a source address for the response that is the same as
- the specific destination address of the request. See
- the "General Issues" section of [INTRO:1].
-
- 4.1.3.6 Invalid Addresses
-
- A UDP datagram received with an invalid IP source address
- (e.g., a broadcast or multicast address) must be discarded
- by UDP or by the IP layer (see Section 3.2.1.3).
-
- When a host sends a UDP datagram, the source address MUST be
- (one of) the IP address(es) of the host.
-
- 4.1.4 UDP/APPLICATION LAYER INTERFACE
-
- The application interface to UDP MUST provide the full services
- of the IP/transport interface described in Section 3.4 of this
-
-
-
-Internet Engineering Task Force [Page 79]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- UDP October 1989
-
-
- document. Thus, an application using UDP needs the functions
- of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and
- RECV_ICMP() calls described in Section 3.4. For example,
- GET_MAXSIZES() can be used to learn the effective maximum UDP
- maximum datagram size for a particular {interface,remote
- host,TOS} triplet.
-
- An application-layer program MUST be able to set the TTL and
- TOS values as well as IP options for sending a UDP datagram,
- and these values must be passed transparently to the IP layer.
- UDP MAY pass the received TOS up to the application layer.
-
- 4.1.5 UDP REQUIREMENTS SUMMARY
-
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
- | | | | | | |
- UDP | | | | | | |
--------------------------------------------------|--------|-|-|-|-|-|--
- | | | | | | |
-UDP send Port Unreachable |4.1.3.1 | |x| | | |
- | | | | | | |
-IP Options in UDP | | | | | | |
- - Pass rcv'd IP options to applic layer |4.1.3.2 |x| | | | |
- - Applic layer can specify IP options in Send |4.1.3.2 |x| | | | |
- - UDP passes IP options down to IP layer |4.1.3.2 |x| | | | |
- | | | | | | |
-Pass ICMP msgs up to applic layer |4.1.3.3 |x| | | | |
- | | | | | | |
-UDP checksums: | | | | | | |
- - Able to generate/check checksum |4.1.3.4 |x| | | | |
- - Silently discard bad checksum |4.1.3.4 |x| | | | |
- - Sender Option to not generate checksum |4.1.3.4 | | |x| | |
- - Default is to checksum |4.1.3.4 |x| | | | |
- - Receiver Option to require checksum |4.1.3.4 | | |x| | |
- | | | | | | |
-UDP Multihoming | | | | | | |
- - Pass spec-dest addr to application |4.1.3.5 |x| | | | |
-
-
-
-Internet Engineering Task Force [Page 80]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- UDP October 1989
-
-
- - Applic layer can specify Local IP addr |4.1.3.5 |x| | | | |
- - Applic layer specify wild Local IP addr |4.1.3.5 |x| | | | |
- - Applic layer notified of Local IP addr used |4.1.3.5 | |x| | | |
- | | | | | | |
-Bad IP src addr silently discarded by UDP/IP |4.1.3.6 |x| | | | |
-Only send valid IP source address |4.1.3.6 |x| | | | |
-UDP Application Interface Services | | | | | | |
-Full IP interface of 3.4 for application |4.1.4 |x| | | | |
- - Able to spec TTL, TOS, IP opts when send dg |4.1.4 |x| | | | |
- - Pass received TOS up to applic layer |4.1.4 | | |x| | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 81]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP
-
- 4.2.1 INTRODUCTION
-
- The Transmission Control Protocol TCP [TCP:1] is the primary
- virtual-circuit transport protocol for the Internet suite. TCP
- provides reliable, in-sequence delivery of a full-duplex stream
- of octets (8-bit bytes). TCP is used by those applications
- needing reliable, connection-oriented transport service, e.g.,
- mail (SMTP), file transfer (FTP), and virtual terminal service
- (Telnet); requirements for these application-layer protocols
- are described in [INTRO:1].
-
- 4.2.2 PROTOCOL WALK-THROUGH
-
- 4.2.2.1 Well-Known Ports: RFC-793 Section 2.7
-
- DISCUSSION:
- TCP reserves port numbers in the range 0-255 for
- "well-known" ports, used to access services that are
- standardized across the Internet. The remainder of the
- port space can be freely allocated to application
- processes. Current well-known port definitions are
- listed in the RFC entitled "Assigned Numbers"
- [INTRO:6]. A prerequisite for defining a new well-
- known port is an RFC documenting the proposed service
- in enough detail to allow new implementations.
-
- Some systems extend this notion by adding a third
- subdivision of the TCP port space: reserved ports,
- which are generally used for operating-system-specific
- services. For example, reserved ports might fall
- between 256 and some system-dependent upper limit.
- Some systems further choose to protect well-known and
- reserved ports by permitting only privileged users to
- open TCP connections with those port values. This is
- perfectly reasonable as long as the host does not
- assume that all hosts protect their low-numbered ports
- in this manner.
-
- 4.2.2.2 Use of Push: RFC-793 Section 2.8
-
- When an application issues a series of SEND calls without
- setting the PUSH flag, the TCP MAY aggregate the data
- internally without sending it. Similarly, when a series of
- segments is received without the PSH bit, a TCP MAY queue
- the data internally without passing it to the receiving
- application.
-
-
-
-Internet Engineering Task Force [Page 82]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- The PSH bit is not a record marker and is independent of
- segment boundaries. The transmitter SHOULD collapse
- successive PSH bits when it packetizes data, to send the
- largest possible segment.
-
- A TCP MAY implement PUSH flags on SEND calls. If PUSH flags
- are not implemented, then the sending TCP: (1) must not
- buffer data indefinitely, and (2) MUST set the PSH bit in
- the last buffered segment (i.e., when there is no more
- queued data to be sent).
-
- The discussion in RFC-793 on pages 48, 50, and 74
- erroneously implies that a received PSH flag must be passed
- to the application layer. Passing a received PSH flag to
- the application layer is now OPTIONAL.
-
- An application program is logically required to set the PUSH
- flag in a SEND call whenever it needs to force delivery of
- the data to avoid a communication deadlock. However, a TCP
- SHOULD send a maximum-sized segment whenever possible, to
- improve performance (see Section 4.2.3.4).
-
- DISCUSSION:
- When the PUSH flag is not implemented on SEND calls,
- i.e., when the application/TCP interface uses a pure
- streaming model, responsibility for aggregating any
- tiny data fragments to form reasonable sized segments
- is partially borne by the application layer.
-
- Generally, an interactive application protocol must set
- the PUSH flag at least in the last SEND call in each
- command or response sequence. A bulk transfer protocol
- like FTP should set the PUSH flag on the last segment
- of a file or when necessary to prevent buffer deadlock.
-
- At the receiver, the PSH bit forces buffered data to be
- delivered to the application (even if less than a full
- buffer has been received). Conversely, the lack of a
- PSH bit can be used to avoid unnecessary wakeup calls
- to the application process; this can be an important
- performance optimization for large timesharing hosts.
- Passing the PSH bit to the receiving application allows
- an analogous optimization within the application.
-
- 4.2.2.3 Window Size: RFC-793 Section 3.1
-
- The window size MUST be treated as an unsigned number, or
- else large window sizes will appear like negative windows
-
-
-
-Internet Engineering Task Force [Page 83]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- and TCP will not work. It is RECOMMENDED that
- implementations reserve 32-bit fields for the send and
- receive window sizes in the connection record and do all
- window computations with 32 bits.
-
- DISCUSSION:
- It is known that the window field in the TCP header is
- too small for high-speed, long-delay paths.
- Experimental TCP options have been defined to extend
- the window size; see for example [TCP:11]. In
- anticipation of the adoption of such an extension, TCP
- implementors should treat windows as 32 bits.
-
- 4.2.2.4 Urgent Pointer: RFC-793 Section 3.1
-
- The second sentence is in error: the urgent pointer points
- to the sequence number of the LAST octet (not LAST+1) in a
- sequence of urgent data. The description on page 56 (last
- sentence) is correct.
-
- A TCP MUST support a sequence of urgent data of any length.
-
- A TCP MUST inform the application layer asynchronously
- whenever it receives an Urgent pointer and there was
- previously no pending urgent data, or whenever the Urgent
- pointer advances in the data stream. There MUST be a way
- for the application to learn how much urgent data remains to
- be read from the connection, or at least to determine
- whether or not more urgent data remains to be read.
-
- DISCUSSION:
- Although the Urgent mechanism may be used for any
- application, it is normally used to send "interrupt"-
- type commands to a Telnet program (see "Using Telnet
- Synch Sequence" section in [INTRO:1]).
-
- The asynchronous or "out-of-band" notification will
- allow the application to go into "urgent mode", reading
- data from the TCP connection. This allows control
- commands to be sent to an application whose normal
- input buffers are full of unprocessed data.
-
- IMPLEMENTATION:
- The generic ERROR-REPORT() upcall described in Section
- 4.2.4.1 is a possible mechanism for informing the
- application of the arrival of urgent data.
-
-
-
-
-
-Internet Engineering Task Force [Page 84]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- 4.2.2.5 TCP Options: RFC-793 Section 3.1
-
- A TCP MUST be able to receive a TCP option in any segment.
- A TCP MUST ignore without error any TCP option it does not
- implement, assuming that the option has a length field (all
- TCP options defined in the future will have length fields).
- TCP MUST be prepared to handle an illegal option length
- (e.g., zero) without crashing; a suggested procedure is to
- reset the connection and log the reason.
-
- 4.2.2.6 Maximum Segment Size Option: RFC-793 Section 3.1
-
- TCP MUST implement both sending and receiving the Maximum
- Segment Size option [TCP:4].
-
- TCP SHOULD send an MSS (Maximum Segment Size) option in
- every SYN segment when its receive MSS differs from the
- default 536, and MAY send it always.
-
- If an MSS option is not received at connection setup, TCP
- MUST assume a default send MSS of 536 (576-40) [TCP:4].
-
- The maximum size of a segment that TCP really sends, the
- "effective send MSS," MUST be the smaller of the send MSS
- (which reflects the available reassembly buffer size at the
- remote host) and the largest size permitted by the IP layer:
-
- Eff.snd.MSS =
-
- min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
-
- where:
-
- * SendMSS is the MSS value received from the remote host,
- or the default 536 if no MSS option is received.
-
- * MMS_S is the maximum size for a transport-layer message
- that TCP may send.
-
- * TCPhdrsize is the size of the TCP header; this is
- normally 20, but may be larger if TCP options are to be
- sent.
-
- * IPoptionsize is the size of any IP options that TCP
- will pass to the IP layer with the current message.
-
-
- The MSS value to be sent in an MSS option must be less than
-
-
-
-Internet Engineering Task Force [Page 85]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- or equal to:
-
- MMS_R - 20
-
- where MMS_R is the maximum size for a transport-layer
- message that can be received (and reassembled). TCP obtains
- MMS_R and MMS_S from the IP layer; see the generic call
- GET_MAXSIZES in Section 3.4.
-
- DISCUSSION:
- The choice of TCP segment size has a strong effect on
- performance. Larger segments increase throughput by
- amortizing header size and per-datagram processing
- overhead over more data bytes; however, if the packet
- is so large that it causes IP fragmentation, efficiency
- drops sharply if any fragments are lost [IP:9].
-
- Some TCP implementations send an MSS option only if the
- destination host is on a non-connected network.
- However, in general the TCP layer may not have the
- appropriate information to make this decision, so it is
- preferable to leave to the IP layer the task of
- determining a suitable MTU for the Internet path. We
- therefore recommend that TCP always send the option (if
- not 536) and that the IP layer determine MMS_R as
- specified in 3.3.3 and 3.4. A proposed IP-layer
- mechanism to measure the MTU would then modify the IP
- layer without changing TCP.
-
- 4.2.2.7 TCP Checksum: RFC-793 Section 3.1
-
- Unlike the UDP checksum (see Section 4.1.3.4), the TCP
- checksum is never optional. The sender MUST generate it and
- the receiver MUST check it.
-
- 4.2.2.8 TCP Connection State Diagram: RFC-793 Section 3.2,
- page 23
-
- There are several problems with this diagram:
-
- (a) The arrow from SYN-SENT to SYN-RCVD should be labeled
- with "snd SYN,ACK", to agree with the text on page 68
- and with Figure 8.
-
- (b) There could be an arrow from SYN-RCVD state to LISTEN
- state, conditioned on receiving a RST after a passive
- open (see text page 70).
-
-
-
-
-Internet Engineering Task Force [Page 86]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- (c) It is possible to go directly from FIN-WAIT-1 to the
- TIME-WAIT state (see page 75 of the spec).
-
-
- 4.2.2.9 Initial Sequence Number Selection: RFC-793 Section
- 3.3, page 27
-
- A TCP MUST use the specified clock-driven selection of
- initial sequence numbers.
-
- 4.2.2.10 Simultaneous Open Attempts: RFC-793 Section 3.4, page
- 32
-
- There is an error in Figure 8: the packet on line 7 should
- be identical to the packet on line 5.
-
- A TCP MUST support simultaneous open attempts.
-
- DISCUSSION:
- It sometimes surprises implementors that if two
- applications attempt to simultaneously connect to each
- other, only one connection is generated instead of two.
- This was an intentional design decision; don't try to
- "fix" it.
-
- 4.2.2.11 Recovery from Old Duplicate SYN: RFC-793 Section 3.4,
- page 33
-
- Note that a TCP implementation MUST keep track of whether a
- connection has reached SYN_RCVD state as the result of a
- passive OPEN or an active OPEN.
-
- 4.2.2.12 RST Segment: RFC-793 Section 3.4
-
- A TCP SHOULD allow a received RST segment to include data.
-
- DISCUSSION
- It has been suggested that a RST segment could contain
- ASCII text that encoded and explained the cause of the
- RST. No standard has yet been established for such
- data.
-
- 4.2.2.13 Closing a Connection: RFC-793 Section 3.5
-
- A TCP connection may terminate in two ways: (1) the normal
- TCP close sequence using a FIN handshake, and (2) an "abort"
- in which one or more RST segments are sent and the
- connection state is immediately discarded. If a TCP
-
-
-
-Internet Engineering Task Force [Page 87]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- connection is closed by the remote site, the local
- application MUST be informed whether it closed normally or
- was aborted.
-
- The normal TCP close sequence delivers buffered data
- reliably in both directions. Since the two directions of a
- TCP connection are closed independently, it is possible for
- a connection to be "half closed," i.e., closed in only one
- direction, and a host is permitted to continue sending data
- in the open direction on a half-closed connection.
-
- A host MAY implement a "half-duplex" TCP close sequence, so
- that an application that has called CLOSE cannot continue to
- read data from the connection. If such a host issues a
- CLOSE call while received data is still pending in TCP, or
- if new data is received after CLOSE is called, its TCP
- SHOULD send a RST to show that data was lost.
-
- When a connection is closed actively, it MUST linger in
- TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
- However, it MAY accept a new SYN from the remote TCP to
- reopen the connection directly from TIME-WAIT state, if it:
-
- (1) assigns its initial sequence number for the new
- connection to be larger than the largest sequence
- number it used on the previous connection incarnation,
- and
-
- (2) returns to TIME-WAIT state if the SYN turns out to be
- an old duplicate.
-
-
- DISCUSSION:
- TCP's full-duplex data-preserving close is a feature
- that is not included in the analogous ISO transport
- protocol TP4.
-
- Some systems have not implemented half-closed
- connections, presumably because they do not fit into
- the I/O model of their particular operating system. On
- these systems, once an application has called CLOSE, it
- can no longer read input data from the connection; this
- is referred to as a "half-duplex" TCP close sequence.
-
- The graceful close algorithm of TCP requires that the
- connection state remain defined on (at least) one end
- of the connection, for a timeout period of 2xMSL, i.e.,
- 4 minutes. During this period, the (remote socket,
-
-
-
-Internet Engineering Task Force [Page 88]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- local socket) pair that defines the connection is busy
- and cannot be reused. To shorten the time that a given
- port pair is tied up, some TCPs allow a new SYN to be
- accepted in TIME-WAIT state.
-
- 4.2.2.14 Data Communication: RFC-793 Section 3.7, page 40
-
- Since RFC-793 was written, there has been extensive work on
- TCP algorithms to achieve efficient data communication.
- Later sections of the present document describe required and
- recommended TCP algorithms to determine when to send data
- (Section 4.2.3.4), when to send an acknowledgment (Section
- 4.2.3.2), and when to update the window (Section 4.2.3.3).
-
- DISCUSSION:
- One important performance issue is "Silly Window
- Syndrome" or "SWS" [TCP:5], a stable pattern of small
- incremental window movements resulting in extremely
- poor TCP performance. Algorithms to avoid SWS are
- described below for both the sending side (Section
- 4.2.3.4) and the receiving side (Section 4.2.3.3).
-
- In brief, SWS is caused by the receiver advancing the
- right window edge whenever it has any new buffer space
- available to receive data and by the sender using any
- incremental window, no matter how small, to send more
- data [TCP:5]. The result can be a stable pattern of
- sending tiny data segments, even though both sender and
- receiver have a large total buffer space for the
- connection. SWS can only occur during the transmission
- of a large amount of data; if the connection goes
- quiescent, the problem will disappear. It is caused by
- typical straightforward implementation of window
- management, but the sender and receiver algorithms
- given below will avoid it.
-
- Another important TCP performance issue is that some
- applications, especially remote login to character-at-
- a-time hosts, tend to send streams of one-octet data
- segments. To avoid deadlocks, every TCP SEND call from
- such applications must be "pushed", either explicitly
- by the application or else implicitly by TCP. The
- result may be a stream of TCP segments that contain one
- data octet each, which makes very inefficient use of
- the Internet and contributes to Internet congestion.
- The Nagle Algorithm described in Section 4.2.3.4
- provides a simple and effective solution to this
- problem. It does have the effect of clumping
-
-
-
-Internet Engineering Task Force [Page 89]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- characters over Telnet connections; this may initially
- surprise users accustomed to single-character echo, but
- user acceptance has not been a problem.
-
- Note that the Nagle algorithm and the send SWS
- avoidance algorithm play complementary roles in
- improving performance. The Nagle algorithm discourages
- sending tiny segments when the data to be sent
- increases in small increments, while the SWS avoidance
- algorithm discourages small segments resulting from the
- right window edge advancing in small increments.
-
- A careless implementation can send two or more
- acknowledgment segments per data segment received. For
- example, suppose the receiver acknowledges every data
- segment immediately. When the application program
- subsequently consumes the data and increases the
- available receive buffer space again, the receiver may
- send a second acknowledgment segment to update the
- window at the sender. The extreme case occurs with
- single-character segments on TCP connections using the
- Telnet protocol for remote login service. Some
- implementations have been observed in which each
- incoming 1-character segment generates three return
- segments: (1) the acknowledgment, (2) a one byte
- increase in the window, and (3) the echoed character,
- respectively.
-
- 4.2.2.15 Retransmission Timeout: RFC-793 Section 3.7, page 41
-
- The algorithm suggested in RFC-793 for calculating the
- retransmission timeout is now known to be inadequate; see
- Section 4.2.3.1 below.
-
- Recent work by Jacobson [TCP:7] on Internet congestion and
- TCP retransmission stability has produced a transmission
- algorithm combining "slow start" with "congestion
- avoidance". A TCP MUST implement this algorithm.
-
- If a retransmitted packet is identical to the original
- packet (which implies not only that the data boundaries have
- not changed, but also that the window and acknowledgment
- fields of the header have not changed), then the same IP
- Identification field MAY be used (see Section 3.2.1.5).
-
- IMPLEMENTATION:
- Some TCP implementors have chosen to "packetize" the
- data stream, i.e., to pick segment boundaries when
-
-
-
-Internet Engineering Task Force [Page 90]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- segments are originally sent and to queue these
- segments in a "retransmission queue" until they are
- acknowledged. Another design (which may be simpler) is
- to defer packetizing until each time data is
- transmitted or retransmitted, so there will be no
- segment retransmission queue.
-
- In an implementation with a segment retransmission
- queue, TCP performance may be enhanced by repacketizing
- the segments awaiting acknowledgment when the first
- retransmission timeout occurs. That is, the
- outstanding segments that fitted would be combined into
- one maximum-sized segment, with a new IP Identification
- value. The TCP would then retain this combined segment
- in the retransmit queue until it was acknowledged.
- However, if the first two segments in the
- retransmission queue totalled more than one maximum-
- sized segment, the TCP would retransmit only the first
- segment using the original IP Identification field.
-
- 4.2.2.16 Managing the Window: RFC-793 Section 3.7, page 41
-
- A TCP receiver SHOULD NOT shrink the window, i.e., move the
- right window edge to the left. However, a sending TCP MUST
- be robust against window shrinking, which may cause the
- "useable window" (see Section 4.2.3.4) to become negative.
-
- If this happens, the sender SHOULD NOT send new data, but
- SHOULD retransmit normally the old unacknowledged data
- between SND.UNA and SND.UNA+SND.WND. The sender MAY also
- retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT
- time out the connection if data beyond the right window edge
- is not acknowledged. If the window shrinks to zero, the TCP
- MUST probe it in the standard way (see next Section).
-
- DISCUSSION:
- Many TCP implementations become confused if the window
- shrinks from the right after data has been sent into a
- larger window. Note that TCP has a heuristic to select
- the latest window update despite possible datagram
- reordering; as a result, it may ignore a window update
- with a smaller window than previously offered if
- neither the sequence number nor the acknowledgment
- number is increased.
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 91]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- 4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42
-
- Probing of zero (offered) windows MUST be supported.
-
- A TCP MAY keep its offered receive window closed
- indefinitely. As long as the receiving TCP continues to
- send acknowledgments in response to the probe segments, the
- sending TCP MUST allow the connection to stay open.
-
- DISCUSSION:
- It is extremely important to remember that ACK
- (acknowledgment) segments that contain no data are not
- reliably transmitted by TCP. If zero window probing is
- not supported, a connection may hang forever when an
- ACK segment that re-opens the window is lost.
-
- The delay in opening a zero window generally occurs
- when the receiving application stops taking data from
- its TCP. For example, consider a printer daemon
- application, stopped because the printer ran out of
- paper.
-
- The transmitting host SHOULD send the first zero-window
- probe when a zero window has existed for the retransmission
- timeout period (see Section 4.2.2.15), and SHOULD increase
- exponentially the interval between successive probes.
-
- DISCUSSION:
- This procedure minimizes delay if the zero-window
- condition is due to a lost ACK segment containing a
- window-opening update. Exponential backoff is
- recommended, possibly with some maximum interval not
- specified here. This procedure is similar to that of
- the retransmission algorithm, and it may be possible to
- combine the two procedures in the implementation.
-
- 4.2.2.18 Passive OPEN Calls: RFC-793 Section 3.8
-
- Every passive OPEN call either creates a new connection
- record in LISTEN state, or it returns an error; it MUST NOT
- affect any previously created connection record.
-
- A TCP that supports multiple concurrent users MUST provide
- an OPEN call that will functionally allow an application to
- LISTEN on a port while a connection block with the same
- local port is in SYN-SENT or SYN-RECEIVED state.
-
- DISCUSSION:
-
-
-
-Internet Engineering Task Force [Page 92]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- Some applications (e.g., SMTP servers) may need to
- handle multiple connection attempts at about the same
- time. The probability of a connection attempt failing
- is reduced by giving the application some means of
- listening for a new connection at the same time that an
- earlier connection attempt is going through the three-
- way handshake.
-
- IMPLEMENTATION:
- Acceptable implementations of concurrent opens may
- permit multiple passive OPEN calls, or they may allow
- "cloning" of LISTEN-state connections from a single
- passive OPEN call.
-
- 4.2.2.19 Time to Live: RFC-793 Section 3.9, page 52
-
- RFC-793 specified that TCP was to request the IP layer to
- send TCP segments with TTL = 60. This is obsolete; the TTL
- value used to send TCP segments MUST be configurable. See
- Section 3.2.1.7 for discussion.
-
- 4.2.2.20 Event Processing: RFC-793 Section 3.9
-
- While it is not strictly required, a TCP SHOULD be capable
- of queueing out-of-order TCP segments. Change the "may" in
- the last sentence of the first paragraph on page 70 to
- "should".
-
- DISCUSSION:
- Some small-host implementations have omitted segment
- queueing because of limited buffer space. This
- omission may be expected to adversely affect TCP
- throughput, since loss of a single segment causes all
- later segments to appear to be "out of sequence".
-
- In general, the processing of received segments MUST be
- implemented to aggregate ACK segments whenever possible.
- For example, if the TCP is processing a series of queued
- segments, it MUST process them all before sending any ACK
- segments.
-
- Here are some detailed error corrections and notes on the
- Event Processing section of RFC-793.
-
- (a) CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK
- state, not CLOSING.
-
- (b) LISTEN state, check for SYN (pp. 65, 66): With a SYN
-
-
-
-Internet Engineering Task Force [Page 93]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- bit, if the security/compartment or the precedence is
- wrong for the segment, a reset is sent. The wrong form
- of reset is shown in the text; it should be:
-
- <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
-
-
- (c) SYN-SENT state, Check for SYN, p. 68: When the
- connection enters ESTABLISHED state, the following
- variables must be set:
- SND.WND <- SEG.WND
- SND.WL1 <- SEG.SEQ
- SND.WL2 <- SEG.ACK
-
-
- (d) Check security and precedence, p. 71: The first heading
- "ESTABLISHED STATE" should really be a list of all
- states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT-
- 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and
- TIME-WAIT.
-
- (e) Check SYN bit, p. 71: "In SYN-RECEIVED state and if
- the connection was initiated with a passive OPEN, then
- return this connection to the LISTEN state and return.
- Otherwise...".
-
- (f) Check ACK field, SYN-RECEIVED state, p. 72: When the
- connection enters ESTABLISHED state, the variables
- listed in (c) must be set.
-
- (g) Check ACK field, ESTABLISHED state, p. 72: The ACK is a
- duplicate if SEG.ACK =< SND.UNA (the = was omitted).
- Similarly, the window should be updated if: SND.UNA =<
- SEG.ACK =< SND.NXT.
-
- (h) USER TIMEOUT, p. 77:
-
- It would be better to notify the application of the
- timeout rather than letting TCP force the connection
- closed. However, see also Section 4.2.3.5.
-
-
- 4.2.2.21 Acknowledging Queued Segments: RFC-793 Section 3.9
-
- A TCP MAY send an ACK segment acknowledging RCV.NXT when a
- valid segment arrives that is in the window but not at the
- left window edge.
-
-
-
-
-Internet Engineering Task Force [Page 94]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- DISCUSSION:
- RFC-793 (see page 74) was ambiguous about whether or
- not an ACK segment should be sent when an out-of-order
- segment was received, i.e., when SEG.SEQ was unequal to
- RCV.NXT.
-
- One reason for ACKing out-of-order segments might be to
- support an experimental algorithm known as "fast
- retransmit". With this algorithm, the sender uses the
- "redundant" ACK's to deduce that a segment has been
- lost before the retransmission timer has expired. It
- counts the number of times an ACK has been received
- with the same value of SEG.ACK and with the same right
- window edge. If more than a threshold number of such
- ACK's is received, then the segment containing the
- octets starting at SEG.ACK is assumed to have been lost
- and is retransmitted, without awaiting a timeout. The
- threshold is chosen to compensate for the maximum
- likely segment reordering in the Internet. There is
- not yet enough experience with the fast retransmit
- algorithm to determine how useful it is.
-
- 4.2.3 SPECIFIC ISSUES
-
- 4.2.3.1 Retransmission Timeout Calculation
-
- A host TCP MUST implement Karn's algorithm and Jacobson's
- algorithm for computing the retransmission timeout ("RTO").
-
- o Jacobson's algorithm for computing the smoothed round-
- trip ("RTT") time incorporates a simple measure of the
- variance [TCP:7].
-
- o Karn's algorithm for selecting RTT measurements ensures
- that ambiguous round-trip times will not corrupt the
- calculation of the smoothed round-trip time [TCP:6].
-
- This implementation also MUST include "exponential backoff"
- for successive RTO values for the same segment.
- Retransmission of SYN segments SHOULD use the same algorithm
- as data segments.
-
- DISCUSSION:
- There were two known problems with the RTO calculations
- specified in RFC-793. First, the accurate measurement
- of RTTs is difficult when there are retransmissions.
- Second, the algorithm to compute the smoothed round-
- trip time is inadequate [TCP:7], because it incorrectly
-
-
-
-Internet Engineering Task Force [Page 95]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- assumed that the variance in RTT values would be small
- and constant. These problems were solved by Karn's and
- Jacobson's algorithm, respectively.
-
- The performance increase resulting from the use of
- these improvements varies from noticeable to dramatic.
- Jacobson's algorithm for incorporating the measured RTT
- variance is especially important on a low-speed link,
- where the natural variation of packet sizes causes a
- large variation in RTT. One vendor found link
- utilization on a 9.6kb line went from 10% to 90% as a
- result of implementing Jacobson's variance algorithm in
- TCP.
-
- The following values SHOULD be used to initialize the
- estimation parameters for a new connection:
-
- (a) RTT = 0 seconds.
-
- (b) RTO = 3 seconds. (The smoothed variance is to be
- initialized to the value that will result in this RTO).
-
- The recommended upper and lower bounds on the RTO are known
- to be inadequate on large internets. The lower bound SHOULD
- be measured in fractions of a second (to accommodate high
- speed LANs) and the upper bound should be 2*MSL, i.e., 240
- seconds.
-
- DISCUSSION:
- Experience has shown that these initialization values
- are reasonable, and that in any case the Karn and
- Jacobson algorithms make TCP behavior reasonably
- insensitive to the initial parameter choices.
-
- 4.2.3.2 When to Send an ACK Segment
-
- A host that is receiving a stream of TCP data segments can
- increase efficiency in both the Internet and the hosts by
- sending fewer than one ACK (acknowledgment) segment per data
- segment received; this is known as a "delayed ACK" [TCP:5].
-
- A TCP SHOULD implement a delayed ACK, but an ACK should not
- be excessively delayed; in particular, the delay MUST be
- less than 0.5 seconds, and in a stream of full-sized
- segments there SHOULD be an ACK for at least every second
- segment.
-
- DISCUSSION:
-
-
-
-Internet Engineering Task Force [Page 96]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- A delayed ACK gives the application an opportunity to
- update the window and perhaps to send an immediate
- response. In particular, in the case of character-mode
- remote login, a delayed ACK can reduce the number of
- segments sent by the server by a factor of 3 (ACK,
- window update, and echo character all combined in one
- segment).
-
- In addition, on some large multi-user hosts, a delayed
- ACK can substantially reduce protocol processing
- overhead by reducing the total number of packets to be
- processed [TCP:5]. However, excessive delays on ACK's
- can disturb the round-trip timing and packet "clocking"
- algorithms [TCP:7].
-
- 4.2.3.3 When to Send a Window Update
-
- A TCP MUST include a SWS avoidance algorithm in the receiver
- [TCP:5].
-
- IMPLEMENTATION:
- The receiver's SWS avoidance algorithm determines when
- the right window edge may be advanced; this is
- customarily known as "updating the window". This
- algorithm combines with the delayed ACK algorithm (see
- Section 4.2.3.2) to determine when an ACK segment
- containing the current window will really be sent to
- the receiver. We use the notation of RFC-793; see
- Figures 4 and 5 in that document.
-
- The solution to receiver SWS is to avoid advancing the
- right window edge RCV.NXT+RCV.WND in small increments,
- even if data is received from the network in small
- segments.
-
- Suppose the total receive buffer space is RCV.BUFF. At
- any given moment, RCV.USER octets of this total may be
- tied up with data that has been received and
- acknowledged but which the user process has not yet
- consumed. When the connection is quiescent, RCV.WND =
- RCV.BUFF and RCV.USER = 0.
-
- Keeping the right window edge fixed as data arrives and
- is acknowledged requires that the receiver offer less
- than its full buffer space, i.e., the receiver must
- specify a RCV.WND that keeps RCV.NXT+RCV.WND constant
- as RCV.NXT increases. Thus, the total buffer space
- RCV.BUFF is generally divided into three parts:
-
-
-
-Internet Engineering Task Force [Page 97]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
-
- |<------- RCV.BUFF ---------------->|
- 1 2 3
- ----|---------|------------------|------|----
- RCV.NXT ^
- (Fixed)
-
- 1 - RCV.USER = data received but not yet consumed;
- 2 - RCV.WND = space advertised to sender;
- 3 - Reduction = space available but not yet
- advertised.
-
-
- The suggested SWS avoidance algorithm for the receiver
- is to keep RCV.NXT+RCV.WND fixed until the reduction
- satisfies:
-
- RCV.BUFF - RCV.USER - RCV.WND >=
-
- min( Fr * RCV.BUFF, Eff.snd.MSS )
-
- where Fr is a fraction whose recommended value is 1/2,
- and Eff.snd.MSS is the effective send MSS for the
- connection (see Section 4.2.2.6). When the inequality
- is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.
-
- Note that the general effect of this algorithm is to
- advance RCV.WND in increments of Eff.snd.MSS (for
- realistic receive buffers: Eff.snd.MSS < RCV.BUFF/2).
- Note also that the receiver must use its own
- Eff.snd.MSS, assuming it is the same as the sender's.
-
- 4.2.3.4 When to Send Data
-
- A TCP MUST include a SWS avoidance algorithm in the sender.
-
- A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
- coalesce short segments. However, there MUST be a way for
- an application to disable the Nagle algorithm on an
- individual connection. In all cases, sending data is also
- subject to the limitation imposed by the Slow Start
- algorithm (Section 4.2.2.15).
-
- DISCUSSION:
- The Nagle algorithm is generally as follows:
-
- If there is unacknowledged data (i.e., SND.NXT >
- SND.UNA), then the sending TCP buffers all user
-
-
-
-Internet Engineering Task Force [Page 98]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- data (regardless of the PSH bit), until the
- outstanding data has been acknowledged or until
- the TCP can send a full-sized segment (Eff.snd.MSS
- bytes; see Section 4.2.2.6).
-
- Some applications (e.g., real-time display window
- updates) require that the Nagle algorithm be turned
- off, so small data segments can be streamed out at the
- maximum rate.
-
- IMPLEMENTATION:
- The sender's SWS avoidance algorithm is more difficult
- than the receivers's, because the sender does not know
- (directly) the receiver's total buffer space RCV.BUFF.
- An approach which has been found to work well is for
- the sender to calculate Max(SND.WND), the maximum send
- window it has seen so far on the connection, and to use
- this value as an estimate of RCV.BUFF. Unfortunately,
- this can only be an estimate; the receiver may at any
- time reduce the size of RCV.BUFF. To avoid a resulting
- deadlock, it is necessary to have a timeout to force
- transmission of data, overriding the SWS avoidance
- algorithm. In practice, this timeout should seldom
- occur.
-
- The "useable window" [TCP:5] is:
-
- U = SND.UNA + SND.WND - SND.NXT
-
- i.e., the offered window less the amount of data sent
- but not acknowledged. If D is the amount of data
- queued in the sending TCP but not yet sent, then the
- following set of rules is recommended.
-
- Send data:
-
- (1) if a maximum-sized segment can be sent, i.e, if:
-
- min(D,U) >= Eff.snd.MSS;
-
-
- (2) or if the data is pushed and all queued data can
- be sent now, i.e., if:
-
- [SND.NXT = SND.UNA and] PUSHED and D <= U
-
- (the bracketed condition is imposed by the Nagle
- algorithm);
-
-
-
-Internet Engineering Task Force [Page 99]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- (3) or if at least a fraction Fs of the maximum window
- can be sent, i.e., if:
-
- [SND.NXT = SND.UNA and]
-
- min(D.U) >= Fs * Max(SND.WND);
-
-
- (4) or if data is PUSHed and the override timeout
- occurs.
-
- Here Fs is a fraction whose recommended value is 1/2.
- The override timeout should be in the range 0.1 - 1.0
- seconds. It may be convenient to combine this timer
- with the timer used to probe zero windows (Section
- 4.2.2.17).
-
- Finally, note that the SWS avoidance algorithm just
- specified is to be used instead of the sender-side
- algorithm contained in [TCP:5].
-
- 4.2.3.5 TCP Connection Failures
-
- Excessive retransmission of the same segment by TCP
- indicates some failure of the remote host or the Internet
- path. This failure may be of short or long duration. The
- following procedure MUST be used to handle excessive
- retransmissions of data segments [IP:11]:
-
- (a) There are two thresholds R1 and R2 measuring the amount
- of retransmission that has occurred for the same
- segment. R1 and R2 might be measured in time units or
- as a count of retransmissions.
-
- (b) When the number of transmissions of the same segment
- reaches or exceeds threshold R1, pass negative advice
- (see Section 3.3.1.4) to the IP layer, to trigger
- dead-gateway diagnosis.
-
- (c) When the number of transmissions of the same segment
- reaches a threshold R2 greater than R1, close the
- connection.
-
- (d) An application MUST be able to set the value for R2 for
- a particular connection. For example, an interactive
- application might set R2 to "infinity," giving the user
- control over when to disconnect.
-
-
-
-
-Internet Engineering Task Force [Page 100]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- (d) TCP SHOULD inform the application of the delivery
- problem (unless such information has been disabled by
- the application; see Section 4.2.4.1), when R1 is
- reached and before R2. This will allow a remote login
- (User Telnet) application program to inform the user,
- for example.
-
- The value of R1 SHOULD correspond to at least 3
- retransmissions, at the current RTO. The value of R2 SHOULD
- correspond to at least 100 seconds.
-
- An attempt to open a TCP connection could fail with
- excessive retransmissions of the SYN segment or by receipt
- of a RST segment or an ICMP Port Unreachable. SYN
- retransmissions MUST be handled in the general way just
- described for data retransmissions, including notification
- of the application layer.
-
- However, the values of R1 and R2 may be different for SYN
- and data segments. In particular, R2 for a SYN segment MUST
- be set large enough to provide retransmission of the segment
- for at least 3 minutes. The application can close the
- connection (i.e., give up on the open attempt) sooner, of
- course.
-
- DISCUSSION:
- Some Internet paths have significant setup times, and
- the number of such paths is likely to increase in the
- future.
-
- 4.2.3.6 TCP Keep-Alives
-
- Implementors MAY include "keep-alives" in their TCP
- implementations, although this practice is not universally
- accepted. If keep-alives are included, the application MUST
- be able to turn them on or off for each TCP connection, and
- they MUST default to off.
-
- Keep-alive packets MUST only be sent when no data or
- acknowledgement packets have been received for the
- connection within an interval. This interval MUST be
- configurable and MUST default to no less than two hours.
-
- It is extremely important to remember that ACK segments that
- contain no data are not reliably transmitted by TCP.
- Consequently, if a keep-alive mechanism is implemented it
- MUST NOT interpret failure to respond to any specific probe
- as a dead connection.
-
-
-
-Internet Engineering Task Force [Page 101]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- An implementation SHOULD send a keep-alive segment with no
- data; however, it MAY be configurable to send a keep-alive
- segment containing one garbage octet, for compatibility with
- erroneous TCP implementations.
-
- DISCUSSION:
- A "keep-alive" mechanism periodically probes the other
- end of a connection when the connection is otherwise
- idle, even when there is no data to be sent. The TCP
- specification does not include a keep-alive mechanism
- because it could: (1) cause perfectly good connections
- to break during transient Internet failures; (2)
- consume unnecessary bandwidth ("if no one is using the
- connection, who cares if it is still good?"); and (3)
- cost money for an Internet path that charges for
- packets.
-
- Some TCP implementations, however, have included a
- keep-alive mechanism. To confirm that an idle
- connection is still active, these implementations send
- a probe segment designed to elicit a response from the
- peer TCP. Such a segment generally contains SEG.SEQ =
- SND.NXT-1 and may or may not contain one garbage octet
- of data. Note that on a quiet connection SND.NXT =
- RCV.NXT, so that this SEG.SEQ will be outside the
- window. Therefore, the probe causes the receiver to
- return an acknowledgment segment, confirming that the
- connection is still live. If the peer has dropped the
- connection due to a network partition or a crash, it
- will respond with a RST instead of an acknowledgment
- segment.
-
- Unfortunately, some misbehaved TCP implementations fail
- to respond to a segment with SEG.SEQ = SND.NXT-1 unless
- the segment contains data. Alternatively, an
- implementation could determine whether a peer responded
- correctly to keep-alive packets with no garbage data
- octet.
-
- A TCP keep-alive mechanism should only be invoked in
- server applications that might otherwise hang
- indefinitely and consume resources unnecessarily if a
- client crashes or aborts a connection during a network
- failure.
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 102]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- 4.2.3.7 TCP Multihoming
-
- If an application on a multihomed host does not specify the
- local IP address when actively opening a TCP connection,
- then the TCP MUST ask the IP layer to select a local IP
- address before sending the (first) SYN. See the function
- GET_SRCADDR() in Section 3.4.
-
- At all other times, a previous segment has either been sent
- or received on this connection, and TCP MUST use the same
- local address is used that was used in those previous
- segments.
-
- 4.2.3.8 IP Options
-
- When received options are passed up to TCP from the IP
- layer, TCP MUST ignore options that it does not understand.
-
- A TCP MAY support the Time Stamp and Record Route options.
-
- An application MUST be able to specify a source route when
- it actively opens a TCP connection, and this MUST take
- precedence over a source route received in a datagram.
-
- When a TCP connection is OPENed passively and a packet
- arrives with a completed IP Source Route option (containing
- a return route), TCP MUST save the return route and use it
- for all segments sent on this connection. If a different
- source route arrives in a later segment, the later
- definition SHOULD override the earlier one.
-
- 4.2.3.9 ICMP Messages
-
- TCP MUST act on an ICMP error message passed up from the IP
- layer, directing it to the connection that created the
- error. The necessary demultiplexing information can be
- found in the IP header contained within the ICMP message.
-
- o Source Quench
-
- TCP MUST react to a Source Quench by slowing
- transmission on the connection. The RECOMMENDED
- procedure is for a Source Quench to trigger a "slow
- start," as if a retransmission timeout had occurred.
-
- o Destination Unreachable -- codes 0, 1, 5
-
- Since these Unreachable messages indicate soft error
-
-
-
-Internet Engineering Task Force [Page 103]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- conditions, TCP MUST NOT abort the connection, and it
- SHOULD make the information available to the
- application.
-
- DISCUSSION:
- TCP could report the soft error condition directly
- to the application layer with an upcall to the
- ERROR_REPORT routine, or it could merely note the
- message and report it to the application only when
- and if the TCP connection times out.
-
- o Destination Unreachable -- codes 2-4
-
- These are hard error conditions, so TCP SHOULD abort
- the connection.
-
- o Time Exceeded -- codes 0, 1
-
- This should be handled the same way as Destination
- Unreachable codes 0, 1, 5 (see above).
-
- o Parameter Problem
-
- This should be handled the same way as Destination
- Unreachable codes 0, 1, 5 (see above).
-
-
- 4.2.3.10 Remote Address Validation
-
- A TCP implementation MUST reject as an error a local OPEN
- call for an invalid remote IP address (e.g., a broadcast or
- multicast address).
-
- An incoming SYN with an invalid source address must be
- ignored either by TCP or by the IP layer (see Section
- 3.2.1.3).
-
- A TCP implementation MUST silently discard an incoming SYN
- segment that is addressed to a broadcast or multicast
- address.
-
- 4.2.3.11 TCP Traffic Patterns
-
- IMPLEMENTATION:
- The TCP protocol specification [TCP:1] gives the
- implementor much freedom in designing the algorithms
- that control the message flow over the connection --
- packetizing, managing the window, sending
-
-
-
-Internet Engineering Task Force [Page 104]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- acknowledgments, etc. These design decisions are
- difficult because a TCP must adapt to a wide range of
- traffic patterns. Experience has shown that a TCP
- implementor needs to verify the design on two extreme
- traffic patterns:
-
- o Single-character Segments
-
- Even if the sender is using the Nagle Algorithm,
- when a TCP connection carries remote login traffic
- across a low-delay LAN the receiver will generally
- get a stream of single-character segments. If
- remote terminal echo mode is in effect, the
- receiver's system will generally echo each
- character as it is received.
-
- o Bulk Transfer
-
- When TCP is used for bulk transfer, the data
- stream should be made up (almost) entirely of
- segments of the size of the effective MSS.
- Although TCP uses a sequence number space with
- byte (octet) granularity, in bulk-transfer mode
- its operation should be as if TCP used a sequence
- space that counted only segments.
-
- Experience has furthermore shown that a single TCP can
- effectively and efficiently handle these two extremes.
-
- The most important tool for verifying a new TCP
- implementation is a packet trace program. There is a
- large volume of experience showing the importance of
- tracing a variety of traffic patterns with other TCP
- implementations and studying the results carefully.
-
-
- 4.2.3.12 Efficiency
-
- IMPLEMENTATION:
- Extensive experience has led to the following
- suggestions for efficient implementation of TCP:
-
- (a) Don't Copy Data
-
- In bulk data transfer, the primary CPU-intensive
- tasks are copying data from one place to another
- and checksumming the data. It is vital to
- minimize the number of copies of TCP data. Since
-
-
-
-Internet Engineering Task Force [Page 105]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- the ultimate speed limitation may be fetching data
- across the memory bus, it may be useful to combine
- the copy with checksumming, doing both with a
- single memory fetch.
-
- (b) Hand-Craft the Checksum Routine
-
- A good TCP checksumming routine is typically two
- to five times faster than a simple and direct
- implementation of the definition. Great care and
- clever coding are often required and advisable to
- make the checksumming code "blazing fast". See
- [TCP:10].
-
- (c) Code for the Common Case
-
- TCP protocol processing can be complicated, but
- for most segments there are only a few simple
- decisions to be made. Per-segment processing will
- be greatly speeded up by coding the main line to
- minimize the number of decisions in the most
- common case.
-
-
- 4.2.4 TCP/APPLICATION LAYER INTERFACE
-
- 4.2.4.1 Asynchronous Reports
-
- There MUST be a mechanism for reporting soft TCP error
- conditions to the application. Generically, we assume this
- takes the form of an application-supplied ERROR_REPORT
- routine that may be upcalled [INTRO:7] asynchronously from
- the transport layer:
-
- ERROR_REPORT(local connection name, reason, subreason)
-
- The precise encoding of the reason and subreason parameters
- is not specified here. However, the conditions that are
- reported asynchronously to the application MUST include:
-
- * ICMP error message arrived (see 4.2.3.9)
-
- * Excessive retransmissions (see 4.2.3.5)
-
- * Urgent pointer advance (see 4.2.2.4).
-
- However, an application program that does not want to
- receive such ERROR_REPORT calls SHOULD be able to
-
-
-
-Internet Engineering Task Force [Page 106]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- effectively disable these calls.
-
- DISCUSSION:
- These error reports generally reflect soft errors that
- can be ignored without harm by many applications. It
- has been suggested that these error report calls should
- default to "disabled," but this is not required.
-
- 4.2.4.2 Type-of-Service
-
- The application layer MUST be able to specify the Type-of-
- Service (TOS) for segments that are sent on a connection.
- It not required, but the application SHOULD be able to
- change the TOS during the connection lifetime. TCP SHOULD
- pass the current TOS value without change to the IP layer,
- when it sends segments on the connection.
-
- The TOS will be specified independently in each direction on
- the connection, so that the receiver application will
- specify the TOS used for ACK segments.
-
- TCP MAY pass the most recently received TOS up to the
- application.
-
- DISCUSSION
- Some applications (e.g., SMTP) change the nature of
- their communication during the lifetime of a
- connection, and therefore would like to change the TOS
- specification.
-
- Note also that the OPEN call specified in RFC-793
- includes a parameter ("options") in which the caller
- can specify IP options such as source route, record
- route, or timestamp.
-
- 4.2.4.3 Flush Call
-
- Some TCP implementations have included a FLUSH call, which
- will empty the TCP send queue of any data for which the user
- has issued SEND calls but which is still to the right of the
- current send window. That is, it flushes as much queued
- send data as possible without losing sequence number
- synchronization. This is useful for implementing the "abort
- output" function of Telnet.
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 107]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- 4.2.4.4 Multihoming
-
- The user interface outlined in sections 2.7 and 3.8 of RFC-
- 793 needs to be extended for multihoming. The OPEN call
- MUST have an optional parameter:
-
- OPEN( ... [local IP address,] ... )
-
- to allow the specification of the local IP address.
-
- DISCUSSION:
- Some TCP-based applications need to specify the local
- IP address to be used to open a particular connection;
- FTP is an example.
-
- IMPLEMENTATION:
- A passive OPEN call with a specified "local IP address"
- parameter will await an incoming connection request to
- that address. If the parameter is unspecified, a
- passive OPEN will await an incoming connection request
- to any local IP address, and then bind the local IP
- address of the connection to the particular address
- that is used.
-
- For an active OPEN call, a specified "local IP address"
- parameter will be used for opening the connection. If
- the parameter is unspecified, the networking software
- will choose an appropriate local IP address (see
- Section 3.3.4.2) for the connection
-
- 4.2.5 TCP REQUIREMENT SUMMARY
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
- | | | | | | |
-Push flag | | | | | | |
- Aggregate or queue un-pushed data |4.2.2.2 | | |x| | |
- Sender collapse successive PSH flags |4.2.2.2 | |x| | | |
- SEND call can specify PUSH |4.2.2.2 | | |x| | |
-
-
-
-Internet Engineering Task Force [Page 108]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- If cannot: sender buffer indefinitely |4.2.2.2 | | | | |x|
- If cannot: PSH last segment |4.2.2.2 |x| | | | |
- Notify receiving ALP of PSH |4.2.2.2 | | |x| | |1
- Send max size segment when possible |4.2.2.2 | |x| | | |
- | | | | | | |
-Window | | | | | | |
- Treat as unsigned number |4.2.2.3 |x| | | | |
- Handle as 32-bit number |4.2.2.3 | |x| | | |
- Shrink window from right |4.2.2.16| | | |x| |
- Robust against shrinking window |4.2.2.16|x| | | | |
- Receiver's window closed indefinitely |4.2.2.17| | |x| | |
- Sender probe zero window |4.2.2.17|x| | | | |
- First probe after RTO |4.2.2.17| |x| | | |
- Exponential backoff |4.2.2.17| |x| | | |
- Allow window stay zero indefinitely |4.2.2.17|x| | | | |
- Sender timeout OK conn with zero wind |4.2.2.17| | | | |x|
- | | | | | | |
-Urgent Data | | | | | | |
- Pointer points to last octet |4.2.2.4 |x| | | | |
- Arbitrary length urgent data sequence |4.2.2.4 |x| | | | |
- Inform ALP asynchronously of urgent data |4.2.2.4 |x| | | | |1
- ALP can learn if/how much urgent data Q'd |4.2.2.4 |x| | | | |1
- | | | | | | |
-TCP Options | | | | | | |
- Receive TCP option in any segment |4.2.2.5 |x| | | | |
- Ignore unsupported options |4.2.2.5 |x| | | | |
- Cope with illegal option length |4.2.2.5 |x| | | | |
- Implement sending & receiving MSS option |4.2.2.6 |x| | | | |
- Send MSS option unless 536 |4.2.2.6 | |x| | | |
- Send MSS option always |4.2.2.6 | | |x| | |
- Send-MSS default is 536 |4.2.2.6 |x| | | | |
- Calculate effective send seg size |4.2.2.6 |x| | | | |
- | | | | | | |
-TCP Checksums | | | | | | |
- Sender compute checksum |4.2.2.7 |x| | | | |
- Receiver check checksum |4.2.2.7 |x| | | | |
- | | | | | | |
-Use clock-driven ISN selection |4.2.2.9 |x| | | | |
- | | | | | | |
-Opening Connections | | | | | | |
- Support simultaneous open attempts |4.2.2.10|x| | | | |
- SYN-RCVD remembers last state |4.2.2.11|x| | | | |
- Passive Open call interfere with others |4.2.2.18| | | | |x|
- Function: simultan. LISTENs for same port |4.2.2.18|x| | | | |
- Ask IP for src address for SYN if necc. |4.2.3.7 |x| | | | |
- Otherwise, use local addr of conn. |4.2.3.7 |x| | | | |
- OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x|
- Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | |
-
-
-
-Internet Engineering Task Force [Page 109]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- | | | | | | |
-Closing Connections | | | | | | |
- RST can contain data |4.2.2.12| |x| | | |
- Inform application of aborted conn |4.2.2.13|x| | | | |
- Half-duplex close connections |4.2.2.13| | |x| | |
- Send RST to indicate data lost |4.2.2.13| |x| | | |
- In TIME-WAIT state for 2xMSL seconds |4.2.2.13|x| | | | |
- Accept SYN from TIME-WAIT state |4.2.2.13| | |x| | |
- | | | | | | |
-Retransmissions | | | | | | |
- Jacobson Slow Start algorithm |4.2.2.15|x| | | | |
- Jacobson Congestion-Avoidance algorithm |4.2.2.15|x| | | | |
- Retransmit with same IP ident |4.2.2.15| | |x| | |
- Karn's algorithm |4.2.3.1 |x| | | | |
- Jacobson's RTO estimation alg. |4.2.3.1 |x| | | | |
- Exponential backoff |4.2.3.1 |x| | | | |
- SYN RTO calc same as data |4.2.3.1 | |x| | | |
- Recommended initial values and bounds |4.2.3.1 | |x| | | |
- | | | | | | |
-Generating ACK's: | | | | | | |
- Queue out-of-order segments |4.2.2.20| |x| | | |
- Process all Q'd before send ACK |4.2.2.20|x| | | | |
- Send ACK for out-of-order segment |4.2.2.21| | |x| | |
- Delayed ACK's |4.2.3.2 | |x| | | |
- Delay < 0.5 seconds |4.2.3.2 |x| | | | |
- Every 2nd full-sized segment ACK'd |4.2.3.2 |x| | | | |
- Receiver SWS-Avoidance Algorithm |4.2.3.3 |x| | | | |
- | | | | | | |
-Sending data | | | | | | |
- Configurable TTL |4.2.2.19|x| | | | |
- Sender SWS-Avoidance Algorithm |4.2.3.4 |x| | | | |
- Nagle algorithm |4.2.3.4 | |x| | | |
- Application can disable Nagle algorithm |4.2.3.4 |x| | | | |
- | | | | | | |
-Connection Failures: | | | | | | |
- Negative advice to IP on R1 retxs |4.2.3.5 |x| | | | |
- Close connection on R2 retxs |4.2.3.5 |x| | | | |
- ALP can set R2 |4.2.3.5 |x| | | | |1
- Inform ALP of R1<=retxs<R2 |4.2.3.5 | |x| | | |1
- Recommended values for R1, R2 |4.2.3.5 | |x| | | |
- Same mechanism for SYNs |4.2.3.5 |x| | | | |
- R2 at least 3 minutes for SYN |4.2.3.5 |x| | | | |
- | | | | | | |
-Send Keep-alive Packets: |4.2.3.6 | | |x| | |
- - Application can request |4.2.3.6 |x| | | | |
- - Default is "off" |4.2.3.6 |x| | | | |
- - Only send if idle for interval |4.2.3.6 |x| | | | |
- - Interval configurable |4.2.3.6 |x| | | | |
-
-
-
-Internet Engineering Task Force [Page 110]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- - Default at least 2 hrs. |4.2.3.6 |x| | | | |
- - Tolerant of lost ACK's |4.2.3.6 |x| | | | |
- | | | | | | |
-IP Options | | | | | | |
- Ignore options TCP doesn't understand |4.2.3.8 |x| | | | |
- Time Stamp support |4.2.3.8 | | |x| | |
- Record Route support |4.2.3.8 | | |x| | |
- Source Route: | | | | | | |
- ALP can specify |4.2.3.8 |x| | | | |1
- Overrides src rt in datagram |4.2.3.8 |x| | | | |
- Build return route from src rt |4.2.3.8 |x| | | | |
- Later src route overrides |4.2.3.8 | |x| | | |
- | | | | | | |
-Receiving ICMP Messages from IP |4.2.3.9 |x| | | | |
- Dest. Unreach (0,1,5) => inform ALP |4.2.3.9 | |x| | | |
- Dest. Unreach (0,1,5) => abort conn |4.2.3.9 | | | | |x|
- Dest. Unreach (2-4) => abort conn |4.2.3.9 | |x| | | |
- Source Quench => slow start |4.2.3.9 | |x| | | |
- Time Exceeded => tell ALP, don't abort |4.2.3.9 | |x| | | |
- Param Problem => tell ALP, don't abort |4.2.3.9 | |x| | | |
- | | | | | | |
-Address Validation | | | | | | |
- Reject OPEN call to invalid IP address |4.2.3.10|x| | | | |
- Reject SYN from invalid IP address |4.2.3.10|x| | | | |
- Silently discard SYN to bcast/mcast addr |4.2.3.10|x| | | | |
- | | | | | | |
-TCP/ALP Interface Services | | | | | | |
- Error Report mechanism |4.2.4.1 |x| | | | |
- ALP can disable Error Report Routine |4.2.4.1 | |x| | | |
- ALP can specify TOS for sending |4.2.4.2 |x| | | | |
- Passed unchanged to IP |4.2.4.2 | |x| | | |
- ALP can change TOS during connection |4.2.4.2 | |x| | | |
- Pass received TOS up to ALP |4.2.4.2 | | |x| | |
- FLUSH call |4.2.4.3 | | |x| | |
- Optional local IP addr parm. in OPEN |4.2.4.4 |x| | | | |
--------------------------------------------------|--------|-|-|-|-|-|--
--------------------------------------------------|--------|-|-|-|-|-|--
-
-FOOTNOTES:
-
-(1) "ALP" means Application-Layer program.
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 111]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
-5. REFERENCES
-
-INTRODUCTORY REFERENCES
-
-
-[INTRO:1] "Requirements for Internet Hosts -- Application and Support,"
- IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,
- October 1989.
-
-[INTRO:2] "Requirements for Internet Gateways," R. Braden and J.
- Postel, RFC-1009, June 1987.
-
-[INTRO:3] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
- (three volumes), SRI International, December 1985.
-
-[INTRO:4] "Official Internet Protocols," J. Reynolds and J. Postel,
- RFC-1011, May 1987.
-
- This document is republished periodically with new RFC numbers; the
- latest version must be used.
-
-[INTRO:5] "Protocol Document Order Information," O. Jacobsen and J.
- Postel, RFC-980, March 1986.
-
-[INTRO:6] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May
- 1987.
-
- This document is republished periodically with new RFC numbers; the
- latest version must be used.
-
-[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D.
- Clark, RFC-817, July 1982.
-
-[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM
- SOSP, Orcas Island, Washington, December 1985.
-
-
-Secondary References:
-
-
-[INTRO:9] "A Protocol for Packet Network Intercommunication," V. Cerf
- and R. Kahn, IEEE Transactions on Communication, May 1974.
-
-[INTRO:10] "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D.
- Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
-
-[INTRO:11] "The DARPA Internet Protocol Suite," B. Leiner, J. Postel,
- R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,
-
-
-
-Internet Engineering Task Force [Page 112]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- March 1985. Also in: IEEE Communications Magazine, March 1985.
- Also available as ISI-RS-85-153.
-
-[INTRO:12] "Final Text of DIS8473, Protocol for Providing the
- Connectionless Mode Network Service," ANSI, published as RFC-994,
- March 1986.
-
-[INTRO:13] "End System to Intermediate System Routing Exchange
- Protocol," ANSI X3S3.3, published as RFC-995, April 1986.
-
-
-LINK LAYER REFERENCES
-
-
-[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893,
- April 1984.
-
-[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
- November 1982.
-
-[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet
- Networks," C. Hornig, RFC-894, April 1984.
-
-[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802
- "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988.
-
- This RFC contains a great deal of information of importance to
- Internet implementers planning to use IEEE 802 networks.
-
-
-IP LAYER REFERENCES
-
-
-[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981.
-
-[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792,
- September 1981.
-
-[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel,
- RFC-950, August 1985.
-
-[IP:4] "Host Extensions for IP Multicasting," S. Deering, RFC-1112,
- August 1989.
-
-[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department
- of Defense, August 1983.
-
- This specification, as amended by RFC-963, is intended to describe
-
-
-
-Internet Engineering Task Force [Page 113]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
- the Internet Protocol but has some serious omissions (e.g., the
- mandatory subnet extension [IP:3] and the optional multicasting
- extension [IP:4]). It is also out of date. If there is a
- conflict, RFC-791, RFC-792, and RFC-950 must be taken as
- authoritative, while the present document is authoritative over
- all.
-
-[IP:6] "Some Problems with the Specification of the Military Standard
- Internet Protocol," D. Sidhu, RFC-963, November 1985.
-
-[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel,
- RFC-879, November 1983.
-
- Discusses and clarifies the relationship between the TCP Maximum
- Segment Size option and the IP datagram size.
-
-[IP:8] "Internet Protocol Security Options," B. Schofield, RFC-1108,
- October 1989.
-
-[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM
- SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol.
- 17, no. 5.
-
- This useful paper discusses the problems created by Internet
- fragmentation and presents alternative solutions.
-
-[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July
- 1982.
-
- This and the following paper should be read by every implementor.
-
-[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.
-
-SECONDARY IP REFERENCES:
-
-
-[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J.
- Mogul, RFC-922, October 1984.
-
-[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July
- 1982.
-
-[IP:14] "Something a Host Could Do with Source Quench: The Source Quench
- Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July
- 1987.
-
- This RFC first described directed broadcast addresses. However,
- the bulk of the RFC is concerned with gateways, not hosts.
-
-
-
-Internet Engineering Task Force [Page 114]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
-UDP REFERENCES:
-
-
-[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.
-
-
-TCP REFERENCES:
-
-
-[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September
- 1981.
-
-
-[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of
- Defense, August 1984.
-
- This specification as amended by RFC-964 is intended to describe
- the same protocol as RFC-793 [TCP:1]. If there is a conflict,
- RFC-793 takes precedence, and the present document is authoritative
- over both.
-
-
-[TCP:3] "Some Problems with the Specification of the Military Standard
- Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964,
- November 1985.
-
-
-[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel,
- RFC-879, November 1983.
-
-
-[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813,
- July 1982.
-
-
-[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
- SIGCOMM-87, August 1987.
-
-
-[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
- August 1988.
-
-
-SECONDARY TCP REFERENCES:
-
-
-[TCP:8] "Modularity and Efficiency in Protocol Implementation," D.
- Clark, RFC-817, July 1982.
-
-
-
-Internet Engineering Task Force [Page 115]
-
-
-
-
-RFC1122 TRANSPORT LAYER -- TCP October 1989
-
-
-[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.
-
-
-[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C.
- Partridge, RFC-1071, September 1988.
-
-
-[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden,
- RFC-1072, October 1988.
-
-
-Security Considerations
-
- There are many security issues in the communication layers of host
- software, but a full discussion is beyond the scope of this RFC.
-
- The Internet architecture generally provides little protection
- against spoofing of IP source addresses, so any security mechanism
- that is based upon verifying the IP source address of a datagram
- should be treated with suspicion. However, in restricted
- environments some source-address checking may be possible. For
- example, there might be a secure LAN whose gateway to the rest of the
- Internet discarded any incoming datagram with a source address that
- spoofed the LAN address. In this case, a host on the LAN could use
- the source address to test for local vs. remote source. This problem
- is complicated by source routing, and some have suggested that
- source-routed datagram forwarding by hosts (see Section 3.3.5) should
- be outlawed for security reasons.
-
- Security-related issues are mentioned in sections concerning the IP
- Security option (Section 3.2.1.8), the ICMP Parameter Problem message
- (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and
- reserved TCP ports (Section 4.2.2.1).
-
-Author's Address
-
- Robert Braden
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA 90292-6695
-
- Phone: (213) 822 1511
-
- EMail: Braden@ISI.EDU
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 116]
-
diff --git a/contrib/bind9/doc/rfc/rfc1123.txt b/contrib/bind9/doc/rfc/rfc1123.txt
deleted file mode 100644
index 51cdf83c98444..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1123.txt
+++ /dev/null
@@ -1,5782 +0,0 @@
-
-
-
-
-
-
-Network Working Group Internet Engineering Task Force
-Request for Comments: 1123 R. Braden, Editor
- October 1989
-
-
- Requirements for Internet Hosts -- Application and Support
-
-Status of This Memo
-
- This RFC is an official specification for the Internet community. It
- incorporates by reference, amends, corrects, and supplements the
- primary protocol standards documents relating to hosts. Distribution
- of this document is unlimited.
-
-Summary
-
- This RFC is one of a pair that defines and discusses the requirements
- for Internet host software. This RFC covers the application and
- support protocols; its companion RFC-1122 covers the communication
- protocol layers: link layer, IP layer, and transport layer.
-
-
-
- Table of Contents
-
-
-
-
- 1. INTRODUCTION ............................................... 5
- 1.1 The Internet Architecture .............................. 6
- 1.2 General Considerations ................................. 6
- 1.2.1 Continuing Internet Evolution ..................... 6
- 1.2.2 Robustness Principle .............................. 7
- 1.2.3 Error Logging ..................................... 8
- 1.2.4 Configuration ..................................... 8
- 1.3 Reading this Document .................................. 10
- 1.3.1 Organization ...................................... 10
- 1.3.2 Requirements ...................................... 10
- 1.3.3 Terminology ....................................... 11
- 1.4 Acknowledgments ........................................ 12
-
- 2. GENERAL ISSUES ............................................. 13
- 2.1 Host Names and Numbers ................................. 13
- 2.2 Using Domain Name Service .............................. 13
- 2.3 Applications on Multihomed hosts ....................... 14
- 2.4 Type-of-Service ........................................ 14
- 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15
-
-
-
-
-Internet Engineering Task Force [Page 1]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16
- 3.1 INTRODUCTION ........................................... 16
- 3.2 PROTOCOL WALK-THROUGH .................................. 16
- 3.2.1 Option Negotiation ................................ 16
- 3.2.2 Telnet Go-Ahead Function .......................... 16
- 3.2.3 Control Functions ................................. 17
- 3.2.4 Telnet "Synch" Signal ............................. 18
- 3.2.5 NVT Printer and Keyboard .......................... 19
- 3.2.6 Telnet Command Structure .......................... 20
- 3.2.7 Telnet Binary Option .............................. 20
- 3.2.8 Telnet Terminal-Type Option ....................... 20
- 3.3 SPECIFIC ISSUES ........................................ 21
- 3.3.1 Telnet End-of-Line Convention ..................... 21
- 3.3.2 Data Entry Terminals .............................. 23
- 3.3.3 Option Requirements ............................... 24
- 3.3.4 Option Initiation ................................. 24
- 3.3.5 Telnet Linemode Option ............................ 25
- 3.4 TELNET/USER INTERFACE .................................. 25
- 3.4.1 Character Set Transparency ........................ 25
- 3.4.2 Telnet Commands ................................... 26
- 3.4.3 TCP Connection Errors ............................. 26
- 3.4.4 Non-Default Telnet Contact Port ................... 26
- 3.4.5 Flushing Output ................................... 26
- 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27
-
- 4. FILE TRANSFER .............................................. 29
- 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29
- 4.1.1 INTRODUCTION ...................................... 29
- 4.1.2. PROTOCOL WALK-THROUGH ............................ 29
- 4.1.2.1 LOCAL Type ................................... 29
- 4.1.2.2 Telnet Format Control ........................ 30
- 4.1.2.3 Page Structure ............................... 30
- 4.1.2.4 Data Structure Transformations ............... 30
- 4.1.2.5 Data Connection Management ................... 31
- 4.1.2.6 PASV Command ................................. 31
- 4.1.2.7 LIST and NLST Commands ....................... 31
- 4.1.2.8 SITE Command ................................. 32
- 4.1.2.9 STOU Command ................................. 32
- 4.1.2.10 Telnet End-of-line Code ..................... 32
- 4.1.2.11 FTP Replies ................................. 33
- 4.1.2.12 Connections ................................. 34
- 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34
- 4.1.3 SPECIFIC ISSUES ................................... 35
- 4.1.3.1 Non-standard Command Verbs ................... 35
- 4.1.3.2 Idle Timeout ................................. 36
- 4.1.3.3 Concurrency of Data and Control .............. 36
- 4.1.3.4 FTP Restart Mechanism ........................ 36
- 4.1.4 FTP/USER INTERFACE ................................ 39
-
-
-
-Internet Engineering Task Force [Page 2]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- 4.1.4.1 Pathname Specification ....................... 39
- 4.1.4.2 "QUOTE" Command .............................. 40
- 4.1.4.3 Displaying Replies to User ................... 40
- 4.1.4.4 Maintaining Synchronization .................. 40
- 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41
- 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44
- 4.2.1 INTRODUCTION ...................................... 44
- 4.2.2 PROTOCOL WALK-THROUGH ............................. 44
- 4.2.2.1 Transfer Modes ............................... 44
- 4.2.2.2 UDP Header ................................... 44
- 4.2.3 SPECIFIC ISSUES ................................... 44
- 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44
- 4.2.3.2 Timeout Algorithms ........................... 46
- 4.2.3.3 Extensions ................................... 46
- 4.2.3.4 Access Control ............................... 46
- 4.2.3.5 Broadcast Request ............................ 46
- 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47
-
- 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48
- 5.1 INTRODUCTION ........................................... 48
- 5.2 PROTOCOL WALK-THROUGH .................................. 48
- 5.2.1 The SMTP Model .................................... 48
- 5.2.2 Canonicalization .................................. 49
- 5.2.3 VRFY and EXPN Commands ............................ 50
- 5.2.4 SEND, SOML, and SAML Commands ..................... 50
- 5.2.5 HELO Command ...................................... 50
- 5.2.6 Mail Relay ........................................ 51
- 5.2.7 RCPT Command ...................................... 52
- 5.2.8 DATA Command ...................................... 53
- 5.2.9 Command Syntax .................................... 54
- 5.2.10 SMTP Replies ..................................... 54
- 5.2.11 Transparency ..................................... 55
- 5.2.12 WKS Use in MX Processing ......................... 55
- 5.2.13 RFC-822 Message Specification .................... 55
- 5.2.14 RFC-822 Date and Time Specification .............. 55
- 5.2.15 RFC-822 Syntax Change ............................ 56
- 5.2.16 RFC-822 Local-part .............................. 56
- 5.2.17 Domain Literals .................................. 57
- 5.2.18 Common Address Formatting Errors ................. 58
- 5.2.19 Explicit Source Routes ........................... 58
- 5.3 SPECIFIC ISSUES ........................................ 59
- 5.3.1 SMTP Queueing Strategies .......................... 59
- 5.3.1.1 Sending Strategy .............................. 59
- 5.3.1.2 Receiving strategy ........................... 61
- 5.3.2 Timeouts in SMTP .................................. 61
- 5.3.3 Reliable Mail Receipt ............................. 63
- 5.3.4 Reliable Mail Transmission ........................ 63
- 5.3.5 Domain Name Support ............................... 65
-
-
-
-Internet Engineering Task Force [Page 3]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- 5.3.6 Mailing Lists and Aliases ......................... 65
- 5.3.7 Mail Gatewaying ................................... 66
- 5.3.8 Maximum Message Size .............................. 68
- 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69
-
- 6. SUPPORT SERVICES ............................................ 72
- 6.1 DOMAIN NAME TRANSLATION ................................. 72
- 6.1.1 INTRODUCTION ....................................... 72
- 6.1.2 PROTOCOL WALK-THROUGH ............................. 72
- 6.1.2.1 Resource Records with Zero TTL ............... 73
- 6.1.2.2 QCLASS Values ................................ 73
- 6.1.2.3 Unused Fields ................................ 73
- 6.1.2.4 Compression .................................. 73
- 6.1.2.5 Misusing Configuration Info .................. 73
- 6.1.3 SPECIFIC ISSUES ................................... 74
- 6.1.3.1 Resolver Implementation ...................... 74
- 6.1.3.2 Transport Protocols .......................... 75
- 6.1.3.3 Efficient Resource Usage ..................... 77
- 6.1.3.4 Multihomed Hosts ............................. 78
- 6.1.3.5 Extensibility ................................ 79
- 6.1.3.6 Status of RR Types ........................... 79
- 6.1.3.7 Robustness ................................... 80
- 6.1.3.8 Local Host Table ............................. 80
- 6.1.4 DNS USER INTERFACE ................................ 81
- 6.1.4.1 DNS Administration ........................... 81
- 6.1.4.2 DNS User Interface ........................... 81
- 6.1.4.3 Interface Abbreviation Facilities ............. 82
- 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84
- 6.2 HOST INITIALIZATION .................................... 87
- 6.2.1 INTRODUCTION ...................................... 87
- 6.2.2 REQUIREMENTS ...................................... 87
- 6.2.2.1 Dynamic Configuration ........................ 87
- 6.2.2.2 Loading Phase ................................ 89
- 6.3 REMOTE MANAGEMENT ...................................... 90
- 6.3.1 INTRODUCTION ...................................... 90
- 6.3.2 PROTOCOL WALK-THROUGH ............................. 90
- 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92
-
- 7. REFERENCES ................................................. 93
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 4]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
-1. INTRODUCTION
-
- This document is one of a pair that defines and discusses the
- requirements for host system implementations of the Internet protocol
- suite. This RFC covers the applications layer and support protocols.
- Its companion RFC, "Requirements for Internet Hosts -- Communications
- Layers" [INTRO:1] covers the lower layer protocols: transport layer,
- IP layer, and link layer.
-
- These documents are intended to provide guidance for vendors,
- implementors, and users of Internet communication software. They
- represent the consensus of a large body of technical experience and
- wisdom, contributed by members of the Internet research and vendor
- communities.
-
- This RFC enumerates standard protocols that a host connected to the
- Internet must use, and it incorporates by reference the RFCs and
- other documents describing the current specifications for these
- protocols. It corrects errors in the referenced documents and adds
- additional discussion and guidance for an implementor.
-
- For each protocol, this document also contains an explicit set of
- requirements, recommendations, and options. The reader must
- understand that the list of requirements in this document is
- incomplete by itself; the complete set of requirements for an
- Internet host is primarily defined in the standard protocol
- specification documents, with the corrections, amendments, and
- supplements contained in this RFC.
-
- A good-faith implementation of the protocols that was produced after
- careful reading of the RFC's and with some interaction with the
- Internet technical community, and that followed good communications
- software engineering practices, should differ from the requirements
- of this document in only minor ways. Thus, in many cases, the
- "requirements" in this RFC are already stated or implied in the
- standard protocol documents, so that their inclusion here is, in a
- sense, redundant. However, they were included because some past
- implementation has made the wrong choice, causing problems of
- interoperability, performance, and/or robustness.
-
- This document includes discussion and explanation of many of the
- requirements and recommendations. A simple list of requirements
- would be dangerous, because:
-
- o Some required features are more important than others, and some
- features are optional.
-
- o There may be valid reasons why particular vendor products that
-
-
-
-Internet Engineering Task Force [Page 5]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- are designed for restricted contexts might choose to use
- different specifications.
-
- However, the specifications of this document must be followed to meet
- the general goal of arbitrary host interoperation across the
- diversity and complexity of the Internet system. Although most
- current implementations fail to meet these requirements in various
- ways, some minor and some major, this specification is the ideal
- towards which we need to move.
-
- These requirements are based on the current level of Internet
- architecture. This document will be updated as required to provide
- additional clarifications or to include additional information in
- those areas in which specifications are still evolving.
-
- This introductory section begins with general advice to host software
- vendors, and then gives some guidance on reading the rest of the
- document. Section 2 contains general requirements that may be
- applicable to all application and support protocols. Sections 3, 4,
- and 5 contain the requirements on protocols for the three major
- applications: Telnet, file transfer, and electronic mail,
- respectively. Section 6 covers the support applications: the domain
- name system, system initialization, and management. Finally, all
- references will be found in Section 7.
-
- 1.1 The Internet Architecture
-
- For a brief introduction to the Internet architecture from a host
- viewpoint, see Section 1.1 of [INTRO:1]. That section also
- contains recommended references for general background on the
- Internet architecture.
-
- 1.2 General Considerations
-
- There are two important lessons that vendors of Internet host
- software have learned and which a new vendor should consider
- seriously.
-
- 1.2.1 Continuing Internet Evolution
-
- The enormous growth of the Internet has revealed problems of
- management and scaling in a large datagram-based packet
- communication system. These problems are being addressed, and
- as a result there will be continuing evolution of the
- specifications described in this document. These changes will
- be carefully planned and controlled, since there is extensive
- participation in this planning by the vendors and by the
- organizations responsible for operations of the networks.
-
-
-
-Internet Engineering Task Force [Page 6]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- Development, evolution, and revision are characteristic of
- computer network protocols today, and this situation will
- persist for some years. A vendor who develops computer
- communication software for the Internet protocol suite (or any
- other protocol suite!) and then fails to maintain and update
- that software for changing specifications is going to leave a
- trail of unhappy customers. The Internet is a large
- communication network, and the users are in constant contact
- through it. Experience has shown that knowledge of
- deficiencies in vendor software propagates quickly through the
- Internet technical community.
-
- 1.2.2 Robustness Principle
-
- At every layer of the protocols, there is a general rule whose
- application can lead to enormous benefits in robustness and
- interoperability:
-
- "Be liberal in what you accept, and
- conservative in what you send"
-
- Software should be written to deal with every conceivable
- error, no matter how unlikely; sooner or later a packet will
- come in with that particular combination of errors and
- attributes, and unless the software is prepared, chaos can
- ensue. In general, it is best to assume that the network is
- filled with malevolent entities that will send in packets
- designed to have the worst possible effect. This assumption
- will lead to suitable protective design, although the most
- serious problems in the Internet have been caused by
- unenvisaged mechanisms triggered by low-probability events;
- mere human malice would never have taken so devious a course!
-
- Adaptability to change must be designed into all levels of
- Internet host software. As a simple example, consider a
- protocol specification that contains an enumeration of values
- for a particular header field -- e.g., a type field, a port
- number, or an error code; this enumeration must be assumed to
- be incomplete. Thus, if a protocol specification defines four
- possible error codes, the software must not break when a fifth
- code shows up. An undefined code might be logged (see below),
- but it must not cause a failure.
-
- The second part of the principle is almost as important:
- software on other hosts may contain deficiencies that make it
- unwise to exploit legal but obscure protocol features. It is
- unwise to stray far from the obvious and simple, lest untoward
- effects result elsewhere. A corollary of this is "watch out
-
-
-
-Internet Engineering Task Force [Page 7]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- for misbehaving hosts"; host software should be prepared, not
- just to survive other misbehaving hosts, but also to cooperate
- to limit the amount of disruption such hosts can cause to the
- shared communication facility.
-
- 1.2.3 Error Logging
-
- The Internet includes a great variety of host and gateway
- systems, each implementing many protocols and protocol layers,
- and some of these contain bugs and mis-features in their
- Internet protocol software. As a result of complexity,
- diversity, and distribution of function, the diagnosis of user
- problems is often very difficult.
-
- Problem diagnosis will be aided if host implementations include
- a carefully designed facility for logging erroneous or
- "strange" protocol events. It is important to include as much
- diagnostic information as possible when an error is logged. In
- particular, it is often useful to record the header(s) of a
- packet that caused an error. However, care must be taken to
- ensure that error logging does not consume prohibitive amounts
- of resources or otherwise interfere with the operation of the
- host.
-
- There is a tendency for abnormal but harmless protocol events
- to overflow error logging files; this can be avoided by using a
- "circular" log, or by enabling logging only while diagnosing a
- known failure. It may be useful to filter and count duplicate
- successive messages. One strategy that seems to work well is:
- (1) always count abnormalities and make such counts accessible
- through the management protocol (see Section 6.3); and (2)
- allow the logging of a great variety of events to be
- selectively enabled. For example, it might useful to be able
- to "log everything" or to "log everything for host X".
-
- Note that different managements may have differing policies
- about the amount of error logging that they want normally
- enabled in a host. Some will say, "if it doesn't hurt me, I
- don't want to know about it", while others will want to take a
- more watchful and aggressive attitude about detecting and
- removing protocol abnormalities.
-
- 1.2.4 Configuration
-
- It would be ideal if a host implementation of the Internet
- protocol suite could be entirely self-configuring. This would
- allow the whole suite to be implemented in ROM or cast into
- silicon, it would simplify diskless workstations, and it would
-
-
-
-Internet Engineering Task Force [Page 8]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- be an immense boon to harried LAN administrators as well as
- system vendors. We have not reached this ideal; in fact, we
- are not even close.
-
- At many points in this document, you will find a requirement
- that a parameter be a configurable option. There are several
- different reasons behind such requirements. In a few cases,
- there is current uncertainty or disagreement about the best
- value, and it may be necessary to update the recommended value
- in the future. In other cases, the value really depends on
- external factors -- e.g., the size of the host and the
- distribution of its communication load, or the speeds and
- topology of nearby networks -- and self-tuning algorithms are
- unavailable and may be insufficient. In some cases,
- configurability is needed because of administrative
- requirements.
-
- Finally, some configuration options are required to communicate
- with obsolete or incorrect implementations of the protocols,
- distributed without sources, that unfortunately persist in many
- parts of the Internet. To make correct systems coexist with
- these faulty systems, administrators often have to "mis-
- configure" the correct systems. This problem will correct
- itself gradually as the faulty systems are retired, but it
- cannot be ignored by vendors.
-
- When we say that a parameter must be configurable, we do not
- intend to require that its value be explicitly read from a
- configuration file at every boot time. We recommend that
- implementors set up a default for each parameter, so a
- configuration file is only necessary to override those defaults
- that are inappropriate in a particular installation. Thus, the
- configurability requirement is an assurance that it will be
- POSSIBLE to override the default when necessary, even in a
- binary-only or ROM-based product.
-
- This document requires a particular value for such defaults in
- some cases. The choice of default is a sensitive issue when
- the configuration item controls the accommodation to existing
- faulty systems. If the Internet is to converge successfully to
- complete interoperability, the default values built into
- implementations must implement the official protocol, not
- "mis-configurations" to accommodate faulty implementations.
- Although marketing considerations have led some vendors to
- choose mis-configuration defaults, we urge vendors to choose
- defaults that will conform to the standard.
-
- Finally, we note that a vendor needs to provide adequate
-
-
-
-Internet Engineering Task Force [Page 9]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- documentation on all configuration parameters, their limits and
- effects.
-
-
- 1.3 Reading this Document
-
- 1.3.1 Organization
-
- In general, each major section is organized into the following
- subsections:
-
- (1) Introduction
-
- (2) Protocol Walk-Through -- considers the protocol
- specification documents section-by-section, correcting
- errors, stating requirements that may be ambiguous or
- ill-defined, and providing further clarification or
- explanation.
-
- (3) Specific Issues -- discusses protocol design and
- implementation issues that were not included in the walk-
- through.
-
- (4) Interfaces -- discusses the service interface to the next
- higher layer.
-
- (5) Summary -- contains a summary of the requirements of the
- section.
-
- Under many of the individual topics in this document, there is
- parenthetical material labeled "DISCUSSION" or
- "IMPLEMENTATION". This material is intended to give
- clarification and explanation of the preceding requirements
- text. It also includes some suggestions on possible future
- directions or developments. The implementation material
- contains suggested approaches that an implementor may want to
- consider.
-
- The summary sections are intended to be guides and indexes to
- the text, but are necessarily cryptic and incomplete. The
- summaries should never be used or referenced separately from
- the complete RFC.
-
- 1.3.2 Requirements
-
- In this document, the words that are used to define the
- significance of each particular requirement are capitalized.
- These words are:
-
-
-
-Internet Engineering Task Force [Page 10]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- * "MUST"
-
- This word or the adjective "REQUIRED" means that the item
- is an absolute requirement of the specification.
-
- * "SHOULD"
-
- This word or the adjective "RECOMMENDED" means that there
- may exist valid reasons in particular circumstances to
- ignore this item, but the full implications should be
- understood and the case carefully weighed before choosing
- a different course.
-
- * "MAY"
-
- This word or the adjective "OPTIONAL" means that this item
- is truly optional. One vendor may choose to include the
- item because a particular marketplace requires it or
- because it enhances the product, for example; another
- vendor may omit the same item.
-
-
- An implementation is not compliant if it fails to satisfy one
- or more of the MUST requirements for the protocols it
- implements. An implementation that satisfies all the MUST and
- all the SHOULD requirements for its protocols is said to be
- "unconditionally compliant"; one that satisfies all the MUST
- requirements but not all the SHOULD requirements for its
- protocols is said to be "conditionally compliant".
-
- 1.3.3 Terminology
-
- This document uses the following technical terms:
-
- Segment
- A segment is the unit of end-to-end transmission in the
- TCP protocol. A segment consists of a TCP header followed
- by application data. A segment is transmitted by
- encapsulation in an IP datagram.
-
- Message
- This term is used by some application layer protocols
- (particularly SMTP) for an application data unit.
-
- Datagram
- A [UDP] datagram is the unit of end-to-end transmission in
- the UDP protocol.
-
-
-
-
-Internet Engineering Task Force [Page 11]
-
-
-
-
-RFC1123 INTRODUCTION October 1989
-
-
- Multihomed
- A host is said to be multihomed if it has multiple IP
- addresses to connected networks.
-
-
-
- 1.4 Acknowledgments
-
- This document incorporates contributions and comments from a large
- group of Internet protocol experts, including representatives of
- university and research labs, vendors, and government agencies.
- It was assembled primarily by the Host Requirements Working Group
- of the Internet Engineering Task Force (IETF).
-
- The Editor would especially like to acknowledge the tireless
- dedication of the following people, who attended many long
- meetings and generated 3 million bytes of electronic mail over the
- past 18 months in pursuit of this document: Philip Almquist, Dave
- Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
- Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
- John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
- Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
- (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
-
- In addition, the following people made major contributions to the
- effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
- (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
- Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
- John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
- Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
- (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
- Technology), and Mike StJohns (DCA). The following also made
- significant contributions to particular areas: Eric Allman
- (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
- (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
- (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
- (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
- Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
- (Toronto).
-
- We are grateful to all, including any contributors who may have
- been inadvertently omitted from this list.
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 12]
-
-
-
-
-RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
-
-
-2. GENERAL ISSUES
-
- This section contains general requirements that may be applicable to
- all application-layer protocols.
-
- 2.1 Host Names and Numbers
-
- The syntax of a legal Internet host name was specified in RFC-952
- [DNS:4]. One aspect of host name syntax is hereby changed: the
- restriction on the first character is relaxed to allow either a
- letter or a digit. Host software MUST support this more liberal
- syntax.
-
- Host software MUST handle host names of up to 63 characters and
- SHOULD handle host names of up to 255 characters.
-
- Whenever a user inputs the identity of an Internet host, it SHOULD
- be possible to enter either (1) a host domain name or (2) an IP
- address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
- the string syntactically for a dotted-decimal number before
- looking it up in the Domain Name System.
-
- DISCUSSION:
- This last requirement is not intended to specify the complete
- syntactic form for entering a dotted-decimal host number;
- that is considered to be a user-interface issue. For
- example, a dotted-decimal number must be enclosed within
- "[ ]" brackets for SMTP mail (see Section 5.2.17). This
- notation could be made universal within a host system,
- simplifying the syntactic checking for a dotted-decimal
- number.
-
- If a dotted-decimal number can be entered without such
- identifying delimiters, then a full syntactic check must be
- made, because a segment of a host domain name is now allowed
- to begin with a digit and could legally be entirely numeric
- (see Section 6.1.2.4). However, a valid host name can never
- have the dotted-decimal form #.#.#.#, since at least the
- highest-level component label will be alphabetic.
-
- 2.2 Using Domain Name Service
-
- Host domain names MUST be translated to IP addresses as described
- in Section 6.1.
-
- Applications using domain name services MUST be able to cope with
- soft error conditions. Applications MUST wait a reasonable
- interval between successive retries due to a soft error, and MUST
-
-
-
-Internet Engineering Task Force [Page 13]
-
-
-
-
-RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
-
-
- allow for the possibility that network problems may deny service
- for hours or even days.
-
- An application SHOULD NOT rely on the ability to locate a WKS
- record containing an accurate listing of all services at a
- particular host address, since the WKS RR type is not often used
- by Internet sites. To confirm that a service is present, simply
- attempt to use it.
-
- 2.3 Applications on Multihomed hosts
-
- When the remote host is multihomed, the name-to-address
- translation will return a list of alternative IP addresses. As
- specified in Section 6.1.3.4, this list should be in order of
- decreasing preference. Application protocol implementations
- SHOULD be prepared to try multiple addresses from the list until
- success is obtained. More specific requirements for SMTP are
- given in Section 5.3.4.
-
- When the local host is multihomed, a UDP-based request/response
- application SHOULD send the response with an IP source address
- that is the same as the specific destination address of the UDP
- request datagram. The "specific destination address" is defined
- in the "IP Addressing" section of the companion RFC [INTRO:1].
-
- Similarly, a server application that opens multiple TCP
- connections to the same client SHOULD use the same local IP
- address for all.
-
- 2.4 Type-of-Service
-
- Applications MUST select appropriate TOS values when they invoke
- transport layer services, and these values MUST be configurable.
- Note that a TOS value contains 5 bits, of which only the most-
- significant 3 bits are currently defined; the other two bits MUST
- be zero.
-
- DISCUSSION:
- As gateway algorithms are developed to implement Type-of-
- Service, the recommended values for various application
- protocols may change. In addition, it is likely that
- particular combinations of users and Internet paths will want
- non-standard TOS values. For these reasons, the TOS values
- must be configurable.
-
- See the latest version of the "Assigned Numbers" RFC
- [INTRO:5] for the recommended TOS values for the major
- application protocols.
-
-
-
-Internet Engineering Task Force [Page 14]
-
-
-
-
-RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
-
-
- 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
------------------------------------------------|----------|-|-|-|-|-|--
- | | | | | | |
-User interfaces: | | | | | | |
- Allow host name to begin with digit |2.1 |x| | | | |
- Host names of up to 635 characters |2.1 |x| | | | |
- Host names of up to 255 characters |2.1 | |x| | | |
- Support dotted-decimal host numbers |2.1 | |x| | | |
- Check syntactically for dotted-dec first |2.1 | |x| | | |
- | | | | | | |
-Map domain names per Section 6.1 |2.2 |x| | | | |
-Cope with soft DNS errors |2.2 |x| | | | |
- Reasonable interval between retries |2.2 |x| | | | |
- Allow for long outages |2.2 |x| | | | |
-Expect WKS records to be available |2.2 | | | |x| |
- | | | | | | |
-Try multiple addr's for remote multihomed host |2.3 | |x| | | |
-UDP reply src addr is specific dest of request |2.3 | |x| | | |
-Use same IP addr for related TCP connections |2.3 | |x| | | |
-Specify appropriate TOS values |2.4 |x| | | | |
- TOS values configurable |2.4 |x| | | | |
- Unused TOS bits zero |2.4 |x| | | | |
- | | | | | | |
- | | | | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 15]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
-3. REMOTE LOGIN -- TELNET PROTOCOL
-
- 3.1 INTRODUCTION
-
- Telnet is the standard Internet application protocol for remote
- login. It provides the encoding rules to link a user's
- keyboard/display on a client ("user") system with a command
- interpreter on a remote server system. A subset of the Telnet
- protocol is also incorporated within other application protocols,
- e.g., FTP and SMTP.
-
- Telnet uses a single TCP connection, and its normal data stream
- ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
- escape sequences to embed control functions. Telnet also allows
- the negotiation of many optional modes and functions.
-
- The primary Telnet specification is to be found in RFC-854
- [TELNET:1], while the options are defined in many other RFCs; see
- Section 7 for references.
-
- 3.2 PROTOCOL WALK-THROUGH
-
- 3.2.1 Option Negotiation: RFC-854, pp. 2-3
-
- Every Telnet implementation MUST include option negotiation and
- subnegotiation machinery [TELNET:2].
-
- A host MUST carefully follow the rules of RFC-854 to avoid
- option-negotiation loops. A host MUST refuse (i.e, reply
- WONT/DONT to a DO/WILL) an unsupported option. Option
- negotiation SHOULD continue to function (even if all requests
- are refused) throughout the lifetime of a Telnet connection.
-
- If all option negotiations fail, a Telnet implementation MUST
- default to, and support, an NVT.
-
- DISCUSSION:
- Even though more sophisticated "terminals" and supporting
- option negotiations are becoming the norm, all
- implementations must be prepared to support an NVT for any
- user-server communication.
-
- 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
-
- On a host that never sends the Telnet command Go Ahead (GA),
- the Telnet Server MUST attempt to negotiate the Suppress Go
- Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or
- Server Telnet MUST always accept negotiation of the Suppress Go
-
-
-
-Internet Engineering Task Force [Page 16]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- Ahead option.
-
- When it is driving a full-duplex terminal for which GA has no
- meaning, a User Telnet implementation MAY ignore GA commands.
-
- DISCUSSION:
- Half-duplex ("locked-keyboard") line-at-a-time terminals
- for which the Go-Ahead mechanism was designed have largely
- disappeared from the scene. It turned out to be difficult
- to implement sending the Go-Ahead signal in many operating
- systems, even some systems that support native half-duplex
- terminals. The difficulty is typically that the Telnet
- server code does not have access to information about
- whether the user process is blocked awaiting input from
- the Telnet connection, i.e., it cannot reliably determine
- when to send a GA command. Therefore, most Telnet Server
- hosts do not send GA commands.
-
- The effect of the rules in this section is to allow either
- end of a Telnet connection to veto the use of GA commands.
-
- There is a class of half-duplex terminals that is still
- commercially important: "data entry terminals," which
- interact in a full-screen manner. However, supporting
- data entry terminals using the Telnet protocol does not
- require the Go Ahead signal; see Section 3.3.2.
-
- 3.2.3 Control Functions: RFC-854, pp. 7-8
-
- The list of Telnet commands has been extended to include EOR
- (End-of-Record), with code 239 [TELNET:9].
-
- Both User and Server Telnets MAY support the control functions
- EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
- SB, and SE.
-
- A host MUST be able to receive and ignore any Telnet control
- functions that it does not support.
-
- DISCUSSION:
- Note that a Server Telnet is required to support the
- Telnet IP (Interrupt Process) function, even if the server
- host has an equivalent in-stream function (e.g., Control-C
- in many systems). The Telnet IP function may be stronger
- than an in-stream interrupt command, because of the out-
- of-band effect of TCP urgent data.
-
- The EOR control function may be used to delimit the
-
-
-
-Internet Engineering Task Force [Page 17]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- stream. An important application is data entry terminal
- support (see Section 3.3.2). There was concern that since
- EOR had not been defined in RFC-854, a host that was not
- prepared to correctly ignore unknown Telnet commands might
- crash if it received an EOR. To protect such hosts, the
- End-of-Record option [TELNET:9] was introduced; however, a
- properly implemented Telnet program will not require this
- protection.
-
- 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10
-
- When it receives "urgent" TCP data, a User or Server Telnet
- MUST discard all data except Telnet commands until the DM (and
- end of urgent) is reached.
-
- When it sends Telnet IP (Interrupt Process), a User Telnet
- SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
- TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent
- pointer points to the DM octet.
-
- When it receives a Telnet IP command, a Server Telnet MAY send
- a Telnet "Synch" sequence back to the user, to flush the output
- stream. The choice ought to be consistent with the way the
- server operating system behaves when a local user interrupts a
- process.
-
- When it receives a Telnet AO command, a Server Telnet MUST send
- a Telnet "Synch" sequence back to the user, to flush the output
- stream.
-
- A User Telnet SHOULD have the capability of flushing output
- when it sends a Telnet IP; see also Section 3.4.5.
-
- DISCUSSION:
- There are three possible ways for a User Telnet to flush
- the stream of server output data:
-
- (1) Send AO after IP.
-
- This will cause the server host to send a "flush-
- buffered-output" signal to its operating system.
- However, the AO may not take effect locally, i.e.,
- stop terminal output at the User Telnet end, until
- the Server Telnet has received and processed the AO
- and has sent back a "Synch".
-
- (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard
- all output locally until a WILL/WONT TIMING-MARK is
-
-
-
-Internet Engineering Task Force [Page 18]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- received from the Server Telnet.
-
- Since the DO TIMING-MARK will be processed after the
- IP at the server, the reply to it should be in the
- right place in the output data stream. However, the
- TIMING-MARK will not send a "flush buffered output"
- signal to the server operating system. Whether or
- not this is needed is dependent upon the server
- system.
-
- (3) Do both.
-
- The best method is not entirely clear, since it must
- accommodate a number of existing server hosts that do not
- follow the Telnet standards in various ways. The safest
- approach is probably to provide a user-controllable option
- to select (1), (2), or (3).
-
- 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11
-
- In NVT mode, a Telnet SHOULD NOT send characters with the
- high-order bit 1, and MUST NOT send it as a parity bit.
- Implementations that pass the high-order bit to applications
- SHOULD negotiate binary mode (see Section 3.2.6).
-
-
- DISCUSSION:
- Implementors should be aware that a strict reading of
- RFC-854 allows a client or server expecting NVT ASCII to
- ignore characters with the high-order bit set. In
- general, binary mode is expected to be used for
- transmission of an extended (beyond 7-bit) character set
- with Telnet.
-
- However, there exist applications that really need an 8-
- bit NVT mode, which is currently not defined, and these
- existing applications do set the high-order bit during
- part or all of the life of a Telnet connection. Note that
- binary mode is not the same as 8-bit NVT mode, since
- binary mode turns off end-of-line processing. For this
- reason, the requirements on the high-order bit are stated
- as SHOULD, not MUST.
-
- RFC-854 defines a minimal set of properties of a "network
- virtual terminal" or NVT; this is not meant to preclude
- additional features in a real terminal. A Telnet
- connection is fully transparent to all 7-bit ASCII
- characters, including arbitrary ASCII control characters.
-
-
-
-Internet Engineering Task Force [Page 19]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- For example, a terminal might support full-screen commands
- coded as ASCII escape sequences; a Telnet implementation
- would pass these sequences as uninterpreted data. Thus,
- an NVT should not be conceived as a terminal type of a
- highly-restricted device.
-
- 3.2.6 Telnet Command Structure: RFC-854, p. 13
-
- Since options may appear at any point in the data stream, a
- Telnet escape character (known as IAC, with the value 255) to
- be sent as data MUST be doubled.
-
- 3.2.7 Telnet Binary Option: RFC-856
-
- When the Binary option has been successfully negotiated,
- arbitrary 8-bit characters are allowed. However, the data
- stream MUST still be scanned for IAC characters, any embedded
- Telnet commands MUST be obeyed, and data bytes equal to IAC
- MUST be doubled. Other character processing (e.g., replacing
- CR by CR NUL or by CR LF) MUST NOT be done. In particular,
- there is no end-of-line convention (see Section 3.3.1) in
- binary mode.
-
- DISCUSSION:
- The Binary option is normally negotiated in both
- directions, to change the Telnet connection from NVT mode
- to "binary mode".
-
- The sequence IAC EOR can be used to delimit blocks of data
- within a binary-mode Telnet stream.
-
- 3.2.8 Telnet Terminal-Type Option: RFC-1091
-
- The Terminal-Type option MUST use the terminal type names
- officially defined in the Assigned Numbers RFC [INTRO:5], when
- they are available for the particular terminal. However, the
- receiver of a Terminal-Type option MUST accept any name.
-
- DISCUSSION:
- RFC-1091 [TELNET:10] updates an earlier version of the
- Terminal-Type option defined in RFC-930. The earlier
- version allowed a server host capable of supporting
- multiple terminal types to learn the type of a particular
- client's terminal, assuming that each physical terminal
- had an intrinsic type. However, today a "terminal" is
- often really a terminal emulator program running in a PC,
- perhaps capable of emulating a range of terminal types.
- Therefore, RFC-1091 extends the specification to allow a
-
-
-
-Internet Engineering Task Force [Page 20]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- more general terminal-type negotiation between User and
- Server Telnets.
-
- 3.3 SPECIFIC ISSUES
-
- 3.3.1 Telnet End-of-Line Convention
-
- The Telnet protocol defines the sequence CR LF to mean "end-
- of-line". For terminal input, this corresponds to a command-
- completion or "end-of-line" key being pressed on a user
- terminal; on an ASCII terminal, this is the CR key, but it may
- also be labelled "Return" or "Enter".
-
- When a Server Telnet receives the Telnet end-of-line sequence
- CR LF as input from a remote terminal, the effect MUST be the
- same as if the user had pressed the "end-of-line" key on a
- local terminal. On server hosts that use ASCII, in particular,
- receipt of the Telnet sequence CR LF must cause the same effect
- as a local user pressing the CR key on a local terminal. Thus,
- CR LF and CR NUL MUST have the same effect on an ASCII server
- host when received as input over a Telnet connection.
-
- A User Telnet MUST be able to send any of the forms: CR LF, CR
- NUL, and LF. A User Telnet on an ASCII host SHOULD have a
- user-controllable mode to send either CR LF or CR NUL when the
- user presses the "end-of-line" key, and CR LF SHOULD be the
- default.
-
- The Telnet end-of-line sequence CR LF MUST be used to send
- Telnet data that is not terminal-to-computer (e.g., for Server
- Telnet sending output, or the Telnet protocol incorporated
- another application protocol).
-
- DISCUSSION:
- To allow interoperability between arbitrary Telnet clients
- and servers, the Telnet protocol defined a standard
- representation for a line terminator. Since the ASCII
- character set includes no explicit end-of-line character,
- systems have chosen various representations, e.g., CR, LF,
- and the sequence CR LF. The Telnet protocol chose the CR
- LF sequence as the standard for network transmission.
-
- Unfortunately, the Telnet protocol specification in RFC-
- 854 [TELNET:1] has turned out to be somewhat ambiguous on
- what character(s) should be sent from client to server for
- the "end-of-line" key. The result has been a massive and
- continuing interoperability headache, made worse by
- various faulty implementations of both User and Server
-
-
-
-Internet Engineering Task Force [Page 21]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- Telnets.
-
- Although the Telnet protocol is based on a perfectly
- symmetric model, in a remote login session the role of the
- user at a terminal differs from the role of the server
- host. For example, RFC-854 defines the meaning of CR, LF,
- and CR LF as output from the server, but does not specify
- what the User Telnet should send when the user presses the
- "end-of-line" key on the terminal; this turns out to be
- the point at issue.
-
- When a user presses the "end-of-line" key, some User
- Telnet implementations send CR LF, while others send CR
- NUL (based on a different interpretation of the same
- sentence in RFC-854). These will be equivalent for a
- correctly-implemented ASCII server host, as discussed
- above. For other servers, a mode in the User Telnet is
- needed.
-
- The existence of User Telnets that send only CR NUL when
- CR is pressed creates a dilemma for non-ASCII hosts: they
- can either treat CR NUL as equivalent to CR LF in input,
- thus precluding the possibility of entering a "bare" CR,
- or else lose complete interworking.
-
- Suppose a user on host A uses Telnet to log into a server
- host B, and then execute B's User Telnet program to log
- into server host C. It is desirable for the Server/User
- Telnet combination on B to be as transparent as possible,
- i.e., to appear as if A were connected directly to C. In
- particular, correct implementation will make B transparent
- to Telnet end-of-line sequences, except that CR LF may be
- translated to CR NUL or vice versa.
-
- IMPLEMENTATION:
- To understand Telnet end-of-line issues, one must have at
- least a general model of the relationship of Telnet to the
- local operating system. The Server Telnet process is
- typically coupled into the terminal driver software of the
- operating system as a pseudo-terminal. A Telnet end-of-
- line sequence received by the Server Telnet must have the
- same effect as pressing the end-of-line key on a real
- locally-connected terminal.
-
- Operating systems that support interactive character-at-
- a-time applications (e.g., editors) typically have two
- internal modes for their terminal I/O: a formatted mode,
- in which local conventions for end-of-line and other
-
-
-
-Internet Engineering Task Force [Page 22]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- formatting rules have been applied to the data stream, and
- a "raw" mode, in which the application has direct access
- to every character as it was entered. A Server Telnet
- must be implemented in such a way that these modes have
- the same effect for remote as for local terminals. For
- example, suppose a CR LF or CR NUL is received by the
- Server Telnet on an ASCII host. In raw mode, a CR
- character is passed to the application; in formatted mode,
- the local system's end-of-line convention is used.
-
- 3.3.2 Data Entry Terminals
-
- DISCUSSION:
- In addition to the line-oriented and character-oriented
- ASCII terminals for which Telnet was designed, there are
- several families of video display terminals that are
- sometimes known as "data entry terminals" or DETs. The
- IBM 3270 family is a well-known example.
-
- Two Internet protocols have been designed to support
- generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
- option [TELNET:18, TELNET:19]. The DET option drives a
- data entry terminal over a Telnet connection using (sub-)
- negotiation. SUPDUP is a completely separate terminal
- protocol, which can be entered from Telnet by negotiation.
- Although both SUPDUP and the DET option have been used
- successfully in particular environments, neither has
- gained general acceptance or wide implementation.
-
- A different approach to DET interaction has been developed
- for supporting the IBM 3270 family through Telnet,
- although the same approach would be applicable to any DET.
- The idea is to enter a "native DET" mode, in which the
- native DET input/output stream is sent as binary data.
- The Telnet EOR command is used to delimit logical records
- (e.g., "screens") within this binary stream.
-
- IMPLEMENTATION:
- The rules for entering and leaving native DET mode are as
- follows:
-
- o The Server uses the Terminal-Type option [TELNET:10]
- to learn that the client is a DET.
-
- o It is conventional, but not required, that both ends
- negotiate the EOR option [TELNET:9].
-
- o Both ends negotiate the Binary option [TELNET:3] to
-
-
-
-Internet Engineering Task Force [Page 23]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- enter native DET mode.
-
- o When either end negotiates out of binary mode, the
- other end does too, and the mode then reverts to
- normal NVT.
-
-
- 3.3.3 Option Requirements
-
- Every Telnet implementation MUST support the Binary option
- [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
- SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
- Record [TELNET:9], and Extended Options List [TELNET:8]
- options.
-
- A User or Server Telnet SHOULD support the Window Size Option
- [TELNET:12] if the local operating system provides the
- corresponding capability.
-
- DISCUSSION:
- Note that the End-of-Record option only signifies that a
- Telnet can receive a Telnet EOR without crashing;
- therefore, every Telnet ought to be willing to accept
- negotiation of the End-of-Record option. See also the
- discussion in Section 3.2.3.
-
- 3.3.4 Option Initiation
-
- When the Telnet protocol is used in a client/server situation,
- the server SHOULD initiate negotiation of the terminal
- interaction mode it expects.
-
- DISCUSSION:
- The Telnet protocol was defined to be perfectly
- symmetrical, but its application is generally asymmetric.
- Remote login has been known to fail because NEITHER side
- initiated negotiation of the required non-default terminal
- modes. It is generally the server that determines the
- preferred mode, so the server needs to initiate the
- negotiation; since the negotiation is symmetric, the user
- can also initiate it.
-
- A client (User Telnet) SHOULD provide a means for users to
- enable and disable the initiation of option negotiation.
-
- DISCUSSION:
- A user sometimes needs to connect to an application
- service (e.g., FTP or SMTP) that uses Telnet for its
-
-
-
-Internet Engineering Task Force [Page 24]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- control stream but does not support Telnet options. User
- Telnet may be used for this purpose if initiation of
- option negotiation is disabled.
-
- 3.3.5 Telnet Linemode Option
-
- DISCUSSION:
- An important new Telnet option, LINEMODE [TELNET:12], has
- been proposed. The LINEMODE option provides a standard
- way for a User Telnet and a Server Telnet to agree that
- the client rather than the server will perform terminal
- character processing. When the client has prepared a
- complete line of text, it will send it to the server in
- (usually) one TCP packet. This option will greatly
- decrease the packet cost of Telnet sessions and will also
- give much better user response over congested or long-
- delay networks.
-
- The LINEMODE option allows dynamic switching between local
- and remote character processing. For example, the Telnet
- connection will automatically negotiate into single-
- character mode while a full screen editor is running, and
- then return to linemode when the editor is finished.
-
- We expect that when this RFC is released, hosts should
- implement the client side of this option, and may
- implement the server side of this option. To properly
- implement the server side, the server needs to be able to
- tell the local system not to do any input character
- processing, but to remember its current terminal state and
- notify the Server Telnet process whenever the state
- changes. This will allow password echoing and full screen
- editors to be handled properly, for example.
-
- 3.4 TELNET/USER INTERFACE
-
- 3.4.1 Character Set Transparency
-
- User Telnet implementations SHOULD be able to send or receive
- any 7-bit ASCII character. Where possible, any special
- character interpretations by the user host's operating system
- SHOULD be bypassed so that these characters can conveniently be
- sent and received on the connection.
-
- Some character value MUST be reserved as "escape to command
- mode"; conventionally, doubling this character allows it to be
- entered as data. The specific character used SHOULD be user
- selectable.
-
-
-
-Internet Engineering Task Force [Page 25]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- On binary-mode connections, a User Telnet program MAY provide
- an escape mechanism for entering arbitrary 8-bit values, if the
- host operating system doesn't allow them to be entered directly
- from the keyboard.
-
- IMPLEMENTATION:
- The transparency issues are less pressing on servers, but
- implementors should take care in dealing with issues like:
- masking off parity bits (sent by an older, non-conforming
- client) before they reach programs that expect only NVT
- ASCII, and properly handling programs that request 8-bit
- data streams.
-
- 3.4.2 Telnet Commands
-
- A User Telnet program MUST provide a user the capability of
- entering any of the Telnet control functions IP, AO, or AYT,
- and SHOULD provide the capability of entering EC, EL, and
- Break.
-
- 3.4.3 TCP Connection Errors
-
- A User Telnet program SHOULD report to the user any TCP errors
- that are reported by the transport layer (see "TCP/Application
- Layer Interface" section in [INTRO:1]).
-
- 3.4.4 Non-Default Telnet Contact Port
-
- A User Telnet program SHOULD allow the user to optionally
- specify a non-standard contact port number at the Server Telnet
- host.
-
- 3.4.5 Flushing Output
-
- A User Telnet program SHOULD provide the user the ability to
- specify whether or not output should be flushed when an IP is
- sent; see Section 3.2.4.
-
- For any output flushing scheme that causes the User Telnet to
- flush output locally until a Telnet signal is received from the
- Server, there SHOULD be a way for the user to manually restore
- normal output, in case the Server fails to send the expected
- signal.
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 26]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- 3.5. TELNET REQUIREMENTS SUMMARY
-
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
- | | | | | | |
-Option Negotiation |3.2.1 |x| | | | |
- Avoid negotiation loops |3.2.1 |x| | | | |
- Refuse unsupported options |3.2.1 |x| | | | |
- Negotiation OK anytime on connection |3.2.1 | |x| | | |
- Default to NVT |3.2.1 |x| | | | |
- Send official name in Term-Type option |3.2.8 |x| | | | |
- Accept any name in Term-Type option |3.2.8 |x| | | | |
- Implement Binary, Suppress-GA options |3.3.3 |x| | | | |
- Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | |
- Implement Window-Size option if appropriate |3.3.3 | |x| | | |
- Server initiate mode negotiations |3.3.4 | |x| | | |
- User can enable/disable init negotiations |3.3.4 | |x| | | |
- | | | | | | |
-Go-Aheads | | | | | | |
- Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | |
- User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | |
- User Telnet ignore GA's |3.2.2 | | |x| | |
- | | | | | | |
-Control Functions | | | | | | |
- Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | |
- Support EOR EC EL Break |3.2.3 | | |x| | |
- Ignore unsupported control functions |3.2.3 |x| | | | |
- User, Server discard urgent data up to DM |3.2.4 |x| | | | |
- User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | |
- Server Telnet reply Synch to IP |3.2.4 | | |x| | |
- Server Telnet reply Synch to AO |3.2.4 |x| | | | |
- User Telnet can flush output when send IP |3.2.4 | |x| | | |
- | | | | | | |
-Encoding | | | | | | |
- Send high-order bit in NVT mode |3.2.5 | | | |x| |
- Send high-order bit as parity bit |3.2.5 | | | | |x|
- Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | |
- Always double IAC data byte |3.2.6 |x| | | | |
-
-
-
-Internet Engineering Task Force [Page 27]
-
-
-
-
-RFC1123 REMOTE LOGIN -- TELNET October 1989
-
-
- Double IAC data byte in binary mode |3.2.7 |x| | | | |
- Obey Telnet cmds in binary mode |3.2.7 |x| | | | |
- End-of-line, CR NUL in binary mode |3.2.7 | | | | |x|
- | | | | | | |
-End-of-Line | | | | | | |
- EOL at Server same as local end-of-line |3.3.1 |x| | | | |
- ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | |
- User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | |
- ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | |
- User Telnet default mode is CR LF |3.3.1 | |x| | | |
- Non-interactive uses CR LF for EOL |3.3.1 |x| | | | |
- | | | | | | |
-User Telnet interface | | | | | | |
- Input & output all 7-bit characters |3.4.1 | |x| | | |
- Bypass local op sys interpretation |3.4.1 | |x| | | |
- Escape character |3.4.1 |x| | | | |
- User-settable escape character |3.4.1 | |x| | | |
- Escape to enter 8-bit values |3.4.1 | | |x| | |
- Can input IP, AO, AYT |3.4.2 |x| | | | |
- Can input EC, EL, Break |3.4.2 | |x| | | |
- Report TCP connection errors to user |3.4.3 | |x| | | |
- Optional non-default contact port |3.4.4 | |x| | | |
- Can spec: output flushed when IP sent |3.4.5 | |x| | | |
- Can manually restore output mode |3.4.5 | |x| | | |
- | | | | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 28]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
-4. FILE TRANSFER
-
- 4.1 FILE TRANSFER PROTOCOL -- FTP
-
- 4.1.1 INTRODUCTION
-
- The File Transfer Protocol FTP is the primary Internet standard
- for file transfer. The current specification is contained in
- RFC-959 [FTP:1].
-
- FTP uses separate simultaneous TCP connections for control and
- for data transfer. The FTP protocol includes many features,
- some of which are not commonly implemented. However, for every
- feature in FTP, there exists at least one implementation. The
- minimum implementation defined in RFC-959 was too small, so a
- somewhat larger minimum implementation is defined here.
-
- Internet users have been unnecessarily burdened for years by
- deficient FTP implementations. Protocol implementors have
- suffered from the erroneous opinion that implementing FTP ought
- to be a small and trivial task. This is wrong, because FTP has
- a user interface, because it has to deal (correctly) with the
- whole variety of communication and operating system errors that
- may occur, and because it has to handle the great diversity of
- real file systems in the world.
-
- 4.1.2. PROTOCOL WALK-THROUGH
-
- 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4
-
- An FTP program MUST support TYPE I ("IMAGE" or binary type)
- as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
- A machine whose memory is organized into m-bit words, where
- m is not a multiple of 8, MAY also support TYPE L m.
-
- DISCUSSION:
- The command "TYPE L 8" is often required to transfer
- binary data between a machine whose memory is organized
- into (e.g.) 36-bit words and a machine with an 8-bit
- byte organization. For an 8-bit byte machine, TYPE L 8
- is equivalent to IMAGE.
-
- "TYPE L m" is sometimes specified to the FTP programs
- on two m-bit word machines to ensure the correct
- transfer of a native-mode binary file from one machine
- to the other. However, this command should have the
- same effect on these machines as "TYPE I".
-
-
-
-
-Internet Engineering Task Force [Page 29]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2
-
- A host that makes no distinction between TYPE N and TYPE T
- SHOULD implement TYPE T to be identical to TYPE N.
-
- DISCUSSION:
- This provision should ease interoperation with hosts
- that do make this distinction.
-
- Many hosts represent text files internally as strings
- of ASCII characters, using the embedded ASCII format
- effector characters (LF, BS, FF, ...) to control the
- format when a file is printed. For such hosts, there
- is no distinction between "print" files and other
- files. However, systems that use record structured
- files typically need a special format for printable
- files (e.g., ASA carriage control). For the latter
- hosts, FTP allows a choice of TYPE N or TYPE T.
-
- 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
-
- Implementation of page structure is NOT RECOMMENDED in
- general. However, if a host system does need to implement
- FTP for "random access" or "holey" files, it MUST use the
- defined page structure format rather than define a new
- private FTP format.
-
- 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2
-
- An FTP transformation between record-structure and file-
- structure SHOULD be invertible, to the extent possible while
- making the result useful on the target host.
-
- DISCUSSION:
- RFC-959 required strict invertibility between record-
- structure and file-structure, but in practice,
- efficiency and convenience often preclude it.
- Therefore, the requirement is being relaxed. There are
- two different objectives for transferring a file:
- processing it on the target host, or just storage. For
- storage, strict invertibility is important. For
- processing, the file created on the target host needs
- to be in the format expected by application programs on
- that host.
-
- As an example of the conflict, imagine a record-
- oriented operating system that requires some data files
- to have exactly 80 bytes in each record. While STORing
-
-
-
-Internet Engineering Task Force [Page 30]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- a file on such a host, an FTP Server must be able to
- pad each line or record to 80 bytes; a later retrieval
- of such a file cannot be strictly invertible.
-
- 4.1.2.5 Data Connection Management: RFC-959 Section 3.3
-
- A User-FTP that uses STREAM mode SHOULD send a PORT command
- to assign a non-default data port before each transfer
- command is issued.
-
- DISCUSSION:
- This is required because of the long delay after a TCP
- connection is closed until its socket pair can be
- reused, to allow multiple transfers during a single FTP
- session. Sending a port command can avoided if a
- transfer mode other than stream is used, by leaving the
- data transfer connection open between transfers.
-
- 4.1.2.6 PASV Command: RFC-959 Section 4.1.2
-
- A server-FTP MUST implement the PASV command.
-
- If multiple third-party transfers are to be executed during
- the same session, a new PASV command MUST be issued before
- each transfer command, to obtain a unique port pair.
-
- IMPLEMENTATION:
- The format of the 227 reply to a PASV command is not
- well standardized. In particular, an FTP client cannot
- assume that the parentheses shown on page 40 of RFC-959
- will be present (and in fact, Figure 3 on page 43 omits
- them). Therefore, a User-FTP program that interprets
- the PASV reply must scan the reply for the first digit
- of the host and port numbers.
-
- Note that the host number h1,h2,h3,h4 is the IP address
- of the server host that is sending the reply, and that
- p1,p2 is a non-default data transfer port that PASV has
- assigned.
-
- 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3
-
- The data returned by an NLST command MUST contain only a
- simple list of legal pathnames, such that the server can use
- them directly as the arguments of subsequent data transfer
- commands for the individual files.
-
- The data returned by a LIST or NLST command SHOULD use an
-
-
-
-Internet Engineering Task Force [Page 31]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- implied TYPE AN, unless the current type is EBCDIC, in which
- case an implied TYPE EN SHOULD be used.
-
- DISCUSSION:
- Many FTP clients support macro-commands that will get
- or put files matching a wildcard specification, using
- NLST to obtain a list of pathnames. The expansion of
- "multiple-put" is local to the client, but "multiple-
- get" requires cooperation by the server.
-
- The implied type for LIST and NLST is designed to
- provide compatibility with existing User-FTPs, and in
- particular with multiple-get commands.
-
- 4.1.2.8 SITE Command: RFC-959 Section 4.1.3
-
- A Server-FTP SHOULD use the SITE command for non-standard
- features, rather than invent new private commands or
- unstandardized extensions to existing commands.
-
- 4.1.2.9 STOU Command: RFC-959 Section 4.1.3
-
- The STOU command stores into a uniquely named file. When it
- receives an STOU command, a Server-FTP MUST return the
- actual file name in the "125 Transfer Starting" or the "150
- Opening Data Connection" message that precedes the transfer
- (the 250 reply code mentioned in RFC-959 is incorrect). The
- exact format of these messages is hereby defined to be as
- follows:
-
- 125 FILE: pppp
- 150 FILE: pppp
-
- where pppp represents the unique pathname of the file that
- will be written.
-
- 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34
-
- Implementors MUST NOT assume any correspondence between READ
- boundaries on the control connection and the Telnet EOL
- sequences (CR LF).
-
- DISCUSSION:
- Thus, a server-FTP (or User-FTP) must continue reading
- characters from the control connection until a complete
- Telnet EOL sequence is encountered, before processing
- the command (or response, respectively). Conversely, a
- single READ from the control connection may include
-
-
-
-Internet Engineering Task Force [Page 32]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- more than one FTP command.
-
- 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35
-
- A Server-FTP MUST send only correctly formatted replies on
- the control connection. Note that RFC-959 (unlike earlier
- versions of the FTP spec) contains no provision for a
- "spontaneous" reply message.
-
- A Server-FTP SHOULD use the reply codes defined in RFC-959
- whenever they apply. However, a server-FTP MAY use a
- different reply code when needed, as long as the general
- rules of Section 4.2 are followed. When the implementor has
- a choice between a 4xx and 5xx reply code, a Server-FTP
- SHOULD send a 4xx (temporary failure) code when there is any
- reasonable possibility that a failed FTP will succeed a few
- hours later.
-
- A User-FTP SHOULD generally use only the highest-order digit
- of a 3-digit reply code for making a procedural decision, to
- prevent difficulties when a Server-FTP uses non-standard
- reply codes.
-
- A User-FTP MUST be able to handle multi-line replies. If
- the implementation imposes a limit on the number of lines
- and if this limit is exceeded, the User-FTP MUST recover,
- e.g., by ignoring the excess lines until the end of the
- multi-line reply is reached.
-
- A User-FTP SHOULD NOT interpret a 421 reply code ("Service
- not available, closing control connection") specially, but
- SHOULD detect closing of the control connection by the
- server.
-
- DISCUSSION:
- Server implementations that fail to strictly follow the
- reply rules often cause FTP user programs to hang.
- Note that RFC-959 resolved ambiguities in the reply
- rules found in earlier FTP specifications and must be
- followed.
-
- It is important to choose FTP reply codes that properly
- distinguish between temporary and permanent failures,
- to allow the successful use of file transfer client
- daemons. These programs depend on the reply codes to
- decide whether or not to retry a failed transfer; using
- a permanent failure code (5xx) for a temporary error
- will cause these programs to give up unnecessarily.
-
-
-
-Internet Engineering Task Force [Page 33]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- When the meaning of a reply matches exactly the text
- shown in RFC-959, uniformity will be enhanced by using
- the RFC-959 text verbatim. However, a Server-FTP
- implementor is encouraged to choose reply text that
- conveys specific system-dependent information, when
- appropriate.
-
- 4.1.2.12 Connections: RFC-959 Section 5.2
-
- The words "and the port used" in the second paragraph of
- this section of RFC-959 are erroneous (historical), and they
- should be ignored.
-
- On a multihomed server host, the default data transfer port
- (L-1) MUST be associated with the same local IP address as
- the corresponding control connection to port L.
-
- A user-FTP MUST NOT send any Telnet controls other than
- SYNCH and IP on an FTP control connection. In particular, it
- MUST NOT attempt to negotiate Telnet options on the control
- connection. However, a server-FTP MUST be capable of
- accepting and refusing Telnet negotiations (i.e., sending
- DONT/WONT).
-
- DISCUSSION:
- Although the RFC says: "Server- and User- processes
- should follow the conventions for the Telnet
- protocol...[on the control connection]", it is not the
- intent that Telnet option negotiation is to be
- employed.
-
- 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1
-
- The following commands and options MUST be supported by
- every server-FTP and user-FTP, except in cases where the
- underlying file system or operating system does not allow or
- support a particular command.
-
- Type: ASCII Non-print, IMAGE, LOCAL 8
- Mode: Stream
- Structure: File, Record*
- Commands:
- USER, PASS, ACCT,
- PORT, PASV,
- TYPE, MODE, STRU,
- RETR, STOR, APPE,
- RNFR, RNTO, DELE,
- CWD, CDUP, RMD, MKD, PWD,
-
-
-
-Internet Engineering Task Force [Page 34]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- LIST, NLST,
- SYST, STAT,
- HELP, NOOP, QUIT.
-
- *Record structure is REQUIRED only for hosts whose file
- systems support record structure.
-
- DISCUSSION:
- Vendors are encouraged to implement a larger subset of
- the protocol. For example, there are important
- robustness features in the protocol (e.g., Restart,
- ABOR, block mode) that would be an aid to some Internet
- users but are not widely implemented.
-
- A host that does not have record structures in its file
- system may still accept files with STRU R, recording
- the byte stream literally.
-
- 4.1.3 SPECIFIC ISSUES
-
- 4.1.3.1 Non-standard Command Verbs
-
- FTP allows "experimental" commands, whose names begin with
- "X". If these commands are subsequently adopted as
- standards, there may still be existing implementations using
- the "X" form. At present, this is true for the directory
- commands:
-
- RFC-959 "Experimental"
-
- MKD XMKD
- RMD XRMD
- PWD XPWD
- CDUP XCUP
- CWD XCWD
-
- All FTP implementations SHOULD recognize both forms of these
- commands, by simply equating them with extra entries in the
- command lookup table.
-
- IMPLEMENTATION:
- A User-FTP can access a server that supports only the
- "X" forms by implementing a mode switch, or
- automatically using the following procedure: if the
- RFC-959 form of one of the above commands is rejected
- with a 500 or 502 response code, then try the
- experimental form; any other response would be passed
- to the user.
-
-
-
-Internet Engineering Task Force [Page 35]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- 4.1.3.2 Idle Timeout
-
- A Server-FTP process SHOULD have an idle timeout, which will
- terminate the process and close the control connection if
- the server is inactive (i.e., no command or data transfer in
- progress) for a long period of time. The idle timeout time
- SHOULD be configurable, and the default should be at least 5
- minutes.
-
- A client FTP process ("User-PI" in RFC-959) will need
- timeouts on responses only if it is invoked from a program.
-
- DISCUSSION:
- Without a timeout, a Server-FTP process may be left
- pending indefinitely if the corresponding client
- crashes without closing the control connection.
-
- 4.1.3.3 Concurrency of Data and Control
-
- DISCUSSION:
- The intent of the designers of FTP was that a user
- should be able to send a STAT command at any time while
- data transfer was in progress and that the server-FTP
- would reply immediately with status -- e.g., the number
- of bytes transferred so far. Similarly, an ABOR
- command should be possible at any time during a data
- transfer.
-
- Unfortunately, some small-machine operating systems
- make such concurrent programming difficult, and some
- other implementers seek minimal solutions, so some FTP
- implementations do not allow concurrent use of the data
- and control connections. Even such a minimal server
- must be prepared to accept and defer a STAT or ABOR
- command that arrives during data transfer.
-
- 4.1.3.4 FTP Restart Mechanism
-
- The description of the 110 reply on pp. 40-41 of RFC-959 is
- incorrect; the correct description is as follows. A restart
- reply message, sent over the control connection from the
- receiving FTP to the User-FTP, has the format:
-
- 110 MARK ssss = rrrr
-
- Here:
-
- * ssss is a text string that appeared in a Restart Marker
-
-
-
-Internet Engineering Task Force [Page 36]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- in the data stream and encodes a position in the
- sender's file system;
-
- * rrrr encodes the corresponding position in the
- receiver's file system.
-
- The encoding, which is specific to a particular file system
- and network implementation, is always generated and
- interpreted by the same system, either sender or receiver.
-
- When an FTP that implements restart receives a Restart
- Marker in the data stream, it SHOULD force the data to that
- point to be written to stable storage before encoding the
- corresponding position rrrr. An FTP sending Restart Markers
- MUST NOT assume that 110 replies will be returned
- synchronously with the data, i.e., it must not await a 110
- reply before sending more data.
-
- Two new reply codes are hereby defined for errors
- encountered in restarting a transfer:
-
- 554 Requested action not taken: invalid REST parameter.
-
- A 554 reply may result from a FTP service command that
- follows a REST command. The reply indicates that the
- existing file at the Server-FTP cannot be repositioned
- as specified in the REST.
-
- 555 Requested action not taken: type or stru mismatch.
-
- A 555 reply may result from an APPE command or from any
- FTP service command following a REST command. The
- reply indicates that there is some mismatch between the
- current transfer parameters (type and stru) and the
- attributes of the existing file.
-
- DISCUSSION:
- Note that the FTP Restart mechanism requires that Block
- or Compressed mode be used for data transfer, to allow
- the Restart Markers to be included within the data
- stream. The frequency of Restart Markers can be low.
-
- Restart Markers mark a place in the data stream, but
- the receiver may be performing some transformation on
- the data as it is stored into stable storage. In
- general, the receiver's encoding must include any state
- information necessary to restart this transformation at
- any point of the FTP data stream. For example, in TYPE
-
-
-
-Internet Engineering Task Force [Page 37]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- A transfers, some receiver hosts transform CR LF
- sequences into a single LF character on disk. If a
- Restart Marker happens to fall between CR and LF, the
- receiver must encode in rrrr that the transfer must be
- restarted in a "CR has been seen and discarded" state.
-
- Note that the Restart Marker is required to be encoded
- as a string of printable ASCII characters, regardless
- of the type of the data.
-
- RFC-959 says that restart information is to be returned
- "to the user". This should not be taken literally. In
- general, the User-FTP should save the restart
- information (ssss,rrrr) in stable storage, e.g., append
- it to a restart control file. An empty restart control
- file should be created when the transfer first starts
- and deleted automatically when the transfer completes
- successfully. It is suggested that this file have a
- name derived in an easily-identifiable manner from the
- name of the file being transferred and the remote host
- name; this is analogous to the means used by many text
- editors for naming "backup" files.
-
- There are three cases for FTP restart.
-
- (1) User-to-Server Transfer
-
- The User-FTP puts Restart Markers <ssss> at
- convenient places in the data stream. When the
- Server-FTP receives a Marker, it writes all prior
- data to disk, encodes its file system position and
- transformation state as rrrr, and returns a "110
- MARK ssss = rrrr" reply over the control
- connection. The User-FTP appends the pair
- (ssss,rrrr) to its restart control file.
-
- To restart the transfer, the User-FTP fetches the
- last (ssss,rrrr) pair from the restart control
- file, repositions its local file system and
- transformation state using ssss, and sends the
- command "REST rrrr" to the Server-FTP.
-
- (2) Server-to-User Transfer
-
- The Server-FTP puts Restart Markers <ssss> at
- convenient places in the data stream. When the
- User-FTP receives a Marker, it writes all prior
- data to disk, encodes its file system position and
-
-
-
-Internet Engineering Task Force [Page 38]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- transformation state as rrrr, and appends the pair
- (rrrr,ssss) to its restart control file.
-
- To restart the transfer, the User-FTP fetches the
- last (rrrr,ssss) pair from the restart control
- file, repositions its local file system and
- transformation state using rrrr, and sends the
- command "REST ssss" to the Server-FTP.
-
- (3) Server-to-Server ("Third-Party") Transfer
-
- The sending Server-FTP puts Restart Markers <ssss>
- at convenient places in the data stream. When it
- receives a Marker, the receiving Server-FTP writes
- all prior data to disk, encodes its file system
- position and transformation state as rrrr, and
- sends a "110 MARK ssss = rrrr" reply over the
- control connection to the User. The User-FTP
- appends the pair (ssss,rrrr) to its restart
- control file.
-
- To restart the transfer, the User-FTP fetches the
- last (ssss,rrrr) pair from the restart control
- file, sends "REST ssss" to the sending Server-FTP,
- and sends "REST rrrr" to the receiving Server-FTP.
-
-
- 4.1.4 FTP/USER INTERFACE
-
- This section discusses the user interface for a User-FTP
- program.
-
- 4.1.4.1 Pathname Specification
-
- Since FTP is intended for use in a heterogeneous
- environment, User-FTP implementations MUST support remote
- pathnames as arbitrary character strings, so that their form
- and content are not limited by the conventions of the local
- operating system.
-
- DISCUSSION:
- In particular, remote pathnames can be of arbitrary
- length, and all the printing ASCII characters as well
- as space (0x20) must be allowed. RFC-959 allows a
- pathname to contain any 7-bit ASCII character except CR
- or LF.
-
-
-
-
-
-Internet Engineering Task Force [Page 39]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- 4.1.4.2 "QUOTE" Command
-
- A User-FTP program MUST implement a "QUOTE" command that
- will pass an arbitrary character string to the server and
- display all resulting response messages to the user.
-
- To make the "QUOTE" command useful, a User-FTP SHOULD send
- transfer control commands to the server as the user enters
- them, rather than saving all the commands and sending them
- to the server only when a data transfer is started.
-
- DISCUSSION:
- The "QUOTE" command is essential to allow the user to
- access servers that require system-specific commands
- (e.g., SITE or ALLO), or to invoke new or optional
- features that are not implemented by the User-FTP. For
- example, "QUOTE" may be used to specify "TYPE A T" to
- send a print file to hosts that require the
- distinction, even if the User-FTP does not recognize
- that TYPE.
-
- 4.1.4.3 Displaying Replies to User
-
- A User-FTP SHOULD display to the user the full text of all
- error reply messages it receives. It SHOULD have a
- "verbose" mode in which all commands it sends and the full
- text and reply codes it receives are displayed, for
- diagnosis of problems.
-
- 4.1.4.4 Maintaining Synchronization
-
- The state machine in a User-FTP SHOULD be forgiving of
- missing and unexpected reply messages, in order to maintain
- command synchronization with the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 40]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- 4.1.5 FTP REQUIREMENTS SUMMARY
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
--------------------------------------------|---------------|-|-|-|-|-|--
-Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | |
-File/Record transform invertible if poss. |4.1.2.4 | |x| | | |
-User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | |
-Server-FTP implement PASV |4.1.2.6 |x| | | | |
- PASV is per-transfer |4.1.2.6 |x| | | | |
-NLST reply usable in RETR cmds |4.1.2.7 |x| | | | |
-Implied type for LIST and NLST |4.1.2.7 | |x| | | |
-SITE cmd for non-standard features |4.1.2.8 | |x| | | |
-STOU cmd return pathname as specified |4.1.2.9 |x| | | | |
-Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x|
- | | | | | | |
-Server-FTP send only correct reply format |4.1.2.11 |x| | | | |
-Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | |
- New reply code following Section 4.2 |4.1.2.11 | | |x| | |
-User-FTP use only high digit of reply |4.1.2.11 | |x| | | |
-User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | |
-User-FTP handle 421 reply specially |4.1.2.11 | | | |x| |
- | | | | | | |
-Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | |
-User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x|
-User-FTP negotiate Telnet options |4.1.2.12 | | | | |x|
-Server-FTP handle Telnet options |4.1.2.12 |x| | | | |
-Handle "Experimental" directory cmds |4.1.3.1 | |x| | | |
-Idle timeout in server-FTP |4.1.3.2 | |x| | | |
- Configurable idle timeout |4.1.3.2 | |x| | | |
-Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | |
-Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x|
- | | | | | | |
-Support TYPE: | | | | | | |
- ASCII - Non-Print (AN) |4.1.2.13 |x| | | | |
- ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | |
- ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | |
- EBCDIC - (any form) |959 3.1.1.2 | | |x| | |
- IMAGE |4.1.2.1 |x| | | | |
- LOCAL 8 |4.1.2.1 |x| | | | |
-
-
-
-Internet Engineering Task Force [Page 41]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
- LOCAL m |4.1.2.1 | | |x| | |2
- | | | | | | |
-Support MODE: | | | | | | |
- Stream |4.1.2.13 |x| | | | |
- Block |959 3.4.2 | | |x| | |
- | | | | | | |
-Support STRUCTURE: | | | | | | |
- File |4.1.2.13 |x| | | | |
- Record |4.1.2.13 |x| | | | |3
- Page |4.1.2.3 | | | |x| |
- | | | | | | |
-Support commands: | | | | | | |
- USER |4.1.2.13 |x| | | | |
- PASS |4.1.2.13 |x| | | | |
- ACCT |4.1.2.13 |x| | | | |
- CWD |4.1.2.13 |x| | | | |
- CDUP |4.1.2.13 |x| | | | |
- SMNT |959 5.3.1 | | |x| | |
- REIN |959 5.3.1 | | |x| | |
- QUIT |4.1.2.13 |x| | | | |
- | | | | | | |
- PORT |4.1.2.13 |x| | | | |
- PASV |4.1.2.6 |x| | | | |
- TYPE |4.1.2.13 |x| | | | |1
- STRU |4.1.2.13 |x| | | | |1
- MODE |4.1.2.13 |x| | | | |1
- | | | | | | |
- RETR |4.1.2.13 |x| | | | |
- STOR |4.1.2.13 |x| | | | |
- STOU |959 5.3.1 | | |x| | |
- APPE |4.1.2.13 |x| | | | |
- ALLO |959 5.3.1 | | |x| | |
- REST |959 5.3.1 | | |x| | |
- RNFR |4.1.2.13 |x| | | | |
- RNTO |4.1.2.13 |x| | | | |
- ABOR |959 5.3.1 | | |x| | |
- DELE |4.1.2.13 |x| | | | |
- RMD |4.1.2.13 |x| | | | |
- MKD |4.1.2.13 |x| | | | |
- PWD |4.1.2.13 |x| | | | |
- LIST |4.1.2.13 |x| | | | |
- NLST |4.1.2.13 |x| | | | |
- SITE |4.1.2.8 | | |x| | |
- STAT |4.1.2.13 |x| | | | |
- SYST |4.1.2.13 |x| | | | |
- HELP |4.1.2.13 |x| | | | |
- NOOP |4.1.2.13 |x| | | | |
- | | | | | | |
-
-
-
-Internet Engineering Task Force [Page 42]
-
-
-
-
-RFC1123 FILE TRANSFER -- FTP October 1989
-
-
-User Interface: | | | | | | |
- Arbitrary pathnames |4.1.4.1 |x| | | | |
- Implement "QUOTE" command |4.1.4.2 |x| | | | |
- Transfer control commands immediately |4.1.4.2 | |x| | | |
- Display error messages to user |4.1.4.3 | |x| | | |
- Verbose mode |4.1.4.3 | |x| | | |
- Maintain synchronization with server |4.1.4.4 | |x| | | |
-
-Footnotes:
-
-(1) For the values shown earlier.
-
-(2) Here m is number of bits in a memory word.
-
-(3) Required for host with record-structured file system, optional
- otherwise.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 43]
-
-
-
-
-RFC1123 FILE TRANSFER -- TFTP October 1989
-
-
- 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
-
- 4.2.1 INTRODUCTION
-
- The Trivial File Transfer Protocol TFTP is defined in RFC-783
- [TFTP:1].
-
- TFTP provides its own reliable delivery with UDP as its
- transport protocol, using a simple stop-and-wait acknowledgment
- system. Since TFTP has an effective window of only one 512
- octet segment, it can provide good performance only over paths
- that have a small delay*bandwidth product. The TFTP file
- interface is very simple, providing no access control or
- security.
-
- TFTP's most important application is bootstrapping a host over
- a local network, since it is simple and small enough to be
- easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are
- urged to support TFTP for booting.
-
- 4.2.2 PROTOCOL WALK-THROUGH
-
- The TFTP specification [TFTP:1] is written in an open style,
- and does not fully specify many parts of the protocol.
-
- 4.2.2.1 Transfer Modes: RFC-783, Page 3
-
- The transfer mode "mail" SHOULD NOT be supported.
-
- 4.2.2.2 UDP Header: RFC-783, Page 17
-
- The Length field of a UDP header is incorrectly defined; it
- includes the UDP header length (8).
-
- 4.2.3 SPECIFIC ISSUES
-
- 4.2.3.1 Sorcerer's Apprentice Syndrome
-
- There is a serious bug, known as the "Sorcerer's Apprentice
- Syndrome," in the protocol specification. While it does not
- cause incorrect operation of the transfer (the file will
- always be transferred correctly if the transfer completes),
- this bug may cause excessive retransmission, which may cause
- the transfer to time out.
-
- Implementations MUST contain the fix for this problem: the
- sender (i.e., the side originating the DATA packets) must
- never resend the current DATA packet on receipt of a
-
-
-
-Internet Engineering Task Force [Page 44]
-
-
-
-
-RFC1123 FILE TRANSFER -- TFTP October 1989
-
-
- duplicate ACK.
-
- DISCUSSION:
- The bug is caused by the protocol rule that either
- side, on receiving an old duplicate datagram, may
- resend the current datagram. If a packet is delayed in
- the network but later successfully delivered after
- either side has timed out and retransmitted a packet, a
- duplicate copy of the response may be generated. If
- the other side responds to this duplicate with a
- duplicate of its own, then every datagram will be sent
- in duplicate for the remainder of the transfer (unless
- a datagram is lost, breaking the repetition). Worse
- yet, since the delay is often caused by congestion,
- this duplicate transmission will usually causes more
- congestion, leading to more delayed packets, etc.
-
- The following example may help to clarify this problem.
-
- TFTP A TFTP B
-
- (1) Receive ACK X-1
- Send DATA X
- (2) Receive DATA X
- Send ACK X
- (ACK X is delayed in network,
- and A times out):
- (3) Retransmit DATA X
-
- (4) Receive DATA X again
- Send ACK X again
- (5) Receive (delayed) ACK X
- Send DATA X+1
- (6) Receive DATA X+1
- Send ACK X+1
- (7) Receive ACK X again
- Send DATA X+1 again
- (8) Receive DATA X+1 again
- Send ACK X+1 again
- (9) Receive ACK X+1
- Send DATA X+2
- (10) Receive DATA X+2
- Send ACK X+3
- (11) Receive ACK X+1 again
- Send DATA X+2 again
- (12) Receive DATA X+2 again
- Send ACK X+3 again
-
-
-
-
-Internet Engineering Task Force [Page 45]
-
-
-
-
-RFC1123 FILE TRANSFER -- TFTP October 1989
-
-
- Notice that once the delayed ACK arrives, the protocol
- settles down to duplicate all further packets
- (sequences 5-8 and 9-12). The problem is caused not by
- either side timing out, but by both sides
- retransmitting the current packet when they receive a
- duplicate.
-
- The fix is to break the retransmission loop, as
- indicated above. This is analogous to the behavior of
- TCP. It is then possible to remove the retransmission
- timer on the receiver, since the resent ACK will never
- cause any action; this is a useful simplification where
- TFTP is used in a bootstrap program. It is OK to allow
- the timer to remain, and it may be helpful if the
- retransmitted ACK replaces one that was genuinely lost
- in the network. The sender still requires a retransmit
- timer, of course.
-
- 4.2.3.2 Timeout Algorithms
-
- A TFTP implementation MUST use an adaptive timeout.
-
- IMPLEMENTATION:
- TCP retransmission algorithms provide a useful base to
- work from. At least an exponential backoff of
- retransmission timeout is necessary.
-
- 4.2.3.3 Extensions
-
- A variety of non-standard extensions have been made to TFTP,
- including additional transfer modes and a secure operation
- mode (with passwords). None of these have been
- standardized.
-
- 4.2.3.4 Access Control
-
- A server TFTP implementation SHOULD include some
- configurable access control over what pathnames are allowed
- in TFTP operations.
-
- 4.2.3.5 Broadcast Request
-
- A TFTP request directed to a broadcast address SHOULD be
- silently ignored.
-
- DISCUSSION:
- Due to the weak access control capability of TFTP,
- directed broadcasts of TFTP requests to random networks
-
-
-
-Internet Engineering Task Force [Page 46]
-
-
-
-
-RFC1123 FILE TRANSFER -- TFTP October 1989
-
-
- could create a significant security hole.
-
- 4.2.4 TFTP REQUIREMENTS SUMMARY
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | |
-Transfer modes: | | | | | | |
- netascii |RFC-783 |x| | | | |
- octet |RFC-783 |x| | | | |
- mail |4.2.2.1 | | | |x| |
- extensions |4.2.3.3 | | |x| | |
-Use adaptive timeout |4.2.3.2 |x| | | | |
-Configurable access control |4.2.3.4 | |x| | | |
-Silently ignore broadcast request |4.2.3.5 | |x| | | |
--------------------------------------------------|--------|-|-|-|-|-|--
--------------------------------------------------|--------|-|-|-|-|-|--
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 47]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
-5. ELECTRONIC MAIL -- SMTP and RFC-822
-
- 5.1 INTRODUCTION
-
- In the TCP/IP protocol suite, electronic mail in a format
- specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
- Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
-
- While SMTP has remained unchanged over the years, the Internet
- community has made several changes in the way SMTP is used. In
- particular, the conversion to the Domain Name System (DNS) has
- caused changes in address formats and in mail routing. In this
- section, we assume familiarity with the concepts and terminology
- of the DNS, whose requirements are given in Section 6.1.
-
- RFC-822 specifies the Internet standard format for electronic mail
- messages. RFC-822 supercedes an older standard, RFC-733, that may
- still be in use in a few places, although it is obsolete. The two
- formats are sometimes referred to simply by number ("822" and
- "733").
-
- RFC-822 is used in some non-Internet mail environments with
- different mail transfer protocols than SMTP, and SMTP has also
- been adapted for use in some non-Internet environments. Note that
- this document presents the rules for the use of SMTP and RFC-822
- for the Internet environment only; other mail environments that
- use these protocols may be expected to have their own rules.
-
- 5.2 PROTOCOL WALK-THROUGH
-
- This section covers both RFC-821 and RFC-822.
-
- The SMTP specification in RFC-821 is clear and contains numerous
- examples, so implementors should not find it difficult to
- understand. This section simply updates or annotates portions of
- RFC-821 to conform with current usage.
-
- RFC-822 is a long and dense document, defining a rich syntax.
- Unfortunately, incomplete or defective implementations of RFC-822
- are common. In fact, nearly all of the many formats of RFC-822
- are actually used, so an implementation generally needs to
- recognize and correctly interpret all of the RFC-822 syntax.
-
- 5.2.1 The SMTP Model: RFC-821 Section 2
-
- DISCUSSION:
- Mail is sent by a series of request/response transactions
- between a client, the "sender-SMTP," and a server, the
-
-
-
-Internet Engineering Task Force [Page 48]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- "receiver-SMTP". These transactions pass (1) the message
- proper, which is composed of header and body, and (2) SMTP
- source and destination addresses, referred to as the
- "envelope".
-
- The SMTP programs are analogous to Message Transfer Agents
- (MTAs) of X.400. There will be another level of protocol
- software, closer to the end user, that is responsible for
- composing and analyzing RFC-822 message headers; this
- component is known as the "User Agent" in X.400, and we
- use that term in this document. There is a clear logical
- distinction between the User Agent and the SMTP
- implementation, since they operate on different levels of
- protocol. Note, however, that this distinction is may not
- be exactly reflected the structure of typical
- implementations of Internet mail. Often there is a
- program known as the "mailer" that implements SMTP and
- also some of the User Agent functions; the rest of the
- User Agent functions are included in a user interface used
- for entering and reading mail.
-
- The SMTP envelope is constructed at the originating site,
- typically by the User Agent when the message is first
- queued for the Sender-SMTP program. The envelope
- addresses may be derived from information in the message
- header, supplied by the user interface (e.g., to implement
- a bcc: request), or derived from local configuration
- information (e.g., expansion of a mailing list). The SMTP
- envelope cannot in general be re-derived from the header
- at a later stage in message delivery, so the envelope is
- transmitted separately from the message itself using the
- MAIL and RCPT commands of SMTP.
-
- The text of RFC-821 suggests that mail is to be delivered
- to an individual user at a host. With the advent of the
- domain system and of mail routing using mail-exchange (MX)
- resource records, implementors should now think of
- delivering mail to a user at a domain, which may or may
- not be a particular host. This DOES NOT change the fact
- that SMTP is a host-to-host mail exchange protocol.
-
- 5.2.2 Canonicalization: RFC-821 Section 3.1
-
- The domain names that a Sender-SMTP sends in MAIL and RCPT
- commands MUST have been "canonicalized," i.e., they must be
- fully-qualified principal names or domain literals, not
- nicknames or domain abbreviations. A canonicalized name either
- identifies a host directly or is an MX name; it cannot be a
-
-
-
-Internet Engineering Task Force [Page 49]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- CNAME.
-
- 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3
-
- A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
- (this requirement overrides RFC-821). However, there MAY be
- configuration information to disable VRFY and EXPN in a
- particular installation; this might even allow EXPN to be
- disabled for selected lists.
-
- A new reply code is defined for the VRFY command:
-
- 252 Cannot VRFY user (e.g., info is not local), but will
- take message for this user and attempt delivery.
-
- DISCUSSION:
- SMTP users and administrators make regular use of these
- commands for diagnosing mail delivery problems. With the
- increasing use of multi-level mailing list expansion
- (sometimes more than two levels), EXPN has been
- increasingly important for diagnosing inadvertent mail
- loops. On the other hand, some feel that EXPN represents
- a significant privacy, and perhaps even a security,
- exposure.
-
- 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4
-
- An SMTP MAY implement the commands to send a message to a
- user's terminal: SEND, SOML, and SAML.
-
- DISCUSSION:
- It has been suggested that the use of mail relaying
- through an MX record is inconsistent with the intent of
- SEND to deliver a message immediately and directly to a
- user's terminal. However, an SMTP receiver that is unable
- to write directly to the user terminal can return a "251
- User Not Local" reply to the RCPT following a SEND, to
- inform the originator of possibly deferred delivery.
-
- 5.2.5 HELO Command: RFC-821 Section 3.5
-
- The sender-SMTP MUST ensure that the <domain> parameter in a
- HELO command is a valid principal host domain name for the
- client host. As a result, the receiver-SMTP will not have to
- perform MX resolution on this name in order to validate the
- HELO parameter.
-
- The HELO receiver MAY verify that the HELO parameter really
-
-
-
-Internet Engineering Task Force [Page 50]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- corresponds to the IP address of the sender. However, the
- receiver MUST NOT refuse to accept a message, even if the
- sender's HELO command fails verification.
-
- DISCUSSION:
- Verifying the HELO parameter requires a domain name lookup
- and may therefore take considerable time. An alternative
- tool for tracking bogus mail sources is suggested below
- (see "DATA Command").
-
- Note also that the HELO argument is still required to have
- valid <domain> syntax, since it will appear in a Received:
- line; otherwise, a 501 error is to be sent.
-
- IMPLEMENTATION:
- When HELO parameter validation fails, a suggested
- procedure is to insert a note about the unknown
- authenticity of the sender into the message header (e.g.,
- in the "Received:" line).
-
- 5.2.6 Mail Relay: RFC-821 Section 3.6
-
- We distinguish three types of mail (store-and-) forwarding:
-
- (1) A simple forwarder or "mail exchanger" forwards a message
- using private knowledge about the recipient; see section
- 3.2 of RFC-821.
-
- (2) An SMTP mail "relay" forwards a message within an SMTP
- mail environment as the result of an explicit source route
- (as defined in section 3.6 of RFC-821). The SMTP relay
- function uses the "@...:" form of source route from RFC-
- 822 (see Section 5.2.19 below).
-
- (3) A mail "gateway" passes a message between different
- environments. The rules for mail gateways are discussed
- below in Section 5.3.7.
-
- An Internet host that is forwarding a message but is not a
- gateway to a different mail environment (i.e., it falls under
- (1) or (2)) SHOULD NOT alter any existing header fields,
- although the host will add an appropriate Received: line as
- required in Section 5.2.8.
-
- A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
- explicit source route using the "@...:" address form. Thus,
- the relay function defined in section 3.6 of RFC-821 should
- not be used.
-
-
-
-Internet Engineering Task Force [Page 51]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- DISCUSSION:
- The intent is to discourage all source routing and to
- abolish explicit source routing for mail delivery within
- the Internet environment. Source-routing is unnecessary;
- the simple target address "user@domain" should always
- suffice. This is the result of an explicit architectural
- decision to use universal naming rather than source
- routing for mail. Thus, SMTP provides end-to-end
- connectivity, and the DNS provides globally-unique,
- location-independent names. MX records handle the major
- case where source routing might otherwise be needed.
-
- A receiver-SMTP MUST accept the explicit source route syntax in
- the envelope, but it MAY implement the relay function as
- defined in section 3.6 of RFC-821. If it does not implement
- the relay function, it SHOULD attempt to deliver the message
- directly to the host to the right of the right-most "@" sign.
-
- DISCUSSION:
- For example, suppose a host that does not implement the
- relay function receives a message with the SMTP command:
- "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
- GAMMA represent domain names. Rather than immediately
- refusing the message with a 550 error reply as suggested
- on page 20 of RFC-821, the host should try to forward the
- message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
- Since this host does not support relaying, it is not
- required to update the reverse path.
-
- Some have suggested that source routing may be needed
- occasionally for manually routing mail around failures;
- however, the reality and importance of this need is
- controversial. The use of explicit SMTP mail relaying for
- this purpose is discouraged, and in fact it may not be
- successful, as many host systems do not support it. Some
- have used the "%-hack" (see Section 5.2.16) for this
- purpose.
-
- 5.2.7 RCPT Command: RFC-821 Section 4.1.1
-
- A host that supports a receiver-SMTP MUST support the reserved
- mailbox "Postmaster".
-
- The receiver-SMTP MAY verify RCPT parameters as they arrive;
- however, RCPT responses MUST NOT be delayed beyond a reasonable
- time (see Section 5.3.2).
-
- Therefore, a "250 OK" response to a RCPT does not necessarily
-
-
-
-Internet Engineering Task Force [Page 52]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- imply that the delivery address(es) are valid. Errors found
- after message acceptance will be reported by mailing a
- notification message to an appropriate address (see Section
- 5.3.3).
-
- DISCUSSION:
- The set of conditions under which a RCPT parameter can be
- validated immediately is an engineering design choice.
- Reporting destination mailbox errors to the Sender-SMTP
- before mail is transferred is generally desirable to save
- time and network bandwidth, but this advantage is lost if
- RCPT verification is lengthy.
-
- For example, the receiver can verify immediately any
- simple local reference, such as a single locally-
- registered mailbox. On the other hand, the "reasonable
- time" limitation generally implies deferring verification
- of a mailing list until after the message has been
- transferred and accepted, since verifying a large mailing
- list can take a very long time. An implementation might
- or might not choose to defer validation of addresses that
- are non-local and therefore require a DNS lookup. If a
- DNS lookup is performed but a soft domain system error
- (e.g., timeout) occurs, validity must be assumed.
-
- 5.2.8 DATA Command: RFC-821 Section 4.1.1
-
- Every receiver-SMTP (not just one that "accepts a message for
- relaying or for final delivery" [SMTP:1]) MUST insert a
- "Received:" line at the beginning of a message. In this line,
- called a "time stamp line" in RFC-821:
-
- * The FROM field SHOULD contain both (1) the name of the
- source host as presented in the HELO command and (2) a
- domain literal containing the IP address of the source,
- determined from the TCP connection.
-
- * The ID field MAY contain an "@" as suggested in RFC-822,
- but this is not required.
-
- * The FOR field MAY contain a list of <path> entries when
- multiple RCPT commands have been given.
-
-
- An Internet mail program MUST NOT change a Received: line that
- was previously added to the message header.
-
-
-
-
-
-Internet Engineering Task Force [Page 53]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- DISCUSSION:
- Including both the source host and the IP source address
- in the Received: line may provide enough information for
- tracking illicit mail sources and eliminate a need to
- explicitly verify the HELO parameter.
-
- Received: lines are primarily intended for humans tracing
- mail routes, primarily of diagnosis of faults. See also
- the discussion under 5.3.7.
-
- When the receiver-SMTP makes "final delivery" of a message,
- then it MUST pass the MAIL FROM: address from the SMTP envelope
- with the message, for use if an error notification message must
- be sent later (see Section 5.3.3). There is an analogous
- requirement when gatewaying from the Internet into a different
- mail environment; see Section 5.3.7.
-
- DISCUSSION:
- Note that the final reply to the DATA command depends only
- upon the successful transfer and storage of the message.
- Any problem with the destination address(es) must either
- (1) have been reported in an SMTP error reply to the RCPT
- command(s), or (2) be reported in a later error message
- mailed to the originator.
-
- IMPLEMENTATION:
- The MAIL FROM: information may be passed as a parameter or
- in a Return-Path: line inserted at the beginning of the
- message.
-
- 5.2.9 Command Syntax: RFC-821 Section 4.1.2
-
- The syntax shown in RFC-821 for the MAIL FROM: command omits
- the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page
- 15). An empty reverse path MUST be supported.
-
- 5.2.10 SMTP Replies: RFC-821 Section 4.2
-
- A receiver-SMTP SHOULD send only the reply codes listed in
- section 4.2.2 of RFC-821 or in this document. A receiver-SMTP
- SHOULD use the text shown in examples in RFC-821 whenever
- appropriate.
-
- A sender-SMTP MUST determine its actions only by the reply
- code, not by the text (except for 251 and 551 replies); any
- text, including no text at all, must be acceptable. The space
- (blank) following the reply code is considered part of the
- text. Whenever possible, a sender-SMTP SHOULD test only the
-
-
-
-Internet Engineering Task Force [Page 54]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- first digit of the reply code, as specified in Appendix E of
- RFC-821.
-
- DISCUSSION:
- Interoperability problems have arisen with SMTP systems
- using reply codes that are not listed explicitly in RFC-
- 821 Section 4.3 but are legal according to the theory of
- reply codes explained in Appendix E.
-
- 5.2.11 Transparency: RFC-821 Section 4.5.2
-
- Implementors MUST be sure that their mail systems always add
- and delete periods to ensure message transparency.
-
- 5.2.12 WKS Use in MX Processing: RFC-974, p. 5
-
- RFC-974 [SMTP:3] recommended that the domain system be queried
- for WKS ("Well-Known Service") records, to verify that each
- proposed mail target does support SMTP. Later experience has
- shown that WKS is not widely supported, so the WKS step in MX
- processing SHOULD NOT be used.
-
- The following are notes on RFC-822, organized by section of that
- document.
-
- 5.2.13 RFC-822 Message Specification: RFC-822 Section 4
-
- The syntax shown for the Return-path line omits the possibility
- of a null return path, which is used to prevent looping of
- error notifications (see Section 5.3.3). The complete syntax
- is:
-
- return = "Return-path" ":" route-addr
- / "Return-path" ":" "<" ">"
-
- The set of optional header fields is hereby expanded to include
- the Content-Type field defined in RFC-1049 [SMTP:7]. This
- field "allows mail reading systems to automatically identify
- the type of a structured message body and to process it for
- display accordingly". [SMTP:7] A User Agent MAY support this
- field.
-
- 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5
-
- The syntax for the date is hereby changed to:
-
- date = 1*2DIGIT month 2*4DIGIT
-
-
-
-
-Internet Engineering Task Force [Page 55]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- All mail software SHOULD use 4-digit years in dates, to ease
- the transition to the next century.
-
- There is a strong trend towards the use of numeric timezone
- indicators, and implementations SHOULD use numeric timezones
- instead of timezone names. However, all implementations MUST
- accept either notation. If timezone names are used, they MUST
- be exactly as defined in RFC-822.
-
- The military time zones are specified incorrectly in RFC-822:
- they count the wrong way from UT (the signs are reversed). As
- a result, military time zones in RFC-822 headers carry no
- information.
-
- Finally, note that there is a typo in the definition of "zone"
- in the syntax summary of appendix D; the correct definition
- occurs in Section 3 of RFC-822.
-
- 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1
-
- The syntactic definition of "mailbox" in RFC-822 is hereby
- changed to:
-
- mailbox = addr-spec ; simple address
- / [phrase] route-addr ; name & addr-spec
-
- That is, the phrase preceding a route address is now OPTIONAL.
- This change makes the following header field legal, for
- example:
-
- From: <craig@nnsc.nsf.net>
-
- 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2
-
- The basic mailbox address specification has the form: "local-
- part@domain". Here "local-part", sometimes called the "left-
- hand side" of the address, is domain-dependent.
-
- A host that is forwarding the message but is not the
- destination host implied by the right-hand side "domain" MUST
- NOT interpret or modify the "local-part" of the address.
-
- When mail is to be gatewayed from the Internet mail environment
- into a foreign mail environment (see Section 5.3.7), routing
- information for that foreign environment MAY be embedded within
- the "local-part" of the address. The gateway will then
- interpret this local part appropriately for the foreign mail
- environment.
-
-
-
-Internet Engineering Task Force [Page 56]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- DISCUSSION:
- Although source routes are discouraged within the Internet
- (see Section 5.2.6), there are non-Internet mail
- environments whose delivery mechanisms do depend upon
- source routes. Source routes for extra-Internet
- environments can generally be buried in the "local-part"
- of the address (see Section 5.2.16) while mail traverses
- the Internet. When the mail reaches the appropriate
- Internet mail gateway, the gateway will interpret the
- local-part and build the necessary address or route for
- the target mail environment.
-
- For example, an Internet host might send mail to:
- "a!b!c!user@gateway-domain". The complex local part
- "a!b!c!user" would be uninterpreted within the Internet
- domain, but could be parsed and understood by the
- specified mail gateway.
-
- An embedded source route is sometimes encoded in the
- "local-part" using "%" as a right-binding routing
- operator. For example, in:
-
- user%domain%relay3%relay2@relay1
-
- the "%" convention implies that the mail is to be routed
- from "relay1" through "relay2", "relay3", and finally to
- "user" at "domain". This is commonly known as the "%-
- hack". It is suggested that "%" have lower precedence
- than any other routing operator (e.g., "!") hidden in the
- local-part; for example, "a!b%c" would be interpreted as
- "(a!b)%c".
-
- Only the target host (in this case, "relay1") is permitted
- to analyze the local-part "user%domain%relay3%relay2".
-
- 5.2.17 Domain Literals: RFC-822 Section 6.2.3
-
- A mailer MUST be able to accept and parse an Internet domain
- literal whose content ("dtext"; see RFC-822) is a dotted-
- decimal host address. This satisfies the requirement of
- Section 2.1 for the case of mail.
-
- An SMTP MUST accept and recognize a domain literal for any of
- its own IP addresses.
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 57]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1
-
- Errors in formatting or parsing 822 addresses are unfortunately
- common. This section mentions only the most common errors. A
- User Agent MUST accept all valid RFC-822 address formats, and
- MUST NOT generate illegal address syntax.
-
- o A common error is to leave out the semicolon after a group
- identifier.
-
- o Some systems fail to fully-qualify domain names in
- messages they generate. The right-hand side of an "@"
- sign in a header address field MUST be a fully-qualified
- domain name.
-
- For example, some systems fail to fully-qualify the From:
- address; this prevents a "reply" command in the user
- interface from automatically constructing a return
- address.
-
- DISCUSSION:
- Although RFC-822 allows the local use of abbreviated
- domain names within a domain, the application of
- RFC-822 in Internet mail does not allow this. The
- intent is that an Internet host must not send an SMTP
- message header containing an abbreviated domain name
- in an address field. This allows the address fields
- of the header to be passed without alteration across
- the Internet, as required in Section 5.2.6.
-
- o Some systems mis-parse multiple-hop explicit source routes
- such as:
-
- @relay1,@relay2,@relay3:user@domain.
-
-
- o Some systems over-qualify domain names by adding a
- trailing dot to some or all domain names in addresses or
- message-ids. This violates RFC-822 syntax.
-
-
- 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7
-
- Internet host software SHOULD NOT create an RFC-822 header
- containing an address with an explicit source route, but MUST
- accept such headers for compatibility with earlier systems.
-
- DISCUSSION:
-
-
-
-Internet Engineering Task Force [Page 58]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- In an understatement, RFC-822 says "The use of explicit
- source routing is discouraged". Many hosts implemented
- RFC-822 source routes incorrectly, so the syntax cannot be
- used unambiguously in practice. Many users feel the
- syntax is ugly. Explicit source routes are not needed in
- the mail envelope for delivery; see Section 5.2.6. For
- all these reasons, explicit source routes using the RFC-
- 822 notations are not to be used in Internet mail headers.
-
- As stated in Section 5.2.16, it is necessary to allow an
- explicit source route to be buried in the local-part of an
- address, e.g., using the "%-hack", in order to allow mail
- to be gatewayed into another environment in which explicit
- source routing is necessary. The vigilant will observe
- that there is no way for a User Agent to detect and
- prevent the use of such implicit source routing when the
- destination is within the Internet. We can only
- discourage source routing of any kind within the Internet,
- as unnecessary and undesirable.
-
- 5.3 SPECIFIC ISSUES
-
- 5.3.1 SMTP Queueing Strategies
-
- The common structure of a host SMTP implementation includes
- user mailboxes, one or more areas for queueing messages in
- transit, and one or more daemon processes for sending and
- receiving mail. The exact structure will vary depending on the
- needs of the users on the host and the number and size of
- mailing lists supported by the host. We describe several
- optimizations that have proved helpful, particularly for
- mailers supporting high traffic levels.
-
- Any queueing strategy MUST include:
-
- o Timeouts on all activities. See Section 5.3.2.
-
- o Never sending error messages in response to error
- messages.
-
-
- 5.3.1.1 Sending Strategy
-
- The general model of a sender-SMTP is one or more processes
- that periodically attempt to transmit outgoing mail. In a
- typical system, the program that composes a message has some
- method for requesting immediate attention for a new piece of
- outgoing mail, while mail that cannot be transmitted
-
-
-
-Internet Engineering Task Force [Page 59]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- immediately MUST be queued and periodically retried by the
- sender. A mail queue entry will include not only the
- message itself but also the envelope information.
-
- The sender MUST delay retrying a particular destination
- after one attempt has failed. In general, the retry
- interval SHOULD be at least 30 minutes; however, more
- sophisticated and variable strategies will be beneficial
- when the sender-SMTP can determine the reason for non-
- delivery.
-
- Retries continue until the message is transmitted or the
- sender gives up; the give-up time generally needs to be at
- least 4-5 days. The parameters to the retry algorithm MUST
- be configurable.
-
- A sender SHOULD keep a list of hosts it cannot reach and
- corresponding timeouts, rather than just retrying queued
- mail items.
-
- DISCUSSION:
- Experience suggests that failures are typically
- transient (the target system has crashed), favoring a
- policy of two connection attempts in the first hour the
- message is in the queue, and then backing off to once
- every two or three hours.
-
- The sender-SMTP can shorten the queueing delay by
- cooperation with the receiver-SMTP. In particular, if
- mail is received from a particular address, it is good
- evidence that any mail queued for that host can now be
- sent.
-
- The strategy may be further modified as a result of
- multiple addresses per host (see Section 5.3.4), to
- optimize delivery time vs. resource usage.
-
- A sender-SMTP may have a large queue of messages for
- each unavailable destination host, and if it retried
- all these messages in every retry cycle, there would be
- excessive Internet overhead and the daemon would be
- blocked for a long period. Note that an SMTP can
- generally determine that a delivery attempt has failed
- only after a timeout of a minute or more; a one minute
- timeout per connection will result in a very large
- delay if it is repeated for dozens or even hundreds of
- queued messages.
-
-
-
-
-Internet Engineering Task Force [Page 60]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- When the same message is to be delivered to several users on
- the same host, only one copy of the message SHOULD be
- transmitted. That is, the sender-SMTP should use the
- command sequence: RCPT, RCPT,... RCPT, DATA instead of the
- sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
- Implementation of this efficiency feature is strongly urged.
-
- Similarly, the sender-SMTP MAY support multiple concurrent
- outgoing mail transactions to achieve timely delivery.
- However, some limit SHOULD be imposed to protect the host
- from devoting all its resources to mail.
-
- The use of the different addresses of a multihomed host is
- discussed below.
-
- 5.3.1.2 Receiving strategy
-
- The receiver-SMTP SHOULD attempt to keep a pending listen on
- the SMTP port at all times. This will require the support
- of multiple incoming TCP connections for SMTP. Some limit
- MAY be imposed.
-
- IMPLEMENTATION:
- When the receiver-SMTP receives mail from a particular
- host address, it could notify the sender-SMTP to retry
- any mail pending for that host address.
-
- 5.3.2 Timeouts in SMTP
-
- There are two approaches to timeouts in the sender-SMTP: (a)
- limit the time for each SMTP command separately, or (b) limit
- the time for the entire SMTP dialogue for a single mail
- message. A sender-SMTP SHOULD use option (a), per-command
- timeouts. Timeouts SHOULD be easily reconfigurable, preferably
- without recompiling the SMTP code.
-
- DISCUSSION:
- Timeouts are an essential feature of an SMTP
- implementation. If the timeouts are too long (or worse,
- there are no timeouts), Internet communication failures or
- software bugs in receiver-SMTP programs can tie up SMTP
- processes indefinitely. If the timeouts are too short,
- resources will be wasted with attempts that time out part
- way through message delivery.
-
- If option (b) is used, the timeout has to be very large,
- e.g., an hour, to allow time to expand very large mailing
- lists. The timeout may also need to increase linearly
-
-
-
-Internet Engineering Task Force [Page 61]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- with the size of the message, to account for the time to
- transmit a very large message. A large fixed timeout
- leads to two problems: a failure can still tie up the
- sender for a very long time, and very large messages may
- still spuriously time out (which is a wasteful failure!).
-
- Using the recommended option (a), a timer is set for each
- SMTP command and for each buffer of the data transfer.
- The latter means that the overall timeout is inherently
- proportional to the size of the message.
-
- Based on extensive experience with busy mail-relay hosts, the
- minimum per-command timeout values SHOULD be as follows:
-
- o Initial 220 Message: 5 minutes
-
- A Sender-SMTP process needs to distinguish between a
- failed TCP connection and a delay in receiving the initial
- 220 greeting message. Many receiver-SMTPs will accept a
- TCP connection but delay delivery of the 220 message until
- their system load will permit more mail to be processed.
-
- o MAIL Command: 5 minutes
-
-
- o RCPT Command: 5 minutes
-
- A longer timeout would be required if processing of
- mailing lists and aliases were not deferred until after
- the message was accepted.
-
- o DATA Initiation: 2 minutes
-
- This is while awaiting the "354 Start Input" reply to a
- DATA command.
-
- o Data Block: 3 minutes
-
- This is while awaiting the completion of each TCP SEND
- call transmitting a chunk of data.
-
- o DATA Termination: 10 minutes.
-
- This is while awaiting the "250 OK" reply. When the
- receiver gets the final period terminating the message
- data, it typically performs processing to deliver the
- message to a user mailbox. A spurious timeout at this
- point would be very wasteful, since the message has been
-
-
-
-Internet Engineering Task Force [Page 62]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- successfully sent.
-
- A receiver-SMTP SHOULD have a timeout of at least 5 minutes
- while it is awaiting the next command from the sender.
-
- 5.3.3 Reliable Mail Receipt
-
- When the receiver-SMTP accepts a piece of mail (by sending a
- "250 OK" message in response to DATA), it is accepting
- responsibility for delivering or relaying the message. It must
- take this responsibility seriously, i.e., it MUST NOT lose the
- message for frivolous reasons, e.g., because the host later
- crashes or because of a predictable resource shortage.
-
- If there is a delivery failure after acceptance of a message,
- the receiver-SMTP MUST formulate and mail a notification
- message. This notification MUST be sent using a null ("<>")
- reverse path in the envelope; see Section 3.6 of RFC-821. The
- recipient of this notification SHOULD be the address from the
- envelope return path (or the Return-Path: line). However, if
- this address is null ("<>"), the receiver-SMTP MUST NOT send a
- notification. If the address is an explicit source route, it
- SHOULD be stripped down to its final hop.
-
- DISCUSSION:
- For example, suppose that an error notification must be
- sent for a message that arrived with:
- "MAIL FROM:<@a,@b:user@d>". The notification message
- should be sent to: "RCPT TO:<user@d>".
-
- Some delivery failures after the message is accepted by
- SMTP will be unavoidable. For example, it may be
- impossible for the receiver-SMTP to validate all the
- delivery addresses in RCPT command(s) due to a "soft"
- domain system error or because the target is a mailing
- list (see earlier discussion of RCPT).
-
- To avoid receiving duplicate messages as the result of
- timeouts, a receiver-SMTP MUST seek to minimize the time
- required to respond to the final "." that ends a message
- transfer. See RFC-1047 [SMTP:4] for a discussion of this
- problem.
-
- 5.3.4 Reliable Mail Transmission
-
- To transmit a message, a sender-SMTP determines the IP address
- of the target host from the destination address in the
- envelope. Specifically, it maps the string to the right of the
-
-
-
-Internet Engineering Task Force [Page 63]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- "@" sign into an IP address. This mapping or the transfer
- itself may fail with a soft error, in which case the sender-
- SMTP will requeue the outgoing mail for a later retry, as
- required in Section 5.3.1.1.
-
- When it succeeds, the mapping can result in a list of
- alternative delivery addresses rather than a single address,
- because of (a) multiple MX records, (b) multihoming, or both.
- To provide reliable mail transmission, the sender-SMTP MUST be
- able to try (and retry) each of the addresses in this list in
- order, until a delivery attempt succeeds. However, there MAY
- also be a configurable limit on the number of alternate
- addresses that can be tried. In any case, a host SHOULD try at
- least two addresses.
-
- The following information is to be used to rank the host
- addresses:
-
- (1) Multiple MX Records -- these contain a preference
- indication that should be used in sorting. If there are
- multiple destinations with the same preference and there
- is no clear reason to favor one (e.g., by address
- preference), then the sender-SMTP SHOULD pick one at
- random to spread the load across multiple mail exchanges
- for a specific organization; note that this is a
- refinement of the procedure in [DNS:3].
-
- (2) Multihomed host -- The destination host (perhaps taken
- from the preferred MX record) may be multihomed, in which
- case the domain name resolver will return a list of
- alternative IP addresses. It is the responsibility of the
- domain name resolver interface (see Section 6.1.3.4 below)
- to have ordered this list by decreasing preference, and
- SMTP MUST try them in the order presented.
-
- DISCUSSION:
- Although the capability to try multiple alternative
- addresses is required, there may be circumstances where
- specific installations want to limit or disable the use of
- alternative addresses. The question of whether a sender
- should attempt retries using the different addresses of a
- multihomed host has been controversial. The main argument
- for using the multiple addresses is that it maximizes the
- probability of timely delivery, and indeed sometimes the
- probability of any delivery; the counter argument is that
- it may result in unnecessary resource use.
-
- Note that resource use is also strongly determined by the
-
-
-
-Internet Engineering Task Force [Page 64]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- sending strategy discussed in Section 5.3.1.
-
- 5.3.5 Domain Name Support
-
- SMTP implementations MUST use the mechanism defined in Section
- 6.1 for mapping between domain names and IP addresses. This
- means that every Internet SMTP MUST include support for the
- Internet DNS.
-
- In particular, a sender-SMTP MUST support the MX record scheme
- [SMTP:3]. See also Section 7.4 of [DNS:2] for information on
- domain name support for SMTP.
-
- 5.3.6 Mailing Lists and Aliases
-
- An SMTP-capable host SHOULD support both the alias and the list
- form of address expansion for multiple delivery. When a
- message is delivered or forwarded to each address of an
- expanded list form, the return address in the envelope
- ("MAIL FROM:") MUST be changed to be the address of a person
- who administers the list, but the message header MUST be left
- unchanged; in particular, the "From" field of the message is
- unaffected.
-
- DISCUSSION:
- An important mail facility is a mechanism for multi-
- destination delivery of a single message, by transforming
- or "expanding" a pseudo-mailbox address into a list of
- destination mailbox addresses. When a message is sent to
- such a pseudo-mailbox (sometimes called an "exploder"),
- copies are forwarded or redistributed to each mailbox in
- the expanded list. We classify such a pseudo-mailbox as
- an "alias" or a "list", depending upon the expansion
- rules:
-
- (a) Alias
-
- To expand an alias, the recipient mailer simply
- replaces the pseudo-mailbox address in the envelope
- with each of the expanded addresses in turn; the rest
- of the envelope and the message body are left
- unchanged. The message is then delivered or
- forwarded to each expanded address.
-
- (b) List
-
- A mailing list may be said to operate by
- "redistribution" rather than by "forwarding". To
-
-
-
-Internet Engineering Task Force [Page 65]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- expand a list, the recipient mailer replaces the
- pseudo-mailbox address in the envelope with each of
- the expanded addresses in turn. The return address in
- the envelope is changed so that all error messages
- generated by the final deliveries will be returned to
- a list administrator, not to the message originator,
- who generally has no control over the contents of the
- list and will typically find error messages annoying.
-
-
- 5.3.7 Mail Gatewaying
-
- Gatewaying mail between different mail environments, i.e.,
- different mail formats and protocols, is complex and does not
- easily yield to standardization. See for example [SMTP:5a],
- [SMTP:5b]. However, some general requirements may be given for
- a gateway between the Internet and another mail environment.
-
- (A) Header fields MAY be rewritten when necessary as messages
- are gatewayed across mail environment boundaries.
-
- DISCUSSION:
- This may involve interpreting the local-part of the
- destination address, as suggested in Section 5.2.16.
-
- The other mail systems gatewayed to the Internet
- generally use a subset of RFC-822 headers, but some
- of them do not have an equivalent to the SMTP
- envelope. Therefore, when a message leaves the
- Internet environment, it may be necessary to fold the
- SMTP envelope information into the message header. A
- possible solution would be to create new header
- fields to carry the envelope information (e.g., "X-
- SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
- require changes in mail programs in the foreign
- environment.
-
- (B) When forwarding a message into or out of the Internet
- environment, a gateway MUST prepend a Received: line, but
- it MUST NOT alter in any way a Received: line that is
- already in the header.
-
- DISCUSSION:
- This requirement is a subset of the general
- "Received:" line requirement of Section 5.2.8; it is
- restated here for emphasis.
-
- Received: fields of messages originating from other
-
-
-
-Internet Engineering Task Force [Page 66]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- environments may not conform exactly to RFC822.
- However, the most important use of Received: lines is
- for debugging mail faults, and this debugging can be
- severely hampered by well-meaning gateways that try
- to "fix" a Received: line.
-
- The gateway is strongly encouraged to indicate the
- environment and protocol in the "via" clauses of
- Received field(s) that it supplies.
-
- (C) From the Internet side, the gateway SHOULD accept all
- valid address formats in SMTP commands and in RFC-822
- headers, and all valid RFC-822 messages. Although a
- gateway must accept an RFC-822 explicit source route
- ("@...:" format) in either the RFC-822 header or in the
- envelope, it MAY or may not act on the source route; see
- Sections 5.2.6 and 5.2.19.
-
- DISCUSSION:
- It is often tempting to restrict the range of
- addresses accepted at the mail gateway to simplify
- the translation into addresses for the remote
- environment. This practice is based on the
- assumption that mail users have control over the
- addresses their mailers send to the mail gateway. In
- practice, however, users have little control over the
- addresses that are finally sent; their mailers are
- free to change addresses into any legal RFC-822
- format.
-
- (D) The gateway MUST ensure that all header fields of a
- message that it forwards into the Internet meet the
- requirements for Internet mail. In particular, all
- addresses in "From:", "To:", "Cc:", etc., fields must be
- transformed (if necessary) to satisfy RFC-822 syntax, and
- they must be effective and useful for sending replies.
-
-
- (E) The translation algorithm used to convert mail from the
- Internet protocols to another environment's protocol
- SHOULD try to ensure that error messages from the foreign
- mail environment are delivered to the return path from the
- SMTP envelope, not to the sender listed in the "From:"
- field of the RFC-822 message.
-
- DISCUSSION:
- Internet mail lists usually place the address of the
- mail list maintainer in the envelope but leave the
-
-
-
-Internet Engineering Task Force [Page 67]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- original message header intact (with the "From:"
- field containing the original sender). This yields
- the behavior the average recipient expects: a reply
- to the header gets sent to the original sender, not
- to a mail list maintainer; however, errors get sent
- to the maintainer (who can fix the problem) and not
- the sender (who probably cannot).
-
- (F) Similarly, when forwarding a message from another
- environment into the Internet, the gateway SHOULD set the
- envelope return path in accordance with an error message
- return address, if any, supplied by the foreign
- environment.
-
-
- 5.3.8 Maximum Message Size
-
- Mailer software MUST be able to send and receive messages of at
- least 64K bytes in length (including header), and a much larger
- maximum size is highly desirable.
-
- DISCUSSION:
- Although SMTP does not define the maximum size of a
- message, many systems impose implementation limits.
-
- The current de facto minimum limit in the Internet is 64K
- bytes. However, electronic mail is used for a variety of
- purposes that create much larger messages. For example,
- mail is often used instead of FTP for transmitting ASCII
- files, and in particular to transmit entire documents. As
- a result, messages can be 1 megabyte or even larger. We
- note that the present document together with its lower-
- layer companion contains 0.5 megabytes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 68]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- 5.4 SMTP REQUIREMENTS SUMMARY
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
------------------------------------------------|----------|-|-|-|-|-|--
- | | | | | | |
-RECEIVER-SMTP: | | | | | | |
- Implement VRFY |5.2.3 |x| | | | |
- Implement EXPN |5.2.3 | |x| | | |
- EXPN, VRFY configurable |5.2.3 | | |x| | |
- Implement SEND, SOML, SAML |5.2.4 | | |x| | |
- Verify HELO parameter |5.2.5 | | |x| | |
- Refuse message with bad HELO |5.2.5 | | | | |x|
- Accept explicit src-route syntax in env. |5.2.6 |x| | | | |
- Support "postmaster" |5.2.7 |x| | | | |
- Process RCPT when received (except lists) |5.2.7 | | |x| | |
- Long delay of RCPT responses |5.2.7 | | | | |x|
- | | | | | | |
- Add Received: line |5.2.8 |x| | | | |
- Received: line include domain literal |5.2.8 | |x| | | |
- Change previous Received: line |5.2.8 | | | | |x|
- Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | |
- Support empty reverse path |5.2.9 |x| | | | |
- Send only official reply codes |5.2.10 | |x| | | |
- Send text from RFC-821 when appropriate |5.2.10 | |x| | | |
- Delete "." for transparency |5.2.11 |x| | | | |
- Accept and recognize self domain literal(s) |5.2.17 |x| | | | |
- | | | | | | |
- Error message about error message |5.3.1 | | | | |x|
- Keep pending listen on SMTP port |5.3.1.2 | |x| | | |
- Provide limit on recv concurrency |5.3.1.2 | | |x| | |
- Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | |
- Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x|
- Send error notification msg after accept |5.3.3 |x| | | | |
- Send using null return path |5.3.3 |x| | | | |
- Send to envelope return path |5.3.3 | |x| | | |
- Send to null address |5.3.3 | | | | |x|
- Strip off explicit src route |5.3.3 | |x| | | |
- Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | |
------------------------------------------------|----------|-|-|-|-|-|--
-
-
-
-Internet Engineering Task Force [Page 69]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- | | | | | | |
-SENDER-SMTP: | | | | | | |
- Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | |
- Implement SEND, SOML, SAML |5.2.4 | | |x| | |
- Send valid principal host name in HELO |5.2.5 |x| | | | |
- Send explicit source route in RCPT TO: |5.2.6 | | | |x| |
- Use only reply code to determine action |5.2.10 |x| | | | |
- Use only high digit of reply code when poss. |5.2.10 | |x| | | |
- Add "." for transparency |5.2.11 |x| | | | |
- | | | | | | |
- Retry messages after soft failure |5.3.1.1 |x| | | | |
- Delay before retry |5.3.1.1 |x| | | | |
- Configurable retry parameters |5.3.1.1 |x| | | | |
- Retry once per each queued dest host |5.3.1.1 | |x| | | |
- Multiple RCPT's for same DATA |5.3.1.1 | |x| | | |
- Support multiple concurrent transactions |5.3.1.1 | | |x| | |
- Provide limit on concurrency |5.3.1.1 | |x| | | |
- | | | | | | |
- Timeouts on all activities |5.3.1 |x| | | | |
- Per-command timeouts |5.3.2 | |x| | | |
- Timeouts easily reconfigurable |5.3.2 | |x| | | |
- Recommended times |5.3.2 | |x| | | |
- Try alternate addr's in order |5.3.4 |x| | | | |
- Configurable limit on alternate tries |5.3.4 | | |x| | |
- Try at least two alternates |5.3.4 | |x| | | |
- Load-split across equal MX alternates |5.3.4 | |x| | | |
- Use the Domain Name System |5.3.5 |x| | | | |
- Support MX records |5.3.5 |x| | | | |
- Use WKS records in MX processing |5.2.12 | | | |x| |
------------------------------------------------|----------|-|-|-|-|-|--
- | | | | | | |
-MAIL FORWARDING: | | | | | | |
- Alter existing header field(s) |5.2.6 | | | |x| |
- Implement relay function: 821/section 3.6 |5.2.6 | | |x| | |
- If not, deliver to RHS domain |5.2.6 | |x| | | |
- Interpret 'local-part' of addr |5.2.16 | | | | |x|
- | | | | | | |
-MAILING LISTS AND ALIASES | | | | | | |
- Support both |5.3.6 | |x| | | |
- Report mail list error to local admin. |5.3.6 |x| | | | |
- | | | | | | |
-MAIL GATEWAYS: | | | | | | |
- Embed foreign mail route in local-part |5.2.16 | | |x| | |
- Rewrite header fields when necessary |5.3.7 | | |x| | |
- Prepend Received: line |5.3.7 |x| | | | |
- Change existing Received: line |5.3.7 | | | | |x|
- Accept full RFC-822 on Internet side |5.3.7 | |x| | | |
- Act on RFC-822 explicit source route |5.3.7 | | |x| | |
-
-
-
-Internet Engineering Task Force [Page 70]
-
-
-
-
-RFC1123 MAIL -- SMTP & RFC-822 October 1989
-
-
- Send only valid RFC-822 on Internet side |5.3.7 |x| | | | |
- Deliver error msgs to envelope addr |5.3.7 | |x| | | |
- Set env return path from err return addr |5.3.7 | |x| | | |
- | | | | | | |
-USER AGENT -- RFC-822 | | | | | | |
- Allow user to enter <route> address |5.2.6 | | | |x| |
- Support RFC-1049 Content Type field |5.2.13 | | |x| | |
- Use 4-digit years |5.2.14 | |x| | | |
- Generate numeric timezones |5.2.14 | |x| | | |
- Accept all timezones |5.2.14 |x| | | | |
- Use non-num timezones from RFC-822 |5.2.14 |x| | | | |
- Omit phrase before route-addr |5.2.15 | | |x| | |
- Accept and parse dot.dec. domain literals |5.2.17 |x| | | | |
- Accept all RFC-822 address formats |5.2.18 |x| | | | |
- Generate invalid RFC-822 address format |5.2.18 | | | | |x|
- Fully-qualified domain names in header |5.2.18 |x| | | | |
- Create explicit src route in header |5.2.19 | | | |x| |
- Accept explicit src route in header |5.2.19 |x| | | | |
- | | | | | | |
-Send/recv at least 64KB messages |5.3.8 |x| | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 71]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
-6. SUPPORT SERVICES
-
- 6.1 DOMAIN NAME TRANSLATION
-
- 6.1.1 INTRODUCTION
-
- Every host MUST implement a resolver for the Domain Name System
- (DNS), and it MUST implement a mechanism using this DNS
- resolver to convert host names to IP addresses and vice-versa
- [DNS:1, DNS:2].
-
- In addition to the DNS, a host MAY also implement a host name
- translation mechanism that searches a local Internet host
- table. See Section 6.1.3.8 for more information on this
- option.
-
- DISCUSSION:
- Internet host name translation was originally performed by
- searching local copies of a table of all hosts. This
- table became too large to update and distribute in a
- timely manner and too large to fit into many hosts, so the
- DNS was invented.
-
- The DNS creates a distributed database used primarily for
- the translation between host names and host addresses.
- Implementation of DNS software is required. The DNS
- consists of two logically distinct parts: name servers and
- resolvers (although implementations often combine these
- two logical parts in the interest of efficiency) [DNS:2].
-
- Domain name servers store authoritative data about certain
- sections of the database and answer queries about the
- data. Domain resolvers query domain name servers for data
- on behalf of user processes. Every host therefore needs a
- DNS resolver; some host machines will also need to run
- domain name servers. Since no name server has complete
- information, in general it is necessary to obtain
- information from more than one name server to resolve a
- query.
-
- 6.1.2 PROTOCOL WALK-THROUGH
-
- An implementor must study references [DNS:1] and [DNS:2]
- carefully. They provide a thorough description of the theory,
- protocol, and implementation of the domain name system, and
- reflect several years of experience.
-
-
-
-
-
-Internet Engineering Task Force [Page 72]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1
-
- All DNS name servers and resolvers MUST properly handle RRs
- with a zero TTL: return the RR to the client but do not
- cache it.
-
- DISCUSSION:
- Zero TTL values are interpreted to mean that the RR can
- only be used for the transaction in progress, and
- should not be cached; they are useful for extremely
- volatile data.
-
- 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5
-
- A query with "QCLASS=*" SHOULD NOT be used unless the
- requestor is seeking data from more than one class. In
- particular, if the requestor is only interested in Internet
- data types, QCLASS=IN MUST be used.
-
- 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1
-
- Unused fields in a query or response message MUST be zero.
-
- 6.1.2.4 Compression: RFC-1035 Section 4.1.4
-
- Name servers MUST use compression in responses.
-
- DISCUSSION:
- Compression is essential to avoid overflowing UDP
- datagrams; see Section 6.1.3.2.
-
- 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2
-
- Recursive name servers and full-service resolvers generally
- have some configuration information containing hints about
- the location of root or local name servers. An
- implementation MUST NOT include any of these hints in a
- response.
-
- DISCUSSION:
- Many implementors have found it convenient to store
- these hints as if they were cached data, but some
- neglected to ensure that this "cached data" was not
- included in responses. This has caused serious
- problems in the Internet when the hints were obsolete
- or incorrect.
-
-
-
-
-
-Internet Engineering Task Force [Page 73]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- 6.1.3 SPECIFIC ISSUES
-
- 6.1.3.1 Resolver Implementation
-
- A name resolver SHOULD be able to multiplex concurrent
- requests if the host supports concurrent processes.
-
- In implementing a DNS resolver, one of two different models
- MAY optionally be chosen: a full-service resolver, or a stub
- resolver.
-
-
- (A) Full-Service Resolver
-
- A full-service resolver is a complete implementation of
- the resolver service, and is capable of dealing with
- communication failures, failure of individual name
- servers, location of the proper name server for a given
- name, etc. It must satisfy the following requirements:
-
- o The resolver MUST implement a local caching
- function to avoid repeated remote access for
- identical requests, and MUST time out information
- in the cache.
-
- o The resolver SHOULD be configurable with start-up
- information pointing to multiple root name servers
- and multiple name servers for the local domain.
- This insures that the resolver will be able to
- access the whole name space in normal cases, and
- will be able to access local domain information
- should the local network become disconnected from
- the rest of the Internet.
-
-
- (B) Stub Resolver
-
- A "stub resolver" relies on the services of a recursive
- name server on the connected network or a "nearby"
- network. This scheme allows the host to pass on the
- burden of the resolver function to a name server on
- another host. This model is often essential for less
- capable hosts, such as PCs, and is also recommended
- when the host is one of several workstations on a local
- network, because it allows all of the workstations to
- share the cache of the recursive name server and hence
- reduce the number of domain requests exported by the
- local network.
-
-
-
-Internet Engineering Task Force [Page 74]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- At a minimum, the stub resolver MUST be capable of
- directing its requests to redundant recursive name
- servers. Note that recursive name servers are allowed
- to restrict the sources of requests that they will
- honor, so the host administrator must verify that the
- service will be provided. Stub resolvers MAY implement
- caching if they choose, but if so, MUST timeout cached
- information.
-
-
- 6.1.3.2 Transport Protocols
-
- DNS resolvers and recursive servers MUST support UDP, and
- SHOULD support TCP, for sending (non-zone-transfer) queries.
- Specifically, a DNS resolver or server that is sending a
- non-zone-transfer query MUST send a UDP query first. If the
- Answer section of the response is truncated and if the
- requester supports TCP, it SHOULD try the query again using
- TCP.
-
- DNS servers MUST be able to service UDP queries and SHOULD
- be able to service TCP queries. A name server MAY limit the
- resources it devotes to TCP queries, but it SHOULD NOT
- refuse to service a TCP query just because it would have
- succeeded with UDP.
-
- Truncated responses MUST NOT be saved (cached) and later
- used in such a way that the fact that they are truncated is
- lost.
-
- DISCUSSION:
- UDP is preferred over TCP for queries because UDP
- queries have much lower overhead, both in packet count
- and in connection state. The use of UDP is essential
- for heavily-loaded servers, especially the root
- servers. UDP also offers additional robustness, since
- a resolver can attempt several UDP queries to different
- servers for the cost of a single TCP query.
-
- It is possible for a DNS response to be truncated,
- although this is a very rare occurrence in the present
- Internet DNS. Practically speaking, truncation cannot
- be predicted, since it is data-dependent. The
- dependencies include the number of RRs in the answer,
- the size of each RR, and the savings in space realized
- by the name compression algorithm. As a rule of thumb,
- truncation in NS and MX lists should not occur for
- answers containing 15 or fewer RRs.
-
-
-
-Internet Engineering Task Force [Page 75]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- Whether it is possible to use a truncated answer
- depends on the application. A mailer must not use a
- truncated MX response, since this could lead to mail
- loops.
-
- Responsible practices can make UDP suffice in the vast
- majority of cases. Name servers must use compression
- in responses. Resolvers must differentiate truncation
- of the Additional section of a response (which only
- loses extra information) from truncation of the Answer
- section (which for MX records renders the response
- unusable by mailers). Database administrators should
- list only a reasonable number of primary names in lists
- of name servers, MX alternatives, etc.
-
- However, it is also clear that some new DNS record
- types defined in the future will contain information
- exceeding the 512 byte limit that applies to UDP, and
- hence will require TCP. Thus, resolvers and name
- servers should implement TCP services as a backup to
- UDP today, with the knowledge that they will require
- the TCP service in the future.
-
- By private agreement, name servers and resolvers MAY arrange
- to use TCP for all traffic between themselves. TCP MUST be
- used for zone transfers.
-
- A DNS server MUST have sufficient internal concurrency that
- it can continue to process UDP queries while awaiting a
- response or performing a zone transfer on an open TCP
- connection [DNS:2].
-
- A server MAY support a UDP query that is delivered using an
- IP broadcast or multicast address. However, the Recursion
- Desired bit MUST NOT be set in a query that is multicast,
- and MUST be ignored by name servers receiving queries via a
- broadcast or multicast address. A host that sends broadcast
- or multicast DNS queries SHOULD send them only as occasional
- probes, caching the IP address(es) it obtains from the
- response(s) so it can normally send unicast queries.
-
- DISCUSSION:
- Broadcast or (especially) IP multicast can provide a
- way to locate nearby name servers without knowing their
- IP addresses in advance. However, general broadcasting
- of recursive queries can result in excessive and
- unnecessary load on both network and servers.
-
-
-
-
-Internet Engineering Task Force [Page 76]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- 6.1.3.3 Efficient Resource Usage
-
- The following requirements on servers and resolvers are very
- important to the health of the Internet as a whole,
- particularly when DNS services are invoked repeatedly by
- higher level automatic servers, such as mailers.
-
- (1) The resolver MUST implement retransmission controls to
- insure that it does not waste communication bandwidth,
- and MUST impose finite bounds on the resources consumed
- to respond to a single request. See [DNS:2] pages 43-
- 44 for specific recommendations.
-
- (2) After a query has been retransmitted several times
- without a response, an implementation MUST give up and
- return a soft error to the application.
-
- (3) All DNS name servers and resolvers SHOULD cache
- temporary failures, with a timeout period of the order
- of minutes.
-
- DISCUSSION:
- This will prevent applications that immediately
- retry soft failures (in violation of Section 2.2
- of this document) from generating excessive DNS
- traffic.
-
- (4) All DNS name servers and resolvers SHOULD cache
- negative responses that indicate the specified name, or
- data of the specified type, does not exist, as
- described in [DNS:2].
-
- (5) When a DNS server or resolver retries a UDP query, the
- retry interval SHOULD be constrained by an exponential
- backoff algorithm, and SHOULD also have upper and lower
- bounds.
-
- IMPLEMENTATION:
- A measured RTT and variance (if available) should
- be used to calculate an initial retransmission
- interval. If this information is not available, a
- default of no less than 5 seconds should be used.
- Implementations may limit the retransmission
- interval, but this limit must exceed twice the
- Internet maximum segment lifetime plus service
- delay at the name server.
-
- (6) When a resolver or server receives a Source Quench for
-
-
-
-Internet Engineering Task Force [Page 77]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- a query it has issued, it SHOULD take steps to reduce
- the rate of querying that server in the near future. A
- server MAY ignore a Source Quench that it receives as
- the result of sending a response datagram.
-
- IMPLEMENTATION:
- One recommended action to reduce the rate is to
- send the next query attempt to an alternate
- server, if there is one available. Another is to
- backoff the retry interval for the same server.
-
-
- 6.1.3.4 Multihomed Hosts
-
- When the host name-to-address function encounters a host
- with multiple addresses, it SHOULD rank or sort the
- addresses using knowledge of the immediately connected
- network number(s) and any other applicable performance or
- history information.
-
- DISCUSSION:
- The different addresses of a multihomed host generally
- imply different Internet paths, and some paths may be
- preferable to others in performance, reliability, or
- administrative restrictions. There is no general way
- for the domain system to determine the best path. A
- recommended approach is to base this decision on local
- configuration information set by the system
- administrator.
-
- IMPLEMENTATION:
- The following scheme has been used successfully:
-
- (a) Incorporate into the host configuration data a
- Network-Preference List, that is simply a list of
- networks in preferred order. This list may be
- empty if there is no preference.
-
- (b) When a host name is mapped into a list of IP
- addresses, these addresses should be sorted by
- network number, into the same order as the
- corresponding networks in the Network-Preference
- List. IP addresses whose networks do not appear
- in the Network-Preference List should be placed at
- the end of the list.
-
-
-
-
-
-
-Internet Engineering Task Force [Page 78]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- 6.1.3.5 Extensibility
-
- DNS software MUST support all well-known, class-independent
- formats [DNS:2], and SHOULD be written to minimize the
- trauma associated with the introduction of new well-known
- types and local experimentation with non-standard types.
-
- DISCUSSION:
- The data types and classes used by the DNS are
- extensible, and thus new types will be added and old
- types deleted or redefined. Introduction of new data
- types ought to be dependent only upon the rules for
- compression of domain names inside DNS messages, and
- the translation between printable (i.e., master file)
- and internal formats for Resource Records (RRs).
-
- Compression relies on knowledge of the format of data
- inside a particular RR. Hence compression must only be
- used for the contents of well-known, class-independent
- RRs, and must never be used for class-specific RRs or
- RR types that are not well-known. The owner name of an
- RR is always eligible for compression.
-
- A name server may acquire, via zone transfer, RRs that
- the server doesn't know how to convert to printable
- format. A resolver can receive similar information as
- the result of queries. For proper operation, this data
- must be preserved, and hence the implication is that
- DNS software cannot use textual formats for internal
- storage.
-
- The DNS defines domain name syntax very generally -- a
- string of labels each containing up to 63 8-bit octets,
- separated by dots, and with a maximum total of 255
- octets. Particular applications of the DNS are
- permitted to further constrain the syntax of the domain
- names they use, although the DNS deployment has led to
- some applications allowing more general names. In
- particular, Section 2.1 of this document liberalizes
- slightly the syntax of a legal Internet host name that
- was defined in RFC-952 [DNS:4].
-
- 6.1.3.6 Status of RR Types
-
- Name servers MUST be able to load all RR types except MD and
- MF from configuration files. The MD and MF types are
- obsolete and MUST NOT be implemented; in particular, name
- servers MUST NOT load these types from configuration files.
-
-
-
-Internet Engineering Task Force [Page 79]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- DISCUSSION:
- The RR types MB, MG, MR, NULL, MINFO and RP are
- considered experimental, and applications that use the
- DNS cannot expect these RR types to be supported by
- most domains. Furthermore these types are subject to
- redefinition.
-
- The TXT and WKS RR types have not been widely used by
- Internet sites; as a result, an application cannot rely
- on the the existence of a TXT or WKS RR in most
- domains.
-
- 6.1.3.7 Robustness
-
- DNS software may need to operate in environments where the
- root servers or other servers are unavailable due to network
- connectivity or other problems. In this situation, DNS name
- servers and resolvers MUST continue to provide service for
- the reachable part of the name space, while giving temporary
- failures for the rest.
-
- DISCUSSION:
- Although the DNS is meant to be used primarily in the
- connected Internet, it should be possible to use the
- system in networks which are unconnected to the
- Internet. Hence implementations must not depend on
- access to root servers before providing service for
- local names.
-
- 6.1.3.8 Local Host Table
-
- DISCUSSION:
- A host may use a local host table as a backup or
- supplement to the DNS. This raises the question of
- which takes precedence, the DNS or the host table; the
- most flexible approach would make this a configuration
- option.
-
- Typically, the contents of such a supplementary host
- table will be determined locally by the site. However,
- a publically-available table of Internet hosts is
- maintained by the DDN Network Information Center (DDN
- NIC), with a format documented in [DNS:4]. This table
- can be retrieved from the DDN NIC using a protocol
- described in [DNS:5]. It must be noted that this table
- contains only a small fraction of all Internet hosts.
- Hosts using this protocol to retrieve the DDN NIC host
- table should use the VERSION command to check if the
-
-
-
-Internet Engineering Task Force [Page 80]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- table has changed before requesting the entire table
- with the ALL command. The VERSION identifier should be
- treated as an arbitrary string and tested only for
- equality; no numerical sequence may be assumed.
-
- The DDN NIC host table includes administrative
- information that is not needed for host operation and
- is therefore not currently included in the DNS
- database; examples include network and gateway entries.
- However, much of this additional information will be
- added to the DNS in the future. Conversely, the DNS
- provides essential services (in particular, MX records)
- that are not available from the DDN NIC host table.
-
- 6.1.4 DNS USER INTERFACE
-
- 6.1.4.1 DNS Administration
-
- This document is concerned with design and implementation
- issues in host software, not with administrative or
- operational issues. However, administrative issues are of
- particular importance in the DNS, since errors in particular
- segments of this large distributed database can cause poor
- or erroneous performance for many sites. These issues are
- discussed in [DNS:6] and [DNS:7].
-
- 6.1.4.2 DNS User Interface
-
- Hosts MUST provide an interface to the DNS for all
- application programs running on the host. This interface
- will typically direct requests to a system process to
- perform the resolver function [DNS:1, 6.1:2].
-
- At a minimum, the basic interface MUST support a request for
- all information of a specific type and class associated with
- a specific name, and it MUST return either all of the
- requested information, a hard error code, or a soft error
- indication. When there is no error, the basic interface
- returns the complete response information without
- modification, deletion, or ordering, so that the basic
- interface will not need to be changed to accommodate new
- data types.
-
- DISCUSSION:
- The soft error indication is an essential part of the
- interface, since it may not always be possible to
- access particular information from the DNS; see Section
- 6.1.3.3.
-
-
-
-Internet Engineering Task Force [Page 81]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- A host MAY provide other DNS interfaces tailored to
- particular functions, transforming the raw domain data into
- formats more suited to these functions. In particular, a
- host MUST provide a DNS interface to facilitate translation
- between host addresses and host names.
-
- 6.1.4.3 Interface Abbreviation Facilities
-
- User interfaces MAY provide a method for users to enter
- abbreviations for commonly-used names. Although the
- definition of such methods is outside of the scope of the
- DNS specification, certain rules are necessary to insure
- that these methods allow access to the entire DNS name space
- and to prevent excessive use of Internet resources.
-
- If an abbreviation method is provided, then:
-
- (a) There MUST be some convention for denoting that a name
- is already complete, so that the abbreviation method(s)
- are suppressed. A trailing dot is the usual method.
-
- (b) Abbreviation expansion MUST be done exactly once, and
- MUST be done in the context in which the name was
- entered.
-
-
- DISCUSSION:
- For example, if an abbreviation is used in a mail
- program for a destination, the abbreviation should be
- expanded into a full domain name and stored in the
- queued message with an indication that it is already
- complete. Otherwise, the abbreviation might be
- expanded with a mail system search list, not the
- user's, or a name could grow due to repeated
- canonicalizations attempts interacting with wildcards.
-
- The two most common abbreviation methods are:
-
- (1) Interface-level aliases
-
- Interface-level aliases are conceptually implemented as
- a list of alias/domain name pairs. The list can be
- per-user or per-host, and separate lists can be
- associated with different functions, e.g. one list for
- host name-to-address translation, and a different list
- for mail domains. When the user enters a name, the
- interface attempts to match the name to the alias
- component of a list entry, and if a matching entry can
-
-
-
-Internet Engineering Task Force [Page 82]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- be found, the name is replaced by the domain name found
- in the pair.
-
- Note that interface-level aliases and CNAMEs are
- completely separate mechanisms; interface-level aliases
- are a local matter while CNAMEs are an Internet-wide
- aliasing mechanism which is a required part of any DNS
- implementation.
-
- (2) Search Lists
-
- A search list is conceptually implemented as an ordered
- list of domain names. When the user enters a name, the
- domain names in the search list are used as suffixes to
- the user-supplied name, one by one, until a domain name
- with the desired associated data is found, or the
- search list is exhausted. Search lists often contain
- the name of the local host's parent domain or other
- ancestor domains. Search lists are often per-user or
- per-process.
-
- It SHOULD be possible for an administrator to disable a
- DNS search-list facility. Administrative denial may be
- warranted in some cases, to prevent abuse of the DNS.
-
- There is danger that a search-list mechanism will
- generate excessive queries to the root servers while
- testing whether user input is a complete domain name,
- lacking a final period to mark it as complete. A
- search-list mechanism MUST have one of, and SHOULD have
- both of, the following two provisions to prevent this:
-
- (a) The local resolver/name server can implement
- caching of negative responses (see Section
- 6.1.3.3).
-
- (b) The search list expander can require two or more
- interior dots in a generated domain name before it
- tries using the name in a query to non-local
- domain servers, such as the root.
-
- DISCUSSION:
- The intent of this requirement is to avoid
- excessive delay for the user as the search list is
- tested, and more importantly to prevent excessive
- traffic to the root and other high-level servers.
- For example, if the user supplied a name "X" and
- the search list contained the root as a component,
-
-
-
-Internet Engineering Task Force [Page 83]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- a query would have to consult a root server before
- the next search list alternative could be tried.
- The resulting load seen by the root servers and
- gateways near the root would be multiplied by the
- number of hosts in the Internet.
-
- The negative caching alternative limits the effect
- to the first time a name is used. The interior
- dot rule is simpler to implement but can prevent
- easy use of some top-level names.
-
-
- 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
------------------------------------------------|-----------|-|-|-|-|-|--
-GENERAL ISSUES | | | | | | |
- | | | | | | |
-Implement DNS name-to-address conversion |6.1.1 |x| | | | |
-Implement DNS address-to-name conversion |6.1.1 |x| | | | |
-Support conversions using host table |6.1.1 | | |x| | |
-Properly handle RR with zero TTL |6.1.2.1 |x| | | | |
-Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | |
- Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | |
-Unused fields zero |6.1.2.3 |x| | | | |
-Use compression in responses |6.1.2.4 |x| | | | |
- | | | | | | |
-Include config info in responses |6.1.2.5 | | | | |x|
-Support all well-known, class-indep. types |6.1.3.5 |x| | | | |
-Easily expand type list |6.1.3.5 | |x| | | |
-Load all RR types (except MD and MF) |6.1.3.6 |x| | | | |
-Load MD or MF type |6.1.3.6 | | | | |x|
-Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-RESOLVER ISSUES: | | | | | | |
- | | | | | | |
-Resolver support multiple concurrent requests |6.1.3.1 | |x| | | |
-Full-service resolver: |6.1.3.1 | | |x| | |
- Local caching |6.1.3.1 |x| | | | |
-
-
-
-Internet Engineering Task Force [Page 84]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- Information in local cache times out |6.1.3.1 |x| | | | |
- Configurable with starting info |6.1.3.1 | |x| | | |
-Stub resolver: |6.1.3.1 | | |x| | |
- Use redundant recursive name servers |6.1.3.1 |x| | | | |
- Local caching |6.1.3.1 | | |x| | |
- Information in local cache times out |6.1.3.1 |x| | | | |
-Support for remote multi-homed hosts: | | | | | | |
- Sort multiple addresses by preference list |6.1.3.4 | |x| | | |
- | | | | | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-TRANSPORT PROTOCOLS: | | | | | | |
- | | | | | | |
-Support UDP queries |6.1.3.2 |x| | | | |
-Support TCP queries |6.1.3.2 | |x| | | |
- Send query using UDP first |6.1.3.2 |x| | | | |1
- Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | |
-Name server limit TCP query resources |6.1.3.2 | | |x| | |
- Punish unnecessary TCP query |6.1.3.2 | | | |x| |
-Use truncated data as if it were not |6.1.3.2 | | | | |x|
-Private agreement to use only TCP |6.1.3.2 | | |x| | |
-Use TCP for zone transfers |6.1.3.2 |x| | | | |
-TCP usage not block UDP queries |6.1.3.2 |x| | | | |
-Support broadcast or multicast queries |6.1.3.2 | | |x| | |
- RD bit set in query |6.1.3.2 | | | | |x|
- RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | |
- Send only as occasional probe for addr's |6.1.3.2 | |x| | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-RESOURCE USAGE: | | | | | | |
- | | | | | | |
-Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | |
- Finite bounds per request |6.1.3.3 |x| | | | |
-Failure after retries => soft error |6.1.3.3 |x| | | | |
-Cache temporary failures |6.1.3.3 | |x| | | |
-Cache negative responses |6.1.3.3 | |x| | | |
-Retries use exponential backoff |6.1.3.3 | |x| | | |
- Upper, lower bounds |6.1.3.3 | |x| | | |
-Client handle Source Quench |6.1.3.3 | |x| | | |
-Server ignore Source Quench |6.1.3.3 | | |x| | |
------------------------------------------------|-----------|-|-|-|-|-|--
-USER INTERFACE: | | | | | | |
- | | | | | | |
-All programs have access to DNS interface |6.1.4.2 |x| | | | |
-Able to request all info for given name |6.1.4.2 |x| | | | |
-Returns complete info or error |6.1.4.2 |x| | | | |
-Special interfaces |6.1.4.2 | | |x| | |
- Name<->Address translation |6.1.4.2 |x| | | | |
- | | | | | | |
-Abbreviation Facilities: |6.1.4.3 | | |x| | |
-
-
-
-Internet Engineering Task Force [Page 85]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
-
-
- Convention for complete names |6.1.4.3 |x| | | | |
- Conversion exactly once |6.1.4.3 |x| | | | |
- Conversion in proper context |6.1.4.3 |x| | | | |
- Search list: |6.1.4.3 | | |x| | |
- Administrator can disable |6.1.4.3 | |x| | | |
- Prevention of excessive root queries |6.1.4.3 |x| | | | |
- Both methods |6.1.4.3 | |x| | | |
------------------------------------------------|-----------|-|-|-|-|-|--
------------------------------------------------|-----------|-|-|-|-|-|--
-
-1. Unless there is private agreement between particular resolver and
- particular server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 86]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
-
-
- 6.2 HOST INITIALIZATION
-
- 6.2.1 INTRODUCTION
-
- This section discusses the initialization of host software
- across a connected network, or more generally across an
- Internet path. This is necessary for a diskless host, and may
- optionally be used for a host with disk drives. For a diskless
- host, the initialization process is called "network booting"
- and is controlled by a bootstrap program located in a boot ROM.
-
- To initialize a diskless host across the network, there are two
- distinct phases:
-
- (1) Configure the IP layer.
-
- Diskless machines often have no permanent storage in which
- to store network configuration information, so that
- sufficient configuration information must be obtained
- dynamically to support the loading phase that follows.
- This information must include at least the IP addresses of
- the host and of the boot server. To support booting
- across a gateway, the address mask and a list of default
- gateways are also required.
-
- (2) Load the host system code.
-
- During the loading phase, an appropriate file transfer
- protocol is used to copy the system code across the
- network from the boot server.
-
- A host with a disk may perform the first step, dynamic
- configuration. This is important for microcomputers, whose
- floppy disks allow network configuration information to be
- mistakenly duplicated on more than one host. Also,
- installation of new hosts is much simpler if they automatically
- obtain their configuration information from a central server,
- saving administrator time and decreasing the probability of
- mistakes.
-
- 6.2.2 REQUIREMENTS
-
- 6.2.2.1 Dynamic Configuration
-
- A number of protocol provisions have been made for dynamic
- configuration.
-
- o ICMP Information Request/Reply messages
-
-
-
-Internet Engineering Task Force [Page 87]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
-
-
- This obsolete message pair was designed to allow a host
- to find the number of the network it is on.
- Unfortunately, it was useful only if the host already
- knew the host number part of its IP address,
- information that hosts requiring dynamic configuration
- seldom had.
-
- o Reverse Address Resolution Protocol (RARP) [BOOT:4]
-
- RARP is a link-layer protocol for a broadcast medium
- that allows a host to find its IP address given its
- link layer address. Unfortunately, RARP does not work
- across IP gateways and therefore requires a RARP server
- on every network. In addition, RARP does not provide
- any other configuration information.
-
- o ICMP Address Mask Request/Reply messages
-
- These ICMP messages allow a host to learn the address
- mask for a particular network interface.
-
- o BOOTP Protocol [BOOT:2]
-
- This protocol allows a host to determine the IP
- addresses of the local host and the boot server, the
- name of an appropriate boot file, and optionally the
- address mask and list of default gateways. To locate a
- BOOTP server, the host broadcasts a BOOTP request using
- UDP. Ad hoc gateway extensions have been used to
- transmit the BOOTP broadcast through gateways, and in
- the future the IP Multicasting facility will provide a
- standard mechanism for this purpose.
-
-
- The suggested approach to dynamic configuration is to use
- the BOOTP protocol with the extensions defined in "BOOTP
- Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084
- defines some important general (not vendor-specific)
- extensions. In particular, these extensions allow the
- address mask to be supplied in BOOTP; we RECOMMEND that the
- address mask be supplied in this manner.
-
- DISCUSSION:
- Historically, subnetting was defined long after IP, and
- so a separate mechanism (ICMP Address Mask messages)
- was designed to supply the address mask to a host.
- However, the IP address mask and the corresponding IP
- address conceptually form a pair, and for operational
-
-
-
-Internet Engineering Task Force [Page 88]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
-
-
- simplicity they ought to be defined at the same time
- and by the same mechanism, whether a configuration file
- or a dynamic mechanism like BOOTP.
-
- Note that BOOTP is not sufficiently general to specify
- the configurations of all interfaces of a multihomed
- host. A multihomed host must either use BOOTP
- separately for each interface, or configure one
- interface using BOOTP to perform the loading, and
- perform the complete initialization from a file later.
-
- Application layer configuration information is expected
- to be obtained from files after loading of the system
- code.
-
- 6.2.2.2 Loading Phase
-
- A suggested approach for the loading phase is to use TFTP
- [BOOT:1] between the IP addresses established by BOOTP.
-
- TFTP to a broadcast address SHOULD NOT be used, for reasons
- explained in Section 4.2.3.4.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 89]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
- 6.3 REMOTE MANAGEMENT
-
- 6.3.1 INTRODUCTION
-
- The Internet community has recently put considerable effort
- into the development of network management protocols. The
- result has been a two-pronged approach [MGT:1, MGT:6]: the
- Simple Network Management Protocol (SNMP) [MGT:4] and the
- Common Management Information Protocol over TCP (CMOT) [MGT:5].
-
- In order to be managed using SNMP or CMOT, a host will need to
- implement an appropriate management agent. An Internet host
- SHOULD include an agent for either SNMP or CMOT.
-
- Both SNMP and CMOT operate on a Management Information Base
- (MIB) that defines a collection of management values. By
- reading and setting these values, a remote application may
- query and change the state of the managed system.
-
- A standard MIB [MGT:3] has been defined for use by both
- management protocols, using data types defined by the Structure
- of Management Information (SMI) defined in [MGT:2]. Additional
- MIB variables can be introduced under the "enterprises" and
- "experimental" subtrees of the MIB naming space [MGT:2].
-
- Every protocol module in the host SHOULD implement the relevant
- MIB variables. A host SHOULD implement the MIB variables as
- defined in the most recent standard MIB, and MAY implement
- other MIB variables when appropriate and useful.
-
- 6.3.2 PROTOCOL WALK-THROUGH
-
- The MIB is intended to cover both hosts and gateways, although
- there may be detailed differences in MIB application to the two
- cases. This section contains the appropriate interpretation of
- the MIB for hosts. It is likely that later versions of the MIB
- will include more entries for host management.
-
- A managed host must implement the following groups of MIB
- object definitions: System, Interfaces, Address Translation,
- IP, ICMP, TCP, and UDP.
-
- The following specific interpretations apply to hosts:
-
- o ipInHdrErrors
-
- Note that the error "time-to-live exceeded" can occur in a
- host only when it is forwarding a source-routed datagram.
-
-
-
-Internet Engineering Task Force [Page 90]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
- o ipOutNoRoutes
-
- This object counts datagrams discarded because no route
- can be found. This may happen in a host if all the
- default gateways in the host's configuration are down.
-
- o ipFragOKs, ipFragFails, ipFragCreates
-
- A host that does not implement intentional fragmentation
- (see "Fragmentation" section of [INTRO:1]) MUST return the
- value zero for these three objects.
-
- o icmpOutRedirects
-
- For a host, this object MUST always be zero, since hosts
- do not send Redirects.
-
- o icmpOutAddrMaskReps
-
- For a host, this object MUST always be zero, unless the
- host is an authoritative source of address mask
- information.
-
- o ipAddrTable
-
- For a host, the "IP Address Table" object is effectively a
- table of logical interfaces.
-
- o ipRoutingTable
-
- For a host, the "IP Routing Table" object is effectively a
- combination of the host's Routing Cache and the static
- route table described in "Routing Outbound Datagrams"
- section of [INTRO:1].
-
- Within each ipRouteEntry, ipRouteMetric1...4 normally will
- have no meaning for a host and SHOULD always be -1, while
- ipRouteType will normally have the value "remote".
-
- If destinations on the connected network do not appear in
- the Route Cache (see "Routing Outbound Datagrams section
- of [INTRO:1]), there will be no entries with ipRouteType
- of "direct".
-
-
- DISCUSSION:
- The current MIB does not include Type-of-Service in an
- ipRouteEntry, but a future revision is expected to make
-
-
-
-Internet Engineering Task Force [Page 91]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
- this addition.
-
- We also expect the MIB to be expanded to allow the remote
- management of applications (e.g., the ability to partially
- reconfigure mail systems). Network service applications
- such as mail systems should therefore be written with the
- "hooks" for remote management.
-
- 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY
-
- | | | | |S| |
- | | | | |H| |F
- | | | | |O|M|o
- | | |S| |U|U|o
- | | |H| |L|S|t
- | |M|O| |D|T|n
- | |U|U|M| | |o
- | |S|L|A|N|N|t
- | |T|D|Y|O|O|t
-FEATURE |SECTION | | | |T|T|e
------------------------------------------------|-----------|-|-|-|-|-|--
-Support SNMP or CMOT agent |6.3.1 | |x| | | |
-Implement specified objects in standard MIB |6.3.1 | |x| | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 92]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
-7. REFERENCES
-
- This section lists the primary references with which every
- implementer must be thoroughly familiar. It also lists some
- secondary references that are suggested additional reading.
-
- INTRODUCTORY REFERENCES:
-
-
- [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
- IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
- October 1989.
-
- [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
- (three volumes), SRI International, December 1985.
-
- [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel,
- RFC-1011, May 1987.
-
- This document is republished periodically with new RFC numbers;
- the latest version must be used.
-
- [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J.
- Postel, RFC-980, March 1986.
-
- [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
- May 1987.
-
- This document is republished periodically with new RFC numbers;
- the latest version must be used.
-
-
- TELNET REFERENCES:
-
-
- [TELNET:1] "Telnet Protocol Specification," J. Postel and J.
- Reynolds, RFC-854, May 1983.
-
- [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds,
- RFC-855, May 1983.
-
- [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds,
- RFC-856, May 1983.
-
- [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
- May 1983.
-
- [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J.
-
-
-
-Internet Engineering Task Force [Page 93]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
- Reynolds, RFC-858, May 1983.
-
- [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC-
- 859, May 1983.
-
- [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds,
- RFC-860, May 1983.
-
- [TELNET:8] "Telnet Extended Options List," J. Postel and J.
- Reynolds, RFC-861, May 1983.
-
- [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855,
- December 1983.
-
- [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
- February 1989.
-
- This document supercedes RFC-930.
-
- [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
- October 1988.
-
- [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
- 1989.
-
- [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
- December 1988.
-
- [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
- 1080, November 1988.
-
-
- SECONDARY TELNET REFERENCES:
-
-
- [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
- Defense, May 1984.
-
- This document is intended to describe the same protocol as RFC-
- 854. In case of conflict, RFC-854 takes precedence, and the
- present document takes precedence over both.
-
- [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
-
- [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
- 1977.
-
- [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
-
-
-
-Internet Engineering Task Force [Page 94]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
- [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
- Implementation," A. Yasuda and T. Thompson, RFC-1043, February
- 1988.
-
-
- FTP REFERENCES:
-
-
- [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
- 959, October 1985.
-
- [FTP:2] "Document File Format Standards," J. Postel, RFC-678,
- December 1974.
-
- [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of
- Defense, May 1984.
-
- This document is based on an earlier version of the FTP
- specification (RFC-765) and is obsolete.
-
-
- TFTP REFERENCES:
-
-
- [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
- 1981.
-
-
- MAIL REFERENCES:
-
-
- [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
- 1982.
-
- [SMTP:2] "Standard For The Format of ARPA Internet Text Messages,"
- D. Crocker, RFC-822, August 1982.
-
- This document obsoleted an earlier specification, RFC-733.
-
- [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC-
- 974, January 1986.
-
- This RFC describes the use of MX records, a mandatory extension
- to the mail delivery process.
-
- [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
- February 1988.
-
-
-
-
-Internet Engineering Task Force [Page 95]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
- [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
- June 1986.
-
- [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
-
- The two preceding RFC's define a proposed standard for
- gatewaying mail between the Internet and the X.400 environments.
-
- [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S.
- Department of Defense, May 1984.
-
- This specification is intended to describe the same protocol as
- does RFC-821. However, MIL-STD-1781 is incomplete; in
- particular, it does not include MX records [SMTP:3].
-
- [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu,
- RFC-1049, March 1988.
-
-
- DOMAIN NAME SYSTEM REFERENCES:
-
-
- [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris,
- RFC-1034, November 1987.
-
- This document and the following one obsolete RFC-882, RFC-883,
- and RFC-973.
-
- [DNS:2] "Domain Names - Implementation and Specification," RFC-1035,
- P. Mockapetris, November 1987.
-
-
- [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974,
- January 1986.
-
-
- [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein,
- RFC-952, M. Stahl, E. Feinler, October 1985.
-
- SECONDARY DNS REFERENCES:
-
-
- [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
- RFC-953, October 1985.
-
- [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November
- 1987.
-
-
-
-
-Internet Engineering Task Force [Page 96]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
- [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC-
- 1033, November 1987.
-
- [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet
- Protocol Handbook, NIC 50007, SRI Network Information Center,
- August 1989.
-
-
- SYSTEM INITIALIZATION REFERENCES:
-
-
- [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
- 1984.
-
- [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
- 951, September 1985.
-
- [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
- 1084, December 1988.
-
- Note: this RFC revised and obsoleted RFC-1048.
-
- [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
- Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
-
-
- MANAGEMENT REFERENCES:
-
-
- [MGT:1] "IAB Recommendations for the Development of Internet Network
- Management Standards," V. Cerf, RFC-1052, April 1988.
-
- [MGT:2] "Structure and Identification of Management Information for
- TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
- August 1988.
-
- [MGT:3] "Management Information Base for Network Management of
- TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
- August 1988.
-
- [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor,
- M. Schoffstall, and C. Davin, RFC-1098, April 1989.
-
- [MGT:5] "The Common Management Information Services and Protocol
- over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
-
- [MGT:6] "Report of the Second Ad Hoc Network Management Review
- Group," V. Cerf, RFC-1109, August 1989.
-
-
-
-Internet Engineering Task Force [Page 97]
-
-
-
-
-RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
-
-
-Security Considerations
-
- There are many security issues in the application and support
- programs of host software, but a full discussion is beyond the scope
- of this RFC. Security-related issues are mentioned in sections
- concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
- EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
- SMTP DATA command (Section 5.2.8).
-
-Author's Address
-
- Robert Braden
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA 90292-6695
-
- Phone: (213) 822 1511
-
- EMail: Braden@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force [Page 98]
-
diff --git a/contrib/bind9/doc/rfc/rfc1183.txt b/contrib/bind9/doc/rfc/rfc1183.txt
deleted file mode 100644
index 6f080448bc72c..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1183.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group C. Everhart
-Request for Comments: 1183 Transarc
-Updates: RFCs 1034, 1035 L. Mamakos
- University of Maryland
- R. Ullmann
- Prime Computer
- P. Mockapetris, Editor
- ISI
- October 1990
-
-
- New DNS RR Definitions
-
-Status of this Memo
-
- This memo defines five new DNS types for experimental purposes. This
- RFC describes an Experimental Protocol for the Internet community,
- and requests discussion and suggestions for improvements.
- Distribution of this memo is unlimited.
-
-Table of Contents
-
- Introduction.................................................... 1
- 1. AFS Data Base location....................................... 2
- 2. Responsible Person........................................... 3
- 2.1. Identification of the guilty party......................... 3
- 2.2. The Responsible Person RR.................................. 4
- 3. X.25 and ISDN addresses, Route Binding....................... 6
- 3.1. The X25 RR................................................. 6
- 3.2. The ISDN RR................................................ 7
- 3.3. The Route Through RR....................................... 8
- REFERENCES and BIBLIOGRAPHY..................................... 9
- Security Considerations......................................... 10
- Authors' Addresses.............................................. 11
-
-Introduction
-
- This RFC defines the format of new Resource Records (RRs) for the
- Domain Name System (DNS), and reserves corresponding DNS type
- mnemonics and numerical codes. The definitions are in three
- independent sections: (1) location of AFS database servers, (2)
- location of responsible persons, and (3) representation of X.25 and
- ISDN addresses and route binding. All are experimental.
-
- This RFC assumes that the reader is familiar with the DNS [3,4]. The
- data shown is for pedagogical use and does not necessarily reflect
- the real Internet.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 1]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
-1. AFS Data Base location
-
- This section defines an extension of the DNS to locate servers both
- for AFS (AFS is a registered trademark of Transarc Corporation) and
- for the Open Software Foundation's (OSF) Distributed Computing
- Environment (DCE) authenticated naming system using HP/Apollo's NCA,
- both to be components of the OSF DCE. The discussion assumes that
- the reader is familiar with AFS [5] and NCA [6].
-
- The AFS (originally the Andrew File System) system uses the DNS to
- map from a domain name to the name of an AFS cell database server.
- The DCE Naming service uses the DNS for a similar function: mapping
- from the domain name of a cell to authenticated name servers for that
- cell. The method uses a new RR type with mnemonic AFSDB and type
- code of 18 (decimal).
-
- AFSDB has the following format:
-
- <owner> <ttl> <class> AFSDB <subtype> <hostname>
-
- Both RDATA fields are required in all AFSDB RRs. The <subtype> field
- is a 16 bit integer. The <hostname> field is a domain name of a host
- that has a server for the cell named by the owner name of the RR.
-
- The format of the AFSDB RR is class insensitive. AFSDB records cause
- type A additional section processing for <hostname>. This, in fact,
- is the rationale for using a new type code, rather than trying to
- build the same functionality with TXT RRs.
-
- Note that the format of AFSDB in a master file is identical to MX.
- For purposes of the DNS itself, the subtype is merely an integer.
- The present subtype semantics are discussed below, but changes are
- possible and will be announced in subsequent RFCs.
-
- In the case of subtype 1, the host has an AFS version 3.0 Volume
- Location Server for the named AFS cell. In the case of subtype 2,
- the host has an authenticated name server holding the cell-root
- directory node for the named DCE/NCA cell.
-
- The use of subtypes is motivated by two considerations. First, the
- space of DNS RR types is limited. Second, the services provided are
- sufficiently distinct that it would continue to be confusing for a
- client to attempt to connect to a cell's servers using the protocol
- for one service, if the cell offered only the other service.
-
- As an example of the use of this RR, suppose that the Toaster
- Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE. Their
- cell, named toaster.com, has three "AFS 3.0 cell database server"
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 2]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
- machines: bigbird.toaster.com, ernie.toaster.com, and
- henson.toaster.com. These three machines would be listed in three
- AFSDB RRs. These might appear in a master file as:
-
- toaster.com. AFSDB 1 bigbird.toaster.com.
- toaster.com. AFSDB 1 ernie.toaster.com.
- toaster.com. AFSDB 1 henson.toaster.com.
-
- As another example use of this RR, suppose that Femto College (domain
- name femto.edu) has deployed DCE, and that their DCE cell root
- directory is served by processes running on green.femto.edu and
- turquoise.femto.edu. Furthermore, their DCE file servers also run
- AFS 3.0-compatible volume location servers, on the hosts
- turquoise.femto.edu and orange.femto.edu. These machines would be
- listed in four AFSDB RRs, which might appear in a master file as:
-
- femto.edu. AFSDB 2 green.femto.edu.
- femto.edu. AFSDB 2 turquoise.femto.edu.
- femto.edu. AFSDB 1 turquoise.femto.edu.
- femto.edu. AFSDB 1 orange.femto.edu.
-
-2. Responsible Person
-
- The purpose of this section is to provide a standard method for
- associating responsible person identification to any name in the DNS.
-
- The domain name system functions as a distributed database which
- contains many different form of information. For a particular name
- or host, you can discover it's Internet address, mail forwarding
- information, hardware type and operating system among others.
-
- A key aspect of the DNS is that the tree-structured namespace can be
- divided into pieces, called zones, for purposes of distributing
- control and responsibility. The responsible person for zone database
- purposes is named in the SOA RR for that zone. This section
- describes an extension which allows different responsible persons to
- be specified for different names in a zone.
-
-2.1. Identification of the guilty party
-
- Often it is desirable to be able to identify the responsible entity
- for a particular host. When that host is down or malfunctioning, it
- is difficult to contact those parties which might resolve or repair
- the host. Mail sent to POSTMASTER may not reach the person in a
- timely fashion. If the host is one of a multitude of workstations,
- there may be no responsible person which can be contacted on that
- host.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 3]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
- The POSTMASTER mailbox on that host continues to be a good contact
- point for mail problems, and the zone contact in the SOA record for
- database problem, but the RP record allows us to associate a mailbox
- to entities that don't receive mail or are not directly connected
- (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
- point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
- ISI zone administrator have a clue about fixing gateways).
-
-2.2. The Responsible Person RR
-
- The method uses a new RR type with mnemonic RP and type code of 17
- (decimal).
-
- RP has the following format:
-
- <owner> <ttl> <class> RP <mbox-dname> <txt-dname>
-
- Both RDATA fields are required in all RP RRs.
-
- The first field, <mbox-dname>, is a domain name that specifies the
- mailbox for the responsible person. Its format in master files uses
- the DNS convention for mailbox encoding, identical to that used for
- the RNAME mailbox field in the SOA RR. The root domain name (just
- ".") may be specified for <mbox-dname> to indicate that no mailbox is
- available.
-
- The second field, <txt-dname>, is a domain name for which TXT RR's
- exist. A subsequent query can be performed to retrieve the
- associated TXT resource records at <txt-dname>. This provides a
- level of indirection so that the entity can be referred to from
- multiple places in the DNS. The root domain name (just ".") may be
- specified for <txt-dname> to indicate that the TXT_DNAME is absent,
- and no associated TXT RR exists.
-
- The format of the RP RR is class insensitive. RP records cause no
- additional section processing. (TXT additional section processing
- for <txt-dname> is allowed as an option, but only if it is disabled
- for the root, i.e., ".").
-
- The Responsible Person RR can be associated with any node in the
- Domain Name System hierarchy, not just at the leaves of the tree.
-
- The TXT RR associated with the TXT_DNAME contain free format text
- suitable for humans. Refer to [4] for more details on the TXT RR.
-
- Multiple RP records at a single name may be present in the database.
- They should have identical TTLs.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 4]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
- EXAMPLES
-
- Some examples of how the RP record might be used.
-
- sayshell.umd.edu. A 128.8.1.14
- MX 10 sayshell.umd.edu.
- HINFO NeXT UNIX
- WKS 128.8.1.14 tcp ftp telnet smtp
- RP louie.trantor.umd.edu. LAM1.people.umd.edu.
-
- LAM1.people.umd.edu. TXT (
- "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
-
- In this example, the responsible person's mailbox for the host
- SAYSHELL.UMD.EDU is louie@trantor.umd.edu. The TXT RR at
- LAM1.people.umd.edu provides additional information and advice.
-
- TERP.UMD.EDU. A 128.8.10.90
- MX 10 128.8.10.90
- HINFO MICROVAX-II UNIX
- WKS 128.8.10.90 udp domain
- WKS 128.8.10.90 tcp ftp telnet smtp domain
- RP louie.trantor.umd.edu. LAM1.people.umd.edu.
- RP root.terp.umd.edu. ops.CS.UMD.EDU.
-
- TRANTOR.UMD.EDU. A 128.8.10.14
- MX 10 trantor.umd.edu.
- HINFO MICROVAX-II UNIX
- WKS 128.8.10.14 udp domain
- WKS 128.8.10.14 tcp ftp telnet smtp domain
- RP louie.trantor.umd.edu. LAM1.people.umd.edu.
- RP petry.netwolf.umd.edu. petry.people.UMD.EDU.
- RP root.trantor.umd.edu. ops.CS.UMD.EDU.
- RP gregh.sunset.umd.edu. .
-
- LAM1.people.umd.edu. TXT "Louis A. Mamakos (301) 454-2946"
- petry.people.umd.edu. TXT "Michael G. Petry (301) 454-2946"
- ops.CS.UMD.EDU. TXT "CS Operations Staff (301) 454-2943"
-
- This set of resource records has two hosts, TRANTOR.UMD.EDU and
- TERP.UMD.EDU, as well as a number of TXT RRs. Note that TERP.UMD.EDU
- and TRANTOR.UMD.EDU both reference the same pair of TXT resource
- records, although the mail box names (root.terp.umd.edu and
- root.trantor.umd.edu) differ.
-
- Here, we obviously care much more if the machine flakes out, as we've
- specified four persons which might want to be notified of problems or
- other events involving TRANTOR.UMD.EDU. In this example, the last RP
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 5]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
- RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
- but no associated TXT RR.
-
-3. X.25 and ISDN addresses, Route Binding
-
- This section describes an experimental representation of X.25 and
- ISDN addresses in the DNS, as well as a route binding method,
- analogous to the MX for mail routing, for very large scale networks.
-
- There are several possible uses, all experimental at this time.
- First, the RRs provide simple documentation of the correct addresses
- to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
-
- The RRs could also be used automatically by an internet network-layer
- router, typically IP. The procedure would be to map IP address to
- domain name, then name to canonical name if needed, then following RT
- records, and finally attempting an IP/X.25 call to the address found.
- Alternately, configured domain names could be resolved to identify IP
- to X.25/ISDN bindings for a static but periodically refreshed routing
- table.
-
- This provides a function similar to ARP for wide area non-broadcast
- networks that will scale well to a network with hundreds of millions
- of hosts.
-
- Also, a standard address binding reference will facilitate other
- experiments in the use of X.25 and ISDN, especially in serious
- inter-operability testing. The majority of work in such a test is
- establishing the n-squared entries in static tables.
-
- Finally, the RRs are intended for use in a proposal [13] by one of
- the authors for a possible next-generation internet.
-
-3.1. The X25 RR
-
- The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
-
- X25 has the following format:
-
- <owner> <ttl> <class> X25 <PSDN-address>
-
- <PSDN-address> is required in all X25 RRs.
-
- <PSDN-address> identifies the PSDN (Public Switched Data Network)
- address in the X.121 [10] numbering plan associated with <owner>.
- Its format in master files is a <character-string> syntactically
- identical to that used in TXT and HINFO.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 6]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
- The format of X25 is class insensitive. X25 RRs cause no additional
- section processing.
-
- The <PSDN-address> is a string of decimal digits, beginning with the
- 4 digit DNIC (Data Network Identification Code), as specified in
- X.121. National prefixes (such as a 0) MUST NOT be used.
-
- For example:
-
- Relay.Prime.COM. X25 311061700956
-
-3.2. The ISDN RR
-
- The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
-
- An ISDN (Integrated Service Digital Network) number is simply a
- telephone number. The intent of the members of the CCITT is to
- upgrade all telephone and data network service to a common service.
-
- The numbering plan (E.163/E.164) is the same as the familiar
- international plan for POTS (an un-official acronym, meaning Plain
- Old Telephone Service). In E.166, CCITT says "An E.163/E.164
- telephony subscriber may become an ISDN subscriber without a number
- change."
-
- ISDN has the following format:
-
- <owner> <ttl> <class> ISDN <ISDN-address> <sa>
-
- The <ISDN-address> field is required; <sa> is optional.
-
- <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
- Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
- PSTN (Public Switched Telephone Network) numbering plan. E.163
- defines the country codes, and E.164 the form of the addresses. Its
- format in master files is a <character-string> syntactically
- identical to that used in TXT and HINFO.
-
- <sa> specifies the subaddress (SA). The format of <sa> in master
- files is a <character-string> syntactically identical to that used in
- TXT and HINFO.
-
- The format of ISDN is class insensitive. ISDN RRs cause no
- additional section processing.
-
- The <ISDN-address> is a string of characters, normally decimal
- digits, beginning with the E.163 country code and ending with the DDI
- if any. Note that ISDN, in Q.931, permits any IA5 character in the
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 7]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
- general case.
-
- The <sa> is a string of hexadecimal digits. For digits 0-9, the
- concrete encoding in the Q.931 call setup information element is
- identical to BCD.
-
- For example:
-
- Relay.Prime.COM. IN ISDN 150862028003217
- sh.Prime.COM. IN ISDN 150862028003217 004
-
- (Note: "1" is the country code for the North American Integrated
- Numbering Area, i.e., the system of "area codes" familiar to people
- in those countries.)
-
- The RR data is the ASCII representation of the digits. It is encoded
- as one or two <character-string>s, i.e., count followed by
- characters.
-
- CCITT recommendation E.166 [9] defines prefix escape codes for the
- representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
- (X.121) addresses in E.164. It specifies that the exact codes are a
- "national matter", i.e., different on different networks. A host
- connected to the ISDN may be able to use both the X25 and ISDN
- addresses, with the local prefix added.
-
-3.3. The Route Through RR
-
- The Route Through RR is defined with mnemonic RT and type code 21
- (decimal).
-
- The RT resource record provides a route-through binding for hosts
- that do not have their own direct wide area network addresses. It is
- used in much the same way as the MX RR.
-
- RT has the following format:
-
- <owner> <ttl> <class> RT <preference> <intermediate-host>
-
- Both RDATA fields are required in all RT RRs.
-
- The first field, <preference>, is a 16 bit integer, representing the
- preference of the route. Smaller numbers indicate more preferred
- routes.
-
- <intermediate-host> is the domain name of a host which will serve as
- an intermediate in reaching the host specified by <owner>. The DNS
- RRs associated with <intermediate-host> are expected to include at
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 8]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
- least one A, X25, or ISDN record.
-
- The format of the RT RR is class insensitive. RT records cause type
- X25, ISDN, and A additional section processing for <intermediate-
- host>.
-
- For example,
-
- sh.prime.com. IN RT 2 Relay.Prime.COM.
- IN RT 10 NET.Prime.COM.
- *.prime.com. IN RT 90 Relay.Prime.COM.
-
- When a host is looking up DNS records to attempt to route a datagram,
- it first looks for RT records for the destination host, which point
- to hosts with address records (A, X25, ISDN) compatible with the wide
- area networks available to the host. If it is itself in the set of
- RT records, it discards any RTs with preferences higher or equal to
- its own. If there are no (remaining) RTs, it can then use address
- records of the destination itself.
-
- Wild-card RTs are used exactly as are wild-card MXs. RT's do not
- "chain"; that is, it is not valid to use the RT RRs found for a host
- referred to by an RT.
-
- The concrete encoding is identical to the MX RR.
-
-REFERENCES and BIBLIOGRAPHY
-
- [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
- Information Center, SRI International, November 1987.
-
- [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
- Network Information Center, SRI International, November, 1987.
-
- [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
- 1034, USC/Information Sciences Institute, November 1987.
-
- [4] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, USC/Information Sciences Institute,
- November 1987.
-
- [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
- 7(3), pp. 61-69, March 1989.
-
- [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
- 1989.
-
- [7] International Telegraph and Telephone Consultative Committee,
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 9]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
- "Numbering Plan for the International Telephone Service", CCITT
- Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
- Fascicle II.2 ("Blue Book").
-
- [8] International Telegraph and Telephone Consultative Committee,
- "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
- IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
- Book").
-
- [9] International Telegraph and Telephone Consultative Committee.
- "Numbering Plan Interworking in the ISDN Era", CCITT
- Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
- Fascicle II.2 ("Blue Book").
-
- [10] International Telegraph and Telephone Consultative Committee,
- "International Numbering Plan for the Public Data Networks",
- CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
- 1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
- amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
- 1988.
-
- [11] Korb, J., "Standard for the Transmission of IP datagrams Over
- Public Data Networks", RFC 877, Purdue University, September
- 1983.
-
- [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
- 1989.
-
- [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
- (unpublished), July 1990.
-
- [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
- RFC 1101, USC/Information Sciences Institute, April 1989.
-
-Security Considerations
-
- Security issues are not addressed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 10]
-
-RFC 1183 New DNS RR Definitions October 1990
-
-
-Authors' Addresses
-
- Craig F. Everhart
- Transarc Corporation
- The Gulf Tower
- 707 Grant Street
- Pittsburgh, PA 15219
-
- Phone: +1 412 338 4467
-
- EMail: Craig_Everhart@transarc.com
-
-
- Louis A. Mamakos
- Network Infrastructure Group
- Computer Science Center
- University of Maryland
- College Park, MD 20742-2411
-
- Phone: +1-301-405-7836
-
- Email: louie@Sayshell.UMD.EDU
-
-
- Robert Ullmann 10-30
- Prime Computer, Inc.
- 500 Old Connecticut Path
- Framingham, MA 01701
-
- Phone: +1 508 620 2800 ext 1736
-
- Email: Ariel@Relay.Prime.COM
-
-
- Paul Mockapetris
- USC Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA 90292
-
- Phone: 213-822-1511
-
- EMail: pvm@isi.edu
-
-
-
-
-
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris [Page 11]
- \ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1348.txt b/contrib/bind9/doc/rfc/rfc1348.txt
deleted file mode 100644
index d9e5dea040eee..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1348.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group B. Manning
-Request for Comments: 1348 Rice University
-Updates: RFCs 1034, 1035 July 1992
-
-
- DNS NSAP RRs
-
-Status of this Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. Discussion and suggestions for improvement are requested.
- Please refer to the current edition of the "IAB Official Protocol
- Standards" for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
-Table of Contents
-
- Introduction ..................................................... 1
- Background ....................................................... 1
- NSAP RR .......................................................... 2
- NSAP-PTR RR ...................................................... 2
- REFERENCES and BIBLIOGRAPHY ...................................... 3
- Security Considerations .......................................... 4
- Author's Address ................................................. 4
-
-Introduction
-
- This RFC defines the format of two new Resource Records (RRs) for the
- Domain Name System (DNS), and reserves corresponding DNS type
- mnemonic and numerical codes. This format may be used with the any
- proposal that has variable length addresses, but is targeted for CLNP
- use.
-
- This memo assumes that the reader is familiar with the DNS [3,4].
-
-Background
-
- This section describes an experimental representation of NSAP
- addresses in the DNS. There are several reasons to take this approch.
- First, it provides simple documentation of the correct addresses to
- use in static configurations of CLNP compliant hosts and routers.
-
- NSAP support requires that a new DNS resource record entry type
- ("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses.
- This resource record allows mapping from DNS names to NSAP addresses,
- and will contain entries for systems which are able to run Internet
- applications, over TCP or UDP, over CLNP.
-
-
-
-
-Manning [Page 1]
-
-RFC 1348 DNS NSAP RRs July 1992
-
-
- The backward translation (from NSAP address to DNS name) is
- facilitated by definition of an associated resource record. This
- resource record is known as "NSAP-PTR", and is used in a manner
- analogous to the existing "in-addr.arpa".
-
- These RRs are intended for use in a proposal [6] by one of the
- members of the NOOP WG to address the next-generation internet.
-
-The NSAP RR
-
- The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal).
-
- An NSAP (Network Service Access Protocol) number is a unique string
- to OSI transport service.
-
- The numbering plan follows RFC 1237 and associated OSI definitions
- for NSAP format.
-
- NSAP has the following format:
-
- <owner> <ttl> <class> NSAP <length> <NSAP-address>
-
- All fields are required.
-
- <length> identifies the number of octets in the <NSAP-address> as
- defined by the various national and international authorities.
-
- <NSAP-address> enumerates the actual octet values assigned by the
- assigning authority. Its format in master files is a <character-
- string> syntactically identical to that used in TXT and HINFO.
-
- The format of NSAP is class insensitive. NSAP RR causes no
- additional section processing.
-
- For example:
-
-foo.bar.com. IN NSAP 21 47000580ffff000000321099991111222233334444
-host.school.de IN NSAP 17 39276f3100111100002222333344449876
-
- The RR data is the ASCII representation of the digits. It is encoded
- as two <character-strings>, i.e., count followed by characters.
-
-The NSAP-PTR RR
-
- The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23
- (decimal).
-
- Its function is analogous to the PTR record used for IP addresses
-
-
-
-Manning [Page 2]
-
-RFC 1348 DNS NSAP RRs July 1992
-
-
- [4,7].
-
- NSAP-PTR has the following format:
-
- <NSAP-suffix> <ttl> <class> NSAP-PTR <owner>
-
- All fields are required.
-
- <NSAP-suffix> enumerates the actual octet values assigned by the
- assigning authority for the LOCAL network. Its format in master
- files is a <character-string> syntactically identical to that used in
- TXT and HINFO.
-
- The format of NSAP-PTR is class insensitive. NSAP-PTR RR causes no
- additional section processing.
-
- For example:
-
- In net ff08000574.nsap-in-addr.arpa:
-
- 444433332222111199990123000000ff NSAP-PTR foo.bar.com.
-
- Or in net 11110031f67293.nsap-in-addr.arpa:
-
- 67894444333322220000 NSAP-PTR host.school.de.
-
- The RR data is the ASCII representation of the digits. It is encoded
- as a <character-string>.
-
-REFERENCES and BIBLIOGRAPHY
-
- [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
- Information Center, SRI International, November 1987.
-
- [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
- Network Information Center, SRI International, November, 1987.
-
- [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
- 1034, USC/Information Sciences Institute, November 1987.
-
- [4] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, USC/Information Sciences Institute,
- November 1987.
-
- [5] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
- NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
- July 1991.
-
-
-
-
-Manning [Page 3]
-
-RFC 1348 DNS NSAP RRs July 1992
-
-
- [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
- A Simple Proposal for Internet Addressing and Routing",
- Digital Equipment Corporation, RFC 1347, June 1992.
-
- [7] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
- RFC 1101, USC/Information Sciences Institute, April 1989.
-
- [8] ISO/IEC. Information Processing Systems -- Data Communications
- -- Network Service Definition Addendum 2: Network Layer Address-
- ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
- Switzerland, 1988.
-
- [9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING
- RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992.
-
-Security Considerations
-
- Security issues are not addressed in this memo.
-
-Author's Address
-
- Bill Manning
- Rice University - ONCS
- PO Box 1892
- 6100 South Main
- Houston, Texas 77251-1892
-
- Phone: +1.713.285.5415
- EMail: bmanning@rice.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning [Page 4]
- \ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1535.txt b/contrib/bind9/doc/rfc/rfc1535.txt
deleted file mode 100644
index 03bddeebedcb9..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1535.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group E. Gavron
-Request for Comments: 1535 ACES Research Inc.
-Category: Informational October 1993
-
-
- A Security Problem and Proposed Correction
- With Widely Deployed DNS Software
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard. Distribution of this memo is
- unlimited.
-
-Abstract
-
- This document discusses a flaw in some of the currently distributed
- name resolver clients. The flaw exposes a security weakness related
- to the search heuristic invoked by these same resolvers when users
- provide a partial domain name, and which is easy to exploit (although
- not by the masses). This document points out the flaw, a case in
- point, and a solution.
-
-Background
-
- Current Domain Name Server clients are designed to ease the burden of
- remembering IP dotted quad addresses. As such they translate human-
- readable names into addresses and other resource records. Part of
- the translation process includes understanding and dealing with
- hostnames that are not fully qualified domain names (FQDNs).
-
- An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
- domain name is of the format {name}
-
- A domain name may have many parts and typically these include the
- host, domain, and type. Example: foobar.company.com or
- fooschool.university.edu.
-
-Flaw
-
- The problem with most widely distributed resolvers based on the BSD
- BIND resolver is that they attempt to resolve a partial name by
- processing a search list of partial domains to be added to portions
- of the specified host name until a DNS record is found. This
- "feature" is disabled by default in the official BIND 4.9.2 release.
-
- Example: A TELNET attempt by User@Machine.Tech.ACES.COM
- to UnivHost.University.EDU
-
-
-
-Gavron [Page 1]
-
-RFC 1535 DNS Software Enhancements October 1993
-
-
- The resolver client will realize that since "UnivHost.University.EDU"
- does not end with a ".", it is not an absolute "rooted" FQDN. It
- will then try the following combinations until a resource record is
- found:
-
- UnivHost.University.EDU.Tech.ACES.COM.
- UnivHost.University.EDU.ACES.COM.
- UnivHost.University.EDU.COM.
- UnivHost.University.EDU.
-
-Security Issue
-
- After registering the EDU.COM domain, it was discovered that an
- unliberal application of one wildcard CNAME record would cause *all*
- connects from any .COM site to any .EDU site to terminate at one
- target machine in the private edu.com sub-domain.
-
- Further, discussion reveals that specific hostnames registered in
- this private subdomain, or any similarly named subdomain may be used
- to spoof a host.
-
- Example: harvard.edu.com. CNAME targethost
-
- Thus all connects to Harvard.edu from all .com sites would end up at
- targthost, a machine which could provide a Harvard.edu login banner.
-
- This is clearly unacceptable. Further, it could only be made worse
- with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
-
-Public vs. Local Name Space Administration
-
- The specification of the Domain Name System and the software that
- implements it provides an undifferentiated hierarchy which permits
- delegation of administration for subordinate portions of the name
- space. Actual administration of the name space is divided between
- "public" and "local" portions. Public administration pertains to all
- top-level domains, such as .COM and .EDU. For some domains, it also
- pertains to some number of sub-domain levels. The multi-level nature
- of the public administration is most evident for top-level domains
- for countries. For example in the Fully Qualified Domain Name,
- dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
- of public administration. Only the left-most portion is subject to
- local administration.
-
-
-
-
-
-
-
-
-Gavron [Page 2]
-
-RFC 1535 DNS Software Enhancements October 1993
-
-
- The danger of the heuristic search common in current practise is that
- it it is possible to "intercept" the search by matching against an
- unintended value while walking up the search list. While this is
- potentially dangerous at any level, it is entirely unacceptable when
- the error impacts users outside of a local administration.
-
- When attempting to resolve a partial domain name, DNS resolvers use
- the Domain Name of the searching host for deriving the search list.
- Existing DNS resolvers do not distinguish the portion of that name
- which is in the locally administered scope from the part that is
- publically administered.
-
-Solution(s)
-
- At a minimum, DNS resolvers must honor the BOUNDARY between local and
- public administration, by limiting any search lists to locally-
- administered portions of the Domain Name space. This requires a
- parameter which shows the scope of the name space controlled by the
- local administrator.
-
- This would permit progressive searches from the most qualified to
- less qualified up through the locally controlled domain, but not
- beyond.
-
- For example, if the local user were trying to reach:
-
- User@chief.admin.DESERTU.EDU from
- starburst,astro.DESERTU.EDU,
-
- it is reasonable to permit the user to enter just chief.admin, and
- for the search to cover:
-
- chief.admin.astro.DESERTU.EDU
- chief.admin.DESERTU.EDU
-
- but not
-
- chief.admin.EDU
-
- In this case, the value of "search" should be set to "DESERTU.EDU"
- because that's the scope of the name space controlled by the local
- DNS administrator.
-
- This is more than a mere optimization hack. The local administrator
- has control over the assignment of names within the locally
- administered domain, so the administrator can make sure that
- abbreviations result in the right thing. Outside of the local
- control, users are necessarily at risk.
-
-
-
-Gavron [Page 3]
-
-RFC 1535 DNS Software Enhancements October 1993
-
-
- A more stringent mechanism is implemented in BIND 4.9.2, to respond
- to this problem:
-
- The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
- to only try the first and the last of the examples shown.
-
- Any additional search alternatives must be configured into the
- resolver EXPLICITLY.
-
- DNS Name resolver software SHOULD NOT use implicit search lists in
- attempts to resolve partial names into absolute FQDNs other than the
- hosts's immediate parent domain.
-
- Resolvers which continue to use implicit search lists MUST limit
- their scope to locally administered sub-domains.
-
- DNS Name resolver software SHOULD NOT come pre-configured with
- explicit search lists that perpetuate this problem.
-
- Further, in any event where a "." exists in a specified name it
- should be assumed to be a fully qualified domain name (FQDN) and
- SHOULD be tried as a rooted name first.
-
- Example: Given user@a.b.c.d connecting to e.f.g.h only two tries
- should be attempted as a result of using an implicit
- search list:
-
- e.f.g.h. and e.f.g.h.b.c.d.
-
- Given user@a.b.c.d. connecting to host those same two
- tries would appear as:
-
- x.b.c.d. and x.
-
- Some organizations make regular use of multi-part, partially
- qualified Domain Names. For example, host foo.loc1.org.city.state.us
- might be used to making references to bar.loc2, or mumble.loc3, all
- of which refer to whatever.locN.org.city.state.us
-
- The stringent implicit search rules for BIND 4.9.2 will now cause
- these searches to fail. To return the ability for them to succeed,
- configuration of the client resolvers must be changed to include an
- explicit search rule for org.city.state.us. That is, it must contain
- an explicit rule for any -- and each -- portion of the locally-
- administered sub-domain that it wishes to have as part of the search
- list.
-
-
-
-
-
-Gavron [Page 4]
-
-RFC 1535 DNS Software Enhancements October 1993
-
-
-References
-
- [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
- RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [2] Mockapetris, P., "Domain Names Implementation and Specification",
- STD 13, RFC 1035, USC/Information Sciences Institute, November
- 1987.
-
- [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
- 974, CSNET CIC BBN, January 1986.
-
- [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
- "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
- USC/Information Sciences Institute, USC, October 1993.
-
- [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
- 1537, CWI, October 1993.
-
-Security Considerations
-
- This memo indicates vulnerabilities with all too-forgiving DNS
- clients. It points out a correction that would eliminate the future
- potential of the problem.
-
-Author's Address
-
- Ehud Gavron
- ACES Research Inc.
- PO Box 14546
- Tucson, AZ 85711
-
- Phone: (602) 743-9841
- EMail: gavron@aces.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gavron [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc1536.txt b/contrib/bind9/doc/rfc/rfc1536.txt
deleted file mode 100644
index 5ff2b25d03706..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1536.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Kumar
-Request for Comments: 1536 J. Postel
-Category: Informational C. Neuman
- ISI
- P. Danzig
- S. Miller
- USC
- October 1993
-
-
- Common DNS Implementation Errors and Suggested Fixes
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard. Distribution of this memo is
- unlimited.
-
-Abstract
-
- This memo describes common errors seen in DNS implementations and
- suggests some fixes. Where applicable, violations of recommendations
- from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
- also describes, where relevant, the algorithms followed in BIND
- (versions 4.8.3 and 4.9 which the authors referred to) to serve as an
- example.
-
-Introduction
-
- The last few years have seen, virtually, an explosion of DNS traffic
- on the NSFnet backbone. Various DNS implementations and various
- versions of these implementations interact with each other, producing
- huge amounts of unnecessary traffic. Attempts are being made by
- researchers all over the internet, to document the nature of these
- interactions, the symptomatic traffic patterns and to devise remedies
- for the sick pieces of software.
-
- This draft is an attempt to document fixes for known DNS problems so
- people know what problems to watch out for and how to repair broken
- software.
-
-1. Fast Retransmissions
-
- DNS implements the classic request-response scheme of client-server
- interaction. UDP is, therefore, the chosen protocol for communication
- though TCP is used for zone transfers. The onus of requerying in case
- no response is seen in a "reasonable" period of time, lies with the
- client. Although RFC 1034 and 1035 do not recommend any
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 1]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
- retransmission policy, RFC 1035 does recommend that the resolvers
- should cycle through a list of servers. Both name servers and stub
- resolvers should, therefore, implement some kind of a retransmission
- policy based on round trip time estimates of the name servers. The
- client should back-off exponentially, probably to a maximum timeout
- value.
-
- However, clients might not implement either of the two. They might
- not wait a sufficient amount of time before retransmitting or they
- might not back-off their inter-query times sufficiently.
-
- Thus, what the server would see will be a series of queries from the
- same querying entity, spaced very close together. Of course, a
- correctly implemented server discards all duplicate queries but the
- queries contribute to wide-area traffic, nevertheless.
-
- We classify a retransmission of a query as a pure Fast retry timeout
- problem when a series of query packets meet the following conditions.
-
- a. Query packets are seen within a time less than a "reasonable
- waiting period" of each other.
-
- b. No response to the original query was seen i.e., we see two or
- more queries, back to back.
-
- c. The query packets share the same query identifier.
-
- d. The server eventually responds to the query.
-
-A GOOD IMPLEMENTATION:
-
- BIND (we looked at versions 4.8.3 and 4.9) implements a good
- retransmission algorithm which solves or limits all of these
- problems. The Berkeley stub-resolver queries servers at an interval
- that starts at the greater of 4 seconds and 5 seconds divided by the
- number of servers the resolver queries. The resolver cycles through
- servers and at the end of a cycle, backs off the time out
- exponentially.
-
- The Berkeley full-service resolver (built in with the program
- "named") starts with a time-out equal to the greater of 4 seconds and
- two times the round-trip time estimate of the server. The time-out
- is backed off with each cycle, exponentially, to a ceiling value of
- 45 seconds.
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 2]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
-FIXES:
-
- a. Estimate round-trip times or set a reasonably high initial
- time-out.
-
- b. Back-off timeout periods exponentially.
-
- c. Yet another fundamental though difficult fix is to send the
- client an acknowledgement of a query, with a round-trip time
- estimate.
-
- Since UDP is used, no response is expected by the client until the
- query is complete. Thus, it is less likely to have information about
- previous packets on which to estimate its back-off time. Unless, you
- maintain state across queries, so subsequent queries to the same
- server use information from previous queries. Unfortunately, such
- estimates are likely to be inaccurate for chained requests since the
- variance is likely to be high.
-
- The fix chosen in the ARDP library used by Prospero is that the
- server will send an initial acknowledgement to the client in those
- cases where the server expects the query to take a long time (as
- might be the case for chained queries). This initial acknowledgement
- can include an expected time to wait before retrying.
-
- This fix is more difficult since it requires that the client software
- also be trained to expect the acknowledgement packet. This, in an
- internet of millions of hosts is at best a hard problem.
-
-2. Recursion Bugs
-
- When a server receives a client request, it first looks up its zone
- data and the cache to check if the query can be answered. If the
- answer is unavailable in either place, the server seeks names of
- servers that are more likely to have the information, in its cache or
- zone data. It then does one of two things. If the client desires the
- server to recurse and the server architecture allows recursion, the
- server chains this request to these known servers closest to the
- queried name. If the client doesn't seek recursion or if the server
- cannot handle recursion, it returns the list of name servers to the
- client assuming the client knows what to do with these records.
-
- The client queries this new list of name servers to get either the
- answer, or names of another set of name servers to query. This
- process repeats until the client is satisfied. Servers might also go
- through this chaining process if the server returns a CNAME record
- for the queried name. Some servers reprocess this name to try and get
- the desired record type.
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 3]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
- However, in certain cases, this chain of events may not be good. For
- example, a broken or malicious name server might list itself as one
- of the name servers to query again. The unsuspecting client resends
- the same query to the same server.
-
- In another situation, more difficult to detect, a set of servers
- might form a loop wherein A refers to B and B refers to A. This loop
- might involve more than two servers.
-
- Yet another error is where the client does not know how to process
- the list of name servers returned, and requeries the same server
- since that is one (of the few) servers it knows.
-
- We, therefore, classify recursion bugs into three distinct
- categories:
-
- a. Ignored referral: Client did not know how to handle NS records
- in the AUTHORITY section.
-
- b. Too many referrals: Client called on a server too many times,
- beyond a "reasonable" number, with same query. This is
- different from a Fast retransmission problem and a Server
- Failure detection problem in that a response is seen for every
- query. Also, the identifiers are always different. It implies
- client is in a loop and should have detected that and broken
- it. (RFC 1035 mentions that client should not recurse beyond
- a certain depth.)
-
- c. Malicious Server: a server refers to itself in the authority
- section. If a server does not have an answer now, it is very
- unlikely it will be any better the next time you query it,
- specially when it claims to be authoritative over a domain.
-
- RFC 1034 warns against such situations, on page 35.
-
- "Bound the amount of work (packets sent, parallel processes
- started) so that a request can't get into an infinite loop or
- start off a chain reaction of requests or queries with other
- implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
- SOME DATA."
-
-A GOOD IMPLEMENTATION:
-
- BIND fixes at least one of these problems. It places an upper limit
- on the number of recursive queries it will make, to answer a
- question. It chases a maximum of 20 referral links and 8 canonical
- name translations.
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 4]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
-FIXES:
-
- a. Set an upper limit on the number of referral links and CNAME
- links you are willing to chase.
-
- Note that this is not guaranteed to break only recursion loops.
- It could, in a rare case, prune off a very long search path,
- prematurely. We know, however, with high probability, that if
- the number of links cross a certain metric (two times the depth
- of the DNS tree), it is a recursion problem.
-
- b. Watch out for self-referring servers. Avoid them whenever
- possible.
-
- c. Make sure you never pass off an authority NS record with your
- own name on it!
-
- d. Fix clients to accept iterative answers from servers not built
- to provide recursion. Such clients should either be happy with
- the non-authoritative answer or be willing to chase the
- referral links themselves.
-
-3. Zero Answer Bugs:
-
- Name servers sometimes return an authoritative NOERROR with no
- ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
- queried name is valid but it does not have a record of the desired
- type. Of course, the server has authority over the domain.
-
- However, once again, some implementations of resolvers do not
- interpret this kind of a response reasonably. They always expect an
- answer record when they see an authoritative NOERROR. These entities
- continue to resend their queries, possibly endlessly.
-
-A GOOD IMPLEMENTATION
-
- BIND resolver code does not query a server more than 3 times. If it
- is unable to get an answer from 4 servers, querying them three times
- each, it returns error.
-
- Of course, it treats a zero-answer response the way it should be
- treated; with respect!
-
-FIXES:
-
- a. Set an upper limit on the number of retransmissions for a given
- query, at the very least.
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 5]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
- b. Fix resolvers to interpret such a response as an authoritative
- statement of non-existence of the record type for the given
- name.
-
-4. Inability to detect server failure:
-
- Servers in the internet are not very reliable (they go down every
- once in a while) and resolvers are expected to adapt to the changed
- scenario by not querying the server for a while. Thus, when a server
- does not respond to a query, resolvers should try another server.
- Also, non-stub resolvers should update their round trip time estimate
- for the server to a large value so that server is not tried again
- before other, faster servers.
-
- Stub resolvers, however, cycle through a fixed set of servers and if,
- unfortunately, a server is down while others do not respond for other
- reasons (high load, recursive resolution of query is taking more time
- than the resolver's time-out, ....), the resolver queries the dead
- server again! In fact, some resolvers might not set an upper limit on
- the number of query retransmissions they will send and continue to
- query dead servers indefinitely.
-
- Name servers running system or chained queries might also suffer from
- the same problem. They store names of servers they should query for a
- given domain. They cycle through these names and in case none of them
- answers, hit each one more than one. It is, once again, important
- that there be an upper limit on the number of retransmissions, to
- prevent network overload.
-
- This behavior is clearly in violation of the dictum in RFC 1035 (page
- 46)
-
- "If a resolver gets a server error or other bizarre response
- from a name server, it should remove it from SLIST, and may
- wish to schedule an immediate transmission to the next
- candidate server address."
-
- Removal from SLIST implies that the server is not queried again for
- some time.
-
- Correctly implemented full-service resolvers should, as pointed out
- before, update round trip time values for servers that do not respond
- and query them only after other, good servers. Full-service resolvers
- might, however, not follow any of these common sense directives. They
- query dead servers, and they query them endlessly.
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 6]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
-A GOOD IMPLEMENTATION:
-
- BIND places an upper limit on the number of times it queries a
- server. Both the stub-resolver and the full-service resolver code do
- this. Also, since the full-service resolver estimates round-trip
- times and sorts name server addresses by these estimates, it does not
- query a dead server again, until and unless all the other servers in
- the list are dead too! Further, BIND implements exponential back-off
- too.
-
-FIXES:
-
- a. Set an upper limit on number of retransmissions.
-
- b. Measure round-trip time from servers (some estimate is better
- than none). Treat no response as a "very large" round-trip
- time.
-
- c. Maintain a weighted rtt estimate and decay the "large" value
- slowly, with time, so that the server is eventually tested
- again, but not after an indefinitely long period.
-
- d. Follow an exponential back-off scheme so that even if you do
- not restrict the number of queries, you do not overload the
- net excessively.
-
-5. Cache Leaks:
-
- Every resource record returned by a server is cached for TTL seconds,
- where the TTL value is returned with the RR. Full-service (or stub)
- resolvers cache the RR and answer any queries based on this cached
- information, in the future, until the TTL expires. After that, one
- more query to the wide-area network gets the RR in cache again.
-
- Full-service resolvers might not implement this caching mechanism
- well. They might impose a limit on the cache size or might not
- interpret the TTL value correctly. In either case, queries repeated
- within a TTL period of a RR constitute a cache leak.
-
-A GOOD/BAD IMPLEMENTATION:
-
- BIND has no restriction on the cache size and the size is governed by
- the limits on the virtual address space of the machine it is running
- on. BIND caches RRs for the duration of the TTL returned with each
- record.
-
- It does, however, not follow the RFCs with respect to interpretation
- of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 7]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
- the minimum TTL value, for that zone, from the SOA record and caches
- it for that duration. This, though it saves some traffic on the
- wide-area network, is not correct behavior.
-
-FIXES:
-
- a. Look over your caching mechanism to ensure TTLs are interpreted
- correctly.
-
- b. Do not restrict cache sizes (come on, memory is cheap!).
- Expired entries are reclaimed periodically, anyway. Of course,
- the cache size is bound to have some physical limit. But, when
- possible, this limit should be large (run your name server on
- a machine with a large amount of physical memory).
-
- c. Possibly, a mechanism is needed to flush the cache, when it is
- known or even suspected that the information has changed.
-
-6. Name Error Bugs:
-
- This bug is very similar to the Zero Answer bug. A server returns an
- authoritative NXDOMAIN when the queried name is known to be bad, by
- the server authoritative for the domain, in the absence of negative
- caching. This authoritative NXDOMAIN response is usually accompanied
- by the SOA record for the domain, in the authority section.
-
- Resolvers should recognize that the name they queried for was a bad
- name and should stop querying further.
-
- Some resolvers might, however, not interpret this correctly and
- continue to query servers, expecting an answer record.
-
- Some applications, in fact, prompt NXDOMAIN answers! When given a
- perfectly good name to resolve, they append the local domain to it
- e.g., an application in the domain "foo.bar.com", when trying to
- resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
- "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
- least two queries that return NXDOMAIN, for every good query. The
- problem is aggravated since the negative answers from the previous
- queries are not cached. When the same name is sought again, the
- process repeats.
-
- Some DNS resolver implementations suffer from this problem, too. They
- append successive sub-parts of the local domain using an implicit
- searchlist mechanism, when certain conditions are satisfied and try
- the original name, only when this first set of iterations fails. This
- behavior recently caused pandemonium in the Internet when the domain
- "edu.com" was registered and a wildcard "CNAME" record placed at the
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 8]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
- top level. All machines from "com" domains trying to connect to hosts
- in the "edu" domain ended up with connections to the local machine in
- the "edu.com" domain!
-
-GOOD/BAD IMPLEMENTATIONS:
-
- Some local versions of BIND already implement negative caching. They
- typically cache negative answers with a very small TTL, sufficient to
- answer a burst of queries spaced close together, as is typically
- seen.
-
- The next official public release of BIND (4.9.2) will have negative
- caching as an ifdef'd feature.
-
- The BIND resolver appends local domain to the given name, when one of
- two conditions is met:
-
- i. The name has no periods and the flag RES_DEFNAME is set.
- ii. There is no trailing period and the flag RES_DNSRCH is set.
-
- The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
- BIND, but can be changed at compile time.
-
- Only if the name, so generated, returns an NXDOMAIN is the original
- name tried as a Fully Qualified Domain Name. And only if it contains
- at least one period.
-
-FIXES:
-
- a. Fix the resolver code.
-
- b. Negative Caching. Negative caching servers will restrict the
- traffic seen on the wide-area network, even if not curb it
- altogether.
-
- c. Applications and resolvers should not append the local domain to
- names they seek to resolve, as far as possible. Names
- interspersed with periods should be treated as Fully Qualified
- Domain Names.
-
- In other words, Use searchlists only when explicitly specified.
- No implicit searchlists should be used. A name that contains
- any dots should first be tried as a FQDN and if that fails, with
- the local domain name (or searchlist if specified) appended. A
- name containing no dots can be appended with the searchlist right
- away, but once again, no implicit searchlists should be used.
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 9]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
- Associated with the name error bug is another problem where a server
- might return an authoritative NXDOMAIN, although the name is valid. A
- secondary server, on start-up, reads the zone information from the
- primary, through a zone transfer. While it is in the process of
- loading the zones, it does not have information about them, although
- it is authoritative for them. Thus, any query for a name in that
- domain is answered with an NXDOMAIN response code. This problem might
- not be disastrous were it not for negative caching servers that cache
- this answer and so propagate incorrect information over the internet.
-
-BAD IMPLEMENTATION:
-
- BIND apparently suffers from this problem.
-
- Also, a new name added to the primary database will take a while to
- propagate to the secondaries. Until that time, they will return
- NXDOMAIN answers for a good name. Negative caching servers store this
- answer, too and aggravate this problem further. This is probably a
- more general DNS problem but is apparently more harmful in this
- situation.
-
-FIX:
-
- a. Servers should start answering only after loading all the zone
- data. A failed server is better than a server handing out
- incorrect information.
-
- b. Negative cache records for a very small time, sufficient only
- to ward off a burst of requests for the same bad name. This
- could be related to the round-trip time of the server from
- which the negative answer was received. Alternatively, a
- statistical measure of the amount of time for which queries
- for such names are received could be used. Minimum TTL value
- from the SOA record is not advisable since they tend to be
- pretty large.
-
- c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
- and implemented, to allow the primary server to inform
- secondaries that the database has been modified since it last
- transferred zone data. To alleviate the problem of "too many
- zone transfers" that this might cause, Incremental Zone
- Transfers should also be part of DNS. Also, the primary should
- not NOTIFY/PUSH with every update but bunch a good number
- together.
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 10]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
-7. Format Errors:
-
- Some resolvers issue query packets that do not necessarily conform to
- standards as laid out in the relevant RFCs. This unnecessarily
- increases net traffic and wastes server time.
-
-FIXES:
-
- a. Fix resolvers.
-
- b. Each resolver verify format of packets before sending them out,
- using a mechanism outside of the resolver. This is, obviously,
- needed only if step 1 cannot be followed.
-
-References
-
- [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
- RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [2] Mockapetris, P., "Domain Names Implementation and Specification",
- STD 13, RFC 1035, USC/Information Sciences Institute, November
- 1987.
-
- [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
- 974, CSNET CIC BBN, January 1986.
-
- [4] Gavron, E., "A Security Problem and Proposed Correction With
- Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
- October 1993.
-
- [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
- 1537, CWI, October 1993.
-
-Security Considerations
-
- Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 11]
-
-RFC 1536 Common DNS Implementation Errors October 1993
-
-
-Authors' Addresses
-
- Anant Kumar
- USC Information Sciences Institute
- 4676 Admiralty Way
- Marina Del Rey CA 90292-6695
-
- Phone:(310) 822-1511
- FAX: (310) 823-6741
- EMail: anant@isi.edu
-
-
- Jon Postel
- USC Information Sciences Institute
- 4676 Admiralty Way
- Marina Del Rey CA 90292-6695
-
- Phone:(310) 822-1511
- FAX: (310) 823-6714
- EMail: postel@isi.edu
-
-
- Cliff Neuman
- USC Information Sciences Institute
- 4676 Admiralty Way
- Marina Del Rey CA 90292-6695
-
- Phone:(310) 822-1511
- FAX: (310) 823-6714
- EMail: bcn@isi.edu
-
-
- Peter Danzig
- Computer Science Department
- University of Southern California
- University Park
-
- EMail: danzig@caldera.usc.edu
-
-
- Steve Miller
- Computer Science Department
- University of Southern California
- University Park
- Los Angeles CA 90089
-
- EMail: smiller@caldera.usc.edu
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc1537.txt b/contrib/bind9/doc/rfc/rfc1537.txt
deleted file mode 100644
index 81b97683156b7..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1537.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Beertema
-Request for Comments: 1537 CWI
-Category: Informational October 1993
-
-
- Common DNS Data File Configuration Errors
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard. Distribution of this memo is
- unlimited.
-
-Abstract
-
- This memo describes errors often found in DNS data files. It points
- out common mistakes system administrators tend to make and why they
- often go unnoticed for long periods of time.
-
-Introduction
-
- Due to the lack of extensive documentation and automated tools, DNS
- zone files have mostly been configured by system administrators, by
- hand. Some of the rules for writing the data files are rather subtle
- and a few common mistakes are seen in domains worldwide.
-
- This document is an attempt to list "surprises" that administrators
- might find hidden in their zone files. It describes the symptoms of
- the malady and prescribes medicine to cure that. It also gives some
- general recommendations and advice on specific nameserver and zone
- file issues and on the (proper) use of the Domain Name System.
-
-1. SOA records
-
- A problem I've found in quite some nameservers is that the various
- timers have been set (far) too low. Especially for top level domain
- nameservers this causes unnecessary traffic over international and
- intercontinental links.
-
- Unfortunately the examples given in the BIND manual, in RFC's and in
- some expert documents give those very short timer values, and that's
- most likely what people have modeled their SOA records after.
-
- First of all a short explanation of the timers used in the SOA
- record:
-
-
-
-
-
-
-Beertema [Page 1]
-
-RFC 1537 Common DNS Data File Configuration Errors October 1993
-
-
- - Refresh: The SOA record of the primary server is checked
- every "refresh" time by the secondary servers;
- if it has changed, a zone transfer is done.
-
- - Retry: If a secondary server cannot reach the primary
- server, it tries it again every "retry" time.
-
- - Expire: If for "expire" time the primary server cannot
- be reached, all information about the zone is
- invalidated on the secondary servers (i.e., they
- are no longer authoritative for that zone).
-
- - Minimum TTL: The default TTL value for all records in the
- zone file; a different TTL value may be given
- explicitly in a record when necessary.
- (This timer is named "Minimum", and that's
- what it's function should be according to
- STD 13, RFC 1035, but most (all?)
- implementations take it as the default value
- exported with records without an explicit TTL
- value).
-
- For top level domain servers I would recommend the following values:
-
- 86400 ; Refresh 24 hours
- 7200 ; Retry 2 hours
- 2592000 ; Expire 30 days
- 345600 ; Minimum TTL 4 days
-
- For other servers I would suggest:
-
- 28800 ; Refresh 8 hours
- 7200 ; Retry 2 hours
- 604800 ; Expire 7 days
- 86400 ; Minimum TTL 1 day
-
- but here the frequency of changes, the required speed of propagation,
- the reachability of the primary server etc. play a role in optimizing
- the timer values.
-
-2. Glue records
-
- Quite often, people put unnecessary glue (A) records in their zone
- files. Even worse is that I've even seen *wrong* glue records for an
- external host in a primary zone file! Glue records need only be in a
- zone file if the server host is within the zone and there is no A
- record for that host elsewhere in the zone file.
-
-
-
-
-Beertema [Page 2]
-
-RFC 1537 Common DNS Data File Configuration Errors October 1993
-
-
- Old BIND versions ("native" 4.8.3 and older versions) showed the
- problem that wrong glue records could enter secondary servers in a
- zone transfer.
-
-3. "Secondary server surprise"
-
- I've seen it happen on various occasions that hosts got bombarded by
- nameserver requests without knowing why. On investigation it turned
- out then that such a host was supposed to (i.e., the information was
- in the root servers) run secondary for some domain (or reverse (in-
- addr.arpa)) domain, without that host's nameserver manager having
- been asked or even been told so!
-
- Newer BIND versions (4.9 and later) solved this problem. At the same
- time though the fix has the disadvantage that it's far less easy to
- spot this problem.
-
- Practice has shown that most domain registrars accept registrations
- of nameservers without checking if primary (!) and secondary servers
- have been set up, informed, or even asked. It should also be noted
- that a combination of long-lasting unreachability of primary
- nameservers, (therefore) expiration of zone information, plus static
- IP routing, can lead to massive network traffic that can fill up
- lines completely.
-
-4. "MX records surprise"
-
- In a sense similar to point 3. Sometimes nameserver managers enter MX
- records in their zone files that point to external hosts, without
- first asking or even informing the systems managers of those external
- hosts. This has to be fought out between the nameserver manager and
- the systems managers involved. Only as a last resort, if really
- nothing helps to get the offending records removed, can the systems
- manager turn to the naming authority of the domain above the
- offending domain to get the problem sorted out.
-
-5. "Name extension surprise"
-
- Sometimes one encounters weird names, which appear to be an external
- name extended with a local domain. This is caused by forgetting to
- terminate a name with a dot: names in zone files that don't end with
- a dot are always expanded with the name of the current zone (the
- domain that the zone file stands for or the last $ORIGIN).
-
- Example: zone file for foo.xx:
-
- pqr MX 100 relay.yy.
- xyz MX 100 relay.yy (no trailing dot!)
-
-
-
-Beertema [Page 3]
-
-RFC 1537 Common DNS Data File Configuration Errors October 1993
-
-
- When fully written out this stands for:
-
- pqr.foo.xx. MX 100 relay.yy.
- xyz.foo.xx. MX 100 relay.yy.foo.xx. (name extension!)
-
-6. Missing secondary servers
-
- It is required that there be a least 2 nameservers for a domain. For
- obvious reasons the nameservers for top level domains need to be very
- well reachable from all over the Internet. This implies that there
- must be more than just 2 of them; besides, most of the (secondary)
- servers should be placed at "strategic" locations, e.g., close to a
- point where international and/or intercontinental lines come
- together. To keep things manageable, there shouldn't be too many
- servers for a domain either.
-
- Important aspects in selecting the location of primary and secondary
- servers are reliability (network, host) and expedient contacts: in
- case of problems, changes/fixes must be carried out quickly. It
- should be considered logical that primary servers for European top
- level domains should run on a host in Europe, preferably (if
- possible) in the country itself. For each top level domain there
- should be 2 secondary servers in Europe and 2 in the USA, but there
- may of course be more on either side. An excessive number of
- nameservers is not a good idea though; a recommended maximum is 7
- nameservers. In Europe, EUnet has offered to run secondary server
- for each European top level domain.
-
-7. Wildcard MX records
-
- Wildcard MX records should be avoided where possible. They often
- cause confusion and errors: especially beginning nameserver managers
- tend to overlook the fact that a host/domain listed with ANY type of
- record in a zone file is NOT covered by an overall wildcard MX record
- in that zone; this goes not only for simple domain/host names, but
- also for names that cover one or more domains. Take the following
- example in zone foo.bar:
-
- * MX 100 mailhost
- pqr MX 100 mailhost
- abc.def MX 100 mailhost
-
- This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
- domains, but the wildcard MX record covers NONE of them, nor anything
- below them. To cover everything by MX records, the required entries
- are:
-
-
-
-
-
-Beertema [Page 4]
-
-RFC 1537 Common DNS Data File Configuration Errors October 1993
-
-
- * MX 100 mailhost
- pqr MX 100 mailhost
- *.pqr MX 100 mailhost
- abc.def MX 100 mailhost
- *.def MX 100 mailhost
- *.abc.def MX 100 mailhost
-
- An overall wildcard MX record is almost never useful.
-
- In particular the zone file of a top level domain should NEVER
- contain only an overall wildcard MX record (*.XX). The effect of such
- a wildcard MX record can be that mail is unnecessarily sent across
- possibly expensive links, only to fail at the destination or gateway
- that the record points to. Top level domain zone files should
- explicitly list at least all the officially registered primary
- subdomains.
-
- Whereas overall wildcard MX records should be avoided, wildcard MX
- records are acceptable as an explicit part of subdomain entries,
- provided they are allowed under a given subdomain (to be determined
- by the naming authority for that domain).
-
- Example:
-
- foo.xx. MX 100 gateway.xx.
- MX 200 fallback.yy.
- *.foo.xx. MX 100 gateway.xx.
- MX 200 fallback.yy.
-8. Hostnames
-
- People appear to sometimes look only at STD 11, RFC 822 to determine
- whether a particular hostname is correct or not. Hostnames should
- strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
- with *addresses* in addition conforming to RFC 822. As an example
- take "c&w.blues" which is perfectly legal according to RFC 822, but
- which can have quite surprising effects on particular systems, e.g.,
- "telnet c&w.blues" on a Unix system.
-
-9. HINFO records
-
- There appears to be a common misunderstanding that one of the data
- fields (usually the second field) in HINFO records is optional. A
- recent scan of all reachable nameservers in only one country revealed
- some 300 incomplete HINFO records. Specifying two data fields in a
- HINFO record is mandatory (RFC 1033), but note that this does *not*
- mean that HINFO records themselves are mandatory.
-
-
-
-
-
-Beertema [Page 5]
-
-RFC 1537 Common DNS Data File Configuration Errors October 1993
-
-
-10. Safety measures and specialties
-
- Nameservers and resolvers aren't flawless. Bogus queries should be
- kept from being forwarded to the root servers, since they'll only
- lead to unnecessary intercontinental traffic. Known bogus queries
- that can easily be dealt with locally are queries for 0 and broadcast
- addresses. To catch such queries, every nameserver should run
- primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
- files need only contain a SOA and an NS record.
-
- Also each nameserver should run primary for 0.0.127.in-addr.arpa;
- that zone file should contain a SOA and NS record and an entry:
-
- 1 PTR localhost.
-
- There has been extensive discussion about whether or not to append
- the local domain to it. The conclusion was that "localhost." would be
- the best solution; reasons given were:
-
- - "localhost" itself is used and expected to work on some systems.
-
- - translating 127.0.0.1 into "localhost.my_domain" can cause some
- software to connect to itself using the loopback interface when
- it didn't want to.
-
- Note that all domains that contain hosts should have a "localhost" A
- record in them.
-
- People maintaining zone files with the Serial number given in dotted
- decimal notation (e.g., when SCCS is used to maintain the files)
- should beware of a bug in all BIND versions: if the serial number is
- in Release.Version (dotted decimal) notation, then it is virtually
- impossible to change to a higher release: because of the wrong way
- that notation is turned into an integer, it results in a serial
- number that is LOWER than that of the former release.
-
- For this reason and because the Serial is an (unsigned) integer
- according to STD 13, RFC 1035, it is recommended not to use the
- dotted decimal notation. A recommended notation is to use the date
- (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
- or can be more than one change per day in a zone file.
-
- Very old versions of DNS resolver code have a bug that causes queries
- for A records with domain names like "192.16.184.3" to go out. This
- happens when users type in IP addresses and the resolver code does
- not catch this case before sending out a DNS query. This problem has
- been fixed in all resolver implementations known to us but if it
- still pops up it is very serious because all those queries will go to
-
-
-
-Beertema [Page 6]
-
-RFC 1537 Common DNS Data File Configuration Errors October 1993
-
-
- the root servers looking for top level domains like "3" etc. It is
- strongly recommended to install the latest (publicly) available BIND
- version plus all available patches to get rid of these and other
- problems.
-
- Running secondary nameserver off another secondary nameserver is
- possible, but not recommended unless really necessary: there are
- known cases where it has led to problems like bogus TTL values. This
- can be caused by older or flawed implementations, but secondary
- nameservers in principle should always transfer their zones from the
- official primary nameserver.
-
-11. Some general points
-
- The Domain Name System and nameserver are purely technical tools, not
- meant in any way to exert control or impose politics. The function of
- a naming authority is that of a clearing house. Anyone registering a
- subdomain under a particular (top level) domain becomes naming
- authority and therewith the sole responsible for that subdomain.
- Requests to enter MX or NS records concerning such a subdomain
- therefore always MUST be honored by the registrar of the next higher
- domain.
-
- Examples of practices that are not allowed are:
-
- - imposing specific mail routing (MX records) when registering
- a subdomain.
-
- - making registration of a subdomain dependent on to the use of
- certain networks or services.
-
- - using TXT records as a means of (free) commercial advertising.
-
- In the latter case a network service provider could decide to cut off
- a particular site until the offending TXT records have been removed
- from the site's zone file.
-
- Of course there are obvious cases where a naming authority can refuse
- to register a particular subdomain and can require a proposed name to
- be changed in order to get it registered (think of DEC trying to
- register a domain IBM.XX).
-
- There are also cases were one has to probe the authority of the
- person: sending in the application - not every systems manager should
- be able to register a domain name for a whole university. The naming
- authority can impose certain extra rules as long as they don't
- violate or conflict with the rights and interest of the registrars of
- subdomains; a top level domain registrar may e.g., require that there
-
-
-
-Beertema [Page 7]
-
-RFC 1537 Common DNS Data File Configuration Errors October 1993
-
-
- be primary subdomain "ac" and "co" only and that subdomains be
- registered under those primary subdomains.
-
- The naming authority can also interfere in exceptional cases like the
- one mentioned in point 4, e.g., by temporarily removing a domain's
- entry from the nameserver zone files; this of course should be done
- only with extreme care and only as a last resort.
-
- When adding NS records for subdomains, top level domain nameserver
- managers should realize that the people setting up the nameserver for
- a subdomain often are rather inexperienced and can make mistakes that
- can easily lead to the subdomain becoming completely unreachable or
- that can cause unnecessary DNS traffic (see point 1). It is therefore
- highly recommended that, prior to entering such an NS record, the
- (top level) nameserver manager does a couple of sanity checks on the
- new nameserver (SOA record and timers OK?, MX records present where
- needed? No obvious errors made? Listed secondary servers
- operational?). Things that cannot be caught though by such checks
- are:
-
- - resolvers set up to use external hosts as nameservers
-
- - nameservers set up to use external hosts as forwarders
- without permission from those hosts.
-
- Care should also be taken when registering 2-letter subdomains.
- Although this is allowed, an implication is that abbreviated
- addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
- and under that subdomain. When requested to register such a domain,
- one should always notify the people of this consequence. As an
- example take the name "cs", which is commonly used for Computer
- Science departments: it is also the name of the top level domain for
- Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
- ambiguous in that in can denote both a user on the host
- host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
- (This example does not take into account the recent political changes
- in the mentioned country).
-
-References
-
- [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
- RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [2] Mockapetris, P., "Domain Names Implementation and Specification",
- STD 13, RFC 1035, USC/Information Sciences Institute, November
- 1987.
-
-
-
-
-
-Beertema [Page 8]
-
-RFC 1537 Common DNS Data File Configuration Errors October 1993
-
-
- [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
- 974, CSNET CIC BBN, January 1986.
-
- [4] Gavron, E., "A Security Problem and Proposed Correction With
- Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
- October 1993.
-
- [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
- "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
- USC/Information Sciences Institute, USC, October 1993.
-
-Security Considerations
-
- Security issues are not discussed in this memo.
-
-Author's Address
-
- Piet Beertema
- CWI
- Kruislaan 413
- NL-1098 SJ Amsterdam
- The Netherlands
-
- Phone: +31 20 592 4112
- FAX: +31 20 592 4199
- EMail: Piet.Beertema@cwi.nl
-
-
-Editor's Address
-
- Anant Kumar
- USC Information Sciences Institute
- 4676 Admiralty Way
- Marina Del Rey CA 90292-6695
-
- Phone:(310) 822-1511
- FAX: (310) 823-6741
- EMail: anant@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-Beertema [Page 9]
- \ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1591.txt b/contrib/bind9/doc/rfc/rfc1591.txt
deleted file mode 100644
index 89e0a254a235e..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1591.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Postel
-Request for Comments: 1591 ISI
-Category: Informational March 1994
-
-
- Domain Name System Structure and Delegation
-
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-1. Introduction
-
- This memo provides some information on the structure of the names in
- the Domain Name System (DNS), specifically the top-level domain
- names; and on the administration of domains. The Internet Assigned
- Numbers Authority (IANA) is the overall authority for the IP
- Addresses, the Domain Names, and many other parameters, used in the
- Internet. The day-to-day responsibility for the assignment of IP
- Addresses, Autonomous System Numbers, and most top and second level
- Domain Names are handled by the Internet Registry (IR) and regional
- registries.
-
-2. The Top Level Structure of the Domain Names
-
- In the Domain Name System (DNS) naming of computers there is a
- hierarchy of names. The root of system is unnamed. There are a set
- of what are called "top-level domain names" (TLDs). These are the
- generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
- letter country codes from ISO-3166. It is extremely unlikely that
- any other TLDs will be created.
-
- Under each TLD may be created a hierarchy of names. Generally, under
- the generic TLDs the structure is very flat. That is, many
- organizations are registered directly under the TLD, and any further
- structure is up to the individual organizations.
-
- In the country TLDs, there is a wide variation in the structure, in
- some countries the structure is very flat, in others there is
- substantial structural organization. In some country domains the
- second levels are generic categories (such as, AC, CO, GO, and RE),
- in others they are based on political geography, and in still others,
- organization names are listed directly under the country code. The
- organization for the US country domain is described in RFC 1480 [1].
-
-
-
-
-Postel [Page 1]
-
-RFC 1591 Domain Name System Structure and Delegation March 1994
-
-
- Each of the generic TLDs was created for a general category of
- organizations. The country code domains (for example, FR, NL, KR,
- US) are each organized by an administrator for that country. These
- administrators may further delegate the management of portions of the
- naming tree. These administrators are performing a public service on
- behalf of the Internet community. Descriptions of the generic
- domains and the US country domain follow.
-
- Of these generic domains, five are international in nature, and two
- are restricted to use by entities in the United States.
-
- World Wide Generic Domains:
-
- COM - This domain is intended for commercial entities, that is
- companies. This domain has grown very large and there is
- concern about the administrative load and system performance if
- the current growth pattern is continued. Consideration is
- being taken to subdivide the COM domain and only allow future
- commercial registrations in the subdomains.
-
- EDU - This domain was originally intended for all educational
- institutions. Many Universities, colleges, schools,
- educational service organizations, and educational consortia
- have registered here. More recently a decision has been taken
- to limit further registrations to 4 year colleges and
- universities. Schools and 2-year colleges will be registered
- in the country domains (see US Domain, especially K12 and CC,
- below).
-
- NET - This domain is intended to hold only the computers of network
- providers, that is the NIC and NOC computers, the
- administrative computers, and the network node computers. The
- customers of the network provider would have domain names of
- their own (not in the NET TLD).
-
- ORG - This domain is intended as the miscellaneous TLD for
- organizations that didn't fit anywhere else. Some non-
- government organizations may fit here.
-
- INT - This domain is for organizations established by international
- treaties, or international databases.
-
- United States Only Generic Domains:
-
- GOV - This domain was originally intended for any kind of government
- office or agency. More recently a decision was taken to
- register only agencies of the US Federal government in this
- domain. State and local agencies are registered in the country
-
-
-
-Postel [Page 2]
-
-RFC 1591 Domain Name System Structure and Delegation March 1994
-
-
- domains (see US Domain, below).
-
- MIL - This domain is used by the US military.
-
- Example country code Domain:
-
- US - As an example of a country domain, the US domain provides for
- the registration of all kinds of entities in the United States
- on the basis of political geography, that is, a hierarchy of
- <entity-name>.<locality>.<state-code>.US. For example,
- "IBM.Armonk.NY.US". In addition, branches of the US domain are
- provided within each state for schools (K12), community colleges
- (CC), technical schools (TEC), state government agencies
- (STATE), councils of governments (COG),libraries (LIB), museums
- (MUS), and several other generic types of entities (see RFC 1480
- for details [1]).
-
- To find a contact for a TLD use the "whois" program to access the
- database on the host rs.internic.net. Append "-dom" to the name of
- TLD you are interested in. For example:
-
- whois -h rs.internic.net us-dom
- or
- whois -h rs.internic.net edu-dom
-
-3. The Administration of Delegated Domains
-
- The Internet Assigned Numbers Authority (IANA) is responsible for the
- overall coordination and management of the Domain Name System (DNS),
- and especially the delegation of portions of the name space called
- top-level domains. Most of these top-level domains are two-letter
- country codes taken from the ISO standard 3166.
-
- A central Internet Registry (IR) has been selected and designated to
- handled the bulk of the day-to-day administration of the Domain Name
- System. Applications for new top-level domains (for example, country
- code domains) are handled by the IR with consultation with the IANA.
- The central IR is INTERNIC.NET. Second level domains in COM, EDU,
- ORG, NET, and GOV are registered by the Internet Registry at the
- InterNIC. The second level domains in the MIL are registered by the
- DDN registry at NIC.DDN.MIL. Second level names in INT are
- registered by the PVM at ISI.EDU.
-
- While all requests for new top-level domains must be sent to the
- Internic (at hostmaster@internic.net), the regional registries are
- often enlisted to assist in the administration of the DNS, especially
- in solving problems with a country administration. Currently, the
- RIPE NCC is the regional registry for Europe and the APNIC is the
-
-
-
-Postel [Page 3]
-
-RFC 1591 Domain Name System Structure and Delegation March 1994
-
-
- regional registry for the Asia-Pacific region, while the INTERNIC
- administers the North America region, and all the as yet undelegated
- regions.
-
- The contact mailboxes for these regional registries are:
-
- INTERNIC hostmaster@internic.net
- APNIC hostmaster@apnic.net
- RIPE NCC ncc@ripe.net
-
- The policy concerns involved when a new top-level domain is
- established are described in the following. Also mentioned are
- concerns raised when it is necessary to change the delegation of an
- established domain from one party to another.
-
- A new top-level domain is usually created and its management
- delegated to a "designated manager" all at once.
-
- Most of these same concerns are relevant when a sub-domain is
- delegated and in general the principles described here apply
- recursively to all delegations of the Internet DNS name space.
-
- The major concern in selecting a designated manager for a domain is
- that it be able to carry out the necessary responsibilities, and have
- the ability to do a equitable, just, honest, and competent job.
-
- 1) The key requirement is that for each domain there be a designated
- manager for supervising that domain's name space. In the case of
- top-level domains that are country codes this means that there is
- a manager that supervises the domain names and operates the domain
- name system in that country.
-
- The manager must, of course, be on the Internet. There must be
- Internet Protocol (IP) connectivity to the nameservers and email
- connectivity to the management and staff of the manager.
-
- There must be an administrative contact and a technical contact
- for each domain. For top-level domains that are country codes at
- least the administrative contact must reside in the country
- involved.
-
- 2) These designated authorities are trustees for the delegated
- domain, and have a duty to serve the community.
-
- The designated manager is the trustee of the top-level domain for
- both the nation, in the case of a country code, and the global
- Internet community.
-
-
-
-
-Postel [Page 4]
-
-RFC 1591 Domain Name System Structure and Delegation March 1994
-
-
- Concerns about "rights" and "ownership" of domains are
- inappropriate. It is appropriate to be concerned about
- "responsibilities" and "service" to the community.
-
- 3) The designated manager must be equitable to all groups in the
- domain that request domain names.
-
- This means that the same rules are applied to all requests, all
- requests must be processed in a non-discriminatory fashion, and
- academic and commercial (and other) users are treated on an equal
- basis. No bias shall be shown regarding requests that may come
- from customers of some other business related to the manager --
- e.g., no preferential service for customers of a particular data
- network provider. There can be no requirement that a particular
- mail system (or other application), protocol, or product be used.
-
- There are no requirements on subdomains of top-level domains
- beyond the requirements on higher-level domains themselves. That
- is, the requirements in this memo are applied recursively. In
- particular, all subdomains shall be allowed to operate their own
- domain name servers, providing in them whatever information the
- subdomain manager sees fit (as long as it is true and correct).
-
- 4) Significantly interested parties in the domain should agree that
- the designated manager is the appropriate party.
-
- The IANA tries to have any contending parties reach agreement
- among themselves, and generally takes no action to change things
- unless all the contending parties agree; only in cases where the
- designated manager has substantially mis-behaved would the IANA
- step in.
-
- However, it is also appropriate for interested parties to have
- some voice in selecting the designated manager.
-
- There are two cases where the IANA and the central IR may
- establish a new top-level domain and delegate only a portion of
- it: (1) there are contending parties that cannot agree, or (2) the
- applying party may not be able to represent or serve the whole
- country. The later case sometimes arises when a party outside a
- country is trying to be helpful in getting networking started in a
- country -- this is sometimes called a "proxy" DNS service.
-
- The Internet DNS Names Review Board (IDNB), a committee
- established by the IANA, will act as a review panel for cases in
- which the parties can not reach agreement among themselves. The
- IDNB's decisions will be binding.
-
-
-
-
-Postel [Page 5]
-
-RFC 1591 Domain Name System Structure and Delegation March 1994
-
-
- 5) The designated manager must do a satisfactory job of operating the
- DNS service for the domain.
-
- That is, the actual management of the assigning of domain names,
- delegating subdomains and operating nameservers must be done with
- technical competence. This includes keeping the central IR (in
- the case of top-level domains) or other higher-level domain
- manager advised of the status of the domain, responding to
- requests in a timely manner, and operating the database with
- accuracy, robustness, and resilience.
-
- There must be a primary and a secondary nameserver that have IP
- connectivity to the Internet and can be easily checked for
- operational status and database accuracy by the IR and the IANA.
-
- In cases when there are persistent problems with the proper
- operation of a domain, the delegation may be revoked, and possibly
- delegated to another designated manager.
-
- 6) For any transfer of the designated manager trusteeship from one
- organization to another, the higher-level domain manager (the IANA
- in the case of top-level domains) must receive communications from
- both the old organization and the new organization that assure the
- IANA that the transfer in mutually agreed, and that the new
- organization understands its responsibilities.
-
- It is also very helpful for the IANA to receive communications
- from other parties that may be concerned or affected by the
- transfer.
-
-4. Rights to Names
-
- 1) Names and Trademarks
-
- In case of a dispute between domain name registrants as to the
- rights to a particular name, the registration authority shall have
- no role or responsibility other than to provide the contact
- information to both parties.
-
- The registration of a domain name does not have any Trademark
- status. It is up to the requestor to be sure he is not violating
- anyone else's Trademark.
-
- 2) Country Codes
-
- The IANA is not in the business of deciding what is and what is
- not a country.
-
-
-
-
-Postel [Page 6]
-
-RFC 1591 Domain Name System Structure and Delegation March 1994
-
-
- The selection of the ISO 3166 list as a basis for country code
- top-level domain names was made with the knowledge that ISO has a
- procedure for determining which entities should be and should not
- be on that list.
-
-5. Security Considerations
-
- Security issues are not discussed in this memo.
-
-6. Acknowledgements
-
- Many people have made comments on draft version of these descriptions
- and procedures. Steve Goldstein and John Klensin have been
- particularly helpful.
-
-7. Author's Address
-
- Jon Postel
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA 90292
-
- Phone: 310-822-1511
- Fax: 310-823-6714
- EMail: Postel@ISI.EDU
-
-7. References
-
- [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
- USC/Information Sciences Institute, June 1993.
-
- [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
- USC/Information Sciences Institute, July 1992.
-
- [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [4] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
- 974, CSNET CIC BBN, January 1986.
-
- [7] Braden, R., Editor, "Requirements for Internet Hosts --
- Application and Support", STD 3, RFC 1123, Internet Engineering
- Task Force, October 1989.
-
-
-
-
-Postel [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc1611.txt b/contrib/bind9/doc/rfc/rfc1611.txt
deleted file mode 100644
index ed5b93a83d8bf..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1611.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Austein
-Request for Comments: 1611 Epilogue Technology Corporation
-Category: Standards Track J. Saperia
- Digital Equipment Corporation
- May 1994
-
- DNS Server MIB 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.
-
-Table of Contents
-
- 1. Introduction .............................................. 1
- 2. The SNMPv2 Network Management Framework ................... 2
- 2.1 Object Definitions ....................................... 2
- 3. Overview .................................................. 2
- 3.1 Resolvers ................................................ 3
- 3.2 Name Servers ............................................. 3
- 3.3 Selected Objects ......................................... 4
- 3.4 Textual Conventions ...................................... 4
- 4. Definitions ............................................... 5
- 5. Acknowledgements .......................................... 28
- 6. References ................................................ 28
- 7. Security Considerations ................................... 29
- 8. Authors' Addresses ........................................ 30
-
-1. Introduction
-
- This memo defines a portion of the Management Information Base (MIB)
- for use with network management protocols in the Internet community.
- In particular, it describes a set of extensions which instrument DNS
- name server functions. This memo was produced by the DNS working
- group.
-
- With the adoption of the Internet-standard Network Management
- Framework [4,5,6,7], and with a large number of vendor
- implementations of these standards in commercially available
- products, it became possible to provide a higher level of effective
- network management in TCP/IP-based internets than was previously
- available. With the growth in the use of these standards, it has
- become possible to consider the management of other elements of the
- infrastructure beyond the basic TCP/IP protocols. A key element of
-
-
-
-Austein & Saperia [Page 1]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- the TCP/IP infrastructure is the DNS.
-
- Up to this point there has been no mechanism to integrate the
- management of the DNS with SNMP-based managers. This memo provides
- the mechanisms by which IP-based management stations can effectively
- manage DNS name server software in an integrated fashion.
-
- We have defined DNS MIB objects to be used in conjunction with the
- Internet MIB to allow access to and control of DNS name server
- software via SNMP by the Internet community.
-
-2. The SNMPv2 Network Management Framework
-
- The SNMPv2 Network Management Framework consists of four major
- components. They are:
-
- o RFC 1442 which defines the SMI, the mechanisms used for
- describing and naming objects for the purpose of management.
-
- o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
- for the Internet suite of protocols.
-
- o RFC 1445 which defines the administrative and other architectural
- aspects of the framework.
-
- o RFC 1448 which defines the protocol used for network access to
- managed objects.
-
- The Framework permits new objects to be defined for the purpose of
- experimentation and evaluation.
-
-2.1. Object Definitions
-
- Managed objects are accessed via a virtual information store, termed
- the Management Information Base or MIB. Objects in the MIB are
- defined using the subset of Abstract Syntax Notation One (ASN.1)
- defined in the SMI. In particular, each object object type is named
- by an OBJECT IDENTIFIER, an administratively assigned name. The
- object type together with an object instance serves to uniquely
- identify a specific instantiation of the object. For human
- convenience, we often use a textual string, termed the descriptor, to
- refer to the object type.
-
-3. Overview
-
- In theory, the DNS world is pretty simple. There are two kinds of
- entities: resolvers and name servers. Resolvers ask questions. Name
- servers answer them. The real world, however, is not so simple.
-
-
-
-Austein & Saperia [Page 2]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- Implementors have made widely differing choices about how to divide
- DNS functions between resolvers and servers. They have also
- constructed various sorts of exotic hybrids. The most difficult task
- in defining this MIB was to accommodate this wide range of entities
- without having to come up with a separate MIB for each.
-
- We divided up the various DNS functions into two, non-overlapping
- classes, called "resolver functions" and "name server functions." A
- DNS entity that performs what we define as resolver functions
- contains a resolver, and therefore must implement the MIB groups
- required of all resolvers which are defined in a separate MIB Module.
- A DNS entity which implements name server functions is considered to
- be a name server, and must implement the MIB groups required for name
- servers in this module. If the same piece of software performs both
- resolver and server functions, we imagine that it contains both a
- resolver and a server and would thus implement both the DNS Server
- and DNS Resolver MIBs.
-
-3.1. Resolvers
-
- In our model, a resolver is a program (or piece thereof) which
- obtains resource records from servers. Normally it does so at the
- behest of an application, but may also do so as part of its own
- operation. A resolver sends DNS protocol queries and receives DNS
- protocol replies. A resolver neither receives queries nor sends
- replies. A full service resolver is one that knows how to resolve
- queries: it obtains the needed resource records by contacting a
- server authoritative for the records desired. A stub resolver does
- not know how to resolve queries: it sends all queries to a local name
- server, setting the "recursion desired" flag to indicate that it
- hopes that the name server will be willing to resolve the query. A
- resolver may (optionally) have a cache for remembering previously
- acquired resource records. It may also have a negative cache for
- remembering names or data that have been determined not to exist.
-
-3.2. Name Servers
-
- A name server is a program (or piece thereof) that provides resource
- records to resolvers. All references in this document to "a name
- server" imply "the name server's role"; in some cases the name
- server's role and the resolver's role might be combined into a single
- program. A name server receives DNS protocol queries and sends DNS
- protocol replies. A name server neither sends queries nor receives
- replies. As a consequence, name servers do not have caches.
- Normally, a name server would expect to receive only those queries to
- which it could respond with authoritative information. However, if a
- name server receives a query that it cannot respond to with purely
- authoritative information, it may choose to try to obtain the
-
-
-
-Austein & Saperia [Page 3]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- necessary additional information from a resolver which may or may not
- be a separate process.
-
-3.3. Selected Objects
-
- Many of the objects included in this memo have been created from
- information contained in the DNS specifications [1,2], as amended and
- clarified by subsequent host requirements documents [3]. Other
- objects have been created based on experience with existing DNS
- management tools, expected operational needs, the statistics
- generated by existing DNS implementations, and the configuration
- files used by existing DNS implementations. These objects have been
- ordered into groups as follows:
-
- o Server Configuration Group
-
- o Server Counter Group
-
- o Server Optional Counter Group
-
- o Server Zone Group
-
- This information has been converted into a standard form using the
- SNMPv2 SMI defined in [9]. For the most part, the descriptions are
- influenced by the DNS related RFCs noted above. For example, the
- descriptions for counters used for the various types of queries of
- DNS records are influenced by the definitions used for the various
- record types found in [2].
-
-3.4. Textual Conventions
-
- Several conceptual data types have been introduced as a textual
- conventions in this DNS MIB document. These additions will
- facilitate the common understanding of information used by the DNS.
- No changes to the SMI or the SNMP are necessary to support these
- conventions.
-
- Readers familiar with MIBs designed to manage entities in the lower
- layers of the Internet protocol suite may be surprised at the number
- of non-enumerated integers used in this MIB to represent values such
- as DNS RR class and type numbers. The reason for this choice is
- simple: the DNS itself is designed as an extensible protocol,
- allowing new classes and types of resource records to be added to the
- protocol without recoding the core DNS software. Using non-
- enumerated integers to represent these data types in this MIB allows
- the MIB to accommodate these changes as well.
-
-
-
-
-
-Austein & Saperia [Page 4]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
-4. Definitions
-
- DNS-SERVER-MIB DEFINITIONS ::= BEGIN
-
- IMPORTS
- mib-2
- FROM RFC-1213
- MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
- IpAddress, Counter32, Gauge32
- FROM SNMPv2-SMI
- TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue
- FROM SNMPv2-TC
- MODULE-COMPLIANCE, OBJECT-GROUP
- FROM SNMPv2-CONF;
-
- dns OBJECT-IDENTITY
- STATUS current
- DESCRIPTION
- "The OID assigned to DNS MIB work by the IANA."
- ::= { mib-2 32 }
-
- dnsServMIB MODULE-IDENTITY
- LAST-UPDATED "9401282251Z"
- ORGANIZATION "IETF DNS Working Group"
- CONTACT-INFO
- " Rob Austein
- Postal: Epilogue Technology Corporation
- 268 Main Street, Suite 283
- North Reading, MA 10864
- US
- Tel: +1 617 245 0804
- Fax: +1 617 245 8122
- E-Mail: sra@epilogue.com
-
- Jon Saperia
- Postal: Digital Equipment Corporation
- 110 Spit Brook Road
- ZKO1-3/H18
- Nashua, NH 03062-2698
- US
- Tel: +1 603 881 0480
- Fax: +1 603 881 0120
- Email: saperia@zko.dec.com"
- DESCRIPTION
- "The MIB module for entities implementing the server side
- of the Domain Name System (DNS) protocol."
- ::= { dns 1 }
-
-
-
-
-Austein & Saperia [Page 5]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- dnsServMIBObjects OBJECT IDENTIFIER ::= { dnsServMIB 1 }
-
- -- (Old-style) groups in the DNS server MIB.
-
- dnsServConfig OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 }
- dnsServCounter OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 }
- dnsServOptCounter OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 }
- dnsServZone OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 }
-
-
- -- Textual conventions
-
- DnsName ::= TEXTUAL-CONVENTION
- -- A DISPLAY-HINT would be nice, but difficult to express.
- STATUS current
- DESCRIPTION
- "A DNS name is a sequence of labels. When DNS names are
- displayed, the boundaries between labels are typically
- indicated by dots (e.g. `Acme' and `COM' are labels in
- the name `Acme.COM'). In the DNS protocol, however, no
- such separators are needed because each label is encoded
- as a length octet followed by the indicated number of
- octets of label. For example, `Acme.COM' is encoded as
- the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
- 'M', 0 } (the final 0 is the length of the name of the
- root domain, which appears implicitly at the end of any
- DNS name). This MIB uses the same encoding as the DNS
- protocol.
-
- A DnsName must always be a fully qualified name. It is
- an error to encode a relative domain name as a DnsName
- without first making it a fully qualified name."
- REFERENCE
- "RFC-1034 section 3.1."
- SYNTAX OCTET STRING (SIZE (0..255))
-
- DnsNameAsIndex ::= TEXTUAL-CONVENTION
- STATUS current
- DESCRIPTION
- "This textual convention is like a DnsName, but is used
- as an index componant in tables. Alphabetic characters
- in names of this type are restricted to uppercase: the
- characters 'a' through 'z' are mapped to the characters
- 'A' through 'Z'. This restriction is intended to make
- the lexical ordering imposed by SNMP useful when applied
- to DNS names.
-
- Note that it is theoretically possible for a valid DNS
-
-
-
-Austein & Saperia [Page 6]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- name to exceed the allowed length of an SNMP object
- identifer, and thus be impossible to represent in tables
- in this MIB that are indexed by DNS name. Sampling of
- DNS names in current use on the Internet suggests that
- this limit does not pose a serious problem in practice."
- REFERENCE
- "RFC-1034 section 3.1, RFC-1448 section 4.1."
- SYNTAX DnsName
-
- DnsClass ::= TEXTUAL-CONVENTION
- DISPLAY-HINT "2d"
- STATUS current
- DESCRIPTION
- "This data type is used to represent the class values
- which appear in Resource Records in the DNS. A 16-bit
- unsigned integer is used to allow room for new classes
- of records to be defined. Existing standard classes are
- listed in the DNS specifications."
- REFERENCE
- "RFC-1035 section 3.2.4."
- SYNTAX INTEGER (0..65535)
-
- DnsType ::= TEXTUAL-CONVENTION
- DISPLAY-HINT "2d"
- STATUS current
- DESCRIPTION
- "This data type is used to represent the type values
- which appear in Resource Records in the DNS. A 16-bit
- unsigned integer is used to allow room for new record
- types to be defined. Existing standard types are listed
- in the DNS specifications."
- REFERENCE
- "RFC-1035 section 3.2.2."
- SYNTAX INTEGER (0..65535)
-
- DnsQClass ::= TEXTUAL-CONVENTION
- DISPLAY-HINT "2d"
- STATUS current
- DESCRIPTION
- "This data type is used to represent the QClass values
- which appear in Resource Records in the DNS. A 16-bit
- unsigned integer is used to allow room for new QClass
- records to be defined. Existing standard QClasses are
- listed in the DNS specification."
- REFERENCE
- "RFC-1035 section 3.2.5."
- SYNTAX INTEGER (0..65535)
-
-
-
-
-Austein & Saperia [Page 7]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- DnsQType ::= TEXTUAL-CONVENTION
- DISPLAY-HINT "2d"
- STATUS current
- DESCRIPTION
- "This data type is used to represent the QType values
- which appear in Resource Records in the DNS. A 16-bit
- unsigned integer is used to allow room for new QType
- records to be defined. Existing standard QTypes are
- listed in the DNS specification."
- REFERENCE
- "RFC-1035 section 3.2.3."
- SYNTAX INTEGER (0..65535)
-
- DnsTime ::= TEXTUAL-CONVENTION
- DISPLAY-HINT "4d"
- STATUS current
- DESCRIPTION
- "DnsTime values are 32-bit unsigned integers which
- measure time in seconds."
- REFERENCE
- "RFC-1035."
- SYNTAX Gauge32
-
-
- DnsOpCode ::= TEXTUAL-CONVENTION
- STATUS current
- DESCRIPTION
- "This textual convention is used to represent the DNS
- OPCODE values used in the header section of DNS
- messages. Existing standard OPCODE values are listed in
- the DNS specifications."
- REFERENCE
- "RFC-1035 section 4.1.1."
- SYNTAX INTEGER (0..15)
-
- DnsRespCode ::= TEXTUAL-CONVENTION
- STATUS current
- DESCRIPTION
- "This data type is used to represent the DNS RCODE value
- in DNS response messages. Existing standard RCODE
- values are listed in the DNS specifications."
- REFERENCE
- "RFC-1035 section 4.1.1."
- SYNTAX INTEGER (0..15)
-
-
-
-
-
-
-
-Austein & Saperia [Page 8]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- -- Server Configuration Group
-
- dnsServConfigImplementIdent OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The implementation identification string for the DNS
- server software in use on the system, for example;
- `FNS-2.1'"
- ::= { dnsServConfig 1 }
-
- dnsServConfigRecurs OBJECT-TYPE
- SYNTAX INTEGER { available(1),
- restricted(2),
- unavailable(3) }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "This represents the recursion services offered by this
- name server. The values that can be read or written
- are:
-
- available(1) - performs recursion on requests from
- clients.
-
- restricted(2) - recursion is performed on requests only
- from certain clients, for example; clients on an access
- control list.
-
- unavailable(3) - recursion is not available."
- ::= { dnsServConfig 2 }
-
- dnsServConfigUpTime OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "If the server has a persistent state (e.g., a process),
- this value will be the time elapsed since it started.
- For software without persistant state, this value will
- be zero."
- ::= { dnsServConfig 3 }
-
- dnsServConfigResetTime OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
-
-
-
-Austein & Saperia [Page 9]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- DESCRIPTION
- "If the server has a persistent state (e.g., a process)
- and supports a `reset' operation (e.g., can be told to
- re-read configuration files), this value will be the
- time elapsed since the last time the name server was
- `reset.' For software that does not have persistence or
- does not support a `reset' operation, this value will be
- zero."
- ::= { dnsServConfig 4 }
-
- dnsServConfigReset OBJECT-TYPE
- SYNTAX INTEGER { other(1),
- reset(2),
- initializing(3),
- running(4) }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Status/action object to reinitialize any persistant name
- server state. When set to reset(2), any persistant
- name server state (such as a process) is reinitialized as
- if the name server had just been started. This value
- will never be returned by a read operation. When read,
- one of the following values will be returned:
- other(1) - server in some unknown state;
- initializing(3) - server (re)initializing;
- running(4) - server currently running."
- ::= { dnsServConfig 5 }
-
-
- -- Server Counter Group
-
- dnsServCounterAuthAns OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries which were authoritatively answered."
- ::= { dnsServCounter 2 }
-
- dnsServCounterAuthNoNames OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries for which `authoritative no such name'
- responses were made."
- ::= { dnsServCounter 3 }
-
-
-
-Austein & Saperia [Page 10]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- dnsServCounterAuthNoDataResps OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries for which `authoritative no such data'
- (empty answer) responses were made."
- ::= { dnsServCounter 4 }
-
- dnsServCounterNonAuthDatas OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries which were non-authoritatively
- answered (cached data)."
- ::= { dnsServCounter 5 }
-
- dnsServCounterNonAuthNoDatas OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries which were non-authoritatively
- answered with no data (empty answer)."
- ::= { dnsServCounter 6 }
-
- dnsServCounterReferrals OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests that were referred to other servers."
- ::= { dnsServCounter 7 }
-
- dnsServCounterErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests the server has processed that were
- answered with errors (RCODE values other than 0 and 3)."
- REFERENCE
- "RFC-1035 section 4.1.1."
- ::= { dnsServCounter 8 }
-
- dnsServCounterRelNames OBJECT-TYPE
- SYNTAX Counter32
-
-
-
-Austein & Saperia [Page 11]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests received by the server for names that
- are only 1 label long (text form - no internal dots)."
- ::= { dnsServCounter 9 }
-
- dnsServCounterReqRefusals OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of DNS requests refused by the server."
- ::= { dnsServCounter 10 }
-
- dnsServCounterReqUnparses OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests received which were unparseable."
- ::= { dnsServCounter 11 }
-
- dnsServCounterOtherErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests which were aborted for other (local)
- server errors."
- ::= { dnsServCounter 12 }
-
- -- DNS Server Counter Table
-
- dnsServCounterTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsServCounterEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Counter information broken down by DNS class and type."
- ::= { dnsServCounter 13 }
-
- dnsServCounterEntry OBJECT-TYPE
- SYNTAX DnsServCounterEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "This table contains count information for each DNS class
-
-
-
-Austein & Saperia [Page 12]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- and type value known to the server. The index allows
- management software to to create indices to the table to
- get the specific information desired, e.g., number of
- queries over UDP for records with type value `A' which
- came to this server. In order to prevent an
- uncontrolled expansion of rows in the table; if
- dnsServCounterRequests is 0 and dnsServCounterResponses
- is 0, then the row does not exist and `no such' is
- returned when the agent is queried for such instances."
- INDEX { dnsServCounterOpCode,
- dnsServCounterQClass,
- dnsServCounterQType,
- dnsServCounterTransport }
- ::= { dnsServCounterTable 1 }
-
- DnsServCounterEntry ::=
- SEQUENCE {
- dnsServCounterOpCode
- DnsOpCode,
- dnsServCounterQClass
- DnsClass,
- dnsServCounterQType
- DnsType,
- dnsServCounterTransport
- INTEGER,
- dnsServCounterRequests
- Counter32,
- dnsServCounterResponses
- Counter32
- }
-
- dnsServCounterOpCode OBJECT-TYPE
- SYNTAX DnsOpCode
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The DNS OPCODE being counted in this row of the table."
- ::= { dnsServCounterEntry 1 }
-
- dnsServCounterQClass OBJECT-TYPE
- SYNTAX DnsClass
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The class of record being counted in this row of the
- table."
- ::= { dnsServCounterEntry 2 }
-
-
-
-
-Austein & Saperia [Page 13]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- dnsServCounterQType OBJECT-TYPE
- SYNTAX DnsType
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The type of record which is being counted in this row in
- the table."
- ::= { dnsServCounterEntry 3 }
-
- dnsServCounterTransport OBJECT-TYPE
- SYNTAX INTEGER { udp(1), tcp(2), other(3) }
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A value of udp(1) indicates that the queries reported on
- this row were sent using UDP.
-
- A value of tcp(2) indicates that the queries reported on
- this row were sent using TCP.
-
- A value of other(3) indicates that the queries reported
- on this row were sent using a transport that was neither
- TCP nor UDP."
- ::= { dnsServCounterEntry 4 }
-
- dnsServCounterRequests OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests (queries) that have been recorded in
- this row of the table."
- ::= { dnsServCounterEntry 5 }
-
- dnsServCounterResponses OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of responses made by the server since
- initialization for the kind of query identified on this
- row of the table."
- ::= { dnsServCounterEntry 6 }
-
-
-
-
-
-
-
-
-Austein & Saperia [Page 14]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- -- Server Optional Counter Group
-
- -- The Server Optional Counter Group is intended for those systems
- -- which make distinctions between the different sources of the DNS
- -- queries as defined below.
- --
- -- Objects in this group are implemented on servers which distinguish
- -- between queries which originate from the same host as the server,
- -- queries from one of an arbitrary group of hosts that are on an
- -- access list defined by the server, and queries from hosts that do
- -- not fit either of these descriptions.
- --
- -- The objects found in the Server Counter group are totals. Thus if
- -- one wanted to identify, for example, the number of queries from
- -- `remote' hosts which have been given authoritative answers, one
- -- would subtract the current values of ServOptCounterFriendsAuthAns
- -- and ServOptCounterSelfAuthAns from servCounterAuthAns.
- --
- -- The purpose of these distinctions is to allow for implementations
- -- to group queries and responses on this basis. One way in which
- -- servers may make these distinctions is by looking at the source IP
- -- address of the DNS query. If the source of the query is `your
- -- own' then the query should be counted as `yourself' (local host).
- -- If the source of the query matches an `access list,' the query
- -- came from a friend. What constitutes an `access list' is
- -- implementation dependent and could be as simple as a rule that all
- -- hosts on the same IP network as the DNS server are classed
- -- `friends.'
- --
- -- In order to avoid double counting, the following rules apply:
- --
- -- 1. No host is in more than one of the three groups defined above.
- --
- -- 2. All queries from the local host are always counted in the
- -- `yourself' group regardless of what the access list, if any,
- -- says.
- --
- -- 3. The access list should not define `your friends' in such a way
- -- that it includes all hosts. That is, not everybody is your
- -- `friend.'
-
- dnsServOptCounterSelfAuthAns OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests the server has processed which
- originated from a resolver on the same host for which
-
-
-
-Austein & Saperia [Page 15]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- there has been an authoritative answer."
- ::= { dnsServOptCounter 1 }
-
- dnsServOptCounterSelfAuthNoNames OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests the server has processed which
- originated from a resolver on the same host for which
- there has been an authoritative no such name answer
- given."
- ::= { dnsServOptCounter 2 }
-
- dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests the server has processed which
- originated from a resolver on the same host for which
- there has been an authoritative no such data answer
- (empty answer) made."
- ::= { dnsServOptCounter 3 }
-
- dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests the server has processed which
- originated from a resolver on the same host for which a
- non-authoritative answer (cached data) was made."
- ::= { dnsServOptCounter 4 }
-
- dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests the server has processed which
- originated from a resolver on the same host for which a
- `non-authoritative, no such data' response was made
- (empty answer)."
- ::= { dnsServOptCounter 5 }
-
- dnsServOptCounterSelfReferrals OBJECT-TYPE
- SYNTAX Counter32
-
-
-
-Austein & Saperia [Page 16]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries the server has processed which
- originated from a resolver on the same host and were
- referred to other servers."
- ::= { dnsServOptCounter 6 }
-
- dnsServOptCounterSelfErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests the server has processed which
- originated from a resolver on the same host which have
- been answered with errors (RCODEs other than 0 and 3)."
- REFERENCE
- "RFC-1035 section 4.1.1."
- ::= { dnsServOptCounter 7 }
-
- dnsServOptCounterSelfRelNames OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests received for names that are only 1
- label long (text form - no internal dots) the server has
- processed which originated from a resolver on the same
- host."
- ::= { dnsServOptCounter 8 }
-
- dnsServOptCounterSelfReqRefusals OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of DNS requests refused by the server which
- originated from a resolver on the same host."
- ::= { dnsServOptCounter 9 }
-
- dnsServOptCounterSelfReqUnparses OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests received which were unparseable and
- which originated from a resolver on the same host."
- ::= { dnsServOptCounter 10 }
-
-
-
-Austein & Saperia [Page 17]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- dnsServOptCounterSelfOtherErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests which were aborted for other (local)
- server errors and which originated on the same host."
- ::= { dnsServOptCounter 11 }
-
- dnsServOptCounterFriendsAuthAns OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries originating from friends which were
- authoritatively answered. The definition of friends is
- a locally defined matter."
- ::= { dnsServOptCounter 12 }
-
- dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries originating from friends, for which
- authoritative `no such name' responses were made. The
- definition of friends is a locally defined matter."
- ::= { dnsServOptCounter 13 }
-
- dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries originating from friends for which
- authoritative no such data (empty answer) responses were
- made. The definition of friends is a locally defined
- matter."
- ::= { dnsServOptCounter 14 }
-
- dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries originating from friends which were
- non-authoritatively answered (cached data). The
- definition of friends is a locally defined matter."
-
-
-
-Austein & Saperia [Page 18]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- ::= { dnsServOptCounter 15 }
-
- dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries originating from friends which were
- non-authoritatively answered with no such data (empty
- answer)."
- ::= { dnsServOptCounter 16 }
-
- dnsServOptCounterFriendsReferrals OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests which originated from friends that
- were referred to other servers. The definition of
- friends is a locally defined matter."
- ::= { dnsServOptCounter 17 }
-
- dnsServOptCounterFriendsErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests the server has processed which
- originated from friends and were answered with errors
- (RCODE values other than 0 and 3). The definition of
- friends is a locally defined matter."
- REFERENCE
- "RFC-1035 section 4.1.1."
- ::= { dnsServOptCounter 18 }
-
- dnsServOptCounterFriendsRelNames OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests received for names from friends that
- are only 1 label long (text form - no internal dots) the
- server has processed."
- ::= { dnsServOptCounter 19 }
-
- dnsServOptCounterFriendsReqRefusals OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
-
-
-
-Austein & Saperia [Page 19]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- STATUS current
- DESCRIPTION
- "Number of DNS requests refused by the server which were
- received from `friends'."
- ::= { dnsServOptCounter 20 }
-
- dnsServOptCounterFriendsReqUnparses OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests received which were unparseable and
- which originated from `friends'."
- ::= { dnsServOptCounter 21 }
-
- dnsServOptCounterFriendsOtherErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests which were aborted for other (local)
- server errors and which originated from `friends'."
- ::= { dnsServOptCounter 22 }
-
-
- -- Server Zone Group
-
- -- DNS Management Zone Configuration Table
-
- -- This table contains zone configuration information.
-
- dnsServZoneTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsServZoneEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of zones for which this name server provides
- information. Each of the zones may be loaded from stable
- storage via an implementation-specific mechanism or may
- be obtained from another name server via a zone transfer.
-
- If name server doesn't load any zones, this table is
- empty."
- ::= { dnsServZone 1 }
-
- dnsServZoneEntry OBJECT-TYPE
- SYNTAX DnsServZoneEntry
- MAX-ACCESS not-accessible
-
-
-
-Austein & Saperia [Page 20]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- STATUS current
- DESCRIPTION
- "An entry in the name server zone table. New rows may be
- added either via SNMP or by the name server itself."
- INDEX { dnsServZoneName,
- dnsServZoneClass }
- ::= { dnsServZoneTable 1 }
-
- DnsServZoneEntry ::=
- SEQUENCE {
- dnsServZoneName
- DnsNameAsIndex,
- dnsServZoneClass
- DnsClass,
- dnsServZoneLastReloadSuccess
- DnsTime,
- dnsServZoneLastReloadAttempt
- DnsTime,
- dnsServZoneLastSourceAttempt
- IpAddress,
- dnsServZoneStatus
- RowStatus,
- dnsServZoneSerial
- Counter32,
- dnsServZoneCurrent
- TruthValue,
- dnsServZoneLastSourceSuccess
- IpAddress
- }
-
- dnsServZoneName OBJECT-TYPE
- SYNTAX DnsNameAsIndex
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS name of the zone described by this row of the table.
- This is the owner name of the SOA RR that defines the
- top of the zone. This is name is in uppercase:
- characters 'a' through 'z' are mapped to 'A' through 'Z'
- in order to make the lexical ordering useful."
- ::= { dnsServZoneEntry 1 }
-
- dnsServZoneClass OBJECT-TYPE
- SYNTAX DnsClass
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS class of the RRs in this zone."
-
-
-
-Austein & Saperia [Page 21]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- ::= { dnsServZoneEntry 2 }
-
- dnsServZoneLastReloadSuccess OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Elapsed time in seconds since last successful reload of
- this zone."
- ::= { dnsServZoneEntry 3 }
-
- dnsServZoneLastReloadAttempt OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Elapsed time in seconds since last attempted reload of
- this zone."
- ::= { dnsServZoneEntry 4 }
-
- dnsServZoneLastSourceAttempt OBJECT-TYPE
- SYNTAX IpAddress
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "IP address of host from which most recent zone transfer
- of this zone was attempted. This value should match the
- value of dnsServZoneSourceSuccess if the attempt was
- succcessful. If zone transfer has not been attempted
- within the memory of this name server, this value should
- be 0.0.0.0."
- ::= { dnsServZoneEntry 5 }
-
- dnsServZoneStatus OBJECT-TYPE
- SYNTAX RowStatus
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "The status of the information represented in this row of
- the table."
- ::= { dnsServZoneEntry 6 }
-
- dnsServZoneSerial OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Zone serial number (from the SOA RR) of the zone
-
-
-
-Austein & Saperia [Page 22]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- represented by this row of the table. If the zone has
- not been successfully loaded within the memory of this
- name server, the value of this variable is zero."
- ::= { dnsServZoneEntry 7 }
-
- dnsServZoneCurrent OBJECT-TYPE
- SYNTAX TruthValue
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Whether the server's copy of the zone represented by
- this row of the table is currently valid. If the zone
- has never been successfully loaded or has expired since
- it was last succesfully loaded, this variable will have
- the value false(2), otherwise this variable will have
- the value true(1)."
- ::= { dnsServZoneEntry 8 }
-
- dnsServZoneLastSourceSuccess OBJECT-TYPE
- SYNTAX IpAddress
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "IP address of host which was the source of the most
- recent successful zone transfer for this zone. If
- unknown (e.g., zone has never been successfully
- transfered) or irrelevant (e.g., zone was loaded from
- stable storage), this value should be 0.0.0.0."
- ::= { dnsServZoneEntry 9 }
-
- -- DNS Zone Source Table
-
- dnsServZoneSrcTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsServZoneSrcEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "This table is a list of IP addresses from which the
- server will attempt to load zone information using DNS
- zone transfer operations. A reload may occur due to SNMP
- operations that create a row in dnsServZoneTable or a
- SET to object dnsServZoneReload. This table is only
- used when the zone is loaded via zone transfer."
- ::= { dnsServZone 2 }
-
- dnsServZoneSrcEntry OBJECT-TYPE
- SYNTAX DnsServZoneSrcEntry
- MAX-ACCESS not-accessible
-
-
-
-Austein & Saperia [Page 23]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- STATUS current
- DESCRIPTION
- "An entry in the name server zone source table."
- INDEX { dnsServZoneSrcName,
- dnsServZoneSrcClass,
- dnsServZoneSrcAddr }
- ::= { dnsServZoneSrcTable 1 }
-
- DnsServZoneSrcEntry ::=
- SEQUENCE {
- dnsServZoneSrcName
- DnsNameAsIndex,
- dnsServZoneSrcClass
- DnsClass,
- dnsServZoneSrcAddr
- IpAddress,
- dnsServZoneSrcStatus
- RowStatus
- }
-
- dnsServZoneSrcName OBJECT-TYPE
- SYNTAX DnsNameAsIndex
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS name of the zone to which this entry applies."
- ::= { dnsServZoneSrcEntry 1 }
-
- dnsServZoneSrcClass OBJECT-TYPE
- SYNTAX DnsClass
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS class of zone to which this entry applies."
- ::= { dnsServZoneSrcEntry 2 }
-
- dnsServZoneSrcAddr OBJECT-TYPE
- SYNTAX IpAddress
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "IP address of name server host from which this zone
- might be obtainable."
- ::= { dnsServZoneSrcEntry 3 }
-
- dnsServZoneSrcStatus OBJECT-TYPE
- SYNTAX RowStatus
- MAX-ACCESS read-create
-
-
-
-Austein & Saperia [Page 24]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- STATUS current
- DESCRIPTION
- "The status of the information represented in this row of
- the table."
- ::= { dnsServZoneSrcEntry 4 }
-
-
- -- SNMPv2 groups.
-
- dnsServMIBGroups OBJECT IDENTIFIER ::= { dnsServMIB 2 }
-
- dnsServConfigGroup OBJECT-GROUP
- OBJECTS { dnsServConfigImplementIdent,
- dnsServConfigRecurs,
- dnsServConfigUpTime,
- dnsServConfigResetTime,
- dnsServConfigReset }
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic configuration
- control of a DNS name server."
- ::= { dnsServMIBGroups 1 }
-
- dnsServCounterGroup OBJECT-GROUP
- OBJECTS { dnsServCounterAuthAns,
- dnsServCounterAuthNoNames,
- dnsServCounterAuthNoDataResps,
- dnsServCounterNonAuthDatas,
- dnsServCounterNonAuthNoDatas,
- dnsServCounterReferrals,
- dnsServCounterErrors,
- dnsServCounterRelNames,
- dnsServCounterReqRefusals,
- dnsServCounterReqUnparses,
- dnsServCounterOtherErrors,
- dnsServCounterOpCode,
- dnsServCounterQClass,
- dnsServCounterQType,
- dnsServCounterTransport,
- dnsServCounterRequests,
- dnsServCounterResponses }
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic instrumentation
- of a DNS name server."
- ::= { dnsServMIBGroups 2 }
-
-
-
-
-
-Austein & Saperia [Page 25]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- dnsServOptCounterGroup OBJECT-GROUP
- OBJECTS { dnsServOptCounterSelfAuthAns,
- dnsServOptCounterSelfAuthNoNames,
- dnsServOptCounterSelfAuthNoDataResps,
- dnsServOptCounterSelfNonAuthDatas,
- dnsServOptCounterSelfNonAuthNoDatas,
- dnsServOptCounterSelfReferrals,
- dnsServOptCounterSelfErrors,
- dnsServOptCounterSelfRelNames,
- dnsServOptCounterSelfReqRefusals,
- dnsServOptCounterSelfReqUnparses,
- dnsServOptCounterSelfOtherErrors,
- dnsServOptCounterFriendsAuthAns,
- dnsServOptCounterFriendsAuthNoNames,
- dnsServOptCounterFriendsAuthNoDataResps,
- dnsServOptCounterFriendsNonAuthDatas,
- dnsServOptCounterFriendsNonAuthNoDatas,
- dnsServOptCounterFriendsReferrals,
- dnsServOptCounterFriendsErrors,
- dnsServOptCounterFriendsRelNames,
- dnsServOptCounterFriendsReqRefusals,
- dnsServOptCounterFriendsReqUnparses,
- dnsServOptCounterFriendsOtherErrors }
- STATUS current
- DESCRIPTION
- "A collection of objects providing extended
- instrumentation of a DNS name server."
- ::= { dnsServMIBGroups 3 }
-
- dnsServZoneGroup OBJECT-GROUP
- OBJECTS { dnsServZoneName,
- dnsServZoneClass,
- dnsServZoneLastReloadSuccess,
- dnsServZoneLastReloadAttempt,
- dnsServZoneLastSourceAttempt,
- dnsServZoneLastSourceSuccess,
- dnsServZoneStatus,
- dnsServZoneSerial,
- dnsServZoneCurrent,
- dnsServZoneSrcName,
- dnsServZoneSrcClass,
- dnsServZoneSrcAddr,
- dnsServZoneSrcStatus }
- STATUS current
- DESCRIPTION
- "A collection of objects providing configuration control
- of a DNS name server which loads authoritative zones."
- ::= { dnsServMIBGroups 4 }
-
-
-
-Austein & Saperia [Page 26]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- -- Compliances.
-
- dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 }
-
- dnsServMIBCompliance MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "The compliance statement for agents implementing the DNS
- name server MIB extensions."
- MODULE -- This MIB module
- MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup }
- GROUP dnsServOptCounterGroup
- DESCRIPTION
- "The server optional counter group is unconditionally
- optional."
- GROUP dnsServZoneGroup
- DESCRIPTION
- "The server zone group is mandatory for any name server
- that acts as an authoritative server for any DNS zone."
- OBJECT dnsServConfigRecurs
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- OBJECT dnsServConfigReset
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- ::= { dnsServMIBCompliances 1 }
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia [Page 27]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
-5. Acknowledgements
-
- This document is the result of work undertaken the by DNS working
- group. The authors would particularly like to thank the following
- people for their contributions to this document: Philip Almquist,
- Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
- (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
-
-6. References
-
- [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [2] Mockapetris, P., "Domain Names -- Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [3] Braden, R., Editor, "Requirements for Internet Hosts --
- Application and Support, STD 3, RFC 1123, USC/Information
- Sciences Institute, October 1989.
-
- [4] Rose, M., and K. McCloghrie, "Structure and Identification of
- Management Information for TCP/IP-based internets", STD 16, RFC
- 1155, Performance Systems International, Hughes LAN Systems, May
- 1990.
-
- [5] McCloghrie, K., and M. Rose, "Management Information Base for
- Network Management of TCP/IP-based internets", RFC 1156, Hughes
- LAN Systems, Performance Systems International, May 1990.
-
- [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
- Network Management Protocol", STD 15, RFC 1157, SNMP Research,
- Performance Systems International, Performance Systems
- International, MIT Laboratory for Computer Science, May 1990.
-
- [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
- STD 16, RFC 1212, Performance Systems International, Hughes LAN
- Systems, March 1991.
-
- [8] McCloghrie, K., and M. Rose, Editors, "Management Information
- Base for Network Management of TCP/IP-based internets: MIB-II",
- STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
- International, March 1991.
-
- [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
- of Management Information for version 2 of the Simple Network
- Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
- Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-
-
-
-Austein & Saperia [Page 28]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
- University, April 1993.
-
- [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
- Conventions for version 2 of the the Simple Network Management
- Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
- Systems, Dover Beach Consulting, Inc., Carnegie Mellon
- University, April 1993.
-
- [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
- "Conformance Statements for version 2 of the the Simple Network
- Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
- Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
- University, April 1993.
-
- [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
- 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
- Trusted Information Systems, Hughes LAN Systems, April 1993.
-
- [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
- Operations for version 2 of the Simple Network Management
- Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
- Systems, Dover Beach Consulting, Inc., Carnegie Mellon
- University, April 1993.
-
- [14] "Information processing systems - Open Systems Interconnection -
- Specification of Abstract Syntax Notation One (ASN.1)",
- International Organization for Standardization, International
- Standard 8824, December 1987.
-
-7. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia [Page 29]
-
-RFC 1611 DNS Server MIB Extensions May 1994
-
-
-8. Authors' Addresses
-
- Rob Austein
- Epilogue Technology Corporation
- 268 Main Street, Suite 283
- North Reading, MA 01864
- USA
-
- Phone: +1-617-245-0804
- Fax: +1-617-245-8122
- EMail: sra@epilogue.com
-
-
- Jon Saperia
- Digital Equipment Corporation
- 110 Spit Brook Road
- ZKO1-3/H18
- Nashua, NH 03062-2698
- USA
-
- Phone: +1-603-881-0480
- Fax: +1-603-881-0120
- EMail: saperia@zko.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia [Page 30]
-
diff --git a/contrib/bind9/doc/rfc/rfc1612.txt b/contrib/bind9/doc/rfc/rfc1612.txt
deleted file mode 100644
index 4ef23b0c659c9..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1612.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Austein
-Request for Comments: 1612 Epilogue Technology Corporation
-Category: Standards Track J. Saperia
- Digital Equipment Corporation
- May 1994
-
-
- DNS Resolver MIB 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.
-
-Table of Contents
-
- 1. Introduction .............................................. 1
- 2. The SNMPv2 Network Management Framework ................... 2
- 2.1 Object Definitions ....................................... 2
- 3. Overview .................................................. 2
- 3.1 Resolvers ................................................ 3
- 3.2 Name Servers ............................................. 3
- 3.3 Selected Objects ......................................... 4
- 3.4 Textual Conventions ...................................... 4
- 4. Definitions ............................................... 5
- 5. Acknowledgements .......................................... 30
- 6. References ................................................ 30
- 7. Security Considerations ................................... 32
- 8. Authors' Addresses ........................................ 32
-
-1. Introduction
-
- This memo defines a portion of the Management Information Base (MIB)
- for use with network management protocols in the Internet community.
- In particular, it describes a set of extensions which instrument DNS
- resolver functions. This memo was produced by the DNS working group.
-
- With the adoption of the Internet-standard Network Management
- Framework [4,5,6,7], and with a large number of vendor
- implementations of these standards in commercially available
- products, it became possible to provide a higher level of effective
- network management in TCP/IP-based internets than was previously
- available. With the growth in the use of these standards, it has
- become possible to consider the management of other elements of the
- infrastructure beyond the basic TCP/IP protocols. A key element of
-
-
-
-Austein & Saperia [Page 1]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- the TCP/IP infrastructure is the DNS.
-
- Up to this point there has been no mechanism to integrate the
- management of the DNS with SNMP-based managers. This memo provides
- the mechanisms by which IP-based management stations can effectively
- manage DNS resolver software in an integrated fashion.
-
- We have defined DNS MIB objects to be used in conjunction with the
- Internet MIB to allow access to and control of DNS resolver software
- via SNMP by the Internet community.
-
-2. The SNMPv2 Network Management Framework
-
- The SNMPv2 Network Management Framework consists of four major
- components. They are:
-
- o RFC 1442 which defines the SMI, the mechanisms used for
- describing and naming objects for the purpose of management.
-
- o STD 17, RFC 1213 defines MIB-II, the core set of managed
- objects for the Internet suite of protocols.
-
- o RFC 1445 which defines the administrative and other
- architectural aspects of the framework.
-
- o RFC 1448 which defines the protocol used for network access to
- managed objects.
-
- The Framework permits new objects to be defined for the purpose of
- experimentation and evaluation.
-
-2.1. Object Definitions
-
- Managed objects are accessed via a virtual information store, termed
- the Management Information Base or MIB. Objects in the MIB are
- defined using the subset of Abstract Syntax Notation One (ASN.1)
- defined in the SMI. In particular, each object object type is named
- by an OBJECT IDENTIFIER, an administratively assigned name. The
- object type together with an object instance serves to uniquely
- identify a specific instantiation of the object. For human
- convenience, we often use a textual string, termed the descriptor, to
- refer to the object type.
-
-3. Overview
-
- In theory, the DNS world is pretty simple. There are two kinds of
- entities: resolvers and name servers. Resolvers ask questions. Name
- servers answer them. The real world, however, is not so simple.
-
-
-
-Austein & Saperia [Page 2]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- Implementors have made widely differing choices about how to divide
- DNS functions between resolvers and servers. They have also
- constructed various sorts of exotic hybrids. The most difficult task
- in defining this MIB was to accommodate this wide range of entities
- without having to come up with a separate MIB for each.
-
- We divided up the various DNS functions into two, non-overlapping
- classes, called "resolver functions" and "name server functions." A
- DNS entity that performs what we define as resolver functions
- contains a resolver, and therefore must implement the MIB groups
- required of all resolvers which are defined in this module. Some
- resolvers also implement "optional" functions such as a cache, in
- which case they must also implement the cache group contained in this
- MIB. A DNS entity which implements name server functions is
- considered to be a name server, and must implement the MIB groups
- required for name servers which are defined in a separate module. If
- the same piece of software performs both resolver and server
- functions, we imagine that it contains both a resolver and a server
- and would thus implement both the DNS Server and DNS Resolver MIBs.
-
-3.1. Resolvers
-
- In our model, a resolver is a program (or piece thereof) which
- obtains resource records from servers. Normally it does so at the
- behest of an application, but may also do so as part of its own
- operation. A resolver sends DNS protocol queries and receives DNS
- protocol replies. A resolver neither receives queries nor sends
- replies. A full service resolver is one that knows how to resolve
- queries: it obtains the needed resource records by contacting a
- server authoritative for the records desired. A stub resolver does
- not know how to resolve queries: it sends all queries to a local name
- server, setting the "recursion desired" flag to indicate that it
- hopes that the name server will be willing to resolve the query. A
- resolver may (optionally) have a cache for remembering previously
- acquired resource records. It may also have a negative cache for
- remembering names or data that have been determined not to exist.
-
-3.2. Name Servers
-
- A name server is a program (or piece thereof) that provides resource
- records to resolvers. All references in this document to "a name
- server" imply "the name server's role"; in some cases the name
- server's role and the resolver's role might be combined into a single
- program. A name server receives DNS protocol queries and sends DNS
- protocol replies. A name server neither sends queries nor receives
- replies. As a consequence, name servers do not have caches.
- Normally, a name server would expect to receive only those queries to
- which it could respond with authoritative information. However, if a
-
-
-
-Austein & Saperia [Page 3]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- name server receives a query that it cannot respond to with purely
- authoritative information, it may choose to try to obtain the
- necessary additional information from a resolver which may or may not
- be a separate process.
-
-3.3. Selected Objects
-
- Many of the objects included in this memo have been created from
- information contained in the DNS specifications [1,2], as amended and
- clarified by subsequent host requirements documents [3]. Other
- objects have been created based on experience with existing DNS
- management tools, expected operational needs, the statistics
- generated by existing DNS implementations, and the configuration
- files used by existing DNS implementations. These objects have been
- ordered into groups as follows:
-
- o Resolver Configuration Group
-
- o Resolver Counter Group
-
- o Resolver Lame Delegation Group
-
- o Resolver Cache Group
-
- o Resolver Negative Cache Group
-
- o Resolver Optional Counter Group
-
- This information has been converted into a standard form using the
- SNMPv2 SMI defined in [9]. For the most part, the descriptions are
- influenced by the DNS related RFCs noted above. For example, the
- descriptions for counters used for the various types of queries of
- DNS records are influenced by the definitions used for the various
- record types found in [2].
-
-3.4. Textual Conventions
-
- Several conceptual data types have been introduced as a textual
- conventions in the DNS Server MIB document and have been imported
- into this MIB module. These additions will facilitate the common
- understanding of information used by the DNS. No changes to the SMI
- or the SNMP are necessary to support these conventions.
-
- Readers familiar with MIBs designed to manage entities in the lower
- layers of the Internet protocol suite may be surprised at the number
- of non-enumerated integers used in this MIB to represent values such
- as DNS RR class and type numbers. The reason for this choice is
- simple: the DNS itself is designed as an extensible protocol,
-
-
-
-Austein & Saperia [Page 4]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- allowing new classes and types of resource records to be added to the
- protocol without recoding the core DNS software. Using non-
- enumerated integers to represent these data types in this MIB allows
- the MIB to accommodate these changes as well.
-
-4. Definitions
-
- DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN
-
- IMPORTS
- MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32
- FROM SNMPv2-SMI
- TEXTUAL-CONVENTION, RowStatus, DisplayString
- FROM SNMPv2-TC
- MODULE-COMPLIANCE, OBJECT-GROUP
- FROM SNMPv2-CONF
- dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass,
- DnsQType, DnsTime, DnsOpCode, DnsRespCode
- FROM DNS-SERVER-MIB;
-
- -- DNS Resolver MIB
-
- dnsResMIB MODULE-IDENTITY
- LAST-UPDATED "9401282250Z"
- ORGANIZATION "IETF DNS Working Group"
- CONTACT-INFO
- " Rob Austein
- Postal: Epilogue Technology Corporation
- 268 Main Street, Suite 283
- North Reading, MA 10864
- US
- Tel: +1 617 245 0804
- Fax: +1 617 245 8122
- E-Mail: sra@epilogue.com
-
- Jon Saperia
- Postal: Digital Equipment Corporation
- 110 Spit Brook Road
- ZKO1-3/H18
- Nashua, NH 03062-2698
- US
- Tel: +1 603 881 0480
- Fax: +1 603 881 0120
- E-mail: saperia@zko.dec.com"
- DESCRIPTION
- "The MIB module for entities implementing the client
- (resolver) side of the Domain Name System (DNS)
- protocol."
-
-
-
-Austein & Saperia [Page 5]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- ::= { dns 2 }
-
- dnsResMIBObjects OBJECT IDENTIFIER ::= { dnsResMIB 1 }
-
- -- (Old-style) groups in the DNS resolver MIB.
-
- dnsResConfig OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 }
- dnsResCounter OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 }
- dnsResLameDelegation OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 }
- dnsResCache OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 }
- dnsResNCache OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 }
- dnsResOptCounter OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 }
-
-
- -- Resolver Configuration Group
-
- dnsResConfigImplementIdent OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The implementation identification string for the
- resolver software in use on the system, for example;
- `RES-2.1'"
- ::= { dnsResConfig 1 }
-
- dnsResConfigService OBJECT-TYPE
- SYNTAX INTEGER { recursiveOnly(1),
- iterativeOnly(2),
- recursiveAndIterative(3) }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Kind of DNS resolution service provided:
-
- recursiveOnly(1) indicates a stub resolver.
-
- iterativeOnly(2) indicates a normal full service
- resolver.
-
- recursiveAndIterative(3) indicates a full-service
- resolver which performs a mix of recursive and iterative
- queries."
- ::= { dnsResConfig 2 }
-
- dnsResConfigMaxCnames OBJECT-TYPE
- SYNTAX INTEGER (0..2147483647)
- MAX-ACCESS read-write
-
-
-
-Austein & Saperia [Page 6]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- STATUS current
- DESCRIPTION
- "Limit on how many CNAMEs the resolver should allow
- before deciding that there's a CNAME loop. Zero means
- that resolver has no explicit CNAME limit."
- REFERENCE
- "RFC-1035 section 7.1."
- ::= { dnsResConfig 3 }
-
- -- DNS Resolver Safety Belt Table
-
- dnsResConfigSbeltTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsResConfigSbeltEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of safety belt information used by the resolver
- when it hasn't got any better idea of where to send a
- query, such as when the resolver is booting or is a stub
- resolver."
- ::= { dnsResConfig 4 }
-
- dnsResConfigSbeltEntry OBJECT-TYPE
- SYNTAX DnsResConfigSbeltEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry in the resolver's Sbelt table.
- Rows may be created or deleted at any time by the DNS
- resolver and by SNMP SET requests. Whether the values
- changed via SNMP are saved in stable storage across
- `reset' operations is implementation-specific."
- INDEX { dnsResConfigSbeltAddr,
- dnsResConfigSbeltSubTree,
- dnsResConfigSbeltClass }
- ::= { dnsResConfigSbeltTable 1 }
-
- DnsResConfigSbeltEntry ::=
- SEQUENCE {
- dnsResConfigSbeltAddr
- IpAddress,
- dnsResConfigSbeltName
- DnsName,
- dnsResConfigSbeltRecursion
- INTEGER,
- dnsResConfigSbeltPref
- INTEGER,
- dnsResConfigSbeltSubTree
-
-
-
-Austein & Saperia [Page 7]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- DnsNameAsIndex,
- dnsResConfigSbeltClass
- DnsClass,
- dnsResConfigSbeltStatus
- RowStatus
- }
-
- dnsResConfigSbeltAddr OBJECT-TYPE
- SYNTAX IpAddress
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The IP address of the Sbelt name server identified by
- this row of the table."
- ::= { dnsResConfigSbeltEntry 1 }
-
- dnsResConfigSbeltName OBJECT-TYPE
- SYNTAX DnsName
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "The DNS name of a Sbelt nameserver identified by this
- row of the table. A zero-length string indicates that
- the name is not known by the resolver."
- ::= { dnsResConfigSbeltEntry 2 }
-
- dnsResConfigSbeltRecursion OBJECT-TYPE
- SYNTAX INTEGER { iterative(1),
- recursive(2),
- recursiveAndIterative(3) }
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "Kind of queries resolver will be sending to the name
- server identified in this row of the table:
-
- iterative(1) indicates that resolver will be directing
- iterative queries to this name server (RD bit turned
- off).
-
- recursive(2) indicates that resolver will be directing
- recursive queries to this name server (RD bit turned
- on).
-
- recursiveAndIterative(3) indicates that the resolver
- will be directing both recursive and iterative queries
- to the server identified in this row of the table."
- ::= { dnsResConfigSbeltEntry 3 }
-
-
-
-Austein & Saperia [Page 8]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResConfigSbeltPref OBJECT-TYPE
- SYNTAX INTEGER (0..2147483647)
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "This value identifies the preference for the name server
- identified in this row of the table. The lower the
- value, the more desirable the resolver considers this
- server."
- ::= { dnsResConfigSbeltEntry 4 }
-
- dnsResConfigSbeltSubTree OBJECT-TYPE
- SYNTAX DnsNameAsIndex
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Queries sent to the name server identified by this row
- of the table are limited to those for names in the name
- subtree identified by this variable. If no such
- limitation applies, the value of this variable is the
- name of the root domain (a DNS name consisting of a
- single zero octet)."
- ::= { dnsResConfigSbeltEntry 5 }
-
- dnsResConfigSbeltClass OBJECT-TYPE
- SYNTAX DnsClass
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The class of DNS queries that will be sent to the server
- identified by this row of the table."
- ::= { dnsResConfigSbeltEntry 6 }
-
- dnsResConfigSbeltStatus OBJECT-TYPE
- SYNTAX RowStatus
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "Row status column for this row of the Sbelt table."
- ::= { dnsResConfigSbeltEntry 7 }
-
- dnsResConfigUpTime OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "If the resolver has a persistent state (e.g., a
- process), this value will be the time elapsed since it
-
-
-
-Austein & Saperia [Page 9]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- started. For software without persistant state, this
- value will be 0."
- ::= { dnsResConfig 5 }
-
- dnsResConfigResetTime OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "If the resolver has a persistent state (e.g., a process)
- and supports a `reset' operation (e.g., can be told to
- re-read configuration files), this value will be the
- time elapsed since the last time the resolver was
- `reset.' For software that does not have persistence or
- does not support a `reset' operation, this value will be
- zero."
- ::= { dnsResConfig 6 }
-
- dnsResConfigReset OBJECT-TYPE
- SYNTAX INTEGER { other(1),
- reset(2),
- initializing(3),
- running(4) }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Status/action object to reinitialize any persistant
- resolver state. When set to reset(2), any persistant
- resolver state (such as a process) is reinitialized as if
- the resolver had just been started. This value will
- never be returned by a read operation. When read, one of
- the following values will be returned:
- other(1) - resolver in some unknown state;
- initializing(3) - resolver (re)initializing;
- running(4) - resolver currently running."
- ::= { dnsResConfig 7 }
-
-
- -- Resolver Counters Group
-
- -- Resolver Counter Table
-
- dnsResCounterByOpcodeTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsResCounterByOpcodeEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of the current count of resolver queries and
-
-
-
-Austein & Saperia [Page 10]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- answers."
- ::= { dnsResCounter 3 }
-
- dnsResCounterByOpcodeEntry OBJECT-TYPE
- SYNTAX DnsResCounterByOpcodeEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Entry in the resolver counter table. Entries are
- indexed by DNS OpCode."
- INDEX { dnsResCounterByOpcodeCode }
- ::= { dnsResCounterByOpcodeTable 1 }
-
- DnsResCounterByOpcodeEntry ::=
- SEQUENCE {
- dnsResCounterByOpcodeCode
- DnsOpCode,
- dnsResCounterByOpcodeQueries
- Counter32,
- dnsResCounterByOpcodeResponses
- Counter32
- }
-
- dnsResCounterByOpcodeCode OBJECT-TYPE
- SYNTAX DnsOpCode
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The index to this table. The OpCodes that have already
- been defined are found in RFC-1035."
- REFERENCE
- "RFC-1035 section 4.1.1."
- ::= { dnsResCounterByOpcodeEntry 1 }
-
- dnsResCounterByOpcodeQueries OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Total number of queries that have sent out by the
- resolver since initialization for the OpCode which is
- the index to this row of the table."
- ::= { dnsResCounterByOpcodeEntry 2 }
-
- dnsResCounterByOpcodeResponses OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
-
-
-
-Austein & Saperia [Page 11]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- DESCRIPTION
- "Total number of responses that have been received by the
- resolver since initialization for the OpCode which is
- the index to this row of the table."
- ::= { dnsResCounterByOpcodeEntry 3 }
-
- -- Resolver Response Code Counter Table
-
- dnsResCounterByRcodeTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsResCounterByRcodeEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of the current count of responses to resolver
- queries."
- ::= { dnsResCounter 4 }
-
- dnsResCounterByRcodeEntry OBJECT-TYPE
- SYNTAX DnsResCounterByRcodeEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Entry in the resolver response table. Entries are
- indexed by DNS response code."
- INDEX { dnsResCounterByRcodeCode }
- ::= { dnsResCounterByRcodeTable 1 }
-
- DnsResCounterByRcodeEntry ::=
- SEQUENCE {
- dnsResCounterByRcodeCode
- DnsRespCode,
- dnsResCounterByRcodeResponses
- Counter32
- }
-
- dnsResCounterByRcodeCode OBJECT-TYPE
- SYNTAX DnsRespCode
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The index to this table. The Response Codes that have
- already been defined are found in RFC-1035."
- REFERENCE
- "RFC-1035 section 4.1.1."
- ::= { dnsResCounterByRcodeEntry 1 }
-
-
-
-
-
-
-Austein & Saperia [Page 12]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResCounterByRcodeResponses OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of responses the resolver has received for the
- response code value which identifies this row of the
- table."
- ::= { dnsResCounterByRcodeEntry 2 }
-
- -- Additional DNS Resolver Counter Objects
-
- dnsResCounterNonAuthDataResps OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests made by the resolver for which a
- non-authoritative answer (cached data) was received."
- ::= { dnsResCounter 5 }
-
- dnsResCounterNonAuthNoDataResps OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests made by the resolver for which a
- non-authoritative answer - no such data response (empty
- answer) was received."
- ::= { dnsResCounter 6 }
-
- dnsResCounterMartians OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of responses received which were received from
- servers that the resolver does not think it asked."
- ::= { dnsResCounter 7 }
-
- dnsResCounterRecdResponses OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of responses received to all queries."
- ::= { dnsResCounter 8 }
-
-
-
-
-Austein & Saperia [Page 13]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResCounterUnparseResps OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of responses received which were unparseable."
- ::= { dnsResCounter 9 }
-
- dnsResCounterFallbacks OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of times the resolver had to fall back to its
- seat belt information."
- ::= { dnsResCounter 10 }
-
-
- -- Lame Delegation Group
-
- dnsResLameDelegationOverflows OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of times the resolver attempted to add an entry
- to the Lame Delegation table but was unable to for some
- reason such as space constraints."
- ::= { dnsResLameDelegation 1 }
-
- -- Lame Delegation Table
-
- dnsResLameDelegationTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsResLameDelegationEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of name servers returning lame delegations.
-
- A lame delegation has occured when a parent zone
- delegates authority for a child zone to a server that
- appears not to think that it is authoritative for the
- child zone in question."
- ::= { dnsResLameDelegation 2 }
-
- dnsResLameDelegationEntry OBJECT-TYPE
- SYNTAX DnsResLameDelegationEntry
- MAX-ACCESS not-accessible
-
-
-
-Austein & Saperia [Page 14]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- STATUS current
- DESCRIPTION
- "Entry in lame delegation table. Only the resolver may
- create rows in this table. SNMP SET requests may be used
- to delete rows."
- INDEX { dnsResLameDelegationSource,
- dnsResLameDelegationName,
- dnsResLameDelegationClass }
- ::= { dnsResLameDelegationTable 1 }
-
- DnsResLameDelegationEntry ::=
- SEQUENCE {
- dnsResLameDelegationSource
- IpAddress,
- dnsResLameDelegationName
- DnsNameAsIndex,
- dnsResLameDelegationClass
- DnsClass,
- dnsResLameDelegationCounts
- Counter32,
- dnsResLameDelegationStatus
- RowStatus
- }
-
- dnsResLameDelegationSource OBJECT-TYPE
- SYNTAX IpAddress
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Source of lame delegation."
- ::= { dnsResLameDelegationEntry 1 }
-
- dnsResLameDelegationName OBJECT-TYPE
- SYNTAX DnsNameAsIndex
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS name for which lame delegation was received."
- ::= { dnsResLameDelegationEntry 2 }
-
- dnsResLameDelegationClass OBJECT-TYPE
- SYNTAX DnsClass
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS class of received lame delegation."
- ::= { dnsResLameDelegationEntry 3 }
-
-
-
-
-Austein & Saperia [Page 15]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResLameDelegationCounts OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "How many times this lame delegation has been received."
- ::= { dnsResLameDelegationEntry 4 }
-
- dnsResLameDelegationStatus OBJECT-TYPE
- SYNTAX RowStatus
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Status column for the lame delegation table. Since only
- the agent (DNS resolver) creates rows in this table, the
- only values that a manager may write to this variable
- are active(1) and destroy(6)."
- ::= { dnsResLameDelegationEntry 5 }
-
-
- -- Resolver Cache Group
-
- dnsResCacheStatus OBJECT-TYPE
- SYNTAX INTEGER { enabled(1), disabled(2), clear(3) }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Status/action for the resolver's cache.
-
- enabled(1) means that the use of the cache is allowed.
- Query operations can return this state.
-
- disabled(2) means that the cache is not being used.
- Query operations can return this state.
-
- Setting this variable to clear(3) deletes the entire
- contents of the resolver's cache, but does not otherwise
- change the resolver's state. The status will retain its
- previous value from before the clear operation (i.e.,
- enabled(1) or disabled(2)). The value of clear(3) can
- NOT be returned by a query operation."
- ::= { dnsResCache 1 }
-
- dnsResCacheMaxTTL OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
-
-
-
-Austein & Saperia [Page 16]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- "Maximum Time-To-Live for RRs in this cache. If the
- resolver does not implement a TTL ceiling, the value of
- this field should be zero."
- ::= { dnsResCache 2 }
-
- dnsResCacheGoodCaches OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of RRs the resolver has cached successfully."
- ::= { dnsResCache 3 }
-
- dnsResCacheBadCaches OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of RRs the resolver has refused to cache because
- they appear to be dangerous or irrelevant. E.g., RRs
- with suspiciously high TTLs, unsolicited root
- information, or that just don't appear to be relevant to
- the question the resolver asked."
- ::= { dnsResCache 4 }
-
- -- Resolver Cache Table
-
- dnsResCacheRRTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsResCacheRREntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "This table contains information about all the resource
- records currently in the resolver's cache."
- ::= { dnsResCache 5 }
-
- dnsResCacheRREntry OBJECT-TYPE
- SYNTAX DnsResCacheRREntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry in the resolvers's cache. Rows may be created
- only by the resolver. SNMP SET requests may be used to
- delete rows."
- INDEX { dnsResCacheRRName,
- dnsResCacheRRClass,
- dnsResCacheRRType,
- dnsResCacheRRIndex }
-
-
-
-Austein & Saperia [Page 17]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- ::= { dnsResCacheRRTable 1 }
-
- DnsResCacheRREntry ::=
- SEQUENCE {
- dnsResCacheRRName
- DnsNameAsIndex,
- dnsResCacheRRClass
- DnsClass,
- dnsResCacheRRType
- DnsType,
- dnsResCacheRRTTL
- DnsTime,
- dnsResCacheRRElapsedTTL
- DnsTime,
- dnsResCacheRRSource
- IpAddress,
- dnsResCacheRRData
- OCTET STRING,
- dnsResCacheRRStatus
- RowStatus,
- dnsResCacheRRIndex
- Integer32,
- dnsResCacheRRPrettyName
- DnsName
- }
-
- dnsResCacheRRName OBJECT-TYPE
- SYNTAX DnsNameAsIndex
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Owner name of the Resource Record in the cache which is
- identified in this row of the table. As described in
- RFC-1034, the owner of the record is the domain name
- were the RR is found."
- REFERENCE
- "RFC-1034 section 3.6."
- ::= { dnsResCacheRREntry 1 }
-
- dnsResCacheRRClass OBJECT-TYPE
- SYNTAX DnsClass
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS class of the Resource Record in the cache which is
- identified in this row of the table."
- ::= { dnsResCacheRREntry 2 }
-
-
-
-
-Austein & Saperia [Page 18]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResCacheRRType OBJECT-TYPE
- SYNTAX DnsType
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS type of the Resource Record in the cache which is
- identified in this row of the table."
- ::= { dnsResCacheRREntry 3 }
-
- dnsResCacheRRTTL OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Time-To-Live of RR in DNS cache. This is the initial
- TTL value which was received with the RR when it was
- originally received."
- ::= { dnsResCacheRREntry 4 }
-
- dnsResCacheRRElapsedTTL OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Elapsed seconds since RR was received."
- ::= { dnsResCacheRREntry 5 }
-
- dnsResCacheRRSource OBJECT-TYPE
- SYNTAX IpAddress
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Host from which RR was received, 0.0.0.0 if unknown."
- ::= { dnsResCacheRREntry 6 }
-
- dnsResCacheRRData OBJECT-TYPE
- SYNTAX OCTET STRING
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "RDATA portion of a cached RR. The value is in the
- format defined for the particular DNS class and type of
- the resource record."
- REFERENCE
- "RFC-1035 section 3.2.1."
- ::= { dnsResCacheRREntry 7 }
-
-
-
-
-
-Austein & Saperia [Page 19]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResCacheRRStatus OBJECT-TYPE
- SYNTAX RowStatus
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Status column for the resolver cache table. Since only
- the agent (DNS resolver) creates rows in this table, the
- only values that a manager may write to this variable
- are active(1) and destroy(6)."
- ::= { dnsResCacheRREntry 8 }
-
- dnsResCacheRRIndex OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A value which makes entries in the table unique when the
- other index values (dnsResCacheRRName,
- dnsResCacheRRClass, and dnsResCacheRRType) do not
- provide a unique index."
- ::= { dnsResCacheRREntry 9 }
-
- dnsResCacheRRPrettyName OBJECT-TYPE
- SYNTAX DnsName
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Name of the RR at this row in the table. This is
- identical to the dnsResCacheRRName variable, except that
- character case is preserved in this variable, per DNS
- conventions."
- REFERENCE
- "RFC-1035 section 2.3.3."
- ::= { dnsResCacheRREntry 10 }
-
- -- Resolver Negative Cache Group
-
- dnsResNCacheStatus OBJECT-TYPE
- SYNTAX INTEGER { enabled(1), disabled(2), clear(3) }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Status/action for the resolver's negative response
- cache.
-
- enabled(1) means that the use of the negative response
- cache is allowed. Query operations can return this
- state.
-
-
-
-Austein & Saperia [Page 20]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- disabled(2) means that the negative response cache is
- not being used. Query operations can return this state.
-
- Setting this variable to clear(3) deletes the entire
- contents of the resolver's negative response cache. The
- status will retain its previous value from before the
- clear operation (i.e., enabled(1) or disabled(2)). The
- value of clear(3) can NOT be returned by a query
- operation."
- ::= { dnsResNCache 1 }
-
- dnsResNCacheMaxTTL OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Maximum Time-To-Live for cached authoritative errors.
- If the resolver does not implement a TTL ceiling, the
- value of this field should be zero."
- ::= { dnsResNCache 2 }
-
- dnsResNCacheGoodNCaches OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of authoritative errors the resolver has cached
- successfully."
- ::= { dnsResNCache 3 }
-
- dnsResNCacheBadNCaches OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of authoritative errors the resolver would have
- liked to cache but was unable to because the appropriate
- SOA RR was not supplied or looked suspicious."
- REFERENCE
- "RFC-1034 section 4.3.4."
- ::= { dnsResNCache 4 }
-
- -- Resolver Negative Cache Table
-
- dnsResNCacheErrTable OBJECT-TYPE
- SYNTAX SEQUENCE OF DnsResNCacheErrEntry
- MAX-ACCESS not-accessible
- STATUS current
-
-
-
-Austein & Saperia [Page 21]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- DESCRIPTION
- "The resolver's negative response cache. This table
- contains information about authoritative errors that
- have been cached by the resolver."
- ::= { dnsResNCache 5 }
-
- dnsResNCacheErrEntry OBJECT-TYPE
- SYNTAX DnsResNCacheErrEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry in the resolver's negative response cache
- table. Only the resolver can create rows. SNMP SET
- requests may be used to delete rows."
- INDEX { dnsResNCacheErrQName,
- dnsResNCacheErrQClass,
- dnsResNCacheErrQType,
- dnsResNCacheErrIndex }
- ::= { dnsResNCacheErrTable 1 }
-
- DnsResNCacheErrEntry ::=
- SEQUENCE {
- dnsResNCacheErrQName
- DnsNameAsIndex,
- dnsResNCacheErrQClass
- DnsQClass,
- dnsResNCacheErrQType
- DnsQType,
- dnsResNCacheErrTTL
- DnsTime,
- dnsResNCacheErrElapsedTTL
- DnsTime,
- dnsResNCacheErrSource
- IpAddress,
- dnsResNCacheErrCode
- INTEGER,
- dnsResNCacheErrStatus
- RowStatus,
- dnsResNCacheErrIndex
- Integer32,
- dnsResNCacheErrPrettyName
- DnsName
- }
-
- dnsResNCacheErrQName OBJECT-TYPE
- SYNTAX DnsNameAsIndex
- MAX-ACCESS not-accessible
- STATUS current
-
-
-
-Austein & Saperia [Page 22]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- DESCRIPTION
- "QNAME associated with a cached authoritative error."
- REFERENCE
- "RFC-1034 section 3.7.1."
- ::= { dnsResNCacheErrEntry 1 }
-
- dnsResNCacheErrQClass OBJECT-TYPE
- SYNTAX DnsQClass
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS QCLASS associated with a cached authoritative
- error."
- ::= { dnsResNCacheErrEntry 2 }
-
- dnsResNCacheErrQType OBJECT-TYPE
- SYNTAX DnsQType
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "DNS QTYPE associated with a cached authoritative error."
- ::= { dnsResNCacheErrEntry 3 }
-
- dnsResNCacheErrTTL OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Time-To-Live of a cached authoritative error at the time
- of the error, it should not be decremented by the number
- of seconds since it was received. This should be the
- TTL as copied from the MINIMUM field of the SOA that
- accompanied the authoritative error, or a smaller value
- if the resolver implements a ceiling on negative
- response cache TTLs."
- REFERENCE
- "RFC-1034 section 4.3.4."
- ::= { dnsResNCacheErrEntry 4 }
-
- dnsResNCacheErrElapsedTTL OBJECT-TYPE
- SYNTAX DnsTime
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Elapsed seconds since authoritative error was received."
- ::= { dnsResNCacheErrEntry 5 }
-
-
-
-
-
-Austein & Saperia [Page 23]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResNCacheErrSource OBJECT-TYPE
- SYNTAX IpAddress
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Host which sent the authoritative error, 0.0.0.0 if
- unknown."
- ::= { dnsResNCacheErrEntry 6 }
-
- dnsResNCacheErrCode OBJECT-TYPE
- SYNTAX INTEGER { nonexistantName(1), noData(2), other(3) }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The authoritative error that has been cached:
-
- nonexistantName(1) indicates an authoritative name error
- (RCODE = 3).
-
- noData(2) indicates an authoritative response with no
- error (RCODE = 0) and no relevant data.
-
- other(3) indicates some other cached authoritative
- error. At present, no such errors are known to exist."
- ::= { dnsResNCacheErrEntry 7 }
-
- dnsResNCacheErrStatus OBJECT-TYPE
- SYNTAX RowStatus
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Status column for the resolver negative response cache
- table. Since only the agent (DNS resolver) creates rows
- in this table, the only values that a manager may write
- to this variable are active(1) and destroy(6)."
- ::= { dnsResNCacheErrEntry 8 }
-
- dnsResNCacheErrIndex OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "A value which makes entries in the table unique when the
- other index values (dnsResNCacheErrQName,
- dnsResNCacheErrQClass, and dnsResNCacheErrQType) do not
- provide a unique index."
- ::= { dnsResNCacheErrEntry 9 }
-
-
-
-
-Austein & Saperia [Page 24]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResNCacheErrPrettyName OBJECT-TYPE
- SYNTAX DnsName
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "QNAME associated with this row in the table. This is
- identical to the dnsResNCacheErrQName variable, except
- that character case is preserved in this variable, per
- DNS conventions."
- REFERENCE
- "RFC-1035 section 2.3.3."
- ::= { dnsResNCacheErrEntry 10 }
-
-
- -- Resolver Optional Counters Group
-
- dnsResOptCounterReferals OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of responses which were received from servers
- redirecting query to another server."
- ::= { dnsResOptCounter 1 }
-
- dnsResOptCounterRetrans OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number requests retransmitted for all reasons."
- ::= { dnsResOptCounter 2 }
-
- dnsResOptCounterNoResponses OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries that were retransmitted because of no
- response."
- ::= { dnsResOptCounter 3 }
-
- dnsResOptCounterRootRetrans OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of queries that were retransmitted that were to
-
-
-
-Austein & Saperia [Page 25]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- root servers."
- ::= { dnsResOptCounter 4 }
-
- dnsResOptCounterInternals OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests internally generated by the
- resolver."
- ::= { dnsResOptCounter 5 }
-
- dnsResOptCounterInternalTimeOuts OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of requests internally generated which timed
- out."
- ::= { dnsResOptCounter 6 }
-
-
- -- SNMPv2 groups.
-
- dnsResMIBGroups OBJECT IDENTIFIER ::= { dnsResMIB 2 }
-
- dnsResConfigGroup OBJECT-GROUP
- OBJECTS { dnsResConfigImplementIdent,
- dnsResConfigService,
- dnsResConfigMaxCnames,
- dnsResConfigSbeltAddr,
- dnsResConfigSbeltName,
- dnsResConfigSbeltRecursion,
- dnsResConfigSbeltPref,
- dnsResConfigSbeltSubTree,
- dnsResConfigSbeltClass,
- dnsResConfigSbeltStatus,
- dnsResConfigUpTime,
- dnsResConfigResetTime }
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic configuration
- information for a DNS resolver implementation."
- ::= { dnsResMIBGroups 1 }
-
- dnsResCounterGroup OBJECT-GROUP
- OBJECTS { dnsResCounterByOpcodeCode,
- dnsResCounterByOpcodeQueries,
-
-
-
-Austein & Saperia [Page 26]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- dnsResCounterByOpcodeResponses,
- dnsResCounterByRcodeCode,
- dnsResCounterByRcodeResponses,
- dnsResCounterNonAuthDataResps,
- dnsResCounterNonAuthNoDataResps,
- dnsResCounterMartians,
- dnsResCounterRecdResponses,
- dnsResCounterUnparseResps,
- dnsResCounterFallbacks }
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic instrumentation
- of a DNS resolver implementation."
- ::= { dnsResMIBGroups 2 }
-
- dnsResLameDelegationGroup OBJECT-GROUP
- OBJECTS { dnsResLameDelegationOverflows,
- dnsResLameDelegationSource,
- dnsResLameDelegationName,
- dnsResLameDelegationClass,
- dnsResLameDelegationCounts,
- dnsResLameDelegationStatus }
- STATUS current
- DESCRIPTION
- "A collection of objects providing instrumentation of
- `lame delegation' failures."
- ::= { dnsResMIBGroups 3 }
-
-
- dnsResCacheGroup OBJECT-GROUP
- OBJECTS { dnsResCacheStatus,
- dnsResCacheMaxTTL,
- dnsResCacheGoodCaches,
- dnsResCacheBadCaches,
- dnsResCacheRRName,
- dnsResCacheRRClass,
- dnsResCacheRRType,
- dnsResCacheRRTTL,
- dnsResCacheRRElapsedTTL,
- dnsResCacheRRSource,
- dnsResCacheRRData,
- dnsResCacheRRStatus,
- dnsResCacheRRIndex,
- dnsResCacheRRPrettyName }
- STATUS current
- DESCRIPTION
- "A collection of objects providing access to and control
- of a DNS resolver's cache."
-
-
-
-Austein & Saperia [Page 27]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- ::= { dnsResMIBGroups 4 }
-
- dnsResNCacheGroup OBJECT-GROUP
- OBJECTS { dnsResNCacheStatus,
- dnsResNCacheMaxTTL,
- dnsResNCacheGoodNCaches,
- dnsResNCacheBadNCaches,
- dnsResNCacheErrQName,
- dnsResNCacheErrQClass,
- dnsResNCacheErrQType,
- dnsResNCacheErrTTL,
- dnsResNCacheErrElapsedTTL,
- dnsResNCacheErrSource,
- dnsResNCacheErrCode,
- dnsResNCacheErrStatus,
- dnsResNCacheErrIndex,
- dnsResNCacheErrPrettyName }
- STATUS current
- DESCRIPTION
- "A collection of objects providing access to and control
- of a DNS resolver's negative response cache."
- ::= { dnsResMIBGroups 5 }
-
- dnsResOptCounterGroup OBJECT-GROUP
- OBJECTS { dnsResOptCounterReferals,
- dnsResOptCounterRetrans,
- dnsResOptCounterNoResponses,
- dnsResOptCounterRootRetrans,
- dnsResOptCounterInternals,
- dnsResOptCounterInternalTimeOuts }
- STATUS current
- DESCRIPTION
- "A collection of objects providing further
- instrumentation applicable to many but not all DNS
- resolvers."
- ::= { dnsResMIBGroups 6 }
-
-
- -- Compliances.
-
- dnsResMIBCompliances OBJECT IDENTIFIER ::= { dnsResMIB 3 }
-
- dnsResMIBCompliance MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "The compliance statement for agents implementing the DNS
- resolver MIB extensions."
- MODULE -- This MIB module
-
-
-
-Austein & Saperia [Page 28]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- MANDATORY-GROUPS { dnsResConfigGroup, dnsResCounterGroup }
- GROUP dnsResCacheGroup
- DESCRIPTION
- "The resolver cache group is mandatory for resolvers that
- implement a cache."
- GROUP dnsResNCacheGroup
- DESCRIPTION
- "The resolver negative cache group is mandatory for
- resolvers that implement a negative response cache."
- GROUP dnsResLameDelegationGroup
- DESCRIPTION
- "The lame delegation group is unconditionally optional."
- GROUP dnsResOptCounterGroup
- DESCRIPTION
- "The optional counters group is unconditionally
- optional."
- OBJECT dnsResConfigMaxCnames
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- OBJECT dnsResConfigSbeltName
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- OBJECT dnsResConfigSbeltRecursion
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- OBJECT dnsResConfigSbeltPref
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- OBJECT dnsResConfigReset
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- OBJECT dnsResCacheStatus
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- OBJECT dnsResCacheMaxTTL
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- OBJECT dnsResNCacheStatus
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
-
-
-
-Austein & Saperia [Page 29]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- OBJECT dnsResNCacheMaxTTL
- MIN-ACCESS read-only
- DESCRIPTION
- "This object need not be writable."
- ::= { dnsResMIBCompliances 1 }
-
- END
-
-5. Acknowledgements
-
- This document is the result of work undertaken the by DNS working
- group. The authors would particularly like to thank the following
- people for their contributions to this document: Philip Almquist,
- Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
- (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
-
-6. References
-
- [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [2] Mockapetris, P., "Domain Names -- Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [3] Braden, R., Editor, "Requirements for Internet Hosts --
- Application and Support, STD 3, RFC 1123, USC/Information
- Sciences Institute, October 1989.
-
- [4] Rose, M., and K. McCloghrie, "Structure and Identification of
- Management Information for TCP/IP-based internets", STD 16, RFC
- 1155, Performance Systems International, Hughes LAN Systems, May
- 1990.
-
- [5] McCloghrie, K., and M. Rose, "Management Information Base for
- Network Management of TCP/IP-based internets", RFC 1156, Hughes
- LAN Systems, Performance Systems International, May 1990.
-
- [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
- Network Management Protocol", STD 15, RFC 1157, SNMP Research,
- Performance Systems International, Performance Systems
- International, MIT Laboratory for Computer Science, May 1990.
-
- [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
- STD 16, RFC 1212, Performance Systems International, Hughes LAN
- Systems, March 1991.
-
-
-
-
-
-Austein & Saperia [Page 30]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
- [8] McCloghrie, K., and M. Rose, "Management Information Base for
- Network Management of TCP/IP-based internets: MIB-II", STD 17,
- RFC 1213, Hughes LAN Systems, Performance Systems International,
- March 1991.
-
- [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
- of Management Information for version 2 of the Simple Network
- Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
- Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
- University, April 1993.
-
- [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
- Conventions for version 2 of the the Simple Network Management
- Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
- Systems, Dover Beach Consulting, Inc., Carnegie Mellon
- University, April 1993.
-
- [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
- "Conformance Statements for version 2 of the the Simple Network
- Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
- Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
- University, April 1993.
-
- [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
- 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
- Trusted Information Systems, Hughes LAN Systems, April 1993.
-
- [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
- Operations for version 2 of the Simple Network Management
- Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
- Systems, Dover Beach Consulting, Inc., Carnegie Mellon
- University, April 1993.
-
- [14] "Information processing systems - Open Systems Interconnection -
- Specification of Abstract Syntax Notation One (ASN.1)",
- International Organization for Standardization, International
- Standard 8824, December 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia [Page 31]
-
-RFC 1612 DNS Resolver MIB May 1994
-
-
-7. Security Considerations
-
- Security issues are not discussed in this memo.
-
-8. Authors' Addresses
-
- Rob Austein
- Epilogue Technology Corporation
- 268 Main Street, Suite 283
- North Reading, MA 01864
- USA
-
- Phone: +1-617-245-0804
- Fax: +1-617-245-8122
- EMail: sra@epilogue.com
-
-
- Jon Saperia
- Digital Equipment Corporation
- 110 Spit Brook Road
- ZKO1-3/H18
- Nashua, NH 03062-2698
- USA
-
- Phone: +1-603-881-0480
- Fax: +1-603-881-0120
- EMail: saperia@zko.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia [Page 32]
-
diff --git a/contrib/bind9/doc/rfc/rfc1706.txt b/contrib/bind9/doc/rfc/rfc1706.txt
deleted file mode 100644
index 5b5d82194aff9..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1706.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group B. Manning
-Request for Comments: 1706 ISI
-Obsoletes: 1637, 1348 R. Colella
-Category: Informational NIST
- October 1994
-
-
- DNS NSAP Resource Records
-
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-Abstract
-
- OSI lower layer protocols, comprising the connectionless network
- protocol (CLNP) and supporting routing protocols, are deployed in
- some parts of the global Internet. Maintenance and debugging of CLNP
- connectivity is greatly aided by support in the Domain Name System
- (DNS) for mapping between names and NSAP addresses.
-
- This document defines the format of one new Resource Record (RR) for
- the DNS for domain name-to-NSAP mapping. The RR may be used with any
- NSAP address format.
-
- NSAP-to-name translation is accomplished through use of the PTR RR
- (see STD 13, RFC 1035 for a description of the PTR RR). This paper
- describes how PTR RRs are used to support this translation.
-
- This document obsoletes RFC 1348 and RFC 1637.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning & Colella [Page 1]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
-1. Introduction
-
- OSI lower layer protocols, comprising the connectionless network
- protocol (CLNP) [5] and supporting routing protocols, are deployed in
- some parts of the global Internet. Maintenance and debugging of CLNP
- connectivity is greatly aided by support in the Domain Name System
- (DNS) [7] [8] for mapping between names and NSAP (network service
- access point) addresses [6] [Note: NSAP and NSAP address are used
- interchangeably throughout this memo].
-
- This document defines the format of one new Resource Record (RR) for
- the DNS for domain name-to-NSAP mapping. The RR may be used with any
- NSAP address format.
-
- NSAP-to-name translation is accomplished through use of the PTR RR
- (see RFC 1035 for a description of the PTR RR). This paper describes
- how PTR RRs are used to support this translation.
-
- This memo assumes that the reader is familiar with the DNS. Some
- familiarity with NSAPs is useful; see [1] or Annex A of [6] for
- additional information.
-
-2. Background
-
- The reason for defining DNS mappings for NSAPs is to support the
- existing CLNP deployment in the Internet. Debugging with CLNP ping
- and traceroute has become more difficult with only numeric NSAPs as
- the scale of deployment has increased. Current debugging is supported
- by maintaining and exchanging a configuration file with name/NSAP
- mappings similar in function to hosts.txt. This suffers from the lack
- of a central coordinator for this file and also from the perspective
- of scaling. The former describes the most serious short-term
- problem. Scaling of a hosts.txt-like solution has well-known long-
- term scaling difficiencies.
-
-3. Scope
-
- The methods defined in this paper are applicable to all NSAP formats.
-
- As a point of reference, there is a distinction between registration
- and publication of addresses. For IP addresses, the IANA is the root
- registration authority and the DNS a publication method. For NSAPs,
- Annex A of the network service definition, ISO8348 [6], describes the
- root registration authority and this memo defines how the DNS is used
- as a publication method.
-
-
-
-
-
-
-Manning & Colella [Page 2]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
-4. Structure of NSAPs
-
- NSAPs are hierarchically structured to allow distributed
- administration and efficient routing. Distributed administration
- permits subdelegated addressing authorities to, as allowed by the
- delegator, further structure the portion of the NSAP space under
- their delegated control. Accomodating this distributed authority
- requires that there be little or no a priori knowledge of the
- structure of NSAPs built into DNS resolvers and servers.
-
- For the purposes of this memo, NSAPs can be thought of as a tree of
- identifiers. The root of the tree is ISO8348 [6], and has as its
- immediately registered subordinates the one-octet Authority and
- Format Identifiers (AFIs) defined there. The size of subsequently-
- defined fields depends on which branch of the tree is taken. The
- depth of the tree varies according to the authority responsible for
- defining subsequent fields.
-
- An example is the authority under which U.S. GOSIP defines NSAPs [2].
- Under the AFI of 47, NIST (National Institute of Standards and
- Technology) obtained a value of 0005 (the AFI of 47 defines the next
- field as being two octets consisting of four BCD digits from the
- International Code Designator space [3]). NIST defined the subsequent
- fields in [2], as shown in Figure 1. The field immediately following
- 0005 is a format identifier for the rest of the U.S. GOSIP NSAP
- structure, with a hex value of 80. Following this is the three-octet
- field, values for which are allocated to network operators; the
- registration authority for this field is delegated to GSA (General
- Services Administration).
-
- The last octet of the NSAP is the NSelector (NSel). In practice, the
- NSAP minus the NSel identifies the CLNP protocol machine on a given
- system, and the NSel identifies the CLNP user. Since there can be
- more than one CLNP user (meaning multiple NSel values for a given
- "base" NSAP), the representation of the NSAP should be CLNP-user
- independent. To achieve this, an NSel value of zero shall be used
- with all NSAP values stored in the DNS. An NSAP with NSel=0
- identifies the network layer itself. It is left to the application
- retrieving the NSAP to determine the appropriate value to use in that
- instance of communication.
-
- When CLNP is used to support TCP and UDP services, the NSel value
- used is the appropriate IP PROTO value as registered with the IANA.
- For "standard" OSI, the selection of NSel values is left as a matter
- of local administration. Administrators of systems that support the
- OSI transport protocol [4] in addition to TCP/UDP must select NSels
- for use by OSI Transport that do not conflict with the IP PROTO
- values.
-
-
-
-Manning & Colella [Page 3]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
- |--------------|
- | <-- IDP --> |
- |--------------|-------------------------------------|
- | AFI | IDI | <-- DSP --> |
- |-----|--------|-------------------------------------|
- | 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel |
- |-----|--------|-----|----|-----|----|-----|----|----|
- octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
- |-----|--------|-----|----|-----|----|-----|----|----|
-
- IDP Initial Domain Part
- AFI Authority and Format Identifier
- IDI Initial Domain Identifier
- DSP Domain Specific Part
- DFI DSP Format Identifier
- AA Administrative Authority
- Rsvd Reserved
- RD Routing Domain Identifier
- Area Area Identifier
- ID System Identifier
- SEL NSAP Selector
-
- Figure 1: GOSIP Version 2 NSAP structure.
-
-
- In the NSAP RRs in Master Files and in the printed text in this memo,
- NSAPs are often represented as a string of "."-separated hex values.
- The values correspond to convenient divisions of the NSAP to make it
- more readable. For example, the "."-separated fields might correspond
- to the NSAP fields as defined by the appropriate authority (RARE,
- U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
- readability. The "."s do not appear in DNS packets and DNS servers
- can ignore them when reading Master Files. For example, a printable
- representation of the first four fields of a U.S. GOSIP NSAP might
- look like
-
- 47.0005.80.005a00
-
- and a full U.S. GOSIP NSAP might appear as
-
- 47.0005.80.005a00.0000.1000.0020.00800a123456.00.
-
- Other NSAP formats have different lengths and different
- administratively defined field widths to accomodate different
- requirements. For more information on NSAP formats in use see RFC
- 1629 [1].
-
-
-
-
-
-Manning & Colella [Page 4]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
-5. The NSAP RR
-
- The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
- (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
- mapping in the DNS using the NSAP RR operates analogously to IP
- address lookup. A query is generated by the resolver requesting an
- NSAP RR for a provided domain name.
-
- NSAP RRs conform to the top level RR format and semantics as defined
- in Section 3.2.1 of 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 = NSAP |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS = IN |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
- * NAME: an owner name, i.e., the name of the node to which this
- resource record pertains.
-
- * TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
-
- * CLASS: two octets containing the RR IN CLASS code of 1.
-
- * TTL: a 32 bit signed integer that specifies the time interval in
- seconds that the resource record may be cached before the source
- of the information should again be consulted. Zero values are
- interpreted to mean that the RR can only be used for the
- transaction in progress, and should not be cached. For example,
- SOA records are always distributed with a zero TTL to prohibit
- caching. Zero values can also be used for extremely volatile data.
-
-
-
-Manning & Colella [Page 5]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
- * RDLENGTH: an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
- * RDATA: a variable length string of octets containing the NSAP.
- The value is the binary encoding of the NSAP as it would appear in
- the CLNP source or destination address field. A typical example of
- such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
- 20 (decimal); "."s have been omitted to emphasize that they don't
- appear in the DNS packets.
-
- 39840f80005a0000000001e13708002010726e00
-
- NSAP RRs cause no additional section processing.
-
-6. NSAP-to-name Mapping Using the PTR RR
-
- The PTR RR is defined in RFC 1035. This RR is typically used under
- the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
-
- Similarly, the PTR RR is used to map from NSAPs to domain names under
- the "NSAP.INT" domain. A domain name is generated from the NSAP
- according to the rules described below. A query is sent by the
- resolver requesting a PTR RR for the provided domain name.
-
- A domain name is generated from an NSAP by reversing the hex nibbles
- of the NSAP, treating each nibble as a separate subdomain, and
- appending the top-level subdomain name "NSAP.INT" to it. For example,
- the domain name used in the reverse lookup for the NSAP
-
- 47.0005.80.005a00.0000.0001.e133.ffffff000162.00
-
- would appear as
-
- 0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
- 0.8.5.0.0.0.7.4.NSAP.INT.
-
- [Implementation note: For sanity's sake user interfaces should be
- designed to allow users to enter NSAPs using their natural order,
- i.e., as they are typically written on paper. Also, arbitrary "."s
- should be allowed (and ignored) on input.]
-
-7. Master File Format
-
- The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
- conforms to Section 5, "Master Files," of RFC 1035. Below are
- examples of the use of these RRs in Master Files to support name-to-
- NSAP and NSAP-to-name mapping.
-
-
-
-
-Manning & Colella [Page 6]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
- The NSAP RR introduces a new hex string format for the RDATA field.
- The format is "0x" (i.e., a zero followed by an 'x' character)
- followed by a variable length string of hex characters (0 to 9, a to
- f). The hex string is case-insensitive. "."s (i.e., periods) may be
- inserted in the hex string anywhere after the "0x" for readability.
- The "."s have no significance other than for readability and are not
- propagated in the protocol (e.g., queries or zone transfers).
-
-
- ;;;;;;
- ;;;;;; Master File for domain nsap.nist.gov.
- ;;;;;;
-
-
- @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
- 1994041800 ; Serial - date
- 1800 ; Refresh - 30 minutes
- 300 ; Retry - 5 minutes
- 604800 ; Expire - 7 days
- 3600 ) ; Minimum - 1 hour
- IN NS emu.ncsl.nist.gov.
- IN NS tuba.nsap.lanl.gov.
- ;
- ;
- $ORIGIN nsap.nist.gov.
- ;
- ; hosts
- ;
- bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
- IN A 129.6.224.161
- IN HINFO PC_486 BSDi1.1
- ;
- bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
- IN A 129.6.224.162
- IN HINFO PC_486 BSDi1.1
- ;
- cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
- IN A 129.6.224.171
- IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA)
- ;
- infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
- IN A 129.6.55.164
- IN HINFO PC/486 BSDi1.0(TUBA)
- ;
- ; routers
- ;
- cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
- IN A 129.6.224.151
-
-
-
-Manning & Colella [Page 7]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
- IN A 129.6.225.151
- IN A 129.6.229.151
- ;
- 3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
- IN A 129.6.224.111
- IN A 129.6.225.111
- IN A 129.6.228.111
-
-
-
-
- ;;;;;;
- ;;;;;; Master File for reverse mapping of NSAPs under the
- ;;;;;; NSAP prefix:
- ;;;;;;
- ;;;;;; 47.0005.80.005a00.0000.0001.e133
- ;;;;;;
-
-
- @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
- 1994041800 ; Serial - date
- 1800 ; Refresh - 30 minutes
- 300 ; Retry - 5 minutes
- 604800 ; Expire - 7 days
- 3600 ) ; Minimum - 1 hour
- IN NS emu.ncsl.nist.gov.
- IN NS tuba.nsap.lanl.gov.
- ;
- ;
- $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
- ;
- 0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov.
- ;
- 0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov.
- ;
- 0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov.
- ;
- 0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov.
- ;
- 0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov.
- ;
- 0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov.
-
-8. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
-
-
-
-Manning & Colella [Page 8]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
-9. Authors' Addresses
-
- Bill Manning
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA. 90292
- USA
-
- Phone: +1.310.822.1511
- EMail: bmanning@isi.edu
-
-
- Richard Colella
- National Institute of Standards and Technology
- Technology/B217
- Gaithersburg, MD 20899
- USA
-
- Phone: +1 301-975-3627
- Fax: +1 301 590-0932
- EMail: colella@nist.gov
-
-10. References
-
- [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
- for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
- Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
- 1994.
-
- [2] GOSIP Advanced Requirements Group. Government Open Systems
- Interconnection Profile (GOSIP) Version 2. Federal Information
- Processing Standard 146-1, U.S. Department of Commerce, National
- Institute of Standards and Technology, Gaithersburg, MD, April
- 1991.
-
- [3] ISO/IEC. Data interchange - structures for the identification of
- organization. International Standard 6523, ISO/IEC JTC 1,
- Switzerland, 1984.
-
- [4] ISO/IEC. Connection oriented transport protocol specification.
- International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
-
- [5] ISO/IEC. Protocol for Providing the Connectionless-mode Network
- Service. International Standard 8473, ISO/IEC JTC 1,
- Switzerland, 1986.
-
-
-
-
-
-
-Manning & Colella [Page 9]
-
-RFC 1706 DNS NSAP RRs October 1994
-
-
- [6] ISO/IEC. Information Processing Systems -- Data Communications --
- Network Service Definition. International Standard 8348, ISO/IEC
- JTC 1, Switzerland, 1993.
-
- [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [8] Mockapetris, P., "Domain Names -- Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning & Colella [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc1712.txt b/contrib/bind9/doc/rfc/rfc1712.txt
deleted file mode 100644
index 40d88578e83fc..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1712.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group C. Farrell
-Request for Comments: 1712 M. Schulze
-Category: Experimental S. Pleitner
- D. Baldoni
- Curtin University of Technology
- November 1994
-
-
- DNS Encoding of Geographical Location
-
-Status of this Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. This memo does not specify an Internet standard of any
- kind. Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-Abstract
-
- This document defines the format of a new Resource Record (RR) for
- the Domain Naming System (DNS), and reserves a corresponding DNS type
- mnemonic and numerical code. This definition deals with associating
- geographical host location mappings to host names within a domain.
- The data shown in this document is fictitious and does not
- necessarily reflect the real Internet.
-
-1. Introduction
-
- It has been a long standing problem to relate IP numbers to
- geographical locations. The availability of Geographical location
- information has immediate applications in network management. Such
- information can be used to supplement the data already provided by
- utilities such as whois [Har85], traceroute [VJ89], and nslookup
- [UCB89]. The usefulness and functionality of these already widely
- used tools would be greatly enhanced by the provision of reliable
- geographical location information.
-
- The ideal way to manage and maintain a database of information, such
- as geographical location of internet hosts, is to delegate
- responsibility to local domain administrators. A large distributed
- database could be implemented with a simple mechanism for updating
- the local information. A query mechanism also has to be available
- for checking local entries, as well as inquiring about data from
- non-local domains.
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni [Page 1]
-
-RFC 1712 DNS Encoding of Geographical Location November 1994
-
-
-2. Background
-
- The Internet continues to grow at an ever increasing rate with IP
- numbers allocated on a first-come-first-serve basis. Deciding when
- and how to setup a database of geographical information about
- internet hosts presented a number of options. The uumap project
- [UU85] was the first serious attempt to collect geographical location
- data from sites and store it centrally. This project met with
- limited success because of the difficulty in maintaining and updating
- a large central database. Another problem was the lack of tools for
- the checking the data supplied, this problem resulted in some
- erroneous data entering the database.
-
-2.1 SNMP:
-
- Using an SNMP get request on the sysLocation MIB (Management
- Information Base) variable was also an option, however this would
- require the host to be running an appropriate agent with public read
- access. It was also felt that MIB data should reflect local
- management data (e.g., "this" host is on level 5 room 74) rather than
- a hosts geographical position. This view is supported in the
- examples given in literature in this area [ROSE91].
-
-2.2 X500:
-
- The X.500 Directory service [X.500.88] defined as part of the ISO
- standards also appears as a potential provider of geographical
- location data. However due to the limited implementations of this
- service it was decided to defer this until this service gains wider
- use and acceptance within the Internet community.
-
-2.3 BIND:
-
- The DNS [Mock87a][Mock87b] represents an existing system ideally
- suited to the provision of host specific information. The DNS is a
- widely used and well-understood mechanism for providing a distributed
- database of such information and its extensible nature allows it to
- be used to disseminate virtually any information. The most commonly
- used DNS implementation is the Berkeley Internet Name Domain server
- BIND [UCB89]. The information we wished to make available needed to
- be updated locally but available globally; a perfect match with the
- services provided by the DNS. Current DNS servers provide a variety
- of useful information about hosts in their domain but lack the
- ability to report a host's geographical location.
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni [Page 2]
-
-RFC 1712 DNS Encoding of Geographical Location November 1994
-
-
-3. RDATA Format
-
- MSB LSB
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / LONGITUDE /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / LATITUDE /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / ALTITUDE /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
- LONGITUDE The real number describing the longitude encoded as a
- printable string. The precision is limited by 256 charcters
- within the range -90..90 degrees. Positive numbers
- indicate locations north of the equator.
-
- LATITUDE The real number describing the latitude encoded as a
- printable string. The precision is limited by 256 charcters
- within the range -180..180 degrees. Positive numbers
- indicate locations east of the prime meridian.
-
- ALTITUDE The real number describing the altitude (in meters) from
- mean sea-level encoded as a printable string. The precision
- is limited by 256 charcters. Positive numbers indicate
- locations above mean sea-level.
-
- Latitude/Longitude/Altitude values are encoded as strings as to avoid
- the precision limitations imposed by encoding as unsigned integers.
- Although this might not be considered optimal, it allows for a very
- high degree of precision with an acceptable average encoded record
- length.
-
-4. The GPOS RR
-
- The geographical location is defined with the mnemonic GPOS and type
- code 27.
-
- GPOS has the following format:
- <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
-
- A floating point format was chosen to specify geographical locations
- for reasons of simplicity. This also guarantees a concise
- unambiguous description of a location by enforcing three compulsory
- numerical values to be specified.
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni [Page 3]
-
-RFC 1712 DNS Encoding of Geographical Location November 1994
-
-
- The owner, ttl, and class fields are optional and default to the last
- defined value if omitted. The longitude is a floating point number
- ranging from -90 to 90 with positive values indicating locations
- north of the equator. For example Perth, Western Australia is
- located at 32^ 7` 19" south of the equator which would be specified
- as -32.68820. The latitude is a number ranging from -180.0 to 180.0.
- For example Perth, Western Australia is located at 116^ 2' 25" east
- of the prime meridian which would be specified as 116.86520. Curtin
- University, Perth is also 10 meters above sea-level.
-
- The valid GPOS record for a host at Curtin University in Perth
- Western Australia would therefore be:
-
- GPOS -32.6882 116.8652 10.0
-
- There is no limit imposed on the number of decimal places, although
- the length of the encoded string is limited to 256 characters for
- each field. It is also suggested that administrators limit their
- entries to the minimum number of necessary characters in each field.
-
-5. Master File Format
-
- Each host requires its own GPOS field in the corresponding DNS RR to
- explicitly specify its geographical location and altitude. If the
- GPOS field is omitted, a DNS enquiry will return no position
- information for that host.
-
- Consider the following example:
-
-; Authoritative data for cs.curtin.edu.au.
-;
-@ IN SOA marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
- (
- 94070503 ; Serial (yymmddnn)
- 10800 ; Refresh (3 hours)
- 3600 ; Retry (1 hour)
- 3600000 ; Expire (1000 hours)
- 86400 ; Minimum (24 hours)
- )
-
- IN NS marsh.cs.curtin.edu.au.
-
-marsh IN A 134.7.1.1
- IN MX 0 marsh
- IN HINFO SGI-Indigo IRIX-4.0.5F
- IN GPOS -32.6882 116.8652 10.0
-ftp IN CNAME marsh
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni [Page 4]
-
-RFC 1712 DNS Encoding of Geographical Location November 1994
-
-
-lillee IN A 134.7.1.2
- IN MX 0 marsh
- IN HINFO SGI-Indigo IRIX-4.0.5F
- IN GPOS -32.6882 116.8652 10.0
-
-hinault IN A 134.7.1.23
- IN MX 0 marsh
- IN HINFO SUN-IPC SunOS-4.1.3
- IN GPOS -22.6882 116.8652 250.0
-
-merckx IN A 134.7.1.24
- IN MX 0 marsh
- IN HINFO SUN-IPC SunOS-4.1.1
-
-ambrose IN A 134.7.1.99
- IN MX 0 marsh
- IN HINFO SGI-CHALLENGE_L IRIX-5.2
- IN GPOS -32.6882 116.8652 10.0
-
- The hosts marsh, lillee, and ambrose are all at the same geographical
- location, Perth Western Australia (-32.68820 116.86520). The host
- hinault is at a different geographical location, 10 degrees north of
- Perth in the mountains (-22.6882 116.8652 250.0). For security
- reasons we do not wish to give the location of the host merckx.
-
- Although the GPOS clause is not a standard entry within BIND
- configuration files, most vendor implementations seem to ignore
- whatever is not understood upon startup of the DNS. Usually this
- will result in a number of warnings appearing in system log files,
- but in no way alters naming information or impedes the DNS from
- performing its normal duties.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni [Page 5]
-
-RFC 1712 DNS Encoding of Geographical Location November 1994
-
-
-7. References
-
- [ROSE91] Rose M., "The Simple Book: An Introduction to
- Management of TCP/IP-based Internets", Prentice-Hall,
- Englewood Cliffs, New Jersey, 1991.
-
- [X.500.88] CCITT: The Directory - Overview of Concepts, Models
- and Services", Recommendations X.500 - X.521.
-
- [Har82] Harrenstein K, Stahl M., and E. Feinler,
- "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
-
- [Mock87a] Mockapetris P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, USC/Information
- Sciences Institute, November 1987.
-
- [Mock87b] Mockapetris P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, USC/Information
- Sciences Institute, November 1987.
-
- [FRB93] Ford P., Rekhter Y., and H-W. Braun, "Improving the
- Routing and Addressing of IP", IEEE Network
- Vol.7, No. 3, pp. 11-15, May 1993.
-
- [VJ89] Jacobsen V., "The Traceroute(8) Manual Page",
- Lawrence Berkeley Laboratory, Berkeley,
- CA, February 1989.
-
- [UCB89] University of California, "BIND: Berkeley Internet
- Name Domain Server", 1989.
- [UU85] UUCP Mapping Project, Software available via
- anonymous FTP from ftp.uu.net., 1985.
-
-8. Security Considerations
-
- Once information has been entered into the DNS, it is considered
- public.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni [Page 6]
-
-RFC 1712 DNS Encoding of Geographical Location November 1994
-
-
-9. Authors' Addresses
-
- Craig Farrell
- Department of Computer Science
- Curtin University of technology
- GPO Box U1987 Perth,
- Western Australia
-
- EMail: craig@cs.curtin.edu.au
-
-
- Mike Schulze
- Department of Computer Science
- Curtin University of technology
- GPO Box U1987 Perth,
- Western Australia
-
- EMail: mike@cs.curtin.edu.au
-
-
- Scott Pleitner
- Department of Computer Science
- Curtin University of technology
- GPO Box U1987 Perth,
- Western Australia
-
- EMail: pleitner@cs.curtin.edu.au
-
-
- Daniel Baldoni
- Department of Computer Science
- Curtin University of technology
- GPO Box U1987 Perth,
- Western Australia
-
- EMail: flint@cs.curtin.edu.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc1750.txt b/contrib/bind9/doc/rfc/rfc1750.txt
deleted file mode 100644
index 56d478c7eef42..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1750.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake, 3rd
-Request for Comments: 1750 DEC
-Category: Informational S. Crocker
- Cybercash
- J. Schiller
- MIT
- December 1994
-
-
- Randomness Recommendations for Security
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-Abstract
-
- Security systems today are built on increasingly strong cryptographic
- algorithms that foil pattern analysis attempts. However, the security
- of these systems is dependent on generating secret quantities for
- passwords, cryptographic keys, and similar quantities. The use of
- pseudo-random processes to generate secret quantities can result in
- pseudo-security. The sophisticated attacker of these security
- systems may find it easier to reproduce the environment that produced
- the secret quantities, searching the resulting small set of
- possibilities, than to locate the quantities in the whole of the
- number space.
-
- Choosing random quantities to foil a resourceful and motivated
- adversary is surprisingly difficult. This paper points out many
- pitfalls in using traditional pseudo-random number generation
- techniques for choosing such quantities. It recommends the use of
- truly random hardware techniques and shows that the existing hardware
- on many systems can be used for this purpose. It provides
- suggestions to ameliorate the problem when a hardware solution is not
- available. And it gives examples of how large such quantities need
- to be for some particular applications.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 1]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-Acknowledgements
-
- Comments on this document that have been incorporated were received
- from (in alphabetic order) the following:
-
- David M. Balenson (TIS)
- Don Coppersmith (IBM)
- Don T. Davis (consultant)
- Carl Ellison (Stratus)
- Marc Horowitz (MIT)
- Christian Huitema (INRIA)
- Charlie Kaufman (IRIS)
- Steve Kent (BBN)
- Hal Murray (DEC)
- Neil Haller (Bellcore)
- Richard Pitkin (DEC)
- Tim Redmond (TIS)
- Doug Tygar (CMU)
-
-Table of Contents
-
- 1. Introduction........................................... 3
- 2. Requirements........................................... 4
- 3. Traditional Pseudo-Random Sequences.................... 5
- 4. Unpredictability....................................... 7
- 4.1 Problems with Clocks and Serial Numbers............... 7
- 4.2 Timing and Content of External Events................ 8
- 4.3 The Fallacy of Complex Manipulation.................. 8
- 4.4 The Fallacy of Selection from a Large Database....... 9
- 5. Hardware for Randomness............................... 10
- 5.1 Volume Required...................................... 10
- 5.2 Sensitivity to Skew.................................. 10
- 5.2.1 Using Stream Parity to De-Skew..................... 11
- 5.2.2 Using Transition Mappings to De-Skew............... 12
- 5.2.3 Using FFT to De-Skew............................... 13
- 5.2.4 Using Compression to De-Skew....................... 13
- 5.3 Existing Hardware Can Be Used For Randomness......... 14
- 5.3.1 Using Existing Sound/Video Input................... 14
- 5.3.2 Using Existing Disk Drives......................... 14
- 6. Recommended Non-Hardware Strategy..................... 14
- 6.1 Mixing Functions..................................... 15
- 6.1.1 A Trivial Mixing Function.......................... 15
- 6.1.2 Stronger Mixing Functions.......................... 16
- 6.1.3 Diff-Hellman as a Mixing Function.................. 17
- 6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
- 6.1.5 Other Factors in Choosing a Mixing Function........ 18
- 6.2 Non-Hardware Sources of Randomness................... 19
- 6.3 Cryptographically Strong Sequences................... 19
-
-
-
-Eastlake, Crocker & Schiller [Page 2]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- 6.3.1 Traditional Strong Sequences....................... 20
- 6.3.2 The Blum Blum Shub Sequence Generator.............. 21
- 7. Key Generation Standards.............................. 22
- 7.1 US DoD Recommendations for Password Generation....... 23
- 7.2 X9.17 Key Generation................................. 23
- 8. Examples of Randomness Required....................... 24
- 8.1 Password Generation................................. 24
- 8.2 A Very High Security Cryptographic Key............... 25
- 8.2.1 Effort per Key Trial............................... 25
- 8.2.2 Meet in the Middle Attacks......................... 26
- 8.2.3 Other Considerations............................... 26
- 9. Conclusion............................................ 27
- 10. Security Considerations.............................. 27
- References............................................... 28
- Authors' Addresses....................................... 30
-
-1. Introduction
-
- Software cryptography is coming into wider use. Systems like
- Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
- network landscape [PEM]. These systems provide substantial
- protection against snooping and spoofing. However, there is a
- potential flaw. At the heart of all cryptographic systems is the
- generation of secret, unguessable (i.e., random) numbers.
-
- For the present, the lack of generally available facilities for
- generating such unpredictable numbers is an open wound in the design
- of cryptographic software. For the software developer who wants to
- build a key or password generation procedure that runs on a wide
- range of hardware, the only safe strategy so far has been to force
- the local installation to supply a suitable routine to generate
- random numbers. To say the least, this is an awkward, error-prone
- and unpalatable solution.
-
- It is important to keep in mind that the requirement is for data that
- an adversary has a very low probability of guessing or determining.
- This will fail if pseudo-random data is used which only meets
- traditional statistical tests for randomness or which is based on
- limited range sources, such as clocks. Frequently such random
- quantities are determinable by an adversary searching through an
- embarrassingly small space of possibilities.
-
- This informational document suggests techniques for producing random
- quantities that will be resistant to such attack. It recommends that
- future systems include hardware random number generation or provide
- access to existing hardware that can be used for this purpose. It
- suggests methods for use if such hardware is not available. And it
- gives some estimates of the number of random bits required for sample
-
-
-
-Eastlake, Crocker & Schiller [Page 3]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- applications.
-
-2. Requirements
-
- Probably the most commonly encountered randomness requirement today
- is the user password. This is usually a simple character string.
- Obviously, if a password can be guessed, it does not provide
- security. (For re-usable passwords, it is desirable that users be
- able to remember the password. This may make it advisable to use
- pronounceable character strings or phrases composed on ordinary
- words. But this only affects the format of the password information,
- not the requirement that the password be very hard to guess.)
-
- Many other requirements come from the cryptographic arena.
- Cryptographic techniques can be used to provide a variety of services
- including confidentiality and authentication. Such services are
- based on quantities, traditionally called "keys", that are unknown to
- and unguessable by an adversary.
-
- In some cases, such as the use of symmetric encryption with the one
- time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
- parties who wish to communicate confidentially and/or with
- authentication must all know the same secret key. In other cases,
- using what are called asymmetric or "public key" cryptographic
- techniques, keys come in pairs. One key of the pair is private and
- must be kept secret by one party, the other is public and can be
- published to the world. It is computationally infeasible to
- determine the private key from the public key [ASYMMETRIC, CRYPTO*].
-
- The frequency and volume of the requirement for random quantities
- differs greatly for different cryptographic systems. Using pure RSA
- [CRYPTO*], random quantities are required when the key pair is
- generated, but thereafter any number of messages can be signed
- without any further need for randomness. The public key Digital
- Signature Algorithm that has been proposed by the US National
- Institute of Standards and Technology (NIST) requires good random
- numbers for each signature. And encrypting with a one time pad, in
- principle the strongest possible encryption technique, requires a
- volume of randomness equal to all the messages to be processed.
-
- In most of these cases, an adversary can try to determine the
- "secret" key by trial and error. (This is possible as long as the
- key is enough smaller than the message that the correct key can be
- uniquely identified.) The probability of an adversary succeeding at
- this must be made acceptably low, depending on the particular
- application. The size of the space the adversary must search is
- related to the amount of key "information" present in the information
- theoretic sense [SHANNON]. This depends on the number of different
-
-
-
-Eastlake, Crocker & Schiller [Page 4]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- secret values possible and the probability of each value as follows:
-
- -----
- \
- Bits-of-info = \ - p * log ( p )
- / i 2 i
- /
- -----
-
- where i varies from 1 to the number of possible secret values and p
- sub i is the probability of the value numbered i. (Since p sub i is
- less than one, the log will be negative so each term in the sum will
- be non-negative.)
-
- If there are 2^n different values of equal probability, then n bits
- of information are present and an adversary would, on the average,
- have to try half of the values, or 2^(n-1) , before guessing the
- secret quantity. If the probability of different values is unequal,
- then there is less information present and fewer guesses will, on
- average, be required by an adversary. In particular, any values that
- the adversary can know are impossible, or are of low probability, can
- be initially ignored by an adversary, who will search through the
- more probable values first.
-
- For example, consider a cryptographic system that uses 56 bit keys.
- If these 56 bit keys are derived by using a fixed pseudo-random
- number generator that is seeded with an 8 bit seed, then an adversary
- needs to search through only 256 keys (by running the pseudo-random
- number generator with every possible seed), not the 2^56 keys that
- may at first appear to be the case. Only 8 bits of "information" are
- in these 56 bit keys.
-
-3. Traditional Pseudo-Random Sequences
-
- Most traditional sources of random numbers use deterministic sources
- of "pseudo-random" numbers. These typically start with a "seed"
- quantity and use numeric or logical operations to produce a sequence
- of values.
-
- [KNUTH] has a classic exposition on pseudo-random numbers.
- Applications he mentions are simulation of natural phenomena,
- sampling, numerical analysis, testing computer programs, decision
- making, and games. None of these have the same characteristics as
- the sort of security uses we are talking about. Only in the last two
- could there be an adversary trying to find the random quantity.
- However, in these cases, the adversary normally has only a single
- chance to use a guessed value. In guessing passwords or attempting
- to break an encryption scheme, the adversary normally has many,
-
-
-
-Eastlake, Crocker & Schiller [Page 5]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- perhaps unlimited, chances at guessing the correct value and should
- be assumed to be aided by a computer.
-
- For testing the "randomness" of numbers, Knuth suggests a variety of
- measures including statistical and spectral. These tests check
- things like autocorrelation between different parts of a "random"
- sequence or distribution of its values. They could be met by a
- constant stored random sequence, such as the "random" sequence
- printed in the CRC Standard Mathematical Tables [CRC].
-
- A typical pseudo-random number generation technique, known as a
- linear congruence pseudo-random number generator, is modular
- arithmetic where the N+1th value is calculated from the Nth value by
-
- V = ( V * a + b )(Mod c)
- N+1 N
-
- The above technique has a strong relationship to linear shift
- register pseudo-random number generators, which are well understood
- cryptographically [SHIFT*]. In such generators bits are introduced
- at one end of a shift register as the Exclusive Or (binary sum
- without carry) of bits from selected fixed taps into the register.
-
- For example:
-
- +----+ +----+ +----+ +----+
- | B | <-- | B | <-- | B | <-- . . . . . . <-- | B | <-+
- | 0 | | 1 | | 2 | | n | |
- +----+ +----+ +----+ +----+ |
- | | | |
- | | V +-----+
- | V +----------------> | |
- V +-----------------------------> | XOR |
- +---------------------------------------------------> | |
- +-----+
-
-
- V = ( ( V * 2 ) + B .xor. B ... )(Mod 2^n)
- N+1 N 0 2
-
- The goodness of traditional pseudo-random number generator algorithms
- is measured by statistical tests on such sequences. Carefully chosen
- values of the initial V and a, b, and c or the placement of shift
- register tap in the above simple processes can produce excellent
- statistics.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 6]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- These sequences may be adequate in simulations (Monte Carlo
- experiments) as long as the sequence is orthogonal to the structure
- of the space being explored. Even there, subtle patterns may cause
- problems. However, such sequences are clearly bad for use in
- security applications. They are fully predictable if the initial
- state is known. Depending on the form of the pseudo-random number
- generator, the sequence may be determinable from observation of a
- short portion of the sequence [CRYPTO*, STERN]. For example, with
- the generators above, one can determine V(n+1) given knowledge of
- V(n). In fact, it has been shown that with these techniques, even if
- only one bit of the pseudo-random values is released, the seed can be
- determined from short sequences.
-
- Not only have linear congruent generators been broken, but techniques
- are now known for breaking all polynomial congruent generators
- [KRAWCZYK].
-
-4. Unpredictability
-
- Randomness in the traditional sense described in section 3 is NOT the
- same as the unpredictability required for security use.
-
- For example, use of a widely available constant sequence, such as
- that from the CRC tables, is very weak against an adversary. Once
- they learn of or guess it, they can easily break all security, future
- and past, based on the sequence [CRC]. Yet the statistical
- properties of these tables are good.
-
- The following sections describe the limitations of some randomness
- generation techniques and sources.
-
-4.1 Problems with Clocks and Serial Numbers
-
- Computer clocks, or similar operating system or hardware values,
- provide significantly fewer real bits of unpredictability than might
- appear from their specifications.
-
- Tests have been done on clocks on numerous systems and it was found
- that their behavior can vary widely and in unexpected ways. One
- version of an operating system running on one set of hardware may
- actually provide, say, microsecond resolution in a clock while a
- different configuration of the "same" system may always provide the
- same lower bits and only count in the upper bits at much lower
- resolution. This means that successive reads on the clock may
- produce identical values even if enough time has passed that the
- value "should" change based on the nominal clock resolution. There
- are also cases where frequently reading a clock can produce
- artificial sequential values because of extra code that checks for
-
-
-
-Eastlake, Crocker & Schiller [Page 7]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- the clock being unchanged between two reads and increases it by one!
- Designing portable application code to generate unpredictable numbers
- based on such system clocks is particularly challenging because the
- system designer does not always know the properties of the system
- clocks that the code will execute on.
-
- Use of a hardware serial number such as an Ethernet address may also
- provide fewer bits of uniqueness than one would guess. Such
- quantities are usually heavily structured and subfields may have only
- a limited range of possible values or values easily guessable based
- on approximate date of manufacture or other data. For example, it is
- likely that most of the Ethernet cards installed on Digital Equipment
- Corporation (DEC) hardware within DEC were manufactured by DEC
- itself, which significantly limits the range of built in addresses.
-
- Problems such as those described above related to clocks and serial
- numbers make code to produce unpredictable quantities difficult if
- the code is to be ported across a variety of computer platforms and
- systems.
-
-4.2 Timing and Content of External Events
-
- It is possible to measure the timing and content of mouse movement,
- key strokes, and similar user events. This is a reasonable source of
- unguessable data with some qualifications. On some machines, inputs
- such as key strokes are buffered. Even though the user's inter-
- keystroke timing may have sufficient variation and unpredictability,
- there might not be an easy way to access that variation. Another
- problem is that no standard method exists to sample timing details.
- This makes it hard to build standard software intended for
- distribution to a large range of machines based on this technique.
-
- The amount of mouse movement or the keys actually hit are usually
- easier to access than timings but may yield less unpredictability as
- the user may provide highly repetitive input.
-
- Other external events, such as network packet arrival times, can also
- be used with care. In particular, the possibility of manipulation of
- such times by an adversary must be considered.
-
-4.3 The Fallacy of Complex Manipulation
-
- One strategy which may give a misleading appearance of
- unpredictability is to take a very complex algorithm (or an excellent
- traditional pseudo-random number generator with good statistical
- properties) and calculate a cryptographic key by starting with the
- current value of a computer system clock as the seed. An adversary
- who knew roughly when the generator was started would have a
-
-
-
-Eastlake, Crocker & Schiller [Page 8]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- relatively small number of seed values to test as they would know
- likely values of the system clock. Large numbers of pseudo-random
- bits could be generated but the search space an adversary would need
- to check could be quite small.
-
- Thus very strong and/or complex manipulation of data will not help if
- the adversary can learn what the manipulation is and there is not
- enough unpredictability in the starting seed value. Even if they can
- not learn what the manipulation is, they may be able to use the
- limited number of results stemming from a limited number of seed
- values to defeat security.
-
- Another serious strategy error is to assume that a very complex
- pseudo-random number generation algorithm will produce strong random
- numbers when there has been no theory behind or analysis of the
- algorithm. There is a excellent example of this fallacy right near
- the beginning of chapter 3 in [KNUTH] where the author describes a
- complex algorithm. It was intended that the machine language program
- corresponding to the algorithm would be so complicated that a person
- trying to read the code without comments wouldn't know what the
- program was doing. Unfortunately, actual use of this algorithm
- showed that it almost immediately converged to a single repeated
- value in one case and a small cycle of values in another case.
-
- Not only does complex manipulation not help you if you have a limited
- range of seeds but blindly chosen complex manipulation can destroy
- the randomness in a good seed!
-
-4.4 The Fallacy of Selection from a Large Database
-
- Another strategy that can give a misleading appearance of
- unpredictability is selection of a quantity randomly from a database
- and assume that its strength is related to the total number of bits
- in the database. For example, typical USENET servers as of this date
- process over 35 megabytes of information per day. Assume a random
- quantity was selected by fetching 32 bytes of data from a random
- starting point in this data. This does not yield 32*8 = 256 bits
- worth of unguessability. Even after allowing that much of the data
- is human language and probably has more like 2 or 3 bits of
- information per byte, it doesn't yield 32*2.5 = 80 bits of
- unguessability. For an adversary with access to the same 35
- megabytes the unguessability rests only on the starting point of the
- selection. That is, at best, about 25 bits of unguessability in this
- case.
-
- The same argument applies to selecting sequences from the data on a
- CD ROM or Audio CD recording or any other large public database. If
- the adversary has access to the same database, this "selection from a
-
-
-
-Eastlake, Crocker & Schiller [Page 9]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- large volume of data" step buys very little. However, if a selection
- can be made from data to which the adversary has no access, such as
- system buffers on an active multi-user system, it may be of some
- help.
-
-5. Hardware for Randomness
-
- Is there any hope for strong portable randomness in the future?
- There might be. All that's needed is a physical source of
- unpredictable numbers.
-
- A thermal noise or radioactive decay source and a fast, free-running
- oscillator would do the trick directly [GIFFORD]. This is a trivial
- amount of hardware, and could easily be included as a standard part
- of a computer system's architecture. Furthermore, any system with a
- spinning disk or the like has an adequate source of randomness
- [DAVIS]. All that's needed is the common perception among computer
- vendors that this small additional hardware and the software to
- access it is necessary and useful.
-
-5.1 Volume Required
-
- How much unpredictability is needed? Is it possible to quantify the
- requirement in, say, number of random bits per second?
-
- The answer is not very much is needed. For DES, the key is 56 bits
- and, as we show in an example in Section 8, even the highest security
- system is unlikely to require a keying material of over 200 bits. If
- a series of keys are needed, it can be generated from a strong random
- seed using a cryptographically strong sequence as explained in
- Section 6.3. A few hundred random bits generated once a day would be
- enough using such techniques. Even if the random bits are generated
- as slowly as one per second and it is not possible to overlap the
- generation process, it should be tolerable in high security
- applications to wait 200 seconds occasionally.
-
- These numbers are trivial to achieve. It could be done by a person
- repeatedly tossing a coin. Almost any hardware process is likely to
- be much faster.
-
-5.2 Sensitivity to Skew
-
- Is there any specific requirement on the shape of the distribution of
- the random numbers? The good news is the distribution need not be
- uniform. All that is needed is a conservative estimate of how non-
- uniform it is to bound performance. Two simple techniques to de-skew
- the bit stream are given below and stronger techniques are mentioned
- in Section 6.1.2 below.
-
-
-
-Eastlake, Crocker & Schiller [Page 10]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-5.2.1 Using Stream Parity to De-Skew
-
- Consider taking a sufficiently long string of bits and map the string
- to "zero" or "one". The mapping will not yield a perfectly uniform
- distribution, but it can be as close as desired. One mapping that
- serves the purpose is to take the parity of the string. This has the
- advantages that it is robust across all degrees of skew up to the
- estimated maximum skew and is absolutely trivial to implement in
- hardware.
-
- The following analysis gives the number of bits that must be sampled:
-
- Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
- between 0 and 0.5 and is a measure of the "eccentricity" of the
- distribution. Consider the distribution of the parity function of N
- bit samples. The probabilities that the parity will be one or zero
- will be the sum of the odd or even terms in the binomial expansion of
- (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
- e, the probability of a zero.
-
- These sums can be computed easily as
-
- N N
- 1/2 * ( ( p + q ) + ( p - q ) )
- and
- N N
- 1/2 * ( ( p + q ) - ( p - q ) ).
-
- (Which one corresponds to the probability the parity will be 1
- depends on whether N is odd or even.)
-
- Since p + q = 1 and p - q = 2e, these expressions reduce to
-
- N
- 1/2 * [1 + (2e) ]
- and
- N
- 1/2 * [1 - (2e) ].
-
- Neither of these will ever be exactly 0.5 unless e is zero, but we
- can bring them arbitrarily close to 0.5. If we want the
- probabilities to be within some delta d of 0.5, i.e. then
-
- N
- ( 0.5 + ( 0.5 * (2e) ) ) < 0.5 + d.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 11]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- Solving for N yields N > log(2d)/log(2e). (Note that 2e is less than
- 1, so its log is negative. Division by a negative number reverses
- the sense of an inequality.)
-
- The following table gives the length of the string which must be
- sampled for various degrees of skew in order to come within 0.001 of
- a 50/50 distribution.
-
- +---------+--------+-------+
- | Prob(1) | e | N |
- +---------+--------+-------+
- | 0.5 | 0.00 | 1 |
- | 0.6 | 0.10 | 4 |
- | 0.7 | 0.20 | 7 |
- | 0.8 | 0.30 | 13 |
- | 0.9 | 0.40 | 28 |
- | 0.95 | 0.45 | 59 |
- | 0.99 | 0.49 | 308 |
- +---------+--------+-------+
-
- The last entry shows that even if the distribution is skewed 99% in
- favor of ones, the parity of a string of 308 samples will be within
- 0.001 of a 50/50 distribution.
-
-5.2.2 Using Transition Mappings to De-Skew
-
- Another technique, originally due to von Neumann [VON NEUMANN], is to
- examine a bit stream as a sequence of non-overlapping pairs. You
- could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
- 10 as a 1. Assume the probability of a 1 is 0.5+e and the
- probability of a 0 is 0.5-e where e is the eccentricity of the source
- and described in the previous section. Then the probability of each
- pair is as follows:
-
- +------+-----------------------------------------+
- | pair | probability |
- +------+-----------------------------------------+
- | 00 | (0.5 - e)^2 = 0.25 - e + e^2 |
- | 01 | (0.5 - e)*(0.5 + e) = 0.25 - e^2 |
- | 10 | (0.5 + e)*(0.5 - e) = 0.25 - e^2 |
- | 11 | (0.5 + e)^2 = 0.25 + e + e^2 |
- +------+-----------------------------------------+
-
- This technique will completely eliminate any bias but at the expense
- of taking an indeterminate number of input bits for any particular
- desired number of output bits. The probability of any particular
- pair being discarded is 0.5 + 2e^2 so the expected number of input
- bits to produce X output bits is X/(0.25 - e^2).
-
-
-
-Eastlake, Crocker & Schiller [Page 12]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- This technique assumes that the bits are from a stream where each bit
- has the same probability of being a 0 or 1 as any other bit in the
- stream and that bits are not correlated, i.e., that the bits are
- identical independent distributions. If alternate bits were from two
- correlated sources, for example, the above analysis breaks down.
-
- The above technique also provides another illustration of how a
- simple statistical analysis can mislead if one is not always on the
- lookout for patterns that could be exploited by an adversary. If the
- algorithm were mis-read slightly so that overlapping successive bits
- pairs were used instead of non-overlapping pairs, the statistical
- analysis given is the same; however, instead of provided an unbiased
- uncorrelated series of random 1's and 0's, it instead produces a
- totally predictable sequence of exactly alternating 1's and 0's.
-
-5.2.3 Using FFT to De-Skew
-
- When real world data consists of strongly biased or correlated bits,
- it may still contain useful amounts of randomness. This randomness
- can be extracted through use of the discrete Fourier transform or its
- optimized variant, the FFT.
-
- Using the Fourier transform of the data, strong correlations can be
- discarded. If adequate data is processed and remaining correlations
- decay, spectral lines approaching statistical independence and
- normally distributed randomness can be produced [BRILLINGER].
-
-5.2.4 Using Compression to De-Skew
-
- Reversible compression techniques also provide a crude method of de-
- skewing a skewed bit stream. This follows directly from the
- definition of reversible compression and the formula in Section 2
- above for the amount of information in a sequence. Since the
- compression is reversible, the same amount of information must be
- present in the shorter output than was present in the longer input.
- By the Shannon information equation, this is only possible if, on
- average, the probabilities of the different shorter sequences are
- more uniformly distributed than were the probabilities of the longer
- sequences. Thus the shorter sequences are de-skewed relative to the
- input.
-
- However, many compression techniques add a somewhat predicatable
- preface to their output stream and may insert such a sequence again
- periodically in their output or otherwise introduce subtle patterns
- of their own. They should be considered only a rough technique
- compared with those described above or in Section 6.1.2. At a
- minimum, the beginning of the compressed sequence should be skipped
- and only later bits used for applications requiring random bits.
-
-
-
-Eastlake, Crocker & Schiller [Page 13]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-5.3 Existing Hardware Can Be Used For Randomness
-
- As described below, many computers come with hardware that can, with
- care, be used to generate truly random quantities.
-
-5.3.1 Using Existing Sound/Video Input
-
- Increasingly computers are being built with inputs that digitize some
- real world analog source, such as sound from a microphone or video
- input from a camera. Under appropriate circumstances, such input can
- provide reasonably high quality random bits. The "input" from a
- sound digitizer with no source plugged in or a camera with the lens
- cap on, if the system has enough gain to detect anything, is
- essentially thermal noise.
-
- For example, on a SPARCstation, one can read from the /dev/audio
- device with nothing plugged into the microphone jack. Such data is
- essentially random noise although it should not be trusted without
- some checking in case of hardware failure. It will, in any case,
- need to be de-skewed as described elsewhere.
-
- Combining this with compression to de-skew one can, in UNIXese,
- generate a huge amount of medium quality random data by doing
-
- cat /dev/audio | compress - >random-bits-file
-
-5.3.2 Using Existing Disk Drives
-
- Disk drives have small random fluctuations in their rotational speed
- due to chaotic air turbulence [DAVIS]. By adding low level disk seek
- time instrumentation to a system, a series of measurements can be
- obtained that include this randomness. Such data is usually highly
- correlated so that significant processing is needed, including FFT
- (see section 5.2.3). Nevertheless experimentation has shown that,
- with such processing, disk drives easily produce 100 bits a minute or
- more of excellent random data.
-
- Partly offsetting this need for processing is the fact that disk
- drive failure will normally be rapidly noticed. Thus, problems with
- this method of random number generation due to hardware failure are
- very unlikely.
-
-6. Recommended Non-Hardware Strategy
-
- What is the best overall strategy for meeting the requirement for
- unguessable random numbers in the absence of a reliable hardware
- source? It is to obtain random input from a large number of
- uncorrelated sources and to mix them with a strong mixing function.
-
-
-
-Eastlake, Crocker & Schiller [Page 14]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- Such a function will preserve the randomness present in any of the
- sources even if other quantities being combined are fixed or easily
- guessable. This may be advisable even with a good hardware source as
- hardware can also fail, though this should be weighed against any
- increase in the chance of overall failure due to added software
- complexity.
-
-6.1 Mixing Functions
-
- A strong mixing function is one which combines two or more inputs and
- produces an output where each output bit is a different complex non-
- linear function of all the input bits. On average, changing any
- input bit will change about half the output bits. But because the
- relationship is complex and non-linear, no particular output bit is
- guaranteed to change when any particular input bit is changed.
-
- Consider the problem of converting a stream of bits that is skewed
- towards 0 or 1 to a shorter stream which is more random, as discussed
- in Section 5.2 above. This is simply another case where a strong
- mixing function is desired, mixing the input bits to produce a
- smaller number of output bits. The technique given in Section 5.2.1
- of using the parity of a number of bits is simply the result of
- successively Exclusive Or'ing them which is examined as a trivial
- mixing function immediately below. Use of stronger mixing functions
- to extract more of the randomness in a stream of skewed bits is
- examined in Section 6.1.2.
-
-6.1.1 A Trivial Mixing Function
-
- A trivial example for single bit inputs is the Exclusive Or function,
- which is equivalent to addition without carry, as show in the table
- below. This is a degenerate case in which the one output bit always
- changes for a change in either input bit. But, despite its
- simplicity, it will still provide a useful illustration.
-
- +-----------+-----------+----------+
- | input 1 | input 2 | output |
- +-----------+-----------+----------+
- | 0 | 0 | 0 |
- | 0 | 1 | 1 |
- | 1 | 0 | 1 |
- | 1 | 1 | 0 |
- +-----------+-----------+----------+
-
- If inputs 1 and 2 are uncorrelated and combined in this fashion then
- the output will be an even better (less skewed) random bit than the
- inputs. If we assume an "eccentricity" e as defined in Section 5.2
- above, then the output eccentricity relates to the input eccentricity
-
-
-
-Eastlake, Crocker & Schiller [Page 15]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- as follows:
-
- e = 2 * e * e
- output input 1 input 2
-
- Since e is never greater than 1/2, the eccentricity is always
- improved except in the case where at least one input is a totally
- skewed constant. This is illustrated in the following table where
- the top and left side values are the two input eccentricities and the
- entries are the output eccentricity:
-
- +--------+--------+--------+--------+--------+--------+--------+
- | e | 0.00 | 0.10 | 0.20 | 0.30 | 0.40 | 0.50 |
- +--------+--------+--------+--------+--------+--------+--------+
- | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
- | 0.10 | 0.00 | 0.02 | 0.04 | 0.06 | 0.08 | 0.10 |
- | 0.20 | 0.00 | 0.04 | 0.08 | 0.12 | 0.16 | 0.20 |
- | 0.30 | 0.00 | 0.06 | 0.12 | 0.18 | 0.24 | 0.30 |
- | 0.40 | 0.00 | 0.08 | 0.16 | 0.24 | 0.32 | 0.40 |
- | 0.50 | 0.00 | 0.10 | 0.20 | 0.30 | 0.40 | 0.50 |
- +--------+--------+--------+--------+--------+--------+--------+
-
- However, keep in mind that the above calculations assume that the
- inputs are not correlated. If the inputs were, say, the parity of
- the number of minutes from midnight on two clocks accurate to a few
- seconds, then each might appear random if sampled at random intervals
- much longer than a minute. Yet if they were both sampled and
- combined with xor, the result would be zero most of the time.
-
-6.1.2 Stronger Mixing Functions
-
- The US Government Data Encryption Standard [DES] is an example of a
- strong mixing function for multiple bit quantities. It takes up to
- 120 bits of input (64 bits of "data" and 56 bits of "key") and
- produces 64 bits of output each of which is dependent on a complex
- non-linear function of all input bits. Other strong encryption
- functions with this characteristic can also be used by considering
- them to mix all of their key and data input bits.
-
- Another good family of mixing functions are the "message digest" or
- hashing functions such as The US Government Secure Hash Standard
- [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series. These functions
- all take an arbitrary amount of input and produce an output mixing
- all the input bits. The MD* series produce 128 bits of output and SHS
- produces 160 bits.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 16]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- Although the message digest functions are designed for variable
- amounts of input, DES and other encryption functions can also be used
- to combine any number of inputs. If 64 bits of output is adequate,
- the inputs can be packed into a 64 bit data quantity and successive
- 56 bit keys, padding with zeros if needed, which are then used to
- successively encrypt using DES in Electronic Codebook Mode [DES
- MODES]. If more than 64 bits of output are needed, use more complex
- mixing. For example, if inputs are packed into three quantities, A,
- B, and C, use DES to encrypt A with B as a key and then with C as a
- key to produce the 1st part of the output, then encrypt B with C and
- then A for more output and, if necessary, encrypt C with A and then B
- for yet more output. Still more output can be produced by reversing
- the order of the keys given above to stretch things. The same can be
- done with the hash functions by hashing various subsets of the input
- data to produce multiple outputs. But keep in mind that it is
- impossible to get more bits of "randomness" out than are put in.
-
- An example of using a strong mixing function would be to reconsider
- the case of a string of 308 bits each of which is biased 99% towards
- zero. The parity technique given in Section 5.2.1 above reduced this
- to one bit with only a 1/1000 deviance from being equally likely a
- zero or one. But, applying the equation for information given in
- Section 2, this 308 bit sequence has 5 bits of information in it.
- Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
- result would yield 5 unbiased random bits as opposed to the single
- bit given by calculating the parity of the string.
-
-6.1.3 Diffie-Hellman as a Mixing Function
-
- Diffie-Hellman exponential key exchange is a technique that yields a
- shared secret between two parties that can be made computationally
- infeasible for a third party to determine even if they can observe
- all the messages between the two communicating parties. This shared
- secret is a mixture of initial quantities generated by each of them
- [D-H]. If these initial quantities are random, then the shared
- secret contains the combined randomness of them both, assuming they
- are uncorrelated.
-
-6.1.4 Using a Mixing Function to Stretch Random Bits
-
- While it is not necessary for a mixing function to produce the same
- or fewer bits than its inputs, mixing bits cannot "stretch" the
- amount of random unpredictability present in the inputs. Thus four
- inputs of 32 bits each where there is 12 bits worth of
- unpredicatability (such as 4,096 equally probable values) in each
- input cannot produce more than 48 bits worth of unpredictable output.
- The output can be expanded to hundreds or thousands of bits by, for
- example, mixing with successive integers, but the clever adversary's
-
-
-
-Eastlake, Crocker & Schiller [Page 17]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- search space is still 2^48 possibilities. Furthermore, mixing to
- fewer bits than are input will tend to strengthen the randomness of
- the output the way using Exclusive Or to produce one bit from two did
- above.
-
- The last table in Section 6.1.1 shows that mixing a random bit with a
- constant bit with Exclusive Or will produce a random bit. While this
- is true, it does not provide a way to "stretch" one random bit into
- more than one. If, for example, a random bit is mixed with a 0 and
- then with a 1, this produces a two bit sequence but it will always be
- either 01 or 10. Since there are only two possible values, there is
- still only the one bit of original randomness.
-
-6.1.5 Other Factors in Choosing a Mixing Function
-
- For local use, DES has the advantages that it has been widely tested
- for flaws, is widely documented, and is widely implemented with
- hardware and software implementations available all over the world
- including source code available by anonymous FTP. The SHS and MD*
- family are younger algorithms which have been less tested but there
- is no particular reason to believe they are flawed. Both MD5 and SHS
- were derived from the earlier MD4 algorithm. They all have source
- code available by anonymous FTP [SHS, MD2, MD4, MD5].
-
- DES and SHS have been vouched for the the US National Security Agency
- (NSA) on the basis of criteria that primarily remain secret. While
- this is the cause of much speculation and doubt, investigation of DES
- over the years has indicated that NSA involvement in modifications to
- its design, which originated with IBM, was primarily to strengthen
- it. No concealed or special weakness has been found in DES. It is
- almost certain that the NSA modification to MD4 to produce the SHS
- similarly strengthened the algorithm, possibly against threats not
- yet known in the public cryptographic community.
-
- DES, SHS, MD4, and MD5 are royalty free for all purposes. MD2 has
- been freely licensed only for non-profit use in connection with
- Privacy Enhanced Mail [PEM]. Between the MD* algorithms, some people
- believe that, as with "Goldilocks and the Three Bears", MD2 is strong
- but too slow, MD4 is fast but too weak, and MD5 is just right.
-
- Another advantage of the MD* or similar hashing algorithms over
- encryption algorithms is that they are not subject to the same
- regulations imposed by the US Government prohibiting the unlicensed
- export or import of encryption/decryption software and hardware. The
- same should be true of DES rigged to produce an irreversible hash
- code but most DES packages are oriented to reversible encryption.
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 18]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-6.2 Non-Hardware Sources of Randomness
-
- The best source of input for mixing would be a hardware randomness
- such as disk drive timing affected by air turbulence, audio input
- with thermal noise, or radioactive decay. However, if that is not
- available there are other possibilities. These include system
- clocks, system or input/output buffers, user/system/hardware/network
- serial numbers and/or addresses and timing, and user input.
- Unfortunately, any of these sources can produce limited or
- predicatable values under some circumstances.
-
- Some of the sources listed above would be quite strong on multi-user
- systems where, in essence, each user of the system is a source of
- randomness. However, on a small single user system, such as a
- typical IBM PC or Apple Macintosh, it might be possible for an
- adversary to assemble a similar configuration. This could give the
- adversary inputs to the mixing process that were sufficiently
- correlated to those used originally as to make exhaustive search
- practical.
-
- The use of multiple random inputs with a strong mixing function is
- recommended and can overcome weakness in any particular input. For
- example, the timing and content of requested "random" user keystrokes
- can yield hundreds of random bits but conservative assumptions need
- to be made. For example, assuming a few bits of randomness if the
- inter-keystroke interval is unique in the sequence up to that point
- and a similar assumption if the key hit is unique but assuming that
- no bits of randomness are present in the initial key value or if the
- timing or key value duplicate previous values. The results of mixing
- these timings and characters typed could be further combined with
- clock values and other inputs.
-
- This strategy may make practical portable code to produce good random
- numbers for security even if some of the inputs are very weak on some
- of the target systems. However, it may still fail against a high
- grade attack on small single user systems, especially if the
- adversary has ever been able to observe the generation process in the
- past. A hardware based random source is still preferable.
-
-6.3 Cryptographically Strong Sequences
-
- In cases where a series of random quantities must be generated, an
- adversary may learn some values in the sequence. In general, they
- should not be able to predict other values from the ones that they
- know.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 19]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- The correct technique is to start with a strong random seed, take
- cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
- do not reveal the complete state of the generator in the sequence
- elements. If each value in the sequence can be calculated in a fixed
- way from the previous value, then when any value is compromised, all
- future values can be determined. This would be the case, for
- example, if each value were a constant function of the previously
- used values, even if the function were a very strong, non-invertible
- message digest function.
-
- It should be noted that if your technique for generating a sequence
- of key values is fast enough, it can trivially be used as the basis
- for a confidentiality system. If two parties use the same sequence
- generating technique and start with the same seed material, they will
- generate identical sequences. These could, for example, be xor'ed at
- one end with data being send, encrypting it, and xor'ed with this
- data as received, decrypting it due to the reversible properties of
- the xor operation.
-
-6.3.1 Traditional Strong Sequences
-
- A traditional way to achieve a strong sequence has been to have the
- values be produced by hashing the quantities produced by
- concatenating the seed with successive integers or the like and then
- mask the values obtained so as to limit the amount of generator state
- available to the adversary.
-
- It may also be possible to use an "encryption" algorithm with a
- random key and seed value to encrypt and feedback some or all of the
- output encrypted value into the value to be encrypted for the next
- iteration. Appropriate feedback techniques will usually be
- recommended with the encryption algorithm. An example is shown below
- where shifting and masking are used to combine the cypher output
- feedback. This type of feedback is recommended by the US Government
- in connection with DES [DES MODES].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 20]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- +---------------+
- | V |
- | | n |
- +--+------------+
- | | +---------+
- | +---------> | | +-----+
- +--+ | Encrypt | <--- | Key |
- | +-------- | | +-----+
- | | +---------+
- V V
- +------------+--+
- | V | |
- | n+1 |
- +---------------+
-
- Note that if a shift of one is used, this is the same as the shift
- register technique described in Section 3 above but with the all
- important difference that the feedback is determined by a complex
- non-linear function of all bits rather than a simple linear or
- polynomial combination of output from a few bit position taps.
-
- It has been shown by Donald W. Davies that this sort of shifted
- partial output feedback significantly weakens an algorithm compared
- will feeding all of the output bits back as input. In particular,
- for DES, repeated encrypting a full 64 bit quantity will give an
- expected repeat in about 2^63 iterations. Feeding back anything less
- than 64 (and more than 0) bits will give an expected repeat in
- between 2**31 and 2**32 iterations!
-
- To predict values of a sequence from others when the sequence was
- generated by these techniques is equivalent to breaking the
- cryptosystem or inverting the "non-invertible" hashing involved with
- only partial information available. The less information revealed
- each iteration, the harder it will be for an adversary to predict the
- sequence. Thus it is best to use only one bit from each value. It
- has been shown that in some cases this makes it impossible to break a
- system even when the cryptographic system is invertible and can be
- broken if all of each generated value was revealed.
-
-6.3.2 The Blum Blum Shub Sequence Generator
-
- Currently the generator which has the strongest public proof of
- strength is called the Blum Blum Shub generator after its inventors
- [BBS]. It is also very simple and is based on quadratic residues.
- It's only disadvantage is that is is computationally intensive
- compared with the traditional techniques give in 6.3.1 above. This
- is not a serious draw back if it is used for moderately infrequent
- purposes, such as generating session keys.
-
-
-
-Eastlake, Crocker & Schiller [Page 21]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- Simply choose two large prime numbers, say p and q, which both have
- the property that you get a remainder of 3 if you divide them by 4.
- Let n = p * q. Then you choose a random number x relatively prime to
- n. The initial seed for the generator and the method for calculating
- subsequent values are then
-
- 2
- s = ( x )(Mod n)
- 0
-
- 2
- s = ( s )(Mod n)
- i+1 i
-
- You must be careful to use only a few bits from the bottom of each s.
- It is always safe to use only the lowest order bit. If you use no
- more than the
-
- log ( log ( s ) )
- 2 2 i
-
- low order bits, then predicting any additional bits from a sequence
- generated in this manner is provable as hard as factoring n. As long
- as the initial x is secret, you can even make n public if you want.
-
- An intersting characteristic of this generator is that you can
- directly calculate any of the s values. In particular
-
- i
- ( ( 2 )(Mod (( p - 1 ) * ( q - 1 )) ) )
- s = ( s )(Mod n)
- i 0
-
- This means that in applications where many keys are generated in this
- fashion, it is not necessary to save them all. Each key can be
- effectively indexed and recovered from that small index and the
- initial s and n.
-
-7. Key Generation Standards
-
- Several public standards are now in place for the generation of keys.
- Two of these are described below. Both use DES but any equally
- strong or stronger mixing function could be substituted.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 22]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-7.1 US DoD Recommendations for Password Generation
-
- The United States Department of Defense has specific recommendations
- for password generation [DoD]. They suggest using the US Data
- Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
- follows:
-
- use an initialization vector determined from
- the system clock,
- system ID,
- user ID, and
- date and time;
- use a key determined from
- system interrupt registers,
- system status registers, and
- system counters; and,
- as plain text, use an external randomly generated 64 bit
- quantity such as 8 characters typed in by a system
- administrator.
-
- The password can then be calculated from the 64 bit "cipher text"
- generated in 64-bit Output Feedback Mode. As many bits as are needed
- can be taken from these 64 bits and expanded into a pronounceable
- word, phrase, or other format if a human being needs to remember the
- password.
-
-7.2 X9.17 Key Generation
-
- The American National Standards Institute has specified a method for
- generating a sequence of keys as follows:
-
- s is the initial 64 bit seed
- 0
-
- g is the sequence of generated 64 bit key quantities
- n
-
- k is a random key reserved for generating this key sequence
-
- t is the time at which a key is generated to as fine a resolution
- as is available (up to 64 bits).
-
- DES ( K, Q ) is the DES encryption of quantity Q with key K
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 23]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- g = DES ( k, DES ( k, t ) .xor. s )
- n n
-
- s = DES ( k, DES ( k, t ) .xor. g )
- n+1 n
-
- If g sub n is to be used as a DES key, then every eighth bit should
- be adjusted for parity for that use but the entire 64 bit unmodified
- g should be used in calculating the next s.
-
-8. Examples of Randomness Required
-
- Below are two examples showing rough calculations of needed
- randomness for security. The first is for moderate security
- passwords while the second assumes a need for a very high security
- cryptographic key.
-
-8.1 Password Generation
-
- Assume that user passwords change once a year and it is desired that
- the probability that an adversary could guess the password for a
- particular account be less than one in a thousand. Further assume
- that sending a password to the system is the only way to try a
- password. Then the crucial question is how often an adversary can
- try possibilities. Assume that delays have been introduced into a
- system so that, at most, an adversary can make one password try every
- six seconds. That's 600 per hour or about 15,000 per day or about
- 5,000,000 tries in a year. Assuming any sort of monitoring, it is
- unlikely someone could actually try continuously for a year. In
- fact, even if log files are only checked monthly, 500,000 tries is
- more plausible before the attack is noticed and steps taken to change
- passwords and make it harder to try more passwords.
-
- To have a one in a thousand chance of guessing the password in
- 500,000 tries implies a universe of at least 500,000,000 passwords or
- about 2^29. Thus 29 bits of randomness are needed. This can probably
- be achieved using the US DoD recommended inputs for password
- generation as it has 8 inputs which probably average over 5 bits of
- randomness each (see section 7.1). Using a list of 1000 words, the
- password could be expressed as a three word phrase (1,000,000,000
- possibilities) or, using case insensitive letters and digits, six
- would suffice ((26+10)^6 = 2,176,782,336 possibilities).
-
- For a higher security password, the number of bits required goes up.
- To decrease the probability by 1,000 requires increasing the universe
- of passwords by the same factor which adds about 10 bits. Thus to
- have only a one in a million chance of a password being guessed under
- the above scenario would require 39 bits of randomness and a password
-
-
-
-Eastlake, Crocker & Schiller [Page 24]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- that was a four word phrase from a 1000 word list or eight
- letters/digits. To go to a one in 10^9 chance, 49 bits of randomness
- are needed implying a five word phrase or ten letter/digit password.
-
- In a real system, of course, there are also other factors. For
- example, the larger and harder to remember passwords are, the more
- likely users are to write them down resulting in an additional risk
- of compromise.
-
-8.2 A Very High Security Cryptographic Key
-
- Assume that a very high security key is needed for symmetric
- encryption / decryption between two parties. Assume an adversary can
- observe communications and knows the algorithm being used. Within
- the field of random possibilities, the adversary can try key values
- in hopes of finding the one in use. Assume further that brute force
- trial of keys is the best the adversary can do.
-
-8.2.1 Effort per Key Trial
-
- How much effort will it take to try each key? For very high security
- applications it is best to assume a low value of effort. Even if it
- would clearly take tens of thousands of computer cycles or more to
- try a single key, there may be some pattern that enables huge blocks
- of key values to be tested with much less effort per key. Thus it is
- probably best to assume no more than a couple hundred cycles per key.
- (There is no clear lower bound on this as computers operate in
- parallel on a number of bits and a poor encryption algorithm could
- allow many keys or even groups of keys to be tested in parallel.
- However, we need to assume some value and can hope that a reasonably
- strong algorithm has been chosen for our hypothetical high security
- task.)
-
- If the adversary can command a highly parallel processor or a large
- network of work stations, 2*10^10 cycles per second is probably a
- minimum assumption for availability today. Looking forward just a
- couple years, there should be at least an order of magnitude
- improvement. Thus assuming 10^9 keys could be checked per second or
- 3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
- reasonable. This implies a need for a minimum of 51 bits of
- randomness in keys to be sure they cannot be found in a month. Even
- then it is possible that, a few years from now, a highly determined
- and resourceful adversary could break the key in 2 weeks (on average
- they need try only half the keys).
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 25]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-8.2.2 Meet in the Middle Attacks
-
- If chosen or known plain text and the resulting encrypted text are
- available, a "meet in the middle" attack is possible if the structure
- of the encryption algorithm allows it. (In a known plain text
- attack, the adversary knows all or part of the messages being
- encrypted, possibly some standard header or trailer fields. In a
- chosen plain text attack, the adversary can force some chosen plain
- text to be encrypted, possibly by "leaking" an exciting text that
- would then be sent by the adversary over an encrypted channel.)
-
- An oversimplified explanation of the meet in the middle attack is as
- follows: the adversary can half-encrypt the known or chosen plain
- text with all possible first half-keys, sort the output, then half-
- decrypt the encoded text with all the second half-keys. If a match
- is found, the full key can be assembled from the halves and used to
- decrypt other parts of the message or other messages. At its best,
- this type of attack can halve the exponent of the work required by
- the adversary while adding a large but roughly constant factor of
- effort. To be assured of safety against this, a doubling of the
- amount of randomness in the key to a minimum of 102 bits is required.
-
- The meet in the middle attack assumes that the cryptographic
- algorithm can be decomposed in this way but we can not rule that out
- without a deep knowledge of the algorithm. Even if a basic algorithm
- is not subject to a meet in the middle attack, an attempt to produce
- a stronger algorithm by applying the basic algorithm twice (or two
- different algorithms sequentially) with different keys may gain less
- added security than would be expected. Such a composite algorithm
- would be subject to a meet in the middle attack.
-
- Enormous resources may be required to mount a meet in the middle
- attack but they are probably within the range of the national
- security services of a major nation. Essentially all nations spy on
- other nations government traffic and several nations are believed to
- spy on commercial traffic for economic advantage.
-
-8.2.3 Other Considerations
-
- Since we have not even considered the possibilities of special
- purpose code breaking hardware or just how much of a safety margin we
- want beyond our assumptions above, probably a good minimum for a very
- high security cryptographic key is 128 bits of randomness which
- implies a minimum key length of 128 bits. If the two parties agree
- on a key by Diffie-Hellman exchange [D-H], then in principle only
- half of this randomness would have to be supplied by each party.
- However, there is probably some correlation between their random
- inputs so it is probably best to assume that each party needs to
-
-
-
-Eastlake, Crocker & Schiller [Page 26]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- provide at least 96 bits worth of randomness for very high security
- if Diffie-Hellman is used.
-
- This amount of randomness is beyond the limit of that in the inputs
- recommended by the US DoD for password generation and could require
- user typing timing, hardware random number generation, or other
- sources.
-
- It should be noted that key length calculations such at those above
- are controversial and depend on various assumptions about the
- cryptographic algorithms in use. In some cases, a professional with
- a deep knowledge of code breaking techniques and of the strength of
- the algorithm in use could be satisfied with less than half of the
- key size derived above.
-
-9. Conclusion
-
- Generation of unguessable "random" secret quantities for security use
- is an essential but difficult task.
-
- We have shown that hardware techniques to produce such randomness
- would be relatively simple. In particular, the volume and quality
- would not need to be high and existing computer hardware, such as
- disk drives, can be used. Computational techniques are available to
- process low quality random quantities from multiple sources or a
- larger quantity of such low quality input from one source and produce
- a smaller quantity of higher quality, less predictable key material.
- In the absence of hardware sources of randomness, a variety of user
- and software sources can frequently be used instead with care;
- however, most modern systems already have hardware, such as disk
- drives or audio input, that could be used to produce high quality
- randomness.
-
- Once a sufficient quantity of high quality seed key material (a few
- hundred bits) is available, strong computational techniques are
- available to produce cryptographically strong sequences of
- unpredicatable quantities from this seed material.
-
-10. Security Considerations
-
- The entirety of this document concerns techniques and recommendations
- for generating unguessable "random" quantities for use as passwords,
- cryptographic keys, and similar security uses.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 27]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
-References
-
- [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
- edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
- Press, Inc.
-
- [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
- Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
-
- [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
- 1981, David Brillinger.
-
- [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
- Publishing Company.
-
- [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
- John Wiley & Sons, 1981, Alan G. Konheim.
-
- [CRYPTO2] - Cryptography: A New Dimension in Computer Data Security,
- A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
- Meyer & Stephen M. Matyas.
-
- [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
- Code in C, John Wiley & Sons, 1994, Bruce Schneier.
-
- [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
- Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
- Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
- Philip Fenstermacher.
-
- [DES] - Data Encryption Standard, United States of America,
- Department of Commerce, National Institute of Standards and
- Technology, Federal Information Processing Standard (FIPS) 46-1.
- - Data Encryption Algorithm, American National Standards Institute,
- ANSI X3.92-1981.
- (See also FIPS 112, Password Usage, which includes FORTRAN code for
- performing DES.)
-
- [DES MODES] - DES Modes of Operation, United States of America,
- Department of Commerce, National Institute of Standards and
- Technology, Federal Information Processing Standard (FIPS) 81.
- - Data Encryption Algorithm - Modes of Operation, American National
- Standards Institute, ANSI X3.106-1983.
-
- [D-H] - New Directions in Cryptography, IEEE Transactions on
- Information Technology, November, 1976, Whitfield Diffie and Martin
- E. Hellman.
-
-
-
-
-Eastlake, Crocker & Schiller [Page 28]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- [DoD] - Password Management Guideline, United States of America,
- Department of Defense, Computer Security Center, CSC-STD-002-85.
- (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
- as one of its appendices.)
-
- [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
- David K. Gifford
-
- [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
- Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
- Company, Second Edition 1982, Donald E. Knuth.
-
- [KRAWCZYK] - How to Predict Congruential Generators, Journal of
- Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
-
- [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
- Kaliski
- [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
- Rivest
- [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
- Rivest
-
- [PEM] - RFCs 1421 through 1424:
- - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
- IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
- - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
- III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
- - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
- II: Certificate-Based Key Management, 02/10/1993, S. Kent
- - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
- Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
-
- [SHANNON] - The Mathematical Theory of Communication, University of
- Illinois Press, 1963, Claude E. Shannon. (originally from: Bell
- System Technical Journal, July and October 1948)
-
- [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
- Edition 1982, Solomon W. Golomb.
-
- [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
- Systems, Aegean Park Press, 1984, Wayne G. Barker.
-
- [SHS] - Secure Hash Standard, United States of American, National
- Institute of Science and Technology, Federal Information Processing
- Standard (FIPS) 180, April 1993.
-
- [STERN] - Secret Linear Congruential Generators are not
- Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
-
-
-
-Eastlake, Crocker & Schiller [Page 29]
-
-RFC 1750 Randomness Recommendations for Security December 1994
-
-
- [VON NEUMANN] - Various techniques used in connection with random
- digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
- J. von Neumann.
-
-Authors' Addresses
-
- Donald E. Eastlake 3rd
- Digital Equipment Corporation
- 550 King Street, LKG2-1/BB3
- Littleton, MA 01460
-
- Phone: +1 508 486 6577(w) +1 508 287 4877(h)
- EMail: dee@lkg.dec.com
-
-
- Stephen D. Crocker
- CyberCash Inc.
- 2086 Hunters Crest Way
- Vienna, VA 22181
-
- Phone: +1 703-620-1222(w) +1 703-391-2651 (fax)
- EMail: crocker@cybercash.com
-
-
- Jeffrey I. Schiller
- Massachusetts Institute of Technology
- 77 Massachusetts Avenue
- Cambridge, MA 02139
-
- Phone: +1 617 253 0161(w)
- EMail: jis@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller [Page 30]
-
diff --git a/contrib/bind9/doc/rfc/rfc1876.txt b/contrib/bind9/doc/rfc/rfc1876.txt
deleted file mode 100644
index a289cffece251..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1876.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group C. Davis
-Request for Comments: 1876 Kapor Enterprises
-Updates: 1034, 1035 P. Vixie
-Category: Experimental Vixie Enterprises
- T. Goodwin
- FORE Systems
- I. Dickinson
- University of Warwick
- January 1996
-
-
- A Means for Expressing Location Information in the Domain Name System
-
-Status of this Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. This memo does not specify an Internet standard of any
- kind. Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-1. Abstract
-
- This memo defines a new DNS RR type for experimental purposes. This
- RFC describes a mechanism to allow the DNS to carry location
- information about hosts, networks, and subnets. Such information for
- a small subset of hosts is currently contained in the flat-file UUCP
- maps. However, just as the DNS replaced the use of HOSTS.TXT to
- carry host and network address information, it is possible to replace
- the UUCP maps as carriers of location information.
-
- This RFC defines the format of a new Resource Record (RR) for the
- Domain Name System (DNS), and reserves a corresponding DNS type
- mnemonic (LOC) and numerical code (29).
-
- This RFC assumes that the reader is familiar with the DNS [RFC 1034,
- RFC 1035]. The data shown in our examples is for pedagogical use and
- does not necessarily reflect the real Internet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al Experimental [Page 1]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
-2. RDATA Format
-
- MSB LSB
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 0| VERSION | SIZE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 2| HORIZ PRE | VERT PRE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 4| LATITUDE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 6| LATITUDE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 8| LONGITUDE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 10| LONGITUDE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 12| ALTITUDE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 14| ALTITUDE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- (octet)
-
-where:
-
-VERSION Version number of the representation. This must be zero.
- Implementations are required to check this field and make
- no assumptions about the format of unrecognized versions.
-
-SIZE The diameter of a sphere enclosing the described entity, in
- centimeters, expressed as a pair of four-bit unsigned
- integers, each ranging from zero to nine, with the most
- significant four bits representing the base and the second
- number representing the power of ten by which to multiply
- the base. This allows sizes from 0e0 (<1cm) to 9e9
- (90,000km) to be expressed. This representation was chosen
- such that the hexadecimal representation can be read by
- eye; 0x15 = 1e5. Four-bit values greater than 9 are
- undefined, as are values with a base of zero and a non-zero
- exponent.
-
- Since 20000000m (represented by the value 0x29) is greater
- than the equatorial diameter of the WGS 84 ellipsoid
- (12756274m), it is therefore suitable for use as a
- "worldwide" size.
-
-HORIZ PRE The horizontal precision of the data, in centimeters,
- expressed using the same representation as SIZE. This is
- the diameter of the horizontal "circle of error", rather
-
-
-
-Davis, et al Experimental [Page 2]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- than a "plus or minus" value. (This was chosen to match
- the interpretation of SIZE; to get a "plus or minus" value,
- divide by 2.)
-
-VERT PRE The vertical precision of the data, in centimeters,
- expressed using the sane representation as for SIZE. This
- is the total potential vertical error, rather than a "plus
- or minus" value. (This was chosen to match the
- interpretation of SIZE; to get a "plus or minus" value,
- divide by 2.) Note that if altitude above or below sea
- level is used as an approximation for altitude relative to
- the [WGS 84] ellipsoid, the precision value should be
- adjusted.
-
-LATITUDE The latitude of the center of the sphere described by the
- SIZE field, expressed as a 32-bit integer, most significant
- octet first (network standard byte order), in thousandths
- of a second of arc. 2^31 represents the equator; numbers
- above that are north latitude.
-
-LONGITUDE The longitude of the center of the sphere described by the
- SIZE field, expressed as a 32-bit integer, most significant
- octet first (network standard byte order), in thousandths
- of a second of arc, rounded away from the prime meridian.
- 2^31 represents the prime meridian; numbers above that are
- east longitude.
-
-ALTITUDE The altitude of the center of the sphere described by the
- SIZE field, expressed as a 32-bit integer, most significant
- octet first (network standard byte order), in centimeters,
- from a base of 100,000m below the [WGS 84] reference
- spheroid used by GPS (semimajor axis a=6378137.0,
- reciprocal flattening rf=298.257223563). Altitude above
- (or below) sea level may be used as an approximation of
- altitude relative to the the [WGS 84] spheroid, though due
- to the Earth's surface not being a perfect spheroid, there
- will be differences. (For example, the geoid (which sea
- level approximates) for the continental US ranges from 10
- meters to 50 meters below the [WGS 84] spheroid.
- Adjustments to ALTITUDE and/or VERT PRE will be necessary
- in most cases. The Defense Mapping Agency publishes geoid
- height values relative to the [WGS 84] ellipsoid.
-
-
-
-
-
-
-
-
-
-Davis, et al Experimental [Page 3]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
-3. Master File Format
-
- The LOC record is expressed in a master file in the following format:
-
- <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
- {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
- [vp["m"]]]] )
-
- (The parentheses are used for multi-line data as specified in [RFC
- 1035] section 5.1.)
-
- where:
-
- d1: [0 .. 90] (degrees latitude)
- d2: [0 .. 180] (degrees longitude)
- m1, m2: [0 .. 59] (minutes latitude/longitude)
- s1, s2: [0 .. 59.999] (seconds latitude/longitude)
- alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
- siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
-
- If omitted, minutes and seconds default to zero, size defaults to 1m,
- horizontal precision defaults to 10000m, and vertical precision
- defaults to 10m. These defaults are chosen to represent typical
- ZIP/postal code area sizes, since it is often easy to find
- approximate geographical location by ZIP/postal code.
-
-4. Example Data
-
-;;;
-;;; note that these data would not all appear in one zone file
-;;;
-
-;; network LOC RR derived from ZIP data. note use of precision defaults
-cambridge-net.kei.com. LOC 42 21 54 N 71 06 18 W -24m 30m
-
-;; higher-precision host LOC RR. note use of vertical precision default
-loiosh.kei.com. LOC 42 21 43.952 N 71 5 6.344 W
- -24m 1m 200m
-
-pipex.net. LOC 52 14 05 N 00 08 50 E 10m
-
-curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m
-
-rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617 W
- -44m 2000m
-
-
-
-
-
-
-Davis, et al Experimental [Page 4]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
-5. Application use of the LOC RR
-
-5.1 Suggested Uses
-
- Some uses for the LOC RR have already been suggested, including the
- USENET backbone flow maps, a "visual traceroute" application showing
- the geographical path of an IP packet, and network management
- applications that could use LOC RRs to generate a map of hosts and
- routers being managed.
-
-5.2 Search Algorithms
-
- This section specifies how to use the DNS to translate domain names
- and/or IP addresses into location information.
-
- If an application wishes to have a "fallback" behavior, displaying a
- less precise or larger area when a host does not have an associated
- LOC RR, it MAY support use of the algorithm in section 5.2.3, as
- noted in sections 5.2.1 and 5.2.2. If fallback is desired, this
- behaviour is the RECOMMENDED default, but in some cases it may need
- to be modified based on the specific requirements of the application
- involved.
-
- This search algorithm is designed to allow network administrators to
- specify the location of a network or subnet without requiring LOC RR
- data for each individual host. For example, a computer lab with 24
- workstations, all of which are on the same subnet and in basically
- the same location, would only need a LOC RR for the subnet.
- (However, if the file server's location has been more precisely
- measured, a separate LOC RR for it can be placed in the DNS.)
-
-5.2.1 Searching by Name
-
- If the application is beginning with a name, rather than an IP
- address (as the USENET backbone flow maps do), it MUST check for a
- LOC RR associated with that name. (CNAME records should be followed
- as for any other RR type.)
-
- If there is no LOC RR for that name, all A records (if any)
- associated with the name MAY be checked for network (or subnet) LOC
- RRs using the "Searching by Network or Subnet" algorithm (5.2.3). If
- multiple A records exist and have associated network or subnet LOC
- RRs, the application may choose to use any, some, or all of the LOC
- RRs found, possibly in combination. It is suggested that multi-homed
- hosts have LOC RRs for their name in the DNS to avoid any ambiguity
- in these cases.
-
-
-
-
-
-Davis, et al Experimental [Page 5]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- Note that domain names that do not have associated A records must
- have a LOC RR associated with their name in order for location
- information to be accessible.
-
-5.2.2 Searching by Address
-
- If the application is beginning with an IP address (as a "visual
- traceroute" application might be) it MUST first map the address to a
- name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
- 5.2.1), then check for a LOC RR associated with that name.
-
- If there is no LOC RR for the name, the address MAY be checked for
- network (or subnet) LOC RRs using the "Searching by Network or
- Subnet" algorithm (5.2.3).
-
-5.2.3 Searching by Network or Subnet
-
- Even if a host's name does not have any associated LOC RRs, the
- network(s) or subnet(s) it is on may. If the application wishes to
- search for such less specific data, the following algorithm SHOULD be
- followed to find a network or subnet LOC RR associated with the IP
- address. This algorithm is adapted slightly from that specified in
- [RFC 1101], sections 4.3 and 4.4.
-
- Since subnet LOC RRs are (if present) more specific than network LOC
- RRs, it is best to use them if available. In order to do so, we
- build a stack of network and subnet names found while performing the
- [RFC 1101] search, then work our way down the stack until a LOC RR is
- found.
-
- 1. create a host-zero address using the network portion of the IP
- address (one, two, or three bytes for class A, B, or C networks,
- respectively). For example, for the host 128.9.2.17, on the class
- B network 128.9, this would result in the address "128.9.0.0".
-
- 2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
- records. Retrieve:
-
- 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
- A 255.255.255.0
-
- Push the name "isi-net.isi.edu" onto the stack of names to be
- searched for LOC RRs later.
-
-
-
-
-
-
-
-
-Davis, et al Experimental [Page 6]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- 3. Since an A RR was found, repeat using mask from RR
- (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
- Retrieve:
-
- 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
- A 255.255.255.240
-
- Push the name "div2-subnet.isi.edu" onto the stack of names to be
- searched for LOC RRs later.
-
- 4. Since another A RR was found, repeat using mask 255.255.255.240
- (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
- Retrieve:
-
- 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
-
- Push the name "inc-subsubnet.isi.edu" onto the stack of names to
- be searched for LOC RRs later.
-
- 5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
- more subnet levels to search. We now pop the top name from the
- stack and check for an associated LOC RR. Repeat until a LOC RR
- is found.
-
- In this case, assume that inc-subsubnet.isi.edu does not have an
- associated LOC RR, but that div2-subnet.isi.edu does. We will
- then use div2-subnet.isi.edu's LOC RR as an approximation of this
- host's location. (Note that even if isi-net.isi.edu has a LOC RR,
- it will not be used if a subnet also has a LOC RR.)
-
-5.3 Applicability to non-IN Classes and non-IP Addresses
-
- The LOC record is defined for all RR classes, and may be used with
- non-IN classes such as HS and CH. The semantics of such use are not
- defined by this memo.
-
- The search algorithm in section 5.2.3 may be adapted to other
- addressing schemes by extending [RFC 1101]'s encoding of network
- names to cover those schemes. Such extensions are not defined by
- this memo.
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al Experimental [Page 7]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
-6. References
-
- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, USC/Information Sciences Institute,
- November 1987.
-
- [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
- Types", RFC 1101, USC/Information Sciences Institute,
- April 1989.
-
- [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
- Definition and Relationships with Local Geodetic Systems;
- Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
- 138-R; CV, KV;
-
-7. Security Considerations
-
- High-precision LOC RR information could be used to plan a penetration
- of physical security, leading to potential denial-of-machine attacks.
- To avoid any appearance of suggesting this method to potential
- attackers, we declined the opportunity to name this RR "ICBM".
-
-8. Authors' Addresses
-
- The authors as a group can be reached as <loc@pipex.net>.
-
- Christopher Davis
- Kapor Enterprises, Inc.
- 238 Main Street, Suite 400
- Cambridge, MA 02142
-
- Phone: +1 617 576 4532
- EMail: ckd@kei.com
-
-
- Paul Vixie
- Vixie Enterprises
- Star Route Box 159A
- Woodside, CA 94062
-
- Phone: +1 415 747 0204
- EMail: paul@vix.com
-
-
-
-
-
-Davis, et al Experimental [Page 8]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- Tim Goodwin
- Public IP Exchange Ltd (PIPEX)
- 216 The Science Park
- Cambridge CB4 4WA
- UK
-
- Phone: +44 1223 250250
- EMail: tim@pipex.net
-
-
- Ian Dickinson
- FORE Systems
- 2475 The Crescent
- Solihull Parkway
- Birmingham Business Park
- B37 7YE
- UK
-
- Phone: +44 121 717 4444
- EMail: idickins@fore.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al Experimental [Page 9]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
-Appendix A: Sample Conversion Routines
-
-/*
- * routines to convert between on-the-wire RR format and zone file
- * format. Does not contain conversion to/from decimal degrees;
- * divide or multiply by 60*60*1000 for that.
- */
-
-static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
- 1000000,10000000,100000000,1000000000};
-
-/* takes an XeY precision/size value, returns a string representation.*/
-static const char *
-precsize_ntoa(prec)
- u_int8_t prec;
-{
- static char retbuf[sizeof("90000000.00")];
- unsigned long val;
- int mantissa, exponent;
-
- mantissa = (int)((prec >> 4) & 0x0f) % 10;
- exponent = (int)((prec >> 0) & 0x0f) % 10;
-
- val = mantissa * poweroften[exponent];
-
- (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
- return (retbuf);
-}
-
-/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
-static u_int8_t
-precsize_aton(strptr)
- char **strptr;
-{
- unsigned int mval = 0, cmval = 0;
- u_int8_t retval = 0;
- register char *cp;
- register int exponent;
- register int mantissa;
-
- cp = *strptr;
-
- while (isdigit(*cp))
- mval = mval * 10 + (*cp++ - '0');
-
- if (*cp == '.') { /* centimeters */
- cp++;
- if (isdigit(*cp)) {
-
-
-
-Davis, et al Experimental [Page 10]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- cmval = (*cp++ - '0') * 10;
- if (isdigit(*cp)) {
- cmval += (*cp++ - '0');
- }
- }
- }
- cmval = (mval * 100) + cmval;
-
- for (exponent = 0; exponent < 9; exponent++)
- if (cmval < poweroften[exponent+1])
- break;
-
- mantissa = cmval / poweroften[exponent];
- if (mantissa > 9)
- mantissa = 9;
-
- retval = (mantissa << 4) | exponent;
-
- *strptr = cp;
-
- return (retval);
-}
-
-/* converts ascii lat/lon to unsigned encoded 32-bit number.
- * moves pointer. */
-static u_int32_t
-latlon2ul(latlonstrptr,which)
- char **latlonstrptr;
- int *which;
-{
- register char *cp;
- u_int32_t retval;
- int deg = 0, min = 0, secs = 0, secsfrac = 0;
-
- cp = *latlonstrptr;
-
- while (isdigit(*cp))
- deg = deg * 10 + (*cp++ - '0');
-
- while (isspace(*cp))
- cp++;
-
- if (!(isdigit(*cp)))
- goto fndhemi;
-
- while (isdigit(*cp))
- min = min * 10 + (*cp++ - '0');
-
-
-
-
-Davis, et al Experimental [Page 11]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- while (isspace(*cp))
- cp++;
-
- if (!(isdigit(*cp)))
- goto fndhemi;
-
- while (isdigit(*cp))
- secs = secs * 10 + (*cp++ - '0');
-
- if (*cp == '.') { /* decimal seconds */
- cp++;
- if (isdigit(*cp)) {
- secsfrac = (*cp++ - '0') * 100;
- if (isdigit(*cp)) {
- secsfrac += (*cp++ - '0') * 10;
- if (isdigit(*cp)) {
- secsfrac += (*cp++ - '0');
- }
- }
- }
- }
-
- while (!isspace(*cp)) /* if any trailing garbage */
- cp++;
-
- while (isspace(*cp))
- cp++;
-
- fndhemi:
- switch (*cp) {
- case 'N': case 'n':
- case 'E': case 'e':
- retval = ((unsigned)1<<31)
- + (((((deg * 60) + min) * 60) + secs) * 1000)
- + secsfrac;
- break;
- case 'S': case 's':
- case 'W': case 'w':
- retval = ((unsigned)1<<31)
- - (((((deg * 60) + min) * 60) + secs) * 1000)
- - secsfrac;
- break;
- default:
- retval = 0; /* invalid value -- indicates error */
- break;
- }
-
- switch (*cp) {
-
-
-
-Davis, et al Experimental [Page 12]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- case 'N': case 'n':
- case 'S': case 's':
- *which = 1; /* latitude */
- break;
- case 'E': case 'e':
- case 'W': case 'w':
- *which = 2; /* longitude */
- break;
- default:
- *which = 0; /* error */
- break;
- }
-
- cp++; /* skip the hemisphere */
-
- while (!isspace(*cp)) /* if any trailing garbage */
- cp++;
-
- while (isspace(*cp)) /* move to next field */
- cp++;
-
- *latlonstrptr = cp;
-
- return (retval);
-}
-
-/* converts a zone file representation in a string to an RDATA
- * on-the-wire representation. */
-u_int32_t
-loc_aton(ascii, binary)
- const char *ascii;
- u_char *binary;
-{
- const char *cp, *maxcp;
- u_char *bcp;
-
- u_int32_t latit = 0, longit = 0, alt = 0;
- u_int32_t lltemp1 = 0, lltemp2 = 0;
- int altmeters = 0, altfrac = 0, altsign = 1;
- u_int8_t hp = 0x16; /* default = 1e6 cm = 10000.00m = 10km */
- u_int8_t vp = 0x13; /* default = 1e3 cm = 10.00m */
- u_int8_t siz = 0x12; /* default = 1e2 cm = 1.00m */
- int which1 = 0, which2 = 0;
-
- cp = ascii;
- maxcp = cp + strlen(ascii);
-
- lltemp1 = latlon2ul(&cp, &which1);
-
-
-
-Davis, et al Experimental [Page 13]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- lltemp2 = latlon2ul(&cp, &which2);
-
- switch (which1 + which2) {
- case 3: /* 1 + 2, the only valid combination */
- if ((which1 == 1) && (which2 == 2)) { /* normal case */
- latit = lltemp1;
- longit = lltemp2;
- } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
- longit = lltemp1;
- latit = lltemp2;
- } else { /* some kind of brokenness */
- return 0;
- }
- break;
- default: /* we didn't get one of each */
- return 0;
- }
-
- /* altitude */
- if (*cp == '-') {
- altsign = -1;
- cp++;
- }
-
- if (*cp == '+')
- cp++;
-
- while (isdigit(*cp))
- altmeters = altmeters * 10 + (*cp++ - '0');
-
- if (*cp == '.') { /* decimal meters */
- cp++;
- if (isdigit(*cp)) {
- altfrac = (*cp++ - '0') * 10;
- if (isdigit(*cp)) {
- altfrac += (*cp++ - '0');
- }
- }
- }
-
- alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
-
- while (!isspace(*cp) && (cp < maxcp))
- /* if trailing garbage or m */
- cp++;
-
- while (isspace(*cp) && (cp < maxcp))
- cp++;
-
-
-
-Davis, et al Experimental [Page 14]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- if (cp >= maxcp)
- goto defaults;
-
- siz = precsize_aton(&cp);
-
- while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
- cp++;
-
- while (isspace(*cp) && (cp < maxcp))
- cp++;
-
- if (cp >= maxcp)
- goto defaults;
-
- hp = precsize_aton(&cp);
-
- while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
- cp++;
-
- while (isspace(*cp) && (cp < maxcp))
- cp++;
-
- if (cp >= maxcp)
- goto defaults;
-
- vp = precsize_aton(&cp);
-
- defaults:
-
- bcp = binary;
- *bcp++ = (u_int8_t) 0; /* version byte */
- *bcp++ = siz;
- *bcp++ = hp;
- *bcp++ = vp;
- PUTLONG(latit,bcp);
- PUTLONG(longit,bcp);
- PUTLONG(alt,bcp);
-
- return (16); /* size of RR in octets */
-}
-
-/* takes an on-the-wire LOC RR and prints it in zone file
- * (human readable) format. */
-char *
-loc_ntoa(binary,ascii)
- const u_char *binary;
- char *ascii;
-{
-
-
-
-Davis, et al Experimental [Page 15]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- static char tmpbuf[255*3];
-
- register char *cp;
- register const u_char *rcp;
-
- int latdeg, latmin, latsec, latsecfrac;
- int longdeg, longmin, longsec, longsecfrac;
- char northsouth, eastwest;
- int altmeters, altfrac, altsign;
-
- const int referencealt = 100000 * 100;
-
- int32_t latval, longval, altval;
- u_int32_t templ;
- u_int8_t sizeval, hpval, vpval, versionval;
-
- char *sizestr, *hpstr, *vpstr;
-
- rcp = binary;
- if (ascii)
- cp = ascii;
- else {
- cp = tmpbuf;
- }
-
- versionval = *rcp++;
-
- if (versionval) {
- sprintf(cp,"; error: unknown LOC RR version");
- return (cp);
- }
-
- sizeval = *rcp++;
-
- hpval = *rcp++;
- vpval = *rcp++;
-
- GETLONG(templ,rcp);
- latval = (templ - ((unsigned)1<<31));
-
- GETLONG(templ,rcp);
- longval = (templ - ((unsigned)1<<31));
-
- GETLONG(templ,rcp);
- if (templ < referencealt) { /* below WGS 84 spheroid */
- altval = referencealt - templ;
- altsign = -1;
- } else {
-
-
-
-Davis, et al Experimental [Page 16]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- altval = templ - referencealt;
- altsign = 1;
- }
-
- if (latval < 0) {
- northsouth = 'S';
- latval = -latval;
- }
- else
- northsouth = 'N';
-
- latsecfrac = latval % 1000;
- latval = latval / 1000;
- latsec = latval % 60;
- latval = latval / 60;
- latmin = latval % 60;
- latval = latval / 60;
- latdeg = latval;
-
- if (longval < 0) {
- eastwest = 'W';
- longval = -longval;
- }
- else
- eastwest = 'E';
-
- longsecfrac = longval % 1000;
- longval = longval / 1000;
- longsec = longval % 60;
- longval = longval / 60;
- longmin = longval % 60;
- longval = longval / 60;
- longdeg = longval;
-
- altfrac = altval % 100;
- altmeters = (altval / 100) * altsign;
-
- sizestr = savestr(precsize_ntoa(sizeval));
- hpstr = savestr(precsize_ntoa(hpval));
- vpstr = savestr(precsize_ntoa(vpval));
-
- sprintf(cp,
- "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
- %sm %sm %sm",
- latdeg, latmin, latsec, latsecfrac, northsouth,
- longdeg, longmin, longsec, longsecfrac, eastwest,
- altmeters, altfrac, sizestr, hpstr, vpstr);
-
-
-
-
-Davis, et al Experimental [Page 17]
-
-RFC 1876 Location Information in the DNS January 1996
-
-
- free(sizestr);
- free(hpstr);
- free(vpstr);
-
- return (cp);
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al Experimental [Page 18]
-
diff --git a/contrib/bind9/doc/rfc/rfc1886.txt b/contrib/bind9/doc/rfc/rfc1886.txt
deleted file mode 100644
index 9874fddb17a51..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1886.txt
+++ /dev/null
@@ -1,268 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Thomson
-Request for Comments: 1886 Bellcore
-Category: Standards Track C. Huitema
- INRIA
- December 1995
-
-
- DNS Extensions to support IP version 6
-
-
-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.
-
-
-Abstract
-
- This document defines the changes that need to be made to the Domain
- Name System to support hosts running IP version 6 (IPv6). The
- changes include a new resource record type to store an IPv6 address,
- a new domain to support lookups based on an IPv6 address, and updated
- definitions of existing query types that return Internet addresses as
- part of additional section processing. The extensions are designed
- to be compatible with existing applications and, in particular, DNS
- implementations themselves.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thompson & Huitema Standards Track [Page 1]
-
-RFC 1886 IPv6 DNS Extensions December 1995
-
-
-1. INTRODUCTION
-
- Current support for the storage of Internet addresses in the Domain
- Name System (DNS)[1,2] cannot easily be extended to support IPv6
- addresses[3] since applications assume that address queries return
- 32-bit IPv4 addresses only.
-
- To support the storage of IPv6 addresses we define the following
- extensions:
-
- o A new resource record type is defined to map a domain name to an
- IPv6 address.
-
- o A new domain is defined to support lookups based on address.
-
- o Existing queries that perform additional section processing to
- locate IPv4 addresses are redefined to perform additional
- section processing on both IPv4 and IPv6 addresses.
-
- The changes are designed to be compatible with existing software. The
- existing support for IPv4 addresses is retained. Transition issues
- related to the co-existence of both IPv4 and IPv6 addresses in DNS
- are discussed in [4].
-
-
-2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
-
- A new record type is defined to store a host's IPv6 address. A host
- that has more than one IPv6 address must have more than one such
- record.
-
-
-2.1 AAAA record type
-
- The AAAA resource record type is a new record specific to the
- Internet class that stores a single IPv6 address.
-
- The value of the type is 28 (decimal).
-
-
-2.2 AAAA data format
-
- A 128 bit IPv6 address is encoded in the data portion of an AAAA
- resource record in network byte order (high-order byte first).
-
-
-
-
-Thompson & Huitema Standards Track [Page 2]
-
-RFC 1886 IPv6 DNS Extensions December 1995
-
-
-2.3 AAAA query
-
- An AAAA query for a specified domain name in the Internet class
- returns all associated AAAA resource records in the answer section of
- a response.
-
- A type AAAA query does not perform additional section processing.
-
-
-2.4 Textual format of AAAA records
-
- The textual representation of the data portion of the AAAA resource
- record used in a master database file is the textual representation
- of a IPv6 address as defined in [3].
-
-
-2.5 IP6.INT Domain
-
- A special domain is defined to look up a record given an address. The
- intent of this domain is to provide a way of mapping an IPv6 address
- to a host name, although it may be used for other purposes as well.
- The domain is rooted at IP6.INT.
-
- An IPv6 address is represented as a name in the IP6.INT domain by a
- sequence of nibbles separated by dots with the suffix ".IP6.INT". The
- sequence of nibbles is encoded in reverse order, i.e. the low-order
- nibble is encoded first, followed by the next low-order nibble and so
- on. Each nibble is represented by a hexadecimal digit. For example,
- the inverse lookup domain name corresponding to the address
-
- 4321:0:1:2:3:4:567:89ab
-
- would be
-
-b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
-
-
-
-3. MODIFICATIONS TO EXISTING QUERY TYPES
-
- All existing query types that perform type A additional section
- processing, i.e. name server (NS), mail exchange (MX) and mailbox
- (MB) query types, must be redefined to perform both type A and type
- AAAA additional section processing. These new definitions mean that a
- name server must add any relevant IPv4 addresses and any relevant
-
-
-
-Thompson & Huitema Standards Track [Page 3]
-
-RFC 1886 IPv6 DNS Extensions December 1995
-
-
- IPv6 addresses available locally to the additional section of a
- response when processing any one of the above queries.
-
-
-4. SECURITY CONSIDERATIONS
-
- Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thompson & Huitema Standards Track [Page 4]
-
-RFC 1886 IPv6 DNS Extensions December 1995
-
-
-5. REFERENCES
-
-
- [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [2] Mockapetris, P., "Domain Names - Implementation and Specifica-
- tion", STD 13, RFC 1035, USC/Information Sciences Institute,
- November 1987.
-
- [3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
- Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
- 1995.
-
-
- [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
- Hosts and Routers", Work in Progress.
-
-
-Authors' Addresses
-
- Susan Thomson
- Bellcore
- MRE 2P343
- 445 South Street
- Morristown, NJ 07960
- U.S.A.
-
- Phone: +1 201-829-4514
- EMail: set@thumper.bellcore.com
-
-
- Christian Huitema
- INRIA, Sophia-Antipolis
- 2004 Route des Lucioles
- BP 109
- F-06561 Valbonne Cedex
- France
-
- Phone: +33 93 65 77 15
- EMail: Christian.Huitema@MIRSA.INRIA.FR
-
-
-
-
-
-
-
-Thompson & Huitema Standards Track [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc1982.txt b/contrib/bind9/doc/rfc/rfc1982.txt
deleted file mode 100644
index 5a34bc42ab72f..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1982.txt
+++ /dev/null
@@ -1,394 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Elz
-Request for Comments: 1982 University of Melbourne
-Updates: 1034, 1035 R. Bush
-Category: Standards Track RGnet, Inc.
- August 1996
-
-
- Serial Number Arithmetic
-
-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.
-
-Abstract
-
- This memo defines serial number arithmetic, as used in the Domain
- Name System. The DNS has long relied upon serial number arithmetic,
- a concept which has never really been defined, certainly not in an
- IETF document, though which has been widely understood. This memo
- supplies the missing definition. It is intended to update RFC1034
- and RFC1035.
-
-1. Introduction
-
- The serial number field of the SOA resource record is defined in
- RFC1035 as
-
- SERIAL The unsigned 32 bit version number of the original copy of
- the zone. Zone transfers preserve this value. This value
- wraps and should be compared using sequence space
- arithmetic.
-
- RFC1034 uses the same terminology when defining secondary server zone
- consistency procedures.
-
- Unfortunately the term "sequence space arithmetic" is not defined in
- either RFC1034 or RFC1035, nor do any of their references provide
- further information.
-
- This phrase seems to have been intending to specify arithmetic as
- used in TCP sequence numbers [RFC793], and defined in [IEN-74].
-
- Unfortunately, the arithmetic defined in [IEN-74] is not adequate for
- the purposes of the DNS, as no general comparison operator is
-
-
-
-Elz & Bush Standards Track [Page 1]
-
-RFC 1982 Serial Number Arithmetic August 1996
-
-
- defined.
-
- To avoid further problems with this simple field, this document
- defines the field and the operations available upon it. This
- definition is intended merely to clarify the intent of RFC1034 and
- RFC1035, and is believed to generally agree with current
- implementations. However, older, superseded, implementations are
- known to have treated the serial number as a simple unsigned integer,
- with no attempt to implement any kind of "sequence space arithmetic",
- however that may have been interpreted, and further, ignoring the
- requirement that the value wraps. Nothing can be done with these
- implementations, beyond extermination.
-
-2. Serial Number Arithmetic
-
- Serial numbers are formed from non-negative integers from a finite
- subset of the range of all integer values. The lowest integer in
- every subset used for this purpose is zero, the maximum is always one
- less than a power of two.
-
- When considered as serial numbers however no value has any particular
- significance, there is no minimum or maximum serial number, every
- value has a successor and predecessor.
-
- To define a serial number to be used in this way, the size of the
- serial number space must be given. This value, called "SERIAL_BITS",
- gives the power of two which results in one larger than the largest
- integer corresponding to a serial number value. This also specifies
- the number of bits required to hold every possible value of a serial
- number of the defined type. The operations permitted upon serial
- numbers are defined in the following section.
-
-3. Operations upon the serial number
-
- Only two operations are defined upon serial numbers, addition of a
- positive integer of limited range, and comparison with another serial
- number.
-
-3.1. Addition
-
- Serial numbers may be incremented by the addition of a positive
- integer n, where n is taken from the range of integers
- [0 .. (2^(SERIAL_BITS - 1) - 1)]. For a sequence number s, the
- result of such an addition, s', is defined as
-
- s' = (s + n) modulo (2 ^ SERIAL_BITS)
-
-
-
-
-
-Elz & Bush Standards Track [Page 2]
-
-RFC 1982 Serial Number Arithmetic August 1996
-
-
- where the addition and modulus operations here act upon values that
- are non-negative values of unbounded size in the usual ways of
- integer arithmetic.
-
- Addition of a value outside the range
- [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.
-
-3.2. Comparison
-
- Any two serial numbers, s1 and s2, may be compared. The definition
- of the result of this comparison is as follows.
-
- For the purposes of this definition, consider two integers, i1 and
- i2, from the unbounded set of non-negative integers, such that i1 and
- s1 have the same numeric value, as do i2 and s2. Arithmetic and
- comparisons applied to i1 and i2 use ordinary unbounded integer
- arithmetic.
-
- Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,
- in all other cases, s1 is not equal to s2.
-
- s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
- and
-
- (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or
- (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))
-
- s1 is said to be greater than s2 if, and only if, s1 is not equal to
- s2, and
-
- (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
- (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))
-
- Note that there are some pairs of values s1 and s2 for which s1 is
- not equal to s2, but for which s1 is neither greater than, nor less
- than, s2. An attempt to use these ordering operators on such pairs
- of values produces an undefined result.
-
- The reason for this is that those pairs of values are such that any
- simple definition that were to define s1 to be less than s2 where
- (s1, s2) is such a pair, would also usually cause s2 to be less than
- s1, when the pair is (s2, s1). This would mean that the particular
- order selected for a test could cause the result to differ, leading
- to unpredictable implementations.
-
- While it would be possible to define the test in such a way that the
- inequality would not have this surprising property, while being
- defined for all pairs of values, such a definition would be
-
-
-
-Elz & Bush Standards Track [Page 3]
-
-RFC 1982 Serial Number Arithmetic August 1996
-
-
- unnecessarily burdensome to implement, and difficult to understand,
- and would still allow cases where
-
- s1 < s2 and (s1 + 1) > (s2 + 1)
-
- which is just as non-intuitive.
-
- Thus the problem case is left undefined, implementations are free to
- return either result, or to flag an error, and users must take care
- not to depend on any particular outcome. Usually this will mean
- avoiding allowing those particular pairs of numbers to co-exist.
-
- The relationships greater than or equal to, and less than or equal
- to, follow in the natural way from the above definitions.
-
-4. Corollaries
-
- These definitions give rise to some results of note.
-
-4.1. Corollary 1
-
- For any sequence number s and any integer n such that addition of n
- to s is well defined, (s + n) >= s. Further (s + n) == s only when
- n == 0, in all other defined cases, (s + n) > s.
-
-4.2. Corollary 2
-
- If s' is the result of adding the non-zero integer n to the sequence
- number s, and m is another integer from the range defined as able to
- be added to a sequence number, and s" is the result of adding m to
- s', then it is undefined whether s" is greater than, or less than s,
- though it is known that s" is not equal to s.
-
-4.3. Corollary 3
-
- If s" from the previous corollary is further incremented, then there
- is no longer any known relationship between the result and s.
-
-4.4. Corollary 4
-
- If in corollary 2 the value (n + m) is such that addition of the sum
- to sequence number s would produce a defined result, then corollary 1
- applies, and s" is known to be greater than s.
-
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 4]
-
-RFC 1982 Serial Number Arithmetic August 1996
-
-
-5. Examples
-
-5.1. A trivial example
-
- The simplest meaningful serial number space has SERIAL_BITS == 2. In
- this space, the integers that make up the serial number space are 0,
- 1, 2, and 3. That is, 3 == 2^SERIAL_BITS - 1.
-
- In this space, the largest integer that it is meaningful to add to a
- sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.
-
- Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.
- Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3. It is undefined whether
- 2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.
-
-5.2. A slightly larger example
-
- Consider the case where SERIAL_BITS == 8. In this space the integers
- that make up the serial number space are 0, 1, 2, ... 254, 255.
- 255 == 2^SERIAL_BITS - 1.
-
- In this space, the largest integer that it is meaningful to add to a
- sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.
-
- Addition is as expected in this space, for example: 255+1 == 0,
- 100+100 == 200, and 200+100 == 44.
-
- Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,
- 200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.
-
- Note that 100+100 > 100, but that (100+100)+100 < 100. Incrementing
- a serial number can cause it to become "smaller". Of course,
- incrementing by a smaller number will allow many more increments to
- be made before this occurs. However this is always something to be
- aware of, it can cause surprising errors, or be useful as it is the
- only defined way to actually cause a serial number to decrease.
-
- The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and
- 255 are not equal, but in each pair, neither number is defined as
- being greater than, or less than, the other.
-
- It could be defined (arbitrarily) that 128 > 0, 129 > 1,
- 130 > 2, ..., 255 > 127, by changing the comparison operator
- definitions, as mentioned above. However note that that would cause
- 255 > 127, while (255 + 1) < (127 + 1), as 0 < 128. Such a
- definition, apart from being arbitrary, would also be more costly to
- implement.
-
-
-
-
-Elz & Bush Standards Track [Page 5]
-
-RFC 1982 Serial Number Arithmetic August 1996
-
-
-6. Citation
-
- As this defined arithmetic may be useful for purposes other than for
- the DNS serial number, it may be referenced as Serial Number
- Arithmetic from RFC1982. Any such reference shall be taken as
- implying that the rules of sections 2 to 5 of this document apply to
- the stated values.
-
-7. The DNS SOA serial number
-
- The serial number in the DNS SOA Resource Record is a Serial Number
- as defined above, with SERIAL_BITS being 32. That is, the serial
- number is a non negative integer with values taken from the range
- [0 .. 4294967295]. That is, a 32 bit unsigned integer.
-
- The maximum defined increment is 2147483647 (2^31 - 1).
-
- Care should be taken that the serial number not be incremented, in
- one or more steps, by more than this maximum within the period given
- by the value of SOA.expire. Doing so may leave some secondary
- servers with out of date copies of the zone, but with a serial number
- "greater" than that of the primary server. Of course, special
- circumstances may require this rule be set aside, for example, when
- the serial number needs to be set lower for some reason. If this
- must be done, then take special care to verify that ALL servers have
- correctly succeeded in following the primary server's serial number
- changes, at each step.
-
- Note that each, and every, increment to the serial number must be
- treated as the start of a new sequence of increments for this
- purpose, as well as being the continuation of all previous sequences
- started within the period specified by SOA.expire.
-
- Caution should also be exercised before causing the serial number to
- be set to the value zero. While this value is not in any way special
- in serial number arithmetic, or to the DNS SOA serial number, many
- DNS implementations have incorrectly treated zero as a special case,
- with special properties, and unusual behaviour may be expected if
- zero is used as a DNS SOA serial number.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 6]
-
-RFC 1982 Serial Number Arithmetic August 1996
-
-
-8. Document Updates
-
- RFC1034 and RFC1035 are to be treated as if the references to
- "sequence space arithmetic" therein are replaced by references to
- serial number arithmetic, as defined in this document.
-
-9. Security Considerations
-
- This document does not consider security.
-
- It is not believed that anything in this document adds to any
- security issues that may exist with the DNS, nor does it do anything
- to lessen them.
-
-References
-
- [RFC1034] Domain Names - Concepts and Facilities,
- P. Mockapetris, STD 13, ISI, November 1987.
-
- [RFC1035] Domain Names - Implementation and Specification
- P. Mockapetris, STD 13, ISI, November 1987
-
- [RFC793] Transmission Control protocol
- Information Sciences Institute, STD 7, USC, September 1981
-
- [IEN-74] Sequence Number Arithmetic
- William W. Plummer, BB&N Inc, September 1978
-
-Acknowledgements
-
- Thanks to Rob Austein for suggesting clarification of the undefined
- comparison operators, and to Michael Patton for attempting to locate
- another reference for this procedure. Thanks also to members of the
- IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.
-
-Authors' Addresses
-
- Robert Elz Randy Bush
- Computer Science RGnet, Inc.
- University of Melbourne 10361 NE Sasquatch Lane
- Parkville, Vic, 3052 Bainbridge Island, Washington, 98110
- Australia. United States.
-
- EMail: kre@munnari.OZ.AU EMail: randy@psg.com
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 7]
diff --git a/contrib/bind9/doc/rfc/rfc1995.txt b/contrib/bind9/doc/rfc/rfc1995.txt
deleted file mode 100644
index b50bdc604870c..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1995.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Ohta
-Request for Comments: 1995 Tokyo Institute of Technology
-Updates: 1035 August 1996
-Category: Standards Track
-
-
- Incremental Zone Transfer 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.
-
-Abstract
-
- This document proposes extensions to the DNS protocols to provide an
- incremental zone transfer (IXFR) mechanism.
-
-1. Introduction
-
- For rapid propagation of changes to a DNS database [STD13], it is
- necessary to reduce latency by actively notifying servers of the
- change. This is accomplished by the NOTIFY extension of the DNS
- [NOTIFY].
-
- The current full zone transfer mechanism (AXFR) is not an efficient
- means to propagate changes to a small part of a zone, as it transfers
- the entire zone file.
-
- Incremental transfer (IXFR) as proposed is a more efficient
- mechanism, as it transfers only the changed portion(s) of a zone.
-
- In this document, a secondary name server which requests IXFR is
- called an IXFR client and a primary or secondary name server which
- responds to the request is called an IXFR server.
-
-2. Brief Description of the Protocol
-
- If an IXFR client, which likely has an older version of a zone,
- thinks it needs new information about the zone (typically through SOA
- refresh timeout or the NOTIFY mechanism), it sends an IXFR message
- containing the SOA serial number of its, presumably outdated, copy of
- the zone.
-
-
-
-
-
-Ohta Standards Track [Page 1]
-
-RFC 1995 Incremental Zone Transfer in DNS August 1996
-
-
- An IXFR server should keep record of the newest version of the zone
- and the differences between that copy and several older versions.
- When an IXFR request with an older version number is received, the
- IXFR server needs to send only the differences required to make that
- version current. Alternatively, the server may choose to transfer
- the entire zone just as in a normal full zone transfer.
-
- When a zone has been updated, it should be saved in stable storage
- before the new version is used to respond to IXFR (or AXFR) queries.
- Otherwise, if the server crashes, data which is no longer available
- may have been distributed to secondary servers, which can cause
- persistent database inconsistencies.
-
- If an IXFR query with the same or newer version number than that of
- the server is received, it is replied to with a single SOA record of
- the server's current version, just as in AXFR.
-
- Transport of a query may be by either UDP or TCP. If an IXFR query
- is via UDP, the IXFR server may attempt to reply using UDP if the
- entire response can be contained in a single DNS packet. If the UDP
- reply does not fit, the query is responded to with a single SOA
- record of the server's current version to inform the client that a
- TCP query should be initiated.
-
- Thus, a client should first make an IXFR query using UDP. If the
- query type is not recognized by the server, an AXFR (preceded by a
- UDP SOA query) should be tried, ensuring backward compatibility. If
- the query response is a single packet with the entire new zone, or if
- the server does not have a newer version than the client, everything
- is done. Otherwise, a TCP IXFR query should be tried.
-
- To ensure integrity, servers should use UDP checksums for all UDP
- responses. A cautious client which receives a UDP packet with a
- checksum value of zero should ignore the result and try a TCP IXFR
- instead.
-
- The query type value of IXFR assigned by IANA is 251.
-
-3. Query Format
-
- The IXFR query packet format is the same as that of a normal DNS
- query, but with the query type being IXFR and the authority section
- containing the SOA record of client's version of the zone.
-
-
-
-
-
-
-
-
-Ohta Standards Track [Page 2]
-
-RFC 1995 Incremental Zone Transfer in DNS August 1996
-
-
-4. Response Format
-
- If incremental zone transfer is not available, the entire zone is
- returned. The first and the last RR of the response is the SOA
- record of the zone. I.e. the behavior is the same as an AXFR
- response except the query type is IXFR.
-
- If incremental zone transfer is available, one or more difference
- sequences is returned. The list of difference sequences is preceded
- and followed by a copy of the server's current version of the SOA.
-
- Each difference sequence represents one update to the zone (one SOA
- serial change) consisting of deleted RRs and added RRs. The first RR
- of the deleted RRs is the older SOA RR and the first RR of the added
- RRs is the newer SOA RR.
-
- Modification of an RR is performed first by removing the original RR
- and then adding the modified one.
-
- The sequences of differential information are ordered oldest first
- newest last. Thus, the differential sequences are the history of
- changes made since the version known by the IXFR client up to the
- server's current version.
-
- RRs in the incremental transfer messages may be partial. That is, if
- a single RR of multiple RRs of the same RR type changes, only the
- changed RR is transferred.
-
- An IXFR client, should only replace an older version with a newer
- version after all the differences have been successfully processed.
-
- An incremental response is different from that of a non-incremental
- response in that it begins with two SOA RRs, the server's current SOA
- followed by the SOA of the client's version which is about to be
- replaced.
-
- 5. Purging Strategy
-
- An IXFR server can not be required to hold all previous versions
- forever and may delete them anytime. In general, there is a trade-off
- between the size of storage space and the possibility of using IXFR.
-
- Information about older versions should be purged if the total length
- of an IXFR response would be longer than that of an AXFR response.
- Given that the purpose of IXFR is to reduce AXFR overhead, this
- strategy is quite reasonable. The strategy assures that the amount
- of storage required is at most twice that of the current zone
- information.
-
-
-
-Ohta Standards Track [Page 3]
-
-RFC 1995 Incremental Zone Transfer in DNS August 1996
-
-
- Information older than the SOA expire period may also be purged.
-
-6. Optional Condensation of Multiple Versions
-
- An IXFR server may optionally condense multiple difference sequences
- into a single difference sequence, thus, dropping information on
- intermediate versions.
-
- This may be beneficial if a lot of versions, not all of which are
- useful, are generated. For example, if multiple ftp servers share a
- single DNS name and the IP address associated with the name is
- changed once a minute to balance load between the ftp servers, it is
- not so important to keep track of all the history of changes.
-
- But, this feature may not be so useful if an IXFR client has access
- to two IXFR servers: A and B, with inconsistent condensation results.
- The current version of the IXFR client, received from server A, may
- be unknown to server B. In such a case, server B can not provide
- incremental data from the unknown version and a full zone transfer is
- necessary.
-
- Condensation is completely optional. Clients can't detect from the
- response whether the server has condensed the reply or not.
-
- For interoperability, IXFR servers, including those without the
- condensation feature, should not flag an error even if it receives a
- client's IXFR request with a unknown version number and should,
- instead, attempt to perform a full zone transfer.
-
-7. Example
-
- Given the following three generations of data with the current serial
- number of 3,
-
- JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
- 1 600 600 3600000 604800)
- IN NS NS.JAIN.AD.JP.
- NS.JAIN.AD.JP. IN A 133.69.136.1
- NEZU.JAIN.AD.JP. IN A 133.69.136.5
-
- NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
-
- jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
- 2 600 600 3600000 604800)
- IN NS NS.JAIN.AD.JP.
- NS.JAIN.AD.JP. IN A 133.69.136.1
- JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4
- IN A 192.41.197.2
-
-
-
-Ohta Standards Track [Page 4]
-
-RFC 1995 Incremental Zone Transfer in DNS August 1996
-
-
- One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
-
- JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
- 3 600 600 3600000 604800)
- IN NS NS.JAIN.AD.JP.
- NS.JAIN.AD.JP. IN A 133.69.136.1
- JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3
- IN A 192.41.197.2
-
- The following IXFR query
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY |
- +---------------------------------------------------+
- Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
- +---------------------------------------------------+
- Answer | <empty> |
- +---------------------------------------------------+
- Authority | JAIN.AD.JP. IN SOA serial=1 |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
- could be replied to with the following full zone transfer message:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
- +---------------------------------------------------+
- Answer | JAIN.AD.JP. IN SOA serial=3 |
- | JAIN.AD.JP. IN NS NS.JAIN.AD.JP. |
- | NS.JAIN.AD.JP. IN A 133.69.136.1 |
- | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
- | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
- | JAIN.AD.JP. IN SOA serial=3 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-
-
-
-
-
-
-
-
-
-Ohta Standards Track [Page 5]
-
-RFC 1995 Incremental Zone Transfer in DNS August 1996
-
-
- or with the following incremental message:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
- +---------------------------------------------------+
- Answer | JAIN.AD.JP. IN SOA serial=3 |
- | JAIN.AD.JP. IN SOA serial=1 |
- | NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
- | JAIN.AD.JP. IN SOA serial=2 |
- | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
- | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
- | JAIN.AD.JP. IN SOA serial=2 |
- | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
- | JAIN.AD.JP. IN SOA serial=3 |
- | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
- | JAIN.AD.JP. IN SOA serial=3 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
- or with the following condensed incremental message:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
- +---------------------------------------------------+
- Answer | JAIN.AD.JP. IN SOA serial=3 |
- | JAIN.AD.JP. IN SOA serial=1 |
- | NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
- | JAIN.AD.JP. IN SOA serial=3 |
- | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
- | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
- | JAIN.AD.JP. IN SOA serial=3 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-
-
-
-
-
-
-
-Ohta Standards Track [Page 6]
-
-RFC 1995 Incremental Zone Transfer in DNS August 1996
-
-
- or, if UDP packet overflow occurs, with the following message:
-
- +---------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE |
- +---------------------------------------------------+
- Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
- +---------------------------------------------------+
- Answer | JAIN.AD.JP. IN SOA serial=3 |
- +---------------------------------------------------+
- Authority | <empty> |
- +---------------------------------------------------+
- Additional | <empty> |
- +---------------------------------------------------+
-
-8. Acknowledgements
-
- The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
- and Jon Postel.
-
- For the refinement of the protocol and documentation, many people
- have contributed including, but not limited to, Anant Kumar, Robert
- Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
- members of the IETF DNSIND working group.
-
-9. References
-
- [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
- Notification of Zone Changes", RFC 1996, August 1996.
-
- [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
- RFC 1035), November 1987.
-
-10. Security Considerations
-
- Though DNS is related to several security problems, no attempt is
- made to fix them in this document.
-
- This document is believed to introduce no additional security
- problems to the current DNS protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta Standards Track [Page 7]
-
-RFC 1995 Incremental Zone Transfer in DNS August 1996
-
-
-11. Author's Address
-
- Masataka Ohta
- Computer Center
- Tokyo Institute of Technology
- 2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
-
- Phone: +81-3-5734-3299
- Fax: +81-3-5734-3415
- EMail: mohta@necom830.hpcl.titech.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta Standards Track [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc1996.txt b/contrib/bind9/doc/rfc/rfc1996.txt
deleted file mode 100644
index b08f2007972f6..0000000000000
--- a/contrib/bind9/doc/rfc/rfc1996.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Vixie
-Request for Comments: 1996 ISC
-Updates: 1035 August 1996
-Category: Standards Track
-
-
- A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
-
-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.
-
-Abstract
-
- This memo describes the NOTIFY opcode for DNS, by which a master
- server advises a set of slave servers that the master's data has been
- changed and that a query should be initiated to discover the new
- data.
-
-1. Rationale and Scope
-
- 1.1. Slow propagation of new and changed data in a DNS zone can be
- due to a zone's relatively long refresh times. Longer refresh times
- are beneficial in that they reduce load on the master servers, but
- that benefit comes at the cost of long intervals of incoherence among
- authority servers whenever the zone is updated.
-
- 1.2. The DNS NOTIFY transaction allows master servers to inform slave
- servers when the zone has changed -- an interrupt as opposed to poll
- model -- which it is hoped will reduce propagation delay while not
- unduly increasing the masters' load. This specification only allows
- slaves to be notified of SOA RR changes, but the architechture of
- NOTIFY is intended to be extensible to other RR types.
-
- 1.3. This document intentionally gives more definition to the roles
- of "Master," "Slave" and "Stealth" servers, their enumeration in NS
- RRs, and the SOA MNAME field. In that sense, this document can be
- considered an addendum to [RFC1035].
-
-
-
-
-
-
-
-
-
-Vixie Standards Track [Page 1]
-
-RFC 1996 DNS NOTIFY August 1996
-
-
-2. Definitions and Invariants
-
- 2.1. The following definitions are used in this document:
-
- Slave an authoritative server which uses zone transfer to
- retrieve the zone. All slave servers are named in
- the NS RRs for the zone.
-
- Master any authoritative server configured to be the source
- of zone transfer for one or more slave servers.
-
- Primary Master master server at the root of the zone transfer
- dependency graph. The primary master is named in the
- zone's SOA MNAME field and optionally by an NS RR.
- There is by definition only one primary master server
- per zone.
-
- Stealth like a slave server except not listed in an NS RR for
- the zone. A stealth server, unless explicitly
- configured to do otherwise, will set the AA bit in
- responses and be capable of acting as a master. A
- stealth server will only be known by other servers if
- they are given static configuration data indicating
- its existence.
-
- Notify Set set of servers to be notified of changes to some
- zone. Default is all servers named in the NS RRset,
- except for any server also named in the SOA MNAME.
- Some implementations will permit the name server
- administrator to override this set or add elements to
- it (such as, for example, stealth servers).
-
- 2.2. The zone's servers must be organized into a dependency graph
- such that there is a primary master, and all other servers must use
- AXFR or IXFR either from the primary master or from some slave which
- is also a master. No loops are permitted in the AXFR dependency
- graph.
-
-3. NOTIFY Message
-
- 3.1. When a master has updated one or more RRs in which slave servers
- may be interested, the master may send the changed RR's name, class,
- type, and optionally, new RDATA(s), to each known slave server using
- a best efforts protocol based on the NOTIFY opcode.
-
- 3.2. NOTIFY uses the DNS Message Format, although it uses only a
- subset of the available fields. Fields not otherwise described
- herein are to be filled with binary zero (0), and implementations
-
-
-
-Vixie Standards Track [Page 2]
-
-RFC 1996 DNS NOTIFY August 1996
-
-
- must ignore all messages for which this is not the case.
-
- 3.3. NOTIFY is similar to QUERY in that it has a request message with
- the header QR flag "clear" and a response message with QR "set". The
- response message contains no useful information, but its reception by
- the master is an indication that the slave has received the NOTIFY
- and that the master can remove the slave from any retry queue for
- this NOTIFY event.
-
- 3.4. The transport protocol used for a NOTIFY transaction will be UDP
- unless the master has reason to believe that TCP is necessary; for
- example, if a firewall has been installed between master and slave,
- and only TCP has been allowed; or, if the changed RR is too large to
- fit in a UDP/DNS datagram.
-
- 3.5. If TCP is used, both master and slave must continue to offer
- name service during the transaction, even when the TCP transaction is
- not making progress. The NOTIFY request is sent once, and a
- "timeout" is said to have occurred if no NOTIFY response is received
- within a reasonable interval.
-
- 3.6. If UDP is used, a master periodically sends a NOTIFY request to
- a slave until either too many copies have been sent (a "timeout"), an
- ICMP message indicating that the port is unreachable, or until a
- NOTIFY response is received from the slave with a matching query ID,
- QNAME, IP source address, and UDP source port number.
-
- Note:
- The interval between transmissions, and the total number of
- retransmissions, should be operational parameters specifiable by
- the name server administrator, perhaps on a per-zone basis.
- Reasonable defaults are a 60 second interval (or timeout if
- using TCP), and a maximum of 5 retransmissions (for UDP). It is
- considered reasonable to use additive or exponential backoff for
- the retry interval.
-
- 3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
- ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an
- unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A
- slave receiving such a hint is free to treat equivilence of this
- answer section with its local data as a "no further work needs to be
- done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section
- differs from the slave's local data, then the slave should query its
- known masters to retrieve the new data.
-
- 3.8. In no case shall the answer section of a NOTIFY request be used
- to update a slave's local data, or to indicate that a zone transfer
- needs to be undertaken, or to change the slave's zone refresh timers.
-
-
-
-Vixie Standards Track [Page 3]
-
-RFC 1996 DNS NOTIFY August 1996
-
-
- Only a "data present; data same" condition can lead a slave to act
- differently if ANCOUNT>0 than it would if ANCOUNT=0.
-
- 3.9. This version of the NOTIFY specification makes no use of the
- authority or additional data sections, and so conforming
- implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
- requests. Since a future revision of this specification may define a
- backwards compatible use for either or both of these sections,
- current implementations must ignore these sections, but not the
- entire message, if AUCOUNT>0 and/or ADCOUNT>0.
-
- 3.10. If a slave receives a NOTIFY request from a host that is not a
- known master for the zone containing the QNAME, it should ignore the
- request and produce an error message in its operations log.
-
- Note:
- This implies that slaves of a multihomed master must either know
- their master by the "closest" of the master's interface
- addresses, or must know all of the master's interface addresses.
- Otherwise, a valid NOTIFY request might come from an address
- that is not on the slave's state list of masters for the zone,
- which would be an error.
-
- 3.11. The only defined NOTIFY event at this time is that the SOA RR
- has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA,
- the slave should behave as though the zone given in the QNAME had
- reached its REFRESH interval (see [RFC1035]), i.e., it should query
- its masters for the SOA of the zone given in the NOTIFY QNAME, and
- check the answer to see if the SOA SERIAL has been incremented since
- the last time the zone was fetched. If so, a zone transfer (either
- AXFR or IXFR) should be initiated.
-
- Note:
- Because a deep server dependency graph may have multiple paths
- from the primary master to any given slave, it is possible that
- a slave will receive a NOTIFY from one of its known masters even
- though the rest of its known masters have not yet updated their
- copies of the zone. Therefore, when issuing a QUERY for the
- zone's SOA, the query should be directed at the known master who
- was the source of the NOTIFY event, and not at any of the other
- known masters. This represents a departure from [RFC1035],
- which specifies that upon expiry of the SOA REFRESH interval,
- all known masters should be queried in turn.
-
- 3.12. If a NOTIFY request is received by a slave who does not
- implement the NOTIFY opcode, it will respond with a NOTIMP
- (unimplemented feature error) message. A master server who receives
- such a NOTIMP should consider the NOTIFY transaction complete for
-
-
-
-Vixie Standards Track [Page 4]
-
-RFC 1996 DNS NOTIFY August 1996
-
-
- that slave.
-
-4. Details and Examples
-
- 4.1. Retaining query state information across host reboots is
- optional, but it is reasonable to simply execute an SOA NOTIFY
- transaction on each authority zone when a server first starts.
-
- 4.2. Each slave is likely to receive several copies of the same
- NOTIFY request: One from the primary master, and one from each other
- slave as that slave transfers the new zone and notifies its potential
- peers. The NOTIFY protocol supports this multiplicity by requiring
- that NOTIFY be sent by a slave/master only AFTER it has updated the
- SOA RR or has determined that no update is necessary, which in
- practice means after a successful zone transfer. Thus, barring
- delivery reordering, the last NOTIFY any slave receives will be the
- one indicating the latest change. Since a slave always requests SOAs
- and AXFR/IXFRs only from its known masters, it will have an
- opportunity to retry its QUERY for the SOA after each of its masters
- have completed each zone update.
-
- 4.3. If a master server seeks to avoid causing a large number of
- simultaneous outbound zone transfers, it may delay for an arbitrary
- length of time before sending a NOTIFY message to any given slave.
- It is expected that the time will be chosen at random, so that each
- slave will begin its transfer at a unique time. The delay shall not
- in any case be longer than the SOA REFRESH time.
-
- Note:
- This delay should be a parameter that each primary master name
- server can specify, perhaps on a per-zone basis. Random delays
- of between 30 and 60 seconds would seem adequate if the servers
- share a LAN and the zones are of moderate size.
-
- 4.4. A slave which receives a valid NOTIFY should defer action on any
- subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
- completed the transaction begun by the first NOTIFY. This duplicate
- rejection is necessary to avoid having multiple notifications lead to
- pummeling the master server.
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie Standards Track [Page 5]
-
-RFC 1996 DNS NOTIFY August 1996
-
-
- 4.5 Zone has Updated on Primary Master
-
- Primary master sends a NOTIFY request to all servers named in Notify
- Set. The NOTIFY request has the following characteristics:
-
- query ID: (new)
- op: NOTIFY (4)
- resp: NOERROR
- flags: AA
- qcount: 1
- qname: (zone name)
- qclass: (zone class)
- qtype: T_SOA
-
- 4.6 Zone has Updated on a Slave that is also a Master
-
- As above in 4.5, except that this server's Notify Set may be
- different from the Primary Master's due to optional static
- specification of local stealth servers.
-
- 4.7 Slave Receives a NOTIFY Request from a Master
-
- When a slave server receives a NOTIFY request from one of its locally
- designated masters for the zone enclosing the given QNAME, with
- QTYPE=SOA and QR=0, it should enter the state it would if the zone's
- refresh timer had expired. It will also send a NOTIFY response back
- to the NOTIFY request's source, with the following characteristics:
-
- query ID: (same)
- op: NOTIFY (4)
- resp: NOERROR
- flags: QR AA
- qcount: 1
- qname: (zone name)
- qclass: (zone class)
- qtype: T_SOA
-
- This is intended to be identical to the NOTIFY request, except that
- the QR bit is also set. The query ID of the response must be the
- same as was received in the request.
-
- 4.8 Master Receives a NOTIFY Response from Slave
-
- When a master server receives a NOTIFY response, it deletes this
- query from the retry queue, thus completing the "notification
- process" of "this" RRset change to "that" server.
-
-
-
-
-
-Vixie Standards Track [Page 6]
-
-RFC 1996 DNS NOTIFY August 1996
-
-
-5. Security Considerations
-
- We believe that the NOTIFY operation's only security considerations
- are:
-
- 1. That a NOTIFY request with a forged IP/UDP source address can
- cause a slave to send spurious SOA queries to its masters,
- leading to a benign denial of service attack if the forged
- requests are sent very often.
-
- 2. That TCP spoofing could be used against a slave server given
- NOTIFY as a means of synchronizing an SOA query and UDP/DNS
- spoofing as a means of forcing a zone transfer.
-
-6. References
-
- [RFC1035]
- Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [IXFR]
- Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
-
-7. Author's Address
-
- Paul Vixie
- Internet Software Consortium
- Star Route Box 159A
- Woodside, CA 94062
-
- Phone: +1 415 747 0204
- EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie Standards Track [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2052.txt b/contrib/bind9/doc/rfc/rfc2052.txt
deleted file mode 100644
index 46ba36296b969..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2052.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Gulbrandsen
-Request for Comments: 2052 Troll Technologies
-Updates: 1035, 1183 P. Vixie
-Category: Experimental Vixie Enterprises
- October 1996
-
-
- A DNS RR for specifying the location of services (DNS SRV)
-
-Status of this Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. This memo does not specify an Internet standard of any
- kind. Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-Abstract
-
- This document describes a DNS RR which specifies the location of the
- server(s) for a specific protocol and domain (like a more general
- form of MX).
-
-Overview and rationale
-
- Currently, one must either know the exact address of a server to
- contact it, or broadcast a question. This has led to, for example,
- ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
- level broadcasts to locate servers.
-
- The SRV RR allows administrators to use several servers for a single
- domain, to move services from host to host with little fuss, and to
- designate some hosts as primary servers for a service and others as
- backups.
-
- Clients ask for a specific service/protocol for a specific domain
- (the word domain is used here in the strict RFC 1034 sense), and get
- back the names of any available servers.
-
-Introductory example
-
- When a SRV-cognizant web-browser wants to retrieve
-
- http://www.asdf.com/
-
- it does a lookup of
-
- http.tcp.www.asdf.com
-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 1]
-
-RFC 2052 DNS SRV RR October 1996
-
-
- and retrieves the document from one of the servers in the reply. The
- example zone file near the end of the memo contains answering RRs for
- this query.
-
-The format of the SRV RR
-
- Here is the format of the SRV RR, whose DNS type code is 33:
-
- Service.Proto.Name TTL Class SRV Priority Weight Port Target
-
- (There is an example near the end of this document.)
-
- Service
- The symbolic name of the desired service, as defined in Assigned
- Numbers or locally.
-
- Some widely used services, notably POP, don't have a single
- universal name. If Assigned Numbers names the service
- indicated, that name is the only name which is legal for SRV
- lookups. Only locally defined services may be named locally.
- The Service is case insensitive.
-
- Proto
- TCP and UDP are at present the most useful values
- for this field, though any name defined by Assigned Numbers or
- locally may be used (as for Service). The Proto is case
- insensitive.
-
- 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.
-
- TTL
- Standard DNS meaning.
-
- Class
- Standard DNS meaning.
-
- Priority
- As for MX, the priority of this target host. A client MUST
- attempt to contact the target host with the lowest-numbered
- priority it can reach; target hosts with the same priority
- SHOULD be tried in pseudorandom order. The range is 0-65535.
-
-
-
-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 2]
-
-RFC 2052 DNS SRV RR October 1996
-
-
- Weight
- Load balancing mechanism. When selecting a target host among
- the those that have the same priority, the chance of trying this
- one first SHOULD be proportional to its weight. The range of
- this number is 1-65535. Domain administrators are urged to use
- Weight 0 when there isn't any load balancing to do, to make the
- RR easier to read for humans (less noisy).
-
- Port
- The port on this target host of this service. The range is
- 0-65535. This is often as specified in Assigned Numbers but
- need not be.
-
- Target
- As for MX, the domain name of the target host. There MUST be
- one or more A records for this name. Implementors are urged, but
- not required, to return the A record(s) in the Additional Data
- section. Name compression is to be used for this field.
-
- A Target of "." means that the service is decidedly not
- available at this domain.
-
-Domain administrator advice
-
- Asking everyone to update their telnet (for example) clients when the
- first internet site adds a SRV RR for Telnet/TCP is futile (even if
- desirable). Therefore SRV will have to coexist with A record lookups
- for a long time, and DNS administrators should try to provide A
- records to support old clients:
-
- - Where the services for a single domain are spread over several
- hosts, it seems advisable to have a list of A RRs at the same
- DNS node as the SRV RR, listing reasonable (if perhaps
- suboptimal) fallback hosts for Telnet, NNTP and other protocols
- likely to be used with this name. Note that some programs only
- try the first address they get back from e.g. gethostbyname(),
- and we don't know how widespread this behaviour is.
-
- - Where one service is provided by several hosts, one can either
- provide A records for all the hosts (in which case the round-
- robin mechanism, where available, will share the load equally)
- or just for one (presumably the fastest).
-
- - If a host is intended to provide a service only when the main
- server(s) is/are down, it probably shouldn't be listed in A
- records.
-
-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 3]
-
-RFC 2052 DNS SRV RR October 1996
-
-
- - Hosts that are referenced by backup A records must use the port
- number specified in Assigned Numbers for the service.
-
- Currently there's a practical limit of 512 bytes for DNS replies.
- Until all resolvers can handle larger responses, domain
- administrators are strongly advised to keep their SRV replies below
- 512 bytes.
-
- All round numbers, wrote Dr. Johnson, are false, and these numbers
- are very round: A reply packet has a 30-byte overhead plus the name
- of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
- 20 bytes plus the name of the target host; each NS RR in the NS
- section is 15 bytes plus the name of the name server host; and
- finally each A RR in the additional data section is 20 bytes or so,
- and there are A's for each SRV and NS RR mentioned in the answer.
- This size estimate is extremely crude, but shouldn't underestimate
- the actual answer size by much. If an answer may be close to the
- limit, using e.g. "dig" to look at the actual answer is a good idea.
-
-The "Weight" field
-
- Weight, the load balancing field, is not quite satisfactory, but the
- actual load on typical servers changes much too quickly to be kept
- around in DNS caches. It seems to the authors that offering
- administrators a way to say "this machine is three times as fast as
- that one" is the best that can practically be done.
-
- The only way the authors can see of getting a "better" load figure is
- asking a separate server when the client selects a server and
- contacts it. For short-lived services like SMTP an extra step in the
- connection establishment seems too expensive, and for long-lived
- services like telnet, the load figure may well be thrown off a minute
- after the connection is established when someone else starts or
- finishes a heavy job.
-
-The Port number
-
- Currently, the translation from service name to port number happens
- at the client, often using a file such as /etc/services.
-
- Moving this information to the DNS makes it less necessary to update
- these files on every single computer of the net every time a new
- service is added, and makes it possible to move standard services out
- of the "root-only" port range on unix
-
-
-
-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 4]
-
-RFC 2052 DNS SRV RR October 1996
-
-
-Usage rules
-
- A SRV-cognizant client SHOULD use this procedure to locate a list of
- servers and connect to the preferred one:
-
- Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
- QTYPE=SRV.
-
- If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
- RR which specifies the requested Service and Protocol in the
- reply:
-
- If there is precisely one SRV RR, and its Target is "."
- (the root domain), abort.
-
- Else, for all such RR's, build a list of (Priority, Weight,
- Target) tuples
-
- Sort the list by priority (lowest number first)
-
- Create a new empty list
-
- For each distinct priority level
- While there are still elements left at this priority
- level
- Select an element randomly, with probability
- Weight, and move it to the tail of the new list
-
- For each element in the new list
-
- query the DNS for A RR's for the Target or use any
- RR's found in the Additional Data secion of the
- earlier SRV query.
-
- for each A RR found, try to connect to the (protocol,
- address, service).
-
- else if the service desired is SMTP
-
- skip to RFC 974 (MX).
-
- else
-
- Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
-
- for each A RR found, try to connect to the (protocol,
- address, service)
-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 5]
-
-RFC 2052 DNS SRV RR October 1996
-
-
- Notes:
-
- - Port numbers SHOULD NOT be used in place of the symbolic service
- or protocol names (for the same reason why variant names cannot
- be allowed: Applications would have to do two or more lookups).
-
- - If a truncated response comes back from an SRV query, and the
- Additional Data section has at least one complete RR in it, the
- answer MUST be considered complete and the client resolver
- SHOULD NOT retry the query using TCP, but use normal UDP queries
- for A RR's missing from the Additional Data section.
-
- - A client MAY use means other than Weight to choose among target
- hosts with equal Priority.
-
- - A client MUST parse all of the RR's in the reply.
-
- - If the Additional Data section doesn't contain A RR's for all
- the SRV RR's and the client may want to connect to the target
- host(s) involved, the client MUST look up the A RR(s). (This
- happens quite often when the A RR has shorter TTL than the SRV
- or NS RR's.)
-
- - A future standard could specify that a SRV RR whose Protocol was
- TCP and whose Service was SMTP would override RFC 974's rules
- with regard to the use of an MX RR. This would allow firewalled
- organizations with several SMTP relays to control the load
- distribution using the Weight field.
-
- - Future protocols could be designed to use SRV RR lookups as the
- means by which clients locate their servers.
-
-Fictional example
-
- This is (part of) the zone file for asdf.com, a still-unused domain:
-
- $ORIGIN asdf.com.
- @ SOA server.asdf.com. root.asdf.com. (
- 1995032001 3600 3600 604800 86400 )
- NS server.asdf.com.
- NS ns1.ip-provider.net.
- NS ns2.ip-provider.net.
- ftp.tcp SRV 0 0 21 server.asdf.com.
- finger.tcp SRV 0 0 79 server.asdf.com.
- ; telnet - use old-slow-box or new-fast-box if either is
- ; available, make three quarters of the logins go to
- ; new-fast-box.
- telnet.tcp SRV 0 1 23 old-slow-box.asdf.com.
-
-
-
-Gulbrandsen & Vixie Experimental [Page 6]
-
-RFC 2052 DNS SRV RR October 1996
-
-
- SRV 0 3 23 new-fast-box.asdf.com.
- ; if neither old-slow-box or new-fast-box is up, switch to
- ; using the sysdmin's box and the server
- SRV 1 0 23 sysadmins-box.asdf.com.
- SRV 1 0 23 server.asdf.com.
- ; HTTP - server is the main server, new-fast-box is the backup
- ; (On new-fast-box, the HTTP daemon runs on port 8000)
- http.tcp SRV 0 0 80 server.asdf.com.
- SRV 10 0 8000 new-fast-box.asdf.com.
- ; since we want to support both http://asdf.com/ and
- ; http://www.asdf.com/ we need the next two RRs as well
- http.tcp.www SRV 0 0 80 server.asdf.com.
- SRV 10 0 8000 new-fast-box.asdf.com.
- ; SMTP - mail goes to the server, and to the IP provider if
- ; the net is down
- smtp.tcp SRV 0 0 25 server.asdf.com.
- SRV 1 0 25 mailhost.ip-provider.net.
- @ MX 0 server.asdf.com.
- MX 1 mailhost.ip-provider.net.
- ; NNTP - use the IP providers's NNTP server
- nntp.tcp SRV 0 0 119 nntphost.ip-provider.net.
- ; IDB is an locally defined protocol
- idb.tcp SRV 0 0 2025 new-fast-box.asdf.com.
- ; addresses
- server A 172.30.79.10
- old-slow-box A 172.30.79.11
- sysadmins-box A 172.30.79.12
- new-fast-box A 172.30.79.13
- ; backup A records - new-fast-box and old-slow-box are
- ; included, naturally, and server is too, but might go
- ; if the load got too bad
- @ A 172.30.79.10
- A 172.30.79.11
- A 172.30.79.13
- ; backup A RR for www.asdf.com
- www A 172.30.79.10
- ; NO other services are supported
- *.tcp SRV 0 0 0 .
- *.udp SRV 0 0 0 .
-
- In this example, a telnet connection to "asdf.com." needs an SRV
- lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
- fast-box.asdf.com." and/or the other hosts named. The size of the
- SRV reply is approximately 365 bytes:
-
- 30 bytes general overhead
- 20 bytes for the query string, "telnet.tcp.asdf.com."
- 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 7]
-
-RFC 2052 DNS SRV RR October 1996
-
-
- fast-box", "old-slow-box", "server" and "sysadmins-box" -
- "asdf.com" in the query section is quoted here and doesn't
- need to be counted again.
- 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
- "server", "ns1.ip-provider.net." and "ns2" - again, "ip-
- provider.net." is quoted and only needs to be counted once.
- 120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
-
-Refererences
-
- RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
- and E. Lear, "Address Allocation for Private Internets",
- RFC 1918, February 1996.
-
- RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
- "Enterprise Renumbering: Experience and Information
- Solicitation", RFC 1916, February 1996.
-
- RFC 1912 Barr, D., "Common DNS Operational and Configuration
- Errors", RFC 1912, February 1996.
-
- RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
- RFC 1900, February 1996.
-
- RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
- STD 1, RFC 1920, March 1996.
-
- RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
- 1995.
-
- RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
-
- RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
-
- RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
- "DNS Encoding of Geographical Location", RFC 1712, November
- 1994.
-
- RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
- RFC 1706, October 1994.
-
- RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
- STD 2, RFC 1700, October 1994.
-
- RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
- C. Everhart, "New DNS RR Definitions", RFC 1183, November
- 1990.
-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 8]
-
-RFC 2052 DNS SRV RR October 1996
-
-
- RFC 1101: Mockapetris, P., "DNS encoding of network names and other
- types", RFC 1101, April 1989.
-
- RFC 1035: Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- RFC 1034: Mockapetris, P., "Domain names - concepts and
- facilities", STD 13, RFC 1034, November 1987.
-
- RFC 1033: Lottor, M., "Domain administrators operations guide",
- RFC 1033, November 1987.
-
- RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
- November 1987.
-
- RFC 974: Partridge, C., "Mail routing and the domain system",
- STD 14, RFC 974, January 1986.
-
-Security Considerations
-
- The authors believes this RR to not cause any new security problems.
- Some problems become more visible, though.
-
- - The ability to specify ports on a fine-grained basis obviously
- changes how a router can filter packets. It becomes impossible
- to block internal clients from accessing specific external
- services, slightly harder to block internal users from running
- unautorised services, and more important for the router
- operations and DNS operations personnel to cooperate.
-
- - There is no way a site can keep its hosts from being referenced
- as servers (as, indeed, some sites become unwilling secondary
- MXes today). This could lead to denial of service.
-
- - With SRV, DNS spoofers can supply false port numbers, as well as
- host names and addresses. The authors do not see any practical
- effect of this.
-
- We assume that as the DNS-security people invent new features, DNS
- servers will return the relevant RRs in the Additional Data section
- when answering an SRV query.
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 9]
-
-RFC 2052 DNS SRV RR October 1996
-
-
-Authors' Addresses
-
- Arnt Gulbrandsen
- Troll Tech
- Postboks 6133 Etterstad
- N-0602 Oslo
- Norway
-
- Phone: +47 22646966
- EMail: agulbra@troll.no
-
-
- Paul Vixie
- Vixie Enterprises
- Star Route 159A
- Woodside, CA 94062
-
- Phone: (415) 747-0204
- EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen & Vixie Experimental [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2104.txt b/contrib/bind9/doc/rfc/rfc2104.txt
deleted file mode 100644
index a205103a2ede5..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2104.txt
+++ /dev/null
@@ -1,620 +0,0 @@
-
-
-
-
-
-
-Network Working Group H. Krawczyk
-Request for Comments: 2104 IBM
-Category: Informational M. Bellare
- UCSD
- R. Canetti
- IBM
- February 1997
-
-
- HMAC: Keyed-Hashing for Message Authentication
-
-Status of This Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-Abstract
-
- This document describes HMAC, a mechanism for message authentication
- using cryptographic hash functions. HMAC can be used with any
- iterative cryptographic hash function, e.g., MD5, SHA-1, in
- combination with a secret shared key. The cryptographic strength of
- HMAC depends on the properties of the underlying hash function.
-
-1. Introduction
-
- Providing a way to check the integrity of information transmitted
- over or stored in an unreliable medium is a prime necessity in the
- world of open computing and communications. Mechanisms that provide
- such integrity check based on a secret key are usually called
- "message authentication codes" (MAC). Typically, message
- authentication codes are used between two parties that share a secret
- key in order to validate information transmitted between these
- parties. In this document we present such a MAC mechanism based on
- cryptographic hash functions. This mechanism, called HMAC, is based
- on work by the authors [BCK1] where the construction is presented and
- cryptographically analyzed. We refer to that work for the details on
- the rationale and security analysis of HMAC, and its comparison to
- other keyed-hash methods.
-
-
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al. Informational [Page 1]
-
-RFC 2104 HMAC February 1997
-
-
- HMAC can be used in combination with any iterated cryptographic hash
- function. MD5 and SHA-1 are examples of such hash functions. HMAC
- also uses a secret key for calculation and verification of the
- message authentication values. The main goals behind this
- construction are
-
- * To use, without modifications, available hash functions.
- In particular, hash functions that perform well in software,
- and for which code is freely and widely available.
-
- * To preserve the original performance of the hash function without
- incurring a significant degradation.
-
- * To use and handle keys in a simple way.
-
- * To have a well understood cryptographic analysis of the strength of
- the authentication mechanism based on reasonable assumptions on the
- underlying hash function.
-
- * To allow for easy replaceability of the underlying hash function in
- case that faster or more secure hash functions are found or
- required.
-
- This document specifies HMAC using a generic cryptographic hash
- function (denoted by H). Specific instantiations of HMAC need to
- define a particular hash function. Current candidates for such hash
- functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
- These different realizations of HMAC will be denoted by HMAC-SHA1,
- HMAC-MD5, HMAC-RIPEMD, etc.
-
- Note: To the date of writing of this document MD5 and SHA-1 are the
- most widely used cryptographic hash functions. MD5 has been recently
- shown to be vulnerable to collision search attacks [Dobb]. This
- attack and other currently known weaknesses of MD5 do not compromise
- the use of MD5 within HMAC as specified in this document (see
- [Dobb]); however, SHA-1 appears to be a cryptographically stronger
- function. To this date, MD5 can be considered for use in HMAC for
- applications where the superior performance of MD5 is critical. In
- any case, implementers and users need to be aware of possible
- cryptanalytic developments regarding any of these cryptographic hash
- functions, and the eventual need to replace the underlying hash
- function. (See section 6 for more information on the security of
- HMAC.)
-
-
-
-
-
-
-
-
-Krawczyk, et. al. Informational [Page 2]
-
-RFC 2104 HMAC February 1997
-
-
-2. Definition of HMAC
-
- The definition of HMAC requires a cryptographic hash function, which
- we denote by H, and a secret key K. We assume H to be a cryptographic
- hash function where data is hashed by iterating a basic compression
- function on blocks of data. We denote by B the byte-length of such
- blocks (B=64 for all the above mentioned examples of hash functions),
- and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
- SHA-1). The authentication key K can be of any length up to B, the
- block length of the hash function. Applications that use keys longer
- than B bytes will first hash the key using H and then use the
- resultant L byte string as the actual key to HMAC. In any case the
- minimal recommended length for K is L bytes (as the hash output
- length). See section 3 for more information on keys.
-
- We define two fixed and different strings ipad and opad as follows
- (the 'i' and 'o' are mnemonics for inner and outer):
-
- ipad = the byte 0x36 repeated B times
- opad = the byte 0x5C repeated B times.
-
- To compute HMAC over the data `text' we perform
-
- H(K XOR opad, H(K XOR ipad, text))
-
- Namely,
-
- (1) append zeros to the end of K to create a B byte string
- (e.g., if K is of length 20 bytes and B=64, then K will be
- appended with 44 zero bytes 0x00)
- (2) XOR (bitwise exclusive-OR) the B byte string computed in step
- (1) with ipad
- (3) append the stream of data 'text' to the B byte string resulting
- from step (2)
- (4) apply H to the stream generated in step (3)
- (5) XOR (bitwise exclusive-OR) the B byte string computed in
- step (1) with opad
- (6) append the H result from step (4) to the B byte string
- resulting from step (5)
- (7) apply H to the stream generated in step (6) and output
- the result
-
- For illustration purposes, sample code based on MD5 is provided as an
- appendix.
-
-
-
-
-
-
-
-Krawczyk, et. al. Informational [Page 3]
-
-RFC 2104 HMAC February 1997
-
-
-3. Keys
-
- The key for HMAC can be of any length (keys longer than B bytes are
- first hashed using H). However, less than L bytes is strongly
- discouraged as it would decrease the security strength of the
- function. Keys longer than L bytes are acceptable but the extra
- length would not significantly increase the function strength. (A
- longer key may be advisable if the randomness of the key is
- considered weak.)
-
- Keys need to be chosen at random (or using a cryptographically strong
- pseudo-random generator seeded with a random seed), and periodically
- refreshed. (Current attacks do not indicate a specific recommended
- frequency for key changes as these attacks are practically
- infeasible. However, 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.)
-
-4. Implementation Note
-
- HMAC is defined in such a way that the underlying hash function H can
- be used with no modification to its code. In particular, it uses the
- function H with the pre-defined initial value IV (a fixed value
- specified by each iterative hash function to initialize its
- compression function). However, if desired, a performance
- improvement can be achieved at the cost of (possibly) modifying the
- code of H to support variable IVs.
-
- The idea is that the intermediate results of the compression function
- on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
- only once at the time of generation of the key K, or before its first
- use. These intermediate results are stored and then used to
- initialize the IV of H each time that a message needs to be
- authenticated. This method saves, for each authenticated message,
- the application of the compression function of H on two B-byte blocks
- (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
- significant when authenticating short streams of data. We stress
- that the stored intermediate values need to be treated and protected
- the same as secret keys.
-
- Choosing to implement HMAC in the above way is a decision of the
- local implementation and has no effect on inter-operability.
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al. Informational [Page 4]
-
-RFC 2104 HMAC February 1997
-
-
-5. Truncated output
-
- A well-known practice with message authentication codes is to
- truncate the output of the MAC and output only part of the bits
- (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some
- analytical advantages of truncating the output of hash-based MAC
- functions. The results in this area are not absolute as for the
- overall security advantages of truncation. It has advantages (less
- information on the hash result available to an attacker) and
- disadvantages (less bits to predict for the attacker). Applications
- of HMAC can choose to truncate the output of HMAC by outputting the t
- leftmost bits of the HMAC computation for some parameter t (namely,
- the computation is carried in the normal way as defined in section 2
- above but the end result is truncated to t bits). We recommend that
- the output length t be not less than half the length of the hash
- output (to match the birthday attack bound) and not less than 80 bits
- (a suitable lower bound on the number of bits that need to be
- predicted by an attacker). We propose denoting a realization of HMAC
- that uses a hash function H with t bits of output as HMAC-H-t. For
- example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
- and with the output truncated to 80 bits. (If the parameter t is not
- specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
- hash are output.)
-
-6. Security
-
- The security of the message authentication mechanism presented here
- depends on cryptographic properties of the hash function H: the
- resistance to collision finding (limited to the case where the
- initial value is secret and random, and where the output of the
- function is not explicitly available to the attacker), and the
- message authentication property of the compression function of H when
- applied to single blocks (in HMAC these blocks are partially unknown
- to an attacker as they contain the result of the inner H computation
- and, in particular, cannot be fully chosen by the attacker).
-
- These properties, and actually stronger ones, are commonly assumed
- for hash functions of the kind used with HMAC. In particular, a hash
- function for which the above properties do not hold would become
- unsuitable for most (probably, all) cryptographic applications,
- including alternative message authentication schemes based on such
- functions. (For a complete analysis and rationale of the HMAC
- function the reader is referred to [BCK1].)
-
-
-
-
-
-
-
-
-Krawczyk, et. al. Informational [Page 5]
-
-RFC 2104 HMAC February 1997
-
-
- Given the limited confidence gained so far as for the cryptographic
- strength of candidate hash functions, it is important to observe the
- following two properties of the HMAC construction and its secure use
- for message authentication:
-
- 1. The construction is independent of the details of the particular
- hash function H in use and then the latter can be replaced by any
- other secure (iterative) cryptographic hash function.
-
- 2. Message authentication, as opposed to encryption, has a
- "transient" effect. A published breaking of a message authentication
- scheme would lead to the replacement of that scheme, but would have
- no adversarial effect on information authenticated in the past. This
- is in sharp contrast with encryption, where information encrypted
- today may suffer from exposure in the future if, and when, the
- encryption algorithm is broken.
-
- The strongest attack known against HMAC is based on the frequency of
- collisions for the hash function H ("birthday attack") [PV,BCK2], and
- is totally impractical for minimally reasonable hash functions.
-
- As an example, if we consider a hash function like MD5 where the
- output length equals L=16 bytes (128 bits) the attacker needs to
- acquire the correct message authentication tags computed (with the
- _same_ secret key K!) on about 2**64 known plaintexts. This would
- require the processing of at least 2**64 blocks under H, an
- impossible task in any realistic scenario (for a block length of 64
- bytes this would take 250,000 years in a continuous 1Gbps link, and
- without changing the secret key K during all this time). This attack
- could become realistic only if serious flaws in the collision
- behavior of the function H are discovered (e.g. collisions found
- after 2**30 messages). Such a discovery would determine the immediate
- replacement of the function H (the effects of such failure would be
- far more severe for the traditional uses of H in the context of
- digital signatures, public key certificates, etc.).
-
- Note: this attack needs to be strongly contrasted with regular
- collision attacks on cryptographic hash functions where no secret key
- is involved and where 2**64 off-line parallelizable (!) operations
- suffice to find collisions. The latter attack is approaching
- feasibility [VW] while the birthday attack on HMAC is totally
- impractical. (In the above examples, if one uses a hash function
- with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
-
-
-
-
-
-
-
-
-Krawczyk, et. al. Informational [Page 6]
-
-RFC 2104 HMAC February 1997
-
-
- A correct implementation of the above construction, the choice of
- random (or cryptographically pseudorandom) keys, a secure key
- exchange mechanism, frequent key refreshments, and good secrecy
- protection of keys are all essential ingredients for the security of
- the integrity verification mechanism provided by HMAC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al. Informational [Page 7]
-
-RFC 2104 HMAC February 1997
-
-
-Appendix -- Sample Code
-
- For the sake of illustration we provide the following sample code for
- the implementation of HMAC-MD5 as well as some corresponding test
- vectors (the code is based on MD5 code as described in [MD5]).
-
-/*
-** Function: hmac_md5
-*/
-
-void
-hmac_md5(text, text_len, key, key_len, digest)
-unsigned char* text; /* pointer to data stream */
-int text_len; /* length of data stream */
-unsigned char* key; /* pointer to authentication key */
-int key_len; /* length of authentication key */
-caddr_t digest; /* caller digest to be filled in */
-
-{
- MD5_CTX context;
- unsigned char k_ipad[65]; /* inner padding -
- * key XORd with ipad
- */
- unsigned char k_opad[65]; /* outer padding -
- * key XORd with opad
- */
- unsigned char tk[16];
- int i;
- /* if key is longer than 64 bytes reset it to key=MD5(key) */
- if (key_len > 64) {
-
- MD5_CTX tctx;
-
- MD5Init(&tctx);
- MD5Update(&tctx, key, key_len);
- MD5Final(tk, &tctx);
-
- key = tk;
- key_len = 16;
- }
-
- /*
- * the HMAC_MD5 transform looks like:
- *
- * MD5(K XOR opad, MD5(K XOR ipad, text))
- *
- * where K is an n byte key
- * ipad is the byte 0x36 repeated 64 times
-
-
-
-Krawczyk, et. al. Informational [Page 8]
-
-RFC 2104 HMAC February 1997
-
-
- * opad is the byte 0x5c repeated 64 times
- * and text is the data being protected
- */
-
- /* start out by storing key in pads */
- bzero( k_ipad, sizeof k_ipad);
- bzero( k_opad, sizeof k_opad);
- bcopy( key, k_ipad, key_len);
- bcopy( key, k_opad, key_len);
-
- /* XOR key with ipad and opad values */
- for (i=0; i<64; i++) {
- k_ipad[i] ^= 0x36;
- k_opad[i] ^= 0x5c;
- }
- /*
- * perform inner MD5
- */
- MD5Init(&context); /* init context for 1st
- * pass */
- MD5Update(&context, k_ipad, 64) /* start with inner pad */
- MD5Update(&context, text, text_len); /* then text of datagram */
- MD5Final(digest, &context); /* finish up 1st pass */
- /*
- * perform outer MD5
- */
- MD5Init(&context); /* init context for 2nd
- * pass */
- MD5Update(&context, k_opad, 64); /* start with outer pad */
- MD5Update(&context, digest, 16); /* then results of 1st
- * hash */
- MD5Final(digest, &context); /* finish up 2nd pass */
-}
-
-Test Vectors (Trailing '\0' of a character string not included in test):
-
- key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
- key_len = 16 bytes
- data = "Hi There"
- data_len = 8 bytes
- digest = 0x9294727a3638bb1c13f48ef8158bfc9d
-
- key = "Jefe"
- data = "what do ya want for nothing?"
- data_len = 28 bytes
- digest = 0x750c783e6ab0b503eaa86e310a5db738
-
- key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
-
-
-
-Krawczyk, et. al. Informational [Page 9]
-
-RFC 2104 HMAC February 1997
-
-
- key_len 16 bytes
- data = 0xDDDDDDDDDDDDDDDDDDDD...
- ..DDDDDDDDDDDDDDDDDDDD...
- ..DDDDDDDDDDDDDDDDDDDD...
- ..DDDDDDDDDDDDDDDDDDDD...
- ..DDDDDDDDDDDDDDDDDDDD
- data_len = 50 bytes
- digest = 0x56be34521d144c88dbb8c733f0e8b3f6
-
-Acknowledgments
-
- Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
- useful comments on early drafts, and ran the first interoperability
- tests of this specification. Jeff and Pau-Chen kindly provided the
- sample code and test vectors that appear in the appendix. Burt
- Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
- Oorschot have provided useful comments and suggestions during the
- investigation of the HMAC construction.
-
-References
-
- [ANSI] ANSI X9.9, "American National Standard for Financial
- Institution Message Authentication (Wholesale)," American
- Bankers Association, 1981. Revised 1986.
-
- [Atk] Atkinson, R., "IP Authentication Header", RFC 1826, August
- 1995.
-
- [BCK1] M. Bellare, R. Canetti, and H. Krawczyk,
- "Keyed Hash Functions and Message Authentication",
- Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
- (http://www.research.ibm.com/security/keyed-md5.html)
-
- [BCK2] M. Bellare, R. Canetti, and H. Krawczyk,
- "Pseudorandom Functions Revisited: The Cascade Construction",
- Proceedings of FOCS'96.
-
- [Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack",
- RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
- http://www.rsa.com/rsalabs/pubs/cryptobytes.html
-
- [PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash
- functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
- Lecture Notes in Computer Science, Springer-Verlag Vol.963,
- 1995, pp. 1-14.
-
- [MD5] Rivest, R., "The MD5 Message-Digest Algorithm",
- RFC 1321, April 1992.
-
-
-
-Krawczyk, et. al. Informational [Page 10]
-
-RFC 2104 HMAC February 1997
-
-
- [MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
- 1982.
-
- [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
- strengthened version of RIPEMD", Fast Software Encryption,
- LNCS Vol 1039, pp. 71-82.
- ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
-
- [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
-
- [Tsu] G. Tsudik, "Message authentication with one-way hash
- functions", In Proceedings of Infocom'92, May 1992.
- (Also in "Access Control and Policy Enforcement in
- Internetworks", Ph.D. Dissertation, Computer Science
- Department, University of Southern California, April 1991.)
-
- [VW] P. van Oorschot and M. Wiener, "Parallel Collision
- Search with Applications to Hash Functions and Discrete
- Logarithms", Proceedings of the 2nd ACM Conf. Computer and
- Communications Security, Fairfax, VA, November 1994.
-
-Authors' Addresses
-
- Hugo Krawczyk
- IBM T.J. Watson Research Center
- P.O.Box 704
- Yorktown Heights, NY 10598
-
- EMail: hugo@watson.ibm.com
-
- Mihir Bellare
- Dept of Computer Science and Engineering
- Mail Code 0114
- University of California at San Diego
- 9500 Gilman Drive
- La Jolla, CA 92093
-
- EMail: mihir@cs.ucsd.edu
-
- Ran Canetti
- IBM T.J. Watson Research Center
- P.O.Box 704
- Yorktown Heights, NY 10598
-
- EMail: canetti@watson.ibm.com
-
-
-
-
-
-
-Krawczyk, et. al. Informational [Page 11]
-
-
diff --git a/contrib/bind9/doc/rfc/rfc2119.txt b/contrib/bind9/doc/rfc/rfc2119.txt
deleted file mode 100644
index e31fae47fd1ff..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2119.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Bradner
-Request for Comments: 2119 Harvard University
-BCP: 14 March 1997
-Category: Best Current Practice
-
-
- Key words for use in RFCs to Indicate Requirement Levels
-
-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.
-
-Abstract
-
- In many standards track documents several words are used to signify
- the requirements in the specification. These words are often
- capitalized. This document defines these words as they should be
- interpreted in IETF documents. Authors who follow these guidelines
- should incorporate this phrase near the beginning of their 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.
-
- Note that the force of these words is modified by the requirement
- level of the document in which they are used.
-
-1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
- definition is an absolute requirement of the specification.
-
-2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
- definition is an absolute prohibition of the specification.
-
-3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
- may exist valid reasons in particular circumstances to ignore a
- particular item, but the full implications must be understood and
- carefully weighed before choosing a different course.
-
-4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
- there may exist valid reasons in particular circumstances when the
- particular behavior is acceptable or even useful, but the full
- implications should be understood and the case carefully weighed
- before implementing any behavior described with this label.
-
-
-
-
-
-Bradner Best Current Practice [Page 1]
-
-RFC 2119 RFC Key Words March 1997
-
-
-5. MAY This word, or the adjective "OPTIONAL", mean that an item is
- truly optional. One vendor may choose to include the item because a
- particular marketplace requires it or because the vendor feels that
- it enhances the product while another vendor may omit the same item.
- An implementation which does not include a particular option MUST be
- prepared to interoperate with another implementation which does
- include the option, though perhaps with reduced functionality. In the
- same vein an implementation which does include a particular option
- MUST be prepared to interoperate with another implementation which
- does not include the option (except, of course, for the feature the
- option provides.)
-
-6. Guidance in the use of these Imperatives
-
- Imperatives of the type defined in this memo must be used with care
- and sparingly. In particular, they MUST only be used where it is
- actually required for interoperation or to limit behavior which has
- potential for causing harm (e.g., limiting retransmisssions) For
- example, they must not be used to try to impose a particular method
- on implementors where the method is not required for
- interoperability.
-
-7. Security Considerations
-
- These terms are frequently used to specify behavior with security
- implications. The effects on security of not implementing a MUST or
- SHOULD, or doing something the specification says MUST NOT or SHOULD
- NOT be done may be very subtle. Document authors should take the time
- to elaborate the security implications of not following
- recommendations or requirements as most implementors will not have
- had the benefit of the experience and discussion that produced the
- specification.
-
-8. Acknowledgments
-
- The definitions of these terms are an amalgam of definitions taken
- from a number of RFCs. In addition, suggestions have been
- incorporated from a number of people including Robert Ullmann, Thomas
- Narten, Neal McBurnett, and Robert Elz.
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner Best Current Practice [Page 2]
-
-RFC 2119 RFC Key Words March 1997
-
-
-9. Author's Address
-
- Scott Bradner
- Harvard University
- 1350 Mass. Ave.
- Cambridge, MA 02138
-
- phone - +1 617 495 3864
-
- email - sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner Best Current Practice [Page 3]
-
diff --git a/contrib/bind9/doc/rfc/rfc2133.txt b/contrib/bind9/doc/rfc/rfc2133.txt
deleted file mode 100644
index ea66cf0126794..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2133.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Gilligan
-Request for Comments: 2133 Freegate
-Category: Informational S. Thomson
- Bellcore
- J. Bound
- Digital
- W. Stevens
- Consultant
- April 1997
-
- Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-Abstract
-
- The de facto standard application program interface (API) for TCP/IP
- applications is the "sockets" interface. Although this API was
- developed for Unix in the early 1980s it has also been implemented on
- a wide variety of non-Unix systems. TCP/IP applications written
- using the sockets API have in the past enjoyed a high degree of
- portability and we would like the same portability with IPv6
- applications. But changes are required to the sockets API to support
- IPv6 and this memo describes these changes. These include a new
- socket address structure to carry IPv6 addresses, new address
- conversion functions, and some new socket options. These extensions
- are designed to provide access to the basic IPv6 features required by
- TCP and UDP applications, including multicasting, while introducing a
- minimum of change into the system and providing complete
- compatibility for existing IPv4 applications. Additional extensions
- for advanced IPv6 features (raw sockets and access to the IPv6
- extension headers) are defined in another document [5].
-
-Table of Contents
-
- 1. Introduction ................................................ 2
- 2. Design Considerations ....................................... 3
- 2.1. What Needs to be Changed .................................. 3
- 2.2. Data Types ................................................ 5
- 2.3. Headers ................................................... 5
- 2.4. Structures ................................................ 5
- 3. Socket Interface ............................................ 5
- 3.1. IPv6 Address Family and Protocol Family ................... 5
- 3.2. IPv6 Address Structure .................................... 6
-
-
-
-Gilligan, et. al. Informational [Page 1]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- 3.3. Socket Address Structure for 4.3BSD-Based Systems ......... 6
- 3.4. Socket Address Structure for 4.4BSD-Based Systems ......... 7
- 3.5. The Socket Functions ...................................... 8
- 3.6. Compatibility with IPv4 Applications ...................... 9
- 3.7. Compatibility with IPv4 Nodes ............................. 9
- 3.8. IPv6 Wildcard Address ..................................... 10
- 3.9. IPv6 Loopback Address ..................................... 11
- 4. Interface Identification .................................... 12
- 4.1. Name-to-Index ............................................. 13
- 4.2. Index-to-Name ............................................. 13
- 4.3. Return All Interface Names and Indexes .................... 14
- 4.4. Free Memory ............................................... 14
- 5. Socket Options .............................................. 14
- 5.1. Changing Socket Type ...................................... 15
- 5.2. Unicast Hop Limit ......................................... 16
- 5.3. Sending and Receiving Multicast Packets ................... 17
- 6. Library Functions ........................................... 19
- 6.1. Hostname-to-Address Translation ........................... 19
- 6.2. Address To Hostname Translation ........................... 22
- 6.3. Protocol-Independent Hostname and Service Name Translation 22
- 6.4. Socket Address Structure to Hostname and Service Name ..... 25
- 6.5. Address Conversion Functions .............................. 27
- 6.6. Address Testing Macros .................................... 28
- 7. Summary of New Definitions .................................. 29
- 8. Security Considerations ..................................... 31
- 9. Acknowledgments ............................................. 31
- 10. References ................................................. 31
- 11. Authors' Addresses ......................................... 32
-
-1. Introduction
-
- While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
- by 128-bit addresses. The socket interface make the size of an IP
- address quite visible to an application; virtually all TCP/IP
- applications for BSD-based systems have knowledge of the size of an
- IP address. Those parts of the API that expose the addresses must be
- changed to accommodate the larger IPv6 address size. IPv6 also
- introduces new features (e.g., flow label and priority), some of
- which must be made visible to applications via the API. This memo
- defines a set of extensions to the socket interface to support the
- larger address size and new features of IPv6.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 2]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
-2. Design Considerations
-
- There are a number of important considerations in designing changes
- to this well-worn API:
-
- - The API changes should provide both source and binary
- compatibility for programs written to the original API. That is,
- existing program binaries should continue to operate when run on
- a system supporting the new API. In addition, existing
- applications that are re-compiled and run on a system supporting
- the new API should continue to operate. Simply put, the API
- changes for IPv6 should not break existing programs.
-
- - The changes to the API should be as small as possible in order to
- simplify the task of converting existing IPv4 applications to
- IPv6.
-
- - Where possible, applications should be able to use this API to
- interoperate with both IPv6 and IPv4 hosts. Applications should
- not need to know which type of host they are communicating with.
-
- - IPv6 addresses carried in data structures should be 64-bit
- aligned. This is necessary in order to obtain optimum
- performance on 64-bit machine architectures.
-
- Because of the importance of providing IPv4 compatibility in the API,
- these extensions are explicitly designed to operate on machines that
- provide complete support for both IPv4 and IPv6. A subset of this
- API could probably be designed for operation on systems that support
- only IPv6. However, this is not addressed in this memo.
-
-2.1. What Needs to be Changed
-
- The socket interface API consists of a few distinct components:
-
- - Core socket functions.
-
- - Address data structures.
-
- - Name-to-address translation functions.
-
- - Address conversion functions.
-
- The core socket functions -- those functions that deal with such
- things as setting up and tearing down TCP connections, and sending
- and receiving UDP packets -- were designed to be transport
- independent. Where protocol addresses are passed as function
- arguments, they are carried via opaque pointers. A protocol-specific
-
-
-
-Gilligan, et. al. Informational [Page 3]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- address data structure is defined for each protocol that the socket
- functions support. Applications must cast pointers to these
- protocol-specific address structures into pointers to the generic
- "sockaddr" address structure when using the socket functions. These
- functions need not change for IPv6, but a new IPv6-specific address
- data structure is needed.
-
- The "sockaddr_in" structure is the protocol-specific data structure
- for IPv4. This data structure actually includes 8-octets of unused
- space, and it is tempting to try to use this space to adapt the
- sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in
- structure is not large enough to hold the 16-octet IPv6 address as
- well as the other information (address family and port number) that
- is needed. So a new address data structure must be defined for IPv6.
-
- The name-to-address translation functions in the socket interface are
- gethostbyname() and gethostbyaddr(). These must be modified to
- support IPv6 and the semantics defined must provide 100% backward
- compatibility for all existing IPv4 applications, along with IPv6
- support for new applications. Additionally, the POSIX 1003.g work in
- progress [4] specifies a new hostname-to-address translation function
- which is protocol independent. This function can also be used with
- IPv6.
-
- The address conversion functions -- inet_ntoa() and inet_addr() --
- convert IPv4 addresses between binary and printable form. These
- functions are quite specific to 32-bit IPv4 addresses. We have
- designed two analogous functions that convert both IPv4 and IPv6
- addresses, and carry an address type parameter so that they can be
- extended to other protocol families as well.
-
- Finally, a few miscellaneous features are needed to support IPv6.
- New interfaces are needed to support the IPv6 flow label, priority,
- and hop limit header fields. New socket options are needed to
- control the sending and receiving of IPv6 multicast packets.
-
- The socket interface will be enhanced in the future to provide access
- to other IPv6 features. These extensions are described in [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 4]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
-2.2. Data Types
-
- The data types of the structure elements given in this memo are
- intended to be examples, not absolute requirements. Whenever
- possible, POSIX 1003.1g data types are used: u_intN_t means an
- unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t
- means an unsigned integer of at least N bits (e.g., u_int32m_t). We
- also assume the argument data types from 1003.1g when possible (e.g.,
- the final argument to setsockopt() is a size_t value). Whenever
- buffer sizes are specified, the POSIX 1003.1 size_t data type is used
- (e.g., the two length arguments to getnameinfo()).
-
-2.3. Headers
-
- When function prototypes and structures are shown we show the headers
- that must be #included to cause that item to be defined.
-
-2.4. Structures
-
- When structures are described the members shown are the ones that
- must appear in an implementation. Additional, nonstandard members
- may also be defined by an implementation.
-
- The ordering shown for the members of a structure is the recommended
- ordering, given alignment considerations of multibyte members, but an
- implementation may order the members differently.
-
-3. Socket Interface
-
- This section specifies the socket interface changes for IPv6.
-
-3.1. IPv6 Address Family and Protocol Family
-
- A new address family name, AF_INET6, is defined in <sys/socket.h>.
- The AF_INET6 definition distinguishes between the original
- sockaddr_in address data structure, and the new sockaddr_in6 data
- structure.
-
- A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
- Like most of the other protocol family names, this will usually be
- defined to have the same value as the corresponding address family
- name:
-
- #define PF_INET6 AF_INET6
-
- The PF_INET6 is used in the first argument to the socket() function
- to indicate that an IPv6 socket is being created.
-
-
-
-
-Gilligan, et. al. Informational [Page 5]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
-3.2. IPv6 Address Structure
-
- A new data structure to hold a single IPv6 address is defined as
- follows:
-
- #include <netinet/in.h>
-
- struct in6_addr {
- u_int8_t s6_addr[16]; /* IPv6 address */
- }
-
- This data structure contains an array of sixteen 8-bit elements,
- which make up one 128-bit IPv6 address. The IPv6 address is stored
- in network byte order.
-
-3.3. Socket Address Structure for 4.3BSD-Based Systems
-
- In the socket interface, a different protocol-specific data structure
- is defined to carry the addresses for each protocol suite. Each
- protocol-specific data structure is designed so it can be cast into a
- protocol-independent data structure -- the "sockaddr" structure.
- Each has a "family" field that overlays the "sa_family" of the
- sockaddr data structure. This field identifies the type of the data
- structure.
-
- The sockaddr_in structure is the protocol-specific address data
- structure for IPv4. It is used to pass addresses between
- applications and the system in the socket functions. The following
- structure is defined to carry IPv6 addresses:
-
- #include <netinet/in.h>
-
- struct sockaddr_in6 {
- u_int16m_t sin6_family; /* AF_INET6 */
- u_int16m_t sin6_port; /* transport layer port # */
- u_int32m_t sin6_flowinfo; /* IPv6 flow information */
- struct in6_addr sin6_addr; /* IPv6 address */
- };
-
- This structure is designed to be compatible with the sockaddr data
- structure used in the 4.3BSD release.
-
- The sin6_family field identifies this as a sockaddr_in6 structure.
- This field overlays the sa_family field when the buffer is cast to a
- sockaddr data structure. The value of this field must be AF_INET6.
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 6]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The sin6_port field contains the 16-bit UDP or TCP port number. This
- field is used in the same way as the sin_port field of the
- sockaddr_in structure. The port number is stored in network byte
- order.
-
- The sin6_flowinfo field is a 32-bit field that contains two pieces of
- information: the 24-bit IPv6 flow label and the 4-bit priority field.
- The contents and interpretation of this member is unspecified at this
- time.
-
- The sin6_addr field is a single in6_addr structure (defined in the
- previous section). This field holds one 128-bit IPv6 address. The
- address is stored in network byte order.
-
- The ordering of elements in this structure is specifically designed
- so that the sin6_addr field will be aligned on a 64-bit boundary.
- This is done for optimum performance on 64-bit architectures.
-
- Notice that the sockaddr_in6 structure will normally be larger than
- the generic sockaddr structure. On many existing implementations the
- sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
- being 16 bytes. Any existing code that makes this assumption needs
- to be examined carefully when converting to IPv6.
-
-3.4. Socket Address Structure for 4.4BSD-Based Systems
-
- The 4.4BSD release includes a small, but incompatible change to the
- socket interface. The "sa_family" field of the sockaddr data
- structure was changed from a 16-bit value to an 8-bit value, and the
- space saved used to hold a length field, named "sa_len". The
- sockaddr_in6 data structure given in the previous section cannot be
- correctly cast into the newer sockaddr data structure. For this
- reason, the following alternative IPv6 address data structure is
- provided to be used on systems based on 4.4BSD:
-
- #include <netinet/in.h>
-
- #define SIN6_LEN
-
- struct sockaddr_in6 {
- u_char sin6_len; /* length of this struct */
- u_char sin6_family; /* AF_INET6 */
- u_int16m_t sin6_port; /* transport layer port # */
- u_int32m_t sin6_flowinfo; /* IPv6 flow information */
- struct in6_addr sin6_addr; /* IPv6 address */
- };
-
-
-
-
-
-Gilligan, et. al. Informational [Page 7]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The only differences between this data structure and the 4.3BSD
- variant are the inclusion of the length field, and the change of the
- family field to a 8-bit data type. The definitions of all the other
- fields are identical to the structure defined in the previous
- section.
-
- Systems that provide this version of the sockaddr_in6 data structure
- must also declare SIN6_LEN as a result of including the
- <netinet/in.h> header. This macro allows applications to determine
- whether they are being built on a system that supports the 4.3BSD or
- 4.4BSD variants of the data structure.
-
-3.5. The Socket Functions
-
- Applications call the socket() function to create a socket descriptor
- that represents a communication endpoint. The arguments to the
- socket() function tell the system which protocol to use, and what
- format address structure will be used in subsequent functions. For
- example, to create an IPv4/TCP socket, applications make the call:
-
- s = socket(PF_INET, SOCK_STREAM, 0);
-
- To create an IPv4/UDP socket, applications make the call:
-
- s = socket(PF_INET, SOCK_DGRAM, 0);
-
- Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
- the constant PF_INET6 instead of PF_INET in the first argument. For
- example, to create an IPv6/TCP socket, applications make the call:
-
- s = socket(PF_INET6, SOCK_STREAM, 0);
-
- To create an IPv6/UDP socket, applications make the call:
-
- s = socket(PF_INET6, SOCK_DGRAM, 0);
-
- Once the application has created a PF_INET6 socket, it must use the
- sockaddr_in6 address structure when passing addresses in to the
- system. The functions that the application uses to pass addresses
- into the system are:
-
- bind()
- connect()
- sendmsg()
- sendto()
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 8]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The system will use the sockaddr_in6 address structure to return
- addresses to applications that are using PF_INET6 sockets. The
- functions that return an address from the system to an application
- are:
-
- accept()
- recvfrom()
- recvmsg()
- getpeername()
- getsockname()
-
- No changes to the syntax of the socket functions are needed to
- support IPv6, since all of the "address carrying" functions use an
- opaque address pointer, and carry an address length as a function
- argument.
-
-3.6. Compatibility with IPv4 Applications
-
- In order to support the large base of applications using the original
- API, system implementations must provide complete source and binary
- compatibility with the original API. This means that systems must
- continue to support PF_INET sockets and the sockaddr_in address
- structure. Applications must be able to create IPv4/TCP and IPv4/UDP
- sockets using the PF_INET constant in the socket() function, as
- described in the previous section. Applications should be able to
- hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
- sockets simultaneously within the same process.
-
- Applications using the original API should continue to operate as
- they did on systems supporting only IPv4. That is, they should
- continue to interoperate with IPv4 nodes.
-
-3.7. Compatibility with IPv4 Nodes
-
- The API also provides a different type of compatibility: the ability
- for IPv6 applications to interoperate with IPv4 applications. This
- feature uses the IPv4-mapped IPv6 address format defined in the IPv6
- addressing architecture specification [2]. This address format
- allows the IPv4 address of an IPv4 node to be represented as an IPv6
- address. The IPv4 address is encoded into the low-order 32 bits of
- the IPv6 address, and the high-order 96 bits hold the fixed prefix
- 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows:
-
- ::FFFF:<IPv4-address>
-
- These addresses are often generated automatically by the
- gethostbyname() function when the specified host has only IPv4
- addresses (as described in Section 6.1).
-
-
-
-Gilligan, et. al. Informational [Page 9]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- Applications may use PF_INET6 sockets to open TCP connections to IPv4
- nodes, or send UDP packets to IPv4 nodes, by simply encoding the
- destination's IPv4 address as an IPv4-mapped IPv6 address, and
- passing that address, within a sockaddr_in6 structure, in the
- connect() or sendto() call. When applications use PF_INET6 sockets
- to accept TCP connections from IPv4 nodes, or receive UDP packets
- from IPv4 nodes, the system returns the peer's address to the
- application in the accept(), recvfrom(), or getpeername() call using
- a sockaddr_in6 structure encoded this way.
-
- Few applications will likely need to know which type of node they are
- interoperating with. However, for those applications that do need to
- know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is
- provided.
-
-3.8. IPv6 Wildcard Address
-
- While the bind() function allows applications to select the source IP
- address of UDP packets and TCP connections, applications often want
- the system to select the source address for them. With IPv4, one
- specifies the address as the symbolic constant INADDR_ANY (called the
- "wildcard" address) in the bind() call, or simply omits the bind()
- entirely.
-
- Since the IPv6 address type is a structure (struct in6_addr), a
- symbolic constant can be used to initialize an IPv6 address variable,
- but cannot be used in an assignment. Therefore systems provide the
- IPv6 wildcard address in two forms.
-
- The first version is a global variable named "in6addr_any" that is an
- in6_addr structure. The extern declaration for this variable is
- defined in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_any;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 10]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- Applications use in6addr_any similarly to the way they use INADDR_ANY
- in IPv4. For example, to bind a socket to port number 23, but let
- the system select the source address, an application could use the
- following code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_any; /* structure assignment */
- . . .
- if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
- The other version is a symbolic constant named IN6ADDR_ANY_INIT and
- is defined in <netinet/in.h>. This constant can be used to
- initialize an in6_addr structure:
-
- struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
- Note that this constant can be used ONLY at declaration time. It can
- not be used to assign a previously declared in6_addr structure. For
- example, the following code will not work:
-
- /* This is the WRONG way to assign an unspecified address */
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
- Be aware that the IPv4 INADDR_xxx constants are all defined in host
- byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
- in6addr_xxx externals are defined in network byte order.
-
-3.9. IPv6 Loopback Address
-
- Applications may need to send UDP packets to, or originate TCP
- connections to, services residing on the local node. In IPv4, they
- can do this by using the constant IPv4 address INADDR_LOOPBACK in
- their connect(), sendto(), or sendmsg() call.
-
- IPv6 also provides a loopback address to contact local TCP and UDP
- services. Like the unspecified address, the IPv6 loopback address is
- provided in two forms -- a global variable and a symbolic constant.
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 11]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The global variable is an in6_addr structure named
- "in6addr_loopback." The extern declaration for this variable is
- defined in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_loopback;
-
- Applications use in6addr_loopback as they would use INADDR_LOOPBACK
- in IPv4 applications (but beware of the byte ordering difference
- mentioned at the end of the previous section). For example, to open
- a TCP connection to the local telnet server, an application could use
- the following code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_loopback; /* structure assignment */
- . . .
- if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
- The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
- in <netinet/in.h>. It can be used at declaration time ONLY; for
- example:
-
- struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
- Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
- to a previously declared IPv6 address variable.
-
-4. Interface Identification
-
- This API uses an interface index (a small positive integer) to
- identify the local interface on which a multicast group is joined
- (Section 5.3). Additionally, the advanced API [5] uses these same
- interface indexes to identify the interface on which a datagram is
- received, or to specify the interface on which a datagram is to be
- sent.
-
- Interfaces are normally known by names such as "le0", "sl1", "ppp2",
- and the like. On Berkeley-derived implementations, when an interface
- is made known to the system, the kernel assigns a unique positive
- integer value (called the interface index) to that interface. These
- are small positive integers that start at 1. (Note that 0 is never
- used for an interface index.) There may be gaps so that there is no
- current interface for a particular positive interface index.
-
-
-
-
-Gilligan, et. al. Informational [Page 12]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- This API defines two functions that map between an interface name and
- index, a third function that returns all the interface names and
- indexes, and a fourth function to return the dynamic memory allocated
- by the previous function. How these functions are implemented is
- left up to the implementation. 4.4BSD implementations can implement
- these functions using the existing sysctl() function with the
- NET_RT_LIST command. Other implementations may wish to use ioctl()
- for this purpose.
-
-4.1. Name-to-Index
-
- The first function maps an interface name into its corresponding
- index.
-
- #include <net/if.h>
-
- unsigned int if_nametoindex(const char *ifname);
-
- If the specified interface does not exist, the return value is 0.
-
-4.2. Index-to-Name
-
- The second function maps an interface index into its corresponding
- name.
-
- #include <net/if.h>
-
- char *if_indextoname(unsigned int ifindex, char *ifname);
-
- The ifname argument must point to a buffer of at least IFNAMSIZ bytes
- into which the interface name corresponding to the specified index is
- returned. (IFNAMSIZ is also defined in <net/if.h> and its value
- includes a terminating null byte at the end of the interface name.)
- This pointer is also the return value of the function. If there is
- no interface corresponding to the specified index, NULL is returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 13]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
-4.3. Return All Interface Names and Indexes
-
- The final function returns an array of if_nameindex structures, one
- structure per interface.
-
- #include <net/if.h>
-
- struct if_nameindex {
- unsigned int if_index; /* 1, 2, ... */
- char *if_name; /* null terminated name: "le0", ... */
- };
-
- struct if_nameindex *if_nameindex(void);
-
- The end of the array of structures is indicated by a structure with
- an if_index of 0 and an if_name of NULL. The function returns a NULL
- pointer upon an error.
-
- The memory used for this array of structures along with the interface
- names pointed to by the if_name members is obtained dynamically.
- This memory is freed by the next function.
-
-4.4. Free Memory
-
- The following function frees the dynamic memory that was allocated by
- if_nameindex().
-
- #include <net/if.h>
-
- void if_freenameindex(struct if_nameindex *ptr);
-
- The argument to this function must be a pointer that was returned by
- if_nameindex().
-
-5. Socket Options
-
- A number of new socket options are defined for IPv6. All of these
- new options are at the IPPROTO_IPV6 level. That is, the "level"
- parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
- when using these options. The constant name prefix IPV6_ is used in
- all of the new socket options. This serves to clearly identify these
- options as applying to IPv6.
-
- The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
- related constants defined in this section are obtained by including
- the header <netinet/in.h>.
-
-
-
-
-
-Gilligan, et. al. Informational [Page 14]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
-5.1. Changing Socket Type
-
- Unix allows open sockets to be passed between processes via the
- exec() call and other means. It is a relatively common application
- practice to pass open sockets across exec() calls. Thus it is
- possible for an application using the original API to pass an open
- PF_INET socket to an application that is expecting to receive a
- PF_INET6 socket. Similarly, it is possible for an application using
- the extended API to pass an open PF_INET6 socket to an application
- using the original API, which would be equipped only to deal with
- PF_INET sockets. Either of these cases could cause problems, because
- the application that is passed the open socket might not know how to
- decode the address structures returned in subsequent socket
- functions.
-
- To remedy this problem, a new setsockopt() option is defined that
- allows an application to "convert" a PF_INET6 socket into a PF_INET
- socket and vice versa.
-
- An IPv6 application that is passed an open socket from an unknown
- process may use the IPV6_ADDRFORM setsockopt() option to "convert"
- the socket to PF_INET6. Once that has been done, the system will
- return sockaddr_in6 address structures in subsequent socket
- functions.
-
- An IPv6 application that is about to pass an open PF_INET6 socket to
- a program that is not be IPv6 capable can "downgrade" the socket to
- PF_INET before calling exec(). After that, the system will return
- sockaddr_in address structures to the application that was exec()'ed.
- Be aware that you cannot downgrade an IPv6 socket to an IPv4 socket
- unless all nonwildcard addresses already associated with the IPv6
- socket are IPv4-mapped IPv6 addresses.
-
- The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and
- IPPROTO_IPV6 levels. The only valid option values are PF_INET6 and
- PF_INET. For example, to convert a PF_INET6 socket to PF_INET, a
- program would call:
-
- int addrform = PF_INET;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
- (char *) &addrform, sizeof(addrform)) == -1)
- perror("setsockopt IPV6_ADDRFORM");
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 15]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- An application may use IPV6_ADDRFORM with getsockopt() to learn
- whether an open socket is a PF_INET of PF_INET6 socket. For example:
-
- int addrform;
- size_t len = sizeof(addrform);
-
- if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
- (char *) &addrform, &len) == -1)
- perror("getsockopt IPV6_ADDRFORM");
- else if (addrform == PF_INET)
- printf("This is an IPv4 socket.\n");
- else if (addrform == PF_INET6)
- printf("This is an IPv6 socket.\n");
- else
- printf("This system is broken.\n");
-
-5.2. Unicast Hop Limit
-
- A new setsockopt() option controls the hop limit used in outgoing
- unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS,
- and it is used at the IPPROTO_IPV6 layer. The following example
- illustrates how it is used:
-
- int hoplimit = 10;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, sizeof(hoplimit)) == -1)
- perror("setsockopt IPV6_UNICAST_HOPS");
-
- When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
- option value given is used as the hop limit for all subsequent
- unicast packets sent via that socket. If the option is not set, the
- system selects a default value. The integer hop limit value (called
- x) is interpreted as follows:
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 16]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The IPV6_UNICAST_HOPS option may be used with getsockopt() to
- determine the hop limit value that the system will use for subsequent
- unicast packets sent via that socket. For example:
-
- int hoplimit;
- size_t len = sizeof(hoplimit);
-
- if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, &len) == -1)
- perror("getsockopt IPV6_UNICAST_HOPS");
- else
- printf("Using %d for hop limit.\n", hoplimit);
-
-5.3. Sending and Receiving Multicast Packets
-
- IPv6 applications may send UDP multicast packets by simply specifying
- an IPv6 multicast address in the address argument of the sendto()
- function.
-
- Three socket options at the IPPROTO_IPV6 layer control some of the
- parameters for sending multicast packets. Setting these options is
- not required: applications may send multicast packets without using
- these options. The setsockopt() options for controlling the sending
- of multicast packets are summarized below:
-
- IPV6_MULTICAST_IF
-
- Set the interface to use for outgoing multicast packets. The
- argument is the index of the interface to use.
-
- Argument type: unsigned int
-
- IPV6_MULTICAST_HOPS
-
- Set the hop limit to use for outgoing multicast packets.
- (Note a separate option - IPV6_UNICAST_HOPS - is provided to
- set the hop limit to use for outgoing unicast packets.) The
- interpretation of the argument is the same as for the
- IPV6_UNICAST_HOPS option:
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
- Argument type: int
-
-
-
-
-
-Gilligan, et. al. Informational [Page 17]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- IPV6_MULTICAST_LOOP
-
- Controls whether outgoing multicast packets sent should be
- delivered back to the local application. A toggle. If the
- option is set to 1, multicast packets are looped back. If it
- is set to 0, they are not.
-
- Argument type: unsigned int
-
- The reception of multicast packets is controlled by the two
- setsockopt() options summarized below:
-
- IPV6_ADD_MEMBERSHIP
-
- Join a multicast group on a specified local interface. If
- the interface index is specified as 0, the kernel chooses the
- local interface. For example, some kernels look up the
- multicast group in the normal IPv6 routing table and using
- the resulting interface.
-
- Argument type: struct ipv6_mreq
-
- IPV6_DROP_MEMBERSHIP
-
- Leave a multicast group on a specified interface.
-
- Argument type: struct ipv6_mreq
-
- The argument type of both of these options is the ipv6_mreq
- structure, defined as:
-
- #include <netinet/in.h>
-
- struct ipv6_mreq {
- struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
- unsigned int ipv6mr_interface; /* interface index */
- };
-
- Note that to receive multicast datagrams a process must join the
- multicast group and bind the UDP port to which datagrams will be
- sent. Some processes also bind the multicast group address to the
- socket, in addition to the port, to prevent other datagrams destined
- to that same port from being delivered to the socket.
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 18]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
-6. Library Functions
-
- New library functions are needed to perform a variety of operations
- with IPv6 addresses. Functions are needed to lookup IPv6 addresses
- in the Domain Name System (DNS). Both forward lookup (hostname-to-
- address translation) and reverse lookup (address-to-hostname
- translation) need to be supported. Functions are also needed to
- convert IPv6 addresses between their binary and textual form.
-
-6.1. Hostname-to-Address Translation
-
- The commonly used function gethostbyname() remains unchanged as does
- the hostent structure to which it returns a pointer. Existing
- applications that call this function continue to receive only IPv4
- addresses that are the result of a query in the DNS for A records.
- (We assume the DNS is being used; some environments may be using a
- hosts file or some other name resolution system, either of which may
- impede renumbering. We also assume that the RES_USE_INET6 resolver
- option is not set, which we describe in more detail shortly.)
-
- Two new changes are made to support IPv6 addresses. First, the
- following function is new:
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- struct hostent *gethostbyname2(const char *name, int af);
-
- The af argument specifies the address family. The default operation
- of this function is simple:
-
- - If the af argument is AF_INET, then a query is made for A
- records. If successful, IPv4 addresses are returned and the
- h_length member of the hostent structure will be 4, else the
- function returns a NULL pointer.
-
- - If the af argument is AF_INET6, then a query is made for AAAA
- records. If successful, IPv6 addresses are returned and the
- h_length member of the hostent structure will be 16, else the
- function returns a NULL pointer.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 19]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The second change, that provides additional functionality, is a new
- resolver option RES_USE_INET6, which is defined as a result of
- including the <resolv.h> header. (This option is provided starting
- with the BIND 4.9.4 release.) There are three ways to set this
- option.
-
- - The first way is
-
- res_init();
- _res.options |= RES_USE_INET6;
-
- and then call either gethostbyname() or gethostbyname2(). This
- option then affects only the process that is calling the
- resolver.
-
- - The second way to set this option is to set the environment
- variable RES_OPTIONS, as in RES_OPTIONS=inet6. (This example is
- for the Bourne and Korn shells.) This method affects any
- processes that see this environment variable.
-
- - The third way is to set this option in the resolver configuration
- file (normally /etc/resolv.conf) and the option then affects all
- applications on the host. This final method should not be done
- until all applications on the host are capable of dealing with
- IPv6 addresses.
-
- There is no priority among these three methods. When the
- RES_USE_INET6 option is set, two changes occur:
-
- - gethostbyname(host) first calls gethostbyname2(host, AF_INET6)
- looking for AAAA records, and if this fails it then calls
- gethostbyname2(host, AF_INET) looking for A records.
-
- - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6
- addresses with the h_length member of the hostent structure set
- to 16.
-
- An application must not enable the RES_USE_INET6 option until it is
- prepared to deal with 16-byte addresses in the returned hostent
- structure.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 20]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The following table summarizes the operation of the existing
- gethostbyname() function, the new function gethostbyname2(), along
- with the new resolver option RES_USE_INET6.
-
-+------------------+---------------------------------------------------+
-| | RES_USE_INET6 option |
-| +-------------------------+-------------------------+
-| | off | on |
-+------------------+-------------------------+-------------------------+
-| |Search for A records. |Search for AAAA records. |
-| gethostbyname | If found, return IPv4 | If found, return IPv6 |
-| (host) | addresses (h_length=4). | addresses (h_length=16).|
-| | Else error. | Else search for A |
-| | | records. If found, |
-| |Provides backward | return IPv4-mapped IPv6 |
-| | compatibility with all | addresses (h_length=16).|
-| | existing IPv4 appls. | Else error. |
-+------------------+-------------------------+-------------------------+
-| |Search for A records. |Search for A records. |
-| gethostbyname2 | If found, return IPv4 | If found, return |
-| (host, AF_INET) | addresses (h_length=4). | IPv4-mapped IPv6 |
-| | Else error. | addresses (h_length=16).|
-| | | Else error. |
-+------------------+-------------------------+-------------------------+
-| |Search for AAAA records. |Search for AAAA records. |
-| gethostbyname2 | If found, return IPv6 | If found, return IPv6 |
-| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).|
-| | Else error. | Else error. |
-+------------------+-------------------------+-------------------------+
-
- It is expected that when a typical naive application that calls
- gethostbyname() today is modified to use IPv6, it simply changes the
- program to use IPv6 sockets and then enables the RES_USE_INET6
- resolver option before calling gethostbyname(). This application
- will then work with either IPv4 or IPv6 peers.
-
- Note that gethostbyname() and gethostbyname2() are not thread-safe,
- since both return a pointer to a static hostent structure. But
- several vendors have defined a thread-safe gethostbyname_r() function
- that requires four additional arguments. We expect these vendors to
- also define a gethostbyname2_r() function.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 21]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
-6.2. Address To Hostname Translation
-
- The existing gethostbyaddr() function already requires an address
- family argument and can therefore work with IPv6 addresses:
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- struct hostent *gethostbyaddr(const char *src, int len, int af);
-
- One possible source of confusion is the handling of IPv4-mapped IPv6
- addresses and IPv4-compatible IPv6 addresses. This is addressed in
- [6] and involves the following logic:
-
- 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address
- is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6
- address, then skip over the first 12 bytes of the IPv6 address,
- set af to AF_INET, and set len to 4.
-
- 2. If af is AF_INET, then query for a PTR record in the in-
- addr.arpa domain.
-
- 3. If af is AF_INET6, then query for a PTR record in the ip6.int
- domain.
-
- 4. If the function is returning success, and if af equals AF_INET,
- and if the RES_USE_INET6 option was set, then the single address
- that is returned in the hostent structure (a copy of the first
- argument to the function) is returned as an IPv4-mapped IPv6
- address and the h_length member is set to 16.
-
- All four steps listed are performed, in order. The same caveats
- regarding a thread-safe version of gethostbyname() that were made at
- the end of the previous section apply here as well.
-
-6.3. Protocol-Independent Hostname and Service Name Translation
-
- Hostname-to-address translation is done in a protocol-independent
- fashion using the getaddrinfo() function that is taken from the
- Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
- (Protocol Independent Interfaces) work in progress specification [4].
-
- The official specification for this function will be the final POSIX
- standard. We are providing this independent description of the
- function because POSIX standards are not freely available (as are
- IETF documents). Should there be any discrepancies between this
- description and the POSIX description, the POSIX description takes
- precedence.
-
-
-
-Gilligan, et. al. Informational [Page 22]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- int getaddrinfo(const char *hostname, const char *servname,
- const struct addrinfo *hints,
- struct addrinfo **res);
-
- The addrinfo structure is defined as:
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- struct addrinfo {
- int ai_flags; /* AI_PASSIVE, AI_CANONNAME */
- int ai_family; /* PF_xxx */
- int ai_socktype; /* SOCK_xxx */
- int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
- size_t ai_addrlen; /* length of ai_addr */
- char *ai_canonname; /* canonical name for hostname */
- struct sockaddr *ai_addr; /* binary address */
- struct addrinfo *ai_next; /* next structure in linked list */
- };
-
- The return value from the function is 0 upon success or a nonzero
- error code. The following names are the nonzero error codes from
- getaddrinfo(), and are defined in <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 nor servname 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 hostname and servname arguments are pointers to null-terminated
- strings or NULL. One or both of these two arguments must be a non-
- NULL pointer. In the normal client scenario, both the hostname and
- servname are specified. In the normal server scenario, only the
- servname is specified. A non-NULL hostname string can be either a
- host name or a numeric host address string (i.e., a dotted-decimal
- IPv4 address or an IPv6 hex address). A non-NULL servname string can
- be either a service name or a decimal port number.
-
-
-
-
-Gilligan, et. al. Informational [Page 23]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The caller can optionally pass an addrinfo structure, pointed to by
- the third argument, to provide hints concerning the type of socket
- that the caller supports. In this hints structure all members other
- than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
- or a NULL pointer. A value of PF_UNSPEC for ai_family means the
- caller will accept any protocol family. A value of 0 for ai_socktype
- means the caller will accept any socket type. A value of 0 for
- ai_protocol means the caller will accept any protocol. For example,
- if the caller handles only TCP and not UDP, then the ai_socktype
- member of the hints structure should be set to SOCK_STREAM when
- getaddrinfo() is called. If the caller handles only IPv4 and not
- IPv6, then the ai_family member of the hints structure should be set
- to PF_INET when getaddrinfo() is called. If the third argument to
- getaddrinfo() is a NULL pointer, this is the same as if the caller
- had filled in an addrinfo structure initialized to zero with
- ai_family set to PF_UNSPEC.
-
- Upon successful return a pointer to a linked list of one or more
- addrinfo structures is returned through the final argument. The
- caller can process each addrinfo structure in this list by following
- the ai_next pointer, until a NULL pointer is encountered. In each
- returned addrinfo structure the three members ai_family, ai_socktype,
- and ai_protocol are the corresponding arguments for a call to the
- socket() function. In each addrinfo structure the ai_addr member
- points to a filled-in socket address structure whose length is
- specified by the ai_addrlen member.
-
- If the AI_PASSIVE bit is set in the ai_flags member of the hints
- structure, then the caller plans to use the returned socket address
- structure in a call to bind(). In this case, if the hostname
- argument is a NULL pointer, then the IP address portion of the socket
- address structure will be set to INADDR_ANY for an IPv4 address or
- IN6ADDR_ANY_INIT for an IPv6 address.
-
- If the AI_PASSIVE bit is not set in the ai_flags member of the hints
- structure, then the returned socket address structure will be ready
- for a call to connect() (for a connection-oriented protocol) or
- either connect(), sendto(), or sendmsg() (for a connectionless
- protocol). In this case, if the hostname argument is a NULL pointer,
- then the IP address portion of the socket address structure will be
- set to the loopback address.
-
- If the AI_CANONNAME bit is set in the ai_flags member of the hints
- structure, then upon successful return the ai_canonname member of the
- first addrinfo structure in the linked list will point to a null-
- terminated string containing the canonical name of the specified
- hostname.
-
-
-
-
-Gilligan, et. al. Informational [Page 24]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- All of the information returned by getaddrinfo() is dynamically
- allocated: the addrinfo structures, and the socket address structures
- and canonical host name strings pointed to by the addrinfo
- structures. To return this information to the system the function
- freeaddrinfo() is called:
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- void freeaddrinfo(struct addrinfo *ai);
-
- The addrinfo structure pointed to by the ai argument is freed, along
- with any dynamic storage pointed to by the structure. This operation
- is repeated until a NULL ai_next pointer is encountered.
-
- To aid applications in printing error messages based on the EAI_xxx
- codes returned by getaddrinfo(), the following function is defined.
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- char *gai_strerror(int ecode);
-
- The argument is one of the EAI_xxx values defined earlier and the
- eturn value points to a string describing the error. If the argument
- is not one of the EAI_xxx values, the function still returns a
- pointer to a string whose contents indicate an unknown error.
-
-6.4. Socket Address Structure to Hostname and Service Name
-
- The POSIX 1003.1g specification includes no function to perform the
- reverse conversion from getaddrinfo(): to look up a hostname and
- service name, given the binary address and port. Therefore, we
- define the following function:
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- int getnameinfo(const struct sockaddr *sa, size_t salen,
- char *host, size_t hostlen,
- char *serv, size_t servlen,
- int flags);
-
- This function looks up an IP address and port number provided by the
- caller in the DNS and system-specific database, and returns text
- strings for both in buffers provided by the caller. The function
- indicates successful completion by a zero return value; a non-zero
- return value indicates failure.
-
-
-
-Gilligan, et. al. Informational [Page 25]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The first argument, sa, points to either a sockaddr_in structure (for
- IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
- address and port number. The salen argument gives the length of the
- sockaddr_in or sockaddr_in6 structure.
-
- The function returns the hostname associated with the IP address in
- the buffer pointed to by the host argument. The caller provides the
- size of this buffer via the hostlen argument. The service name
- associated with the port number is returned in the buffer pointed to
- by serv, and the servlen argument gives the length of this buffer.
- The caller specifies not to return either string by providing a zero
- value for the hostlen or servlen arguments. Otherwise, the caller
- must provide buffers large enough to hold the hostname and the
- service name, including the terminating null characters.
-
- Unfortunately most systems do not provide constants that specify the
- maximum size of either a fully-qualified domain name or a service
- name. Therefore to aid the application in allocating buffers for
- these two returned strings the following constants are defined in
- <netdb.h>:
-
- #define NI_MAXHOST 1025
- #define NI_MAXSERV 32
-
- The first value is actually defined as the constant MAXDNAME in
- recent versions of BIND's <arpa/nameser.h> header (older versions of
- BIND define this constant to be 256) and the second is a guess based
- on the services listed in the current Assigned Numbers RFC.
-
- The final argument is a flag that changes the default actions of this
- function. By default the fully-qualified domain name (FQDN) for the
- host is looked up in the DNS and returned. If the flag bit NI_NOFQDN
- is set, only the hostname portion of the FQDN is returned for local
- hosts.
-
- If the flag bit NI_NUMERICHOST is set, or if the host's name cannot
- be located in the DNS, the numeric form of the host's address is
- returned instead of its name (e.g., by calling inet_ntop() instead of
- gethostbyaddr()). If the flag bit NI_NAMEREQD is set, an error is
- returned if the host's name cannot be located in the DNS.
-
- If the flag bit NI_NUMERICSERV is set, the numeric form of the
- service address is returned (e.g., its port number) instead of its
- name. The two NI_NUMERICxxx flags are required to support the "-n"
- flag that many commands provide.
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 26]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- A fifth flag bit, NI_DGRAM, specifies that the service 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.
-
- These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
- flags already defined for getaddrinfo().
-
-6.5. Address Conversion Functions
-
- The two functions inet_addr() and inet_ntoa() convert an IPv4 address
- between binary and text form. IPv6 applications need similar
- functions. The following two functions convert both IPv6 and IPv4
- addresses:
-
- #include <sys/socket.h>
- #include <arpa/inet.h>
-
- int inet_pton(int af, const char *src, void *dst);
-
- const char *inet_ntop(int af, const void *src,
- char *dst, size_t size);
-
- The inet_pton() function converts an address in its standard text
- presentation form into its numeric binary form. The af argument
- specifies the family of the address. Currently the AF_INET and
- AF_INET6 address families are supported. The src argument points to
- the string being passed in. The dst argument points to a buffer into
- which the function stores the numeric address. The address is
- returned in network byte order. Inet_pton() returns 1 if the
- conversion succeeds, 0 if the input is not a valid IPv4 dotted-
- decimal string or a valid IPv6 address string, or -1 with errno set
- to EAFNOSUPPORT if the af argument is unknown. The calling
- application must ensure that the buffer referred to by dst is large
- enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
- bytes for AF_INET6).
-
- If the af argument is AF_INET, the function accepts a string in the
- standard IPv4 dotted-decimal form:
-
- ddd.ddd.ddd.ddd
-
- where ddd is a one to three digit decimal number between 0 and 255.
- Note that many implementations of the existing inet_addr() and
- inet_aton() functions accept nonstandard input: octal numbers,
- hexadecimal numbers, and fewer than four numbers. inet_pton() does
- not accept these formats.
-
-
-
-Gilligan, et. al. Informational [Page 27]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- If the af argument is AF_INET6, then the function accepts a string in
- one of the standard IPv6 text forms defined in Section 2.2 of the
- addressing architecture specification [2].
-
- The inet_ntop() function converts a numeric address into a text
- string suitable for presentation. The af argument specifies the
- family of the address. This can be AF_INET or AF_INET6. The src
- argument points to a buffer holding an IPv4 address if the af
- argument is AF_INET, or an IPv6 address if the af argument is
- AF_INET6. The dst argument points to a buffer where the function
- will store the resulting text string. The size argument specifies
- the size of this buffer. The application must specify a non-NULL dst
- argument. For IPv6 addresses, the buffer must be at least 46-octets.
- For IPv4 addresses, the buffer must be at least 16-octets. In order
- to allow applications to easily declare buffers of the proper size to
- store IPv4 and IPv6 addresses in string form, the following two
- constants are defined in <netinet/in.h>:
-
- #define INET_ADDRSTRLEN 16
- #define INET6_ADDRSTRLEN 46
-
- The inet_ntop() function returns a pointer to the buffer containing
- the text string if the conversion succeeds, and NULL otherwise. Upon
- failure, errno is set to EAFNOSUPPORT if the af argument is invalid
- or ENOSPC if the size of the result buffer is inadequate.
-
-6.6. Address Testing Macros
-
- The following macros can be used to test for special IPv6 addresses.
-
- #include <netinet/in.h>
-
- int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
- int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
- int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
- int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
- int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
-
- int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 28]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- The first seven macros return true if the address is of the specified
- type, or false otherwise. The last five test the scope of a
- multicast address and return true if the address is a multicast
- address of the specified scope or false if the address is either not
- a multicast address or not of the specified scope.
-
-7. Summary of New Definitions
-
- The following list summarizes the constants, structure, and extern
- definitions discussed in this memo, sorted by header.
-
- <net/if.h> IFNAMSIZ
- <net/if.h> struct if_nameindex{};
-
- <netdb.h> AI_CANONNAME
- <netdb.h> AI_PASSIVE
- <netdb.h> EAI_ADDRFAMILY
- <netdb.h> EAI_AGAIN
- <netdb.h> EAI_BADFLAGS
- <netdb.h> EAI_FAIL
- <netdb.h> EAI_FAMILY
- <netdb.h> EAI_MEMORY
- <netdb.h> EAI_NODATA
- <netdb.h> EAI_NONAME
- <netdb.h> EAI_SERVICE
- <netdb.h> EAI_SOCKTYPE
- <netdb.h> EAI_SYSTEM
- <netdb.h> NI_DGRAM
- <netdb.h> NI_MAXHOST
- <netdb.h> NI_MAXSERV
- <netdb.h> NI_NAMEREQD
- <netdb.h> NI_NOFQDN
- <netdb.h> NI_NUMERICHOST
- <netdb.h> NI_NUMERICSERV
- <netdb.h> struct addrinfo{};
-
- <netinet/in.h> IN6ADDR_ANY_INIT
- <netinet/in.h> IN6ADDR_LOOPBACK_INIT
- <netinet/in.h> INET6_ADDRSTRLEN
- <netinet/in.h> INET_ADDRSTRLEN
- <netinet/in.h> IPPROTO_IPV6
- <netinet/in.h> IPV6_ADDRFORM
- <netinet/in.h> IPV6_ADD_MEMBERSHIP
- <netinet/in.h> IPV6_DROP_MEMBERSHIP
- <netinet/in.h> IPV6_MULTICAST_HOPS
- <netinet/in.h> IPV6_MULTICAST_IF
- <netinet/in.h> IPV6_MULTICAST_LOOP
- <netinet/in.h> IPV6_UNICAST_HOPS
-
-
-
-Gilligan, et. al. Informational [Page 29]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- <netinet/in.h> SIN6_LEN
- <netinet/in.h> extern const struct in6_addr in6addr_any;
- <netinet/in.h> extern const struct in6_addr in6addr_loopback;
- <netinet/in.h> struct in6_addr{};
- <netinet/in.h> struct ipv6_mreq{};
- <netinet/in.h> struct sockaddr_in6{};
-
- <resolv.h> RES_USE_INET6
-
- <sys/socket.h> AF_INET6
- <sys/socket.h> PF_INET6
-
-
- The following list summarizes the function and macro prototypes
- discussed in this memo, sorted by header.
-
-<arpa/inet.h> int inet_pton(int, const char *, void *);
-<arpa/inet.h> const char *inet_ntop(int, const void *,
- char *, size_t);
-
-<net/if.h> char *if_indextoname(unsigned int, char *);
-<net/if.h> unsigned int if_nametoindex(const char *);
-<net/if.h> void if_freenameindex(struct if_nameindex *);
-<net/if.h> struct if_nameindex *if_nameindex(void);
-
-<netdb.h> int getaddrinfo(const char *, const char *,
- const struct addrinfo *,
- struct addrinfo **);
-<netdb.h> int getnameinfo(const struct sockaddr *, size_t,
- char *, size_t, char *, size_t, int);
-<netdb.h> void freeaddrinfo(struct addrinfo *);
-<netdb.h> char *gai_strerror(int);
-<netdb.h> struct hostent *gethostbyname(const char *);
-<netdb.h> struct hostent *gethostbyaddr(const char *, int, int);
-<netdb.h> struct hostent *gethostbyname2(const char *, int);
-
-<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-
-
-Gilligan, et. al. Informational [Page 30]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
-8. Security Considerations
-
- IPv6 provides a number of new security mechanisms, many of which need
- to be accessible to applications. A companion memo detailing the
- extensions to the socket interfaces to support IPv6 security is being
- written [3].
-
-9. Acknowledgments
-
- Thanks to the many people who made suggestions and provided feedback
- to to the numerous revisions of this document, including: Werner
- Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson,
- Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont,
- Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-
- Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan
- Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas
- Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc
- Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
- Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
- Waitzman, Carl Williams, and Kazuhiko Yamamoto,
-
- The getaddrinfo() and getnameinfo() functions are taken from an
- earlier Work in Progress by Keith Sklower. As noted in that
- document, William Durst, Steven Wise, Michael Karels, and Eric Allman
- provided many useful discussions on the subject of protocol-
- independent name-to-address translation, and reviewed early versions
- of Keith Sklower's original proposal. Eric Allman implemented the
- first prototype of getaddrinfo(). The observation that specifying
- the pair of name and service would suffice for connecting to a
- service independent of protocol details was made by Marshall Rose in
- a proposal to X/Open for a "Uniform Network Interface".
-
- Craig Metz made many contributions to this document. Ramesh Govindan
- made a number of contributions and co-authored an earlier version of
- this memo.
-
-10. References
-
- [1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
- Specification", RFC 1883, December 1995.
-
- [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
- RFC 1884, December 1995.
-
- [3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets",
- Work in Progress.
-
-
-
-
-
-Gilligan, et. al. Informational [Page 31]
-
-RFC 2133 IPv6 Socket Interface Extensions April 1997
-
-
- [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
- 6.3, November 1995.
-
- [5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6",
- Work in Progress.
-
- [6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in
- IPv6", Work in Progress.
-
-11. Authors' Addresses
-
- Robert E. Gilligan
- Freegate Corporation
- 710 Lakeway Dr. STE 230
- Sunnyvale, CA 94086
-
- Phone: +1 408 524 4804
- EMail: gilligan@freegate.net
-
-
- Susan Thomson
- Bell Communications Research
- MRE 2P-343, 445 South Street
- Morristown, NJ 07960
-
- Phone: +1 201 829 4514
- EMail: set@thumper.bellcore.com
-
-
- Jim Bound
- Digital Equipment Corporation
- 110 Spitbrook Road ZK3-3/U14
- Nashua, NH 03062-2698
-
- Phone: +1 603 881 0400
- Email: bound@zk3.dec.com
-
-
- W. Richard Stevens
- 1202 E. Paseo del Zorro
- Tucson, AZ 85718-2826
-
- Phone: +1 520 297 9416
- EMail: rstevens@kohala.com
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 32]
-
diff --git a/contrib/bind9/doc/rfc/rfc2136.txt b/contrib/bind9/doc/rfc/rfc2136.txt
deleted file mode 100644
index 4d62702e0d4b8..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2136.txt
+++ /dev/null
@@ -1,1460 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Vixie, Editor
-Request for Comments: 2136 ISC
-Updates: 1035 S. Thomson
-Category: Standards Track Bellcore
- Y. Rekhter
- Cisco
- J. Bound
- DEC
- April 1997
-
- Dynamic Updates in the Domain Name System (DNS UPDATE)
-
-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.
-
-Abstract
-
- The Domain Name System was originally designed to support queries of
- a statically configured database. While the data was expected to
- change, the frequency of those changes was expected to be fairly low,
- and all updates were made as external edits to a zone's Master File.
-
- Using this specification of the UPDATE opcode, it is possible to add
- or delete RRs or RRsets from a specified zone. Prerequisites are
- specified separately from update operations, and can specify a
- dependency upon either the previous existence or nonexistence of an
- RRset, or the existence of a single RR.
-
- UPDATE is atomic, i.e., all prerequisites must be satisfied or else
- no update operations will take place. There are no data dependent
- error conditions defined after the prerequisites have been met.
-
-1 - Definitions
-
- This document intentionally gives more definition to the roles of
- "Master," "Slave," and "Primary Master" servers, and their
- enumeration in NS RRs, and the SOA MNAME field. In that sense, the
- following server type definitions can be considered an addendum to
- [RFC1035], and are intended to be consistent with [RFC1996]:
-
- Slave an authoritative server that uses AXFR or IXFR to
- retrieve the zone and is named in the zone's NS
- RRset.
-
-
-
-Vixie, et. al. Standards Track [Page 1]
-
-RFC 2136 DNS Update April 1997
-
-
- Master an authoritative server configured to be the
- source of AXFR or IXFR data for one or more slave
- servers.
-
- Primary Master master server at the root of the AXFR/IXFR
- dependency graph. The primary master is named in
- the zone's SOA MNAME field and optionally by an NS
- RR. There is by definition only one primary master
- server per zone.
-
- A domain name identifies a node within the domain name space tree
- structure. Each node has a set (possibly empty) of Resource Records
- (RRs). All RRs having the same NAME, CLASS and TYPE are called a
- Resource Record Set (RRset).
-
- The pseudocode used in this document is for example purposes only.
- If it is found to disagree with the text, the text shall be
- considered authoritative. If the text is found to be ambiguous, the
- pseudocode can be used to help resolve the ambiguity.
-
- 1.1 - Comparison Rules
-
- 1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
- RDLENGTH and RDATA fields are equal. Note that the time-to-live
- (TTL) field is explicitly excluded from the comparison.
-
- 1.1.2. The rules for comparison of character strings in names are
- specified in [RFC1035 2.3.3].
-
- 1.1.3. Wildcarding is disabled. That is, a wildcard ("*") in an
- update only matches a wildcard ("*") in the zone, and vice versa.
-
- 1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
- the update, and will not otherwise be followed. All UPDATE
- operations are done on the basis of canonical names.
-
- 1.1.5. The following RR types cannot be appended to an RRset. If the
- following comparison rules are met, then an attempt to add the new RR
- will result in the replacement of the previous RR:
-
- SOA compare only NAME, CLASS and TYPE -- it is not possible to
- have more than one SOA per zone, even if any of the data
- fields differ.
-
- WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
- -- only one WKS RR is possible for this tuple, even if the
- services masks differ.
-
-
-
-
-Vixie, et. al. Standards Track [Page 2]
-
-RFC 2136 DNS Update April 1997
-
-
- CNAME compare only NAME, CLASS, and TYPE -- it is not possible
- to have more than one CNAME RR, even if their data fields
- differ.
-
- 1.2 - Glue RRs
-
- For the purpose of determining whether a domain name used in the
- UPDATE protocol is contained within a specified zone, a domain name
- is "in" a zone if it is owned by that zone's domain name. See
- section 7.18 for details.
-
- 1.3 - New Assigned Numbers
-
- CLASS = NONE (254)
- RCODE = YXDOMAIN (6)
- RCODE = YXRRSET (7)
- RCODE = NXRRSET (8)
- RCODE = NOTAUTH (9)
- RCODE = NOTZONE (10)
- Opcode = UPDATE (5)
-
-2 - Update Message Format
-
- The DNS Message Format is defined by [RFC1035 4.1]. Some extensions
- are necessary (for example, more error codes are possible under
- UPDATE than under QUERY) and some fields must be overloaded (see
- description of CLASS fields below).
-
- The overall format of an UPDATE message is, following [ibid]:
-
- +---------------------+
- | Header |
- +---------------------+
- | Zone | specifies the zone to be updated
- +---------------------+
- | Prerequisite | RRs or RRsets which must (not) preexist
- +---------------------+
- | Update | RRs or RRsets to be added or deleted
- +---------------------+
- | Additional Data | additional data
- +---------------------+
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 3]
-
-RFC 2136 DNS Update April 1997
-
-
- The Header Section specifies that this message is an UPDATE, and
- describes the size of the other sections. The Zone Section names the
- zone that is to be updated by this message. The Prerequisite Section
- specifies the starting invariants (in terms of zone content) required
- for this update. The Update Section contains the edits to be made,
- and the Additional Data Section contains data which may be necessary
- to complete, but is not part of, this update.
-
- 2.1 - Transport Issues
-
- An update transaction may be carried in a UDP datagram, if the
- request fits, or in a TCP connection (at the discretion of the
- requestor). When TCP is used, the message is in the format described
- in [RFC1035 4.2.2].
-
- 2.2 - Message Header
-
- The header of the DNS Message Format is defined by [RFC 1035 4.1].
- Not all opcodes define the same set of flag bits, though as a
- practical matter most of the bits defined for QUERY (in [ibid]) are
- identically defined by the other opcodes. UPDATE uses only one flag
- bit (QR).
-
- The DNS Message Format specifies record counts for its four sections
- (Question, Answer, Authority, and Additional). UPDATE uses the same
- fields, and the same section formats, but the naming and use of these
- sections differs as shown in the following modified header, after
- [RFC1035 4.1.1]:
-
- 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 | Z | RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ZOCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PRCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | UPCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 4]
-
-RFC 2136 DNS Update April 1997
-
-
- These fields are used as follows:
-
- ID A 16-bit identifier assigned by the entity that generates any
- kind of request. This identifier is copied in the
- corresponding reply and can be used by the requestor to match
- replies to outstanding requests, or by the server to detect
- duplicated requests from some requestor.
-
- QR A one bit field that specifies whether this message is a
- request (0), or a response (1).
-
- Opcode A four bit field that specifies the kind of request in this
- message. This value is set by the originator of a request
- and copied into the response. The Opcode value that
- identifies an UPDATE message is five (5).
-
- Z Reserved for future use. Should be zero (0) in all requests
- and responses. A non-zero Z field should be ignored by
- implementations of this specification.
-
- RCODE Response code - this four bit field is undefined in requests
- and set in responses. The values and meanings of this field
- within responses are as follows:
-
- Mneumonic Value Description
- ------------------------------------------------------------
- NOERROR 0 No error condition.
- FORMERR 1 The name server was unable to interpret
- the request due to a format error.
- SERVFAIL 2 The name server encountered an internal
- failure while processing this request,
- for example an operating system error
- or a forwarding timeout.
- NXDOMAIN 3 Some name that ought to exist,
- does not exist.
- NOTIMP 4 The name server does not support
- the specified Opcode.
- REFUSED 5 The name server refuses to perform the
- specified operation for policy or
- security reasons.
- YXDOMAIN 6 Some name that ought not to exist,
- does exist.
- YXRRSET 7 Some RRset that ought not to exist,
- does exist.
- NXRRSET 8 Some RRset that ought to exist,
- does not exist.
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 5]
-
-RFC 2136 DNS Update April 1997
-
-
- NOTAUTH 9 The server is not authoritative for
- the zone named in the Zone Section.
- NOTZONE 10 A name used in the Prerequisite or
- Update Section is not within the
- zone denoted by the Zone Section.
-
- ZOCOUNT The number of RRs in the Zone Section.
-
- PRCOUNT The number of RRs in the Prerequisite Section.
-
- UPCOUNT The number of RRs in the Update Section.
-
- ADCOUNT The number of RRs in the Additional Data Section.
-
- 2.3 - Zone Section
-
- The Zone Section has the same format as that specified in [RFC1035
- 4.1.2], with the fields redefined as follows:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / ZNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ZTYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ZCLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- UPDATE uses this section to denote the zone of the records being
- updated. All records to be updated must be in the same zone, and
- therefore the Zone Section is allowed to contain exactly one record.
- The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
- the zone's class.
-
- 2.4 - Prerequisite Section
-
- This section contains a set of RRset prerequisites which must be
- satisfied at the time the UPDATE packet is received by the primary
- master server. The format of this section is as specified by
- [RFC1035 4.1.3]. There are five possible sets of semantics that can
- be expressed here, summarized as follows and then explained below.
-
- (1) RRset exists (value independent). At least one RR with a
- specified NAME and TYPE (in the zone and class specified by
- the Zone Section) must exist.
-
-
-
-Vixie, et. al. Standards Track [Page 6]
-
-RFC 2136 DNS Update April 1997
-
-
- (2) RRset exists (value dependent). A set of RRs with a
- specified NAME and TYPE exists and has the same members
- with the same RDATAs as the RRset specified here in this
- Section.
-
- (3) RRset does not exist. No RRs with a specified NAME and TYPE
- (in the zone and class denoted by the Zone Section) can exist.
-
- (4) Name is in use. At least one RR with a specified NAME (in
- the zone and class specified by the Zone Section) must exist.
- Note that this prerequisite is NOT satisfied by empty
- nonterminals.
-
- (5) Name is not in use. No RR of any type is owned by a
- specified NAME. Note that this prerequisite IS satisfied by
- empty nonterminals.
-
- The syntax of these is as follows:
-
- 2.4.1 - RRset Exists (Value Independent)
-
- At least one RR with a specified NAME and TYPE (in the zone and class
- specified in the Zone Section) must exist.
-
- For this prerequisite, a requestor adds to the section a single RR
- whose NAME and TYPE are equal to that of the zone RRset whose
- existence is required. RDLENGTH is zero and RDATA is therefore
- empty. CLASS must be specified as ANY to differentiate this
- condition from that of an actual RR whose RDLENGTH is naturally zero
- (0) (e.g., NULL). TTL is specified as zero (0).
-
- 2.4.2 - RRset Exists (Value Dependent)
-
- A set of RRs with a specified NAME and TYPE exists and has the same
- members with the same RDATAs as the RRset specified here in this
- section. While RRset ordering is undefined and therefore not
- significant to this comparison, the sets be identical in their
- extent.
-
- For this prerequisite, a requestor adds to the section an entire
- RRset whose preexistence is required. NAME and TYPE are that of the
- RRset being denoted. CLASS is that of the zone. TTL must be
- specified as zero (0) and is ignored when comparing RRsets for
- identity.
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 7]
-
-RFC 2136 DNS Update April 1997
-
-
- 2.4.3 - RRset Does Not Exist
-
- No RRs with a specified NAME and TYPE (in the zone and class denoted
- by the Zone Section) can exist.
-
- For this prerequisite, a requestor adds to the section a single RR
- whose NAME and TYPE are equal to that of the RRset whose nonexistence
- is required. The RDLENGTH of this record is zero (0), and RDATA
- field is therefore empty. CLASS must be specified as NONE in order
- to distinguish this condition from a valid RR whose RDLENGTH is
- naturally zero (0) (for example, the NULL RR). TTL must be specified
- as zero (0).
-
- 2.4.4 - Name Is In Use
-
- Name is in use. At least one RR with a specified NAME (in the zone
- and class specified by the Zone Section) must exist. Note that this
- prerequisite is NOT satisfied by empty nonterminals.
-
- For this prerequisite, a requestor adds to the section a single RR
- whose NAME is equal to that of the name whose ownership of an RR is
- required. RDLENGTH is zero and RDATA is therefore empty. CLASS must
- be specified as ANY to differentiate this condition from that of an
- actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE
- must be specified as ANY to differentiate this case from that of an
- RRset existence test. TTL is specified as zero (0).
-
- 2.4.5 - Name Is Not In Use
-
- Name is not in use. No RR of any type is owned by a specified NAME.
- Note that this prerequisite IS satisfied by empty nonterminals.
-
- For this prerequisite, a requestor adds to the section a single RR
- whose NAME is equal to that of the name whose nonownership of any RRs
- is required. RDLENGTH is zero and RDATA is therefore empty. CLASS
- must be specified as NONE. TYPE must be specified as ANY. TTL must
- be specified as zero (0).
-
- 2.5 - Update Section
-
- This section contains RRs to be added to or deleted from the zone.
- The format of this section is as specified by [RFC1035 4.1.3]. There
- are four possible sets of semantics, summarized below and with
- details to follow.
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 8]
-
-RFC 2136 DNS Update April 1997
-
-
- (1) Add RRs to an RRset.
- (2) Delete an RRset.
- (3) Delete all RRsets from a name.
- (4) Delete an RR from an RRset.
-
- The syntax of these is as follows:
-
- 2.5.1 - Add To An RRset
-
- RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
- and RDATA are those being added, and CLASS is the same as the zone
- class. Any duplicate RRs will be silently ignored by the primary
- master.
-
- 2.5.2 - Delete An RRset
-
- One RR is added to the Update Section whose NAME and TYPE are those
- of the RRset to be deleted. TTL must be specified as zero (0) and is
- otherwise not used by the primary master. CLASS must be specified as
- ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty.
- If no such RRset exists, then this Update RR will be silently ignored
- by the primary master.
-
- 2.5.3 - Delete All RRsets From A Name
-
- One RR is added to the Update Section whose NAME is that of the name
- to be cleansed of RRsets. TYPE must be specified as ANY. TTL must
- be specified as zero (0) and is otherwise not used by the primary
- master. CLASS must be specified as ANY. RDLENGTH must be zero (0)
- and RDATA must therefore be empty. If no such RRsets exist, then
- this Update RR will be silently ignored by the primary master.
-
- 2.5.4 - Delete An RR From An RRset
-
- RRs to be deleted are added to the Update Section. The NAME, TYPE,
- RDLENGTH and RDATA must match the RR being deleted. TTL must be
- specified as zero (0) and will otherwise be ignored by the primary
- master. CLASS must be specified as NONE to distinguish this from an
- RR addition. If no such RRs exist, then this Update RR will be
- silently ignored by the primary master.
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 9]
-
-RFC 2136 DNS Update April 1997
-
-
- 2.6 - Additional Data Section
-
- This section contains RRs which are related to the update itself, or
- to new RRs being added by the update. For example, out of zone glue
- (A RRs referred to by new NS RRs) should be presented here. The
- server can use or ignore out of zone glue, at the discretion of the
- server implementor. The format of this section is as specified by
- [RFC1035 4.1.3].
-
-3 - Server Behavior
-
- A server, upon receiving an UPDATE request, will signal NOTIMP to the
- requestor if the UPDATE opcode is not recognized or if it is
- recognized but has not been implemented. Otherwise, processing
- continues as follows.
-
- 3.1 - Process Zone Section
-
- 3.1.1. The Zone Section is checked to see that there is exactly one
- RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
- requestor. Next, the ZNAME and ZCLASS are checked to see if the zone
- so named is one of this server's authority zones, else signal NOTAUTH
- to the requestor. If the server is a zone slave, the request will be
- forwarded toward the primary master.
-
- 3.1.2 - Pseudocode For Zone Section Processing
-
- if (zcount != 1 || ztype != SOA)
- return (FORMERR)
- if (zone_type(zname, zclass) == SLAVE)
- return forward()
- if (zone_type(zname, zclass) == MASTER)
- return update()
- return (NOTAUTH)
-
- Sections 3.2 through 3.8 describe the primary master's behaviour,
- whereas Section 6 describes a forwarder's behaviour.
-
- 3.2 - Process Prerequisite Section
-
- Next, the Prerequisite Section is checked to see that all
- prerequisites are satisfied by the current state of the zone. Using
- the definitions expressed in Section 1.2, if any RR's NAME is not
- within the zone specified in the Zone Section, signal NOTZONE to the
- requestor.
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 10]
-
-RFC 2136 DNS Update April 1997
-
-
- 3.2.1. For RRs in this section whose CLASS is ANY, test to see that
- TTL and RDLENGTH are both zero (0), else signal FORMERR to the
- requestor. If TYPE is ANY, test to see that there is at least one RR
- in the zone whose NAME is the same as that of the Prerequisite RR,
- else signal NXDOMAIN to the requestor. If TYPE is not ANY, test to
- see that there is at least one RR in the zone whose NAME and TYPE are
- the same as that of the Prerequisite RR, else signal NXRRSET to the
- requestor.
-
- 3.2.2. For RRs in this section whose CLASS is NONE, test to see that
- the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
- requestor. If the TYPE is ANY, test to see that there are no RRs in
- the zone whose NAME is the same as that of the Prerequisite RR, else
- signal YXDOMAIN to the requestor. If the TYPE is not ANY, test to
- see that there are no RRs in the zone whose NAME and TYPE are the
- same as that of the Prerequisite RR, else signal YXRRSET to the
- requestor.
-
- 3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
- test to see that the TTL is zero (0), else signal FORMERR to the
- requestor. Then, build an RRset for each unique <NAME,TYPE> and
- compare each resulting RRset for set equality (same members, no more,
- no less) with RRsets in the zone. If any Prerequisite RRset is not
- entirely and exactly matched by a zone RRset, signal NXRRSET to the
- requestor. If any RR in this section has a CLASS other than ZCLASS
- or NONE or ANY, signal FORMERR to the requestor.
-
- 3.2.4 - Table Of Metavalues Used In Prerequisite Section
-
- CLASS TYPE RDATA Meaning
- ------------------------------------------------------------
- ANY ANY empty Name is in use
- ANY rrset empty RRset exists (value independent)
- NONE ANY empty Name is not in use
- NONE rrset empty RRset does not exist
- zone rrset rr RRset exists (value dependent)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 11]
-
-RFC 2136 DNS Update April 1997
-
-
- 3.2.5 - Pseudocode for Prerequisite Section Processing
-
- for rr in prerequisites
- if (rr.ttl != 0)
- return (FORMERR)
- if (zone_of(rr.name) != ZNAME)
- return (NOTZONE);
- if (rr.class == ANY)
- if (rr.rdlength != 0)
- return (FORMERR)
- if (rr.type == ANY)
- if (!zone_name<rr.name>)
- return (NXDOMAIN)
- else
- if (!zone_rrset<rr.name, rr.type>)
- return (NXRRSET)
- if (rr.class == NONE)
- if (rr.rdlength != 0)
- return (FORMERR)
- if (rr.type == ANY)
- if (zone_name<rr.name>)
- return (YXDOMAIN)
- else
- if (zone_rrset<rr.name, rr.type>)
- return (YXRRSET)
- if (rr.class == zclass)
- temp<rr.name, rr.type> += rr
- else
- return (FORMERR)
-
- for rrset in temp
- if (zone_rrset<rrset.name, rrset.type> != rrset)
- return (NXRRSET)
-
- 3.3 - Check Requestor's Permissions
-
- 3.3.1. Next, the requestor's permission to update the RRs named in
- the Update Section may be tested in an implementation dependent
- fashion or using mechanisms specified in a subsequent Secure DNS
- Update protocol. If the requestor does not have permission to
- perform these updates, the server may write a warning message in its
- operations log, and may either signal REFUSED to the requestor, or
- ignore the permission problem and proceed with the update.
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 12]
-
-RFC 2136 DNS Update April 1997
-
-
- 3.3.2. While the exact processing is implementation defined, if these
- verification activities are to be performed, this is the point in the
- server's processing where such performance should take place, since
- if a REFUSED condition is encountered after an update has been
- partially applied, it will be necessary to undo the partial update
- and restore the zone to its original state before answering the
- requestor.
-
- 3.3.3 - Pseudocode for Permission Checking
-
- if (security policy exists)
- if (this update is not permitted)
- if (local option)
- log a message about permission problem
- if (local option)
- return (REFUSED)
-
- 3.4 - Process Update Section
-
- Next, the Update Section is processed as follows.
-
- 3.4.1 - Prescan
-
- The Update Section is parsed into RRs and each RR's CLASS is checked
- to see if it is ANY, NONE, or the same as the Zone Class, else signal
- a FORMERR to the requestor. Using the definitions in Section 1.2,
- each RR's NAME must be in the zone specified by the Zone Section,
- else signal NOTZONE to the requestor.
-
- 3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
- ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
- unrecognized type, then signal FORMERR to the requestor. For RRs
- whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
- else signal a FORMERR to the requestor. For any RR whose CLASS is
- ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
- the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
- MAILB, or any other QUERY metatype besides ANY, or any unrecognized
- type, else signal FORMERR to the requestor.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 13]
-
-RFC 2136 DNS Update April 1997
-
-
- 3.4.1.3 - Pseudocode For Update Section Prescan
-
- [rr] for rr in updates
- if (zone_of(rr.name) != ZNAME)
- return (NOTZONE);
- if (rr.class == zclass)
- if (rr.type & ANY|AXFR|MAILA|MAILB)
- return (FORMERR)
- elsif (rr.class == ANY)
- if (rr.ttl != 0 || rr.rdlength != 0
- || rr.type & AXFR|MAILA|MAILB)
- return (FORMERR)
- elsif (rr.class == NONE)
- if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
- return (FORMERR)
- else
- return (FORMERR)
-
- 3.4.2 - Update
-
- The Update Section is parsed into RRs and these RRs are processed in
- order.
-
- 3.4.2.1. If any system failure (such as an out of memory condition,
- or a hardware error in persistent storage) occurs during the
- processing of this section, signal SERVFAIL to the requestor and undo
- all updates applied to the zone during this transaction.
-
- 3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
- the zone. In case of duplicate RDATAs (which for SOA RRs is always
- the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
- fields both match), the Zone RR is replaced by Update RR. If the
- TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
- lower (according to [RFC1982]) than or equal to the current Zone SOA
- RR's SOA.SERIAL, the Update RR is ignored. In the case of a CNAME
- Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
- Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
- RR.
-
- 3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
- all Zone RRs with the same NAME are deleted, unless the NAME is the
- same as ZNAME in which case only those RRs whose TYPE is other than
- SOA or NS are deleted. For any Update RR whose CLASS is ANY and
- whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
- deleted, unless the NAME is the same as ZNAME in which case neither
- SOA or NS RRs will be deleted.
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 14]
-
-RFC 2136 DNS Update April 1997
-
-
- 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
- NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
- unless the NAME is the same as ZNAME and either the TYPE is SOA or
- the TYPE is NS and the matching Zone RR is the only NS remaining in
- the RRset, in which case this Update RR is ignored.
-
- 3.4.2.5. Signal NOERROR to the requestor.
-
- 3.4.2.6 - Table Of Metavalues Used In Update Section
-
- CLASS TYPE RDATA Meaning
- ---------------------------------------------------------
- ANY ANY empty Delete all RRsets from a name
- ANY rrset empty Delete an RRset
- NONE rrset rr Delete an RR from an RRset
- zone rrset rr Add to an RRset
-
- 3.4.2.7 - Pseudocode For Update Section Processing
-
- [rr] for rr in updates
- if (rr.class == zclass)
- if (rr.type == CNAME)
- if (zone_rrset<rr.name, ~CNAME>)
- next [rr]
- elsif (zone_rrset<rr.name, CNAME>)
- next [rr]
- if (rr.type == SOA)
- if (!zone_rrset<rr.name, SOA> ||
- zone_rr<rr.name, SOA>.serial > rr.soa.serial)
- next [rr]
- for zrr in zone_rrset<rr.name, rr.type>
- if (rr.type == CNAME || rr.type == SOA ||
- (rr.type == WKS && rr.proto == zrr.proto &&
- rr.address == zrr.address) ||
- rr.rdata == zrr.rdata)
- zrr = rr
- next [rr]
- zone_rrset<rr.name, rr.type> += rr
- elsif (rr.class == ANY)
- if (rr.type == ANY)
- if (rr.name == zname)
- zone_rrset<rr.name, ~(SOA|NS)> = Nil
- else
- zone_rrset<rr.name, *> = Nil
- elsif (rr.name == zname &&
- (rr.type == SOA || rr.type == NS))
- next [rr]
- else
-
-
-
-Vixie, et. al. Standards Track [Page 15]
-
-RFC 2136 DNS Update April 1997
-
-
- zone_rrset<rr.name, rr.type> = Nil
- elsif (rr.class == NONE)
- if (rr.type == SOA)
- next [rr]
- if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
- next [rr]
- zone_rr<rr.name, rr.type, rr.data> = Nil
- return (NOERROR)
-
- 3.5 - Stability
-
- When a zone is modified by an UPDATE operation, the server must
- commit the change to nonvolatile storage before sending a response to
- the requestor or answering any queries or transfers for the modified
- zone. It is reasonable for a server to store only the update records
- as long as a system reboot or power failure will cause these update
- records to be incorporated into the zone the next time the server is
- started. It is also reasonable for the server to copy the entire
- modified zone to nonvolatile storage after each update operation,
- though this would have suboptimal performance for large zones.
-
- 3.6 - Zone Identity
-
- If the zone's SOA SERIAL is changed by an update operation, that
- change must be in a positive direction (using modulo 2**32 arithmetic
- as specified by [RFC1982]). Attempts to replace an SOA with one
- whose SERIAL is less than the current one will be silently ignored by
- the primary master server.
-
- If the zone's SOA's SERIAL is not changed as a result of an update
- operation, then the server shall increment it automatically before
- the SOA or any changed name or RR or RRset is included in any
- response or transfer. The primary master server's implementor might
- choose to autoincrement the SOA SERIAL if any of the following events
- occurs:
-
- (1) Each update operation.
-
- (2) A name, RR or RRset in the zone has changed and has subsequently
- been visible to a DNS client since the unincremented SOA was
- visible to a DNS client, and the SOA is about to become visible
- to a DNS client.
-
- (3) A configurable period of time has elapsed since the last update
- operation. This period shall be less than or equal to one third
- of the zone refresh time, and the default shall be the lesser of
- that maximum and 300 seconds.
-
-
-
-
-Vixie, et. al. Standards Track [Page 16]
-
-RFC 2136 DNS Update April 1997
-
-
- (4) A configurable number of updates has been applied since the last
- SOA change. The default value for this configuration parameter
- shall be one hundred (100).
-
- It is imperative that the zone's contents and the SOA's SERIAL be
- tightly synchronized. If the zone appears to change, the SOA must
- appear to change as well.
-
- 3.7 - Atomicity
-
- During the processing of an UPDATE transaction, the server must
- ensure atomicity with respect to other (concurrent) UPDATE or QUERY
- transactions. No two transactions can be processed concurrently if
- either depends on the final results of the other; in particular, a
- QUERY should not be able to retrieve RRsets which have been partially
- modified by a concurrent UPDATE, and an UPDATE should not be able to
- start from prerequisites that might not still hold at the completion
- of some other concurrent UPDATE. Finally, if two UPDATE transactions
- would modify the same names, RRs or RRsets, then such UPDATE
- transactions must be serialized.
-
- 3.8 - Response
-
- At the end of UPDATE processing, a response code will be known. A
- response message is generated by copying the ID and Opcode fields
- from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
- and ADCOUNT fields and associated sections, or placing zeros (0) in
- the these "count" fields and not including any part of the original
- update. The QR bit is set to one (1), and the response is sent back
- to the requestor. If the requestor used UDP, then the response will
- be sent to the requestor's source UDP port. If the requestor used
- TCP, then the response will be sent back on the requestor's open TCP
- connection.
-
-4 - Requestor Behaviour
-
- 4.1. From a requestor's point of view, any authoritative server for
- the zone can appear to be able to process update requests, even
- though only the primary master server is actually able to modify the
- zone's master file. Requestors are expected to know the name of the
- zone they intend to update and to know or be able to determine the
- name servers for that zone.
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 17]
-
-RFC 2136 DNS Update April 1997
-
-
- 4.2. If update ordering is desired, the requestor will need to know
- the value of the existing SOA RR. Requestors who update the SOA RR
- must update the SOA SERIAL field in a positive direction (as defined
- by [RFC1982]) and also preserve the other SOA fields unless the
- requestor's explicit intent is to change them. The SOA SERIAL field
- must never be set to zero (0).
-
- 4.3. If the requestor has reasonable cause to believe that all of a
- zone's servers will be equally reachable, then it should arrange to
- try the primary master server (as given by the SOA MNAME field if
- matched by some NS NSDNAME) first to avoid unnecessary forwarding
- inside the slave servers. (Note that the primary master will in some
- cases not be reachable by all requestors, due to firewalls or network
- partitioning.)
-
- 4.4. Once the zone's name servers been found and possibly sorted so
- that the ones more likely to be reachable and/or support the UPDATE
- opcode are listed first, the requestor composes an UPDATE message of
- the following form and sends it to the first name server on its list:
-
- ID: (new)
- Opcode: UPDATE
- Zone zcount: 1
- Zone zname: (zone name)
- Zone zclass: (zone class)
- Zone ztype: T_SOA
- Prerequisite Section: (see previous text)
- Update Section: (see previous text)
- Additional Data Section: (empty)
-
- 4.5. If the requestor receives a response, and the response has an
- RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
- appropriate response to its caller.
-
- 4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
- if no response is received within an implementation dependent timeout
- period, or if an ICMP error is received indicating that the server's
- port is unreachable, then the requestor will delete the unusable
- server from its internal name server list and try the next one,
- repeating until the name server list is empty. If the requestor runs
- out of servers to try, an appropriate error will be returned to the
- requestor's caller.
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 18]
-
-RFC 2136 DNS Update April 1997
-
-
-5 - Duplicate Detection, Ordering and Mutual Exclusion
-
- 5.1. For correct operation, mechanisms may be needed to ensure
- idempotence, order UPDATE requests and provide mutual exclusion. An
- UPDATE message or response might be delivered zero times, one time,
- or multiple times. Datagram duplication is of particular interest
- since it covers the case of the so-called "replay attack" where a
- correct request is duplicated maliciously by an intruder.
-
- 5.2. Multiple UPDATE requests or responses in transit might be
- delivered in any order, due to network topology changes or load
- balancing, or to multipath forwarding graphs wherein several slave
- servers all forward to the primary master. In some cases, it might
- be required that the earlier update not be applied after the later
- update, where "earlier" and "later" are defined by an external time
- base visible to some set of requestors, rather than by the order of
- request receipt at the primary master.
-
- 5.3. A requestor can ensure transaction idempotence by explicitly
- deleting some "marker RR" (rather than deleting the RRset of which it
- is a part) and then adding a new "marker RR" with a different RDATA
- field. The Prerequisite Section should specify that the original
- "marker RR" must be present in order for this UPDATE message to be
- accepted by the server.
-
- 5.4. If the request is duplicated by a network error, all duplicate
- requests will fail since only the first will find the original
- "marker RR" present and having its known previous value. The
- decisions of whether to use such a "marker RR" and what RR to use are
- left up to the application programmer, though one obvious choice is
- the zone's SOA RR as described below.
-
- 5.5. Requestors can ensure update ordering by externally
- synchronizing their use of successive values of the "marker RR."
- Mutual exclusion can be addressed as a degenerate case, in that a
- single succession of the "marker RR" is all that is needed.
-
- 5.6. A special case where update ordering and datagram duplication
- intersect is when an RR validly changes to some new value and then
- back to its previous value. Without a "marker RR" as described
- above, this sequence of updates can leave the zone in an undefined
- state if datagrams are duplicated.
-
- 5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
- a requestor could first retrieve the SOA RR, and build an UPDATE
- message one of whose prerequisites was the old SOA RR. It would then
- specify updates that would delete this SOA RR and add a new one with
- an incremented SOA SERIAL, along with whatever actual prerequisites
-
-
-
-Vixie, et. al. Standards Track [Page 19]
-
-RFC 2136 DNS Update April 1997
-
-
- and updates were the object of the transaction. If the transaction
- succeeds, the requestor knows that the RRs being changed were not
- otherwise altered by any other requestor.
-
-6 - Forwarding
-
- When a zone slave forwards an UPDATE message upward toward the zone's
- primary master server, it must allocate a new ID and prepare to enter
- the role of "forwarding server," which is a requestor with respect to
- the forward server.
-
- 6.1. The set of forward servers will be same as the set of servers
- this zone slave would use as the source of AXFR or IXFR data. So,
- while the original requestor might have used the zone's NS RRset to
- locate its update server, a forwarder always forwards toward its
- designated zone master servers.
-
- 6.2. If the original requestor used TCP, then the TCP connection from
- the requestor is still open and the forwarder must use TCP to forward
- the message. If the original requestor used UDP, the forwarder may
- use either UDP or TCP to forward the message, at the whim of the
- implementor.
-
- 6.3. It is reasonable for forward servers to be forwarders
- themselves, if the AXFR dependency graph being followed is a deep one
- involving firewalls and multiple connectivity realms. In most cases
- the AXFR dependency graph will be shallow and the forward server will
- be the primary master server.
-
- 6.4. The forwarder will not respond to its requestor until it
- receives a response from its forward server. UPDATE transactions
- involving forwarders are therefore time synchronized with respect to
- the original requestor and the primary master server.
-
- 6.5. When there are multiple possible sources of AXFR data and
- therefore multiple possible forward servers, a forwarder will use the
- same fallback strategy with respect to connectivity or timeout errors
- that it would use when performing an AXFR. This is implementation
- dependent.
-
- 6.6. When a forwarder receives a response from a forward server, it
- copies this response into a new response message, assigns its
- requestor's ID to that message, and sends the response back to the
- requestor.
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 20]
-
-RFC 2136 DNS Update April 1997
-
-
-7 - Design, Implementation, Operation, and Protocol Notes
-
- Some of the principles which guided the design of this UPDATE
- specification are as follows. Note that these are not part of the
- formal specification and any disagreement between this section and
- any other section of this document should be resolved in favour of
- the other section.
-
- 7.1. Using metavalues for CLASS is possible only because all RRs in
- the packet are assumed to be in the same zone, and CLASS is an
- attribute of a zone rather than of an RRset. (It is for this reason
- that the Zone Section is not optional.)
-
- 7.2. Since there are no data-present or data-absent errors possible
- from processing the Update Section, any necessary data-present and
- data- absent dependencies should be specified in the Prerequisite
- Section.
-
- 7.3. The Additional Data Section can be used to supply a server with
- out of zone glue that will be needed in referrals. For example, if
- adding a new NS RR to HOME.VIX.COM specifying a nameserver called
- NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
- Data Section. Servers can use this information or ignore it, at the
- discretion of the implementor. We discourage caching this
- information for use in subsequent DNS responses.
-
- 7.4. The Additional Data Section might be used if some of the RRs
- later needed for Secure DNS Update are not actually zone updates, but
- rather ancillary keys or signatures not intended to be stored in the
- zone (as an update would be), yet necessary for validating the update
- operation.
-
- 7.5. It is expected that in the absence of Secure DNS Update, a
- server will only accept updates if they come from a source address
- that has been statically configured in the server's description of a
- primary master zone. DHCP servers would be likely candidates for
- inclusion in this statically configured list.
-
- 7.6. It is not possible to create a zone using this protocol, since
- there is no provision for a slave server to be told who its master
- servers are. It is expected that this protocol will be extended in
- the future to cover this case. Therefore, at this time, the addition
- of SOA RRs is unsupported. For similar reasons, deletion of SOA RRs
- is also unsupported.
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 21]
-
-RFC 2136 DNS Update April 1997
-
-
- 7.7. The prerequisite for specifying that a name own at least one RR
- differs semantically from QUERY, in that QUERY would return
- <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
- this name, while UPDATE's prerequisite condition [Section 2.4.4]
- would NOT be satisfied.
-
- 7.8. It is possible for a UDP response to be lost in transit and for
- a request to be retried due to a timeout condition. In this case an
- UPDATE that was successful the first time it was received by the
- primary master might ultimately appear to have failed when the
- response to a duplicate request is finally received by the requestor.
- (This is because the original prerequisites may no longer be
- satisfied after the update has been applied.) For this reason,
- requestors who require an accurate response code must use TCP.
-
- 7.9. Because a requestor who requires an accurate response code will
- initiate their UPDATE transaction using TCP, a forwarder who receives
- a request via TCP must forward it using TCP.
-
- 7.10. Deferral of SOA SERIAL autoincrements is made possible so that
- serial numbers can be conserved and wraparound at 2**32 can be made
- an infrequent occurance. Visible (to DNS clients) SOA SERIALs need
- to differ if the zone differs. Note that the Authority Section SOA
- in a QUERY response is a form of visibility, for the purposes of this
- prerequisite.
-
- 7.11. A zone's SOA SERIAL should never be set to zero (0) due to
- interoperability problems with some older but widely installed
- implementations of DNS. When incrementing an SOA SERIAL, if the
- result of the increment is zero (0) (as will be true when wrapping
- around 2**32), it is necessary to increment it again or set it to one
- (1). See [RFC1982] for more detail on this subject.
-
- 7.12. Due to the TTL minimalization necessary when caching an RRset,
- it is recommended that all TTLs in an RRset be set to the same value.
- While the DNS Message Format permits variant TTLs to exist in the
- same RRset, and this variance can exist inside a zone, such variance
- will have counterintuitive results and its use is discouraged.
-
- 7.13. Zone cut management presents some obscure corner cases to the
- add and delete operations in the Update Section. It is possible to
- delete an NS RR as long as it is not the last NS RR at the root of a
- zone. If deleting all RRs from a name, SOA and NS RRs at the root of
- a zone are unaffected. If deleting RRsets, it is not possible to
- delete either SOA or NS RRsets at the top of a zone. An attempt to
- add an SOA will be treated as a replace operation if an SOA already
- exists, or as a no-op if the SOA would be new.
-
-
-
-
-Vixie, et. al. Standards Track [Page 22]
-
-RFC 2136 DNS Update April 1997
-
-
- 7.14. No semantic checking is required in the primary master server
- when adding new RRs. Therefore a requestor can cause CNAME or NS or
- any other kind of RR to be added even if their target name does not
- exist or does not have the proper RRsets to make the original RR
- useful. Primary master servers that DO implement this kind of
- checking should take great care to avoid out-of-zone dependencies
- (whose veracity cannot be authoritatively checked) and should
- implement all such checking during the prescan phase.
-
- 7.15. Nonterminal or wildcard CNAMEs are not well specified by
- [RFC1035] and their use will probably lead to unpredictable results.
- Their use is discouraged.
-
- 7.16. Empty nonterminals (nodes with children but no RRs of their
- own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
- to a query of any type for that name. There is no provision for
- empty terminal nodes -- so if all RRs of a terminal node are deleted,
- the name is no longer in use, and queries of any type for that name
- will result in an NXDOMAIN response.
-
- 7.17. In a deep AXFR dependency graph, it has not historically been
- an error for slaves to depend mutually upon each other. This
- configuration has been used to enable a zone to flow from the primary
- master to all slaves even though not all slaves have continuous
- connectivity to the primary master. UPDATE's use of the AXFR
- dependency graph for forwarding prohibits this kind of dependency
- loop, since UPDATE forwarding has no loop detection analagous to the
- SOA SERIAL pretest used by AXFR.
-
- 7.18. Previously existing names which are occluded by a new zone cut
- are still considered part of the parent zone, for the purposes of
- zone transfers, even though queries for such names will be referred
- to the new subzone's servers. If a zone cut is removed, all parent
- zone names that were occluded by it will again become visible to
- queries. (This is a clarification of [RFC1034].)
-
- 7.19. If a server is authoritative for both a zone and its child,
- then queries for names at the zone cut between them will be answered
- authoritatively using only data from the child zone. (This is a
- clarification of [RFC1034].)
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 23]
-
-RFC 2136 DNS Update April 1997
-
-
- 7.20. Update ordering using the SOA RR is problematic since there is
- no way to know which of a zone's NS RRs represents the primary
- master, and the zone slaves can be out of date if their SOA.REFRESH
- timers have not elapsed since the last time the zone was changed on
- the primary master. We recommend that a zone needing ordered updates
- use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
- [RFC1995]), and that a client receiving a prerequisite error while
- attempting an ordered update simply retry after a random delay period
- to allow the zone to settle.
-
-8 - Security Considerations
-
- 8.1. In the absence of [RFC2137] or equivilent technology, the
- protocol described by this document makes it possible for anyone who
- can reach an authoritative name server to alter the contents of any
- zones on that server. This is a serious increase in vulnerability
- from the current technology. Therefore it is very strongly
- recommended that the protocols described in this document not be used
- without [RFC2137] or other equivalently strong security measures,
- e.g. IPsec.
-
- 8.2. A denial of service attack can be launched by flooding an update
- forwarder with TCP sessions containing updates that the primary
- master server will ultimately refuse due to permission problems.
- This arises due to the requirement that an update forwarder receiving
- a request via TCP use a synchronous TCP session for its forwarding
- operation. The connection management mechanisms of [RFC1035 4.2.2]
- are sufficient to prevent large scale damage from such an attack, but
- not to prevent some queries from going unanswered during the attack.
-
-Acknowledgements
-
- We would like to thank the IETF DNSIND working group for their input
- and assistance, in particular, Rob Austein, Randy Bush, Donald
- Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz. Special
- thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
- document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 24]
-
-RFC 2136 DNS Update April 1997
-
-
-References
-
- [RFC1035]
- Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [RFC1982]
- Elz, R., "Serial Number Arithmetic", RFC 1982, University of
- Melbourne, August 1996.
-
- [RFC1995]
- Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
- of Technology, August 1996.
-
- [RFC1996]
- Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
- RFC 1996, Internet Software Consortium, August 1996.
-
- [RFC2065]
- Eastlake, D., and C. Kaufman, "Domain Name System Protocol
- Security Extensions", RFC 2065, January 1997.
-
- [RFC2137]
- Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
- 2137, April 1997.
-
-Authors' Addresses
-
- Yakov Rekhter
- Cisco Systems
- 170 West Tasman Drive
- San Jose, CA 95134-1706
-
- Phone: +1 914 528 0090
- EMail: yakov@cisco.com
-
-
- Susan Thomson
- Bellcore
- 445 South Street
- Morristown, NJ 07960
-
- Phone: +1 201 829 4514
- EMail: set@thumper.bellcore.com
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 25]
-
-RFC 2136 DNS Update April 1997
-
-
- Jim Bound
- Digital Equipment Corp.
- 110 Spitbrook Rd ZK3-3/U14
- Nashua, NH 03062-2698
-
- Phone: +1 603 881 0400
- EMail: bound@zk3.dec.com
-
-
- Paul Vixie
- Internet Software Consortium
- Star Route Box 159A
- Woodside, CA 94062
-
- Phone: +1 415 747 0204
- EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al. Standards Track [Page 26]
-
-
diff --git a/contrib/bind9/doc/rfc/rfc2137.txt b/contrib/bind9/doc/rfc/rfc2137.txt
deleted file mode 100644
index ceb3613dde7df..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2137.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake 3rd
-Request for Comments: 2137 CyberCash, Inc.
-Updates: 1035 April 1997
-Category: Standards Track
-
-
- Secure Domain Name System Dynamic Update
-
-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.
-
-Abstract
-
- Domain Name System (DNS) protocol extensions have been defined to
- authenticate the data in DNS and provide key distribution services
- [RFC2065]. DNS Dynamic Update operations have also been defined
- [RFC2136], but without a detailed description of security for the
- update operation. This memo describes how to use DNSSEC digital
- signatures covering requests and data to secure updates and restrict
- updates to those authorized to perform them as indicated by the
- updater's possession of cryptographic keys.
-
-Acknowledgements
-
- The contributions of the following persons (who are listed in
- alphabetic order) to this memo are gratefully acknowledged:
-
- Olafur Gudmundsson (ogud@tis.com>
- Charlie Kaufman <Charlie_Kaufman@iris.com>
- Stuart Kwan <skwan@microsoft.com>
- Edward Lewis <lewis@tis.com>
-
-Table of Contents
-
- 1. Introduction............................................2
- 1.1 Overview of DNS Dynamic Update.........................2
- 1.2 Overview of DNS Security...............................2
- 2. Two Basic Modes.........................................3
- 3. Keys....................................................5
- 3.1 Update Keys............................................6
- 3.1.1 Update Key Name Scope................................6
- 3.1.2 Update Key Class Scope...............................6
- 3.1.3 Update Key Signatory Field...........................6
-
-
-
-Eastlake Standards Track [Page 1]
-
-RFC 2137 SDNSDU April 1997
-
-
- 3.2 Zone Keys and Update Modes.............................8
- 3.3 Wildcard Key Punch Through.............................9
- 4. Update Signatures.......................................9
- 4.1 Update Request Signatures..............................9
- 4.2 Update Data Signatures................................10
- 5. Security Considerations................................10
- References................................................10
- Author's Address..........................................11
-
-1. Introduction
-
- Dynamic update operations have been defined for the Domain Name
- System (DNS) in RFC 2136, but without a detailed description of
- security for those updates. Means of securing the DNS and using it
- for key distribution have been defined in RFC 2065.
-
- This memo proposes techniques based on the defined DNS security
- mechanisms to authenticate DNS updates.
-
- Familiarity with the DNS system [RFC 1034, 1035] is assumed.
- Familiarity with the DNS security and dynamic update proposals will
- be helpful.
-
-1.1 Overview of DNS Dynamic Update
-
- DNS dynamic update defines a new DNS opcode, new DNS request and
- response structure if that opcode is used, and new error codes. An
- update can specify complex combinations of deletion and insertion
- (with or without pre-existence testing) of resource records (RRs)
- with one or more owner names; however, all testing and changes for
- any particular DNS update request are restricted to a single zone.
- Updates occur at the primary server for a zone.
-
- The primary server for a secure dynamic zone must increment the zone
- SOA serial number when an update occurs or the next time the SOA is
- retrieved if one or more updates have occurred since the previous SOA
- retrieval and the updates themselves did not update the SOA.
-
-1.2 Overview of DNS Security
-
- DNS security authenticates data in the DNS by also storing digital
- signatures in the DNS as SIG resource records (RRs). A SIG RR
- provides a digital signature on the set of all RRs with the same
- owner name and class as the SIG and whose type is the type covered by
- the SIG. The SIG RR cryptographically binds the covered RR set to
- the signer, time signed, signature expiration date, etc. There are
- one or more keys associated with every secure zone and all data in
- the secure zone is signed either by a zone key or by a dynamic update
-
-
-
-Eastlake Standards Track [Page 2]
-
-RFC 2137 SDNSDU April 1997
-
-
- key tracing its authority to a zone key.
-
- DNS security also defines transaction SIGs and request SIGs.
- Transaction SIGs appear at the end of a response. Transaction SIGs
- authenticate the response and bind it to the corresponding request
- with the key of the host where the responding DNS server is. Request
- SIGs appear at the end of a request and authenticate the request with
- the key of the submitting entity.
-
- Request SIGs are the primary means of authenticating update requests.
-
- DNS security also permits the storage of public keys in the DNS via
- KEY RRs. These KEY RRs are also, of course, authenticated by SIG
- RRs. KEY RRs for zones are stored in their superzone and subzone
- servers, if any, so that the secure DNS tree of zones can be
- traversed by a security aware resolver.
-
-2. Two Basic Modes
-
- A dynamic secure zone is any secure DNS zone containing one or more
- KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
- RRs with the signatory field non-zero, and whose zone KEY RR
- signatory field indicates that updates are implemented. There are two
- basic modes of dynamic secure zone which relate to the update
- strategy, mode A and mode B. A summary comparison table is given
- below and then each mode is described.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 3]
-
-RFC 2137 SDNSDU April 1997
-
-
- SUMMARY OF DYNAMIC SECURE ZONE MODES
-
- CRITERIA: | MODE A | MODE B
- =========================+====================+===================
- Definition: | Zone Key Off line | Zone Key On line
- =========================+====================+===================
- Server Workload | Low | High
- -------------------------+--------------------+-------------------
- Static Data Security | Very High | Medium-High
- -------------------------+--------------------+-------------------
- Dynamic Data Security | Medium | Medium-High
- -------------------------+--------------------+-------------------
- Key Restrictions | Fine grain | Coarse grain
- -------------------------+--------------------+-------------------
- Dynamic Data Temporality | Transient | Permanent
- -------------------------+--------------------+-------------------
- Dynamic Key Rollover | No | Yes
- -------------------------+--------------------+-------------------
-
- For mode A, the zone owner key and static zone master file are always
- kept off-line for maximum security of the static zone contents.
-
- As a consequence, any dynamicly added or changed RRs are signed in
- the secure zone by their authorizing dynamic update key and they are
- backed up, along with this SIG RR, in a separate online dynamic
- master file. In this type of zone, server computation is minimized
- since the server need only check signatures on the update data and
- request, which have already been signed by the updater, generally a
- much faster operation than signing data. However, the AXFR SIG and
- NXT RRs which covers the zone under the zone key will not cover
- dynamically added data. Thus, for type A dynamic secure zones, zone
- transfer security is not automatically provided for dynamically added
- RRs, where they could be omitted, and authentication is not provided
- for the server denial of the existence of a dynamically added type.
- Because the dynamicly added RRs retain their update KEY signed SIG,
- finer grained control of updates can be implemented via bits in the
- KEY RR signatory field. Because dynamic data is only stored in the
- online dynamic master file and only authenticated by dynamic keys
- which expire, updates are transient in nature. Key rollover for an
- entity that can authorize dynamic updates is more cumbersome since
- the authority of their key must be traceable to a zone key and so, in
- general, they must securely communicate a new key to the zone
- authority for manual transfer to the off line static master file.
- NOTE: for this mode the zone SOA must be signed by a dynamic update
- key and that private key must be kept on line so that the SOA can be
- changed for updates.
-
-
-
-
-
-Eastlake Standards Track [Page 4]
-
-RFC 2137 SDNSDU April 1997
-
-
- For mode B, the zone owner key and master file are kept on-line at
- the zone primary server. When authenticated updates succeed, SIGs
- under the zone key for the resulting data (including the possible NXT
- type bit map changes) are calculated and these SIG (and possible NXT)
- changes are entered into the zone and the unified on-line master
- file. (The zone transfer AXFR SIG may be recalculated for each
- update or on demand when a zone transfer is requested and it is out
- of date.)
-
- As a consequence, this mode requires considerably more computational
- effort on the part of the server as the public/private keys are
- generally arranged so that signing (calculating a SIG) is more effort
- than verifying a signature. The security of static data in the zone
- is decreased because the ultimate state of the static data being
- served and the ultimate zone authority private key are all on-line on
- the net. This means that if the primary server is subverted, false
- data could be authenticated to secondaries and other
- servers/resolvers. On the other hand, this mode of operation means
- that data added dynamically is more secure than in mode A. Dynamic
- data will be covered by the AXFR SIG and thus always protected during
- zone transfers and will be included in NXT RRs so that it can be
- falsely denied by a server only to the same extent that static data
- can (i.e., if it is within a wild card scope). Because the zone key
- is used to sign all the zone data, the information as to who
- originated the current state of dynamic RR sets is lost, making
- unavailable the effects of some of the update control bits in the KEY
- RR signatory field. In addition, the incorporation of the updates
- into the primary master file and their authentication by the zone key
- makes then permanent in nature. Maintaining the zone key on-line
- also means that dynamic update keys which are signed by the zone key
- can be dynamically updated since the zone key is available to
- dynamically sign new values.
-
- NOTE: The Mode A / Mode B distinction only effects the validation
- and performance of update requests. It has no effect on retrievals.
- One reasonable operational scheme may be to keep a mostly static main
- zone operating in Mode A and have one or more dynamic subzones
- operating in Mode B.
-
-3. Keys
-
- Dynamic update requests depend on update keys as described in section
- 3.1 below. In addition, the zone secure dynamic update mode and
- availability of some options is indicated in the zone key. Finally,
- a special rule is used in searching for KEYs to validate updates as
- described in section 3.3.
-
-
-
-
-
-Eastlake Standards Track [Page 5]
-
-RFC 2137 SDNSDU April 1997
-
-
-3.1 Update Keys
-
- All update requests to a secure zone must include signatures by one
- or more key(s) that together can authorize that update. In order for
- the Domain Name System (DNS) server receiving the request to confirm
- this, the key or keys must be available to and authenticated by that
- server as a specially flagged KEY Resource Record.
-
- The scope of authority of such keys is indicated by their KEY RR
- owner name, class, and signatory field flags as described below. In
- addition, such KEY RRs must be entity or user keys and not have the
- authentication use prohibited bit on. All parts of the actual update
- must be within the scope of at least one of the keys used for a
- request SIG on the update request as described in section 4.
-
-3.1.1 Update Key Name Scope
-
- The owner name of any update authorizing KEY RR must (1) be the same
- as the owner name of any RRs being added or deleted or (2) a wildcard
- name including within its extended scope (see section 3.3) the name
- of any RRs being added or deleted and those RRs must be in the same
- zone.
-
-3.1.2 Update Key Class Scope
-
- The class of any update authorizing KEY RR must be the same as the
- class of any RR's being added or deleted.
-
-3.1.3 Update Key Signatory Field
-
- The four bit "signatory field" (see RFC 2065) of any update
- authorizing KEY RR must be non-zero. The bits have the meanings
- described below for non-zone keys (see section 3.2 for zone type
- keys).
-
- UPDATE KEY RR SIGNATORY FIELD BITS
-
- 0 1 2 3
- +-----------+-----------+-----------+-----------+
- | zone | strong | unique | general |
- +-----------+-----------+-----------+-----------+
-
- Bit 0, zone control - If nonzero, this key is authorized to attach,
- detach, and move zones by creating and deleting NS, glue A, and
- zone KEY RR(s). If zero, the key can not authorize any update
- that would effect such RRs. This bit is meaningful for both
- type A and type B dynamic secure zones.
-
-
-
-
-Eastlake Standards Track [Page 6]
-
-RFC 2137 SDNSDU April 1997
-
-
- NOTE: do not confuse the "zone" signatory field bit with the
- "zone" key type bit.
-
- Bit 1, strong update - If nonzero, this key is authorized to add and
- delete RRs even if there are other RRs with the same owner name
- and class that are authenticated by a SIG signed with a
- different dynamic update KEY. If zero, the key can only
- authorize updates where any existing RRs of the same owner and
- class are authenticated by a SIG using the same key. This bit
- is meaningful only for type A dynamic zones and is ignored in
- type B dynamic zones.
-
- Keeping this bit zero on multiple KEY RRs with the same or
- nested wild card owner names permits multiple entities to exist
- that can create and delete names but can not effect RRs with
- different owner names from any they created. In effect, this
- creates two levels of dynamic update key, strong and weak, where
- weak keys are limited in interfering with each other but a
- strong key can interfere with any weak keys or other strong
- keys.
-
- Bit 2, unique name update - If nonzero, this key is authorized to add
- and update RRs for only a single owner name. If there already
- exist RRs with one or more names signed by this key, they may be
- updated but no new name created until the number of existing
- names is reduced to zero. This bit is meaningful only for mode
- A dynamic zones and is ignored in mode B dynamic zones. This bit
- is meaningful only if the owner name is a wildcard. (Any
- dynamic update KEY with a non-wildcard name is, in effect, a
- unique name update key.)
-
- This bit can be used to restrict a KEY from flooding a zone with
- new names. In conjunction with a local administratively imposed
- limit on the number of dynamic RRs with a particular name, it
- can completely restrict a KEY from flooding a zone with RRs.
-
- Bit 3, general update - The general update signatory field bit has no
- special meaning. If the other three bits are all zero, it must
- be one so that the field is non-zero to designate that the key
- is an update key. The meaning of all values of the signatory
- field with the general bit and one or more other signatory field
- bits on is reserved.
-
- All the signatory bit update authorizations described above only
- apply if the update is within the name and class scope as per
- sections 3.1.1 and 3.1.2.
-
-
-
-
-
-Eastlake Standards Track [Page 7]
-
-RFC 2137 SDNSDU April 1997
-
-
-3.2 Zone Keys and Update Modes
-
- Zone type keys are automatically authorized to sign anything in their
- zone, of course, regardless of the value of their signatory field.
- For zone keys, the signatory field bits have different means than
- they they do for update keys, as shown below. The signatory field
- MUST be zero if dynamic update is not supported for a zone and MUST
- be non-zero if it is.
-
- ZONE KEY RR SIGNATORY FIELD BITS
-
- 0 1 2 3
- +-----------+-----------+-----------+-----------+
- | mode | strong | unique | general |
- +-----------+-----------+-----------+-----------+
-
- Bit 0, mode - This bit indicates the update mode for this zone. Zero
- indicates mode A while a one indicates mode B.
-
- Bit 1, strong update - If nonzero, this indicates that the "strong"
- key feature described in section 3.1.3 above is implemented and
- enabled for this secure zone. If zero, the feature is not
- available. Has no effect if the zone is a mode B secure update
- zone.
-
- Bit 2, unique name update - If nonzero, this indicates that the
- "unique name" feature described in section 3.1.3 above is
- implemented and enabled for this secure zone. If zero, this
- feature is not available. Has no effect if the zone is a mode B
- secure update zone.
-
- Bit 3, general - This bit has no special meeting. If dynamic update
- for a zone is supported and the other bits in the zone key
- signatory field are zero, it must be a one. The meaning of zone
- keys where the signatory field has the general bit and one or
- more other bits on is reserved.
-
- If there are multiple dynamic update KEY RRs for a zone and zone
- policy is in transition, they might have different non-zero signatory
- fields. In that case, strong and unique name restrictions must be
- enforced as long as there is a non-expired zone key being advertised
- that indicates mode A with the strong or unique name bit on
- respectively. Mode B updates MUST be supported as long as there is a
- non-expired zone key that indicates mode B. Mode A updates may be
- treated as mode B updates at server option if non-expired zone keys
- indicate that both are supported.
-
-
-
-
-
-Eastlake Standards Track [Page 8]
-
-RFC 2137 SDNSDU April 1997
-
-
- A server that will be executing update operations on a zone, that is,
- the primary master server, MUST not advertize a zone key that will
- attract requests for a mode or features that it can not support.
-
-3.3 Wildcard Key Punch Through
-
- Just as a zone key is valid throughout the entire zone, update keys
- with wildcard names are valid throughout their extended scope, within
- the zone. That is, they remain valid for any name that would match
- them, even existing specific names within their apparent scope.
-
- If this were not so, then whenever a name within a wildcard scope was
- created by dynamic update, it would be necessary to first create a
- copy of the KEY RR with this name, because otherwise the existence of
- the more specific name would hide the authorizing KEY RR and would
- make later updates impossible. An updater could create such a KEY RR
- but could not zone sign it with their authorizing signer. They would
- have to sign it with the same key using the wildcard name as signer.
- Thus in creating, for example, one hundred type A RRs authorized by a
- *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
- KEYs, and 200 SIGs would have to be created as opposed to merely 100
- As and 100 SIGs with key punch through.
-
-4. Update Signatures
-
- Two kinds of signatures can appear in updates. Request signatures,
- which are always required, cover the entire request and authenticate
- the DNS header, including opcode, counts, etc., as well as the data.
- Data signatures, on the other hand, appear only among the RRs to be
- added and are only required for mode A operation. These two types of
- signatures are described further below.
-
-4.1 Update Request Signatures
-
- An update can effect multiple owner names in a zone. It may be that
- these different names are covered by different dynamic update keys.
- For every owner name effected, the updater must know a private key
- valid for that name (and the zone's class) and must prove this by
- appending request SIG RRs under each such key.
-
- As specified in RFC 2065, a request signature is a SIG RR occurring
- at the end of a request with a type covered field of zero. For an
- update, request signatures occur in the Additional information
- section. Each request SIG signs the entire request, including DNS
- header, but excluding any other request SIG(s) and with the ARCOUNT
- in the DNS header set to what it wold be without the request SIGs.
-
-
-
-
-
-Eastlake Standards Track [Page 9]
-
-RFC 2137 SDNSDU April 1997
-
-
-4.2 Update Data Signatures
-
- Mode A dynamic secure zones require that the update requester provide
- SIG RRs that will authenticate the after update state of all RR sets
- that are changed by the update and are non-empty after the update.
- These SIG RRs appear in the request as RRs to be added and the
- request must delete any previous data SIG RRs that are invalidated by
- the request.
-
- In Mode B dynamic secure zones, all zone data is authenticated by
- zone key SIG RRs. In this case, data signatures need not be included
- with the update. A resolver can determine which mode an updatable
- secure zone is using by examining the signatory field bits of the
- zone KEY RR (see section 3.2).
-
-5. Security Considerations
-
- Any zone permitting dynamic updates is inherently less secure than a
- static secure zone maintained off line as recommended in RFC 2065. If
- nothing else, secure dynamic update requires on line change to and
- re-signing of the zone SOA resource record (RR) to increase the SOA
- serial number. This means that compromise of the primary server host
- could lead to arbitrary serial number changes.
-
- Isolation of dynamic RRs to separate zones from those holding most
- static RRs can limit the damage that could occur from breach of a
- dynamic zone's security.
-
-References
-
- [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
- Extensions", RFC 2065, CyberCash, Iris, January 1997.
-
- [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specifications", STD 13, RFC 1035, November 1987.
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 10]
-
-RFC 2137 SDNSDU April 1997
-
-
-Author's Address
-
- Donald E. Eastlake, 3rd
- CyberCash, Inc.
- 318 Acton Street
- Carlisle, MA 01741 USA
-
- Phone: +1 508-287-4877
- +1 508-371-7148 (fax)
- +1 703-620-4200 (main office, Reston, Virginia, USA)
- EMail: dee@cybercash.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc2163.txt b/contrib/bind9/doc/rfc/rfc2163.txt
deleted file mode 100644
index 00fcee7c8843a..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2163.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group C. Allocchio
-Request for Comments: 2163 GARR-Italy
-Obsoletes: 1664 January 1998
-Category: Standards Track
-
-
- Using the Internet DNS to Distribute
- MIXER Conformant Global Address Mapping (MCGAM)
-
-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 (1998). All Rights Reserved.
-
-Abstract
-
- This memo is the complete technical specification to store in the
- Internet Domain Name System (DNS) the mapping information (MCGAM)
- needed by MIXER conformant e-mail gateways and other tools to map
- RFC822 domain names into X.400 O/R names and vice versa. Mapping
- information can be managed in a distributed rather than a centralised
- way. Organizations can publish their MIXER mapping or preferred
- gateway routing information using just local resources (their local
- DNS server), avoiding the need for a strong coordination with any
- centralised organization. MIXER conformant gateways and tools located
- on Internet hosts can retrieve the mapping information querying the
- DNS instead of having fixed tables which need to be centrally updated
- and distributed.
-
- This memo obsoletes RFC1664. It includes the changes introduced by
- MIXER specification with respect to RFC1327: the new 'gate1' (O/R
- addresses to domain) table is fully supported. Full backward
- compatibility with RFC1664 specification is mantained, too.
-
- RFC1664 was a joint effort of IETF X400 operation working group
- (x400ops) and TERENA (formely named "RARE") Mail and Messaging
- working group (WG-MSG). This update was performed by the IETF MIXER
- working group.
-
-
-
-
-
-
-Allocchio Standards Track [Page 1]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
-1. Introduction
-
- The connectivity between the Internet SMTP mail and other mail
- services, including the Internet X.400 mail and the commercial X.400
- service providers, is assured by the Mail eXchanger (MX) record
- information distributed via the Internet Domain Name System (DNS). A
- number of documents then specify in details how to convert or encode
- addresses from/to RFC822 style to the other mail system syntax.
- However, only conversion methods provide, via some algorithm or a set
- of mapping rules, a smooth translation, resulting in addresses
- indistinguishable from the native ones in both RFC822 and foreign
- world.
-
- MIXER describes a set of mappings (MIXER Conformant Global Address
- Mapping - MCGAM) which will enable interworking between systems
- operating the CCITT X.400 (1984/88/92) Recommendations and systems
- using using the RFC822 mail protocol, or protocols derived from
- RFC822. That document addresses conversion of services, addresses,
- message envelopes, and message bodies between the two mail systems.
- This document is concerned with one aspect of MIXER: the mechanism
- for mapping between X.400 O/R addresses and RFC822 domain names. As
- described in Appendix F of MIXER, implementation of the mappings
- requires a database which maps between X.400 O/R addresses and domain
- names; in RFC1327 this database was statically defined.
-
- The original approach in RFC1327 required many efforts to maintain
- the correct mapping: all the gateways needed to get coherent tables
- to apply the same mappings, the conversion tables had to be
- distributed among all the operational gateways, and also every update
- needed to be distributed.
-
- The concept of mapping rules distribution and use has been revised in
- the new MIXER specification, introducing the concept of MIXER
- Conformant Global Address Mapping (MCGAM). A MCGAM does not need to
- be globally installed by any MIXER conformant gateway in the world
- any more. However MIXER requires now efficient methods to publish its
- MCGAM.
-
- Static tables are one of the possible methods to publish MCGAM.
- However this static mechanism requires quite a long time to be spent
- modifying and distributing the information, putting heavy constraints
- on the time schedule of every update. In fact it does not appear
- efficient compared to the Internet Domain Name Service (DNS). More
- over it does not look feasible to distribute the database to a large
- number of other useful applications, like local address converters,
- e-mail User Agents or any other tool requiring the mapping rules to
- produce correct results.
-
-
-
-
-Allocchio Standards Track [Page 2]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- Two much more efficient methods are proposed by MIXER for publication
- of MCGAM: the Internet DNS and X.500. This memo is the complete
- technical specification for publishing MCGAM via Internet DNS.
-
- A first proposal to use the Internet DNS to store, retrieve and
- maintain those mappings was introduced by two of the authors of
- RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record
- (RR) types: TO-X400 and TO-822. This proposal now adopts a more
- complete strategy, and requires one new RR only. The distribution of
- MCGAMs via DNS is in fact an important service for the whole Internet
- community: it completes the information given by MX resource record
- and it allows to produce clean addresses when messages are exchanged
- among the Internet RFC822 world and the X.400 one (both Internet and
- Public X.400 service providers).
-
- A first experiment in using the DNS without expanding the current set
- of RR and using available ones was deployed by some of the authors of
- RFC1664 at the time of its development. The existing PTR resource
- records were used to store the mapping rules, and a new DNS tree was
- created under the ".it" top level domain. The result of the
- experiment was positive, and a few test applications ran under this
- provisional set up. This test was also very useful in order to define
- a possible migration strategy during the deployment of the new DNS
- containing the new RR. The Internet DNS nameservers wishing to
- provide this mapping information need in fact to be modified to
- support the new RR type, and in the real Internet, due to the large
- number of different implementations, this takes some time.
-
- The basic idea is to adopt a new DNS RR to store the mapping
- information. The RFC822 to X.400 mapping rules (including the so
- called 'gate2' rules) will be stored in the ordinary DNS tree, while
- the definition of a new branch of the name space defined under each
- national top level domain is envisaged in order to contain the X.400
- to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping
- resolution schema is thus fully implemented.
-
- The creation of the new domain name space representing the X.400 O/R
- names structure also provides the chance to use the DNS to distribute
- dynamically other X.400 related information, thus solving other
- efficiency problems currently affecting the X.400 MHS service.
-
- In this paper we will adopt the MCGAM syntax, showing how it can be
- stored into the Internet DNS.
-
-
-
-
-
-
-
-
-Allocchio Standards Track [Page 3]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
-1.1 Definitions syntax
-
- The definitions in this document is given in BNF-like syntax, using
- the following conventions:
-
- | means choice
- \ is used for continuation of a definition over several lines
- [] means optional
- {} means repeated one or more times
-
- The definitions, however, are detailed only until a certain level,
- and below it self-explaining character text strings will be used.
-
-2. Motivation
-
- Implementations of MIXER gateways require that a database store
- address mapping information for X.400 and RFC822. This information
- must be made available (published) to all MIXER gateways. In the
- Internet community, the DNS has proven to be a practical mean for
- providing a distributed name service. Advantages of using a DNS based
- system over a table based approach for mapping between O/R addresses
- and domain names are:
-
- - It avoids fetching and storing of entire mapping tables by every
- host that wishes to implement MIXER gateways and/or tools
-
- - Modifications to the DNS based mapping information can be made
- available in a more timely manner than with a table driven
- approach.
-
- - It allows full authority delegation, in agreement with the
- Internet regionalization process.
-
- - Table management is not necessarily required for DNS-based
- MIXER gateways.
-
- - One can determine the mappings in use by a remote gateway by
- querying the DNS (remote debugging).
-
- Also many other tools, like address converters and User Agents can
- take advantage of the real-time availability of MIXER tables,
- allowing a much easier maintenance of the information.
-
-3. The domain space for X.400 O/R name addresses
-
- Usual domain names (the ones normally used as the global part of an
- RFC822 e-mail address) and their associated information, i.e., host
- IP addresses, mail exchanger names, etc., are stored in the DNS as a
-
-
-
-Allocchio Standards Track [Page 4]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- distributed database under a number of top-level domains. Some top-
- level domains are used for traditional categories or international
- organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
- any country has its own two letter ISO country code as top-level
- domain (FR, DE, GB, IT, RU, ...), including "US" for USA. The
- special top-level/second-level couple IN-ADDR.ARPA is used to store
- the IP address to domain name relationship. This memo defines in the
- above structure the appropriate way to locate the X.400 O/R name
- space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
-
- The MIXER mapping information is composed by four tables:
-
- - 'table1' and 'gate1' gives the translation from X.400 to RFC822;
- - 'table2' and 'gate2' tables map RFC822 into X.400.
-
- Each mapping table is composed by mapping rules, and a single mapping
- rule is composed by a keyword (the argument of the mapping function
- derived from the address to be translated) and a translator (the
- mapping function parameter):
-
- keyword#translator#
-
- the '#' sign is a delimiter enclosing the translator. An example:
-
- foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
-
- Local mappings are not intended for use outside their restricted
- environment, thus they should not be included in DNS. If local
- mappings are used, they should be stored using static local tables,
- exactly as local static host tables can be used with DNS.
-
- The keyword of a 'table2' and 'gate2' table entry is a valid RFC822
- domain; thus the usual domain name space can be used without problems
- to store these entries.
- On the other hand, the keyword of a 'table1' and 'gate1' entry
- belongs to the X.400 O/R name space. The X.400 O/R name space does
- not usually fit into the usual domain name space, although there are
- a number of similarities; a new name structure is thus needed to
- represent it. This new name structure contains the X.400 mail
- domains.
-
- To ensure the correct functioning of the DNS system, the new X.400
- name structure must be hooked to the existing domain name space in a
- way which respects the existing name hierarchy.
-
- A possible solution was to create another special branch, starting
- from the root of the DNS tree, somehow similar to the in-addr.arpa
- tree. This idea would have required to establish a central authority
-
-
-
-Allocchio Standards Track [Page 5]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- to coordinate at international level the management of each national
- X.400 name tree, including the X.400 public service providers. This
- coordination problem is a heavy burden if approached globally. More
- over the X.400 name structure is very 'country oriented': thus while
- it requires a coordination at national level, it does not have
- concepts like the international root. In fact the X.400 international
- service is based on a large number of bilateral agreements, and only
- within some communities an international coordination service exists.
-
- The X.400 two letter ISO country codes, however, are the same used
- for the RFC822 country top-level domains and this gives us an
- appropriate hook to insert the new branches. The proposal is, in
- fact, to create under each national top level ISO country code a new
- branch in the name space. This branch represents exactly the X.400
- O/R name structure as defined in each single country, following the
- ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
- under each country top-level domain, and hence the national X.400
- name space derives its own structure:
-
- . (root)
- |
- +-----------------+-----------+--------+-----------------+...
- | | | |
- edu it us fr
- | | | |
- +---+---+... +-----+-----+... +-----+-----+... +--+---+...
- | | | | | | | | | |
- ... ... cnr X42D infn va ca X42D X42D inria
- | | | |
- +------------+------------+... ... ... +----+-------+...
- | | | | |
- ADMD-PtPostel ADMD-garr ADMD-Master400 ADMD-atlas ADMD-red
- | | | |
- +----------+----+... ... +-------+------+... ...
- | | | |
- PRMD-infn PRMD-STET PRMD-Telecom PRMD-Renault
- | | | |
- ... ... ... ...
-
-
- The creation of the X.400 new name tree at national level solves the
- problem of the international coordination. Actually the coordination
- problem is just moved at national level, but it thus becomes easier
- to solve. The coordination at national level between the X.400
- communities and the Internet world is already a requirement for the
- creation of the national static MIXER mapping tables; the use of the
- Internet DNS gives further motivations for this coordination.
-
-
-
-
-Allocchio Standards Track [Page 6]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- The coordination at national level also fits in the new concept of
- MCGAM pubblication. The DNS in fact allows a step by step authority
- distribution, up to a final complete delegation: thus organizations
- whishing to publish their MCGAM just need to receive delegation also
- for their branch of the new X.400 name space. A further advantage of
- the national based solution is to allow each country to set up its
- own X.400 name structure in DNS and to deploy its own authority
- delegation according to its local time scale and requirements, with
- no loss of global service in the mean time. And last, placing the new
- X.400 name tree and coordination process at national level fits into
- the Internet regionalization and internationalisation process, as it
- requires local bodies to take care of local coordination problems.
-
- The DNS name space thus contains completely the information required
- by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
- simple query to the nearest nameserver provides it. Moreover there is
- no more any need to store, maintain and distribute manually any
- mapping table. The new X.400 name space can also contain further
- information about the X.400 community, as DNS allows for it a
- complete set of resource records, and thus it allows further
- developments. This set of RRs in the new X.400 name space must be
- considered 'reserved' and thus not used until further specifications.
-
- The construction of the new domain space trees will follow the same
- procedures used when organising at first the already existing DNS
- space: at first the information will be stored in a quite centralised
- way, and distribution of authority will be gradually achieved. A
- separate document will describe the implementation phase and the
- methods to assure a smooth introduction of the new service.
-
-4. The new DNS resource record for MIXER mapping rules: PX
-
- The specification of the Internet DNS (RFC1035) provides a number of
- specific resource records (RRs) to contain specific pieces of
- information. In particular they contain the Mail eXchanger (MX) RR
- and the host Address (A) records which are used by the Internet SMTP
- mailers. As we will store the RFC822 to X.400 mapping information in
- the already existing DNS name tree, we need to define a new DNS RR in
- order to avoid any possible clash or misuse of already existing data
- structures. The same new RR will also be used to store the mappings
- from X.400 to RFC822. More over the mapping information, i.e., the
- MCGAMs, has a specific format and syntax which require an appropriate
- data structure and processing. A further advantage of defining a new
- RR is the ability to include flexibility for some eventual future
- development.
-
-
-
-
-
-
-Allocchio Standards Track [Page 7]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- The definition of the new 'PX' DNS resource record is:
-
- class: IN (Internet)
-
- name: PX (pointer to X.400/RFC822 mapping information)
-
- value: 26
-
- The PX RDATA format is:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PREFERENCE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MAP822 /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MAPX400 /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
- PREFERENCE A 16 bit integer which specifies the preference given to
- this RR among others at the same owner. Lower values
- are preferred;
-
- MAP822 A <domain-name> element containing <rfc822-domain>, the
- RFC822 part of the MCGAM;
-
- MAPX400 A <domain-name> element containing the value of
- <x400-in-domain-syntax> derived from the X.400 part of
- the MCGAM (see sect. 4.2);
-
- PX records cause no additional section processing. The PX RR format
- is the usual one:
-
- <name> [<class>] [<TTL>] <type> <RDATA>
-
- When we store in DNS a 'table1' or a 'gate1' entry, then <name> will
- be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we
- store a 'table2' or a 'gate2' table entry, <name> will be an RFC822
- mail domain name, including both fully qualified DNS domains and mail
- only domains (MX-only domains). All normal DNS conventions, like
- default values, wildcards, abbreviations and message compression,
- apply also for all the components of the PX RR. In particular <name>,
- MAP822 and MAPX400, as <domain-name> elements, must have the final
- "." (root) when they are fully qualified.
-
-
-
-
-Allocchio Standards Track [Page 8]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
-4.1 Additional features of the PX resource record
-
- The definition of the RDATA for the PX resource record, and the fact
- that DNS allows a distinction between an exact value and a wildcard
- match for the <name> parameter, represent an extension of the MIXER
- specification for mapping rules. In fact, any MCGAM entry is an
- implicit wildcard entry, i.e., the rule
-
- net2.it#PRMD$net2.ADMD$p400.C$it#
-
- covers any RFC822 domain ending with 'net2.it', unless more detailed
- rules for some subdomain in 'net2.it' are present. Thus there is no
- possibility to specify explicitly a MCGAM as an exact match only
- rule. In DNS an entry like
-
- *.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it.
-
- specify the usual wildcard match as for MIXER tables. However an
- entry like
-
- ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it.
-
- is valid only for an exact match of 'ab.net2.it' RFC822 domain.
-
- Note also that in DNS syntax there is no '#' delimiter around MAP822
- and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not
- allow the <blank> (ASCII decimal 32) character within these fields,
- making unneeded the use of an explicit delimiter as required in the
- MIXER original syntax.
-
- Another extension to the MIXER specifications is the PREFERENCE value
- defined as part of the PX RDATA section. This numeric value has
- exactly the same meaning than the similar one used for the MX RR. It
- is thus possible to specify more than one single mapping for a domain
- (both from RFC822 to X.400 and vice versa), giving as the preference
- order. In MIXER static tables, however, you cannot specify more than
- one mapping per each RFC822 domain, and the same restriction apply
- for any X.400 domain mapping to an RFC822 one.
-
- More over, in the X.400 recommendations a note suggests than an
- ADMD=<blank> should be reserved for some special cases. Various
- national functional profile specifications for an X.400 MHS states
- that if an X.400 PRMD is reachable via any of its national ADMDs,
- independently of its actual single or multiple connectivity with
- them, it should use ADMD=<blank> to advertise this fact. Again, if a
- PRMD has no connections to any ADMD it should use ADMD=0 to notify
- its status, etc. However, in most of the current real situations, the
- ADMD service providers do not accept messages coming from their
-
-
-
-Allocchio Standards Track [Page 9]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- subscribers if they have a blank ADMD, forcing them to have their own
- ADMD value. In such a situation there are problems in indicating
- properly the actually working mappings for domains with multiple
- connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
- take in consideration these problems.
-
- However, as these extensions are not available with MIXER static
- tables, it is strongly discouraged to use them when interworking with
- any table based gateway or application. The extensions were in fact
- introduced just to add more flexibility, like the PREFERENCE value,
- or they were already implicit in the DNS mechanism, like the
- wildcard specification. They should be used very carefully or just
- considered 'reserved for future use'. In particular, for current use,
- the PREFERENCE value in the PX record specification should be fixed
- to a value of 50, and only wildcard specifications should be used
- when specifying <name> values.
-
-4.2 The DNS syntax for an X.400 'domain'
-
- The syntax definition of the MCGAM rules is defined in appendix F of
- that document. However that syntax is not very human oriented and
- contains a number of characters which have a special meaning in other
- fields of the Internet DNS. Thus in order to avoid any possible
- problem, especially due to some old DNS implementations still being
- used in the Internet, we define a syntax for the X.400 part of any
- MCGAM rules (and hence for any X.400 O/R name) which makes it
- compatible with a <domain-name> element, i.e.,
-
- <domain-name> ::= <subdomain> | " "
- <subdomain> ::= <label> | <label> "." <subdomain>
- <label> ::= <alphanum>|
- <alphanum> {<alphanumhyphen>} <alphanum>
- <alphanum> ::= "0".."9" | "A".."Z" | "a".."z"
- <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
-
- (see RFC1035, section 2.3.1, page 8). The legal character set for
- <label> does not correspond to the IA5 Printablestring one used in
- MIXER to define MCGAM rules. However a very simple "escape mechanism"
- can be applied in order to bypass the problem. We can in fact simply
- describe the X.400 part of a MCGAM rule format as:
-
- <map-rule> ::= <map-elem> | <map-elem> { "." <map-elem> }
- <map-elem> ::= <attr-label> "$" <attr-value>
- <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
- <attr-value> ::= " " | "@" | IA5-Printablestring
-
-
-
-
-
-
-Allocchio Standards Track [Page 10]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- As you can notice <domain-name> and <map-rule> look similar, and also
- <label> and <map-elem> look the same. If we define the correct method
- to transform a <map-elem> into a <label> and vice versa the problem
- to write a MCGAM rule in <domain-name> syntax is solved.
-
- The RFC822 domain part of any MCGAM rule is of course already in
- <domain-name> syntax, and thus remains unchanged.
-
- In particular, in a 'table1' or 'gate1' mapping rule the 'keyword'
- value must be converted into <x400-in-domain-syntax> (X.400 mail DNS
- mail domain), while the 'translator' value is already a valid RFC822
- domain. Vice versa in a 'table2' or 'gate2' mapping rule, the
- 'translator' must be converted into <x400-in-domain-syntax>, while
- the 'keyword' is already a valid RFC822 domain.
-
-4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
-
- The problem of unmatching IA5-Printablestring and <label> character
- set definition is solved by a simple character mapping rule: whenever
- an IA5 character does not belong to <alphanumhyphen>, then it is
- mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
- small set of special rules is also defined for the most frequent
- cases. Moreover some frequent characters combinations used in MIXER
- rules are also mapped as special cases.
-
- Let's then define the following simple rules:
-
- MCGAM rule DNS store translation conditions
- -----------------------------------------------------------------
- <attr-label>$@ <attr-label> missing attribute
- <attr-label>$<blank> <attr-label>"b" blank attribute
- <attr-label>$xxx <attr-label>-xxx elsewhere
-
- Non <alphanumhyphen> characters in <attr-value>:
-
- MCGAM rule DNS store translation conditions
- -----------------------------------------------------------------
- - -h- hyphen
- \. -d- quoted dot
- <blank> -b- blank
- <non A/N character> -<3digit-decimal>- elsewhere
-
- If the DNS store translation of <attr-value> happens to end with an
- hyphen, then this last hyphen is omitted.
-
- Let's now have some examples:
-
-
-
-
-
-Allocchio Standards Track [Page 11]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- MCGAM rule DNS store translation conditions
- -----------------------------------------------------------------
- PRMD$@ PRMD missing attribute
- ADMD$<blank> ADMDb blank attribute
- ADMD$400-net ADMD-400-h-net hyphen mapping
- PRMD$UK\.BD PRMD-UK-d-BD quoted dot mapping
- O$ACME Inc\. O-ACME-b-Inc-d blank & final hyphen
- PRMD$main-400-a PRMD-main-h-400-h-a hyphen mapping
- O$-123-b O--h-123-h-b hyphen mapping
- OU$123-x OU-123-h-x hyphen mapping
- PRMD$Adis+co PRMD-Adis-043-co 3digit mapping
-
- Thus, an X.400 part from a MCGAM like
-
- OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
-
- translates to
-
- OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
-
- Another example:
-
- OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
-
- translates to
-
- OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
-
-4.2.2 Flow chart
-
- In order to achieve the proper DNS store translations of the X.400
- part of a MCGAM or any other X.400 O/R name, some software tools will
- be used. It is in fact evident that the above rules for converting
- mapping table from MIXER to DNS format (and vice versa) are not user
- friendly enough to think of a human made conversion.
-
- To help in designing such tools, we describe hereunder a small flow
- chart. The fundamental rule to be applied during translation is,
- however, the following:
-
- "A string must be parsed from left to right, moving appropriately
- the pointer in order not to consider again the already translated
- left section of the string in subsequent analysis."
-
-
-
-
-
-
-
-
-Allocchio Standards Track [Page 12]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- Flow chart 1 - Translation from MIXER to DNS format:
-
- parse single attribute
- (enclosed in "." separators)
- |
- (yes) --- <label>$@ ? --- (no)
- | |
- map to <label> (no) <label>$<blank> ? (yes)
- | | |
- | map to <label>- map to <label>"b"
- | | |
- | map "\." to -d- |
- | | |
- | map "-" to -h- |
- | | |
- | map non A/N char to -<3digit>- |
- restart | | |
- ^ | remove (if any) last "-" |
- | | | |
- | \-------> add a "." <--------------/
- | |
- \---------- take next attribute (if any)
-
-
- Flow chart 2 - Translation from DNS to MIXER format:
-
-
- parse single attribute
- (enclosed in "." separators)
- |
- (yes) ---- <label> ? ---- (no)
- | |
- map to <label>$@ (no) <label>"b" ? (yes)
- | | |
- | map to <label>$ map to <label>$<blank>
- | | |
- | map -d- to "\." |
- | | |
- | map -h- to "-" |
- | | |
- | map -b- to " " |
- restart | | |
- ^ | map -<3digit>- to non A/N char |
- | | | |
- | \--------> add a "." <----------/
- | |
- \------------- take next attribute (if any)
-
-
-
-
-Allocchio Standards Track [Page 13]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- Note that the above flow charts deal with the translation of the
- attributes syntax, only.
-
-4.2.3 The Country Code convention in the <name> value.
-
- The RFC822 domain space and the X.400 O/R address space, as said in
- section 3, have one specific common feature: the X.400 ISO country
- codes are the same as the RFC822 ISO top level domains for countries.
- In the previous sections we have also defined a method to write in
- <domain-name> syntax any X.400 domain, while in section 3 we
- described the new name space starting at each country top level
- domain under the X42D.cc (where 'cc' is then two letter ISO country
- code).
-
- The <name> value for a 'table1' or 'gate1' entry in DNS should thus
- be derived from the X.400 domain value, translated to <domain-name>
- syntax, adding the 'X42D.cc.' post-fix to it, i.e.,
-
- ADMD$acme.C$fr
-
- produces in <domain-name> syntax the key:
-
- ADMD-acme.C-fr
-
- which is post-fixed by 'X42D.fr.' resulting in:
-
- ADMD-acme.C-fr.X42D.fr.
-
- However, due to the identical encoding for X.400 country codes and
- RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
- clearly redundant.
-
- We thus define the 'Country Code convention' for the <name> key,
- i.e.,
-
- "The C-cc section of an X.400 domain in <domain-name> syntax must
- be omitted when creating a <name> key, as it is identical to the
- top level country code used to identify the DNS zone where the
- information is stored".
-
- Thus we obtain the following <name> key examples:
-
- X.400 domain DNS <name> key
- --------------------------------------------------------------------
- ADMD$acme.C$fr ADMD-acme.X42D.fr.
- PRMD$ux\.av.ADMD$ .C$gb PRMD-ux-d-av.ADMDb.X42D.gb.
- PRMD$ppb.ADMD$Dat 400.C$de PRMD-ppb.ADMD-Dat-b-400.X42D.de.
-
-
-
-
-Allocchio Standards Track [Page 14]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
-4.3 Creating the appropriate DNS files
-
- Using MIXER's assumption of an asymmetric mapping between X.400 and
- RFC822 addresses, two separate relations are required to store the
- mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS
- we will maintain the two different sections, even if they will both
- use the PX resource record. More over MIXER also specify two
- additional tables: MIXER 'gate1' and 'gate2' tables. These additional
- tables, however, have the same syntax rules than MIXER 'table1' and
- 'table2' respectively, and thus the same translation procedure as
- 'table1' and 'table2' will be applied; some details about the MIXER
- 'gate1' and 'gate2' tables are discussed in section 4.4.
-
- Let's now check how to create, from an MCGAM entry, the appropriate
- DNS entry in a DNS data file. We can again define an MCGAM entry as
- defined in appendix F of that document as:
-
- <x400-domain>#<rfc822-domain># (case A: 'table1' and 'gate1'
- entry)
-
- and
-
- <rfc822-domain>#<x400-domain># (case B: 'table2' and 'gate2'
- entry)
-
- The two cases must be considered separately. Let's consider case A.
-
- - take <x400-domain> and translate it into <domain-name> syntax,
- obtaining <x400-in-domain-syntax>;
- - create the <name> key from <x400-in-domain-syntax> i.e., apply
- the Country Code convention described in sect. 4.2.3;
- - construct the DNS PX record as:
-
- *.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax>
-
- Please note that within PX RDATA the <rfc822-domain> precedes the
- <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry.
-
- an example: from the 'table1' rule
-
- PRMD$ab.ADMD$ac.C$fr#ab.fr#
-
- we obtain
-
- *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr.
-
- Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
- fully qualified <domain-name> elements, thus ending with a ".".
-
-
-
-Allocchio Standards Track [Page 15]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- Let's now consider case B.
-
- - take <rfc822-domain> as <name> key;
- - translate <x400-domain> into <x400-in-domain-syntax>;
- - construct the DNS PX record as:
-
- *.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax>
-
- an example: from the 'table2' rule
-
- ab.fr#PRMD$ab.ADMD$ac.C$fr#
-
- we obtain
-
- *.ab.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr.
-
- Again note the fully qualified <domain-name> elements.
-
- A file containing the MIXER mapping rules and MIXER 'gate1' and
- 'gate2' table written in DNS format will look like the following
- fictious example:
-
- !
- ! MIXER table 1: X.400 --> RFC822
- !
- *.ADMD-acme.X42D.it. IN PX 50 it. ADMD-acme.C-it.
- *.PRMD-accred.ADMD-tx400.X42D.it. IN PX 50 \
- accred.it. PRMD-accred.ADMD-tx400.C-it.
- *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it. IN PX 50 \
- cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
- !
- ! MIXER table 2: RFC822 --> X.400
- !
- *.nrc.it. IN PX 50 nrc.it. PRMD-nrc.ADMD-acme.C-it.
- *.ninp.it. IN PX 50 ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
- *.bd.it. IN PX 50 bd.it. PRMD-uk-d-bd.ADMDb.C-it.
- !
- ! MIXER Gate 1 Table
- !
- *.ADMD-XKW-h-Mail.X42D.it. IN PX 50 \
- XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
- *.PRMD-Super-b-Inc.ADMDb.X42D.it. IN PX 50 \
- GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
- !
- ! MIXER Gate 2 Table
- !
- my.it. IN PX 50 my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
- co.it. IN PX 50 co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.
-
-
-
-Allocchio Standards Track [Page 16]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- (here the "\" indicates continuation on the same line, as wrapping is
- done only due to typographical reasons).
-
- Note the special suffix ".G." on the right side of the 'gate1' and
- 'gate2' Tables section whose aim is described in section 4.4. The
- corresponding MIXER tables are:
-
- #
- # MIXER table 1: X.400 --> RFC822
- #
- ADMD$acme.C$it#it#
- PRMD$accred.ADMD$tx400.C$it#accred.it#
- O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
- #
- # MIXER table 2: RFC822 --> X.400
- #
- nrc.it#PRMD$nrc.ADMD$acme.C$it#
- ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
- bd.it#PRMD$uk\.bd.ADMD$ .C$it#
- #
- # MIXER Gate 1 Table
- #
- ADMD$XKW-Mail.C$it#XKW-gateway.it#
- PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
- #
- # MIXER Gate 2 Table
- #
- my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
- co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
-
-4.4 Storing the MIXER 'gate1' and 'gate2' tables
-
- Section 4.3.4 of MIXER also specify how an address should be
- converted between RFC822 and X.400 in case a complete mapping is
- impossible. To allow the use of DDAs for non mappable domains, the
- MIXER 'gate2' table is thus introduced.
-
- In a totally similar way, when an X.400 address cannot be completely
- converted in RFC822, section 4.3.5 of MIXER specifies how to encode
- (LHS encoding) the address itself, pointing then to the appropriate
- MIXER conformant gateway, indicated in the MIXER 'gate1' table.
-
- DNS must store and distribute also these 'gate1' and 'gate2' data.
-
- One of the major features of the DNS is the ability to distribute the
- authority: a certain site runs the "primary" nameserver for one
- determined sub-tree and thus it is also the only place allowed to
- update information regarding that sub-tree. This fact allows, in our
-
-
-
-Allocchio Standards Track [Page 17]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- case, a further additional feature to the table based approach. In
- fact we can avoid one possible ambiguity about the use of the 'gate1'
- and 'gate2' tables (and thus of LHS and DDAs encoding).
-
- The authority maintaining a DNS entry in the usual RFC822 domain
- space is the only one allowed to decide if its domain should be
- mapped using Standard Attributes (SA) syntax or Domain Defined
- Attributes (DDA) one. If the authority decides that its RFC822 domain
- should be mapped using SA, then the PX RDATA will be a 'table2'
- entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822
- domain we cannot have any more two possible entries, one from 'table2
- and another one from 'gate2' table, and the action for a gateway
- results clearly stated.
-
- Similarly, the authority mantaining a DNS entry in the new X.400 name
- space is the only one allowed to decide if its X.400 domain should be
- mapped using SA syntax or Left Hand Side (LHS) encoding. If the
- authority decides that its X.400 domain should be mapped using SA,
- then the PX RDATA will be a 'table1' entry, otherwise it will be a
- 'gate1' table entry. Thus also for an X.400 domain we cannot have any
- more two possible entries, one from 'table1' and another one from
- 'gate1' table, and the action for a gateway results clearly stated.
-
- The MIXER 'gate1' table syntax is actually identical to MIXER
- 'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
- Thus the same syntax translation rules from MIXER to DNS format can
- be applied in both cases. However a gateway or any other application
- must know if the answer it got from DNS contains some 'table1',
- 'table2' or some 'gate1', 'gate2' table information. This is easily
- obtained flagging with an additional ".G." post-fix the PX RDATA
- value when it contains a 'gate1' or 'gate2' table entry. The example
- in section 4.3 shows clearly the result. As any X.400 O/R domain must
- end with a country code ("C-xx" in our DNS syntax) the additional
- ".G." creates no conflicts or ambiguities at all. This postfix must
- obviously be removed before using the MIXER 'gate1' or 'gate2' table
- data.
-
-5. Finding MIXER mapping information from DNS
-
- The MIXER mapping information is stored in DNS both in the normal
- RFC822 domain name space, and in the newly defined X.400 name space.
- The information, stored in PX resource records, does not represent a
- full RFC822 or X.400 O/R address: it is a template which specifies
- the fields of the domain that are used by the mapping algorithm.
-
- When mapping information is stored in the DNS, queries to the DNS are
- issued whenever an iterative search through the mapping table would
- be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping
-
-
-
-Allocchio Standards Track [Page 18]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- B). Due to the DNS search mechanism, DNS by itself returns the
- longest possible match in the stored mapping rule with a single
- query, thus no iteration and/or multiple queries are needed. As
- specified in MIXER, a search of the mapping table will result in
- either success (mapping found) or failure (query failed, mapping not
- found).
-
- When a DNS query is issued, a third possible result is timeout. If
- the result is timeout, the gateway operation is delayed and then
- retried at a later time. A result of success or failure is processed
- according to the algorithms specified in MIXER. If a DNS error code
- is returned, an error message should be logged and the gateway
- operation is delayed as for timeout. These pathological situations,
- however, should be avoided with a careful duplication and chaching
- mechanism which DNS itself provides.
-
- Searching the nameserver which can authoritatively solve the query is
- automatically performed by the DNS distributed name service.
-
-5.1 A DNS query example
-
- An MIXER mail-gateway located in the Internet, when translating
- addresses from RFC822 to X.400, can get information about the MCGAM
- rule asking the DNS. As an example, when translating the address
- SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX
- resource record. The DNS should contain a PX record like this:
-
- *.cce.nrc.it. IN PX 50 cce.nrc.it. O-cce.PRMD-nrc.ADMD-acme.C-it.
-
- The first query will return immediately the appropriate mapping rule
- in DNS store format.
-
- There is no ".G." at the end of the obtained PX RDATA value, thus
- applying the syntax translation specified in paragraph 4.2 the MIXER
- Table 2 mapping rule will be obtained.
-
- Let's now take another example where a 'gate2' table rule is
- returned. If we are looking for an RFC822 domain ending with top
- level domain "MW", and the DNS contains a PX record like this,
-
- *.mw. IN PX 50 mw. O-cce.PRMD-nrc.ADMD-acme.C-it.G.
-
- DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
- 'gate2' table entry in DNS store format. Dropping the final ".G." and
- applying the syntax translation specified in paragraph 4.2 the
- original rule will be available. More over, the ".G." flag also tells
- the gateway to use DDA encoding for the inquired RFC822 domain.
-
-
-
-
-Allocchio Standards Track [Page 19]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- On the other hand, translating from X.400 to RFC822 the address
-
- C=de; ADMD=pkz; PRMD=nfc; O=top;
-
- the mail gateway should convert the syntax according to paragraph
- 4.2, apply the 'Country code convention' described in 4.2.3 to derive
- the appropriate DNS translation of the X.400 O/R name and then query
- DNS for the corresponding PX resource record. The obtained record for
- which the PX record must be queried is thus:
-
- O-top.PRMD-nfc.ADMD-pkz.X42D.de.
-
- The DNS could contain:
-
- *.ADMD-pkz.X42D.de. IN PX 50 pkz.de. ADMD-pkz.C-de.
-
- Assuming that there are not more specific records in DNS, the
- wildcard mechanism will return the MIXER 'table1' rule in encoded
- format.
-
- Finally, an example where a 'gate1' rule is involved. If we are
- looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the
- DNS contains a PX record like this,
-
- *.ADMD-PWT400.X42D.us. IN PX 50 intGw.com. ADMD-PWT400.C-us.G.
-
- DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a
- 'gate1' table entry in DNS store format. Dropping the final ".G." and
- applying the syntax translation specified in paragraph 4.2 the
- original rule will be available. More over, the ".G." flag also tells
- the gateway to use LHS encoding for the inquired X.400 domain.
-
-6. Administration of mapping information
-
- The DNS, using the PX RR, is able to distribute the MCGAM rules to
- all MIXER gateways located on the Internet. However, not all MIXER
- gateways will be able to use the Internet DNS. It is expected that
- some gateways in a particular management domain will conform to one
- of the following models:
-
- (a) Table-based, (b) DNS-based, (c) X.500-based
-
- Table-based management domains will continue to publish their MCGAM
- rules and retrieve the mapping tables via the International Mapping
- Table coordinator, manually or via some automated procedures. Their
- MCGAM information can be made available also in DNS by the
- appropriate DNS authorities, using the same mechanism already in
- place for MX records: if a branch has not yet in place its own DNS
-
-
-
-Allocchio Standards Track [Page 20]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- server, some higher authority in the DNS tree will provide the
- service for it. A transition procedure similar to the one used to
- migrate from the 'hosts.txt' tables to DNS can be applied also to the
- deployment phase of this specification. An informational document
- describing the implementation phase and the detailed coordination
- procedures is expected.
-
- Another distributed directory service which can distribute the MCGAM
- information is X.500. Coordination with table-based domains can be
- obtained in an identical way as for the DNS case.
-
- Coordination of MCGAM information between DNS and X.500 is more
- complex, as it requies some kind of uploading information between the
- two systems. The ideal solution is a dynamic alignment mechanism
- which transparently makes the DNS mapping information available in
- X.500 and vice versa. Some work in this specific field is already
- being done [see Costa] which can result in a global transparent
- directory service, where the information is stored in DNS or in
- X.500, but is visible completely by any of the two systems.
-
- However we must remind that MIXER concept of MCGAM rules publication
- is different from the old RFC1327 concept of globally distributed,
- coordinated and unique mapping rules. In fact MIXER does not requires
- any more for any conformant gateway or tool to know the complete set
- of MCGAM: it only requires to use some set (eventually empty) of
- valid MCGAM rules, published either by Tables, DNS or X.500
- mechanisms or any combination of these methods. More over MIXER
- specifies that also incomplete sets of MCGAM can be used, and
- supplementary local unpublished (but valid) MCGAM can also be used.
- As a consequence, the problem of coordination between the three
- systems proposed by MIXER for MCGAM publication is non essential, and
- important only for efficient operational matters. It does not in fact
- affect the correct behaviour of MIXER conformant gateways and tools.
-
-7. Conclusion
-
- The introduction of the new PX resource record and the definition of
- the X.400 O/R name space in the DNS structure provide a good
- repository for MCGAM information. The mapping information is stored
- in the DNS tree structure so that it can be easily obtained using the
- DNS distributed name service. At the same time the definition of the
- appropriate DNS space for X.400 O/R names provide a repository where
- to store and distribute some other X.400 MHS information. The use of
- the DNS has many known advantages in storing, managing and updating
- the information. A successful number of tests were been performed
- under the provisional top level domain "X400.IT" when RFC1664 was
- developed, and their results confirmed the advantages of the method.
- Operational exeprience for over 2 years with RFC1664 specification
-
-
-
-Allocchio Standards Track [Page 21]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- confirmed the feasibility of the method, and helped identifying some
- operational procedures to deploy the insertion of MCGAM into DNS.
-
- Software to query the DNS and then to convert between the textual
- representation of DNS resource records and the address format defined
- in MIXER was developed with RFC1664. This software also allows a
- smooth implementation and deployment period, eventually taking care
- of the transition phase. This software can be easily used (with
- little or null modification) also for this updated specification,
- supporting the new 'gate1' MIXER table. DNS software implementations
- supporting RFC1664 also supports with no modification this memo new
- specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio Standards Track [Page 22]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- A further informational document describing operational and
- implementation of the service is expected.
-
-8. Acknowledgements
-
- We wish to thanks all those who contributed to the discussion and
- revision of this document: many of their ideas and suggestions
- constitute essential parts of this work. In particular thanks to Jon
- Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
- TERENA wg-msg and IETF namedroppers groups. A special mention to
- Christian Huitema for his fundamental contribution to this work.
-
- This document is a revision of RFC1664, edited by one of its authors
- on behalf of the IETF MIXER working group. The current editor wishes
- to thank here also the authors of RFC1664:
-
- Antonio Blasco Bonito RFC822: bonito@cnuce.cnr.it
- CNUCE - CNR X.400: C=it;A=garr;P=cnr;
- Reparto infr. reti O=cnuce;S=bonito;
- Viale S. Maria 36
- I 56126 Pisa
- Italy
-
-
- Bruce Cole RFC822: bcole@cisco.com
- Cisco Systems Inc. X.400: C=us;A= ;P=Internet;
- P.O. Box 3075 DD.rfc-822=bcole(a)cisco.com;
- 1525 O'Brien Drive
- Menlo Park, CA 94026
- U.S.A.
-
-
- Silvia Giordano RFC822: giordano@cscs.ch
- Centro Svizzero di X.400: C=ch;A=arcom;P=switch;O=cscs;
- Calcolo Scientifico S=giordano;
- Via Cantonale
- CH 6928 Manno
- Switzerland
-
-
- Robert Hagens RFC822: hagens@ans.net
- Advanced Network and Services X.400: C=us;A= ;P=Internet;
- 1875 Campus Commons Drive DD.rfc-822=hagens(a)ans.net;
- Reston, VA 22091
- U.S.A.
-
-
-
-
-
-
-Allocchio Standards Track [Page 23]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
-9. References
-
- [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
- Systems: System Model - Service Elements", October 1988.
-
- [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
- 822", RFC 1327, March 1992.
-
- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, USC/Information Sciences Institute, November
- 1987.
-
- [RFC 1035] Mockapetris, P., "Domain names - Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
- 1033, SRI International, November 1987.
-
- [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
- Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
- January 1998.
-
- [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
- Managing DNS Information in the X.500 Directory", Proceeding of
- the 4th Joint European Networking Conference, Trondheim, NO, May
- 1993.
-
-10. Security Considerations
-
- This document specifies a means by which DNS "PX" records can direct
- the translation between X.400 and Internet mail addresses.
-
- This can indirectly affect the routing of mail across an gateway
- between X.400 and Internet Mail. A succesful attack on this service
- could cause incorrect translation of an originator address (thus
- "forging" the originator address), or incorrect translation of a
- recipient address (thus directing the mail to an unauthorized
- recipient, or making it appear to an authorized recipient, that the
- message was intended for recipients other than those chosen by the
- originator) or could force the mail path via some particular gateway
- or message transfer agent where mail security can be affected by
- compromised software.
-
-
-
-
-
-
-
-
-Allocchio Standards Track [Page 24]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
- There are several means by which an attacker might be able to deliver
- incorrect PX records to a client. These include: (a) compromise of a
- DNS server, (b) generating a counterfeit response to a client's DNS
- query, (c) returning incorrect "additional information" in response
- to an unrelated query.
-
- Clients using PX records SHOULD ensure that routing and address
- translations are based only on authoritative answers. Once DNS
- Security mechanisms [RFC 2065] become more widely deployed, clients
- SHOULD employ those mechanisms to verify the authenticity and
- integrity of PX records.
-
-11. Author's Address
-
- Claudio Allocchio
- Sincrotrone Trieste
- SS 14 Km 163.5 Basovizza
- I 34012 Trieste
- Italy
-
- RFC822: Claudio.Allocchio@elettra.trieste.it
- X.400: C=it;A=garr;P=Trieste;O=Elettra;
- S=Allocchio;G=Claudio;
- Phone: +39 40 3758523
- Fax: +39 40 3758565
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio Standards Track [Page 25]
-
-RFC 2163 MIXER MCGAM January 1998
-
-
-12. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio Standards Track [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2168.txt b/contrib/bind9/doc/rfc/rfc2168.txt
deleted file mode 100644
index 3eed1bdb4d11d..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2168.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Daniel
-Request for Comments: 2168 Los Alamos National Laboratory
-Category: Experimental M. Mealling
- Network Solutions, Inc.
- June 1997
-
-
- Resolution of Uniform Resource Identifiers
- using the Domain Name System
-
-Status of this Memo
-===================
-
- This memo defines an Experimental Protocol for the Internet
- community. This memo does not specify an Internet standard of any
- kind. Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-Abstract:
-=========
-
- Uniform Resource Locators (URLs) are the foundation of the World Wide
- Web, and are a vital Internet technology. However, they have proven
- to be brittle in practice. The basic problem is that URLs typically
- identify a particular path to a file on a particular host. There is
- no graceful way of changing the path or host once the URL has been
- assigned. Neither is there a graceful way of replicating the resource
- located by the URL to achieve better network utilization and/or fault
- tolerance. Uniform Resource Names (URNs) have been hypothesized as a
- adjunct to URLs that would overcome such problems. URNs and URLs are
- both instances of a broader class of identifiers known as Uniform
- Resource Identifiers (URIs).
-
- The requirements document for URN resolution systems[15] defines the
- concept of a "resolver discovery service". This document describes
- the first, experimental, RDS. It is implemented by a new DNS Resource
- Record, NAPTR (Naming Authority PoinTeR), that provides rules for
- mapping parts of URIs to domain names. By changing the mapping
- rules, we can change the host that is contacted to resolve a URI.
- This will allow a more graceful handling of URLs over long time
- periods, and forms the foundation for a new proposal for Uniform
- Resource Names.
-
-
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 1]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- In addition to locating resolvers, the NAPTR provides for other
- naming systems to be grandfathered into the URN world, provides
- independence between the name assignment system and the resolution
- protocol system, and allows multiple services (Name to Location, Name
- to Description, Name to Resource, ...) to be offered. In conjunction
- with the SRV RR, the NAPTR record allows those services to be
- replicated for the purposes of fault tolerance and load balancing.
-
-Introduction:
-=============
-
- Uniform Resource Locators have been a significant advance in
- retrieving Internet-accessible resources. However, their brittle
- nature over time has been recognized for several years. The Uniform
- Resource Identifier working group proposed the development of Uniform
- Resource Names to serve as persistent, location-independent
- identifiers for Internet resources in order to overcome most of the
- problems with URLs. RFC-1737 [1] sets forth requirements on URNs.
-
- During the lifetime of the URI-WG, a number of URN proposals were
- generated. The developers of several of those proposals met in a
- series of meetings, resulting in a compromise known as the Knoxville
- framework. The major principle behind the Knoxville framework is
- that the resolution system must be separate from the way names are
- assigned. This is in marked contrast to most URLs, which identify the
- host to contact and the protocol to use. Readers are referred to [2]
- for background on the Knoxville framework and for additional
- information on the context and purpose of this proposal.
-
- Separating the way names are resolved from the way they are
- constructed provides several benefits. It allows multiple naming
- approaches and resolution approaches to compete, as it allows
- different protocols and resolvers to be used. There is just one
- problem with such a separation - how do we resolve a name when it
- can't give us directions to its resolver?
-
- For the short term, DNS is the obvious candidate for the resolution
- framework, since it is widely deployed and understood. However, it is
- not appropriate to use DNS to maintain information on a per-resource
- basis. First of all, DNS was never intended to handle that many
- records. Second, the limited record size is inappropriate for catalog
- information. Third, domain names are not appropriate as URNs.
-
- Therefore our approach is to use DNS to locate "resolvers" that can
- provide information on individual resources, potentially including
- the resource itself. To accomplish this, we "rewrite" the URI into a
- domain name following the rules provided in NAPTR records. Rewrite
- rules provide considerable power, which is important when trying to
-
-
-
-Daniel & Mealling Experimental [Page 2]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- meet the goals listed above. However, collections of rules can become
- difficult to understand. To lessen this problem, the NAPTR rules are
- *always* applied to the original URI, *never* to the output of
- previous rules.
-
- Locating a resolver through the rewrite procedure may take multiple
- steps, but the beginning is always the same. The start of the URI is
- scanned to extract its colon-delimited prefix. (For URNs, the prefix
- is always "urn:" and we extract the following colon-delimited
- namespace identifier [3]). NAPTR resolution begins by taking the
- extracted string, appending the well-known suffix ".urn.net", and
- querying the DNS for NAPTR records at that domain name. Based on the
- results of this query, zero or more additional DNS queries may be
- needed to locate resolvers for the URI. The details of the
- conversation between the client and the resolver thus located are
- outside the bounds of this draft. Three brief examples of this
- procedure are given in the next section.
-
- The NAPTR RR provides the level of indirection needed to keep the
- naming system independent of the resolution system, its protocols,
- and services. Coupled with the new SRV resource record proposal[4]
- there is also the potential for replicating the resolver on multiple
- hosts, overcoming some of the most significant problems of URLs. This
- is an important and subtle point. Not only do the NAPTR and SRV
- records allow us to replicate the resource, we can replicate the
- resolvers that know about the replicated resource. Preventing a
- single point of failure at the resolver level is a significant
- benefit. Separating the resolution procedure from the way names are
- constructed has additional benefits. Different resolution procedures
- can be used over time, and resolution procedures that are determined
- to be useful can be extended to deal with additional namespaces.
-
-Caveats
-=======
-
- The NAPTR proposal is the first resolution procedure to be considered
- by the URN-WG. There are several concerns about the proposal which
- have motivated the group to recommend it for publication as an
- Experimental rather than a standards-track RFC.
-
- First, URN resolution is new to the IETF and we wish to gain
- operational experience before recommending any procedure for the
- standards track. Second, the NAPTR proposal is based on DNS and
- consequently inherits concerns about security and administration. The
- recent advancement of the DNSSEC and secure update drafts to Proposed
- Standard reduce these concerns, but we wish to experiment with those
- new capabilities in the context of URN administration. A third area
- of concern is the potential for a noticeable impact on the DNS. We
-
-
-
-Daniel & Mealling Experimental [Page 3]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- believe that the proposal makes appropriate use of caching and
- additional information, but it is best to go slow where the potential
- for impact on a core system like the DNS is concerned. Fourth, the
- rewrite rules in the NAPTR proposal are based on regular expressions.
- Since regular expressions are difficult for humans to construct
- correctly, concerns exist about the usability and maintainability of
- the rules. This is especially true where international character sets
- are concerned. Finally, the URN-WG is developing a requirements
- document for URN Resolution Services[15], but that document is not
- complete. That document needs to precede any resolution service
- proposals on the standards track.
-
-Terminology
-===========
-
- "Must" or "Shall" - Software that does not behave in the manner that
- this document says it must is not conformant to this
- document.
- "Should" - Software that does not follow the behavior that this
- document says it should may still be conformant, but is
- probably broken in some fundamental way.
- "May" - Implementations may or may not provide the described
- behavior, while still remaining conformant to this
- document.
-
-Brief overview and examples of the NAPTR RR:
-============================================
-
- A detailed description of the NAPTR RR will be given later, but to
- give a flavor for the proposal we first give a simple description of
- the record and three examples of its use.
-
- The key fields in the NAPTR RR are order, preference, service, flags,
- regexp, and replacement:
-
- * The order field specifies the order in which records MUST be
- processed when multiple NAPTR records are returned in response to a
- single query. A naming authority may have delegated a portion of
- its namespace to another agency. Evaluating the NAPTR records in
- the correct order is necessary for delegation to work properly.
-
- * The preference field specifies the order in which records SHOULD be
- processed when multiple NAPTR records have the same value of
- "order". This field lets a service provider specify the order in
- which resolvers are contacted, so that more capable machines are
- contacted in preference to less capable ones.
-
-
-
-
-
-Daniel & Mealling Experimental [Page 4]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- * The service field specifies the resolution protocol and resolution
- service(s) that will be available if the rewrite specified by the
- regexp or replacement fields is applied. Resolution protocols are
- the protocols used to talk with a resolver. They will be specified
- in other documents, such as [5]. Resolution services are operations
- such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
- etc. These will be discussed in the URN Resolution Services
- document[6], and their behavior in a particular resolution protocol
- will be given in the specification for that protocol (see [5] for a
- concrete example).
-
- * The flags field contains modifiers that affect what happens in the
- next DNS lookup, typically for optimizing the process. Flags may
- also affect the interpretation of the other fields in the record,
- therefore, clients MUST skip NAPTR records which contain an unknown
- flag value.
-
- * The regexp field is one of two fields used for the rewrite rules,
- and is the core concept of the NAPTR record. The regexp field is a
- String containing a sed-like substitution expression. (The actual
- grammar for the substitution expressions is given later in this
- draft). The substitution expression is applied to the original URN
- to determine the next domain name to be queried. The regexp field
- should be used when the domain name to be generated is conditional
- on information in the URI. If the next domain name is always known,
- which is anticipated to be a common occurrence, the replacement
- field should be used instead.
-
- * The replacement field is the other field that may be used for the
- rewrite rule. It is an optimization of the rewrite process for the
- case where the next domain name is fixed instead of being
- conditional on the content of the URI. The replacement field is a
- domain name (subject to compression if a DNS sender knows that a
- given recipient is able to decompress names in this RR type's RDATA
- field). If the rewrite is more complex than a simple substitution
- of a domain name, the replacement field should be set to . and the
- regexp field used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 5]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- Note that the client applies all the substitutions and performs all
- lookups, they are not performed in the DNS servers. Note also that it
- is the belief of the developers of this document that regexps should
- rarely be used. The replacement field seems adequate for the vast
- majority of situations. Regexps are only necessary when portions of a
- namespace are to be delegated to different resolvers. Finally, note
- that the regexp and replacement fields are, at present, mutually
- exclusive. However, developers of client software should be aware
- that a new flag might be defined which requires values in both
- fields.
-
-Example 1
----------
-
- Consider a URN that uses the hypothetical DUNS namespace. DUNS
- numbers are identifiers for approximately 30 million registered
- businesses around the world, assigned and maintained by Dunn and
- Bradstreet. The URN might look like:
-
- urn:duns:002372413:annual-report-1997
-
- The first step in the resolution process is to find out about the
- DUNS namespace. The namespace identifier, "duns", is extracted from
- the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked
- up. It might return records of the form:
-
-duns.urn.net
-;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" dunslink.udp.isi.dandb.com
- IN NAPTR 100 20 "s" "rcds+N2C" "" rcds.udp.isi.dandb.com
- IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" http.tcp.isi.dandb.com
-
- The order field contains equal values, indicating that no name
- delegation order has to be followed. The preference field indicates
- that the provider would like clients to use the special dunslink
- protocol, followed by the RCDS protocol, and that HTTP is offered as
- a last resort. All the records specify the "s" flag, which will be
- explained momentarily. The service fields say that if we speak
- dunslink, we will be able to issue either the N2L or N2C requests to
- obtain a URL or a URC (description) of the resource. The Resource
- Cataloging and Distribution Service (RCDS)[7] could be used to get a
- URC for the resource, while HTTP could be used to get a URL, URC, or
- the resource itself. All the records supply the next domain name to
- query, none of them need to be rewritten with the aid of regular
- expressions.
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 6]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- The general case might require multiple NAPTR rewrites to locate a
- resolver, but eventually we will come to the "terminal NAPTR". Once
- we have the terminal NAPTR, our next probe into the DNS will be for a
- SRV or A record instead of another NAPTR. Rather than probing for a
- non-existent NAPTR record to terminate the loop, the flags field is
- used to indicate a terminal lookup. If it has a value of "s", the
- next lookup should be for SRV RRs, "a" denotes that A records should
- sought. A "p" flag is also provided to indicate that the next action
- is Protocol-specific, but that looking up another NAPTR will not be
- part of it.
-
- Since our example RR specified the "s" flag, it was terminal.
- Assuming our client does not know the dunslink protocol, our next
- action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will
- tell us hosts that can provide the necessary resolution service. That
- lookup might return:
-
- ;; Pref Weight Port Target
- rcds.udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com
- IN SRV 0 0 1000 dbmirror.com.au
- IN SRV 0 0 1000 ukmirror.com.uk
-
- telling us three hosts that could actually do the resolution, and
- giving us the port we should use to talk to their RCDS server. (The
- reader is referred to the SRV proposal [4] for the interpretation of
- the fields above).
-
- There is opportunity for significant optimization here. We can return
- the SRV records as additional information for terminal NAPTRs (and
- the A records as additional information for those SRVs). While this
- recursive provision of additional information is not explicitly
- blessed in the DNS specifications, it is not forbidden, and BIND does
- take advantage of it [8]. This is a significant optimization. In
- conjunction with a long TTL for *.urn.net records, the average number
- of probes to DNS for resolving DUNS URNs would approach one.
- Therefore, DNS server implementors SHOULD provide additional
- information with NAPTR responses. The additional information will be
- either SRV or A records. If SRV records are available, their A
- records should be provided as recursive additional information.
-
- Note that the example NAPTR records above are intended to represent
- the reply the client will see. They are not quite identical to what
- the domain administrator would put into the zone files. For one
- thing, the administrator should supply the trailing '.' character on
- any FQDNs.
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 7]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
-Example 2
----------
-
- Consider a URN namespace based on MIME Content-Ids. The URN might
- look like this:
-
- urn:cid:199606121851.1@mordred.gatech.edu
-
- (Note that this example is chosen for pedagogical purposes, and does
- not conform to the recently-approved CID URL scheme.)
-
- The first step in the resolution process is to find out about the CID
- namespace. The namespace identifier, cid, is extracted from the URN,
- prepended to urn.net, and the NAPTR for cid.urn.net looked up. It
- might return records of the form:
-
- cid.urn.net
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" .
-
- We have only one NAPTR response, so ordering the responses is not a
- problem. The replacement field is empty, so we check the regexp
- field and use the pattern provided there. We apply that regexp to the
- entire URN to see if it matches, which it does. The \2 part of the
- substitution expression returns the string "gatech.edu". Since the
- flags field does not contain "s" or "a", the lookup is not terminal
- and our next probe to DNS is for more NAPTR records:
- lookup(query=NAPTR, "gatech.edu").
-
- Note that the rule does not extract the full domain name from the
- CID, instead it assumes the CID comes from a host and extracts its
- domain. While all hosts, such as mordred, could have their very own
- NAPTR, maintaining those records for all the machines at a site as
- large as Georgia Tech would be an intolerable burden. Wildcards are
- not appropriate here since they only return results when there is no
- exactly matching names already in the system.
-
- The record returned from the query on "gatech.edu" might look like:
-
-gatech.edu IN NAPTR
-;; order pref flags service regexp replacement
- IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" z3950.tcp.gatech.edu
- IN NAPTR 100 50 "s" "rcds+N2C" "" rcds.udp.gatech.edu
- IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" http.tcp.gatech.edu
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 8]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- Continuing with our example, we note that the values of the order and
- preference fields are equal in all records, so the client is free to
- pick any record. The flags field tells us that these are the last
- NAPTR patterns we should see, and after the rewrite (a simple
- replacement in this case) we should look up SRV records to get
- information on the hosts that can provide the necessary service.
-
- Assuming we prefer the Z39.50 protocol, our lookup might return:
-
- ;; Pref Weight Port Target
- z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu
- IN SRV 0 0 1000 z3950.cc.gatech.edu
- IN SRV 0 0 1000 z3950.uga.edu
-
- telling us three hosts that could actually do the resolution, and
- giving us the port we should use to talk to their Z39.50 server.
-
- Recall that the regular expression used \2 to extract a domain name
- from the CID, and \. for matching the literal '.' characters
- seperating the domain name components. Since '\' is the escape
- character, literal occurances of a backslash must be escaped by
- another backslash. For the case of the cid.urn.net record above, the
- regular expression entered into the zone file should be
- "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually
- receives the record, the pattern will have been converted to
- "/urn:cid:.+@([^.]+\.)(.*)$/\2/i".
-
-Example 3
----------
-
- Even if URN systems were in place now, there would still be a
- tremendous number of URLs. It should be possible to develop a URN
- resolution system that can also provide location independence for
- those URLs. This is related to the requirement in [1] to be able to
- grandfather in names from other naming systems, such as ISO Formal
- Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
- etc.
-
- The NAPTR RR could also be used for URLs that have already been
- assigned. Assume we have the URL for a very popular piece of
- software that the publisher wishes to mirror at multiple sites around
- the world:
-
- http://www.foo.com/software/latest-beta.exe
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 9]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- We extract the prefix, "http", and lookup NAPTR records for
- http.urn.net. This might return a record of the form
-
- http.urn.net IN NAPTR
- ;; order pref flags service regexp replacement
- 100 90 "" "" "!http://([^/:]+)!\1!i" .
-
- This expression returns everything after the first double slash and
- before the next slash or colon. (We use the '!' character to delimit
- the parts of the substitution expression. Otherwise we would have to
- use backslashes to escape the forward slashes, and would have a
- regexp in the zone file that looked like
- "/http:\\/\\/([^\\/:]+)/\\1/i".).
-
- Applying this pattern to the URL extracts "www.foo.com". Looking up
- NAPTR records for that might return:
-
- www.foo.com
- ;; order pref flags service regexp replacement
- IN NAPTR 100 100 "s" "http+L2R" "" http.tcp.foo.com
- IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.tcp.foo.com
-
- Looking up SRV records for http.tcp.foo.com would return information
- on the hosts that foo.com has designated to be its mirror sites. The
- client can then pick one for the user.
-
-NAPTR RR Format
-===============
-
- The format of the NAPTR RR is given below. The DNS type code for
- NAPTR is 35.
-
- Domain TTL Class Order Preference Flags Service Regexp
- Replacement
-
- where:
-
- Domain
- The domain name this resource record refers to.
- TTL
- Standard DNS Time To Live field
- Class
- Standard DNS meaning
-
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 10]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- Order
- A 16-bit integer specifying the order in which the NAPTR
- records MUST be processed to ensure correct delegation of
- portions of the namespace over time. Low numbers are processed
- before high numbers, and once a NAPTR is found that "matches"
- a URN, the client MUST NOT consider any NAPTRs with a higher
- value for order.
-
- Preference
- A 16-bit integer which specifies the order in which NAPTR
- records with equal "order" values SHOULD be processed, low
- numbers being processed before high numbers. This is similar
- to the preference field in an MX record, and is used so domain
- administrators can direct clients towards more capable hosts
- or lighter weight protocols.
-
- Flags
- A String giving flags to control aspects of the rewriting and
- interpretation of the fields in the record. Flags are single
- characters from the set [A-Z0-9]. The case of the alphabetic
- characters is not significant.
-
- At this time only three flags, "S", "A", and "P", are defined.
- "S" means that the next lookup should be for SRV records
- instead of NAPTR records. "A" means that the next lookup
- should be for A records. The "P" flag says that the remainder
- of the resolution shall be carried out in a Protocol-specific
- fashion, and we should not do any more DNS queries.
-
- The remaining alphabetic flags are reserved. The numeric flags
- may be used for local experimentation. The S, A, and P flags
- are all mutually exclusive, and resolution libraries MAY
- signal an error if more than one is given. (Experimental code
- and code for assisting in the creation of NAPTRs would be more
- likely to signal such an error than a client such as a
- browser). We anticipate that multiple flags will be allowed in
- the future, so implementers MUST NOT assume that the flags
- field can only contain 0 or 1 characters. Finally, if a client
- encounters a record with an unknown flag, it MUST ignore it
- and move to the next record. This test takes precedence even
- over the "order" field. Since flags can control the
- interpretation placed on fields, a novel flag might change the
- interpretation of the regexp and/or replacement fields such
- that it is impossible to determine if a record matched a URN.
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 11]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- Service
- Specifies the resolution service(s) available down this
- rewrite path. It may also specify the particular protocol that
- is used to talk with a resolver. A protocol MUST be specified
- if the flags field states that the NAPTR is terminal. If a
- protocol is specified, but the flags field does not state that
- the NAPTR is terminal, the next lookup MUST be for a NAPTR.
- The client MAY choose not to perform the next lookup if the
- protocol is unknown, but that behavior MUST NOT be relied
- upon.
-
- The service field may take any of the values below (using the
- Augmented BNF of RFC 822[9]):
-
- service_field = [ [protocol] *("+" rs)]
- protocol = ALPHA *31ALPHANUM
- rs = ALPHA *31ALPHANUM
- // The protocol and rs fields are limited to 32
- // characters and must start with an alphabetic.
- // The current set of "known" strings are:
- // protocol = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
- // rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
- // / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"
-
- i.e. an optional protocol specification followed by 0 or more
- resolution services. Each resolution service is indicated by
- an initial '+' character.
-
- Note that the empty string is also a valid service field. This
- will typically be seen at the top levels of a namespace, when
- it is impossible to know what services and protocols will be
- offered by a particular publisher within that name space.
-
- At this time the known protocols are rcds[7], hdl[10] (binary,
- UDP-based protocols), thttp[5] (a textual, TCP-based
- protocol), rwhois[11] (textual, UDP or TCP based), and
- Z39.50[12] (binary, TCP-based). More will be allowed later.
- The names of the protocols must be formed from the characters
- [a-Z0-9]. Case of the characters is not significant.
-
- The service requests currently allowed will be described in
- more detail in [6], but in brief they are:
- N2L - Given a URN, return a URL
- N2Ls - Given a URN, return a set of URLs
- N2R - Given a URN, return an instance of the resource.
- N2Rs - Given a URN, return multiple instances of the
- resource, typically encoded using
- multipart/alternative.
-
-
-
-Daniel & Mealling Experimental [Page 12]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- N2C - Given a URN, return a collection of meta-
- information on the named resource. The format of
- this response is the subject of another document.
- N2Ns - Given a URN, return all URNs that are also
- identifers for the resource.
- L2R - Given a URL, return the resource.
- L2Ns - Given a URL, return all the URNs that are
- identifiers for the resource.
- L2Ls - Given a URL, return all the URLs for instances of
- of the same resource.
- L2C - Given a URL, return a description of the
- resource.
-
- The actual format of the service request and response will be
- determined by the resolution protocol, and is the subject for
- other documents (e.g. [5]). Protocols need not offer all
- services. The labels for service requests shall be formed from
- the set of characters [A-Z0-9]. The case of the alphabetic
- characters is not significant.
-
- Regexp
- A STRING containing a substitution expression that is applied
- to the original URI in order to construct the next domain name
- to lookup. The grammar of the substitution expression is given
- in the next section.
-
- Replacement
- The next NAME to query for NAPTR, SRV, or A records depending
- on the value of the flags field. As mentioned above, this may
- be compressed.
-
-Substitution Expression Grammar:
-================================
-
- The content of the regexp field is a substitution expression. True
- sed(1) substitution expressions are not appropriate for use in this
- application for a variety of reasons, therefore the contents of the
- regexp field MUST follow the grammar below:
-
-subst_expr = delim-char ere delim-char repl delim-char *flags
-delim-char = "/" / "!" / ... (Any non-digit or non-flag character other
- than backslash '\'. All occurances of a delim_char in a
- subst_expr must be the same character.)
-ere = POSIX Extended Regular Expression (see [13], section
- 2.8.4)
-repl = dns_str / backref / repl dns_str / repl backref
-dns_str = 1*DNS_CHAR
-backref = "\" 1POS_DIGIT
-
-
-
-Daniel & Mealling Experimental [Page 13]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
-flags = "i"
-DNS_CHAR = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z"
-POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed backref
-value domain name (see RFC-1123 [14]).
-
- The result of applying the substitution expression to the original
- URI MUST result in a string that obeys the syntax for DNS host names
- [14]. Since it is possible for the regexp field to be improperly
- specified, such that a non-conforming host name can be constructed,
- client software SHOULD verify that the result is a legal host name
- before making queries on it.
-
- Backref expressions in the repl portion of the substitution
- expression are replaced by the (possibly empty) string of characters
- enclosed by '(' and ')' in the ERE portion of the substitution
- expression. N is a single digit from 1 through 9, inclusive. It
- specifies the N'th backref expression, the one that begins with the
- N'th '(' and continues to the matching ')'. For example, the ERE
- (A(B(C)DE)(F)G)
- has backref expressions:
- \1 = ABCDEFG
- \2 = BCDE
- \3 = C
- \4 = F
- \5..\9 = error - no matching subexpression
-
- The "i" flag indicates that the ERE matching SHALL be performed in a
- case-insensitive fashion. Furthermore, any backref replacements MAY
- be normalized to lower case when the "i" flag is given.
-
- The first character in the substitution expression shall be used as
- the character that delimits the components of the substitution
- expression. There must be exactly three non-escaped occurrences of
- the delimiter character in a substitution expression. Since escaped
- occurrences of the delimiter character will be interpreted as
- occurrences of that character, digits MUST NOT be used as delimiters.
- Backrefs would be confused with literal digits were this allowed.
- Similarly, if flags are specified in the substitution expression, the
- delimiter character must not also be a flag character.
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 14]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
-Advice to domain administrators:
-================================
-
- Beware of regular expressions. Not only are they a pain to get
- correct on their own, but there is the previously mentioned
- interaction with DNS. Any backslashes in a regexp must be entered
- twice in a zone file in order to appear once in a query response.
- More seriously, the need for double backslashes has probably not been
- tested by all implementors of DNS servers. We anticipate that urn.net
- will be the heaviest user of regexps. Only when delegating portions
- of namespaces should the typical domain administrator need to use
- regexps.
-
- On a related note, beware of interactions with the shell when
- manipulating regexps from the command line. Since '\' is a common
- escape character in shells, there is a good chance that when you
- think you are saying "\\" you are actually saying "\". Similar
- caveats apply to characters such as
-
- The "a" flag allows the next lookup to be for A records rather than
- SRV records. Since there is no place for a port specification in the
- NAPTR record, when the "A" flag is used the specified protocol must
- be running on its default port.
-
- The URN Sytnax draft defines a canonical form for each URN, which
- requires %encoding characters outside a limited repertoire. The
- regular expressions MUST be written to operate on that canonical
- form. Since international character sets will end up with extensive
- use of %encoded characters, regular expressions operating on them
- will be essentially impossible to read or write by hand.
-
-Usage
-=====
-
- For the edification of implementers, pseudocode for a client routine
- using NAPTRs is given below. This code is provided merely as a
- convience, it does not have any weight as a standard way to process
- NAPTR records. Also, as is the case with pseudocode, it has never
- been executed and may contain logical errors. You have been warned.
-
- //
- // findResolver(URN)
- // Given a URN, find a host that can resolve it.
- //
- findResolver(string URN) {
- // prepend prefix to urn.net
- sprintf(key, "%s.urn.net", extractNS(URN));
- do {
-
-
-
-Daniel & Mealling Experimental [Page 15]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- rewrite_flag = false;
- terminal = false;
- if (key has been seen) {
- quit with a loop detected error
- }
- add key to list of "seens"
- records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'
-
- discard any records with an unknown value in the "flags" field.
- sort NAPTR records by "order" field and "preference" field
- (with "order" being more significant than "preference").
- n_naptrs = number of NAPTR records in response.
- curr_order = records[0].order;
- max_order = records[n_naptrs-1].order;
-
- // Process current batch of NAPTRs according to "order" field.
- for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
- if (unknown_flag) // skip this record and go to next one
- continue;
- newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
- if (!newkey) // Skip to next record if the rewrite didn't
- match continue;
- // We did do a rewrite, shrink max_order to current value
- // so that delegation works properly
- max_order = naptr[j].order;
- // Will we know what to do with the protocol and services
- // specified in the NAPTR? If not, try next record.
- if(!isKnownProto(naptr[j].services)) {
- continue;
- }
- if(!isKnownService(naptr[j].services)) {
- continue;
- }
-
- // At this point we have a successful rewrite and we will
- // know how to speak the protocol and request a known
- // resolution service. Before we do the next lookup, check
- // some optimization possibilities.
-
- if (strcasecmp(flags, "S")
- || strcasecmp(flags, "P"))
- || strcasecmp(flags, "A")) {
- terminal = true;
- services = naptr[j].services;
- addnl = any SRV and/or A records returned as additional
- info for naptr[j].
- }
- key = newkey;
-
-
-
-Daniel & Mealling Experimental [Page 16]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- rewriteflag = true;
- break;
- }
- } while (rewriteflag && !terminal);
-
- // Did we not find our way to a resolver?
- if (!rewrite_flag) {
- report an error
- return NULL;
- }
-
-
- // Leave rest to another protocol?
- if (strcasecmp(flags, "P")) {
- return key as host to talk to;
- }
-
- // If not, keep plugging
- if (!addnl) { // No SRVs came in as additional info, look them up
- srvs = lookup(type=SRV, key);
- }
-
- sort SRV records by preference, weight, ...
- foreach (SRV record) { // in order of preference
- try contacting srv[j].target using the protocol and one of the
- resolution service requests from the "services" field of the
- last NAPTR record.
- if (successful)
- return (target, protocol, service);
- // Actually we would probably return a result, but this
- // code was supposed to just tell us a good host to talk to.
- }
- die with an "unable to find a host" error;
- }
-
-Notes:
-======
-
- - A client MUST process multiple NAPTR records in the order
- specified by the "order" field, it MUST NOT simply use the first
- record that provides a known protocol and service combination.
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 17]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- - If a record at a particular order matches the URI, but the
- client doesn't know the specified protocol and service, the
- client SHOULD continue to examine records that have the same
- order. The client MUST NOT consider records with a higher value
- of order. This is necessary to make delegation of portions of
- the namespace work. The order field is what lets site
- administrators say "all requests for URIs matching pattern x go
- to server 1, all others go to server 2".
- (A match is defined as:
- 1) The NAPTR provides a replacement domain name
- or
- 2) The regular expression matches the URN
- )
-
- - When multiple RRs have the same "order", the client should use
- the value of the preference field to select the next NAPTR to
- consider. However, because of preferred protocols or services,
- estimates of network distance and bandwidth, etc. clients may
- use different criteria to sort the records.
- - If the lookup after a rewrite fails, clients are strongly
- encouraged to report a failure, rather than backing up to pursue
- other rewrite paths.
- - When a namespace is to be delegated among a set of resolvers,
- regexps must be used. Each regexp appears in a separate NAPTR
- RR. Administrators should do as little delegation as possible,
- because of limitations on the size of DNS responses.
- - Note that SRV RRs impose additional requirements on clients.
-
-Acknowledgments:
-=================
-
- The editors would like to thank Keith Moore for all his consultations
- during the development of this draft. We would also like to thank
- Paul Vixie for his assistance in debugging our implementation, and
- his answers on our questions. Finally, we would like to acknowledge
- our enormous intellectual debt to the participants in the Knoxville
- series of meetings, as well as to the participants in the URI and URN
- working groups.
-
-References:
-===========
-
- [1] Sollins, Karen and Larry Masinter, "Functional Requirements
- for Uniform Resource Names", RFC-1737, Dec. 1994.
-
- [2] The URN Implementors, Uniform Resource Names: A Progress Report,
- http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
- February 1996.
-
-
-
-Daniel & Mealling Experimental [Page 18]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
- [3] Moats, Ryan, "URN Syntax", RFC-2141, May 1997.
-
- [4] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
- the location of services (DNS SRV)", RFC-2052, October 1996.
-
- [5] Daniel, Jr., Ron, "A Trivial Convention for using HTTP in URN
- Resolution", RFC-2169, June 1997.
-
- [6] URN-WG, "URN Resolution Services", Work in Progress.
-
- [7] Moore, Keith, Shirley Browne, Jason Cox, and Jonathan Gettler,
- Resource Cataloging and Distribution System, Technical Report
- CS-97-346, University of Tennessee, Knoxville, December 1996
-
- [8] Paul Vixie, personal communication.
-
- [9] Crocker, Dave H. "Standard for the Format of ARPA Internet Text
- Messages", RFC-822, August 1982.
-
- [10] Orth, Charles and Bill Arms; Handle Resolution Protocol
- Specification, http://www.handle.net/docs/client_spec.html
-
- [11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra,
- "Referral Whois Protocol (RWhois)", RFC-2167, June 1997.
-
- [12] Information Retrieval (Z39.50): Application Service Definition
- and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.
-
- [13] IEEE Standard for Information Technology - Portable Operating
- System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
- IEEE Std 1003.2-1992; The Institute of Electrical and
- Electronics Engineers; New York; 1993. ISBN:1-55937-255-9
-
- [14] Braden, R., "Requirements for Internet Hosts - Application and
- and Support", RFC-1123, Oct. 1989.
-
- [15] Sollins, Karen, "Requirements and a Framework for URN Resolution
- Systems", November 1996, Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 19]
-
-RFC 2168 Resolution of URIs Using the DNS June 1997
-
-
-Security Considerations
-=======================
-
- The use of "urn.net" as the registry for URN namespaces is subject to
- denial of service attacks, as well as other DNS spoofing attacks. The
- interactions with DNSSEC are currently being studied. It is expected
- that NAPTR records will be signed with SIG records once the DNSSEC
- work is deployed.
-
- The rewrite rules make identifiers from other namespaces subject to
- the same attacks as normal domain names. Since they have not been
- easily resolvable before, this may or may not be considered a
- problem.
-
- Regular expressions should be checked for sanity, not blindly passed
- to something like PERL.
-
- This document has discussed a way of locating a resolver, but has not
- discussed any detail of how the communication with the resolver takes
- place. There are significant security considerations attached to the
- communication with a resolver. Those considerations are outside the
- scope of this document, and must be addressed by the specifications
- for particular resolver communication protocols.
-
-Author Contact Information:
-===========================
-
- Ron Daniel
- Los Alamos National Laboratory
- MS B287
- Los Alamos, NM, USA, 87545
- voice: +1 505 665 0597
- fax: +1 505 665 4939
- email: rdaniel@lanl.gov
-
-
- Michael Mealling
- Network Solutions
- 505 Huntmar Park Drive
- Herndon, VA 22070
- voice: (703) 742-0400
- fax: (703) 742-9552
- email: michaelm@internic.net
- URL: http://www.netsol.com/
-
-
-
-
-
-
-
-Daniel & Mealling Experimental [Page 20]
-
diff --git a/contrib/bind9/doc/rfc/rfc2181.txt b/contrib/bind9/doc/rfc/rfc2181.txt
deleted file mode 100644
index 7899e1cbf412b..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2181.txt
+++ /dev/null
@@ -1,842 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Elz
-Request for Comments: 2181 University of Melbourne
-Updates: 1034, 1035, 1123 R. Bush
-Category: Standards Track RGnet, Inc.
- July 1997
-
-
- Clarifications to the DNS Specification
-
-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.
-
-1. Abstract
-
- This document considers some areas that have been identified as
- problems with the specification of the Domain Name System, and
- proposes remedies for the defects identified. Eight separate issues
- are considered:
-
- + IP packet header address usage from multi-homed servers,
- + TTLs in sets of records with the same name, class, and type,
- + correct handling of zone cuts,
- + three minor issues concerning SOA records and their use,
- + the precise definition of the Time to Live (TTL)
- + Use of the TC (truncated) header bit
- + the issue of what is an authoritative, or canonical, name,
- + and the issue of what makes a valid DNS label.
-
- The first six of these are areas where the correct behaviour has been
- somewhat unclear, we seek to rectify that. The other two are already
- adequately specified, however the specifications seem to be sometimes
- ignored. We seek to reinforce the existing specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 1]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
-
-
-Contents
-
- 1 Abstract ................................................... 1
- 2 Introduction ............................................... 2
- 3 Terminology ................................................ 3
- 4 Server Reply Source Address Selection ...................... 3
- 5 Resource Record Sets ....................................... 4
- 6 Zone Cuts .................................................. 8
- 7 SOA RRs .................................................... 10
- 8 Time to Live (TTL) ......................................... 10
- 9 The TC (truncated) header bit .............................. 11
- 10 Naming issues .............................................. 11
- 11 Name syntax ................................................ 13
- 12 Security Considerations .................................... 14
- 13 References ................................................. 14
- 14 Acknowledgements ........................................... 15
- 15 Authors' Addresses ......................................... 15
-
-
-
-
-2. Introduction
-
- Several problem areas in the Domain Name System specification
- [RFC1034, RFC1035] have been noted through the years [RFC1123]. This
- document addresses several additional problem areas. The issues here
- are independent. Those issues are the question of which source
- address a multi-homed DNS server should use when replying to a query,
- the issue of differing TTLs for DNS records with the same label,
- class and type, and the issue of canonical names, what they are, how
- CNAME records relate, what names are legal in what parts of the DNS,
- and what is the valid syntax of a DNS name.
-
- Clarifications to the DNS specification to avoid these problems are
- made in this memo. A minor ambiguity in RFC1034 concerned with SOA
- records is also corrected, as is one in the definition of the TTL
- (Time To Live) and some possible confusion in use of the TC bit.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 2]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
-3. Terminology
-
- This memo does not use the oft used expressions MUST, SHOULD, MAY, or
- their negative forms. In some sections it may seem that a
- specification is worded mildly, and hence some may infer that the
- specification is optional. That is not correct. Anywhere that this
- memo suggests that some action should be carried out, or must be
- carried out, or that some behaviour is acceptable, or not, that is to
- be considered as a fundamental aspect of this specification,
- regardless of the specific words used. If some behaviour or action
- is truly optional, that will be clearly specified by the text.
-
-4. Server Reply Source Address Selection
-
- Most, if not all, DNS clients, expect the address from which a reply
- is received to be the same address as that to which the query
- eliciting the reply was sent. This is true for servers acting as
- clients for the purposes of recursive query resolution, as well as
- simple resolver clients. The address, along with the identifier (ID)
- in the reply is used for disambiguating replies, and filtering
- spurious responses. This may, or may not, have been intended when
- the DNS was designed, but is now a fact of life.
-
- Some multi-homed hosts running DNS servers generate a reply using a
- source address that is not the same as the destination address from
- the client's request packet. Such replies will be discarded by the
- client because the source address of the reply does not match that of
- a host to which the client sent the original request. That is, it
- appears to be an unsolicited response.
-
-4.1. UDP Source Address Selection
-
- To avoid these problems, servers when responding to queries using UDP
- must cause the reply to be sent with the source address field in the
- IP header set to the address that was in the destination address
- field of the IP header of the packet containing the query causing the
- response. If this would cause the response to be sent from an IP
- address that is not permitted for this purpose, then the response may
- be sent from any legal IP address allocated to the server. That
- address should be chosen to maximise the possibility that the client
- will be able to use it for further queries. Servers configured in
- such a way that not all their addresses are equally reachable from
- all potential clients need take particular care when responding to
- queries sent to anycast, multicast, or similar, addresses.
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 3]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
-4.2. Port Number Selection
-
- Replies to all queries must be directed to the port from which they
- were sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- server must take note of the source port and use that as the
- destination port in the response. Replies should always be sent from
- the port to which they were directed. Except in extraordinary
- circumstances, this will be the well known port assigned for DNS
- queries [RFC1700].
-
-5. Resource Record Sets
-
- Each DNS Resource Record (RR) has a label, class, type, and data. It
- is meaningless for two records to ever have label, class, type and
- data all equal - servers should suppress such duplicates if
- encountered. It is however possible for most record types to exist
- with the same label, class and type, but with different data. Such a
- group of records is hereby defined to be a Resource Record Set
- (RRSet).
-
-5.1. Sending RRs from an RRSet
-
- A query for a specific (or non-specific) label, class, and type, will
- always return all records in the associated RRSet - whether that be
- one or more RRs. The response must be marked as "truncated" if the
- entire RRSet will not fit in the response.
-
-5.2. TTLs of RRs in an RRSet
-
- Resource Records also have a time to live (TTL). It is possible for
- the RRs in an RRSet to have different TTLs. No uses for this have
- been found that cannot be better accomplished in other ways. This
- can, however, cause partial replies (not marked "truncated") from a
- caching server, where the TTLs for some but not all the RRs in the
- RRSet have expired.
-
- Consequently the use of differing TTLs in an RRSet is hereby
- deprecated, the TTLs of all RRs in an RRSet must be the same.
-
- Should a client receive a response containing RRs from an RRSet with
- differing TTLs, it should treat this as an error. If the RRSet
- concerned is from a non-authoritative source for this data, the
- client should simply ignore the RRSet, and if the values were
- required, seek to acquire them from an authoritative source. Clients
- that are configured to send all queries to one, or more, particular
- servers should treat those servers as authoritative for this purpose.
- Should an authoritative source send such a malformed RRSet, the
-
-
-
-Elz & Bush Standards Track [Page 4]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- client should treat the RRs for all purposes as if all TTLs in the
- RRSet had been set to the value of the lowest TTL in the RRSet. In
- no case may a server send an RRSet with TTLs not all equal.
-
-5.3. DNSSEC Special Cases
-
- Two of the record types added by DNS Security (DNSSEC) [RFC2065]
- require special attention when considering the formation of Resource
- Record Sets. Those are the SIG and NXT records. It should be noted
- that DNS Security is still very new, and there is, as yet, little
- experience with it. Readers should be prepared for the information
- related to DNSSEC contained in this document to become outdated as
- the DNS Security specification matures.
-
-5.3.1. SIG records and RRSets
-
- A SIG record provides signature (validation) data for another RRSet
- in the DNS. Where a zone has been signed, every RRSet in the zone
- will have had a SIG record associated with it. The data type of the
- RRSet is included in the data of the SIG RR, to indicate with which
- particular RRSet this SIG record is associated. Were the rules above
- applied, whenever a SIG record was included with a response to
- validate that response, the SIG records for all other RRSets
- associated with the appropriate node would also need to be included.
- In some cases, this could be a very large number of records, not
- helped by their being rather large RRs.
-
- Thus, it is specifically permitted for the authority section to
- contain only those SIG RRs with the "type covered" field equal to the
- type field of an answer being returned. However, where SIG records
- are being returned in the answer section, in response to a query for
- SIG records, or a query for all records associated with a name
- (type=ANY) the entire SIG RRSet must be included, as for any other RR
- type.
-
- Servers that receive responses containing SIG records in the
- authority section, or (probably incorrectly) as additional data, must
- understand that the entire RRSet has almost certainly not been
- included. Thus, they must not cache that SIG record in a way that
- would permit it to be returned should a query for SIG records be
- received at that server. RFC2065 actually requires that SIG queries
- be directed only to authoritative servers to avoid the problems that
- could be caused here, and while servers exist that do not understand
- the special properties of SIG records, this will remain necessary.
- However, careful design of SIG record processing in new
- implementations should permit this restriction to be relaxed in the
- future, so resolvers do not need to treat SIG record queries
- specially.
-
-
-
-Elz & Bush Standards Track [Page 5]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- It has been occasionally stated that a received request for a SIG
- record should be forwarded to an authoritative server, rather than
- being answered from data in the cache. This is not necessary - a
- server that has the knowledge of SIG as a special case for processing
- this way would be better to correctly cache SIG records, taking into
- account their characteristics. Then the server can determine when it
- is safe to reply from the cache, and when the answer is not available
- and the query must be forwarded.
-
-5.3.2. NXT RRs
-
- Next Resource Records (NXT) are even more peculiar. There will only
- ever be one NXT record in a zone for a particular label, so
- superficially, the RRSet problem is trivial. However, at a zone cut,
- both the parent zone, and the child zone (superzone and subzone in
- RFC2065 terminology) will have NXT records for the same name. Those
- two NXT records do not form an RRSet, even where both zones are
- housed at the same server. NXT RRSets always contain just a single
- RR. Where both NXT records are visible, two RRSets exist. However,
- servers are not required to treat this as a special case when
- receiving NXT records in a response. They may elect to notice the
- existence of two different NXT RRSets, and treat that as they would
- two different RRSets of any other type. That is, cache one, and
- ignore the other. Security aware servers will need to correctly
- process the NXT record in the received response though.
-
-5.4. Receiving RRSets
-
- Servers must never merge RRs from a response with RRs in their cache
- to form an RRSet. If a response contains data that would form an
- RRSet with data in a server's cache the server must either ignore the
- RRs in the response, or discard the entire RRSet currently in the
- cache, as appropriate. Consequently the issue of TTLs varying
- between the cache and a response does not cause concern, one will be
- ignored. That is, one of the data sets is always incorrect if the
- data from an answer differs from the data in the cache. The
- challenge for the server is to determine which of the data sets is
- correct, if one is, and retain that, while ignoring the other. Note
- that if a server receives an answer containing an RRSet that is
- identical to that in its cache, with the possible exception of the
- TTL value, it may, optionally, update the TTL in its cache with the
- TTL of the received answer. It should do this if the received answer
- would be considered more authoritative (as discussed in the next
- section) than the previously cached answer.
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 6]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
-5.4.1. Ranking data
-
- When considering whether to accept an RRSet in a reply, or retain an
- RRSet already in its cache instead, a server should consider the
- relative likely trustworthiness of the various data. An
- authoritative answer from a reply should replace cached data that had
- been obtained from additional information in an earlier reply.
- However additional information from a reply will be ignored if the
- cache contains data from an authoritative answer or a zone file.
-
- The accuracy of data available is assumed from its source.
- Trustworthiness shall be, in order from most to least:
-
- + Data from a primary zone file, other than glue data,
- + Data from a zone transfer, other than glue,
- + The authoritative data included in the answer section of an
- authoritative reply.
- + Data from the authority section of an authoritative answer,
- + Glue from a primary zone, or glue from a zone transfer,
- + Data from the answer section of a non-authoritative answer, and
- non-authoritative data from the answer section of authoritative
- answers,
- + Additional information from an authoritative answer,
- Data from the authority section of a non-authoritative answer,
- Additional information from non-authoritative answers.
-
- Note that the answer section of an authoritative answer normally
- contains only authoritative data. However when the name sought is an
- alias (see section 10.1.1) only the record describing that alias is
- necessarily authoritative. Clients should assume that other records
- may have come from the server's cache. Where authoritative answers
- are required, the client should query again, using the canonical name
- associated with the alias.
-
- Unauthenticated RRs received and cached from the least trustworthy of
- those groupings, that is data from the additional data section, and
- data from the authority section of a non-authoritative answer, should
- not be cached in such a way that they would ever be returned as
- answers to a received query. They may be returned as additional
- information where appropriate. Ignoring this would allow the
- trustworthiness of relatively untrustworthy data to be increased
- without cause or excuse.
-
- When DNS security [RFC2065] is in use, and an authenticated reply has
- been received and verified, the data thus authenticated shall be
- considered more trustworthy than unauthenticated data of the same
- type. Note that throughout this document, "authoritative" means a
- reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY
-
-
-
-Elz & Bush Standards Track [Page 7]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- records to determine the authenticity of data, the AA bit is almost
- irrelevant. However DNSSEC aware servers must still correctly set
- the AA bit in responses to enable correct operation with servers that
- are not security aware (almost all currently).
-
- Note that, glue excluded, it is impossible for data from two
- correctly configured primary zone files, two correctly configured
- secondary zones (data from zone transfers) or data from correctly
- configured primary and secondary zones to ever conflict. Where glue
- for the same name exists in multiple zones, and differs in value, the
- nameserver should select data from a primary zone file in preference
- to secondary, but otherwise may choose any single set of such data.
- Choosing that which appears to come from a source nearer the
- authoritative data source may make sense where that can be
- determined. Choosing primary data over secondary allows the source
- of incorrect glue data to be discovered more readily, when a problem
- with such data exists. Where a server can detect from two zone files
- that one or more are incorrectly configured, so as to create
- conflicts, it should refuse to load the zones determined to be
- erroneous, and issue suitable diagnostics.
-
- "Glue" above includes any record in a zone file that is not properly
- part of that zone, including nameserver records of delegated sub-
- zones (NS records), address records that accompany those NS records
- (A, AAAA, etc), and any other stray data that might appear.
-
-5.5. Sending RRSets (reprise)
-
- A Resource Record Set should only be included once in any DNS reply.
- It may occur in any of the Answer, Authority, or Additional
- Information sections, as required. However it should not be repeated
- in the same, or any other, section, except where explicitly required
- by a specification. For example, an AXFR response requires the SOA
- record (always an RRSet containing a single RR) be both the first and
- last record of the reply. Where duplicates are required this way,
- the TTL transmitted in each case must be the same.
-
-6. Zone Cuts
-
- The DNS tree is divided into "zones", which are collections of
- domains that are treated as a unit for certain management purposes.
- Zones are delimited by "zone cuts". Each zone cut separates a
- "child" zone (below the cut) from a "parent" zone (above the cut).
- The domain name that appears at the top of a zone (just below the cut
- that separates the zone from its parent) is called the zone's
- "origin". The name of the zone is the same as the name of the domain
- at the zone's origin. Each zone comprises that subset of the DNS
- tree that is at or below the zone's origin, and that is above the
-
-
-
-Elz & Bush Standards Track [Page 8]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- cuts that separate the zone from its children (if any). The
- existence of a zone cut is indicated in the parent zone by the
- existence of NS records specifying the origin of the child zone. A
- child zone does not contain any explicit reference to its parent.
-
-6.1. Zone authority
-
- The authoritative servers for a zone are enumerated in the NS records
- for the origin of the zone, which, along with a Start of Authority
- (SOA) record are the mandatory records in every zone. Such a server
- is authoritative for all resource records in a zone that are not in
- another zone. The NS records that indicate a zone cut are the
- property of the child zone created, as are any other records for the
- origin of that child zone, or any sub-domains of it. A server for a
- zone should not return authoritative answers for queries related to
- names in another zone, which includes the NS, and perhaps A, records
- at a zone cut, unless it also happens to be a server for the other
- zone.
-
- Other than the DNSSEC cases mentioned immediately below, servers
- should ignore data other than NS records, and necessary A records to
- locate the servers listed in the NS records, that may happen to be
- configured in a zone at a zone cut.
-
-6.2. DNSSEC issues
-
- The DNS security mechanisms [RFC2065] complicate this somewhat, as
- some of the new resource record types added are very unusual when
- compared with other DNS RRs. In particular the NXT ("next") RR type
- contains information about which names exist in a zone, and hence
- which do not, and thus must necessarily relate to the zone in which
- it exists. The same domain name may have different NXT records in
- the parent zone and the child zone, and both are valid, and are not
- an RRSet. See also section 5.3.2.
-
- Since NXT records are intended to be automatically generated, rather
- than configured by DNS operators, servers may, but are not required
- to, retain all differing NXT records they receive regardless of the
- rules in section 5.4.
-
- For a secure parent zone to securely indicate that a subzone is
- insecure, DNSSEC requires that a KEY RR indicating that the subzone
- is insecure, and the parent zone's authenticating SIG RR(s) be
- present in the parent zone, as they by definition cannot be in the
- subzone. Where a subzone is secure, the KEY and SIG records will be
- present, and authoritative, in that zone, but should also always be
- present in the parent zone (if secure).
-
-
-
-
-Elz & Bush Standards Track [Page 9]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- Note that in none of these cases should a server for the parent zone,
- not also being a server for the subzone, set the AA bit in any
- response for a label at a zone cut.
-
-7. SOA RRs
-
- Three minor issues concerning the Start of Zone of Authority (SOA)
- Resource Record need some clarification.
-
-7.1. Placement of SOA RRs in authoritative answers
-
- RFC1034, in section 3.7, indicates that the authority section of an
- authoritative answer may contain the SOA record for the zone from
- which the answer was obtained. When discussing negative caching,
- RFC1034 section 4.3.4 refers to this technique but mentions the
- additional section of the response. The former is correct, as is
- implied by the example shown in section 6.2.5 of RFC1034. SOA
- records, if added, are to be placed in the authority section.
-
-7.2. TTLs on SOA RRs
-
- It may be observed that in section 3.2.1 of RFC1035, which defines
- the format of a Resource Record, that the definition of the TTL field
- contains a throw away line which states that the TTL of an SOA record
- should always be sent as zero to prevent caching. This is mentioned
- nowhere else, and has not generally been implemented.
- Implementations should not assume that SOA records will have a TTL of
- zero, nor are they required to send SOA records with a TTL of zero.
-
-7.3. The SOA.MNAME field
-
- It is quite clear in the specifications, yet seems to have been
- widely ignored, that the MNAME field of the SOA record should contain
- the name of the primary (master) server for the zone identified by
- the SOA. It should not contain the name of the zone itself. That
- information would be useless, as to discover it, one needs to start
- with the domain name of the SOA record - that is the name of the
- zone.
-
-8. Time to Live (TTL)
-
- The definition of values appropriate to the TTL field in STD 13 is
- not as clear as it could be, with respect to how many significant
- bits exist, and whether the value is signed or unsigned. It is
- hereby specified that a TTL value is an unsigned number, with a
- minimum value of 0, and a maximum value of 2147483647. That is, a
- maximum of 2^31 - 1. When transmitted, this value shall be encoded
- in the less significant 31 bits of the 32 bit TTL field, with the
-
-
-
-Elz & Bush Standards Track [Page 10]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- most significant, or sign, bit set to zero.
-
- Implementations should treat TTL values received with the most
- significant bit set as if the entire value received was zero.
-
- Implementations are always free to place an upper bound on any TTL
- received, and treat any larger values as if they were that upper
- bound. The TTL specifies a maximum time to live, not a mandatory
- time to live.
-
-9. The TC (truncated) header bit
-
- The TC bit should be set in responses only when an RRSet is required
- as a part of the response, but could not be included in its entirety.
- The TC bit should not be set merely because some extra information
- could have been included, but there was insufficient room. This
- includes the results of additional section processing. In such cases
- the entire RRSet that will not fit in the response should be omitted,
- and the reply sent as is, with the TC bit clear. If the recipient of
- the reply needs the omitted data, it can construct a query for that
- data and send that separately.
-
- Where TC is set, the partial RRSet that would not completely fit may
- be left in the response. When a DNS client receives a reply with TC
- set, it should ignore that response, and query again, using a
- mechanism, such as a TCP connection, that will permit larger replies.
-
-10. Naming issues
-
- It has sometimes been inferred from some sections of the DNS
- specification [RFC1034, RFC1035] that a host, or perhaps an interface
- of a host, is permitted exactly one authoritative, or official, name,
- called the canonical name. There is no such requirement in the DNS.
-
-10.1. CNAME resource records
-
- The DNS CNAME ("canonical name") record exists to provide the
- canonical name associated with an alias name. There may be only one
- such canonical name for any one alias. That name should generally be
- a name that exists elsewhere in the DNS, though there are some rare
- applications for aliases with the accompanying canonical name
- undefined in the DNS. An alias name (label of a CNAME record) may,
- if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
- other data. That is, for any label in the DNS (any domain name)
- exactly one of the following is true:
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 11]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- + one CNAME record exists, optionally accompanied by SIG, NXT, and
- KEY RRs,
- + one or more records exist, none being CNAME records,
- + the name exists, but has no associated RRs of any type,
- + the name does not exist at all.
-
-10.1.1. CNAME terminology
-
- It has been traditional to refer to the label of a CNAME record as "a
- CNAME". This is unfortunate, as "CNAME" is an abbreviation of
- "canonical name", and the label of a CNAME record is most certainly
- not a canonical name. It is, however, an entrenched usage. Care
- must therefore be taken to be very clear whether the label, or the
- value (the canonical name) of a CNAME resource record is intended.
- In this document, the label of a CNAME resource record will always be
- referred to as an alias.
-
-10.2. PTR records
-
- Confusion about canonical names has lead to a belief that a PTR
- record should have exactly one RR in its RRSet. This is incorrect,
- the relevant section of RFC1034 (section 3.6.2) indicates that the
- value of a PTR record should be a canonical name. That is, it should
- not be an alias. There is no implication in that section that only
- one PTR record is permitted for a name. No such restriction should
- be inferred.
-
- Note that while the value of a PTR record must not be an alias, there
- is no requirement that the process of resolving a PTR record not
- encounter any aliases. The label that is being looked up for a PTR
- value might have a CNAME record. That is, it might be an alias. The
- value of that CNAME RR, if not another alias, which it should not be,
- will give the location where the PTR record is found. That record
- gives the result of the PTR type lookup. This final result, the
- value of the PTR RR, is the label which must not be an alias.
-
-10.3. MX and NS records
-
- The domain name used as the value of a NS resource record, or part of
- the value of a MX resource record must not be an alias. Not only is
- the specification clear on this point, but using an alias in either
- of these positions neither works as well as might be hoped, nor well
- fulfills the ambition that may have led to this approach. This
- domain name must have as its value one or more address records.
- Currently those will be A records, however in the future other record
- types giving addressing information may be acceptable. It can also
- have other RRs, but never a CNAME RR.
-
-
-
-
-Elz & Bush Standards Track [Page 12]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- Searching for either NS or MX records causes "additional section
- processing" in which address records associated with the value of the
- record sought are appended to the answer. This helps avoid needless
- extra queries that are easily anticipated when the first was made.
-
- Additional section processing does not include CNAME records, let
- alone the address records that may be associated with the canonical
- name derived from the alias. Thus, if an alias is used as the value
- of an NS or MX record, no address will be returned with the NS or MX
- value. This can cause extra queries, and extra network burden, on
- every query. It is trivial for the DNS administrator to avoid this
- by resolving the alias and placing the canonical name directly in the
- affected record just once when it is updated or installed. In some
- particular hard cases the lack of the additional section address
- records in the results of a NS lookup can cause the request to fail.
-
-11. Name syntax
-
- Occasionally it is assumed that the Domain Name System serves only
- the purpose of mapping Internet host names to data, and mapping
- Internet addresses to host names. This is not correct, the DNS is a
- general (if somewhat limited) hierarchical database, and can store
- almost any kind of data, for almost any purpose.
-
- The DNS itself places only one restriction on the particular labels
- that can be used to identify resource records. That one restriction
- relates to the length of the label and the full name. The length of
- any one label is limited to between 1 and 63 octets. A full domain
- name is limited to 255 octets (including the separators). The zero
- length full name is defined as representing the root of the DNS tree,
- and is typically written and displayed as ".". Those restrictions
- aside, any binary string whatever can be used as the label of any
- resource record. Similarly, any binary string can serve as the value
- of any record that includes a domain name as some or all of its value
- (SOA, NS, MX, PTR, CNAME, and any others that may be added).
- Implementations of the DNS protocols must not place any restrictions
- on the labels that can be used. In particular, DNS servers must not
- refuse to serve a zone because it contains labels that might not be
- acceptable to some DNS client programs. A DNS server may be
- configurable to issue warnings when loading, or even to refuse to
- load, a primary zone containing labels that might be considered
- questionable, however this should not happen by default.
-
- Note however, that the various applications that make use of DNS data
- can have restrictions imposed on what particular values are
- acceptable in their environment. For example, that any binary label
- can have an MX record does not imply that any binary name can be used
- as the host part of an e-mail address. Clients of the DNS can impose
-
-
-
-Elz & Bush Standards Track [Page 13]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
- whatever restrictions are appropriate to their circumstances on the
- values they use as keys for DNS lookup requests, and on the values
- returned by the DNS. If the client has such restrictions, it is
- solely responsible for validating the data from the DNS to ensure
- that it conforms before it makes any use of that data.
-
- See also [RFC1123] section 6.1.3.5.
-
-12. Security Considerations
-
- This document does not consider security.
-
- In particular, nothing in section 4 is any way related to, or useful
- for, any security related purposes.
-
- Section 5.4.1 is also not related to security. Security of DNS data
- will be obtained by the Secure DNS [RFC2065], which is mostly
- orthogonal to this memo.
-
- It is not believed that anything in this document adds to any
- security issues that may exist with the DNS, nor does it do anything
- to that will necessarily lessen them. Correct implementation of the
- clarifications in this document might play some small part in
- limiting the spread of non-malicious bad data in the DNS, but only
- DNSSEC can help with deliberate attempts to subvert DNS data.
-
-13. 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.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts - application
- and support", STD 3, RFC 1123, January 1989.
-
- [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers",
- STD 2, RFC 1700, October 1994.
-
- [RFC2065] Eastlake, D., Kaufman, C., "Domain Name System Security
- Extensions", RFC 2065, January 1997.
-
-
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 14]
-
-RFC 2181 Clarifications to the DNS Specification July 1997
-
-
-14. Acknowledgements
-
- This memo arose from discussions in the DNSIND working group of the
- IETF in 1995 and 1996, the members of that working group are largely
- responsible for the ideas captured herein. Particular thanks to
- Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
- DNSSEC issues in this document, and to John Gilmore for pointing out
- where the clarifications were not necessarily clarifying. Bob Halley
- suggested clarifying the placement of SOA records in authoritative
- answers, and provided the references. Michael Patton, as usual, and
- Mark Andrews, Alan Barrett and Stan Barber provided much assistance
- with many details. Josh Littlefield helped make sure that the
- clarifications didn't cause problems in some irritating corner cases.
-
-15. Authors' Addresses
-
- Robert Elz
- Computer Science
- University of Melbourne
- Parkville, Victoria, 3052
- Australia.
-
- EMail: kre@munnari.OZ.AU
-
-
- Randy Bush
- RGnet, Inc.
- 5147 Crystal Springs Drive NE
- Bainbridge Island, Washington, 98110
- United States.
-
- EMail: randy@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush Standards Track [Page 15]
diff --git a/contrib/bind9/doc/rfc/rfc2230.txt b/contrib/bind9/doc/rfc/rfc2230.txt
deleted file mode 100644
index 03995fe25bd13..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2230.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Atkinson
-Request for Comments: 2230 NRL
-Category: Informational November 1997
-
-
- Key Exchange Delegation Record for the DNS
-
-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 (1997). All Rights Reserved.
-
-ABSTRACT
-
- This note describes a mechanism whereby authorisation for one node to
- act as key exchanger for a second node is delegated and made
- available via the Secure DNS. This mechanism is intended to be used
- only with the Secure DNS. It can be used with several security
- services. For example, a system seeking to use IP Security [RFC-
- 1825, RFC-1826, RFC-1827] to protect IP packets for a given
- destination can use this mechanism to determine the set of authorised
- remote key exchanger systems for that destination.
-
-1. INTRODUCTION
-
-
- The Domain Name System (DNS) is the standard way that Internet nodes
- locate information about addresses, mail exchangers, and other data
- relating to remote Internet nodes. [RFC-1035, RFC-1034] More
- recently, Eastlake and Kaufman have defined standards-track security
- extensions to the DNS. [RFC-2065] These security extensions can be
- used to authenticate signed DNS data records and can also be used to
- store signed public keys in the DNS.
-
- The KX record is useful in providing an authenticatible method of
- delegating authorisation for one node to provide key exchange
- services on behalf of one or more, possibly different, nodes. This
- note specifies the syntax and semantics of the KX record, which is
- currently in limited deployment in certain IP-based networks. The
-
-
-
-
-
-
-
-Atkinson Informational [Page 1]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- reader is assumed to be familiar with the basics of DNS, including
- familiarity with [RFC-1035, RFC-1034]. This document is not on the
- IETF standards-track and does not specify any level of standard.
- This document merely provides information for the Internet community.
-
-1.1 Identity Terminology
-
- This document relies upon the concept of "identity domination". This
- concept might be new to the reader and so is explained in this
- section. The subject of endpoint naming for security associations
- has historically been somewhat contentious. This document takes no
- position on what forms of identity should be used. In a network,
- there are several forms of identity that are possible.
-
- For example, IP Security has defined notions of identity that
- include: IP Address, IP Address Range, Connection ID, Fully-Qualified
- Domain Name (FQDN), and User with Fully Qualified Domain Name (USER
- FQDN).
-
- A USER FQDN identity dominates a FQDN identity. A FQDN identity in
- turn dominates an IP Address identity. Similarly, a Connection ID
- dominates an IP Address identity. An IP Address Range dominates each
- IP Address identity for each IP address within that IP address range.
- Also, for completeness, an IP Address identity is considered to
- dominate itself.
-
-2. APPROACH
-
- This document specifies a new kind of DNS Resource Record (RR), known
- as the Key Exchanger (KX) record. A Key Exchanger Record has the
- mnemonic "KX" and the type code of 36. Each KX record is associated
- with a fully-qualified domain name. The KX record is modeled on the
- MX record described in [Part86]. Any given domain, subdomain, or host
- entry in the DNS might have a KX record.
-
-2.1 IPsec Examples
-
- In these two examples, let S be the originating node and let D be the
- destination node. S2 is another node on the same subnet as S. D2 is
- another node on the same subnet as D. R1 and R2 are IPsec-capable
- routers. The path from S to D goes via first R1 and later R2. The
- return path from D to S goes via first R2 and later R1.
-
- IETF-standard IP Security uses unidirectional Security Associations
- [RFC-1825]. Therefore, a typical IP session will use a pair of
- related Security Associations, one in each direction. The examples
- below talk about how to setup an example Security Association, but in
- practice a pair of matched Security Associations will normally be
-
-
-
-Atkinson Informational [Page 2]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- used.
-
-2.1.1 Subnet-to-Subnet Example
-
- If neither S nor D implements IPsec, security can still be provided
- between R1 and R2 by building a secure tunnel. This can use either
- AH or ESP.
-
- S ---+ +----D
- | |
- +- R1 -----[zero or more routers]-------R2-+
- | |
- S2---+ +----D2
-
- Figure 1: Network Diagram for Subnet-to-Subnet Example
-
- In this example, R1 makes the policy decision to provide the IPsec
- service for traffic from R1 destined for R2. Once R1 has decided
- that the packet from S to D should be protected, it performs a secure
- DNS lookup for the records associated with domain D. If R1 only
- knows the IP address for D, then a secure reverse DNS lookup will be
- necessary to determine the domain D, before that forward secure DNS
- lookup for records associated with domain D. If these DNS records of
- domain D include a KX record for the IPsec service, then R1 knows
- which set of nodes are authorised key exchanger nodes for the
- destination D.
-
- In this example, let there be at least one KX record for D and let
- the most preferred KX record for D point at R2. R1 then selects a
- key exchanger (in this example, R2) for D from the list obtained from
- the secure DNS. Then R1 initiates a key management session with that
- key exchanger (in this example, R2) to setup an IPsec Security
- Association between R1 and D. In this example, R1 knows (either by
- seeing an outbound packet arriving from S destined to D or via other
- methods) that S will be sending traffic to D. In this example R1's
- policy requires that traffic from S to D should be segregated at
- least on a host-to-host basis, so R1 desires an IPsec Security
- Association with source identity that dominates S, proxy identity
- that dominates R1, and destination identity that dominates R2.
-
- In turn, R2 is able to authenticate the delegation of Key Exchanger
- authorisation for target S to R1 by making an authenticated forward
- DNS lookup for KX records associated with S and verifying that at
- least one such record points to R1. The identity S is typically
- given to R2 as part of the key management process between R1 and R2.
-
-
-
-
-
-
-Atkinson Informational [Page 3]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- If D initially only knows the IP address of S, then it will need to
- perform a secure reverse DNS lookup to obtain the fully-qualified
- domain name for S prior to that secure forward DNS lookup.
-
- If R2 does not receive an authenticated DNS response indicating that
- R1 is an authorised key exchanger for S, then D will not accept the
- SA negotiation from R1 on behalf of identity S.
-
- If the proposed IPsec Security Association is acceptable to both R1
- and R2, each of which might have separate policies, then they create
- that IPsec Security Association via Key Management.
-
- Note that for unicast traffic, Key Management will typically also
- setup a separate (but related) IPsec Security Association for the
- return traffic. That return IPsec Security Association will have
- equivalent identities. In this example, that return IPsec Security
- Association will have a source identity that dominates D, a proxy
- identity that dominates R2, and a destination identity that dominates
- R1.
-
- Once the IPsec Security Association has been created, then R1 uses it
- to protect traffic from S destined for D via a secure tunnel that
- originates at R1 and terminates at R2. For the case of unicast, R2
- will use the return IPsec Security Association to protect traffic
- from D destined for S via a secure tunnel that originates at R2 and
- terminates at R1.
-
-2.1.2 Subnet-to-Host Example
-
- Consider the case where D and R1 implement IPsec, but S does not
- implement IPsec, which is an interesting variation on the previous
- example. This example is shown in Figure 2 below.
-
- S ---+
- |
- +- R1 -----[zero or more routers]-------D
- |
- S2---+
-
- Figure 2: Network Diagram for Subnet-to-Host Example
-
- In this example, R1 makes the policy decision that IP Security is
- needed for the packet travelling from S to D. Then, R1 performs the
- secure DNS lookup for D and determines that D is its own key
- exchanger, either from the existence of a KX record for D pointing to
- D or from an authenticated DNS response indicating that no KX record
- exists for D. If R1 does not initially know the domain name of D,
- then prior to the above forward secure DNS lookup, R1 performs a
-
-
-
-Atkinson Informational [Page 4]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- secure reverse DNS lookup on the IP address of D to determine the
- fully-qualified domain name for that IP address. R1 then initiates
- key management with D to create an IPsec Security Association on
- behalf of S.
-
- In turn, D can verify that R1 is authorised to create an IPsec
- Security Association on behalf of S by performing a DNS KX record
- lookup for target S. R1 usually provides identity S to D via key
- management. If D only has the IP address of S, then D will need to
- perform a secure reverse lookup on the IP address of S to determine
- domain name S prior to the secure forward DNS lookup on S to locate
- the KX records for S.
-
- If D does not receive an authenticated DNS response indicating that
- R1 is an authorised key exchanger for S, then D will not accept the
- SA negotiation from R1 on behalf of identity S.
-
- If the IPsec Security Association is successfully established between
- R1 and D, that IPsec Security Association has a source identity that
- dominates S's IP address, a proxy identity that dominates R1's IP
- address, and a destination identity that dominates D's IP address.
-
- Finally, R1 begins providing the security service for packets from S
- that transit R1 destined for D. When D receives such packets, D
- examines the SA information during IPsec input processing and sees
- that R1's address is listed as valid proxy address for that SA and
- that S is the source address for that SA. Hence, D knows at input
- processing time that R1 is authorised to provide security on behalf
- of S. Therefore packets coming from R1 with valid IP security that
- claim to be from S are trusted by D to have really come from S.
-
-2.1.3 Host to Subnet Example
-
- Now consider the above case from D's perspective (i.e. where D is
- sending IP packets to S). This variant is sometimes known as the
- Mobile Host or "roadwarrier" case. The same basic concepts apply, but
- the details are covered here in hope of improved clarity.
-
- S ---+
- |
- +- R1 -----[zero or more routers]-------D
- |
- S2---+
-
- Figure 3: Network Diagram for Host-to-Subnet Example
-
-
-
-
-
-
-Atkinson Informational [Page 5]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- In this example, D makes the policy decision that IP Security is
- needed for the packets from D to S. Then D performs the secure DNS
- lookup for S and discovers that a KX record for S exists and points
- at R1. If D only has the IP address of S, then it performs a secure
- reverse DNS lookup on the IP address of S prior to the forward secure
- DNS lookup for S.
-
- D then initiates key management with R1, where R1 is acting on behalf
- of S, to create an appropriate Security Association. Because D is
- acting as its own key exchanger, R1 does not need to perform a secure
- DNS lookup for KX records associated with D.
-
- D and R1 then create an appropriate IPsec Security Security
- Association. This IPsec Security Association is setup as a secure
- tunnel with a source identity that dominates D's IP Address and a
- destination identity that dominates R1's IP Address. Because D
- performs IPsec for itself, no proxy identity is needed in this IPsec
- Security Association. If the proxy identity is non-null in this
- situation, then the proxy identity must dominate D's IP Address.
-
- Finally, D sends secured IP packets to R1. R1 receives those
- packets, provides IPsec input processing (including appropriate
- inner/outer IP address validation), and forwards valid packets along
- to S.
-
-2.2 Other Examples
-
- This mechanism can be extended for use with other services as well.
- To give some insight into other possible uses, this section discusses
- use of KX records in environments using a Key Distribution Center
- (KDC), such as Kerberos [KN93], and a possible use of KX records in
- conjunction with mobile nodes accessing the network via a dialup
- service.
-
-2.2.1 KDC Examples
-
- This example considers the situation of a destination node
- implementing IPsec that can only obtain its Security Association
- information from a Key Distribution Center (KDC). Let the KDC
- implement both the KDC protocol and also a non-KDC key management
- protocol (e.g. ISAKMP). In such a case, each client node of the KDC
- might have its own KX record pointing at the KDC so that nodes not
- implementing the KDC protocol can still create Security Associations
- with each of the client nodes of the KDC.
-
- In the event the session initiator were not using the KDC but the
- session target was an IPsec node that only used the KDC, the
- initiator would find the KX record for the target pointing at the
-
-
-
-Atkinson Informational [Page 6]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- KDC. Then, the external key management exchange (e.g. ISAKMP) would
- be between the initiator and the KDC. Then the KDC would distribute
- the IPsec SA to the KDC-only IPsec node using the KDC. The IPsec
- traffic itself could travel directly between the initiator and the
- destination node.
-
- In the event the initiator node could only use the KDC and the target
- were not using the KDC, the initiator would send its request for a
- key to the KDC. The KDC would then initiate an external key
- management exchange (e.g. ISAKMP) with a node that the target's KX
- record(s) pointed to, on behalf of the initiator node.
-
- The target node could verify that the KDC were allowed to proxy for
- the initiator node by looking up the KX records for the initiator
- node and finding a KX record for the initiator that listed the KDC.
-
- Then the external key exchange would be performed between the KDC and
- the target node. Then the KDC would distribute the resulting IPsec
- Security Association to the initiator. Again, IPsec traffic itself
- could travel directly between the initiator and the destination.
-
-2.2.2 Dial-Up Host Example
-
- This example outlines a possible use of KX records with mobile hosts
- that dial into the network via PPP and are dynamically assigned an IP
- address and domain-name at dial-in time.
-
- Consider the situation where each mobile node is dynamically assigned
- both a domain name and an IP address at the time that node dials into
- the network. Let the policy require that each mobile node act as its
- own Key Exchanger. In this case, it is important that dial-in nodes
- use addresses from one or more well known IP subnets or address pools
- dedicated to dial-in access. If that is true, then no KX record or
- other action is needed to ensure that each node will act as its own
- Key Exchanger because lack of a KX record indicates that the node is
- its own Key Exchanger.
-
- Consider the situation where the mobile node's domain name remains
- constant but its IP address changes. Let the policy require that
- each mobile node act as its own Key Exchanger. In this case, there
- might be operational problems when another node attempts to perform a
- secure reverse DNS lookup on the IP address to determine the
- corresponding domain name. The authenticated DNS binding (in the
- form of a PTR record) between the mobile node's currently assigned IP
- address and its permanent domain name will need to be securely
- updated each time the node is assigned a new IP address. There are
- no mechanisms for accomplishing this that are both IETF-standard and
- widely deployed as of the time this note was written. Use of Dynamic
-
-
-
-Atkinson Informational [Page 7]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- DNS Update without authentication is a significant security risk and
- hence is not recommended for this situation.
-
-3. SYNTAX OF KX RECORD
-
- A KX record has the DNS TYPE of "KX" and a numeric value of 36. A KX
- record is a member of the Internet ("IN") CLASS in the DNS. Each KX
- record is associated with a <domain-name> entry in the DNS. A KX
- record has the following textual syntax:
-
- <domain-name> IN KX <preference> <domain-name>
-
- For this description, let the <domain-name> item to the left of the
- "KX" string be called <domain-name 1> and the <domain-name> item to
- the right of the "KX" string be called <domain-name 2>. <preference>
- is a non-negative integer.
-
- Internet nodes about to initiate a key exchange with <domain-name 1>
- should instead contact <domain-name 2> to initiate the key exchange
- for a security service between the initiator and <domain-name 2>. If
- more than one KX record exists for <domain-name 1>, then the
- <preference> field is used to indicate preference among the systems
- delegated to. Lower values are preferred over higher values. The
- <domain-name 2> is authorised to provide key exchange services on
- behalf of <domain-name 1>. The <domain-name 2> MUST have a CNAME
- record, an A record, or an AAAA record associated with it.
-
-3.1 KX RDATA format
-
- The KX DNS record has the following RDATA format:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PREFERENCE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EXCHANGER /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
- PREFERENCE A 16 bit non-negative integer which specifies the
- preference given to this RR among other KX records
- at the same owner. Lower values are preferred.
-
- EXCHANGER A <domain-name> which specifies a host willing to
- act as a mail exchange for the owner name.
-
-
-
-
-
-Atkinson Informational [Page 8]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- KX records MUST cause type A additional section processing for the
- host specified by EXCHANGER. In the event that the host processing
- the DNS transaction supports IPv6, KX records MUST also cause type
- AAAA additional section processing.
-
- The KX RDATA field MUST NOT be compressed.
-
-4. SECURITY CONSIDERATIONS
-
- KX records MUST always be signed using the method(s) defined by the
- DNS Security extensions specified in [RFC-2065]. All unsigned KX
- records MUST be ignored because of the security vulnerability caused
- by assuming that unsigned records are valid. All signed KX records
- whose signatures do not correctly validate MUST be ignored because of
- the potential security vulnerability in trusting an invalid KX
- record.
-
- KX records MUST be ignored by systems not implementing Secure DNS
- because such systems have no mechanism to authenticate the KX record.
-
- If a node does not have a permanent DNS entry and some form of
- Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
- fully authenticated to prevent an adversary from injecting false DNS
- records (especially the KX, A, and PTR records) into the Domain Name
- System. If false records were inserted into the DNS without being
- signed by the Secure DNS mechanisms, then a denial-of-service attack
- results. If false records were inserted into the DNS and were
- (erroneously) signed by the signing authority, then an active attack
- results.
-
- Myriad serious security vulnerabilities can arise if the restrictions
- throuhout this document are not strictly adhered to. Implementers
- should carefully consider the openly published issues relating to DNS
- security [Bell95,Vixie95] as they build their implementations.
- Readers should also consider the security considerations discussed in
- the DNS Security Extensions document [RFC-2065].
-
-5. REFERENCES
-
-
- [RFC-1825] Atkinson, R., "IP Authentication Header", RFC 1826,
- August 1995.
-
- [RFC-1827] Atkinson, R., "IP Encapsulating Security Payload",
- RFC 1827, August 1995.
-
-
-
-
-
-
-Atkinson Informational [Page 9]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
- [Bell95] Bellovin, S., "Using the Domain Name System for System
- Break-ins", Proceedings of 5th USENIX UNIX Security
- Symposium, USENIX Association, Berkeley, CA, June 1995.
- ftp://ftp.research.att.com/dist/smb/dnshack.ps
-
- [RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name System
- Security Extensions", RFC 2065, January 1997.
-
- [RFC-1510] Kohl J., and C. Neuman, "The Kerberos Network
- Authentication Service", RFC 1510, September 1993.
-
- [RFC-1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC-1034] Mockapetris, P., "Domain names - concepts and
- facilities", STD 13, RFC 1034, November 1987.
-
- [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
- the 5th USENIX UNIX Security Symposium, USENIX
- Association, Berkeley, CA, June 1995.
- ftp://ftp.vix.com/pri/vixie/bindsec.psf
-
-ACKNOWLEDGEMENTS
-
- Development of this DNS record was primarily performed during 1993
- through 1995. The author's work on this was sponsored jointly by the
- Computing Systems Technology Office (CSTO) of the Advanced Research
- Projects Agency (ARPA) and by the Information Security Program Office
- (PD71E), Space & Naval Warface Systems Command (SPAWAR). In that
- era, Dave Mihelcic and others provided detailed review and
- constructive feedback. More recently, Bob Moscowitz and Todd Welch
- provided detailed review and constructive feedback of a work in
- progress version of this document.
-
-AUTHOR'S ADDRESS
-
- Randall Atkinson
- Code 5544
- Naval Research Laboratory
- 4555 Overlook Avenue, SW
- Washington, DC 20375-5337
-
- Phone: (DSN) 354-8590
- EMail: atkinson@itd.nrl.navy.mil
-
-
-
-
-
-
-
-Atkinson Informational [Page 10]
-
-RFC 2230 DNS Key Exchange Delegation Record November 1997
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published
- andand distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Atkinson Informational [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc2308.txt b/contrib/bind9/doc/rfc/rfc2308.txt
deleted file mode 100644
index 9123a9527a819..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2308.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Andrews
-Request for Comments: 2308 CSIRO
-Updates: 1034, 1035 March 1998
-Category: Standards Track
-
-
- Negative Caching of DNS Queries (DNS NCACHE)
-
-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 (1998). All Rights Reserved.
-
-Abstract
-
- [RFC1034] provided a description of how to cache negative responses.
- It however had a fundamental flaw in that it did not allow a name
- server to hand out those cached responses to other resolvers, thereby
- greatly reducing the effect of the caching. This document addresses
- issues raise in the light of experience and replaces [RFC1034 Section
- 4.3.4].
-
- Negative caching was an optional part of the DNS specification and
- deals with the caching of the non-existence of an RRset [RFC2181] or
- domain name.
-
- Negative caching is useful as it reduces the response time for
- negative answers. It also reduces the number of messages that have
- to be sent between resolvers and name servers hence overall network
- traffic. A large proportion of DNS traffic on the Internet could be
- eliminated if all resolvers implemented negative caching. With this
- in mind negative caching should no longer be seen as an optional part
- of a DNS resolver.
-
-
-
-
-
-
-
-
-
-
-
-Andrews Standards Track [Page 1]
-
-RFC 2308 DNS NCACHE March 1998
-
-
-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 [RFC2119].
-
- "Negative caching" - the storage of knowledge that something does not
- exist. We can store the knowledge that a record has a particular
- value. We can also do the reverse, that is, to store the knowledge
- that a record does not exist. It is the storage of knowledge that
- something does not exist, cannot or does not give an answer that we
- call negative caching.
-
- "QNAME" - the name in the query section of an answer, or where this
- resolves to a CNAME, or CNAME chain, the data field of the last
- CNAME. The last CNAME in this sense is that which contains a value
- which does not resolve to another CNAME. Implementations should note
- that including CNAME records in responses in order, so that the first
- has the label from the query section, and then each in sequence has
- the label from the data section of the previous (where more than one
- CNAME is needed) allows the sequence to be processed in one pass, and
- considerably eases the task of the receiver. Other relevant records
- (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
-
- "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
- described in [RFC1035 Section 4.1.1] and the two terms are used
- interchangeably in this document.
-
- "NODATA" - a pseudo RCODE which indicates that the name is valid, for
- the given class, but are no records of the given type. A NODATA
- response has to be inferred from the answer.
-
- "FORWARDER" - a nameserver used to resolve queries instead of
- directly using the authoritative nameserver chain. The forwarder
- typically either has better access to the internet, or maintains a
- bigger cache which may be shared amongst many resolvers. How a
- server is identified as a FORWARDER, or knows it is a FORWARDER is
- outside the scope of this document. However if you are being used as
- a forwarder the query will have the recursion desired flag set.
-
- An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
- when reading this document.
-
-
-
-
-
-
-
-
-
-Andrews Standards Track [Page 2]
-
-RFC 2308 DNS NCACHE March 1998
-
-
-2 - Negative Responses
-
- The most common negative responses indicate that a particular RRset
- does not exist in the DNS. The first sections of this document deal
- with this case. Other negative responses can indicate failures of a
- nameserver, those are dealt with in section 7 (Other Negative
- Responses).
-
- A negative response is indicated by one of the following conditions:
-
-2.1 - Name Error
-
- Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
- in the RCODE field. In this case the domain referred to by the QNAME
- does not exist. Note: the answer section may have SIG and CNAME RRs
- and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
-
- It is possible to distinguish between a referral and a NXDOMAIN
- response by the presense of NXDOMAIN in the RCODE regardless of the
- presence of NS or SOA records in the authority section.
-
- NXDOMAIN responses can be categorised into four types by the contents
- of the authority section. These are shown below along with a
- referral for comparison. Fields not mentioned are not important in
- terms of the examples.
-
- NXDOMAIN RESPONSE: TYPE 1.
-
- Header:
- RDCODE=NXDOMAIN
- Query:
- AN.EXAMPLE. A
- Answer:
- AN.EXAMPLE. CNAME TRIPPLE.XX.
- Authority:
- XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
- XX. NS NS1.XX.
- XX. NS NS2.XX.
- Additional:
- NS1.XX. A 127.0.0.2
- NS2.XX. A 127.0.0.3
-
- NXDOMAIN RESPONSE: TYPE 2.
-
- Header:
- RDCODE=NXDOMAIN
- Query:
- AN.EXAMPLE. A
-
-
-
-Andrews Standards Track [Page 3]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- Answer:
- AN.EXAMPLE. CNAME TRIPPLE.XX.
- Authority:
- XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
- Additional:
- <empty>
-
- NXDOMAIN RESPONSE: TYPE 3.
-
- Header:
- RDCODE=NXDOMAIN
- Query:
- AN.EXAMPLE. A
- Answer:
- AN.EXAMPLE. CNAME TRIPPLE.XX.
- Authority:
- <empty>
- Additional:
- <empty>
-
- NXDOMAIN RESPONSE: TYPE 4
-
- Header:
- RDCODE=NXDOMAIN
- Query:
- AN.EXAMPLE. A
- Answer:
- AN.EXAMPLE. CNAME TRIPPLE.XX.
- Authority:
- XX. NS NS1.XX.
- XX. NS NS2.XX.
- Additional:
- NS1.XX. A 127.0.0.2
- NS2.XX. A 127.0.0.3
-
- REFERRAL RESPONSE.
-
- Header:
- RDCODE=NOERROR
- Query:
- AN.EXAMPLE. A
- Answer:
- AN.EXAMPLE. CNAME TRIPPLE.XX.
- Authority:
- XX. NS NS1.XX.
- XX. NS NS2.XX.
- Additional:
- NS1.XX. A 127.0.0.2
-
-
-
-Andrews Standards Track [Page 4]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- NS2.XX. A 127.0.0.3
-
- Note, in the four examples of NXDOMAIN responses, it is known that
- the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
- The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
- exist. On the other hand, in the referral example, it is shown that
- "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
- known one way or the other about the existence of "TRIPPLE.XX", other
- than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
- obtaining information about it.
-
- Where no CNAME records appear, the NXDOMAIN response refers to the
- name in the label of the RR in the question section.
-
-2.1.1 Special Handling of Name Error
-
- This section deals with errors encountered when implementing negative
- caching of NXDOMAIN responses.
-
- There are a large number of resolvers currently in existence that
- fail to correctly detect and process all forms of NXDOMAIN response.
- Some resolvers treat a TYPE 1 NXDOMAIN response as a referral. To
- alleviate this problem it is recommended that servers that are
- authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
- responses, that is the authority section contains a SOA record and no
- NS records. If a non- authoritative server sends a type 1 NXDOMAIN
- response to one of these old resolvers, the result will be an
- unnecessary query to an authoritative server. This is undesirable,
- but not fatal except when the server is being used a FORWARDER. If
- however the resolver is using the server as a FORWARDER to such a
- resolver it will be necessary to disable the sending of TYPE 1
- NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
-
- Some resolvers incorrectly continue processing if the authoritative
- answer flag is not set, looping until the query retry threshold is
- exceeded and then returning SERVFAIL. This is a problem when your
- nameserver is listed as a FORWARDER for such resolvers. If the
- nameserver is used as a FORWARDER by such resolver, the authority
- flag will have to be forced on for NXDOMAIN responses to these
- resolvers. In practice this causes no problems even if turned on
- always, and has been the default behaviour in BIND from 4.9.3
- onwards.
-
-2.2 - No Data
-
- NODATA is indicated by an answer with the RCODE set to NOERROR and no
- relevant answers in the answer section. The authority section will
- contain an SOA record, or there will be no NS records there.
-
-
-
-Andrews Standards Track [Page 5]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- NODATA responses have to be algorithmically determined from the
- response's contents as there is no RCODE value to indicate NODATA.
- In some cases to determine with certainty that NODATA is the correct
- response it can be necessary to send another query.
-
- The authority section may contain NXT and SIG RRsets in addition to
- NS and SOA records. CNAME and SIG records may exist in the answer
- section.
-
- It is possible to distinguish between a NODATA and a referral
- response by the presence of a SOA record in the authority section or
- the absence of NS records in the authority section.
-
- NODATA responses can be categorised into three types by the contents
- of the authority section. These are shown below along with a
- referral for comparison. Fields not mentioned are not important in
- terms of the examples.
-
- NODATA RESPONSE: TYPE 1.
-
- Header:
- RDCODE=NOERROR
- Query:
- ANOTHER.EXAMPLE. A
- Answer:
- <empty>
- Authority:
- EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
- EXAMPLE. NS NS1.XX.
- EXAMPLE. NS NS2.XX.
- Additional:
- NS1.XX. A 127.0.0.2
- NS2.XX. A 127.0.0.3
-
- NO DATA RESPONSE: TYPE 2.
-
- Header:
- RDCODE=NOERROR
- Query:
- ANOTHER.EXAMPLE. A
- Answer:
- <empty>
- Authority:
- EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
- Additional:
- <empty>
-
-
-
-
-
-Andrews Standards Track [Page 6]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- NO DATA RESPONSE: TYPE 3.
-
- Header:
- RDCODE=NOERROR
- Query:
- ANOTHER.EXAMPLE. A
- Answer:
- <empty>
- Authority:
- <empty>
- Additional:
- <empty>
-
- REFERRAL RESPONSE.
-
- Header:
- RDCODE=NOERROR
- Query:
- ANOTHER.EXAMPLE. A
- Answer:
- <empty>
- Authority:
- EXAMPLE. NS NS1.XX.
- EXAMPLE. NS NS2.XX.
- Additional:
- NS1.XX. A 127.0.0.2
- NS2.XX. A 127.0.0.3
-
-
- These examples, unlike the NXDOMAIN examples above, have no CNAME
- records, however they could, in just the same way that the NXDOMAIN
- examples did, in which case it would be the value of the last CNAME
- (the QNAME) for which NODATA would be concluded.
-
-2.2.1 - Special Handling of No Data
-
- There are a large number of resolvers currently in existence that
- fail to correctly detect and process all forms of NODATA response.
- Some resolvers treat a TYPE 1 NODATA response as a referral. To
- alleviate this problem it is recommended that servers that are
- authoritative for the NODATA response only send TYPE 2 NODATA
- responses, that is the authority section contains a SOA record and no
- NS records. Sending a TYPE 1 NODATA response from a non-
- authoritative server to one of these resolvers will only result in an
- unnecessary query. If a server is listed as a FORWARDER for another
- resolver it may also be necessary to disable the sending of TYPE 1
- NODATA response for non-authoritative NODATA responses.
-
-
-
-
-Andrews Standards Track [Page 7]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- Some name servers fail to set the RCODE to NXDOMAIN in the presence
- of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA
- answer is required in this case the resolver must query again using
- the QNAME as the query label.
-
-3 - Negative Answers from Authoritative Servers
-
- Name servers authoritative for a zone MUST include the SOA record of
- the zone in the authority section of the response when reporting an
- NXDOMAIN or indicating that no data of the requested type exists.
- This is required so that the response may be cached. 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 TTL SIG record associated with the
- SOA record should also be trimmed in line with the SOA's TTL.
-
- If the containing zone is signed [RFC2065] the SOA and appropriate
- NXT and SIG records MUST be added.
-
-4 - SOA Minimum Field
-
- The SOA minimum field has been overloaded in the past to have three
- different meanings, the minimum TTL value of all RRs in a zone, the
- default TTL of RRs which did not contain a TTL value and the TTL of
- negative responses.
-
- Despite being the original defined meaning, the first of these, the
- minimum TTL value of all RRs in a zone, has never in practice been
- used and is hereby deprecated.
-
- The second, the default TTL of RRs which contain no explicit TTL in
- the master zone file, is relevant only at the primary server. After
- a zone transfer all RRs have explicit TTLs and it is impossible to
- determine whether the TTL for a record was explicitly set or derived
- from the default after a zone transfer. Where a server does not
- require RRs to include the TTL value explicitly, it should provide a
- mechanism, not being the value of the MINIMUM field of the SOA
- record, from which the missing TTL values are obtained. How this is
- done is implementation dependent.
-
- The Master File format [RFC 1035 Section 5] is extended to include
- the following directive:
-
- $TTL <TTL> [comment]
-
-
-
-
-
-
-
-Andrews Standards Track [Page 8]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- All resource records appearing after the directive, and which do not
- explicitly include a TTL value, have their TTL set to the TTL given
- in the $TTL directive. SIG records without a explicit TTL get their
- TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
-
- The remaining of the current meanings, of being the TTL to be used
- for negative responses, is the new defined meaning of the SOA minimum
- field.
-
-5 - Caching Negative Answers
-
- Like normal answers negative answers have a time to live (TTL). As
- there is no record in the answer section to which this TTL can be
- applied, the TTL must be carried by another method. This is done by
- including the SOA record from the zone in the authority section of
- the reply. When the authoritative server creates this record its TTL
- is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
- This TTL decrements in a similar manner to a normal cached answer and
- upon reaching zero (0) indicates the cached negative answer MUST NOT
- be used again.
-
- A negative answer that resulted from a name error (NXDOMAIN) should
- be cached such that it can be retrieved and returned in response to
- another query for the same <QNAME, QCLASS> that resulted in the
- cached negative response.
-
- A negative answer that resulted from a no data error (NODATA) should
- be cached such that it can be retrieved and returned in response to
- another query for the same <QNAME, QTYPE, QCLASS> that resulted in
- the cached negative response.
-
- The NXT record, if it exists in the authority section of a negative
- answer received, MUST be stored such that it can be be located and
- returned with SOA record in the authority section, as should any SIG
- records in the authority section. For NXDOMAIN answers there is no
- "necessary" obvious relationship between the NXT records and the
- QNAME. The NXT record MUST have the same owner name as the query
- name for NODATA responses.
-
- Negative responses without SOA records SHOULD NOT be cached as there
- is no way to prevent the negative responses looping forever between a
- pair of servers even with a short TTL.
-
- Despite the DNS forming a tree of servers, with various mis-
- configurations it is possible to form a loop in the query graph, e.g.
- two servers listing each other as forwarders, various lame server
- configurations. Without a TTL count down a cache negative response
-
-
-
-
-Andrews Standards Track [Page 9]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- when received by the next server would have its TTL reset. This
- negative indication could then live forever circulating between the
- servers involved.
-
- As with caching positive responses it is sensible for a resolver to
- limit for how long it will cache a negative response as the protocol
- supports caching for up to 68 years. Such a limit should not be
- greater than that applied to positive answers and preferably be
- tunable. Values of one to three hours have been found to work well
- and would make sensible a default. Values exceeding one day have
- been found to be problematic.
-
-6 - Negative answers from the cache
-
- When a server, in answering a query, encounters a cached negative
- response it MUST add the cached SOA record to the authority section
- of the response with the TTL decremented by the amount of time it was
- stored in the cache. This allows the NXDOMAIN / NODATA response to
- time out correctly.
-
- If a NXT record was cached along with SOA record it MUST be added to
- the authority section. If a SIG record was cached along with a NXT
- record it SHOULD be added to the authority section.
-
- As with all answers coming from the cache, negative answers SHOULD
- have an implicit referral built into the answer. This enables the
- resolver to locate an authoritative source. An implicit referral is
- characterised by NS records in the authority section referring the
- resolver towards a authoritative source. NXDOMAIN types 1 and 4
- responses contain implicit referrals as does NODATA type 1 response.
-
-7 - Other Negative Responses
-
- Caching of other negative responses is not covered by any existing
- RFC. There is no way to indicate a desired TTL in these responses.
- Care needs to be taken to ensure that there are not forwarding loops.
-
-7.1 Server Failure (OPTIONAL)
-
- Server failures fall into two major classes. The first is where a
- server can determine that it has been misconfigured for a zone. This
- may be where it has been listed as a server, but not configured to be
- a server for the zone, or where it has been configured to be a server
- for the zone, but cannot obtain the zone data for some reason. This
- can occur either because the zone file does not exist or contains
- errors, or because another server from which the zone should have
- been available either did not respond or was unable or unwilling to
- supply the zone.
-
-
-
-Andrews Standards Track [Page 10]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- The second class is where the server needs to obtain an answer from
- elsewhere, but is unable to do so, due to network failures, other
- servers that don't reply, or return server failure errors, or
- similar.
-
- In either case a resolver MAY cache a server failure response. If it
- does so it MUST NOT cache it for longer than five (5) minutes, and it
- MUST be cached against the specific query tuple <query name, type,
- class, server IP address>.
-
-7.2 Dead / Unreachable Server (OPTIONAL)
-
- Dead / Unreachable servers are servers that fail to respond in any
- way to a query or where the transport layer has provided an
- indication that the server does not exist or is unreachable. A
- server may be deemed to be dead or unreachable if it has not
- responded to an outstanding query within 120 seconds.
-
- Examples of transport layer indications are:
-
- ICMP error messages indicating host, net or port unreachable.
- TCP resets
- IP stack error messages providing similar indications to those above.
-
- A server MAY cache a dead server indication. If it does so it MUST
- NOT be deemed dead for longer than five (5) minutes. The indication
- MUST be stored against query tuple <query name, type, class, server
- IP address> unless there was a transport layer indication that the
- server does not exist, in which case it applies to all queries to
- that specific IP address.
-
-8 - Changes from RFC 1034
-
- Negative caching in resolvers is no-longer optional, if a resolver
- caches anything it must also cache negative answers.
-
- Non-authoritative negative answers MAY be cached.
-
- The SOA record from the authority section MUST be cached. Name error
- indications must be cached against the tuple <query name, QCLASS>.
- No data indications must be cached against <query name, QTYPE,
- QCLASS> tuple.
-
- A cached SOA record must be added to the response. This was
- explicitly not allowed because previously the distinction between a
- normal cached SOA record, and the SOA cached as a result of a
- negative response was not made, and simply extracting a normal cached
- SOA and adding that to a cached negative response causes problems.
-
-
-
-Andrews Standards Track [Page 11]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- The $TTL TTL directive was added to the master file format.
-
-9 - History of Negative Caching
-
- This section presents a potted history of negative caching in the DNS
- and forms no part of the technical specification of negative caching.
-
- It is interesting to note that the same concepts were re-invented in
- both the CHIVES and BIND servers.
-
- The history of the early CHIVES work (Section 9.1) was supplied by
- Rob Austein <sra@epilogue.com> and is reproduced here in the form in
- which he supplied it [MPA].
-
- Sometime around the spring of 1985, I mentioned to Paul Mockapetris
- that our experience with his JEEVES DNS resolver had pointed out the
- need for some kind of negative caching scheme. Paul suggested that
- we simply cache authoritative errors, using the SOA MINIMUM value for
- the zone that would have contained the target RRs. I'm pretty sure
- that this conversation took place before RFC-973 was written, but it
- was never clear to me whether this idea was something that Paul came
- up with on the spot in response to my question or something he'd
- already been planning to put into the document that became RFC-973.
- In any case, neither of us was entirely sure that the SOA MINIMUM
- value was really the right metric to use, but it was available and
- was under the control of the administrator of the target zone, both
- of which seemed to us at the time to be important feature.
-
- Late in 1987, I released the initial beta-test version of CHIVES, the
- DNS resolver I'd written to replace Paul's JEEVES resolver. CHIVES
- included a search path mechanism that was used pretty heavily at
- several sites (including my own), so CHIVES also included a negative
- caching mechanism based on SOA MINIMUM values. The basic strategy
- was to cache authoritative error codes keyed by the exact query
- parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
- SOA MINIMUM value. CHIVES did not attempt to track down SOA RRs if
- they weren't supplied in the authoritative response, so it never
- managed to completely eliminate the gratuitous DNS error message
- traffic, but it did help considerably. Keep in mind that this was
- happening at about the same time as the near-collapse of the ARPANET
- due to congestion caused by exponential growth and the the "old"
- (pre-VJ) TCP retransmission algorithm, so negative caching resulted
- in drasticly better DNS response time for our users, mailer daemons,
- etcetera.
-
-
-
-
-
-
-
-Andrews Standards Track [Page 12]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- As far as I know, CHIVES was the first resolver to implement negative
- caching. CHIVES was developed during the twilight years of TOPS-20,
- so it never ran on very many machines, but the few machines that it
- did run on were the ones that were too critical to shut down quickly
- no matter how much it cost to keep them running. So what few users
- we did have tended to drive CHIVES pretty hard. Several interesting
- bits of DNS technology resulted from that, but the one that's
- relevant here is the MAXTTL configuration parameter.
-
- Experience with JEEVES had already shown that RRs often showed up
- with ridiculously long TTLs (99999999 was particularly popular for
- many years, due to bugs in the code and documentation of several
- early versions of BIND), and that robust software that blindly
- believed such TTLs could create so many strange failures that it was
- often necessary to reboot the resolver frequently just to clear this
- garbage out of the cache. So CHIVES had a configuration parameter
- "MAXTTL", which specified the maximum "reasonable" TTL in a received
- RR. RRs with TTLs greater than MAXTTL would either have their TTLs
- reduced to MAXTTL or would be discarded entirely, depending on the
- setting of another configuration parameter.
-
- When we started getting field experience with CHIVES's negative
- caching code, it became clear that the SOA MINIMUM value was often
- large enough to cause the same kinds of problems for negative caching
- as the huge TTLs in RRs had for normal caching (again, this was in
- part due to a bug in several early versions of BIND, where a
- secondary server would authoritatively deny all knowledge of its
- zones if it couldn't contact the primaries on reboot). So we started
- running the negative cache TTLs through the MAXTTL check too, and
- continued to experiment.
-
- The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
- (last of the major Internet TOPS-20 machines to be shut down, thus
- the last major user of CHIVES, thus the place where we had the
- longest experimental baseline) was to set MAXTTL to about three days.
- Most of the traffic initiated by SIMTEL20 in its last years was
- mail-related, and the mail queue timeout was set to one week, so this
- gave a "stuck" message several tries at complete DNS resolution,
- without bogging down the system with a lot of useless queries. Since
- (for reasons that now escape me) we only had the single MAXTTL
- parameter rather than separate ones for positive and negative
- caching, it's not clear how much effect this setting of MAXTTL had on
- the negative caching code.
-
- CHIVES also included a second, somewhat controversial mechanism which
- took the place of negative caching in some cases. The CHIVES
- resolver daemon could be configured to load DNS master files, giving
- it the ability to act as what today would be called a "stealth
-
-
-
-Andrews Standards Track [Page 13]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- secondary". That is, when configured in this way, the resolver had
- direct access to authoritative information for heavily-used zones.
- The search path mechanisms in CHIVES reflected this: there were
- actually two separate search paths, one of which only searched local
- authoritative zone data, and one which could generate normal
- iterative queries. This cut down on the need for negative caching in
- cases where usage was predictably heavy (e.g., the resolver on
- XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
- AI.MIT.EDU and put both of these suffixes into the "local" search
- path, since between them the hosts in these two zones accounted for
- the bulk of the DNS traffic). Not all sites running CHIVES chose to
- use this feature; C.CS.CMU.EDU, for example, chose to use the
- "remote" search path for everything because there were too many
- different sub-zones at CMU for zone shadowing to be practical for
- them, so they relied pretty heavily on negative caching even for
- local traffic.
-
- Overall, I still think the basic design we used for negative caching
- was pretty reasonable: the zone administrator specified how long to
- cache negative answers, and the resolver configuration chose the
- actual cache time from the range between zero and the period
- specified by the zone administrator. There are a lot of details I'd
- do differently now (like using a new SOA field instead of overloading
- the MINIMUM field), but after more than a decade, I'd be more worried
- if we couldn't think of at least a few improvements.
-
-9.2 BIND
-
- While not the first attempt to get negative caching into BIND, in
- July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
- implemented, validation and negative caching (NCACHE). This code had
- a 10 minute TTL for negative caching and only cached the indication
- that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
- is the origin of the NODATA pseudo response code mentioned above.
-
- Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
- record such that it could be retrieved by a similar query. UUnet
- complained that they were getting old answers after loading a new
- zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
- In reality this indicated that the named needed to purge the space
- the zone would occupy. Functionality to do this was added in BIND
- 4.9.3 BETA11 patch2, December 1994.
-
- RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
-
-
-
-
-
-
-
-Andrews Standards Track [Page 14]
-
-RFC 2308 DNS NCACHE March 1998
-
-
-10 Example
-
- The following example is based on a signed zone that is empty apart
- from the nameservers. We will query for WWW.XX.EXAMPLE showing
- initial response and again 10 minutes later. Note 1: during the
- intervening 10 minutes the NS records for XX.EXAMPLE have expired.
- Note 2: the TTL of the SIG records are not explicitly set in the zone
- file and are hence the TTL of the RRset they are the signature for.
-
- Zone File:
-
- $TTL 86400
- $ORIGIN XX.EXAMPLE.
- @ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
- 1997102000 ; serial
- 1800 ; refresh (30 mins)
- 900 ; retry (15 mins)
- 604800 ; expire (7 days)
- 1200 ) ; minimum (20 mins)
- IN SIG SOA ...
- 1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
- IN SIG NXT ... XX.EXAMPLE. ...
- 300 IN NS NS1.XX.EXAMPLE.
- 300 IN NS NS2.XX.EXAMPLE.
- IN SIG NS ... XX.EXAMPLE. ...
- IN KEY 0x4100 1 1 ...
- IN SIG KEY ... XX.EXAMPLE. ...
- IN SIG KEY ... EXAMPLE. ...
- NS1 IN A 10.0.0.1
- IN SIG A ... XX.EXAMPLE. ...
- 1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG
- IN SIG NXT ...
- NS2 IN A 10.0.0.2
- IN SIG A ... XX.EXAMPLE. ...
- 1200 IN NXT XX.EXAMPLE. A NXT SIG
- IN SIG NXT ... XX.EXAMPLE. ...
-
- Initial Response:
-
- Header:
- RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
- Query:
- WWW.XX.EXAMPLE. IN A
- Answer:
- <empty>
- Authority:
- XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ...
- XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ...
-
-
-
-Andrews Standards Track [Page 15]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
- NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ...
- XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE.
- XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE.
- XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ...
- Additional
- XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ...
- XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ...
- NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1
- NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
- NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2
- NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
-
- After 10 Minutes:
-
- Header:
- RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
- Query:
- WWW.XX.EXAMPLE. IN A
- Answer:
- <empty>
- Authority:
- XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ...
- XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ...
- NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG
- NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ...
- EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE.
- EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE.
- EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ...
- Additional
- XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ...
- XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ...
- NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1
- NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
- NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2
- NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
- EXAMPLE. 65799 IN KEY 0x4100 1 1 ...
- EXAMPLE. 65799 IN SIG KEY ... . ...
-
-
-11 Security Considerations
-
- It is believed that this document does not introduce any significant
- additional security threats other that those that already exist when
- using data from the DNS.
-
-
-
-
-
-
-Andrews Standards Track [Page 16]
-
-RFC 2308 DNS NCACHE March 1998
-
-
- With negative caching it might be possible to propagate a denial of
- service attack by spreading a NXDOMAIN message with a very high TTL.
- Without negative caching that would be much harder. A similar effect
- could be achieved previously by spreading a bad A record, so that the
- server could not be reached - which is almost the same. It has the
- same effect as far as what the end user is able to do, but with a
- different psychological effect. With the bad A, I feel "damn the
- network is broken again" and try again tomorrow. With the "NXDOMAIN"
- I feel "Oh, they've turned off the server and it doesn't exist any
- more" and probably never bother trying this server again.
-
- A practical example of this is a SMTP server where this behaviour is
- encoded. With a NXDOMAIN attack the mail message would bounce
- immediately, where as with a bad A attack the mail would be queued
- and could potentially get through after the attack was suspended.
-
- For such an attack to be successful, the NXDOMAIN indiction must be
- injected into a parent server (or a busy caching resolver). One way
- this might be done by the use of a CNAME which results in the parent
- server querying an attackers server. Resolvers that wish to prevent
- such attacks can query again the final QNAME ignoring any NS data in
- the query responses it has received for this query.
-
- Implementing TTL sanity checking will reduce the effectiveness of
- such an attack, because a successful attack would require re-
- injection of the bogus data at more frequent intervals.
-
- DNS Security [RFC2065] provides a mechanism to verify whether a
- negative response is valid or not, through the use of NXT and SIG
- records. This document supports the use of that mechanism by
- promoting the transmission of the relevant security records even in a
- non security aware server.
-
-Acknowledgments
-
- I would like to thank Rob Austein for his history of the CHIVES
- nameserver. The DNSIND working group, in particular Robert Elz for
- his valuable technical and editorial contributions to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Standards Track [Page 17]
-
-RFC 2308 DNS NCACHE March 1998
-
-
-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.
-
- [RFC2065]
- Eastlake, D., and C. Kaufman, "Domain Name System Security
- Extensions," RFC 2065, January 1997.
-
- [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.
-
-Author's Address
-
- Mark Andrews
- CSIRO - Mathematical and Information Sciences
- Locked Bag 17
- North Ryde NSW 2113
- AUSTRALIA
-
- Phone: +61 2 9325 3148
- EMail: Mark.Andrews@cmis.csiro.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Standards Track [Page 18]
-
-RFC 2308 DNS NCACHE March 1998
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Standards Track [Page 19]
-
diff --git a/contrib/bind9/doc/rfc/rfc2317.txt b/contrib/bind9/doc/rfc/rfc2317.txt
deleted file mode 100644
index c17bb41f29f3d..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2317.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group H. Eidnes
-Request for Comments: 2317 SINTEF RUNIT
-BCP: 20 G. de Groot
-Category: Best Current Practice Berkeley Software Design, Inc.
- P. Vixie
- Internet Software Consortium
- March 1998
-
-
- Classless IN-ADDR.ARPA delegation
-
-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 (1998). All Rights Reserved.
-
-2. Introduction
-
- This document describes a way to do IN-ADDR.ARPA delegation on non-
- octet boundaries for address spaces covering fewer than 256
- addresses. The proposed method should thus remove one of the
- objections to subnet on non-octet boundaries but perhaps more
- significantly, make it possible to assign IP address space in smaller
- chunks than 24-bit prefixes, without losing the ability to delegate
- authority for the corresponding IN-ADDR.ARPA mappings. The proposed
- method is fully compatible with the original DNS lookup mechanisms
- specified in [1], i.e. there is no need to modify the lookup
- algorithm used, and there should be no need to modify any software
- which does DNS lookups.
-
- The document also discusses some operational considerations to
- provide some guidance in implementing this method.
-
-3. Motivation
-
- With the proliferation of classless routing technology, it has become
- feasible to assign address space on non-octet boundaries. In case of
- a very small organization with only a few hosts, assigning a full
- 24-bit prefix (what was traditionally referred to as a "class C
- network number") often leads to inefficient address space
- utilization.
-
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 1]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
- One of the problems encountered when assigning a longer prefix (less
- address space) is that it seems impossible for such an organization
- to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously. By
- use of the reverse delegation method described below, the most
- important objection to assignment of longer prefixes to unrelated
- organizations can be removed.
-
- Let us assume we have assigned the address spaces to three different
- parties as follows:
-
- 192.0.2.0/25 to organization A
- 192.0.2.128/26 to organization B
- 192.0.2.192/26 to organization C
-
- In the classical approach, this would lead to a single zone like
- this:
-
- $ORIGIN 2.0.192.in-addr.arpa.
- ;
- 1 PTR host1.A.domain.
- 2 PTR host2.A.domain.
- 3 PTR host3.A.domain.
- ;
- 129 PTR host1.B.domain.
- 130 PTR host2.B.domain.
- 131 PTR host3.B.domain.
- ;
- 193 PTR host1.C.domain.
- 194 PTR host2.C.domain.
- 195 PTR host3.C.domain.
-
- The administration of this zone is problematic. Authority for this
- zone can only be delegated once, and this usually translates into
- "this zone can only be administered by one organization." The other
- organizations with address space that corresponds to entries in this
- zone would thus have to depend on another organization for their
- address to name translation. With the proposed method, this
- potential problem can be avoided.
-
-4. Classless IN-ADDR.ARPA delegation
-
- Since a single zone can only be delegated once, we need more points
- to do delegation on to solve the problem above. These extra points
- of delegation can be introduced by extending the IN-ADDR.ARPA tree
- downwards, e.g. by using the first address or the first address and
- the network mask length (as shown below) in the corresponding address
-
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 2]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
- space to form the the first component in the name for the zones. The
- following four zone files show how the problem in the motivation
- section could be solved using this method.
-
- $ORIGIN 2.0.192.in-addr.arpa.
- @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
- ;...
- ; <<0-127>> /25
- 0/25 NS ns.A.domain.
- 0/25 NS some.other.name.server.
- ;
- 1 CNAME 1.0/25.2.0.192.in-addr.arpa.
- 2 CNAME 2.0/25.2.0.192.in-addr.arpa.
- 3 CNAME 3.0/25.2.0.192.in-addr.arpa.
- ;
- ; <<128-191>> /26
- 128/26 NS ns.B.domain.
- 128/26 NS some.other.name.server.too.
- ;
- 129 CNAME 129.128/26.2.0.192.in-addr.arpa.
- 130 CNAME 130.128/26.2.0.192.in-addr.arpa.
- 131 CNAME 131.128/26.2.0.192.in-addr.arpa.
- ;
- ; <<192-255>> /26
- 192/26 NS ns.C.domain.
- 192/26 NS some.other.third.name.server.
- ;
- 193 CNAME 193.192/26.2.0.192.in-addr.arpa.
- 194 CNAME 194.192/26.2.0.192.in-addr.arpa.
- 195 CNAME 195.192/26.2.0.192.in-addr.arpa.
-
- $ORIGIN 0/25.2.0.192.in-addr.arpa.
- @ IN SOA ns.A.domain. hostmaster.A.domain. (...)
- @ NS ns.A.domain.
- @ NS some.other.name.server.
- ;
- 1 PTR host1.A.domain.
- 2 PTR host2.A.domain.
- 3 PTR host3.A.domain.
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 3]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
- $ORIGIN 128/26.2.0.192.in-addr.arpa.
- @ IN SOA ns.B.domain. hostmaster.B.domain. (...)
- @ NS ns.B.domain.
- @ NS some.other.name.server.too.
- ;
- 129 PTR host1.B.domain.
- 130 PTR host2.B.domain.
- 131 PTR host3.B.domain.
-
-
- $ORIGIN 192/26.2.0.192.in-addr.arpa.
- @ IN SOA ns.C.domain. hostmaster.C.domain. (...)
- @ NS ns.C.domain.
- @ NS some.other.third.name.server.
- ;
- 193 PTR host1.C.domain.
- 194 PTR host2.C.domain.
- 195 PTR host3.C.domain.
-
- For each size-256 chunk split up using this method, there is a need
- to install close to 256 CNAME records in the parent zone. Some
- people might view this as ugly; we will not argue that particular
- point. It is however quite easy to automatically generate the CNAME
- resource records in the parent zone once and for all, if the way the
- address space is partitioned is known.
-
- The advantage of this approach over the other proposed approaches for
- dealing with this problem is that there should be no need to modify
- any already-deployed software. In particular, the lookup mechanism
- in the DNS does not have to be modified to accommodate this splitting
- of the responsibility for the IPv4 address to name translation on
- "non-dot" boundaries. Furthermore, this technique has been in use
- for several years in many installations, apparently with no ill
- effects.
-
- As usual, a resource record like
-
- $ORIGIN 2.0.192.in-addr.arpa.
- 129 CNAME 129.128/26.2.0.192.in-addr.arpa.
-
- can be convienently abbreviated to
-
- $ORIGIN 2.0.192.in-addr.arpa.
- 129 CNAME 129.128/26
-
-
-
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 4]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
- Some DNS implementations are not kind to special characters in domain
- names, e.g. the "/" used in the above examples. As [3] makes clear,
- these are legal, though some might feel unsightly. Because these are
- not host names the restriction of [2] does not apply. Modern clients
- and servers have an option to act in the liberal and correct fashion.
-
- The examples here use "/" because it was felt to be more visible and
- pedantic reviewers felt that the 'these are not hostnames' argument
- needed to be repeated. We advise you not to be so pedantic, and to
- not precisely copy the above examples, e.g. substitute a more
- conservative character, such as hyphen, for "/".
-
-5. Operational considerations
-
- This technique is intended to be used for delegating address spaces
- covering fewer than 256 addresses. For delegations covering larger
- blocks of addresses the traditional methods (multiple delegations)
- can be used instead.
-
-5.1 Recommended secondary name service
-
- Some older versions of name server software will make no effort to
- find and return the pointed-to name in CNAME records if the pointed-
- to name is not already known locally as cached or as authoritative
- data. This can cause some confusion in resolvers, as only the CNAME
- record will be returned in the response. To avoid this problem it is
- recommended that the authoritative name servers for the delegating
- zone (the zone containing all the CNAME records) all run as slave
- (secondary) name servers for the "child" zones delegated and pointed
- into via the CNAME records.
-
-5.2 Alternative naming conventions
-
- As a result of this method, the location of the zone containing the
- actual PTR records is no longer predefined. This gives flexibility
- and some examples will be presented here.
-
- An alternative to using the first address, or the first address and
- the network mask length in the corresponding address space, to name
- the new zones is to use some other (non-numeric) name. Thus it is
- also possible to point to an entirely different part of the DNS tree
- (i.e. outside of the IN-ADDR.ARPA tree). It would be necessary to
- use one of these alternate methods if two organizations somehow
- shared the same physical subnet (and corresponding IP address space)
- with no "neat" alignment of the addresses, but still wanted to
- administrate their own IN-ADDR.ARPA mappings.
-
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 5]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
- The following short example shows how you can point out of the IN-
- ADDR.ARPA tree:
-
- $ORIGIN 2.0.192.in-addr.arpa.
- @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
- ; ...
- 1 CNAME 1.A.domain.
- 2 CNAME 2.A.domain.
- ; ...
- 129 CNAME 129.B.domain.
- 130 CNAME 130.B.domain.
- ;
-
-
- $ORIGIN A.domain.
- @ IN SOA my-ns.A.domain. hostmaster.A.domain. (...)
- ; ...
- ;
- host1 A 192.0.2.1
- 1 PTR host1
- ;
- host2 A 192.0.2.2
- 2 PTR host2
- ;
-
- etc.
-
- This way you can actually end up with the name->address and the
- (pointed-to) address->name mapping data in the same zone file - some
- may view this as an added bonus as no separate set of secondaries for
- the reverse zone is required. Do however note that the traversal via
- the IN-ADDR.ARPA tree will still be done, so the CNAME records
- inserted there need to point in the right direction for this to work.
-
- Sketched below is an alternative approach using the same solution:
-
- $ORIGIN 2.0.192.in-addr.arpa.
- @ SOA my-ns.my.domain. hostmaster.my.domain. (...)
- ; ...
- 1 CNAME 1.2.0.192.in-addr.A.domain.
- 2 CNAME 2.2.0.192.in-addr.A.domain.
-
- $ORIGIN A.domain.
- @ SOA my-ns.A.domain. hostmaster.A.domain. (...)
- ; ...
- ;
- host1 A 192.0.2.1
- 1.2.0.192.in-addr PTR host1
-
-
-
-Eidnes, et. al. Best Current Practice [Page 6]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
- host2 A 192.0.2.2
- 2.2.0.192.in-addr PTR host2
-
- It is clear that many possibilities exist which can be adapted to the
- specific requirements of the situation at hand.
-
-5.3 Other operational issues
-
- Note that one cannot provide CNAME referrals twice for the same
- address space, i.e. you cannot allocate a /25 prefix to one
- organisation, and run IN-ADDR.ARPA this way, and then have the
- organisation subnet the /25 into longer prefixes, and attempt to
- employ the same technique to give each subnet control of its own
- number space. This would result in a CNAME record pointing to a CNAME
- record, which may be less robust overall.
-
- Unfortunately, some old beta releases of the popular DNS name server
- implementation BIND 4.9.3 had a bug which caused problems if a CNAME
- record was encountered when a reverse lookup was made. The beta
- releases involved have since been obsoleted, and this issue is
- resolved in the released code. Some software manufacturers have
- included the defective beta code in their product. In the few cases
- we know of, patches from the manufacturers are available or planned
- to replace the obsolete beta code involved.
-
-6. Security Considerations
-
- With this scheme, the "leaf sites" will need to rely on one more site
- running their DNS name service correctly than they would be if they
- had a /24 allocation of their own, and this may add an extra
- component which will need to work for reliable name resolution.
-
- Other than that, the authors are not aware of any additional security
- issues introduced by this mechanism.
-
-7. Conclusion
-
- The suggested scheme gives more flexibility in delegating authority
- in the IN-ADDR.ARPA domain, thus making it possible to assign address
- space more efficiently without losing the ability to delegate the DNS
- authority over the corresponding address to name mappings.
-
-8. Acknowledgments
-
- Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
- ip.domains some time ago. Alan Barrett and Sam Wilson provided
- valuable comments on the newsgroup.
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 7]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
- We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
- Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
- Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
- and Peter Koch for their review and constructive comments.
-
-9. References
-
- [1] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
- [2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
- Table Specification", RFC 952, October 1985.
-
- [3] Elz, R., and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 8]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
-10. Authors' Addresses
-
- Havard Eidnes
- SINTEF RUNIT
- N-7034 Trondheim
- Norway
-
- Phone: +47 73 59 44 68
- Fax: +47 73 59 17 00
- EMail: Havard.Eidnes@runit.sintef.no
-
-
- Geert Jan de Groot
- Berkeley Software Design, Inc. (BSDI)
- Hendrik Staetslaan 69
- 5622 HM Eindhoven
- The Netherlands
-
- Phone: +31 40 2960509
- Fax: +31 40 2960309
- EMail: GeertJan.deGroot@bsdi.com
-
-
- Paul Vixie
- Internet Software Consortium
- Star Route Box 159A
- Woodside, CA 94062
- USA
-
- Phone: +1 415 747 0204
- EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 9]
-
-RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al. Best Current Practice [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2373.txt b/contrib/bind9/doc/rfc/rfc2373.txt
deleted file mode 100644
index 59fcff80f1407..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2373.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Hinden
-Request for Comments: 2373 Nokia
-Obsoletes: 1884 S. Deering
-Category: Standards Track Cisco Systems
- July 1998
-
- IP Version 6 Addressing Architecture
-
-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 (1998). All Rights Reserved.
-
-Abstract
-
- This specification defines the addressing architecture of the IP
- Version 6 protocol [IPV6]. The document includes the IPv6 addressing
- model, text representations of IPv6 addresses, definition of IPv6
- unicast addresses, anycast addresses, and multicast addresses, and an
- IPv6 node's required addresses.
-
-Table of Contents
-
- 1. Introduction.................................................2
- 2. IPv6 Addressing..............................................2
- 2.1 Addressing Model.........................................3
- 2.2 Text Representation of Addresses.........................3
- 2.3 Text Representation of Address Prefixes..................5
- 2.4 Address Type Representation..............................6
- 2.5 Unicast Addresses........................................7
- 2.5.1 Interface Identifiers................................8
- 2.5.2 The Unspecified Address..............................9
- 2.5.3 The Loopback Address.................................9
- 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10
- 2.5.5 NSAP Addresses......................................10
- 2.5.6 IPX Addresses.......................................10
- 2.5.7 Aggregatable Global Unicast Addresses...............11
- 2.5.8 Local-use IPv6 Unicast Addresses....................11
- 2.6 Anycast Addresses.......................................12
- 2.6.1 Required Anycast Address............................13
- 2.7 Multicast Addresses.....................................14
-
-
-
-Hinden & Deering Standards Track [Page 1]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- 2.7.1 Pre-Defined Multicast Addresses.....................15
- 2.7.2 Assignment of New IPv6 Multicast Addresses..........17
- 2.8 A Node's Required Addresses.............................17
- 3. Security Considerations.....................................18
- APPENDIX A: Creating EUI-64 based Interface Identifiers........19
- APPENDIX B: ABNF Description of Text Representations...........22
- APPENDIX C: CHANGES FROM RFC-1884..............................23
- REFERENCES.....................................................24
- AUTHORS' ADDRESSES.............................................25
- FULL COPYRIGHT STATEMENT.......................................26
-
-
-1.0 INTRODUCTION
-
- This specification defines the addressing architecture of the IP
- Version 6 protocol. It includes a detailed description of the
- currently defined address formats for IPv6 [IPV6].
-
- The authors would like to acknowledge the contributions of Paul
- Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
- Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
- Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
- Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
- and Sue Thomson.
-
- 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.0 IPv6 ADDRESSING
-
- IPv6 addresses are 128-bit identifiers for interfaces and sets of
- interfaces. There are three types of addresses:
-
- Unicast: An identifier for a single interface. A packet sent to
- a unicast address is delivered to the interface
- identified by that address.
-
- Anycast: An identifier for a set of interfaces (typically
- belonging to different nodes). A packet sent to an
- anycast address is delivered to one of the interfaces
- identified by that address (the "nearest" one, according
- to the routing protocols' measure of distance).
-
- Multicast: An identifier for a set of interfaces (typically
- belonging to different nodes). A packet sent to a
- multicast address is delivered to all interfaces
- identified by that address.
-
-
-
-Hinden & Deering Standards Track [Page 2]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- There are no broadcast addresses in IPv6, their function being
- superseded by multicast addresses.
-
- In this document, fields in addresses are given a specific name, for
- example "subscriber". When this name is used with the term "ID" for
- identifier after the name (e.g., "subscriber ID"), it refers to the
- contents of the named field. When it is used with the term "prefix"
- (e.g. "subscriber prefix") it refers to all of the address up to and
- including this field.
-
- In IPv6, all zeros and all ones are legal values for any field,
- unless specifically excluded. Specifically, prefixes may contain
- zero-valued fields or end in zeros.
-
-2.1 Addressing Model
-
- IPv6 addresses of all types are assigned to interfaces, not nodes.
- An IPv6 unicast address refers to a single interface. Since each
- interface belongs to a single node, any of that node's interfaces'
- unicast addresses may be used as an identifier for the node.
-
- All interfaces are required to have at least one link-local unicast
- address (see section 2.8 for additional required addresses). A
- single interface may also be assigned multiple IPv6 addresses of any
- type (unicast, anycast, and multicast) or scope. Unicast addresses
- with scope greater than link-scope are not needed for interfaces that
- are not used as the origin or destination of any IPv6 packets to or
- from non-neighbors. This is sometimes convenient for point-to-point
- interfaces. There is one exception to this addressing model:
-
- An unicast address or a set of unicast addresses may be assigned to
- multiple physical interfaces if the implementation treats the
- multiple physical interfaces as one interface when presenting it to
- the internet layer. This is useful for load-sharing over multiple
- physical interfaces.
-
- Currently IPv6 continues the IPv4 model that a subnet prefix is
- associated with one link. Multiple subnet prefixes may be assigned
- to the same link.
-
-2.2 Text Representation of Addresses
-
- There are three conventional forms for representing IPv6 addresses as
- text strings:
-
- 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
- hexadecimal values of the eight 16-bit pieces of the address.
- Examples:
-
-
-
-Hinden & Deering Standards Track [Page 3]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
- 1080:0:0:0:8:800:200C:417A
-
- Note that it is not necessary to write the leading zeros in an
- individual field, but there must be at least one numeral in every
- field (except for the case described in 2.).
-
- 2. Due to some methods of allocating certain styles of IPv6
- addresses, it will be common for addresses to contain long strings
- of zero bits. In order to make writing addresses containing zero
- bits easier a special syntax is available to compress the zeros.
- The use of "::" indicates multiple groups of 16-bits of zeros.
- The "::" can only appear once in an address. The "::" can also be
- used to compress the leading and/or trailing zeros in an address.
-
- For example the following addresses:
-
- 1080:0:0:0:8:800:200C:417A a unicast address
- FF01:0:0:0:0:0:0:101 a multicast address
- 0:0:0:0:0:0:0:1 the loopback address
- 0:0:0:0:0:0:0:0 the unspecified addresses
-
- may be represented as:
-
- 1080::8:800:200C:417A a unicast address
- FF01::101 a multicast address
- ::1 the loopback address
- :: the unspecified addresses
-
- 3. An alternative form that is sometimes more convenient when dealing
- with a mixed environment of IPv4 and IPv6 nodes is
- x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
- the six high-order 16-bit pieces of the address, and the 'd's are
- the decimal values of the four low-order 8-bit pieces of the
- address (standard IPv4 representation). Examples:
-
- 0:0:0:0:0:0:13.1.68.3
-
- 0:0:0:0:0:FFFF:129.144.52.38
-
- or in compressed form:
-
- ::13.1.68.3
-
- ::FFFF:129.144.52.38
-
-
-
-
-
-Hinden & Deering Standards Track [Page 4]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-2.3 Text Representation of Address Prefixes
-
- The text representation of IPv6 address prefixes is similar to the
- way IPv4 addresses prefixes are written in CIDR notation. An IPv6
- address prefix is represented by the notation:
-
- ipv6-address/prefix-length
-
- where
-
- ipv6-address is an IPv6 address in any of the notations listed
- in section 2.2.
-
- prefix-length is a decimal value specifying how many of the
- leftmost contiguous bits of the address comprise
- the prefix.
-
- For example, the following are legal representations of the 60-bit
- prefix 12AB00000000CD3 (hexadecimal):
-
- 12AB:0000:0000:CD30:0000:0000:0000:0000/60
- 12AB::CD30:0:0:0:0/60
- 12AB:0:0:CD30::/60
-
- The following are NOT legal representations of the above prefix:
-
- 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros,
- within any 16-bit chunk of the address
-
- 12AB::CD30/60 address to left of "/" expands to
- 12AB:0000:0000:0000:0000:000:0000:CD30
-
- 12AB::CD3/60 address to left of "/" expands to
- 12AB:0000:0000:0000:0000:000:0000:0CD3
-
- When writing both a node address and a prefix of that node address
- (e.g., the node's subnet prefix), the two can combined as follows:
-
- the node address 12AB:0:0:CD30:123:4567:89AB:CDEF
- and its subnet number 12AB:0:0:CD30::/60
-
- can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 5]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-2.4 Address Type Representation
-
- The specific type of an IPv6 address is indicated by the leading bits
- in the address. The variable-length field comprising these leading
- bits is called the Format Prefix (FP). The initial allocation of
- these prefixes is as follows:
-
- Allocation Prefix Fraction of
- (binary) Address Space
- ----------------------------------- -------- -------------
- Reserved 0000 0000 1/256
- Unassigned 0000 0001 1/256
-
- Reserved for NSAP Allocation 0000 001 1/128
- Reserved for IPX Allocation 0000 010 1/128
-
- Unassigned 0000 011 1/128
- Unassigned 0000 1 1/32
- Unassigned 0001 1/16
-
- Aggregatable Global Unicast Addresses 001 1/8
- Unassigned 010 1/8
- Unassigned 011 1/8
- Unassigned 100 1/8
- Unassigned 101 1/8
- Unassigned 110 1/8
-
- Unassigned 1110 1/16
- Unassigned 1111 0 1/32
- Unassigned 1111 10 1/64
- Unassigned 1111 110 1/128
- Unassigned 1111 1110 0 1/512
-
- Link-Local Unicast Addresses 1111 1110 10 1/1024
- Site-Local Unicast Addresses 1111 1110 11 1/1024
-
- Multicast Addresses 1111 1111 1/256
-
- Notes:
-
- (1) The "unspecified address" (see section 2.5.2), the loopback
- address (see section 2.5.3), and the IPv6 Addresses with
- Embedded IPv4 Addresses (see section 2.5.4), are assigned out
- of the 0000 0000 format prefix space.
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 6]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- (2) The format prefixes 001 through 111, except for Multicast
- Addresses (1111 1111), are all required to have to have 64-bit
- interface identifiers in EUI-64 format. See section 2.5.1 for
- definitions.
-
- This allocation supports the direct allocation of aggregation
- addresses, local use addresses, and multicast addresses. Space is
- reserved for NSAP addresses and IPX addresses. The remainder of the
- address space is unassigned for future use. This can be used for
- expansion of existing use (e.g., additional aggregatable addresses,
- etc.) or new uses (e.g., separate locators and identifiers). Fifteen
- percent of the address space is initially allocated. The remaining
- 85% is reserved for future use.
-
- Unicast addresses are distinguished from multicast addresses by the
- value of the high-order octet of the addresses: a value of FF
- (11111111) identifies an address as a multicast address; any other
- value identifies an address as a unicast address. Anycast addresses
- are taken from the unicast address space, and are not syntactically
- distinguishable from unicast addresses.
-
-2.5 Unicast Addresses
-
- IPv6 unicast addresses are aggregatable with contiguous bit-wise
- masks similar to IPv4 addresses under Class-less Interdomain Routing
- [CIDR].
-
- There are several forms of unicast address assignment in IPv6,
- including the global aggregatable global unicast address, the NSAP
- address, the IPX hierarchical address, the site-local address, the
- link-local address, and the IPv4-capable host address. Additional
- address types can be defined in the future.
-
- IPv6 nodes may have considerable or little knowledge of the internal
- structure of the IPv6 address, depending on the role the node plays
- (for instance, host versus router). At a minimum, a node may
- consider that unicast addresses (including its own) have no internal
- structure:
-
- | 128 bits |
- +-----------------------------------------------------------------+
- | node address |
- +-----------------------------------------------------------------+
-
- A slightly sophisticated host (but still rather simple) may
- additionally be aware of subnet prefix(es) for the link(s) it is
- attached to, where different addresses may have different values for
- n:
-
-
-
-Hinden & Deering Standards Track [Page 7]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- | n bits | 128-n bits |
- +------------------------------------------------+----------------+
- | subnet prefix | interface ID |
- +------------------------------------------------+----------------+
-
- Still more sophisticated hosts may be aware of other hierarchical
- boundaries in the unicast address. Though a very simple router may
- have no knowledge of the internal structure of IPv6 unicast
- addresses, routers will more generally have knowledge of one or more
- of the hierarchical boundaries for the operation of routing
- protocols. The known boundaries will differ from router to router,
- depending on what positions the router holds in the routing
- hierarchy.
-
-2.5.1 Interface Identifiers
-
- Interface identifiers in IPv6 unicast addresses are used to identify
- interfaces on a link. They are required to be unique on that link.
- They may also be unique over a broader scope. In many cases an
- interface's identifier will be the same as that interface's link-
- layer address. The same interface identifier may be used on multiple
- interfaces on a single node.
-
- Note that the use of the same interface identifier on multiple
- interfaces of a single node does not affect the interface
- identifier's global uniqueness or each IPv6 addresses global
- uniqueness created using that interface identifier.
-
- In a number of the format prefixes (see section 2.4) Interface IDs
- are required to be 64 bits long and to be constructed in IEEE EUI-64
- format [EUI64]. EUI-64 based Interface identifiers may have global
- scope when a global token is available (e.g., IEEE 48bit MAC) or may
- have local scope where a global token is not available (e.g., serial
- links, tunnel end-points, etc.). It is required that the "u" bit
- (universal/local bit in IEEE EUI-64 terminology) be inverted when
- forming the interface identifier from the EUI-64. The "u" bit is set
- to one (1) to indicate global scope, and it is set to zero (0) to
- indicate local scope. The first three octets in binary of an EUI-64
- identifier are as follows:
-
- 0 0 0 1 1 2
- |0 7 8 5 6 3|
- +----+----+----+----+----+----+
- |cccc|ccug|cccc|cccc|cccc|cccc|
- +----+----+----+----+----+----+
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 8]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- written in Internet standard bit-order , where "u" is the
- universal/local bit, "g" is the individual/group bit, and "c" are the
- bits of the company_id. Appendix A: "Creating EUI-64 based Interface
- Identifiers" provides examples on the creation of different EUI-64
- based interface identifiers.
-
- The motivation for inverting the "u" bit when forming the interface
- identifier is to make it easy for system administrators to hand
- configure local scope identifiers when hardware tokens are not
- available. This is expected to be case for serial links, tunnel end-
- points, etc. The alternative would have been for these to be of the
- form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
- ::2, etc.
-
- The use of the universal/local bit in the IEEE EUI-64 identifier is
- to allow development of future technology that can take advantage of
- interface identifiers with global scope.
-
- The details of forming interface identifiers are defined in the
- appropriate "IPv6 over <link>" specification such as "IPv6 over
- Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-2.5.2 The Unspecified Address
-
- The address 0:0:0:0:0:0:0:0 is called the unspecified address. It
- must never be assigned to any node. It indicates the absence of an
- address. One example of its use is in the Source Address field of
- any IPv6 packets sent by an initializing host before it has learned
- its own address.
-
- The unspecified address must not be used as the destination address
- of IPv6 packets or in IPv6 Routing Headers.
-
-2.5.3 The Loopback Address
-
- The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
- It may be used by a node to send an IPv6 packet to itself. It may
- never be assigned to any physical interface. It may be thought of as
- being associated with a virtual interface (e.g., the loopback
- interface).
-
- The loopback address must not be used as the source address in IPv6
- packets that are sent outside of a single node. An IPv6 packet with
- a destination address of loopback must never be sent outside of a
- single node and must never be forwarded by an IPv6 router.
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 9]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-2.5.4 IPv6 Addresses with Embedded IPv4 Addresses
-
- The IPv6 transition mechanisms [TRAN] include a technique for hosts
- and routers to dynamically tunnel IPv6 packets over IPv4 routing
- infrastructure. IPv6 nodes that utilize this technique are assigned
- special IPv6 unicast addresses that carry an IPv4 address in the low-
- order 32-bits. This type of address is termed an "IPv4-compatible
- IPv6 address" and has the format:
-
- | 80 bits | 16 | 32 bits |
- +--------------------------------------+--------------------------+
- |0000..............................0000|0000| IPv4 address |
- +--------------------------------------+----+---------------------+
-
- A second type of IPv6 address which holds an embedded IPv4 address is
- also defined. This address is used to represent the addresses of
- IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
- This type of address is termed an "IPv4-mapped IPv6 address" and has
- the format:
-
- | 80 bits | 16 | 32 bits |
- +--------------------------------------+--------------------------+
- |0000..............................0000|FFFF| IPv4 address |
- +--------------------------------------+----+---------------------+
-
-2.5.5 NSAP Addresses
-
- This mapping of NSAP address into IPv6 addresses is defined in
- [NSAP]. This document recommends that network implementors who have
- planned or deployed an OSI NSAP addressing plan, and who wish to
- deploy or transition to IPv6, should redesign a native IPv6
- addressing plan to meet their needs. However, it also defines a set
- of mechanisms for the support of OSI NSAP addressing in an IPv6
- network. These mechanisms are the ones that must be used if such
- support is required. This document also defines a mapping of IPv6
- addresses within the OSI address format, should this be required.
-
-2.5.6 IPX Addresses
-
- This mapping of IPX address into IPv6 addresses is as follows:
-
- | 7 | 121 bits |
- +-------+---------------------------------------------------------+
- |0000010| to be defined |
- +-------+---------------------------------------------------------+
-
- The draft definition, motivation, and usage are under study.
-
-
-
-
-Hinden & Deering Standards Track [Page 10]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-2.5.7 Aggregatable Global Unicast Addresses
-
- The global aggregatable global unicast address is defined in [AGGR].
- This address format is designed to support both the current provider
- based aggregation and a new type of aggregation called exchanges.
- The combination will allow efficient routing aggregation for both
- sites which connect directly to providers and who connect to
- exchanges. Sites will have the choice to connect to either type of
- aggregation point.
-
- The IPv6 aggregatable global unicast address format is as follows:
-
- | 3| 13 | 8 | 24 | 16 | 64 bits |
- +--+-----+---+--------+--------+--------------------------------+
- |FP| TLA |RES| NLA | SLA | Interface ID |
- | | ID | | ID | ID | |
- +--+-----+---+--------+--------+--------------------------------+
-
- Where
-
- 001 Format Prefix (3 bit) for Aggregatable Global
- Unicast Addresses
- 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 contents, field sizes, and assignment rules are defined in
- [AGGR].
-
-2.5.8 Local-Use IPv6 Unicast Addresses
-
- There are two types of local-use unicast addresses defined. These
- are Link-Local and Site-Local. The Link-Local is for use on a single
- link and the Site-Local is for use in a single site. Link-Local
- addresses have the following format:
-
- | 10 |
- | bits | 54 bits | 64 bits |
- +----------+-------------------------+----------------------------+
- |1111111010| 0 | interface ID |
- +----------+-------------------------+----------------------------+
-
- Link-Local addresses are designed to be used for addressing on a
- single link for purposes such as auto-address configuration, neighbor
- discovery, or when no routers are present.
-
-
-
-
-Hinden & Deering Standards Track [Page 11]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- Routers must not forward any packets with link-local source or
- destination addresses to other links.
-
- Site-Local addresses have the following format:
-
- | 10 |
- | bits | 38 bits | 16 bits | 64 bits |
- +----------+-------------+-----------+----------------------------+
- |1111111011| 0 | subnet ID | interface ID |
- +----------+-------------+-----------+----------------------------+
-
- Site-Local addresses are designed to be used for addressing inside of
- a site without the need for a global prefix.
-
- Routers must not forward any packets with site-local source or
- destination addresses outside of the site.
-
-2.6 Anycast Addresses
-
- An IPv6 anycast address is an address that is assigned to more than
- one interface (typically belonging to different nodes), with the
- property that a packet sent to an anycast address is routed to the
- "nearest" interface having that address, according to the routing
- protocols' measure of distance.
-
- Anycast addresses are allocated from the unicast address space, using
- any of the defined unicast address formats. Thus, anycast addresses
- are syntactically indistinguishable from unicast addresses. When a
- unicast address is assigned to more than one interface, thus turning
- it into an anycast address, the nodes to which the address is
- assigned must be explicitly configured to know that it is an anycast
- address.
-
- For any assigned anycast address, there is a longest address prefix P
- that identifies the topological region in which all interfaces
- belonging to that anycast address reside. Within the region
- identified by P, each member of the anycast set must be advertised as
- a separate entry in the routing system (commonly referred to as a
- "host route"); outside the region identified by P, the anycast
- address may be aggregated into the routing advertisement for prefix
- P.
-
- Note that in, the worst case, the prefix P of an anycast set may be
- the null prefix, i.e., the members of the set may have no topological
- locality. In that case, the anycast address must be advertised as a
- separate routing entry throughout the entire internet, which presents
-
-
-
-
-
-Hinden & Deering Standards Track [Page 12]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- a severe scaling limit on how many such "global" anycast sets may be
- supported. Therefore, it is expected that support for global anycast
- sets may be unavailable or very restricted.
-
- One expected use of anycast addresses is to identify the set of
- routers belonging to an organization providing internet service.
- Such addresses could be used as intermediate addresses in an IPv6
- Routing header, to cause a packet to be delivered via a particular
- aggregation or sequence of aggregations. Some other possible uses
- are to identify the set of routers attached to a particular subnet,
- or the set of routers providing entry into a particular routing
- domain.
-
- There is little experience with widespread, arbitrary use of internet
- anycast addresses, and some known complications and hazards when
- using them in their full generality [ANYCST]. Until more experience
- has been gained and solutions agreed upon for those problems, the
- following restrictions are imposed on IPv6 anycast addresses:
-
- o An anycast address must not be used as the source address of an
- IPv6 packet.
-
- o An anycast address must not be assigned to an IPv6 host, that
- is, it may be assigned to an IPv6 router only.
-
-2.6.1 Required Anycast Address
-
- The Subnet-Router anycast address is predefined. Its format is as
- follows:
-
- | n bits | 128-n bits |
- +------------------------------------------------+----------------+
- | subnet prefix | 00000000000000 |
- +------------------------------------------------+----------------+
-
- The "subnet prefix" in an anycast address is the prefix which
- identifies a specific link. This anycast address is syntactically
- the same as a unicast address for an interface on the link with the
- interface identifier set to zero.
-
- Packets sent to the Subnet-Router anycast address will be delivered
- to one router on the subnet. All routers are required to support the
- Subnet-Router anycast addresses for the subnets which they have
- interfaces.
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 13]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- The subnet-router anycast address is intended to be used for
- applications where a node needs to communicate with one of a set of
- routers on a remote subnet. For example when a mobile host needs to
- communicate with one of the mobile agents on its "home" subnet.
-
-2.7 Multicast Addresses
-
- An IPv6 multicast address is an identifier for a group of nodes. A
- node may belong to any number of multicast groups. Multicast
- addresses have the following format:
-
- | 8 | 4 | 4 | 112 bits |
- +------ -+----+----+---------------------------------------------+
- |11111111|flgs|scop| group ID |
- +--------+----+----+---------------------------------------------+
-
- 11111111 at the start of the address identifies the address as
- being a multicast address.
-
- +-+-+-+-+
- flgs is a set of 4 flags: |0|0|0|T|
- +-+-+-+-+
-
- The high-order 3 flags are reserved, and must be initialized to
- 0.
-
- T = 0 indicates a permanently-assigned ("well-known") multicast
- address, assigned by the global internet numbering authority.
-
- T = 1 indicates a non-permanently-assigned ("transient")
- multicast address.
-
- scop is a 4-bit multicast scope value used to limit the scope of
- the multicast group. The values are:
-
- 0 reserved
- 1 node-local scope
- 2 link-local scope
- 3 (unassigned)
- 4 (unassigned)
- 5 site-local scope
- 6 (unassigned)
- 7 (unassigned)
- 8 organization-local scope
- 9 (unassigned)
- A (unassigned)
- B (unassigned)
- C (unassigned)
-
-
-
-Hinden & Deering Standards Track [Page 14]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- D (unassigned)
- E global scope
- F reserved
-
- group ID identifies the multicast group, either permanent or
- transient, within the given scope.
-
- The "meaning" of a permanently-assigned multicast address is
- independent of the scope value. For example, if the "NTP servers
- group" is assigned a permanent multicast address with a group ID of
- 101 (hex), then:
-
- FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as the
- sender.
-
- FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
- sender.
-
- FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as the
- sender.
-
- FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
-
- Non-permanently-assigned multicast addresses are meaningful only
- within a given scope. For example, a group identified by the non-
- permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
- site bears no relationship to a group using the same address at a
- different site, nor to a non-permanent group using the same group ID
- with different scope, nor to a permanent group with the same group
- ID.
-
- Multicast addresses must not be used as source addresses in IPv6
- packets or appear in any routing header.
-
-2.7.1 Pre-Defined Multicast Addresses
-
- The following well-known multicast addresses are pre-defined:
-
- Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0
- FF01:0:0:0:0:0:0:0
- FF02:0:0:0:0:0:0:0
- FF03:0:0:0:0:0:0:0
- FF04:0:0:0:0:0:0:0
- FF05:0:0:0:0:0:0:0
- FF06:0:0:0:0:0:0:0
- FF07:0:0:0:0:0:0:0
- FF08:0:0:0:0:0:0:0
- FF09:0:0:0:0:0:0:0
-
-
-
-Hinden & Deering Standards Track [Page 15]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- FF0A:0:0:0:0:0:0:0
- FF0B:0:0:0:0:0:0:0
- FF0C:0:0:0:0:0:0:0
- FF0D:0:0:0:0:0:0:0
- FF0E:0:0:0:0:0:0:0
- FF0F:0:0:0:0:0:0:0
-
- The above multicast addresses are reserved and shall never be
- assigned to any multicast group.
-
- All Nodes Addresses: FF01:0:0:0:0:0:0:1
- FF02:0:0:0:0:0:0:1
-
- The above multicast addresses identify the group of all IPv6 nodes,
- within scope 1 (node-local) or 2 (link-local).
-
- All Routers Addresses: FF01:0:0:0:0:0:0:2
- FF02:0:0:0:0:0:0:2
- FF05:0:0:0:0:0:0:2
-
- The above multicast addresses identify the group of all IPv6 routers,
- within scope 1 (node-local), 2 (link-local), or 5 (site-local).
-
- Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX
-
- The above multicast address is computed as a function of a node's
- unicast and anycast addresses. The solicited-node multicast address
- is formed by taking the low-order 24 bits of the address (unicast or
- anycast) and appending those bits to the prefix
- FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
- range
-
- FF02:0:0:0:0:1:FF00:0000
-
- to
-
- FF02:0:0:0:0:1:FFFF:FFFF
-
- For example, the solicited node multicast address corresponding to
- the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6
- addresses that differ only in the high-order bits, e.g. due to
- multiple high-order prefixes associated with different aggregations,
- will map to the same solicited-node address thereby reducing the
- number of multicast addresses a node must join.
-
- A node is required to compute and join the associated Solicited-Node
- multicast addresses for every unicast and anycast address it is
- assigned.
-
-
-
-Hinden & Deering Standards Track [Page 16]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-2.7.2 Assignment of New IPv6 Multicast Addresses
-
- The current approach [ETHER] to map IPv6 multicast addresses into
- IEEE 802 MAC addresses takes the low order 32 bits of the IPv6
- multicast address and uses it to create a MAC address. Note that
- Token Ring networks are handled differently. This is defined in
- [TOKEN]. Group ID's less than or equal to 32 bits will generate
- unique MAC addresses. Due to this new IPv6 multicast addresses
- should be assigned so that the group identifier is always in the low
- order 32 bits as shown in the following:
-
- | 8 | 4 | 4 | 80 bits | 32 bits |
- +------ -+----+----+---------------------------+-----------------+
- |11111111|flgs|scop| reserved must be zero | group ID |
- +--------+----+----+---------------------------+-----------------+
-
- While this limits the number of permanent IPv6 multicast groups to
- 2^32 this is unlikely to be a limitation in the future. If it
- becomes necessary to exceed this limit in the future multicast will
- still work but the processing will be sightly slower.
-
- Additional IPv6 multicast addresses are defined and registered by the
- IANA [MASGN].
-
-2.8 A Node's Required Addresses
-
- A host is required to recognize the following addresses as
- identifying itself:
-
- o Its Link-Local Address for each interface
- o Assigned Unicast Addresses
- o Loopback Address
- o All-Nodes Multicast Addresses
- o Solicited-Node Multicast Address for each of its assigned
- unicast and anycast addresses
- o Multicast Addresses of all other groups to which the host
- belongs.
-
- A router is required to recognize all addresses that a host is
- required to recognize, plus the following addresses as identifying
- itself:
-
- o The Subnet-Router anycast addresses for the interfaces it is
- configured to act as a router on.
- o All other Anycast addresses with which the router has been
- configured.
- o All-Routers Multicast Addresses
-
-
-
-
-Hinden & Deering Standards Track [Page 17]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- o Multicast Addresses of all other groups to which the router
- belongs.
-
- The only address prefixes which should be predefined in an
- implementation are the:
-
- o Unspecified Address
- o Loopback Address
- o Multicast Prefix (FF)
- o Local-Use Prefixes (Link-Local and Site-Local)
- o Pre-Defined Multicast Addresses
- o IPv4-Compatible Prefixes
-
- Implementations should assume all other addresses are unicast unless
- specifically configured (e.g., anycast addresses).
-
-3. Security Considerations
-
- IPv6 addressing documents do not have any direct impact on Internet
- infrastructure security. Authentication of IPv6 packets is defined
- in [AUTH].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 18]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-APPENDIX A : Creating EUI-64 based Interface Identifiers
---------------------------------------------------------
-
- Depending on the characteristics of a specific link or node there are
- a number of approaches for creating EUI-64 based interface
- identifiers. This appendix describes some of these approaches.
-
-Links or Nodes with EUI-64 Identifiers
-
- The only change needed to transform an EUI-64 identifier to an
- interface identifier is to invert the "u" (universal/local) bit. For
- example, a globally unique EUI-64 identifier of the form:
-
- |0 1|1 3|3 4|4 6|
- |0 5|6 1|2 7|8 3|
- +----------------+----------------+----------------+----------------+
- |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
- +----------------+----------------+----------------+----------------+
-
- where "c" are the bits of the assigned company_id, "0" is the value
- of the universal/local bit to indicate global scope, "g" is
- individual/group bit, and "m" are the bits of the manufacturer-
- selected extension identifier. The IPv6 interface identifier would
- be of the form:
-
- |0 1|1 3|3 4|4 6|
- |0 5|6 1|2 7|8 3|
- +----------------+----------------+----------------+----------------+
- |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
- +----------------+----------------+----------------+----------------+
-
- The only change is inverting the value of the universal/local bit.
-
-Links or Nodes with IEEE 802 48 bit MAC's
-
- [EUI64] defines a method to create a EUI-64 identifier from an IEEE
- 48bit MAC identifier. This is to insert two octets, with hexadecimal
- values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the
- company_id and vendor supplied id). For example the 48 bit MAC with
- global scope:
-
- |0 1|1 3|3 4|
- |0 5|6 1|2 7|
- +----------------+----------------+----------------+
- |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
- +----------------+----------------+----------------+
-
-
-
-
-
-Hinden & Deering Standards Track [Page 19]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- where "c" are the bits of the assigned company_id, "0" is the value
- of the universal/local bit to indicate global scope, "g" is
- individual/group bit, and "m" are the bits of the manufacturer-
- selected extension identifier. The interface identifier would be of
- the form:
-
- |0 1|1 3|3 4|4 6|
- |0 5|6 1|2 7|8 3|
- +----------------+----------------+----------------+----------------+
- |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
- +----------------+----------------+----------------+----------------+
-
- When IEEE 802 48bit MAC addresses are available (on an interface or a
- node), an implementation should use them to create interface
- identifiers due to their availability and uniqueness properties.
-
-Links with Non-Global Identifiers
-
- There are a number of types of links that, while multi-access, do not
- have globally unique link identifiers. Examples include LocalTalk
- and Arcnet. The method to create an EUI-64 formatted identifier is
- to take the link identifier (e.g., the LocalTalk 8 bit node
- identifier) and zero fill it to the left. For example a LocalTalk 8
- bit node identifier of hexadecimal value 0x4F results in the
- following interface identifier:
-
- |0 1|1 3|3 4|4 6|
- |0 5|6 1|2 7|8 3|
- +----------------+----------------+----------------+----------------+
- |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
- +----------------+----------------+----------------+----------------+
-
- Note that this results in the universal/local bit set to "0" to
- indicate local scope.
-
-Links without Identifiers
-
- There are a number of links that do not have any type of built-in
- identifier. The most common of these are serial links and configured
- tunnels. Interface identifiers must be chosen that are unique for
- the link.
-
- When no built-in identifier is available on a link the preferred
- approach is to use a global interface identifier from another
- interface or one which is assigned to the node itself. To use this
- approach no other interface connecting the same node to the same link
- may use the same identifier.
-
-
-
-
-Hinden & Deering Standards Track [Page 20]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
- If there is no global interface identifier available for use on the
- link the implementation needs to create a local scope interface
- identifier. The only requirement is that it be unique on the link.
- There are many possible approaches to select a link-unique interface
- identifier. They include:
-
- Manual Configuration
- Generated Random Number
- Node Serial Number (or other node-specific token)
-
- The link-unique interface identifier should be generated in a manner
- that it does not change after a reboot of a node or if interfaces are
- added or deleted from the node.
-
- The selection of the appropriate algorithm is link and implementation
- dependent. The details on forming interface identifiers are defined
- in the appropriate "IPv6 over <link>" specification. It is strongly
- recommended that a collision detection algorithm be implemented as
- part of any automatic algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 21]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-APPENDIX B: ABNF Description of Text Representations
-----------------------------------------------------
-
- This appendix defines the text representation of IPv6 addresses and
- prefixes in Augmented BNF [ABNF] for reference purposes.
-
- IPv6address = hexpart [ ":" IPv4address ]
- IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
-
- IPv6prefix = hexpart "/" 1*2DIGIT
-
- hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
- hexseq = hex4 *( ":" hex4)
- hex4 = 1*4HEXDIG
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 22]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-APPENDIX C: CHANGES FROM RFC-1884
----------------------------------
-
- The following changes were made from RFC-1884 "IP Version 6
- Addressing Architecture":
-
- - Added an appendix providing a ABNF description of text
- representations.
- - Clarification that link unique identifiers not change after
- reboot or other interface reconfigurations.
- - Clarification of Address Model based on comments.
- - Changed aggregation format terminology to be consistent with
- aggregation draft.
- - Added text to allow interface identifier to be used on more than
- one interface on same node.
- - Added rules for defining new multicast addresses.
- - Added appendix describing procedures for creating EUI-64 based
- interface ID's.
- - Added notation for defining IPv6 prefixes.
- - Changed solicited node multicast definition to use a longer
- prefix.
- - Added site scope all routers multicast address.
- - Defined Aggregatable Global Unicast Addresses to use "001" Format
- Prefix.
- - Changed "010" (Provider-Based Unicast) and "100" (Reserved for
- Geographic) Format Prefixes to Unassigned.
- - Added section on Interface ID definition for unicast addresses.
- Requires use of EUI-64 in range of format prefixes and rules for
- setting global/local scope bit in EUI-64.
- - Updated NSAP text to reflect working in RFC1888.
- - Removed protocol specific IPv6 multicast addresses (e.g., DHCP)
- and referenced the IANA definitions.
- - Removed section "Unicast Address Example". Had become OBE.
- - Added new and updated references.
- - Minor text clarifications and improvements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 23]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-REFERENCES
-
- [ABNF] Crocker, D., and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 2234, November 1997.
-
- [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An
- Aggregatable Global Unicast Address Format", RFC 2374, July
- 1998.
-
- [AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August
- 1995.
-
- [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host
- Anycasting Service", RFC 1546, November 1993.
-
- [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
- Inter-Domain Routing (CIDR): An Address Assignment and
- Aggregation Strategy", RFC 1519, September 1993.
-
- [ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet
- Networks", Work in Progress.
-
- [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
- Registration Authority",
- http://standards.ieee.org/db/oui/tutorials/EUI64.html,
- March 1997.
-
- [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
- Networks", Work in Progress.
-
- [IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol,
- Version 6 (IPv6) Specification", RFC 1883, December 1995.
-
- [MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address
- Assignments", RFC 2375, July 1998.
-
- [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
- and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring
- Networks", Work in Progress.
-
- [TRAN] Gilligan, R., and E. Nordmark, "Transition Mechanisms for
- IPv6 Hosts and Routers", RFC 1993, April 1996.
-
-
-
-
-Hinden & Deering Standards Track [Page 24]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-AUTHORS' ADDRESSES
-
- Robert M. Hinden
- Nokia
- 232 Java Drive
- Sunnyvale, CA 94089
- USA
-
- Phone: +1 408 990-2004
- Fax: +1 408 743-5677
- EMail: hinden@iprg.nokia.com
-
-
- Stephen E. Deering
- Cisco Systems, Inc.
- 170 West Tasman Drive
- San Jose, CA 95134-1706
- USA
-
- Phone: +1 408 527-8213
- Fax: +1 408 527-8254
- EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 25]
-
-RFC 2373 IPv6 Addressing Architecture July 1998
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2374.txt b/contrib/bind9/doc/rfc/rfc2374.txt
deleted file mode 100644
index e3c7f0de490ae..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2374.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Hinden
-Request for Comments: 2374 Nokia
-Obsoletes: 2073 M. O'Dell
-Category: Standards Track UUNET
- S. Deering
- Cisco
- July 1998
-
-
- An IPv6 Aggregatable Global Unicast Address Format
-
-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 (1998). All Rights Reserved.
-
-1.0 Introduction
-
- This document defines an IPv6 aggregatable global unicast address
- format for use in the Internet. The address format defined in this
- document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
- Addressing Architecture" [ARCH]. It is designed to facilitate
- scalable Internet routing.
-
- This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
- Address Format". RFC 2073 will become historic. The Aggregatable
- Global Unicast Address Format is an improvement over RFC 2073 in a
- number of areas. The major changes include removal of the registry
- bits because they are not needed for route aggregation, support of
- EUI-64 based interface identifiers, support of provider and exchange
- based aggregation, separation of public and site topology, and new
- aggregation based 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].
-
-
-
-
-
-
-
-
-Hinden, et. al. Standards Track [Page 1]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
-2.0 Overview of the IPv6 Address
-
- IPv6 addresses are 128-bit identifiers for interfaces and sets of
- interfaces. There are three types of addresses: Unicast, Anycast,
- and Multicast. This document defines a specific type of Unicast
- address.
-
- In this document, fields in addresses are given specific names, for
- example "subnet". When this name is used with the term "ID" (for
- "identifier") after the name (e.g., "subnet ID"), it refers to the
- contents of the named field. When it is used with the term "prefix"
- (e.g. "subnet prefix") it refers to all of the addressing bits to
- the left of and including this field.
-
- IPv6 unicast addresses are designed assuming that the Internet
- routing system makes forwarding decisions based on a "longest prefix
- match" algorithm on arbitrary bit boundaries and does not have any
- knowledge of the internal structure of IPv6 addresses. The structure
- in IPv6 addresses is for assignment and allocation. The only
- exception to this is the distinction made between unicast and
- multicast addresses.
-
- The specific type of an IPv6 address is indicated by the leading bits
- in the address. The variable-length field comprising these leading
- bits is called the Format Prefix (FP).
-
- This document defines an address format for the 001 (binary) Format
- Prefix for Aggregatable Global Unicast addresses. The same address
- format could be used for other Format Prefixes, as long as these
- Format Prefixes also identify IPv6 unicast addresses. Only the "001"
- Format Prefix is defined here.
-
-3.0 IPv6 Aggregatable Global Unicast Address Format
-
- This document defines an address format for the IPv6 aggregatable
- global unicast address assignment. The authors believe that this
- address format will be widely used for IPv6 nodes connected to the
- Internet. This address format is designed to support both the
- current provider-based aggregation and a new type of exchange-based
- aggregation. The combination will allow efficient routing
- aggregation for sites that connect directly to providers and for
- sites that connect to exchanges. Sites will have the choice to
- connect to either type of aggregation entity.
-
-
-
-
-
-
-
-
-Hinden, et. al. Standards Track [Page 2]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
- While this address format is designed to support exchange-based
- aggregation (in addition to current provider-based aggregation) it is
- not dependent on exchanges for it's overall route aggregation
- properties. It will provide efficient route aggregation with only
- provider-based aggregation.
-
- Aggregatable addresses are organized into a three level hierarchy:
-
- - Public Topology
- - Site Topology
- - Interface Identifier
-
- Public topology is the collection of providers and exchanges who
- provide public Internet transit services. Site topology is local to
- a specific site or organization which does not provide public transit
- service to nodes outside of the site. Interface identifiers identify
- interfaces on links.
-
- ______________ ______________
- --+/ \+--------------+/ \+----------
- ( P1 ) +----+ ( P3 ) +----+
- +\______________/ | |----+\______________/+--| |--
- | +--| X1 | +| X2 |
- | ______________ / | |-+ ______________ / | |--
- +/ \+ +-+--+ \ / \+ +----+
- ( P2 ) / \ +( P4 )
- --+\______________/ / \ \______________/
- | / \ | |
- | / | | |
- | / | | |
- _|_ _/_ _|_ _|_ _|_
- / \ / \ / \ / \ / \
- ( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )
- \___/ \___/ \___/ \___/ \___/
- | / \
- _|_ _/_ \ ___
- / \ / \ +-/ \
- ( S.D ) ( S.E ) ( S.F )
- \___/ \___/ \___/
-
- As shown in the figure above, the aggregatable address format is
- designed to support long-haul providers (shown as P1, P2, P3, and
- P4), exchanges (shown as X1 and X2), multiple levels of providers
- (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
- (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
- Organizations who connect to these exchanges will also subscribe
- (directly, indirectly via the exchange, etc.) for long-haul service
- from one or more long-haul providers. Doing so, they will achieve
-
-
-
-Hinden, et. al. Standards Track [Page 3]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
- addressing independence from long-haul transit providers. They will
- be able to change long-haul providers without having to renumber
- their organization. They can also be multihomed via the exchange to
- more than one long-haul provider without having to have address
- prefixes from each long-haul provider. Note that the mechanisms used
- for this type of provider selection and portability are not discussed
- in the document.
-
-3.1 Aggregatable Global Unicast Address Structure
-
- The aggregatable global unicast address format is as follows:
-
- | 3| 13 | 8 | 24 | 16 | 64 bits |
- +--+-----+---+--------+--------+--------------------------------+
- |FP| TLA |RES| NLA | SLA | Interface ID |
- | | ID | | ID | 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 following sections specify each part of the IPv6 Aggregatable
- Global Unicast address format.
-
-3.2 Top-Level Aggregation ID
-
- Top-Level Aggregation Identifiers (TLA ID) are the top level in the
- routing hierarchy. Default-free routers must have a routing table
- entry for every active TLA ID and will probably have additional
- entries providing routing information for the TLA ID in which they
- are located. They may have additional entries in order to optimize
- routing for their specific topology, but the routing topology at all
- levels must be designed to minimize the number of additional entries
- fed into the default free routing tables.
-
-
-
-
-
-
-Hinden, et. al. Standards Track [Page 4]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
- This addressing format supports 8,192 (2^13) TLA ID's. Additional
- TLA ID's may be added by either growing the TLA field to the right
- into the reserved field or by using this format for additional format
- prefixes.
-
- The issues relating to TLA ID assignment are beyond the scope of this
- document. They will be described in a document under preparation.
-
-3.3 Reserved
-
- The Reserved field is reserved for future use and must be set to
- zero.
-
- The Reserved field allows for future growth of the TLA and NLA fields
- as appropriate. See section 4.0 for a discussion.
-
-3.4 Next-Level Aggregation Identifier
-
- Next-Level Aggregation Identifier's are used by organizations
- assigned a TLA ID to create an addressing hierarchy and to identify
- sites. The organization can assign the top part of the NLA ID in a
- manner to create an addressing hierarchy appropriate to its network.
- It can use the remainder of the bits in the field to identify sites
- it wishes to serve. This is shown as follows:
-
- | n | 24-n bits | 16 | 64 bits |
- +-----+--------------------+--------+-----------------+
- |NLA1 | Site ID | SLA ID | Interface ID |
- +-----+--------------------+--------+-----------------+
-
- Each organization assigned a TLA ID receives 24 bits of NLA ID space.
- This NLA ID space allows each organization to provide service to
- approximately as many organizations as the current IPv4 Internet can
- support total networks.
-
- Organizations assigned TLA ID's may also support NLA ID's in their
- own Site ID space. This allows the organization assigned a TLA ID to
- provide service to organizations providing public transit service and
- to organizations who do not provide public transit service. These
- organizations receiving an NLA ID may also choose to use their Site
- ID space to support other NLA ID's. This is shown as follows:
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al. Standards Track [Page 5]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
- | n | 24-n bits | 16 | 64 bits |
- +-----+--------------------+--------+-----------------+
- |NLA1 | Site ID | SLA ID | Interface ID |
- +-----+--------------------+--------+-----------------+
-
- | m | 24-n-m | 16 | 64 bits |
- +-----+--------------+--------+-----------------+
- |NLA2 | Site ID | SLA ID | Interface ID |
- +-----+--------------+--------+-----------------+
-
- | o |24-n-m-o| 16 | 64 bits |
- +-----+--------+--------+-----------------+
- |NLA3 | Site ID| SLA ID | Interface ID |
- +-----+--------+--------+-----------------+
-
- The design of the bit layout of the NLA ID space for a specific TLA
- ID is left to the organization responsible for that TLA ID. Likewise
- the design of the bit layout of the next level NLA ID is the
- responsibility of the previous level NLA ID. It is recommended that
- organizations assigning NLA address space use "slow start" allocation
- procedures similar to [RFC2050].
-
- The design of an NLA ID allocation plan is a tradeoff between routing
- aggregation efficiency and flexibility. Creating hierarchies allows
- for greater amount of aggregation and results in smaller routing
- tables. Flat NLA ID assignment provides for easier allocation and
- attachment flexibility, but results in larger routing tables.
-
-3.5 Site-Level Aggregation Identifier
-
- The SLA ID field is used by an individual organization to create its
- own local addressing hierarchy and to identify subnets. This is
- analogous to subnets in IPv4 except that each organization has a much
- greater number of subnets. The 16 bit SLA ID field support 65,535
- individual subnets.
-
- Organizations may choose to either route their SLA ID "flat" (e.g.,
- not create any logical relationship between the SLA identifiers that
- results in larger routing tables), or to create a two or more level
- hierarchy (that results in smaller routing tables) in the SLA ID
- field. The latter is shown as follows:
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al. Standards Track [Page 6]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
- | n | 16-n | 64 bits |
- +-----+------------+-------------------------------------+
- |SLA1 | Subnet | Interface ID |
- +-----+------------+-------------------------------------+
-
- | m |16-n-m | 64 bits |
- +----+-------+-------------------------------------+
- |SLA2|Subnet | Interface ID |
- +----+-------+-------------------------------------+
-
- The approach chosen for structuring an SLA ID field is the
- responsibility of the individual organization.
-
- The number of subnets supported in this address format should be
- sufficient for all but the largest of organizations. Organizations
- which need additional subnets can arrange with the organization they
- are obtaining Internet service from to obtain additional site
- identifiers and use this to create additional subnets.
-
-3.6 Interface ID
-
- Interface identifiers are used to identify interfaces on a link.
- They are required to be unique on that link. They may also be unique
- over a broader scope. In many cases an interfaces identifier will be
- the same or be based on the interface's link-layer address.
- Interface IDs used in the aggregatable global unicast address format
- are required to be 64 bits long and to be constructed in IEEE EUI-64
- format [EUI-64]. These identifiers may have global scope when a
- global token (e.g., IEEE 48bit MAC) is available or may have local
- scope where a global token is not available (e.g., serial links,
- tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE
- EUI-64 terminology) in the EUI-64 identifier must be set correctly,
- as defined in [ARCH], to indicate global or local scope.
-
- The procedures for creating EUI-64 based Interface Identifiers is
- defined in [ARCH]. The details on forming interface identifiers is
- defined in the appropriate "IPv6 over <link>" specification such as
- "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-4.0 Technical Motivation
-
- The design choices for the size of the fields in the aggregatable
- address format were based on the need to meet a number of technical
- requirements. These are described in the following paragraphs.
-
- The size of the Top-Level Aggregation Identifier is 13 bits. This
- allows for 8,192 TLA ID's. This size was chosen to insure that the
- default-free routing table in top level routers in the Internet is
-
-
-
-Hinden, et. al. Standards Track [Page 7]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
- kept within the limits, with a reasonable margin, of the current
- routing technology. The margin is important because default-free
- routers will also carry a significant number of longer (i.e., more-
- specific) prefixes for optimizing paths internal to a TLA and between
- TLAs.
-
- The important issue is not only the size of the default-free routing
- table, but the complexity of the topology that determines the number
- of copies of the default-free routes that a router must examine while
- computing a forwarding table. Current practice with IPv4 it is
- common to see a prefix announced fifteen times via different paths.
-
- The complexity of Internet topology is very likely to increase in the
- future. It is important that IPv6 default-free routing support
- additional complexity as well as a considerably larger internet.
-
- It should be noted for comparison that at the time of this writing
- (spring, 1998) the IPv4 default-free routing table contains
- approximately 50,000 prefixes. While this shows that it is possible
- to support more routes than 8,192 it is matter of debate if the
- number of prefixes supported today in IPv4 is already too high for
- current routing technology. There are serious issues of route
- stability as well as cases of providers not supporting all top level
- prefixes. The technical requirement was to pick a TLA ID size that
- was below, with a reasonable margin, what was being done with IPv4.
-
- The choice of 13 bits for the TLA field was an engineering
- compromise. Fewer bits would have been too small by not supporting
- enough top level organizations. More bits would have exceeded what
- can be reasonably accommodated, with a reasonable margin, with
- current routing technology in order to deal with the issues described
- in the previous paragraphs.
-
- If in the future, routing technology improves to support a larger
- number of top level routes in the default-free routing tables there
- are two choices on how to increase the number TLA identifiers. The
- first is to expand the TLA ID field into the reserved field. This
- would increase the number of TLA ID's to approximately 2 million.
- The second approach is to allocate another format prefix (FP) for use
- with this address format. Either or a combination of these
- approaches allows the number of TLA ID's to increase significantly.
-
- The size of the Reserved field is 8 bits. This size was chosen to
- allow significant growth of either the TLA ID and/or the NLA ID
- fields.
-
- The size of the Next-Level Aggregation Identifier field is 24 bits.
-
-
-
-
-Hinden, et. al. Standards Track [Page 8]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
- This allows for approximately sixteen million NLA ID's if used in a
- flat manner. Used hierarchically it allows for a complexity roughly
- equivalent to the IPv4 address space (assuming an average network
- size of 254 interfaces). If in the future additional room for
- complexity is needed in the NLA ID, this may be accommodated by
- extending the NLA ID into the Reserved field.
-
- The size of the Site-Level Aggregation Identifier field is 16 bits.
- This supports 65,535 individual subnets per site. The design goal
- for the size of this field was to be sufficient for all but the
- largest of organizations. Organizations which need additional
- subnets can arrange with the organization they are obtaining Internet
- service from to obtain additional site identifiers and use this to
- create additional subnets.
-
- The Site-Level Aggregation Identifier field was given a fixed size in
- order to force the length of all prefixes identifying a particular
- site to be the same length (i.e., 48 bits). This facilitates
- movement of sites in the topology (e.g., changing service providers
- and multi-homing to multiple service providers).
-
- The Interface ID Interface Identifier field is 64 bits. This size
- was chosen to meet the requirement specified in [ARCH] to support
- EUI-64 based Interface Identifiers.
-
-5.0 Acknowledgments
-
- The authors would like to express our thanks to Thomas Narten, Bob
- Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
- Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
- for their review and constructive comments.
-
-6.0 References
-
- [ALLOC] IAB and IESG, "IPv6 Address Allocation Management",
- RFC 1881, December 1995.
-
- [ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
- RFC 2373, July 1998.
-
- [AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August
- 1995.
-
- [AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address
- Autoconfiguration", RFC 1971, August 1996.
-
- [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
- Networks", Work in Progress.
-
-
-
-Hinden, et. al. Standards Track [Page 9]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
- [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
- Registration Authority",
- http://standards.ieee.org/db/oui/tutorials/EUI64.html,
- March 1997.
-
- [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
- Networks", Work in Progress.
-
- [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 1883, December 1995.
-
- [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
- and J. Postel, "Internet Registry IP Allocation
- Guidelines", BCP 12, RFC 1466, November 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-7.0 Security Considerations
-
- IPv6 addressing documents do not have any direct impact on Internet
- infrastructure security. Authentication of IPv6 packets is defined
- in [AUTH].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al. Standards Track [Page 10]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
-8.0 Authors' Addresses
-
- Robert M. Hinden
- Nokia
- 232 Java Drive
- Sunnyvale, CA 94089
- USA
-
- Phone: 1 408 990-2004
- EMail: hinden@iprg.nokia.com
-
-
- Mike O'Dell
- UUNET Technologies, Inc.
- 3060 Williams Drive
- Fairfax, VA 22030
- USA
-
- Phone: 1 703 206-5890
- EMail: mo@uunet.uu.net
-
-
- Stephen E. Deering
- Cisco Systems, Inc.
- 170 West Tasman Drive
- San Jose, CA 95134-1706
- USA
-
- Phone: 1 408 527-8213
- EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al. Standards Track [Page 11]
-
-RFC 2374 IPv6 Global Unicast Address Format July 1998
-
-
-9.0 Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al. Standards Track [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2375.txt b/contrib/bind9/doc/rfc/rfc2375.txt
deleted file mode 100644
index a1fe8b9a40d84..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2375.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Hinden
-Request for Comments: 2375 Ipsilon Networks
-Category: Informational S. Deering
- Cisco
- July 1998
-
-
- IPv6 Multicast Address Assignments
-
-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 (1998). All Rights Reserved.
-
-1.0 Introduction
-
- This document defines the initial assignment of IPv6 multicast
- addresses. It is based on the "IP Version 6 Addressing Architecture"
- [ADDARCH] and current IPv4 multicast address assignment found in
- <ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
- It adapts the IPv4 assignments that are relevant to IPv6 assignments.
- IPv4 assignments that were not relevant were not converted into IPv6
- assignments. Comments are solicited on this conversion.
-
- All other IPv6 multicast addresses are reserved.
-
- Sections 2 and 3 specify reserved and preassigned IPv6 multicast
- addresses.
-
- [ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
-
- 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. Fixed Scope Multicast Addresses
-
- These permanently assigned multicast addresses are valid over a
- specified scope value.
-
-
-
-
-
-
-
-Hinden & Deering Informational [Page 1]
-
-RFC 2375 IPv6 Multicast Address Assignments July 1998
-
-
-2.1 Node-Local Scope
-
- FF01:0:0:0:0:0:0:1 All Nodes Address [ADDARCH]
- FF01:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
-
-2.2 Link-Local Scope
-
- FF02:0:0:0:0:0:0:1 All Nodes Address [ADDARCH]
- FF02:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
- FF02:0:0:0:0:0:0:3 Unassigned [JBP]
- FF02:0:0:0:0:0:0:4 DVMRP Routers [RFC1075,JBP]
- FF02:0:0:0:0:0:0:5 OSPFIGP [RFC2328,Moy]
- FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers [RFC2328,Moy]
- FF02:0:0:0:0:0:0:7 ST Routers [RFC1190,KS14]
- FF02:0:0:0:0:0:0:8 ST Hosts [RFC1190,KS14]
- FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080]
- FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci]
- FF02:0:0:0:0:0:0:B Mobile-Agents [Bill Simpson]
-
- FF02:0:0:0:0:0:0:D All PIM Routers [Farinacci]
- FF02:0:0:0:0:0:0:E RSVP-ENCAPSULATION [Braden]
-
- FF02:0:0:0:0:0:1:1 Link Name [Harrington]
- FF02:0:0:0:0:0:1:2 All-dhcp-agents [Bound,Perkins]
-
- FF02:0:0:0:0:1:FFXX:XXXX Solicited-Node Address [ADDARCH]
-
-2.3 Site-Local Scope
-
- FF05:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
-
- FF05:0:0:0:0:0:1:3 All-dhcp-servers [Bound,Perkins]
- FF05:0:0:0:0:0:1:4 All-dhcp-relays [Bound,Perkins]
- FF05:0:0:0:0:0:1:1000 Service Location [RFC2165]
- -FF05:0:0:0:0:0:1:13FF
-
-3.0 All Scope Multicast Addresses
-
- These permanently assigned multicast addresses are valid over all
- scope ranges. This is shown by an "X" in the scope field of the
- address that means any legal scope value.
-
- Note that, as defined in [ADDARCH], IPv6 multicast addresses which
- are only different in scope represent different groups. Nodes must
- join each group individually.
-
- The IPv6 multicast addresses with variable scope are as follows:
-
-
-
-
-Hinden & Deering Informational [Page 2]
-
-RFC 2375 IPv6 Multicast Address Assignments July 1998
-
-
- FF0X:0:0:0:0:0:0:0 Reserved Multicast Address [ADDARCH]
-
- FF0X:0:0:0:0:0:0:100 VMTP Managers Group [RFC1045,DRC3]
- FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119,DLM1]
- FF0X:0:0:0:0:0:0:102 SGI-Dogfight [AXC]
- FF0X:0:0:0:0:0:0:103 Rwhod [SXD]
- FF0X:0:0:0:0:0:0:104 VNP [DRC3]
- FF0X:0:0:0:0:0:0:105 Artificial Horizons - Aviator [BXF]
- FF0X:0:0:0:0:0:0:106 NSS - Name Service Server [BXS2]
- FF0X:0:0:0:0:0:0:107 AUDIONEWS - Audio News Multicast [MXF2]
- FF0X:0:0:0:0:0:0:108 SUN NIS+ Information Service [CXM3]
- FF0X:0:0:0:0:0:0:109 MTP Multicast Transport Protocol [SXA]
- FF0X:0:0:0:0:0:0:10A IETF-1-LOW-AUDIO [SC3]
- FF0X:0:0:0:0:0:0:10B IETF-1-AUDIO [SC3]
- FF0X:0:0:0:0:0:0:10C IETF-1-VIDEO [SC3]
- FF0X:0:0:0:0:0:0:10D IETF-2-LOW-AUDIO [SC3]
- FF0X:0:0:0:0:0:0:10E IETF-2-AUDIO [SC3]
- FF0X:0:0:0:0:0:0:10F IETF-2-VIDEO [SC3]
-
- FF0X:0:0:0:0:0:0:110 MUSIC-SERVICE [Guido van Rossum]
- FF0X:0:0:0:0:0:0:111 SEANET-TELEMETRY [Andrew Maffei]
- FF0X:0:0:0:0:0:0:112 SEANET-IMAGE [Andrew Maffei]
- FF0X:0:0:0:0:0:0:113 MLOADD [Braden]
- FF0X:0:0:0:0:0:0:114 any private experiment [JBP]
- FF0X:0:0:0:0:0:0:115 DVMRP on MOSPF [Moy]
- FF0X:0:0:0:0:0:0:116 SVRLOC [Veizades]
- FF0X:0:0:0:0:0:0:117 XINGTV <hgxing@aol.com>
- FF0X:0:0:0:0:0:0:118 microsoft-ds <arnoldm@microsoft.com>
- FF0X:0:0:0:0:0:0:119 nbc-pro <bloomer@birch.crd.ge.com>
- FF0X:0:0:0:0:0:0:11A nbc-pfn <bloomer@birch.crd.ge.com>
- FF0X:0:0:0:0:0:0:11B lmsc-calren-1 [Uang]
- FF0X:0:0:0:0:0:0:11C lmsc-calren-2 [Uang]
- FF0X:0:0:0:0:0:0:11D lmsc-calren-3 [Uang]
- FF0X:0:0:0:0:0:0:11E lmsc-calren-4 [Uang]
- FF0X:0:0:0:0:0:0:11F ampr-info [Janssen]
-
- FF0X:0:0:0:0:0:0:120 mtrace [Casner]
- FF0X:0:0:0:0:0:0:121 RSVP-encap-1 [Braden]
- FF0X:0:0:0:0:0:0:122 RSVP-encap-2 [Braden]
- FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Veizades]
- FF0X:0:0:0:0:0:0:124 rln-server [Kean]
- FF0X:0:0:0:0:0:0:125 proshare-mc [Lewis]
- FF0X:0:0:0:0:0:0:126 dantz [Yackle]
- FF0X:0:0:0:0:0:0:127 cisco-rp-announce [Farinacci]
- FF0X:0:0:0:0:0:0:128 cisco-rp-discovery [Farinacci]
- FF0X:0:0:0:0:0:0:129 gatekeeper [Toga]
- FF0X:0:0:0:0:0:0:12A iberiagames [Marocho]
-
-
-
-
-Hinden & Deering Informational [Page 3]
-
-RFC 2375 IPv6 Multicast Address Assignments July 1998
-
-
- FF0X:0:0:0:0:0:0:201 "rwho" Group (BSD) (unofficial) [JBP]
- FF0X:0:0:0:0:0:0:202 SUN RPC PMAPPROC_CALLIT [BXE1]
-
- FF0X:0:0:0:0:0:2:0000
- -FF0X:0:0:0:0:0:2:7FFD Multimedia Conference Calls [SC3]
- FF0X:0:0:0:0:0:2:7FFE SAPv1 Announcements [SC3]
- FF0X:0:0:0:0:0:2:7FFF SAPv0 Announcements (deprecated) [SC3]
- FF0X:0:0:0:0:0:2:8000
- -FF0X:0:0:0:0:0:2:FFFF SAP Dynamic Assignments [SC3]
-
-5.0 References
-
- [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC 1971, August 1996.
-
- [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
- Networks", Work in Progress.
-
- [RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
- Specification", RFC 1045, February 1988.
-
- [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
- Vector Multicast Routing Protocol", RFC 1075, November
- 1988.
-
- [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
- RFC 1112, Stanford University, August 1989.
-
- [RFC1119] Mills, D., "Network Time Protocol (Version 1),
- Specification and Implementation", STD 12, RFC 1119, July
- 1988.
-
- [RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
- Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
-
- [RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
- January 1997.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan
- "Service Location Protocol", RFC 2165 June 1997.
-
- [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
-
-
-
-Hinden & Deering Informational [Page 4]
-
-RFC 2375 IPv6 Multicast Address Assignments July 1998
-
-
-6. People
-
- <arnoldm@microsoft.com>
-
- [AXC] Andrew Cherenson <arc@SGI.COM>
-
- [Braden] Bob Braden, <braden@isi.edu>, April 1996.
-
- [Bob Brenner]
-
- [Bressler] David J. Bressler, <bressler@tss.com>, April 1996.
-
- <bloomer@birch.crd.ge.com>
-
- [Bound] Jim Bound <bound@zk3.dec.com>
-
- [BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com>
-
- [BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET>
-
- [BXS2] Bill Schilit <schilit@parc.xerox.com>
-
- [Casner] Steve Casner, <casner@isi.edu>, January 1995.
-
- [CXM3] Chuck McManis <cmcmanis@sun.com>
-
- [Tim Clark]
-
- [DLM1] David Mills <Mills@HUEY.UDEL.EDU>
-
- [DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU>
-
- [DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM>
-
- [Farinacci] Dino Farinacci, <dino@cisco.com>
-
- [GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM>
-
- [Harrington] Dan Harrington, <dan@lucent.com>, July 1996.
-
- <hgxing@aol.com>
-
- [IANA] IANA <iana@iana.org>
-
- [Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995.
-
- [JBP] Jon Postel <postel@isi.edu>
-
-
-
-
-Hinden & Deering Informational [Page 5]
-
-RFC 2375 IPv6 Multicast Address Assignments July 1998
-
-
- [JXM1] Jim Miner <miner@star.com>
-
- [Kean] Brian Kean, <bkean@dca.com>, August 1995.
-
- [KS14] <mystery contact>
-
- [Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996.
-
- [Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995.
-
- [Malamud] Carl Malamud, <carl@radio.com>, January 1996.
-
- [Andrew Maffei]
-
- [Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996.
-
- [Moy] John Moy <jmoy@casc.com>
-
- [MXF2] Martin Forssen <maf@dtek.chalmers.se>
-
- [Perkins] Charlie Perkins, <cperkins@corp.sun.com>
-
- [Guido van Rossum]
-
- [SC3] Steve Casner <casner@isi.edu>
-
- [Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994.
-
- [Joel Snyder]
-
- [SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM>
-
- [SXD] Steve Deering <deering@PARC.XEROX.COM>
-
- [tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995.
-
- [Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996.
-
- [Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994.
-
- [Veizades] John Veizades, <veizades@tgv.com>, May 1995.
-
- [Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996.
-
-
-
-
-
-
-
-
-Hinden & Deering Informational [Page 6]
-
-RFC 2375 IPv6 Multicast Address Assignments July 1998
-
-
-7.0 Security Considerations
-
- This document defines the initial assignment of IPv6 multicast
- addresses. As such it does not directly impact the security of the
- Internet infrastructure or its applications.
-
-8.0 Authors' Addresses
-
- Robert M. Hinden
- Ipsilon Networks, Inc.
- 232 Java Drive
- Sunnyvale, CA 94089
- USA
-
- Phone: +1 415 990 2004
- EMail: hinden@ipsilon.com
-
-
- Stephen E. Deering
- Cisco Systems, Inc.
- 170 West Tasman Drive
- San Jose, CA 95134-1706
- USA
-
- Phone: +1 408 527-8213
- EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Informational [Page 7]
-
-RFC 2375 IPv6 Multicast Address Assignments July 1998
-
-
-9.0 Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Informational [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc2418.txt b/contrib/bind9/doc/rfc/rfc2418.txt
deleted file mode 100644
index 9bdb2c5367833..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2418.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Bradner
-Request for Comments: 2418 Editor
-Obsoletes: 1603 Harvard University
-BCP: 25 September 1998
-Category: Best Current Practice
-
-
- IETF Working Group
- Guidelines and Procedures
-
-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 (1998). All Rights Reserved.
-
-Abstract
-
- The Internet Engineering Task Force (IETF) has responsibility for
- developing and reviewing specifications intended as Internet
- Standards. IETF activities are organized into working groups (WGs).
- This document describes the guidelines and procedures for formation
- and operation of IETF working groups. It also describes the formal
- relationship between IETF participants WG and the Internet
- Engineering Steering Group (IESG) and the basic duties of IETF
- participants, including WG Chairs, WG participants, and IETF Area
- Directors.
-
-Table of Contents
-
- Abstract ......................................................... 1
- 1. Introduction .................................................. 2
- 1.1. IETF approach to standardization .......................... 4
- 1.2. Roles within a Working Group .............................. 4
- 2. Working group formation ....................................... 4
- 2.1. Criteria for formation .................................... 4
- 2.2. Charter ................................................... 6
- 2.3. Charter review & approval ................................. 8
- 2.4. Birds of a feather (BOF) .................................. 9
- 3. Working Group Operation ....................................... 10
- 3.1. Session planning .......................................... 11
- 3.2. Session venue ............................................. 11
- 3.3. Session management ........................................ 13
- 3.4. Contention and appeals .................................... 15
-
-
-
-Bradner Best Current Practice [Page 1]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- 4. Working Group Termination ..................................... 15
- 5. Rechartering a Working Group .................................. 15
- 6. Staff Roles ................................................... 16
- 6.1. WG Chair .................................................. 16
- 6.2. WG Secretary .............................................. 18
- 6.3. Document Editor ........................................... 18
- 6.4. WG Facilitator ............................................ 18
- 6.5. Design teams .............................................. 19
- 6.6. Working Group Consultant .................................. 19
- 6.7. Area Director ............................................. 19
- 7. Working Group Documents ....................................... 19
- 7.1. Session documents ......................................... 19
- 7.2. Internet-Drafts (I-D) ..................................... 19
- 7.3. Request For Comments (RFC) ................................ 20
- 7.4. Working Group Last-Call ................................... 20
- 7.5. Submission of documents ................................... 21
- 8. Review of documents ........................................... 21
- 9. Security Considerations ....................................... 22
- 10. Acknowledgments .............................................. 23
- 11. References ................................................... 23
- 12. Editor's Address ............................................. 23
- Appendix: Sample Working Group Charter .......................... 24
- Full Copyright Statement ......................................... 26
-
-1. Introduction
-
- The Internet, a loosely-organized international collaboration of
- autonomous, interconnected networks, supports host-to-host
- communication through voluntary adherence to open protocols and
- procedures defined by Internet Standards. There are also many
- isolated interconnected networks, which are not connected to the
- global Internet but use the Internet Standards. Internet Standards
- are developed in the Internet Engineering Task Force (IETF). This
- document defines guidelines and procedures for IETF working groups.
- The Internet Standards Process of the IETF is defined in [1]. The
- organizations involved in the IETF Standards Process are described in
- [2] as are the roles of specific individuals.
-
- The IETF is a large, open community of network designers, operators,
- vendors, users, and researchers concerned with the Internet and the
- technology used on it. The primary activities of the IETF are
- performed by committees known as working groups. There are currently
- more than 100 working groups. (See the IETF web page for an up-to-
- date list of IETF Working Groups - http://www.ietf.org.) Working
- groups tend to have a narrow focus and a lifetime bounded by the
- completion of a specific set of tasks, although there are exceptions.
-
-
-
-
-
-Bradner Best Current Practice [Page 2]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- For management purposes, the IETF working groups are collected
- together into areas, with each area having a separate focus. For
- example, the security area deals with the development of security-
- related technology. Each IETF area is managed by one or two Area
- Directors (ADs). There are currently 8 areas in the IETF but the
- number changes from time to time. (See the IETF web page for a list
- of the current areas, the Area Directors for each area, and a list of
- which working groups are assigned to each area.)
-
- In many areas, the Area Directors have formed an advisory group or
- directorate. These comprise experienced members of the IETF and the
- technical community represented by the area. The specific name and
- the details of the role for each group differ from area to area, but
- the primary intent is that these groups assist the Area Director(s),
- e.g., with the review of specifications produced in the area.
-
- The IETF area directors are selected by a nominating committee, which
- also selects an overall chair for the IETF. The nominations process
- is described in [3].
-
- The area directors sitting as a body, along with the IETF Chair,
- comprise the Internet Engineering Steering Group (IESG). The IETF
- Executive Director is an ex-officio participant of the IESG, as are
- the IAB Chair and a designated Internet Architecture Board (IAB)
- liaison. The IESG approves IETF Standards and approves the
- publication of other IETF documents. (See [1].)
-
- A small IETF Secretariat provides staff and administrative support
- for the operation of the IETF.
-
- There is no formal membership in the IETF. Participation is open to
- all. This participation may be by on-line contribution, attendance
- at face-to-face sessions, or both. Anyone from the Internet
- community who has the time and interest is urged to participate in
- IETF meetings and any of its on-line working group discussions.
- Participation is by individual technical contributors, rather than by
- formal representatives of organizations.
-
- This document defines procedures and guidelines for the formation and
- operation of working groups in the IETF. It defines the relations of
- working groups to other bodies within the IETF. The duties of working
- group Chairs and Area Directors with respect to the operation of the
- working group are also defined. When used in this document the key
- words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
- "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
- interpreted as described in RFC 2119 [6]. RFC 2119 defines the use
- of these key words to help make the intent of standards track
- documents as clear as possible. The same key words are used in this
-
-
-
-Bradner Best Current Practice [Page 3]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- document to help smooth WG operation and reduce the chance for
- confusion about the processes.
-
-1.1. IETF approach to standardization
-
- Familiarity with The Internet Standards Process [1] is essential for
- a complete understanding of the philosophy, procedures and guidelines
- described in this document.
-
-1.2. Roles within a Working Group
-
- The document, "Organizations Involved in the IETF Standards Process"
- [2] describes the roles of a number of individuals within a working
- group, including the working group chair and the document editor.
- These descriptions are expanded later in this document.
-
-2. Working group formation
-
- IETF working groups (WGs) are the primary mechanism for development
- of IETF specifications and guidelines, many of which are intended to
- be standards or recommendations. A working group may be established
- at the initiative of an Area Director or it may be initiated by an
- individual or group of individuals. Anyone interested in creating an
- IETF working group MUST obtain the advice and consent of the IETF
- Area Director(s) in whose area the working group would fall and MUST
- proceed through the formal steps detailed in this section.
-
- Working groups are typically created to address a specific problem or
- to produce one or more specific deliverables (a guideline, standards
- specification, etc.). Working groups are generally expected to be
- short-lived in nature. Upon completion of its goals and achievement
- of its objectives, the working group is terminated. A working group
- may also be terminated for other reasons (see section 4).
- Alternatively, with the concurrence of the IESG, Area Director, the
- WG Chair, and the WG participants, the objectives or assignment of
- the working group may be extended by modifying the working group's
- charter through a rechartering process (see section 5).
-
-2.1. Criteria for formation
-
- When determining whether it is appropriate to create a working group,
- the Area Director(s) and the IESG will consider several issues:
-
- - Are the issues that the working group plans to address clear and
- relevant to the Internet community?
-
- - Are the goals specific and reasonably achievable, and achievable
- within a reasonable time frame?
-
-
-
-Bradner Best Current Practice [Page 4]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- - What are the risks and urgency of the work, to determine the level
- of effort required?
-
- - Do the working group's activities overlap with those of another
- working group? If so, it may still be appropriate to create the
- working group, but this question must be considered carefully by
- the Area Directors as subdividing efforts often dilutes the
- available technical expertise.
-
- - Is there sufficient interest within the IETF in the working
- group's topic with enough people willing to expend the effort to
- produce the desired result (e.g., a protocol specification)?
- Working groups require considerable effort, including management
- of the working group process, editing of working group documents,
- and contributing to the document text. IETF experience suggests
- that these roles typically cannot all be handled by one person; a
- minimum of four or five active participants in the management
- positions are typically required in addition to a minimum of one
- or two dozen people that will attend the working group meetings
- and contribute on the mailing list. NOTE: The interest must be
- broad enough that a working group would not be seen as merely the
- activity of a single vendor.
-
- - Is there enough expertise within the IETF in the working group's
- topic, and are those people interested in contributing in the
- working group?
-
- - Does a base of interested consumers (end-users) appear to exist
- for the planned work? Consumer interest can be measured by
- participation of end-users within the IETF process, as well as by
- less direct means.
-
- - Does the IETF have a reasonable role to play in the determination
- of the technology? There are many Internet-related technologies
- that may be interesting to IETF members but in some cases the IETF
- may not be in a position to effect the course of the technology in
- the "real world". This can happen, for example, if the technology
- is being developed by another standards body or an industry
- consortium.
-
- - Are all known intellectual property rights relevant to the
- proposed working group's efforts issues understood?
-
- - Is the proposed work plan an open IETF effort or is it an attempt
- to "bless" non-IETF technology where the effect of input from IETF
- participants may be limited?
-
-
-
-
-
-Bradner Best Current Practice [Page 5]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- - Is there a good understanding of any existing work that is
- relevant to the topics that the proposed working group is to
- pursue? This includes work within the IETF and elsewhere.
-
- - Do the working group's goals overlap with known work in another
- standards body, and if so is adequate liaison in place?
-
- Considering the above criteria, the Area Director(s), using his or
- her best judgement, will decide whether to pursue the formation of
- the group through the chartering process.
-
-2.2. Charter
-
- The formation of a working group requires a charter which is
- primarily negotiated between a prospective working group Chair and
- the relevant Area Director(s), although final approval is made by the
- IESG with advice from the Internet Architecture Board (IAB). A
- charter is a contract between a working group and the IETF to perform
- a set of tasks. A charter:
-
- 1. Lists relevant administrative information for the working group;
- 2. Specifies the direction or objectives of the working group and
- describes the approach that will be taken to achieve the goals;
- and
- 3. Enumerates a set of milestones together with time frames for their
- completion.
-
- When the prospective Chair(s), the Area Director and the IETF
- Secretariat are satisfied with the charter form and content, it
- becomes the basis for forming a working group. Note that an Area
- Director MAY require holding an exploratory Birds of a Feather (BOF)
- meeting, as described below, to gage the level of support for a
- working group before submitting the charter to the IESG and IAB for
- approval.
-
- Charters may be renegotiated periodically to reflect the current
- status, organization or goals of the working group (see section 5).
- Hence, a charter is a contract between the IETF and the working group
- which is committing to meet explicit milestones and delivering
- specific "products".
-
- Specifically, each charter consists of the following sections:
-
- Working group name
- A working group name should be reasonably descriptive or
- identifiable. Additionally, the group shall define an acronym
- (maximum 8 printable ASCII characters) to reference the group in
- the IETF directories, mailing lists, and general documents.
-
-
-
-Bradner Best Current Practice [Page 6]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- Chair(s)
- The working group may have one or more Chairs to perform the
- administrative functions of the group. The email address(es) of
- the Chair(s) shall be included. Generally, a working group is
- limited to two chairs.
-
- Area and Area Director(s)
- The name of the IETF area with which the working group is
- affiliated and the name and electronic mail address of the
- associated Area Director(s).
-
- Responsible Area Director
- The Area Director who acts as the primary IESG contact for the
- working group.
-
- Mailing list
- An IETF working group MUST have a general Internet mailing list.
- Most of the work of an IETF working group will be conducted on the
- mailing list. The working group charter MUST include:
-
- 1. The address to which a participant sends a subscription request
- and the procedures to follow when subscribing,
-
- 2. The address to which a participant sends submissions and
- special procedures, if any, and
-
- 3. The location of the mailing list archive. A message archive
- MUST be maintained in a public place which can be accessed via
- FTP or via the web.
-
- As a service to the community, the IETF Secretariat operates a
- mailing list archive for working group mailing lists. In order
- to take advantage of this service, working group mailing lists
- MUST include the address "wg_acronym-archive@lists.ietf.org"
- (where "wg_acronym" is the working group acronym) in the
- mailing list in order that a copy of all mailing list messages
- be recorded in the Secretariat's archive. Those archives are
- located at ftp://ftp.ietf.org/ietf-mail-archive. For
- robustness, WGs SHOULD maintain an additional archive separate
- from that maintained by the Secretariat.
-
- Description of working group
- The focus and intent of the group shall be set forth briefly. By
- reading this section alone, an individual should be able to decide
- whether this group is relevant to their own work. The first
- paragraph must give a brief summary of the problem area, basis,
- goal(s) and approach(es) planned for the working group. This
- paragraph can be used as an overview of the working group's
-
-
-
-Bradner Best Current Practice [Page 7]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- effort.
-
- To facilitate evaluation of the intended work and to provide on-
- going guidance to the working group, the charter must describe the
- problem being solved and should discuss objectives and expected
- impact with respect to:
-
- - Architecture
- - Operations
- - Security
- - Network management
- - Scaling
- - Transition (where applicable)
-
- Goals and milestones
- The working group charter MUST establish a timetable for specific
- work items. While this may be renegotiated over time, the list of
- milestones and dates facilitates the Area Director's tracking of
- working group progress and status, and it is indispensable to
- potential participants identifying the critical moments for input.
- Milestones shall consist of deliverables that can be qualified as
- showing specific achievement; e.g., "Internet-Draft finished" is
- fine, but "discuss via email" is not. It is helpful to specify
- milestones for every 3-6 months, so that progress can be gauged
- easily. This milestone list is expected to be updated
- periodically (see section 5).
-
- An example of a WG charter is included as Appendix A.
-
-2.3. Charter review & approval
-
- Proposed working groups often comprise technically competent
- participants who are not familiar with the history of Internet
- architecture or IETF processes. This can, unfortunately, lead to
- good working group consensus about a bad design. To facilitate
- working group efforts, an Area Director may assign a Consultant from
- among the ranks of senior IETF participants. (Consultants are
- described in section 6.) At the discretion of the Area Director,
- approval of a new WG may be withheld in the absence of sufficient
- consultant resources.
-
- Once the Area Director (and the Area Directorate, as the Area
- Director deems appropriate) has approved the working group charter,
- the charter is submitted for review by the IAB and approval by the
- IESG. After a review period of at least a week the proposed charter
- is posted to the IETF-announce mailing list as a public notice that
- the formation of the working group is being considered. At the same
- time the proposed charter is also posted to the "new-work" mailing
-
-
-
-Bradner Best Current Practice [Page 8]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- list. This mailing list has been created to let qualified
- representatives from other standards organizations know about pending
- IETF working groups. After another review period lasting at least a
- week the IESG MAY approve the charter as-is, it MAY request that
- changes be made in the charter, or MAY decline to approve chartering
- of the working group
-
- If the IESG approves the formation of the working group it remands
- the approved charter to the IETF Secretariat who records and enters
- the information into the IETF tracking database. The working group
- is announced to the IETF-announce a by the IETF Secretariat.
-
-2.4. Birds of a Feather (BOF)
-
- Often it is not clear whether an issue merits the formation of a
- working group. To facilitate exploration of the issues the IETF
- offers the possibility of a Birds of a Feather (BOF) session, as well
- as the early formation of an email list for preliminary discussion.
- In addition, a BOF may serve as a forum for a single presentation or
- discussion, without any intent to form a working group.
-
- A BOF is a session at an IETF meeting which permits "market research"
- and technical "brainstorming". Any individual may request permission
- to hold a BOF on a subject. The request MUST be filed with a relevant
- Area Director who must approve a BOF before it can be scheduled. The
- person who requests the BOF may be asked to serve as Chair of the
- BOF.
-
- The Chair of the BOF is also responsible for providing a report on
- the outcome of the BOF. If the Area Director approves, the BOF is
- then scheduled by submitting a request to agenda@ietf.org with copies
- to the Area Director(s). A BOF description and agenda are required
- before a BOF can be scheduled.
-
- Available time for BOFs is limited, and BOFs are held at the
- discretion of the ADs for an area. The AD(s) may require additional
- assurances before authorizing a BOF. For example,
-
- - The Area Director MAY require the establishment of an open email
- list prior to authorizing a BOF. This permits initial exchanges
- and sharing of framework, vocabulary and approaches, in order to
- make the time spent in the BOF more productive.
-
- - The Area Director MAY require that a BOF be held, prior to
- establishing a working group (see section 2.2).
-
- - The Area Director MAY require that there be a draft of the WG
- charter prior to holding a BOF.
-
-
-
-Bradner Best Current Practice [Page 9]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- - The Area Director MAY require that a BOF not be held until an
- Internet-Draft describing the proposed technology has been
- published so it can be used as a basis for discussion in the BOF.
-
- In general, a BOF on a particular topic is held only once (ONE slot
- at one IETF Plenary meeting). Under unusual circumstances Area
- Directors may, at their discretion, allow a BOF to meet for a second
- time. BOFs are not permitted to meet three times. Note that all
- other things being equal, WGs will be given priority for meeting
- space over BOFs. Also, occasionally BOFs may be held for other
- purposes than to discuss formation of a working group.
-
- Usually the outcome of a BOF will be one of the following:
-
- - There was enough interest and focus in the subject to warrant the
- formation of a WG;
-
- - While there was a reasonable level of interest expressed in the
- BOF some other criteria for working group formation was not met
- (see section 2.1).
-
- - The discussion came to a fruitful conclusion, with results to be
- written down and published, however there is no need to establish
- a WG; or
-
- - There was not enough interest in the subject to warrant the
- formation of a WG.
-
-3. Working Group Operation
-
- The IETF has basic requirements for open and fair participation and
- for thorough consideration of technical alternatives. Within those
- constraints, working groups are autonomous and each determines most
- of the details of its own operation with respect to session
- participation, reaching closure, etc. The core rule for operation is
- that acceptance or agreement is achieved via working group "rough
- consensus". WG participants should specifically note the
- requirements for disclosure of conflicts of interest in [2].
-
- A number of procedural questions and issues will arise over time, and
- it is the function of the Working Group Chair(s) to manage the group
- process, keeping in mind that the overall purpose of the group is to
- make progress towards reaching rough consensus in realizing the
- working group's goals and objectives.
-
- There are few hard and fast rules on organizing or conducting working
- group activities, but a set of guidelines and practices has evolved
- over time that have proven successful. These are listed here, with
-
-
-
-Bradner Best Current Practice [Page 10]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- actual choices typically determined by the working group participants
- and the Chair(s).
-
-3.1. Session planning
-
- For coordinated, structured WG interactions, the Chair(s) MUST
- publish a draft agenda well in advance of the actual session. The
- agenda should contain at least:
-
- - The items for discussion;
- - The estimated time necessary per item; and
- - A clear indication of what documents the participants will need to
- read before the session in order to be well prepared.
-
- Publication of the working group agenda shall include sending a copy
- of the agenda to the working group mailing list and to
- agenda@ietf.org.
-
- All working group actions shall be taken in a public forum, and wide
- participation is encouraged. A working group will conduct much of its
- business via electronic mail distribution lists but may meet
- periodically to discuss and review task status and progress, to
- resolve specific issues and to direct future activities. IETF
- Plenary meetings are the primary venue for these face-to-face working
- group sessions, and it is common (though not required) that active
- "interim" face-to-face meetings, telephone conferences, or video
- conferences may also be held. Interim meetings are subject to the
- same rules for advance notification, reporting, open participation,
- and process, which apply to other working group meetings.
-
- All working group sessions (including those held outside of the IETF
- meetings) shall be reported by making minutes available. These
- minutes should include the agenda for the session, an account of the
- discussion including any decisions made, and a list of attendees. The
- Working Group Chair is responsible for insuring that session minutes
- are written and distributed, though the actual task may be performed
- by someone designated by the Working Group Chair. The minutes shall
- be submitted in printable ASCII text for publication in the IETF
- Proceedings, and for posting in the IETF Directories and are to be
- sent to: minutes@ietf.org
-
-3.2. Session venue
-
- Each working group will determine the balance of email and face-to-
- face sessions that is appropriate for achieving its milestones.
- Electronic mail permits the widest participation; face-to-face
- meetings often permit better focus and therefore can be more
- efficient for reaching a consensus among a core of the working group
-
-
-
-Bradner Best Current Practice [Page 11]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- participants. In determining the balance, the WG must ensure that
- its process does not serve to exclude contribution by email-only
- participants. Decisions reached during a face-to-face meeting about
- topics or issues which have not been discussed on the mailing list,
- or are significantly different from previously arrived mailing list
- consensus MUST be reviewed on the mailing list.
-
- IETF Meetings
- If a WG needs a session at an IETF meeting, the Chair must apply for
- time-slots as soon as the first announcement of that IETF meeting is
- made by the IETF Secretariat to the WG-chairs list. Session time is
- a scarce resource at IETF meetings, so placing requests early will
- facilitate schedule coordination for WGs requiring the same set of
- experts.
-
- The application for a WG session at an IETF meeting MUST be made to
- the IETF Secretariat at the address agenda@ietf.org. Some Area
- Directors may want to coordinate WG sessions in their area and
- request that time slots be coordinated through them. If this is the
- case it will be noted in the IETF meeting announcement. A WG
- scheduling request MUST contain:
-
- - The working group name and full title;
- - The amount of time requested;
- - The rough outline of the WG agenda that is expected to be covered;
- - The estimated number of people that will attend the WG session;
- - Related WGs that should not be scheduled for the same time slot(s);
- and
- - Optionally a request can be added for the WG session to be
- transmitted over the Internet in audio and video.
-
- NOTE: While open discussion and contribution is essential to working
- group success, the Chair is responsible for ensuring forward
- progress. When acceptable to the WG, the Chair may call for
- restricted participation (but not restricted attendance!) at IETF
- working group sessions for the purpose of achieving progress. The
- Working Group Chair then has the authority to refuse to grant the
- floor to any individual who is unprepared or otherwise covering
- inappropriate material, or who, in the opinion of the Chair is
- disrupting the WG process. The Chair should consult with the Area
- Director(s) if the individual persists in disruptive behavior.
-
- On-line
- It can be quite useful to conduct email exchanges in the same manner
- as a face-to-face session, with published schedule and agenda, as
- well as on-going summarization and consensus polling.
-
-
-
-
-
-Bradner Best Current Practice [Page 12]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- Many working group participants hold that mailing list discussion is
- the best place to consider and resolve issues and make decisions. The
- choice of operational style is made by the working group itself. It
- is important to note, however, that Internet email discussion is
- possible for a much wider base of interested persons than is
- attendance at IETF meetings, due to the time and expense required to
- attend.
-
- As with face-to-face sessions occasionally one or more individuals
- may engage in behavior on a mailing list which disrupts the WG's
- progress. In these cases the Chair should attempt to discourage the
- behavior by communication directly with the offending individual
- rather than on the open mailing list. If the behavior persists then
- the Chair must involve the Area Director in the issue. As a last
- resort and after explicit warnings, the Area Director, with the
- approval of the IESG, may request that the mailing list maintainer
- block the ability of the offending individual to post to the mailing
- list. (If the mailing list software permits this type of operation.)
- Even if this is done, the individual must not be prevented from
- receiving messages posted to the list. Other methods of mailing list
- control may be considered but must be approved by the AD(s) and the
- IESG.
-
-3.3. Session management
-
- Working groups make decisions through a "rough consensus" process.
- IETF consensus does not require that all participants agree although
- this is, of course, preferred. In general, the dominant view of the
- working group shall prevail. (However, it must be noted that
- "dominance" is not to be determined on the basis of volume or
- persistence, but rather a more general sense of agreement.) Consensus
- can be determined by a show of hands, humming, or any other means on
- which the WG agrees (by rough consensus, of course). Note that 51%
- of the working group does not qualify as "rough consensus" and 99% is
- better than rough. It is up to the Chair to determine if rough
- consensus has been reached.
-
- It can be particularly challenging to gauge the level of consensus on
- a mailing list. There are two different cases where a working group
- may be trying to understand the level of consensus via a mailing list
- discussion. But in both cases the volume of messages on a topic is
- not, by itself, a good indicator of consensus since one or two
- individuals may be generating much of the traffic.
-
- In the case where a consensus which has been reached during a face-
- to-face meeting is being verified on a mailing list the people who
- were in the meeting and expressed agreement must be taken into
- account. If there were 100 people in a meeting and only a few people
-
-
-
-Bradner Best Current Practice [Page 13]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- on the mailing list disagree with the consensus of the meeting then
- the consensus should be seen as being verified. Note that enough
- time should be given to the verification process for the mailing list
- readers to understand and consider any objections that may be raised
- on the list. The normal two week last-call period should be
- sufficient for this.
-
- The other case is where the discussion has been held entirely over
- the mailing list. The determination of the level of consensus may be
- harder to do in this case since most people subscribed to mailing
- lists do not actively participate in discussions on the list. It is
- left to the discretion of the working group chair how to evaluate the
- level of consensus. The most common method used is for the working
- group chair to state what he or she believes to be the consensus view
- and. at the same time, requests comments from the list about the
- stated conclusion.
-
- The challenge to managing working group sessions is to balance the
- need for open and fair consideration of the issues against the need
- to make forward progress. The working group, as a whole, has the
- final responsibility for striking this balance. The Chair has the
- responsibility for overseeing the process but may delegate direct
- process management to a formally-designated Facilitator.
-
- It is occasionally appropriate to revisit a topic, to re-evaluate
- alternatives or to improve the group's understanding of a relevant
- decision. However, unnecessary repeated discussions on issues can be
- avoided if the Chair makes sure that the main arguments in the
- discussion (and the outcome) are summarized and archived after a
- discussion has come to conclusion. It is also good practice to note
- important decisions/consensus reached by email in the minutes of the
- next 'live' session, and to summarize briefly the decision-making
- history in the final documents the WG produces.
-
- To facilitate making forward progress, a Working Group Chair may wish
- to decide to reject or defer the input from a member, based upon the
- following criteria:
-
- Old
- The input pertains to a topic that already has been resolved and is
- redundant with information previously available;
-
- Minor
- The input is new and pertains to a topic that has already been
- resolved, but it is felt to be of minor import to the existing
- decision;
-
-
-
-
-
-Bradner Best Current Practice [Page 14]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- Timing
- The input pertains to a topic that the working group has not yet
- opened for discussion; or
-
- Scope
- The input is outside of the scope of the working group charter.
-
-3.4. Contention and appeals
-
- Disputes are possible at various stages during the IETF process. As
- much as possible the process is designed so that compromises can be
- made, and genuine consensus achieved; however, there are times when
- even the most reasonable and knowledgeable people are unable to
- agree. To achieve the goals of openness and fairness, such conflicts
- must be resolved by a process of open review and discussion.
-
- Formal procedures for requesting a review of WG, Chair, Area Director
- or IESG actions and conducting appeals are documented in The Internet
- Standards Process [1].
-
-4. Working Group Termination
-
- Working groups are typically chartered to accomplish a specific task
- or tasks. After the tasks are complete, the group will be disbanded.
- However, if a WG produces a Proposed or Draft Standard, the WG will
- frequently become dormant rather than disband (i.e., the WG will no
- longer conduct formal activities, but the mailing list will remain
- available to review the work as it moves to Draft Standard and
- Standard status.)
-
- If, at some point, it becomes evident that a working group is unable
- to complete the work outlined in the charter, or if the assumptions
- which that work was based have been modified in discussion or by
- experience, the Area Director, in consultation with the working group
- can either:
-
- 1. Recharter to refocus its tasks,
- 2. Choose new Chair(s), or
- 3. Disband.
-
- If the working group disagrees with the Area Director's choice, it
- may appeal to the IESG (see section 3.4).
-
-5. Rechartering a Working Group
-
- Updated milestones are renegotiated with the Area Director and the
- IESG, as needed, and then are submitted to the IESG Secretariat:
- iesg-secretary@ietf.org.
-
-
-
-Bradner Best Current Practice [Page 15]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- Rechartering (other than revising milestones) a working group follows
- the same procedures that the initial chartering does (see section 2).
- The revised charter must be submitted to the IESG and IAB for
- approval. As with the initial chartering, the IESG may approve new
- charter as-is, it may request that changes be made in the new charter
- (including having the Working Group continue to use the old charter),
- or it may decline to approve the rechartered working group. In the
- latter case, the working group is disbanded.
-
-6. Staff Roles
-
- Working groups require considerable care and feeding. In addition to
- general participation, successful working groups benefit from the
- efforts of participants filling specific functional roles. The Area
- Director must agree to the specific people performing the WG Chair,
- and Working Group Consultant roles, and they serve at the discretion
- of the Area Director.
-
-6.1. WG Chair
-
- The Working Group Chair is concerned with making forward progress
- through a fair and open process, and has wide discretion in the
- conduct of WG business. The Chair must ensure that a number of tasks
- are performed, either directly or by others assigned to the tasks.
-
- The Chair has the responsibility and the authority to make decisions,
- on behalf of the working group, regarding all matters of working
- group process and staffing, in conformance with the rules of the
- IETF. The AD has the authority and the responsibility to assist in
- making those decisions at the request of the Chair or when
- circumstances warrant such an intervention.
-
- The Chair's responsibility encompasses at least the following:
-
- Ensure WG process and content management
-
- The Chair has ultimate responsibility for ensuring that a working
- group achieves forward progress and meets its milestones. The
- Chair is also responsible to ensure that the working group
- operates in an open and fair manner. For some working groups,
- this can be accomplished by having the Chair perform all
- management-related activities. In other working groups --
- particularly those with large or divisive participation -- it is
- helpful to allocate process and/or secretarial functions to other
- participants. Process management pertains strictly to the style
- of working group interaction and not to its content. It ensures
- fairness and detects redundancy. The secretarial function
- encompasses document editing. It is quite common for a working
-
-
-
-Bradner Best Current Practice [Page 16]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- group to assign the task of specification Editor to one or two
- participants. Sometimes, they also are part of the design team,
- described below.
-
- Moderate the WG email list
-
- The Chair should attempt to ensure that the discussions on this
- list are relevant and that they converge to consensus agreements.
- The Chair should make sure that discussions on the list are
- summarized and that the outcome is well documented (to avoid
- repetition). The Chair also may choose to schedule organized on-
- line "sessions" with agenda and deliverables. These can be
- structured as true meetings, conducted over the course of several
- days (to allow participation across the Internet).
-
- Organize, prepare and chair face-to-face and on-line formal
- sessions.
-
- Plan WG Sessions
-
- The Chair must plan and announce all WG sessions well in advance
- (see section 3.1).
-
- Communicate results of sessions
-
- The Chair and/or Secretary must ensure that minutes of a session
- are taken and that an attendance list is circulated (see section
- 3.1).
-
- Immediately after a session, the WG Chair MUST provide the Area
- Director with a very short report (approximately one paragraph,
- via email) on the session.
-
- Distribute the workload
-
- Of course, each WG will have participants who may not be able (or
- want) to do any work at all. Most of the time the bulk of the work
- is done by a few dedicated participants. It is the task of the
- Chair to motivate enough experts to allow for a fair distribution
- of the workload.
-
- Document development
-
- Working groups produce documents and documents need authors. The
- Chair must make sure that authors of WG documents incorporate
- changes as agreed to by the WG (see section 6.3).
-
-
-
-
-
-Bradner Best Current Practice [Page 17]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- Document publication
-
- The Chair and/or Document Editor will work with the RFC Editor to
- ensure document conformance with RFC publication requirements [5]
- and to coordinate any editorial changes suggested by the RFC
- Editor. A particular concern is that all participants are working
- from the same version of a document at the same time.
-
- Document implementations
-
- Under the procedures described in [1], the Chair is responsible
- for documenting the specific implementations which qualify the
- specification for Draft or Internet Standard status along with
- documentation about testing of the interoperation of these
- implementations.
-
-6.2. WG Secretary
-
- Taking minutes and editing working group documents often is performed
- by a specifically-designated participant or set of participants. In
- this role, the Secretary's job is to record WG decisions, rather than
- to perform basic specification.
-
-6.3. Document Editor
-
- Most IETF working groups focus their efforts on a document, or set of
- documents, that capture the results of the group's work. A working
- group generally designates a person or persons to serve as the Editor
- for a particular document. The Document Editor is responsible for
- ensuring that the contents of the document accurately reflect the
- decisions that have been made by the working group.
-
- As a general practice, the Working Group Chair and Document Editor
- positions are filled by different individuals to help ensure that the
- resulting documents accurately reflect the consensus of the working
- group and that all processes are followed.
-
-6.4. WG Facilitator
-
- When meetings tend to become distracted or divisive, it often is
- helpful to assign the task of "process management" to one
- participant. Their job is to oversee the nature, rather than the
- content, of participant interactions. That is, they attend to the
- style of the discussion and to the schedule of the agenda, rather
- than making direct technical contributions themselves.
-
-
-
-
-
-
-Bradner Best Current Practice [Page 18]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
-6.5. Design teams
-
- It is often useful, and perhaps inevitable, for a sub-group of a
- working group to develop a proposal to solve a particular problem.
- Such a sub-group is called a design team. In order for a design team
- to remain small and agile, it is acceptable to have closed membership
- and private meetings. Design teams may range from an informal chat
- between people in a hallway to a formal set of expert volunteers that
- the WG chair or AD appoints to attack a controversial problem. The
- output of a design team is always subject to approval, rejection or
- modification by the WG as a whole.
-
-6.6. Working Group Consultant
-
- At the discretion of the Area Director, a Consultant may be assigned
- to a working group. Consultants have specific technical background
- appropriate to the WG and experience in Internet architecture and
- IETF process.
-
-6.7. Area Director
-
- Area Directors are responsible for ensuring that working groups in
- their area produce coherent, coordinated, architecturally consistent
- and timely output as a contribution to the overall results of the
- IETF.
-
-7. Working Group Documents
-
-7.1. Session documents
-
- All relevant documents to be discussed at a session should be
- published and available as Internet-Drafts at least two weeks before
- a session starts. Any document which does not meet this publication
- deadline can only be discussed in a working group session with the
- specific approval of the working group chair(s). Since it is
- important that working group members have adequate time to review all
- documents, granting such an exception should only be done under
- unusual conditions. The final session agenda should be posted to the
- working group mailing list at least two weeks before the session and
- sent at that time to agenda@ietf.org for publication on the IETF web
- site.
-
-7.2. Internet-Drafts (I-D)
-
- The Internet-Drafts directory is provided to working groups as a
- resource for posting and disseminating in-process copies of working
- group documents. This repository is replicated at various locations
- around the Internet. It is encouraged that draft documents be posted
-
-
-
-Bradner Best Current Practice [Page 19]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- as soon as they become reasonably stable.
-
- It is stressed here that Internet-Drafts are working documents and
- have no official standards status whatsoever. They may, eventually,
- turn into a standards-track document or they may sink from sight.
- Internet-Drafts are submitted to: internet-drafts@ietf.org
-
- The format of an Internet-Draft must be the same as for an RFC [2].
- Further, an I-D must contain:
-
- - Beginning, standard, boilerplate text which is provided by the
- Secretariat on their web site and in the ftp directory;
- - The I-D filename; and
- - The expiration date for the I-D.
-
- Complete specification of requirements for an Internet-Draft are
- found in the file "1id-guidelines.txt" in the Internet-Drafts
- directory at an Internet Repository site. The organization of the
- Internet-Drafts directory is found in the file "1id-organization" in
- the Internet-Drafts directory at an Internet Repository site. This
- file also contains the rules for naming Internet-Drafts. (See [1]
- for more information about Internet-Drafts.)
-
-7.3. Request For Comments (RFC)
-
- The work of an IETF working group often results in publication of one
- or more documents, as part of the Request For Comments (RFCs) [1]
- series. This series is the archival publication record for the
- Internet community. A document can be written by an individual in a
- working group, by a group as a whole with a designated Editor, or by
- others not involved with the IETF.
-
- NOTE: The RFC series is a publication mechanism only and publication
- does not determine the IETF status of a document. Status is
- determined through separate, explicit status labels assigned by the
- IESG on behalf of the IETF. In other words, the reader is reminded
- that all Internet Standards are published as RFCs, but NOT all RFCs
- specify standards [4].
-
-7.4. Working Group Last-Call
-
- When a WG decides that a document is ready for publication it may be
- submitted to the IESG for consideration. In most cases the
- determination that a WG feels that a document is ready for
- publication is done by the WG Chair issuing a working group Last-
- Call. The decision to issue a working group Last-Call is at the
- discretion of the WG Chair working with the Area Director. A working
- group Last-Call serves the same purpose within a working group that
-
-
-
-Bradner Best Current Practice [Page 20]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- an IESG Last-Call does in the broader IETF community (see [1]).
-
-7.5. Submission of documents
-
- Once that a WG has determined at least rough consensus exists within
- the WG for the advancement of a document the following must be done:
-
- - The version of the relevant document exactly as agreed to by the WG
- MUST be in the Internet-Drafts directory.
-
- - The relevant document MUST be formatted according to section 7.3.
-
- - The WG Chair MUST send email to the relevant Area Director. A copy
- of the request MUST be also sent to the IESG Secretariat. The mail
- MUST contain the reference to the document's ID filename, and the
- action requested. The copy of the message to the IESG Secretariat
- is to ensure that the request gets recorded by the Secretariat so
- that they can monitor the progress of the document through the
- process.
-
- Unless returned by the IESG to the WG for further development,
- progressing of the document is then the responsibility of the IESG.
- After IESG approval, responsibility for final disposition is the
- joint responsibility of the RFC Editor, the WG Chair and the Document
- Editor.
-
-8. Review of documents
-
- The IESG reviews all documents submitted for publication as RFCs.
- Usually minimal IESG review is necessary in the case of a submission
- from a WG intended as an Informational or Experimental RFC. More
- extensive review is undertaken in the case of standards-track
- documents.
-
- Prior to the IESG beginning their deliberations on standards-track
- documents, IETF Secretariat will issue a "Last-Call" to the IETF
- mailing list (see [1]). This Last Call will announce the intention of
- the IESG to consider the document, and it will solicit final comments
- from the IETF within a period of two weeks. It is important to note
- that a Last-Call is intended as a brief, final check with the
- Internet community, to make sure that no important concerns have been
- missed or misunderstood. The Last-Call should not serve as a more
- general, in-depth review.
-
- The IESG review takes into account responses to the Last-Call and
- will lead to one of these possible conclusions:
-
-
-
-
-
-Bradner Best Current Practice [Page 21]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- 1. The document is accepted as is for the status requested.
- This fact will be announced by the IETF Secretariat to the IETF
- mailing list and to the RFC Editor.
-
- 2. The document is accepted as-is but not for the status requested.
- This fact will be announced by the IETF Secretariat to the IETF
- mailing list and to the RFC Editor (see [1] for more details).
-
- 3. Changes regarding content are suggested to the author(s)/WG.
- Suggestions from the IESG must be clear and direct, so as to
- facilitate working group and author correction of the
- specification. If the author(s)/WG can explain to the
- satisfaction of the IESG why the changes are not necessary, the
- document will be accepted for publication as under point 1, above.
- If the changes are made the revised document may be resubmitted
- for IESG review.
-
- 4. Changes are suggested by the IESG and a change in status is
- recommended.
- The process described above for 3 and 2 are followed in that
- order.
-
- 5. The document is rejected.
- Any document rejection will be accompanied by specific and
- thorough arguments from the IESG. Although the IETF and working
- group process is structured such that this alternative is not
- likely to arise for documents coming from a working group, the
- IESG has the right and responsibility to reject documents that the
- IESG feels are fatally flawed in some way.
-
- If any individual or group of individuals feels that the review
- treatment has been unfair, there is the opportunity to make a
- procedural complaint. The mechanism for this type of complaints is
- described in [1].
-
-9. Security Considerations
-
- Documents describing IETF processes, such as this one, do not have an
- impact on the security of the network infrastructure or of Internet
- applications.
-
- It should be noted that all IETF working groups are required to
- examine and understand the security implications of any technology
- they develop. This analysis must be included in any resulting RFCs
- in a Security Considerations section. Note that merely noting a
- significant security hole is no longer sufficient. IETF developed
- technologies should not add insecurity to the environment in which
- they are run.
-
-
-
-Bradner Best Current Practice [Page 22]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
-10. Acknowledgments
-
- This revision of this document relies heavily on the previous version
- (RFC 1603) which was edited by Erik Huizer and Dave Crocker. It has
- been reviewed by the Poisson Working Group.
-
-11. References
-
- [1] Bradner, S., Editor, "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
- [2] Hovey, R., and S. Bradner, "The Organizations involved in the
- IETF Standards Process", BCP 11, RFC 2028, October 1996.
-
- [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
- Process: Operation of the Nominating and Recall Committees", BCP
- 10, RFC 2282, February 1998.
-
- [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
- RFC 1796, April 1995.
-
- [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
- 2223, October 1997.
-
- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Level", BCP 14, RFC 2119, March 1997.
-
-
-12. Editor's Address
-
- Scott Bradner
- Harvard University
- 1350 Mass Ave.
- Cambridge MA
- 02138
- USA
-
- Phone +1 617 495 3864
- EMail: sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner Best Current Practice [Page 23]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- Appendix: Sample Working Group Charter
-
- Working Group Name:
- IP Telephony (iptel)
-
- IETF Area:
- Transport Area
-
- Chair(s):
- Jonathan Rosenberg <jdrosen@bell-labs.com>
-
- Transport Area Director(s):
- Scott Bradner <sob@harvard.edu>
- Allyn Romanow <allyn@mci.net>
-
- Responsible Area Director:
- Allyn Romanow <allyn@mci.net>
-
- Mailing Lists:
- General Discussion:iptel@lists.research.bell-labs.com
- To Subscribe: iptel-request@lists.research.bell-labs.com
- Archive: http://www.bell-labs.com/mailing-lists/siptel
-
- Description of Working Group:
-
- Before Internet telephony can become a widely deployed service, a
- number of protocols must be deployed. These include signaling and
- capabilities exchange, but also include a number of "peripheral"
- protocols for providing related services.
-
- The primary purpose of this working group is to develop two such
- supportive protocols and a frameword document. They are:
-
- 1. Call Processing Syntax. When a call is setup between two
- endpoints, the signaling will generally pass through several servers
- (such as an H.323 gatekeeper) which are responsible for forwarding,
- redirecting, or proxying the signaling messages. For example, a user
- may make a call to j.doe@bigcompany.com. The signaling message to
- initiate the call will arrive at some server at bigcompany. This
- server can inform the caller that the callee is busy, forward the
- call initiation request to another server closer to the user, or drop
- the call completely (among other possibilities). It is very desirable
- to allow the callee to provide input to this process, guiding the
- server in its decision on how to act. This can enable a wide variety
- of advanced personal mobility and call agent services.
-
-
-
-
-
-
-Bradner Best Current Practice [Page 24]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
- Such preferences can be expressed in a call processing syntax, which
- can be authored by the user (or generated automatically by some
- tool), and then uploaded to the server. The group will develop this
- syntax, and specify means of securely transporting and extending it.
- The result will be a single standards track RFC.
-
- 2. In addition, the group will write a service model document, which
- describes the services that are enabled by the call processing
- syntax, and discusses how the syntax can be used. This document will
- result in a single RFC.
-
- 3. Gateway Attribute Distribution Protocol. When making a call
- between an IP host and a PSTN user, a telephony gateway must be used.
- The selection of such gateways can be based on many criteria,
- including client expressed preferences, service provider preferences,
- and availability of gateways, in addition to destination telephone
- number. Since gateways outside of the hosts' administrative domain
- might be used, a protocol is required to allow gateways in remote
- domains to distribute their attributes (such as PSTN connectivity,
- supported codecs, etc.) to entities in other domains which must make
- a selection of a gateway. The protocol must allow for scalable,
- bandwidth efficient, and very secure transmission of these
- attributes. The group will investigate and design a protocol for this
- purpose, generate an Internet Draft, and advance it to RFC as
- appropriate.
-
- Goals and Milestones:
-
- May 98 Issue first Internet-Draft on service framework
- Jul 98 Submit framework ID to IESG for publication as an RFC.
- Aug 98 Issue first Internet-Draft on Call Processing Syntax
- Oct 98 Submit Call processing syntax to IESG for consideration
- as a Proposed Standard.
- Dec 98 Achieve consensus on basics of gateway attribute
- distribution protocol
- Jan 99 Submit Gateway Attribute Distribution protocol to IESG
- for consideration as a RFC (info, exp, stds track TB
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner Best Current Practice [Page 25]
-
-RFC 2418 Working Group Guidelines September 1998
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner Best Current Practice [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2535.txt b/contrib/bind9/doc/rfc/rfc2535.txt
deleted file mode 100644
index fe0b3d07f4ae7..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2535.txt
+++ /dev/null
@@ -1,2635 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake
-Request for Comments: 2535 IBM
-Obsoletes: 2065 March 1999
-Updates: 2181, 1035, 1034
-Category: Standards Track
-
- Domain Name System 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 (1999). All Rights Reserved.
-
-Abstract
-
- Extensions to the Domain Name System (DNS) are described that provide
- data integrity and authentication to security aware resolvers and
- applications through the use of cryptographic digital signatures.
- These digital signatures are included in secured zones as resource
- records. Security can also be provided through non-security aware
- DNS servers in some cases.
-
- The extensions provide for the storage of authenticated public keys
- in the DNS. This storage of keys can support general public key
- distribution services as well as DNS security. The stored keys
- enable security aware resolvers to learn the authenticating key of
- zones in addition to those for which they are initially configured.
- Keys associated with DNS names can be retrieved to support other
- protocols. Provision is made for a variety of key types and
- algorithms.
-
- In addition, the security extensions provide for the optional
- authentication of DNS protocol transactions and requests.
-
- This document incorporates feedback on RFC 2065 from early
- implementers and potential users.
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 1]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-Acknowledgments
-
- The significant contributions and suggestions of the following
- persons (in alphabetic order) to DNS security are gratefully
- acknowledged:
-
- James M. Galvin
- John Gilmore
- Olafur Gudmundsson
- Charlie Kaufman
- Edward Lewis
- Thomas Narten
- Radia J. Perlman
- Jeffrey I. Schiller
- Steven (Xunhua) Wang
- Brian Wellington
-
-Table of Contents
-
- Abstract...................................................1
- Acknowledgments............................................2
- 1. Overview of Contents....................................4
- 2. Overview of the DNS Extensions..........................5
- 2.1 Services Not Provided..................................5
- 2.2 Key Distribution.......................................5
- 2.3 Data Origin Authentication and Integrity...............6
- 2.3.1 The SIG Resource Record..............................7
- 2.3.2 Authenticating Name and Type Non-existence...........7
- 2.3.3 Special Considerations With Time-to-Live.............7
- 2.3.4 Special Considerations at Delegation Points..........8
- 2.3.5 Special Considerations with CNAME....................8
- 2.3.6 Signers Other Than The Zone..........................9
- 2.4 DNS Transaction and Request Authentication.............9
- 3. The KEY Resource Record................................10
- 3.1 KEY RDATA format......................................10
- 3.1.1 Object Types, DNS Names, and Keys...................11
- 3.1.2 The KEY RR Flag Field...............................11
- 3.1.3 The Protocol Octet..................................13
- 3.2 The KEY Algorithm Number Specification................14
- 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
- 3.4 Determination of Zone Secure/Unsecured Status.........15
- 3.5 KEY RRs in the Construction of Responses..............17
- 4. The SIG Resource Record................................17
- 4.1 SIG RDATA Format......................................17
- 4.1.1 Type Covered Field..................................18
- 4.1.2 Algorithm Number Field..............................18
- 4.1.3 Labels Field........................................18
- 4.1.4 Original TTL Field..................................19
-
-
-
-Eastlake Standards Track [Page 2]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 4.1.5 Signature Expiration and Inception Fields...........19
- 4.1.6 Key Tag Field.......................................20
- 4.1.7 Signer's Name Field.................................20
- 4.1.8 Signature Field.....................................20
- 4.1.8.1 Calculating Transaction and Request SIGs..........21
- 4.2 SIG RRs in the Construction of Responses..............21
- 4.3 Processing Responses and SIG RRs......................22
- 4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
- 5. Non-existent Names and Types...........................24
- 5.1 The NXT Resource Record...............................24
- 5.2 NXT RDATA Format......................................25
- 5.3 Additional Complexity Due to Wildcards................26
- 5.4 Example...............................................26
- 5.5 Special Considerations at Delegation Points...........27
- 5.6 Zone Transfers........................................27
- 5.6.1 Full Zone Transfers.................................28
- 5.6.2 Incremental Zone Transfers..........................28
- 6. How to Resolve Securely and the AD and CD Bits.........29
- 6.1 The AD and CD Header Bits.............................29
- 6.2 Staticly Configured Keys..............................31
- 6.3 Chaining Through The DNS..............................31
- 6.3.1 Chaining Through KEYs...............................31
- 6.3.2 Conflicting Data....................................33
- 6.4 Secure Time...........................................33
- 7. ASCII Representation of Security RRs...................34
- 7.1 Presentation of KEY RRs...............................34
- 7.2 Presentation of SIG RRs...............................35
- 7.3 Presentation of NXT RRs...............................36
- 8. Canonical Form and Order of Resource Records...........36
- 8.1 Canonical RR Form.....................................36
- 8.2 Canonical DNS Name Order..............................37
- 8.3 Canonical RR Ordering Within An RRset.................37
- 8.4 Canonical Ordering of RR Types........................37
- 9. Conformance............................................37
- 9.1 Server Conformance....................................37
- 9.2 Resolver Conformance..................................38
- 10. Security Considerations...............................38
- 11. IANA Considerations...................................39
- References................................................39
- Author's Address..........................................41
- Appendix A: Base 64 Encoding..............................42
- Appendix B: Changes from RFC 2065.........................44
- Appendix C: Key Tag Calculation...........................46
- Full Copyright Statement..................................47
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 3]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-1. Overview of Contents
-
- This document standardizes extensions of the Domain Name System (DNS)
- protocol to support DNS security and public key distribution. It
- assumes that the reader is familiar with the Domain Name System,
- particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
- earlier version of these extensions appears in RFC 2065. This
- replacement for that RFC incorporates early implementation experience
- and requests from potential users.
-
- Section 2 provides an overview of the extensions and the key
- distribution, data origin authentication, and transaction and request
- security they provide.
-
- Section 3 discusses the KEY resource record, its structure, and use
- in DNS responses. These resource records represent the public keys
- of entities named in the DNS and are used for key distribution.
-
- Section 4 discusses the SIG digital signature resource record, its
- structure, and use in DNS responses. These resource records are used
- to authenticate other resource records in the DNS and optionally to
- authenticate DNS transactions and requests.
-
- Section 5 discusses the NXT resource record (RR) and its use in DNS
- responses including full and incremental zone transfers. The NXT RR
- permits authenticated denial of the existence of a name or of an RR
- type for an existing name.
-
- Section 6 discusses how a resolver can be configured with a starting
- key or keys and proceed to securely resolve DNS requests.
- Interactions between resolvers and servers are discussed for various
- combinations of security aware and security non-aware. Two
- additional DNS header bits are defined for signaling between
- resolvers and servers.
-
- Section 7 describes the ASCII representation of the security resource
- records for use in master files and elsewhere.
-
- Section 8 defines the canonical form and order of RRs for DNS
- security purposes.
-
- Section 9 defines levels of conformance for resolvers and servers.
-
- Section 10 provides a few paragraphs on overall security
- considerations.
-
- Section 11 specified IANA considerations for allocation of additional
- values of paramters defined in this document.
-
-
-
-Eastlake Standards Track [Page 4]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- Appendix A gives details of base 64 encoding which is used in the
- file representation of some RRs defined in this document.
-
- Appendix B summarizes changes between this memo and RFC 2065.
-
- Appendix C specified how to calculate the simple checksum used as a
- key tag in most SIG RRs.
-
- 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. Overview of the DNS Extensions
-
- The Domain Name System (DNS) protocol security extensions provide
- three distinct services: key distribution as described in Section 2.2
- below, data origin authentication as described in Section 2.3 below,
- and transaction and request authentication, described in Section 2.4
- below.
-
- Special considerations related to "time to live", CNAMEs, and
- delegation points are also discussed in Section 2.3.
-
-2.1 Services Not Provided
-
- It is part of the design philosophy of the DNS that the data in it is
- public and that the DNS gives the same answers to all inquirers.
- Following this philosophy, no attempt has been made to include any
- sort of access control lists or other means to differentiate
- inquirers.
-
- No effort has been made to provide for any confidentiality for
- queries or responses. (This service may be available via IPSEC [RFC
- 2401], TLS, or other security protocols.)
-
- Protection is not provided against denial of service.
-
-2.2 Key Distribution
-
- A resource record format is defined to associate keys with DNS names.
- This permits the DNS to be used as a public key distribution
- mechanism in support of DNS security itself and other protocols.
-
- The syntax of a KEY resource record (RR) is described in Section 3.
- It includes an algorithm identifier, the actual public key
- parameter(s), and a variety of flags including those indicating the
- type of entity the key is associated with and/or asserting that there
- is no key associated with that entity.
-
-
-
-Eastlake Standards Track [Page 5]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- Under conditions described in Section 3.5, security aware DNS servers
- will automatically attempt to return KEY resources as additional
- information, along with those resource records actually requested, to
- minimize the number of queries needed.
-
-2.3 Data Origin Authentication and Integrity
-
- Authentication is provided by associating with resource record sets
- (RRsets [RFC 2181]) in the DNS cryptographically generated digital
- signatures. Commonly, there will be a single private key that
- authenticates an entire zone but there might be multiple keys for
- different algorithms, signers, etc. If a security aware resolver
- reliably learns a public key of the zone, it can authenticate, for
- signed data read from that zone, that it is properly authorized. The
- most secure implementation is for the zone private key(s) to be kept
- off-line and used to re-sign all of the records in the zone
- periodically. However, there are cases, for example dynamic update
- [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
- 2541].
-
- The data origin authentication key(s) are associated with the zone
- and not with the servers that store copies of the data. That means
- compromise of a secondary server or, if the key(s) are kept off line,
- even the primary server for a zone, will not necessarily affect the
- degree of assurance that a resolver has that it can determine whether
- data is genuine.
-
- A resolver could learn a public key of a zone either by reading it
- from the DNS or by having it staticly configured. To reliably learn
- a public key by reading it from the DNS, the key itself must be
- signed with a key the resolver trusts. The resolver must be
- configured with at least a public key which authenticates one zone as
- a starting point. From there, it can securely read public keys of
- other zones, if the intervening zones in the DNS tree are secure and
- their signed keys accessible.
-
- Adding data origin authentication and integrity requires no change to
- the "on-the-wire" DNS protocol beyond the addition of the signature
- resource type and the key resource type needed for key distribution.
- (Data non-existence authentication also requires the NXT RR as
- described in 2.3.2.) This service can be supported by existing
- resolver and caching server implementations so long as they can
- support the additional resource types (see Section 9). The one
- exception is that CNAME referrals in a secure zone can not be
- authenticated if they are from non-security aware servers (see
- Section 2.3.5).
-
-
-
-
-
-Eastlake Standards Track [Page 6]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- If signatures are separately retrieved and verified when retrieving
- the information they authenticate, there will be more trips to the
- server and performance will suffer. Security aware servers mitigate
- that degradation by attempting to send the signature(s) needed (see
- Section 4.2).
-
-2.3.1 The SIG Resource Record
-
- The syntax of a SIG resource record (signature) is described in
- Section 4. It cryptographicly binds the RRset being signed to the
- signer and a validity interval.
-
- Every name in a secured zone will have associated with it at least
- one SIG resource record for each resource type under that name except
- for glue address RRs and delegation point NS RRs. A security aware
- server will attempt to return, with RRs retrieved, the corresponding
- SIGs. If a server is not security aware, the resolver must retrieve
- all the SIG records for a name and select the one or ones that sign
- the resource record set(s) that resolver is interested in.
-
-2.3.2 Authenticating Name and Type Non-existence
-
- The above security mechanism only provides a way to sign existing
- RRsets in a zone. "Data origin" authentication is not obviously
- provided for the non-existence of a domain name in a zone or the
- non-existence of a type for an existing name. This gap is filled by
- the NXT RR which authenticatably asserts a range of non-existent
- names in a zone and the non-existence of types for the existing name
- just before that range.
-
- Section 5 below covers the NXT RR.
-
-2.3.3 Special Considerations With Time-to-Live
-
- A digital signature will fail to verify if any change has occurred to
- the data between the time it was originally signed and the time the
- signature is verified. This conflicts with our desire to have the
- time-to-live (TTL) field of resource records tick down while they are
- cached.
-
- This could be avoided by leaving the time-to-live out of the digital
- signature, but that would allow unscrupulous servers to set
- arbitrarily long TTL values undetected. Instead, we include the
- "original" TTL in the signature and communicate that data along with
- the current TTL. Unscrupulous servers under this scheme can
- manipulate the TTL but a security aware resolver will bound the TTL
- value it uses at the original signed value. Separately, signatures
- include a signature inception time and a signature expiration time. A
-
-
-
-Eastlake Standards Track [Page 7]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- resolver that knows the absolute time can determine securely whether
- a signature is in effect. It is not possible to rely solely on the
- signature expiration as a substitute for the TTL, however, since the
- TTL is primarily a database consistency mechanism and non-security
- aware servers that depend on TTL must still be supported.
-
-2.3.4 Special Considerations at Delegation Points
-
- DNS security would like to view each zone as a unit of data
- completely under the control of the zone owner with each entry
- (RRset) signed by a special private key held by the zone manager.
- But the DNS protocol views the leaf nodes in a zone, which are also
- the apex nodes of a subzone (i.e., delegation points), as "really"
- belonging to the subzone. These nodes occur in two master files and
- might have RRs signed by both the upper and lower zone's keys. A
- retrieval could get a mixture of these RRs and SIGs, especially since
- one server could be serving both the zone above and below a
- delegation point. [RFC 2181]
-
- There MUST be a zone KEY RR, signed by its superzone, for every
- subzone if the superzone is secure. This will normally appear in the
- subzone and may also be included in the superzone. But, in the case
- of an unsecured subzone which can not or will not be modified to add
- any security RRs, a KEY declaring the subzone to be unsecured MUST
- appear with the superzone signature in the superzone, if the
- superzone is secure. For all but one other RR type the data from the
- subzone is more authoritative so only the subzone KEY RR should be
- signed in the superzone if it appears there. The NS and any glue
- address RRs SHOULD only be signed in the subzone. The SOA and any
- other RRs that have the zone name as owner should appear only in the
- subzone and thus are signed only there. The NXT RR type is the
- exceptional case that will always appear differently and
- authoritatively in both the superzone and subzone, if both are
- secure, as described in Section 5.
-
-2.3.5 Special Considerations with CNAME
-
- There is a problem when security related RRs with the same owner name
- as a CNAME RR are retrieved from a non-security-aware server. In
- particular, an initial retrieval for the CNAME or any other type may
- not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
- other than CNAME, it will retrieve that type at the target name of
- the CNAME (or chain of CNAMEs) and will also return the CNAME. In
- particular, a specific retrieval for type SIG will not get the SIG,
- if any, at the original CNAME domain name but rather a SIG at the
- target name.
-
-
-
-
-
-Eastlake Standards Track [Page 8]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- Security aware servers must be used to securely CNAME in DNS.
- Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along
- with CNAME RRs, (2) suppress CNAME processing on retrieval of these
- types as well as on retrieval of the type CNAME, and (3)
- automatically return SIG RRs authenticating the CNAME or CNAMEs
- encountered in resolving a query. This is a change from the previous
- DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
- node where a CNAME RR was present.
-
-2.3.6 Signers Other Than The Zone
-
- There are cases where the signer in a SIG resource record is other
- than one of the private key(s) used to authenticate a zone.
-
- One is for support of dynamic update [RFC 2136] (or future requests
- which require secure authentication) where an entity is permitted to
- authenticate/update its records [RFC 2137] and the zone is operating
- in a mode where the zone key is not on line. The public key of the
- entity must be present in the DNS and be signed by a zone level key
- but the other RR(s) may be signed with the entity's key.
-
- A second case is support of transaction and request authentication as
- described in Section 2.4.
-
- In additions, signatures can be included on resource records within
- the DNS for use by applications other than DNS. DNS related
- signatures authenticate that data originated with the authority of a
- zone owner or that a request or transaction originated with the
- relevant entity. Other signatures can provide other types of
- assurances.
-
-2.4 DNS Transaction and Request Authentication
-
- The data origin authentication service described above protects
- retrieved resource records and the non-existence of resource records
- but provides no protection for DNS requests or for message headers.
-
- If header bits are falsely set by a bad server, there is little that
- can be done. However, it is possible to add transaction
- authentication. Such authentication means that a resolver can be
- sure it is at least getting messages from the server it thinks it
- queried and that the response is from the query it sent (i.e., that
- these messages have not been diddled in transit). This is
- accomplished by optionally adding a special SIG resource record at
- the end of the reply which digitally signs the concatenation of the
- server's response and the resolver's query.
-
-
-
-
-
-Eastlake Standards Track [Page 9]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- Requests can also be authenticated by including a special SIG RR at
- the end of the request. Authenticating requests serves no function
- in older DNS servers and requests with a non-empty additional
- information section produce error returns or may even be ignored by
- many of them. However, this syntax for signing requests is defined as
- a way of authenticating secure dynamic update requests [RFC 2137] or
- future requests requiring authentication.
-
- The private keys used in transaction security belong to the entity
- composing the reply, not to the zone involved. Request
- authentication may also involve the private key of the host or other
- entity composing the request or other private keys depending on the
- request authority it is sought to establish. The corresponding public
- key(s) are normally stored in and retrieved from the DNS for
- verification.
-
- Because requests and replies are highly variable, message
- authentication SIGs can not be pre-calculated. Thus it will be
- necessary to keep the private key on-line, for example in software or
- in a directly connected piece of hardware.
-
-3. The KEY Resource Record
-
- The KEY resource record (RR) is used to store a public key that is
- associated with a Domain Name System (DNS) name. This can be the
- public key of a zone, a user, or a host or other end entity. Security
- aware DNS implementations MUST be designed to handle at least two
- simultaneously valid keys of the same type associated with the same
- name.
-
- The type number for the KEY RR is 25.
-
- A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs
- must be signed by a zone level key.
-
-3.1 KEY RDATA format
-
- The RDATA for a KEY RR consists of flags, a protocol octet, the
- algorithm number octet, and the public key itself. The format is as
- follows:
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 10]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 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 /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
- The KEY RR is not intended for storage of certificates and a separate
- certificate RR has been developed for that purpose, defined in [RFC
- 2538].
-
- The meaning of the KEY RR owner name, flags, and protocol octet are
- described in Sections 3.1.1 through 3.1.5 below. The flags and
- algorithm must be examined before any data following the algorithm
- octet as they control the existence and format of any following data.
- The algorithm and public key fields are described in Section 3.2.
- The format of the public key is algorithm dependent.
-
- KEY RRs do not specify their validity period but their authenticating
- SIG RR(s) do as described in Section 4 below.
-
-3.1.1 Object Types, DNS Names, and Keys
-
- The public key in a KEY RR is for the object named in the owner name.
-
- A DNS name may refer to three different categories of things. For
- example, foo.host.example could be (1) a zone, (2) a host or other
- end entity , or (3) the mapping into a DNS name of the user or
- account foo@host.example. Thus, there are flag bits, as described
- below, in the KEY RR to indicate with which of these roles the owner
- name and public key are associated. Note that an appropriate zone
- KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
- occur only at delegation points.
-
-3.1.2 The KEY RR Flag Field
-
- In the "flags" field:
-
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
- Bit 0 and 1 are the key "type" bits whose values have the following
- meanings:
-
-
-
-Eastlake Standards Track [Page 11]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 10: Use of the key is prohibited for authentication.
- 01: Use of the key is prohibited for confidentiality.
- 00: Use of the key for authentication and/or confidentiality
- is permitted. Note that DNS security makes use of keys
- for authentication only. Confidentiality use flagging is
- provided for use of keys in other protocols.
- Implementations not intended to support key distribution
- for confidentiality MAY require that the confidentiality
- use prohibited bit be on for keys they serve.
- 11: If both bits are one, the "no key" value, there is no key
- information and the RR stops after the algorithm octet.
- By the use of this "no key" value, a signed KEY RR can
- authenticatably assert that, for example, a zone is not
- secured. See section 3.4 below.
-
- Bits 2 is reserved and must be zero.
-
- Bits 3 is reserved as a flag extension bit. If it is a one, a second
- 16 bit flag field is added after the algorithm octet and
- before the key data. This bit MUST NOT be set unless one or
- more such additional bits have been defined and are non-zero.
-
- Bits 4-5 are reserved and must be zero.
-
- Bits 6 and 7 form a field that encodes the name type. Field values
- have the following meanings:
-
- 00: indicates that this is a key associated with a "user" or
- "account" at an end entity, usually a host. The coding
- of the owner name is that used for the responsible
- individual mailbox in the SOA and RP RRs: The owner name
- is the user name as the name of a node under the entity
- name. For example, "j_random_user" on
- host.subdomain.example could have a public key associated
- through a KEY RR with name
- j_random_user.host.subdomain.example. It could be used
- in a security protocol where authentication of a user was
- desired. This key might be useful in IP or other
- security for a user level service such a telnet, ftp,
- rlogin, etc.
- 01: indicates that this is a zone key for the zone whose name
- is the KEY RR owner name. This is the public key used
- for the primary DNS security feature of data origin
- authentication. Zone KEY RRs occur only at delegation
- points.
- 10: indicates that this is a key associated with the non-zone
- "entity" whose name is the RR owner name. This will
- commonly be a host but could, in some parts of the DNS
-
-
-
-Eastlake Standards Track [Page 12]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- tree, be some other type of entity such as a telephone
- number [RFC 1530] or numeric IP address. This is the
- public key used in connection with DNS request and
- transaction authentication services. It could also be
- used in an IP-security protocol where authentication at
- the host, rather than user, level was desired, such as
- routing, NTP, etc.
- 11: reserved.
-
- Bits 8-11 are reserved and must be zero.
-
- Bits 12-15 are the "signatory" field. If non-zero, they indicate
- that the key can validly sign things as specified in DNS
- dynamic update [RFC 2137]. Note that zone keys (see bits
- 6 and 7 above) always have authority to sign any RRs in
- the zone regardless of the value of the signatory field.
-
-3.1.3 The Protocol Octet
-
- It is anticipated that keys stored in DNS will be used in conjunction
- with a variety of Internet protocols. It is intended that the
- protocol octet and possibly some of the currently unused (must be
- zero) bits in the KEY RR flags as specified in the future will be
- used to indicate a key's validity for different protocols.
-
- The following values of the Protocol Octet are reserved as indicated:
-
- VALUE Protocol
-
- 0 -reserved
- 1 TLS
- 2 email
- 3 dnssec
- 4 IPSEC
- 5-254 - available for assignment by IANA
- 255 All
-
- In more detail:
- 1 is reserved for use in connection with TLS.
- 2 is reserved for use in connection with email.
- 3 is used for DNS security. The protocol field SHOULD be set to
- this value for zone keys and other keys used in DNS security.
- Implementations that can determine that a key is a DNS
- security key by the fact that flags label it a zone key or the
- signatory flag field is non-zero are NOT REQUIRED to check the
- protocol field.
- 4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
- and indicates that this key is valid for use in conjunction
-
-
-
-Eastlake Standards Track [Page 13]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- with that security standard. This key could be used in
- connection with secured communication on behalf of an end
- entity or user whose name is the owner name of the KEY RR if
- the entity or user flag bits are set. The presence of a KEY
- resource with this protocol value is an assertion that the
- host speaks Oakley/IPSEC.
- 255 indicates that the key can be used in connection with any
- protocol for which KEY RR protocol octet values have been
- defined. The use of this value is discouraged and the use of
- different keys for different protocols is encouraged.
-
-3.2 The KEY Algorithm Number Specification
-
- This octet is the key algorithm parallel to the same field for the
- SIG resource as described in Section 4.1. The following values are
- assigned:
-
- VALUE Algorithm
-
- 0 - reserved, see Section 11
- 1 RSA/MD5 [RFC 2537] - recommended
- 2 Diffie-Hellman [RFC 2539] - optional, key only
- 3 DSA [RFC 2536] - MANDATORY
- 4 reserved for elliptic curve crypto
- 5-251 - available, see Section 11
- 252 reserved for indirect keys
- 253 private - domain name (see below)
- 254 private - OID (see below)
- 255 - reserved, see Section 11
-
- Algorithm specific formats and procedures are given in separate
- documents. The mandatory to implement for interoperability algorithm
- is number 3, DSA. It is recommended that the RSA/MD5 algorithm,
- number 1, also be implemented. Algorithm 2 is used to indicate
- Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
-
- Algorithm number 252 indicates an indirect key format where the
- actual key material is elsewhere. This format is to be defined in a
- separate document.
-
- Algorithm numbers 253 and 254 are reserved for private use and will
- never be assigned a specific algorithm. For number 253, the public
- key area and the signature begin with a wire encoded domain name.
- Only local domain name compression is permitted. The domain name
- indicates the private algorithm to use and the remainder of the
- public key area is whatever is required by that algorithm. For
- number 254, the public key area for the KEY RR and the signature
- begin with an unsigned length byte followed by a BER encoded Object
-
-
-
-Eastlake Standards Track [Page 14]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 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 domain names
- and OIDs they control to designate their private algorithms.
-
- Values 0 and 255 are reserved but the value 0 is used in the
- algorithm field when that field is not used. An example is in a KEY
- RR with the top two flag bits on, the "no-key" value, where no key is
- present.
-
-3.3 Interaction of Flags, Algorithm, and Protocol Bytes
-
- Various combinations of the no-key type flags, algorithm byte,
- protocol byte, and any future assigned protocol indicating flags are
- possible. The meaning of these combinations is indicated below:
-
- NK = no key type (flags bits 0 and 1 on)
- AL = algorithm byte
- PR = protocols indicated by protocol byte or future assigned flags
-
- x represents any valid non-zero value(s).
-
- AL PR NK Meaning
- 0 0 0 Illegal, claims key but has bad algorithm field.
- 0 0 1 Specifies total lack of security for owner zone.
- 0 x 0 Illegal, claims key but has bad algorithm field.
- 0 x 1 Specified protocols unsecured, others may be secure.
- x 0 0 Gives key but no protocols to use it.
- x 0 1 Denies key for specific algorithm.
- x x 0 Specifies key for protocols.
- x x 1 Algorithm not understood for protocol.
-
-3.4 Determination of Zone Secure/Unsecured Status
-
- A zone KEY RR with the "no-key" type field value (both key type flag
- bits 0 and 1 on) indicates that the zone named is unsecured while a
- zone KEY RR with a key present indicates that the zone named is
- secure. The secured versus unsecured status of a zone may vary with
- different cryptographic algorithms. Even for the same algorithm,
- conflicting zone KEY RRs may be present.
-
- Zone KEY RRs, like all RRs, are only trusted if they are
- authenticated by a SIG RR whose signer field is a signer for which
- the resolver has a public key they trust and where resolver policy
- permits that signer to sign for the KEY owner name. Untrusted zone
- KEY RRs MUST be ignored in determining the security status of the
- zone. However, there can be multiple sets of trusted zone KEY RRs
- for a zone with different algorithms, signers, etc.
-
-
-
-Eastlake Standards Track [Page 15]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- For any particular algorithm, zones can be (1) secure, indicating
- that any retrieved RR must be authenticated by a SIG RR or it will be
- discarded as bogus, (2) unsecured, indicating that SIG RRs are not
- expected or required for RRs retrieved from the zone, or (3)
- experimentally secure, which indicates that SIG RRs might or might
- not be present but must be checked if found. The status of a zone is
- determined as follows:
-
- 1. If, for a zone and algorithm, every trusted zone KEY RR for the
- zone says there is no key for that zone, it is unsecured for that
- algorithm.
-
- 2. If, there is at least one trusted no-key zone KEY RR and one
- trusted key specifying zone KEY RR, then that zone is only
- experimentally secure for the algorithm. Both authenticated and
- non-authenticated RRs for it should be accepted by the resolver.
-
- 3. If every trusted zone KEY RR that the zone and algorithm has is
- key specifying, then it is secure for that algorithm and only
- authenticated RRs from it will be accepted.
-
- Examples:
-
- (1) A resolver initially trusts only signatures by the superzone of
- zone Z within the DNS hierarchy. Thus it will look only at the KEY
- RRs that are signed by the superzone. If it finds only no-key KEY
- RRs, it will assume the zone is not secure. If it finds only key
- specifying KEY RRs, it will assume the zone is secure and reject any
- unsigned responses. If it finds both, it will assume the zone is
- experimentally secure
-
- (2) A resolver trusts the superzone of zone Z (to which it got
- securely from its local zone) and a third party, cert-auth.example.
- When considering data from zone Z, it may be signed by the superzone
- of Z, by cert-auth.example, by both, or by neither. The following
- table indicates whether zone Z will be considered secure,
- experimentally secure, or unsecured, depending on the signed zone KEY
- RRs for Z;
-
- c e r t - a u t h . e x a m p l e
-
- KEY RRs| None | NoKeys | Mixed | Keys |
- S --+-----------+-----------+----------+----------+
- u None | illegal | unsecured | experim. | secure |
- p --+-----------+-----------+----------+----------+
- e NoKeys | unsecured | unsecured | experim. | secure |
- r --+-----------+-----------+----------+----------+
- Z Mixed | experim. | experim. | experim. | secure |
-
-
-
-Eastlake Standards Track [Page 16]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- o --+-----------+-----------+----------+----------+
- n Keys | secure | secure | secure | secure |
- e +-----------+-----------+----------+----------+
-
-3.5 KEY RRs in the Construction of Responses
-
- An explicit request for KEY RRs does not cause any special additional
- information processing except, of course, for the corresponding SIG
- RR from a security aware server (see Section 4.2).
-
- Security aware DNS servers include KEY RRs as additional information
- in responses, where a KEY is available, in the following cases:
-
- (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
- name (perhaps just a zone key) SHOULD be included as additional
- information if space is available. If not all additional information
- will fit, type A and AAAA glue RRs have higher priority than KEY
- RR(s).
-
- (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
- name (usually just a host RR and NOT the zone key (which usually
- would have a different name)) SHOULD be included if space is
- available. On inclusion of A or AAAA RRs as additional information,
- the KEY RRset with the same name should also be included but with
- lower priority than the A or AAAA RRs.
-
-4. The SIG Resource Record
-
- The SIG or "signature" resource record (RR) is the fundamental way
- that data is authenticated in the secure Domain Name System (DNS). As
- such it is the heart of the security provided.
-
- The SIG RR unforgably authenticates an RRset [RFC 2181] of a
- particular type, class, and name and binds it to a time interval and
- the signer's domain name. This is done using cryptographic
- techniques and the signer's private key. The signer is frequently
- the owner of the zone from which the RR originated.
-
- The type number for the SIG RR type is 24.
-
-4.1 SIG RDATA Format
-
- The RDATA portion of a SIG RR is as shown below. The integrity of
- the RDATA information is protected by the signature field.
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 17]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 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 /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-4.1.1 Type Covered Field
-
- The "type covered" is the type of the other RRs covered by this SIG.
-
-4.1.2 Algorithm Number Field
-
- This octet is as described in section 3.2.
-
-4.1.3 Labels Field
-
- The "labels" octet is an unsigned count of how many labels there are
- in the original SIG RR owner name not counting the null label for
- root and not counting any initial "*" for a wildcard. If a secured
- retrieval is the result of wild card substitution, it is necessary
- for the resolver to use the original form of the name in verifying
- the digital signature. This field makes it easy to determine the
- original form.
-
- If, on retrieval, the RR appears to have a longer name than indicated
- by "labels", the resolver can tell it is the result of wildcard
- substitution. If the RR owner name appears to be shorter than the
- labels count, the SIG RR must be considered corrupt and ignored. The
- maximum number of labels allowed in the current DNS is 127 but the
- entire octet is reserved and would be required should DNS names ever
- be expanded to 255 labels. The following table gives some examples.
- The value of "labels" is at the top, the retrieved owner name on the
- left, and the table entry is the name to use in signature
- verification except that "bad" means the RR is corrupt.
-
-
-
-Eastlake Standards Track [Page 18]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- labels= | 0 | 1 | 2 | 3 | 4 |
- --------+-----+------+--------+----------+----------+
- .| . | bad | bad | bad | bad |
- d.| *. | d. | bad | bad | bad |
- c.d.| *. | *.d. | c.d. | bad | bad |
- b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad |
- a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
-
-4.1.4 Original TTL Field
-
- The "original TTL" field is included in the RDATA portion to avoid
- (1) authentication problems that caching servers would otherwise
- cause by decrementing the real TTL field and (2) security problems
- that unscrupulous servers could otherwise cause by manipulating the
- real TTL field. This original TTL is protected by the signature
- while the current TTL field is not.
-
- NOTE: The "original TTL" must be restored into the covered RRs when
- the signature is verified (see Section 8). This generaly implies
- that all RRs for a particular type, name, and class, that is, all the
- RRs in any particular RRset, must have the same TTL to start with.
-
-4.1.5 Signature Expiration and Inception Fields
-
- The SIG is valid from the "signature inception" time until the
- "signature expiration" time. Both are unsigned numbers of seconds
- since the start of 1 January 1970, GMT, ignoring leap seconds. (See
- also Section 4.4.) Ring arithmetic is used as for DNS SOA serial
- numbers [RFC 1982] which means that these times can never be more
- than about 68 years in the past or the future. This means that these
- times are ambiguous modulo ~136.09 years. However there is no
- security flaw because keys are required to be changed to new random
- keys by [RFC 2541] at least every five years. This means that the
- probability that the same key is in use N*136.09 years later should
- be the same as the probability that a random guess will work.
-
- A SIG RR may have an expiration time numerically less than the
- inception time if the expiration time is near the 32 bit wrap around
- point and/or the signature is long lived.
-
- (To prevent misordering of network requests to update a zone
- dynamically, monotonically increasing "signature inception" times may
- be necessary.)
-
- A secure zone must be considered changed for SOA serial number
- purposes not only when its data is updated but also when new SIG RRs
- are inserted (ie, the zone or any part of it is re-signed).
-
-
-
-
-Eastlake Standards Track [Page 19]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-4.1.6 Key Tag Field
-
- The "key Tag" is a two octet quantity that is used to efficiently
- select between multiple keys which may be applicable and thus check
- that a public key about to be used for the computationally expensive
- effort to check the signature is possibly valid. For algorithm 1
- (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
- octets of the public key modulus needed to decode the signature
- field. That is to say, the most significant 16 of the least
- significant 24 bits of the modulus in network (big endian) order. For
- all other algorithms, including private algorithms, it is calculated
- as a simple checksum of the KEY RR as described in Appendix C.
-
-4.1.7 Signer's Name Field
-
- The "signer's name" field is the domain name of the signer generating
- the SIG RR. This is the owner name of the public KEY RR that can be
- used to verify the signature. It is frequently the zone which
- contained the RRset being authenticated. Which signers should be
- authorized to sign what is a significant resolver policy question as
- discussed in Section 6. The signer's name may be compressed with
- standard DNS name compression when being transmitted over the
- network.
-
-4.1.8 Signature Field
-
- The actual signature portion of the SIG RR binds the other RDATA
- fields to the RRset of the "type covered" RRs with that owner name
- and class. This covered RRset is thereby authenticated. To
- accomplish this, a data sequence is constructed as follows:
-
- data = RDATA | RR(s)...
-
- where "|" is concatenation,
-
- RDATA is the wire format of all the RDATA fields in the SIG RR itself
- (including the canonical form of the signer's name) before but not
- including the signature, and
-
- RR(s) is the RRset of the RR(s) of the type covered with the same
- owner name and class as the SIG RR in canonical form and order as
- defined in Section 8.
-
- How this data sequence is processed into the signature is algorithm
- dependent. These algorithm dependent formats and procedures are
- described in separate documents (Section 3.2).
-
-
-
-
-
-Eastlake Standards Track [Page 20]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- SIGs SHOULD NOT be included in a zone for any "meta-type" such as
- ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).
-
-4.1.8.1 Calculating Transaction and Request SIGs
-
- A response message from a security aware server may optionally
- contain a special SIG at the end of the additional information
- section to authenticate the transaction.
-
- This SIG has a "type covered" field of zero, which is not a valid RR
- type. It is calculated by using a "data" (see Section 4.1.8) of the
- entire preceding DNS reply message, including DNS header but not the
- IP header and before the reply RR counts have been adjusted for the
- inclusion of any transaction SIG, concatenated with the entire DNS
- query message that produced this response, including the query's DNS
- header and any request SIGs but not its IP header. That is
-
- data = full response (less transaction SIG) | full query
-
- Verification of the transaction SIG (which is signed by the server
- host key, not the zone key) by the requesting resolver shows that the
- query and response were not tampered with in transit, that the
- response corresponds to the intended query, and that the response
- comes from the queried server.
-
- A DNS request may be optionally signed by including one or more SIGs
- at the end of the query. Such SIGs are identified by having a "type
- covered" field of zero. They sign the preceding DNS request message
- including DNS header but not including the IP header or any request
- SIGs at the end and before the request RR counts have been adjusted
- for the inclusions of any request SIG(s).
-
- WARNING: Request SIGs are unnecessary for any currently defined
- request other than update [RFC 2136, 2137] and will cause some old
- DNS servers to give an error return or ignore a query. However, such
- SIGs may in the future be needed for other requests.
-
- Except where needed to authenticate an update or similar privileged
- request, servers are not required to check request SIGs.
-
-4.2 SIG RRs in the Construction of Responses
-
- Security aware DNS servers SHOULD, for every authenticated RRset the
- query will return, attempt to send the available SIG RRs which
- authenticate the requested RRset. The following rules apply to the
- inclusion of SIG RRs in responses:
-
-
-
-
-
-Eastlake Standards Track [Page 21]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 1. when an RRset is placed in a response, its SIG RR has a higher
- priority for inclusion than additional RRs that may need to be
- included. If space does not permit its inclusion, the response
- MUST be considered truncated except as provided in 2 below.
-
- 2. When a SIG RR is present in the zone for an additional
- information section RR, the response MUST NOT be considered
- truncated merely because space does not permit the inclusion of
- the SIG RR with the additional information.
-
- 3. SIGs to authenticate glue records and NS RRs for subzones at a
- delegation point are unnecessary and MUST NOT be sent.
-
- 4. If a SIG covers any RR that would be in the answer section of
- the response, its automatic inclusion MUST be in the answer
- section. If it covers an RR that would appear in the authority
- section, its automatic inclusion MUST be in the authority
- section. If it covers an RR that would appear in the additional
- information section it MUST appear in the additional information
- section. This is a change in the existing standard [RFCs 1034,
- 1035] which contemplates only NS and SOA RRs in the authority
- section.
-
- 5. Optionally, DNS transactions may be authenticated by a SIG RR at
- the end of the response in the additional information section
- (Section 4.1.8.1). Such SIG RRs are signed by the DNS server
- originating the response. Although the signer field MUST be a
- name of the originating server host, the owner name, class, TTL,
- and original TTL, are meaningless. The class and TTL fields
- SHOULD be zero. To conserve space, the owner name SHOULD be
- root (a single zero octet). If transaction authentication is
- desired, that SIG RR must be considered the highest priority for
- inclusion.
-
-4.3 Processing Responses and SIG RRs
-
- The following rules apply to the processing of SIG RRs included in a
- response:
-
- 1. A security aware resolver that receives a response from a
- security aware server via a secure communication with the AD bit
- (see Section 6.1) set, MAY choose to accept the RRs as received
- without verifying the zone SIG RRs.
-
- 2. In other cases, a security aware resolver SHOULD verify the SIG
- RRs for the RRs of interest. This may involve initiating
- additional queries for SIG or KEY RRs, especially in the case of
-
-
-
-
-Eastlake Standards Track [Page 22]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- getting a response from a server that does not implement
- security. (As explained in 2.3.5 above, it will not be possible
- to secure CNAMEs being served up by non-secure resolvers.)
-
- NOTE: Implementers might expect the above SHOULD to be a MUST.
- However, local policy or the calling application may not require
- the security services.
-
- 3. If SIG RRs are received in response to a user query explicitly
- specifying the SIG type, no special processing is required.
-
- If the message does not pass integrity checks or the SIG does not
- check against the signed RRs, the SIG RR is invalid and should be
- ignored. If all of the SIG RR(s) purporting to authenticate an RRset
- are invalid, then the RRset is not authenticated.
-
- If the SIG RR is the last RR in a response in the additional
- information section and has a type covered of zero, it is a
- transaction signature of the response and the query that produced the
- response. It MAY be optionally checked and the message rejected if
- the checks fail. But even if the checks succeed, such a transaction
- authentication SIG does NOT directly authenticate any RRs in the
- message. Only a proper SIG RR signed by the zone or a key tracing
- its authority to the zone or to static resolver configuration can
- directly authenticate RRs, depending on resolver policy (see Section
- 6). If a resolver does not implement transaction and/or request
- SIGs, it MUST ignore them without error.
-
- If all checks indicate that the SIG RR is valid then RRs verified by
- it should be considered authenticated.
-
-4.4 Signature Lifetime, Expiration, TTLs, and Validity
-
- Security aware servers MUST NOT consider SIG RRs to authenticate
- anything before their signature inception or after its expiration
- time (see also Section 6). Security aware servers MUST NOT consider
- any RR to be authenticated after all its signatures have expired.
- When a secure server caches authenticated data, if the TTL would
- expire at a time further in the future than the authentication
- expiration time, the server SHOULD trim the TTL in the cache entry
- not to extent beyond the authentication expiration time. Within
- these constraints, servers should continue to follow DNS TTL aging.
- Thus authoritative servers should continue to follow the zone refresh
- and expire parameters and a non-authoritative server should count
- down the TTL and discard RRs when the TTL is zero (even for a SIG
- that has not yet reached its authentication expiration time). In
- addition, when RRs are transmitted in a query response, the TTL
-
-
-
-
-Eastlake Standards Track [Page 23]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- should be trimmed so that current time plus the TTL does not extend
- beyond the authentication expiration time. Thus, in general, the TTL
- on a transmitted RR would be
-
- min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
-
- When signatures are generated, signature expiration times should be
- set far enough in the future that it is quite certain that new
- signatures can be generated before the old ones expire. However,
- setting expiration too far into the future could mean a long time to
- flush any bad data or signatures that may have been generated.
-
- It is recommended that signature lifetime be a small multiple of the
- TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
- maximum re-signing interval and not less than the zone expiry time.
-
-5. Non-existent Names and Types
-
- The SIG RR mechanism described in Section 4 above provides strong
- authentication of RRs that exist in a zone. But it is not clear
- above how to verifiably deny the existence of a name in a zone or a
- type for an existent name.
-
- The nonexistence of a name in a zone is indicated by the NXT ("next")
- RR for a name interval containing the nonexistent name. An NXT RR or
- RRs and its or their SIG(s) are returned in the authority section,
- along with the error, if the server is security aware. The same is
- true for a non-existent type under an existing name except that there
- is no error indication other than an empty answer section
- accompanying the NXT(s). This is a change in the existing standard
- [RFCs 1034/1035] which contemplates only NS and SOA RRs in the
- authority section. NXT RRs will also be returned if an explicit query
- is made for the NXT type.
-
- The existence of a complete set of NXT records in a zone means that
- any query for any name and any type to a security aware server
- serving the zone will result in an reply containing at least one
- signed RR unless it is a query for delegation point NS or glue A or
- AAAA RRs.
-
-5.1 The NXT Resource Record
-
- The NXT resource record is used to securely indicate that RRs with an
- owner name in a certain name interval do not exist in a zone and to
- indicate what RR types are present for an existing name.
-
-
-
-
-
-
-Eastlake Standards Track [Page 24]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- The owner name of the NXT RR is an existing name in the zone. It's
- RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone
- create a chain of all of the literal owner names in that zone,
- including unexpanded wildcards but omitting the owner name of glue
- address records unless they would otherwise be included. This implies
- a canonical ordering of all domain names in a zone as described in
- Section 8. The presence of the NXT RR means that no name between its
- owner name and the name in its RDATA area exists and that no other
- types exist under its owner name.
-
- There is a potential problem with the last NXT in a zone as it wants
- to have an owner name which is the last existing name in canonical
- order, which is easy, but it is not obvious what name to put in its
- RDATA to indicate the entire remainder of the name space. This is
- handled by treating the name space as circular and putting the zone
- name in the RDATA of the last NXT in a zone.
-
- The NXT RRs for a zone SHOULD be automatically calculated and added
- to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed
- the zone minimum TTL.
-
- The type number for the NXT RR is 30.
-
- NXT RRs are only signed by zone level keys.
-
-5.2 NXT RDATA Format
-
- The RDATA for an NXT RR consists simply of a domain name followed by
- a bit map, 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 map /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The NXT RR type bit map format currently defined is one bit per RR
- type present for the owner name. A one bit indicates that at least
- one RR of that type is present for the owner name. A zero indicates
- that no such RR is present. All bits not specified because they are
- beyond the end of the bit map are assumed to be zero. Note that bit
- 30, for NXT, will always be on so the minimum bit map length is
- actually four octets. Trailing zero octets are prohibited in this
- format. The first bit represents RR type zero (an illegal type which
- can not be present) and so will be zero in this format. This format
- is not used if there exists an RR with a type number greater than
-
-
-
-Eastlake Standards Track [Page 25]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 127. If the zero bit of the type bit map is a one, it indicates that
- a different format is being used which will always be the case if a
- type number greater than 127 is present.
-
- The domain name may be compressed with standard DNS name compression
- when being transmitted over the network. The size of the bit map can
- be inferred from the RDLENGTH and the length of the next domain name.
-
-5.3 Additional Complexity Due to Wildcards
-
- Proving that a non-existent name response is correct or that a
- wildcard expansion response is correct makes things a little more
- complex.
-
- In particular, when a non-existent name response is returned, an NXT
- must be returned showing that the exact name queried did not exist
- and, in general, one or more additional NXT's need to be returned to
- also prove that there wasn't a wildcard whose expansion should have
- been returned. (There is no need to return multiple copies of the
- same NXT.) These NXTs, if any, are returned in the authority section
- of the response.
-
- Furthermore, if a wildcard expansion is returned in a response, in
- general one or more NXTs needs to also be returned in the authority
- section to prove that no more specific name (including possibly more
- specific wildcards in the zone) existed on which the response should
- have been based.
-
-5.4 Example
-
- Assume zone foo.nil has entries for
-
- big.foo.nil,
- medium.foo.nil.
- small.foo.nil.
- tiny.foo.nil.
-
- Then a query to a security aware server for huge.foo.nil would
- produce an error reply with an RCODE of NXDOMAIN and the authority
- section data including something like the following:
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 26]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
- foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
- 19970102030405 ;signature expiration
- 19961211100908 ;signature inception
- 2143 ;key identifier
- foo.nil. ;signer
- AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
- fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
- )
- big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil
- big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
- 19970102030405 ;signature expiration
- 19961211100908 ;signature inception
- 2143 ;key identifier
- foo.nil. ;signer
- MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
- 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
- )
- Note that this response implies that big.foo.nil is an existing name
- in the zone and thus has other RR types associated with it than NXT.
- However, only the NXT (and its SIG) RR appear in the response to this
- query for huge.foo.nil, which is a non-existent name.
-
-5.5 Special Considerations at Delegation Points
-
- A name (other than root) which is the head of a zone also appears as
- the leaf in a superzone. If both are secure, there will always be
- two different NXT RRs with the same name. They can be easily
- distinguished by their signers, the next domain name fields, the
- presence of the SOA type bit, etc. Security aware servers should
- return the correct NXT automatically when required to authenticate
- the non-existence of a name and both NXTs, if available, on explicit
- query for type NXT.
-
- Non-security aware servers will never automatically return an NXT and
- some old implementations may only return the NXT from the subzone on
- explicit queries.
-
-5.6 Zone Transfers
-
- The subsections below describe how full and incremental zone
- transfers are secured.
-
- SIG RRs secure all authoritative RRs transferred for both full and
- incremental [RFC 1995] zone transfers. NXT RRs are an essential
- element in secure zone transfers and assure that every authoritative
- name and type will be present; however, if there are multiple SIGs
- with the same name and type covered, a subset of the SIGs could be
-
-
-
-Eastlake Standards Track [Page 27]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- sent as long as at least one is present and, in the case of unsigned
- delegation point NS or glue A or AAAA RRs a subset of these RRs or
- simply a modified set could be sent as long as at least one of each
- type is included.
-
- When an incremental or full zone transfer request is received with
- the same or newer version number than that of the server's copy of
- the zone, it is replied to with just the SOA RR of the server's
- current version and the SIG RRset verifying that SOA RR.
-
- The complete NXT chains specified in this document enable a resolver
- to obtain, by successive queries chaining through NXTs, all of the
- names in a zone even if zone transfers are prohibited. Different
- format NXTs may be specified in the future to avoid this.
-
-5.6.1 Full Zone Transfers
-
- To provide server authentication that a complete transfer has
- occurred, transaction authentication SHOULD be used on full zone
- transfers. This provides strong server based protection for the
- entire zone in transit.
-
-5.6.2 Incremental Zone Transfers
-
- Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be
- verified in the same way as for a full zone transfer and the
- integrity of the NXT name chain and correctness of the NXT type bits
- for the zone after the incremental RR deletes and adds can check each
- disjoint area of the zone updated. But the completeness of an
- incremental transfer can not be confirmed because usually neither the
- deleted RR section nor the added RR section has a compete zone NXT
- chain. As a result, a server which securely supports IXFR must
- handle IXFR SIG RRs for each incremental transfer set that it
- maintains.
-
- The IXFR SIG is calculated over the incremental zone update
- collection of RRs in the order in which it is transmitted: old SOA,
- then deleted RRs, then new SOA and added RRs. Within each section,
- RRs must be ordered as specified in Section 8. If condensation of
- adjacent incremental update sets is done by the zone owner, the
- original IXFR SIG for each set included in the condensation must be
- discarded and a new on IXFR SIG calculated to cover the resulting
- condensed set.
-
- The IXFR SIG really belongs to the zone as a whole, not to the zone
- name. Although it SHOULD be correct for the zone name, the labels
- field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only
- sent as part of an incremental zone transfer. After validation of
-
-
-
-Eastlake Standards Track [Page 28]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- the IXFR SIG, the transferred RRs MAY be considered valid without
- verification of the internal SIGs if such trust in the server
- conforms to local policy.
-
-6. How to Resolve Securely and the AD and CD Bits
-
- Retrieving or resolving secure data from the Domain Name System (DNS)
- involves starting with one or more trusted public keys that have been
- staticly configured at the resolver. With starting trusted keys, a
- resolver willing to perform cryptography can progress securely
- through the secure DNS structure to the zone of interest as described
- in Section 6.3. Such trusted public keys would normally be configured
- in a manner similar to that described in Section 6.2. However, as a
- practical matter, a security aware resolver would still gain some
- confidence in the results it returns even if it was not configured
- with any keys but trusted what it got from a local well known server
- as if it were staticly configured.
-
- Data stored at a security aware server needs to be internally
- categorized as Authenticated, Pending, or Insecure. There is also a
- fourth transient state of Bad which indicates that all SIG checks
- have explicitly failed on the data. Such Bad data is not retained at
- a security aware server. Authenticated means that the data has a
- valid SIG under a KEY traceable via a chain of zero or more SIG and
- KEY RRs allowed by the resolvers policies to a KEY staticly
- configured at the resolver. Pending data has no authenticated SIGs
- and at least one additional SIG the resolver is still trying to
- authenticate. Insecure data is data which it is known can never be
- either Authenticated or found Bad in the zone where it was found
- because it is in or has been reached via a unsecured zone or because
- it is unsigned glue address or delegation point NS data. Behavior in
- terms of control of and flagging based on such data labels is
- described in Section 6.1.
-
- The proper validation of signatures requires a reasonably secure
- shared opinion of the absolute time between resolvers and servers as
- described in Section 6.4.
-
-6.1 The AD and CD Header Bits
-
- Two previously unused bits are allocated out of the DNS
- query/response format header. The AD (authentic data) bit indicates
- in a response that all the data included in the answer and authority
- portion of the response has been authenticated by the server
- according to the policies of that server. The CD (checking disabled)
- bit indicates in a query that Pending (non-authenticated) data is
- acceptable to the resolver sending the query.
-
-
-
-
-Eastlake Standards Track [Page 29]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- These bits are allocated from the previously must-be-zero Z field as
- follows:
-
- 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 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- These bits are zero in old servers and resolvers. Thus the responses
- of old servers are not flagged as authenticated to security aware
- resolvers and queries from non-security aware resolvers do not assert
- the checking disabled bit and thus will be answered by security aware
- servers only with Authenticated or Insecure data. Security aware
- resolvers MUST NOT trust the AD bit unless they trust the server they
- are talking to and either have a secure path to it or use DNS
- transaction security.
-
- Any security aware resolver willing to do cryptography SHOULD assert
- the CD bit on all queries to permit it to impose its own policies and
- to reduce DNS latency time by allowing security aware servers to
- answer with Pending data.
-
- Security aware servers MUST NOT return Bad data. For non-security
- aware resolvers or security aware resolvers requesting service by
- having the CD bit clear, security aware servers MUST return only
- Authenticated or Insecure data in the answer and authority sections
- with the AD bit set in the response. Security aware servers SHOULD
- return Pending data, with the AD bit clear in the response, to
- security aware resolvers requesting this service by asserting the CD
- bit in their request. The AD bit MUST NOT be set on a response
- unless all of the RRs in the answer and authority sections of the
- response are either Authenticated or Insecure. The AD bit does not
- cover the additional information section.
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 30]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-6.2 Staticly Configured Keys
-
- The public key to authenticate a zone SHOULD be defined in local
- configuration files before that zone is loaded at the primary server
- so the zone can be authenticated.
-
- While it might seem logical for everyone to start with a public key
- associated with the root zone and staticly configure this in every
- resolver, this has problems. The logistics of updating every DNS
- resolver in the world should this key ever change would be severe.
- Furthermore, many organizations will explicitly wish their "interior"
- DNS implementations to completely trust only their own DNS servers.
- Interior resolvers of such organizations can then go through the
- organization's zone servers to access data outside the organization's
- domain and need not be configured with keys above the organization's
- DNS apex.
-
- Host resolvers that are not part of a larger organization may be
- configured with a key for the domain of their local ISP whose
- recursive secure DNS caching server they use.
-
-6.3 Chaining Through The DNS
-
- Starting with one or more trusted keys for any zone, it should be
- possible to retrieve signed keys for that zone's subzones which have
- a key. A secure sub-zone is indicated by a KEY RR with non-null key
- information appearing with the NS RRs in the sub-zone and which may
- also be present in the parent. These make it possible to descend
- within the tree of zones.
-
-6.3.1 Chaining Through KEYs
-
- In general, some RRset that you wish to validate in the secure DNS
- will be signed by one or more SIG RRs. Each of these SIG RRs has a
- signer under whose name is stored the public KEY to use in
- authenticating the SIG. Each of those KEYs will, generally, also be
- signed with a SIG. And those SIGs will have signer names also
- referring to KEYs. And so on. As a result, authentication leads to
- chains of alternating SIG and KEY RRs with the first SIG signing the
- original data whose authenticity is to be shown and the final KEY
- being some trusted key staticly configured at the resolver performing
- the authentication.
-
- In testing such a chain, the validity periods of the SIGs encountered
- must be intersected to determine the validity period of the
- authentication of the data, a purely algorithmic process. In
- addition, the validation of each SIG over the data with reference to
- a KEY must meet the objective cryptographic test implied by the
-
-
-
-Eastlake Standards Track [Page 31]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- cryptographic algorithm used (although even here the resolver may
- have policies as to trusted algorithms and key lengths). Finally,
- the judgement that a SIG with a particular signer name can
- authenticate data (possibly a KEY RRset) with a particular owner
- name, is primarily a policy question. Ultimately, this is a policy
- local to the resolver and any clients that depend on that resolver's
- decisions. It is, however, recommended, that the policy below be
- adopted:
-
- Let A < B mean that A is a shorter domain name than B formed by
- dropping one or more whole labels from the left end of B, i.e.,
- A is a direct or indirect superdomain of B. Let A = B mean that
- A and B are the same domain name (i.e., are identical after
- letter case canonicalization). Let A > B mean that A is a
- longer domain name than B formed by adding one or more whole
- labels on the left end of B, i.e., A is a direct or indirect
- subdomain of B
-
- Let Static be the owner names of the set of staticly configured
- trusted keys at a resolver.
-
- Then Signer is a valid signer name for a SIG authenticating an
- RRset (possibly a KEY RRset) with owner name Owner at the
- resolver if any of the following three rules apply:
-
- (1) Owner > or = Signer (except that if Signer is root, Owner
- must be root or a top level domain name). That is, Owner is the
- same as or a subdomain of Signer.
-
- (2) ( Owner < Signer ) and ( Signer > or = some Static ). That
- is, Owner is a superdomain of Signer and Signer is staticly
- configured or a subdomain of a staticly configured key.
-
- (3) Signer = some Static. That is, the signer is exactly some
- staticly configured key.
-
- Rule 1 is the rule for descending the DNS tree and includes a special
- prohibition on the root zone key due to the restriction that the root
- zone be only one label deep. This is the most fundamental rule.
-
- Rule 2 is the rule for ascending the DNS tree from one or more
- staticly configured keys. Rule 2 has no effect if only root zone
- keys are staticly configured.
-
- Rule 3 is a rule permitting direct cross certification. Rule 3 has
- no effect if only root zone keys are staticly configured.
-
-
-
-
-
-Eastlake Standards Track [Page 32]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- Great care should be taken that the consequences have been fully
- considered before making any local policy adjustments to these rules
- (other than dispensing with rules 2 and 3 if only root zone keys are
- staticly configured).
-
-6.3.2 Conflicting Data
-
- It is possible that there will be multiple SIG-KEY chains that appear
- to authenticate conflicting RRset answers to the same query. A
- resolver should choose only the most reliable answer to return and
- discard other data. This choice of most reliable is a matter of
- local policy which could take into account differing trust in
- algorithms, key sizes, staticly configured keys, zones traversed,
- etc. The technique given below is recommended for taking into
- account SIG-KEY chain length.
-
- A resolver should keep track of the number of successive secure zones
- traversed from a staticly configured key starting point to any secure
- zone it can reach. In general, the lower such a distance number is,
- the greater the confidence in the data. Staticly configured data
- should be given a distance number of zero. If a query encounters
- different Authenticated data for the same query with different
- distance values, that with a larger value should be ignored unless
- some other local policy covers the case.
-
- A security conscious resolver should completely refuse to step from a
- secure zone into a unsecured zone unless the unsecured zone is
- certified to be non-secure by the presence of an authenticated KEY RR
- for the unsecured zone with the no-key type value. Otherwise the
- resolver is getting bogus or spoofed data.
-
- If legitimate unsecured zones are encountered in traversing the DNS
- tree, then no zone can be trusted as secure that can be reached only
- via information from such non-secure zones. Since the unsecured zone
- data could have been spoofed, the "secure" zone reached via it could
- be counterfeit. The "distance" to data in such zones or zones
- reached via such zones could be set to 256 or more as this exceeds
- the largest possible distance through secure zones in the DNS.
-
-6.4 Secure Time
-
- Coordinated interpretation of the time fields in SIG RRs requires
- that reasonably consistent time be available to the hosts
- implementing the DNS security extensions.
-
- A variety of time synchronization protocols exist including the
- Network Time Protocol (NTP [RFC 1305, 2030]). If such protocols are
- used, they MUST be used securely so that time can not be spoofed.
-
-
-
-Eastlake Standards Track [Page 33]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- Otherwise, for example, a host could get its clock turned back and
- might then believe old SIG RRs, and the data they authenticate, which
- were valid but are no longer.
-
-7. ASCII Representation of Security RRs
-
- This section discusses the format for master file and other ASCII
- presentation of the three DNS security resource records.
-
- The algorithm field in KEY and SIG RRs can be represented as either
- an unsigned integer or symbolicly. The following initial symbols are
- defined as indicated:
-
- Value Symbol
-
- 001 RSAMD5
- 002 DH
- 003 DSA
- 004 ECC
- 252 INDIRECT
- 253 PRIVATEDNS
- 254 PRIVATEOID
-
-7.1 Presentation of KEY RRs
-
- KEY RRs may appear as single logical lines in a zone data master file
- [RFC 1033].
-
- The flag field is represented as an unsigned integer or a sequence of
- mnemonics as follows separated by instances of the verticle bar ("|")
- character:
-
- BIT Mnemonic Explanation
- 0-1 key type
- NOCONF =1 confidentiality use prohibited
- NOAUTH =2 authentication use prohibited
- NOKEY =3 no key present
- 2 FLAG2 - reserved
- 3 EXTEND flags extension
- 4 FLAG4 - reserved
- 5 FLAG5 - reserved
- 6-7 name type
- USER =0 (default, may be omitted)
- ZONE =1
- HOST =2 (host or other end entity)
- NTYP3 - reserved
- 8 FLAG8 - reserved
- 9 FLAG9 - reserved
-
-
-
-Eastlake Standards Track [Page 34]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 10 FLAG10 - reserved
- 11 FLAG11 - reserved
- 12-15 signatory field, values 0 to 15
- can be represented by SIG0, SIG1, ... SIG15
-
- No flag mnemonic need be present if the bit or field it represents is
- zero.
-
- The protocol octet can be represented as either an unsigned integer
- or symbolicly. The following initial symbols are defined:
-
- 000 NONE
- 001 TLS
- 002 EMAIL
- 003 DNSSEC
- 004 IPSEC
- 255 ALL
-
- Note that if the type flags field has the NOKEY value, nothing
- appears after the algorithm octet.
-
- The remaining public key portion is represented in base 64 (see
- Appendix A) 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.
-
- Note that the public key may have internal sub-fields but these do
- not appear in the master file representation. For example, with
- algorithm 1 there is a public exponent size, then a public exponent,
- and then a modulus. With algorithm 254, there will be an OID size,
- an OID, and algorithm dependent information. But in both cases only a
- single logical base 64 string will appear in the master file.
-
-7.2 Presentation of SIG RRs
-
- A data SIG RR may be represented as a single logical line in a zone
- data file [RFC 1033] but there are some special considerations as
- described below. (It does not make sense to include a transaction or
- request authenticating SIG RR in a file as they are a transient
- authentication that covers data including an ephemeral transaction
- number and so must be calculated in real time.)
-
- There is no particular problem with the signer, covered type, and
- times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY
- is the year, the first MM is the month number (01-12), DD is the day
- of the month (01-31), HH is the hour in 24 hours notation (00-23),
- the second MM is the minute (00-59), and SS is the second (00-59).
-
-
-
-Eastlake Standards Track [Page 35]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- The original TTL field appears as an unsigned integer.
-
- If the original TTL, which applies to the type signed, is the same as
- the TTL of the SIG RR itself, it may be omitted. The date field
- which follows it is larger than the maximum possible TTL so there is
- no ambiguity.
-
- The "labels" field appears as an unsigned integer.
-
- The key tag appears as an unsigned number.
-
- However, the signature itself can be very long. It is the last data
- field and is represented in base 64 (see Appendix A) 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 be split between lines using the
- standard parenthesis.
-
-7.3 Presentation of NXT RRs
-
- NXT RRs do not appear in original unsigned zone master files since
- they should be derived from the zone as it is being signed. If a
- signed file with NXTs added is printed or NXTs are printed by
- debugging code, they appear as the next domain name followed by the
- RR type present bits as an unsigned interger or sequence of RR
- mnemonics.
-
-8. Canonical Form and Order of Resource Records
-
- This section specifies, for purposes of domain name system (DNS)
- security, the canonical form of resource records (RRs), their name
- order, and their overall order. A canonical name order is necessary
- to construct the NXT name chain. A canonical form and ordering
- within an RRset is necessary in consistently constructing and
- verifying SIG RRs. A canonical ordering of types within a name is
- required in connection with incremental transfer (Section 5.6.2).
-
-8.1 Canonical RR Form
-
- For purposes of DNS security, the canonical form for an RR is the
- wire format of the RR with domain names (1) fully expanded (no name
- compression via pointers), (2) all domain name letters set to lower
- case, (3) owner name wild cards in master file form (no substitution
- made for *), and (4) the original TTL substituted for the current
- TTL.
-
-
-
-
-
-
-Eastlake Standards Track [Page 36]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-8.2 Canonical DNS Name Order
-
- For purposes of DNS security, the canonical ordering of owner names
- is to sort individual labels as unsigned left justified octet strings
- where the absence of a octet sorts before a zero value octet and
- upper case letters are treated as lower case letters. Names in a
- zone are sorted by sorting on the highest level label and then,
- within those names with the same highest level label by the next
- lower label, etc. down to leaf node labels. Within a zone, the zone
- name itself always exists and all other names are the zone name with
- some prefix of lower level labels. Thus the zone name itself always
- sorts first.
-
- Example:
- foo.example
- a.foo.example
- yljkjljk.a.foo.example
- Z.a.foo.example
- zABC.a.FOO.EXAMPLE
- z.foo.example
- *.z.foo.example
- \200.z.foo.example
-
-8.3 Canonical RR Ordering Within An RRset
-
- Within any particular owner name and type, RRs are sorted by RDATA as
- a left justified unsigned octet sequence where the absence of an
- octet sorts before the zero octet.
-
-8.4 Canonical Ordering of RR Types
-
- When RRs of the same name but different types must be ordered, they
- are ordered by type, considering the type to be an unsigned integer,
- except that SIG RRs are placed immediately after the type they cover.
- Thus, for example, an A record would be put before an MX record
- because A is type 1 and MX is type 15 but if both were signed, the
- order would be A < SIG(A) < MX < SIG(MX).
-
-9. Conformance
-
- Levels of server and resolver conformance are defined below.
-
-9.1 Server Conformance
-
- Two levels of server conformance for DNS security are defined as
- follows:
-
-
-
-
-
-Eastlake Standards Track [Page 37]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- BASIC: Basic server compliance is the ability to store and retrieve
- (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or
- caching server for a secure zone MUST have at least basic compliance
- and even then some things, such as secure CNAMEs, will not work
- without full compliance.
-
- FULL: Full server compliance adds the following to basic compliance:
- (1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
- ability, given a zone file and private key, to add appropriate SIG
- and NXT RRs, possibly via a separate application, (3) proper
- automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
- suppression of CNAME following on retrieval of the security type RRs,
- (5) recognize the CD query header bit and set the AD query header
- bit, as appropriate, and (6) proper handling of the two NXT RRs at
- delegation points. Primary servers for secure zones MUST be fully
- compliant and for complete secure operation, all secondary, caching,
- and other servers handling the zone SHOULD be fully compliant as
- well.
-
-9.2 Resolver Conformance
-
- Two levels of resolver compliance (including the resolver portion of
- a server) are defined for DNS Security:
-
- BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs
- when they are explicitly requested.
-
- FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT
- RRs including verification of SIGs at least for the mandatory
- algorithm, (2) maintains appropriate information in its local caches
- and database to indicate which RRs have been authenticated and to
- what extent they have been authenticated, (3) performs additional
- queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when
- needed, (4) normally sets the CD query header bit on its queries.
-
-10. Security Considerations
-
- This document specifies extensions to the Domain Name System (DNS)
- protocol to provide data integrity and data origin authentication,
- public key distribution, and optional transaction and request
- security.
-
- It should be noted that, at most, these extensions guarantee the
- validity of resource records, including KEY resource records,
- retrieved from the DNS. They do not magically solve other security
- problems. For example, using secure DNS you can have high confidence
- in the IP address you retrieve for a host name; however, this does
- not stop someone for substituting an unauthorized host at that
-
-
-
-Eastlake Standards Track [Page 38]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- address or capturing packets sent to that address and falsely
- responding with packets apparently from that address. Any reasonably
- complete security system will require the protection of many
- additional facets of the Internet beyond DNS.
-
- The implementation of NXT RRs as described herein enables a resolver
- to determine all the names in a zone even if zone transfers are
- prohibited (section 5.6). This is an active area of work and may
- change.
-
- A number of precautions in DNS implementation have evolved over the
- years to harden the insecure DNS against spoofing. These precautions
- should not be abandoned but should be considered to provide
- additional protection in case of key compromise in secure DNS.
-
-11. IANA Considerations
-
- KEY RR flag bits 2 and 8-11 and all flag extension field bits can be
- assigned by IETF consensus as defined in RFC 2434. The remaining
- values of the NAMTYP flag field and flag bits 4 and 5 (which could
- conceivably become an extension of the NAMTYP field) can only be
- assigned by an IETF Standards Action [RFC 2434].
-
- Algorithm numbers 5 through 251 are available for assignment should
- sufficient reason arise. However, the designation of a new algorithm
- could have a major impact on interoperability and requires an IETF
- Standards Action [RFC 2434]. The existence of the private algorithm
- types 253 and 254 should satify most needs for private or proprietary
- algorithms.
-
- Additional values of the Protocol Octet (5-254) can be assigned by
- IETF Consensus [RFC 2434].
-
- The meaning of the first bit of the NXT RR "type bit map" being a one
- can only be assigned by a standards action.
-
-References
-
- [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", RFC
- 1033, November 1987.
-
- [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.
-
-
-
-
-
-Eastlake Standards Track [Page 39]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- [RFC 1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, March
- 1992.
-
- [RFC 1530] Malamud, C. and M. Rose, "Principles of Operation for the
- TPC.INT Subdomain: General Principles and Policy", RFC
- 1530, October 1993.
-
- [RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
- 1982, September 1996.
-
- [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-
- [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
- for IPv4, IPv6 and OSI", RFC 2030, October 1996.
-
- [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
- [RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
- Extensions", RFC 2065, January 1997.
-
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [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 2137] Eastlake, D., "Secure Domain Name System Dynamic Update",
- RFC 2137, 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 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
- System (DNS)", RFC 2537, March 1999.
-
- [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
- Domain Name System (DNS)", RFC 2539, March 1999.
-
-
-
-Eastlake Standards Track [Page 40]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- [RFC 2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
- System (DNS)", RFC 2536, March 1999.
-
- [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
- the Domain Name System", RFC 2538, March 1999.
-
- [RFC 2541] Eastlake, D., "DNS Operational Security Considerations",
- RFC 2541, March 1999.
-
- [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
-
-Author's Address
-
- Donald E. Eastlake 3rd
- IBM
- 65 Shindegan Hill Road
- RR #1
- Carmel, NY 10512
-
- Phone: +1-914-784-7913 (w)
- +1-914-276-2668 (h)
- Fax: +1-914-784-3833 (w-fax)
- EMail: dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 41]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-Appendix A: Base 64 Encoding
-
- The following encoding technique is taken from [RFC 2045] by N.
- Borenstein and N. Freed. It is reproduced here in an edited form for
- convenience.
-
- A 65-character subset of US-ASCII is used, enabling 6 bits to be
- represented per printable character. (The extra 65th character, "=",
- is used to signify a special processing function.)
-
- The encoding process represents 24-bit groups of input bits as output
- strings of 4 encoded characters. Proceeding from left to right, a
- 24-bit input group is formed by concatenating 3 8-bit input groups.
- These 24 bits are then treated as 4 concatenated 6-bit groups, each
- of which is translated into a single digit in the base 64 alphabet.
-
- Each 6-bit group is used as an index into an array of 64 printable
- characters. The character referenced by the index is placed in the
- output string.
-
- Table 1: The Base 64 Alphabet
-
- Value Encoding Value Encoding Value Encoding Value Encoding
- 0 A 17 R 34 i 51 z
- 1 B 18 S 35 j 52 0
- 2 C 19 T 36 k 53 1
- 3 D 20 U 37 l 54 2
- 4 E 21 V 38 m 55 3
- 5 F 22 W 39 n 56 4
- 6 G 23 X 40 o 57 5
- 7 H 24 Y 41 p 58 6
- 8 I 25 Z 42 q 59 7
- 9 J 26 a 43 r 60 8
- 10 K 27 b 44 s 61 9
- 11 L 28 c 45 t 62 +
- 12 M 29 d 46 u 63 /
- 13 N 30 e 47 v
- 14 O 31 f 48 w (pad) =
- 15 P 32 g 49 x
- 16 Q 33 h 50 y
-
- Special processing is performed if fewer than 24 bits are available
- at the end of the data being encoded. A full encoding quantum is
- always completed at the end of a quantity. When fewer than 24 input
- bits are available in an input group, zero bits are added (on the
- right) to form an integral number of 6-bit groups. Padding at the
- end of the data is performed using the '=' character. Since all base
- 64 input is an integral number of octets, only the following cases
-
-
-
-Eastlake Standards Track [Page 42]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- can arise: (1) the final quantum of encoding input is an integral
- multiple of 24 bits; here, the final unit of encoded output will be
- an integral multiple of 4 characters with no "=" padding, (2) the
- final quantum of encoding input is exactly 8 bits; here, the final
- unit of encoded output will be two characters followed by two "="
- padding characters, or (3) the final quantum of encoding input is
- exactly 16 bits; here, the final unit of encoded output will be three
- characters followed by one "=" padding character.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 43]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-Appendix B: Changes from RFC 2065
-
- This section summarizes the most important changes that have been
- made since RFC 2065.
-
- 1. Most of Section 7 of [RFC 2065] called "Operational
- Considerations", has been removed and may be made into a separate
- document [RFC 2541].
-
- 2. The KEY RR has been changed by (2a) eliminating the "experimental"
- flag as unnecessary, (2b) reserving a flag bit for flags
- expansion, (2c) more compactly encoding a number of bit fields in
- such a way as to leave unchanged bits actually used by the limited
- code currently deployed, (2d) eliminating the IPSEC and email flag
- bits which are replaced by values of the protocol field and adding
- a protocol field value for DNS security itself, (2e) adding
- material to indicate that zone KEY RRs occur only at delegation
- points, and (2f) removing the description of the RSA/MD5 algorithm
- to a separate document [RFC 2537]. Section 3.4 describing the
- meaning of various combinations of "no-key" and key present KEY
- RRs has been added and the secure / unsecure status of a zone has
- been clarified as being per algorithm.
-
- 3. The SIG RR has been changed by (3a) renaming the "time signed"
- field to be the "signature inception" field, (3b) clarifying that
- signature expiration and inception use serial number ring
- arithmetic, (3c) changing the definition of the key footprint/tag
- for algorithms other than 1 and adding Appendix C to specify its
- calculation. In addition, the SIG covering type AXFR has been
- eliminated while one covering IXFR [RFC 1995] has been added (see
- section 5.6).
-
- 4. Algorithm 3, the DSA algorithm, is now designated as the mandatory
- to implement algorithm. Algorithm 1, the RSA/MD5 algorithm, is
- now a recommended option. Algorithm 2 and 4 are designated as the
- Diffie-Hellman key and elliptic cryptography algorithms
- respectively, all to be defined in separate documents. Algorithm
- code point 252 is designated to indicate "indirect" keys, to be
- defined in a separate document, where the actual key is elsewhere.
- Both the KEY and SIG RR definitions have been simplified by
- eliminating the "null" algorithm 253 as defined in [RFC 2065].
- That algorithm had been included because at the time it was
- thought it might be useful in DNS dynamic update [RFC 2136]. It
- was in fact not so used and it is dropped to simplify DNS
- security. Howver, that algorithm number has been re-used to
- indicate private algorithms where a domain name specifies the
- algorithm.
-
-
-
-
-Eastlake Standards Track [Page 44]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
- 5. The NXT RR has been changed so that (5a) the NXT RRs in a zone
- cover all names, including wildcards as literal names without
- expansion, except for glue address records whose names would not
- otherwise appear, (5b) all NXT bit map areas whose first octet has
- bit zero set have been reserved for future definition, (5c) the
- number of and circumstances under which an NXT must be returned in
- connection with wildcard names has been extended, and (5d) in
- connection with the bit map, references to the WKS RR have been
- removed and verticle bars ("|") have been added between the RR
- type mnemonics in the ASCII representation.
-
- 6. Information on the canonical form and ordering of RRs has been
- moved into a separate Section 8.
-
- 7. A subsection covering incremental and full zone transfer has been
- added in Section 5.
-
- 8. Concerning DNS chaining: Further specification and policy
- recommendations on secure resolution have been added, primarily in
- Section 6.3.1. It is now clearly stated that authenticated data
- has a validity period of the intersection of the validity periods
- of the SIG RRs in its authentication chain. The requirement to
- staticly configure a superzone's key signed by a zone in all of
- the zone's authoritative servers has been removed. The
- recommendation to continue DNS security checks in a secure island
- of DNS data that is separated from other parts of the DNS tree by
- insecure zones and does not contain a zone for which a key has
- been staticly configured was dropped.
-
- 9. It was clarified that the presence of the AD bit in a response
- does not apply to the additional information section or to glue
- address or delegation point NS RRs. The AD bit only indicates
- that the answer and authority sections of the response are
- authoritative.
-
- 10. It is now required that KEY RRs and NXT RRs be signed only with
- zone-level keys.
-
- 11. Add IANA Considerations section and references to RFC 2434.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 45]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-Appendix C: Key Tag Calculation
-
- The key tag field in the SIG RR is just a means of more efficiently
- selecting the correct KEY RR to use when there is more than one KEY
- RR candidate available, for example, in verifying a signature. It is
- possible for more than one candidate key to have the same tag, in
- which case each must be tried until one works or all fail. The
- following reference implementation of how to calculate the Key Tag,
- for all algorithms other than algorithm 1, is in ANSI C. It is coded
- for clarity, not efficiency. (See section 4.1.6 for how to determine
- the Key Tag of an algorithm 1 key.)
-
- /* assumes int is at least 16 bits
- first byte of the key tag is the most significant byte of return
- value
- second byte of the key tag is the least significant byte of
- return value
- */
-
- int keytag (
-
- unsigned char key[], /* the RDATA part of the KEY RR */
- unsigned int keysize, /* the RDLENGTH */
- )
- {
- long int ac; /* assumed to be 32 bits or larger */
-
- for ( ac = 0, i = 0; i < keysize; ++i )
- ac += (i&1) ? key[i] : key[i]<<8;
- ac += (ac>>16) & 0xFFFF;
- return ac & 0xFFFF;
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 46]
-
-RFC 2535 DNS Security Extensions March 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 47]
-
diff --git a/contrib/bind9/doc/rfc/rfc2536.txt b/contrib/bind9/doc/rfc/rfc2536.txt
deleted file mode 100644
index 88be242bb7d07..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2536.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. EastLake
-Request for Comments: 2536 IBM
-Category: Standards Track March 1999
-
-
- DSA KEYs and SIGs in the Domain Name System (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 (1999). All Rights Reserved.
-
-Abstract
-
- A standard method for storing US Government Digital Signature
- Algorithm keys and signatures in the Domain Name System is described
- which utilizes DNS KEY and SIG resource records.
-
-Table of Contents
-
- Abstract...................................................1
- 1. Introduction............................................1
- 2. DSA KEY Resource Records................................2
- 3. DSA SIG Resource Records................................3
- 4. Performance Considerations..............................3
- 5. Security Considerations.................................4
- 6. IANA Considerations.....................................4
- References.................................................5
- Author's Address...........................................5
- Full Copyright Statement...................................6
-
-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 2535]. Thus
- the DNS can now be secured and can be used for secure key
- distribution.
-
-
-
-
-
-Eastlake Standards Track [Page 1]
-
-RFC 2536 DSA in the DNS March 1999
-
-
- This document describes how to store US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [Schneier]. Implementation
- of DSA is mandatory for DNS security.
-
-2. DSA KEY Resource Records
-
- DSA public keys are stored in the DNS as KEY RRs using algorithm
- number 3 [RFC 2535]. The structure of the algorithm specific portion
- of the RDATA part of this RR is as shown below. These fields, from Q
- through Y are the "public key" part of the DSA KEY RR.
-
- The period of key validity is not in the KEY RR but is indicated by
- the SIG RR(s) which signs and authenticates the KEY RR(s) at that
- domain name.
-
- 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] and [Schneier]: T is a key size parameter
- chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T
- octet is greater than 8 is reserved and the remainder of the RDATA
- portion 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
- so 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 key generation algorithm [Schneier]. P is
- in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
- octets long. G and Y are quantities modulus 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
-
- Y = G**X mod P
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 2]
-
-RFC 2536 DSA in the DNS March 1999
-
-
-3. DSA SIG Resource Records
-
- The signature portion of the SIG RR RDATA area, when using the US
- Digital Signature Algorithm, is shown below with fields in the order
- they occur. See [RFC 2535] for fields in the SIG RR RDATA which
- precede the signature itself.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- The data signed is determined as specified in [RFC 2535]. Then the
- following steps are taken, as specified in [FIPS 186], 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
-
- 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 specified.
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 2537] 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 KEY RRs used in domain name system (DNS) data
- authentication.
-
- Current DNS implementations are optimized for small transfers,
- typically less 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
- reasonable efforts to minimize the size of KEY RR sets stored within
-
-
-
-Eastlake Standards Track [Page 3]
-
-RFC 2536 DSA in the DNS March 1999
-
-
- the DNS consistent with adequate security. Keep in mind that in a
- secure zone, at least one authenticating SIG RR will also be
- returned.
-
-5. Security Considerations
-
- Many of the general security consideration in [RFC 2535] apply. 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 particularly
- critical 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 [RFC 1750] for guidance. DSA is designed so that if
- manipulated rather than random numbers are used, very 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 requires an IETF standards actions. It is intended
- that values unallocated herein be used to cover future extensions of
- the DSS standard.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 4]
-
-RFC 2536 DSA in the DNS March 1999
-
-
-References
-
- [FIPS 186] U.S. Federal Information Processing Standard: Digital
- Signature Standard.
-
- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
- [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
- System (DNS)", RFC 2537, March 1999.
-
- [Schneier] Schneier, B., "Applied Cryptography Second Edition:
- protocols, algorithms, and source code in C", 1996.
-
-Author's Address
-
- Donald E. Eastlake 3rd
- IBM
- 65 Shindegan Hill Road, RR #1
- Carmel, NY 10512
-
- Phone: +1-914-276-2668(h)
- +1-914-784-7913(w)
- Fax: +1-914-784-3833(w)
- EMail: dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 5]
-
-RFC 2536 DSA in the DNS March 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2537.txt b/contrib/bind9/doc/rfc/rfc2537.txt
deleted file mode 100644
index cb75cf5b3b81d..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2537.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake
-Request for Comments: 2537 IBM
-Category: Standards Track March 1999
-
-
- RSA/MD5 KEYs and SIGs in the Domain Name System (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 (1999). All Rights Reserved.
-
-Abstract
-
- A standard method for storing RSA keys and and RSA/MD5 based
- signatures in the Domain Name System is described which utilizes DNS
- KEY and SIG resource records.
-
-Table of Contents
-
- Abstract...................................................1
- 1. Introduction............................................1
- 2. RSA Public KEY Resource Records.........................2
- 3. RSA/MD5 SIG Resource Records............................2
- 4. Performance Considerations..............................3
- 5. Security Considerations.................................4
- References.................................................4
- Author's Address...........................................5
- Full Copyright Statement...................................6
-
-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 2535]. Thus
- the DNS can now be secured and used for secure key distribution.
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 1]
-
-RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
-
-
- This document describes how to store RSA keys and and RSA/MD5 based
- signatures in the DNS. Familiarity with the RSA algorithm is assumed
- [Schneier]. Implementation of the RSA algorithm in DNS is
- recommended.
-
- The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
- in this document are to be interpreted as described in RFC 2119.
-
-2. RSA Public KEY Resource Records
-
- RSA public keys are stored in the DNS as KEY RRs using algorithm
- number 1 [RFC 2535]. The structure of the algorithm specific portion
- of the RDATA part of such RRs is as shown below.
-
- Field Size
- ----- ----
- exponent length 1 or 3 octets (see text)
- exponent as specified by length field
- modulus remaining space
-
- For interoperability, the exponent and modulus are each currently
- limited to 4096 bits in length. The public key exponent is a
- variable length unsigned integer. Its length in octets is
- represented as one octet if it is in the range of 1 to 255 and by a
- zero octet followed by a two octet unsigned length if it is longer
- than 255 bytes. The public key modulus field is a multiprecision
- unsigned integer. The length of the modulus can be determined from
- the RDLENGTH and the preceding RDATA fields including the exponent.
- Leading zero octets are prohibited in the exponent and modulus.
-
-3. RSA/MD5 SIG Resource Records
-
- The signature portion of the SIG RR RDATA area, when using the
- RSA/MD5 algorithm, is calculated as shown below. The data signed is
- determined as specified in [RFC 2535]. See [RFC 2535] for fields in
- the SIG RR RDATA which precede the signature itself.
-
-
- hash = MD5 ( data )
-
- signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 2]
-
-RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
-
-
- where MD5 is the message digest algorithm documented in [RFC 1321],
- "|" is concatenation, "e" is the private key exponent of the signer,
- and "n" is the modulus of the signer's public key. 01, FF, and 00
- are fixed octets of the corresponding hexadecimal value. "prefix" is
- the ASN.1 BER MD5 algorithm designator prefix specified in [RFC
- 2437], that is,
-
- hex 3020300c06082a864886f70d020505000410 [NETSEC].
-
- This prefix is included to make it easier to use RSAREF (or similar
- packages such as EuroRef). The FF octet MUST be repeated the maximum
- number of times such that the value of the quantity being
- exponentiated is the same length in octets as the value of n.
-
- (The above specifications are identical to the corresponding part of
- Public Key Cryptographic Standard #1 [RFC 2437].)
-
- The size of n, including most and least significant bits (which will
- be 1) MUST be not less than 512 bits and not more than 4096 bits. n
- and e SHOULD be chosen such that the public exponent is small.
-
- Leading zero bytes are permitted in the RSA/MD5 algorithm signature.
-
- A public exponent of 3 minimizes the effort needed to verify a
- signature. Use of 3 as the public exponent is weak for
- confidentiality uses since, if the same data can be collected
- encrypted under three different keys with an exponent of 3 then,
- using the Chinese Remainder Theorem [NETSEC], the original plain text
- can be easily recovered. This weakness is not significant for DNS
- security because we seek only authentication, not confidentiality.
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA and
- DSA [RFC 2536]. 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 with DSA when the RSA public exponent is chosen to
- be small as is recommended for KEY RRs used in domain name system
- (DNS) data authentication.
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including overhead. While larger
- transfers will perform correctly and work is underway to make larger
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 3]
-
-RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
-
-
- transfers more efficient, it is still advisable at this time to make
- reasonable efforts to minimize the size of KEY RR sets stored within
- the DNS consistent with adequate security. Keep in mind that in a
- secure zone, at least one authenticating SIG RR will also be
- returned.
-
-5. Security Considerations
-
- Many of the general security consideration in [RFC 2535] apply. 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.
-
- For interoperability, the RSA key size is limited to 4096 bits. For
- particularly critical applications, implementors are encouraged to
- consider the range of available algorithms and key sizes.
-
-References
-
- [NETSEC] Kaufman, C., Perlman, R. and M. Speciner, "Network
- Security: PRIVATE Communications in a PUBLIC World",
- Series in Computer Networking and Distributed
- Communications, 1995.
-
- [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
- Specifications Version 2.0", RFC 2437, October 1998.
-
- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321
- April 1992.
-
- [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC 2536] EastLake, D., "DSA KEYs and SIGs in the Domain Name
- System (DNS)", RFC 2536, March 1999.
-
-
-
-
-
-
-Eastlake Standards Track [Page 4]
-
-RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
-
-
- [Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
- protocols, algorithms, and source code in C", 1996, John
- Wiley and Sons, ISBN 0-471-11709-9.
-
-Author's Address
-
- Donald E. Eastlake 3rd
- IBM
- 65 Shindegan Hill Road, RR #1
- Carmel, NY 10512
-
- Phone: +1-914-276-2668(h)
- +1-914-784-7913(w)
- Fax: +1-914-784-3833(w)
- EMail: dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 5]
-
-RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2538.txt b/contrib/bind9/doc/rfc/rfc2538.txt
deleted file mode 100644
index c53e3efd15b5b..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2538.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake
-Request for Comments: 2538 IBM
-Category: Standards Track O. Gudmundsson
- TIS Labs
- March 1999
-
-
- Storing Certificates in the Domain Name System (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 (1999). All Rights Reserved.
-
-Abstract
-
- Cryptographic public key 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).
-
-Table of Contents
-
- Abstract...................................................1
- 1. Introduction............................................2
- 2. The CERT Resource Record................................2
- 2.1 Certificate Type Values................................3
- 2.2 Text Representation of CERT RRs........................4
- 2.3 X.509 OIDs.............................................4
- 3. Appropriate Owner Names for CERT RRs....................5
- 3.1 X.509 CERT RR Names....................................5
- 3.2 PGP CERT RR Names......................................6
- 4. Performance Considerations..............................6
- 5. IANA Considerations.....................................7
- 6. Security Considerations.................................7
- References.................................................8
- Authors' Addresses.........................................9
- Full Copyright Notice.....................................10
-
-
-
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 1]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
-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 PGP
- certificates/revocations used by PGP software.
-
- Section 2 below specifies a CERT resource record (RR) for the storage
- of certificates in the Domain Name System.
-
- 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 [RFC2119].
-
-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 define in section 2.1
- below.
-
- The algorithm field has the same meaning as the algorithm field in
- KEY and SIG RRs [RFC 2535] 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
- secure DNS.
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 2]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
- The key tag field is the 16 bit value computed for the key embedded
- in the certificate as specified in the DNSSEC Standard [RFC 2535].
- This field is used as an efficiency measure to pick which CERT RRs
- may be applicable to a particular key. The key 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 KEY 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.
-
-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 cert
- 3 PGP PGP cert
- 4-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 a certificate formated as to be
- specified by the IETF SPKI working group.
-
- The PGP type indicates a Pretty Good Privacy certificate as described
- in RFC 2440 and its extensions and successors.
-
- 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 [RFC 2396] 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
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 3]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
- 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 a 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
- integer or as a mnemonic symbol as listed in section 2.1 above.
-
- The key tag field is represented as an unsigned integer.
-
- The algorithm field is represented as an unsigned integer or a
- mnemonic symbol as listed in [RFC 2535].
-
- The certificate / CRL portion is represented in base 64 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.
-
- 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:
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 4]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
- 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 such as \000 for NULL.
-
-3.1 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:
-
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 5]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
- (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 it 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 PGP names in
- 3.2 below.
- (5) If none of the above apply, then the distinguished name (DN)
- should be mapped into a domain name as specified in RFC 2247.
-
- Example 1: Assume that an X.509v3 certificate is issued to /CN=John
- Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
- names of (a) string "John (the Man) Doe", (b) domain name john-
- doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>. Then
- 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: Assume that an X.509v3 certificate is issued to /CN=James
- Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
- of (a) domain name widget.foo.example, (b) IPv4 address
- 10.251.13.201, and (c) string "James Hacker
- <hacker@mail.widget.foo.example>". Then 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 PGP CERT RR Names
-
- PGP signed keys (certificates) use a general character string User ID
- [RFC 2440]. However, it is recommended by PGP that such names include
- the RFC 822 email address of the party, as in "Leslie Example
- <Leslie@host.example>". If such a format is used, the CERT should be
- under the standard translation of the email address into a domain
- name, which would be leslie.host.example in this case. If no RFC 822
- name can be extracted from the string name no specific domain name is
- recommended.
-
-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
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 6]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
- 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 extensions
- fields and using short field values for variable length fields that
- must be included.
-
-5. IANA Considerations
-
- Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
- only be assigned by an IETF standards action [RFC 2434] (and this
- document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
- Certificate types 0x0100 through 0xFEFF are assigned through IETF
- Consensus [RFC 2434] 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.
-
-6. 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,
- the key within the retrieved certificate MAY be trusted without
- verifying the certificate chain if this conforms with the user's
- security policy.
-
- CERT RRs are not used in connection with securing the DNS security
- additions so there are no security considerations related to CERT RRs
- and securing the DNS itself.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 7]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
-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 2119 Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- RFC 2247 Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
- Sataluri, "Using Domains in LDAP/X.500 Distinguished
- Names", RFC 2247, January 1998.
-
- RFC 2396 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- RFC 2440 Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
- "OpenPGP Message Format", RFC 2240, November 1998.
-
- RFC 2434 Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- RFC 2535 Eastlake, D., "Domain Name System (DNS) Security
- Extensions", RFC 2535, March 1999.
-
- RFC 2459 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
- X.509 Public Key Infrastructure Certificate and CRL
- Profile", RFC 2459, January 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 8]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
-Authors' Addresses
-
- Donald E. Eastlake 3rd
- IBM
- 65 Shindegan Hill Road
- RR#1
- Carmel, NY 10512 USA
-
- Phone: +1-914-784-7913 (w)
- +1-914-276-2668 (h)
- Fax: +1-914-784-3833 (w-fax)
- EMail: dee3@us.ibm.com
-
-
- Olafur Gudmundsson
- TIS Labs at Network Associates
- 3060 Washington Rd, Route 97
- Glenwood MD 21738
-
- Phone: +1 443-259-2389
- EMail: ogud@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 9]
-
-RFC 2538 Storing Certificates in the DNS March 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson Standards Track [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2539.txt b/contrib/bind9/doc/rfc/rfc2539.txt
deleted file mode 100644
index cf32523d9fa11..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2539.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake
-Request for Comments: 2539 IBM
-Category: Standards Track March 1999
-
-
- Storage of Diffie-Hellman Keys in the Domain Name System (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 (1999). All Rights Reserved.
-
-Abstract
-
- A standard method for storing Diffie-Hellman keys in the Domain Name
- System is described which utilizes DNS KEY resource records.
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by:
-
- Ashar Aziz <ashar.aziz@eng.sun.com>
- Tom Markson <markson@incog.com>
- Hemma Prafullchandra <hemma@eng.sun.com>
-
- In addition, the following person provided useful comments that have
- been incorporated:
-
- Ran Atkinson <rja@inet.org>
- Thomas Narten <narten@raleigh.ibm.com>
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 1]
-
-RFC 2539 Diffie-Hellman Keys in the DNS March 1999
-
-
-Table of Contents
-
- Abstract...................................................1
- Acknowledgements...........................................1
- 1. Introduction............................................2
- 1.1 About This Document....................................2
- 1.2 About Diffie-Hellman...................................2
- 2. Diffie-Hellman KEY Resource Records.....................3
- 3. Performance Considerations..............................4
- 4. IANA Considerations.....................................4
- 5. Security Considerations.................................4
- References.................................................5
- Author's Address...........................................5
- Appendix A: Well known prime/generator pairs...............6
- A.1. Well-Known Group 1: A 768 bit prime..................6
- A.2. Well-Known Group 2: A 1024 bit prime.................6
- Full Copyright Notice......................................7
-
-1. Introduction
-
- The Domain Name System (DNS) is the current global hierarchical
- replicated distributed database system for Internet addressing, mail
- proxy, and similar information. The DNS has been extended to include
- digital signatures and cryptographic keys as described in [RFC 2535].
- Thus the DNS can now be used for secure key distribution.
-
-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].
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Since DNS SIG
- RRs are primarily used as stored authenticators of zone information
- for many different resolvers, no Diffie-Hellman algorithm SIG RR is
- defined. 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 )
-
-
-
-
-Eastlake Standards Track [Page 2]
-
-RFC 2539 Diffie-Hellman Keys in the DNS March 1999
-
-
- 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).
-
-2. Diffie-Hellman KEY Resource Records
-
- Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
- number 2. The structure of the RDATA portion of this RR is as shown
- below. The first 4 octets, including the flags, protocol, and
- algorithm fields are common to all KEY RRs as described in [RFC
- 2535]. The remainder, from prime length through public value is the
- "public key" part of the KEY RR. The period of key validity is not in
- the KEY RR but is indicated by the SIG RR(s) which signs and
- authenticates the KEY RR(s) at that domain name.
-
- 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 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.
-
-
-
-
-
-
-Eastlake Standards Track [Page 3]
-
-RFC 2539 Diffie-Hellman Keys in the DNS March 1999
-
-
- 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.
-
- The corresponding algorithm=2 SIG resource record is not used so no
- format for it is defined.
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less 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 to make reasonable
- efforts to minimize the size of KEY RR sets stored within the DNS
- consistent with adequate security. Keep in mind that in a secure
- zone, an authenticating SIG RR will also be returned.
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus.
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action and this Proposed
- Standard assigns 0x0001 through 0x0002. 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.
-
-5. Security Considerations
-
- Many of the general security consideration in [RFC 2535] apply. 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 important and
- dependent on local 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. [Schneier]
-
-
-
-
-Eastlake Standards Track [Page 4]
-
-RFC 2539 Diffie-Hellman Keys in the DNS March 1999
-
-
-References
-
- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", 1996, John Wiley and
- Sons
-
-Author's Address
-
- Donald E. Eastlake 3rd
- IBM
- 65 Shindegan Hill Road, RR #1
- Carmel, NY 10512
-
- Phone: +1-914-276-2668(h)
- +1-914-784-7913(w)
- Fax: +1-914-784-3833(w)
- EMail: dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 5]
-
-RFC 2539 Diffie-Hellman Keys in the DNS March 1999
-
-
-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
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 6]
-
-RFC 2539 Diffie-Hellman Keys in the DNS March 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2540.txt b/contrib/bind9/doc/rfc/rfc2540.txt
deleted file mode 100644
index 6314806188674..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2540.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake
-Request for Comments: 2540 IBM
-Category: Experimental March 1999
-
-
- Detached Domain Name System (DNS) Information
-
-Status of this Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. It does not specify an Internet standard of any kind.
- Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-Abstract
-
- A standard format is defined for representing detached DNS
- information. This is anticipated to be of use for storing
- information retrieved from the Domain Name System (DNS), including
- security information, in archival contexts or contexts not connected
- to the Internet.
-
-Table of Contents
-
- Abstract...................................................1
- 1. Introduction............................................1
- 2. General Format..........................................2
- 2.1 Binary Format..........................................3
- 2.2. Text Format...........................................4
- 3. Usage Example...........................................4
- 4. IANA Considerations.....................................4
- 5. Security Considerations.................................4
- References.................................................5
- Author's Address...........................................5
- Full Copyright Statement...................................6
-
-1. Introduction
-
- The Domain Name System (DNS) is a replicated hierarchical distributed
- database system [RFC 1034, 1035] that can provide highly available
- service. It provides the operational basis for Internet host name to
- address translation, automatic SMTP mail routing, and other basic
- Internet functions. The DNS has been extended as described in [RFC
- 2535] to permit the general storage of public cryptographic keys in
-
-
-
-Eastlake Experimental [Page 1]
-
-RFC 2540 Detached DNS Information March 1999
-
-
- the DNS and to enable the authentication of information retrieved
- from the DNS though digital signatures.
-
- The DNS was not originally designed for storage of information
- outside of the active zones and authoritative master files that are
- part of the connected DNS. However there may be cases where this is
- useful, particularly in connection with archived security
- information.
-
-2. General Format
-
- The formats used for detached Domain Name System (DNS) information
- are similar to those used for connected DNS information. The primary
- difference is that elements of the connected DNS system (unless they
- are an authoritative server for the zone containing the information)
- are required to count down the Time To Live (TTL) associated with
- each DNS Resource Record (RR) and discard them (possibly fetching a
- fresh copy) when the TTL reaches zero. In contrast to this, detached
- information may be stored in a off-line file, where it can not be
- updated, and perhaps used to authenticate historic data or it might
- be received via non-DNS protocols long after it was retrieved from
- the DNS. Therefore, it is not practical to count down detached DNS
- information TTL and it may be necessary to keep the data beyond the
- point where the TTL (which is defined as an unsigned field) would
- underflow. To preserve information as to the freshness of this
- detached data, it is accompanied by its retrieval time.
-
- Whatever retrieves the information from the DNS must associate this
- retrieval time with it. The retrieval time remains fixed thereafter.
- When the current time minus the retrieval time exceeds the TTL for
- any particular detached RR, it is no longer a valid copy within the
- normal connected DNS scheme. This may make it invalid in context for
- some detached purposes as well. If the RR is a SIG (signature) RR it
- also has an expiration time. Regardless of the TTL, it and any RRs
- it signs can not be considered authenticated after the signature
- expiration time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Experimental [Page 2]
-
-RFC 2540 Detached DNS Information March 1999
-
-
-2.1 Binary Format
-
- The standard binary format for detached DNS information is as
- follows:
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | first retrieval time |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | RR count | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) |
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- | next retrieval time |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | RR count | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) |
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / ... /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | hex 20 |
- +-+-+-+-+-+-+-+-+
-
- Retrieval time - the time that the immediately following information
- was obtained from the connected DNS system. It is an unsigned
- number of seconds since the start of 1 January 1970, GMT,
- ignoring leap seconds, in network (big-endian) order. Note that
- this time can not be before the initial proposal of this
- standard. Therefore, the initial byte of an actual retrieval
- time, considered as a 32 bit unsigned quantity, would always be
- larger than 20 hex. The end of detached DNS information is
- indicated by a "retrieval time" field initial byte equal to 0x20.
- Use of a "retrieval time" field with a leading unsigned byte of
- zero indicates a 64 bit (actually 8 leading zero bits plus a 56
- bit quantity). This 64 bit format will be required when
- retrieval time is larger than 0xFFFFFFFF, which is some time in
- the year 2106. The meaning of retrieval times with an initial
- byte between 0x01 and 0x1F is reserved (see section 5).
- Retrieval times will not generally be 32 bit aligned with respect
- to each other due to the variable length nature of RRs.
-
- RR count - an unsigned integer number (with bytes in network order)
- of following resource records retrieved at the preceding
- retrieval time.
-
-
-
-
-
-Eastlake Experimental [Page 3]
-
-RFC 2540 Detached DNS Information March 1999
-
-
- Resource Records - the actual data which is in the same format as if
- it were being transmitted in a DNS response. In particular, name
- compression via pointers is permitted with the origin at the
- beginning of the particular detached information data section,
- just after the RR count.
-
-2.2. Text Format
-
- The standard text format for detached DNS information is as
- prescribed for zone master files [RFC 1035] except that the $INCLUDE
- control entry is prohibited and the new $DATE entry is required
- (unless the information set is empty). $DATE is followed by the date
- and time that the following information was obtained from the DNS
- system as described for retrieval time in section 2.1 above. It is
- in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
- be more than four digits to cover years after 9999), the first MM is
- the month number (01-12), DD is the day of the month (01-31), HH is
- the hour in 24 hours notation (00-23), the second MM is the minute
- (00-59), and SS is the second (00-59). Thus a $DATE must appear
- before the first RR and at every change in retrieval time through the
- detached information.
-
-3. Usage Example
-
- A document might be authenticated by a key retrieved from the DNS in
- a KEY resource record (RR). To later prove the authenticity of this
- document, it would be desirable to preserve the KEY RR for that
- public key, the SIG RR signing that KEY RR, the KEY RR for the key
- used to authenticate that SIG, and so on through SIG and KEY RRs
- until a well known trusted key is reached, perhaps the key for the
- DNS root or some third party authentication service. (In some cases
- these KEY RRs will actually be sets of KEY RRs with the same owner
- and class because SIGs actually sign such record sets.)
-
- This information could be preserved as a set of detached DNS
- information blocks.
-
-4. IANA Considerations
-
- Allocation of meanings to retrieval time fields with a initial byte
- of between 0x01 and 0x1F requires an IETF consensus.
-
-5. Security Considerations
-
- The entirety of this document concerns a means to represent detached
- DNS information. Such detached resource records may be security
- relevant and/or secured information as described in [RFC 2535]. The
- detached format provides no overall security for sets of detached
-
-
-
-Eastlake Experimental [Page 4]
-
-RFC 2540 Detached DNS Information March 1999
-
-
- information or for the association between retrieval time and
- information. This can be provided by wrapping the detached
- information format with some other form of signature. However, if
- the detached information is accompanied by SIG RRs, its validity
- period is indicated in those SIG RRs so the retrieval time might be
- of secondary importance.
-
-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 2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
-Author's Address
-
- Donald E. Eastlake 3rd
- IBM
- 65 Shindegan Hill Road, RR #1
- Carmel, NY 10512
-
- Phone: +1-914-276-2668(h)
- +1-914-784-7913(w)
- Fax: +1-914-784-3833(w)
- EMail: dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Experimental [Page 5]
-
-RFC 2540 Detached DNS Information March 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Experimental [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2541.txt b/contrib/bind9/doc/rfc/rfc2541.txt
deleted file mode 100644
index a62ed2b486775..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2541.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake
-Request for Comments: 2541 IBM
-Category: Informational March 1999
-
-
- DNS Security Operational Considerations
-
-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 (1999). All Rights Reserved.
-
-Abstract
-
- Secure DNS is based on cryptographic techniques. A necessary part of
- the strength of these techniques is careful attention to the
- operational aspects of key and signature generation, lifetime, size,
- and storage. In addition, special attention must be paid to the
- security of the high level zones, particularly the root zone. This
- document discusses these operational aspects for keys and signatures
- used in connection with the KEY and SIG DNS resource records.
-
-Acknowledgments
-
- The contributions and suggestions of the following persons (in
- alphabetic order) are gratefully acknowledged:
-
- John Gilmore
- Olafur Gudmundsson
- Charlie Kaufman
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Informational [Page 1]
-
-RFC 2541 DNS Security Operational Considerations March 1999
-
-
-Table of Contents
-
- Abstract...................................................1
- Acknowledgments............................................1
- 1. Introduction............................................2
- 2. Public/Private Key Generation...........................2
- 3. Public/Private Key Lifetimes............................2
- 4. Public/Private Key Size Considerations..................3
- 4.1 RSA Key Sizes..........................................3
- 4.2 DSS Key Sizes..........................................4
- 5. Private Key Storage.....................................4
- 6. High Level Zones, The Root Zone, and The Meta-Root Key..5
- 7. Security Considerations.................................5
- References.................................................6
- Author's Address...........................................6
- Full Copyright Statement...................................7
-
-1. Introduction
-
- This document describes operational considerations for the
- generation, lifetime, size, and storage of DNS cryptographic keys and
- signatures for use in the KEY and SIG resource records [RFC 2535].
- Particular attention is paid to high level zones and the root zone.
-
-2. Public/Private Key Generation
-
- 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 [RFC
- 1750].
-
- Long term keys 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. Public/Private Key Lifetimes
-
- No key should be used forever. The longer a key is in use, the
- greater the probability that it will have been compromised through
- carelessness, accident, espionage, or cryptanalysis. Furthermore, if
-
-
-
-
-
-
-Eastlake Informational [Page 2]
-
-RFC 2541 DNS Security Operational Considerations March 1999
-
-
- key rollover is a rare event, there is an increased risk that, when
- the time does come to change the key, no one at the site will
- remember how to do it or operational problems will have developed in
- the key rollover procedures.
-
- While public key lifetime is a matter of local policy, these
- considerations imply that, unless there are extraordinary
- circumstances, no long term key should have a lifetime significantly
- over four years. In fact, a reasonable guideline for long term keys
- that are kept off-line and carefully guarded is a 13 month lifetime
- with the intent that they be replaced every year. A reasonable
- maximum lifetime for keys that are used for transaction security or
- the like and are kept on line is 36 days with the intent that they be
- replaced monthly or more often. In many cases, a key lifetime of
- somewhat over a day may be reasonable.
-
- On the other hand, public keys with too short a lifetime can lead to
- excessive resource consumption in re-signing data and retrieving
- fresh information because cached information becomes stale. In the
- Internet environment, almost all public keys should have lifetimes no
- shorter than three minutes, which is a reasonable estimate of maximum
- packet delay even in unusual circumstances.
-
-4. Public/Private Key Size Considerations
-
- There are a number of factors that effect public key size choice for
- use in the DNS security extension. Unfortunately, these factors
- usually do not all point in the same direction. Choice of zone key
- size should generally be made by the zone administrator depending on
- their local conditions.
-
- For most schemes, larger keys are more secure but slower. In
- addition, larger keys increase the size of the KEY and SIG RRs. This
- increases the chance of DNS UDP packet overflow and the possible
- necessity for using higher overhead TCP in responses.
-
-4.1 RSA Key Sizes
-
- Given a small public exponent, verification (the most common
- operation) for the MD5/RSA algorithm will vary roughly with the
- square of the modulus length, signing will vary with the cube of the
- modulus length, and key generation (the least common operation) will
- vary with the fourth power of the modulus length. The current best
- algorithms for factoring a modulus and breaking RSA security vary
- roughly with the 1.6 power of the modulus itself. Thus going from a
- 640 bit modulus to a 1280 bit modulus only increases the verification
- time by a factor of 4 but may increase the work factor of breaking
- the key by over 2^900.
-
-
-
-Eastlake Informational [Page 3]
-
-RFC 2541 DNS Security Operational Considerations March 1999
-
-
- The recommended minimum RSA algorithm modulus size is 704 bits which
- is believed by the author to be secure at this time. But high level
- zones in the DNS tree may wish to set a higher minimum, perhaps 1000
- bits, for security reasons. (Since the United States National
- Security Agency generally permits export of encryption systems using
- an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
- n, must be considered weak.)
-
- For an RSA key used only to secure data and not to secure other keys,
- 704 bits should be adequate at this time.
-
-4.2 DSS Key Sizes
-
- DSS keys are probably roughly as strong as an RSA key of the same
- length but DSS signatures are significantly smaller.
-
-5. 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 SIG
- and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
- where a real KEY RR for the subzone with that algorithm is not
- provided. Then the augmented file can be transferred, perhaps by
- sneaker-net, to the networked zone primary server machine.
-
- The idea 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.
-
- This is not possible if the zone is to be dynamically updated
- securely [RFC 2137]. At least a private key capable of updating the
- SOA and NXT chain must be on line in that case.
-
- Secure resolvers must be configured with some trusted on-line public
- key information (or a secure path to such a resolver) or they will be
- unable to authenticate. Although on line, this public key
- information must be protected or it could be altered so that spoofed
- DNS data would appear authentic.
-
-
-
-
-
-
-Eastlake Informational [Page 4]
-
-RFC 2541 DNS Security Operational Considerations March 1999
-
-
- Non-zone private keys, such as host or user keys, generally have to
- be kept on line to be used for real-time purposes such as DNS
- transaction security.
-
-6. High Level Zones, The Root Zone, and The Meta-Root Key
-
- 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 subdomains (except in the case of
- resolvers that have locally configured the public key of a
- subdomain). 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
- 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 subdomain). 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 an enormous population
- of resolvers around the world will be extremely difficult. Yet the
- guidelines in section 3 above would imply that the root zone private
- key be changed annually or more often and if it were staticly
- configured at all these resolvers, it would have to be updated when
- changed.
-
- To permit relatively frequent change to the root zone key yet
- minimize exposure of the ultimate key of the DNS tree, there will be
- a "meta-root" key used very rarely and then only to sign a sequence
- of regular root key RRsets with overlapping time validity periods
- that are to be rolled out. The root zone contains the meta-root and
- current regular root KEY RR(s) signed by SIG RRs under both the
- meta-root and other root private key(s) themselves.
-
- The utmost security in the storage and use of the meta-root key is
- essential. The exact techniques are precautions to be used are
- beyond the scope of this document. Because of its special position,
- it may be best to continue with the same meta-root key for an
- extended period of time such as ten to fifteen years.
-
-7. Security Considerations
-
- The entirety of this document is concerned with operational
- considerations of public/private key pair DNS Security.
-
-
-
-Eastlake Informational [Page 5]
-
-RFC 2541 DNS Security Operational Considerations March 1999
-
-
-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 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Requirements for Security", RFC 1750, December 1994.
-
- [RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System
- Security Extensions", RFC 2065, January 1997.
-
- [RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic
- Update", RFC 2137, April 1997.
-
- [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RSA FAQ] RSADSI Frequently Asked Questions periodic posting.
-
-Author's Address
-
- Donald E. Eastlake 3rd
- IBM
- 65 Shindegan Hill Road, RR #1
- Carmel, NY 10512
-
- Phone: +1-914-276-2668(h)
- +1-914-784-7913(w)
- Fax: +1-914-784-3833(w)
- EMail: dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Informational [Page 6]
-
-RFC 2541 DNS Security Operational Considerations March 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Informational [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2553.txt b/contrib/bind9/doc/rfc/rfc2553.txt
deleted file mode 100644
index 6989bf3045e50..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2553.txt
+++ /dev/null
@@ -1,2299 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Gilligan
-Request for Comments: 2553 FreeGate
-Obsoletes: 2133 S. Thomson
-Category: Informational Bellcore
- J. Bound
- Compaq
- W. Stevens
- Consultant
- March 1999
-
-
- Basic Socket Interface Extensions for IPv6
-
-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 (1999). All Rights Reserved.
-
-Abstract
-
- The de facto standard application program interface (API) for TCP/IP
- applications is the "sockets" interface. Although this API was
- developed for Unix in the early 1980s it has also been implemented on
- a wide variety of non-Unix systems. TCP/IP applications written
- using the sockets API have in the past enjoyed a high degree of
- portability and we would like the same portability with IPv6
- applications. But changes are required to the sockets API to support
- IPv6 and this memo describes these changes. These include a new
- socket address structure to carry IPv6 addresses, new address
- conversion functions, and some new socket options. These extensions
- are designed to provide access to the basic IPv6 features required by
- TCP and UDP applications, including multicasting, while introducing a
- minimum of change into the system and providing complete
- compatibility for existing IPv4 applications. Additional extensions
- for advanced IPv6 features (raw sockets and access to the IPv6
- extension headers) are defined in another document [4].
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 1]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-Table of Contents
-
- 1. Introduction.................................................3
- 2. Design Considerations........................................3
- 2.1 What Needs to be Changed....................................4
- 2.2 Data Types..................................................5
- 2.3 Headers.....................................................5
- 2.4 Structures..................................................5
- 3. Socket Interface.............................................6
- 3.1 IPv6 Address Family and Protocol Family.....................6
- 3.2 IPv6 Address Structure......................................6
- 3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
- 3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
- 3.5 The Socket Functions........................................9
- 3.6 Compatibility with IPv4 Applications.......................10
- 3.7 Compatibility with IPv4 Nodes..............................10
- 3.8 IPv6 Wildcard Address......................................11
- 3.9 IPv6 Loopback Address......................................12
- 3.10 Portability Additions.....................................13
- 4. Interface Identification....................................16
- 4.1 Name-to-Index..............................................16
- 4.2 Index-to-Name..............................................17
- 4.3 Return All Interface Names and Indexes.....................17
- 4.4 Free Memory................................................18
- 5. Socket Options..............................................18
- 5.1 Unicast Hop Limit..........................................18
- 5.2 Sending and Receiving Multicast Packets....................19
- 6. Library Functions...........................................21
- 6.1 Nodename-to-Address Translation............................21
- 6.2 Address-To-Nodename Translation............................24
- 6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
- 6.4 Protocol-Independent Nodename and Service Name Translation.26
- 6.5 Socket Address Structure to Nodename and Service Name......29
- 6.6 Address Conversion Functions...............................31
- 6.7 Address Testing Macros.....................................32
- 7. Summary of New Definitions..................................33
- 8. Security Considerations.....................................35
- 9. Year 2000 Considerations....................................35
- Changes From RFC 2133..........................................35
- Acknowledgments................................................38
- References.....................................................39
- Authors' Addresses.............................................40
- Full Copyright Statement.......................................41
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 2]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-1. Introduction
-
- While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
- by 128-bit addresses. The socket interface makes the size of an IP
- address quite visible to an application; virtually all TCP/IP
- applications for BSD-based systems have knowledge of the size of an
- IP address. Those parts of the API that expose the addresses must be
- changed to accommodate the larger IPv6 address size. IPv6 also
- introduces new features (e.g., traffic class and flowlabel), some of
- which must be made visible to applications via the API. This memo
- defines a set of extensions to the socket interface to support the
- larger address size and new features of IPv6.
-
-2. Design Considerations
-
- There are a number of important considerations in designing changes
- to this well-worn API:
-
- - The API changes should provide both source and binary
- compatibility for programs written to the original API. That
- is, existing program binaries should continue to operate when
- run on a system supporting the new API. In addition, existing
- applications that are re-compiled and run on a system supporting
- the new API should continue to operate. Simply put, the API
- changes for IPv6 should not break existing programs. An
- additonal mechanism for implementations to verify this is to
- verify the new symbols are protected by Feature Test Macros as
- described in IEEE Std 1003.1. (Such Feature Test Macros are not
- defined by this RFC.)
-
- - The changes to the API should be as small as possible in order
- to simplify the task of converting existing IPv4 applications to
- IPv6.
-
- - Where possible, applications should be able to use this API to
- interoperate with both IPv6 and IPv4 hosts. Applications should
- not need to know which type of host they are communicating with.
-
- - IPv6 addresses carried in data structures should be 64-bit
- aligned. This is necessary in order to obtain optimum
- performance on 64-bit machine architectures.
-
- Because of the importance of providing IPv4 compatibility in the API,
- these extensions are explicitly designed to operate on machines that
- provide complete support for both IPv4 and IPv6. A subset of this
- API could probably be designed for operation on systems that support
- only IPv6. However, this is not addressed in this memo.
-
-
-
-
-Gilligan, et. al. Informational [Page 3]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-2.1 What Needs to be Changed
-
- The socket interface API consists of a few distinct components:
-
- - Core socket functions.
-
- - Address data structures.
-
- - Name-to-address translation functions.
-
- - Address conversion functions.
-
- The core socket functions -- those functions that deal with such
- things as setting up and tearing down TCP connections, and sending
- and receiving UDP packets -- were designed to be transport
- independent. Where protocol addresses are passed as function
- arguments, they are carried via opaque pointers. A protocol-specific
- address data structure is defined for each protocol that the socket
- functions support. Applications must cast pointers to these
- protocol-specific address structures into pointers to the generic
- "sockaddr" address structure when using the socket functions. These
- functions need not change for IPv6, but a new IPv6-specific address
- data structure is needed.
-
- The "sockaddr_in" structure is the protocol-specific data structure
- for IPv4. This data structure actually includes 8-octets of unused
- space, and it is tempting to try to use this space to adapt the
- sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in
- structure is not large enough to hold the 16-octet IPv6 address as
- well as the other information (address family and port number) that
- is needed. So a new address data structure must be defined for IPv6.
-
- IPv6 addresses are scoped [2] so they could be link-local, site,
- organization, global, or other scopes at this time undefined. To
- support applications that want to be able to identify a set of
- interfaces for a specific scope, the IPv6 sockaddr_in structure must
- support a field that can be used by an implementation to identify a
- set of interfaces identifying the scope for an IPv6 address.
-
- The name-to-address translation functions in the socket interface are
- gethostbyname() and gethostbyaddr(). These are left as is and new
- functions are defined to support IPv4 and IPv6. Additionally, the
- POSIX 1003.g draft [3] specifies a new nodename-to-address
- translation function which is protocol independent. This function
- can also be used with IPv4 and IPv6.
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 4]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- The address conversion functions -- inet_ntoa() and inet_addr() --
- convert IPv4 addresses between binary and printable form. These
- functions are quite specific to 32-bit IPv4 addresses. We have
- designed two analogous functions that convert both IPv4 and IPv6
- addresses, and carry an address type parameter so that they can be
- extended to other protocol families as well.
-
- Finally, a few miscellaneous features are needed to support IPv6.
- New interfaces are needed to support the IPv6 traffic class, flow
- label, and hop limit header fields. New socket options are needed to
- control the sending and receiving of IPv6 multicast packets.
-
- The socket interface will be enhanced in the future to provide access
- to other IPv6 features. These extensions are described in [4].
-
-2.2 Data Types
-
- The data types of the structure elements given in this memo are
- intended to be examples, not absolute requirements. Whenever
- possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are
- used: uintN_t means an unsigned integer of exactly N bits (e.g.,
- uint16_t). We also assume the argument data types from 1003.1g when
- possible (e.g., the final argument to setsockopt() is a size_t
- value). Whenever buffer sizes are specified, the POSIX 1003.1 size_t
- data type is used (e.g., the two length arguments to getnameinfo()).
-
-2.3 Headers
-
- When function prototypes and structures are shown we show the headers
- that must be #included to cause that item to be defined.
-
-2.4 Structures
-
- When structures are described the members shown are the ones that
- must appear in an implementation. Additional, nonstandard members
- may also be defined by an implementation. As an additional
- precaution nonstandard members could be verified by Feature Test
- Macros as described in IEEE Std 1003.1. (Such Feature Test Macros
- are not defined by this RFC.)
-
- The ordering shown for the members of a structure is the recommended
- ordering, given alignment considerations of multibyte members, but an
- implementation may order the members differently.
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 5]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-3. Socket Interface
-
- This section specifies the socket interface changes for IPv6.
-
-3.1 IPv6 Address Family and Protocol Family
-
- A new address family name, AF_INET6, is defined in <sys/socket.h>.
- The AF_INET6 definition distinguishes between the original
- sockaddr_in address data structure, and the new sockaddr_in6 data
- structure.
-
- A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
- Like most of the other protocol family names, this will usually be
- defined to have the same value as the corresponding address family
- name:
-
- #define PF_INET6 AF_INET6
-
- The PF_INET6 is used in the first argument to the socket() function
- to indicate that an IPv6 socket is being created.
-
-3.2 IPv6 Address Structure
-
- A new in6_addr structure holds a single IPv6 address and is defined
- as a result of including <netinet/in.h>:
-
- struct in6_addr {
- uint8_t s6_addr[16]; /* IPv6 address */
- };
-
- This data structure contains an array of sixteen 8-bit elements,
- which make up one 128-bit IPv6 address. The IPv6 address is stored
- in network byte order.
-
- The structure in6_addr above is usually implemented with an embedded
- union with extra fields that force the desired alignment level in a
- manner similar to BSD implementations of "struct in_addr". Those
- additional implementation details are omitted here for simplicity.
-
- An example is as follows:
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 6]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- struct in6_addr {
- union {
- uint8_t _S6_u8[16];
- uint32_t _S6_u32[4];
- uint64_t _S6_u64[2];
- } _S6_un;
- };
- #define s6_addr _S6_un._S6_u8
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
- In the socket interface, a different protocol-specific data structure
- is defined to carry the addresses for each protocol suite. Each
- protocol- specific data structure is designed so it can be cast into a
- protocol- independent data structure -- the "sockaddr" structure.
- Each has a "family" field that overlays the "sa_family" of the
- sockaddr data structure. This field identifies the type of the data
- structure.
-
- The sockaddr_in structure is the protocol-specific address data
- structure for IPv4. It is used to pass addresses between applications
- and the system in the socket functions. The following sockaddr_in6
- structure holds IPv6 addresses and is defined as a result of including
- the <netinet/in.h> header:
-
-struct sockaddr_in6 {
- sa_family_t sin6_family; /* AF_INET6 */
- in_port_t sin6_port; /* transport layer port # */
- uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */
- struct in6_addr sin6_addr; /* IPv6 address */
- uint32_t sin6_scope_id; /* set of interfaces for a scope */
-};
-
- This structure is designed to be compatible with the sockaddr data
- structure used in the 4.3BSD release.
-
- The sin6_family field identifies this as a sockaddr_in6 structure.
- This field overlays the sa_family field when the buffer is cast to a
- sockaddr data structure. The value of this field must be AF_INET6.
-
- The sin6_port field contains the 16-bit UDP or TCP port number. This
- field is used in the same way as the sin_port field of the
- sockaddr_in structure. The port number is stored in network byte
- order.
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 7]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- The sin6_flowinfo field is a 32-bit field that contains two pieces of
- information: the traffic class and the flow label. The contents and
- interpretation of this member is specified in [1]. The sin6_flowinfo
- field SHOULD be set to zero by an implementation prior to using the
- sockaddr_in6 structure by an application on receive operations.
-
- The sin6_addr field is a single in6_addr structure (defined in the
- previous section). This field holds one 128-bit IPv6 address. The
- address is stored in network byte order.
-
- The ordering of elements in this structure is specifically designed
- so that when sin6_addr field is aligned on a 64-bit boundary, the
- start of the structure will also be aligned on a 64-bit boundary.
- This is done for optimum performance on 64-bit architectures.
-
- The sin6_scope_id field is a 32-bit integer that identifies a set of
- interfaces as appropriate for the scope of the address carried in the
- sin6_addr field. For a link scope sin6_addr sin6_scope_id would be
- an interface index. For a site scope sin6_addr, sin6_scope_id would
- be a site identifier. The mapping of sin6_scope_id to an interface
- or set of interfaces is left to implementation and future
- specifications on the subject of site identifiers.
-
- Notice that the sockaddr_in6 structure will normally be larger than
- the generic sockaddr structure. On many existing implementations the
- sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
- being 16 bytes. Any existing code that makes this assumption needs
- to be examined carefully when converting to IPv6.
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
- The 4.4BSD release includes a small, but incompatible change to the
- socket interface. The "sa_family" field of the sockaddr data
- structure was changed from a 16-bit value to an 8-bit value, and the
- space saved used to hold a length field, named "sa_len". The
- sockaddr_in6 data structure given in the previous section cannot be
- correctly cast into the newer sockaddr data structure. For this
- reason, the following alternative IPv6 address data structure is
- provided to be used on systems based on 4.4BSD. It is defined as a
- result of including the <netinet/in.h> header.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 8]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-struct sockaddr_in6 {
- uint8_t sin6_len; /* length of this struct */
- sa_family_t sin6_family; /* AF_INET6 */
- in_port_t sin6_port; /* transport layer port # */
- uint32_t sin6_flowinfo; /* IPv6 flow information */
- struct in6_addr sin6_addr; /* IPv6 address */
- uint32_t sin6_scope_id; /* set of interfaces for a scope */
-};
-
- The only differences between this data structure and the 4.3BSD
- variant are the inclusion of the length field, and the change of the
- family field to a 8-bit data type. The definitions of all the other
- fields are identical to the structure defined in the previous
- section.
-
- Systems that provide this version of the sockaddr_in6 data structure
- must also declare SIN6_LEN as a result of including the
- <netinet/in.h> header. This macro allows applications to determine
- whether they are being built on a system that supports the 4.3BSD or
- 4.4BSD variants of the data structure.
-
-3.5 The Socket Functions
-
- Applications call the socket() function to create a socket descriptor
- that represents a communication endpoint. The arguments to the
- socket() function tell the system which protocol to use, and what
- format address structure will be used in subsequent functions. For
- example, to create an IPv4/TCP socket, applications make the call:
-
- s = socket(PF_INET, SOCK_STREAM, 0);
-
- To create an IPv4/UDP socket, applications make the call:
-
- s = socket(PF_INET, SOCK_DGRAM, 0);
-
- Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
- the constant PF_INET6 instead of PF_INET in the first argument. For
- example, to create an IPv6/TCP socket, applications make the call:
-
- s = socket(PF_INET6, SOCK_STREAM, 0);
-
- To create an IPv6/UDP socket, applications make the call:
-
- s = socket(PF_INET6, SOCK_DGRAM, 0);
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 9]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- Once the application has created a PF_INET6 socket, it must use the
- sockaddr_in6 address structure when passing addresses in to the
- system. The functions that the application uses to pass addresses
- into the system are:
-
- bind()
- connect()
- sendmsg()
- sendto()
-
- The system will use the sockaddr_in6 address structure to return
- addresses to applications that are using PF_INET6 sockets. The
- functions that return an address from the system to an application
- are:
-
- accept()
- recvfrom()
- recvmsg()
- getpeername()
- getsockname()
-
- No changes to the syntax of the socket functions are needed to
- support IPv6, since all of the "address carrying" functions use an
- opaque address pointer, and carry an address length as a function
- argument.
-
-3.6 Compatibility with IPv4 Applications
-
- In order to support the large base of applications using the original
- API, system implementations must provide complete source and binary
- compatibility with the original API. This means that systems must
- continue to support PF_INET sockets and the sockaddr_in address
- structure. Applications must be able to create IPv4/TCP and IPv4/UDP
- sockets using the PF_INET constant in the socket() function, as
- described in the previous section. Applications should be able to
- hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
- sockets simultaneously within the same process.
-
- Applications using the original API should continue to operate as
- they did on systems supporting only IPv4. That is, they should
- continue to interoperate with IPv4 nodes.
-
-3.7 Compatibility with IPv4 Nodes
-
- The API also provides a different type of compatibility: the ability
- for IPv6 applications to interoperate with IPv4 applications. This
- feature uses the IPv4-mapped IPv6 address format defined in the IPv6
- addressing architecture specification [2]. This address format
-
-
-
-Gilligan, et. al. Informational [Page 10]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- allows the IPv4 address of an IPv4 node to be represented as an IPv6
- address. The IPv4 address is encoded into the low-order 32 bits of
- the IPv6 address, and the high-order 96 bits hold the fixed prefix
- 0:0:0:0:0:FFFF. IPv4- mapped addresses are written as follows:
-
- ::FFFF:<IPv4-address>
-
- These addresses can be generated automatically by the
- getipnodebyname() function when the specified host has only IPv4
- addresses (as described in Section 6.1).
-
- Applications may use PF_INET6 sockets to open TCP connections to IPv4
- nodes, or send UDP packets to IPv4 nodes, by simply encoding the
- destination's IPv4 address as an IPv4-mapped IPv6 address, and
- passing that address, within a sockaddr_in6 structure, in the
- connect() or sendto() call. When applications use PF_INET6 sockets
- to accept TCP connections from IPv4 nodes, or receive UDP packets
- from IPv4 nodes, the system returns the peer's address to the
- application in the accept(), recvfrom(), or getpeername() call using
- a sockaddr_in6 structure encoded this way.
-
- Few applications will likely need to know which type of node they are
- interoperating with. However, for those applications that do need to
- know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
- provided.
-
-3.8 IPv6 Wildcard Address
-
- While the bind() function allows applications to select the source IP
- address of UDP packets and TCP connections, applications often want
- the system to select the source address for them. With IPv4, one
- specifies the address as the symbolic constant INADDR_ANY (called the
- "wildcard" address) in the bind() call, or simply omits the bind()
- entirely.
-
- Since the IPv6 address type is a structure (struct in6_addr), a
- symbolic constant can be used to initialize an IPv6 address variable,
- but cannot be used in an assignment. Therefore systems provide the
- IPv6 wildcard address in two forms.
-
- The first version is a global variable named "in6addr_any" that is an
- in6_addr structure. The extern declaration for this variable is
- defined in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_any;
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 11]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- Applications use in6addr_any similarly to the way they use INADDR_ANY
- in IPv4. For example, to bind a socket to port number 23, but let
- the system select the source address, an application could use the
- following code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_any; /* structure assignment */
- . . .
- if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
- The other version is a symbolic constant named IN6ADDR_ANY_INIT and
- is defined in <netinet/in.h>. This constant can be used to
- initialize an in6_addr structure:
-
- struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
- Note that this constant can be used ONLY at declaration time. It can
- not be used to assign a previously declared in6_addr structure. For
- example, the following code will not work:
-
- /* This is the WRONG way to assign an unspecified address */
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
- Be aware that the IPv4 INADDR_xxx constants are all defined in host
- byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
- in6addr_xxx externals are defined in network byte order.
-
-3.9 IPv6 Loopback Address
-
- Applications may need to send UDP packets to, or originate TCP
- connections to, services residing on the local node. In IPv4, they
- can do this by using the constant IPv4 address INADDR_LOOPBACK in
- their connect(), sendto(), or sendmsg() call.
-
- IPv6 also provides a loopback address to contact local TCP and UDP
- services. Like the unspecified address, the IPv6 loopback address is
- provided in two forms -- a global variable and a symbolic constant.
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 12]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- The global variable is an in6_addr structure named
- "in6addr_loopback." The extern declaration for this variable is
- defined in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_loopback;
-
- Applications use in6addr_loopback as they would use INADDR_LOOPBACK
- in IPv4 applications (but beware of the byte ordering difference
- mentioned at the end of the previous section). For example, to open
- a TCP connection to the local telnet server, an application could use
- the following code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_loopback; /* structure assignment */
- . . .
- if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
- The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
- in <netinet/in.h>. It can be used at declaration time ONLY; for
- example:
-
- struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
- Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
- to a previously declared IPv6 address variable.
-
-3.10 Portability Additions
-
- One simple addition to the sockets API that can help application
- writers is the "struct sockaddr_storage". This data structure can
- simplify writing code portable across multiple address families and
- platforms. This data structure is designed with the following goals.
-
- - It has a large enough implementation specific maximum size to
- store the desired set of protocol specific socket address data
- structures. Specifically, it is at least large enough to
- accommodate sockaddr_in and sockaddr_in6 and possibly other
- protocol specific socket addresses too.
- - It is aligned at an appropriate boundary so protocol specific
- socket address data structure pointers can be cast to it and
- access their fields without alignment problems. (e.g. pointers
- to sockaddr_in6 and/or sockaddr_in can be cast to it and access
- fields without alignment problems).
-
-
-
-Gilligan, et. al. Informational [Page 13]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- - It has the initial field(s) isomorphic to the fields of the
- "struct sockaddr" data structure on that implementation which
- can be used as a discriminants for deriving the protocol in use.
- These initial field(s) would on most implementations either be a
- single field of type "sa_family_t" (isomorphic to sa_family
- field, 16 bits) or two fields of type uint8_t and sa_family_t
- respectively, (isomorphic to sa_len and sa_family_t, 8 bits
- each).
-
- An example implementation design of such a data structure would be as
- follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE 128 /* Implementation specific max size */
-#define _SS_ALIGNSIZE (sizeof (int64_t))
- /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
- _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
- sa_family_t __ss_family; /* address family */
- /* Following fields are implementation specific */
- char __ss_pad1[_SS_PAD1SIZE];
- /* 6 byte pad, this is to make implementation
- /* specific pad up to alignment field that */
- /* follows explicit in the data structure */
- int64_t __ss_align; /* field to force desired structure */
- /* storage alignment */
- char __ss_pad2[_SS_PAD2SIZE];
- /* 112 byte pad to achieve desired size, */
- /* _SS_MAXSIZE value minus size of ss_family */
- /* __ss_pad1, __ss_align fields is 112 */
-};
-
- On implementations where sockaddr data structure includes a "sa_len",
- field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
- (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
-
-
-
-Gilligan, et. al. Informational [Page 14]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
- uint8_t __ss_len; /* address length */
- sa_family_t __ss_family; /* address family */
- /* Following fields are implementation specific */
- char __ss_pad1[_SS_PAD1SIZE];
- /* 6 byte pad, this is to make implementation
- /* specific pad up to alignment field that */
- /* follows explicit in the data structure */
- int64_t __ss_align; /* field to force desired structure */
- /* storage alignment */
- char __ss_pad2[_SS_PAD2SIZE];
- /* 112 byte pad to achieve desired size, */
- /* _SS_MAXSIZE value minus size of ss_len, */
- /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
- The above example implementation illustrates a data structure which
- will align on a 64 bit boundary. An implementation specific field
- "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment
- which covers proper alignment good enough for needs of sockaddr_in6
- (IPv6), sockaddr_in (IPv4) address data structures. The size of
- padding fields __ss_pad1 depends on the chosen alignment boundary.
- The size of padding field __ss_pad2 depends on the value of overall
- size chosen for the total size of the structure. This size and
- alignment are represented in the above example by implementation
- specific (not required) constants _SS_MAXSIZE (chosen value 128) and
- _SS_ALIGNMENT (with chosen value 8). Constants _SS_PAD1SIZE (derived
- value 6) and _SS_PAD2SIZE (derived value 112) are also for
- illustration and not required. The implementation specific
- definitions and structure field names above start with an underscore
- to denote implementation private namespace. Portable code is not
- expected to access or reference those fields or constants.
-
- The sockaddr_storage structure solves the problem of declaring
- storage for automatic variables which is large enough and aligned
- enough for storing socket address data structure of any family. For
- example, code with a file descriptor and without the context of the
- address family can pass a pointer to a variable of this type where a
- pointer to a socket address structure is expected in calls such as
- getpeername() and determine the address family by accessing the
- received content after the call.
-
- The sockaddr_storage structure may also be useful and applied to
- certain other interfaces where a generic socket address large enough
- and aligned for use with multiple address families may be needed. A
- discussion of those interfaces is outside the scope of this document.
-
-
-
-
-Gilligan, et. al. Informational [Page 15]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- Also, much existing code assumes that any socket address structure
- can fit in a generic sockaddr structure. While this has been true
- for IPv4 socket address structures, it has always been false for Unix
- domain socket address structures (but in practice this has not been a
- problem) and it is also false for IPv6 socket address structures
- (which can be a problem).
-
- So now an application can do the following:
-
- struct sockaddr_storage __ss;
- struct sockaddr_in6 *sin6;
- sin6 = (struct sockaddr_in6 *) &__ss;
-
-4. Interface Identification
-
- This API uses an interface index (a small positive integer) to
- identify the local interface on which a multicast group is joined
- (Section 5.3). Additionally, the advanced API [4] uses these same
- interface indexes to identify the interface on which a datagram is
- received, or to specify the interface on which a datagram is to be
- sent.
-
- Interfaces are normally known by names such as "le0", "sl1", "ppp2",
- and the like. On Berkeley-derived implementations, when an interface
- is made known to the system, the kernel assigns a unique positive
- integer value (called the interface index) to that interface. These
- are small positive integers that start at 1. (Note that 0 is never
- used for an interface index.) There may be gaps so that there is no
- current interface for a particular positive interface index.
-
- This API defines two functions that map between an interface name and
- index, a third function that returns all the interface names and
- indexes, and a fourth function to return the dynamic memory allocated
- by the previous function. How these functions are implemented is
- left up to the implementation. 4.4BSD implementations can implement
- these functions using the existing sysctl() function with the
- NET_RT_IFLIST command. Other implementations may wish to use ioctl()
- for this purpose.
-
-4.1 Name-to-Index
-
- The first function maps an interface name into its corresponding
- index.
-
- #include <net/if.h>
-
- unsigned int if_nametoindex(const char *ifname);
-
-
-
-
-Gilligan, et. al. Informational [Page 16]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- If the specified interface name does not exist, the return value is
- 0, and errno is set to ENXIO. If there was a system error (such as
- running out of memory), the return value is 0 and errno is set to the
- proper value (e.g., ENOMEM).
-
-4.2 Index-to-Name
-
- The second function maps an interface index into its corresponding
- name.
-
- #include <net/if.h>
-
- char *if_indextoname(unsigned int ifindex, char *ifname);
-
- The ifname argument must point to a buffer of at least IF_NAMESIZE
- bytes into which the interface name corresponding to the specified
- index is returned. (IF_NAMESIZE is also defined in <net/if.h> and
- its value includes a terminating null byte at the end of the
- interface name.) This pointer is also the return value of the
- function. If there is no interface corresponding to the specified
- index, NULL is returned, and errno is set to ENXIO, if there was a
- system error (such as running out of memory), if_indextoname returns
- NULL and errno would be set to the proper value (e.g., ENOMEM).
-
-4.3 Return All Interface Names and Indexes
-
- The if_nameindex structure holds the information about a single
- interface and is defined as a result of including the <net/if.h>
- header.
-
- struct if_nameindex {
- unsigned int if_index; /* 1, 2, ... */
- char *if_name; /* null terminated name: "le0", ... */
- };
-
- The final function returns an array of if_nameindex structures, one
- structure per interface.
-
- struct if_nameindex *if_nameindex(void);
-
- The end of the array of structures is indicated by a structure with
- an if_index of 0 and an if_name of NULL. The function returns a NULL
- pointer upon an error, and would set errno to the appropriate value.
-
- The memory used for this array of structures along with the interface
- names pointed to by the if_name members is obtained dynamically.
- This memory is freed by the next function.
-
-
-
-
-Gilligan, et. al. Informational [Page 17]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-4.4 Free Memory
-
- The following function frees the dynamic memory that was allocated by
- if_nameindex().
-
- #include <net/if.h>
-
- void if_freenameindex(struct if_nameindex *ptr);
-
- The argument to this function must be a pointer that was returned by
- if_nameindex().
-
- Currently net/if.h doesn't have prototype definitions for functions
- and it is recommended that these definitions be defined in net/if.h
- as well and the struct if_nameindex{}.
-
-5. Socket Options
-
- A number of new socket options are defined for IPv6. All of these
- new options are at the IPPROTO_IPV6 level. That is, the "level"
- parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
- when using these options. The constant name prefix IPV6_ is used in
- all of the new socket options. This serves to clearly identify these
- options as applying to IPv6.
-
- The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
- related constants defined in this section are obtained by including
- the header <netinet/in.h>.
-
-5.1 Unicast Hop Limit
-
- A new setsockopt() option controls the hop limit used in outgoing
- unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS,
- and it is used at the IPPROTO_IPV6 layer. The following example
- illustrates how it is used:
-
- int hoplimit = 10;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, sizeof(hoplimit)) == -1)
- perror("setsockopt IPV6_UNICAST_HOPS");
-
- When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
- option value given is used as the hop limit for all subsequent
- unicast packets sent via that socket. If the option is not set, the
- system selects a default value. The integer hop limit value (called
- x) is interpreted as follows:
-
-
-
-
-Gilligan, et. al. Informational [Page 18]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
- The IPV6_UNICAST_HOPS option may be used with getsockopt() to
- determine the hop limit value that the system will use for subsequent
- unicast packets sent via that socket. For example:
-
- int hoplimit;
- size_t len = sizeof(hoplimit);
-
- if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, &len) == -1)
- perror("getsockopt IPV6_UNICAST_HOPS");
- else
- printf("Using %d for hop limit.\n", hoplimit);
-
-5.2 Sending and Receiving Multicast Packets
-
- IPv6 applications may send UDP multicast packets by simply specifying
- an IPv6 multicast address in the address argument of the sendto()
- function.
-
- Three socket options at the IPPROTO_IPV6 layer control some of the
- parameters for sending multicast packets. Setting these options is
- not required: applications may send multicast packets without using
- these options. The setsockopt() options for controlling the sending
- of multicast packets are summarized below. These three options can
- also be used with getsockopt().
-
- IPV6_MULTICAST_IF
-
- Set the interface to use for outgoing multicast packets. The
- argument is the index of the interface to use.
-
- Argument type: unsigned int
-
- IPV6_MULTICAST_HOPS
-
- Set the hop limit to use for outgoing multicast packets. (Note
- a separate option - IPV6_UNICAST_HOPS - is provided to set the
- hop limit to use for outgoing unicast packets.)
-
- The interpretation of the argument is the same as for the
- IPV6_UNICAST_HOPS option:
-
-
-
-
-
-Gilligan, et. al. Informational [Page 19]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
- If IPV6_MULTICAST_HOPS is not set, the default is 1
- (same as IPv4 today)
-
- Argument type: int
-
- IPV6_MULTICAST_LOOP
-
- If a multicast datagram is sent to a group to which the sending
- host itself belongs (on the outgoing interface), a copy of the
- datagram is looped back by the IP layer for local delivery if
- this option is set to 1. If this option is set to 0 a copy
- is not looped back. Other option values return an error of
- EINVAL.
-
- If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
- same as IPv4 today).
-
- Argument type: unsigned int
-
- The reception of multicast packets is controlled by the two
- setsockopt() options summarized below. An error of EOPNOTSUPP is
- returned if these two options are used with getsockopt().
-
- IPV6_JOIN_GROUP
-
- Join a multicast group on a specified local interface. If the
- interface index is specified as 0, the kernel chooses the local
- interface. For example, some kernels look up the multicast
- group in the normal IPv6 routing table and using the resulting
- interface.
-
- Argument type: struct ipv6_mreq
-
- IPV6_LEAVE_GROUP
-
- Leave a multicast group on a specified interface.
-
- Argument type: struct ipv6_mreq
-
- The argument type of both of these options is the ipv6_mreq structure,
- defined as a result of including the <netinet/in.h> header;
-
-
-
-
-
-Gilligan, et. al. Informational [Page 20]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- struct ipv6_mreq {
- struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
- unsigned int ipv6mr_interface; /* interface index */
- };
-
- Note that to receive multicast datagrams a process must join the
- multicast group and bind the UDP port to which datagrams will be
- sent. Some processes also bind the multicast group address to the
- socket, in addition to the port, to prevent other datagrams destined
- to that same port from being delivered to the socket.
-
-6. Library Functions
-
- New library functions are needed to perform a variety of operations
- with IPv6 addresses. Functions are needed to lookup IPv6 addresses
- in the Domain Name System (DNS). Both forward lookup (nodename-to-
- address translation) and reverse lookup (address-to-nodename
- translation) need to be supported. Functions are also needed to
- convert IPv6 addresses between their binary and textual form.
-
- We note that the two existing functions, gethostbyname() and
- gethostbyaddr(), are left as-is. New functions are defined to handle
- both IPv4 and IPv6 addresses.
-
-6.1 Nodename-to-Address Translation
-
- The commonly used function gethostbyname() is inadequate for many
- applications, first because it provides no way for the caller to
- specify anything about the types of addresses desired (IPv4 only,
- IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
- implementations of this function are not thread safe. RFC 2133
- defined a function named gethostbyname2() but this function was also
- inadequate, first because its use required setting a global option
- (RES_USE_INET6) when IPv6 addresses were required, and second because
- a flag argument is needed to provide the caller with additional
- control over the types of addresses required.
-
- The following function is new and must be thread safe:
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- struct hostent *getipnodebyname(const char *name, int af, int flags
- int *error_num);
-
- The name argument can be either a node name or a numeric address
- string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address).
- The af argument specifies the address family, either AF_INET or
-
-
-
-Gilligan, et. al. Informational [Page 21]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- AF_INET6. The error_num value is returned to the caller, via a
- pointer, with the appropriate error code in error_num, to support
- thread safe error code returns. error_num will be set to one of the
- following values:
-
- 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.
-
- NO_RECOVERY
-
- An unexpected server failure occurred which cannot be recovered.
-
- TRY_AGAIN
-
- A temporary and possibly transient error occurred, such as a
- failure of a server to respond.
-
- The flags argument specifies the types of addresses that are searched
- for, and the types of addresses that are returned. We note that a
- special flags value of AI_DEFAULT (defined below) should handle most
- applications.
-
- That is, porting simple applications to use IPv6 replaces the call
-
- hptr = gethostbyname(name);
-
- with
-
- hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
-
- and changes any subsequent error diagnosis code to use error_num
- instead of externally declared variables, such as h_errno.
-
- Applications desiring finer control over the types of addresses
- searched for and returned, can specify other combinations of the
- flags argument.
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 22]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- A flags of 0 implies a strict interpretation of the af argument:
-
- - If flags is 0 and af is AF_INET, then the caller wants only
- IPv4 addresses. A query is made for A records. If successful,
- the IPv4 addresses are returned and the h_length member of the
- hostent structure will be 4, else the function returns a NULL
- pointer.
-
- - If flags is 0 and if af is AF_INET6, then the caller wants only
- IPv6 addresses. A query is made for AAAA records. If
- successful, the IPv6 addresses are returned and the h_length
- member of the hostent structure will be 16, else the function
- returns a NULL pointer.
-
- Other constants can be logically-ORed into the flags argument, to
- modify the behavior of the function.
-
- - If the AI_V4MAPPED flag is specified along with an af of
- AF_INET6, then the caller will accept IPv4-mapped IPv6
- addresses. That is, if no AAAA records are found then a query
- is made for A records and any found are returned as IPv4-mapped
- IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is
- ignored unless af equals AF_INET6.
-
- - The AI_ALL flag is used in conjunction with the AI_V4MAPPED
- flag, and is only used with the IPv6 address family. When AI_ALL
- is logically or'd with AI_V4MAPPED flag then the caller wants
- all addresses: IPv6 and IPv4-mapped IPv6. A query is first made
- for AAAA records and if successful, the IPv6 addresses are
- returned. Another query is then made for A records and any found
- are returned as IPv4-mapped IPv6 addresses. h_length will be 16.
- Only if both queries fail does the function return a NULL pointer.
- This flag is ignored unless af equals AF_INET6.
-
- - The AI_ADDRCONFIG flag specifies that a query for AAAA records
- should occur only if the node has at least one IPv6 source
- address configured and a query for A records should occur only
- if the node has at least one IPv4 source address configured.
-
- For example, if the node has no IPv6 source addresses
- configured, and af equals AF_INET6, and the node name being
- looked up has both AAAA and A records, then:
-
- (a) if only AI_ADDRCONFIG is specified, the function
- returns a NULL pointer;
- (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
- records are returned as IPv4-mapped IPv6 addresses;
-
-
-
-
-Gilligan, et. al. Informational [Page 23]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- The special flags value of AI_DEFAULT is defined as
-
- #define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG)
-
- We noted that the getipnodebyname() function must allow the name
- argument to be either a node name or a literal address string (i.e.,
- a dotted-decimal IPv4 address or an IPv6 hex address). This saves
- applications from having to call inet_pton() to handle literal
- address strings.
-
- There are four scenarios based on the type of literal address string
- and the value of the af argument.
-
- The two simple cases are:
-
- When name is a dotted-decimal IPv4 address and af equals AF_INET, or
- when name is an IPv6 hex address and af equals AF_INET6. The members
- of the returned hostent structure are: h_name points to a copy of the
- name argument, h_aliases is a NULL pointer, h_addrtype is a copy of
- the af argument, h_length is either 4 (for AF_INET) or 16 (for
- AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte
- binary address, and h_addr_list[1] is a NULL pointer.
-
- When name is a dotted-decimal IPv4 address and af equals AF_INET6,
- and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is
- returned: h_name points to an IPv6 hex address containing the IPv4-
- mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is
- AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte
- binary address, and h_addr_list[1] is a NULL pointer. If AI_V4MAPPED
- is set (with or without AI_ALL) return IPv4-mapped otherwise return
- NULL.
-
- It is an error when name is an IPv6 hex address and af equals
- AF_INET. The function's return value is a NULL pointer and error_num
- equals HOST_NOT_FOUND.
-
-6.2 Address-To-Nodename Translation
-
- The following function has the same arguments as the existing
- gethostbyaddr() function, but adds an error number.
-
- #include <sys/socket.h> #include <netdb.h>
-
- struct hostent *getipnodebyaddr(const void *src, size_t len,
- int af, int *error_num);
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 24]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- As with getipnodebyname(), getipnodebyaddr() must be thread safe.
- The error_num value is returned to the caller with the appropriate
- error code, to support thread safe error code returns. The following
- error conditions may be returned for error_num:
-
- HOST_NOT_FOUND
-
- No such host is known.
-
- NO_ADDRESS
-
- The server recognized 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.
-
- NO_RECOVERY
-
- An unexpected server failure occurred which cannot be
- recovered.
-
- TRY_AGAIN
-
- A temporary and possibly transient error occurred, such as a
- failure of a server to respond.
-
- One possible source of confusion is the handling of IPv4-mapped IPv6
- addresses and IPv4-compatible IPv6 addresses, but the following logic
- should apply.
-
- 1. If af is AF_INET6, and if len equals 16, and if the IPv6
- address is an IPv4-mapped IPv6 address or an IPv4-compatible
- IPv6 address, then skip over the first 12 bytes of the IPv6
- address, set af to AF_INET, and set len to 4.
-
- 2. If af is AF_INET, lookup the name for the given IPv4 address
- (e.g., query for a PTR record in the in-addr.arpa domain).
-
- 3. If af is AF_INET6, lookup the name for the given IPv6 address
- (e.g., query for a PTR record in the ip6.int domain).
-
- 4. If the function is returning success, then the single address
- that is returned in the hostent structure is a copy of the
- first argument to the function with the same address family
- that was passed as an argument to this function.
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 25]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- All four steps listed are performed, in order. Also note that the
- IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
- compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
- be returned and a query of the address not performed.
-
- Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
- false for "::" and "::1".
-
-6.3 Freeing memory for getipnodebyname and getipnodebyaddr
-
- The hostent structure does not change from its existing definition.
- This structure, and the information pointed to by this structure, are
- dynamically allocated by getipnodebyname and getipnodebyaddr. The
- following function frees this memory:
-
- #include <netdb.h>
-
- void freehostent(struct hostent *ptr);
-
-6.4 Protocol-Independent Nodename and Service Name Translation
-
- Nodename-to-address translation is done in a protocol-independent
- fashion using the getaddrinfo() function that is taken from the
- Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
- (Protocol Independent Interfaces) draft specification [3].
-
- The official specification for this function will be the final POSIX
- standard, with the following additional requirements:
-
- - getaddrinfo() (along with the getnameinfo() function described
- in the next section) must be thread safe.
-
- - The AI_NUMERICHOST is new with this document.
-
- - All fields in socket address structures returned by
- getaddrinfo() that are not filled in through an explicit
- argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
- (This makes it easier to compare socket address structures.)
-
- - getaddrinfo() must fill in the length field of a socket address
- structure (e.g., sin6_len) on systems that support this field.
-
- We are providing this independent description of the function because
- POSIX standards are not freely available (as are IETF documents).
-
- #include <sys/socket.h>
- #include <netdb.h>
-
-
-
-
-Gilligan, et. al. Informational [Page 26]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- int getaddrinfo(const char *nodename, const char *servname,
- const struct addrinfo *hints,
- struct addrinfo **res);
-
- The addrinfo structure is defined as a result of including the
- <netdb.h> header.
-
- struct addrinfo {
- int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
- int ai_family; /* PF_xxx */
- int ai_socktype; /* SOCK_xxx */
- int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
- size_t ai_addrlen; /* length of ai_addr */
- char *ai_canonname; /* canonical name for nodename */
- struct sockaddr *ai_addr; /* binary address */
- struct addrinfo *ai_next; /* next structure in linked list */
- };
-
- The return value from the function is 0 upon success or a nonzero
- error code. The following names are the nonzero error codes from
- getaddrinfo(), and are defined in <netdb.h>:
-
- EAI_ADDRFAMILY address family for nodename 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 nodename
- EAI_NONAME nodename nor servname 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 nodename and servname arguments are pointers to null-terminated
- strings or NULL. One or both of these two arguments must be a non-
- NULL pointer. In the normal client scenario, both the nodename and
- servname are specified. In the normal server scenario, only the
- servname is specified. A non-NULL nodename string can be either a
- node name or a numeric host address string (i.e., a dotted-decimal
- IPv4 address or an IPv6 hex address). A non-NULL servname string can
- be either a service name or a decimal port number.
-
- The caller can optionally pass an addrinfo structure, pointed to by
- the third argument, to provide hints concerning the type of socket
- that the caller supports. In this hints structure all members other
- than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
- or a NULL pointer. A value of PF_UNSPEC for ai_family means the
-
-
-
-Gilligan, et. al. Informational [Page 27]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- caller will accept any protocol family. A value of 0 for ai_socktype
- means the caller will accept any socket type. A value of 0 for
- ai_protocol means the caller will accept any protocol. For example,
- if the caller handles only TCP and not UDP, then the ai_socktype
- member of the hints structure should be set to SOCK_STREAM when
- getaddrinfo() is called. If the caller handles only IPv4 and not
- IPv6, then the ai_family member of the hints structure should be set
- to PF_INET when getaddrinfo() is called. If the third argument to
- getaddrinfo() is a NULL pointer, this is the same as if the caller
- had filled in an addrinfo structure initialized to zero with
- ai_family set to PF_UNSPEC.
-
- Upon successful return a pointer to a linked list of one or more
- addrinfo structures is returned through the final argument. The
- caller can process each addrinfo structure in this list by following
- the ai_next pointer, until a NULL pointer is encountered. In each
- returned addrinfo structure the three members ai_family, ai_socktype,
- and ai_protocol are the corresponding arguments for a call to the
- socket() function. In each addrinfo structure the ai_addr member
- points to a filled-in socket address structure whose length is
- specified by the ai_addrlen member.
-
- If the AI_PASSIVE bit is set in the ai_flags member of the hints
- structure, then the caller plans to use the returned socket address
- structure in a call to bind(). In this case, if the nodename
- argument is a NULL pointer, then the IP address portion of the socket
- address structure will be set to INADDR_ANY for an IPv4 address or
- IN6ADDR_ANY_INIT for an IPv6 address.
-
- If the AI_PASSIVE bit is not set in the ai_flags member of the hints
- structure, then the returned socket address structure will be ready
- for a call to connect() (for a connection-oriented protocol) or
- either connect(), sendto(), or sendmsg() (for a connectionless
- protocol). In this case, if the nodename argument is a NULL pointer,
- then the IP address portion of the socket address structure will be
- set to the loopback address.
-
- If the AI_CANONNAME bit is set in the ai_flags member of the hints
- structure, then upon successful return the ai_canonname member of the
- first addrinfo structure in the linked list will point to a null-
- terminated string containing the canonical name of the specified
- nodename.
-
- If the AI_NUMERICHOST bit is set in the ai_flags member of the hints
- structure, then a non-NULL nodename string must be a numeric host
- address string. Otherwise an error of EAI_NONAME is returned. This
- flag prevents any type of name resolution service (e.g., the DNS)
- from being called.
-
-
-
-Gilligan, et. al. Informational [Page 28]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- All of the information returned by getaddrinfo() is dynamically
- allocated: the addrinfo structures, and the socket address structures
- and canonical node name strings pointed to by the addrinfo
- structures. To return this information to the system the function
- freeaddrinfo() is called:
-
- #include <sys/socket.h> #include <netdb.h>
-
- void freeaddrinfo(struct addrinfo *ai);
-
- The addrinfo structure pointed to by the ai argument is freed, along
- with any dynamic storage pointed to by the structure. This operation
- is repeated until a NULL ai_next pointer is encountered.
-
- To aid applications in printing error messages based on the EAI_xxx
- codes returned by getaddrinfo(), the following function is defined.
-
- #include <sys/socket.h> #include <netdb.h>
-
- char *gai_strerror(int ecode);
-
- The argument is one of the EAI_xxx values defined earlier and the
- return value points to a string describing the error. If the
- argument is not one of the EAI_xxx values, the function still returns
- a pointer to a string whose contents indicate an unknown error.
-
-6.5 Socket Address Structure to Nodename and Service Name
-
- The POSIX 1003.1g specification includes no function to perform the
- reverse conversion from getaddrinfo(): to look up a nodename and
- service name, given the binary address and port. Therefore, we
- define the following function:
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- int getnameinfo(const struct sockaddr *sa, socklen_t salen,
- char *host, size_t hostlen,
- char *serv, size_t servlen,
- int flags);
-
- This function looks up an IP address and port number provided by the
- caller in the DNS and system-specific database, and returns text
- strings for both in buffers provided by the caller. The function
- indicates successful completion by a zero return value; a non-zero
- return value indicates failure.
-
-
-
-
-
-Gilligan, et. al. Informational [Page 29]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- The first argument, sa, points to either a sockaddr_in structure (for
- IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
- address and port number. The salen argument gives the length of the
- sockaddr_in or sockaddr_in6 structure.
-
- The function returns the nodename associated with the IP address in
- the buffer pointed to by the host argument. The caller provides the
- size of this buffer via the hostlen argument. The service name
- associated with the port number is returned in the buffer pointed to
- by serv, and the servlen argument gives the length of this buffer.
- The caller specifies not to return either string by providing a zero
- value for the hostlen or servlen arguments. Otherwise, the caller
- must provide buffers large enough to hold the nodename and the
- service name, including the terminating null characters.
-
- Unfortunately most systems do not provide constants that specify the
- maximum size of either a fully-qualified domain name or a service
- name. Therefore to aid the application in allocating buffers for
- these two returned strings the following constants are defined in
- <netdb.h>:
-
- #define NI_MAXHOST 1025
- #define NI_MAXSERV 32
-
- The first value is actually defined as the constant MAXDNAME in recent
- versions of BIND's <arpa/nameser.h> header (older versions of BIND
- define this constant to be 256) and the second is a guess based on the
- services listed in the current Assigned Numbers RFC.
-
- The final argument is a flag that changes the default actions of this
- function. By default the fully-qualified domain name (FQDN) for the
- host is looked up in the DNS and returned. If the flag bit NI_NOFQDN
- is set, only the nodename portion of the FQDN is returned for local
- hosts.
-
- If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
- located in the DNS, the numeric form of the host's address is returned
- instead of its name (e.g., by calling inet_ntop() instead of
- getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is
- returned if the host's name cannot be located in the DNS.
-
- If the flag bit NI_NUMERICSERV is set, the numeric form of the service
- address is returned (e.g., its port number) instead of its name. The
- two NI_NUMERICxxx flags are required to support the "-n" flag that
- many commands provide.
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 30]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- A fifth flag bit, NI_DGRAM, specifies that the service 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 (e.g. 512-514) that have different services for UDP
- and TCP.
-
- These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
- flags already defined for getaddrinfo().
-
-6.6 Address Conversion Functions
-
- The two functions inet_addr() and inet_ntoa() convert an IPv4 address
- between binary and text form. IPv6 applications need similar
- functions. The following two functions convert both IPv6 and IPv4
- addresses:
-
- #include <sys/socket.h>
- #include <arpa/inet.h>
-
- int inet_pton(int af, const char *src, void *dst);
-
- const char *inet_ntop(int af, const void *src,
- char *dst, size_t size);
-
- The inet_pton() function converts an address in its standard text
- presentation form into its numeric binary form. The af argument
- specifies the family of the address. Currently the AF_INET and
- AF_INET6 address families are supported. The src argument points to
- the string being passed in. The dst argument points to a buffer into
- which the function stores the numeric address. The address is
- returned in network byte order. Inet_pton() returns 1 if the
- conversion succeeds, 0 if the input is not a valid IPv4 dotted-
- decimal string or a valid IPv6 address string, or -1 with errno set
- to EAFNOSUPPORT if the af argument is unknown. The calling
- application must ensure that the buffer referred to by dst is large
- enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
- bytes for AF_INET6).
-
- If the af argument is AF_INET, the function accepts a string in the
- standard IPv4 dotted-decimal form:
-
- ddd.ddd.ddd.ddd
-
- where ddd is a one to three digit decimal number between 0 and 255.
- Note that many implementations of the existing inet_addr() and
- inet_aton() functions accept nonstandard input: octal numbers,
- hexadecimal numbers, and fewer than four numbers. inet_pton() does
- not accept these formats.
-
-
-
-Gilligan, et. al. Informational [Page 31]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- If the af argument is AF_INET6, then the function accepts a string in
- one of the standard IPv6 text forms defined in Section 2.2 of the
- addressing architecture specification [2].
-
- The inet_ntop() function converts a numeric address into a text
- string suitable for presentation. The af argument specifies the
- family of the address. This can be AF_INET or AF_INET6. The src
- argument points to a buffer holding an IPv4 address if the af
- argument is AF_INET, or an IPv6 address if the af argument is
- AF_INET6, the address must be in network byte order. The dst
- argument points to a buffer where the function will store the
- resulting text string. The size argument specifies the size of this
- buffer. The application must specify a non-NULL dst argument. For
- IPv6 addresses, the buffer must be at least 46-octets. For IPv4
- addresses, the buffer must be at least 16-octets. In order to allow
- applications to easily declare buffers of the proper size to store
- IPv4 and IPv6 addresses in string form, the following two constants
- are defined in <netinet/in.h>:
-
- #define INET_ADDRSTRLEN 16
- #define INET6_ADDRSTRLEN 46
-
- The inet_ntop() function returns a pointer to the buffer containing
- the text string if the conversion succeeds, and NULL otherwise. Upon
- failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
- ENOSPC if the size of the result buffer is inadequate.
-
-6.7 Address Testing Macros
-
- The following macros can be used to test for special IPv6 addresses.
-
- #include <netinet/in.h>
-
- int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
- int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
- int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
- int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
- int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
-
- int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
-
-
-
-
-
-Gilligan, et. al. Informational [Page 32]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- The first seven macros return true if the address is of the specified
- type, or false otherwise. The last five test the scope of a
- multicast address and return true if the address is a multicast
- address of the specified scope or false if the address is either not
- a multicast address or not of the specified scope. Note that
- IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for
- the two local-use IPv6 unicast addresses. These two macros do not
- return true for IPv6 multicast addresses of either link-local scope
- or site-local scope.
-
-7. Summary of New Definitions
-
- The following list summarizes the constants, structure, and extern
- definitions discussed in this memo, sorted by header.
-
- <net/if.h> IF_NAMESIZE
- <net/if.h> struct if_nameindex{};
-
- <netdb.h> AI_ADDRCONFIG
- <netdb.h> AI_DEFAULT
- <netdb.h> AI_ALL
- <netdb.h> AI_CANONNAME
- <netdb.h> AI_NUMERICHOST
- <netdb.h> AI_PASSIVE
- <netdb.h> AI_V4MAPPED
- <netdb.h> EAI_ADDRFAMILY
- <netdb.h> EAI_AGAIN
- <netdb.h> EAI_BADFLAGS
- <netdb.h> EAI_FAIL
- <netdb.h> EAI_FAMILY
- <netdb.h> EAI_MEMORY
- <netdb.h> EAI_NODATA
- <netdb.h> EAI_NONAME
- <netdb.h> EAI_SERVICE
- <netdb.h> EAI_SOCKTYPE
- <netdb.h> EAI_SYSTEM
- <netdb.h> NI_DGRAM
- <netdb.h> NI_MAXHOST
- <netdb.h> NI_MAXSERV
- <netdb.h> NI_NAMEREQD
- <netdb.h> NI_NOFQDN
- <netdb.h> NI_NUMERICHOST
- <netdb.h> NI_NUMERICSERV
- <netdb.h> struct addrinfo{};
-
- <netinet/in.h> IN6ADDR_ANY_INIT
- <netinet/in.h> IN6ADDR_LOOPBACK_INIT
- <netinet/in.h> INET6_ADDRSTRLEN
-
-
-
-Gilligan, et. al. Informational [Page 33]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- <netinet/in.h> INET_ADDRSTRLEN
- <netinet/in.h> IPPROTO_IPV6
- <netinet/in.h> IPV6_JOIN_GROUP
- <netinet/in.h> IPV6_LEAVE_GROUP
- <netinet/in.h> IPV6_MULTICAST_HOPS
- <netinet/in.h> IPV6_MULTICAST_IF
- <netinet/in.h> IPV6_MULTICAST_LOOP
- <netinet/in.h> IPV6_UNICAST_HOPS
- <netinet/in.h> SIN6_LEN
- <netinet/in.h> extern const struct in6_addr in6addr_any;
- <netinet/in.h> extern const struct in6_addr in6addr_loopback;
- <netinet/in.h> struct in6_addr{};
- <netinet/in.h> struct ipv6_mreq{};
- <netinet/in.h> struct sockaddr_in6{};
-
- <sys/socket.h> AF_INET6
- <sys/socket.h> PF_INET6
- <sys/socket.h> struct sockaddr_storage;
-
- The following list summarizes the function and macro prototypes
- discussed in this memo, sorted by header.
-
-<arpa/inet.h> int inet_pton(int, const char *, void *);
-<arpa/inet.h> const char *inet_ntop(int, const void *,
- char *, size_t);
-
-<net/if.h> char *if_indextoname(unsigned int, char *);
-<net/if.h> unsigned int if_nametoindex(const char *);
-<net/if.h> void if_freenameindex(struct if_nameindex *);
-<net/if.h> struct if_nameindex *if_nameindex(void);
-
-<netdb.h> int getaddrinfo(const char *, const char *,
- const struct addrinfo *,
- struct addrinfo **);
-<netdb.h> int getnameinfo(const struct sockaddr *, socklen_t,
- char *, size_t, char *, size_t, int);
-<netdb.h> void freeaddrinfo(struct addrinfo *);
-<netdb.h> char *gai_strerror(int);
-<netdb.h> struct hostent *getipnodebyname(const char *, int, int,
- int *);
-<netdb.h> struct hostent *getipnodebyaddr(const void *, size_t,
- int, int *);
-<netdb.h> void freehostent(struct hostent *);
-
-<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-
-
-
-Gilligan, et. al. Informational [Page 34]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-8. Security Considerations
-
- IPv6 provides a number of new security mechanisms, many of which need
- to be accessible to applications. Companion memos detailing the
- extensions to the socket interfaces to support IPv6 security are
- being written.
-
-9. Year 2000 Considerations
-
- There are no issues for this memo concerning the Year 2000 issue
- regarding the use of dates.
-
-Changes From RFC 2133
-
- Changes made in the March 1998 Edition (-01 draft):
-
- Changed all "hostname" to "nodename" for consistency with other
- IPv6 documents.
-
- Section 3.3: changed comment for sin6_flowinfo to be "traffic
- class & flow info" and updated corresponding text description to
- current definition of these two fields.
-
- Section 3.10 ("Portability Additions") is new.
-
- Section 6: a new paragraph was added reiterating that the existing
- gethostbyname() and gethostbyaddr() are not changed.
-
- Section 6.1: change gethostbyname3() to getnodebyname(). Add
- AI_DEFAULT to handle majority of applications. Renamed
- AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
- IPv4 addresses too. Defined exactly what getnodebyname() must
- return if the name argument is a numeric address string.
-
- Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword
- items 2 and 3 in the description of how to handle IPv4-mapped and
- IPv4- compatible addresses to "lookup a name" for a given address,
- instead of specifying what type of DNS query to issue.
-
-
-
-
-Gilligan, et. al. Informational [Page 35]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- Section 6.3: added two more requirements to getaddrinfo().
-
- Section 7: added the following constants to the list for
- <netdb.h>: AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union
- sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
-
- Updated references.
-
- Changes made in the November 1997 Edition (-00 draft):
-
- The data types have been changed to conform with Draft 6.6 of the
- Posix 1003.1g standard.
-
- Section 3.2: data type of s6_addr changed to "uint8_t".
-
- Section 3.3: data type of sin6_family changed to "sa_family_t".
- data type of sin6_port changed to "in_port_t", data type of
- sin6_flowinfo changed to "uint32_t".
-
- Section 3.4: same as Section 3.3, plus data type of sin6_len
- changed to "uint8_t".
-
- Section 6.2: first argument of gethostbyaddr() changed from "const
- char *" to "const void *" and second argument changed from "int"
- to "size_t".
-
- Section 6.4: second argument of getnameinfo() changed from
- "size_t" to "socklen_t".
-
- The wording was changed when new structures were defined, to be
- more explicit as to which header must be included to define the
- structure:
-
- Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
- 3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
- (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
-
- Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
-
- Section 5.1: The IPV6_ADDRFORM socket option was removed.
-
- Section 5.3: Added a note that an option value other than 0 or 1
- for IPV6_MULTICAST_LOOP returns an error. Added a note that
- IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
- can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
- IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
-
-
-
-
-
-Gilligan, et. al. Informational [Page 36]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- Section 6.1: Removed the description of gethostbyname2() and its
- associated RES_USE_INET6 option, replacing it with
- gethostbyname3().
-
- Section 6.2: Added requirement that gethostbyaddr() be thread
- safe. Reworded step 4 to avoid using the RES_USE_INET6 option.
-
- Section 6.3: Added the requirement that getaddrinfo() and
- getnameinfo() be thread safe. Added the AI_NUMERICHOST flag.
-
- Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
- IN6_IS_ADDR_SITELOCAL macros.
-
- Changes made to the draft -01 specification Sept 98
-
- Changed priority to traffic class in the spec.
-
- Added the need for scope identification in section 2.1.
-
- Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
- 3.4.
-
- Changed 3.10 to use generic storage structure to support holding
- IPv6 addresses and removed the SA_LEN macro.
-
- Distinguished between invalid input parameters and system failures
- for Interface Identification in Section 4.1 and 4.2.
-
- Added defaults for multicast operations in section 5.2 and changed
- the names from ADD to JOIN and DROP to LEAVE to be consistent with
- IPv6 multicast terminology.
-
- Changed getnodebyname to getipnodebyname, getnodebyaddr to
- getipnodebyaddr, and added MT safe error code to function
- parameters in section 6.
-
- Moved freehostent to its own sub-section after getipnodebyaddr now
- 6.3 (so this bumps all remaining sections in section 6.
-
- Clarified the use of AI_ALL and AI_V4MAPPED that these are
- dependent on the AF parameter and must be used as a conjunction in
- section 6.1.
-
- Removed the restriction that literal addresses cannot be used with
- a flags argument in section 6.1.
-
- Added Year 2000 Section to the draft
-
-
-
-
-Gilligan, et. al. Informational [Page 37]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- Deleted Reference to the following because the attached is deleted
- from the ID directory and has expired. But the logic from the
- aforementioned draft still applies, so that was kept in Section
- 6.2 bullets after 3rd paragraph.
-
- [7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
- Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
- ipv4ptr-00.txt>, May 1996.
-
- Deleted the following reference as it is no longer referenced.
- And the draft has expired.
-
- [3] D. McDonald, "A Simple IP Security API Extension to BSD
- Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
- 01.txt>, March 1997.
-
- Deleted the following reference as it is no longer referenced.
-
- [4] C. Metz, "Network Security API for Sockets",
- Internet-Draft, <draft-metz-net-security-api-01.txt>, January
- 1998.
-
- Update current references to current status.
-
- Added alignment notes for in6_addr and sin6_addr.
-
- Clarified further that AI_V4MAPPED must be used with a dotted IPv4
- literal address for getipnodebyname(), when address family is
- AF_INET6.
-
- Added text to clarify "::" and "::1" when used by
- getipnodebyaddr().
-
-Acknowledgments
-
- Thanks to the many people who made suggestions and provided feedback
- to this document, including: Werner Almesberger, Ran Atkinson, Fred
- Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve
- Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom
- Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada,
- Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave
- Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc
- Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
- Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
- Waitzman, Carl Williams, and Kazu Yamamoto,
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 38]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
- The getaddrinfo() and getnameinfo() functions are taken from an
- earlier Internet Draft by Keith Sklower. As noted in that draft,
- William Durst, Steven Wise, Michael Karels, and Eric Allman provided
- many useful discussions on the subject of protocol-independent name-
- to-address translation, and reviewed early versions of Keith
- Sklower's original proposal. Eric Allman implemented the first
- prototype of getaddrinfo(). The observation that specifying the pair
- of name and service would suffice for connecting to a service
- independent of protocol details was made by Marshall Rose in a
- proposal to X/Open for a "Uniform Network Interface".
-
- Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
- Kacker made many contributions to this document. Ramesh Govindan
- made a number of contributions and co-authored an earlier version of
- this memo.
-
-References
-
- [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
- Specification", RFC 2460, December 1998.
-
- [2] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [3] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
- 6.6, March 1997.
-
- [4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
- 2292, February 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 39]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-Authors' Addresses
-
- Robert E. Gilligan
- FreeGate Corporation
- 1208 E. Arques Ave.
- Sunnyvale, CA 94086
-
- Phone: +1 408 617 1004
- EMail: gilligan@freegate.com
-
-
- Susan Thomson
- Bell Communications Research
- MRE 2P-343, 445 South Street
- Morristown, NJ 07960
-
- Phone: +1 201 829 4514
- EMail: set@thumper.bellcore.com
-
-
- Jim Bound
- Compaq Computer Corporation
- 110 Spitbrook Road ZK3-3/U14
- Nashua, NH 03062-2698
-
- Phone: +1 603 884 0400
- EMail: bound@zk3.dec.com
-
-
- W. Richard Stevens
- 1202 E. Paseo del Zorro
- Tucson, AZ 85718-2826
-
- Phone: +1 520 297 9416
- EMail: rstevens@kohala.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 40]
-
-RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al. Informational [Page 41]
-
diff --git a/contrib/bind9/doc/rfc/rfc2671.txt b/contrib/bind9/doc/rfc/rfc2671.txt
deleted file mode 100644
index ec05f80829cf5..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2671.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Vixie
-Request for Comments: 2671 ISC
-Category: Standards Track August 1999
-
-
- Extension Mechanisms for DNS (EDNS0)
-
-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 (1999). All Rights Reserved.
-
-Abstract
-
- The Domain Name System's wire protocol includes a number of fixed
- fields whose range has been or soon will be exhausted and does not
- allow clients to advertise their capabilities to servers. This
- document describes backward compatible mechanisms for allowing the
- protocol to grow.
-
-1 - Rationale and Scope
-
-1.1. DNS (see [RFC1035]) specifies a Message Format and within such
- messages there are standard formats for encoding options, errors,
- and name compression. The maximum allowable size of a DNS Message
- is fixed. Many of DNS's protocol limits are too small for uses
- which are or which are desired to become common. There is no way
- for implementations to advertise their capabilities.
-
-1.2. Existing clients will not know how to interpret the protocol
- extensions detailed here. In practice, these clients will be
- upgraded when they have need of a new feature, and only new
- features will make use of the extensions. We must however take
- account of client behaviour in the face of extra fields, and design
- a fallback scheme for interoperability with these clients.
-
-
-
-
-
-
-
-
-
-Vixie Standards Track [Page 1]
-
-RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
-
-
-2 - Affected Protocol Elements
-
-2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
- word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
- 1-bit flags. The original reserved Z bits have been allocated to
- various purposes, and most of the RCODE values are now in use.
- More flags and more possible RCODEs are needed.
-
-2.2. The first two bits of a wire format domain label are used to denote
- the type of the label. [RFC1035 4.1.4] allocates two of the four
- possible types and reserves the other two. Proposals for use of
- the remaining types far outnumber those available. More label
- types are needed.
-
-2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
- While the minimum maximum reassembly buffer size still allows a
- limit of 512 octets of UDP payload, most of the hosts now connected
- to the Internet are able to reassemble larger datagrams. Some
- mechanism must be created to allow requestors to advertise larger
- buffer sizes to responders.
-
-3 - Extended Label Types
-
-3.1. The "0 1" label type will now indicate an extended label type,
- whose value is encoded in the lower six bits of the first octet of
- a label. All subsequently developed label types should be encoded
- using an extended label type.
-
-3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
- expansion of the extended label type code space.
-
-4 - OPT pseudo-RR
-
-4.1. One OPT pseudo-RR can be added to the additional data section of
- either a request or a response. An OPT is called a pseudo-RR
- because it pertains to a particular transport level message and not
- to any actual DNS data. OPT RRs shall never be cached, forwarded,
- or stored in or loaded from master files. The quantity of OPT
- pseudo-RRs per message shall be either zero or one, but not
- greater.
-
-4.2. An OPT RR has a fixed part and a variable set of options expressed
- as {attribute, value} pairs. The fixed part holds some DNS meta
- data and also a small collection of new protocol elements which we
- expect to be so popular that it would be a waste of wire space to
- encode them as {attribute, value} pairs.
-
-
-
-
-
-Vixie Standards Track [Page 2]
-
-RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
-
-
-4.3. The fixed part of an OPT RR is structured as follows:
-
- Field Name Field Type Description
- ------------------------------------------------------
- NAME domain name empty (root domain)
- TYPE u_int16_t OPT
- CLASS u_int16_t sender's UDP payload size
- TTL u_int32_t extended RCODE and flags
- RDLEN u_int16_t describes RDATA
- RDATA octet stream {attribute,value} pairs
-
-4.4. The variable part of an OPT RR is encoded in its RDATA and is
- structured as zero or more of the following:
-
- +0 (MSB) +1 (LSB)
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | OPTION-CODE |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: | OPTION-LENGTH |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 4: | |
- / OPTION-DATA /
- / /
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
- OPTION-CODE (Assigned by IANA.)
-
- OPTION-LENGTH Size (in octets) of OPTION-DATA.
-
- OPTION-DATA Varies per OPTION-CODE.
-
-4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
- field) is the number of octets of the largest UDP payload that can
- be reassembled and delivered in the sender's network stack. Note
- that path MTU, with or without fragmentation, may be smaller than
- this.
-
-4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
- reassembly buffer. Choosing 1280 on an Ethernet connected
- requestor would be reasonable. The consequence of choosing too
- large a value may be an ICMP message from an intermediate
- gateway, or even a silent drop of the response message.
-
-4.5.2. Both requestors and responders are advised to take account of the
- path's discovered MTU (if already known) when considering message
- sizes.
-
-
-
-
-
-Vixie Standards Track [Page 3]
-
-RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
-
-
-4.5.3. The requestor's maximum payload size can change over time, and
- should therefore not be cached for use beyond the transaction in
- which it is advertised.
-
-4.5.4. The responder's maximum payload size can change over time, but
- can be reasonably expected to remain constant between two
- sequential transactions; for example, a meaningless QUERY to
- discover a responder's maximum UDP payload size, followed
- immediately by an UPDATE which takes advantage of this size.
- (This is considered preferrable to the outright use of TCP for
- oversized requests, if there is any reason to suspect that the
- responder implements EDNS, and if a request will not fit in the
- default 512 payload size limit.)
-
-4.5.5. Due to transaction overhead, it is unwise to advertise an
- architectural limit as a maximum UDP payload size. Just because
- your stack can reassemble 64KB datagrams, don't assume that you
- want to spend more than about 4KB of state memory per ongoing
- transaction.
-
-4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
- are structured as follows:
-
- +0 (MSB) +1 (LSB)
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | EXTENDED-RCODE | VERSION |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: | Z |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
- EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note
- that EXTENDED-RCODE value "0" indicates that an
- unextended RCODE is in use (values "0" through "15").
-
- VERSION Indicates the implementation level of whoever sets
- it. Full conformance with this specification is
- indicated by version "0." Requestors are encouraged
- to set this to the lowest implemented level capable
- of expressing a transaction, to minimize the
- responder and network load of discovering the
- greatest common implementation level between
- requestor and responder. A requestor's version
- numbering strategy should ideally be a run time
- configuration option.
-
- If a responder does not implement the VERSION level
- of the request, then it answers with RCODE=BADVERS.
- All responses will be limited in format to the
-
-
-
-Vixie Standards Track [Page 4]
-
-RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
-
-
- VERSION level of the request, but the VERSION of each
- response will be the highest implementation level of
- the responder. In this way a requestor will learn
- the implementation level of a responder as a side
- effect of every response, including error responses,
- including RCODE=BADVERS.
-
- Z Set to zero by senders and ignored by receivers,
- unless modified in a subsequent specification.
-
-5 - Transport Considerations
-
-5.1. The presence of an OPT pseudo-RR in a request should be taken as an
- indication that the requestor fully implements the given version of
- EDNS, and can correctly understand any response that conforms to
- that feature's specification.
-
-5.2. Lack of use of these features in a request must be taken as an
- indication that the requestor does not implement any part of this
- specification and that the responder may make no use of any
- protocol extension described here in its response.
-
-5.3. Responders who do not understand these protocol extensions are
- expected to send a response with RCODE NOTIMPL, FORMERR, or
- SERVFAIL. Therefore use of extensions should be "probed" such that
- a responder who isn't known to support them be allowed a retry with
- no extensions if it responds with such an RCODE. If a responder's
- capability level is cached by a requestor, a new probe should be
- sent periodically to test for changes to responder capability.
-
-6 - Security Considerations
-
- Requestor-side specification of the maximum buffer size may open a
- new DNS denial of service attack if responders can be made to send
- messages which are too large for intermediate gateways to forward,
- thus leading to potential ICMP storms between gateways and
- responders.
-
-7 - IANA Considerations
-
- The IANA has assigned RR type code 41 for OPT.
-
- It is the recommendation of this document and its working group
- that IANA create a registry for EDNS Extended Label Types, for EDNS
- Option Codes, and for EDNS Version Numbers.
-
- This document assigns label type 0b01xxxxxx as "EDNS Extended Label
- Type." We request that IANA record this assignment.
-
-
-
-Vixie Standards Track [Page 5]
-
-RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
-
-
- This document assigns extended label type 0bxx111111 as "Reserved
- for future extended label types." We request that IANA record this
- assignment.
-
- This document assigns option code 65535 to "Reserved for future
- expansion."
-
- This document expands the RCODE space from 4 bits to 12 bits. This
- will allow IANA to assign more than the 16 distinct RCODE values
- allowed in [RFC1035].
-
- This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
- IESG approval should be required to create new entries in the EDNS
- Extended Label Type or EDNS Version Number registries, while any
- published RFC (including Informational, Experimental, or BCP)
- should be grounds for allocation of an EDNS Option Code.
-
-8 - Acknowledgements
-
- Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
- Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
- Narten were each instrumental in creating and refining this
- specification.
-
-9 - References
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
-10 - Author's Address
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
-
- Phone: +1 650 779 7001
- EMail: vixie@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie Standards Track [Page 6]
-
-RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
-
-
-11 - Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie Standards Track [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2672.txt b/contrib/bind9/doc/rfc/rfc2672.txt
deleted file mode 100644
index 11030168dcd0e..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2672.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Crawford
-Request for Comments: 2672 Fermilab
-Category: Standards Track August 1999
-
-
- Non-Terminal DNS Name Redirection
-
-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 (1999). All Rights Reserved.
-
-1. Introduction
-
- This document defines a new DNS Resource Record called "DNAME", which
- provides the capability to map an entire subtree of the DNS name
- space to another domain. It differs from the CNAME record which maps
- a single node of the name space.
-
- 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 [KWORD].
-
-2. Motivation
-
- This Resource Record and its processing rules were conceived as a
- solution to the problem of maintaining address-to-name mappings in a
- context of network renumbering. Without the DNAME mechanism, an
- authoritative DNS server for the address-to-name mappings of some
- network must be reconfigured when that network is renumbered. With
- DNAME, the zone can be constructed so that it needs no modification
- when renumbered. DNAME can also be useful in other situations, such
- as when an organizational unit is renamed.
-
-3. The DNAME Resource Record
-
- The DNAME RR has mnemonic DNAME and type code 39 (decimal).
-
-
-
-
-
-
-
-Crawford Standards Track [Page 1]
-
-RFC 2672 Non-Terminal DNS Name Redirection August 1999
-
-
- DNAME has the following format:
-
- <owner> <ttl> <class> DNAME <target>
-
- The format is not class-sensitive. All fields are required. The
- RDATA field <target> is a <domain-name> [DNSIS].
-
- The DNAME RR causes type NS additional section processing.
-
- The effect of the DNAME record is the substitution of the record's
- <target> for its <owner> as a suffix of a domain name. A "no-
- descendants" limitation governs the use of DNAMEs in a zone file:
-
- If a DNAME RR is present at a node N, there may be other data at N
- (except a CNAME or another DNAME), but there MUST be no data at
- any descendant of N. This restriction applies only to records of
- the same class as the DNAME record.
-
- This rule assures predictable results when a DNAME record is cached
- by a server which is not authoritative for the record's zone. It
- MUST be enforced when authoritative zone data is loaded. Together
- with the rules for DNS zone authority [DNSCLR] it implies that DNAME
- and NS records can only coexist at the top of a zone which has only
- one node.
-
- The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
- portion of a DNAME record unless the sending server has some way of
- knowing that the receiver understands the DNAME record format.
- Signalling such understanding is expected to be the subject of future
- DNS Extensions.
-
- Naming loops can be created with DNAME records or a combination of
- DNAME and CNAME records, just as they can with CNAME records alone.
- Resolvers, including resolvers embedded in DNS servers, MUST limit
- the resources they devote to any query. Implementors should note,
- however, that fairly lengthy chains of DNAME records may be valid.
-
-4. Query Processing
-
- To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
- must be modified slightly for both servers and resolvers.
-
- Both modified algorithms incorporate the operation of making a
- substitution on a name (either QNAME or SNAME) under control of a
- DNAME record. This operation will be referred to as "the DNAME
- substitution".
-
-
-
-
-
-Crawford Standards Track [Page 2]
-
-RFC 2672 Non-Terminal DNS Name Redirection August 1999
-
-
-4.1. Processing by Servers
-
- For a server performing non-recursive service steps 3.c and 4 of
- section 4.3.2 [DNSCF] are changed to check for a DNAME record before
- checking for a wildcard ("*") label, and to return certain DNAME
- records from zone data and the cache.
-
- DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
- non-extended queries are presumed not to understand the semantics of
- the DNAME record, so a server which implements this specification,
- when answering a non-extended query, SHOULD synthesize a CNAME record
- for each DNAME record encountered during query processing to help the
- client reach the correct DNS data. The behavior of clients and
- servers under Extended DNS versions greater than 0 will be specified
- when those versions are defined.
-
- The synthesized CNAME RR, if provided, MUST have
-
- The same CLASS as the QCLASS of the query,
-
- TTL equal to zero,
-
- An <owner> equal to the QNAME in effect at the moment the DNAME RR
- was encountered, and
-
- An RDATA field containing the new QNAME formed by the action of
- the DNAME substitution.
-
- If the server has the appropriate key on-line [DNSSEC, SECDYN], it
- MAY generate and return a SIG RR for the synthesized CNAME RR.
-
- The revised server algorithm is:
-
- 1. Set or clear the value of recursion available in the response
- depending on whether the name server is willing to provide
- recursive service. If recursive service is available and
- requested via the RD bit in the query, go to step 5, otherwise
- step 2.
-
- 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.
-
- 3. Start matching down, label by label, in the zone. The matching
- process can terminate several ways:
-
-
-
-
-
-
-Crawford Standards Track [Page 3]
-
-RFC 2672 Non-Terminal DNS Name Redirection August 1999
-
-
- a. If the whole of QNAME is matched, we have found the node.
-
- If the data at the node is a CNAME, and QTYPE doesn't match
- CNAME, copy the CNAME RR into the answer section of the
- response, change QNAME to the canonical name in the CNAME RR,
- and go back to step 1.
-
- Otherwise, copy all RRs which match QTYPE into the answer
- section and go to step 6.
-
- b. If a match would take us out of the authoritative data, we have
- a referral. This happens when we encounter a node with NS RRs
- marking cuts along the bottom of a zone.
-
- Copy the NS RRs for the subzone into the authority section of
- the reply. Put whatever addresses are available into the
- additional section, using glue RRs if the addresses are not
- available from authoritative data or the cache. Go to step 4.
-
- c. If at some label, a match is impossible (i.e., the
- corresponding label does not exist), look to see whether the
- last label matched has a DNAME record.
-
- If a DNAME record exists at that point, copy that record into
- the answer section. If substitution of its <target> for its
- <owner> in QNAME would overflow the legal size for a <domain-
- name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
- perform the substitution and continue. If the query was not
- extended [EDNS0] with a Version indicating understanding of the
- DNAME record, the server SHOULD synthesize a CNAME record as
- described above and include it in the answer section. Go back
- to step 1.
-
- If there was no DNAME record, look to see if the "*" label
- exists.
-
- 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.
-
-
-
-
-
-Crawford Standards Track [Page 4]
-
-RFC 2672 Non-Terminal DNS Name Redirection August 1999
-
-
- 4. Start matching down in the cache. If QNAME is found in the cache,
- copy all RRs attached to it that match QTYPE into the answer
- section. If QNAME is not found in the cache but a DNAME record is
- present at an ancestor of QNAME, copy that DNAME record into the
- answer section. If there was no delegation from authoritative
- data, look for the best one from the cache, and put it in the
- authority section. Go to step 6.
-
- 5. Use the local resolver or a copy of its algorithm (see resolver
- section of this memo) to answer the query. Store the results,
- including any intermediate CNAMEs and DNAMEs, in the answer
- section of the response.
-
- 6. Using local data only, attempt to add other RRs which may be
- useful to the additional section of the query. Exit.
-
- Note that there will be at most one ancestor with a DNAME as
- described in step 4 unless some zone's data is in violation of the
- no-descendants limitation in section 3. An implementation might take
- advantage of this limitation by stopping the search of step 3c or
- step 4 when a DNAME record is encountered.
-
-4.2. Processing by Resolvers
-
- A resolver or a server providing recursive service must be modified
- to treat a DNAME as somewhat analogous to a CNAME. The resolver
- algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
- as 4.e and insert a new 4.d. The complete algorithm becomes:
-
- 1. See if the answer is in local information, and if so return it to
- the client.
-
- 2. Find the best servers to ask.
-
- 3. Send them queries until one returns a response.
-
- 4. Analyze the response, either:
-
- a. if the response answers the question or contains a name error,
- cache the data as well as returning it back to the client.
-
- b. if the response contains a better delegation to other servers,
- cache the delegation information, and go to step 2.
-
- c. if the response shows a CNAME and that is not the answer
- itself, cache the CNAME, change the SNAME to the canonical name
- in the CNAME RR and go to step 1.
-
-
-
-
-Crawford Standards Track [Page 5]
-
-RFC 2672 Non-Terminal DNS Name Redirection August 1999
-
-
- d. if the response shows a DNAME and that is not the answer
- itself, cache the DNAME. If substitution of the DNAME's
- <target> for its <owner> in the SNAME would overflow the legal
- size for a <domain-name>, return an implementation-dependent
- error to the application; otherwise perform the substitution
- and go to step 1.
-
- e. if the response shows a server failure or other bizarre
- contents, delete the server from the SLIST and go back to step
- 3.
-
- A resolver or recursive server which understands DNAME records but
- sends non-extended queries MUST augment step 4.c by deleting from the
- reply any CNAME records which have an <owner> which is a subdomain of
- the <owner> of any DNAME record in the response.
-
-5. Examples of Use
-
-5.1. Organizational Renaming
-
- If an organization with domain name FROBOZZ.EXAMPLE became part of an
- organization with domain name ACME.EXAMPLE, it might ease transition
- by placing information such as this in its old zone.
-
- frobozz.example. DNAME frobozz-division.acme.example.
- MX 10 mailhub.acme.example.
-
- The response to an extended recursive query for www.frobozz.example
- would contain, in the answer section, the DNAME record shown above
- and the relevant RRs for www.frobozz-division.acme.example.
-
-5.2. Classless Delegation of Shorter Prefixes
-
- The classless scheme for in-addr.arpa delegation [INADDR] can be
- extended to prefixes shorter than 24 bits by use of the DNAME record.
- For example, the prefix 192.0.8.0/22 can be delegated by the
- following records.
-
- $ORIGIN 0.192.in-addr.arpa.
- 8/22 NS ns.slash-22-holder.example.
- 8 DNAME 8.8/22
- 9 DNAME 9.8/22
- 10 DNAME 10.8/22
- 11 DNAME 11.8/22
-
-
-
-
-
-
-
-Crawford Standards Track [Page 6]
-
-RFC 2672 Non-Terminal DNS Name Redirection August 1999
-
-
- A typical entry in the resulting reverse zone for some host with
- address 192.0.9.33 might be
-
- $ORIGIN 8/22.0.192.in-addr.arpa.
- 33.9 PTR somehost.slash-22-holder.example.
-
- The same advisory remarks concerning the choice of the "/" character
- apply here as in [INADDR].
-
-5.3. Network Renumbering Support
-
- If IPv4 network renumbering were common, maintenance of address space
- delegation could be simplified by using DNAME records instead of NS
- records to delegate.
-
- $ORIGIN new-style.in-addr.arpa.
- 189.190 DNAME in-addr.example.net.
-
- $ORIGIN in-addr.example.net.
- 188 DNAME in-addr.customer.example.
-
- $ORIGIN in-addr.customer.example.
- 1 PTR www.customer.example.
- 2 PTR mailhub.customer.example.
- ; etc ...
-
- This would allow the address space 190.189.0.0/16 assigned to the ISP
- "example.net" to be changed without the necessity of altering the
- zone files describing the use of that space by the ISP and its
- customers.
-
- Renumbering IPv4 networks is currently so arduous a task that
- updating the DNS is only a small part of the labor, so this scheme
- may have a low value. But it is hoped that in IPv6 the renumbering
- task will be quite different and the DNAME mechanism may play a
- useful part.
-
-6. IANA Considerations
-
- This document defines a new DNS Resource Record type with the
- mnemonic DNAME and type code 39 (decimal). The naming/numbering
- space is defined in [DNSIS]. This name and number have already been
- registered with the IANA.
-
-
-
-
-
-
-
-
-Crawford Standards Track [Page 7]
-
-RFC 2672 Non-Terminal DNS Name Redirection August 1999
-
-
-7. Security Considerations
-
- The DNAME record is similar to the CNAME record with regard to the
- consequences of insertion of a spoofed record into a DNS server or
- resolver, differing in that the DNAME's effect covers a whole subtree
- of the name space. The facilities of [DNSSEC] are available to
- authenticate this record type.
-
-8. References
-
- [DNSCF] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [DNSIS] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
- Security Extensions", RFC 2065, January 1997.
-
- [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
- "Dynamic Updates in the Domain Name System", RFC 2136, April
- 1997.
-
- [EDNS0] Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
- ADDR.ARPA delegation", RFC 2317, March 1998.
-
- [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels," BCP 14, RFC 2119, March 1997.
-
- [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
- Update", RFC 2137, April 1997.
-
-9. Author's Address
-
- Matt Crawford
- Fermilab MS 368
- PO Box 500
- Batavia, IL 60510
- USA
-
- Phone: +1 630 840-3461
- EMail: crawdad@fnal.gov
-
-
-
-Crawford Standards Track [Page 8]
-
-RFC 2672 Non-Terminal DNS Name Redirection August 1999
-
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford Standards Track [Page 9]
-
diff --git a/contrib/bind9/doc/rfc/rfc2673.txt b/contrib/bind9/doc/rfc/rfc2673.txt
deleted file mode 100644
index 19d272e929995..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2673.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Crawford
-Request for Comments: 2673 Fermilab
-Category: Standards Track August 1999
-
-
- Binary Labels in the Domain Name System
-
-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 (1999). All Rights Reserved.
-
-1. Introduction and Terminology
-
- This document defines a "Bit-String Label" which may appear within
- domain names. This new label type compactly represents a sequence of
- "One-Bit Labels" and enables resource records to be stored at any
- bit-boundary in a binary-named section of the domain name tree.
-
- 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 [KWORD].
-
-2. Motivation
-
- Binary labels are intended to efficiently solve the problem of
- storing data and delegating authority on arbitrary boundaries when
- the structure of underlying name space is most naturally represented
- in binary.
-
-3. Label Format
-
- Up to 256 One-Bit Labels can be grouped into a single Bit-String
- Label. Within a Bit-String Label the most significant or "highest
- level" bit appears first. This is unlike the ordering of DNS labels
- themselves, which has the least significant or "lowest level" label
- first. Nonetheless, this ordering seems to be the most natural and
- efficient for representing binary labels.
-
-
-
-
-
-
-Crawford Standards Track [Page 1]
-
-RFC 2673 Binary Labels in the Domain Name System August 1999
-
-
- Among consecutive Bit-String Labels, the bits in the first-appearing
- label are less significant or "at a lower level" than the bits in
- subsequent Bit-String Labels, just as ASCII labels are ordered.
-
-3.1. Encoding
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
- |0 1| ELT | Count | Label ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
-
- (Each tic mark represents one bit.)
-
-
- ELT 000001 binary, the six-bit extended label type [EDNS0]
- assigned to the Bit-String Label.
-
- Count The number of significant bits in the Label field. A Count
- value of zero indicates that 256 bits are significant.
- (Thus the null label representing the DNS root cannot be
- represented as a Bit String Label.)
-
- Label The bit string representing a sequence of One-Bit Labels,
- with the most significant bit first. That is, the One-Bit
- Label in position 17 in the diagram above represents a
- subdomain of the domain represented by the One-Bit Label in
- position 16, and so on.
-
- The Label field is padded on the right with zero to seven
- pad bits to make the entire field occupy an integral number
- of octets. These pad bits MUST be zero on transmission and
- ignored on reception.
-
- A sequence of bits may be split into two or more Bit-String Labels,
- but the division points have no significance and need not be
- preserved. An excessively clever server implementation might split
- Bit-String Labels so as to maximize the effectiveness of message
- compression [DNSIS]. A simpler server might divide Bit-String Labels
- at zone boundaries, if any zone boundaries happen to fall between
- One-Bit Labels.
-
-3.2. Textual Representation
-
- A Bit-String Label is represented in text -- in a zone file, for
- example -- as a <bit-spec> surrounded by the delimiters "\[" and "]".
- The <bit-spec> is either a dotted quad or a base indicator and a
- sequence of digits appropriate to that base, optionally followed by a
-
-
-
-Crawford Standards Track [Page 2]
-
-RFC 2673 Binary Labels in the Domain Name System August 1999
-
-
- slash and a length. The base indicators are "b", "o" and "x",
- denoting base 2, 8 and 16 respectively. The length counts the
- significant bits and MUST be between 1 and 32, inclusive, after a
- dotted quad, or between 1 and 256, inclusive, after one of the other
- forms. If the length is omitted, the implicit length is 32 for a
- dotted quad or 1, 3 or 4 times the number of binary, octal or
- hexadecimal digits supplied, respectively, for the other forms.
-
- In augmented Backus-Naur form [ABNF],
-
- bit-string-label = "\[" bit-spec "]"
-
- bit-spec = bit-data [ "/" length ]
- / dotted-quad [ "/" slength ]
-
- bit-data = "x" 1*64HEXDIG
- / "o" 1*86OCTDIG
- / "b" 1*256BIT
-
- dotted-quad = decbyte "." decbyte "." decbyte "." decbyte
-
- decbyte = 1*3DIGIT
-
- length = NZDIGIT *2DIGIT
-
- slength = NZDIGIT [ DIGIT ]
-
- OCTDIG = %x30-37
-
- NZDIGIT = %x31-39
-
- If a <length> is present, the number of digits in the <bit-data> MUST
- be just sufficient to contain the number of bits specified by the
- <length>. If there are insignificant bits in a final hexadecimal or
- octal digit, they MUST be zero. A <dotted-quad> always has all four
- parts even if the associated <slength> is less than 24, but, like the
- other forms, insignificant bits MUST be zero.
-
- Each number represented by a <decbyte> must be between 0 and 255,
- inclusive.
-
- The number represented by <length> must be between 1 and 256
- inclusive.
-
- The number represented by <slength> must be between 1 and 32
- inclusive.
-
-
-
-
-
-Crawford Standards Track [Page 3]
-
-RFC 2673 Binary Labels in the Domain Name System August 1999
-
-
- When the textual form of a Bit-String Label is generated by machine,
- the length SHOULD be explicit, not implicit.
-
-3.2.1. Examples
-
- The following four textual forms represent the same Bit-String Label.
-
- \[b11010000011101]
- \[o64072/14]
- \[xd074/14]
- \[208.116.0.0/14]
-
- The following represents two consecutive Bit-String Labels which
- denote the same relative point in the DNS tree as any of the above
- single Bit-String Labels.
-
- \[b11101].\[o640]
-
-3.3. Canonical Representation and Sort Order
-
- Both the wire form and the text form of binary labels have a degree
- of flexibility in their grouping into multiple consecutive Bit-String
- Labels. For generating and checking DNS signature records [DNSSEC]
- binary labels must be in a predictable form. This canonical form is
- defined as the form which has the fewest possible Bit-String Labels
- and in which all except possibly the first (least significant) label
- in any sequence of consecutive Bit-String Labels is of maximum
- length.
-
- For example, the canonical form of any sequence of up to 256 One-Bit
- Labels has a single Bit-String Label, and the canonical form of a
- sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
- which the second and third contain 256 label bits.
-
- The canonical sort order of domain names [DNSSEC] is extended to
- encompass binary labels as follows. Sorting is still label-by-label,
- from most to least significant, where a label may now be a One-Bit
- Label or a standard (code 00) label. Any One-Bit Label sorts before
- any standard label, and a 0 bit sorts before a 1 bit. The absence of
- a label sorts before any label, as specified in [DNSSEC].
-
-
-
-
-
-
-
-
-
-
-
-Crawford Standards Track [Page 4]
-
-RFC 2673 Binary Labels in the Domain Name System August 1999
-
-
- For example, the following domain names are correctly sorted.
-
- foo.example
- \[b1].foo.example
- \[b100].foo.example
- \[b101].foo.example
- bravo.\[b10].foo.example
- alpha.foo.example
-
-4. Processing Rules
-
- A One-Bit Label never matches any other kind of label. In
- particular, the DNS labels represented by the single ASCII characters
- "0" and "1" do not match One-Bit Labels represented by the bit values
- 0 and 1.
-
-5. Discussion
-
- A Count of zero in the wire-form represents a 256-bit sequence, not
- to optimize that particular case, but to make it completely
- impossible to have a zero-bit label.
-
-6. IANA Considerations
-
- This document defines one Extended Label Type, termed the Bit-String
- Label, and requests registration of the code point 000001 binary in
- the space defined by [EDNS0].
-
-7. Security Considerations
-
- All security considerations which apply to traditional ASCII DNS
- labels apply equally to binary labels. he canonicalization and
- sorting rules of section 3.3 allow these to be addressed by DNS
- Security [DNSSEC].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford Standards Track [Page 5]
-
-RFC 2673 Binary Labels in the Domain Name System August 1999
-
-
-8. References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [DNSIS] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security
- Extensions", RFC 2065, January 1997
-
- [EDNS0] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
- [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-9. Author's Address
-
- Matt Crawford
- Fermilab MS 368
- PO Box 500
- Batavia, IL 60510
- USA
-
- Phone: +1 630 840-3461
- EMail: crawdad@fnal.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford Standards Track [Page 6]
-
-RFC 2673 Binary Labels in the Domain Name System August 1999
-
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford Standards Track [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2782.txt b/contrib/bind9/doc/rfc/rfc2782.txt
deleted file mode 100644
index 1827f104c8387..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2782.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Gulbrandsen
-Request for Comments: 2782 Troll Technologies
-Obsoletes: 2052 P. Vixie
-Category: Standards Track Internet Software Consortium
- L. Esibov
- Microsoft Corp.
- February 2000
-
-
- A DNS RR for specifying the location of services (DNS SRV)
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- This document describes a DNS RR which specifies the location of the
- server(s) for a specific protocol and domain.
-
-Overview and rationale
-
- Currently, one must either know the exact address of a server to
- contact it, or broadcast a question.
-
- The SRV RR allows administrators to use several servers for a single
- domain, to move services from host to host with little fuss, and to
- designate some hosts as primary servers for a service and others as
- backups.
-
- Clients ask for a specific service/protocol for a specific domain
- (the word domain is used here in the strict RFC 1034 sense), and get
- back the names of any available servers.
-
- Note that where this document refers to "address records", it means A
- RR's, AAAA RR's, or their most modern equivalent.
-
-
-
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 1]
-
-RFC 2782 DNS SRV RR February 2000
-
-
-Definitions
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
- used in this document are to be interpreted as specified in [BCP 14].
- Other terms used in this document are defined in the DNS
- specification, RFC 1034.
-
-Applicability Statement
-
- In general, it is expected that SRV records will be used by clients
- for applications where the relevant protocol specification indicates
- that clients should use the SRV record. Such specification MUST
- define the symbolic name to be used in the Service field of the SRV
- record as described below. It also MUST include security
- considerations. Service SRV records SHOULD NOT be used in the absence
- of such specification.
-
-Introductory example
-
- If a SRV-cognizant LDAP client wants to discover a LDAP server that
- supports TCP protocol and provides LDAP service for the domain
- example.com., it does a lookup of
-
- _ldap._tcp.example.com
-
- as described in [ARM]. The example zone file near the end of this
- memo contains answering RRs for an SRV query.
-
- Note: LDAP is chosen as an example for illustrative purposes only,
- and the LDAP examples used in this document should not be considered
- a definitive statement on the recommended way for LDAP to use SRV
- records. As described in the earlier applicability section, consult
- the appropriate LDAP documents for the recommended procedures.
-
-The format of the SRV RR
-
- Here is the format of the SRV RR, whose DNS type code is 33:
-
- _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-
- (There is an example near the end of this document.)
-
- Service
- The symbolic name of the desired service, as defined in Assigned
- Numbers [STD 2] or locally. An underscore (_) is prepended to
- the service identifier to avoid collisions with DNS labels that
- occur in nature.
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 2]
-
-RFC 2782 DNS SRV RR February 2000
-
-
- Some widely used services, notably POP, don't have a single
- universal name. If Assigned Numbers names the service
- indicated, that name is the only name which is legal for SRV
- lookups. The Service is case insensitive.
-
- Proto
- The symbolic name of the desired protocol, with an underscore
- (_) prepended to prevent collisions with DNS labels that occur
- in nature. _TCP and _UDP are at present the most useful values
- for this field, though any name defined by Assigned Numbers or
- locally may be used (as for Service). The Proto is case
- insensitive.
-
- 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.
-
- TTL
- Standard DNS meaning [RFC 1035].
-
- Class
- Standard DNS meaning [RFC 1035]. SRV records occur in the IN
- Class.
-
- Priority
- The priority of this target host. A client MUST attempt to
- contact the target host with the lowest-numbered priority it can
- reach; target hosts with the same priority SHOULD be tried in an
- order defined by the weight field. The range is 0-65535. This
- is a 16 bit unsigned integer in network byte order.
-
- Weight
- A server selection mechanism. The weight field specifies a
- relative weight for entries with the same priority. Larger
- weights SHOULD be given a proportionately higher probability of
- being selected. The range of this number is 0-65535. This is a
- 16 bit unsigned integer in network byte order. Domain
- administrators SHOULD use Weight 0 when there isn't any server
- selection to do, to make the RR easier to read for humans (less
- noisy). In the presence of records containing weights greater
- than 0, records with weight 0 should have a very small chance of
- being selected.
-
- In the absence of a protocol whose specification calls for the
- use of other weighting information, a client arranges the SRV
- RRs of the same Priority in the order in which target hosts,
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 3]
-
-RFC 2782 DNS SRV RR February 2000
-
-
- specified by the SRV RRs, will be contacted. The following
- algorithm SHOULD be used to order the SRV RRs of the same
- priority:
-
- To select a target to be contacted next, arrange all SRV RRs
- (that have not been ordered yet) in any order, except that all
- those with weight 0 are placed at the beginning of the list.
-
- Compute the sum of the weights of those RRs, and with each RR
- associate the running sum in the selected order. Then choose a
- uniform random number between 0 and the sum computed
- (inclusive), and select the RR whose running sum value is the
- first in the selected order which is greater than or equal to
- the random number selected. The target host specified in the
- selected SRV RR is the next one to be contacted by the client.
- Remove this SRV RR from the set of the unordered SRV RRs and
- apply the described algorithm to the unordered SRV RRs to select
- the next target host. Continue the ordering process until there
- are no unordered SRV RRs. This process is repeated for each
- Priority.
-
- Port
- The port on this target host of this service. The range is 0-
- 65535. This is a 16 bit unsigned integer in network byte order.
- This is often as specified in Assigned Numbers but need not be.
-
- Target
- The domain name of the target host. There MUST be one or more
- address records for this name, the name MUST NOT be an alias (in
- the sense of RFC 1034 or RFC 2181). Implementors are urged, but
- not required, to return the address record(s) in the Additional
- Data section. Unless and until permitted by future standards
- action, name compression is not to be used for this field.
-
- A Target of "." means that the service is decidedly not
- available at this domain.
-
-Domain administrator advice
-
- Expecting everyone to update their client applications when the first
- server publishes a SRV RR is futile (even if desirable). Therefore
- SRV would have to coexist with address record lookups for existing
- protocols, and DNS administrators should try to provide address
- records to support old clients:
-
- - Where the services for a single domain are spread over several
- hosts, it seems advisable to have a list of address records at
- the same DNS node as the SRV RR, listing reasonable (if perhaps
-
-
-
-Gulbrandsen, et al. Standards Track [Page 4]
-
-RFC 2782 DNS SRV RR February 2000
-
-
- suboptimal) fallback hosts for Telnet, NNTP and other protocols
- likely to be used with this name. Note that some programs only
- try the first address they get back from e.g. gethostbyname(),
- and we don't know how widespread this behavior is.
-
- - Where one service is provided by several hosts, one can either
- provide address records for all the hosts (in which case the
- round-robin mechanism, where available, will share the load
- equally) or just for one (presumably the fastest).
-
- - If a host is intended to provide a service only when the main
- server(s) is/are down, it probably shouldn't be listed in
- address records.
-
- - Hosts that are referenced by backup address records must use the
- port number specified in Assigned Numbers for the service.
-
- - Designers of future protocols for which "secondary servers" is
- not useful (or meaningful) may choose to not use SRV's support
- for secondary servers. Clients for such protocols may use or
- ignore SRV RRs with Priority higher than the RR with the lowest
- Priority for a domain.
-
- Currently there's a practical limit of 512 bytes for DNS replies.
- Until all resolvers can handle larger responses, domain
- administrators are strongly advised to keep their SRV replies below
- 512 bytes.
-
- All round numbers, wrote Dr. Johnson, are false, and these numbers
- are very round: A reply packet has a 30-byte overhead plus the name
- of the service ("_ldap._tcp.example.com" for instance); each SRV RR
- adds 20 bytes plus the name of the target host; each NS RR in the NS
- section is 15 bytes plus the name of the name server host; and
- finally each A RR in the additional data section is 20 bytes or so,
- and there are A's for each SRV and NS RR mentioned in the answer.
- This size estimate is extremely crude, but shouldn't underestimate
- the actual answer size by much. If an answer may be close to the
- limit, using a DNS query tool (e.g. "dig") to look at the actual
- answer is a good idea.
-
-The "Weight" field
-
- Weight, the server selection field, is not quite satisfactory, but
- the actual load on typical servers changes much too quickly to be
- kept around in DNS caches. It seems to the authors that offering
- administrators a way to say "this machine is three times as fast as
- that one" is the best that can practically be done.
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 5]
-
-RFC 2782 DNS SRV RR February 2000
-
-
- The only way the authors can see of getting a "better" load figure is
- asking a separate server when the client selects a server and
- contacts it. For short-lived services an extra step in the
- connection establishment seems too expensive, and for long-lived
- services, the load figure may well be thrown off a minute after the
- connection is established when someone else starts or finishes a
- heavy job.
-
- Note: There are currently various experiments at providing relative
- network proximity estimation, available bandwidth estimation, and
- similar services. Use of the SRV record with such facilities, and in
- particular the interpretation of the Weight field when these
- facilities are used, is for further study. Weight is only intended
- for static, not dynamic, server selection. Using SRV weight for
- dynamic server selection would require assigning unreasonably short
- TTLs to the SRV RRs, which would limit the usefulness of the DNS
- caching mechanism, thus increasing overall network load and
- decreasing overall reliability. Server selection via SRV is only
- intended to express static information such as "this server has a
- faster CPU than that one" or "this server has a much better network
- connection than that one".
-
-The Port number
-
- Currently, the translation from service name to port number happens
- at the client, often using a file such as /etc/services.
-
- Moving this information to the DNS makes it less necessary to update
- these files on every single computer of the net every time a new
- service is added, and makes it possible to move standard services out
- of the "root-only" port range on unix.
-
-Usage rules
-
- A SRV-cognizant client SHOULD use this procedure to locate a list of
- servers and connect to the preferred one:
-
- Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
- QTYPE=SRV.
-
- If the reply is NOERROR, ANCOUNT>0 and there is at least one
- SRV RR which specifies the requested Service and Protocol in
- the reply:
-
- If there is precisely one SRV RR, and its Target is "."
- (the root domain), abort.
-
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 6]
-
-RFC 2782 DNS SRV RR February 2000
-
-
- Else, for all such RR's, build a list of (Priority, Weight,
- Target) tuples
-
- Sort the list by priority (lowest number first)
-
- Create a new empty list
-
- For each distinct priority level
- While there are still elements left at this priority
- level
-
- Select an element as specified above, in the
- description of Weight in "The format of the SRV
- RR" Section, and move it to the tail of the new
- list
-
- For each element in the new list
-
- query the DNS for address records for the Target or
- use any such records found in the Additional Data
- section of the earlier SRV response.
-
- for each address record found, try to connect to the
- (protocol, address, service).
-
- else
-
- Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
-
- for each address record found, try to connect to the
- (protocol, address, service)
-
-Notes:
-
- - Port numbers SHOULD NOT be used in place of the symbolic service
- or protocol names (for the same reason why variant names cannot
- be allowed: Applications would have to do two or more lookups).
-
- - If a truncated response comes back from an SRV query, the rules
- described in [RFC 2181] shall apply.
-
- - A client MUST parse all of the RR's in the reply.
-
- - If the Additional Data section doesn't contain address records
- for all the SRV RR's and the client may want to connect to the
- target host(s) involved, the client MUST look up the address
- record(s). (This happens quite often when the address record
- has shorter TTL than the SRV or NS RR's.)
-
-
-
-Gulbrandsen, et al. Standards Track [Page 7]
-
-RFC 2782 DNS SRV RR February 2000
-
-
- - Future protocols could be designed to use SRV RR lookups as the
- means by which clients locate their servers.
-
-Fictional example
-
- This example uses fictional service "foobar" as an aid in
- understanding SRV records. If ever service "foobar" is implemented,
- it is not intended that it will necessarily use SRV records. This is
- (part of) the zone file for example.com, a still-unused domain:
-
- $ORIGIN example.com.
- @ SOA server.example.com. root.example.com. (
- 1995032001 3600 3600 604800 86400 )
- NS server.example.com.
- NS ns1.ip-provider.net.
- NS ns2.ip-provider.net.
- ; foobar - use old-slow-box or new-fast-box if either is
- ; available, make three quarters of the logins go to
- ; new-fast-box.
- _foobar._tcp SRV 0 1 9 old-slow-box.example.com.
- SRV 0 3 9 new-fast-box.example.com.
- ; if neither old-slow-box or new-fast-box is up, switch to
- ; using the sysdmin's box and the server
- SRV 1 0 9 sysadmins-box.example.com.
- SRV 1 0 9 server.example.com.
- server A 172.30.79.10
- old-slow-box A 172.30.79.11
- sysadmins-box A 172.30.79.12
- new-fast-box A 172.30.79.13
- ; NO other services are supported
- *._tcp SRV 0 0 0 .
- *._udp SRV 0 0 0 .
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 8]
-
-RFC 2782 DNS SRV RR February 2000
-
-
- In this example, a client of the "foobar" service in the
- "example.com." domain needs an SRV lookup of
- "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
- box.example.com." and/or the other hosts named. The size of the SRV
- reply is approximately 365 bytes:
-
- 30 bytes general overhead
- 20 bytes for the query string, "_foobar._tcp.example.com."
- 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
- fast-box", "old-slow-box", "server" and "sysadmins-box" -
- "example.com" in the query section is quoted here and doesn't
- need to be counted again.
- 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
- "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
- quoted and only needs to be counted once.
- 120 bytes for the 6 address records (assuming IPv4 only) mentioned
- by the SRV and NS RR's.
-
-IANA Considerations
-
- The IANA has assigned RR type value 33 to the SRV RR. No other IANA
- services are required by this document.
-
-Changes from RFC 2052
-
- This document obsoletes RFC 2052. The major change from that
- previous, experimental, version of this specification is that now the
- protocol and service labels are prepended with an underscore, to
- lower the probability of an accidental clash with a similar name used
- for unrelated purposes. Aside from that, changes are only intended
- to increase the clarity and completeness of the document. This
- document especially clarifies the use of the Weight field of the SRV
- records.
-
-Security Considerations
-
- The authors believe this RR to not cause any new security problems.
- Some problems become more visible, though.
-
- - The ability to specify ports on a fine-grained basis obviously
- changes how a router can filter packets. It becomes impossible
- to block internal clients from accessing specific external
- services, slightly harder to block internal users from running
- unauthorized services, and more important for the router
- operations and DNS operations personnel to cooperate.
-
- - There is no way a site can keep its hosts from being referenced
- as servers. This could lead to denial of service.
-
-
-
-Gulbrandsen, et al. Standards Track [Page 9]
-
-RFC 2782 DNS SRV RR February 2000
-
-
- - With SRV, DNS spoofers can supply false port numbers, as well as
- host names and addresses. Because this vulnerability exists
- already, with names and addresses, this is not a new
- vulnerability, merely a slightly extended one, with little
- practical effect.
-
-References
-
- STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
- 1700, October 1994.
-
- RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- RFC 1035: Mockapetris, P., "Domain names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- RFC 974: Partridge, C., "Mail routing and the domain system", STD
- 14, RFC 974, January 1986.
-
- BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
- Services", BCP 17, RFC 2219, October 1997.
-
- BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
- Services with DNS", Work in Progress.
-
- KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
- Realm Information with DNS", Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 10]
-
-RFC 2782 DNS SRV RR February 2000
-
-
-Acknowledgements
-
- The algorithm used to select from the weighted SRV RRs of equal
- priority is adapted from one supplied by Dan Bernstein.
-
-Authors' Addresses
-
- Arnt Gulbrandsen
- Troll Tech
- Waldemar Thranes gate 98B
- N-0175 Oslo, Norway
-
- Fax: +47 22806380
- Phone: +47 22806390
- EMail: arnt@troll.no
-
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
-
- Phone: +1 650 779 7001
-
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 11]
-
-RFC 2782 DNS SRV RR February 2000
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al. Standards Track [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2825.txt b/contrib/bind9/doc/rfc/rfc2825.txt
deleted file mode 100644
index fd8ef7c892da7..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2825.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group Internet Architecture Board (IAB)
-Request for Comments: 2825 L. Daigle, Editor
-Category: Informational May 2000
-
-
- A Tangled Web: Issues of I18N, Domain Names, and the
- Other Internet protocols
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- The goals of the work to "internationalize" Internet protocols
- include providing all users of the Internet with the capability of
- using their own language and its standard character set to express
- themselves, write names, and to navigate the network. This impacts
- the domain names visible in e-mail addresses and so many of today's
- URLs used to locate information on the World Wide Web, etc. However,
- domain names are used by Internet protocols that are used across
- national boundaries. These services must interoperate worldwide, or
- we risk isolating components of the network from each other along
- locale boundaries. This type of isolation could impede not only
- communications among people, but opportunities of the areas involved
- to participate effectively in e-commerce, distance learning, and
- other activities at an international scale, thereby retarding
- economic development.
-
- There are several proposals for internationalizing domain names,
- however it it is still to be determined whether any of them will
- ensure this interoperability and global reach while addressing
- visible-name representation. Some of them obviously do not. This
- document does not attempt to review any specific proposals, as that
- is the work of the Internationalized Domain Name (IDN) Working Group
- of the IETF, which is tasked with evaluating them in consideration of
- the continued global network interoperation that is the deserved
- expectation of all Internet users.
-
-
-
-
-
-
-
-IAB Informational [Page 1]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- This document is a statement by the Internet Architecture Board. It
- is not a protocol specification, but an attempt to clarify the range
- of architectural issues that the internationalization of domain names
- faces.
-
-1. A Definition of Success
-
- The Internationalized Domain Names (IDN) Working Group is one
- component of the IETF's continuing comprehensive effort to
- internationalize language representation facilities in the protocols
- that support the global functioning of the Internet.
-
- In keeping with the principles of rough consensus, running code,
- architectural integrity, and in the interest of ensuring the global
- stability of the Internet, the IAB emphasizes that all solutions
- proposed to the (IDN) Working Group will have to be evaluated not
- only on their individual technical features, but also in terms of
- impact on existing standards and operations of the Internet and the
- total effect for end-users: solutions must not cause users to become
- more isolated from their global neighbors even if they appear to
- solve a local problem. In some cases, existing protocols have
- limitations on allowable characters, and in other cases
- implementations of protocols used in the core of the Internet (beyond
- individual organizations) have in practice not implemented all the
- requisite options of the standards.
-
-2. Technical Challenges within the Domain Name System (DNS)
-
- In many technical respects, the IDN work is not different from any
- other effort to enable multiple character set representations in
- textual elements that were traditionally restricted to English
- language characters.
-
- One aspect of the challenge is to decide how to represent the names
- users want in the DNS in a way that is clear, technically feasible,
- and ensures that a name always means the same thing. Several
- proposals have been suggested to address these issues.
-
- These issues are being outlined in more detail in the IDN WG's
- evolving draft requirements document; further discussion is deferred
- to the WG and its documents.
-
-3. Integrating with Current Realities
-
- Nevertheless, issues faced by the IDN working group are complex and
- intricately intertwined with other operational components of the
- Internet. A key challenge in evaluating any proposed solution is the
- analysis of the impact on existing critical operational standards
-
-
-
-IAB Informational [Page 2]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- which use fully-qualified domain names [RFC1034], or simply host
- names [RFC1123]. Standards-changes can be effected, but the best
- path forward is one that takes into account current realities and
- (re)deployment latencies. In the Internet's global context, it is not
- enough to update a few isolated systems, or even most of the systems
- in a country or region. Deployment must be nearly universal in order
- to avoid the creation of "islands" of interoperation that provide
- users with less access to and connection from the rest of the world.
-
- These are not esoteric or ephemeral concerns. Some specific issues
- have already been identified as part of the IDN WG's efforts. These
- include (but are not limited to) the following examples.
-
-3.1 Domain Names and E-mail
-
- As indicated in the IDN WG's draft requirements document, the issue
- goes beyond standardization of DNS usage. Electronic mail has long
- been one of the most-used and most important applications of the
- Internet. Internet e-mail is also used as the bridge that permits
- the users of a variety of local and proprietary mail systems to
- communicate. The standard protocols that define its use (e.g., SMTP
- [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of
- characters allowed in the DNS specification. Certain characters are
- not allowed in e-mail address domain portions of these
- specifications. Some mailers, built to adhere to these
- specifications, are known to fail when on mail having non-ASCII
- domain names in its address -- by discarding, misrouting or damaging
- the mail. Thus, it's not possible to simply switch to
- internationalized domain names and expect global e-mail to continue
- to work until most of the servers in the world are upgraded.
-
-3.2 Domain Names and Routing
-
- At a lower level, the Routing Policy Specification Language (RPLS)
- [RFC2622] makes use of "named objects" -- and inherits object naming
- restrictions from older standards ([RFC822] for the same e-mail
- address restrictions, [RFC1034] for hostnames). This means that
- until routing registries and their protocols are updated, it is not
- possible to enter or retrieve network descriptions utilizing
- internationalized domain names.
-
-3.3 Domain Names and Network Management
-
- Also, the Simple Network Management Protocol (SNMP) uses the textual
- representation defined in [RFC2579]. While that specification does
- allow for UTF-8-based domain names, an informal survey of deployed
- implementations of software libraries being used to build SNMP-
- compliant software uncovered the fact that few (if any) implement it.
-
-
-
-IAB Informational [Page 3]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- This may cause inability to enter or display correct data in network
- management tools, if such names are internationalized domain names.
-
-3.4 Domain Names and Security
-
- Critical components of Internet public key technologies (PKIX,
- [RFC2459], IKE [RFC2409]) rely heavily on identification of servers
- (hostnames, or fully qualified domain names) and users (e-mail
- addresses). Failure to respect the character restrictions in these
- protocols will impact security tools built to use them -- Transport
- Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name
- two.
-
- Failure may not be obvious. For example, in TLS, it is common usage
- for a server to display a certificate containing a domain name
- purporting to be the domain name of the server, which the client can
- then match with the server name he thought he used to reach the
- service.
-
- Unless comparison of domain names is properly defined, the client may
- either fail to match the domain name of a legitimate server, or match
- incorrectly the domain name of a server performing a man-in-the-
- middle attack. Either failure could enable attacks on systems that
- are now impossible or at least far more difficult.
-
-4. Conclusion
-
- It is therefore clear that, although there are many possible ways to
- assign internationalized names that are compatible with today's DNS
- (or a version that is easily-deployable in the near future), not all
- of them are compatible with the full range of necessary networking
- tools. When designing a solution for internationalization of domain
- names, the effects on the current Internet must be carefully
- evaluated. Some types of solutions proposed would, if put into effect
- immediately, cause Internet communications to fail in ways that would
- be hard to detect by and pose problems for those who deploy the new
- services, but also for those who do not; this would have the effect
- of cutting those who deploy them off from effective use of the
- Internet.
-
- The IDN WG has been identified as the appropriate forum for
- identifying and discussing solutions for such potential
- interoperability issues.
-
- Experience with deployment of other protocols has indicated that it
- will take years before a new protocol or enhancement is used all over
- the Internet. So far, the IDN WG has benefited from proposed
- solutions from all quarters, including organizations hoping to
-
-
-
-IAB Informational [Page 4]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- provide services that address visible-name representation and
- registration -- continuing this process with the aim of getting a
- single, scalable and deployable solution to this problem is the only
- way to ensure the continued global interoperation that is the
- deserved expectation of all Internet users.
-
-5. Security Considerations
-
- In general, assignment and use of names does not raise any special
- security problems. However, as noted above, some existing security
- mechanisms are reliant on the current specification of domain names
- and may not be expected to work, as is, with Internationalized domain
- names. Additionally, deployment of non-standard systems (e.g., in
- response to current pressures to address national or regional
- characterset representation) might result in name strings that are
- not globally unique, thereby opening up the possibility of "spoofing"
- hosts from one domain in another, as described in [RFC2826].
-
-6. Acknowledgements
-
- This document is the outcome of the joint effort of the members of
- the IAB. Additionally, valuable remarks were provided by Randy Bush,
- Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.
-
-7. References
-
- [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, August 1982.
-
- [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application
- and Support", STD 3, RFC 1123, November 1989.
-
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange
- (IKE)", RFC 2409, November 1998.
-
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
-
-
-
-IAB Informational [Page 5]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
- RFC 2246, January 1999.
-
- [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
- X.509 Public Key Infrastructure Certificate and CRL
- Profile", RFC 2459, January 1999.
-
- [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.
- and M. Rose, "Textual Conventions for SMIv2", RFC 2579,
- April 1999.
-
- [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
- Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,
- "Routing Policy Specification Language (RPSL)", RFC 2622,
- June 1999.
-
- [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC
- 2826, May 2000.
-
-8. Author's Address
-
- Internet Architecture Board
-
- EMail: iab@iab.org
-
-
- Membership at time this document was completed:
-
- Harald Alvestrand
- Ran Atkinson
- Rob Austein
- Brian Carpenter
- Steve Bellovin
- Jon Crowcroft
- Leslie Daigle
- Steve Deering
- Tony Hain
- Geoff Huston
- John Klensin
- Henning Schulzrinne
-
-
-
-
-
-
-
-
-
-
-
-IAB Informational [Page 6]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB Informational [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2826.txt b/contrib/bind9/doc/rfc/rfc2826.txt
deleted file mode 100644
index b4d886968fc88..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2826.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group Internet Architecture Board
-Request for Comments: 2826 May 2000
-Category: Informational
-
-
- IAB Technical Comment on the Unique DNS Root
-
-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 (2000). All Rights Reserved.
-
-Summary
-
- To remain a global network, the Internet requires the existence of a
- globally unique public name space. The DNS name space is a
- hierarchical name space derived from a single, globally unique root.
- This is a technical constraint inherent in the design of the DNS.
- Therefore it is not technically feasible for there to be more than
- one root in the public DNS. That one root must be supported by a set
- of coordinated root servers administered by a unique naming
- authority.
-
- Put simply, deploying multiple public DNS roots would raise a very
- strong possibility that users of different ISPs who click on the same
- link on a web page could end up at different destinations, against
- the will of the web page designers.
-
- This does not preclude private networks from operating their own
- private name spaces, but if they wish to make use of names uniquely
- defined for the global Internet, they have to fetch that information
- from the global DNS naming hierarchy, and in particular from the
- coordinated root servers of the global DNS naming hierarchy.
-
-1. Detailed Explanation
-
- There are several distinct reasons why the DNS requires a single root
- in order to operate properly.
-
-1.1. Maintenance of a Common Symbol Set
-
- Effective communications between two parties requires two essential
- preconditions:
-
-
-
-IAB Informational [Page 1]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
- - The existence of a common symbol set, and
-
- - The existence of a common semantic interpretation of these
- symbols.
-
- Failure to meet the first condition implies a failure to communicate
- at all, while failure to meet the second implies that the meaning of
- the communication is lost.
-
- In the case of a public communications system this condition of a
- common symbol set with a common semantic interpretation must be
- further strengthened to that of a unique symbol set with a unique
- semantic interpretation. This condition of uniqueness allows any
- party to initiate a communication that can be received and understood
- by any other party. Such a condition rules out the ability to define
- a symbol within some bounded context. In such a case, once the
- communication moves out of the context of interpretation in which it
- was defined, the meaning of the symbol becomes lost.
-
- Within public digital communications networks such as the Internet
- this requirement for a uniquely defined symbol set with a uniquely
- defined meaning exists at many levels, commencing with the binary
- encoding scheme, extending to packet headers and payload formats and
- the protocol that an application uses to interact. In each case a
- variation of the symbol set or a difference of interpretation of the
- symbols being used within the interaction causes a protocol failure,
- and the communication fails. The property of uniqueness allows a
- symbol to be used unambiguously in any context, allowing the symbol
- to be passed on, referred to, and reused, while still preserving the
- meaning of the original use.
-
- The DNS fulfills an essential role within the Internet protocol
- environment, allowing network locations to be referred to using a
- label other than a protocol address. As with any other such symbol
- set, DNS names are designed to be globally unique, that is, for any
- one DNS name at any one time there must be a single set of DNS
- records uniquely describing protocol addresses, network resources and
- services associated with that DNS name. All of the applications
- deployed on the Internet which use the DNS assume this, and Internet
- users expect such behavior from DNS names. Names are then constant
- symbols, whose interpretation does not specifically require knowledge
- of the context of any individual party. A DNS name can be passed
- from one party to another without altering the semantic intent of the
- name.
-
- Since the DNS is hierarchically structured into domains, the
- uniqueness requirement for DNS names in their entirety implies that
- each of the names (sub-domains) defined within a domain has a unique
-
-
-
-IAB Informational [Page 2]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
- meaning (i.e., set of DNS records) within that domain. This is as
- true for the root domain as for any other DNS domain. The
- requirement for uniqueness within a domain further implies that there
- be some mechanism to prevent name conflicts within a domain. In DNS
- this is accomplished by assigning a single owner or maintainer to
- every domain, including the root domain, who is responsible for
- ensuring that each sub-domain of that domain has the proper records
- associated with it. This is a technical requirement, not a policy
- choice.
-
-1.2. Coordination of Updates
-
- Both the design and implementations of the DNS protocol are heavily
- based on the assumption that there is a single owner or maintainer
- for every domain, and that any set of resources records associated
- with a domain is modified in a single-copy serializable fashion.
- That is, even assuming that a single domain could somehow be "shared"
- by uncooperating parties, there is no means within the DNS protocol
- by which a user or client could discover, and choose between,
- conflicting definitions of a DNS name made by different parties. The
- client will simply return the first set of resource records that it
- finds that matches the requested domain, and assume that these are
- valid. This protocol is embedded in the operating software of
- hundreds of millions of computer systems, and is not easily updated
- to support a shared domain scenario.
-
- Moreover, even supposing that some other means of resolving
- conflicting definitions could be provided in the future, it would
- have to be based on objective rules established in advance. For
- example, zone A.B could declare that naming authority Y had been
- delegated all subdomains of A.B with an odd number of characters, and
- that naming authority Z had been delegated authority to define
- subdomains of A.B with an even number of characters. Thus, a single
- set of rules would have to be agreed to prevent Y and Z from making
- conflicting assignments, and with this train of actions a single
- unique space has been created in any case. Even this would not allow
- multiple non-cooperating authorities to assign arbitrary sub-domains
- within a single domain.
-
- It seems that a degree of cooperation and agreed technical rules are
- required in order to guarantee the uniqueness of names. In the DNS,
- these rules are established independently for each part of the naming
- hierarchy, and the root domain is no exception. Thus, there must be
- a generally agreed single set of rules for the root.
-
-
-
-
-
-
-
-IAB Informational [Page 3]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
-1.3. Difficulty of Relocating the Root Zone
-
- There is one specific technical respect in which the root zone
- differs from all other DNS zones: the addresses of the name servers
- for the root zone come primarily from out-of-band information. This
- out-of-band information is often poorly maintained and, unlike all
- other data in the DNS, the out-of-band information has no automatic
- timeout mechanism. It is not uncommon for this information to be
- years out of date at many sites.
-
- Like any other zone, the root zone contains a set of "name server"
- resource records listing its servers, but a resolver with no valid
- addresses for the current set of root servers will never be able to
- obtain these records. More insidiously, a resolver that has a mixed
- set of partially valid and partially stale out-of-band configuration
- information will not be able to tell which are the "real" root
- servers if it gets back conflicting answers; thus, it is very
- difficult to revoke the status of a malicious root server, or even to
- route around a buggy root server.
-
- In effect, every full-service resolver in the world "delegates" the
- root of the public tree to the public root server(s) of its choice.
-
- As a direct consequence, any change to the list of IP addresses that
- specify the public root zone is significantly more difficult than
- changing any other aspect of the DNS delegation chain. Thus,
- stability of the system calls for extremely conservative and cautious
- management of the public root zone: the frequency of updates to the
- root zone must be kept low, and the servers for the root zone must be
- closely coordinated.
-
- These problems can be ameliorated to some extent by the DNS Security
- Extensions [DNSSEC], but a similar out-of-band configuration problem
- exists for the cryptographic signature key to the root zone, so the
- root zone still requires tight coupling and coordinated management
- even in the presence of DNSSEC.
-
-2. Conclusion
-
- The DNS type of unique naming and name-mapping system may not be
- ideal for a number of purposes for which it was never designed, such
- a locating information when the user doesn't precisely know the
- correct names. As the Internet continues to expand, we would expect
- directory systems to evolve which can assist the user in dealing with
- vague or ambiguous references. To preserve the many important
- features of the DNS and its multiple record types -- including the
- Internet's equivalent of telephone number portability -- we would
- expect the result of directory lookups and identification of the
-
-
-
-IAB Informational [Page 4]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
- correct names for a particular purpose to be unique DNS names that
- are then resolved normally, rather than having directory systems
- "replace" the DNS.
-
- There is no getting away from the unique root of the public DNS.
-
-3. Security Considerations
-
- This memo does not introduce any new security issues, but it does
- attempt to identify some of the problems inherent in a family of
- recurring technically naive proposals.
-
-4. IANA Considerations
-
- This memo is not intended to create any new issues for IANA.
-
-5. References
-
- [DNS-CONCEPTS] Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [DNS-IMPLEMENTATION] Mockapetris, P., "Domain Names - Implementation
- and Specification", STD 13, RFC 1035, November
- 1987.
-
- [DNSSEC] Eastlake, D., "Domain Name System Security
- Extensions", RFC 2535, March 1999.
-
-6. Author's Address
-
- Internet Architecture Board
-
- EMail: iab@iab.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB Informational [Page 5]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
-7. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB Informational [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2845.txt b/contrib/bind9/doc/rfc/rfc2845.txt
deleted file mode 100644
index aa9f385ae354b..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2845.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Vixie
-Request for Comments: 2845 ISC
-Category: Standards Track O. Gudmundsson
-Updates: 1035 NAI Labs
- D. Eastlake 3rd
- Motorola
- B. Wellington
- Nominum
- May 2000
-
-
- Secret Key Transaction Authentication for DNS (TSIG)
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- This protocol allows for transaction level authentication using
- shared secrets and one way hashing. It can be used to authenticate
- dynamic updates as coming from an approved client, or to authenticate
- responses as coming from an approved recursive name server.
-
- No provision has been made here for distributing the shared secrets;
- it is expected that a network administrator will statically configure
- name servers and clients using some out of band mechanism such as
- sneaker-net until a secure automated mechanism for key distribution
- is available.
-
-1 - Introduction
-
- 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
- hierarchical distributed database system that provides information
- fundamental to Internet operations, such as name <=> address
- translation and mail handling information. DNS has recently been
- extended [RFC2535] to provide for data origin authentication, and
- public key distribution, all based on public key cryptography and
- public key based digital signatures. To be practical, this form of
-
-
-
-
-Vixie, et al. Standards Track [Page 1]
-
-RFC 2845 DNS TSIG May 2000
-
-
- security generally requires extensive local caching of keys and
- tracing of authentication through multiple keys and signatures to a
- pre-trusted locally configured key.
-
- 1.2. One difficulty with the [RFC2535] scheme is that common DNS
- implementations include simple "stub" resolvers which do not have
- caches. Such resolvers typically rely on a caching DNS server on
- another host. It is impractical for these stub resolvers to perform
- general [RFC2535] authentication and they would naturally depend on
- their caching DNS server to perform such services for them. To do so
- securely requires secure communication of queries and responses.
- [RFC2535] provides public key transaction signatures to support this,
- but such signatures are very expensive computationally to generate.
- In general, these require the same complex public key logic that is
- impractical for stubs. This document specifies use of a message
- authentication code (MAC), specifically HMAC-MD5 (a keyed hash
- function), to provide an efficient means of point-to-point
- authentication and integrity checking for transactions.
-
- 1.3. A second area where use of straight [RFC2535] public key based
- mechanisms may be impractical is authenticating dynamic update
- [RFC2136] requests. [RFC2535] provides for request signatures but
- with [RFC2535] they, like transaction signatures, require
- computationally expensive public key cryptography and complex
- authentication logic. Secure Domain Name System Dynamic Update
- ([RFC2137]) describes how different keys are used in dynamically
- updated zones. This document's secret key based MACs can be used to
- authenticate DNS update requests as well as transaction responses,
- providing a lightweight alternative to the protocol described by
- [RFC2137].
-
- 1.4. A further use of this mechanism is to protect zone transfers.
- In this case the data covered would be the whole zone transfer
- including any glue records sent. The protocol described by [RFC2535]
- does not protect glue records and unsigned records unless SIG(0)
- (transaction signature) is used.
-
- 1.5. The authentication mechanism proposed in this document uses
- shared secret keys to establish a trust relationship between two
- entities. Such keys must be protected in a fashion similar to
- private keys, lest a third party masquerade as one of the intended
- parties (forge MACs). There is an urgent need to provide simple and
- efficient authentication between clients and local servers and this
- proposal addresses that need. This proposal is unsuitable for
- general server to server authentication for servers which speak with
- many other servers, since key management would become unwieldy with
-
-
-
-
-
-Vixie, et al. Standards Track [Page 2]
-
-RFC 2845 DNS TSIG May 2000
-
-
- the number of shared keys going up quadratically. But it is suitable
- for many resolvers on hosts that only talk to a few recursive
- servers.
-
- 1.6. A server acting as an indirect caching resolver -- a "forwarder"
- in common usage -- might use transaction-based authentication when
- communicating with its small number of preconfigured "upstream"
- servers. Other uses of DNS secret key authentication and possible
- systems for automatic secret key distribution may be proposed in
- separate future documents.
-
- 1.7. New Assigned Numbers
-
- RRTYPE = TSIG (250)
- ERROR = 0..15 (a DNS RCODE)
- ERROR = 16 (BADSIG)
- ERROR = 17 (BADKEY)
- ERROR = 18 (BADTIME)
-
- 1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and
- "MAY" in this document are to be interpreted as described in [RFC
- 2119].
-
-2 - TSIG RR Format
-
- 2.1 TSIG RR Type
-
- To provide secret key authentication, we use a new RR type whose
- mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and
- MUST not be cached. TSIG RRs are used for authentication between DNS
- entities that have established a shared secret key. TSIG RRs are
- dynamically computed to cover a particular DNS transaction and are
- not DNS RRs in the usual sense.
-
- 2.2 TSIG Calculation
-
- As the TSIG RRs are related to one DNS request/response, there is no
- value in storing or retransmitting them, thus the TSIG RR is
- discarded once it has been used to authenticate a DNS message. The
- only message digest algorithm specified in this document is "HMAC-
- MD5" (see [RFC1321], [RFC2104]). The "HMAC-MD5" algorithm is
- mandatory to implement for interoperability. Other algorithms can be
- specified at a later date. Names and definitions of new algorithms
- MUST be registered with IANA. All multi-octet integers in the TSIG
- record are sent in network byte order (see [RFC1035 2.3.2]).
-
-
-
-
-
-
-Vixie, et al. Standards Track [Page 3]
-
-RFC 2845 DNS TSIG May 2000
-
-
- 2.3. Record Format
-
- NAME The name of the key used in domain name syntax. The name
- should reflect the names of the hosts and uniquely identify
- the key among a set of keys these two hosts may share at any
- given time. If hosts A.site.example and B.example.net share a
- key, possibilities for the key name include
- <id>.A.site.example, <id>.B.example.net, and
- <id>.A.site.example.B.example.net. It should be possible for
- more than one key to be in simultaneous use among a set of
- interacting hosts. The name only needs to be meaningful to
- the communicating hosts but a meaningful mnemonic name as
- above is strongly recommended.
-
- The name may be used as a local index to the key involved and
- it is recommended that it be globally unique. Where a key is
- just shared between two hosts, its name actually only need
- only be meaningful to them but it is recommended that the key
- name be mnemonic and incorporate the resolver and server host
- names in that order.
-
- TYPE TSIG (250: Transaction SIGnature)
-
- CLASS ANY
-
- TTL 0
-
- RdLen (variable)
-
- RDATA
-
- Field Name Data Type Notes
- --------------------------------------------------------------
- Algorithm Name domain-name Name of the algorithm
- in domain name syntax.
- Time Signed u_int48_t seconds since 1-Jan-70 UTC.
- Fudge u_int16_t seconds of error permitted
- in Time Signed.
- MAC Size u_int16_t number of octets in MAC.
- MAC octet stream defined by Algorithm Name.
- Original ID u_int16_t original message ID
- Error u_int16_t expanded RCODE covering
- TSIG processing.
- Other Len u_int16_t length, in octets, of
- Other Data.
- Other Data octet stream empty unless Error == BADTIME
-
-
-
-
-
-Vixie, et al. Standards Track [Page 4]
-
-RFC 2845 DNS TSIG May 2000
-
-
- 2.4. Example
-
- NAME HOST.EXAMPLE.
-
- TYPE TSIG
-
- CLASS ANY
-
- TTL 0
-
- RdLen as appropriate
-
- RDATA
-
- Field Name Contents
- -------------------------------------
- Algorithm Name SAMPLE-ALG.EXAMPLE.
- Time Signed 853804800
- Fudge 300
- MAC Size as appropriate
- MAC as appropriate
- Original ID as appropriate
- Error 0 (NOERROR)
- Other Len 0
- Other Data empty
-
-3 - Protocol Operation
-
- 3.1. Effects of adding TSIG to outgoing message
-
- Once the outgoing message has been constructed, the keyed message
- digest operation can be performed. The resulting message digest will
- then be stored in a TSIG which is appended to the additional data
- section (the ARCOUNT is incremented to reflect this). If the TSIG
- record cannot be added without causing the message to be truncated,
- the server MUST alter the response so that a TSIG can be included.
- This response consists of only the question and a TSIG record, and
- has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this
- point retry the request using TCP (per [RFC1035 4.2.2]).
-
- 3.2. TSIG processing on incoming messages
-
- If an incoming message contains a TSIG record, it MUST be the last
- record in the additional section. Multiple TSIG records are not
- allowed. If a TSIG record is present in any other position, the
- packet is dropped and a response with RCODE 1 (FORMERR) MUST be
- returned. Upon receipt of a message with a correctly placed TSIG RR,
- the TSIG RR is copied to a safe location, removed from the DNS
-
-
-
-Vixie, et al. Standards Track [Page 5]
-
-RFC 2845 DNS TSIG May 2000
-
-
- Message, and decremented out of the DNS message header's ARCOUNT. At
- this point the keyed message digest operation is performed. If the
- algorithm name or key name is unknown to the recipient, or if the
- message digests do not match, the whole DNS message MUST be
- discarded. If the message is a query, a response with RCODE 9
- (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
- (BADKEY) or TSIG ERROR 16 (BADSIG). If no key is available to sign
- this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
- A message to the system operations log SHOULD be generated, to warn
- the operations staff of a possible security incident in progress.
- Care should be taken to ensure that logging of this type of event
- does not open the system to a denial of service attack.
-
- 3.3. Time values used in TSIG calculations
-
- The data digested includes the two timer values in the TSIG header in
- order to defend against replay attacks. If this were not done, an
- attacker could replay old messages but update the "Time Signed" and
- "Fudge" fields to make the message look new. This data is named
- "TSIG Timers", and for the purpose of digest calculation they are
- invoked in their "on the wire" format, in the following order: first
- Time Signed, then Fudge. For example:
-
-Field Name Value Wire Format Meaning
-----------------------------------------------------------------------
-Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
-Fudge 300 01 2C 5 minutes
-
- 3.4. TSIG Variables and Coverage
-
- When generating or verifying the contents of a TSIG record, the
- following data are digested, in network byte order or wire format, as
- appropriate:
-
- 3.4.1. DNS Message
-
- A whole and complete DNS message in wire format, before the TSIG RR
- has been added to the additional data section and before the DNS
- Message Header's ARCOUNT field has been incremented to contain the
- TSIG RR. If the message ID differs from the original message ID, the
- original message ID is substituted for the message ID. This could
- happen when forwarding a dynamic update request, for example.
-
-
-
-
-
-
-
-
-
-Vixie, et al. Standards Track [Page 6]
-
-RFC 2845 DNS TSIG May 2000
-
-
- 3.4.2. TSIG Variables
-
-Source Field Name Notes
------------------------------------------------------------------------
-TSIG RR NAME Key name, in canonical wire format
-TSIG RR CLASS (Always ANY in the current specification)
-TSIG RR TTL (Always 0 in the current specification)
-TSIG RDATA Algorithm Name in canonical wire format
-TSIG RDATA Time Signed in network byte order
-TSIG RDATA Fudge in network byte order
-TSIG RDATA Error in network byte order
-TSIG RDATA Other Len in network byte order
-TSIG RDATA Other Data exactly as transmitted
-
- The RR RDLEN and RDATA MAC Length are not included in the hash since
- they are not guaranteed to be knowable before the MAC is generated.
-
- The Original ID field is not included in this section, as it has
- already been substituted for the message ID in the DNS header and
- hashed.
-
- For each label type, there must be a defined "Canonical wire format"
- that specifies how to express a label in an unambiguous way. For
- label type 00, this is defined in [RFC2535], for label type 01, this
- is defined in [RFC2673]. The use of label types other than 00 and 01
- is not defined for this specification.
-
- 3.4.3. Request MAC
-
- When generating the MAC to be included in a response, the request MAC
- must be included in the digest. The request's MAC is digested in
- wire format, including the following fields:
-
- Field Type Description
- ---------------------------------------------------
- MAC Length u_int16_t in network byte order
- MAC Data octet stream exactly as transmitted
-
- 3.5. Padding
-
- Digested components are fed into the hashing function as a continuous
- octet stream with no interfield padding.
-
-
-
-
-
-
-
-
-
-Vixie, et al. Standards Track [Page 7]
-
-RFC 2845 DNS TSIG May 2000
-
-
-4 - Protocol Details
-
- 4.1. TSIG generation on requests
-
- Client performs the message digest operation and appends a TSIG
- record to the additional data section and transmits the request to
- the server. The client MUST store the message digest from the
- request while awaiting an answer. The digest components for a
- request are:
-
- DNS Message (request)
- TSIG Variables (request)
-
- Note that some older name servers will not accept requests with a
- nonempty additional data section. Clients SHOULD only attempt signed
- transactions with servers who are known to support TSIG and share
- some secret key with the client -- so, this is not a problem in
- practice.
-
- 4.2. TSIG on Answers
-
- When a server has generated a response to a signed request, it signs
- the response using the same algorithm and key. The server MUST not
- generate a signed response to an unsigned request. The digest
- components are:
-
- Request MAC
- DNS Message (response)
- TSIG Variables (response)
-
- 4.3. TSIG on TSIG Error returns
-
- When a server detects an error relating to the key or MAC, the server
- SHOULD send back an unsigned error message (MAC size == 0 and empty
- MAC). If an error is detected relating to the TSIG validity period,
- the server SHOULD send back a signed error message. The digest
- components are:
-
- Request MAC (if the request MAC validated)
- DNS Message (response)
- TSIG Variables (response)
-
- The reason that the request is not included in this digest in some
- cases is to make it possible for the client to verify the error. If
- the error is not a TSIG error the response MUST be generated as
- specified in [4.2].
-
-
-
-
-
-Vixie, et al. Standards Track [Page 8]
-
-RFC 2845 DNS TSIG May 2000
-
-
- 4.4. TSIG on TCP connection
-
- A DNS TCP session can include multiple DNS envelopes. This is, for
- example, commonly used by zone transfer. Using TSIG on such a
- connection can protect the connection from hijacking and provide data
- integrity. The TSIG MUST be included on the first and last DNS
- envelopes. It can be optionally placed on any intermediary
- envelopes. It is expensive to include it on every envelopes, but it
- MUST be placed on at least every 100'th envelope. The first envelope
- is processed as a standard answer, and subsequent messages have the
- following digest components:
-
- Prior Digest (running)
- DNS Messages (any unsigned messages since the last TSIG)
- TSIG Timers (current message)
-
- This allows the client to rapidly detect when the session has been
- altered; at which point it can close the connection and retry. If a
- client TSIG verification fails, the client MUST close the connection.
- If the client does not receive TSIG records frequently enough (as
- specified above) it SHOULD assume the connection has been hijacked
- and it SHOULD close the connection. The client SHOULD treat this the
- same way as they would any other interrupted transfer (although the
- exact behavior is not specified).
-
- 4.5. Server TSIG checks
-
- Upon receipt of a message, server will check if there is a TSIG RR.
- If one exists, the server is REQUIRED to return a TSIG RR in the
- response. The server MUST perform the following checks in the
- following order, check KEY, check TIME values, check MAC.
-
- 4.5.1. KEY check and error handling
-
- If a non-forwarding server does not recognize the key used by the
- client, the server MUST generate an error response with RCODE 9
- (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned
- as specified in [4.3]. The server SHOULD log the error.
-
- 4.5.2. TIME check and error handling
-
- If the server time is outside the time interval specified by the
- request (which is: Time Signed, plus/minus Fudge), the server MUST
- generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
- (BADTIME). The server SHOULD also cache the most recent time signed
- value in a message generated by a key, and SHOULD return BADTIME if a
- message received later has an earlier time signed value. A response
- indicating a BADTIME error MUST be signed by the same key as the
-
-
-
-Vixie, et al. Standards Track [Page 9]
-
-RFC 2845 DNS TSIG May 2000
-
-
- request. It MUST include the client's current time in the time
- signed field, the server's current time (a u_int48_t) in the other
- data field, and 6 in the other data length field. This is done so
- that the client can verify a message with a BADTIME error without the
- verification failing due to another BADTIME error. The data signed
- is specified in [4.3]. The server SHOULD log the error.
-
- 4.5.3. MAC check and error handling
-
- If a TSIG fails to verify, the server MUST generate an error response
- as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16
- (BADSIG). This response MUST be unsigned as specified in [4.3]. The
- server SHOULD log the error.
-
- 4.6. Client processing of answer
-
- When a client receives a response from a server and expects to see a
- TSIG, it first checks if the TSIG RR is present in the response.
- Otherwise, the response is treated as having a format error and
- discarded. The client then extracts the TSIG, adjusts the ARCOUNT,
- and calculates the keyed digest in the same way as the server. If
- the TSIG does not validate, that response MUST be discarded, unless
- the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
- verify the response as if it were a TSIG Error response, as specified
- in [4.3]. A message containing an unsigned TSIG record or a TSIG
- record which fails verification SHOULD not be considered an
- acceptable response; the client SHOULD log an error and continue to
- wait for a signed response until the request times out.
-
- 4.6.1. Key error handling
-
- If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
- validates, and the TSIG key is different from the key used on the
- request, then this is a KEY error. The client MAY retry the request
- using the key specified by the server. This should never occur, as a
- server MUST NOT sign a response with a different key than signed the
- request.
-
- 4.6.2. Time error handling
-
- If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
- (BADTIME), or the current time does not fall in the range specified
- in the TSIG record, then this is a TIME error. This is an indication
- that the client and server clocks are not synchronized. In this case
- the client SHOULD log the event. DNS resolvers MUST NOT adjust any
- clocks in the client based on BADTIME errors, but the server's time
- in the other data field SHOULD be logged.
-
-
-
-
-Vixie, et al. Standards Track [Page 10]
-
-RFC 2845 DNS TSIG May 2000
-
-
- 4.6.3. MAC error handling
-
- If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
- this is a MAC error, and client MAY retry the request with a new
- request ID but it would be better to try a different shared key if
- one is available. Client SHOULD keep track of how many MAC errors
- are associated with each key. Clients SHOULD log this event.
-
- 4.7. Special considerations for forwarding servers
-
- A server acting as a forwarding server of a DNS message SHOULD check
- for the existence of a TSIG record. If the name on the TSIG is not
- of a secret that the server shares with the originator the server
- MUST forward the message unchanged including the TSIG. If the name
- of the TSIG is of a key this server shares with the originator, it
- MUST process the TSIG. If the TSIG passes all checks, the forwarding
- server MUST, if possible, include a TSIG of his own, to the
- destination or the next forwarder. If no transaction security is
- available to the destination and the response has the AD flag (see
- [RFC2535]), the forwarder MUST unset the AD flag before adding the
- TSIG to the answer.
-
-5 - Shared Secrets
-
- 5.1. Secret keys are very sensitive information and all available
- steps should be taken to protect them on every host on which they are
- stored. Generally such hosts need to be physically protected. If
- they are multi-user machines, great care should be taken that
- unprivileged users have no access to keying material. Resolvers
- often run unprivileged, which means all users of a host would be able
- to see whatever configuration data is used by the resolver.
-
- 5.2. A name server usually runs privileged, which means its
- configuration data need not be visible to all users of the host. For
- this reason, a host that implements transaction-based authentication
- should probably be configured with a "stub resolver" and a local
- caching and forwarding name server. This presents a special problem
- for [RFC2136] which otherwise depends on clients to communicate only
- with a zone's authoritative name servers.
-
- 5.3. Use of strong random shared secrets is essential to the security
- of TSIG. See [RFC1750] for a discussion of this issue. The secret
- should be at least as long as the keyed message digest, i.e. 16 bytes
- for HMAC-MD5 or 20 bytes for HMAC-SHA1.
-
-
-
-
-
-
-
-Vixie, et al. Standards Track [Page 11]
-
-RFC 2845 DNS TSIG May 2000
-
-
-6 - Security Considerations
-
- 6.1. The approach specified here is computationally much less
- expensive than the signatures specified in [RFC2535]. As long as the
- shared secret key is not compromised, strong authentication is
- provided for the last hop from a local name server to the user
- resolver.
-
- 6.2. Secret keys should be changed periodically. If the client host
- has been compromised, the server should suspend the use of all
- secrets known to that client. If possible, secrets should be stored
- in encrypted form. Secrets should never be transmitted in the clear
- over any network. This document does not address the issue on how to
- distribute secrets. Secrets should never be shared by more than two
- entities.
-
- 6.3. This mechanism does not authenticate source data, only its
- transmission between two parties who share some secret. The original
- source data can come from a compromised zone master or can be
- corrupted during transit from an authentic zone master to some
- "caching forwarder." However, if the server is faithfully performing
- the full [RFC2535] security checks, then only security checked data
- will be available to the client.
-
- 6.4. A fudge value that is too large may leave the server open to
- replay attacks. A fudge value that is too small may cause failures
- if machines are not time synchronized or there are unexpected network
- delays. The recommended value in most situation is 300 seconds.
-
-7 - IANA Considerations
-
- IANA is expected to create and maintain a registry of algorithm names
- to be used as "Algorithm Names" as defined in Section 2.3. The
- initial value should be "HMAC-MD5.SIG-ALG.REG.INT". Algorithm names
- are text strings encoded using the syntax of a domain name. There is
- no structure required other than names for different algorithms must
- be unique when compared as DNS names, i.e., comparison is case
- insensitive. Note that the initial value mentioned above is not a
- domain name, and therefore need not be a registered name within the
- DNS. New algorithms are assigned using the IETF Consensus policy
- defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
- looks like a FQDN for historical reasons; future algorithm names are
- expected to be simple (i.e., single-component) names.
-
-
-
-
-
-
-
-
-Vixie, et al. Standards Track [Page 12]
-
-RFC 2845 DNS TSIG May 2000
-
-
- IANA is expected to create and maintain a registry of "TSIG Error
- values" to be used for "Error" values as defined in section 2.3.
- Initial values should be those defined in section 1.7. New TSIG
- error codes for the TSIG error field are assigned using the IETF
- Consensus policy defined in RFC 2434.
-
-8 - 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 1034, November 1987.
-
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
- [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1995.
-
- [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5:
- Keyed-MD5 for Message Authentication", RFC 2104, February
- 1997.
-
- [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", RFC 2136, April 1997.
-
- [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
- Update", RFC 2137, April 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
- RFC 2673, August 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al. Standards Track [Page 13]
-
-RFC 2845 DNS TSIG May 2000
-
-
-9 - Authors' Addresses
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
-
- Phone: +1 650 779 7001
- EMail: vixie@isc.org
-
-
- Olafur Gudmundsson
- NAI Labs
- 3060 Washington Road, Route 97
- Glenwood, MD 21738
-
- Phone: +1 443 259 2389
- EMail: ogud@tislabs.com
-
-
- Donald E. Eastlake 3rd
- Motorola
- 140 Forest Avenue
- Hudson, MA 01749 USA
-
- Phone: +1 508 261 5434
- EMail: dee3@torque.pothole.com
-
-
- Brian Wellington
- Nominum, Inc.
- 950 Charter Street
- Redwood City, CA 94063
-
- Phone: +1 650 779 6022
- EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al. Standards Track [Page 14]
-
-RFC 2845 DNS TSIG May 2000
-
-
-10 Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al. Standards Track [Page 15]
-
diff --git a/contrib/bind9/doc/rfc/rfc2874.txt b/contrib/bind9/doc/rfc/rfc2874.txt
deleted file mode 100644
index 915c104aa161f..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2874.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Crawford
-Request for Comments: 2874 Fermilab
-Category: Standards Track C. Huitema
- Microsoft Corporation
- July 2000
-
-
- DNS Extensions to Support IPv6 Address Aggregation and Renumbering
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- This document defines changes to the Domain Name System to support
- renumberable and aggregatable IPv6 addressing. The changes include a
- new resource record type to store an IPv6 address in a manner which
- expedites network renumbering and updated definitions of existing
- query types that return Internet addresses as part of additional
- section processing.
-
- For lookups keyed on IPv6 addresses (often called reverse lookups),
- this document defines a new zone structure which allows a zone to be
- used without modification for parallel copies of an address space (as
- for a multihomed provider or site) and across network renumbering
- events.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al. Standards Track [Page 1]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-Table of Contents
-
- 1. Introduction ............................................... 2
- 2. Overview ................................................... 3
- 2.1. Name-to-Address Lookup ............................... 4
- 2.2. Underlying Mechanisms for Reverse Lookups ............ 4
- 2.2.1. Delegation on Arbitrary Boundaries ............. 4
- 2.2.2. Reusable Zones ................................. 5
- 3. Specifications ............................................. 5
- 3.1. The A6 Record Type ................................... 5
- 3.1.1. Format ......................................... 6
- 3.1.2. Processing ..................................... 6
- 3.1.3. Textual Representation ......................... 7
- 3.1.4. Name Resolution Procedure ...................... 7
- 3.2. Zone Structure for Reverse Lookups ................... 7
- 4. Modifications to Existing Query Types ...................... 8
- 5. Usage Illustrations ........................................ 8
- 5.1. A6 Record Chains ..................................... 9
- 5.1.1. Authoritative Data ............................. 9
- 5.1.2. Glue ........................................... 10
- 5.1.3. Variations ..................................... 12
- 5.2. Reverse Mapping Zones ................................ 13
- 5.2.1. The TLA level .................................. 13
- 5.2.2. The ISP level .................................. 13
- 5.2.3. The Site Level ................................. 13
- 5.3. Lookups .............................................. 14
- 5.4. Operational Note ..................................... 15
- 6. Transition from RFC 1886 and Deployment Notes .............. 15
- 6.1. Transition from AAAA and Coexistence with A Records .. 16
- 6.2. Transition from Nibble Labels to Binary Labels ....... 17
- 7. Security Considerations .................................... 17
- 8. IANA Considerations ........................................ 17
- 9. Acknowledgments ............................................ 18
- 10. References ................................................ 18
- 11. Authors' Addresses ........................................ 19
- 12. Full Copyright Statement .................................. 20
-
-1. Introduction
-
- Maintenance of address information in the DNS is one of several
- obstacles which have prevented site and provider renumbering from
- being feasible in IP version 4. Arguments about the importance of
- network renumbering for the preservation of a stable routing system
- and for other purposes may be read in [RENUM1, RENUM2, RENUM3]. To
- support the storage of IPv6 addresses without impeding renumbering we
- define the following extensions.
-
-
-
-
-
-Crawford, et al. Standards Track [Page 2]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- o A new resource record type, "A6", is defined to map a domain name
- to an IPv6 address, with a provision for indirection for leading
- "prefix" bits.
-
- o Existing queries that perform additional section processing to
- locate IPv4 addresses are redefined to do that processing for both
- IPv4 and IPv6 addresses.
-
- o A new domain, IP6.ARPA, is defined to support lookups based on
- IPv6 address.
-
- o A new prefix-delegation method is defined, relying on new DNS
- features [BITLBL, DNAME].
-
- The changes are designed to be compatible with existing application
- programming interfaces. The existing support for IPv4 addresses is
- retained. Transition issues related to the coexistence of both IPv4
- and IPv6 addresses in DNS are discussed in [TRANS].
-
- This memo proposes a replacement for the specification in RFC 1886
- [AAAA] and a departure from current implementation practices. The
- changes are designed to facilitate network renumbering and
- multihoming. Domains employing the A6 record for IPv6 addresses can
- insert automatically-generated AAAA records in zone files to ease
- transition. It is expected that after a reasonable period, RFC 1886
- will become Historic.
-
- The next three major sections of this document are an overview of the
- facilities defined or employed by this specification, the
- specification itself, and examples of use.
-
- 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 [KWORD]. The key word
- "SUGGESTED" signifies a strength between MAY and SHOULD: it is
- believed that compliance with the suggestion has tangible benefits in
- most instances.
-
-2. Overview
-
- This section provides an overview of the DNS facilities for storage
- of IPv6 addresses and for lookups based on IPv6 address, including
- those defined here and elsewhere.
-
-
-
-
-
-
-
-
-Crawford, et al. Standards Track [Page 3]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-2.1. Name-to-Address Lookup
-
- IPv6 addresses are stored in one or more A6 resource records. A
- single A6 record may include a complete IPv6 address, or a contiguous
- portion of an address and information leading to one or more
- prefixes. Prefix information comprises a prefix length and a DNS
- name which is in turn the owner of one or more A6 records defining
- the prefix or prefixes which are needed to form one or more complete
- IPv6 addresses. When the prefix length is zero, no DNS name is
- present and all the leading bits of the address are significant.
- There may be multiple levels of indirection and the existence of
- multiple A6 records at any level multiplies the number of IPv6
- addresses which are formed.
-
- An application looking up an IPv6 address will generally cause the
- DNS resolver to access several A6 records, and multiple IPv6
- addresses may be returned even if the queried name was the owner of
- only one A6 record. The authenticity of the returned address(es)
- cannot be directly verified by DNS Security [DNSSEC]. The A6 records
- which contributed to the address(es) may of course be verified if
- signed.
-
- Implementers are reminded of the necessity to limit the amount of
- work a resolver will perform in response to a client request. This
- principle MUST be extended to also limit the generation of DNS
- requests in response to one name-to-address (or address-to-name)
- lookup request.
-
-2.2. Underlying Mechanisms for Reverse Lookups
-
- This section describes the new DNS features which this document
- exploits. This section is an overview, not a specification of those
- features. The reader is directed to the referenced documents for
- more details on each.
-
-2.2.1. Delegation on Arbitrary Boundaries
-
- This new scheme for reverse lookups relies on a new type of DNS label
- called the "bit-string label" [BITLBL]. This label compactly
- represents an arbitrary string of bits which is treated as a
- hierarchical sequence of one-bit domain labels. Resource records can
- thereby be stored at arbitrary bit-boundaries.
-
- Examples in section 5 will employ the following textual
- representation for bit-string labels, which is a subset of the syntax
- defined in [BITLBL]. A base indicator "x" for hexadecimal and a
- sequence of hexadecimal digits is enclosed between "\[" and "]". The
- bits denoted by the digits represent a sequence of one-bit domain
-
-
-
-Crawford, et al. Standards Track [Page 4]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- labels ordered from most to least significant. (This is the opposite
- of the order they would appear if listed one bit at a time, but it
- appears to be a convenient notation.) The digit string may be
- followed by a slash ("/") and a decimal count. If omitted, the
- implicit count is equal to four times the number of hexadecimal
- digits.
-
- Consecutive bit-string labels are equivalent (up to the limit imposed
- by the size of the bit count field) to a single bit-string label
- containing all the bits of the consecutive labels in the proper
- order. As an example, either of the following domain names could be
- used in a QCLASS=IN, QTYPE=PTR query to find the name of the node
- with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
-
- \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
-
- \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
-
-2.2.2. Reusable Zones
-
- DNS address space delegation is implemented not by zone cuts and NS
- records, but by a new analogue to the CNAME record, called the DNAME
- resource record [DNAME]. The DNAME record provides alternate naming
- to an entire subtree of the domain name space, rather than to a
- single node. It causes some suffix of a queried name to be
- substituted with a name from the DNAME record's RDATA.
-
- For example, a resolver or server providing recursion, while looking
- up a QNAME a.b.c.d.e.f may encounter a DNAME record
-
- d.e.f. DNAME w.xy.
-
- which will cause it to look for a.b.c.w.xy.
-
-3. Specifications
-
-3.1. The A6 Record Type
-
- The A6 record type is specific to the IN (Internet) class and has
- type number 38 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al. Standards Track [Page 5]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-3.1.1. Format
-
- The RDATA portion of the A6 record contains two or three fields.
-
- +-----------+------------------+-------------------+
- |Prefix len.| Address suffix | Prefix name |
- | (1 octet) | (0..16 octets) | (0..255 octets) |
- +-----------+------------------+-------------------+
-
- o A prefix length, encoded as an eight-bit unsigned integer with
- value between 0 and 128 inclusive.
-
- o An IPv6 address suffix, encoded in network order (high-order octet
- first). There MUST be exactly enough octets in this field to
- contain a number of bits equal to 128 minus prefix length, with 0
- to 7 leading pad bits to make this field an integral number of
- octets. Pad bits, if present, MUST be set to zero when loading a
- zone file and ignored (other than for SIG [DNSSEC] verification)
- on reception.
-
- o The name of the prefix, encoded as a domain name. By the rules of
- [DNSIS], this name MUST NOT be compressed.
-
- The domain name component SHALL NOT be present if the prefix length
- is zero. The address suffix component SHALL NOT be present if the
- prefix length is 128.
-
- It is SUGGESTED that an A6 record intended for use as a prefix for
- other A6 records have all the insignificant trailing bits in its
- address suffix field set to zero.
-
-3.1.2. Processing
-
- A query with QTYPE=A6 causes type A6 and type NS additional section
- processing for the prefix names, if any, in the RDATA field of the A6
- records in the answer section. This processing SHOULD be recursively
- applied to the prefix names of A6 records included as additional
- data. When space in the reply packet is a limit, inclusion of
- additional A6 records takes priority over NS records.
-
- It is an error for an A6 record with prefix length L1 > 0 to refer to
- a domain name which owns an A6 record with a prefix length L2 > L1.
- If such a situation is encountered by a resolver, the A6 record with
- the offending (larger) prefix length MUST be ignored. Robustness
- precludes signaling an error if addresses can still be formed from
- valid A6 records, but it is SUGGESTED that zone maintainers from time
- to time check all the A6 records their zones reference.
-
-
-
-
-Crawford, et al. Standards Track [Page 6]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-3.1.3. Textual Representation
-
- The textual representation of the RDATA portion of the A6 resource
- record in a zone file comprises two or three fields separated by
- whitespace.
-
- o A prefix length, represented as a decimal number between 0 and 128
- inclusive,
-
- o the textual representation of an IPv6 address as defined in
- [AARCH] (although some leading and/or trailing bits may not be
- significant),
-
- o a domain name, if the prefix length is not zero.
-
- The domain name MUST be absent if the prefix length is zero. The
- IPv6 address MAY be be absent if the prefix length is 128. A number
- of leading address bits equal to the prefix length SHOULD be zero,
- either implicitly (through the :: notation) or explicitly, as
- specified in section 3.1.1.
-
-3.1.4. Name Resolution Procedure
-
- To obtain the IPv6 address or addresses which belong to a given name,
- a DNS client MUST obtain one or more complete chains of A6 records,
- each chain beginning with a record owned by the given name and
- including a record owned by the prefix name in that record, and so on
- recursively, ending with an A6 record with a prefix length of zero.
- One IPv6 address is formed from one such chain by taking the value of
- each bit position from the earliest A6 record in the chain which
- validly covers that position, as indicated by the prefix length. The
- set of all IPv6 addresses for the given name comprises the addresses
- formed from all complete chains of A6 records beginning at that name,
- discarding records which have invalid prefix lengths as defined in
- section 3.1.2.
-
- If some A6 queries fail and others succeed, a client might obtain a
- non-empty but incomplete set of IPv6 addresses for a host. In many
- situations this may be acceptable. The completeness of a set of A6
- records may always be determined by inspection.
-
-3.2. Zone Structure for Reverse Lookups
-
- Very little of the new scheme's data actually appears under IP6.ARPA;
- only the first level of delegation needs to be under that domain.
- More levels of delegation could be placed under IP6.ARPA if some
- top-level delegations were done via NS records instead of DNAME
- records, but this would incur some cost in renumbering ease at the
-
-
-
-Crawford, et al. Standards Track [Page 7]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- level of TLAs [AGGR]. Therefore, it is declared here that all
- address space delegations SHOULD be done by the DNAME mechanism
- rather than NS.
-
- In addition, since uniformity in deployment will simplify maintenance
- of address delegations, it is SUGGESTED that address and prefix
- information be stored immediately below a DNS label "IP6". Stated
- another way, conformance with this suggestion would mean that "IP6"
- is the first label in the RDATA field of DNAME records which support
- IPv6 reverse lookups.
-
- When any "reserved" or "must be zero" bits are adjacent to a
- delegation boundary, the higher-level entity MUST retain those bits
- in its own control and delegate only the bits over which the lower-
- level entity has authority.
-
- To find the name of a node given its IPv6 address, a DNS client MUST
- perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the
- 128 bit address as one or more bit-string labels [BITLBL], followed
- by the two standard labels "IP6.ARPA". If recursive service was not
- obtained from a server and the desired PTR record was not returned,
- the resolver MUST handle returned DNAME records as specified in
- [DNAME], and NS records as specified in [DNSCF], and iterate.
-
-4. Modifications to Existing Query Types
-
- All existing query types that perform type A additional section
- processing, i.e. the name server (NS), mail exchange (MX), and
- mailbox (MB) query types, and the experimental AFS data base (AFSDB)
- and route through (RT) types, must be redefined to perform type A, A6
- and AAAA additional section processing, with type A having the
- highest priority for inclusion and type AAAA the lowest. This
- redefinition means that a name server may add any relevant IPv4 and
- IPv6 address information available locally to the additional section
- of a response when processing any one of the above queries. The
- recursive inclusion of A6 records referenced by A6 records already
- included in the additional section is OPTIONAL.
-
-5. Usage Illustrations
-
- This section provides examples of use of the mechanisms defined in
- the previous section. All addresses and domains mentioned here are
- intended to be fictitious and for illustrative purposes only.
- Example delegations will be on 4-bit boundaries solely for
- readability; this specification is indifferent to bit alignment.
-
- Use of the IPv6 aggregatable address format [AGGR] is assumed in the
- examples.
-
-
-
-Crawford, et al. Standards Track [Page 8]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-5.1. A6 Record Chains
-
- Let's take the example of a site X that is multi-homed to two
- "intermediate" providers A and B. The provider A is itself multi-
- homed to two "transit" providers, C and D. The provider B gets its
- transit service from a single provider, E. For simplicity suppose
- that C, D and E all belong to the same top-level aggregate (TLA) with
- identifier (including format prefix) '2345', and the TLA authority at
- ALPHA-TLA.ORG assigns to C, D and E respectively the next level
- aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and
- 2345:000E::/32.
-
- C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
- prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
- B.
-
- A assigns to X the subscriber identification '11' and B assigns the
- subscriber identification '22'. As a result, the site X inherits
- three address prefixes:
-
- o 2345:00C1:CA11::/48 from A, for routes through C.
- o 2345:00D2:DA11::/48 from A, for routes through D.
- o 2345:000E:EB22::/48 from B, for routes through E.
-
- Let us suppose that N is a node in the site X, that it is assigned to
- subnet number 1 in this site, and that it uses the interface
- identifier '1234:5678:9ABC:DEF0'. In our configuration, this node
- will have three addresses:
-
- o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
- o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
- o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-5.1.1. Authoritative Data
-
- We will assume that the site X is represented in the DNS by the
- domain name X.EXAMPLE, while A, B, C, D and E are represented by
- A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we
- assume a subdomain "IP6" that will hold the corresponding prefixes.
- The node N is identified by the domain name N.X.EXAMPLE. The
- following records would then appear in X's DNS.
-
- $ORIGIN X.EXAMPLE.
- N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
- SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
-
-
-
-
-Crawford, et al. Standards Track [Page 9]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- And elsewhere there would appear
-
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
-
- SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
-
- A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
-
- A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
-
- B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
-
- C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
- D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
- E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
-
-5.1.2. Glue
-
- When, as is common, some or all DNS servers for X.EXAMPLE are within
- the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
- enough "glue" information to enable DNS clients to reach those
- nameservers. This is true in IPv6 just as in IPv4. However, the A6
- record affords the DNS administrator some choices. The glue could be
- any of
-
- o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
-
- o a (possibly smaller) set of records which collapse the structure
- of that minimal set,
-
- o or a set of A6 records with prefix length zero, giving the entire
- global addresses of the servers.
-
- The trade-off is ease of maintenance against robustness. The best
- and worst of both may be had together by implementing either the
- first or second option together with the third. To illustrate the
- glue options, suppose that X.EXAMPLE is served by two nameservers
- NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
- ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
- Then the top-level zone EXAMPLE would include one (or more) of the
- following sets of A6 records as glue.
-
-
-
-
-
-
-
-
-
-Crawford, et al. Standards Track [Page 10]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- $ORIGIN EXAMPLE. ; first option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
- NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
- SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
- SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
- IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
-
-
- $ORIGIN EXAMPLE. ; second option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
- A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
- NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
- A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
-
-
- $ORIGIN EXAMPLE. ; third option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
- A6 0 2345:00D2:DA11:1:1:11:111:1111
- A6 0 2345:000E:EB22:1:1:11:111:1111
- NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
- A6 0 2345:00D2:DA11:2:2:22:222:2222
- A6 0 2345:000E:EB22:2:2:22:222:2222
-
- The first and second glue options are robust against renumbering of
- X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
- those providers' own DNS is unreachable. The glue records of the
- third option are robust against DNS failures elsewhere than the zones
- EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
- address space is renumbered.
-
- If the EXAMPLE zone includes redundant glue, for instance the union
- of the A6 records of the first and third options, then under normal
- circumstances duplicate IPv6 addresses will be derived by DNS
- clients. But if provider DNS fails, addresses will still be obtained
- from the zero-prefix-length records, while if the EXAMPLE zone lags
- behind a renumbering of X.EXAMPLE, half of the addresses obtained by
- DNS clients will still be up-to-date.
-
- The zero-prefix-length glue records can of course be automatically
- generated and/or checked in practice.
-
-
-
-
-Crawford, et al. Standards Track [Page 11]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-5.1.3. Variations
-
- Several more-or-less arbitrary assumptions are reflected in the above
- structure. All of the following choices could have been made
- differently, according to someone's notion of convenience or an
- agreement between two parties.
-
- First, that site X has chosen to put subnet information in a
- separate A6 record rather than incorporate it into each node's A6
- records.
-
- Second, that site X is referred to as "SUBSCRIBER-X" by both of
- its providers A and B.
-
- Third, that site X chose to indirect its provider information
- through A6 records at IP6.X.EXAMPLE containing no significant
- bits. An alternative would have been to replicate each subnet
- record for each provider.
-
- Fourth, B and E used a slightly different prefix naming convention
- between themselves than did A, C and D. Each hierarchical pair of
- network entities must arrange this naming between themselves.
-
- Fifth, that the upward prefix referral chain topped out at ALPHA-
- TLA.ORG. There could have been another level which assigned the
- TLA values and holds A6 records containing those bits.
-
- Finally, the above structure reflects an assumption that address
- fields assigned by a given entity are recorded only in A6 records
- held by that entity. Those bits could be entered into A6 records in
- the lower-level entity's zone instead, thus:
-
- IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
- IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
-
- IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
- and so on.
-
- Or the higher-level entities could hold both sorts of A6 records
- (with different DNS owner names) and allow the lower-level entities
- to choose either mode of A6 chaining. But the general principle of
- avoiding data duplication suggests that the proper place to store
- assigned values is with the entity that assigned them.
-
- It is possible, but not necessarily recommended, for a zone
- maintainer to forego the renumbering support afforded by the chaining
- of A6 records and to record entire IPv6 addresses within one zone
- file.
-
-
-
-Crawford, et al. Standards Track [Page 12]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-5.2. Reverse Mapping Zones
-
- Supposing that address space assignments in the TLAs with Format
- Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
- zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
- the IP6.ARPA zone would include
-
- $ORIGIN IP6.ARPA.
- \[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
- \[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
- \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
-
- Eight trailing zero bits have been included in each TLA ID to reflect
- the eight reserved bits in the current aggregatable global unicast
- addresses format [AGGR].
-
-5.2.1. The TLA level
-
- ALPHA-TLA's assignments to network providers C, D and E are reflected
- in the reverse data as follows.
-
- \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
- \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
- \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
-
-5.2.2. The ISP level
-
- The providers A through E carry the following delegation information
- in their zone files.
-
- \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
- \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
- \[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
- \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
- \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
-
- Note that some domain names appear in the RDATA of more than one
- DNAME record. In those cases, one zone is being used to map multiple
- prefixes.
-
-5.2.3. The Site Level
-
- Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
- name translations. This domain is now referenced by two different
- DNAME records held by two different providers.
-
-
-
-
-
-
-Crawford, et al. Standards Track [Page 13]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- $ORIGIN IP6.X.EXAMPLE.
- \[x0001/16] DNAME SUBNET-1
- \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
- and so on.
-
- SUBNET-1 need not have been named in a DNAME record; the subnet bits
- could have been joined with the interface identifier. But if subnets
- are treated alike in both the A6 records and in the reverse zone, it
- will always be possible to keep the forward and reverse definition
- data for each prefix in one zone.
-
-5.3. Lookups
-
- A DNS resolver looking for a hostname for the address
- 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
- DNAME records shown above and would form new queries. Assuming that
- it began the process knowing servers for IP6.ARPA, but that no server
- it consulted provided recursion and none had other useful additional
- information cached, the sequence of queried names and responses would
- be (all with QCLASS=IN, QTYPE=PTR):
-
- To a server for IP6.ARPA:
- QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
-
- Answer:
- \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
-
- To a server for IP6.ALPHA-TLA.ORG:
- QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
-
- Answer:
- \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
-
- To a server for IP6.C.NET.:
- QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
-
- Answer:
- \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
-
- To a server for IP6.A.NET.:
- QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
-
- Answer:
- \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
-
- To a server for IP6.X.EXAMPLE.:
- QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
-
-
-
-
-Crawford, et al. Standards Track [Page 14]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- Answer:
- \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
- \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
-
- All the DNAME (and NS) records acquired along the way can be cached
- to expedite resolution of addresses topologically near to this
- address. And if another global address of N.X.EXAMPLE were resolved
- within the TTL of the final PTR record, that record would not have to
- be fetched again.
-
-5.4. Operational Note
-
- In the illustrations in section 5.1, hierarchically adjacent
- entities, such as a network provider and a customer, must agree on a
- DNS name which will own the definition of the delegated prefix(es).
- One simple convention would be to use a bit-string label representing
- exactly the bits which are assigned to the lower-level entity by the
- higher. For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
- This would place the A6 record(s) defining the delegated prefix at
- exactly the same point in the DNS tree as the DNAME record associated
- with that delegation. The cost of this simplification is that the
- lower-level zone must update its upward-pointing A6 records when it
- is renumbered. This cost may be found quite acceptable in practice.
-
-6. Transition from RFC 1886 and Deployment Notes
-
- When prefixes have been "delegated upward" with A6 records, the
- number of DNS resource records required to establish a single IPv6
- address increases by some non-trivial factor. Those records will
- typically, but not necessarily, come from different DNS zones (which
- can independently suffer failures for all the usual reasons). When
- obtaining multiple IPv6 addresses together, this increase in RR count
- will be proportionally less -- and the total size of a DNS reply
- might even decrease -- if the addresses are topologically clustered.
- But the records could still easily exceed the space available in a
- UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
- SRV query, for example. The possibilities for overall degradation of
- performance and reliability of DNS lookups are numerous, and increase
- with the number of prefix delegations involved, especially when those
- delegations point to records in other zones.
-
- DNS Security [DNSSEC] addresses the trustworthiness of cached data,
- which is a problem intrinsic to DNS, but the cost of applying this to
- an IPv6 address is multiplied by a factor which may be greater than
- the number of prefix delegations involved if different signature
- chains must be verified for different A6 records. If a trusted
- centralized caching server (as in [TSIG], for example) is used, this
- cost might be amortized to acceptable levels. One new phenomenon is
-
-
-
-Crawford, et al. Standards Track [Page 15]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- the possibility that IPv6 addresses may be formed from a A6 records
- from a combination of secure and unsecured zones.
-
- Until more deployment experience is gained with the A6 record, it is
- recommended that prefix delegations be limited to one or two levels.
- A reasonable phasing-in mechanism would be to start with no prefix
- delegations (all A6 records having prefix length 0) and then to move
- to the use of a single level of delegation within a single zone. (If
- the TTL of the "prefix" A6 records is kept to an appropriate duration
- the capability for rapid renumbering is not lost.) More aggressively
- flexible delegation could be introduced for a subset of hosts for
- experimentation.
-
-6.1. Transition from AAAA and Coexistence with A Records
-
- Administrators of zones which contain A6 records can easily
- accommodate deployed resolvers which understand AAAA records but not
- A6 records. Such administrators can do automatic generation of AAAA
- records for all of a zone's names which own A6 records by a process
- which mimics the resolution of a hostname to an IPv6 address (see
- section 3.1.4). Attention must be paid to the TTL assigned to a
- generated AAAA record, which MUST be no more than the minimum of the
- TTLs of the A6 records that were used to form the IPv6 address in
- that record. For full robustness, those A6 records which were in
- different zones should be monitored for changes (in TTL or RDATA)
- even when there are no changes to zone for which AAAA records are
- being generated. If the zone is secure [DNSSEC], the generated AAAA
- records MUST be signed along with the rest of the zone data.
-
- A zone-specific heuristic MAY be used to avoid generation of AAAA
- records for A6 records which record prefixes, although such
- superfluous records would be relatively few in number and harmless.
- Examples of such heuristics include omitting A6 records with a prefix
- length less than the largest value found in the zone file, or records
- with an address suffix field with a certain number of trailing zero
- bits.
-
- On the client side, when looking up and IPv6 address, the order of A6
- and AAAA queries MAY be configurable to be one of: A6, then AAAA;
- AAAA, then A6; A6 only; or both in parallel. The default order (or
- only order, if not configurable) MUST be to try A6 first, then AAAA.
- If and when the AAAA becomes deprecated a new document will change
- the default.
-
- The guidelines and options for precedence between IPv4 and IPv6
- addresses are specified in [TRANS]. All mentions of AAAA records in
- that document are henceforth to be interpreted as meaning A6 and/or
- AAAA records in the order specified in the previous paragraph.
-
-
-
-Crawford, et al. Standards Track [Page 16]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-6.2. Transition from Nibble Labels to Binary Labels
-
- Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
- as follows:
-
- An IPv6 address is represented as a name in the IP6.INT domain by
- a sequence of nibbles separated by dots with the suffix
- ".IP6.INT". The sequence of nibbles is encoded in reverse order,
- i.e. the low-order nibble is encoded first, followed by the next
- low-order nibble and so on. Each nibble is represented by a
- hexadecimal digit. For example, a name for the address
- 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
- 5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
- 8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
-
- Implementations conforming to this specification will perform a
- lookup of a binary label in IP6.ARPA as specified in Section 3.2. It
- is RECOMMENDED that for a transition period implementations first
- lookup the binary label in IP6.ARPA and if this fails try to lookup
- the 'nibble' label in IP6.INT.
-
-7. Security Considerations
-
- The signing authority [DNSSEC] for the A6 records which determine an
- IPv6 address is distributed among several entities, reflecting the
- delegation path of the address space which that address occupies.
- DNS Security is fully applicable to bit-string labels and DNAME
- records. And just as in IPv4, verification of name-to-address
- mappings is logically independent of verification of address-to-name
- mappings.
-
- With or without DNSSEC, the incomplete but non-empty address set
- scenario of section 3.1.4 could be caused by selective interference
- with DNS lookups. If in some situation this would be more harmful
- than complete DNS failure, it might be mitigated on the client side
- by refusing to act on an incomplete set, or on the server side by
- listing all addresses in A6 records with prefix length 0.
-
-8. IANA Considerations
-
- The A6 resource record has been assigned a Type value of 38.
-
-
-
-
-
-
-
-
-
-
-Crawford, et al. Standards Track [Page 17]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-9. Acknowledgments
-
- The authors would like to thank the following persons for valuable
- discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, Randy
- Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
- Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
- Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
- Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
-
-10. References
-
- [AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP
- version 6, RFC 1886, December 1995.
-
- [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
- Aggregatable Global Unicast Address Format", RFC 2374, July
- 1998.
-
- [BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
- RFC 2673, August 1999.
-
- [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
- 2672, August 1999.
-
- [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [DNSIS] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
- Security Extensions", RFC 2535, March 1999.
-
- [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
- 1900, February 1996.
-
- [RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering
- Overview: Why would I want it and what is it anyway?", RFC
- 2071, January 1997.
-
- [RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
- Behaviour Today", RFC 2101, February 1997.
-
-
-
-Crawford, et al. Standards Track [Page 18]
-
-RFC 2874 IPv6 DNS July 2000
-
-
- [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
- IPv6 Hosts and Routers", RFC 1933, April 1996.
-
- [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
-11. Authors' Addresses
-
- Matt Crawford
- Fermilab
- MS 368
- PO Box 500
- Batavia, IL 60510
- USA
-
- Phone: +1 630 840-3461
- EMail: crawdad@fnal.gov
-
-
- Christian Huitema
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
-
- EMail: huitema@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al. Standards Track [Page 19]
-
-RFC 2874 IPv6 DNS July 2000
-
-
-12. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al. Standards Track [Page 20]
-
diff --git a/contrib/bind9/doc/rfc/rfc2915.txt b/contrib/bind9/doc/rfc/rfc2915.txt
deleted file mode 100644
index 2022ba115724c..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2915.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Mealling
-Request for Comments: 2915 Network Solutions, Inc.
-Updates: 2168 R. Daniel
-Category: Standards Track DATAFUSION, Inc.
- September 2000
-
-
- The Naming Authority Pointer (NAPTR) DNS Resource Record
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- This document describes a Domain Name System (DNS) resource record
- which specifies a regular expression based rewrite rule that, when
- applied to an existing string, will produce a new domain label or
- Uniform Resource Identifier (URI). Depending on the value of the
- flags field of the resource record, the resulting domain label or URI
- may be used in subsequent queries for the Naming Authority Pointer
- (NAPTR) resource records (to delegate the name lookup) or as the
- output of the entire process for which this system is used (a
- resolution server for URI resolution, a service URI for ENUM style
- e.164 number to URI mapping, etc).
-
- This allows the DNS to be used to lookup services for a wide variety
- of resource names (including URIs) which are not in domain name
- syntax. Reasons for doing this range from URN Resource Discovery
- Systems to moving out-of-date services to new domains.
-
- This document updates the portions of RFC 2168 specifically dealing
- with the definition of the NAPTR records and how other, non-URI
- specific applications, might use NAPTR.
-
-
-
-
-
-
-
-
-
-Mealling & Daniel Standards Track [Page 1]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Substitution Expression Grammar . . . . . . . . . . . . . . 7
- 4. The Basic NAPTR Algorithm . . . . . . . . . . . . . . . . . 8
- 5. Concerning How NAPTR Uses SRV Records . . . . . . . . . . . 9
- 6. Application Specifications . . . . . . . . . . . . . . . . . 10
- 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 7.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 8. DNS Packet Format . . . . . . . . . . . . . . . . . . . . . 13
- 9. Master File Format . . . . . . . . . . . . . . . . . . . . . 14
- 10. Advice for DNS Administrators . . . . . . . . . . . . . . . 14
- 11. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
- 13. Security Considerations . . . . . . . . . . . . . . . . . . 15
- 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
- References . . . . . . . . . . . . . . . . . . . . . . . . . 16
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
-
-1. Introduction
-
- This RR was originally produced by the URN Working Group [3] as a way
- to encode rule-sets in DNS so that the delegated sections of a URI
- could be decomposed in such a way that they could be changed and re-
- delegated over time. The result was a Resource Record that included
- a regular expression that would be used by a client program to
- rewrite a string into a domain name. Regular expressions were chosen
- for their compactness to expressivity ratio allowing for a great deal
- of information to be encoded in a rather small DNS packet.
-
- The function of rewriting a string according to the rules in a record
- has usefulness in several different applications. This document
- defines the basic assumptions to which all of those applications must
- adhere to. It does not define the reasons the rewrite is used, what
- the expected outcomes are, or what they are used for. Those are
- specified by applications that define how they use the NAPTR record
- and algorithms within their contexts.
-
- Flags and other fields are also specified in the RR to control the
- rewrite procedure in various ways or to provide information on how to
- communicate with the host at the domain name that was the result of
- the rewrite.
-
-
-
-
-
-Mealling & Daniel Standards Track [Page 2]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- The final result is a RR that has several fields that interact in a
- non-trivial but implementable way. This document specifies those
- fields and their values.
-
- This document does not define applications that utilizes this rewrite
- functionality. Instead it specifies just the mechanics of how it is
- done. Why its done, what the rules concerning the inputs, and the
- types of rules used are reserved for other documents that fully
- specify a particular application. This separation is due to several
- different applications all wanting to take advantage of the rewrite
- rule lookup process. Each one has vastly different reasons for why
- and how it uses the service, thus requiring that the definition of
- the service be generic.
-
- 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.
-
- All references to Uniform Resource Identifiers in this document
- adhere to the 'absoluteURI' production of the "Collected ABNF"
- found in RFC 2396 [9]. Specifically, the semantics of URI
- References do not apply since the concept of a Base makes no sense
- here.
-
-2. NAPTR RR Format
-
- The format of the NAPTR RR is given below. The DNS type code [1] for
- NAPTR is 35.
-
- Domain TTL Class Type Order Preference Flags Service Regexp
- Replacement
-
- Domain
- The domain name to which this resource record refers. This is the
- 'key' for this entry in the rule database. This value will either
- be the first well known key (<something>.uri.arpa for example) or
- a new key that is the output of a replacement or regexp rewrite.
- Beyond this, it has the standard DNS requirements [1].
-
- TTL
- Standard DNS meaning [1].
-
- Class
- Standard DNS meaning [1].
-
- Type
- The Type Code [1] for NAPTR is 35.
-
-
-
-
-Mealling & Daniel Standards Track [Page 3]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- Order
- A 16-bit unsigned integer specifying the order in which the NAPTR
- records MUST be processed to ensure the correct ordering of
- rules. Low numbers are processed before high numbers, and once a
- NAPTR is found whose rule "matches" the target, the client MUST
- NOT consider any NAPTRs with a higher value for order (except as
- noted below for the Flags field).
-
- Preference
- A 16-bit unsigned integer that specifies the order in which NAPTR
- records with equal "order" values SHOULD be processed, low
- numbers being processed before high numbers. This is similar to
- the preference field in an MX record, and is used so domain
- administrators can direct clients towards more capable hosts or
- lighter weight protocols. A client MAY look at records with
- higher preference values if it has a good reason to do so such as
- not understanding the preferred protocol or service.
-
- The important difference between Order and Preference is that
- once a match is found the client MUST NOT consider records with a
- different Order but they MAY process records with the same Order
- but different Preferences. I.e., Preference is used to give weight
- to rules that are considered the same from an authority
- standpoint but not from a simple load balancing standpoint.
-
- Flags
- A <character-string> containing flags to control aspects of the
- rewriting and interpretation of the fields in the record. Flags
- are single characters from the set [A-Z0-9]. The case of the
- alphabetic characters is not significant.
-
- At this time only four flags, "S", "A", "U", and "P", are
- defined. The "S", "A" and "U" flags denote a terminal lookup.
- This means that this NAPTR record is the last one and that the
- flag determines what the next stage should be. The "S" flag
- means that the next lookup should be for SRV records [4]. See
- Section 5 for additional information on how NAPTR uses the SRV
- record type. "A" means that the next lookup should be for either
- an A, AAAA, or A6 record. The "U" flag means that the next step
- is not a DNS lookup but that the output of the Regexp field is an
- URI that adheres to the 'absoluteURI' production found in the
- ABNF of RFC 2396 [9]. Since there may be applications that use
- NAPTR to also lookup aspects of URIs, implementors should be
- aware that this may cause loop conditions and should act
- accordingly.
-
-
-
-
-
-
-Mealling & Daniel Standards Track [Page 4]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- The "P" flag says that the remainder of the application side
- algorithm shall be carried out in a Protocol-specific fashion.
- The new set of rules is identified by the Protocol specified in
- the Services field. The record that contains the 'P' flag is the
- last record that is interpreted by the rules specified in this
- document. The new rules are dependent on the application for
- which they are being used and the protocol specified. For
- example, if the application is a URI RDS and the protocol is WIRE
- then the new set of rules are governed by the algorithms
- surrounding the WIRE HTTP specification and not this document.
-
- The remaining alphabetic flags are reserved for future versions
- of the NAPTR specification. The numeric flags may be used for
- local experimentation. The S, A, U and P flags are all mutually
- exclusive, and resolution libraries MAY signal an error if more
- than one is given. (Experimental code and code for assisting in
- the creation of NAPTRs would be more likely to signal such an
- error than a client such as a browser). It is anticipated that
- multiple flags will be allowed in the future, so implementers
- MUST NOT assume that the flags field can only contain 0 or 1
- characters. Finally, if a client encounters a record with an
- unknown flag, it MUST ignore it and move to the next record. This
- test takes precedence even over the "order" field. Since flags
- can control the interpretation placed on fields, a novel flag
- might change the interpretation of the regexp and/or replacement
- fields such that it is impossible to determine if a record
- matched a given target.
-
- The "S", "A", and "U" flags are called 'terminal' flags since
- they halt the looping rewrite algorithm. If those flags are not
- present, clients may assume that another NAPTR RR exists at the
- domain name produced by the current rewrite rule. Since the "P"
- flag specifies a new algorithm, it may or may not be 'terminal'.
- Thus, the client cannot assume that another NAPTR exists since
- this case is determined elsewhere.
-
- DNS servers MAY interpret these flags and values and use that
- information to include appropriate SRV and A,AAAA, or A6 records
- in the additional information portion of the DNS packet. Clients
- are encouraged to check for additional information but are not
- required to do so.
-
- Service
- Specifies the service(s) available down this rewrite path. It may
- also specify the particular protocol that is used to talk with a
- service. A protocol MUST be specified if the flags field states
- that the NAPTR is terminal. If a protocol is specified, but the
- flags field does not state that the NAPTR is terminal, the next
-
-
-
-Mealling & Daniel Standards Track [Page 5]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- lookup MUST be for a NAPTR. The client MAY choose not to perform
- the next lookup if the protocol is unknown, but that behavior
- MUST NOT be relied upon.
-
- The service field may take any of the values below (using the
- Augmented BNF of RFC 2234 [5]):
-
- service_field = [ [protocol] *("+" rs)]
- protocol = ALPHA *31ALPHANUM
- rs = ALPHA *31ALPHANUM
- ; The protocol and rs fields are limited to 32
- ; characters and must start with an alphabetic.
-
- For example, an optional protocol specification followed by 0 or
- more resolution services. Each resolution service is indicated by
- an initial '+' character.
-
- Note that the empty string is also a valid service field. This
- will typically be seen at the beginning of a series of rules,
- when it is impossible to know what services and protocols will be
- offered by a particular service.
-
- The actual format of the service request and response will be
- determined by the resolution protocol, and is the subject for
- other documents. Protocols need not offer all services. The
- labels for service requests shall be formed from the set of
- characters [A-Z0-9]. The case of the alphabetic characters is
- not significant.
-
- The list of "valid" protocols for any given NAPTR record is any
- protocol that implements some or all of the services defined for
- a NAPTR application. Currently, THTTP [6] is the only protocol
- that is known to make that claim at the time of publication. Any
- other protocol that is to be used must have documentation
- specifying:
-
- * how it implements the services of the application
-
- * how it is to appear in the NAPTR record (i.e., the string id
- of the protocol)
-
- The list of valid Resolution Services is defined by the documents
- that specify individual NAPTR based applications.
-
- It is worth noting that the interpretation of this field is
- subject to being changed by new flags, and that the current
- specification is oriented towards telling clients how to talk
- with a URN resolver.
-
-
-
-Mealling & Daniel Standards Track [Page 6]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- Regexp
- A STRING containing a substitution expression that is applied to
- the original string held by the client in order to construct the
- next domain name to lookup. The grammar of the substitution
- expression is given in the next section.
-
- The regular expressions MUST NOT be used in a cumulative fashion,
- that is, they should only be applied to the original string held
- by the client, never to the domain name produced by a previous
- NAPTR rewrite. The latter is tempting in some applications but
- experience has shown such use to be extremely fault sensitive,
- very error prone, and extremely difficult to debug.
-
- Replacement
- The next NAME to query for NAPTR, SRV, or address records
- depending on the value of the flags field. This MUST be a fully
- qualified domain-name. Unless and until permitted by future
- standards action, name compression is not to be used for this
- field.
-
-3. Substitution Expression Grammar
-
- The content of the regexp field is a substitution expression. True
- sed(1) and Perl style substitution expressions are not appropriate
- for use in this application for a variety of reasons stemming from
- internationalization requirements and backref limitations, therefore
- the contents of the regexp field MUST follow the grammar below:
-
-subst_expr = delim-char ere delim-char repl delim-char *flags
-delim-char = "/" / "!" / ... <Any non-digit or non-flag character
- other than backslash '\'. All occurances of a delim_char
- in a subst_expr must be the same character.>
-ere = POSIX Extended Regular Expression
-repl = 1 * ( OCTET / backref )
-backref = "\" 1POS_DIGIT
-flags = "i"
-POS_DIGIT = %x31-39 ; 0 is not an allowed backref
-
- The definition of a POSIX Extended Regular Expression can be found in
- [8], section 2.8.4.
-
- The result of applying the substitution expression to the original
- URI MUST result in either a string that obeys the syntax for DNS
- domain-names [1] or a URI [9] if the Flags field contains a 'u'.
- Since it is possible for the regexp field to be improperly specified,
- such that a non-conforming domain-name can be constructed, client
- software SHOULD verify that the result is a legal DNS domain-name
- before making queries on it.
-
-
-
-Mealling & Daniel Standards Track [Page 7]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- Backref expressions in the repl portion of the substitution
- expression are replaced by the (possibly empty) string of characters
- enclosed by '(' and ')' in the ERE portion of the substitution
- expression. N is a single digit from 1 through 9, inclusive. It
- specifies the N'th backref expression, the one that begins with the
- N'th '(' and continues to the matching ')'. For example, the ERE
-
- (A(B(C)DE)(F)G)
-
- has backref expressions:
-
- \1 = ABCDEFG
- \2 = BCDE
- \3 = C
- \4 = F
- \5..\9 = error - no matching subexpression
-
- The "i" flag indicates that the ERE matching SHALL be performed in a
- case-insensitive fashion. Furthermore, any backref replacements MAY
- be normalized to lower case when the "i" flag is given.
-
- The first character in the substitution expression shall be used as
- the character that delimits the components of the substitution
- expression. There must be exactly three non-escaped occurrences of
- the delimiter character in a substitution expression. Since escaped
- occurrences of the delimiter character will be interpreted as
- occurrences of that character, digits MUST NOT be used as delimiters.
- Backrefs would be confused with literal digits were this allowed.
- Similarly, if flags are specified in the substitution expression, the
- delimiter character must not also be a flag character.
-
-4. The Basic NAPTR Algorithm
-
- The behavior and meaning of the flags and services assume an
- algorithm where the output of one rewrite is a new key that points to
- another rule. This looping algorithm allows NAPTR records to
- incrementally specify a complete rule. These incremental rules can
- be delegated which allows other entities to specify rules so that one
- entity does not need to understand _all_ rules.
-
- The algorithm starts with a string and some known key (domain).
- NAPTR records for this key are retrieved, those with unknown Flags or
- inappropriate Services are discarded and the remaining records are
- sorted by their Order field. Within each value of Order, the records
- are further sorted by the Preferences field.
-
- The records are examined in sorted order until a matching record is
- found. A record is considered a match iff:
-
-
-
-Mealling & Daniel Standards Track [Page 8]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- o it has a Replacement field value instead of a Regexp field value.
-
- o or the Regexp field matches the string held by the client.
-
- The first match MUST be the match that is used. Once a match is
- found, the Services field is examined for whether or not this rule
- advances toward the desired result. If so, the rule is applied to
- the target string. If not, the process halts. The domain that
- results from the regular expression is then used as the domain of the
- next loop through the NAPTR algorithm. Note that the same target
- string is used throughout the algorithm.
-
- This looping is extremely important since it is the method by which
- complex rules are broken down into manageable delegated chunks. The
- flags fields simply determine at which point the looping should stop
- (or other specialized behavior).
-
- Since flags are valid at any level of the algorithm, the degenerative
- case is to never loop but to look up the NAPTR and then stop. In
- many specialized cases this is all that is needed. Implementors
- should be aware that the degenerative case should not become the
- common case.
-
-5. Concerning How NAPTR Uses SRV Records
-
- When the SRV record type was originally specified it assumed that the
- client did not know the specific domain-name before hand. The client
- would construct a domain-name more in the form of a question than the
- usual case of knowing ahead of time that the domain-name should
- exist. I.e., if the client wants to know if there is a TCP based
- HTTP server running at a particular domain, the client would
- construct the domain-name _http._tcp.somedomain.com and ask the DNS
- if that records exists. The underscores are used to avoid collisions
- with potentially 'real' domain-names.
-
- In the case of NAPTR, the actual domain-name is specified by the
- various fields in the NAPTR record. In this case the client isn't
- asking a question but is instead attempting to get at information
- that it has been told exists in an SRV record at that particular
- domain-name. While this usage of SRV is slightly different than the
- SRV authors originally intended it does not break any of the
- assumptions concerning what SRV contains. Also, since the NAPTR
- explicitly spells out the domain-name for which an SRV exists, that
- domain-name MUST be used in SRV queries with NO transformations. Any
- given NAPTR record may result in a domain-name to be used for SRV
- queries that may or may not contain the SRV standardized underscore
-
-
-
-
-
-Mealling & Daniel Standards Track [Page 9]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- characters. NAPTR applications that make use of SRV MUST NOT attempt
- to understand these domains or use them according to how the SRV
- specification structures its query domains.
-
-6. Application Specifications
-
- It should be noted that the NAPTR algorithm is the basic assumption
- about how NAPTR works. The reasons for the rewrite and the expected
- output and its use are specified by documents that define what
- applications the NAPTR record and algorithm are used for. Any
- document that defines such an application must define the following:
-
- o The first known domain-name or how to build it
-
- o The valid Services and Protocols
-
- o What the expected use is for the output of the last rewrite
-
- o The validity and/or behavior of any 'P' flag protocols.
-
- o The general semantics surrounding why and how NAPTR and its
- algorithm are being used.
-
-7. Examples
-
- NOTE: These are examples only. They are taken from ongoing work and
- may not represent the end result of that work. They are here for
- pedagogical reasons only.
-
-7.1 Example 1
-
- NAPTR was originally specified for use with the a Uniform Resource
- Name Resolver Discovery System. This example details how a
- particular URN would use the NAPTR record to find a resolver service.
-
- Consider a URN namespace based on MIME Content-Ids. The URN might
- look like this:
-
- urn:cid:39CB83F7.A8450130@fake.gatech.edu
-
- (Note that this example is chosen for pedagogical purposes, and does
- not conform to the CID URL scheme.)
-
- The first step in the resolution process is to find out about the CID
- namespace. The namespace identifier [3], 'cid', is extracted from
- the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first
- 'known' key in the NAPTR algorithm. The NAPTR records for
- cid.urn.arpa looked up and return a single record:
-
-
-
-Mealling & Daniel Standards Track [Page 10]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- cid.urn.arpa.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" .
-
- There is only one NAPTR response, so ordering the responses is not a
- problem. The replacement field is empty, so the pattern provided in
- the regexp field is used. We apply that regexp to the entire URN to
- see if it matches, which it does. The \2 part of the substitution
- expression returns the string "gatech.edu". Since the flags field
- does not contain "s" or "a", the lookup is not terminal and our next
- probe to DNS is for more NAPTR records where the new domain is '
- gatech.edu' and the string is the same string as before.
-
- Note that the rule does not extract the full domain name from the
- CID, instead it assumes the CID comes from a host and extracts its
- domain. While all hosts, such as mordred, could have their very own
- NAPTR, maintaining those records for all the machines at a site as
- large as Georgia Tech would be an intolerable burden. Wildcards are
- not appropriate here since they only return results when there is no
- exactly matching names already in the system.
-
- The record returned from the query on "gatech.edu" might look like:
-
-;; order pref flags service regexp replacement
- IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu.
- IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu.
- IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu.
-
- Continuing with the example, note that the values of the order and
- preference fields are equal in all records, so the client is free to
- pick any record. The flags field tells us that these are the last
- NAPTR patterns we should see, and after the rewrite (a simple
- replacement in this case) we should look up SRV records to get
- information on the hosts that can provide the necessary service.
-
- Assuming we prefer the Z39.50 protocol, our lookup might return:
-
- ;; Pref Weight Port Target
- _z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu.
- IN SRV 0 0 1000 z3950.cc.gatech.edu.
- IN SRV 0 0 1000 z3950.uga.edu.
-
- telling us three hosts that could actually do the resolution, and
- giving us the port we should use to talk to their Z39.50 server.
-
- Recall that the regular expression used \2 to extract a domain name
- from the CID, and \. for matching the literal '.' characters
- separating the domain name components. Since '\' is the escape
-
-
-
-Mealling & Daniel Standards Track [Page 11]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- character, literal occurances of a backslash must be escaped by
- another backslash. For the case of the cid.urn.arpa record above,
- the regular expression entered into the master file should be
- "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually
- receives the record, the pattern will have been converted to
- "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
-
-7.2 Example 2
-
- Even if URN systems were in place now, there would still be a
- tremendous number of URLs. It should be possible to develop a URN
- resolution system that can also provide location independence for
- those URLs. This is related to the requirement that URNs be able to
- grandfather in names from other naming systems, such as ISO Formal
- Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
- etc.
-
- The NAPTR RR could also be used for URLs that have already been
- assigned. Assume we have the URL for a very popular piece of
- software that the publisher wishes to mirror at multiple sites around
- the world:
-
- Using the rules specified for this application we extract the prefix,
- "http", and lookup NAPTR records for http.uri.arpa. This might
- return a record of the form
-
- http.uri.arpa. IN NAPTR
- ;; order pref flags service regexp replacement
- 100 90 "" "" "!http://([^/:]+)!\1!i" .
-
- This expression returns everything after the first double slash and
- before the next slash or colon. (We use the '!' character to delimit
- the parts of the substitution expression. Otherwise we would have to
- use backslashes to escape the forward slashes and would have a regexp
- in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
-
- Applying this pattern to the URL extracts "www.foo.com". Looking up
- NAPTR records for that might return:
-
- www.foo.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com.
- IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com.
-
- Looking up SRV records for http.tcp.foo.com would return information
- on the hosts that foo.com has designated to be its mirror sites. The
- client can then pick one for the user.
-
-
-
-
-Mealling & Daniel Standards Track [Page 12]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
-7.3 Example 3
-
- A non-URI example is the ENUM application which uses a NAPTR record
- to map an e.164 telephone number to a URI. In order to convert the
- phone number to a domain name for the first iteration all characters
- other than digits are removed from the the telephone number, the
- entire number is inverted, periods are put between each digit and the
- string ".e164.arpa" is put on the left-hand side. For example, the
- E.164 phone number "+1-770-555-1212" converted to a domain-name it
- would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
-
- For this example telephone number we might get back the following
- NAPTR records:
-
-$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
- IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@tele2.se!" .
- IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!" .
-
- This application uses the same 'u' flag as the URI Resolution
- application. This flag states that the Rule is terminal and that the
- output is a URI which contains the information needed to contact that
- telephone service. ENUM also uses the same format for its Service
- field except that it defines the 'E2U' service instead of the 'I2*'
- services that URI resolution uses. The example above states that the
- available protocols used to access that telephone's service are
- either the Session Initiation Protocol or SMTP mail.
-
-8. DNS Packet Format
-
- The packet format for the NAPTR record is:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ORDER |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PREFERENCE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / FLAGS /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / SERVICES /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / REGEXP /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / REPLACEMENT /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-
-Mealling & Daniel Standards Track [Page 13]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- where:
-
- FLAGS A <character-string> which contains various flags.
-
- SERVICES A <character-string> which contains protocol and service
- identifiers.
-
- REGEXP A <character-string> which contains a regular expression.
-
- REPLACEMENT A <domain-name> which specifies the new value in the
- case where the regular expression is a simple replacement
- operation.
-
- <character-string> and <domain-name> as used here are defined in
- RFC1035 [1].
-
-9. Master File Format
-
- The master file format follows the standard rules in RFC-1035 [1].
- Order and preference, being 16-bit unsigned integers, shall be an
- integer between 0 and 65535. The Flags and Services and Regexp
- fields are all quoted <character-string>s. Since the Regexp field
- can contain numerous backslashes and thus should be treated with
- care. See Section 10 for how to correctly enter and escape the
- regular expression.
-
-10. Advice for DNS Administrators
-
- Beware of regular expressions. Not only are they difficult to get
- correct on their own, but there is the previously mentioned
- interaction with DNS. Any backslashes in a regexp must be entered
- twice in a zone file in order to appear once in a query response.
- More seriously, the need for double backslashes has probably not been
- tested by all implementors of DNS servers.
-
- The "a" flag allows the next lookup to be for address records (A,
- AAAA, A6) rather than SRV records. Since there is no place for a
- port specification in the NAPTR record, when the "A" flag is used the
- specified protocol must be running on its default port.
-
- The URN Syntax draft defines a canonical form for each URN, which
- requires %encoding characters outside a limited repertoire. The
- regular expressions MUST be written to operate on that canonical
- form. Since international character sets will end up with extensive
- use of %encoded characters, regular expressions operating on them
- will be essentially impossible to read or write by hand.
-
-
-
-
-
-Mealling & Daniel Standards Track [Page 14]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
-11. Notes
-
- o A client MUST process multiple NAPTR records in the order
- specified by the "order" field, it MUST NOT simply use the first
- record that provides a known protocol and service combination.
-
- o When multiple RRs have the same "order" and all other criteria
- being equal, the client should use the value of the preference
- field to select the next NAPTR to consider. However, because it
- will often be the case where preferred protocols or services
- exist, clients may use this additional criteria to sort
- the records.
-
- o If the lookup after a rewrite fails, clients are strongly
- encouraged to report a failure, rather than backing up to pursue
- other rewrite paths.
-
- o Note that SRV RRs impose additional requirements on clients.
-
-12. IANA Considerations
-
- The only registration function that impacts the IANA is for the
- values that are standardized for the Services and Flags fields. To
- extend the valid values of the Flags field beyond what is specified
- in this document requires a published specification that is approved
- by the IESG.
-
- The values for the Services field will be determined by the
- application that makes use of the NAPTR record. Those values must be
- specified in a published specification and approved by the IESG.
-
-13. Security Considerations
-
- The interactions with DNSSEC are currently being studied. It is
- expected that NAPTR records will be signed with SIG records once the
- DNSSEC work is deployed.
-
- The rewrite rules make identifiers from other namespaces subject to
- the same attacks as normal domain names. Since they have not been
- easily resolvable before, this may or may not be considered a
- problem.
-
- Regular expressions should be checked for sanity, not blindly passed
- to something like PERL.
-
- This document has discussed a way of locating a service, but has not
- discussed any detail of how the communication with that service takes
- place. There are significant security considerations attached to the
-
-
-
-Mealling & Daniel Standards Track [Page 15]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
- communication with a service. Those considerations are outside the
- scope of this document, and must be addressed by the specifications
- for particular communication protocols.
-
-14. Acknowledgments
-
- The editors would like to thank Keith Moore for all his consultations
- during the development of this memo. We would also like to thank
- Paul Vixie for his assistance in debugging our implementation, and
- his answers on our questions. Finally, we would like to acknowledge
- our enormous intellectual debt to the participants in the Knoxville
- series of meetings, as well as to the participants in the URI and URN
- working groups.
-
-References
-
- [1] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [2] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [3] Moats, R., "URN Syntax", RFC 2141, May 1997.
-
- [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
- RFC 2234, November 1997.
-
- [6] Daniel, R., "A Trivial Convention for using HTTP in URN
- Resolution", RFC 2169, June 1997.
-
- [7] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
- Identifiers using the Domain Name System", RFC 2168, June 1997.
-
- [8] IEEE, "IEEE Standard for Information Technology - Portable
- Operating System Interface (POSIX) - Part 2: Shell and Utilities
- (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
-
- [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396, August
- 1998.
-
-
-
-
-
-
-
-Mealling & Daniel Standards Track [Page 16]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
-Authors' Addresses
-
- Michael Mealling
- Network Solutions, Inc.
- 505 Huntmar Park Drive
- Herndon, VA 22070
- US
-
- Phone: +1 770 921 2251
- EMail: michaelm@netsol.com
- URI: http://www.netsol.com
-
-
- Ron Daniel
- DATAFUSION, Inc.
- 139 Townsend Street, Ste. 100
- San Francisco, CA 94107
- US
-
- Phone: +1 415 222 0100
- EMail: rdaniel@datafusion.net
- URI: http://www.datafusion.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mealling & Daniel Standards Track [Page 17]
-
-RFC 2915 NAPTR DNS RR September 2000
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mealling & Daniel Standards Track [Page 18]
-
diff --git a/contrib/bind9/doc/rfc/rfc2929.txt b/contrib/bind9/doc/rfc/rfc2929.txt
deleted file mode 100644
index f055968935b8a..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2929.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake, 3rd
-Request for Comments: 2929 Motorola
-BCP: 42 E. Brunner-Williams
-Category: Best Current Practice Engage
- B. Manning
- ISI
- September 2000
-
- Domain Name System (DNS) IANA Considerations
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- Internet Assigned Number Authority (IANA) parameter assignment
- considerations are given for the allocation of Domain Name System
- (DNS) classes, Resource Record (RR) types, operation codes, error
- codes, etc.
-
-Table of Contents
-
- 1. Introduction................................................. 2
- 2. DNS Query/Response Headers................................... 2
- 2.1 One Spare Bit?.............................................. 3
- 2.2 Opcode Assignment........................................... 3
- 2.3 RCODE Assignment............................................ 4
- 3. DNS Resource Records......................................... 5
- 3.1 RR TYPE IANA Considerations................................. 6
- 3.1.1 Special Note on the OPT RR................................ 7
- 3.2 RR CLASS IANA Considerations................................ 7
- 3.3 RR NAME Considerations...................................... 8
- 4. Security Considerations...................................... 9
- References...................................................... 9
- Authors' Addresses.............................................. 11
- Full Copyright Statement........................................ 12
-
-
-
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 1]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
-1. Introduction
-
- The Domain Name System (DNS) provides replicated distributed secure
- hierarchical databases which hierarchically store "resource records"
- (RRs) under domain names.
-
- This data is structured into CLASSes and zones which can be
- independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
- familiarity with which is assumed.
-
- This document covers, 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.
-
- IANA currently maintains a web page of DNS parameters. See
- <http://www.iana.org/numbers.htm>.
-
- "IETF Standards Action", "IETF Consensus", "Specification Required",
- and "Private Use" are as defined in [RFC 2434].
-
-2. DNS Query/Response Headers
-
- The header for DNS queries and responses contains field/bits in the
- following diagram taken from [RFC 2136, 2535]:
-
- 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.
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 2]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
- The QR bit indicates whether the header is for a query or a response.
-
- 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
-
- New OpCode assignments require an IETF Standards Action.
-
- Currently DNS OpCodes are assigned as follows:
-
- OpCode Name Reference
-
- 0 Query [RFC 1035]
- 1 IQuery (Inverse Query) [RFC 1035]
- 2 Status [RFC 1035]
- 3 available for assignment
- 4 Notify [RFC 1996]
- 5 Update [RFC 2136]
- 6-15 available for assignment
-
-
-
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 3]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
-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 [RFC 2930]
- 20 BADNAME Duplicate key name [RFC 2930]
- 21 BADALG Algorithm not supported [RFC 2930]
- 22-3840 available for assignment
- 0x0016-0x0F00
- 3841-4095 Private Use
- 0x0F01-0x0FFF
- 4096-65535 available for assignment
- 0x1000-0xFFFF
-
- Since it is important that RCODEs be understood for interoperability,
- assignment of new RCODE listed above as "available for assignment"
- requires an IETF Consensus.
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 4]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
-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
- octets of the RDATA field.
-
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 5]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
- 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 IETF Consensus.
-
- 128 - 255
- 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
- Meta TYPEs by IETF Consensus.
-
- 256 - 32767
- 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
- Consensus.
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 6]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
- 32768 - 65279
- 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
- 65280 - 65535
- 0xFF00 - 0xFFFF - Private Use.
-
-3.1.1 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, 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.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 although 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.
-
- 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 - 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].
-
-
-
-Eastlake, et al. Best Current Practice [Page 7]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
- 5 - 127
- 0x0005 - 0x007F - available for assignment by IETF Consensus as data
- CLASSes only.
-
- 128 - 253
- 0x0080 - 0x00FD - available for assignment by IETF Consensus as
- QCLASSes only.
-
- 254
- 0x00FE - QCLASS None [RFC 2136].
-
- 255
- 0x00FF - QCLASS Any [RFC 1035].
-
- 256 - 32767
- 0x0100 - 0x7FFF - assigned by IETF Consensus.
-
- 32768 - 65280
- 0x8000 - 0xFEFF - assigned based on Specification Required as defined
- in [RFC 2434].
-
- 65280 - 65534
- 0xFF00 - 0xFFFE - Private Use.
-
- 65535
- 0xFFFF - can only be assigned by an IETF Standards Action.
-
-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 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.
- Binary labels are bit sequences [RFC 2673].
-
- IANA considerations for label types are given in [RFC 2671].
-
-
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 8]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
- 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 dated description of name allocation in the IN Class is
- given in [RFC 1591]. Some information on reserved top level domain
- names is in Best Current Practice 32 [RFC 2606].
-
-4. Security Considerations
-
- This document addresses IANA considerations in the allocation of
- general DNS parameters, not security. See [RFC 2535] for secure DNS
- considerations.
-
-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 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 1591] Postel, J., "Domain Name System Structure and
- Delegation", RFC 1591, March 1994.
-
- [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.
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 9]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
- [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
- Names", RFC 2606, June 1999.
-
- [RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
- 2672, 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.
-
- [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [US-ASCII] ANSI, "USA Standard Code for Information Interchange",
- X3.4, American National Standards Institute: New York,
- 1968.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 10]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
-Authors' Addresses
-
- Donald E. Eastlake 3rd
- Motorola
- 140 Forest Avenue
- Hudson, MA 01749 USA
-
- Phone: +1-978-562-2827 (h)
- +1-508-261-5434 (w)
- Fax: +1-508-261-4447 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
- Eric Brunner-Williams
- Engage
- 100 Brickstone Square, 2nd Floor
- Andover, MA 01810
-
- Phone: +1-207-797-0525 (h)
- +1-978-684-7796 (w)
- Fax: +1-978-684-3118
- EMail: brunner@engage.com
-
-
- Bill Manning
- USC/ISI
- 4676 Admiralty Way, #1001
- Marina del Rey, CA 90292 USA
-
- Phone: +1-310-822-1511
- EMail: bmanning@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 11]
-
-RFC 2929 DNS IANA Considerations September 2000
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al. Best Current Practice [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2930.txt b/contrib/bind9/doc/rfc/rfc2930.txt
deleted file mode 100644
index f99573dd1cdfa..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2930.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake, 3rd
-Request for Comments: 2930 Motorola
-Category: Standards Track September 2000
-
-
- Secret Key Establishment for DNS (TKEY RR)
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- [RFC 2845] provides a means of authenticating Domain Name System
- (DNS) queries and responses using shared secret keys via the
- Transaction Signature (TSIG) resource record (RR). However, it
- provides no mechanism for setting up such keys other than manual
- exchange. This document describes a Transaction Key (TKEY) RR that
- can be used in a number of different modes to establish shared secret
- keys between a DNS resolver and server.
-
-Acknowledgments
-
- The comments and ideas of the following persons (listed in alphabetic
- order) have been incorporated herein and are gratefully acknowledged:
-
- Olafur Gudmundsson (TIS)
-
- Stuart Kwan (Microsoft)
-
- Ed Lewis (TIS)
-
- Erik Nordmark (SUN)
-
- Brian Wellington (Nominum)
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 1]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
-Table of Contents
-
- 1. Introduction............................................... 2
- 1.1 Overview of Contents...................................... 3
- 2. The TKEY Resource Record................................... 4
- 2.1 The Name Field............................................ 4
- 2.2 The TTL Field............................................. 5
- 2.3 The Algorithm Field....................................... 5
- 2.4 The Inception and Expiration Fields....................... 5
- 2.5 The Mode Field............................................ 5
- 2.6 The Error Field........................................... 6
- 2.7 The Key Size and Data Fields.............................. 6
- 2.8 The Other Size and Data Fields............................ 6
- 3. General TKEY Considerations................................ 7
- 4. Exchange via Resolver Query................................ 8
- 4.1 Query for Diffie-Hellman Exchanged Keying................. 8
- 4.2 Query for TKEY Deletion................................... 9
- 4.3 Query for GSS-API Establishment........................... 10
- 4.4 Query for Server Assigned Keying.......................... 10
- 4.5 Query for Resolver Assigned Keying........................ 11
- 5. Spontaneous Server Inclusion............................... 12
- 5.1 Spontaneous Server Key Deletion........................... 12
- 6. Methods of Encryption...................................... 12
- 7. IANA Considerations........................................ 13
- 8. Security Considerations.................................... 13
- References.................................................... 14
- Author's Address.............................................. 15
- Full Copyright Statement...................................... 16
-
-1. Introduction
-
- The Domain Name System (DNS) is a hierarchical, distributed, highly
- available database used for bi-directional mapping between domain
- names and addresses, for email routing, and for other information
- [RFC 1034, 1035]. It has been extended to provide for public key
- security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
- these RFCs is assumed.
-
- [RFC 2845] provides a means of efficiently authenticating DNS
- messages using shared secret keys via the TSIG resource record (RR)
- but provides no mechanism for setting up such keys other than manual
- exchange. This document specifies a TKEY RR that can be used in a
- number of different modes to establish and delete such shared secret
- keys between a DNS resolver and server.
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 2]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
- Note that TKEY established keying material and TSIGs that use it are
- associated with DNS servers or resolvers. They are not associated
- with zones. They may be used to authenticate queries and responses
- but they do not provide zone based DNS data origin or denial
- authentication [RFC 2535].
-
- Certain modes of TKEY perform encryption which may affect their
- export or import status for some countries. The affected modes
- specified in this document are the server assigned mode and the
- resolver assigned mode.
-
- 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].
-
- In all cases herein, the term "resolver" includes that part of a
- server which may make full and incremental [RFC 1995] zone transfer
- queries, forwards recursive queries, etc.
-
-1.1 Overview of Contents
-
- Section 2 below specifies the TKEY RR and provides a description of
- and considerations for its constituent fields.
-
- Section 3 describes general principles of operations with TKEY.
-
- Section 4 discusses key agreement and deletion via DNS requests with
- the Query opcode for RR type TKEY. This method is applicable to all
- currently defined TKEY modes, although in some cases it is not what
- would intuitively be called a "query".
-
- Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
- servers which is currently used only for key deletion.
-
- Section 6 describes encryption methods for transmitting secret key
- information. In this document these are used only for the server
- assigned mode and the resolver assigned mode.
-
- Section 7 covers IANA considerations in assignment of TKEY modes.
-
- Finally, Section 8 provides the required security considerations
- section.
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 3]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
-2. The TKEY Resource Record
-
- The TKEY resource record (RR) has the structure given below. Its RR
- type code is 249.
-
- Field Type Comment
- ----- ---- -------
-
- NAME domain see description below
- TTYPE u_int16_t TKEY = 249
- CLASS u_int16_t ignored, SHOULD be 255 (ANY)
- TTL u_int32_t ignored, SHOULD be zero
- RDLEN u_int16_t size of RDATA
- RDATA:
- Algorithm: domain
- Inception: u_int32_t
- Expiration: u_int32_t
- Mode: u_int16_t
- Error: u_int16_t
- Key Size: u_int16_t
- Key Data: octet-stream
- Other Size: u_int16_t
- Other Data: octet-stream undefined by this specification
-
-2.1 The Name Field
-
- The Name field relates to naming keys. Its meaning differs somewhat
- with mode and context as explained in subsequent sections.
-
- At any DNS server or resolver only one octet string of keying
- material may be in place for any particular key name. An attempt to
- establish another set of keying material at a server for an existing
- name returns a BADNAME error.
-
- For a TKEY with a non-root name appearing in a query, the TKEY RR
- name SHOULD be a domain locally unique at the resolver, less than 128
- octets long in wire encoding, and meaningful to the resolver to
- assist in distinguishing keys and/or key agreement sessions. For
- TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
- be a globally unique server assigned domain.
-
- A reasonable key naming strategy is as follows:
-
- If the key is generated as the result of a query with root as its
- owner name, then the server SHOULD create a globally unique domain
- name, to be the key name, by suffixing a pseudo-random [RFC 1750]
- label with a domain name of the server. For example
- 89n3mDgX072pp.server1.example.com. If generation of a new
-
-
-
-Eastlake Standards Track [Page 4]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
- pseudo-random name in each case is an excessive computation load
- or entropy drain, a serial number prefix can be added to a fixed
- pseudo-random name generated an DNS server start time, such as
- 1001.89n3mDgX072pp.server1.example.com.
-
- If the key is generated as the result of a query with a non-root
- name, say 789.resolver.example.net, then use the concatenation of
- that with a name of the server. For example
- 789.resolver.example.net.server1.example.com.
-
-2.2 The TTL Field
-
- The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
- be sure that older DNS implementations do not cache TKEY RRs.
-
-2.3 The Algorithm Field
-
- The algorithm name is in the form of a domain name with the same
- meaning as in [RFC 2845]. The algorithm determines how the secret
- keying material agreed to using the TKEY RR is actually used to
- derive the algorithm specific key.
-
-2.4 The Inception and Expiration Fields
-
- The inception time and expiration times are in number of seconds
- since the beginning of 1 January 1970 GMT ignoring leap seconds
- treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
- between a DNS resolver and a DNS server where these fields are
- meaningful, they are either the requested validity interval for the
- keying material asked for or specify the validity interval of keying
- material provided.
-
- To avoid different interpretations of the inception and expiration
- times in TKEY RRs, resolvers and servers exchanging them must have
- the same idea of what time it is. One way of doing this is with the
- NTP protocol [RFC 2030] but that or any other time synchronization
- used for this purpose MUST be done securely.
-
-2.5 The Mode Field
-
- The mode field specifies the general scheme for key agreement or the
- purpose of the TKEY DNS message. Servers and resolvers supporting
- this specification MUST implement the Diffie-Hellman key agreement
- mode and the key deletion mode for queries. All other modes are
- OPTIONAL. A server supporting TKEY that receives a TKEY request with
- a mode it does not support returns the BADMODE error. The following
- values of the Mode octet are defined, available, or reserved:
-
-
-
-
-Eastlake Standards Track [Page 5]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
- Value Description
- ----- -----------
- 0 - reserved, see section 7
- 1 server assignment
- 2 Diffie-Hellman exchange
- 3 GSS-API negotiation
- 4 resolver assignment
- 5 key deletion
- 6-65534 - available, see section 7
- 65535 - reserved, see section 7
-
-2.6 The Error Field
-
- The error code field is an extended RCODE. The following values are
- defined:
-
- Value Description
- ----- -----------
- 0 - no error
- 1-15 a non-extended RCODE
- 16 BADSIG (TSIG)
- 17 BADKEY (TSIG)
- 18 BADTIME (TSIG)
- 19 BADMODE
- 20 BADNAME
- 21 BADALG
-
- When the TKEY Error Field is non-zero in a response to a TKEY query,
- the DNS header RCODE field indicates no error. However, it is
- possible if a TKEY is spontaneously included in a response the TKEY
- RR and DNS header error field could have unrelated non-zero error
- codes.
-
-2.7 The Key Size and Data Fields
-
- The key data size field is an unsigned 16 bit integer in network
- order which specifies the size of the key exchange data field in
- octets. The meaning of this data depends on the mode.
-
-2.8 The Other Size and Data Fields
-
- The Other Size and Other Data fields are not used in this
- specification but may be used in future extensions. The RDLEN field
- MUST equal the length of the RDATA section through the end of Other
- Data or the RR is to be considered malformed and rejected.
-
-
-
-
-
-
-Eastlake Standards Track [Page 6]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
-3. General TKEY Considerations
-
- TKEY is a meta-RR that is not stored or cached in the DNS and does
- not appear in zone files. It supports a variety of modes for the
- establishment and deletion of shared secret keys information between
- DNS resolvers and servers. The establishment of such a shared key
- requires that state be maintained at both ends and the allocation of
- the resources to maintain such state may require mutual agreement. In
- the absence of willingness to provide such state, servers MUST return
- errors such as NOTIMP or REFUSED for an attempt to use TKEY and
- resolvers are free to ignore any TKEY RRs they receive.
-
- The shared secret keying material developed by using TKEY is a plain
- octet sequence. The means by which this shared secret keying
- material, exchanged via TKEY, is actually used in any particular TSIG
- algorithm is algorithm dependent and is defined in connection with
- that algorithm. For example, see [RFC 2104] for how TKEY agreed
- shared secret keying material is used in the HMAC-MD5 algorithm or
- other HMAC algorithms.
-
- There MUST NOT be more than one TKEY RR in a DNS query or response.
-
- Except for GSS-API mode, TKEY responses MUST always have DNS
- transaction authentication to protect the integrity of any keying
- data, error codes, etc. This authentication MUST use a previously
- established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
- NOT use any key that the response to be verified is itself providing.
-
- TKEY queries MUST be authenticated for all modes except GSS-API and,
- under some circumstances, server assignment mode. In particular, if
- the query for a server assigned key is for a key to assert some
- privilege, such as update authority, then the query must be
- authenticated to avoid spoofing. However, if the key is just to be
- used for transaction security, then spoofing will lead at worst to
- denial of service. Query authentication SHOULD use an established
- secret (TSIG) key authenticator if available. Otherwise, it must use
- a public (SIG(0)) key signature. It MUST NOT use any key that the
- query is itself providing.
-
- In the absence of required TKEY authentication, a NOTAUTH error MUST
- be returned.
-
- To avoid replay attacks, it is necessary that a TKEY response or
- query not be valid if replayed on the order of 2**32 second (about
- 136 years), or a multiple thereof, later. To accomplish this, the
- keying material used in any TSIG or SIG(0) RR that authenticates a
- TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
-
-
-
-
-Eastlake Standards Track [Page 7]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
- (about 68 years). Thus, on attempted replay, the authenticating TSIG
- or SIG(0) RR will not be verifiable due to key expiration and the
- replay will fail.
-
-4. Exchange via Resolver Query
-
- One method for a resolver and a server to agree about shared secret
- keying material for use in TSIG is through DNS requests from the
- resolver which are syntactically DNS queries for type TKEY. Such
- queries MUST be accompanied by a TKEY RR in the additional
- information section to indicate the mode in use and accompanied by
- other information where required.
-
- Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
- ignore the recursive header bit in TKEY queries they receive.
-
-4.1 Query for Diffie-Hellman Exchanged Keying
-
- Diffie-Hellman (DH) key exchange is a means whereby two parties can
- derive some shared secret information without requiring any secrecy
- of the messages they exchange [Schneier]. Provisions have been made
- for the storage of DH public keys in the DNS [RFC 2539].
-
- A resolver sends a query for type TKEY accompanied by a TKEY RR in
- the additional information section specifying the Diffie-Hellman mode
- and accompanied by a KEY RR also in the additional information
- section specifying a resolver Diffie-Hellman key. The TKEY RR
- algorithm field is set to the authentication algorithm the resolver
- plans to use. The "key data" provided in the TKEY is used as a random
- [RFC 1750] nonce to avoid always deriving the same keying material
- for the same pair of DH KEYs.
-
- The server response contains a TKEY in its answer section with the
- Diffie-Hellman mode. The "key data" provided in this TKEY is used as
- an additional nonce to avoid always deriving the same keying material
- for the same pair of DH KEYs. If the TKEY error field is non-zero,
- the query failed for the reason given. FORMERR is given if the query
- included no DH KEY and BADKEY is given if the query included an
- incompatible DH KEY.
-
- If the TKEY error field is zero, the resolver supplied Diffie-Hellman
- KEY RR SHOULD be echoed in the additional information section and a
- server Diffie-Hellman KEY RR will also be present in the answer
- section of the response. Both parties can then calculate the same
- shared secret quantity from the pair of Diffie-Hellman (DH) keys used
- [Schneier] (provided these DH keys use the same generator and
- modulus) and the data in the TKEY RRs. The TKEY RR data is mixed
- with the DH result as follows:
-
-
-
-Eastlake Standards Track [Page 8]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
- keying material =
- XOR ( DH value, MD5 ( query data | DH value ) |
- MD5 ( server data | DH value ) )
-
- Where XOR is an exclusive-OR operation and "|" is byte-stream
- concatenation. The shorter of the two operands to XOR is byte-wise
- left justified and padded with zero-valued bytes to match the length
- of the other operand. "DH value" is the Diffie-Hellman value derived
- from the KEY RRs. Query data and server data are the values sent in
- the TKEY RR data fields. These "query data" and "server data" nonces
- are suffixed by the DH value, digested by MD5, the results
- concatenated, and then XORed with the DH value.
-
- The inception and expiry times in the query TKEY RR are those
- requested for the keying material. The inception and expiry times in
- the response TKEY RR are the maximum period the server will consider
- the keying material valid. Servers may pre-expire keys so this is
- not a guarantee.
-
-4.2 Query for TKEY Deletion
-
- Keys established via TKEY can be treated as soft state. Since DNS
- transactions are originated by the resolver, the resolver can simply
- toss keys, although it may have to go through another key exchange if
- it later needs one. Similarly, the server can discard keys although
- that will result in an error on receiving a query with a TSIG using
- the discarded key.
-
- To avoid attempted reliance in requests on keys no longer in effect,
- servers MUST implement key deletion whereby the server "discards" a
- key on receipt from a resolver of an authenticated delete request for
- a TKEY RR with the key's name. If the server has no record of a key
- with that name, it returns BADNAME.
-
- Key deletion TKEY queries MUST be authenticated. This authentication
- MAY be a TSIG RR using the key to be deleted.
-
- For querier assigned and Diffie-Hellman keys, the server MUST truly
- "discard" all active state associated with the key. For server
- assigned keys, the server MAY simply mark the key as no longer
- retained by the client and may re-send it in response to a future
- query for server assigned keying material.
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 9]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
-4.3 Query for GSS-API Establishment
-
- This mode is described in a separate document under preparation which
- should be seen for the full description. Basically the resolver and
- server can exchange queries and responses for type TKEY with a TKEY
- RR specifying the GSS-API mode in the additional information section
- and a GSS-API token in the key data portion of the TKEY RR.
-
- Any issues of possible encryption of parts the GSS-API token data
- being transmitted are handled by the GSS-API level. In addition, the
- GSS-API level provides its own authentication so that this mode of
- TKEY query and response MAY be, but do not need to be, authenticated
- with TSIG RR or SIG(0) RR [RFC 2931].
-
- The inception and expiry times in a GSS-API mode TKEY RR are ignored.
-
-4.4 Query for Server Assigned Keying
-
- Optionally, the server can assign keying for the resolver. It is
- sent to the resolver encrypted under a resolver public key. See
- section 6 for description of encryption methods.
-
- A resolver sends a query for type TKEY accompanied by a TKEY RR
- specifying the "server assignment" mode and a resolver KEY RR to be
- used in encrypting the response, both in the additional information
- section. The TKEY algorithm field is set to the authentication
- algorithm the resolver plans to use. It is RECOMMENDED that any "key
- data" provided in the query TKEY RR by the resolver be strongly mixed
- by the server with server generated randomness [RFC 1750] to derive
- the keying material to be used. The KEY RR that appears in the query
- need not be accompanied by a SIG(KEY) RR. If the query is
- authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
- and that authentication is verified, then any SIG(KEY) provided in
- the query SHOULD be ignored. The KEY RR in such a query SHOULD have
- a name that corresponds to the resolver but it is only essential that
- it be a public key for which the resolver has the corresponding
- private key so it can decrypt the response data.
-
- The server response contains a TKEY RR in its answer section with the
- server assigned mode and echoes the KEY RR provided in the query in
- its additional information section.
-
- If the response TKEY error field is zero, the key data portion of the
- response TKEY RR will be the server assigned keying data encrypted
- under the public key in the resolver provided KEY RR. In this case,
- the owner name of the answer TKEY RR will be the server assigned name
- of the key.
-
-
-
-
-Eastlake Standards Track [Page 10]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
- If the error field of the response TKEY is non-zero, the query failed
- for the reason given. FORMERR is given if the query specified no
- encryption key.
-
- The inception and expiry times in the query TKEY RR are those
- requested for the keying material. The inception and expiry times in
- the response TKEY are the maximum period the server will consider the
- keying material valid. Servers may pre-expire keys so this is not a
- guarantee.
-
- The resolver KEY RR MUST be authenticated, through the authentication
- of this query with a TSIG or SIG(0) or the signing of the resolver
- KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY
- for which they know the private key, and thereby the attacker could
- obtain a valid shared secret key from the server.
-
-4.5 Query for Resolver Assigned Keying
-
- Optionally, a server can accept resolver assigned keys. The keying
- material MUST be encrypted under a server key for protection in
- transmission as described in Section 6.
-
- The resolver sends a TKEY query with a TKEY RR that specifies the
- encrypted keying material and a KEY RR specifying the server public
- key used to encrypt the data, both in the additional information
- section. The name of the key and the keying data are completely
- controlled by the sending resolver so a globally unique key name
- SHOULD be used. The KEY RR used MUST be one for which the server has
- the corresponding private key, or it will not be able to decrypt the
- keying material and will return a FORMERR. It is also important that
- no untrusted party (preferably no other party than the server) has
- the private key corresponding to the KEY RR because, if they do, they
- can capture the messages to the server, learn the shared secret, and
- spoof valid TSIGs.
-
- The query TKEY RR inception and expiry give the time period the
- querier intends to consider the keying material valid. The server
- can return a lesser time interval to advise that it will not maintain
- state for that long and can pre-expire keys in any case.
-
- This mode of query MUST be authenticated with a TSIG or SIG(0).
- Otherwise, an attacker can forge a resolver assigned TKEY query, and
- thereby the attacker could specify a shared secret key that would be
- accepted, used, and honored by the server.
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 11]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
-5. Spontaneous Server Inclusion
-
- A DNS server may include a TKEY RR spontaneously as additional
- information in responses. This SHOULD only be done if the server
- knows the querier understands TKEY and has this option implemented.
- This technique can be used to delete a key and may be specified for
- modes defined in the future. A disadvantage of this technique is
- that there is no way for the server to get any error or success
- indication back and, in the case of UDP, no way to even know if the
- DNS response reached the resolver.
-
-5.1 Spontaneous Server Key Deletion
-
- A server can optionally tell a client that it has deleted a secret
- key by spontaneously including a TKEY RR in the additional
- information section of a response with the key's name and specifying
- the key deletion mode. Such a response SHOULD be authenticated. If
- authenticated, it "deletes" the key with the given name. The
- inception and expiry times of the delete TKEY RR are ignored. Failure
- by a client to receive or properly process such additional
- information in a response would mean that the client might use a key
- that the server had discarded and would then get an error indication.
-
- For server assigned and Diffie-Hellman keys, the client MUST
- "discard" active state associated with the key. For querier assigned
- keys, the querier MAY simply mark the key as no longer retained by
- the server and may re-send it in a future query specifying querier
- assigned keying material.
-
-6. Methods of Encryption
-
- For the server assigned and resolver assigned key agreement modes,
- the keying material is sent within the key data field of a TKEY RR
- encrypted under the public key in an accompanying KEY RR [RFC 2535].
- This KEY RR MUST be for a public key algorithm where the public and
- private keys can be used for encryption and the corresponding
- decryption which recovers the originally encrypted data. The KEY RR
- SHOULD correspond to a name for the decrypting resolver/server such
- that the decrypting process has access to the corresponding private
- key to decrypt the data. The secret keying material being sent will
- generally be fairly short, usually less than 256 bits, because that
- is adequate for very strong protection with modern keyed hash or
- symmetric algorithms.
-
- If the KEY RR specifies the RSA algorithm, then the keying material
- is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
- PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is
- directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
-
-
-
-Eastlake Standards Track [Page 12]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
- some other symmetric algorithm.) In the unlikely event that the
- keying material will not fit within one RSA modulus of the chosen
- public key, additional RSA encryption blocks are included. The
- length of each block is clear from the public RSA key specified and
- the RSAES-PKCS1-v1_5 padding makes it clear what part of the
- encrypted data is actually keying material and what part is
- formatting or the required at least eight bytes of random [RFC 1750]
- padding.
-
-7. IANA Considerations
-
- This section is to be interpreted as provided in [RFC 2434].
-
- Mode field values 0x0000 and 0xFFFF are reserved.
-
- Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
- can only be assigned by an IETF Standards Action.
-
- Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
- are allocated by IESG approval or IETF consensus.
-
- Mode field values 0x1000 through 0xEFFF are allocated based on
- Specification Required as defined in [RFC 2434].
-
- Mode values should not be changed when the status of their use
- changes. For example, a mode value assigned based just on providing
- a specification should not be changed later just because that use's
- status is changed to standards track.
-
- The following assignments are documented herein:
-
- RR Type 249 for TKEY.
-
- TKEY Modes 1 through 5 as listed in section 2.5.
-
- Extended RCODE Error values of 19, 20, and 21 as listed in section
- 2.6.
-
-8. Security Considerations
-
- The entirety of this specification is concerned with the secure
- establishment of a shared secret between DNS clients and servers in
- support of TSIG [RFC 2845].
-
- Protection against denial of service via the use of TKEY is not
- provided.
-
-
-
-
-
-Eastlake Standards Track [Page 13]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
-References
-
- [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", 1996, John Wiley and
- Sons
-
- [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 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
- [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
- September 1996.
-
- [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-
- [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
- for IPv4, IPv6 and OSI", RFC 2030, October 1996.
-
- [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 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
- Specifications Version 2.0", RFC 2437, October 1998.
-
- [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
- Domain Name System (DNS)", RFC 2539, March 1999.
-
-
-
-
-Eastlake Standards Track [Page 14]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
- [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s )", RFC 2931, September 2000.
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola
- 140 Forest Avenue
- Hudson, MA 01749 USA
-
- Phone: +1 978-562-2827 (h)
- +1 508-261-5434 (w)
- Fax: +1 508-261-4447 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 15]
-
-RFC 2930 The DNS TKEY RR September 2000
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 16]
-
diff --git a/contrib/bind9/doc/rfc/rfc2931.txt b/contrib/bind9/doc/rfc/rfc2931.txt
deleted file mode 100644
index 84cc97e2d26e9..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2931.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake 3rd
-Request for Comments: 2931 Motorola
-Updates: 2535 September 2000
-Category: Standards Track
-
-
- DNS Request and Transaction Signatures ( SIG(0)s )
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- Extensions to the Domain Name System (DNS) are described in [RFC
- 2535] that can provide data origin and transaction integrity and
- authentication to security aware resolvers and applications through
- the use of cryptographic digital signatures.
-
- Implementation experience has indicated the need for minor but non-
- interoperable changes in Request and Transaction signature resource
- records ( SIG(0)s ). These changes are documented herein.
-
-Acknowledgments
-
- The contributions and suggestions of the following persons (in
- alphabetic order) to this memo are gratefully acknowledged:
-
- Olafur Gudmundsson
-
- Ed Lewis
-
- Erik Nordmark
-
- Brian Wellington
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 1]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
-Table of Contents
-
- 1. Introduction................................................. 2
- 2. SIG(0) Design Rationale...................................... 3
- 2.1 Transaction Authentication.................................. 3
- 2.2 Request Authentication...................................... 3
- 2.3 Keying...................................................... 3
- 2.4 Differences Between TSIG and SIG(0)......................... 4
- 3. The SIG(0) Resource Record................................... 4
- 3.1 Calculating Request and Transaction SIGs.................... 5
- 3.2 Processing Responses and SIG(0) RRs......................... 6
- 3.3 SIG(0) Lifetime and Expiration.............................. 7
- 4. Security Considerations...................................... 7
- 5. IANA Considerations.......................................... 7
- References...................................................... 7
- Author's Address................................................ 8
- Appendix: SIG(0) Changes from RFC 2535.......................... 9
- Full Copyright Statement........................................ 10
-
-1. Introduction
-
- This document makes minor but non-interoperable changes to part of
- [RFC 2535], familiarity with which is assumed, and includes
- additional explanatory text. These changes concern SIG Resource
- Records (RRs) that are used to digitally sign DNS requests and
- transactions / responses. Such a resource record, because it has a
- type covered field of zero, is frequently called a SIG(0). The
- changes are based on implementation and attempted implementation
- experience with TSIG [RFC 2845] and the [RFC 2535] specification for
- SIG(0).
-
- Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
- and 4.3. No changes are made herein related to the KEY or NXT RRs or
- to the processing involved with data origin and denial authentication
- for DNS data.
-
- 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].
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 2]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
-2. SIG(0) Design Rationale
-
- SIG(0) provides protection for DNS transactions and requests that is
- not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
- 2535]. The authenticated data origin services of secure DNS either
- provide protected data resource records (RRs) or authenticatably deny
- their nonexistence. These services provide no protection for glue
- records, DNS requests, no protection for message headers on requests
- or responses, and no protection of the overall integrity of a
- response.
-
-2.1 Transaction Authentication
-
- Transaction authentication means that a requester can be sure it is
- at least getting the messages from the server it queried and that the
- received messages are in response to the query it sent. This is
- accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
- described herein, a SIG(0) resource record at the end of the response
- which digitally signs the concatenation of the server's response and
- the corresponding resolver query.
-
-2.2 Request Authentication
-
- Requests can also be authenticated by including a TSIG or, as
- described herein, a special SIG(0) RR at the end of the request.
- Authenticating requests serves no function in DNS servers that
- predate the specification of dynamic update. Requests with a non-
- empty additional information section produce error returns or may
- even be ignored by a few such older DNS servers. However, this syntax
- for signing requests is defined for authenticating dynamic update
- requests [RFC 2136], TKEY requests [RFC 2930], or future requests
- requiring authentication.
-
-2.3 Keying
-
- The private keys used in transaction security belong to the host
- composing the DNS response message, not to the zone involved.
- Request authentication may also involve the private key of the host
- or other entity composing the request or of a zone to be affected by
- the request or other private keys depending on the request authority
- it is sought to establish. The corresponding public key(s) are
- normally stored in and retrieved from the DNS for verification as KEY
- RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
-
- Because requests and replies are highly variable, message
- authentication SIGs can not be pre-calculated. Thus it will be
- necessary to keep the private key on-line, for example in software or
- in a directly connected piece of hardware.
-
-
-
-Eastlake Standards Track [Page 3]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
-2.4 Differences Between TSIG and SIG(0)
-
- There are significant differences between TSIG and SIG(0).
-
- Because TSIG involves secret keys installed at both the requester and
- server the presence of such a key implies that the other party
- understands TSIG and very likely has the same key installed.
- Furthermore, TSIG uses keyed hash authentication codes which are
- relatively inexpensive to compute. Thus it is common to authenticate
- requests with TSIG and responses are authenticated with TSIG if the
- corresponding request is authenticated.
-
- SIG(0) on the other hand, uses public key authentication, where the
- public keys are stored in DNS as KEY RRs and a private key is stored
- at the signer. Existence of such a KEY RR does not necessarily imply
- implementation of SIG(0). In addition, SIG(0) involves relatively
- expensive public key cryptographic operations that should be
- minimized and the verification of a SIG(0) involves obtaining and
- verifying the corresponding KEY which can be an expensive and lengthy
- operation. Indeed, a policy of using SIG(0) on all requests and
- verifying it before responding would, for some configurations, lead
- to a deadly embrace with the attempt to obtain and verify the KEY
- needed to authenticate the request SIG(0) resulting in additional
- requests accompanied by a SIG(0) leading to further requests
- accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not
- required on requests halves the number of public key operations
- required by the transaction.
-
- For these reasons, SIG(0)s SHOULD only be used on requests when
- necessary to authenticate that the requester has some required
- privilege or identity. SIG(0)s on replies are defined in such a way
- as to not require a SIG(0) on the corresponding request and still
- provide transaction protection. For other replies, whether they are
- authenticated by the server or required to be authenticated by the
- requester SHOULD be a local configuration option.
-
-3. The SIG(0) Resource Record
-
- The structure of and type number of SIG resource records (RRs) is
- given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and
- the parts of Sections 4.2 and 4.3 related to SIG(0) should be
- considered replaced by the material below. Any conflict between [RFC
- 2535] and this document concerning SIG(0) RRs should be resolved in
- favor of this document.
-
- For all transaction SIG(0)s, the signer field MUST be a name of the
- originating host and there MUST be a KEY RR at that name with the
- public key corresponding to the private key used to calculate the
-
-
-
-Eastlake Standards Track [Page 4]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
- signature. (The host domain name used may be the inverse IP address
- mapping name for an IP address of the host if the relevant KEY is
- stored there.)
-
- For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
- meaningless. The TTL fields SHOULD be zero and the CLASS field
- SHOULD be ANY. To conserve space, the owner name SHOULD be root (a
- single zero octet). When SIG(0) authentication on a response is
- desired, that SIG RR MUST be considered the highest priority of any
- additional information for inclusion in the response. If the SIG(0)
- RR cannot be added without causing the message to be truncated, the
- server MUST alter the response so that a SIG(0) can be included.
- This response consists of only the question and a SIG(0) record, and
- has the TC bit set and RCODE 0 (NOERROR). The client should at this
- point retry the request using TCP.
-
-3.1 Calculating Request and Transaction SIGs
-
- A DNS request may be optionally signed by including one SIG(0)s at
- the end of the query additional information section. Such a SIG is
- identified by having a "type covered" field of zero. It signs the
- preceding DNS request message including DNS header but not including
- the UDP/IP header and before the request RR counts have been adjusted
- for the inclusions of the request SIG(0).
-
- It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
- (1) the SIG's RDATA section entirely omitting (not just zeroing) the
- signature subfield itself, (2) the DNS query messages, including DNS
- header, but not the UDP/IP header and before the reply RR counts have
- been adjusted for the inclusion of the SIG(0). That is
-
- data = RDATA | request - SIG(0)
-
- where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
- calculated less the signature itself.
-
- Similarly, a SIG(0) can be used to secure a response and the request
- that produced it. Such transaction signatures are calculated by
- using a "data" of (1) the SIG's RDATA section omitting the signature
- itself, (2) the entire DNS query message that produced this response,
- including the query's DNS header but not its UDP/IP header, and (3)
- the entire DNS response message, including DNS header but not the
- UDP/IP header and before the response RR counts have been adjusted
- for the inclusion of the SIG(0).
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 5]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
- That is
-
- data = RDATA | full query | response - SIG(0)
-
- where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
- calculated less the signature itself.
-
- Verification of a response SIG(0) (which is signed by the server host
- key, not the zone key) by the requesting resolver shows that the
- query and response were not tampered with in transit, that the
- response corresponds to the intended query, and that the response
- comes from the queried server.
-
- In the case of a DNS message via TCP, a SIG(0) on the first data
- packet is calculated with "data" as above and for each subsequent
- packet, it is calculated as follows:
-
- data = RDATA | DNS payload - SIG(0) | previous packet
-
- where "|" is concatenations, RDATA is as above, and previous packet
- is the previous DNS payload including DNS header and the SIG(0) but
- not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
- alternative, TSIG may be used after, if necessary, setting up a key
- with TKEY [RFC 2930].
-
- Except where needed to authenticate an update, TKEY, or similar
- privileged request, servers are not required to check a request
- SIG(0).
-
- Note: requests and responses can either have a single TSIG or one
- SIG(0) but not both a TSIG and a SIG(0).
-
-3.2 Processing Responses and SIG(0) RRs
-
- If a SIG RR is at the end of the additional information section of a
- response and has a type covered of zero, it is a transaction
- signature covering the response and the query that produced the
- response. For TKEY responses, it MUST be checked and the message
- rejected if the checks fail unless otherwise specified for the TKEY
- mode in use. For all other responses, it MAY be checked and the
- message rejected if the checks fail.
-
- If a response's SIG(0) check succeed, such a transaction
- authentication SIG does NOT directly authenticate the validity any
- data-RRs in the message. However, it authenticates that they were
- sent by the queried server and have not been diddled. (Only a proper
- SIG(0) RR signed by the zone or a key tracing its authority to the
- zone or to static resolver configuration can directly authenticate
-
-
-
-Eastlake Standards Track [Page 6]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
- data-RRs, depending on resolver policy.) If a resolver or server does
- not implement transaction and/or request SIGs, it MUST ignore them
- without error where they are optional and treat them as failing where
- they are required.
-
-3.3 SIG(0) Lifetime and Expiration
-
- The inception and expiration times in SIG(0)s are for the purpose of
- resisting replay attacks. They should be set to form a time bracket
- such that messages outside that bracket can be ignored. In IP
- networks, this time bracket should not normally extend further than 5
- minutes into the past and 5 minutes into the future.
-
-4. Security Considerations
-
- No additional considerations beyond those in [RFC 2535].
-
- The inclusion of the SIG(0) inception and expiration time under the
- signature improves resistance to replay attacks.
-
-5. IANA Considerations
-
- No new parameters are created or parameter values assigned by this
- document.
-
-References
-
- [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
- September 1996.
-
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [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 2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
- Wellington, "Secret Key Transaction Signatures for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
- 2930, September 2000.
-
-
-
-
-
-Eastlake Standards Track [Page 7]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola
- 140 Forest Avenue
- Hudson, MA 01749 USA
-
- Phone: +1-978-562-2827(h)
- +1-508-261-5434(w)
- Fax: +1 978-567-7941(h)
- +1-508-261-4447(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 8]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
-Appendix: SIG(0) Changes from RFC 2535
-
- Add explanatory text concerning the differences between TSIG and
- SIG(0).
-
- Change the data over which SIG(0) is calculated to include the SIG(0)
- RDATA other than the signature itself so as to secure the signature
- inception and expiration times and resist replay attacks. Specify
- SIG(0) for TCP.
-
- Add discussion of appropriate inception and expiration times for
- SIG(0).
-
- Add wording to indicate that either a TSIG or one or more SIG(0)s may
- be present but not both.
-
- Reword some areas for clarity.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 9]
-
-RFC 2931 DNS SIG(0) September 2000
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake Standards Track [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3007.txt b/contrib/bind9/doc/rfc/rfc3007.txt
deleted file mode 100644
index 1697475355d3a..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3007.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group B. Wellington
-Request for Comments: 3007 Nominum
-Updates: 2535, 2136 November 2000
-Obsoletes: 2137
-Category: Standards Track
-
-
- Secure Domain Name System (DNS) Dynamic Update
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- This document proposes a method for performing secure Domain Name
- System (DNS) dynamic updates. The method described here is intended
- to be flexible and useful while requiring as few changes to the
- protocol as possible. The authentication of the dynamic update
- message is separate from later DNSSEC validation of the data. Secure
- communication based on authenticated requests and transactions is
- used to provide authorization.
-
- 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 - Introduction
-
- This document defines a means to secure dynamic updates of the Domain
- Name System (DNS), allowing only authorized sources to make changes
- to a zone's contents. The existing unsecured dynamic update
- operations form the basis for this work.
-
- Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
- [RFC2136] is helpful and is assumed by this document. In addition,
- knowledge of DNS security extensions [RFC2535], SIG(0) transaction
- security [RFC2535, RFC2931], and TSIG transaction security [RFC2845]
- is recommended.
-
-
-
-
-Wellington Standards Track [Page 1]
-
-RFC 3007 Secure Dynamic Update November 2000
-
-
- This document updates portions of RFC 2535, in particular section
- 3.1.2, and RFC 2136. This document obsoletes RFC 2137, an alternate
- proposal for secure dynamic update, due to implementation experience.
-
-1.1 - Overview of DNS Dynamic Update
-
- DNS dynamic update defines a new DNS opcode and a new interpretation
- of the DNS message if that opcode is used. An update can specify
- insertions or deletions of data, along with prerequisites necessary
- for the updates to occur. All tests and changes for a DNS update
- request are restricted to a single zone, and are performed at the
- primary server for the zone. The primary server for a dynamic zone
- must increment the zone SOA serial number when an update occurs or
- before the next retrieval of the SOA.
-
-1.2 - Overview of DNS Transaction Security
-
- Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
- [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
- requests and responses sent between them. A TSIG MAC (message
- authentication code) is derived from a shared secret, and a SIG(0) is
- generated from a private key whose public counterpart is stored in
- DNS. In both cases, a record containing the message signature/MAC is
- included as the final resource record in a DNS message. Keyed
- hashes, used in TSIG, are inexpensive to calculate and verify.
- Public key encryption, as used in SIG(0), is more scalable as the
- public keys are stored in DNS.
-
-1.3 - Comparison of data authentication and message authentication
-
- Message based authentication, using TSIG or SIG(0), provides
- protection for the entire message with a single signing and single
- verification which, in the case of TSIG, is a relatively inexpensive
- MAC creation and check. For update requests, this signature can
- establish, based on policy or key negotiation, the authority to make
- the request.
-
- DNSSEC SIG records can be used to protect the integrity of individual
- RRs or RRsets in a DNS message with the authority of the zone owner.
- However, this cannot sufficiently protect the dynamic update request.
-
- Using SIG records to secure RRsets in an update request is
- incompatible with the design of update, as described below, and would
- in any case require multiple expensive public key signatures and
- verifications.
-
-
-
-
-
-
-Wellington Standards Track [Page 2]
-
-RFC 3007 Secure Dynamic Update November 2000
-
-
- SIG records do not cover the message header, which includes record
- counts. Therefore, it is possible to maliciously insert or remove
- RRsets in an update request without causing a verification failure.
-
- If SIG records were used to protect the prerequisite section, it
- would be impossible to determine whether the SIGs themselves were a
- prerequisite or simply used for validation.
-
- In the update section of an update request, signing requests to add
- an RRset is straightforward, and this signature could be permanently
- used to protect the data, as specified in [RFC2535]. However, if an
- RRset is deleted, there is no data for a SIG to cover.
-
-1.4 - Data and message signatures
-
- As specified in [RFC3008], the DNSSEC validation process performed by
- a resolver MUST NOT process any non-zone keys unless local policy
- dictates otherwise. When performing secure dynamic update, all zone
- data modified in a signed zone MUST be signed by a relevant zone key.
- This completely disassociates authentication of an update request
- from authentication of the data itself.
-
- The primary usefulness of host and user keys, with respect to DNSSEC,
- is to authenticate messages, including dynamic updates. Thus, host
- and user keys MAY be used to generate SIG(0) records to authenticate
- updates and MAY be used in the TKEY [RFC2930] process to generate
- TSIG shared secrets. In both cases, no SIG records generated by
- non-zone keys will be used in a DNSSEC validation process unless
- local policy dictates.
-
- Authentication of data, once it is present in DNS, only involves
- DNSSEC zone keys and signatures generated by them.
-
-1.5 - Signatory strength
-
- [RFC2535, section 3.1.2] defines the signatory field of a key as the
- final 4 bits of the flags field, but does not define its value. This
- proposal leaves this field undefined. Updating [RFC2535], this field
- SHOULD be set to 0 in KEY records, and MUST be ignored.
-
-2 - Authentication
-
- TSIG or SIG(0) records MUST be included in all secure dynamic update
- messages. This allows the server to verifiably determine the
- originator of a message. If the message contains authentication in
- the form of a SIG(0), the identity of the sender (that is, the
- principal) is the owner of the KEY RR that generated the SIG(0). If
- the message contains a TSIG generated by a statically configured
-
-
-
-Wellington Standards Track [Page 3]
-
-RFC 3007 Secure Dynamic Update November 2000
-
-
- shared secret, the principal is the same as or derived from the
- shared secret name. If the message contains a TSIG generated by a
- dynamically configured shared secret, the principal is the same as
- the one that authenticated the TKEY process; if the TKEY process was
- unauthenticated, no information is known about the principal, and the
- associated TSIG shared secret MUST NOT be used for secure dynamic
- update.
-
- SIG(0) signatures SHOULD NOT be generated by zone keys, since
- transactions are initiated by a host or user, not a zone.
-
- DNSSEC SIG records (other than SIG(0)) MAY be included in an update
- message, but MUST NOT be used to authenticate the update request.
-
- If an update fails because it is signed with an unauthorized key, the
- server MUST indicate failure by returning a message with RCODE
- REFUSED. Other TSIG, SIG(0), or dynamic update errors are returned
- as specified in the appropriate protocol description.
-
-3 - Policy
-
- All policy is configured by the zone administrator and enforced by
- the zone's primary name server. Policy dictates the authorized
- actions that an authenticated principal can take. Policy checks are
- based on the principal and the desired action, where the principal is
- derived from the message signing key and applied to dynamic update
- messages signed with that key.
-
- The server's policy defines criteria which determine if the key used
- to sign the update is permitted to perform the requested updates. By
- default, a principal MUST NOT be permitted to make any changes to
- zone data; any permissions MUST be enabled though configuration.
-
- The policy is fully implemented in the primary zone server's
- configuration for several reasons. This removes limitations imposed
- by encoding policy into a fixed number of bits (such as the KEY RR's
- signatory field). Policy is only relevant in the server applying it,
- so there is no reason to expose it. Finally, a change in policy or a
- new type of policy should not affect the DNS protocol or data format,
- and should not cause interoperability failures.
-
-3.1 - Standard policies
-
- Implementations SHOULD allow access control policies to use the
- principal as an authorization token, and MAY also allow policies to
- grant permission to a signed message regardless of principal.
-
-
-
-
-
-Wellington Standards Track [Page 4]
-
-RFC 3007 Secure Dynamic Update November 2000
-
-
- A common practice would be to restrict the permissions of a principal
- by domain name. That is, a principal could be permitted to add,
- delete, or modify entries corresponding to one or more domain names.
- Implementations SHOULD allow per-name access control, and SHOULD
- provide a concise representation of the principal's own name, its
- subdomains, and all names in the zone.
-
- Additionally, a server SHOULD allow restricting updates by RR type,
- so that a principal could add, delete, or modify specific record
- types at certain names. Implementations SHOULD allow per-type access
- control, and SHOULD provide concise representations of all types and
- all "user" types, where a user type is defined as one that does not
- affect the operation of DNS itself.
-
-3.1.1 - User types
-
- User types include all data types except SOA, NS, SIG, and NXT. SOA
- and NS records SHOULD NOT be modified by normal users, since these
- types create or modify delegation points. The addition of SIG
- records can lead to attacks resulting in additional workload for
- resolvers, and the deletion of SIG records could lead to extra work
- for the server if the zone SIG was deleted. Note that these records
- are not forbidden, but not recommended for normal users.
-
- NXT records MUST NOT be created, modified, or deleted by dynamic
- update, as their update may cause instability in the protocol. This
- is an update to RFC 2136.
-
- Issues concerning updates of KEY records are discussed in the
- Security Considerations section.
-
-3.2 - Additional policies
-
- Users are free to implement any policies. Policies may be as
- specific or general as desired, and as complex as desired. They may
- depend on the principal or any other characteristics of the signed
- message.
-
-4 - Interaction with DNSSEC
-
- Although this protocol does not change the way updates to secure
- zones are processed, there are a number of issues that should be
- clarified.
-
-
-
-
-
-
-
-
-Wellington Standards Track [Page 5]
-
-RFC 3007 Secure Dynamic Update November 2000
-
-
-4.1 - Adding SIGs
-
- An authorized update request MAY include SIG records with each RRset.
- Since SIG records (except SIG(0) records) MUST NOT be used for
- authentication of the update message, they are not required.
-
- If a principal is authorized to update SIG records and there are SIG
- records in the update, the SIG records are added without
- verification. The server MAY examine SIG records and drop SIGs with
- a temporal validity period in the past.
-
-4.2 - Deleting SIGs
-
- If a principal is authorized to update SIG records and the update
- specifies the deletion of SIG records, the server MAY choose to
- override the authority and refuse the update. For example, the
- server may allow all SIG records not generated by a zone key to be
- deleted.
-
-4.3 - Non-explicit updates to SIGs
-
- If the updated zone is secured, the RRset affected by an update
- operation MUST, at the completion of the update, be signed in
- accordance with the zone's signing policy. This will usually require
- one or more SIG records to be generated by one or more zone keys
- whose private components MUST be online [RFC3008].
-
- When the contents of an RRset are updated, the server MAY delete all
- associated SIG records, since they will no longer be valid.
-
-4.4 - Effects on the zone
-
- If any changes are made, the server MUST, if necessary, generate a
- new SOA record and new NXT records, and sign these with the
- appropriate zone keys. Changes to NXT records by secure dynamic
- update are explicitly forbidden. SOA updates are allowed, since the
- maintenance of SOA parameters is outside of the scope of the DNS
- protocol.
-
-5 - Security Considerations
-
- This document requires that a zone key and possibly other
- cryptographic secret material be held in an on-line, network-
- connected host, most likely a name server. This material is at the
- mercy of host security to remain a secret. Exposing this secret puts
- DNS data at risk of masquerade attacks. The data at risk is that in
- both zones served by the machine and delegated from this machine.
-
-
-
-
-Wellington Standards Track [Page 6]
-
-RFC 3007 Secure Dynamic Update November 2000
-
-
- Allowing updates of KEY records may lead to undesirable results,
- since a principal may be allowed to insert a public key without
- holding the private key, and possibly masquerade as the key owner.
-
-6 - Acknowledgements
-
- The author would like to thank the following people for review and
- informative comments (in alphabetical order):
-
- Harald Alvestrand
- Donald Eastlake
- Olafur Gudmundsson
- Andreas Gustafsson
- Bob Halley
- Stuart Kwan
- Ed Lewis
-
-7 - 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.
-
- [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
- "Dynamic Updates in the Domain Name System", RFC 2136,
- April 1997.
-
- [RFC2137] Eastlake, D., "Secure Domain Name System Dynamic Update",
- RFC 2137, April 1997.
-
- [RFC2535] Eastlake, G., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
- Wellington, "Secret Key Transaction Signatures for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
- [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
- Signing Authority", RFC 3008, November 2000.
-
-
-
-
-Wellington Standards Track [Page 7]
-
-RFC 3007 Secure Dynamic Update November 2000
-
-
-8 - Author's Address
-
- Brian Wellington
- Nominum, Inc.
- 950 Charter Street
- Redwood City, CA 94063
-
- Phone: +1 650 381 6022
- EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington Standards Track [Page 8]
-
-RFC 3007 Secure Dynamic Update November 2000
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington Standards Track [Page 9]
-
diff --git a/contrib/bind9/doc/rfc/rfc3008.txt b/contrib/bind9/doc/rfc/rfc3008.txt
deleted file mode 100644
index 08a4a8fabedb9..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3008.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group B. Wellington
-Request for Comments: 3008 Nominum
-Updates: 2535 November 2000
-Category: Standards Track
-
-
- Domain Name System Security (DNSSEC) Signing Authority
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- This document proposes a revised model of Domain Name System Security
- (DNSSEC) Signing Authority. The revised model is designed to clarify
- earlier documents and add additional restrictions to simplify the
- secure resolution process. Specifically, this affects the
- authorization of keys to sign sets of records.
-
- 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 - Introduction
-
- This document defines additional restrictions on DNSSEC signatures
- (SIG) records relating to their authority to sign associated data.
- The intent is to establish a standard policy followed by a secure
- resolver; this policy can be augmented by local rules. This builds
- upon [RFC2535], updating section 2.3.6 of that document.
-
- The most significant change is that in a secure zone, zone data is
- required to be signed by the zone key.
-
- Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
- security extensions [RFC2535] is assumed.
-
-
-
-
-
-
-Wellington Standards Track [Page 1]
-
-RFC 3008 DNSSEC Signing Authority November 2000
-
-
-2 - The SIG Record
-
- A SIG record is normally associated with an RRset, and "covers" (that
- is, demonstrates the authenticity and integrity of) the RRset. This
- is referred to as a "data SIG". Note that there can be multiple SIG
- records covering an RRset, and the same validation process should be
- repeated for each of them. Some data SIGs are considered "material",
- that is, relevant to a DNSSEC capable resolver, and some are
- "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
- validation. Immaterial SIGs may have application defined roles. SIG
- records may exist which are not bound to any RRset; these are also
- considered immaterial. The validation process determines which SIGs
- are material; once a SIG is shown to be immaterial, no other
- validation is necessary.
-
- SIGs may also be used for transaction security. In this case, a SIG
- record with a type covered field of 0 is attached to a message, and
- is used to protect message integrity. This is referred to as a
- SIG(0) [RFC2535, RFC2931].
-
- The following sections define requirements for all of the fields of a
- SIG record. These requirements MUST be met in order for a DNSSEC
- capable resolver to process this signature. If any of these
- requirements are not met, the SIG cannot be further processed.
- Additionally, once a KEY has been identified as having generated this
- SIG, there are requirements that it MUST meet.
-
-2.1 - Type Covered
-
- For a data SIG, the type covered MUST be the same as the type of data
- in the associated RRset. For a SIG(0), the type covered MUST be 0.
-
-2.2 - Algorithm Number
-
- The algorithm specified in a SIG MUST be recognized by the client,
- and it MUST be an algorithm that has a defined SIG rdata format.
-
-2.3 - Labels
-
- The labels count MUST be less than or equal to the number of labels
- in the SIG owner name, as specified in [RFC2535, section 4.1.3].
-
-2.4 - Original TTL
-
- The original TTL MUST be greater than or equal to the TTL of the SIG
- record itself, since the TTL cannot be increased by intermediate
- servers. This field can be ignored for SIG(0) records.
-
-
-
-
-Wellington Standards Track [Page 2]
-
-RFC 3008 DNSSEC Signing Authority November 2000
-
-
-2.5 - Signature Expiration and Inception
-
- The current time at the time of validation MUST lie within the
- validity period bounded by the inception and expiration times.
-
-2.6 - Key Tag
-
- There are no restrictions on the Key Tag field, although it is
- possible that future algorithms will impose constraints.
-
-2.7 - Signer's Name
-
- The signer's name field of a data SIG MUST contain the name of the
- zone to which the data and signature belong. The combination of
- signer's name, key tag, and algorithm MUST identify a zone key if the
- SIG is to be considered material. The only exception that the
- signer's name field in a SIG KEY at a zone apex SHOULD contain the
- parent zone's name, unless the KEY set is self-signed. This document
- defines a standard policy for DNSSEC validation; local policy may
- override the standard policy.
-
- There are no restrictions on the signer field of a SIG(0) record.
- The combination of signer's name, key tag, and algorithm MUST
- identify a key if this SIG(0) is to be processed.
-
-2.8 - Signature
-
- There are no restrictions on the signature field. The signature will
- be verified at some point, but does not need to be examined prior to
- verification unless a future algorithm imposes constraints.
-
-3 - The Signing KEY Record
-
- Once a signature has been examined and its fields validated (but
- before the signature has been verified), the resolver attempts to
- locate a KEY that matches the signer name, key tag, and algorithm
- fields in the SIG. If one is not found, the SIG cannot be verified
- and is considered immaterial. If KEYs are found, several fields of
- the KEY record MUST have specific values if the SIG is to be
- considered material and authorized. If there are multiple KEYs, the
- following checks are performed on all of them, as there is no way to
- determine which one generated the signature until the verification is
- performed.
-
-
-
-
-
-
-
-
-Wellington Standards Track [Page 3]
-
-RFC 3008 DNSSEC Signing Authority November 2000
-
-
-3.1 - Type Flags
-
- The signing KEY record MUST have a flags value of 00 or 01
- (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
- A DNSSEC resolver MUST only trust signatures generated by keys that
- are permitted to authenticate data.
-
-3.2 - Name Flags
-
- The interpretation of this field is considerably different for data
- SIGs and SIG(0) records.
-
-3.2.1 - Data SIG
-
- If the SIG record covers an RRset, the name type of the associated
- KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535,
- section 2.3.6. The DNSSEC validation process performed by a resolver
- MUST ignore all keys that are not zone keys unless local policy
- dictates otherwise.
-
- The primary reason that RFC 2535 allows host and user keys to
- generate material DNSSEC signatures is to allow dynamic update
- without online zone keys; that is, avoid storing private keys in an
- online server. The desire to avoid online signing keys cannot be
- achieved, though, because they are necessary to sign NXT and SOA sets
- [RFC3007]. These online zone keys can sign any incoming data.
- Removing the goal of having no online keys removes the reason to
- allow host and user keys to generate material signatures.
-
- Limiting material signatures to zone keys simplifies the validation
- process. The length of the verification chain is bounded by the
- name's label depth. The authority of a key is clearly defined; a
- resolver does not need to make a potentially complicated decision to
- determine whether a key has the proper authority to sign data.
-
- Finally, there is no additional flexibility granted by allowing
- host/user key generated material signatures. As long as users and
- hosts have the ability to authenticate update requests to the primary
- zone server, signatures by zone keys are sufficient to protect the
- integrity of the data to the world at large.
-
-3.2.2 - SIG(0)
-
- If the SIG record is a SIG(0) protecting a message, the name type of
- the associated KEY SHOULD be 00 (user) or 10 (host/entity).
- Transactions are initiated by a host or user, not a zone, so zone
- keys SHOULD not generate SIG(0) records.
-
-
-
-
-Wellington Standards Track [Page 4]
-
-RFC 3008 DNSSEC Signing Authority November 2000
-
-
- A client is either explicitly executed by a user or on behalf of a
- host, therefore the name type of a SIG(0) generated by a client
- SHOULD be either user or host. A nameserver is associated with a
- host, and its use of SIG(0) is not associated with a particular zone,
- so the name type of a SIG(0) generated by a nameserver SHOULD be
- host.
-
-3.3 - Signatory Flags
-
- This document does not assign any values to the signatory field, nor
- require any values to be present.
-
-3.4 - Protocol
-
- The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
- 255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC
- resolver MUST NOT trust any signature that it generates.
-
-3.5 - Algorithm Number
-
- The algorithm field MUST be identical to that of the generated SIG
- record, and MUST meet all requirements for an algorithm value in a
- SIG record.
-
-4 - Security Considerations
-
- This document defines a standard baseline for a DNSSEC capable
- resolver. This is necessary for a thorough security analysis of
- DNSSEC, if one is to be done.
-
- Specifically, this document places additional restrictions on SIG
- records that a resolver must validate before the signature can be
- considered worthy of DNSSEC trust. This simplifies the protocol,
- making it more robust and able to withstand scrutiny by the security
- community.
-
-5 - Acknowledgements
-
- The author would like to thank the following people for review and
- informative comments (in alphabetical order):
-
- Olafur Gudmundsson
- Ed Lewis
-
-
-
-
-
-
-
-
-Wellington Standards Track [Page 5]
-
-RFC 3008 DNSSEC Signing Authority November 2000
-
-
-6 - 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 (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
- "Dynamic Updates in the Domain Name System", RFC 2136,
- April 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s )", RFC 2931, September 2000.
-
- [RFC3007] Wellington, B., "Simple Secure Domain Name System
- (DNS) Dynamic Update", RFC 3007, November 2000.
-
-7 - Author's Address
-
- Brian Wellington
- Nominum, Inc.
- 950 Charter Street
- Redwood City, CA 94063
-
- Phone: +1 650 381 6022
- EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington Standards Track [Page 6]
-
-RFC 3008 DNSSEC Signing Authority November 2000
-
-
-8 Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington Standards Track [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3071.txt b/contrib/bind9/doc/rfc/rfc3071.txt
deleted file mode 100644
index 2c4d52fc11419..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3071.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Klensin
-Request for Comments: 3071 February 2001
-Category: Informational
-
-
- Reflections on the DNS, RFC 1591, and Categories of Domains
-
-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 (2001). All Rights Reserved.
-
-Abstract
-
- RFC 1591, "Domain Name System Structure and Delegation", laid out the
- basic administrative design and principles for the allocation and
- administration of domains, from the top level down. It was written
- before the introduction of the world wide web (WWW) and rapid growth
- of the Internet put significant market, social, and political
- pressure on domain name allocations. In recent years, 1591 has been
- cited by all sides in various debates, and attempts have been made by
- various bodies to update it or adjust its provisions, sometimes under
- pressures that have arguably produced policies that are less well
- thought out than the original. Some of those efforts have begun from
- misconceptions about the provisions of 1591 or the motivation for
- those provisions. The current directions of the Internet Corporation
- for Assigned Names and Numbers (ICANN) and other groups who now
- determine the Domain Name System (DNS) policy directions appear to be
- drifting away from the policies and philosophy of 1591. This
- document is being published primarily for historical context and
- comparative purposes, essentially to document some thoughts about how
- 1591 might have been interpreted and adjusted by the Internet
- Assigned Numbers Authority (IANA) and ICANN to better reflect today's
- world while retaining characteristics and policies that have proven
- to be effective in supporting Internet growth and stability. An
- earlier variation of this memo was submitted to ICANN as a comment on
- its evolving Top-level Domain (TLD) policies.
-
-
-
-
-
-
-
-
-
-Klensin Informational [Page 1]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
-1. Introduction
-
- RFC 1591 [1] has been heavily discussed and referenced in the last
- year or two, especially in discussions within ICANN and its
- predecessors about the creation, delegation, and management of top-
- level domains. In particular, the ICANN Domain Name Supporting
- Organization (DNSO), and especially its ccTLD constituency, have been
- the home of many discussions in which 1591 and interpretations of it
- have been cited in support of a variety of sometimes-contradictory
- positions. During that period, other discussions have gone on to try
- to reconstruct the thinking that went into RFC 1591. Those in turn
- have led me and others to muse on how that original thinking might
- relate to some of the issues being raised. 1591 is, I believe, one
- of Jon Postel's masterpieces, drawing together very different
- philosophies (e.g., his traditional view that people are basically
- reasonable and will do the right thing if told what it is with some
- stronger mechanisms when that model is not successful) into a single
- whole.
-
- RFC 1591 was written in the context of the assumption that what it
- described as generic TLDs would be bound to policies and categories
- of registration (see the "This domain is intended..." text in
- section 2) while ccTLDs were expected to be used primarily to support
- users and uses within and for a country and its residents. The
- notion that different domains would be run in different ways --albeit
- within the broad contexts of "public service on behalf of the
- Internet community" and "trustee... for the global Internet
- community"-- was considered a design feature and a safeguard against
- a variety of potential abuses. Obviously the world has changed in
- many ways in the seven or eight years since 1591 was written. In
- particular, the Internet has become more heavily used and, because
- the design of the world wide web has put domain names in front of
- users, top-level domain names and registrations in them have been
- heavily in demand: not only has the number of hosts increased
- dramatically during that time, but the ratio between registered
- domain names and physical hosts has increased very significantly.
-
- The issues 1591 attempted to address when it was written and those we
- face today have not changed significantly in principle. But one
- alternative to present trends would be to take a step back to refine
- it into a model that can function effectively today. Therefore, it
- may be useful to try to reconstruct 1591's principles and think about
- their applicability today as a model that could continue to be
- applied: not because it is historically significant, but because many
- of its elements have proven to work reasonably well, even in
- difficult situations. In particular, for many domains (some in
- 1591's "generic" list and others in its "country code" category) the
- notion of "public service" --expected then to imply being carried out
-
-
-
-Klensin Informational [Page 2]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
- at no or minimal cost to the users, not merely on a non-profit
- basis-- has yielded to profitability calculations. And, in most of
- the rest, considerations of at least calculating and recovering costs
- have crept in. While many of us feel some nostalgia for the old
- system, it is clear that its days are waning if not gone: perhaps the
- public service notions as understood when 1591 was written just don't
- scale to rapid internet growth and very large numbers of
- yregistrations.
-
- In particular, some ccTLDs have advertised for registrations outside
- the designated countries (or other entities), while others have made
- clear decisions to allow registrations by non-nationals. These
- decisions and others have produced protests from many sides,
- suggesting, in turn, that a recategorization is in order. For
- example, we have heard concerns by governments and managers of
- traditional, "public service", in-country, ccTLDs about excessive
- ICANN interference and fears of being forced to conform to
- internationally-set policies for dispute resolution when their
- domestic ones are considered more appropriate. We have also heard
- concerns from registrars and operators of externally-marketed ccTLDs
- about unreasonable government interference and from gTLD registrars
- and registries about unreasonable competition from aggressively
- marketed ccTLDs. The appropriate distinction is no longer between
- what RFC 1591 described as "generic" TLDs (but which were really
- intended to be "purpose-specific", a term I will use again below) and
- ccTLDs but among:
-
- (i) true "generic" TLDs, in which any registration is acceptable
- and, ordinarily, registrations from all sources are actively
- promoted. This list currently includes (the formerly purpose-
- specific) COM, NET, and ORG, and some ccTLDs. There have been
- proposals from time to time for additional TLDs of this variety in
- which, as with COM (and, more recently, NET and ORG) anyone
- (generally subject only to name conflicts and national law) could
- register who could pay the fees.
-
- (ii) purpose-specific TLDs, in which registration is accepted only
- from organizations or individuals meeting particular
- qualifications, but where those qualifications are not tied to
- national boundaries. This list currently includes INT, EDU, the
- infrastructure domain ARPA, and, arguably, the specialized US
- Government TLDs MIL and GOV. There have been proposals from time
- to time for other international TLDs of this variety, e.g., for
- medical entities such as physicians and hospitals and for museums.
- ICANN has recently approved several TLDs of this type and
- describes them as "sponsored" TLDs.
-
-
-
-
-
-Klensin Informational [Page 3]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
- (iii) Country domains, operated according to the original
- underlying assumptions of 1591, i.e., registrants are largely
- expected to be people or other entities within the country. While
- external registrations might be accepted by some of these, the
- country does not aggressively advertise for such registrations,
- nor does anyone expect to derive significant fee revenue from
- them. All current domains in this category are ccTLDs, but not
- all ccTLDs are in this category.
-
- These categories are clearly orthogonal to the association between
- the use of the IS 3166-1 registered code list [2] and two-letter
- "country" domain names. If that relationship is to be maintained
- (and I believe it is desirable), the only inherent requirement is
- that no two-letter TLDs be created except from that list (in order to
- avoid future conflicts). ICANN should control the allocation and
- delegation of TLDs using these, and other, criteria, but only
- registered 3166-1 two letter codes should be used as two-letter TLDs.
-
-2. Implications of the Categories
-
- If we had adopted this type of three-way categorization and could
- make it work, I believe it would have presented several opportunities
- for ICANN and the community more generally to reduce controversies
- and move forward. Of course, there will be cases where the
- categorization of a particular domain and its operating style will
- not be completely clear-cut (see section 3, below). But having ICANN
- work out procedures for dealing with those (probably few) situations
- appears preferable to strategies that would tend to propel ICANN into
- areas that are beyond its competence or that might require
- significant expansion of its mandate.
-
- First, the internally-operated ccTLDs (category iii above) should not
- be required to have much interaction with ICANN or vice versa. Once
- a domain of this sort is established and delegated, and assuming that
- the "admin contact in the country" rule is strictly observed, the
- domain should be able to function effectively without ICANN
- intervention or oversight. In particular, while a country might
- choose to adopt the general ICANN policies about dispute resolution
- or name management, issues that arise in these areas might equally
- well be dealt with exclusively under applicable national laws. If a
- domain chooses to use ICANN services that cost resources to provide,
- it should contribute to ICANN's support, but, if it does not, ICANN
- should not presume to charge it for other than a reasonable fraction
- of the costs to ICANN of operating the root, root servers, and any
- directory systems that are generally agreed upon to be necessary and
- in which the domain participates.
-
-
-
-
-
-Klensin Informational [Page 4]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
- By contrast, ccTLDs operated as generic domains ought to be treated
- as generic domains. ICANN dispute resolution and name management
- policies and any special rules developed to protect the Internet
- public in multiple registrar or registry situations should reasonably
- apply.
-
-3. Telling TLD types apart
-
- If appropriate policies are adopted, ccTLDs operated as generic
- domains (category (i) above) and those operated as country domains
- (category (iii) above) ought to be able to be self-identified. There
- are several criteria that could be applied to make this
- determination. For example, either a domain is aggressively seeking
- outside registrations or it is not and either the vast majority of
- registrants in a domain are in-country or they are not. One could
- also think of this as the issue of having some tangible level of
- presence in the jurisdiction - e.g., is the administrative contact
- subject, in practical terms, to the in-country laws, or are the
- registration rules such that it is reasonably likely that a court in
- the jurisdiction of the country associated with the domain can
- exercise jurisdiction and enforce a judgment against the registrant.
-
- One (fairly non-intrusive) rule ICANN might well impose on all top-
- level domains is that they identify and publish the policies they
- intend to use. E.g., registrants in a domain that will use the laws
- of one particular country to resolve disputes should have a
- reasonable opportunity to understand those policies prior to
- registration and to make other arrangements (e.g., to register
- elsewhere) if that mechanism for dispute resolution is not
- acceptable. Giving IANA (as the root registrar) incorrect
- information about the purpose and use of a domain should be subject
- to challenge, and should be grounds for reviewing the appropriateness
- of the domain delegation, just as not acting consistently and
- equitably provides such grounds under the original provisions of RFC
- 1591.
-
- In order to ensure the availability of accurate and up-to-date
- registration information the criteria must be consistent, and
- consistent with more traditional gTLDs, for all nominally country
- code domains operating as generic TLDs.
-
-4. The role of ICANN in country domains
-
- ICANN (and IANA) should, as described above, have as little
- involvement as possible in the direction of true country [code]
- domains (i.e., category (iii)). There is no particular reason why
-
-
-
-
-
-Klensin Informational [Page 5]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
- these domains should be subject to ICANN regulation beyond the basic
- principles of 1591 and associated arrangements needed to ensure
- Internet interoperability and stability.
-
- ICANN's avoiding such involvement strengthens it: the desirability of
- avoiding collisions with national sovereignty, determinations about
- government legitimacy, and the authority of someone purportedly
- writing on behalf of a government, is as important today as it was
- when 1591 was written. The alternatives take us quickly from
- "administration" into "internet governance" or, in the case of
- determining which claimant is the legitimate government of a country,
- "international relations", and the reasons for not moving in that
- particular direction are legion.
-
-5. The role of governments
-
- The history of IANA strategy in handling ccTLDs included three major
- "things to avoid" considerations:
-
- * Never get involved in determining which entities were countries
- and which ones were not.
-
- * Never get involved in determining who was, or was not, the
- legitimate government of a country. And, more generally, avoid
- deciding what entity --government, religion, commercial,
- academic, etc.-- has what legitimacy or rights.
-
- * If possible, never become involved in in-country disputes.
- Instead, very strongly encourage internal parties to work
- problems out among themselves. At most, adopt a role as
- mediator and educator, rather than judge, unless abuses are very
- clear and clearly will not be settled by any internal mechanism.
-
- All three considerations were obviously intended to avoid IANA's
- being dragged into a political morass in which it had (and, I
- suggest, has) no competence to resolve the issues and could only get
- bogged down. The first consideration was the most visible (and the
- easiest) and was implemented by strict and careful adherence (see
- below) to the ISO 3166 registered Country Code list. If an entity
- had a code, it was eligible to be registered with a TLD (although
- IANA was free to apply additional criteria-most of them stated in
- 1591). If it did not, there were no exceptions: the applicant's only
- recourse was a discussion with the 3166 Registration Authority (now
- Maintenance Agency, often known just as "3166/MA") or the UN
- Statistical Office (now Statistics Bureau), not with IANA.
-
-
-
-
-
-
-Klensin Informational [Page 6]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
- There are actually five ccTLD exceptions to the strict rules. One,
- "UK", is historical: it predates the adoption of ISO 3166 for this
- purpose. The others --Ascension Island, Guernsey, Isle of Man, and
- Jersey --are arguably, at least in retrospect, just mistakes.
- Regardless of the historical reasons (about which there has been much
- speculation), it is almost certainly the case that the right way to
- handle mistakes of this sort is to acknowledge them and move on,
- rather than trying to use them as precedents to justify more
- mistakes.
-
- This, obviously, is also the argument against use of the "reserved"
- list (technically internal to the 3166 maintenance activity, and not
- part of the Standard): since IANA (or ICANN) can ask that a name be
- placed on that list, there is no rule of an absolute determination by
- an external organization. Purported countries can come to ICANN,
- insist on having delegations made and persuade ICANN to ask that the
- names be reserved. Then, since the reserved name would exist, they
- could insist that the domain be delegated. Worse, someone could use
- another organization to request reservation of the name by 3166/MA;
- once it was reserved, ICANN might be hard-pressed not to do the
- delegation. Of course, ICANN could (and probably would be forced to)
- adopt additional criteria other than appearance on the "reserved
- list" in order to delegate such domains. But those criteria would
- almost certainly be nearly equivalent to determining which applicants
- were legitimate and stable enough to be considered a country, the
- exact decision process that 1591 strove to avoid.
-
- The other two considerations were more subtle and not always
- successful: from time to time, both before and after the formal
- policy shifted toward "governments could have their way", IANA
- received letters from people purporting to be competent government
- authorities asking for changes. Some of them turned out later to not
- have that authority or appropriate qualifications. The assumption of
- 1591 itself was that, if the "administrative contact in country" rule
- was strictly observed, as was the rule that delegation changes
- requested by the administrative contact would be honored, then, if a
- government _really_ wanted to assert itself, it could pressure the
- administrative contact into requesting the changes it wanted, using
- whatever would pass for due process in that country. And the ability
- to apply that process and pressure would effectively determine who
- was the government and who wasn't, and would do so far more
- effectively than any IANA evaluation of, e.g., whether the letterhead
- on a request looked authentic (and far more safely for ICANN than
- asking the opinion of any particular other government or selection of
- governments).
-
-
-
-
-
-
-Klensin Informational [Page 7]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
- Specific language in 1591 permitted IANA to adopt a "work it out
- yourselves; if we have to decide, we will strive for a solution that
- is not satisfactory to any party" stance. That approach was used
- successfully, along with large doses of education, on many occasions
- over the years, to avoid IANA's having to assume the role of judge
- between conflicting parties.
-
- Similar principles could be applied to the boundary between country-
- code-based generic TLDs and country domains. Different countries,
- under different circumstances, might prefer to operate the ccTLD
- either as a national service or as a profit center where the
- "customers" were largely external. Whatever decisions were made
- historically, general Internet stability argues that changes should
- not be made lightly. At the same time, if a government wishes to
- make a change, the best mechanism for doing so is not to involve
- ICANN in a potential determination of legitimacy (or even to have
- ICANN's Government Advisory Committee (GAC) try to formally make that
- decision for individual countries) but for the relevant government to
- use its own procedures to persuade the administrative contact to
- request the change and for IANA to promptly and efficiently carry out
- requests made by administrative contacts.
-
-6. Implications for the current ICANN DNSO structure.
-
- The arguments by some of the ccTLD administrators that they are
- different from the rest of the ICANN and DNSO structures are (in this
- model) correct: they are different. The ccTLDs that are operating as
- generic TLDs should be separated from the ccTLD constituency and
- joined to the gTLD constituency. The country ccTLDs should be
- separated from ICANN's immediate Supporting Organization structure,
- and operate in a parallel and advisory capacity to ICANN, similar to
- the arrangements used with the GAC. The DNSO and country TLDs should
- not be required to interact with each other except on a mutually
- voluntary basis and, if ICANN needs interaction or advice from some
- of all of those TLDs, it would be more appropriate to get it in the
- form of an advisory body like the GAC rather than as DNSO
- constituency.
-
-7. References
-
- [1] Postel, J., "Domain Name System Structure and Delegation", RFC
- 1591, March 1994.
-
- [2] ISO 3166. ISO 3166-1. Codes for the representation of names of
- countries and their subdivisions - Part 1: Country codes (1997).
-
-
-
-
-
-
-Klensin Informational [Page 8]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
-8. Acknowledgements and disclaimer
-
- These reflections have been prepared in my individual capacity and do
- not necessarily reflect the views of my past or present employers.
- Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
- Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
- suggestions or offered editorial comments about earlier versions of
- this document. Cord Wischhoefer, of the ISO 3166/MA, was also kind
- enough to look at the draft and supplied some useful details. Those
- comments contributed significantly to whatever clarity the document
- has, but the author bears responsibility for the selection of
- comments which were ultimately incorporated and the way in which the
- conclusions were presented.
-
-9. Security Considerations
-
- This memo addresses the context for a set of administrative decisions
- and procedures, and does not raise or address security issues.
-
-10. Author's Address
-
- John C. Klensin
- 1770 Massachusetts Ave, Suite 322
- Cambridge, MA 02140, USA
-
- EMail: klensin@jck.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin Informational [Page 9]
-
-RFC 3071 Reflections on the DNS and RFC 1591 February 2001
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society 2001. All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others provided that the above copyright notice and this paragraph
- are included on all such copies. However, this document itself may
- not be modified in any way, such as by removing the copyright notice
- or references to the Internet Society or other Internet
- organizations, except as required to translate it into languages
- other than English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin Informational [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3090.txt b/contrib/bind9/doc/rfc/rfc3090.txt
deleted file mode 100644
index 08008f7a3ddd2..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3090.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group E. Lewis
-Request for Comments: 3090 NAI Labs
-Category: Standards Track March 2001
-
-
- DNS Security Extension Clarification on Zone Status
-
-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 (2001). All Rights Reserved.
-
-Abstract
-
- The definition of a secured zone is presented, clarifying and
- updating sections of RFC 2535. RFC 2535 defines a zone to be secured
- based on a per algorithm basis, e.g., a zone can be secured with RSA
- keys, and not secured with DSA keys. This document changes this to
- define a zone to be secured or not secured regardless of the key
- algorithm used (or not used). To further simplify the determination
- of a zone's status, "experimentally secure" status is deprecated.
-
-1 Introduction
-
- Whether a DNS zone is "secured" or not is a question asked in at
- least four contexts. A zone administrator asks the question when
- configuring a zone to use DNSSEC. A dynamic update server asks the
- question when an update request arrives, which may require DNSSEC
- processing. A delegating zone asks the question of a child zone when
- the parent enters data indicating the status the child. A resolver
- asks the question upon receipt of data belonging to the zone.
-
-1.1 When a Zone's Status is Important
-
- A zone administrator needs to be able to determine what steps are
- needed to make the zone as secure as it can be. Realizing that due
- to the distributed nature of DNS and its administration, any single
- zone is at the mercy of other zones when it comes to the appearance
- of security. This document will define what makes a zone qualify as
- secure.
-
-
-
-
-Lewis Standards Track [Page 1]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
- A name server performing dynamic updates needs to know whether a zone
- being updated is to have signatures added to the updated data, NXT
- records applied, and other required processing. In this case, it is
- conceivable that the name server is configured with the knowledge,
- but being able to determine the status of a zone by examining the
- data is a desirable alternative to configuration parameters.
-
- A delegating zone is required to indicate whether a child zone is
- secured. The reason for this requirement lies in the way in which a
- resolver makes its own determination about a zone (next paragraph).
- To shorten a long story, a parent needs to know whether a child
- should be considered secured. This is a two part question. Under
- what circumstances does a parent consider a child zone to be secure,
- and how does a parent know if the child conforms?
-
- A resolver needs to know if a zone is secured when the resolver is
- processing data from the zone. Ultimately, a resolver needs to know
- whether or not to expect a usable signature covering the data. How
- this determination is done is out of the scope of this document,
- except that, in some cases, the resolver will need to contact the
- parent of the zone to see if the parent states that the child is
- secured.
-
-1.2 Islands of Security
-
- The goal of DNSSEC is to have each zone secured, from the root zone
- and the top-level domains down the hierarchy to the leaf zones.
- Transitioning from an unsecured DNS, as we have now, to a fully
- secured - or "as much as will be secured" - tree will take some time.
- During this time, DNSSEC will be applied in various locations in the
- tree, not necessarily "top down."
-
- For example, at a particular instant, the root zone and the "test."
- TLD might be secured, but region1.test. might not be. (For
- reference, let's assume that region2.test. is secured.) However,
- subarea1.region1.test. may have gone through the process of becoming
- secured, along with its delegations. The dilemma here is that
- subarea1 cannot get its zone keys properly signed as its parent zone,
- region1, is not secured.
-
- The colloquial phrase describing the collection of contiguous secured
- zones at or below subarea1.region1.test. is an "island of security."
- The only way in which a DNSSEC resolver will come to trust any data
- from this island is if the resolver is pre-configured with the zone
- key(s) for subarea1.region1.test., i.e., the root of the island of
- security. Other resolvers (not so configured) will recognize this
- island as unsecured.
-
-
-
-
-Lewis Standards Track [Page 2]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
- An island of security begins with one zone whose public key is pre-
- configured in resolvers. Within this island are subzones which are
- also secured. The "bottom" of the island is defined by delegations
- to unsecured zones. One island may also be on top of another -
- meaning that there is at least one unsecured zone between the bottom
- of the upper island and the root of the lower secured island.
-
- Although both subarea1.region1.test. and region2.test. have both been
- properly brought to a secured state by the administering staff, only
- the latter of the two is actually "globally" secured - in the sense
- that all DNSSEC resolvers can and will verify its data. The former,
- subarea1, will be seen as secured by a subset of those resolvers,
- just those appropriately configured. This document refers to such
- zones as being "locally" secured.
-
- In RFC 2535, there is a provision for "certification authorities,"
- entities that will sign public keys for zones such as subarea1.
- There is another document, [RFC3008], that restricts this activity.
- Regardless of the other document, resolvers would still need proper
- configuration to be able to use the certification authority to verify
- the data for the subarea1 island.
-
-1.2.1 Determining the closest security root
-
- Given a domain, in order to determine whether it is secure or not,
- the first step is to determine the closest security root. The
- closest security root is the top of an island of security whose name
- has the most matching (in order from the root) right-most labels to
- the given domain.
-
- For example, given a name "sub.domain.testing.signed.exp.test.", and
- given the secure roots "exp.test.", "testing.signed.exp.test." and
- "not-the-same.xy.", the middle one is the closest. The first secure
- root shares 2 labels, the middle 4, and the last 0.
-
- The reason why the closest is desired is to eliminate false senses of
- insecurity because of a NULL key. Continuing with the example, the
- reason both "testing..." and "exp.test." are listed as secure root is
- presumably because "signed.exp.test." is unsecured (has a NULL key).
- If we started to descend from "exp.test." to our given domain
- (sub...), we would encounter a NULL key and conclude that sub... was
- unsigned. However, if we descend from "testing..." and find keys
- "domain...." then we can conclude that "sub..." is secured.
-
- Note that this example assumes one-label deep zones, and assumes that
- we do not configure overlapping islands of security. To be clear,
- the definition given should exclude "short.xy.test." from being a
- closest security root for "short.xy." even though 2 labels match.
-
-
-
-Lewis Standards Track [Page 3]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
- Overlapping islands of security introduce no conceptually interesting
- ideas and do not impact the protocol in anyway. However, protocol
- implementers are advised to make sure their code is not thrown for a
- loop by overlaps. Overlaps are sure to be configuration problems as
- islands of security grow to encompass larger regions of the name
- space.
-
-1.3 Parent Statement of Child Security
-
- In 1.1 of this document, there is the comment "the parent states that
- the child is secured." This has caused quite a bit of confusion.
-
- The need to have the parent "state" the status of a child is derived
- from the following observation. If you are looking to see if an
- answer is secured, that it comes from an "island of security" and is
- properly signed, you must begin at the (appropriate) root of the
- island of security.
-
- To find the answer you are inspecting, you may have to descend
- through zones within the island of security. Beginning with the
- trusted root of the island, you descend into the next zone down. As
- you trust the upper zone, you need to get data from it about the next
- zone down, otherwise there is a vulnerable point in which a zone can
- be hijacked. When or if you reach a point of traversing from a
- secured zone to an unsecured zone, you have left the island of
- security and should conclude that the answer is unsecured.
-
- However, in RFC 2535, section 2.3.4, these words seem to conflict
- with the need to have the parent "state" something about a child:
-
- There MUST be a zone KEY RR, signed by its superzone, for every
- subzone if the superzone is secure. This will normally appear in
- the subzone and may also be included in the superzone. But, in
- the case of an unsecured subzone which can not or will not be
- modified to add any security RRs, a KEY declaring the subzone to
- be unsecured MUST appear with the superzone signature in the
- superzone, if the superzone is secure.
-
- The confusion here is that in RFC 2535, a secured parent states that
- a child is secured by SAYING NOTHING ("may also be" as opposed to
- "MUST also be"). This is counter intuitive, the fact that an absence
- of data means something is "secured." This notion, while acceptable
- in a theoretic setting has met with some discomfort in an operation
- setting. However, the use of "silence" to state something does
- indeed work in this case, so there hasn't been sufficient need
- demonstrated to change the definition.
-
-
-
-
-
-Lewis Standards Track [Page 4]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
-1.4 Impact on RFC 2535
-
- This document updates sections of RFC 2535. The definition of a
- secured zone is an update to section 3.4 of the RFC. Section 3.4 is
- updated to eliminate the definition of experimental keys and
- illustrate a way to still achieve the functionality they were
- designed to provide. Section 3.1.3 is updated by the specifying the
- value of the protocol octet in a zone key.
-
-1.5 "MUST" and other key words
-
- The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
- in this document are to be interpreted as described in [RFC 2119].
- Currently, only "MUST" is used in this document.
-
-2 Status of a Zone
-
- In this section, rules governing a zone's DNSSEC status are
- presented. There are three levels of security defined: global,
- local, and unsecured. A zone is globally secure when it complies
- with the strictest set of DNSSEC processing rules. A zone is locally
- secured when it is configured in such a way that only resolvers that
- are appropriately configured see the zone as secured. All other
- zones are unsecured.
-
- Note: there currently is no document completely defining DNSSEC
- verification rules. For the purposes of this document, the strictest
- rules are assumed to state that the verification chain of zone keys
- parallels the delegation tree up to the root zone. (See 2.b below.)
- This is not intended to disallow alternate verification paths, just
- to establish a baseline definition.
-
- To avoid repetition in the rules below, the following terms are
- defined.
-
- 2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01
- for name type (indicating a zone key) and either value 00 or value 01
- for key type (indicating a key permitted to authenticate data). (See
- RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value
- of DNSSEC (3) or ALL (255).
-
- The definition updates RFC 2535's definition of a zone key. The
- requirement that the protocol field be either DNSSEC or ALL is a new
- requirement (a change to section 3.1.3.)
-
- 2.b On-tree Validation - The authorization model in which only the
- parent zone is recognized to supply a DNSSEC-meaningful signature
- that is used by a resolver to build a chain of trust from the child's
-
-
-
-Lewis Standards Track [Page 5]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
- keys to a recognized root of security. The term "on-tree" refers to
- following the DNS domain hierarchy (upwards) to reach a trusted key,
- presumably the root key if no other key is available. The term
- "validation" refers to the digital signature by the parent to prove
- the integrity, authentication and authorization of the child's key to
- sign the child's zone data.
-
- 2.c Off-tree Validation - Any authorization model that permits domain
- names other than the parent's to provide a signature over a child's
- zone keys that will enable a resolver to trust the keys.
-
-2.1 Globally Secured
-
- A globally secured zone, in a nutshell, is a zone that uses only
- mandatory to implement algorithms (RFC 2535, section 3.2) and relies
- on a key certification chain that parallels the delegation tree (on-
- tree validation). Globally secured zones are defined by the
- following rules.
-
- 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at
- least one zone signing KEY RR (2.a) of a mandatory to implement
- algorithm in the set.
-
- 2.1.b. The zone's apex KEY RR set MUST be signed by a private key
- belonging to the parent zone. The private key's public companion
- MUST be a zone signing KEY RR (2.a) of a mandatory to implement
- algorithm and owned by the parent's apex.
-
- If a zone cannot get a conforming signature from the parent zone, the
- child zone cannot be considered globally secured. The only exception
- to this is the root zone, for which there is no parent zone.
-
- 2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies
- RFC 2535, section 2.3.2.) Note: there is some operational discomfort
- with the current NXT record. This requirement is open to
- modification when two things happen. First, an alternate mechanism
- to the NXT is defined and second, a means by which a zone can
- indicate that it is using an alternate method.
-
- 2.1.d. Each RR set that qualifies for zone membership MUST be signed
- by a key that is in the apex's KEY RR set and is a zone signing KEY
- RR (2.a) of a mandatory to implement algorithm. (Updates 2535,
- section 2.3.1.)
-
- Mentioned earlier, the root zone is a special case. The root zone
- will be considered to be globally secured provided that if conforms
- to the rules for locally secured, with the exception that rule 2.1.a.
- be also met (mandatory to implement requirement).
-
-
-
-Lewis Standards Track [Page 6]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
-2.2 Locally Secured
-
- The term "locally" stems from the likely hood that the only resolvers
- to be configured for a particular zone will be resolvers "local" to
- an organization.
-
- A locally secured zone is a zone that complies with rules like those
- for a globally secured zone with the following exceptions. The
- signing keys may be of an algorithm that is not mandatory to
- implement and/or the verification of the zone keys in use may rely on
- a verification chain that is not parallel to the delegation tree
- (off-tree validation).
-
- 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at
- least one zone signing KEY RR (2.a) in the set.
-
- 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
- one of the following two subclauses MUST hold true.
-
- 2.2.b.1 The private key's public companion MUST be pre-configured in
- all the resolvers of interest.
-
- 2.2.b.2 The private key's public companion MUST be a zone signing KEY
- RR (2.a) authorized to provide validation of the zone's apex KEY RR
- set, as recognized by resolvers of interest.
-
- The previous sentence is trying to convey the notion of using a
- trusted third party to provide validation of keys. If the domain
- name owning the validating key is not the parent zone, the domain
- name must represent someone the resolver trusts to provide
- validation.
-
- 2.2.c. NXT records MUST be deployed throughout the zone. Note: see
- the discussion following 2.1.c.
-
- 2.2.d. Each RR set that qualifies for zone membership MUST be signed
- by a key that is in the apex's KEY RR set and is a zone signing KEY
- RR (2.a). (Updates 2535, section 2.3.1.)
-
-2.3 Unsecured
-
- All other zones qualify as unsecured. This includes zones that are
- designed to be experimentally secure, as defined in a later section
- on that topic.
-
-
-
-
-
-
-
-Lewis Standards Track [Page 7]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
-2.4 Wrap up
-
- The designation of globally secured, locally secured, and unsecured
- are merely labels to apply to zones, based on their contents.
- Resolvers, when determining whether a signature is expected or not,
- will only see a zone as secured or unsecured.
-
- Resolvers that follow the most restrictive DNSSEC verification rules
- will only see globally secured zones as secured, and all others as
- unsecured, including zones which are locally secured. Resolvers that
- are not as restrictive, such as those that implement algorithms in
- addition to the mandatory to implement algorithms, will see some
- locally secured zones as secured.
-
- The intent of the labels "global" and "local" is to identify the
- specific attributes of a zone. The words are chosen to assist in the
- writing of a document recommending the actions a zone administrator
- take in making use of the DNS security extensions. The words are
- explicitly not intended to convey a state of compliance with DNS
- security standards.
-
-3 Experimental Status
-
- The purpose of an experimentally secured zone is to facilitate the
- migration from an unsecured zone to a secured zone. This distinction
- is dropped.
-
- The objective of facilitating the migration can be achieved without a
- special designation of an experimentally secure status.
- Experimentally secured is a special case of locally secured. A zone
- administrator can achieve this by publishing a zone with signatures
- and configuring a set of test resolvers with the corresponding public
- keys. Even if the public key is published in a KEY RR, as long as
- there is no parent signature, the resolvers will need some pre-
- configuration to know to process the signatures. This allows a zone
- to be secured with in the sphere of the experiment, yet still be
- registered as unsecured in the general Internet.
-
-4 IANA Considerations
-
- This document does not request any action from an assigned number
- authority nor recommends any actions.
-
-
-
-
-
-
-
-
-
-Lewis Standards Track [Page 8]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
-5 Security Considerations
-
- Without a means to enforce compliance with specified protocols or
- recommended actions, declaring a DNS zone to be "completely" secured
- is impossible. Even if, assuming an omnipotent view of DNS, one can
- declare a zone to be properly configured for security, and all of the
- zones up to the root too, a misbehaving resolver could be duped into
- believing bad data. If a zone and resolver comply, a non-compliant
- or subverted parent could interrupt operations. The best that can be
- hoped for is that all parties are prepared to be judged secure and
- that security incidents can be traced to the cause in short order.
-
-6 Acknowledgements
-
- The need to refine the definition of a secured zone has become
- apparent through the efforts of the participants at two DNSSEC
- workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
- funded research network), and other workshops. Further discussions
- leading to the document include Olafur Gudmundsson, Russ Mundy,
- Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen and
- others have contributed significant input via the namedroppers
- mailing list.
-
-7 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., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
- "Dynamic Updates in the Domain Name System", RFC 2136,
- April 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [RFC3007] Wellington, B., "Simple 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.
-
-
-
-
-
-Lewis Standards Track [Page 9]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
-10 Author's Address
-
- Edward Lewis
- NAI Labs
- 3060 Washington Road Glenwood
- MD 21738
-
- Phone: +1 443 259 2352
- EMail: lewis@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis Standards Track [Page 10]
-
-RFC 3090 DNS Security Extension on Zone Status March 2001
-
-
-11 Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis Standards Track [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3110.txt b/contrib/bind9/doc/rfc/rfc3110.txt
deleted file mode 100644
index 764694860c604..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3110.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Eastlake 3rd
-Request for Comments: 3110 Motorola
-Obsoletes: 2537 May 2001
-Category: Standards Track
-
-
- RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (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 (2001). All Rights Reserved.
-
-Abstract
-
- This document describes how to produce RSA/SHA1 SIG resource records
- (RRs) in Section 3 and, so as to completely replace RFC 2537,
- describes how to produce RSA KEY RRs in Section 2.
-
- Since the adoption of a Proposed Standard for RSA signatures in the
- DNS (Domain Name Space), advances in hashing have been made. A new
- DNS signature algorithm is defined to make these advances available
- in SIG RRs. The use of the previously specified weaker mechanism is
- deprecated. The algorithm number of the RSA KEY RR is changed to
- correspond to this new SIG algorithm. No other changes are made to
- DNS security.
-
-Acknowledgements
-
- Material and comments from the following have been incorporated and
- are gratefully acknowledged:
-
- Olafur Gudmundsson
-
- The IESG
-
- Charlie Kaufman
-
- Steve Wang
-
-
-
-
-
-D. Eastlake 3rd Standards Track [Page 1]
-
-RFC 3110 RSA SIGs and KEYs in the DNS May 2001
-
-
-Table of Contents
-
- 1. Introduction................................................... 2
- 2. RSA Public KEY Resource Records................................ 3
- 3. RSA/SHA1 SIG Resource Records.................................. 3
- 4. Performance Considerations..................................... 4
- 5. IANA Considerations............................................ 5
- 6. Security Considerations........................................ 5
- References........................................................ 5
- Author's Address.................................................. 6
- Full Copyright Statement.......................................... 7
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information [RFC1034, 1035, etc.]. The DNS has been extended
- to include digital signatures and cryptographic keys as described in
- [RFC2535]. Thus the DNS can now be secured and used for secure key
- distribution.
-
- Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
- FIP180] in this document.
-
- RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
- in the DNS. However, since the adoption of RFC 2537, continued
- cryptographic research has revealed hints of weakness in the MD5
- [RFC1321] algorithm used in RFC 2537. The SHA1 Secure Hash Algorithm
- [FIP180], which produces a larger hash, has been developed. By now
- there has been sufficient experience with SHA1 that it is generally
- acknowledged to be stronger than MD5. While this stronger hash is
- probably not needed today in most secure DNS zones, critical zones
- such a root, most top level domains, and some second and third level
- domains, are sufficiently valuable targets that it would be negligent
- not to provide what are generally agreed to be stronger mechanisms.
- Furthermore, future advances in cryptanalysis and/or computer speeds
- may require a stronger hash everywhere. In addition, the additional
- computation required by SHA1 above that required by MD5 is
- insignificant compared with the computational effort required by the
- RSA modular exponentiation.
-
- This document describes how to produce RSA/SHA1 SIG RRs in Section 3
- and, so as to completely replace RFC 2537, describes how to produce
- RSA KEY RRs in Section 2.
-
- Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
- DNSSEC. The generation of RSA/MD5 SIG RRs as described in RFC 2537
- is NOT RECOMMENDED.
-
-
-
-D. Eastlake 3rd Standards Track [Page 2]
-
-RFC 3110 RSA SIGs and KEYs in the DNS May 2001
-
-
- The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
- RECOMMENDED", and "MAY" in this document are to be interpreted as
- described in RFC 2119.
-
-2. RSA Public KEY Resource Records
-
- RSA public keys are stored in the DNS as KEY RRs using algorithm
- number 5 [RFC2535]. The structure of the algorithm specific portion
- of the RDATA part of such RRs is as shown below.
-
- Field Size
- ----- ----
- exponent length 1 or 3 octets (see text)
- exponent as specified by length field
- modulus remaining space
-
- For interoperability, the exponent and modulus are each limited to
- 4096 bits in length. The public key exponent is a variable length
- unsigned integer. Its length in octets is represented as one octet
- if it is in the range of 1 to 255 and by a zero octet followed by a
- two octet unsigned length if it is longer than 255 bytes. The public
- key modulus field is a multiprecision unsigned integer. The length
- of the modulus can be determined from the RDLENGTH and the preceding
- RDATA fields including the exponent. Leading zero octets are
- prohibited in the exponent and modulus.
-
- Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
- algorithm number (rather than the algorithm number specified in the
- obsoleted RFC 2537).
-
- Note: This changes the algorithm number for RSA KEY RRs to be the
- same as the new algorithm number for RSA/SHA1 SIGs.
-
-3. RSA/SHA1 SIG Resource Records
-
- RSA/SHA1 signatures are stored in the DNS using SIG resource records
- (RRs) with algorithm number 5.
-
- The signature portion of the SIG RR RDATA area, when using the
- RSA/SHA1 algorithm, is calculated as shown below. The data signed is
- determined as specified in RFC 2535. See RFC 2535 for fields in the
- SIG RR RDATA which precede the signature itself.
-
- hash = SHA1 ( data )
-
- signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-
-
-
-
-D. Eastlake 3rd Standards Track [Page 3]
-
-RFC 3110 RSA SIGs and KEYs in the DNS May 2001
-
-
- where SHA1 is the message digest algorithm documented in [FIP180],
- "|" is concatenation, "e" is the private key exponent of the signer,
- and "n" is the modulus of the signer's public key. 01, FF, and 00
- are fixed octets of the corresponding hexadecimal value. "prefix" is
- the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1
- [RFC2437], that is,
-
- hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
-
- This prefix is included to make it easier to use standard
- cryptographic libraries. The FF octet MUST be repeated the maximum
- number of times such that the value of the quantity being
- exponentiated is one octet shorter than the value of n.
-
- (The above specifications are identical to the corresponding parts of
- Public Key Cryptographic Standard #1 [RFC2437].)
-
- The size of "n", including most and least significant bits (which
- will be 1) MUST be not less than 512 bits and not more than 4096
- bits. "n" and "e" SHOULD be chosen such that the public exponent is
- small. These are protocol limits. For a discussion of key size see
- RFC 2541.
-
- Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA and
- DSA [RFC2536]. 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 with
- DSA when the RSA public exponent is chosen to be small as is
- recommended for KEY RRs used in domain name system (DNS) data
- authentication.
-
- A public exponent of 3 minimizes the effort needed to verify a
- signature. Use of 3 as the public exponent is weak for
- confidentiality uses since, if the same data can be collected
- encrypted under three different keys with an exponent of 3 then,
- using the Chinese Remainder Theorem [NETSEC], the original plain text
- can be easily recovered. If a key is known to be used only for
- authentication, as is the case with DNSSEC, then an exponent of 3 is
- acceptable. However other applications in the future may wish to
- leverage DNS distributed keys for applications that do require
- confidentiality. For keys which might have such other uses, a more
- conservative choice would be 65537 (F4, the fourth fermat number).
-
-
-
-
-
-D. Eastlake 3rd Standards Track [Page 4]
-
-RFC 3110 RSA SIGs and KEYs in the DNS May 2001
-
-
- 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 [RFC2671] to make larger transfers more efficient, it is
- still advisable at this time to make reasonable efforts to minimize
- the size of KEY RR sets stored within the DNS consistent with
- adequate security. Keep in mind that in a secure zone, at least one
- authenticating SIG RR will also be returned.
-
-5. IANA Considerations
-
- The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and
- RSA KEY RRs.
-
-6. Security Considerations
-
- Many of the general security considerations in RFC 2535 apply. 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. For particularly critical applications,
- implementers are encouraged to consider the range of available
- algorithms and key sizes. See also RFC 2541, "DNS Security
- Operational Considerations".
-
-References
-
- [FIP180] U.S. Department of Commerce, "Secure Hash Standard", FIPS
- PUB 180-1, 17 Apr 1995.
-
- [NETSEC] Network Security: PRIVATE Communications in a PUBLIC
- World, Charlie Kaufman, Radia Perlman, & Mike Speciner,
- Prentice Hall Series in Computer Networking and
- Distributed Communications, 1995.
-
- [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.
-
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
-
-
-
-
-D. Eastlake 3rd Standards Track [Page 5]
-
-RFC 3110 RSA SIGs and KEYs in the DNS May 2001
-
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
- Specifications Version 2.0", RFC 2437, October 1998.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
- (DNS)", RFC 2536, March 1999.
-
- [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
- System (DNS)", RFC 2537, March 1999.
-
- [RFC2541] Eastlake, D., "DNS Security Operational Considerations",
- RFC 2541, March 1999.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
- protocols, algorithms, and source code in C", 1996, John
- Wiley and Sons, ISBN 0-471-11709-9.
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Phone: +1-508-261-5434 (w)
- +1-508-634-2066 (h)
- Fax +1-508-261-4777 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd Standards Track [Page 6]
-
-RFC 3110 RSA SIGs and KEYs in the DNS May 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd Standards Track [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3123.txt b/contrib/bind9/doc/rfc/rfc3123.txt
deleted file mode 100644
index 3b2fe00e5ee8d..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3123.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Koch
-Request for Comments: 3123 Universitaet Bielefeld
-Category: Experimental June 2001
-
-
- A DNS RR Type for Lists of Address Prefixes (APL RR)
-
-Status of this Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. It does not specify an Internet standard of any kind.
- Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
- The Domain Name System (DNS) is primarily used to translate domain
- names into IPv4 addresses using A RRs (Resource Records). Several
- approaches exist to describe networks or address ranges. This
- document specifies a new DNS RR type "APL" for address prefix lists.
-
-1. Conventions used 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 [RFC2119].
-
- Domain names herein are for explanatory purposes only and should not
- be expected to lead to useful information in real life [RFC2606].
-
-2. Background
-
- The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
- associate addresses and other Internet infrastructure elements with
- hierarchically built domain names. Various types of resource records
- have been defined, especially those for IPv4 and IPv6 [RFC2874]
- addresses. In [RFC1101] a method is described to publish information
- about the address space allocated to an organisation. In older BIND
- versions, a weak form of controlling access to zone data was
- implemented using TXT RRs describing address ranges.
-
- This document specifies a new RR type for address prefix lists.
-
-
-
-
-
-Koch Experimental [Page 1]
-
-RFC 3123 DNS APL RR June 2001
-
-
-3. APL RR Type
-
- An APL record has the DNS type of "APL" and a numeric value of 42
- [IANA]. The APL RR is defined in the IN class only. APL RRs cause
- no additional section processing.
-
-4. APL RDATA format
-
- The RDATA section consists of zero or more items (<apitem>) of the
- form
-
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- | ADDRESSFAMILY |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- | PREFIX | N | AFDLENGTH |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- / AFDPART /
- | |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
- ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
- (see IANA Considerations)
- PREFIX 8 bit unsigned binary coded prefix length.
- Upper and lower bounds and interpretation of
- this value are address family specific.
- N negation flag, indicates the presence of the
- "!" character in the textual format. It has
- the value "1" if the "!" was given, "0" else.
- AFDLENGTH length in octets of the following address
- family dependent part (7 bit unsigned).
- AFDPART address family dependent part. See below.
-
- This document defines the AFDPARTs for address families 1 (IPv4) and
- 2 (IPv6). Future revisions may deal with additional address
- families.
-
-4.1. AFDPART for IPv4
-
- The encoding of an IPv4 address (address family 1) follows the
- encoding specified for the A RR by [RFC1035], section 3.4.1.
-
- PREFIX specifies the number of bits of the IPv4 address starting at
- the most significant bit. Legal values range from 0 to 32.
-
- Trailing zero octets do not bear any information (e.g., there is no
- semantic difference between 10.0.0.0/16 and 10/16) in an address
- prefix, so the shortest possible AFDLENGTH can be used to encode it.
- However, for DNSSEC [RFC2535] a single wire encoding must be used by
-
-
-
-Koch Experimental [Page 2]
-
-RFC 3123 DNS APL RR June 2001
-
-
- all. Therefore the sender MUST NOT include trailing zero octets in
- the AFDPART regardless of the value of PREFIX. This includes cases
- in which AFDLENGTH times 8 results in a value less than PREFIX. The
- AFDPART is padded with zero bits to match a full octet boundary.
-
- An IPv4 AFDPART has a variable length of 0 to 4 octets.
-
-4.2. AFDPART for IPv6
-
- The 128 bit IPv6 address (address family 2) is encoded in network
- byte order (high-order byte first).
-
- PREFIX specifies the number of bits of the IPv6 address starting at
- the most significant bit. Legal values range from 0 to 128.
-
- With the same reasoning as in 4.1 above, the sender MUST NOT include
- trailing zero octets in the AFDPART regardless of the value of
- PREFIX. This includes cases in which AFDLENGTH times 8 results in a
- value less than PREFIX. The AFDPART is padded with zero bits to
- match a full octet boundary.
-
- An IPv6 AFDPART has a variable length of 0 to 16 octets.
-
-5. Zone File Syntax
-
- The textual representation of an APL RR in a DNS zone file is as
- follows:
-
- <owner> IN <TTL> APL {[!]afi:address/prefix}*
-
- The data consists of zero or more strings of the address family
- indicator <afi>, immediately followed by a colon ":", an address,
- immediately followed by the "/" character, immediately followed by a
- decimal numeric value for the prefix length. Any such string may be
- preceded by a "!" character. The strings are separated by
- whitespace. The <afi> is the decimal numeric value of that
- particular address family.
-
-5.1. Textual Representation of IPv4 Addresses
-
- An IPv4 address in the <address> part of an <apitem> is in dotted
- quad notation, just as in an A RR. The <prefix> has values from the
- interval 0..32 (decimal).
-
-
-
-
-
-
-
-
-Koch Experimental [Page 3]
-
-RFC 3123 DNS APL RR June 2001
-
-
-5.2. Textual Representation of IPv6 Addresses
-
- The representation of an IPv6 address in the <address> part of an
- <apitem> follows [RFC2373], section 2.2. Legal values for <prefix>
- are from the interval 0..128 (decimal).
-
-6. APL RR usage
-
- An APL RR with empty RDATA is valid and implements an empty list.
- Multiple occurrences of the same <apitem> in a single APL RR are
- allowed and MUST NOT be merged by a DNS server or resolver.
- <apitems> MUST be kept in order and MUST NOT be rearranged or
- aggregated.
-
- A single APL RR may contain <apitems> belonging to different address
- families. The maximum number of <apitems> is upper bounded by the
- available RDATA space.
-
- RRSets consisting of more than one APL RR are legal but the
- interpretation is left to the particular application.
-
-7. Applicability Statement
-
- The APL RR defines a framework without specifying any particular
- meaning for the list of prefixes. It is expected that APL RRs will
- be used in different application scenarios which have to be
- documented separately. Those scenarios may be distinguished by
- characteristic prefixes placed in front of the DNS owner name.
-
- An APL application specification MUST include information on
-
- o the characteristic prefix, if any
-
- o how to interpret APL RRSets consisting of more than one RR
-
- o how to interpret an empty APL RR
-
- o which address families are expected to appear in the APL RRs for
- that application
-
- o how to deal with APL RR list elements which belong to other
- address families, including those not yet defined
-
- o the exact semantics of list elements negated by the "!" character
-
-
-
-
-
-
-
-Koch Experimental [Page 4]
-
-RFC 3123 DNS APL RR June 2001
-
-
- Possible applications include the publication of address ranges
- similar to [RFC1101], description of zones built following [RFC2317]
- and in-band access control to limit general access or zone transfer
- (AXFR) availability for zone data held in DNS servers.
-
- The specification of particular application scenarios is out of the
- scope of this document.
-
-8. Examples
-
- The following examples only illustrate some of the possible usages
- outlined in the previous section. None of those applications are
- hereby specified nor is it implied that any particular APL RR based
- application does exist now or will exist in the future.
-
- ; RFC 1101-like announcement of address ranges for foo.example
- foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
-
- ; CIDR blocks covered by classless delegation
- 42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
- 1:192.168.42.128/25 )
-
- ; Zone transfer restriction
- _axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
-
- ; List of address ranges for multicast
- multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
-
- Note that since trailing zeroes are ignored in the first APL RR the
- AFDLENGTH of both <apitems> is three.
-
-9. Security Considerations
-
- Any information obtained from the DNS should be regarded as unsafe
- unless techniques specified in [RFC2535] or [RFC2845] were used. The
- definition of a new RR type does not introduce security problems into
- the DNS, but usage of information made available by APL RRs may
- compromise security. This includes disclosure of network topology
- information and in particular the use of APL RRs to construct access
- control lists.
-
-
-
-
-
-
-
-
-
-
-
-Koch Experimental [Page 5]
-
-RFC 3123 DNS APL RR June 2001
-
-
-10. IANA Considerations
-
- This section is to be interpreted as following [RFC2434].
-
- This document does not define any new namespaces. It uses the 16 bit
- identifiers for address families maintained by IANA in
- http://www.iana.org/numbers.html.
-
- The IANA assigned numeric RR type value 42 for APL [IANA].
-
-11. Acknowledgements
-
- The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
- Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
- and constructive comments.
-
-12. 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.
-
- [RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
- Types", RFC 1101, April 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.
-
- [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
- ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
-
- [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
- BCP 32, RFC 2606, June 1999.
-
-
-
-Koch Experimental [Page 6]
-
-RFC 3123 DNS APL RR June 2001
-
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
- IPv6 Address Aggregation and Renumbering", RFC 2874, July
- 2000.
-
- [IANA] http://www.iana.org/assignments/dns-parameters
-
-13. Author's Address
-
- Peter Koch
- Universitaet Bielefeld
- Technische Fakultaet
- D-33594 Bielefeld
- Germany
-
- Phone: +49 521 106 2902
- EMail: pk@TechFak.Uni-Bielefeld.DE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch Experimental [Page 7]
-
-RFC 3123 DNS APL RR June 2001
-
-
-14. Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch Experimental [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3152.txt b/contrib/bind9/doc/rfc/rfc3152.txt
deleted file mode 100644
index b226ce6451f97..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3152.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Bush
-Request for Comments: 3152 RGnet
-BCP: 49 August 2001
-Updates: 2874, 2772, 2766, 2553, 1886
-Category: Best Current Practice
-
-
- Delegation of IP6.ARPA
-
-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 (2001). All Rights Reserved.
-
-Abstract
-
- This document discusses the need for delegation of the IP6.ARPA DNS
- zone, and specifies a plan for the technical operation thereof.
-
-1. Why IP6.ARPA?
-
- In the IPv6 address space, there is a need for 'reverse mapping' of
- addresses to DNS names analogous to that provided by the IN-ADDR.ARPA
- zone for IPv4.
-
- The IAB recommended that the ARPA top level domain (the name is now
- considered an acronym for "Address and Routing Parameters Area") be
- used for technical infrastructure sub-domains when possible. It is
- already in use for IPv4 reverse mapping and has been established as
- the location for E.164 numbering on the Internet [RFC2916 RFC3026].
-
- IETF consensus was reached that the IP6.ARPA domain be used for
- address to DNS name mapping for the IPv6 address space [RFC2874].
-
-2. Obsoleted Usage
-
- This document deprecates references to IP6.INT in [RFC1886] section
- 2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772]
- section 7.1.c, and [RFC2874] section 2.5.
-
- In this context, 'deprecate' means that the old usage is not
- appropriate for new implementations, and IP6.INT will likely be
- phased out in an orderly fashion.
-
-
-
-Bush Best Current Practice [Page 1]
-
-RFC 3152 Delegation of IP6.ARPA August 2001
-
-
-3. IANA Considerations
-
- This memo requests that the IANA delegate the IP6.ARPA domain
- following instructions to be provided by the IAB. Names within this
- zone are to be further delegated to the regional IP registries in
- accordance with the delegation of IPv6 address space to those
- registries. The names allocated should be hierarchic in accordance
- with the address space assignment.
-
-4. Security Considerations
-
- While DNS spoofing of address to name mapping has been exploited in
- IPv4, delegation of the IP6.ARPA zone creates no new threats to the
- security of the internet.
-
-5. References
-
- [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
- version 6", RFC 1886, December 1995.
-
- [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
- "Basic Socket Interface Extensions for IPv6", RFC 2553,
- March 1999.
-
- [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
- Translation - Protocol Translation (NAT-PT)", RFC 2766,
- February 2000.
-
- [RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing
- Guidelines", RFC 2772, February 2000.
-
- [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
- IPv6 Address Aggregation and Renumbering", RFC 2874, July
- 2001.
-
- [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
- September 2000.
-
- [RFC3026] Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026,
- January 2001.
-
-
-
-
-
-
-
-
-
-
-
-Bush Best Current Practice [Page 2]
-
-RFC 3152 Delegation of IP6.ARPA August 2001
-
-
-6. Author's Address
-
- Randy Bush
- 5147 Crystal Springs
- Bainbridge Island, WA US-98110
-
- Phone: +1 206 780 0431
- EMail: randy@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush Best Current Practice [Page 3]
-
-RFC 3152 Delegation of IP6.ARPA August 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush Best Current Practice [Page 4]
-
diff --git a/contrib/bind9/doc/rfc/rfc3197.txt b/contrib/bind9/doc/rfc/rfc3197.txt
deleted file mode 100644
index 94cefa4c6b718..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3197.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Austein
-Request for Comments: 3197 InterNetShare
-Category: Informational November 2001
-
-
- Applicability Statement for DNS MIB Extensions
-
-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 (2001). All Rights Reserved.
-
-Abstract
-
- This document explains why, after more than six years as proposed
- standards, the DNS Server and Resolver MIB extensions were never
- deployed, and recommends retiring these MIB extensions by moving them
- to Historical status.
-
-1. History
-
- The road to the DNS MIB extensions was paved with good intentions.
-
- In retrospect, it's obvious that the working group never had much
- agreement on what belonged in the MIB extensions, just that we should
- have some. This happened during the height of the craze for MIB
- extensions in virtually every protocol that the IETF was working on
- at the time, so the question of why we were doing this in the first
- place never got a lot of scrutiny. Very late in the development
- cycle we discovered that much of the support for writing the MIB
- extensions in the first place had come from people who wanted to use
- SNMP SET operations to update DNS zones on the fly. Examination of
- the security model involved, however, led us to conclude that this
- was not a good way to do dynamic update and that a separate DNS
- Dynamic Update protocol would be necessary.
-
- The MIB extensions started out being fairly specific to one
- particular DNS implementation (BIND-4.8.3); as work progressed, the
- BIND-specific portions were rewritten to be as implementation-neutral
- as we knew how to make them, but somehow every revision of the MIB
- extensions managed to create new counters that just happened to
- closely match statistics kept by some version of BIND. As a result,
- the MIB extensions ended up being much too big, which raised a number
-
-
-
-Austein Informational [Page 1]
-
-RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
-
-
- of concerns with the network management directorate, but the WG
- resisted every attempt to remove any of these variables. In the end,
- large portions of the MIB extensions were moved into optional groups
- in an attempt to get the required subset down to a manageable size.
-
- The DNS Server and Resolver MIB extensions were one of the first
- attempts to write MIB extensions for a protocol usually considered to
- be at the application layer. Fairly early on it became clear that,
- while it was certainly possible to write MIB extensions for DNS, the
- SMI was not really designed with this sort of thing in mind. A case
- in point was the attempt to provide direct indexing into the caches
- in the resolver MIB extensions: while arguably the only sane way to
- do this for a large cache, this required much more complex indexing
- clauses than is usual, and ended up running into known length limits
- for object identifiers in some SNMP implementations.
-
- Furthermore, the lack of either real proxy MIB support in SNMP
- managers or a standard subagent protocol meant that there was no
- reasonable way to implement the MIB extensions in the dominant
- implementation (BIND). When the AgentX subagent protocol was
- developed a few years later, we initially hoped that this would
- finally clear the way for an implementation of the DNS MIB
- extensions, but by the time AgentX was a viable protocol it had
- become clear that nobody really wanted to implement these MIB
- extensions.
-
- Finally, the MIB extensions took much too long to produce. In
- retrospect, this should have been a clear warning sign, particularly
- when the WG had clearly become so tired of the project that the
- authors found it impossible to elicit any comments whatsoever on the
- documents.
-
-2. Lessons
-
- Observations based on the preceding list of mistakes, for the benefit
- of anyone else who ever attempts to write DNS MIB extensions again:
-
- - Define a clear set of goals before writing any MIB extensions.
- Know who the constituency is and make sure that what you write
- solves their problem.
-
- - Keep the MIB extensions short, and don't add variables just
- because somebody in the WG thinks they'd be a cool thing to
- measure.
-
- - If some portion of the task seems to be very hard to do within the
- SMI, that's a strong hint that SNMP is not the right tool for
- whatever it is that you're trying to do.
-
-
-
-Austein Informational [Page 2]
-
-RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
-
-
- - If the entire project is taking too long, perhaps that's a hint
- too.
-
-3. Recommendation
-
- In view of the community's apparent total lack of interest in
- deploying these MIB extensions, we recommend that RFCs 1611 and 1612
- be reclassified as Historical documents.
-
-4. Security Considerations
-
- Re-classifying an existing MIB document from Proposed Standard to
- Historic should not have any negative impact on security for the
- Internet.
-
-5. IANA Considerations
-
- Getting rid of the DNS MIB extensions should not impose any new work
- on IANA.
-
-6. Acknowledgments
-
- The author would like to thank all the people who were involved in
- this project over the years for their optimism and patience,
- misguided though it may have been.
-
-7. References
-
- [DNS-SERVER-MIB] Austein, R. and J. Saperia, "DNS Server MIB
- Extensions", RFC 1611, May 1994.
-
- [DNS-RESOLVER-MIB] Austein, R. and J. Saperia, "DNS Resolver MIB
- Extensions", RFC 1612, May 1994.
-
- [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J.
- Bound, "Dynamic Updates in the Domain Name
- System (DNS UPDATE)", RFC 2136, April 1997.
-
- [AGENTX] Daniele, M., Wijnen, B., Ellison, M., and D.
- Francisco, "Agent Extensibility (AgentX)
- Protocol Version 1", RFC 2741, January 2000.
-
-
-
-
-
-
-
-
-
-
-Austein Informational [Page 3]
-
-RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
-
-
-8. Author's Address
-
- Rob Austein
- InterNetShare, Incorporated
- 325M Sharon Park Drive, Suite 308
- Menlo Park, CA 94025
- USA
-
- EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Informational [Page 4]
-
-RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Informational [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc3225.txt b/contrib/bind9/doc/rfc/rfc3225.txt
deleted file mode 100644
index 13e6768c37a93..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3225.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Conrad
-Request for Comments: 3225 Nominum, Inc.
-Category: Standards Track December 2001
-
-
- Indicating Resolver Support of DNSSEC
-
-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 (2001). All Rights Reserved.
-
-Abstract
-
- In order to deploy DNSSEC (Domain Name System Security Extensions)
- operationally, DNSSEC aware servers should only perform automatic
- inclusion of DNSSEC RRs when there is an explicit indication that the
- resolver can understand those RRs. This document proposes the use of
- a bit in the EDNS0 header to provide that explicit indication and
- describes the necessary protocol changes to implement that
- notification.
-
-1. Introduction
-
- DNSSEC [RFC2535] has been specified to provide data integrity and
- authentication to security aware resolvers and applications through
- the use of cryptographic digital signatures. However, as DNSSEC is
- deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
- servers. In such situations, the DNSSEC-aware server (responding to
- a request for data in a signed zone) will respond with SIG, KEY,
- and/or NXT records. For reasons described in the subsequent section,
- such responses can have significant negative operational impacts for
- the DNS infrastructure.
-
- This document discusses a method to avoid these negative impacts,
- namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
- NXT RRs when there is an explicit indication from the resolver that
- it can understand those RRs.
-
- For the purposes of this document, "DNSSEC security RRs" are
- considered RRs of type SIG, KEY, or NXT.
-
-
-
-Conrad Standards Track [Page 1]
-
-RFC 3225 Indicating Resolver Support of DNSSEC December 2001
-
-
- 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. Rationale
-
- Initially, as DNSSEC is deployed, the vast majority of queries will
- be from resolvers that are not DNSSEC aware and thus do not
- understand or support the DNSSEC security RRs. When a query from
- such a resolver is received for a DNSSEC signed zone, the DNSSEC
- specification indicates the nameserver must respond with the
- appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to
- 512 bytes [RFC1035], responses including DNSSEC security RRs have a
- high probability of resulting in a truncated response being returned
- and the resolver retrying the query using TCP.
-
- TCP DNS queries result in significant overhead due to connection
- setup and teardown. Operationally, the impact of these TCP queries
- will likely be quite detrimental in terms of increased network
- traffic (typically five packets for a single query/response instead
- of two), increased latency resulting from the additional round trip
- times, increased incidences of queries failing due to timeouts, and
- significantly increased load on nameservers.
-
- In addition, in preliminary and experimental deployment of DNSSEC,
- there have been reports of non-DNSSEC aware resolvers being unable to
- handle responses which contain DNSSEC security RRs, resulting in the
- resolver failing (in the worst case) or entire responses being
- ignored (in the better case).
-
- Given these operational implications, explicitly notifying the
- nameserver that the client is prepared to receive (if not understand)
- DNSSEC security RRs would be prudent.
-
- Client-side support of DNSSEC is assumed to be binary -- either the
- client is willing to receive all DNSSEC security RRs or it is not
- willing to accept any. As such, a single bit is sufficient to
- indicate client-side DNSSEC support. As effective use of DNSSEC
- implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
- enhanced DNS header) are scarce, and there may be situations in which
- non-compliant caching or forwarding servers inappropriately copy data
- from classic headers as queries are passed on to authoritative
- servers, the use of a bit from the EDNS0 header is proposed.
-
- An alternative approach would be to use the existence of an EDNS0
- header as an implicit indication of client-side support of DNSSEC.
- This approach was not chosen as there may be applications in which
- EDNS0 is supported but in which the use of DNSSEC is inappropriate.
-
-
-
-Conrad Standards Track [Page 2]
-
-RFC 3225 Indicating Resolver Support of DNSSEC December 2001
-
-
-3. Protocol Changes
-
- The mechanism chosen for the explicit notification of the ability of
- the client to accept (if not understand) DNSSEC security RRs is using
- the most significant bit of the Z field on the EDNS0 OPT header in
- the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In
- the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
- the third and fourth bytes of the "extended RCODE and flags" portion
- of the EDNS0 OPT meta-RR, structured as follows:
-
- +0 (MSB) +1 (LSB)
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 0: | EXTENDED-RCODE | VERSION |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 2: |DO| Z |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- Setting the DO bit to one in a query indicates to the server that the
- resolver is able to accept DNSSEC security RRs. The DO bit cleared
- (set to zero) indicates the resolver is unprepared to handle DNSSEC
- security RRs and those RRs MUST NOT be returned in the response
- (unless DNSSEC security RRs are explicitly queried for). The DO bit
- of the query MUST be copied in the response.
-
- More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
- or NXT RRs to authenticate a response as specified in [RFC2535]
- unless the DO bit was set on the request. Security records that
- match an explicit SIG, KEY, NXT, or ANY query, or are part of the
- zone data for an AXFR or IXFR query, are included whether or not the
- DO bit was set.
-
- A recursive DNSSEC-aware server MUST set the DO bit on recursive
- requests, regardless of the status of the DO bit on the initiating
- resolver request. If the initiating resolver request does not have
- the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
- security RRs before returning the data to the client, however cached
- data MUST NOT be modified.
-
- In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
- to a query that has the DO bit set, the resolver SHOULD NOT expect
- DNSSEC security RRs and SHOULD retry the query without EDNS0 in
- accordance with section 5.3 of [RFC2671].
-
-
-
-
-
-
-
-
-
-Conrad Standards Track [Page 3]
-
-RFC 3225 Indicating Resolver Support of DNSSEC December 2001
-
-
-Security Considerations
-
- The absence of DNSSEC data in response to a query with the DO bit set
- MUST NOT be taken to mean no security information is available for
- that zone as the response may be forged or a non-forged response of
- an altered (DO bit cleared) query.
-
-IANA Considerations
-
- EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
- these bits are encoded into the TTL field of the OPT record (RFC2671
- section 4.6).
-
- This document reserves one of these bits as the OK bit. It is
- requested that the left most bit be allocated. Thus the USE of the
- OPT record TTL field would look like
-
- +0 (MSB) +1 (LSB)
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 0: | EXTENDED-RCODE | VERSION |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 2: |DO| Z |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Acknowledgements
-
- This document is based on a rough draft by Bob Halley with input from
- Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
- Rob Austein, Steve Bellovin, and Erik Nordmark.
-
-References
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specifications", 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.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
-
-
-
-
-Conrad Standards Track [Page 4]
-
-RFC 3225 Indicating Resolver Support of DNSSEC December 2001
-
-
-Author's Address
-
- David Conrad
- Nominum Inc.
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6003
- EMail: david.conrad@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Conrad Standards Track [Page 5]
-
-RFC 3225 Indicating Resolver Support of DNSSEC December 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Conrad Standards Track [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3226.txt b/contrib/bind9/doc/rfc/rfc3226.txt
deleted file mode 100644
index dac0e11c15751..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3226.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group O. Gudmundsson
-Request for Comments: 3226 December 2001
-Updates: 2874, 2535
-Category: Standards Track
-
-
- DNSSEC and IPv6 A6 aware server/resolver message size 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 (2001). All Rights Reserved.
-
-Abstract
-
- This document mandates support for EDNS0 (Extension Mechanisms for
- DNS) in DNS entities claiming to support either DNS Security
- Extensions or A6 records. This requirement is necessary because
- these new features increase the size of DNS messages. If EDNS0 is
- not supported fall back to TCP will happen, having a detrimental
- impact on query latency and DNS server load. This document updates
- RFC 2535 and RFC 2874, by adding new requirements.
-
-1. Introduction
-
- Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
- [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.
-
- STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
- have a data payload of 512 octets or less. Most DNS software today
- will not accept larger UDP datagrams. Any answer that requires more
- than 512 octets, results in a partial and sometimes useless reply
- with the Truncation Bit set; in most cases the requester will then
- retry using TCP. Furthermore, server delivery of truncated responses
- varies widely and resolver handling of these responses also varies,
- leading to additional inefficiencies in handling truncation.
-
- Compared to UDP, TCP is an expensive protocol to use for a simple
- transaction like DNS: a TCP connection requires 5 packets for setup
- and tear down, excluding data packets, thus requiring at least 3
- round trips on top of the one for the original UDP query. The DNS
-
-
-
-Gudmundsson Standards Track [Page 1]
-
-RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
-
-
- server also needs to keep a state of the connection during this
- transaction. Many DNS servers answer thousands of queries per
- second, requiring them to use TCP will cause significant overhead and
- delays.
-
-1.1. Requirements
-
- The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
- in this document are to be interpreted as described in RFC 2119.
-
-2. Motivating factors
-
-2.1. DNSSEC motivations
-
- DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
- RR set. These signatures range in size from about 80 octets to 800
- octets, most are going to be in the range of 80 to 200 octets. The
- addition of signatures on each or most RR sets in an answer
- significantly increases the size of DNS answers from secure zones.
-
- For performance reasons and to reduce load on DNS servers, it is
- important that security aware servers and resolvers get all the data
- in Answer and Authority section in one query without truncation.
- Sending Additional Data in the same query is helpful when the server
- is authoritative for the data, and this reduces round trips.
-
- DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
- it is interested in receiving DNSSEC records. The OK bit does not
- eliminate the need for large answers for DNSSEC capable clients.
-
-2.1.1. Message authentication or TSIG motivation
-
- TSIG [RFC2845] allows for the light weight authentication of DNS
- messages, but increases the size of the messages by at least 70
- octets. DNSSEC specifies for computationally expensive message
- authentication SIG(0) using a standard public key signature. As only
- one TSIG or SIG(0) can be attached to each DNS answer the size
- increase of message authentication is not significant, but may still
- lead to a truncation.
-
-2.2. IPv6 Motivations
-
- IPv6 addresses [RFC2874] are 128 bits and can be represented in the
- DNS by multiple A6 records, each consisting of a domain name and a
- bit field. The domain name refers to an address prefix that may
- require additional A6 RRs to be included in the answer. Answers
- where the queried name has multiple A6 addresses may overflow a 512-
- octet UDP packet size.
-
-
-
-Gudmundsson Standards Track [Page 2]
-
-RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
-
-
-2.3. Root server and TLD server motivations
-
- The current number of root servers is limited to 13 as that is the
- maximum number of name servers and their address records that fit in
- one 512-octet answer for a SOA record. If root servers start
- advertising A6 or KEY records then the answer for the root NS records
- will not fit in a single 512-octet DNS message, resulting in a large
- number of TCP query connections to the root servers. Even if all
- client resolver query their local name server for information, there
- are millions of these servers. Each name server must periodically
- update its information about the high level servers.
-
- For redundancy, latency and load balancing reasons, large numbers of
- DNS servers are required for some zones. Since the root zone is used
- by the entire net, it is important to have as many servers as
- possible. Large TLDs (and many high-visibility SLDs) often have
- enough servers that either A6 or KEY records would cause the NS
- response to overflow the 512 byte limit. Note that these zones with
- large numbers of servers are often exactly those zones that are
- critical to network operation and that already sustain fairly high
- loads.
-
-2.4. UDP vs TCP for DNS messages
-
- Given all these factors, it is essential that any implementation that
- supports DNSSEC and or A6 be able to use larger DNS messages than 512
- octets.
-
- The original 512 restriction was put in place to reduce the
- probability of fragmentation of DNS responses. A fragmented UDP
- message that suffers a loss of one of the fragments renders the
- answer useless and the query must be retried. A TCP connection
- requires a larger number of round trips for establishment, data
- transfer and tear down, but only the lost data segments are
- retransmitted.
-
- In the early days a number of IP implementations did not handle
- fragmentation well, but all modern operating systems have overcome
- that issue thus sending fragmented messages is fine from that
- standpoint. The open issue is the effect of losses on fragmented
- messages. If connection has high loss ratio only TCP will allow
- reliable transfer of DNS data, most links have low loss ratios thus
- sending fragmented UDP packet in one round trip is better than
- establishing a TCP connection to transfer a few thousand octets.
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 3]
-
-RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
-
-
-2.5. EDNS0 and large UDP messages
-
- EDNS0 [RFC2671] allows clients to declare the maximum size of UDP
- message they are willing to handle. Thus, if the expected answer is
- between 512 octets and the maximum size that the client can accept,
- the additional overhead of a TCP connection can be avoided.
-
-3. Protocol changes:
-
- This document updates RFC 2535 and RFC 2874, by adding new
- requirements.
-
- All RFC 2535 compliant servers and resolvers MUST support EDNS0 and
- advertise message size of at least 1220 octets, but SHOULD advertise
- message size of 4000. This value might be too low to get full
- answers for high level servers and successor of this document may
- require a larger value.
-
- All RFC 2874 compliant servers and resolver MUST support EDNS0 and
- advertise message size of at least 1024 octets, but SHOULD advertise
- message size of 2048. The IPv6 datagrams should be 1024 octets,
- unless the MTU of the path is known. (Note that this is smaller than
- the minimum IPv6 MTU to allow for some extension headers and/or
- encapsulation without exceeding the minimum MTU.)
-
- All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
- fragmented IPv4 and IPv6 UDP packets.
-
- All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger
- required value in EDNS0 advertisements.
-
-4. Acknowledgments
-
- Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
- Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
- Michael Patton and Kazu Yamamoto were instrumental in motivating and
- shaping this document.
-
-5. Security Considerations:
-
- There are no additional security considerations other than those in
- RFC 2671.
-
-6. IANA Considerations:
-
- None
-
-
-
-
-
-Gudmundsson Standards Track [Page 4]
-
-RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
-
-
-7. 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, D. "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [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.
-
- [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
- IPv6 Address Aggregation and Renumbering", RFC 2874, July
- 2000.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
-8. Author Address
-
- Olafur Gudmundsson
- 3826 Legation Street, NW
- Washington, DC 20015
- USA
-
- EMail: ogud@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 5]
-
-RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3258.txt b/contrib/bind9/doc/rfc/rfc3258.txt
deleted file mode 100644
index dcd4b34b2b6e9..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3258.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group T. Hardie
-Request for Comments: 3258 Nominum, Inc.
-Category: Informational April 2002
-
-
- Distributing Authoritative Name Servers via Shared Unicast 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 (2002). All Rights Reserved.
-
-Abstract
-
- This memo describes a set of practices intended to enable an
- authoritative name server operator to provide access to a single
- named server in multiple locations. The primary motivation for the
- development and deployment of these practices is to increase the
- distribution of Domain Name System (DNS) servers to previously
- under-served areas of the network topology and to reduce the latency
- for DNS query responses in those areas.
-
-1. Introduction
-
- This memo describes a set of practices intended to enable an
- authoritative name server operator to provide access to a single
- named server in multiple locations. The primary motivation for the
- development and deployment of these practices is to increase the
- distribution of DNS servers to previously under-served areas of the
- network topology and to reduce the latency for DNS query responses in
- those areas. This document presumes a one-to-one mapping between
- named authoritative servers and administrative entities (operators).
- This document contains no guidelines or recommendations for caching
- name servers. The shared unicast system described here is specific
- to IPv4; applicability to IPv6 is an area for further study. It
- should also be noted that the system described here is related to
- that described in [ANYCAST], but it does not require dedicated
- address space, routing changes, or the other elements of a full
- anycast infrastructure which that document describes.
-
-
-
-
-
-
-
-Hardie Informational [Page 1]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
-2. Architecture
-
-2.1 Server Requirements
-
- Operators of authoritative name servers may wish to refer to
- [SECONDARY] and [ROOT] for general guidance on appropriate practice
- for authoritative name servers. In addition to proper configuration
- as a standard authoritative name server, each of the hosts
- participating in a shared-unicast system should be configured with
- two network interfaces. These interfaces may be either two physical
- interfaces or one physical interface mapped to two logical
- interfaces. One of the network interfaces should use the IPv4 shared
- unicast address associated with the authoritative name server. The
- other interface, referred to as the administrative interface below,
- should use a distinct IPv4 address specific to that host. The host
- should respond to DNS queries only on the shared-unicast interface.
- In order to provide the most consistent set of responses from the
- mesh of anycast hosts, it is good practice to limit responses on that
- interface to zones for which the host is authoritative.
-
-2.2 Zone file delivery
-
- In order to minimize the risk of man-in-the-middle attacks, zone
- files should be delivered to the administrative interface of the
- servers participating in the mesh. Secure file transfer methods and
- strong authentication should be used for all transfers. If the hosts
- in the mesh make their zones available for zone transfer, the
- administrative interfaces should be used for those transfers as well,
- in order to avoid the problems with potential routing changes for TCP
- traffic noted in section 2.5 below.
-
-2.3 Synchronization
-
- Authoritative name servers may be loosely or tightly synchronized,
- depending on the practices set by the operating organization. As
- noted below in section 4.1.2, lack of synchronization among servers
- using the same shared unicast address could create problems for some
- users of this service. In order to minimize that risk, switch-overs
- from one data set to another data set should be coordinated as much
- as possible. The use of synchronized clocks on the participating
- hosts and set times for switch-overs provides a basic level of
- coordination. A more complete coordination process would involve:
-
- a) receipt of zones at a distribution host
- b) confirmation of the integrity of zones received
- c) distribution of the zones to all of the servers in the mesh
- d) confirmation of the integrity of the zones at each server
-
-
-
-
-Hardie Informational [Page 2]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
- e) coordination of the switchover times for the servers in the
- mesh
- f) institution of a failure process to ensure that servers that
- did not receive correct data or could not switchover to the new
- data ceased to respond to incoming queries until the problem
- could be resolved.
-
- Depending on the size of the mesh, the distribution host may also be
- a participant; for authoritative servers, it may also be the host on
- which zones are generated.
-
- This document presumes that the usual DNS failover methods are the
- only ones used to ensure reachability of the data for clients. It
- does not advise that the routes be withdrawn in the case of failure;
- it advises instead that the DNS process shutdown so that servers on
- other addresses are queried. This recommendation reflects a choice
- between performance and operational complexity. While it would be
- possible to have some process withdraw the route for a specific
- server instance when it is not available, there is considerable
- operational complexity involved in ensuring that this occurs
- reliably. Given the existing DNS failover methods, the marginal
- improvement in performance will not be sufficient to justify the
- additional complexity for most uses.
-
-2.4 Server Placement
-
- Though the geographic diversity of server placement helps reduce the
- effects of service disruptions due to local problems, it is diversity
- of placement in the network topology which is the driving force
- behind these distribution practices. Server placement should
- emphasize that diversity. Ideally, servers should be placed
- topologically near the points at which the operator exchanges routes
- and traffic with other networks.
-
-2.5 Routing
-
- The organization administering the mesh of servers sharing a unicast
- address must have an autonomous system number and speak BGP to its
- peers. To those peers, the organization announces a route to the
- network containing the shared-unicast address of the name server.
- The organization's border routers must then deliver the traffic
- destined for the name server to the nearest instantiation. Routing
- to the administrative interfaces for the servers can use the normal
- routing methods for the administering organization.
-
- One potential problem with using shared unicast addresses is that
- routers forwarding traffic to them may have more than one available
- route, and those routes may, in fact, reach different instances of
-
-
-
-Hardie Informational [Page 3]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
- the shared unicast address. Applications like the DNS, whose
- communication typically consists of independent request-response
- messages each fitting in a single UDP packet present no problem.
- Other applications, in which multiple packets must reach the same
- endpoint (e.g., TCP) may fail or present unworkable performance
- characteristics in some circumstances. Split-destination failures
- may occur when a router does per-packet (or round-robin) load
- sharing, a topology change occurs that changes the relative metrics
- of two paths to the same anycast destination, etc.
-
- Four things mitigate the severity of this problem. The first is that
- UDP is a fairly high proportion of the query traffic to name servers.
- The second is that the aim of this proposal is to diversify
- topological placement; for most users, this means that the
- coordination of placement will ensure that new instances of a name
- server will be at a significantly different cost metric from existing
- instances. Some set of users may end up in the middle, but that
- should be relatively rare. The third is that per packet load sharing
- is only one of the possible load sharing mechanisms, and other
- mechanisms are increasing in popularity.
-
- Lastly, in the case where the traffic is TCP, per packet load sharing
- is used, and equal cost routes to different instances of a name
- server are available, any DNS implementation which measures the
- performance of servers to select a preferred server will quickly
- prefer a server for which this problem does not occur. For the DNS
- failover mechanisms to reliably avoid this problem, however, those
- using shared unicast distribution mechanisms must take care that all
- of the servers for a specific zone are not participants in the same
- shared-unicast mesh. To guard even against the case where multiple
- meshes have a set of users affected by per packet load sharing along
- equal cost routes, organizations implementing these practices should
- always provide at least one authoritative server which is not a
- participant in any shared unicast mesh. Those deploying shared-
- unicast meshes should note that any specific host may become
- unreachable to a client should a server fail, a path fail, or the
- route to that host be withdrawn. These error conditions are,
- however, not specific to shared-unicast distributions, but would
- occur for standard unicast hosts.
-
- Since ICMP response packets might go to a different member of the
- mesh than that sending a packet, packets sent with a shared unicast
- source address should also avoid using path MTU discovery.
-
- Appendix A. contains an ASCII diagram of an example of a simple
- implementation of this system. In it, the odd numbered routers
- deliver traffic to the shared-unicast interface network and filter
- traffic from the administrative network; the even numbered routers
-
-
-
-Hardie Informational [Page 4]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
- deliver traffic to the administrative network and filter traffic from
- the shared-unicast network. These are depicted as separate routers
- for the ease this gives in explanation, but they could easily be
- separate interfaces on the same router. Similarly, a local NTP
- source is depicted for synchronization, but the level of
- synchronization needed would not require that source to be either
- local or a stratum one NTP server.
-
-3. Administration
-
-3.1 Points of Contact
-
- A single point of contact for reporting problems is crucial to the
- correct administration of this system. If an external user of the
- system needs to report a problem related to the service, there must
- be no ambiguity about whom to contact. If internal monitoring does
- not indicate a problem, the contact may, of course, need to work with
- the external user to identify which server generated the error.
-
-4. Security Considerations
-
- As a core piece of Internet infrastructure, authoritative name
- servers are common targets of attack. The practices outlined here
- increase the risk of certain kinds of attacks and reduce the risk of
- others.
-
-4.1 Increased Risks
-
-4.1.1 Increase in physical servers
-
- The architecture outlined in this document increases the number of
- physical servers, which could increase the possibility that a server
- mis-configuration will occur which allows for a security breach. In
- general, the entity administering a mesh should ensure that patches
- and security mechanisms applied to a single member of the mesh are
- appropriate for and applied to all of the members of a mesh.
- "Genetic diversity" (code from different code bases) can be a useful
- security measure in avoiding attacks based on vulnerabilities in a
- specific code base; in order to ensure consistency of responses from
- a single named server, however, that diversity should be applied to
- different shared-unicast meshes or between a mesh and a related
- unicast authoritative server.
-
-4.1.2 Data synchronization problems
-
- The level of systemic synchronization described above should be
- augmented by synchronization of the data present at each of the
- servers. While the DNS itself is a loosely coupled system, debugging
-
-
-
-Hardie Informational [Page 5]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
- problems with data in specific zones would be far more difficult if
- two different servers sharing a single unicast address might return
- different responses to the same query. For example, if the data
- associated with www.example.com has changed and the administrators of
- the domain are testing for the changes at the example.com
- authoritative name servers, they should not need to check each
- instance of a named authoritative server. The use of NTP to provide
- a synchronized time for switch-over eliminates some aspects of this
- problem, but mechanisms to handle failure during the switchover are
- required. In particular, a server which cannot make the switchover
- must not roll-back to a previous version; it must cease to respond to
- queries so that other servers are queried.
-
-4.1.3 Distribution risks
-
- If the mechanism used to distribute zone files among the servers is
- not well secured, a man-in-the-middle attack could result in the
- injection of false information. Digital signatures will alleviate
- this risk, but encrypted transport and tight access lists are a
- necessary adjunct to them. Since zone files will be distributed to
- the administrative interfaces of meshed servers, the access control
- list for distribution of the zone files should include the
- administrative interface of the server or servers, rather than their
- shared unicast addresses.
-
-4.2 Decreased Risks
-
- The increase in number of physical servers reduces the likelihood
- that a denial-of-service attack will take out a significant portion
- of the DNS infrastructure. The increase in servers also reduces the
- effect of machine crashes, fiber cuts, and localized disasters by
- reducing the number of users dependent on a specific machine.
-
-5. Acknowledgments
-
- Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
- Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
- Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
- provided input and commentary on this work. The editor wishes to
- remember in particular the contribution of the late Scott Tucker,
- whose extensive systems experience and plain common sense both
- contributed greatly to the editor's own deployment experience and are
- missed by all who knew him.
-
-
-
-
-
-
-
-
-Hardie Informational [Page 6]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
-6. References
-
- [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
- and Operation of Secondary DNS Servers", BCP 16, RFC
- 2182, July 1997.
-
- [ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
- Name Server Operational Requirements", BCP 40, RFC 2870,
- June 2000.
-
- [ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host
- Anycasting Service", RFC 1546, November 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie Informational [Page 7]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
-Appendix A.
-
- __________________
-Peer 1-| |
-Peer 2-| |
-Peer 3-| Switch |
-Transit| | _________ _________
-etc | |--|Router1|---|----|----------|Router2|---WAN-|
- | | --------- | | --------- |
- | | | | |
- | | | | |
- ------------------ [NTP] [DNS] |
- |
- |
- |
- |
- __________________ |
-Peer 1-| | |
-Peer 2-| | |
-Peer 3-| Switch | |
-Transit| | _________ _________ |
-etc | |--|Router3|---|----|----------|Router4|---WAN-|
- | | --------- | | --------- |
- | | | | |
- | | | | |
- ------------------ [NTP] [DNS] |
- |
- |
- |
- |
- __________________ |
-Peer 1-| | |
-Peer 2-| | |
-Peer 3-| Switch | |
-Transit| | _________ _________ |
-etc | |--|Router5|---|----|----------|Router6|---WAN-|
- | | --------- | | --------- |
- | | | | |
- | | | | |
- ------------------ [NTP] [DNS] |
- |
- |
- |
-
-
-
-
-
-
-
-
-Hardie Informational [Page 8]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
- |
- __________________ |
-Peer 1-| | |
-Peer 2-| | |
-Peer 3-| Switch | |
-Transit| | _________ _________ |
-etc | |--|Router7|---|----|----------|Router8|---WAN-|
- | | --------- | | ---------
- | | | |
- | | | |
- ------------------ [NTP] [DNS]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie Informational [Page 9]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
-7. Editor's Address
-
- Ted Hardie
- Nominum, Inc.
- 2385 Bay Road.
- Redwood City, CA 94063
-
- Phone: 1.650.381.6226
- EMail: Ted.Hardie@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie Informational [Page 10]
-
-RFC 3258 Distributing Authoritative Name Servers April 2002
-
-
-8. Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie Informational [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3363.txt b/contrib/bind9/doc/rfc/rfc3363.txt
deleted file mode 100644
index 9d7a39c208cb4..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3363.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Bush
-Request for Comments: 3363 A. Durand
-Updates: 2673, 2874 B. Fink
-Category: Informational O. Gudmundsson
- T. Hain
- Editors
- August 2002
-
-
- Representing Internet Protocol version 6 (IPv6)
- Addresses in the Domain Name System (DNS)
-
-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 (2002). All Rights Reserved.
-
-Abstract
-
- This document clarifies and updates the standards status of RFCs that
- define direct and reverse map of IPv6 addresses in DNS. This
- document moves the A6 and Bit label specifications to experimental
- status.
-
-1. Introduction
-
- The IETF had begun the process of standardizing two different address
- formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
- are at proposed standard. This had led to confusion and conflicts on
- which one to deploy. It is important for deployment that any
- confusion in this area be cleared up, as there is a feeling in the
- community that having more than one choice will lead to delays in the
- deployment of IPv6. The goal of this document is to clarify the
- situation.
-
- This document also discusses issues relating to the usage of Binary
- Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
-
- This document is based on extensive technical discussion on various
- relevant working groups mailing lists and a joint DNSEXT and NGTRANS
- meeting at the 51st IETF in August 2001. This document attempts to
- capture the sense of the discussions and reflect them in this
- document to represent the consensus of the community.
-
-
-
-Bush, et. al. Informational [Page 1]
-
-RFC 3363 Representation of IPv6 Addresses in DNS August 2002
-
-
- The main arguments and the issues are covered in a separate document
- [RFC3364] that reflects the current understanding of the issues.
- This document summarizes the outcome of these discussions.
-
- The issue of the root of reverse IPv6 address map is outside the
- scope of this document and is covered in a different document
- [RFC3152].
-
-1.1 Standards Action Taken
-
- This document changes the status of RFCs 2673 and 2874 from Proposed
- Standard to Experimental.
-
-2. IPv6 Addresses: AAAA RR vs A6 RR
-
- Working group consensus as perceived by the chairs of the DNSEXT and
- NGTRANS working groups is that:
-
- a) AAAA records are preferable at the moment for production
- deployment of IPv6, and
-
- b) that A6 records have interesting properties that need to be better
- understood before deployment.
-
- c) It is not known if the benefits of A6 outweigh the costs and
- risks.
-
-2.1 Rationale
-
- There are several potential issues with A6 RRs that stem directly
- from the feature that makes them different from AAAA RRs: the ability
- to build up addresses via chaining.
-
- Resolving a chain of A6 RRs involves resolving a series of what are
- nearly-independent queries. Each of these sub-queries takes some
- non-zero amount of time, unless the answer happens to be in the
- resolver's local cache already. Other things being equal, we expect
- that the time it takes to resolve an N-link chain of A6 RRs will be
- roughly proportional to N. What data we have suggests that users are
- already impatient with the length of time it takes to resolve A RRs
- in the IPv4 Internet, which suggests that users are not likely to be
- patient with significantly longer delays in the IPv6 Internet, but
- terminating queries prematurely is both a waste of resources and
- another source of user frustration. Thus, we are forced to conclude
- that indiscriminate use of long A6 chains is likely to lead to
- increased user frustration.
-
-
-
-
-
-Bush, et. al. Informational [Page 2]
-
-RFC 3363 Representation of IPv6 Addresses in DNS August 2002
-
-
- The probability of failure during the process of resolving an N-link
- A6 chain also appears to be roughly proportional to N, since each of
- the queries involved in resolving an A6 chain has roughly the same
- probability of failure as a single AAAA query.
-
- Last, several of the most interesting potential applications for A6
- RRs involve situations where the prefix name field in the A6 RR
- points to a target that is not only outside the DNS zone containing
- the A6 RR, but is administered by a different organization entirely.
- While pointers out of zone are not a problem per se, experience both
- with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
- pointers to other organizations are often not maintained properly,
- perhaps because they're less susceptible to automation than pointers
- within a single organization would be.
-
-2.2 Recommended Standard Action
-
- Based on the perceived consensus, this document recommends that RFC
- 1886 stay on standards track and be advanced, while moving RFC 2874
- to Experimental status.
-
-3. Bitlabels in the Reverse DNS Tree
-
- RFC 2673 defines a new DNS label type. This was the first new type
- defined since RFC 1035 [RFC1035]. Since the development of 2673 it
- has been learned that deployment of a new type is difficult since DNS
- servers that do not support bitlabels reject queries containing bit
- labels as being malformed. The community has also indicated that
- this new label type is not needed for mapping reverse addresses.
-
-3.1 Rationale
-
- The hexadecimal text representation of IPv6 addresses appears to be
- capable of expressing all of the delegation schemes that we expect to
- be used in the DNS reverse tree.
-
-3.2 Recommended Standard Action
-
- RFC 2673 standard status is to be changed from Proposed to
- Experimental. Future standardization of these documents is to be
- done by the DNSEXT working group or its successor.
-
-
-
-
-
-
-
-
-
-
-Bush, et. al. Informational [Page 3]
-
-RFC 3363 Representation of IPv6 Addresses in DNS August 2002
-
-
-4. DNAME in IPv6 Reverse Tree
-
- The issues for DNAME in the reverse mapping tree appears to be
- closely tied to the need to use fragmented A6 in the main tree: if
- one is necessary, so is the other, and if one isn't necessary, the
- other isn't either. Therefore, in moving RFC 2874 to experimental,
- the intent of this document is that use of DNAME RRs in the reverse
- tree be deprecated.
-
-5. Acknowledgments
-
- This document is based on input from many members of the various IETF
- working groups involved in this issues. Special thanks go to the
- people that prepared reading material for the joint DNSEXT and
- NGTRANS working group meeting at the 51st IETF in London, Rob
- Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
- Christian Huitema. Number of other people have made number of
- comments on mailing lists about this issue including Andrew W.
- Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
- Savola, Paul Vixie.
-
-6. Security Considerations
-
- As this document specifies a course of action, there are no direct
- security considerations. There is an indirect security impact of the
- choice, in that the relationship between A6 and DNSSEC is not well
- understood throughout the community, while the choice of AAAA does
- leads to a model for use of DNSSEC in IPv6 networks which parallels
- current IPv4 practice.
-
-7. IANA Considerations
-
- None.
-
-Normative References
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP
- version 6", RFC 1886, December 1995.
-
- [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
- RFC 2673, August 1999.
-
- [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
- IPv6 Address Aggregation and Renumbering", RFC 2874, July
- 2000.
-
-
-
-Bush, et. al. Informational [Page 4]
-
-RFC 3363 Representation of IPv6 Addresses in DNS August 2002
-
-
- [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
- August 2001.
-
-Informative References
-
- [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
- Support for Internet Protocol version 6 (IPv6)", RFC 3364,
- August 2002.
-
-Editors' Addresses
-
- Randy Bush
- EMail: randy@psg.com
-
-
- Alain Durand
- EMail: alain.durand@sun.com
-
-
- Bob Fink
- EMail: fink@es.net
-
-
- Olafur Gudmundsson
- EMail: ogud@ogud.com
-
-
- Tony Hain
- EMail: hain@tndh.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush, et. al. Informational [Page 5]
-
-RFC 3363 Representation of IPv6 Addresses in DNS August 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush, et. al. Informational [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3364.txt b/contrib/bind9/doc/rfc/rfc3364.txt
deleted file mode 100644
index 189c0d2aa055a..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3364.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Austein
-Request for Comments: 3364 Bourgeois Dilettant
-Updates: 2673, 2874 August 2002
-Category: Informational
-
-
- Tradeoffs in Domain Name System (DNS) Support
- for Internet Protocol version 6 (IPv6)
-
-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 (2002). All Rights Reserved.
-
-Abstract
-
- The IETF has two different proposals on the table for how to do DNS
- support for IPv6, and has thus far failed to reach a clear consensus
- on which approach is better. This note attempts to examine the pros
- and cons of each approach, in the hope of clarifying the debate so
- that we can reach closure and move on.
-
-Introduction
-
- RFC 1886 [RFC1886] specified straightforward mechanisms to support
- IPv6 addresses in the DNS. These mechanisms closely resemble the
- mechanisms used to support IPv4, with a minor improvement to the
- reverse mapping mechanism based on experience with CIDR. RFC 1886 is
- currently listed as a Proposed Standard.
-
- RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
- addresses in the DNS. These mechanisms provide new features that
- make it possible for an IPv6 address stored in the DNS to be broken
- up into multiple DNS resource records in ways that can reflect the
- network topology underlying the address, thus making it possible for
- the data stored in the DNS to reflect certain kinds of network
- topology changes or routing architectures that are either impossible
- or more difficult to represent without these mechanisms. RFC 2874 is
- also currently listed as a Proposed Standard.
-
-
-
-
-
-
-
-Austein Informational [Page 1]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
- Both of these Proposed Standards were the output of the IPNG Working
- Group. Both have been implemented, although implementation of
- [RFC1886] is more widespread, both because it was specified earlier
- and because it's simpler to implement.
-
- There's little question that the mechanisms proposed in [RFC2874] are
- more general than the mechanisms proposed in [RFC1886], and that
- these enhanced mechanisms might be valuable if IPv6's evolution goes
- in certain directions. The questions are whether we really need the
- more general mechanism, what new usage problems might come along with
- the enhanced mechanisms, and what effect all this will have on IPv6
- deployment.
-
- The one thing on which there does seem to be widespread agreement is
- that we should make up our minds about all this Real Soon Now.
-
-Main Advantages of Going with A6
-
- While the A6 RR proposed in [RFC2874] is very general and provides a
- superset of the functionality provided by the AAAA RR in [RFC1886],
- many of the features of A6 can also be implemented with AAAA RRs via
- preprocessing during zone file generation.
-
- There is one specific area where A6 RRs provide something that cannot
- be provided using AAAA RRs: A6 RRs can represent addresses in which a
- prefix portion of the address can change without any action (or
- perhaps even knowledge) by the parties controlling the DNS zone
- containing the terminal portion (least significant bits) of the
- address. This includes both so-called "rapid renumbering" scenarios
- (where an entire network's prefix may change very quickly) and
- routing architectures such as the former "GSE" proposal [GSE] (where
- the "routing goop" portion of an address may be subject to change
- without warning). A6 RRs do not completely remove the need to update
- leaf zones during all renumbering events (for example, changing ISPs
- would usually require a change to the upward delegation pointer), but
- careful use of A6 RRs could keep the number of RRs that need to
- change during such an event to a minimum.
-
- Note that constructing AAAA RRs via preprocessing during zone file
- generation requires exactly the sort of information that A6 RRs store
- in the DNS. This begs the question of where the hypothetical
- preprocessor obtains that information if it's not getting it from the
- DNS.
-
- Note also that the A6 RR, when restricted to its zero-length-prefix
- form ("A6 0"), is semantically equivalent to an AAAA RR (with one
- "wasted" octet in the wire representation), so anything that can be
- done with an AAAA RR can also be done with an A6 RR.
-
-
-
-Austein Informational [Page 2]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
-Main Advantages of Going with AAAA
-
- The AAAA RR proposed in [RFC1886], while providing only a subset of
- the functionality provided by the A6 RR proposed in [RFC2874], has
- two main points to recommend it:
-
- - AAAA RRs are essentially identical (other than their length) to
- IPv4's A RRs, so we have more than 15 years of experience to help
- us predict the usage patterns, failure scenarios and so forth
- associated with AAAA RRs.
-
- - The AAAA RR is "optimized for read", in the sense that, by storing
- a complete address rather than making the resolver fetch the
- address in pieces, it minimizes the effort involved in fetching
- addresses from the DNS (at the expense of increasing the effort
- involved in injecting new data into the DNS).
-
-Less Compelling Arguments in Favor of A6
-
- Since the A6 RR allows a zone administrator to write zone files whose
- description of addresses maps to the underlying network topology, A6
- RRs can be construed as a "better" way of representing addresses than
- AAAA. This may well be a useful capability, but in and of itself
- it's more of an argument for better tools for zone administrators to
- use when constructing zone files than a justification for changing
- the resolution protocol used on the wire.
-
-Less Compelling Arguments in Favor of AAAA
-
- Some of the pressure to go with AAAA instead of A6 appears to be
- based on the wider deployment of AAAA. Since it is possible to
- construct transition tools (see discussion of AAAA synthesis, later
- in this note), this does not appear to be a compelling argument if A6
- provides features that we really need.
-
- Another argument in favor of AAAA RRs over A6 RRs appears to be that
- the A6 RR's advanced capabilities increase the number of ways in
- which a zone administrator could build a non-working configuration.
- While operational issues are certainly important, this is more of
- argument that we need better tools for zone administrators than it is
- a justification for turning away from A6 if A6 provides features that
- we really need.
-
-
-
-
-
-
-
-
-
-Austein Informational [Page 3]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
-Potential Problems with A6
-
- The enhanced capabilities of the A6 RR, while interesting, are not in
- themselves justification for choosing A6 if we don't really need
- those capabilities. The A6 RR is "optimized for write", in the sense
- that, by making it possible to store fragmented IPv6 addresses in the
- DNS, it makes it possible to reduce the effort that it takes to
- inject new data into the DNS (at the expense of increasing the effort
- involved in fetching data from the DNS). This may be justified if we
- expect the effort involved in maintaining AAAA-style DNS entries to
- be prohibitive, but in general, we expect the DNS data to be read
- more frequently than it is written, so we need to evaluate this
- particular tradeoff very carefully.
-
- There are also several potential issues with A6 RRs that stem
- directly from the feature that makes them different from AAAA RRs:
- the ability to build up address via chaining.
-
- Resolving a chain of A6 RRs involves resolving a series of what are
- almost independent queries, but not quite. Each of these sub-queries
- takes some non-zero amount of time, unless the answer happens to be
- in the resolver's local cache already. Assuming that resolving an
- AAAA RR takes time T as a baseline, we can guess that, on the
- average, it will take something approaching time N*T to resolve an
- N-link chain of A6 RRs, although we would expect to see a fairly good
- caching factor for the A6 fragments representing the more significant
- bits of an address. This leaves us with two choices, neither of
- which is very good: we can decrease the amount of time that the
- resolver is willing to wait for each fragment, or we can increase the
- amount of time that a resolver is willing to wait before returning
- failure to a client. What little data we have on this subject
- suggests that users are already impatient with the length of time it
- takes to resolve A RRs in the IPv4 Internet, which suggests that they
- are not likely to be patient with significantly longer delays in the
- IPv6 Internet. At the same time, terminating queries prematurely is
- both a waste of resources and another source of user frustration.
- Thus, we are forced to conclude that indiscriminate use of long A6
- chains is likely to lead to problems.
-
- To make matters worse, the places where A6 RRs are likely to be most
- critical for rapid renumbering or GSE-like routing are situations
- where the prefix name field in the A6 RR points to a target that is
- not only outside the DNS zone containing the A6 RR, but is
- administered by a different organization (for example, in the case of
- an end user's site, the prefix name will most likely point to a name
- belonging to an ISP that provides connectivity for the site). While
- pointers out of zone are not a problem per se, pointers to other
- organizations are somewhat more difficult to maintain and less
-
-
-
-Austein Informational [Page 4]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
- susceptible to automation than pointers within a single organization
- would be. Experience both with glue RRs and with PTR RRs in the IN-
- ADDR.ARPA tree suggests that many zone administrators do not really
- understand how to set up and maintain these pointers properly, and we
- have no particular reason to believe that these zone administrators
- will do a better job with A6 chains than they do today. To be fair,
- however, the alternative case of building AAAA RRs via preprocessing
- before loading zones has many of the same problems; at best, one can
- claim that using AAAA RRs for this purpose would allow DNS clients to
- get the wrong answer somewhat more efficiently than with A6 RRs.
-
- Finally, assuming near total ignorance of how likely a query is to
- fail, the probability of failure with an N-link A6 chain would appear
- to be roughly proportional to N, since each of the queries involved
- in resolving an A6 chain would have the same probability of failure
- as a single AAAA query. Note again that this comment applies to
- failures in the the process of resolving a query, not to the data
- obtained via that process. Arguably, in an ideal world, A6 RRs would
- increase the probability of the answer a client (finally) gets being
- right, assuming that nothing goes wrong in the query process, but we
- have no real idea how to quantify that assumption at this point even
- to the hand-wavey extent used elsewhere in this note.
-
- One potential problem that has been raised in the past regarding A6
- RRs turns out not to be a serious issue. The A6 design includes the
- possibility of there being more than one A6 RR matching the prefix
- name portion of a leaf A6 RR. That is, an A6 chain may not be a
- simple linked list, it may in fact be a tree, where each branch
- represents a possible prefix. Some critics of A6 have been concerned
- that this will lead to a wild expansion of queries, but this turns
- out not to be a problem if a resolver simply follows the "bounded
- work per query" rule described in RFC 1034 (page 35). That rule
- applies to all work resulting from attempts to process a query,
- regardless of whether it's a simple query, a CNAME chain, an A6 tree,
- or an infinite loop. The client may not get back a useful answer in
- cases where the zone has been configured badly, but a proper
- implementation should not produce a query explosion as a result of
- processing even the most perverse A6 tree, chain, or loop.
-
-Interactions with DNSSEC
-
- One of the areas where AAAA and A6 RRs differ is in the precise
- details of how they interact with DNSSEC. The following comments
- apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
- semantically equivalent to AAAA RRs).
-
-
-
-
-
-
-Austein Informational [Page 5]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
- Other things being equal, the time it takes to re-sign all of the
- addresses in a zone after a renumbering event is longer with AAAA RRs
- than with A6 RRs (because each address record has to be re-signed
- rather than just signing a common prefix A6 RR and a few A6 0 RRs
- associated with the zone's name servers). Note, however, that in
- general this does not present a serious scaling problem, because the
- re-signing is performed in the leaf zones.
-
- Other things being equal, there's more work involved in verifying the
- signatures received back for A6 RRs, because each address fragment
- has a separate associated signature. Similarly, a DNS message
- containing a set of A6 address fragments and their associated
- signatures will be larger than the equivalent packet with a single
- AAAA (or A6 0) and a single associated signature.
-
- Since AAAA RRs cannot really represent rapid renumbering or GSE-style
- routing scenarios very well, it should not be surprising that DNSSEC
- signatures of AAAA RRs are also somewhat problematic. In cases where
- the AAAA RRs would have to be changing very quickly to keep up with
- prefix changes, the time required to re-sign the AAAA RRs may be
- prohibitive.
-
- Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
- 333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
- BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
- 1024-bit RSA signatures per second. Extrapolating from this,
- assuming one A RR, one AAAA RR, and one NXT RR per host, this
- suggests that it would take this laptop a few hours to sign a zone
- listing 10**5 hosts, or about a day to sign a zone listing 10**6
- hosts using AAAA RRs.
-
- This suggests that the additional effort of re-signing a large zone
- full of AAAA RRs during a re-numbering event, while noticeable, is
- only likely to be prohibitive in the rapid renumbering case where
- AAAA RRs don't work well anyway.
-
-Interactions with Dynamic Update
-
- DNS dynamic update appears to work equally well for AAAA or A6 RRs,
- with one minor exception: with A6 RRs, the dynamic update client
- needs to know the prefix length and prefix name. At present, no
- mechanism exists to inform a dynamic update client of these values,
- but presumably such a mechanism could be provided via an extension to
- DHCP, or some other equivalent could be devised.
-
-
-
-
-
-
-
-Austein Informational [Page 6]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
-Transition from AAAA to A6 Via AAAA Synthesis
-
- While AAAA is at present more widely deployed than A6, it is possible
- to transition from AAAA-aware DNS software to A6-aware DNS software.
- A rough plan for this was presented at IETF-50 in Minneapolis and has
- been discussed on the ipng mailing list. So if the IETF concludes
- that A6's enhanced capabilities are necessary, it should be possible
- to transition from AAAA to A6.
-
- The details of this transition have been left to a separate document,
- but the general idea is that the resolver that is performing
- iterative resolution on behalf of a DNS client program could
- synthesize AAAA RRs representing the result of performing the
- equivalent A6 queries. Note that in this case it is not possible to
- generate an equivalent DNSSEC signature for the AAAA RR, so clients
- that care about performing DNSSEC validation for themselves would
- have to issue A6 queries directly rather than relying on AAAA
- synthesis.
-
-Bitlabels
-
- While the differences between AAAA and A6 RRs have generated most of
- the discussion to date, there are also two proposed mechanisms for
- building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
- ADDR.ARPA tree).
-
- [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
- mechanism used for IPv4 addresses: the RR name is the hexadecimal
- representation of the IPv6 address, reversed and concatenated with a
- well-known suffix, broken up with a dot between each hexadecimal
- digit. The resulting DNS names are somewhat tedious for humans to
- type, but are very easy for programs to generate. Making each
- hexadecimal digit a separate label means that delegation on arbitrary
- bit boundaries will result in a maximum of 16 NS RRsets per label
- level; again, the mechanism is somewhat tedious for humans, but is
- very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one
- place where this scheme is weak is in handling delegations in the
- least significant label; however, since there appears to be no real
- need to delegate the least significant four bits of an IPv6 address,
- this does not appear to be a serious restriction.
-
- [RFC2874] proposed a radically different way of naming entries in the
- reverse mapping tree: rather than using textual representations of
- addresses, it proposes to use a new kind of DNS label (a "bit label")
- to represent binary addresses directly in the DNS. This has the
- advantage of being significantly more compact than the textual
- representation, and arguably might have been a better solution for
- DNS to use for this purpose if it had been designed into the protocol
-
-
-
-Austein Informational [Page 7]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
- from the outset. Unfortunately, experience to date suggests that
- deploying a new DNS label type is very hard: all of the DNS name
- servers that are authoritative for any portion of the name in
- question must be upgraded before the new label type can be used, as
- must any resolvers involved in the resolution process. Any name
- server that has not been upgraded to understand the new label type
- will reject the query as being malformed.
-
- Since the main benefit of the bit label approach appears to be an
- ability that we don't really need (delegation in the least
- significant four bits of an IPv6 address), and since the upgrade
- problem is likely to render bit labels unusable until a significant
- portion of the DNS code base has been upgraded, it is difficult to
- escape the conclusion that the textual solution is good enough.
-
-DNAME RRs
-
- [RFC2874] also proposes using DNAME RRs as a way of providing the
- equivalent of A6's fragmented addresses in the reverse mapping tree.
- That is, by using DNAME RRs, one can write zone files for the reverse
- mapping tree that have the same ability to cope with rapid
- renumbering or GSE-style routing that the A6 RR offers in the main
- portion of the DNS tree. Consequently, the need to use DNAME in the
- reverse mapping tree appears to be closely tied to the need to use
- fragmented A6 in the main tree: if one is necessary, so is the other,
- and if one isn't necessary, the other isn't either.
-
- Other uses have also been proposed for the DNAME RR, but since they
- are outside the scope of the IPv6 address discussion, they will not
- be addressed here.
-
-Recommendation
-
- Distilling the above feature comparisons down to their key elements,
- the important questions appear to be:
-
- (a) Is IPv6 going to do rapid renumbering or GSE-like routing?
-
- (b) Is the reverse mapping tree for IPv6 going to require delegation
- in the least significant four bits of the address?
-
- Question (a) appears to be the key to the debate. This is really a
- decision for the IPv6 community to make, not the DNS community.
-
- Question (b) is also for the IPv6 community to make, but it seems
- fairly obvious that the answer is "no".
-
-
-
-
-
-Austein Informational [Page 8]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
- Recommendations based on these questions:
-
- (1) If the IPv6 working groups seriously intend to specify and deploy
- rapid renumbering or GSE-like routing, we should transition to
- using the A6 RR in the main tree and to using DNAME RRs as
- necessary in the reverse tree.
-
- (2) Otherwise, we should keep the simpler AAAA solution in the main
- tree and should not use DNAME RRs in the reverse tree.
-
- (3) In either case, the reverse tree should use the textual
- representation described in [RFC1886] rather than the bit label
- representation described in [RFC2874].
-
- (4) If we do go to using A6 RRs in the main tree and to using DNAME
- RRs in the reverse tree, we should write applicability statements
- and implementation guidelines designed to discourage excessively
- complex uses of these features; in general, any network that can
- be described adequately using A6 0 RRs and without using DNAME
- RRs should be described that way, and the enhanced features
- should be used only when absolutely necessary, at least until we
- have much more experience with them and have a better
- understanding of their failure modes.
-
-Security Considerations
-
- This note compares two mechanisms with similar security
- characteristics, but there are a few security implications to the
- choice between these two mechanisms:
-
- (1) The two mechanisms have similar but not identical interactions
- with DNSSEC. Please see the section entitled "Interactions with
- DNSSEC" (above) for a discussion of these issues.
-
- (2) To the extent that operational complexity is the enemy of
- security, the tradeoffs in operational complexity discussed
- throughout this note have an impact on security.
-
- (3) To the extent that protocol complexity is the enemy of security,
- the additional protocol complexity of [RFC2874] as compared to
- [RFC1886] has some impact on security.
-
-IANA Considerations
-
- None, since all of these RR types have already been allocated.
-
-
-
-
-
-
-Austein Informational [Page 9]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
-Acknowledgments
-
- This note is based on a number of discussions both public and private
- over a period of (at least) eight years, but particular thanks go to
- Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
- Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
- and Sue Thomson, none of whom are responsible for what the author did
- with their ideas.
-
-References
-
- [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support
- IP version 6", RFC 1886, December 1995.
-
- [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
- IPv6 Address Aggregation and Renumbering", RFC 2874,
- July 2000.
-
- [Sommerfeld] Private message to the author from Bill Sommerfeld dated
- 21 March 2001, summarizing the result of experiments he
- performed on a copy of the MIT.EDU zone.
-
- [GSE] "GSE" was an evolution of the so-called "8+8" proposal
- discussed by the IPng working group in 1996 and 1997.
- The GSE proposal itself was written up as an Internet-
- Draft, which has long since expired. Readers interested
- in the details and history of GSE should review the IPng
- working group's mailing list archives and minutes from
- that period.
-
-Author's Address
-
- Rob Austein
-
- EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Informational [Page 10]
-
-RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Informational [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3425.txt b/contrib/bind9/doc/rfc/rfc3425.txt
deleted file mode 100644
index 707cafd18aa1f..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3425.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Lawrence
-Request for Comments: 3425 Nominum
-Updates: 1035 November 2002
-Category: Standards Track
-
-
- Obsoleting IQUERY
-
-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 (2002). All Rights Reserved.
-
-Abstract
-
- The IQUERY method of performing inverse DNS lookups, specified in RFC
- 1035, has not been generally implemented and has usually been
- operationally disabled where it has been implemented. Both reflect a
- general view in the community that the concept was unwise and that
- the widely-used alternate approach of using pointer (PTR) queries and
- reverse-mapping records is preferable. Consequently, this document
- deprecates the IQUERY operation, declaring it entirely obsolete.
- This document updates RFC 1035.
-
-1 - Introduction
-
- As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
- queries is used to look up the name(s) which are associated with the
- given value. The value being sought is provided in the query's
- answer section and the response fills in the question section with
- one or more 3-tuples of type, name and class.
-
- As noted in [RFC1035], section 6.4.3, inverse query processing can
- put quite an arduous burden on a server. A server would need to
- perform either an exhaustive search of its database or maintain a
- separate database that is keyed by the values of the primary
- database. Both of these approaches could strain system resource use,
- particularly for servers that are authoritative for millions of
- names.
-
-
-
-
-
-Lawrence Standards Track [Page 1]
-
-RFC 3425 Obsoleting IQUERY November 2002
-
-
- Response packets from these megaservers could be exceptionally large,
- and easily run into megabyte sizes. For example, using IQUERY to
- find every domain that is delegated to one of the nameservers of a
- large ISP could return tens of thousands of 3-tuples in the question
- section. This could easily be used to launch denial of service
- attacks.
-
- Operators of servers that do support IQUERY in some form (such as
- very old BIND 4 servers) generally opt to disable it. This is
- largely due to bugs in insufficiently-exercised code, or concerns
- about exposure of large blocks of names in their zones by probes such
- as inverse MX queries.
-
- IQUERY is also somewhat inherently crippled by being unable to tell a
- requester where it needs to go to get the information that was
- requested. The answer is very specific to the single server that was
- queried. This is sometimes a handy diagnostic tool, but apparently
- not enough so that server operators like to enable it, or request
- implementation where it is lacking.
-
- No known clients use IQUERY to provide any meaningful service. The
- only common reverse mapping support on the Internet, mapping address
- records to names, is provided through the use of pointer (PTR)
- records in the in-addr.arpa tree and has served the community well
- for many years.
-
- Based on all of these factors, this document recommends that the
- IQUERY operation for DNS servers be officially obsoleted.
-
-2 - Requirements
-
- The key word "SHOULD" in this document is to be interpreted as
- described in BCP 14, RFC 2119, namely that there may exist valid
- reasons to ignore a particular item, but the full implications must
- be understood and carefully weighed before choosing a different
- course.
-
-3 - Effect on RFC 1035
-
- The effect of this document is to change the definition of opcode 1
- from that originally defined in section 4.1.1 of RFC 1035, and to
- entirely supersede section 6.4 (including subsections) of RFC 1035.
-
- The definition of opcode 1 is hereby changed to:
-
- "1 an inverse query (IQUERY) (obsolete)"
-
-
-
-
-
-Lawrence Standards Track [Page 2]
-
-RFC 3425 Obsoleting IQUERY November 2002
-
-
- The text in section 6.4 of RFC 1035 is now considered obsolete. The
- following is an applicability statement regarding the IQUERY opcode:
-
- Inverse queries using the IQUERY opcode were originally described as
- the ability to look up the names that are associated with a
- particular Resource Record (RR). Their implementation was optional
- and never achieved widespread use. Therefore IQUERY is now obsolete,
- and name servers SHOULD return a "Not Implemented" error when an
- IQUERY request is received.
-
-4 - Security Considerations
-
- Since this document obsoletes an operation that was once available,
- it is conceivable that someone was using it as the basis of a
- security policy. However, since the most logical course for such a
- policy to take in the face of a lack of positive response from a
- server is to deny authentication/authorization, it is highly unlikely
- that removing support for IQUERY will open any new security holes.
-
- Note that if IQUERY is not obsoleted, securing the responses with DNS
- Security (DNSSEC) is extremely difficult without out-on-the-fly
- digital signing.
-
-5 - IANA Considerations
-
- The IQUERY opcode of 1 should be permanently retired, not to be
- assigned to any future opcode.
-
-6 - Acknowledgments
-
- Olafur Gudmundsson instigated this action. Matt Crawford, John
- Klensin, Erik Nordmark and Keith Moore contributed some improved
- wording in how to handle obsoleting functionality described by an
- Internet Standard.
-
-7 - References
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [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.
-
-
-
-
-
-
-Lawrence Standards Track [Page 3]
-
-RFC 3425 Obsoleting IQUERY November 2002
-
-
-8 - Author's Address
-
- David C Lawrence
- Nominum, Inc.
- 2385 Bay Rd
- Redwood City CA 94063
- USA
-
- Phone: +1.650.779.6042
- EMail: tale@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence Standards Track [Page 4]
-
-RFC 3425 Obsoleting IQUERY November 2002
-
-
-9 - Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence Standards Track [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc3445.txt b/contrib/bind9/doc/rfc/rfc3445.txt
deleted file mode 100644
index 67f9b2d6e5735..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3445.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Massey
-Request for Comments: 3445 USC/ISI
-Updates: 2535 S. Rose
-Category: Standards Track NIST
- December 2002
-
-
- Limiting the Scope of the KEY Resource Record (RR)
-
-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 (2002). All Rights Reserved.
-
-Abstract
-
- This document limits the Domain Name System (DNS) KEY Resource Record
- (RR) to only keys used by the Domain Name System Security Extensions
- (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC
- keys and arbitrary application keys. Storing both DNSSEC and
- application keys with the same record type is a mistake. This
- document removes application keys from the KEY record by redefining
- the Protocol Octet field in the KEY RR Data. As a result of removing
- application keys, all but one of the flags in the KEY record become
- unnecessary and are redefined. Three existing application key sub-
- types are changed to reserved, but the format of the KEY record is
- not changed. This document updates RFC 2535.
-
-1. Introduction
-
- This document limits the scope of the KEY Resource Record (RR). The
- KEY RR was defined in [3] and used resource record sub-typing to hold
- arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
- This document eliminates the existing Email, IPSEC, and TLS sub-types
- and prohibits the introduction of new sub-types. DNSSEC will be the
- only allowable sub-type for the KEY RR (hence sub-typing is
- essentially eliminated) and all but one of the KEY RR flags are also
- eliminated.
-
-
-
-
-
-
-Massey & Rose Standards Track [Page 1]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
- Section 2 presents the motivation for restricting the KEY record and
- Section 3 defines the revised KEY RR. Sections 4 and 5 summarize the
- changes from RFC 2535 and discuss backwards compatibility. It is
- important to note that this document restricts the use of the KEY RR
- and simplifies the flags, but does not change the definition or use
- of DNSSEC keys.
-
- 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].
-
-2. Motivation for Restricting the KEY RR
-
- The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
- Algorithm type, and a Public Key. The Protocol Octet identifies the
- KEY RR sub-type. DNSSEC public keys are stored in the KEY RR using a
- Protocol Octet value of 3. Email, IPSEC, and TLS keys were also
- stored in the KEY RR and used Protocol Octet values of 1,2, and 4
- (respectively). Protocol Octet values 5-254 were available for
- assignment by IANA and values were requested (but not assigned) for
- applications such as SSH.
-
- Any use of sub-typing has inherent limitations. A resolver can not
- specify the desired sub-type in a DNS query and most DNS operations
- apply only to resource records sets. For example, a resolver can not
- directly request the DNSSEC subtype KEY RRs. Instead, the resolver
- has to request all KEY RRs associated with a DNS name and then search
- the set for the desired DNSSEC sub-type. DNSSEC signatures also
- apply to the set of all KEY RRs associated with the DNS name,
- regardless of sub-type.
-
- In the case of the KEY RR, the inherent sub-type limitations are
- exacerbated since the sub-type is used to distinguish between DNSSEC
- keys and application keys. DNSSEC keys and application keys differ
- in virtually every respect and Section 2.1 discusses these
- differences in more detail. Combining these very different types of
- keys into a single sub-typed resource record adds unnecessary
- complexity and increases the potential for implementation and
- deployment errors. Limited experimental deployment has shown that
- application keys stored in KEY RRs are problematic.
-
- This document addresses these issues by removing all application keys
- from the KEY RR. Note that the scope of this document is strictly
- limited to the KEY RR and this document does not endorse or restrict
- the storage of application keys in other, yet undefined, resource
- records.
-
-
-
-
-
-Massey & Rose Standards Track [Page 2]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
-2.1 Differences Between DNSSEC and Application Keys
-
- DNSSEC keys are an essential part of the DNSSEC protocol and are used
- by both name servers and resolvers in order to perform DNS tasks. A
- DNS zone key, used to sign and authenticate RR sets, is the most
- common example of a DNSSEC key. SIG(0) [4] and TKEY [3] also use
- DNSSEC keys.
-
- Application keys such as Email keys, IPSEC keys, and TLS keys are
- simply another type of data. These keys have no special meaning to a
- name server or resolver.
-
- The following table summarizes some of the differences between DNSSEC
- keys and application keys:
-
- 1. They serve different purposes.
-
- 2. They are managed by different administrators.
-
- 3. They are authenticated according to different rules.
-
- 4. Nameservers use different rules when including them in
- responses.
-
- 5. Resolvers process them in different ways.
-
- 6. Faults/key compromises have different consequences.
-
- 1. The purpose of a DNSSEC key is to sign resource records
- associated with a DNS zone (or generate DNS transaction signatures in
- the case of SIG(0)/TKEY). But the purpose of an application key is
- specific to the application. Application keys, such as PGP/email,
- IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
- the purpose and proper use of application keys is outside the scope
- of DNS.
-
- 2. DNSSEC keys are managed by DNS administrators, but application
- keys are managed by application administrators. The DNS zone
- administrator determines the key lifetime, handles any suspected key
- compromises, and manages any DNSSEC key changes. Likewise, the
- application administrator is responsible for the same functions for
- the application keys related to the application. For example, a user
- typically manages her own PGP key and a server manages its own TLS
- key. Application key management tasks are outside the scope of DNS
- administration.
-
-
-
-
-
-
-Massey & Rose Standards Track [Page 3]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
- 3. DNSSEC zone keys are used to authenticate application keys, but
- by definition, application keys are not allowed to authenticate DNS
- zone keys. A DNS zone key is either configured as a trusted key or
- authenticated by constructing a chain of trust in the DNS hierarchy.
- To participate in the chain of trust, a DNS zone needs to exchange
- zone key information with its parent zone [3]. Application keys are
- not configured as trusted keys in the DNS and are never part of any
- DNS chain of trust. Application key data is not needed by the parent
- and does not need to be exchanged with the parent zone for secure DNS
- resolution to work. A resolver considers an application key RRset as
- authenticated DNS information if it has a valid signature from the
- local DNS zone keys, but applications could impose additional
- security requirements before the application key is accepted as
- authentic for use with the application.
-
- 4. It may be useful for nameservers to include DNS zone keys in the
- additional section of a response, but application keys are typically
- not useful unless they have been specifically requested. For
- example, it could be useful to include the example.com zone key along
- with a response that contains the www.example.com A record and SIG
- record. A secure resolver will need the example.com zone key in
- order to check the SIG and authenticate the www.example.com A record.
- It is typically not useful to include the IPSEC, email, and TLS keys
- along with the A record. Note that by placing application keys in
- the KEY record, a resolver would need the IPSEC, email, TLS, and
- other key associated with example.com if the resolver intends to
- authenticate the example.com zone key (since signatures only apply to
- the entire KEY RR set). Depending on the number of protocols
- involved, the KEY RR set could grow unwieldy for resolvers, and DNS
- administrators to manage.
-
- 5. DNS zone keys require special handling by resolvers, but
- application keys are treated the same as any other type of DNS data.
- The DNSSEC keys are of no value to end applications, unless the
- applications plan to do their own DNS authentication. By definition,
- secure resolvers are not allowed to use application keys as part of
- the authentication process. Application keys have no unique meaning
- to resolvers and are only useful to the application requesting the
- key. Note that if sub-types are used to identify the application
- key, then either the interface to the resolver needs to specify the
- sub-type or the application needs to be able to accept all KEY RRs
- and pick out the desired sub-type.
-
- 6. A fault or compromise of a DNS zone key can lead to invalid or
- forged DNS data, but a fault or compromise of an application key
- should have no impact on other DNS data. Incorrectly adding or
- changing a DNS zone key can invalidate all of the DNS data in the
- zone and in all of its subzones. By using a compromised key, an
-
-
-
-Massey & Rose Standards Track [Page 4]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
- attacker can forge data from the effected zone and for any of its
- sub-zones. A fault or compromise of an application key has
- implications for that application, but it should not have an impact
- on the DNS. Note that application key faults and key compromises can
- have an impact on the entire DNS if the application key and DNS zone
- keys are both stored in the KEY RR.
-
- In summary, DNSSEC keys and application keys differ in most every
- respect. DNSSEC keys are an essential part of the DNS infrastructure
- and require special handling by DNS administrators and DNS resolvers.
- Application keys are simply another type of data and have no special
- meaning to DNS administrators or resolvers. These two different
- types of data do not belong in the same resource record.
-
-3. Definition of the KEY RR
-
- The KEY RR uses type 25 and is used as resource record for storing
- DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol
- octet, the algorithm number octet, and the public key itself. The
- format is as follows:
-
- ---------------------------------------------------------------------
-
-
- 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 /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- KEY RR Format
-
- ---------------------------------------------------------------------
-
- In the flags field, all bits except bit 7 are reserved and MUST be
- zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
- key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY
- are examples of DNSSEC keys that are not zone keys.
-
- The protocol field MUST be set to 3.
-
- The algorithm and public key fields are not changed.
-
-
-
-
-
-Massey & Rose Standards Track [Page 5]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
-4. Changes from RFC 2535 KEY RR
-
- The KEY RDATA format is not changed.
-
- All flags except for the zone key flag are eliminated:
-
- The A/C bits (bits 0 and 1) are eliminated. They MUST be set to 0
- and MUST be ignored by the receiver.
-
- The extended flags bit (bit 3) is eliminated. It MUST be set to 0
- and MUST be ignored by the receiver.
-
- The host/user bit (bit 6) is eliminated. It MUST be set to 0 and
- MUST be ignored by the receiver.
-
- The zone bit (bit 7) remains unchanged.
-
- The signatory field (bits 12-15) are eliminated by [5]. They MUST
- be set to 0 and MUST be ignored by the receiver.
-
- Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, MUST be
- set to zero and MUST be ignored by the receiver.
-
- Assignment of any future KEY RR Flag values requires a standards
- action.
-
- All Protocol Octet values except DNSSEC (3) are eliminated:
-
- Value 1 (Email) is renamed to RESERVED.
-
- Value 2 (IPSEC) is renamed to RESERVED.
-
- Value 3 (DNSSEC) is unchanged.
-
- Value 4 (TLS) is renamed to RESERVED.
-
- Value 5-254 remains unchanged (reserved).
-
- Value 255 (ANY) is renamed to RESERVED.
-
- The authoritative data for a zone MUST NOT include any KEY records
- with a protocol octet other than 3. The registry maintained by IANA
- for protocol values is closed for new assignments.
-
- Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
- RRs with a value other than 3. If out of date DNS zones contain
- deprecated KEY RRs with a protocol octet value other than 3, then
- simply dropping the deprecated KEY RRs from the KEY RR set would
-
-
-
-Massey & Rose Standards Track [Page 6]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
- invalidate any associated SIG record(s) and could create caching
- consistency problems. Note that KEY RRs with a protocol octet value
- other than 3 MUST NOT be used to authenticate DNS data.
-
- The algorithm and public key fields are not changed.
-
-5. Backward Compatibility
-
- DNSSEC zone KEY RRs are not changed and remain backwards compatible.
- A properly formatted RFC 2535 zone KEY would have all flag bits,
- other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
- Octet set to 3. This remains true under the restricted KEY.
-
- DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
- but the distinction between host and user keys (flag bit 6) is lost.
-
- No backwards compatibility is provided for application keys. Any
- Email, IPSEC, or TLS keys are now deprecated. Storing application
- keys in the KEY RR created problems such as keys at the apex and
- large RR sets and some change in the definition and/or usage of the
- KEY RR would have been required even if the approach described here
- were not adopted.
-
- Overall, existing nameservers and resolvers will continue to
- correctly process KEY RRs with a sub-type of DNSSEC keys.
-
-6. Storing Application Keys in the DNS
-
- The scope of this document is strictly limited to the KEY record.
- This document prohibits storing application keys in the KEY record,
- but it does not endorse or restrict the storing application keys in
- other record types. Other documents can describe how DNS handles
- application keys.
-
-7. IANA Considerations
-
- RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
- values. Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
- values 5-254 were made available for assignment by IANA. This
- document makes two sets of changes to this registry.
-
- First, this document re-assigns DNS KEY RR Protocol Octet values 1,
- 2, 4, and 255 to "reserved". DNS Key RR Protocol Octet Value 3
- remains unchanged as "DNSSEC".
-
-
-
-
-
-
-
-Massey & Rose Standards Track [Page 7]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
- Second, new values are no longer available for assignment by IANA and
- this document closes the IANA registry for DNS KEY RR Protocol Octet
- Values. Assignment of any future KEY RR Protocol Octet values
- requires a standards action.
-
-8. Security Considerations
-
- This document eliminates potential security problems that could arise
- due to the coupling of DNS zone keys and application keys. Prior to
- the change described in this document, a correctly authenticated KEY
- set could include both application keys and DNSSEC keys. This
- document restricts the KEY RR to DNS security usage only. This is an
- attempt to simplify the security model and make it less user-error
- prone. If one of the application keys is compromised, it could be
- used as a false zone key to create false DNS signatures (SIG
- records). Resolvers that do not carefully check the KEY sub-type
- could believe these false signatures and incorrectly authenticate DNS
- data. With this change, application keys cannot appear in an
- authenticated KEY set and this vulnerability is eliminated.
-
- The format and correct usage of DNSSEC keys is not changed by this
- document and no new security considerations are introduced.
-
-9. 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] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
- 2930, September 2000.
-
- [4] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
- [5] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose Standards Track [Page 8]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
-10. Authors' Addresses
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.edu
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-3460
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose Standards Track [Page 9]
-
-RFC 3445 Limiting the KEY Resource Record (RR) December 2002
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose Standards Track [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3467.txt b/contrib/bind9/doc/rfc/rfc3467.txt
deleted file mode 100644
index 37ac7ec1d930b..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3467.txt
+++ /dev/null
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Klensin
-Request for Comments: 3467 February 2003
-Category: Informational
-
-
- Role of the Domain Name System (DNS)
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- This document reviews the original function and purpose of the domain
- name system (DNS). It contrasts that history with some of the
- purposes for which the DNS has recently been applied and some of the
- newer demands being placed upon it or suggested for it. A framework
- for an alternative to placing these additional stresses on the DNS is
- then outlined. This document and that framework are not a proposed
- solution, only a strong suggestion that the time has come to begin
- thinking more broadly about the problems we are encountering and
- possible approaches to solving them.
-
-Table of Contents
-
- 1. Introduction and History ..................................... 2
- 1.1 Context for DNS Development ............................... 3
- 1.2 Review of the DNS and Its Role as Designed ................ 4
- 1.3 The Web and User-visible Domain Names ..................... 6
- 1.4 Internet Applications Protocols and Their Evolution ....... 7
- 2. Signs of DNS Overloading ..................................... 8
- 3. Searching, Directories, and the DNS .......................... 12
- 3.1 Overview ................................................. 12
- 3.2 Some Details and Comments ................................. 14
- 4. Internationalization ......................................... 15
- 4.1 ASCII Isn't Just Because of English ....................... 16
- 4.2 The "ASCII Encoding" Approaches ........................... 17
- 4.3 "Stringprep" and Its Complexities ......................... 17
- 4.4 The Unicode Stability Problem ............................. 19
- 4.5 Audiences, End Users, and the User Interface Problem ...... 20
- 4.6 Business Cards and Other Natural Uses of Natural Languages. 22
- 4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
-
-
-
-Klensin Informational [Page 1]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- 4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
- 5. Search-based Systems: The Key Controversies .................. 23
- 6. Security Considerations ...................................... 24
- 7. References ................................................... 25
- 7.1 Normative References ...................................... 25
- 7.2 Explanatory and Informative References .................... 25
- 8. Acknowledgements ............................................. 30
- 9. Author's Address ............................................. 30
- 10. Full Copyright Statement ..................................... 31
-
-1. Introduction and History
-
- The DNS was designed as a replacement for the older "host table"
- system. Both were intended to provide names for network resources at
- a more abstract level than network (IP) addresses (see, e.g.,
- [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). In recent years,
- the DNS has become a database of convenience for the Internet, with
- many proposals to add new features. Only some of these proposals
- have been successful. Often the main (or only) motivation for using
- the DNS is because it exists and is widely deployed, not because its
- existing structure, facilities, and content are appropriate for the
- particular application of data involved. This document reviews the
- history of the DNS, including examination of some of those newer
- applications. It then argues that the overloading process is often
- inappropriate. Instead, it suggests that the DNS should be
- supplemented by systems better matched to the intended applications
- and outlines a framework and rationale for one such system.
-
- Several of the comments that follow are somewhat revisionist. Good
- design and engineering often requires a level of intuition by the
- designers about things that will be necessary in the future; the
- reasons for some of these design decisions are not made explicit at
- the time because no one is able to articulate them. The discussion
- below reconstructs some of the decisions about the Internet's primary
- namespace (the "Class=IN" DNS) in the light of subsequent development
- and experience. In addition, the historical reasons for particular
- decisions about the Internet were often severely underdocumented
- contemporaneously and, not surprisingly, different participants have
- different recollections about what happened and what was considered
- important. Consequently, the quasi-historical story below is just
- one story. There may be (indeed, almost certainly are) other stories
- about how the DNS evolved to its present state, but those variants do
- not invalidate the inferences and conclusions.
-
- This document presumes a general understanding of the terminology of
- RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
-
-
-
-
-
-Klensin Informational [Page 2]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
-1.1 Context for DNS Development
-
- During the entire post-startup-period life of the ARPANET and nearly
- the first decade or so of operation of the Internet, the list of host
- names and their mapping to and from addresses was maintained in a
- frequently-updated "host table" [RFC625], [RFC811], [RFC952]. The
- names themselves were restricted to a subset of ASCII [ASCII] chosen
- to avoid ambiguities in printed form, to permit interoperation with
- systems using other character codings (notably EBCDIC), and to avoid
- the "national use" code positions of ISO 646 [IS646]. These
- restrictions later became collectively known as the "LDH" rules for
- "letter-digit-hyphen", the permitted characters. The table was just
- a list with a common format that was eventually agreed upon; sites
- were expected to frequently obtain copies of, and install, new
- versions. The host tables themselves were introduced to:
-
- o Eliminate the requirement for people to remember host numbers
- (addresses). Despite apparent experience to the contrary in the
- conventional telephone system, numeric numbering systems,
- including the numeric host number strategy, did not (and do not)
- work well for more than a (large) handful of hosts.
-
- o Provide stability when addresses changed. Since addresses -- to
- some degree in the ARPANET and more importantly in the
- contemporary Internet -- are a function of network topology and
- routing, they often had to be changed when connectivity or
- topology changed. The names could be kept stable even as
- addresses changed.
-
- o Provide the capability to have multiple addresses associated with
- a given host to reflect different types of connectivity and
- topology. Use of names, rather than explicit addresses, avoided
- the requirement that would otherwise exist for users and other
- hosts to track these multiple host numbers and addresses and the
- topological considerations for selecting one over others.
-
- After several years of using the host table approach, the community
- concluded that model did not scale adequately and that it would not
- adequately support new service variations. A number of discussions
- and meetings were held which drew several ideas and incomplete
- proposals together. The DNS was the result of that effort. It
- continued to evolve during the design and initial implementation
- period, with a number of documents recording the changes (see
- [RFC819], [RFC830], and [RFC1034]).
-
-
-
-
-
-
-
-Klensin Informational [Page 3]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- The goals for the DNS included:
-
- o Preservation of the capabilities of the host table arrangements
- (especially unique, unambiguous, host names),
-
- o Provision for addition of additional services (e.g., the special
- record types for electronic mail routing which quickly followed
- introduction of the DNS), and
-
- o Creation of a robust, hierarchical, distributed, name lookup
- system to accomplish the other goals.
-
- The DNS design also permitted distribution of name administration,
- rather than requiring that each host be entered into a single,
- central, table by a central administration.
-
-1.2 Review of the DNS and Its Role as Designed
-
- The DNS was designed to identify network resources. Although there
- was speculation about including, e.g., personal names and email
- addresses, it was not designed primarily to identify people, brands,
- etc. At the same time, the system was designed with the flexibility
- to accommodate new data types and structures, both through the
- addition of new record types to the initial "INternet" class, and,
- potentially, through the introduction of new classes. Since the
- appropriate identifiers and content of those future extensions could
- not be anticipated, the design provided that these fields could
- contain any (binary) information, not just the restricted text forms
- of the host table.
-
- However, the DNS, as it is actually used, is intimately tied to the
- applications and application protocols that utilize it, often at a
- fairly low level.
-
- In particular, despite the ability of the protocols and data
- structures themselves to accommodate any binary representation, DNS
- names as used were historically not even unrestricted ASCII, but a
- very restricted subset of it, a subset that derives from the original
- host table naming rules. Selection of that subset was driven in part
- by human factors considerations, including a desire to eliminate
- possible ambiguities in an international context. Hence character
- codes that had international variations in interpretation were
- excluded, the underscore character and case distinctions were
- eliminated as being confusing (in the underscore's case, with the
- hyphen character) when written or read by people, and so on. These
- considerations appear to be very similar to those that resulted in
- similarly restricted character sets being used as protocol elements
- in many ITU and ISO protocols (cf. [X29]).
-
-
-
-Klensin Informational [Page 4]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- Another assumption was that there would be a high ratio of physical
- hosts to second level domains and, more generally, that the system
- would be deeply hierarchical, with most systems (and names) at the
- third level or below and a very large percentage of the total names
- representing physical hosts. There are domains that follow this
- model: many university and corporate domains use fairly deep
- hierarchies, as do a few country-oriented top level domains
- ("ccTLDs"). Historically, the "US." domain has been an excellent
- example of the deeply hierarchical approach. However, by 1998,
- comparison of several efforts to survey the DNS showed a count of SOA
- records that approached (and may have passed) the number of distinct
- hosts. Looked at differently, we appear to be moving toward a
- situation in which the number of delegated domains on the Internet is
- approaching or exceeding the number of hosts, or at least the number
- of hosts able to provide services to others on the network. This
- presumably results from synonyms or aliases that map a great many
- names onto a smaller number of hosts. While experience up to this
- time has shown that the DNS is robust enough -- given contemporary
- machines as servers and current bandwidth norms -- to be able to
- continue to operate reasonably well when those historical assumptions
- are not met (e.g., with a flat, structure under ".COM" containing
- well over ten million delegated subdomains [COMSIZE]), it is still
- useful to remember that the system could have been designed to work
- optimally with a flat structure (and very large zones) rather than a
- deeply hierarchical one, and was not.
-
- Similarly, despite some early speculation about entering people's
- names and email addresses into the DNS directly (e.g., see
- [RFC1034]), electronic mail addresses in the Internet have preserved
- the original, pre-DNS, "user (or mailbox) at location" conceptual
- format rather than a flatter or strictly dot-separated one.
- Location, in that instance, is a reference to a host. The sole
- exception, at least in the "IN" class, has been one field of the SOA
- record.
-
- Both the DNS architecture itself and the two-level (host name and
- mailbox name) provisions for email and similar functions (e.g., see
- the finger protocol [FINGER]), also anticipated a relatively high
- ratio of users to actual hosts. Despite the observation in RFC 1034
- that the DNS was expected to grow to be proportional to the number of
- users (section 2.3), it has never been clear that the DNS was
- seriously designed for, or could, scale to the order of magnitude of
- number of users (or, more recently, products or document objects),
- rather than that of physical hosts.
-
- Just as was the case for the host table before it, the DNS provided
- critical uniqueness for names, and universal accessibility to them,
- as part of overall "single internet" and "end to end" models (cf.
-
-
-
-Klensin Informational [Page 5]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- [RFC2826]). However, there are many signs that, as new uses evolved
- and original assumptions were abused (if not violated outright), the
- system was being stretched to, or beyond, its practical limits.
-
- The original design effort that led to the DNS included examination
- of the directory technologies available at the time. The design
- group concluded that the DNS design, with its simplifying assumptions
- and restricted capabilities, would be feasible to deploy and make
- adequately robust, which the more comprehensive directory approaches
- were not. At the same time, some of the participants feared that the
- limitations might cause future problems; this document essentially
- takes the position that they were probably correct. On the other
- hand, directory technology and implementations have evolved
- significantly in the ensuing years: it may be time to revisit the
- assumptions, either in the context of the two- (or more) level
- mechanism contemplated by the rest of this document or, even more
- radically, as a path toward a DNS replacement.
-
-1.3 The Web and User-visible Domain Names
-
- From the standpoint of the integrity of the domain name system -- and
- scaling of the Internet, including optimal accessibility to content
- -- the web design decision to use "A record" domain names directly in
- URLs, rather than some system of indirection, has proven to be a
- serious mistake in several respects. Convenience of typing, and the
- desire to make domain names out of easily-remembered product names,
- has led to a flattening of the DNS, with many people now perceiving
- that second-level names under COM (or in some countries, second- or
- third-level names under the relevant ccTLD) are all that is
- meaningful. This perception has been reinforced by some domain name
- registrars [REGISTRAR] who have been anxious to "sell" additional
- names. And, of course, the perception that one needed a second-level
- (or even top-level) domain per product, rather than having names
- associated with a (usually organizational) collection of network
- resources, has led to a rapid acceleration in the number of names
- being registered. That acceleration has, in turn, clearly benefited
- registrars charging on a per-name basis, "cybersquatters", and others
- in the business of "selling" names, but it has not obviously
- benefited the Internet as a whole.
-
- This emphasis on second-level domain names has also created a problem
- for the trademark community. Since the Internet is international,
- and names are being populated in a flat and unqualified space,
- similarly-named entities are in conflict even if there would
- ordinarily be no chance of confusing them in the marketplace. The
- problem appears to be unsolvable except by a choice between draconian
- measures. These might include significant changes to the legislation
- and conventions that govern disputes over "names" and "marks". Or
-
-
-
-Klensin Informational [Page 6]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- they might result in a situation in which the "rights" to a name are
- typically not settled using the subtle and traditional product (or
- industry) type and geopolitical scope rules of the trademark system.
- Instead they have depended largely on political or economic power,
- e.g., the organization with the greatest resources to invest in
- defending (or attacking) names will ultimately win out. The latter
- raises not only important issues of equity, but also the risk of
- backlash as the numerous small players are forced to relinquish names
- they find attractive and to adopt less-desirable naming conventions.
-
- Independent of these sociopolitical problems, content distribution
- issues have made it clear that it should be possible for an
- organization to have copies of data it wishes to make available
- distributed around the network, with a user who asks for the
- information by name getting the topologically-closest copy. This is
- not possible with simple, as-designed, use of the DNS: DNS names
- identify target resources or, in the case of email "MX" records, a
- preferentially-ordered list of resources "closest" to a target (not
- to the source/user). Several technologies (and, in some cases,
- corresponding business models) have arisen to work around these
- problems, including intercepting and altering DNS requests so as to
- point to other locations.
-
- Additional implications are still being discovered and evaluated.
-
- Approaches that involve interception of DNS queries and rewriting of
- DNS names (or otherwise altering the resolution process based on the
- topological location of the user) seem, however, to risk disrupting
- end-to-end applications in the general case and raise many of the
- issues discussed by the IAB in [IAB-OPES]. These problems occur even
- if the rewriting machinery is accompanied by additional workarounds
- for particular applications. For example, security associations and
- applications that need to identify "the same host" often run into
- problems if DNS names or other references are changed in the network
- without participation of the applications that are trying to invoke
- the associated services.
-
-1.4 Internet Applications Protocols and Their Evolution
-
- At the applications level, few of the protocols in active,
- widespread, use on the Internet reflect either contemporary knowledge
- in computer science or human factors or experience accumulated
- through deployment and use. Instead, protocols tend to be deployed
- at a just-past-prototype level, typically including the types of
- expedient compromises typical with prototypes. If they prove useful,
- the nature of the network permits very rapid dissemination (i.e.,
- they fill a vacuum, even if a vacuum that no one previously knew
- existed). But, once the vacuum is filled, the installed base
-
-
-
-Klensin Informational [Page 7]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- provides its own inertia: unless the design is so seriously faulty as
- to prevent effective use (or there is a widely-perceived sense of
- impending disaster unless the protocol is replaced), future
- developments must maintain backward compatibility and workarounds for
- problematic characteristics rather than benefiting from redesign in
- the light of experience. Applications that are "almost good enough"
- prevent development and deployment of high-quality replacements.
-
- The DNS is both an illustration of, and an exception to, parts of
- this pessimistic interpretation. It was a second-generation
- development, with the host table system being seen as at the end of
- its useful life. There was a serious attempt made to reflect the
- computing state of the art at the time. However, deployment was much
- slower than expected (and very painful for many sites) and some fixed
- (although relaxed several times) deadlines from a central network
- administration were necessary for deployment to occur at all.
- Replacing it now, in order to add functionality, while it continues
- to perform its core functions at least reasonably well, would
- presumably be extremely difficult.
-
- There are many, perhaps obvious, examples of this. Despite many
- known deficiencies and weaknesses of definition, the "finger" and
- "whois" [WHOIS] protocols have not been replaced (despite many
- efforts to update or replace the latter [WHOIS-UPDATE]). The Telnet
- protocol and its many options drove out the SUPDUP [RFC734] one,
- which was arguably much better designed for a diverse collection of
- network hosts. A number of efforts to replace the email or file
- transfer protocols with models which their advocates considered much
- better have failed. And, more recently and below the applications
- level, there is some reason to believe that this resistance to change
- has been one of the factors impeding IPv6 deployment.
-
-2. Signs of DNS Overloading
-
- Parts of the historical discussion above identify areas in which the
- DNS has become overloaded (semantically if not in the mechanical
- ability to resolve names). Despite this overloading, it appears that
- DNS performance and reliability are still within an acceptable range:
- there is little evidence of serious performance degradation. Recent
- proposals and mechanisms to better respond to overloading and scaling
- issues have all focused on patching or working around limitations
- that develop when the DNS is utilized for out-of-design functions,
- rather than on dramatic rethinking of either DNS design or those
- uses. The number of these issues that have arisen at much the same
- time may argue for just that type of rethinking, and not just for
- adding complexity and attempting to incrementally alter the design
- (see, for example, the discussion of simplicity in section 2 of
- [RFC3439]).
-
-
-
-Klensin Informational [Page 8]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- For example:
-
- o While technical approaches such as larger and higher-powered
- servers and more bandwidth, and legal/political mechanisms such as
- dispute resolution policies, have arguably kept the problems from
- becoming critical, the DNS has not proven adequately responsive to
- business and individual needs to describe or identify things (such
- as product names and names of individuals) other than strict
- network resources.
-
- o While stacks have been modified to better handle multiple
- addresses on a physical interface and some protocols have been
- extended to include DNS names for determining context, the DNS
- does not deal especially well with many names associated with a
- given host (e.g., web hosting facilities with multiple domains on
- a server).
-
- o Efforts to add names deriving from languages or character sets
- based on other than simple ASCII and English-like names (see
- below), or even to utilize complex company or product names
- without the use of hierarchy, have created apparent requirements
- for names (labels) that are over 63 octets long. This requirement
- will undoubtedly increase over time; while there are workarounds
- to accommodate longer names, they impose their own restrictions
- and cause their own problems.
-
- o Increasing commercialization of the Internet, and visibility of
- domain names that are assumed to match names of companies or
- products, has turned the DNS and DNS names into a trademark
- battleground. The traditional trademark system in (at least) most
- countries makes careful distinctions about fields of
- applicability. When the space is flattened, without
- differentiation by either geography or industry sector, not only
- are there likely conflicts between "Joe's Pizza" (of Boston) and
- "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
- Repair" (of Los Angeles). All three would like to control
- "Joes.com" (and would prefer, if it were permitted by DNS naming
- rules, to also spell it as "Joe's.com" and have both resolve the
- same way) and may claim trademark rights to do so, even though
- conflict or confusion would not occur with traditional trademark
- principles.
-
- o Many organizations wish to have different web sites under the same
- URL and domain name. Sometimes this is to create local variations
- -- the Widget Company might want to present different material to
- a UK user relative to a US one -- and sometimes it is to provide
- higher performance by supplying information from the server
- topologically closest to the user. If the name resolution
-
-
-
-Klensin Informational [Page 9]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- mechanism is expected to provide this functionality, there are
- three possible models (which might be combined):
-
- - supply information about multiple sites (or locations or
- references). Those sites would, in turn, provide information
- associated with the name and sufficient site-specific
- attributes to permit the application to make a sensible choice
- of destination, or
-
- - accept client-site attributes and utilize them in the search
- process, or
-
- - return different answers based on the location or identity of
- the requestor.
-
- While there are some tricks that can provide partial simulations of
- these types of function, DNS responses cannot be reliably conditioned
- in this way.
-
- These, and similar, issues of performance or content choices can, of
- course, be thought of as not involving the DNS at all. For example,
- the commonly-cited alternate approach of coupling these issues to
- HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
- connection first be opened to some "common" or "primary" host so that
- preferences can be negotiated and then the client redirected or sent
- alternate data. At least from the standpoint of improving
- performance by accessing a "closer" location, both initially and
- thereafter, this approach sacrifices the desired result before the
- client initiates any action. It could even be argued that some of
- the characteristics of common content negotiation approaches are
- workarounds for the non-optimal use of the DNS in web URLs.
-
- o Many existing and proposed systems for "finding things on the
- Internet" require a true search capability in which near matches
- can be reported to the user (or to some user agent with an
- appropriate rule-set) and to which queries may be ambiguous or
- fuzzy. The DNS, by contrast, can accommodate only one set of
- (quite rigid) matching rules. Proposals to permit different rules
- in different localities (e.g., matching rules that are TLD- or
- zone-specific) help to identify the problem. But they cannot be
- applied directly to the DNS without either abandoning the desired
- level of flexibility or isolating different parts of the Internet
- from each other (or both). Fuzzy or ambiguous searches are
- desirable for resolution of names that might have spelling
- variations and for names that can be resolved into different sets
- of glyphs depending on context. Especially when
- internationalization is considered, variant name problems go
- beyond simple differences in representation of a character or
-
-
-
-Klensin Informational [Page 10]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- ordering of a string. Instead, avoiding user astonishment and
- confusion requires consideration of relationships such as
- languages that can be written with different alphabets, Kanji-
- Hiragana relationships, Simplified and Traditional Chinese, etc.
- See [Seng] for a discussion and suggestions for addressing a
- subset of these issues in the context of characters based on
- Chinese ones. But that document essentially illustrates the
- difficulty of providing the type of flexible matching that would
- be anticipated by users; instead, it tries to protect against the
- worst types of confusion (and opportunities for fraud).
-
- o The historical DNS, and applications that make assumptions about
- how it works, impose significant risk (or forces technical kludges
- and consequent odd restrictions), when one considers adding
- mechanisms for use with various multi-character-set and
- multilingual "internationalization" systems. See the IAB's
- discussion of some of these issues [RFC2825] for more information.
-
- o In order to provide proper functionality to the Internet, the DNS
- must have a single unique root (the IAB provides more discussion
- of this issue [RFC2826]). There are many desires for local
- treatment of names or character sets that cannot be accommodated
- without either multiple roots (e.g., a separate root for
- multilingual names, proposed at various times by MINC [MINC] and
- others), or mechanisms that would have similar effects in terms of
- Internet fragmentation and isolation.
-
- o For some purposes, it is desirable to be able to search not only
- an index entry (labels or fully-qualified names in the DNS case),
- but their values or targets (DNS data). One might, for example,
- want to locate all of the host (and virtual host) names which
- cause mail to be directed to a given server via MX records. The
- DNS does not support this capability (see the discussion in
- [IQUERY]) and it can be simulated only by extracting all of the
- relevant records (perhaps by zone transfer if the source permits
- doing so, but that permission is becoming less frequently
- available) and then searching a file built from those records.
-
- o Finally, as additional types of personal or identifying
- information are added to the DNS, issues arise with protection of
- that information. There are increasing calls to make different
- information available based on the credentials and authorization
- of the source of the inquiry. As with information keyed to site
- locations or proximity (as discussed above), the DNS protocols
- make providing these differentiated services quite difficult if
- not impossible.
-
-
-
-
-
-Klensin Informational [Page 11]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- In each of these cases, it is, or might be, possible to devise ways
- to trick the DNS system into supporting mechanisms that were not
- designed into it. Several ingenious solutions have been proposed in
- many of these areas already, and some have been deployed into the
- marketplace with some success. But the price of each of these
- changes is added complexity and, with it, added risk of unexpected
- and destabilizing problems.
-
- Several of the above problems are addressed well by a good directory
- system (supported by the LDAP protocol or some protocol more
- precisely suited to these specific applications) or searching
- environment (such as common web search engines) although not by the
- DNS. Given the difficulty of deploying new applications discussed
- above, an important question is whether the tricks and kludges are
- bad enough, or will become bad enough as usage grows, that new
- solutions are needed and can be deployed.
-
-3. Searching, Directories, and the DNS
-
-3.1 Overview
-
- The constraints of the DNS and the discussion above suggest the
- introduction of an intermediate protocol mechanism, referred to below
- as a "search layer" or "searchable system". The terms "directory"
- and "directory system" are used interchangeably with "searchable
- system" in this document, although the latter is far more precise.
- Search layer proposals would use a two (or more) stage lookup, not
- unlike several of the proposals for internationalized names in the
- DNS (see section 4), but all operations but the final one would
- involve searching other systems, rather than looking up identifiers
- in the DNS itself. As explained below, this would permit relaxation
- of several constraints, leading to a more capable and comprehensive
- overall system.
-
- Ultimately, many of the issues with domain names arise as the result
- of efforts to use the DNS as a directory. While, at the time this
- document was written, sufficient pressure or demand had not occurred
- to justify a change, it was already quite clear that, as a directory
- system, the DNS is a good deal less than ideal. This document
- suggests that there actually is a requirement for a directory system,
- and that the right solution to a searchable system requirement is a
- searchable system, not a series of DNS patches, kludges, or
- workarounds.
-
-
-
-
-
-
-
-
-Klensin Informational [Page 12]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- The following points illustrate particular aspects of this
- conclusion.
-
- o A directory system would not require imposition of particular
- length limits on names.
-
- o A directory system could permit explicit association of
- attributes, e.g., language and country, with a name, without
- having to utilize trick encodings to incorporate that information
- in DNS labels (or creating artificial hierarchy for doing so).
-
- o There is considerable experience (albeit not much of it very
- successful) in doing fuzzy and "sonex" (similar-sounding) matching
- in directory systems. Moreover, it is plausible to think about
- different matching rules for different areas and sets of names so
- that these can be adapted to local cultural requirements.
- Specifically, it might be possible to have a single form of a name
- in a directory, but to have great flexibility about what queries
- matched that name (and even have different variations in different
- areas). Of course, the more flexibility that a system provides,
- the greater the possibility of real or imagined trademark
- conflicts. But the opportunity would exist to design a directory
- structure that dealt with those issues in an intelligent way,
- while DNS constraints almost certainly make a general and
- equitable DNS-only solution impossible.
-
- o If a directory system is used to translate to DNS names, and then
- DNS names are looked up in the normal fashion, it may be possible
- to relax several of the constraints that have been traditional
- (and perhaps necessary) with the DNS. For example, reverse-
- mapping of addresses to directory names may not be a requirement
- even if mapping of addresses to DNS names continues to be, since
- the DNS name(s) would (continue to) uniquely identify the host.
-
- o Solutions to multilingual transcription problems that are common
- in "normal life" (e.g., two-sided business cards to be sure that
- recipients trying to contact a person can access romanized
- spellings and numbers if the original language is not
- comprehensible to them) can be easily handled in a directory
- system by inserting both sets of entries.
-
- o A directory system could be designed that would return, not a
- single name, but a set of names paired with network-locational
- information or other context-establishing attributes. This type
- of information might be of considerable use in resolving the
- "nearest (or best) server for a particular named resource"
-
-
-
-
-
-Klensin Informational [Page 13]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- problems that are a significant concern for organizations hosting
- web and other sites that are accessed from a wide range of
- locations and subnets.
-
- o Names bound to countries and languages might help to manage
- trademark realities, while, as discussed in section 1.3 above, use
- of the DNS in trademark-significant contexts tends to require
- worldwide "flattening" of the trademark system.
-
- Many of these issues are a consequence of another property of the
- DNS: names must be unique across the Internet. The need to have a
- system of unique identifiers is fairly obvious (see [RFC2826]).
- However, if that requirement were to be eliminated in a search or
- directory system that was visible to users instead of the DNS, many
- difficult problems -- of both an engineering and a policy nature --
- would be likely to vanish.
-
-3.2 Some Details and Comments
-
- Almost any internationalization proposal for names that are in, or
- map into, the DNS will require changing DNS resolver API calls
- ("gethostbyname" or equivalent), or adding some pre-resolution
- preparation mechanism, in almost all Internet applications -- whether
- to cause the API to take a different character set (no matter how it
- is then mapped into the bits used in the DNS or another system), to
- accept or return more arguments with qualifying or identifying
- information, or otherwise. Once applications must be opened to make
- such changes, it is a relatively small matter to switch from calling
- into the DNS to calling a directory service and then the DNS (in many
- situations, both actions could be accomplished in a single API call).
-
- A directory approach can be consistent both with "flat" models and
- multi-attribute ones. The DNS requires strict hierarchies, limiting
- its ability to differentiate among names by their properties. By
- contrast, modern directories can utilize independently-searched
- attributes and other structured schema to provide flexibilities not
- present in a strictly hierarchical system.
-
- There is a strong historical argument for a single directory
- structure (implying a need for mechanisms for registration,
- delegation, etc.). But a single structure is not a strict
- requirement, especially if in-depth case analysis and design work
- leads to the conclusion that reverse-mapping to directory names is
- not a requirement (see section 5). If a single structure is not
- needed, then, unlike the DNS, there would be no requirement for a
- global organization to authorize or delegate operation of portions of
- the structure.
-
-
-
-
-Klensin Informational [Page 14]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- The "no single structure" concept could be taken further by moving
- away from simple "names" in favor of, e.g., multiattribute,
- multihierarchical, faceted systems in which most of the facets use
- restricted vocabularies. (These terms are fairly standard in the
- information retrieval and classification system literature, see,
- e.g., [IS5127].) Such systems could be designed to avoid the need
- for procedures to ensure uniqueness across, or even within, providers
- and databases of the faceted entities for which the search is to be
- performed. (See [DNS-Search] for further discussion.)
-
- While the discussion above includes very general comments about
- attributes, it appears that only a very small number of attributes
- would be needed. The list would almost certainly include country and
- language for internationalization purposes. It might require
- "charset" if we cannot agree on a character set and encoding,
- although there are strong arguments for simply using ISO 10646 (also
- known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
- [IS10646] coding in interchange. Trademark issues might motivate
- "commercial" and "non-commercial" (or other) attributes if they would
- be helpful in bypassing trademark problems. And applications to
- resource location, such as those contemplated for Uniform Resource
- Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
- Protocol [RFC2608], might argue for a few other attributes (as
- outlined above).
-
-4. Internationalization
-
- Much of the thinking underlying this document was driven by
- considerations of internationalizing the DNS or, more specifically,
- providing access to the functions of the DNS from languages and
- naming systems that cannot be accurately expressed in the traditional
- DNS subset of ASCII. Much of the relevant work was done in the
- IETF's "Internationalized Domain Names" Working Group (IDN-WG),
- although this document also draws on extensive parallel discussions
- in other forums. This section contains an evaluation of what was
- learned as an "internationalized DNS" or "multilingual DNS" was
- explored and suggests future steps based on that evaluation.
-
- When the IDN-WG was initiated, it was obvious to several of the
- participants that its first important task was an undocumented one:
- to increase the understanding of the complexities of the problem
- sufficiently that naive solutions could be rejected and people could
- go to work on the harder problems. The IDN-WG clearly accomplished
- that task. The beliefs that the problems were simple, and in the
- corresponding simplistic approaches and their promises of quick and
- painless deployment, effectively disappeared as the WG's efforts
- matured.
-
-
-
-
-Klensin Informational [Page 15]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- Some of the lessons learned from increased understanding and the
- dissipation of naive beliefs should be taken as cautions by the wider
- community: the problems are not simple. Specifically, extracting
- small elements for solution rather than looking at whole systems, may
- result in obscuring the problems but not solving any problem that is
- worth the trouble.
-
-4.1 ASCII Isn't Just Because of English
-
- The hostname rules chosen in the mid-70s weren't just "ASCII because
- English uses ASCII", although that was a starting point. We have
- discovered that almost every other script (and even ASCII if we
- permit the rest of the characters specified in the ISO 646
- International Reference Version) is more complex than hostname-
- restricted-ASCII (the "LDH" form, see section 1.1). And ASCII isn't
- sufficient to completely represent English -- there are several words
- in the language that are correctly spelled only with characters or
- diacritical marks that do not appear in ASCII. With a broader
- selection of scripts, in some examples, case mapping works from one
- case to the other but is not reversible. In others, there are
- conventions about alternate ways to represent characters (in the
- language, not [only] in character coding) that work most of the time,
- but not always. And there are issues in coding, with Unicode/10646
- providing different ways to represent the same character
- ("character", rather than "glyph", is used deliberately here). And,
- in still others, there are questions as to whether two glyphs
- "match", which may be a distance-function question, not one with a
- binary answer. The IETF approach to these problems is to require
- pre-matching canonicalization (see the "stringprep" discussion
- below).
-
- The IETF has resisted the temptations to either try to specify an
- entirely new coded character set, or to pick and choose Unicode/10646
- characters on a per-character basis rather than by using well-defined
- blocks. While it may appear that a character set designed to meet
- Internet-specific needs would be very attractive, the IETF has never
- had the expertise, resources, and representation from critically-
- important communities to actually take on that job. Perhaps more
- important, a new effort might have chosen to make some of the many
- complex tradeoffs differently than the Unicode committee did,
- producing a code with somewhat different characteristics. But there
- is no evidence that doing so would produce a code with fewer problems
- and side-effects. It is much more likely that making tradeoffs
- differently would simply result in a different set of problems, which
- would be equally or more difficult.
-
-
-
-
-
-
-Klensin Informational [Page 16]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
-4.2 The "ASCII Encoding" Approaches
-
- While the DNS can handle arbitrary binary strings without known
- internal problems (see [RFC2181]), some restrictions are imposed by
- the requirement that text be interpreted in a case-independent way
- ([RFC1034], [RFC1035]). More important, most internet applications
- assume the hostname-restricted "LDH" syntax that is specified in the
- host table RFCs and as "prudent" in RFC 1035. If those assumptions
- are not met, many conforming implementations of those applications
- may exhibit behavior that would surprise implementors and users. To
- avoid these potential problems, IETF internationalization work has
- focused on "ASCII-Compatible Encodings" (ACE). These encodings
- preserve the LDH conventions in the DNS itself. Implementations of
- applications that have not been upgraded utilize the encoded forms,
- while newer ones can be written to recognize the special codings and
- map them into non-ASCII characters. These approaches are, however,
- not problem-free even if human interface issues are ignored. Among
- other issues, they rely on what is ultimately a heuristic to
- determine whether a DNS label is to be considered as an
- internationalized name (i.e., encoded Unicode) or interpreted as an
- actual LDH name in its own right. And, while all determinations of
- whether a particular query matches a stored object are traditionally
- made by DNS servers, the ACE systems, when combined with the
- complexities of international scripts and names, require that much of
- the matching work be separated into a separate, client-side,
- canonicalization or "preparation" process before the DNS matching
- mechanisms are invoked [STRINGPREP].
-
-4.3 "Stringprep" and Its Complexities
-
- As outlined above, the model for avoiding problems associated with
- putting non-ASCII names in the DNS and elsewhere evolved into the
- principle that strings are to be placed into the DNS only after being
- passed through a string preparation function that eliminates or
- rejects spurious character codes, maps some characters onto others,
- performs some sequence canonicalization, and generally creates forms
- that can be accurately compared. The impact of this process on
- hostname-restricted ASCII (i.e., "LDH") strings is trivial and
- essentially adds only overhead. For other scripts, the impact is, of
- necessity, quite significant.
-
- Although the general notion underlying stringprep is simple, the many
- details are quite subtle and the associated tradeoffs are complex. A
- design team worked on it for months, with considerable effort placed
- into clarifying and fine-tuning the protocol and tables. Despite
- general agreement that the IETF would avoid getting into the business
- of defining character sets, character codings, and the associated
- conventions, the group several times considered and rejected special
-
-
-
-Klensin Informational [Page 17]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- treatment of code positions to more nearly match the distinctions
- made by Unicode with user perceptions about similarities and
- differences between characters. But there were intense temptations
- (and pressures) to incorporate language-specific or country-specific
- rules. Those temptations, even when resisted, were indicative of
- parts of the ongoing controversy or of the basic unsuitability of the
- DNS for fully internationalized names that are visible,
- comprehensible, and predictable for end users.
-
- There have also been controversies about how far one should go in
- these processes of preparation and transformation and, ultimately,
- about the validity of various analogies. For example, each of the
- following operations has been claimed to be similar to case-mapping
- in ASCII:
-
- o stripping of vowels in Arabic or Hebrew
-
- o matching of "look-alike" characters such as upper-case Alpha in
- Greek and upper-case A in Roman-based alphabets
-
- o matching of Traditional and Simplified Chinese characters that
- represent the same words,
-
- o matching of Serbo-Croatian words whether written in Roman-derived
- or Cyrillic characters
-
- A decision to support any of these operations would have implications
- for other scripts or languages and would increase the overall
- complexity of the process. For example, unless language-specific
- information is somehow available, performing matching between
- Traditional and Simplified Chinese has impacts on Japanese and Korean
- uses of the same "traditional" characters (e.g., it would not be
- appropriate to map Kanji into Simplified Chinese).
-
- Even were the IDN-WG's other work to have been abandoned completely
- or if it were to fail in the marketplace, the stringprep and nameprep
- work will continue to be extremely useful, both in identifying issues
- and problem code points and in providing a reasonable set of basic
- rules. Where problems remain, they are arguably not with nameprep,
- but with the DNS-imposed requirement that its results, as with all
- other parts of the matching and comparison process, yield a binary
- "match or no match" answer, rather than, e.g., a value on a
- similarity scale that can be evaluated by the user or by user-driven
- heuristic functions.
-
-
-
-
-
-
-
-Klensin Informational [Page 18]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
-4.4 The Unicode Stability Problem
-
- ISO 10646 basically defines only code points, and not rules for using
- or comparing the characters. This is part of a long-standing
- tradition with the work of what is now ISO/IEC JTC1/SC2: they have
- performed code point assignments and have typically treated the ways
- in which characters are used as beyond their scope. Consequently,
- they have not dealt effectively with the broader range of
- internationalization issues. By contrast, the Unicode Technical
- Committee (UTC) has defined, in annexes and technical reports (see,
- e.g., [UTR15]), some additional rules for canonicalization and
- comparison. Many of those rules and conventions have been factored
- into the "stringprep" and "nameprep" work, but it is not
- straightforward to make or define them in a fashion that is
- sufficiently precise and permanent to be relied on by the DNS.
-
- Perhaps more important, the discussions leading to nameprep also
- identified several areas in which the UTC definitions are inadequate,
- at least without additional information, to make matching precise and
- unambiguous. In some of these cases, the Unicode Standard permits
- several alternate approaches, none of which are an exact and obvious
- match to DNS needs. That has left these sensitive choices up to
- IETF, which lacks sufficient in-depth expertise, much less any
- mechanism for deciding to optimize one language at the expense of
- another.
-
- For example, it is tempting to define some rules on the basis of
- membership in particular scripts, or for punctuation characters, but
- there is no precise definition of what characters belong to which
- script or which ones are, or are not, punctuation. The existence of
- these areas of vagueness raises two issues: whether trying to do
- precise matching at the character set level is actually possible
- (addressed below) and whether driving toward more precision could
- create issues that cause instability in the implementation and
- resolution models for the DNS.
-
- The Unicode definition also evolves. Version 3.2 appeared shortly
- after work on this document was initiated. It added some characters
- and functionality and included a few minor incompatible code point
- changes. IETF has secured an agreement about constraints on future
- changes, but it remains to be seen how that agreement will work out
- in practice. The prognosis actually appears poor at this stage,
- since UTC chose to ballot a recent possible change which should have
- been prohibited by the agreement (the outcome of the ballot is not
- relevant, only that the ballot was issued rather than having the
- result be a foregone conclusion). However, some members of the
- community consider some of the changes between Unicode 3.0 and 3.1
- and between 3.1 and 3.2, as well as this recent ballot, to be
-
-
-
-Klensin Informational [Page 19]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- evidence of instability and that these instabilities are better
- handled in a system that can be more flexible about handling of
- characters, scripts, and ancillary information than the DNS.
-
- In addition, because the systems implications of internationalization
- are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
- those issues to its SC22/WG20 (the Internationalization working group
- within the subcommittee that deals with programming languages,
- systems, and environments). WG20 has historically dealt with
- internationalization issues thoughtfully and in depth, but its status
- has several times been in doubt in recent years. However, assignment
- of these matters to WG20 increases the risk of eventual ISO
- internationalization standards that specify different behavior than
- the UTC specifications.
-
-4.5 Audiences, End Users, and the User Interface Problem
-
- Part of what has "caused" the DNS internationalization problem, as
- well as the DNS trademark problem and several others, is that we have
- stopped thinking about "identifiers for objects" -- which normal
- people are not expected to see -- and started thinking about "names"
- -- strings that are expected not only to be readable, but to have
- linguistically-sensible and culturally-dependent meaning to non-
- specialist users.
-
- Within the IETF, the IDN-WG, and sometimes other groups, avoided
- addressing the implications of that transition by taking "outside our
- scope -- someone else's problem" approaches or by suggesting that
- people will just become accustomed to whatever conventions are
- adopted. The realities of user and vendor behavior suggest that
- these approaches will not serve the Internet community well in the
- long term:
-
- o If we want to make it a problem in a different part of the user
- interface structure, we need to figure out where it goes in order
- to have proof of concept of our solution. Unlike vendors whose
- sole [business] model is the selling or registering of names, the
- IETF must produce solutions that actually work, in the
- applications context as seen by the end user.
-
- o The principle that "they will get used to our conventions and
- adapt" is fine if we are writing rules for programming languages
- or an API. But the conventions under discussion are not part of a
- semi-mathematical system, they are deeply ingrained in culture.
- No matter how often an English-speaking American is told that the
- Internet requires that the correct spelling of "colour" be used,
- he or she isn't going to be convinced. Getting a French-speaker in
- Lyon to use exactly the same lexical conventions as a French-
-
-
-
-Klensin Informational [Page 20]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- speaker in Quebec in order to accommodate the decisions of the
- IETF or of a registrar or registry is just not likely. "Montreal"
- is either a misspelling or an anglicization of a similar word with
- an acute accent mark over the "e" (i.e., using the Unicode
- character U+00E9 or one of its equivalents). But global agreement
- on a rule that will determine whether the two forms should match
- -- and that won't astonish end users and speakers of one language
- or the other -- is as unlikely as agreement on whether
- "misspelling" or "anglicization" is the greater travesty.
-
- More generally, it is not clear that the outcome of any conceivable
- nameprep-like process is going to be good enough for practical,
- user-level, use. In the use of human languages by humans, there are
- many cases in which things that do not match are nonetheless
- interpreted as matching. The Norwegian/Danish character that appears
- in U+00F8 (visually, a lower case 'o' overstruck with a forward
- slash) and the "o-umlaut" German character that appears in U+00F6
- (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
- different and no matching program should yield an "equal" comparison.
- But they are more similar to each other than either of them is to,
- e.g., "e". Humans are able to mentally make the correction in
- context, and do so easily, and they can be surprised if computers
- cannot do so. Worse, there is a Swedish character whose appearance
- is identical to the German o-umlaut, and which shares code point
- U+00F6, but that, if the languages are known and the sounds of the
- letters or meanings of words including the character are considered,
- actually should match the Norwegian/Danish use of U+00F8.
-
- This text uses examples in Roman scripts because it is being written
- in English and those examples are relatively easy to render. But one
- of the important lessons of the discussions about domain name
- internationalization in recent years is that problems similar to
- those described above exist in almost every language and script.
- Each one has its idiosyncrasies, and each set of idiosyncracies is
- tied to common usage and cultural issues that are very familiar in
- the relevant group, and often deeply held as cultural values. As
- long as a schoolchild in the US can get a bad grade on a spelling
- test for using a perfectly valid British spelling, or one in France
- or Germany can get a poor grade for leaving off a diacritical mark,
- there are issues with the relevant language. Similarly, if children
- in Egypt or Israel are taught that it is acceptable to write a word
- with or without vowels or stress marks, but that, if those marks are
- included, they must be the correct ones, or a user in Korea is
- potentially offended or astonished by out-of-order sequences of Jamo,
- systems based on character-at-a-time processing and simplistic
- matching, with no contextual information, are not going to satisfy
- user needs.
-
-
-
-
-Klensin Informational [Page 21]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- Users are demanding solutions that deal with language and culture.
- Systems of identifier symbol-strings that serve specialists or
- computers are, at best, a solution to a rather different (and, at the
- time this document was written, somewhat ill-defined), problem. The
- recent efforts have made it ever more clear that, if we ignore the
- distinction between the user requirements and narrowly-defined
- identifiers, we are solving an insufficient problem. And,
- conversely, the approaches that have been proposed to approximate
- solutions to the user requirement may be far more complex than simple
- identifiers require.
-
-4.6 Business Cards and Other Natural Uses of Natural Languages
-
- Over the last few centuries, local conventions have been established
- in various parts of the world for dealing with multilingual
- situations. It may be helpful to examine some of these. For
- example, if one visits a country where the language is different from
- ones own, business cards are often printed on two sides, one side in
- each language. The conventions are not completely consistent and the
- technique assumes that recipients will be tolerant. Translations of
- names or places are attempted in some situations and transliterations
- in others. Since it is widely understood that exact translations or
- transliterations are often not possible, people typically smile at
- errors, appreciate the effort, and move on.
-
- The DNS situation differs from these practices in at least two ways.
- Since a global solution is required, the business card would need a
- number of sides approximating the number of languages in the world,
- which is probably impossible without violating laws of physics. More
- important, the opportunities for tolerance don't exist: the DNS
- requires a exact match or the lookup fails.
-
-4.7 ASCII Encodings and the Roman Keyboard Assumption
-
- Part of the argument for ACE-based solutions is that they provide an
- escape for multilingual environments when applications have not been
- upgraded. When an older application encounters an ACE-based name,
- the assumption is that the (admittedly ugly) ASCII-coded string will
- be displayed and can be typed in. This argument is reasonable from
- the standpoint of mixtures of Roman-based alphabets, but may not be
- relevant if user-level systems and devices are involved that do not
- support the entry of Roman-based characters or which cannot
- conveniently render such characters. Such systems are few in the
- world today, but the number can reasonably be expected to rise as the
- Internet is increasingly used by populations whose primary concern is
- with local issues, local information, and local languages. It is,
-
-
-
-
-
-Klensin Informational [Page 22]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- for example, fairly easy to imagine populations who use Arabic or
- Thai scripts and who do not have routine access to scripts or input
- devices based on Roman-derived alphabets.
-
-4.8 Intra-DNS Approaches for "Multilingual Names"
-
- It appears, from the cases above and others, that none of the intra-
- DNS-based solutions for "multilingual names" are workable. They rest
- on too many assumptions that do not appear to be feasible -- that
- people will adapt deeply-entrenched language habits to conventions
- laid down to make the lives of computers easy; that we can make
- "freeze it now, no need for changes in these areas" decisions about
- Unicode and nameprep; that ACE will smooth over applications
- problems, even in environments without the ability to key or render
- Roman-based glyphs (or where user experience is such that such glyphs
- cannot easily be distinguished from each other); that the Unicode
- Consortium will never decide to repair an error in a way that creates
- a risk of DNS incompatibility; that we can either deploy EDNS
- [RFC2671] or that long names are not really important; that Japanese
- and Chinese computer users (and others) will either give up their
- local or IS 2022-based character coding solutions (for which addition
- of a large fraction of a million new code points to Unicode is almost
- certainly a necessary, but probably not sufficient, condition) or
- build leakproof and completely accurate boundary conversion
- mechanisms; that out of band or contextual information will always be
- sufficient for the "map glyph onto script" problem; and so on. In
- each case, it is likely that about 80% or 90% of cases will work
- satisfactorily, but it is unlikely that such partial solutions will
- be good enough. For example, suppose someone can spell her name 90%
- correctly, or a company name is matched correctly 80% of the time but
- the other 20% of attempts identify a competitor: are either likely to
- be considered adequate?
-
-5. Search-based Systems: The Key Controversies
-
- For many years, a common response to requirements to locate people or
- resources on the Internet has been to invoke the term "directory".
- While an in-depth analysis of the reasons would require a separate
- document, the history of failure of these invocations has given
- "directory" efforts a bad reputation. The effort proposed here is
- different from those predecessors for several reasons, perhaps the
- most important of which is that it focuses on a fairly-well-
- understood set of problems and needs, rather than on finding uses for
- a particular technology.
-
- As suggested in some of the text above, it is an open question as to
- whether the needs of the community would be best served by a single
- (even if functionally, and perhaps administratively, distributed)
-
-
-
-Klensin Informational [Page 23]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- directory with universal applicability, a single directory that
- supports locally-tailored search (and, most important, matching)
- functions, or multiple, locally-determined, directories. Each has
- its attractions. Any but the first would essentially prevent
- reverse-mapping (determination of the user-visible name of the host
- or resource from target information such as an address or DNS name).
- But reverse mapping has become less useful over the years --at least
- to users -- as more and more names have been associated with many
- host addresses and as CIDR [CIDR] has proven problematic for mapping
- smaller address blocks to meaningful names.
-
- Locally-tailored searches and mappings would permit national
- variations on interpretation of which strings matched which other
- ones, an arrangement that is especially important when different
- localities apply different rules to, e.g., matching of characters
- with and without diacriticals. But, of course, this implies that a
- URL may evaluate properly or not depending on either settings on a
- client machine or the network connectivity of the user. That is not,
- in general, a desirable situation, since it implies that users could
- not, in the general case, share URLs (or other host references) and
- that a particular user might not be able to carry references from one
- host or location to another.
-
- And, of course, completely separate directories would permit
- translation and transliteration functions to be embedded in the
- directory, giving much of the Internet a different appearance
- depending on which directory was chosen. The attractions of this are
- obvious, but, unless things were very carefully designed to preserve
- uniqueness and precise identities at the right points (which may or
- may not be possible), such a system would have many of the
- difficulties associated with multiple DNS roots.
-
- Finally, a system of separate directories and databases, if coupled
- with removal of the DNS-imposed requirement for unique names, would
- largely eliminate the need for a single worldwide authority to manage
- the top of the naming hierarchy.
-
-6. Security Considerations
-
- The set of proposals implied by this document suggests an interesting
- set of security issues (i.e., nothing important is ever easy). A
- directory system used for locating network resources would presumably
- need to be as carefully protected against unauthorized changes as the
- DNS itself. There also might be new opportunities for problems in an
- arrangement involving two or more (sub)layers, especially if such a
- system were designed without central authority or uniqueness of
- names. It is uncertain how much greater those risks would be as
- compared to a DNS lookup sequence that involved looking up one name,
-
-
-
-Klensin Informational [Page 24]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- getting back information, and then doing additional lookups
- potentially in different subtrees. That multistage lookup will often
- be the case with, e.g., NAPTR records [RFC 2915] unless additional
- restrictions are imposed. But additional steps, systems, and
- databases almost certainly involve some additional risks of
- compromise.
-
-7. References
-
-7.1 Normative References
-
- None
-
-7.2 Explanatory and Informative References
-
- [Albitz] Any of the editions of Albitz, P. and C. Liu, DNS and
- BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
-
- [ASCII] American National Standards Institute (formerly United
- States of America Standards Institute), X3.4, 1968,
- "USA Code for Information Interchange". ANSI X3.4-1968
- has been replaced by newer versions with slight
- modifications, but the 1968 version remains definitive
- for the Internet. Some time after ASCII was first
- formulated as a standard, ISO adopted international
- standard 646, which uses ASCII as a base. IS 646
- actually contained two code tables: an "International
- Reference Version" (often referenced as ISO 646-IRV)
- which was essentially identical to the ASCII of the
- time, and a "Basic Version" (ISO 646-BV), which
- designates a number of character positions for
- national use.
-
- [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
- Inter-Domain Routing (CIDR): an Address Assignment and
- Aggregation Strategy", RFC 1519, September 1993.
-
- Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
- ADDR.ARPA delegation", RFC 2317, March 1998.
-
- [COM-SIZE] Size information supplied by Verisign Global Registry
- Services (the zone administrator, or "registry
- operator", for COM, see [REGISTRAR], below) to ICANN,
- third quarter 2002.
-
- [DNS-Search] Klensin, J., "A Search-based access model for the
- DNS", Work in Progress.
-
-
-
-
-Klensin Informational [Page 25]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- [FINGER] Zimmerman, D., "The Finger User Information Protocol",
- RFC 1288, December 1991.
-
- Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
- December 1977.
-
- [IAB-OPES] Floyd, S. and L. Daigle, "IAB Architectural and Policy
- Considerations for Open Pluggable Edge Services", RFC
- 3238, January 2002.
-
- [IQUERY] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
- 2002.
-
- [IS646] ISO/IEC 646:1991 Information technology -- ISO 7-bit
- coded character set for information interchange
-
- [IS10646] ISO/IEC 10646-1:2000 Information technology --
- Universal Multiple-Octet Coded Character Set (UCS) --
- Part 1: Architecture and Basic Multilingual Plane and
- ISO/IEC 10646-2:2001 Information technology --
- Universal Multiple-Octet Coded Character Set (UCS) --
- Part 2: Supplementary Planes
-
- [MINC] The Multilingual Internet Names Consortium,
- http://www.minc.org/ has been an early advocate for
- the importance of expansion of DNS names to
- accommodate non-ASCII characters. Some of their
- specific proposals, while helping people to understand
- the problems better, were not compatible with the
- design of the DNS.
-
- [NAPTR] Mealling, M. and R. Daniel, "The Naming Authority
- Pointer (NAPTR) DNS Resource Record", RFC 2915,
- September 2000.
-
- Mealling, M., "Dynamic Delegation Discovery System
- (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
- October 2002.
-
- Mealling, M., "Dynamic Delegation Discovery System
- (DDDS) Part Two: The Algorithm", RFC 3402, October
- 2002.
-
- Mealling, M., "Dynamic Delegation Discovery System
- (DDDS) Part Three: The Domain Name System (DNS)
- Database", RFC 3403, October 2002.
-
-
-
-
-
-Klensin Informational [Page 26]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- [REGISTRAR] In an early stage of the process that created the
- Internet Corporation for Assigned Names and Numbers
- (ICANN), a "Green Paper" was released by the US
- Government. That paper introduced new terminology
- and some concepts not needed by traditional DNS
- operations. The term "registry" was applied to the
- actual operator and database holder of a domain
- (typically at the top level, since the Green Paper was
- little concerned with anything else), while
- organizations that marketed names and made them
- available to "registrants" were known as "registrars".
- In the classic DNS model, the function of "zone
- administrator" encompassed both registry and registrar
- roles, although that model did not anticipate a
- commercial market in names.
-
- [RFC625] Kudlick, M. and E. Feinler, "On-line hostnames
- service", RFC 625, March 1974.
-
- [RFC734] Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
-
- [RFC811] Harrenstien, K., White, V. and E. Feinler, "Hostnames
- Server", RFC 811, March 1982.
-
- [RFC819] Su, Z. and J. Postel, "Domain naming convention for
- Internet user applications", RFC 819, August 1982.
-
- [RFC830] Su, Z., "Distributed system for Internet name
- service", RFC 830, October 1982.
-
- [RFC882] Mockapetris, P., "Domain names: Concepts and
- facilities", RFC 882, November 1983.
-
- [RFC883] Mockapetris, P., "Domain names: Implementation
- specification", RFC 883, November 1983.
-
- [RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DoD
- Internet host table specification", RFC 952, October
- 1985.
-
- [RFC953] Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
- SERVER", RFC 953, October 1985.
-
- [RFC1034] Mockapetris, P., "Domain names, Concepts and
- facilities", STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-Klensin Informational [Page 27]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC1591] Postel, J., "Domain Name System Structure and
- Delegation", RFC 1591, March 1994.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2295] Holtman, K. and A. Mutz, "Transparent Content
- Negotiation in HTTP", RFC 2295, March 1998
-
- [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
- "Uniform Resource Identifiers (URI): Generic Syntax",
- RFC 2396, August 1998.
-
- [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
- "Service Location Protocol, Version 2", RFC 2608, June
- 1999.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC2825] IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
- Domain Names, and the Other Internet protocols", RFC
- 2825, May 2000.
-
- [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root",
- RFC 2826, May 2000.
-
- [RFC2972] Popp, N., Mealling, M., Masinter, L. and K. Sollins,
- "Context and Goals for Common Name Resolution", RFC
- 2972, October 2000.
-
- [RFC3305] Mealling, M. and R. Denenberg, Eds., "Report from the
- Joint W3C/IETF URI Planning Interest Group: Uniform
- Resource Identifiers (URIs), URLs, and Uniform
- Resource Names (URNs): Clarifications and
- Recommendations", RFC 3305, August 2002.
-
- [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
- Guidelines and Philosophy", RFC 3439, December 2002.
-
- [Seng] Seng, J., et al., Eds., "Internationalized Domain
- Names: Registration and Administration Guideline for
- Chinese, Japanese, and Korean", Work in Progress.
-
-
-
-
-
-Klensin Informational [Page 28]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings (stringprep)", RFC 3454,
- December 2002.
-
- The particular profile used for placing
- internationalized strings in the DNS is called
- "nameprep", described in Hoffman, P. and M. Blanchet,
- "Nameprep: A Stringprep Profile for Internationalized
- Domain Names", Work in Progress.
-
- [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
- Specification", STD 8, RFC 854, May 1983.
-
- Postel, J. and J. Reynolds, "Telnet Option
- Specifications", STD 8, RFC 855, May 1983.
-
- [UNICODE] The Unicode Consortium, The Unicode Standard, Version
- 3.0, Addison-Wesley: Reading, MA, 2000. Update to
- version 3.1, 2001. Update to version 3.2, 2002.
-
- [UTR15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
- Unicode Normalization Forms", Unicode Consortium,
- March 2002. An integral part of The Unicode Standard,
- Version 3.1.1. Available at
- (http://www.unicode.org/reports/tr15/tr15-21.html).
-
- [WHOIS] Harrenstien, K, Stahl, M. and E. Feinler,
- "NICNAME/WHOIS", RFC 954, October 1985.
-
- [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
- Information Lookup Service, Whois++", RFC 1834, August
- 1995.
-
- Weider, C., Fullton, J. and S. Spero, "Architecture of
- the Whois++ Index Service", RFC 1913, February 1996.
-
- Williamson, S., Kosters, M., Blacka, D., Singh, J. and
- K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
- RFC 2167, June 1997;
-
- Daigle, L. and P. Faltstrom, "The
- application/whoispp-query Content-Type", RFC 2957,
- October 2000.
-
- Daigle, L. and P. Falstrom, "The application/whoispp-
- response Content-type", RFC 2958, October 2000.
-
-
-
-
-
-Klensin Informational [Page 29]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
- [X29] International Telecommuncations Union, "Recommendation
- X.29: Procedures for the exchange of control
- information and user data between a Packet
- Assembly/Disassembly (PAD) facility and a packet mode
- DTE or another PAD", December 1997.
-
-8. Acknowledgements
-
- Many people have contributed to versions of this document or the
- thinking that went into it. The author would particularly like to
- thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt
- Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie,
- Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific
- suggestions and/or challenging the assumptions and presentation of
- earlier versions and suggesting ways to improve them.
-
-9. Author's Address
-
- John C. Klensin
- 1770 Massachusetts Ave, #322
- Cambridge, MA 02140
-
- EMail: klensin+srch@jck.com
-
- A mailing list has been initiated for discussion of the topics
- discussed in this document, and closely-related issues, at
- ietf-irnss@lists.elistx.com. See http://lists.elistx.com/archives/
- for subscription and archival information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin Informational [Page 30]
-
-RFC 3467 Role of the Domain Name System (DNS) February 2003
-
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin Informational [Page 31]
-
diff --git a/contrib/bind9/doc/rfc/rfc3490.txt b/contrib/bind9/doc/rfc/rfc3490.txt
deleted file mode 100644
index d2e0b3b75a141..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3490.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Faltstrom
-Request for Comments: 3490 Cisco
-Category: Standards Track P. Hoffman
- IMC & VPNC
- A. Costello
- UC Berkeley
- March 2003
-
-
- Internationalizing Domain Names in Applications (IDNA)
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- Until now, there has been no standard method for domain names to use
- characters outside the ASCII repertoire. This document defines
- internationalized domain names (IDNs) and a mechanism called
- Internationalizing Domain Names in Applications (IDNA) for handling
- them in a standard fashion. IDNs use characters drawn from a large
- repertoire (Unicode), but IDNA allows the non-ASCII characters to be
- represented using only the ASCII characters already allowed in so-
- called host names today. This backward-compatible representation is
- required in existing protocols like DNS, so that IDNs can be
- introduced with no changes to the existing infrastructure. IDNA is
- only meant for processing domain names, not free text.
-
-Table of Contents
-
- 1. Introduction.................................................. 2
- 1.1 Problem Statement......................................... 3
- 1.2 Limitations of IDNA....................................... 3
- 1.3 Brief overview for application developers................. 4
- 2. Terminology................................................... 5
- 3. Requirements and applicability................................ 7
- 3.1 Requirements.............................................. 7
- 3.2 Applicability............................................. 8
- 3.2.1. DNS resource records................................ 8
-
-
-
-Faltstrom, et al. Standards Track [Page 1]
-
-RFC 3490 IDNA March 2003
-
-
- 3.2.2. Non-domain-name data types stored in domain names... 9
- 4. Conversion operations......................................... 9
- 4.1 ToASCII................................................... 10
- 4.2 ToUnicode................................................. 11
- 5. ACE prefix.................................................... 12
- 6. Implications for typical applications using DNS............... 13
- 6.1 Entry and display in applications......................... 14
- 6.2 Applications and resolver libraries....................... 15
- 6.3 DNS servers............................................... 15
- 6.4 Avoiding exposing users to the raw ACE encoding........... 16
- 6.5 DNSSEC authentication of IDN domain names................ 16
- 7. Name server considerations.................................... 17
- 8. Root server considerations.................................... 17
- 9. References.................................................... 18
- 9.1 Normative References...................................... 18
- 9.2 Informative References.................................... 18
- 10. Security Considerations...................................... 19
- 11. IANA Considerations.......................................... 20
- 12. Authors' Addresses........................................... 21
- 13. Full Copyright Statement..................................... 22
-
-1. Introduction
-
- IDNA works by allowing applications to use certain ASCII name labels
- (beginning with a special prefix) to represent non-ASCII name labels.
- Lower-layer protocols need not be aware of this; therefore IDNA does
- not depend on changes to any infrastructure. In particular, IDNA
- does not depend on any changes to DNS servers, resolvers, or protocol
- elements, because the ASCII name service provided by the existing DNS
- is entirely sufficient for IDNA.
-
- This document does not require any applications to conform to IDNA,
- but applications can elect to use IDNA in order to support IDN while
- maintaining interoperability with existing infrastructure. If an
- application wants to use non-ASCII characters in domain names, IDNA
- is the only currently-defined option. Adding IDNA support to an
- existing application entails changes to the application only, and
- leaves room for flexibility in the user interface.
-
- A great deal of the discussion of IDN solutions has focused on
- transition issues and how IDN will work in a world where not all of
- the components have been updated. Proposals that were not chosen by
- the IDN Working Group would depend on user applications, resolvers,
- and DNS servers being updated in order for a user to use an
- internationalized domain name. Rather than rely on widespread
- updating of all components, IDNA depends on updates to user
- applications only; no changes are needed to the DNS protocol or any
- DNS servers or the resolvers on user's computers.
-
-
-
-Faltstrom, et al. Standards Track [Page 2]
-
-RFC 3490 IDNA March 2003
-
-
-1.1 Problem Statement
-
- The IDNA specification solves the problem of extending the repertoire
- of characters that can be used in domain names to include the Unicode
- repertoire (with some restrictions).
-
- IDNA does not extend the service offered by DNS to the applications.
- Instead, the applications (and, by implication, the users) continue
- to see an exact-match lookup service. Either there is a single
- exactly-matching name or there is no match. This model has served
- the existing applications well, but it requires, with or without
- internationalized domain names, that users know the exact spelling of
- the domain names that the users type into applications such as web
- browsers and mail user agents. The introduction of the larger
- repertoire of characters potentially makes the set of misspellings
- larger, especially given that in some cases the same appearance, for
- example on a business card, might visually match several Unicode code
- points or several sequences of code points.
-
- IDNA allows the graceful introduction of IDNs not only by avoiding
- upgrades to existing infrastructure (such as DNS servers and mail
- transport agents), but also by allowing some rudimentary use of IDNs
- in applications by using the ASCII representation of the non-ASCII
- name labels. While such names are very user-unfriendly to read and
- type, and hence are not suitable for user input, they allow (for
- instance) replying to email and clicking on URLs even though the
- domain name displayed is incomprehensible to the user. In order to
- allow user-friendly input and output of the IDNs, the applications
- need to be modified to conform to this specification.
-
- IDNA uses the Unicode character repertoire, which avoids the
- significant delays that would be inherent in waiting for a different
- and specific character set be defined for IDN purposes by some other
- standards developing organization.
-
-1.2 Limitations of IDNA
-
- The IDNA protocol does not solve all linguistic issues with users
- inputting names in different scripts. Many important language-based
- and script-based mappings are not covered in IDNA and need to be
- handled outside the protocol. For example, names that are entered in
- a mix of traditional and simplified Chinese characters will not be
- mapped to a single canonical name. Another example is Scandinavian
- names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
- DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
- STROKE).
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 3]
-
-RFC 3490 IDNA March 2003
-
-
- An example of an important issue that is not considered in detail in
- IDNA is how to provide a high probability that a user who is entering
- a domain name based on visual information (such as from a business
- card or billboard) or aural information (such as from a telephone or
- radio) would correctly enter the IDN. Similar issues exist for ASCII
- domain names, for example the possible visual confusion between the
- letter 'O' and the digit zero, but the introduction of the larger
- repertoire of characters creates more opportunities of similar
- looking and similar sounding names. Note that this is a complex
- issue relating to languages, input methods on computers, and so on.
- Furthermore, the kind of matching and searching necessary for a high
- probability of success would not fit the role of the DNS and its
- exact matching function.
-
-1.3 Brief overview for application developers
-
- Applications can use IDNA to support internationalized domain names
- anywhere that ASCII domain names are already supported, including DNS
- master files and resolver interfaces. (Applications can also define
- protocols and interfaces that support IDNs directly using non-ASCII
- representations. IDNA does not prescribe any particular
- representation for new protocols, but it still defines which names
- are valid and how they are compared.)
-
- The IDNA protocol is contained completely within applications. It is
- not a client-server or peer-to-peer protocol: everything is done
- inside the application itself. When used with a DNS resolver
- library, IDNA is inserted as a "shim" between the application and the
- resolver library. When used for writing names into a DNS zone, IDNA
- is used just before the name is committed to the zone.
-
- There are two operations described in section 4 of this document:
-
- - The ToASCII operation is used before sending an IDN to something
- that expects ASCII names (such as a resolver) or writing an IDN
- into a place that expects ASCII names (such as a DNS master file).
-
- - The ToUnicode operation is used when displaying names to users,
- for example names obtained from a DNS zone.
-
- It is important to note that the ToASCII operation can fail. If it
- fails when processing a domain name, that domain name cannot be used
- as an internationalized domain name and the application has to have
- some method of dealing with this failure.
-
- IDNA requires that implementations process input strings with
- Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
- and then with Punycode [PUNYCODE]. Implementations of IDNA MUST
-
-
-
-Faltstrom, et al. Standards Track [Page 4]
-
-RFC 3490 IDNA March 2003
-
-
- fully implement Nameprep and Punycode; neither Nameprep nor Punycode
- are optional.
-
-2. Terminology
-
- The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
- and "MAY" in this document are to be interpreted as described in BCP
- 14, RFC 2119 [RFC2119].
-
- A code point is an integer value associated with a character in a
- coded character set.
-
- Unicode [UNICODE] is a coded character set containing tens of
- thousands of characters. A single Unicode code point is denoted by
- "U+" followed by four to six hexadecimal digits, while a range of
- Unicode code points is denoted by two hexadecimal numbers separated
- by "..", with no prefixes.
-
- ASCII means US-ASCII [USASCII], a coded character set containing 128
- characters associated with code points in the range 0..7F. Unicode
- is an extension of ASCII: it includes all the ASCII characters and
- associates them with the same code points.
-
- The term "LDH code points" is defined in this document to mean the
- code points associated with ASCII letters, digits, and the hyphen-
- minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
- abbreviation for "letters, digits, hyphen".
-
- [STD13] talks about "domain names" and "host names", but many people
- use the terms interchangeably. Further, because [STD13] was not
- terribly clear, many people who are sure they know the exact
- definitions of each of these terms disagree on the definitions. In
- this document the term "domain name" is used in general. This
- document explicitly cites [STD3] whenever referring to the host name
- syntax restrictions defined therein.
-
- A label is an individual part of a domain name. Labels are usually
- shown separated by dots; for example, the domain name
- "www.example.com" is composed of three labels: "www", "example", and
- "com". (The zero-length root label described in [STD13], which can
- be explicit as in "www.example.com." or implicit as in
- "www.example.com", is not considered a label in this specification.)
- IDNA extends the set of usable characters in labels that are text.
- For the rest of this document, the term "label" is shorthand for
- "text label", and "every label" means "every text label".
-
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 5]
-
-RFC 3490 IDNA March 2003
-
-
- An "internationalized label" is a label to which the ToASCII
- operation (see section 4) can be applied without failing (with the
- UseSTD3ASCIIRules flag unset). This implies that every ASCII label
- that satisfies the [STD13] length restriction is an internationalized
- label. Therefore the term "internationalized label" is a
- generalization, embracing both old ASCII labels and new non-ASCII
- labels. Although most Unicode characters can appear in
- internationalized labels, ToASCII will fail for some input strings,
- and such strings are not valid internationalized labels.
-
- An "internationalized domain name" (IDN) is a domain name in which
- every label is an internationalized label. This implies that every
- ASCII domain name is an IDN (which implies that it is possible for a
- name to be an IDN without it containing any non-ASCII characters).
- This document does not attempt to define an "internationalized host
- name". Just as has been the case with ASCII names, some DNS zone
- administrators may impose restrictions, beyond those imposed by DNS
- or IDNA, on the characters or strings that may be registered as
- labels in their zones. Such restrictions have no impact on the
- syntax or semantics of DNS protocol messages; a query for a name that
- matches no records will yield the same response regardless of the
- reason why it is not in the zone. Clients issuing queries or
- interpreting responses cannot be assumed to have any knowledge of
- zone-specific restrictions or conventions.
-
- In IDNA, equivalence of labels is defined in terms of the ToASCII
- operation, which constructs an ASCII form for a given label, whether
- or not the label was already an ASCII label. Labels are defined to
- be equivalent if and only if their ASCII forms produced by ToASCII
- match using a case-insensitive ASCII comparison. ASCII labels
- already have a notion of equivalence: upper case and lower case are
- considered equivalent. The IDNA notion of equivalence is an
- extension of that older notion. Equivalent labels in IDNA are
- treated as alternate forms of the same label, just as "foo" and "Foo"
- are treated as alternate forms of the same label.
-
- To allow internationalized labels to be handled by existing
- applications, IDNA uses an "ACE label" (ACE stands for ASCII
- Compatible Encoding). An ACE label is an internationalized label
- that can be rendered in ASCII and is equivalent to an
- internationalized label that cannot be rendered in ASCII. Given any
- internationalized label that cannot be rendered in ASCII, the ToASCII
- operation will convert it to an equivalent ACE label (whereas an
- ASCII label will be left unaltered by ToASCII). ACE labels are
- unsuitable for display to users. The ToUnicode operation will
- convert any label to an equivalent non-ACE label. In fact, an ACE
- label is formally defined to be any label that the ToUnicode
- operation would alter (whereas non-ACE labels are left unaltered by
-
-
-
-Faltstrom, et al. Standards Track [Page 6]
-
-RFC 3490 IDNA March 2003
-
-
- ToUnicode). Every ACE label begins with the ACE prefix specified in
- section 5. The ToASCII and ToUnicode operations are specified in
- section 4.
-
- The "ACE prefix" is defined in this document to be a string of ASCII
- characters that appears at the beginning of every ACE label. It is
- specified in section 5.
-
- A "domain name slot" is defined in this document to be a protocol
- element or a function argument or a return value (and so on)
- explicitly designated for carrying a domain name. Examples of domain
- name slots include: the QNAME field of a DNS query; the name argument
- of the gethostbyname() library function; the part of an email address
- following the at-sign (@) in the From: field of an email message
- header; and the host portion of the URI in the src attribute of an
- HTML <IMG> tag. General text that just happens to contain a domain
- name is not a domain name slot; for example, a domain name appearing
- in the plain text body of an email message is not occupying a domain
- name slot.
-
- An "IDN-aware domain name slot" is defined in this document to be a
- domain name slot explicitly designated for carrying an
- internationalized domain name as defined in this document. The
- designation may be static (for example, in the specification of the
- protocol or interface) or dynamic (for example, as a result of
- negotiation in an interactive session).
-
- An "IDN-unaware domain name slot" is defined in this document to be
- any domain name slot that is not an IDN-aware domain name slot.
- Obviously, this includes any domain name slot whose specification
- predates IDNA.
-
-3. Requirements and applicability
-
-3.1 Requirements
-
- IDNA conformance means adherence to the following four requirements:
-
- 1) Whenever dots are used as label separators, the following
- characters MUST be recognized as dots: U+002E (full stop), U+3002
- (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
- (halfwidth ideographic full stop).
-
- 2) Whenever a domain name is put into an IDN-unaware domain name slot
- (see section 2), it MUST contain only ASCII characters. Given an
- internationalized domain name (IDN), an equivalent domain name
- satisfying this requirement can be obtained by applying the
-
-
-
-
-Faltstrom, et al. Standards Track [Page 7]
-
-RFC 3490 IDNA March 2003
-
-
- ToASCII operation (see section 4) to each label and, if dots are
- used as label separators, changing all the label separators to
- U+002E.
-
- 3) ACE labels obtained from domain name slots SHOULD be hidden from
- users when it is known that the environment can handle the non-ACE
- form, except when the ACE form is explicitly requested. When it
- is not known whether or not the environment can handle the non-ACE
- form, the application MAY use the non-ACE form (which might fail,
- such as by not being displayed properly), or it MAY use the ACE
- form (which will look unintelligle to the user). Given an
- internationalized domain name, an equivalent domain name
- containing no ACE labels can be obtained by applying the ToUnicode
- operation (see section 4) to each label. When requirements 2 and
- 3 both apply, requirement 2 takes precedence.
-
- 4) Whenever two labels are compared, they MUST be considered to match
- if and only if they are equivalent, that is, their ASCII forms
- (obtained by applying ToASCII) match using a case-insensitive
- ASCII comparison. Whenever two names are compared, they MUST be
- considered to match if and only if their corresponding labels
- match, regardless of whether the names use the same forms of label
- separators.
-
-3.2 Applicability
-
- IDNA is applicable to all domain names in all domain name slots
- except where it is explicitly excluded.
-
- This implies that IDNA is applicable to many protocols that predate
- IDNA. Note that IDNs occupying domain name slots in those protocols
- MUST be in ASCII form (see section 3.1, requirement 2).
-
-3.2.1. DNS resource records
-
- IDNA does not apply to domain names in the NAME and RDATA fields of
- DNS resource records whose CLASS is not IN. This exclusion applies
- to every non-IN class, present and future, except where future
- standards override this exclusion by explicitly inviting the use of
- IDNA.
-
- There are currently no other exclusions on the applicability of IDNA
- to DNS resource records; it depends entirely on the CLASS, and not on
- the TYPE. This will remain true, even as new types are defined,
- unless there is a compelling reason for a new type to complicate
- matters by imposing type-specific rules.
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 8]
-
-RFC 3490 IDNA March 2003
-
-
-3.2.2. Non-domain-name data types stored in domain names
-
- Although IDNA enables the representation of non-ASCII characters in
- domain names, that does not imply that IDNA enables the
- representation of non-ASCII characters in other data types that are
- stored in domain names. For example, an email address local part is
- sometimes stored in a domain label (hostmaster@example.com would be
- represented as hostmaster.example.com in the RDATA field of an SOA
- record). IDNA does not update the existing email standards, which
- allow only ASCII characters in local parts. Therefore, unless the
- email standards are revised to invite the use of IDNA for local
- parts, a domain label that holds the local part of an email address
- SHOULD NOT begin with the ACE prefix, and even if it does, it is to
- be interpreted literally as a local part that happens to begin with
- the ACE prefix.
-
-4. Conversion operations
-
- An application converts a domain name put into an IDN-unaware slot or
- displayed to a user. This section specifies the steps to perform in
- the conversion, and the ToASCII and ToUnicode operations.
-
- The input to ToASCII or ToUnicode is a single label that is a
- sequence of Unicode code points (remember that all ASCII code points
- are also Unicode code points). If a domain name is represented using
- a character set other than Unicode or US-ASCII, it will first need to
- be transcoded to Unicode.
-
- Starting from a whole domain name, the steps that an application
- takes to do the conversions are:
-
- 1) Decide whether the domain name is a "stored string" or a "query
- string" as described in [STRINGPREP]. If this conversion follows
- the "queries" rule from [STRINGPREP], set the flag called
- "AllowUnassigned".
-
- 2) Split the domain name into individual labels as described in
- section 3.1. The labels do not include the separator.
-
- 3) For each label, decide whether or not to enforce the restrictions
- on ASCII characters in host names [STD3]. (Applications already
- faced this choice before the introduction of IDNA, and can
- continue to make the decision the same way they always have; IDNA
- makes no new recommendations regarding this choice.) If the
- restrictions are to be enforced, set the flag called
- "UseSTD3ASCIIRules" for that label.
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 9]
-
-RFC 3490 IDNA March 2003
-
-
- 4) Process each label with either the ToASCII or the ToUnicode
- operation as appropriate. Typically, you use the ToASCII
- operation if you are about to put the name into an IDN-unaware
- slot, and you use the ToUnicode operation if you are displaying
- the name to a user; section 3.1 gives greater detail on the
- applicable requirements.
-
- 5) If ToASCII was applied in step 4 and dots are used as label
- separators, change all the label separators to U+002E (full stop).
-
- The following two subsections define the ToASCII and ToUnicode
- operations that are used in step 4.
-
- This description of the protocol uses specific procedure names, names
- of flags, and so on, in order to facilitate the specification of the
- protocol. These names, as well as the actual steps of the
- procedures, are not required of an implementation. In fact, any
- implementation which has the same external behavior as specified in
- this document conforms to this specification.
-
-4.1 ToASCII
-
- The ToASCII operation takes a sequence of Unicode code points that
- make up one label and transforms it into a sequence of code points in
- the ASCII range (0..7F). If ToASCII succeeds, the original sequence
- and the resulting sequence are equivalent labels.
-
- It is important to note that the ToASCII operation can fail. ToASCII
- fails if any step of it fails. If any step of the ToASCII operation
- fails on any label in a domain name, that domain name MUST NOT be
- used as an internationalized domain name. The method for dealing
- with this failure is application-specific.
-
- The inputs to ToASCII are a sequence of code points, the
- AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of
- ToASCII is either a sequence of ASCII code points or a failure
- condition.
-
- ToASCII never alters a sequence of code points that are all in the
- ASCII range to begin with (although it could fail). Applying the
- ToASCII operation multiple times has exactly the same effect as
- applying it just once.
-
- ToASCII consists of the following steps:
-
- 1. If the sequence contains any code points outside the ASCII range
- (0..7F) then proceed to step 2, otherwise skip to step 3.
-
-
-
-
-Faltstrom, et al. Standards Track [Page 10]
-
-RFC 3490 IDNA March 2003
-
-
- 2. Perform the steps specified in [NAMEPREP] and fail if there is an
- error. The AllowUnassigned flag is used in [NAMEPREP].
-
- 3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
-
- (a) Verify the absence of non-LDH ASCII code points; that is, the
- absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
-
- (b) Verify the absence of leading and trailing hyphen-minus; that
- is, the absence of U+002D at the beginning and end of the
- sequence.
-
- 4. If the sequence contains any code points outside the ASCII range
- (0..7F) then proceed to step 5, otherwise skip to step 8.
-
- 5. Verify that the sequence does NOT begin with the ACE prefix.
-
- 6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
- fail if there is an error.
-
- 7. Prepend the ACE prefix.
-
- 8. Verify that the number of code points is in the range 1 to 63
- inclusive.
-
-4.2 ToUnicode
-
- The ToUnicode operation takes a sequence of Unicode code points that
- make up one label and returns a sequence of Unicode code points. If
- the input sequence is a label in ACE form, then the result is an
- equivalent internationalized label that is not in ACE form, otherwise
- the original sequence is returned unaltered.
-
- ToUnicode never fails. If any step fails, then the original input
- sequence is returned immediately in that step.
-
- The ToUnicode output never contains more code points than its input.
- Note that the number of octets needed to represent a sequence of code
- points depends on the particular character encoding used.
-
- The inputs to ToUnicode are a sequence of code points, the
- AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of
- ToUnicode is always a sequence of Unicode code points.
-
- 1. If all code points in the sequence are in the ASCII range (0..7F)
- then skip to step 3.
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 11]
-
-RFC 3490 IDNA March 2003
-
-
- 2. Perform the steps specified in [NAMEPREP] and fail if there is an
- error. (If step 3 of ToASCII is also performed here, it will not
- affect the overall behavior of ToUnicode, but it is not
- necessary.) The AllowUnassigned flag is used in [NAMEPREP].
-
- 3. Verify that the sequence begins with the ACE prefix, and save a
- copy of the sequence.
-
- 4. Remove the ACE prefix.
-
- 5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
- fail if there is an error. Save a copy of the result of this
- step.
-
- 6. Apply ToASCII.
-
- 7. Verify that the result of step 6 matches the saved copy from step
- 3, using a case-insensitive ASCII comparison.
-
- 8. Return the saved copy from step 5.
-
-5. ACE prefix
-
- The ACE prefix, used in the conversion operations (section 4), is two
- alphanumeric ASCII characters followed by two hyphen-minuses. It
- cannot be any of the prefixes already used in earlier documents,
- which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
- "ra--", "wq--" and "zq--". The ToASCII and ToUnicode operations MUST
- recognize the ACE prefix in a case-insensitive manner.
-
- The ACE prefix for IDNA is "xn--" or any capitalization thereof.
-
- This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
- "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
- the encoding steps in [PUNYCODE].
-
- While all ACE labels begin with the ACE prefix, not all labels
- beginning with the ACE prefix are necessarily ACE labels. Non-ACE
- labels that begin with the ACE prefix will confuse users and SHOULD
- NOT be allowed in DNS zones.
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 12]
-
-RFC 3490 IDNA March 2003
-
-
-6. Implications for typical applications using DNS
-
- In IDNA, applications perform the processing needed to input
- internationalized domain names from users, display internationalized
- domain names to users, and process the inputs and outputs from DNS
- and other protocols that carry domain names.
-
- The components and interfaces between them can be represented
- pictorially as:
-
- +------+
- | User |
- +------+
- ^
- | Input and display: local interface methods
- | (pen, keyboard, glowing phosphorus, ...)
- +-------------------|-------------------------------+
- | v |
- | +-----------------------------+ |
- | | Application | |
- | | (ToASCII and ToUnicode | |
- | | operations may be | |
- | | called here) | |
- | +-----------------------------+ |
- | ^ ^ | End system
- | | | |
- | Call to resolver: | | Application-specific |
- | ACE | | protocol: |
- | v | ACE unless the |
- | +----------+ | protocol is updated |
- | | Resolver | | to handle other |
- | +----------+ | encodings |
- | ^ | |
- +-----------------|----------|----------------------+
- DNS protocol: | |
- ACE | |
- v v
- +-------------+ +---------------------+
- | DNS servers | | Application servers |
- +-------------+ +---------------------+
-
- The box labeled "Application" is where the application splits a
- domain name into labels, sets the appropriate flags, and performs the
- ToASCII and ToUnicode operations. This is described in section 4.
-
-
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 13]
-
-RFC 3490 IDNA March 2003
-
-
-6.1 Entry and display in applications
-
- Applications can accept domain names using any character set or sets
- desired by the application developer, and can display domain names in
- any charset. That is, the IDNA protocol does not affect the
- interface between users and applications.
-
- An IDNA-aware application can accept and display internationalized
- domain names in two formats: the internationalized character set(s)
- supported by the application, and as an ACE label. ACE labels that
- are displayed or input MUST always include the ACE prefix.
- Applications MAY allow input and display of ACE labels, but are not
- encouraged to do so except as an interface for special purposes,
- possibly for debugging, or to cope with display limitations as
- described in section 6.4.. ACE encoding is opaque and ugly, and
- should thus only be exposed to users who absolutely need it. Because
- name labels encoded as ACE name labels can be rendered either as the
- encoded ASCII characters or the proper decoded characters, the
- application MAY have an option for the user to select the preferred
- method of display; if it does, rendering the ACE SHOULD NOT be the
- default.
-
- Domain names are often stored and transported in many places. For
- example, they are part of documents such as mail messages and web
- pages. They are transported in many parts of many protocols, such as
- both the control commands and the RFC 2822 body parts of SMTP, and
- the headers and the body content in HTTP. It is important to
- remember that domain names appear both in domain name slots and in
- the content that is passed over protocols.
-
- In protocols and document formats that define how to handle
- specification or negotiation of charsets, labels can be encoded in
- any charset allowed by the protocol or document format. If a
- protocol or document format only allows one charset, the labels MUST
- be given in that charset.
-
- In any place where a protocol or document format allows transmission
- of the characters in internationalized labels, internationalized
- labels SHOULD be transmitted using whatever character encoding and
- escape mechanism that the protocol or document format uses at that
- place.
-
- All protocols that use domain name slots already have the capacity
- for handling domain names in the ASCII charset. Thus, ACE labels
- (internationalized labels that have been processed with the ToASCII
- operation) can inherently be handled by those protocols.
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 14]
-
-RFC 3490 IDNA March 2003
-
-
-6.2 Applications and resolver libraries
-
- Applications normally use functions in the operating system when they
- resolve DNS queries. Those functions in the operating system are
- often called "the resolver library", and the applications communicate
- with the resolver libraries through a programming interface (API).
-
- Because these resolver libraries today expect only domain names in
- ASCII, applications MUST prepare labels that are passed to the
- resolver library using the ToASCII operation. Labels received from
- the resolver library contain only ASCII characters; internationalized
- labels that cannot be represented directly in ASCII use the ACE form.
- ACE labels always include the ACE prefix.
-
- An operating system might have a set of libraries for performing the
- ToASCII operation. The input to such a library might be in one or
- more charsets that are used in applications (UTF-8 and UTF-16 are
- likely candidates for almost any operating system, and script-
- specific charsets are likely for localized operating systems).
-
- IDNA-aware applications MUST be able to work with both non-
- internationalized labels (those that conform to [STD13] and [STD3])
- and internationalized labels.
-
- It is expected that new versions of the resolver libraries in the
- future will be able to accept domain names in other charsets than
- ASCII, and application developers might one day pass not only domain
- names in Unicode, but also in local script to a new API for the
- resolver libraries in the operating system. Thus the ToASCII and
- ToUnicode operations might be performed inside these new versions of
- the resolver libraries.
-
- Domain names passed to resolvers or put into the question section of
- DNS requests follow the rules for "queries" from [STRINGPREP].
-
-6.3 DNS servers
-
- Domain names stored in zones follow the rules for "stored strings"
- from [STRINGPREP].
-
- For internationalized labels that cannot be represented directly in
- ASCII, DNS servers MUST use the ACE form produced by the ToASCII
- operation. All IDNs served by DNS servers MUST contain only ASCII
- characters.
-
- If a signaling system which makes negotiation possible between old
- and new DNS clients and servers is standardized in the future, the
- encoding of the query in the DNS protocol itself can be changed from
-
-
-
-Faltstrom, et al. Standards Track [Page 15]
-
-RFC 3490 IDNA March 2003
-
-
- ACE to something else, such as UTF-8. The question whether or not
- this should be used is, however, a separate problem and is not
- discussed in this memo.
-
-6.4 Avoiding exposing users to the raw ACE encoding
-
- Any application that might show the user a domain name obtained from
- a domain name slot, such as from gethostbyaddr or part of a mail
- header, will need to be updated if it is to prevent users from seeing
- the ACE.
-
- If an application decodes an ACE name using ToUnicode but cannot show
- all of the characters in the decoded name, such as if the name
- contains characters that the output system cannot display, the
- application SHOULD show the name in ACE format (which always includes
- the ACE prefix) instead of displaying the name with the replacement
- character (U+FFFD). This is to make it easier for the user to
- transfer the name correctly to other programs. Programs that by
- default show the ACE form when they cannot show all the characters in
- a name label SHOULD also have a mechanism to show the name that is
- produced by the ToUnicode operation with as many characters as
- possible and replacement characters in the positions where characters
- cannot be displayed.
-
- The ToUnicode operation does not alter labels that are not valid ACE
- labels, even if they begin with the ACE prefix. After ToUnicode has
- been applied, if a label still begins with the ACE prefix, then it is
- not a valid ACE label, and is not equivalent to any of the
- intermediate Unicode strings constructed by ToUnicode.
-
-6.5 DNSSEC authentication of IDN domain names
-
- DNS Security [RFC2535] is a method for supplying cryptographic
- verification information along with DNS messages. Public Key
- Cryptography is used in conjunction with digital signatures to
- provide a means for a requester of domain information to authenticate
- the source of the data. This ensures that it can be traced back to a
- trusted source, either directly, or via a chain of trust linking the
- source of the information to the top of the DNS hierarchy.
-
- IDNA specifies that all internationalized domain names served by DNS
- servers that cannot be represented directly in ASCII must use the ACE
- form produced by the ToASCII operation. This operation must be
- performed prior to a zone being signed by the private key for that
- zone. Because of this ordering, it is important to recognize that
- DNSSEC authenticates the ASCII domain name, not the Unicode form or
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 16]
-
-RFC 3490 IDNA March 2003
-
-
- the mapping between the Unicode form and the ASCII form. In the
- presence of DNSSEC, this is the name that MUST be signed in the zone
- and MUST be validated against.
-
- One consequence of this for sites deploying IDNA in the presence of
- DNSSEC is that any special purpose proxies or forwarders used to
- transform user input into IDNs must be earlier in the resolution flow
- than DNSSEC authenticating nameservers for DNSSEC to work.
-
-7. Name server considerations
-
- Existing DNS servers do not know the IDNA rules for handling non-
- ASCII forms of IDNs, and therefore need to be shielded from them.
- All existing channels through which names can enter a DNS server
- database (for example, master files [STD13] and DNS update messages
- [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
- requirement 2 of section 3.1 of this document provides the needed
- shielding, by ensuring that internationalized domain names entering
- DNS server databases through such channels have already been
- converted to their equivalent ASCII forms.
-
- It is imperative that there be only one ASCII encoding for a
- particular domain name. Because of the design of the ToASCII and
- ToUnicode operations, there are no ACE labels that decode to ASCII
- labels, and therefore name servers cannot contain multiple ASCII
- encodings of the same domain name.
-
- [RFC2181] explicitly allows domain labels to contain octets beyond
- the ASCII range (0..7F), and this document does not change that.
- Note, however, that there is no defined interpretation of octets
- 80..FF as characters. If labels containing these octets are returned
- to applications, unpredictable behavior could result. The ASCII form
- defined by ToASCII is the only standard representation for
- internationalized labels in the current DNS protocol.
-
-8. Root server considerations
-
- IDNs are likely to be somewhat longer than current domain names, so
- the bandwidth needed by the root servers is likely to go up by a
- small amount. Also, queries and responses for IDNs will probably be
- somewhat longer than typical queries today, so more queries and
- responses may be forced to go to TCP instead of UDP.
-
-
-
-
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 17]
-
-RFC 3490 IDNA March 2003
-
-
-9. References
-
-9.1 Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings ("stringprep")", RFC 3454,
- December 2002.
-
- [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
- Profile for Internationalized Domain Names (IDN)", RFC
- 3491, March 2003.
-
- [PUNYCODE] Costello, A., "Punycode: A Bootstring encoding of
- Unicode for use with Internationalized Domain Names in
- Applications (IDNA)", RFC 3492, March 2003.
-
- [STD3] Braden, R., "Requirements for Internet Hosts --
- Communication Layers", STD 3, RFC 1122, and
- "Requirements for Internet Hosts -- Application and
- Support", STD 3, RFC 1123, October 1989.
-
- [STD13] Mockapetris, P., "Domain names - concepts and
- facilities", STD 13, RFC 1034 and "Domain names -
- implementation and specification", STD 13, RFC 1035,
- November 1987.
-
-9.2 Informative References
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm,
- <http://www.unicode.org/unicode/reports/tr9/>.
-
- [UNICODE] The Unicode Consortium. The Unicode Standard, Version
- 3.2.0 is defined by The Unicode Standard, Version 3.0
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the Unicode Standard Annex #27: Unicode
- 3.1 (http://www.unicode.org/reports/tr27/) and by the
- Unicode Standard Annex #28: Unicode 3.2
- (http://www.unicode.org/reports/tr28/).
-
-
-
-
-Faltstrom, et al. Standards Track [Page 18]
-
-RFC 3490 IDNA March 2003
-
-
- [USASCII] Cerf, V., "ASCII format for Network Interchange", RFC
- 20, October 1969.
-
-10. Security Considerations
-
- Security on the Internet partly relies on the DNS. Thus, any change
- to the characteristics of the DNS can change the security of much of
- the Internet.
-
- This memo describes an algorithm which encodes characters that are
- not valid according to STD3 and STD13 into octet values that are
- valid. No security issues such as string length increases or new
- allowed values are introduced by the encoding process or the use of
- these encoded values, apart from those introduced by the ACE encoding
- itself.
-
- Domain names are used by users to identify and connect to Internet
- servers. The security of the Internet is compromised if a user
- entering a single internationalized name is connected to different
- servers based on different interpretations of the internationalized
- domain name.
-
- When systems use local character sets other than ASCII and Unicode,
- this specification leaves the the problem of transcoding between the
- local character set and Unicode up to the application. If different
- applications (or different versions of one application) implement
- different transcoding rules, they could interpret the same name
- differently and contact different servers. This problem is not
- solved by security protocols like TLS that do not take local
- character sets into account.
-
- Because this document normatively refers to [NAMEPREP], [PUNYCODE],
- and [STRINGPREP], it includes the security considerations from those
- documents as well.
-
- If or when this specification is updated to use a more recent Unicode
- normalization table, the new normalization table will need to be
- compared with the old to spot backwards incompatible changes. If
- there are such changes, they will need to be handled somehow, or
- there will be security as well as operational implications. Methods
- to handle the conflicts could include keeping the old normalization,
- or taking care of the conflicting characters by operational means, or
- some other method.
-
- Implementations MUST NOT use more recent normalization tables than
- the one referenced from this document, even though more recent tables
- may be provided by operating systems. If an application is unsure of
- which version of the normalization tables are in the operating
-
-
-
-Faltstrom, et al. Standards Track [Page 19]
-
-RFC 3490 IDNA March 2003
-
-
- system, the application needs to include the normalization tables
- itself. Using normalization tables other than the one referenced
- from this specification could have security and operational
- implications.
-
- To help prevent confusion between characters that are visually
- similar, it is suggested that implementations provide visual
- indications where a domain name contains multiple scripts. Such
- mechanisms can also be used to show when a name contains a mixture of
- simplified and traditional Chinese characters, or to distinguish zero
- and one from O and l. DNS zone adminstrators may impose restrictions
- (subject to the limitations in section 2) that try to minimize
- homographs.
-
- Domain names (or portions of them) are sometimes compared against a
- set of privileged or anti-privileged domains. In such situations it
- is especially important that the comparisons be done properly, as
- specified in section 3.1 requirement 4. For labels already in ASCII
- form, the proper comparison reduces to the same case-insensitive
- ASCII comparison that has always been used for ASCII labels.
-
- The introduction of IDNA means that any existing labels that start
- with the ACE prefix and would be altered by ToUnicode will
- automatically be ACE labels, and will be considered equivalent to
- non-ASCII labels, whether or not that was the intent of the zone
- adminstrator or registrant.
-
-11. IANA Considerations
-
- IANA has assigned the ACE prefix in consultation with the IESG.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 20]
-
-RFC 3490 IDNA March 2003
-
-
-12. Authors' Addresses
-
- Patrik Faltstrom
- Cisco Systems
- Arstaangsvagen 31 J
- S-117 43 Stockholm Sweden
-
- EMail: paf@cisco.com
-
-
- Paul Hoffman
- Internet Mail Consortium and VPN Consortium
- 127 Segre Place
- Santa Cruz, CA 95060 USA
-
- EMail: phoffman@imc.org
-
-
- Adam M. Costello
- University of California, Berkeley
-
- URL: http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 21]
-
-RFC 3490 IDNA March 2003
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al. Standards Track [Page 22]
-
diff --git a/contrib/bind9/doc/rfc/rfc3491.txt b/contrib/bind9/doc/rfc/rfc3491.txt
deleted file mode 100644
index dbc86c7fe4c0d..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3491.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Hoffman
-Request for Comments: 3491 IMC & VPNC
-Category: Standards Track M. Blanchet
- Viagenie
- March 2003
-
-
- Nameprep: A Stringprep Profile for
- Internationalized Domain Names (IDN)
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- This document describes how to prepare internationalized domain name
- (IDN) labels in order to increase the likelihood that name input and
- name comparison work in ways that make sense for typical users
- throughout the world. This profile of the stringprep protocol is
- used as part of a suite of on-the-wire protocols for
- internationalizing the Domain Name System (DNS).
-
-1. Introduction
-
- This document specifies processing rules that will allow users to
- enter internationalized domain names (IDNs) into applications and
- have the highest chance of getting the content of the strings
- correct. It is a profile of stringprep [STRINGPREP]. These
- processing rules are only intended for internationalized domain
- names, not for arbitrary text.
-
- This profile defines the following, as required by [STRINGPREP].
-
- - The intended applicability of the profile: internationalized
- domain names processed by IDNA.
-
- - The character repertoire that is the input and output to
- stringprep: Unicode 3.2, specified in section 2.
-
-
-
-
-Hoffman & Blanchet Standards Track [Page 1]
-
-RFC 3491 IDN Nameprep March 2003
-
-
- - The mappings used: specified in section 3.
-
- - The Unicode normalization used: specified in section 4.
-
- - The characters that are prohibited as output: specified in section
- 5.
-
- - Bidirectional character handling: specified in section 6.
-
-1.1 Interaction of protocol parts
-
- Nameprep is used by the IDNA [IDNA] protocol for preparing domain
- names; it is not designed for any other purpose. It is explicitly
- not designed for processing arbitrary free text and SHOULD NOT be
- used for that purpose. Nameprep is a profile of Stringprep
- [STRINGPREP]. Implementations of Nameprep MUST fully implement
- Stringprep.
-
- Nameprep is used to process domain name labels, not domain names.
- IDNA calls nameprep for each label in a domain name, not for the
- whole domain name.
-
-1.2 Terminology
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- in this document are to be interpreted as described in BCP 14, RFC
- 2119 [RFC2119].
-
-2. Character Repertoire
-
- This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
-
-3. Mapping
-
- This profile specifies mapping using the following tables from
- [STRINGPREP]:
-
- Table B.1
- Table B.2
-
-4. Normalization
-
- This profile specifies using Unicode normalization form KC, as
- described in [STRINGPREP].
-
-
-
-
-
-
-
-Hoffman & Blanchet Standards Track [Page 2]
-
-RFC 3491 IDN Nameprep March 2003
-
-
-5. Prohibited Output
-
- This profile specifies prohibiting using the following tables from
- [STRINGPREP]:
-
- Table C.1.2
- Table C.2.2
- Table C.3
- Table C.4
- Table C.5
- Table C.6
- Table C.7
- Table C.8
- Table C.9
-
- IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
- The IDNA protocol has additional prohibitions that are checked
- outside of this profile.
-
-6. Bidirectional characters
-
- This profile specifies checking bidirectional strings as described in
- [STRINGPREP] section 6.
-
-7. Unassigned Code Points in Internationalized Domain Names
-
- If the processing in [IDNA] specifies that a list of unassigned code
- points be used, the system uses table A.1 from [STRINGPREP] as its
- list of unassigned code points.
-
-8. References
-
-8.1 Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings ("stringprep")", RFC 3454,
- December 2002.
-
- [IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
- "Internationalizing Domain Names in Applications
- (IDNA)", RFC 3490, March 2003.
-
-
-
-
-
-
-
-Hoffman & Blanchet Standards Track [Page 3]
-
-RFC 3491 IDN Nameprep March 2003
-
-
-8.2 Informative references
-
- [STD13] Mockapetris, P., "Domain names - concepts and
- facilities", STD 13, RFC 1034, and "Domain names -
- implementation and specification", STD 13, RFC 1035,
- November 1987.
-
-9. Security Considerations
-
- The Unicode and ISO/IEC 10646 repertoires have many characters that
- look similar. In many cases, users of security protocols might do
- visual matching, such as when comparing the names of trusted third
- parties. Because it is impossible to map similar-looking characters
- without a great deal of context such as knowing the fonts used,
- stringprep does nothing to map similar-looking characters together
- nor to prohibit some characters because they look like others.
-
- Security on the Internet partly relies on the DNS. Thus, any change
- to the characteristics of the DNS can change the security of much of
- the Internet.
-
- Domain names are used by users to connect to Internet servers. The
- security of the Internet would be compromised if a user entering a
- single internationalized name could be connected to different servers
- based on different interpretations of the internationalized domain
- name.
-
- Current applications might assume that the characters allowed in
- domain names will always be the same as they are in [STD13]. This
- document vastly increases the number of characters available in
- domain names. Every program that uses "special" characters in
- conjunction with domain names may be vulnerable to attack based on
- the new characters allowed by this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet Standards Track [Page 4]
-
-RFC 3491 IDN Nameprep March 2003
-
-
-10. IANA Considerations
-
- This is a profile of stringprep. It has been registered by the IANA
- in the stringprep profile registry
- (www.iana.org/assignments/stringprep-profiles).
-
- Name of this profile:
- Nameprep
-
- RFC in which the profile is defined:
- This document.
-
- Indicator whether or not this is the newest version of the
- profile:
- This is the first version of Nameprep.
-
-11. Acknowledgements
-
- Many people from the IETF IDN Working Group and the Unicode Technical
- Committee contributed ideas that went into this document.
-
- The IDN Nameprep design team made many useful changes to the
- document. That team and its advisors include:
-
- Asmus Freytag
- Cathy Wissink
- Francois Yergeau
- James Seng
- Marc Blanchet
- Mark Davis
- Martin Duerst
- Patrik Faltstrom
- Paul Hoffman
-
- Additional significant improvements were proposed by:
-
- Jonathan Rosenne
- Kent Karlsson
- Scott Hollenbeck
- Dave Crocker
- Erik Nordmark
- Matitiahu Allouche
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet Standards Track [Page 5]
-
-RFC 3491 IDN Nameprep March 2003
-
-
-12. Authors' Addresses
-
- Paul Hoffman
- Internet Mail Consortium and VPN Consortium
- 127 Segre Place
- Santa Cruz, CA 95060 USA
-
- EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
-
-
- Marc Blanchet
- Viagenie inc.
- 2875 boul. Laurier, bur. 300
- Ste-Foy, Quebec, Canada, G1V 2M2
-
- EMail: Marc.Blanchet@viagenie.qc.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet Standards Track [Page 6]
-
-RFC 3491 IDN Nameprep March 2003
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet Standards Track [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3492.txt b/contrib/bind9/doc/rfc/rfc3492.txt
deleted file mode 100644
index e72ad81a27195..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3492.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Costello
-Request for Comments: 3492 Univ. of California, Berkeley
-Category: Standards Track March 2003
-
-
- Punycode: A Bootstring encoding of Unicode
- for Internationalized Domain Names in Applications (IDNA)
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- Punycode is a simple and efficient transfer encoding syntax designed
- for use with Internationalized Domain Names in Applications (IDNA).
- It uniquely and reversibly transforms a Unicode string into an ASCII
- string. ASCII characters in the Unicode string are represented
- literally, and non-ASCII characters are represented by ASCII
- characters that are allowed in host name labels (letters, digits, and
- hyphens). This document defines a general algorithm called
- Bootstring that allows a string of basic code points to uniquely
- represent any string of code points drawn from a larger set.
- Punycode is an instance of Bootstring that uses particular parameter
- values specified by this document, appropriate for IDNA.
-
-Table of Contents
-
- 1. Introduction...............................................2
- 1.1 Features..............................................2
- 1.2 Interaction of protocol parts.........................3
- 2. Terminology................................................3
- 3. Bootstring description.....................................4
- 3.1 Basic code point segregation..........................4
- 3.2 Insertion unsort coding...............................4
- 3.3 Generalized variable-length integers..................5
- 3.4 Bias adaptation.......................................7
- 4. Bootstring parameters......................................8
- 5. Parameter values for Punycode..............................8
- 6. Bootstring algorithms......................................9
-
-
-
-Costello Standards Track [Page 1]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- 6.1 Bias adaptation function.............................10
- 6.2 Decoding procedure...................................11
- 6.3 Encoding procedure...................................12
- 6.4 Overflow handling....................................13
- 7. Punycode examples.........................................14
- 7.1 Sample strings.......................................14
- 7.2 Decoding traces......................................17
- 7.3 Encoding traces......................................19
- 8. Security Considerations...................................20
- 9. References................................................21
- 9.1 Normative References.................................21
- 9.2 Informative References...............................21
- A. Mixed-case annotation.....................................22
- B. Disclaimer and license....................................22
- C. Punycode sample implementation............................23
- Author's Address.............................................34
- Full Copyright Statement.....................................35
-
-1. Introduction
-
- [IDNA] describes an architecture for supporting internationalized
- domain names. Labels containing non-ASCII characters can be
- represented by ACE labels, which begin with a special ACE prefix and
- contain only ASCII characters. The remainder of the label after the
- prefix is a Punycode encoding of a Unicode string satisfying certain
- constraints. For the details of the prefix and constraints, see
- [IDNA] and [NAMEPREP].
-
- Punycode is an instance of a more general algorithm called
- Bootstring, which allows strings composed from a small set of "basic"
- code points to uniquely represent any string of code points drawn
- from a larger set. Punycode is Bootstring with particular parameter
- values appropriate for IDNA.
-
-1.1 Features
-
- Bootstring has been designed to have the following features:
-
- * Completeness: Every extended string (sequence of arbitrary code
- points) can be represented by a basic string (sequence of basic
- code points). Restrictions on what strings are allowed, and on
- length, can be imposed by higher layers.
-
- * Uniqueness: There is at most one basic string that represents a
- given extended string.
-
- * Reversibility: Any extended string mapped to a basic string can
- be recovered from that basic string.
-
-
-
-Costello Standards Track [Page 2]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- * Efficient encoding: The ratio of basic string length to extended
- string length is small. This is important in the context of
- domain names because RFC 1034 [RFC1034] restricts the length of a
- domain label to 63 characters.
-
- * Simplicity: The encoding and decoding algorithms are reasonably
- simple to implement. The goals of efficiency and simplicity are
- at odds; Bootstring aims at a good balance between them.
-
- * Readability: Basic code points appearing in the extended string
- are represented as themselves in the basic string (although the
- main purpose is to improve efficiency, not readability).
-
- Punycode can also support an additional feature that is not used by
- the ToASCII and ToUnicode operations of [IDNA]. When extended
- strings are case-folded prior to encoding, the basic string can use
- mixed case to tell how to convert the folded string into a mixed-case
- string. See appendix A "Mixed-case annotation".
-
-1.2 Interaction of protocol parts
-
- Punycode is used by the IDNA protocol [IDNA] for converting domain
- labels into ASCII; it is not designed for any other purpose. It is
- explicitly not designed for processing arbitrary free text.
-
-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 BCP 14, RFC 2119
- [RFC2119].
-
- A code point is an integral value associated with a character in a
- coded character set.
-
- As in the Unicode Standard [UNICODE], Unicode code points are denoted
- by "U+" followed by four to six hexadecimal digits, while a range of
- code points is denoted by two hexadecimal numbers separated by "..",
- with no prefixes.
-
- The operators div and mod perform integer division; (x div y) is the
- quotient of x divided by y, discarding the remainder, and (x mod y)
- is the remainder, so (x div y) * y + (x mod y) == x. Bootstring uses
- these operators only with nonnegative operands, so the quotient and
- remainder are always nonnegative.
-
- The break statement jumps out of the innermost loop (as in C).
-
-
-
-
-Costello Standards Track [Page 3]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- An overflow is an attempt to compute a value that exceeds the maximum
- value of an integer variable.
-
-3. Bootstring description
-
- Bootstring represents an arbitrary sequence of code points (the
- "extended string") as a sequence of basic code points (the "basic
- string"). This section describes the representation. Section 6
- "Bootstring algorithms" presents the algorithms as pseudocode.
- Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
- algorithms for sample inputs.
-
- The following sections describe the four techniques used in
- Bootstring. "Basic code point segregation" is a very simple and
- efficient encoding for basic code points occurring in the extended
- string: they are simply copied all at once. "Insertion unsort
- coding" encodes the non-basic code points as deltas, and processes
- the code points in numerical order rather than in order of
- appearance, which typically results in smaller deltas. The deltas
- are represented as "generalized variable-length integers", which use
- basic code points to represent nonnegative integers. The parameters
- of this integer representation are dynamically adjusted using "bias
- adaptation", to improve efficiency when consecutive deltas have
- similar magnitudes.
-
-3.1 Basic code point segregation
-
- All basic code points appearing in the extended string are
- represented literally at the beginning of the basic string, in their
- original order, followed by a delimiter if (and only if) the number
- of basic code points is nonzero. The delimiter is a particular basic
- code point, which never appears in the remainder of the basic string.
- The decoder can therefore find the end of the literal portion (if
- there is one) by scanning for the last delimiter.
-
-3.2 Insertion unsort coding
-
- The remainder of the basic string (after the last delimiter if there
- is one) represents a sequence of nonnegative integral deltas as
- generalized variable-length integers, described in section 3.3. The
- meaning of the deltas is best understood in terms of the decoder.
-
- The decoder builds the extended string incrementally. Initially, the
- extended string is a copy of the literal portion of the basic string
- (excluding the last delimiter). The decoder inserts non-basic code
- points, one for each delta, into the extended string, ultimately
- arriving at the final decoded string.
-
-
-
-
-Costello Standards Track [Page 4]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- At the heart of this process is a state machine with two state
- variables: an index i and a counter n. The index i refers to a
- position in the extended string; it ranges from 0 (the first
- position) to the current length of the extended string (which refers
- to a potential position beyond the current end). If the current
- state is <n,i>, the next state is <n,i+1> if i is less than the
- length of the extended string, or <n+1,0> if i equals the length of
- the extended string. In other words, each state change causes i to
- increment, wrapping around to zero if necessary, and n counts the
- number of wrap-arounds.
-
- Notice that the state always advances monotonically (there is no way
- for the decoder to return to an earlier state). At each state, an
- insertion is either performed or not performed. At most one
- insertion is performed in a given state. An insertion inserts the
- value of n at position i in the extended string. The deltas are a
- run-length encoding of this sequence of events: they are the lengths
- of the runs of non-insertion states preceeding the insertion states.
- Hence, for each delta, the decoder performs delta state changes, then
- an insertion, and then one more state change. (An implementation
- need not perform each state change individually, but can instead use
- division and remainder calculations to compute the next insertion
- state directly.) It is an error if the inserted code point is a
- basic code point (because basic code points were supposed to be
- segregated as described in section 3.1).
-
- The encoder's main task is to derive the sequence of deltas that will
- cause the decoder to construct the desired string. It can do this by
- repeatedly scanning the extended string for the next code point that
- the decoder would need to insert, and counting the number of state
- changes the decoder would need to perform, mindful of the fact that
- the decoder's extended string will include only those code points
- that have already been inserted. Section 6.3 "Encoding procedure"
- gives a precise algorithm.
-
-3.3 Generalized variable-length integers
-
- In a conventional integer representation the base is the number of
- distinct symbols for digits, whose values are 0 through base-1. Let
- digit_0 denote the least significant digit, digit_1 the next least
- significant, and so on. The value represented is the sum over j of
- digit_j * w(j), where w(j) = base^j is the weight (scale factor) for
- position j. For example, in the base 8 integer 437, the digits are
- 7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 +
- 3*8 + 4*64 = 287. This representation has two disadvantages: First,
- there are multiple encodings of each value (because there can be
- extra zeros in the most significant positions), which is inconvenient
-
-
-
-
-Costello Standards Track [Page 5]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- when unique encodings are needed. Second, the integer is not self-
- delimiting, so if multiple integers are concatenated the boundaries
- between them are lost.
-
- The generalized variable-length representation solves these two
- problems. The digit values are still 0 through base-1, but now the
- integer is self-delimiting by means of thresholds t(j), each of which
- is in the range 0 through base-1. Exactly one digit, the most
- significant, satisfies digit_j < t(j). Therefore, if several
- integers are concatenated, it is easy to separate them, starting with
- the first if they are little-endian (least significant digit first),
- or starting with the last if they are big-endian (most significant
- digit first). As before, the value is the sum over j of digit_j *
- w(j), but the weights are different:
-
- w(0) = 1
- w(j) = w(j-1) * (base - t(j-1)) for j > 0
-
- For example, consider the little-endian sequence of base 8 digits
- 734251... Suppose the thresholds are 2, 3, 5, 5, 5, 5... This
- implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) =
- 90, 90*(8-5) = 270, and so on. 7 is not less than 2, and 3 is not
- less than 3, but 4 is less than 5, so 4 is the last digit. The value
- of 734 is 7*1 + 3*6 + 4*30 = 145. The next integer is 251, with
- value 2*1 + 5*6 + 1*30 = 62. Decoding this representation is very
- similar to decoding a conventional integer: Start with a current
- value of N = 0 and a weight w = 1. Fetch the next digit d and
- increase N by d * w. If d is less than the current threshold (t)
- then stop, otherwise increase w by a factor of (base - t), update t
- for the next position, and repeat.
-
- Encoding this representation is similar to encoding a conventional
- integer: If N < t then output one digit for N and stop, otherwise
- output the digit for t + ((N - t) mod (base - t)), then replace N
- with (N - t) div (base - t), update t for the next position, and
- repeat.
-
- For any particular set of values of t(j), there is exactly one
- generalized variable-length representation of each nonnegative
- integral value.
-
- Bootstring uses little-endian ordering so that the deltas can be
- separated starting with the first. The t(j) values are defined in
- terms of the constants base, tmin, and tmax, and a state variable
- called bias:
-
- t(j) = base * (j + 1) - bias,
- clamped to the range tmin through tmax
-
-
-
-Costello Standards Track [Page 6]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- The clamping means that if the formula yields a value less than tmin
- or greater than tmax, then t(j) = tmin or tmax, respectively. (In
- the pseudocode in section 6 "Bootstring algorithms", the expression
- base * (j + 1) is denoted by k for performance reasons.) These t(j)
- values cause the representation to favor integers within a particular
- range determined by the bias.
-
-3.4 Bias adaptation
-
- After each delta is encoded or decoded, bias is set for the next
- delta as follows:
-
- 1. Delta is scaled in order to avoid overflow in the next step:
-
- let delta = delta div 2
-
- But when this is the very first delta, the divisor is not 2, but
- instead a constant called damp. This compensates for the fact
- that the second delta is usually much smaller than the first.
-
- 2. Delta is increased to compensate for the fact that the next delta
- will be inserting into a longer string:
-
- let delta = delta + (delta div numpoints)
-
- numpoints is the total number of code points encoded/decoded so
- far (including the one corresponding to this delta itself, and
- including the basic code points).
-
- 3. Delta is repeatedly divided until it falls within a threshold, to
- predict the minimum number of digits needed to represent the next
- delta:
-
- while delta > ((base - tmin) * tmax) div 2
- do let delta = delta div (base - tmin)
-
- 4. The bias is set:
-
- let bias =
- (base * the number of divisions performed in step 3) +
- (((base - tmin + 1) * delta) div (delta + skew))
-
- The motivation for this procedure is that the current delta
- provides a hint about the likely size of the next delta, and so
- t(j) is set to tmax for the more significant digits starting with
- the one expected to be last, tmin for the less significant digits
- up through the one expected to be third-last, and somewhere
- between tmin and tmax for the digit expected to be second-last
-
-
-
-Costello Standards Track [Page 7]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- (balancing the hope of the expected-last digit being unnecessary
- against the danger of it being insufficient).
-
-4. Bootstring parameters
-
- Given a set of basic code points, one needs to be designated as the
- delimiter. The base cannot be greater than the number of
- distinguishable basic code points remaining. The digit-values in the
- range 0 through base-1 need to be associated with distinct non-
- delimiter basic code points. In some cases multiple code points need
- to have the same digit-value; for example, uppercase and lowercase
- versions of the same letter need to be equivalent if basic strings
- are case-insensitive.
-
- The initial value of n cannot be greater than the minimum non-basic
- code point that could appear in extended strings.
-
- The remaining five parameters (tmin, tmax, skew, damp, and the
- initial value of bias) need to satisfy the following constraints:
-
- 0 <= tmin <= tmax <= base-1
- skew >= 1
- damp >= 2
- initial_bias mod base <= base - tmin
-
- Provided the constraints are satisfied, these five parameters affect
- efficiency but not correctness. They are best chosen empirically.
-
- If support for mixed-case annotation is desired (see appendix A),
- make sure that the code points corresponding to 0 through tmax-1 all
- have both uppercase and lowercase forms.
-
-5. Parameter values for Punycode
-
- Punycode uses the following Bootstring parameter values:
-
- base = 36
- tmin = 1
- tmax = 26
- skew = 38
- damp = 700
- initial_bias = 72
- initial_n = 128 = 0x80
-
- Although the only restriction Punycode imposes on the input integers
- is that they be nonnegative, these parameters are especially designed
- to work well with Unicode [UNICODE] code points, which are integers
- in the range 0..10FFFF (but not D800..DFFF, which are reserved for
-
-
-
-Costello Standards Track [Page 8]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- use by the UTF-16 encoding of Unicode). The basic code points are
- the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the
- delimiter, and some of the others have digit-values as follows:
-
- code points digit-values
- ------------ ----------------------
- 41..5A (A-Z) = 0 to 25, respectively
- 61..7A (a-z) = 0 to 25, respectively
- 30..39 (0-9) = 26 to 35, respectively
-
- Using hyphen-minus as the delimiter implies that the encoded string
- can end with a hyphen-minus only if the Unicode string consists
- entirely of basic code points, but IDNA forbids such strings from
- being encoded. The encoded string can begin with a hyphen-minus, but
- IDNA prepends a prefix. Therefore IDNA using Punycode conforms to
- the RFC 952 rule that host name labels neither begin nor end with a
- hyphen-minus [RFC952].
-
- A decoder MUST recognize the letters in both uppercase and lowercase
- forms (including mixtures of both forms). An encoder SHOULD output
- only uppercase forms or only lowercase forms, unless it uses mixed-
- case annotation (see appendix A).
-
- Presumably most users will not manually write or type encoded strings
- (as opposed to cutting and pasting them), but those who do will need
- to be alert to the potential visual ambiguity between the following
- sets of characters:
-
- G 6
- I l 1
- O 0
- S 5
- U V
- Z 2
-
- Such ambiguities are usually resolved by context, but in a Punycode
- encoded string there is no context apparent to humans.
-
-6. Bootstring algorithms
-
- Some parts of the pseudocode can be omitted if the parameters satisfy
- certain conditions (for which Punycode qualifies). These parts are
- enclosed in {braces}, and notes immediately following the pseudocode
- explain the conditions under which they can be omitted.
-
-
-
-
-
-
-
-Costello Standards Track [Page 9]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- Formally, code points are integers, and hence the pseudocode assumes
- that arithmetic operations can be performed directly on code points.
- In some programming languages, explicit conversion between code
- points and integers might be necessary.
-
-6.1 Bias adaptation function
-
- function adapt(delta,numpoints,firsttime):
- if firsttime then let delta = delta div damp
- else let delta = delta div 2
- let delta = delta + (delta div numpoints)
- let k = 0
- while delta > ((base - tmin) * tmax) div 2 do begin
- let delta = delta div (base - tmin)
- let k = k + base
- end
- return k + (((base - tmin + 1) * delta) div (delta + skew))
-
- It does not matter whether the modifications to delta and k inside
- adapt() affect variables of the same name inside the
- encoding/decoding procedures, because after calling adapt() the
- caller does not read those variables before overwriting them.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 10]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-6.2 Decoding procedure
-
- let n = initial_n
- let i = 0
- let bias = initial_bias
- let output = an empty string indexed from 0
- consume all code points before the last delimiter (if there is one)
- and copy them to output, fail on any non-basic code point
- if more than zero code points were consumed then consume one more
- (which will be the last delimiter)
- while the input is not exhausted do begin
- let oldi = i
- let w = 1
- for k = base to infinity in steps of base do begin
- consume a code point, or fail if there was none to consume
- let digit = the code point's digit-value, fail if it has none
- let i = i + digit * w, fail on overflow
- let t = tmin if k <= bias {+ tmin}, or
- tmax if k >= bias + tmax, or k - bias otherwise
- if digit < t then break
- let w = w * (base - t), fail on overflow
- end
- let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
- let n = n + i div (length(output) + 1), fail on overflow
- let i = i mod (length(output) + 1)
- {if n is a basic code point then fail}
- insert n into output at position i
- increment i
- end
-
- The full statement enclosed in braces (checking whether n is a basic
- code point) can be omitted if initial_n exceeds all basic code points
- (which is true for Punycode), because n is never less than initial_n.
-
- In the assignment of t, where t is clamped to the range tmin through
- tmax, "+ tmin" can always be omitted. This makes the clamping
- calculation incorrect when bias < k < bias + tmin, but that cannot
- happen because of the way bias is computed and because of the
- constraints on the parameters.
-
- Because the decoder state can only advance monotonically, and there
- is only one representation of any delta, there is therefore only one
- encoded string that can represent a given sequence of integers. The
- only error conditions are invalid code points, unexpected end-of-
- input, overflow, and basic code points encoded using deltas instead
- of appearing literally. If the decoder fails on these errors as
- shown above, then it cannot produce the same output for two distinct
- inputs. Without this property it would have been necessary to re-
-
-
-
-Costello Standards Track [Page 11]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- encode the output and verify that it matches the input in order to
- guarantee the uniqueness of the encoding.
-
-6.3 Encoding procedure
-
- let n = initial_n
- let delta = 0
- let bias = initial_bias
- let h = b = the number of basic code points in the input
- copy them to the output in order, followed by a delimiter if b > 0
- {if the input contains a non-basic code point < n then fail}
- while h < length(input) do begin
- let m = the minimum {non-basic} code point >= n in the input
- let delta = delta + (m - n) * (h + 1), fail on overflow
- let n = m
- for each code point c in the input (in order) do begin
- if c < n {or c is basic} then increment delta, fail on overflow
- if c == n then begin
- let q = delta
- for k = base to infinity in steps of base do begin
- let t = tmin if k <= bias {+ tmin}, or
- tmax if k >= bias + tmax, or k - bias otherwise
- if q < t then break
- output the code point for digit t + ((q - t) mod (base - t))
- let q = (q - t) div (base - t)
- end
- output the code point for digit q
- let bias = adapt(delta, h + 1, test h equals b?)
- let delta = 0
- increment h
- end
- end
- increment delta and n
- end
-
- The full statement enclosed in braces (checking whether the input
- contains a non-basic code point less than n) can be omitted if all
- code points less than initial_n are basic code points (which is true
- for Punycode if code points are unsigned).
-
- The brace-enclosed conditions "non-basic" and "or c is basic" can be
- omitted if initial_n exceeds all basic code points (which is true for
- Punycode), because the code point being tested is never less than
- initial_n.
-
- In the assignment of t, where t is clamped to the range tmin through
- tmax, "+ tmin" can always be omitted. This makes the clamping
- calculation incorrect when bias < k < bias + tmin, but that cannot
-
-
-
-Costello Standards Track [Page 12]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- happen because of the way bias is computed and because of the
- constraints on the parameters.
-
- The checks for overflow are necessary to avoid producing invalid
- output when the input contains very large values or is very long.
-
- The increment of delta at the bottom of the outer loop cannot
- overflow because delta < length(input) before the increment, and
- length(input) is already assumed to be representable. The increment
- of n could overflow, but only if h == length(input), in which case
- the procedure is finished anyway.
-
-6.4 Overflow handling
-
- For IDNA, 26-bit unsigned integers are sufficient to handle all valid
- IDNA labels without overflow, because any string that needed a 27-bit
- delta would have to exceed either the code point limit (0..10FFFF) or
- the label length limit (63 characters). However, overflow handling
- is necessary because the inputs are not necessarily valid IDNA
- labels.
-
- If the programming language does not provide overflow detection, the
- following technique can be used. Suppose A, B, and C are
- representable nonnegative integers and C is nonzero. Then A + B
- overflows if and only if B > maxint - A, and A + (B * C) overflows if
- and only if B > (maxint - A) div C, where maxint is the greatest
- integer for which maxint + 1 cannot be represented. Refer to
- appendix C "Punycode sample implementation" for demonstrations of
- this technique in the C language.
-
- The decoding and encoding algorithms shown in sections 6.2 and 6.3
- handle overflow by detecting it whenever it happens. Another
- approach is to enforce limits on the inputs that prevent overflow
- from happening. For example, if the encoder were to verify that no
- input code points exceed M and that the input length does not exceed
- L, then no delta could ever exceed (M - initial_n) * (L + 1), and
- hence no overflow could occur if integer variables were capable of
- representing values that large. This prevention approach would
- impose more restrictions on the input than the detection approach
- does, but might be considered simpler in some programming languages.
-
- In theory, the decoder could use an analogous approach, limiting the
- number of digits in a variable-length integer (that is, limiting the
- number of iterations in the innermost loop). However, the number of
- digits that suffice to represent a given delta can sometimes
- represent much larger deltas (because of the adaptation), and hence
- this approach would probably need integers wider than 32 bits.
-
-
-
-
-Costello Standards Track [Page 13]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- Yet another approach for the decoder is to allow overflow to occur,
- but to check the final output string by re-encoding it and comparing
- to the decoder input. If and only if they do not match (using a
- case-insensitive ASCII comparison) overflow has occurred. This
- delayed-detection approach would not impose any more restrictions on
- the input than the immediate-detection approach does, and might be
- considered simpler in some programming languages.
-
- In fact, if the decoder is used only inside the IDNA ToUnicode
- operation [IDNA], then it need not check for overflow at all, because
- ToUnicode performs a higher level re-encoding and comparison, and a
- mismatch has the same consequence as if the Punycode decoder had
- failed.
-
-7. Punycode examples
-
-7.1 Sample strings
-
- In the Punycode encodings below, the ACE prefix is not shown.
- Backslashes show where line breaks have been inserted in strings too
- long for one line.
-
- The first several examples are all translations of the sentence "Why
- can't they just speak in <language>?" (courtesy of Michael Kaplan's
- "provincial" page [PROVINCIAL]). Word breaks and punctuation have
- been removed, as is often done in domain names.
-
- (A) Arabic (Egyptian):
- u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
- u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
- Punycode: egbpdaj6bu4bxfgehfvwxn
-
- (B) Chinese (simplified):
- u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
- Punycode: ihqwcrb4cv8a8dqg056pqjye
-
- (C) Chinese (traditional):
- u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
- Punycode: ihqwctvzc91f659drss3x8bo0yb
-
- (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
- U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
- u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
- u+0065 u+0073 u+006B u+0079
- Punycode: Proprostnemluvesky-uyb24dma41a
-
-
-
-
-
-
-Costello Standards Track [Page 14]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- (E) Hebrew:
- u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
- u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
- u+05D1 u+05E8 u+05D9 u+05EA
- Punycode: 4dbcagdahymbxekheh6e0a7fei0b
-
- (F) Hindi (Devanagari):
- u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
- u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
- u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
- u+0939 u+0948 u+0902
- Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
-
- (G) Japanese (kanji and hiragana):
- u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
- u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
- Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
-
- (H) Korean (Hangul syllables):
- u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
- u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
- u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
- Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
- psd879ccm6fea98c
-
- (I) Russian (Cyrillic):
- U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
- u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
- u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
- u+0438
- Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
-
- (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
- U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
- u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
- u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
- u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
- u+0061 u+00F1 u+006F u+006C
- Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
-
- (K) Vietnamese:
- T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
- <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
- U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
- u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
- u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
- U+0056 u+0069 u+1EC7 u+0074
- Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
-
-
-
-Costello Standards Track [Page 15]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- The next several examples are all names of Japanese music artists,
- song titles, and TV programs, just because the author happens to have
- them handy (but Japanese is useful for providing examples of single-
- row text, two-row text, ideographic text, and various mixtures
- thereof).
-
- (L) 3<nen>B<gumi><kinpachi><sensei>
- u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
- Punycode: 3B-ww4c5e180e575a65lsy2b
-
- (M) <amuro><namie>-with-SUPER-MONKEYS
- u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
- u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
- U+004F U+004E U+004B U+0045 U+0059 U+0053
- Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
-
- (N) Hello-Another-Way-<sorezore><no><basho>
- U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
- u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
- u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
- Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
-
- (O) <hitotsu><yane><no><shita>2
- u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
- Punycode: 2-u9tlzr9756bt3uc0v
-
- (P) Maji<de>Koi<suru>5<byou><mae>
- U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
- u+308B u+0035 u+79D2 u+524D
- Punycode: MajiKoi5-783gue6qz075azm5e
-
- (Q) <pafii>de<runba>
- u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
- Punycode: de-jg4avhby1noc0d
-
- (R) <sono><supiido><de>
- u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
- Punycode: d9juau41awczczp
-
- The last example is an ASCII string that breaks the existing rules
- for host name labels. (It is not a realistic example for IDNA,
- because IDNA never encodes pure ASCII labels.)
-
- (S) -> $1.00 <-
- u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
- u+003C u+002D
- Punycode: -> $1.00 <--
-
-
-
-
-Costello Standards Track [Page 16]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-7.2 Decoding traces
-
- In the following traces, the evolving state of the decoder is shown
- as a sequence of hexadecimal values, representing the code points in
- the extended string. An asterisk appears just after the most
- recently inserted code point, indicating both n (the value preceeding
- the asterisk) and i (the position of the value just after the
- asterisk). Other numerical values are decimal.
-
- Decoding trace of example B from section 7.1:
-
- n is 128, i is 0, bias is 72
- input is "ihqwcrb4cv8a8dqg056pqjye"
- there is no delimiter, so extended string starts empty
- delta "ihq" decodes to 19853
- bias becomes 21
- 4E0D *
- delta "wc" decodes to 64
- bias becomes 20
- 4E0D 4E2D *
- delta "rb" decodes to 37
- bias becomes 13
- 4E3A * 4E0D 4E2D
- delta "4c" decodes to 56
- bias becomes 17
- 4E3A 4E48 * 4E0D 4E2D
- delta "v8a" decodes to 599
- bias becomes 32
- 4E3A 4EC0 * 4E48 4E0D 4E2D
- delta "8d" decodes to 130
- bias becomes 23
- 4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
- delta "qg" decodes to 154
- bias becomes 25
- 4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
- delta "056p" decodes to 46301
- bias becomes 84
- 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
- delta "qjye" decodes to 88531
- bias becomes 90
- 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 17]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- Decoding trace of example L from section 7.1:
-
- n is 128, i is 0, bias is 72
- input is "3B-ww4c5e180e575a65lsy2b"
- literal portion is "3B-", so extended string starts as:
- 0033 0042
- delta "ww4c" decodes to 62042
- bias becomes 27
- 0033 0042 5148 *
- delta "5e" decodes to 139
- bias becomes 24
- 0033 0042 516B * 5148
- delta "180e" decodes to 16683
- bias becomes 67
- 0033 5E74 * 0042 516B 5148
- delta "575a" decodes to 34821
- bias becomes 82
- 0033 5E74 0042 516B 5148 751F *
- delta "65l" decodes to 14592
- bias becomes 67
- 0033 5E74 0042 7D44 * 516B 5148 751F
- delta "sy2b" decodes to 42088
- bias becomes 84
- 0033 5E74 0042 7D44 91D1 * 516B 5148 751F
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 18]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-7.3 Encoding traces
-
- In the following traces, code point values are hexadecimal, while
- other numerical values are decimal.
-
- Encoding trace of example B from section 7.1:
-
- bias is 72
- input is:
- 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
- there are no basic code points, so no literal portion
- next code point to insert is 4E0D
- needed delta is 19853, encodes as "ihq"
- bias becomes 21
- next code point to insert is 4E2D
- needed delta is 64, encodes as "wc"
- bias becomes 20
- next code point to insert is 4E3A
- needed delta is 37, encodes as "rb"
- bias becomes 13
- next code point to insert is 4E48
- needed delta is 56, encodes as "4c"
- bias becomes 17
- next code point to insert is 4EC0
- needed delta is 599, encodes as "v8a"
- bias becomes 32
- next code point to insert is 4ED6
- needed delta is 130, encodes as "8d"
- bias becomes 23
- next code point to insert is 4EEC
- needed delta is 154, encodes as "qg"
- bias becomes 25
- next code point to insert is 6587
- needed delta is 46301, encodes as "056p"
- bias becomes 84
- next code point to insert is 8BF4
- needed delta is 88531, encodes as "qjye"
- bias becomes 90
- output is "ihqwcrb4cv8a8dqg056pqjye"
-
-
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 19]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- Encoding trace of example L from section 7.1:
-
- bias is 72
- input is:
- 0033 5E74 0042 7D44 91D1 516B 5148 751F
- basic code points (0033, 0042) are copied to literal portion: "3B-"
- next code point to insert is 5148
- needed delta is 62042, encodes as "ww4c"
- bias becomes 27
- next code point to insert is 516B
- needed delta is 139, encodes as "5e"
- bias becomes 24
- next code point to insert is 5E74
- needed delta is 16683, encodes as "180e"
- bias becomes 67
- next code point to insert is 751F
- needed delta is 34821, encodes as "575a"
- bias becomes 82
- next code point to insert is 7D44
- needed delta is 14592, encodes as "65l"
- bias becomes 67
- next code point to insert is 91D1
- needed delta is 42088, encodes as "sy2b"
- bias becomes 84
- output is "3B-ww4c5e180e575a65lsy2b"
-
-8. Security Considerations
-
- Users expect each domain name in DNS to be controlled by a single
- authority. If a Unicode string intended for use as a domain label
- could map to multiple ACE labels, then an internationalized domain
- name could map to multiple ASCII domain names, each controlled by a
- different authority, some of which could be spoofs that hijack
- service requests intended for another. Therefore Punycode is
- designed so that each Unicode string has a unique encoding.
-
- However, there can still be multiple Unicode representations of the
- "same" text, for various definitions of "same". This problem is
- addressed to some extent by the Unicode standard under the topic of
- canonicalization, and this work is leveraged for domain names by
- Nameprep [NAMEPREP].
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 20]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-9. References
-
-9.1 Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-9.2 Informative References
-
- [RFC952] Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
- Host Table Specification", RFC 952, October 1985.
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
- "Internationalizing Domain Names in Applications
- (IDNA)", RFC 3490, March 2003.
-
- [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
- Profile for Internationalized Domain Names (IDN)", RFC
- 3491, March 2003.
-
- [ASCII] Cerf, V., "ASCII format for Network Interchange", RFC
- 20, October 1969.
-
- [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page",
- http://www.trigeminal.com/samples/provincial.html.
-
- [UNICODE] The Unicode Consortium, "The Unicode Standard",
- http://www.unicode.org/unicode/standard/standard.html.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 21]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-A. Mixed-case annotation
-
- In order to use Punycode to represent case-insensitive strings,
- higher layers need to case-fold the strings prior to Punycode
- encoding. The encoded string can use mixed case as an annotation
- telling how to convert the folded string into a mixed-case string for
- display purposes. Note, however, that mixed-case annotation is not
- used by the ToASCII and ToUnicode operations specified in [IDNA], and
- therefore implementors of IDNA can disregard this appendix.
-
- Basic code points can use mixed case directly, because the decoder
- copies them verbatim, leaving lowercase code points lowercase, and
- leaving uppercase code points uppercase. Each non-basic code point
- is represented by a delta, which is represented by a sequence of
- basic code points, the last of which provides the annotation. If it
- is uppercase, it is a suggestion to map the non-basic code point to
- uppercase (if possible); if it is lowercase, it is a suggestion to
- map the non-basic code point to lowercase (if possible).
-
- These annotations do not alter the code points returned by decoders;
- the annotations are returned separately, for the caller to use or
- ignore. Encoders can accept annotations in addition to code points,
- but the annotations do not alter the output, except to influence the
- uppercase/lowercase form of ASCII letters.
-
- Punycode encoders and decoders need not support these annotations,
- and higher layers need not use them.
-
-B. Disclaimer and license
-
- Regarding this entire document or any portion of it (including the
- pseudocode and C code), 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 22]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-C. Punycode sample implementation
-
-/*
-punycode.c from RFC 3492
-http://www.nicemice.net/idn/
-Adam M. Costello
-http://www.nicemice.net/amc/
-
-This is ANSI C code (C89) implementing Punycode (RFC 3492).
-
-*/
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum punycode_status {
- punycode_success,
- punycode_bad_input, /* Input is invalid. */
- punycode_big_output, /* Output would exceed the space provided. */
- punycode_overflow /* Input needs wider integers to process. */
-};
-
-#if UINT_MAX >= (1 << 26) - 1
-typedef unsigned int punycode_uint;
-#else
-typedef unsigned long punycode_uint;
-#endif
-
-enum punycode_status punycode_encode(
- punycode_uint input_length,
- const punycode_uint input[],
- const unsigned char case_flags[],
- punycode_uint *output_length,
- char output[] );
-
- /* punycode_encode() converts Unicode to Punycode. The input */
- /* is represented as an array of Unicode code points (not code */
- /* units; surrogate pairs are not allowed), and the output */
- /* will be represented as an array of ASCII code points. The */
- /* output string is *not* null-terminated; it will contain */
- /* zeros if and only if the input contains zeros. (Of course */
- /* the caller can leave room for a terminator and add one if */
- /* needed.) The input_length is the number of code points in */
- /* the input. The output_length is an in/out argument: the */
- /* caller passes in the maximum number of code points that it */
-
-
-
-Costello Standards Track [Page 23]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- /* can receive, and on successful return it will contain the */
- /* number of code points actually output. The case_flags array */
- /* holds input_length boolean values, where nonzero suggests that */
- /* the corresponding Unicode character be forced to uppercase */
- /* after being decoded (if possible), and zero suggests that */
- /* it be forced to lowercase (if possible). ASCII code points */
- /* are encoded literally, except that ASCII letters are forced */
- /* to uppercase or lowercase according to the corresponding */
- /* uppercase flags. If case_flags is a null pointer then ASCII */
- /* letters are left as they are, and other code points are */
- /* treated as if their uppercase flags were zero. The return */
- /* value can be any of the punycode_status values defined above */
- /* except punycode_bad_input; if not punycode_success, then */
- /* output_size and output might contain garbage. */
-
-enum punycode_status punycode_decode(
- punycode_uint input_length,
- const char input[],
- punycode_uint *output_length,
- punycode_uint output[],
- unsigned char case_flags[] );
-
- /* punycode_decode() converts Punycode to Unicode. The input is */
- /* represented as an array of ASCII code points, and the output */
- /* will be represented as an array of Unicode code points. The */
- /* input_length is the number of code points in the input. The */
- /* output_length is an in/out argument: the caller passes in */
- /* the maximum number of code points that it can receive, and */
- /* on successful return it will contain the actual number of */
- /* code points output. The case_flags array needs room for at */
- /* least output_length values, or it can be a null pointer if the */
- /* case information is not needed. A nonzero flag suggests that */
- /* the corresponding Unicode character be forced to uppercase */
- /* by the caller (if possible), while zero suggests that it be */
- /* forced to lowercase (if possible). ASCII code points are */
- /* output already in the proper case, but their flags will be set */
- /* appropriately so that applying the flags would be harmless. */
- /* The return value can be any of the punycode_status values */
- /* defined above; if not punycode_success, then output_length, */
- /* output, and case_flags might contain garbage. On success, the */
- /* decoder will never need to write an output_length greater than */
- /* input_length, because of how the encoding is defined. */
-
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-
-
-
-Costello Standards Track [Page 24]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-/*** Bootstring parameters for Punycode ***/
-
-enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
- initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
-
-/* basic(cp) tests whether cp is a basic code point: */
-#define basic(cp) ((punycode_uint)(cp) < 0x80)
-
-/* delim(cp) tests whether cp is a delimiter: */
-#define delim(cp) ((cp) == delimiter)
-
-/* decode_digit(cp) returns the numeric value of a basic code */
-/* point (for use in representing integers) in the range 0 to */
-/* base-1, or base if cp is does not represent a value. */
-
-static punycode_uint decode_digit(punycode_uint cp)
-{
- return cp - 48 < 10 ? cp - 22 : cp - 65 < 26 ? cp - 65 :
- cp - 97 < 26 ? cp - 97 : base;
-}
-
-/* encode_digit(d,flag) returns the basic code point whose value */
-/* (when used for representing integers) is d, which needs to be in */
-/* the range 0 to base-1. The lowercase form is used unless flag is */
-/* nonzero, in which case the uppercase form is used. The behavior */
-/* is undefined if flag is nonzero and digit d has no uppercase form. */
-
-static char encode_digit(punycode_uint d, int flag)
-{
- return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
- /* 0..25 map to ASCII a..z or A..Z */
- /* 26..35 map to ASCII 0..9 */
-}
-
-/* flagged(bcp) tests whether a basic code point is flagged */
-/* (uppercase). The behavior is undefined if bcp is not a */
-/* basic code point. */
-
-#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
-
-/* encode_basic(bcp,flag) forces a basic code point to lowercase */
-/* if flag is zero, uppercase if flag is nonzero, and returns */
-/* the resulting code point. The code point is unchanged if it */
-/* is caseless. The behavior is undefined if bcp is not a basic */
-/* code point. */
-
-static char encode_basic(punycode_uint bcp, int flag)
-{
-
-
-
-Costello Standards Track [Page 25]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- bcp -= (bcp - 97 < 26) << 5;
- return bcp + ((!flag && (bcp - 65 < 26)) << 5);
-}
-
-/*** Platform-specific constants ***/
-
-/* maxint is the maximum value of a punycode_uint variable: */
-static const punycode_uint maxint = -1;
-/* Because maxint is unsigned, -1 becomes the maximum value. */
-
-/*** Bias adaptation function ***/
-
-static punycode_uint adapt(
- punycode_uint delta, punycode_uint numpoints, int firsttime )
-{
- punycode_uint k;
-
- delta = firsttime ? delta / damp : delta >> 1;
- /* delta >> 1 is a faster way of doing delta / 2 */
- delta += delta / numpoints;
-
- for (k = 0; delta > ((base - tmin) * tmax) / 2; k += base) {
- delta /= base - tmin;
- }
-
- return k + (base - tmin + 1) * delta / (delta + skew);
-}
-
-/*** Main encode function ***/
-
-enum punycode_status punycode_encode(
- punycode_uint input_length,
- const punycode_uint input[],
- const unsigned char case_flags[],
- punycode_uint *output_length,
- char output[] )
-{
- punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
-
- /* Initialize the state: */
-
- n = initial_n;
- delta = out = 0;
- max_out = *output_length;
- bias = initial_bias;
-
- /* Handle the basic code points: */
-
-
-
-
-Costello Standards Track [Page 26]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- for (j = 0; j < input_length; ++j) {
- if (basic(input[j])) {
- if (max_out - out < 2) return punycode_big_output;
- output[out++] =
- case_flags ? encode_basic(input[j], case_flags[j]) : input[j];
- }
- /* else if (input[j] < n) return punycode_bad_input; */
- /* (not needed for Punycode with unsigned code points) */
- }
-
- h = b = out;
-
- /* h is the number of code points that have been handled, b is the */
- /* number of basic code points, and out is the number of characters */
- /* that have been output. */
-
- if (b > 0) output[out++] = delimiter;
-
- /* Main encoding loop: */
-
- while (h < input_length) {
- /* All non-basic code points < n have been */
- /* handled already. Find the next larger one: */
-
- for (m = maxint, j = 0; j < input_length; ++j) {
- /* if (basic(input[j])) continue; */
- /* (not needed for Punycode) */
- if (input[j] >= n && input[j] < m) m = input[j];
- }
-
- /* Increase delta enough to advance the decoder's */
- /* <n,i> state to <m,0>, but guard against overflow: */
-
- if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
- delta += (m - n) * (h + 1);
- n = m;
-
- for (j = 0; j < input_length; ++j) {
- /* Punycode does not need to check whether input[j] is basic: */
- if (input[j] < n /* || basic(input[j]) */ ) {
- if (++delta == 0) return punycode_overflow;
- }
-
- if (input[j] == n) {
- /* Represent delta as a generalized variable-length integer: */
-
- for (q = delta, k = base; ; k += base) {
- if (out >= max_out) return punycode_big_output;
-
-
-
-Costello Standards Track [Page 27]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */
- k >= bias + tmax ? tmax : k - bias;
- if (q < t) break;
- output[out++] = encode_digit(t + (q - t) % (base - t), 0);
- q = (q - t) / (base - t);
- }
-
- output[out++] = encode_digit(q, case_flags && case_flags[j]);
- bias = adapt(delta, h + 1, h == b);
- delta = 0;
- ++h;
- }
- }
-
- ++delta, ++n;
- }
-
- *output_length = out;
- return punycode_success;
-}
-
-/*** Main decode function ***/
-
-enum punycode_status punycode_decode(
- punycode_uint input_length,
- const char input[],
- punycode_uint *output_length,
- punycode_uint output[],
- unsigned char case_flags[] )
-{
- punycode_uint n, out, i, max_out, bias,
- b, j, in, oldi, w, k, digit, t;
-
- /* Initialize the state: */
-
- n = initial_n;
- out = i = 0;
- max_out = *output_length;
- bias = initial_bias;
-
- /* Handle the basic code points: Let b be the number of input code */
- /* points before the last delimiter, or 0 if there is none, then */
- /* copy the first b code points to the output. */
-
- for (b = j = 0; j < input_length; ++j) if (delim(input[j])) b = j;
- if (b > max_out) return punycode_big_output;
-
- for (j = 0; j < b; ++j) {
-
-
-
-Costello Standards Track [Page 28]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- if (case_flags) case_flags[out] = flagged(input[j]);
- if (!basic(input[j])) return punycode_bad_input;
- output[out++] = input[j];
- }
-
- /* Main decoding loop: Start just after the last delimiter if any */
- /* basic code points were copied; start at the beginning otherwise. */
-
- for (in = b > 0 ? b + 1 : 0; in < input_length; ++out) {
-
- /* in is the index of the next character to be consumed, and */
- /* out is the number of code points in the output array. */
-
- /* Decode a generalized variable-length integer into delta, */
- /* which gets added to i. The overflow checking is easier */
- /* if we increase i as we go, then subtract off its starting */
- /* value at the end to obtain delta. */
-
- for (oldi = i, w = 1, k = base; ; k += base) {
- if (in >= input_length) return punycode_bad_input;
- digit = decode_digit(input[in++]);
- if (digit >= base) return punycode_bad_input;
- if (digit > (maxint - i) / w) return punycode_overflow;
- i += digit * w;
- t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */
- k >= bias + tmax ? tmax : k - bias;
- if (digit < t) break;
- if (w > maxint / (base - t)) return punycode_overflow;
- w *= (base - t);
- }
-
- bias = adapt(i - oldi, out + 1, oldi == 0);
-
- /* i was supposed to wrap around from out+1 to 0, */
- /* incrementing n each time, so we'll fix that now: */
-
- if (i / (out + 1) > maxint - n) return punycode_overflow;
- n += i / (out + 1);
- i %= (out + 1);
-
- /* Insert n at position i of the output: */
-
- /* not needed for Punycode: */
- /* if (decode_digit(n) <= base) return punycode_invalid_input; */
- if (out >= max_out) return punycode_big_output;
-
- if (case_flags) {
- memmove(case_flags + i + 1, case_flags + i, out - i);
-
-
-
-Costello Standards Track [Page 29]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- /* Case of last character determines uppercase flag: */
- case_flags[i] = flagged(input[in - 1]);
- }
-
- memmove(output + i + 1, output + i, (out - i) * sizeof *output);
- output[i++] = n;
- }
-
- *output_length = out;
- return punycode_success;
-}
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a */
-/* command-line option. */
-
-enum {
- unicode_max_length = 256,
- ace_max_length = 256
-};
-
-static void usage(char **argv)
-{
- fprintf(stderr,
- "\n"
- "%s -e reads code points and writes a Punycode string.\n"
- "%s -d reads a Punycode string and writes code points.\n"
- "\n"
- "Input and output are plain text in the native character set.\n"
- "Code points are in the form u+hex separated by whitespace.\n"
- "Although the specification allows Punycode strings to contain\n"
- "any characters from the ASCII repertoire, this test code\n"
- "supports only the printable characters, and needs the Punycode\n"
- "string to be followed by a newline.\n"
- "The case of the u in u+hex is the force-to-uppercase flag.\n"
- , argv[0], argv[0]);
- exit(EXIT_FAILURE);
-}
-
-static void fail(const char *msg)
-
-
-
-Costello Standards Track [Page 30]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-{
- fputs(msg,stderr);
- exit(EXIT_FAILURE);
-}
-
-static const char too_big[] =
- "input or output is too large, recompile with larger limits\n";
-static const char invalid_input[] = "invalid input\n";
-static const char overflow[] = "arithmetic overflow\n";
-static const char io_error[] = "I/O error\n";
-
-/* The following string is used to convert printable */
-/* characters between ASCII and the native charset: */
-
-static const char print_ascii[] =
- "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
- "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
- " !\"#$%&'()*+,-./"
- "0123456789:;<=>?"
- "@ABCDEFGHIJKLMNO"
- "PQRSTUVWXYZ[\\]^_"
- "`abcdefghijklmno"
- "pqrstuvwxyz{|}~\n";
-
-int main(int argc, char **argv)
-{
- enum punycode_status status;
- int r;
- unsigned int input_length, output_length, j;
- unsigned char case_flags[unicode_max_length];
-
- if (argc != 2) usage(argv);
- if (argv[1][0] != '-') usage(argv);
- if (argv[1][2] != 0) usage(argv);
-
- if (argv[1][1] == 'e') {
- punycode_uint input[unicode_max_length];
- unsigned long codept;
- char output[ace_max_length+1], uplus[3];
- int c;
-
- /* Read the input code points: */
-
- input_length = 0;
-
- for (;;) {
- r = scanf("%2s%lx", uplus, &codept);
- if (ferror(stdin)) fail(io_error);
-
-
-
-Costello Standards Track [Page 31]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- if (r == EOF || r == 0) break;
-
- if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
- fail(invalid_input);
- }
-
- if (input_length == unicode_max_length) fail(too_big);
-
- if (uplus[0] == 'u') case_flags[input_length] = 0;
- else if (uplus[0] == 'U') case_flags[input_length] = 1;
- else fail(invalid_input);
-
- input[input_length++] = codept;
- }
-
- /* Encode: */
-
- output_length = ace_max_length;
- status = punycode_encode(input_length, input, case_flags,
- &output_length, output);
- if (status == punycode_bad_input) fail(invalid_input);
- if (status == punycode_big_output) fail(too_big);
- if (status == punycode_overflow) fail(overflow);
- assert(status == punycode_success);
-
- /* Convert to native charset and output: */
-
- for (j = 0; j < output_length; ++j) {
- c = output[j];
- assert(c >= 0 && c <= 127);
- if (print_ascii[c] == 0) fail(invalid_input);
- output[j] = print_ascii[c];
- }
-
- output[j] = 0;
- r = puts(output);
- if (r == EOF) fail(io_error);
- return EXIT_SUCCESS;
- }
-
- if (argv[1][1] == 'd') {
- char input[ace_max_length+2], *p, *pp;
- punycode_uint output[unicode_max_length];
-
- /* Read the Punycode input string and convert to ASCII: */
-
- fgets(input, ace_max_length+2, stdin);
- if (ferror(stdin)) fail(io_error);
-
-
-
-Costello Standards Track [Page 32]
-
-RFC 3492 IDNA Punycode March 2003
-
-
- if (feof(stdin)) fail(invalid_input);
- input_length = strlen(input) - 1;
- if (input[input_length] != '\n') fail(too_big);
- input[input_length] = 0;
-
- for (p = input; *p != 0; ++p) {
- pp = strchr(print_ascii, *p);
- if (pp == 0) fail(invalid_input);
- *p = pp - print_ascii;
- }
-
- /* Decode: */
-
- output_length = unicode_max_length;
- status = punycode_decode(input_length, input, &output_length,
- output, case_flags);
- if (status == punycode_bad_input) fail(invalid_input);
- if (status == punycode_big_output) fail(too_big);
- if (status == punycode_overflow) fail(overflow);
- assert(status == punycode_success);
-
- /* Output the result: */
-
- for (j = 0; j < output_length; ++j) {
- r = printf("%s+%04lX\n",
- case_flags[j] ? "U" : "u",
- (unsigned long) output[j] );
- if (r < 0) fail(io_error);
- }
-
- return EXIT_SUCCESS;
- }
-
- usage(argv);
- return EXIT_SUCCESS; /* not reached, but quiets compiler warning */
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 33]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-Author's Address
-
- Adam M. Costello
- University of California, Berkeley
- http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 34]
-
-RFC 3492 IDNA Punycode March 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello Standards Track [Page 35]
-
diff --git a/contrib/bind9/doc/rfc/rfc3493.txt b/contrib/bind9/doc/rfc/rfc3493.txt
deleted file mode 100644
index 5fea6c19ecb80..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3493.txt
+++ /dev/null
@@ -1,2187 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Gilligan
-Request for Comments: 3493 Intransa, Inc.
-Obsoletes: 2553 S. Thomson
-Category: Informational Cisco
- J. Bound
- J. McCann
- Hewlett-Packard
- W. Stevens
- February 2003
-
-
- Basic Socket Interface Extensions for IPv6
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- The de facto standard Application Program Interface (API) for TCP/IP
- applications is the "sockets" interface. Although this API was
- developed for Unix in the early 1980s it has also been implemented on
- a wide variety of non-Unix systems. TCP/IP applications written
- using the sockets API have in the past enjoyed a high degree of
- portability and we would like the same portability with IPv6
- applications. But changes are required to the sockets API to support
- IPv6 and this memo describes these changes. These include a new
- socket address structure to carry IPv6 addresses, new address
- conversion functions, and some new socket options. These extensions
- are designed to provide access to the basic IPv6 features required by
- TCP and UDP applications, including multicasting, while introducing a
- minimum of change into the system and providing complete
- compatibility for existing IPv4 applications. Additional extensions
- for advanced IPv6 features (raw sockets and access to the IPv6
- extension headers) are defined in another document.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 1]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-Table of Contents
-
- 1. Introduction................................................3
- 2. Design Considerations.......................................4
- 2.1 What Needs to be Changed...............................4
- 2.2 Data Types.............................................6
- 2.3 Headers................................................6
- 2.4 Structures.............................................6
- 3. Socket Interface............................................6
- 3.1 IPv6 Address Family and Protocol Family................6
- 3.2 IPv6 Address Structure.................................7
- 3.3 Socket Address Structure for 4.3BSD-Based Systems......7
- 3.4 Socket Address Structure for 4.4BSD-Based Systems......9
- 3.5 The Socket Functions...................................9
- 3.6 Compatibility with IPv4 Applications..................10
- 3.7 Compatibility with IPv4 Nodes.........................11
- 3.8 IPv6 Wildcard Address.................................11
- 3.9 IPv6 Loopback Address.................................13
- 3.10 Portability Additions.................................14
- 4. Interface Identification...................................16
- 4.1 Name-to-Index.........................................17
- 4.2 Index-to-Name.........................................17
- 4.3 Return All Interface Names and Indexes................18
- 4.4 Free Memory...........................................18
- 5. Socket Options.............................................18
- 5.1 Unicast Hop Limit.....................................19
- 5.2 Sending and Receiving Multicast Packets...............19
- 5.3 IPV6_V6ONLY option for AF_INET6 Sockets...............22
- 6. Library Functions..........................................22
- 6.1 Protocol-Independent Nodename and
- Service Name Translation..............................23
- 6.2 Socket Address Structure to Node Name
- and Service Name......................................28
- 6.3 Address Conversion Functions..........................31
- 6.4 Address Testing Macros................................33
- 7. Summary of New Definitions.................................33
- 8. Security Considerations....................................35
- 9. Changes from RFC 2553......................................35
- 10. Acknowledgments............................................36
- 11. References.................................................37
- 12. Authors' Addresses.........................................38
- 13. Full Copyright Statement...................................39
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 2]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-1. Introduction
-
- While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits
- long. The socket interface makes the size of an IP address quite
- visible to an application; virtually all TCP/IP applications for
- BSD-based systems have knowledge of the size of an IP address. Those
- parts of the API that expose the addresses must be changed to
- accommodate the larger IPv6 address size. IPv6 also introduces new
- features, some of which must be made visible to applications via the
- API. This memo defines a set of extensions to the socket interface
- to support the larger address size and new features of IPv6. It
- defines "basic" extensions that are of use to a broad range of
- applications. A companion document, the "advanced" API [4], covers
- extensions that are of use to more specialized applications, examples
- of which include routing daemons, and the "ping" and "traceroute"
- utilities.
-
- The development of this API was started in 1994 in the IETF IPng
- working group. The API has evolved over the years, published first
- in RFC 2133, then again in RFC 2553, and reaching its final form in
- this document.
-
- As the API matured and stabilized, it was incorporated into the Open
- Group's Networking Services (XNS) specification, issue 5.2, which was
- subsequently incorporated into a joint Open Group/IEEE/ISO standard
- [3].
-
- Effort has been made to ensure that this document and [3] contain the
- same information with regard to the API definitions. However, the
- reader should note that this document is for informational purposes
- only, and that the official standard specification of the sockets API
- is [3].
-
- It is expected that any future standardization work on this API would
- be done by the Open Group Base Working Group [6].
-
- It should also be noted that this document describes only those
- portions of the API needed for IPv4 and IPv6 communications. Other
- potential uses of the API, for example the use of getaddrinfo() and
- getnameinfo() with the AF_UNIX address family, are beyond the scope
- of this document.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 3]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-2. Design Considerations
-
- There are a number of important considerations in designing changes
- to this well-worn API:
-
- - The API changes should provide both source and binary
- compatibility for programs written to the original API. That is,
- existing program binaries should continue to operate when run on a
- system supporting the new API. In addition, existing applications
- that are re-compiled and run on a system supporting the new API
- should continue to operate. Simply put, the API changes for IPv6
- should not break existing programs. An additional mechanism for
- implementations to verify this is to verify the new symbols are
- protected by Feature Test Macros as described in [3]. (Such
- Feature Test Macros are not defined by this RFC.)
-
- - The changes to the API should be as small as possible in order to
- simplify the task of converting existing IPv4 applications to
- IPv6.
-
- - Where possible, applications should be able to use this API to
- interoperate with both IPv6 and IPv4 hosts. Applications should
- not need to know which type of host they are communicating with.
-
- - IPv6 addresses carried in data structures should be 64-bit
- aligned. This is necessary in order to obtain optimum performance
- on 64-bit machine architectures.
-
- Because of the importance of providing IPv4 compatibility in the API,
- these extensions are explicitly designed to operate on machines that
- provide complete support for both IPv4 and IPv6. A subset of this
- API could probably be designed for operation on systems that support
- only IPv6. However, this is not addressed in this memo.
-
-2.1 What Needs to be Changed
-
- The socket interface API consists of a few distinct components:
-
- - Core socket functions.
-
- - Address data structures.
-
- - Name-to-address translation functions.
-
- - Address conversion functions.
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 4]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- The core socket functions -- those functions that deal with such
- things as setting up and tearing down TCP connections, and sending
- and receiving UDP packets -- were designed to be transport
- independent. Where protocol addresses are passed as function
- arguments, they are carried via opaque pointers. A protocol-specific
- address data structure is defined for each protocol that the socket
- functions support. Applications must cast pointers to these
- protocol-specific address structures into pointers to the generic
- "sockaddr" address structure when using the socket functions. These
- functions need not change for IPv6, but a new IPv6-specific address
- data structure is needed.
-
- The "sockaddr_in" structure is the protocol-specific data structure
- for IPv4. This data structure actually includes 8-octets of unused
- space, and it is tempting to try to use this space to adapt the
- sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in
- structure is not large enough to hold the 16-octet IPv6 address as
- well as the other information (address family and port number) that
- is needed. So a new address data structure must be defined for IPv6.
-
- IPv6 addresses are scoped [2] so they could be link-local, site,
- organization, global, or other scopes at this time undefined. To
- support applications that want to be able to identify a set of
- interfaces for a specific scope, the IPv6 sockaddr_in structure must
- support a field that can be used by an implementation to identify a
- set of interfaces identifying the scope for an IPv6 address.
-
- The IPv4 name-to-address translation functions in the socket
- interface are gethostbyname() and gethostbyaddr(). These are left as
- is, and new functions are defined which support both IPv4 and IPv6.
-
- The IPv4 address conversion functions -- inet_ntoa() and inet_addr()
- -- convert IPv4 addresses between binary and printable form. These
- functions are quite specific to 32-bit IPv4 addresses. We have
- designed two analogous functions that convert both IPv4 and IPv6
- addresses, and carry an address type parameter so that they can be
- extended to other protocol families as well.
-
- Finally, a few miscellaneous features are needed to support IPv6. A
- new interface is needed to support the IPv6 hop limit header field.
- New socket options are needed to control the sending and receiving of
- IPv6 multicast packets.
-
- The socket interface will be enhanced in the future to provide access
- to other IPv6 features. Some of these extensions are described in
- [4].
-
-
-
-
-
-Gilligan, et al. Informational [Page 5]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-2.2 Data Types
-
- The data types of the structure elements given in this memo are
- intended to track the relevant standards. uintN_t means an unsigned
- integer of exactly N bits (e.g., uint16_t). The sa_family_t and
- in_port_t types are defined in [3].
-
-2.3 Headers
-
- When function prototypes and structures are shown we show the headers
- that must be #included to cause that item to be defined.
-
-2.4 Structures
-
- When structures are described the members shown are the ones that
- must appear in an implementation. Additional, nonstandard members
- may also be defined by an implementation. As an additional
- precaution nonstandard members could be verified by Feature Test
- Macros as described in [3]. (Such Feature Test Macros are not
- defined by this RFC.)
-
- The ordering shown for the members of a structure is the recommended
- ordering, given alignment considerations of multibyte members, but an
- implementation may order the members differently.
-
-3. Socket Interface
-
- This section specifies the socket interface changes for IPv6.
-
-3.1 IPv6 Address Family and Protocol Family
-
- A new address family name, AF_INET6, is defined in <sys/socket.h>.
- The AF_INET6 definition distinguishes between the original
- sockaddr_in address data structure, and the new sockaddr_in6 data
- structure.
-
- A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
- Like most of the other protocol family names, this will usually be
- defined to have the same value as the corresponding address family
- name:
-
- #define PF_INET6 AF_INET6
-
- The AF_INET6 is used in the first argument to the socket() function
- to indicate that an IPv6 socket is being created.
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 6]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-3.2 IPv6 Address Structure
-
- A new in6_addr structure holds a single IPv6 address and is defined
- as a result of including <netinet/in.h>:
-
- struct in6_addr {
- uint8_t s6_addr[16]; /* IPv6 address */
- };
-
- This data structure contains an array of sixteen 8-bit elements,
- which make up one 128-bit IPv6 address. The IPv6 address is stored
- in network byte order.
-
- The structure in6_addr above is usually implemented with an embedded
- union with extra fields that force the desired alignment level in a
- manner similar to BSD implementations of "struct in_addr". Those
- additional implementation details are omitted here for simplicity.
-
- An example is as follows:
-
- struct in6_addr {
- union {
- uint8_t _S6_u8[16];
- uint32_t _S6_u32[4];
- uint64_t _S6_u64[2];
- } _S6_un;
- };
- #define s6_addr _S6_un._S6_u8
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
- In the socket interface, a different protocol-specific data structure
- is defined to carry the addresses for each protocol suite. Each
- protocol-specific data structure is designed so it can be cast into a
- protocol-independent data structure -- the "sockaddr" structure.
- Each has a "family" field that overlays the "sa_family" of the
- sockaddr data structure. This field identifies the type of the data
- structure.
-
- The sockaddr_in structure is the protocol-specific address data
- structure for IPv4. It is used to pass addresses between
- applications and the system in the socket functions. The following
- sockaddr_in6 structure holds IPv6 addresses and is defined as a
- result of including the <netinet/in.h> header:
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 7]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-struct sockaddr_in6 {
- sa_family_t sin6_family; /* AF_INET6 */
- in_port_t sin6_port; /* transport layer port # */
- uint32_t sin6_flowinfo; /* IPv6 flow information */
- struct in6_addr sin6_addr; /* IPv6 address */
- uint32_t sin6_scope_id; /* set of interfaces for a scope */
-};
-
- This structure is designed to be compatible with the sockaddr data
- structure used in the 4.3BSD release.
-
- The sin6_family field identifies this as a sockaddr_in6 structure.
- This field overlays the sa_family field when the buffer is cast to a
- sockaddr data structure. The value of this field must be AF_INET6.
-
- The sin6_port field contains the 16-bit UDP or TCP port number. This
- field is used in the same way as the sin_port field of the
- sockaddr_in structure. The port number is stored in network byte
- order.
-
- The sin6_flowinfo field is a 32-bit field intended to contain flow-
- related information. The exact way this field is mapped to or from a
- packet is not currently specified. Until such time as its use is
- specified, applications should set this field to zero when
- constructing a sockaddr_in6, and ignore this field in a sockaddr_in6
- structure constructed by the system.
-
- The sin6_addr field is a single in6_addr structure (defined in the
- previous section). This field holds one 128-bit IPv6 address. The
- address is stored in network byte order.
-
- The ordering of elements in this structure is specifically designed
- so that when sin6_addr field is aligned on a 64-bit boundary, the
- start of the structure will also be aligned on a 64-bit boundary.
- This is done for optimum performance on 64-bit architectures.
-
- The sin6_scope_id field is a 32-bit integer that identifies a set of
- interfaces as appropriate for the scope [2] of the address carried in
- the sin6_addr field. The mapping of sin6_scope_id to an interface or
- set of interfaces is left to implementation and future specifications
- on the subject of scoped addresses.
-
- Notice that the sockaddr_in6 structure will normally be larger than
- the generic sockaddr structure. On many existing implementations the
- sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
- being 16 bytes. Any existing code that makes this assumption needs
- to be examined carefully when converting to IPv6.
-
-
-
-
-Gilligan, et al. Informational [Page 8]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
- The 4.4BSD release includes a small, but incompatible change to the
- socket interface. The "sa_family" field of the sockaddr data
- structure was changed from a 16-bit value to an 8-bit value, and the
- space saved used to hold a length field, named "sa_len". The
- sockaddr_in6 data structure given in the previous section cannot be
- correctly cast into the newer sockaddr data structure. For this
- reason, the following alternative IPv6 address data structure is
- provided to be used on systems based on 4.4BSD. It is defined as a
- result of including the <netinet/in.h> header.
-
-struct sockaddr_in6 {
- uint8_t sin6_len; /* length of this struct */
- sa_family_t sin6_family; /* AF_INET6 */
- in_port_t sin6_port; /* transport layer port # */
- uint32_t sin6_flowinfo; /* IPv6 flow information */
- struct in6_addr sin6_addr; /* IPv6 address */
- uint32_t sin6_scope_id; /* set of interfaces for a scope */
-};
-
- The only differences between this data structure and the 4.3BSD
- variant are the inclusion of the length field, and the change of the
- family field to a 8-bit data type. The definitions of all the other
- fields are identical to the structure defined in the previous
- section.
-
- Systems that provide this version of the sockaddr_in6 data structure
- must also declare SIN6_LEN as a result of including the
- <netinet/in.h> header. This macro allows applications to determine
- whether they are being built on a system that supports the 4.3BSD or
- 4.4BSD variants of the data structure.
-
-3.5 The Socket Functions
-
- Applications call the socket() function to create a socket descriptor
- that represents a communication endpoint. The arguments to the
- socket() function tell the system which protocol to use, and what
- format address structure will be used in subsequent functions. For
- example, to create an IPv4/TCP socket, applications make the call:
-
- s = socket(AF_INET, SOCK_STREAM, 0);
-
- To create an IPv4/UDP socket, applications make the call:
-
- s = socket(AF_INET, SOCK_DGRAM, 0);
-
-
-
-
-
-Gilligan, et al. Informational [Page 9]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
- handle IPv4 communication as described in section 3.7) by simply
- using the constant AF_INET6 instead of AF_INET in the first argument.
- For example, to create an IPv6/TCP socket, applications make the
- call:
-
- s = socket(AF_INET6, SOCK_STREAM, 0);
-
- To create an IPv6/UDP socket, applications make the call:
-
- s = socket(AF_INET6, SOCK_DGRAM, 0);
-
- Once the application has created a AF_INET6 socket, it must use the
- sockaddr_in6 address structure when passing addresses in to the
- system. The functions that the application uses to pass addresses
- into the system are:
-
- bind()
- connect()
- sendmsg()
- sendto()
-
- The system will use the sockaddr_in6 address structure to return
- addresses to applications that are using AF_INET6 sockets. The
- functions that return an address from the system to an application
- are:
-
- accept()
- recvfrom()
- recvmsg()
- getpeername()
- getsockname()
-
- No changes to the syntax of the socket functions are needed to
- support IPv6, since all of the "address carrying" functions use an
- opaque address pointer, and carry an address length as a function
- argument.
-
-3.6 Compatibility with IPv4 Applications
-
- In order to support the large base of applications using the original
- API, system implementations must provide complete source and binary
- compatibility with the original API. This means that systems must
- continue to support AF_INET sockets and the sockaddr_in address
- structure. Applications must be able to create IPv4/TCP and IPv4/UDP
- sockets using the AF_INET constant in the socket() function, as
-
-
-
-
-
-Gilligan, et al. Informational [Page 10]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- described in the previous section. Applications should be able to
- hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
- sockets simultaneously within the same process.
-
- Applications using the original API should continue to operate as
- they did on systems supporting only IPv4. That is, they should
- continue to interoperate with IPv4 nodes.
-
-3.7 Compatibility with IPv4 Nodes
-
- The API also provides a different type of compatibility: the ability
- for IPv6 applications to interoperate with IPv4 applications. This
- feature uses the IPv4-mapped IPv6 address format defined in the IPv6
- addressing architecture specification [2]. This address format
- allows the IPv4 address of an IPv4 node to be represented as an IPv6
- address. The IPv4 address is encoded into the low-order 32 bits of
- the IPv6 address, and the high-order 96 bits hold the fixed prefix
- 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows:
-
- ::FFFF:<IPv4-address>
-
- These addresses can be generated automatically by the getaddrinfo()
- function, as described in Section 6.1.
-
- Applications may use AF_INET6 sockets to open TCP connections to IPv4
- nodes, or send UDP packets to IPv4 nodes, by simply encoding the
- destination's IPv4 address as an IPv4-mapped IPv6 address, and
- passing that address, within a sockaddr_in6 structure, in the
- connect() or sendto() call. When applications use AF_INET6 sockets
- to accept TCP connections from IPv4 nodes, or receive UDP packets
- from IPv4 nodes, the system returns the peer's address to the
- application in the accept(), recvfrom(), or getpeername() call using
- a sockaddr_in6 structure encoded this way.
-
- Few applications will likely need to know which type of node they are
- interoperating with. However, for those applications that do need to
- know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is
- provided.
-
-3.8 IPv6 Wildcard Address
-
- While the bind() function allows applications to select the source IP
- address of UDP packets and TCP connections, applications often want
- the system to select the source address for them. With IPv4, one
- specifies the address as the symbolic constant INADDR_ANY (called the
- "wildcard" address) in the bind() call, or simply omits the bind()
- entirely.
-
-
-
-
-Gilligan, et al. Informational [Page 11]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- Since the IPv6 address type is a structure (struct in6_addr), a
- symbolic constant can be used to initialize an IPv6 address variable,
- but cannot be used in an assignment. Therefore systems provide the
- IPv6 wildcard address in two forms.
-
- The first version is a global variable named "in6addr_any" that is an
- in6_addr structure. The extern declaration for this variable is
- defined in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_any;
-
- Applications use in6addr_any similarly to the way they use INADDR_ANY
- in IPv4. For example, to bind a socket to port number 23, but let
- the system select the source address, an application could use the
- following code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_any; /* structure assignment */
- . . .
- if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
- The other version is a symbolic constant named IN6ADDR_ANY_INIT and
- is defined in <netinet/in.h>. This constant can be used to
- initialize an in6_addr structure:
-
- struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
- Note that this constant can be used ONLY at declaration time. It can
- not be used to assign a previously declared in6_addr structure. For
- example, the following code will not work:
-
- /* This is the WRONG way to assign an unspecified address */
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
- Be aware that the IPv4 INADDR_xxx constants are all defined in host
- byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
- in6addr_xxx externals are defined in network byte order.
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 12]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-3.9 IPv6 Loopback Address
-
- Applications may need to send UDP packets to, or originate TCP
- connections to, services residing on the local node. In IPv4, they
- can do this by using the constant IPv4 address INADDR_LOOPBACK in
- their connect(), sendto(), or sendmsg() call.
-
- IPv6 also provides a loopback address to contact local TCP and UDP
- services. Like the unspecified address, the IPv6 loopback address is
- provided in two forms -- a global variable and a symbolic constant.
-
- The global variable is an in6_addr structure named
- "in6addr_loopback." The extern declaration for this variable is
- defined in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_loopback;
-
- Applications use in6addr_loopback as they would use INADDR_LOOPBACK
- in IPv4 applications (but beware of the byte ordering difference
- mentioned at the end of the previous section). For example, to open
- a TCP connection to the local telnet server, an application could use
- the following code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_loopback; /* structure assignment */
- . . .
- if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
- The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
- in <netinet/in.h>. It can be used at declaration time ONLY; for
- example:
-
- struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
- Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
- to a previously declared IPv6 address variable.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 13]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-3.10 Portability Additions
-
- One simple addition to the sockets API that can help application
- writers is the "struct sockaddr_storage". This data structure can
- simplify writing code that is portable across multiple address
- families and platforms. This data structure is designed with the
- following goals.
-
- - Large enough to accommodate all supported protocol-specific address
- structures.
-
- - Aligned at an appropriate boundary so that pointers to it can be
- cast as pointers to protocol specific address structures and used
- to access the fields of those structures without alignment
- problems.
-
- The sockaddr_storage structure contains field ss_family which is of
- type sa_family_t. When a sockaddr_storage structure is cast to a
- sockaddr structure, the ss_family field of the sockaddr_storage
- structure maps onto the sa_family field of the sockaddr structure.
- When a sockaddr_storage structure is cast as a protocol specific
- address structure, the ss_family field maps onto a field of that
- structure that is of type sa_family_t and that identifies the
- protocol's address family.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 14]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- An example implementation design of such a data structure would be as
- follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE 128 /* Implementation specific max size */
-#define _SS_ALIGNSIZE (sizeof (int64_t))
- /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) +
- _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
- sa_family_t ss_family; /* address family */
- /* Following fields are implementation specific */
- char __ss_pad1[_SS_PAD1SIZE];
- /* 6 byte pad, this is to make implementation
- /* specific pad up to alignment field that */
- /* follows explicit in the data structure */
- int64_t __ss_align; /* field to force desired structure */
- /* storage alignment */
- char __ss_pad2[_SS_PAD2SIZE];
- /* 112 byte pad to achieve desired size, */
- /* _SS_MAXSIZE value minus size of ss_family */
- /* __ss_pad1, __ss_align fields is 112 */
-};
-
- The above example implementation illustrates a data structure which
- will align on a 64-bit boundary. An implementation-specific field
- "__ss_align" along with "__ss_pad1" is used to force a 64-bit
- alignment which covers proper alignment good enough for the needs of
- sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures. The
- size of padding field __ss_pad1 depends on the chosen alignment
- boundary. The size of padding field __ss_pad2 depends on the value
- of overall size chosen for the total size of the structure. This
- size and alignment are represented in the above example by
- implementation specific (not required) constants _SS_MAXSIZE (chosen
- value 128) and _SS_ALIGNSIZE (with chosen value 8). Constants
- _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112)
- are also for illustration and not required. The derived values
- assume sa_family_t is 2 bytes. The implementation specific
- definitions and structure field names above start with an underscore
- to denote implementation private namespace. Portable code is not
- expected to access or reference those fields or constants.
-
-
-
-
-Gilligan, et al. Informational [Page 15]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- On implementations where the sockaddr data structure includes a
- "sa_len" field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
- (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE -
- (sizeof (uint8_t) + sizeof (sa_family_t) +
- _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
- uint8_t ss_len; /* address length */
- sa_family_t ss_family; /* address family */
- /* Following fields are implementation specific */
- char __ss_pad1[_SS_PAD1SIZE];
- /* 6 byte pad, this is to make implementation
- /* specific pad up to alignment field that */
- /* follows explicit in the data structure */
- int64_t __ss_align; /* field to force desired structure */
- /* storage alignment */
- char __ss_pad2[_SS_PAD2SIZE];
- /* 112 byte pad to achieve desired size, */
- /* _SS_MAXSIZE value minus size of ss_len, */
- /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-4. Interface Identification
-
- This API uses an interface index (a small positive integer) to
- identify the local interface on which a multicast group is joined
- (Section 5.2). Additionally, the advanced API [4] uses these same
- interface indexes to identify the interface on which a datagram is
- received, or to specify the interface on which a datagram is to be
- sent.
-
- Interfaces are normally known by names such as "le0", "sl1", "ppp2",
- and the like. On Berkeley-derived implementations, when an interface
- is made known to the system, the kernel assigns a unique positive
- integer value (called the interface index) to that interface. These
- are small positive integers that start at 1. (Note that 0 is never
- used for an interface index.) There may be gaps so that there is no
- current interface for a particular positive interface index.
-
- This API defines two functions that map between an interface name and
- index, a third function that returns all the interface names and
- indexes, and a fourth function to return the dynamic memory allocated
- by the previous function. How these functions are implemented is
-
-
-
-Gilligan, et al. Informational [Page 16]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- left up to the implementation. 4.4BSD implementations can implement
- these functions using the existing sysctl() function with the
- NET_RT_IFLIST command. Other implementations may wish to use ioctl()
- for this purpose.
-
-4.1 Name-to-Index
-
- The first function maps an interface name into its corresponding
- index.
-
- #include <net/if.h>
-
- unsigned int if_nametoindex(const char *ifname);
-
- If ifname is the name of an interface, the if_nametoindex() function
- shall return the interface index corresponding to name ifname;
- otherwise, it shall return zero. No errors are defined.
-
-4.2 Index-to-Name
-
- The second function maps an interface index into its corresponding
- name.
-
- #include <net/if.h>
-
- char *if_indextoname(unsigned int ifindex, char *ifname);
-
- When this function is called, the ifname argument shall point to a
- buffer of at least IF_NAMESIZE bytes. The function shall place in
- this buffer the name of the interface with index ifindex.
- (IF_NAMESIZE is also defined in <net/if.h> and its value includes a
- terminating null byte at the end of the interface name.) If ifindex
- is an interface index, then the function shall return the value
- supplied in ifname, which points to a buffer now containing the
- interface name. Otherwise, the function shall return a NULL pointer
- and set errno to indicate the error. If there is no interface
- corresponding to the specified index, errno is set to ENXIO. If
- there was a system error (such as running out of memory), errno would
- be set to the proper value (e.g., ENOMEM).
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 17]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-4.3 Return All Interface Names and Indexes
-
- The if_nameindex structure holds the information about a single
- interface and is defined as a result of including the <net/if.h>
- header.
-
- struct if_nameindex {
- unsigned int if_index; /* 1, 2, ... */
- char *if_name; /* null terminated name: "le0", ... */
- };
-
- The final function returns an array of if_nameindex structures, one
- structure per interface.
-
- #include <net/if.h>
-
- struct if_nameindex *if_nameindex(void);
-
- The end of the array of structures is indicated by a structure with
- an if_index of 0 and an if_name of NULL. The function returns a NULL
- pointer upon an error, and would set errno to the appropriate value.
-
- The memory used for this array of structures along with the interface
- names pointed to by the if_name members is obtained dynamically.
- This memory is freed by the next function.
-
-4.4 Free Memory
-
- The following function frees the dynamic memory that was allocated by
- if_nameindex().
-
- #include <net/if.h>
-
- void if_freenameindex(struct if_nameindex *ptr);
-
- The ptr argument shall be a pointer that was returned by
- if_nameindex(). After if_freenameindex() has been called, the
- application shall not use the array of which ptr is the address.
-
-5. Socket Options
-
- A number of new socket options are defined for IPv6. All of these
- new options are at the IPPROTO_IPV6 level. That is, the "level"
- parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
- when using these options. The constant name prefix IPV6_ is used in
- all of the new socket options. This serves to clearly identify these
- options as applying to IPv6.
-
-
-
-
-Gilligan, et al. Informational [Page 18]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
- related constants defined in this section are obtained by including
- the header <netinet/in.h>.
-
-5.1 Unicast Hop Limit
-
- A new setsockopt() option controls the hop limit used in outgoing
- unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS,
- and it is used at the IPPROTO_IPV6 layer. The following example
- illustrates how it is used:
-
- int hoplimit = 10;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, sizeof(hoplimit)) == -1)
- perror("setsockopt IPV6_UNICAST_HOPS");
-
- When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
- option value given is used as the hop limit for all subsequent
- unicast packets sent via that socket. If the option is not set, the
- system selects a default value. The integer hop limit value (called
- x) is interpreted as follows:
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
- The IPV6_UNICAST_HOPS option may be used with getsockopt() to
- determine the hop limit value that the system will use for subsequent
- unicast packets sent via that socket. For example:
-
- int hoplimit;
- socklen_t len = sizeof(hoplimit);
-
- if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, &len) == -1)
- perror("getsockopt IPV6_UNICAST_HOPS");
- else
- printf("Using %d for hop limit.\n", hoplimit);
-
-5.2 Sending and Receiving Multicast Packets
-
- IPv6 applications may send multicast packets by simply specifying an
- IPv6 multicast address as the destination address, for example in the
- destination address argument of the sendto() function.
-
-
-
-
-
-Gilligan, et al. Informational [Page 19]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- Three socket options at the IPPROTO_IPV6 layer control some of the
- parameters for sending multicast packets. Setting these options is
- not required: applications may send multicast packets without using
- these options. The setsockopt() options for controlling the sending
- of multicast packets are summarized below. These three options can
- also be used with getsockopt().
-
- IPV6_MULTICAST_IF
-
- Set the interface to use for outgoing multicast packets. The
- argument is the index of the interface to use. If the
- interface index is specified as zero, the system selects the
- interface (for example, by looking up the address in a routing
- table and using the resulting interface).
-
- Argument type: unsigned int
-
- IPV6_MULTICAST_HOPS
-
- Set the hop limit to use for outgoing multicast packets. (Note
- a separate option - IPV6_UNICAST_HOPS - is provided to set the
- hop limit to use for outgoing unicast packets.)
-
- The interpretation of the argument is the same as for the
- IPV6_UNICAST_HOPS option:
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
- If IPV6_MULTICAST_HOPS is not set, the default is 1
- (same as IPv4 today)
-
- Argument type: int
-
- IPV6_MULTICAST_LOOP
-
- If a multicast datagram is sent to a group to which the sending
- host itself belongs (on the outgoing interface), a copy of the
- datagram is looped back by the IP layer for local delivery if
- this option is set to 1. If this option is set to 0 a copy is
- not looped back. Other option values return an error of
- EINVAL.
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 20]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
- same as IPv4 today).
-
- Argument type: unsigned int
-
- The reception of multicast packets is controlled by the two
- setsockopt() options summarized below. An error of EOPNOTSUPP is
- returned if these two options are used with getsockopt().
-
- IPV6_JOIN_GROUP
-
- Join a multicast group on a specified local interface.
- If the interface index is specified as 0,
- the kernel chooses the local interface.
- For example, some kernels look up the multicast group
- in the normal IPv6 routing table and use the resulting
- interface.
-
- Argument type: struct ipv6_mreq
-
- IPV6_LEAVE_GROUP
-
- Leave a multicast group on a specified interface.
- If the interface index is specified as 0, the system
- may choose a multicast group membership to drop by
- matching the multicast address only.
-
- Argument type: struct ipv6_mreq
-
- The argument type of both of these options is the ipv6_mreq
- structure, defined as a result of including the <netinet/in.h>
- header;
-
- struct ipv6_mreq {
- struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
- unsigned int ipv6mr_interface; /* interface index */
- };
-
- Note that to receive multicast datagrams a process must join the
- multicast group to which datagrams will be sent. UDP applications
- must also bind the UDP port to which datagrams will be sent. Some
- processes also bind the multicast group address to the socket, in
- addition to the port, to prevent other datagrams destined to that
- same port from being delivered to the socket.
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 21]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-5.3 IPV6_V6ONLY option for AF_INET6 Sockets
-
- This socket option restricts AF_INET6 sockets to IPv6 communications
- only. As stated in section <3.7 Compatibility with IPv4 Nodes>,
- AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
- Some applications may want to restrict their use of an AF_INET6
- socket to IPv6 communications only. For these applications the
- IPV6_V6ONLY socket option is defined. When this option is turned on,
- the socket can be used to send and receive IPv6 packets only. This
- is an IPPROTO_IPV6 level option. This option takes an int value.
- This is a boolean option. By default this option is turned off.
-
- Here is an example of setting this option:
-
- int on = 1;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
- (char *)&on, sizeof(on)) == -1)
- perror("setsockopt IPV6_V6ONLY");
- else
- printf("IPV6_V6ONLY set\n");
-
- Note - This option has no effect on the use of IPv4 Mapped addresses
- which enter a node as a valid IPv6 addresses for IPv6 communications
- as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
-
- An example use of this option is to allow two versions of the same
- server process to run on the same port, one providing service over
- IPv6, the other providing the same service over IPv4.
-
-6. Library Functions
-
- New library functions are needed to perform a variety of operations
- with IPv6 addresses. Functions are needed to lookup IPv6 addresses
- in the Domain Name System (DNS). Both forward lookup (nodename-to-
- address translation) and reverse lookup (address-to-nodename
- translation) need to be supported. Functions are also needed to
- convert IPv6 addresses between their binary and textual form.
-
- We note that the two existing functions, gethostbyname() and
- gethostbyaddr(), are left as-is. New functions are defined to handle
- both IPv4 and IPv6 addresses.
-
- The commonly used function gethostbyname() is inadequate for many
- applications, first because it provides no way for the caller to
- specify anything about the types of addresses desired (IPv4 only,
- IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
- implementations of this function are not thread safe. RFC 2133
-
-
-
-Gilligan, et al. Informational [Page 22]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- defined a function named gethostbyname2() but this function was also
- inadequate, first because its use required setting a global option
- (RES_USE_INET6) when IPv6 addresses were required, and second because
- a flag argument is needed to provide the caller with additional
- control over the types of addresses required. The gethostbyname2()
- function was deprecated in RFC 2553 and is no longer part of the
- basic API.
-
-6.1 Protocol-Independent Nodename and Service Name Translation
-
- Nodename-to-address translation is done in a protocol-independent
- fashion using the getaddrinfo() function.
-
-#include <sys/socket.h>
-#include <netdb.h>
-
-
-int getaddrinfo(const char *nodename, const char *servname,
- const struct addrinfo *hints, struct addrinfo **res);
-
-void freeaddrinfo(struct addrinfo *ai);
-
-struct addrinfo {
- int ai_flags; /* AI_PASSIVE, AI_CANONNAME,
- AI_NUMERICHOST, .. */
- int ai_family; /* AF_xxx */
- int ai_socktype; /* SOCK_xxx */
- int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
- socklen_t ai_addrlen; /* length of ai_addr */
- char *ai_canonname; /* canonical name for nodename */
- struct sockaddr *ai_addr; /* binary address */
- struct addrinfo *ai_next; /* next structure in linked list */
-};
-
- The getaddrinfo() function translates the name of a service location
- (for example, a host name) and/or a service name and returns a set of
- socket addresses and associated information to be used in creating a
- socket with which to address the specified service.
-
- The nodename and servname arguments are either null pointers or
- pointers to null-terminated strings. One or both of these two
- arguments must be a non-null pointer.
-
- The format of a valid name depends on the address family or families.
- If a specific family is not given and the name could be interpreted
- as valid within multiple supported families, the implementation will
- attempt to resolve the name in all supported families and, in absence
- of errors, one or more results shall be returned.
-
-
-
-Gilligan, et al. Informational [Page 23]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- If the nodename argument is not null, it can be a descriptive name or
- can be an address string. If the specified address family is
- AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host
- names. If the specified address family is AF_INET or AF_UNSPEC,
- address strings using Internet standard dot notation as specified in
- inet_addr() are valid. If the specified address family is AF_INET6
- or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
- valid.
-
- If nodename is not null, the requested service location is named by
- nodename; otherwise, the requested service location is local to the
- caller.
-
- If servname is null, the call shall return network-level addresses
- for the specified nodename. If servname is not null, it is a null-
- terminated character string identifying the requested service. This
- can be either a descriptive name or a numeric representation suitable
- for use with the address family or families. If the specified
- address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
- specified as a string specifying a decimal port number.
-
- If the argument hints is not null, it refers to a structure
- containing input values that may direct the operation by providing
- options and by limiting the returned information to a specific socket
- type, address family and/or protocol. In this hints structure every
- member other than ai_flags, ai_family, ai_socktype and ai_protocol
- shall be set to zero or a null pointer. A value of AF_UNSPEC for
- ai_family means that the caller shall accept any address family. A
- value of zero for ai_socktype means that the caller shall accept any
- socket type. A value of zero for ai_protocol means that the caller
- shall accept any protocol. If hints is a null pointer, the behavior
- shall be as if it referred to a structure containing the value zero
- for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
- for the ai_family field.
-
- Note:
-
- 1. If the caller handles only TCP and not UDP, for example, then the
- ai_protocol member of the hints structure should be set to
- IPPROTO_TCP when getaddrinfo() is called.
-
- 2. If the caller handles only IPv4 and not IPv6, then the ai_family
- member of the hints structure should be set to AF_INET when
- getaddrinfo() is called.
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 24]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- The ai_flags field to which hints parameter points shall be set to
- zero or be the bitwise-inclusive OR of one or more of the values
- AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
- AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
-
- If the AI_PASSIVE flag is specified, the returned address information
- shall be suitable for use in binding a socket for accepting incoming
- connections for the specified service (i.e., a call to bind()). In
- this case, if the nodename argument is null, then the IP address
- portion of the socket address structure shall be set to INADDR_ANY
- for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the
- AI_PASSIVE flag is not specified, the returned address information
- shall be suitable for a call to connect() (for a connection-mode
- protocol) or for a call to connect(), sendto() or sendmsg() (for a
- connectionless protocol). In this case, if the nodename argument is
- null, then the IP address portion of the socket address structure
- shall be set to the loopback address. This flag is ignored if the
- nodename argument is not null.
-
- If the AI_CANONNAME flag is specified and the nodename argument is
- not null, the function shall attempt to determine the canonical name
- corresponding to nodename (for example, if nodename is an alias or
- shorthand notation for a complete name).
-
- If the AI_NUMERICHOST flag is specified, then a non-null nodename
- string supplied shall be a numeric host address string. Otherwise,
- an [EAI_NONAME] error is returned. This flag shall prevent any type
- of name resolution service (for example, the DNS) from being invoked.
-
- If the AI_NUMERICSERV flag is specified, then a non-null servname
- string supplied shall be a numeric port string. Otherwise, an
- [EAI_NONAME] error shall be returned. This flag shall prevent any
- type of name resolution service (for example, NIS+) from being
- invoked.
-
- If the AI_V4MAPPED flag is specified along with an ai_family of
- AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
- on finding no matching IPv6 addresses (ai_addrlen shall be 16).
-
- For example, when using the DNS, if no AAAA records are found then
- a query is made for A records and any found are returned as IPv4-
- mapped IPv6 addresses.
-
- The AI_V4MAPPED flag shall be ignored unless ai_family equals
- AF_INET6.
-
- If the AI_ALL flag is used with the AI_V4MAPPED flag, then
- getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
-
-
-
-Gilligan, et al. Informational [Page 25]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- For example, when using the DNS, queries are made for both AAAA
- records and A records, and getaddrinfo() returns the combined
- results of both queries. Any IPv4 addresses found are returned as
- IPv4-mapped IPv6 addresses.
-
- The AI_ALL flag without the AI_V4MAPPED flag is ignored.
-
- Note:
-
- When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
- AI_ALL flags will only be used if AF_INET6 is supported.
-
- If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
- returned only if an IPv4 address is configured on the local system,
- and IPv6 addresses shall be returned only if an IPv6 address is
- configured on the local system. The loopback address is not
- considered for this case as valid as a configured address.
-
- For example, when using the DNS, a query for AAAA records should
- occur only if the node has at least one IPv6 address configured
- (other than IPv6 loopback) and a query for A records should occur
- only if the node has at least one IPv4 address configured (other
- than the IPv4 loopback).
-
- The ai_socktype field to which argument hints points specifies the
- socket type for the service, as defined for socket(). If a specific
- socket type is not given (for example, a value of zero) and the
- service name could be interpreted as valid with multiple supported
- socket types, the implementation shall attempt to resolve the service
- name for all supported socket types and, in the absence of errors,
- all possible results shall be returned. A non-zero socket type value
- shall limit the returned information to values with the specified
- socket type.
-
- If the ai_family field to which hints points has the value AF_UNSPEC,
- addresses shall be returned for use with any address family that can
- be used with the specified nodename and/or servname. Otherwise,
- addresses shall be returned for use only with the specified address
- family. If ai_family is not AF_UNSPEC and ai_protocol is not zero,
- then addresses are returned for use only with the specified address
- family and protocol; the value of ai_protocol shall be interpreted as
- in a call to the socket() function with the corresponding values of
- ai_family and ai_protocol.
-
- The freeaddrinfo() function frees one or more addrinfo structures
- returned by getaddrinfo(), along with any additional storage
- associated with those structures (for example, storage pointed to by
- the ai_canonname and ai_addr fields; an application must not
-
-
-
-Gilligan, et al. Informational [Page 26]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- reference this storage after the associated addrinfo structure has
- been freed). If the ai_next field of the structure is not null, the
- entire list of structures is freed. The freeaddrinfo() function must
- support the freeing of arbitrary sublists of an addrinfo list
- originally returned by getaddrinfo().
-
- Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
-
- A zero return value for getaddrinfo() indicates successful
- completion; a non-zero return value indicates failure. The possible
- values for the failures are listed below under Error Return Values.
-
- Upon successful return of getaddrinfo(), the location to which res
- points shall refer to a linked list of addrinfo structures, each of
- which shall specify a socket address and information for use in
- creating a socket with which to use that socket address. The list
- shall include at least one addrinfo structure. The ai_next field of
- each structure contains a pointer to the next structure on the list,
- or a null pointer if it is the last structure on the list. Each
- structure on the list shall include values for use with a call to the
- socket() function, and a socket address for use with the connect()
- function or, if the AI_PASSIVE flag was specified, for use with the
- bind() function. The fields ai_family, ai_socktype, and ai_protocol
- shall be usable as the arguments to the socket() function to create a
- socket suitable for use with the returned address. The fields
- ai_addr and ai_addrlen are usable as the arguments to the connect()
- or bind() functions with such a socket, according to the AI_PASSIVE
- flag.
-
- If nodename is not null, and if requested by the AI_CANONNAME flag,
- the ai_canonname field of the first returned addrinfo structure shall
- point to a null-terminated string containing the canonical name
- corresponding to the input nodename; if the canonical name is not
- available, then ai_canonname shall refer to the nodename argument or
- a string with the same contents. The contents of the ai_flags field
- of the returned structures are undefined.
-
- All fields in socket address structures returned by getaddrinfo()
- that are not filled in through an explicit argument (for example,
- sin6_flowinfo) shall be set to zero.
-
- Note: This makes it easier to compare socket address structures.
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 27]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- Error Return Values:
-
- The getaddrinfo() function shall fail and return the corresponding
- value if:
-
- [EAI_AGAIN] The name could not be resolved at this time. Future
- attempts may succeed.
-
- [EAI_BADFLAGS] The flags parameter had an invalid value.
-
- [EAI_FAIL] A non-recoverable error occurred when attempting to
- resolve the name.
-
- [EAI_FAMILY] The address family was not recognized.
-
- [EAI_MEMORY] There was a memory allocation failure when trying to
- allocate storage for the return value.
-
- [EAI_NONAME] The name does not resolve for the supplied
- parameters. Neither nodename nor servname were
- supplied. At least one of these must be supplied.
-
- [EAI_SERVICE] The service passed was not recognized for the
- specified socket type.
-
- [EAI_SOCKTYPE] The intended socket type was not recognized.
-
- [EAI_SYSTEM] A system error occurred; the error code can be found
- in errno.
-
- The gai_strerror() function provides a descriptive text string
- corresponding to an EAI_xxx error value.
-
- #include <netdb.h>
-
- const char *gai_strerror(int ecode);
-
- The argument is one of the EAI_xxx values defined for the
- getaddrinfo() and getnameinfo() functions. The return value points
- to a string describing the error. If the argument is not one of the
- EAI_xxx values, the function still returns a pointer to a string
- whose contents indicate an unknown error.
-
-6.2 Socket Address Structure to Node Name and Service Name
-
- The getnameinfo() function is used to translate the contents of a
- socket address structure to a node name and/or service name.
-
-
-
-
-Gilligan, et al. Informational [Page 28]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- int getnameinfo(const struct sockaddr *sa, socklen_t salen,
- char *node, socklen_t nodelen,
- char *service, socklen_t servicelen,
- int flags);
-
- The getnameinfo() function shall translate a socket address to a node
- name and service location, all of which are defined as in
- getaddrinfo().
-
- The sa argument points to a socket address structure to be
- translated.
-
- The salen argument holds the size of the socket address structure
- pointed to by sa.
-
- If the socket address structure contains an IPv4-mapped IPv6 address
- or an IPv4-compatible IPv6 address, the implementation shall extract
- the embedded IPv4 address and lookup the node name for that IPv4
- address.
-
- Note: The IPv6 unspecified address ("::") and the IPv6 loopback
- address ("::1") are not IPv4-compatible addresses. If the address
- is the IPv6 unspecified address ("::"), a lookup is not performed,
- and the [EAI_NONAME] error is returned.
-
- If the node argument is non-NULL and the nodelen argument is nonzero,
- then the node argument points to a buffer able to contain up to
- nodelen characters that receives the node name as a null-terminated
- string. If the node argument is NULL or the nodelen argument is
- zero, the node name shall not be returned. If the node's name cannot
- be located, the numeric form of the node's address is returned
- instead of its name.
-
- If the service argument is non-NULL and the servicelen argument is
- non-zero, then the service argument points to a buffer able to
- contain up to servicelen bytes that receives the service name as a
- null-terminated string. If the service argument is NULL or the
- servicelen argument is zero, the service name shall not be returned.
- If the service's name cannot be located, the numeric form of the
- service address (for example, its port number) shall be returned
- instead of its name.
-
- The arguments node and service cannot both be NULL.
-
-
-
-
-
-Gilligan, et al. Informational [Page 29]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- The flags argument is a flag that changes the default actions of the
- function. By default the fully-qualified domain name (FQDN) for the
- host shall be returned, but:
-
- - If the flag bit NI_NOFQDN is set, only the node name portion of
- the FQDN shall be returned for local hosts.
-
- - If the flag bit NI_NUMERICHOST is set, the numeric form of the
- host's address shall be returned instead of its name, under all
- circumstances.
-
- - If the flag bit NI_NAMEREQD is set, an error shall be returned if
- the host's name cannot be located.
-
- - If the flag bit NI_NUMERICSERV is set, the numeric form of the
- service address shall be returned (for example, its port number)
- instead of its name, under all circumstances.
-
- - If the flag bit NI_DGRAM is set, this indicates that the service
- is a datagram service (SOCK_DGRAM). The default behavior shall
- assume that the service is a stream service (SOCK_STREAM).
-
- Note:
-
- 1. The NI_NUMERICxxx flags are required to support the "-n" flags
- that many commands provide.
-
- 2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6
- port numbers (for example, [512,514]) that represent different
- services for UDP and TCP.
-
- The getnameinfo() function shall be thread safe.
-
- A zero return value for getnameinfo() indicates successful
- completion; a non-zero return value indicates failure.
-
- Upon successful completion, getnameinfo() shall return the node and
- service names, if requested, in the buffers provided. The returned
- names are always null-terminated strings.
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 30]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- Error Return Values:
-
- The getnameinfo() function shall fail and return the corresponding
- value if:
-
- [EAI_AGAIN] The name could not be resolved at this time.
- Future attempts may succeed.
-
- [EAI_BADFLAGS] The flags had an invalid value.
-
- [EAI_FAIL] A non-recoverable error occurred.
-
- [EAI_FAMILY] The address family was not recognized or the address
- length was invalid for the specified family.
-
- [EAI_MEMORY] There was a memory allocation failure.
-
- [EAI_NONAME] The name does not resolve for the supplied parameters.
- NI_NAMEREQD is set and the host's name cannot be
- located, or both nodename and servname were null.
-
- [EAI_OVERFLOW] An argument buffer overflowed.
-
- [EAI_SYSTEM] A system error occurred. The error code can be found
- in errno.
-
-6.3 Address Conversion Functions
-
- The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
- address between binary and text form. IPv6 applications need similar
- functions. The following two functions convert both IPv6 and IPv4
- addresses:
-
- #include <arpa/inet.h>
-
- int inet_pton(int af, const char *src, void *dst);
-
- const char *inet_ntop(int af, const void *src,
- char *dst, socklen_t size);
-
- The inet_pton() function shall convert an address in its standard
- text presentation form into its numeric binary form. The af argument
- shall specify the family of the address. The AF_INET and AF_INET6
- address families shall be supported. The src argument points to the
- string being passed in. The dst argument points to a buffer into
- which the function stores the numeric address; this shall be large
- enough to hold the numeric address (32 bits for AF_INET, 128 bits for
- AF_INET6). The inet_pton() function shall return 1 if the conversion
-
-
-
-Gilligan, et al. Informational [Page 31]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- succeeds, with the address pointed to by dst in network byte order.
- It shall return 0 if the input is not a valid IPv4 dotted-decimal
- string or a valid IPv6 address string, or -1 with errno set to
- EAFNOSUPPORT if the af argument is unknown.
-
- If the af argument of inet_pton() is AF_INET, the src string shall be
- in the standard IPv4 dotted-decimal form:
-
- ddd.ddd.ddd.ddd
-
- where "ddd" is a one to three digit decimal number between 0 and 255.
- The inet_pton() function does not accept other formats (such as the
- octal numbers, hexadecimal numbers, and fewer than four numbers that
- inet_addr() accepts).
-
- If the af argument of inet_pton() is AF_INET6, the src string shall
- be in one of the standard IPv6 text forms defined in Section 2.2 of
- the addressing architecture specification [2].
-
- The inet_ntop() function shall convert a numeric address into a text
- string suitable for presentation. The af argument shall specify the
- family of the address. This can be AF_INET or AF_INET6. The src
- argument points to a buffer holding an IPv4 address if the af
- argument is AF_INET, or an IPv6 address if the af argument is
- AF_INET6; the address must be in network byte order. The dst
- argument points to a buffer where the function stores the resulting
- text string; it shall not be NULL. The size argument specifies the
- size of this buffer, which shall be large enough to hold the text
- string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN
- characters for IPv6).
-
- In order to allow applications to easily declare buffers of the
- proper size to store IPv4 and IPv6 addresses in string form, the
- following two constants are defined in <netinet/in.h>:
-
- #define INET_ADDRSTRLEN 16
- #define INET6_ADDRSTRLEN 46
-
- The inet_ntop() function shall return a pointer to the buffer
- containing the text string if the conversion succeeds, and NULL
- otherwise. Upon failure, errno is set to EAFNOSUPPORT if the af
- argument is invalid or ENOSPC if the size of the result buffer is
- inadequate.
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 32]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-6.4 Address Testing Macros
-
- The following macros can be used to test for special IPv6 addresses.
-
- #include <netinet/in.h>
-
- int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
- int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
- int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
- int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
- int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
-
- int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
-
- The first seven macros return true if the address is of the specified
- type, or false otherwise. The last five test the scope of a
- multicast address and return true if the address is a multicast
- address of the specified scope or false if the address is either not
- a multicast address or not of the specified scope.
-
- Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
- only for the two types of local-use IPv6 unicast addresses (Link-
- Local and Site-Local) defined in [2], and that by this definition,
- the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback
- address (::1). These two macros do not return true for IPv6
- multicast addresses of either link-local scope or site-local scope.
-
-7. Summary of New Definitions
-
- The following list summarizes the constants, structure, and extern
- definitions discussed in this memo, sorted by header.
-
-<net/if.h> IF_NAMESIZE
-<net/if.h> struct if_nameindex{};
-
-<netdb.h> AI_ADDRCONFIG
-<netdb.h> AI_ALL
-<netdb.h> AI_CANONNAME
-<netdb.h> AI_NUMERICHOST
-<netdb.h> AI_NUMERICSERV
-<netdb.h> AI_PASSIVE
-<netdb.h> AI_V4MAPPED
-
-
-
-Gilligan, et al. Informational [Page 33]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-<netdb.h> EAI_AGAIN
-<netdb.h> EAI_BADFLAGS
-<netdb.h> EAI_FAIL
-<netdb.h> EAI_FAMILY
-<netdb.h> EAI_MEMORY
-<netdb.h> EAI_NONAME
-<netdb.h> EAI_OVERFLOW
-<netdb.h> EAI_SERVICE
-<netdb.h> EAI_SOCKTYPE
-<netdb.h> EAI_SYSTEM
-<netdb.h> NI_DGRAM
-<netdb.h> NI_NAMEREQD
-<netdb.h> NI_NOFQDN
-<netdb.h> NI_NUMERICHOST
-<netdb.h> NI_NUMERICSERV
-<netdb.h> struct addrinfo{};
-
-<netinet/in.h> IN6ADDR_ANY_INIT
-<netinet/in.h> IN6ADDR_LOOPBACK_INIT
-<netinet/in.h> INET6_ADDRSTRLEN
-<netinet/in.h> INET_ADDRSTRLEN
-<netinet/in.h> IPPROTO_IPV6
-<netinet/in.h> IPV6_JOIN_GROUP
-<netinet/in.h> IPV6_LEAVE_GROUP
-<netinet/in.h> IPV6_MULTICAST_HOPS
-<netinet/in.h> IPV6_MULTICAST_IF
-<netinet/in.h> IPV6_MULTICAST_LOOP
-<netinet/in.h> IPV6_UNICAST_HOPS
-<netinet/in.h> IPV6_V6ONLY
-<netinet/in.h> SIN6_LEN
-<netinet/in.h> extern const struct in6_addr in6addr_any;
-<netinet/in.h> extern const struct in6_addr in6addr_loopback;
-<netinet/in.h> struct in6_addr{};
-<netinet/in.h> struct ipv6_mreq{};
-<netinet/in.h> struct sockaddr_in6{};
-
-<sys/socket.h> AF_INET6
-<sys/socket.h> PF_INET6
-<sys/socket.h> struct sockaddr_storage;
-
- The following list summarizes the function and macro prototypes
- discussed in this memo, sorted by header.
-
-<arpa/inet.h> int inet_pton(int, const char *, void *);
-<arpa/inet.h> const char *inet_ntop(int, const void *,
- char *, socklen_t);
-
-
-
-
-
-Gilligan, et al. Informational [Page 34]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-<net/if.h> char *if_indextoname(unsigned int, char *);
-<net/if.h> unsigned int if_nametoindex(const char *);
-<net/if.h> void if_freenameindex(struct if_nameindex *);
-<net/if.h> struct if_nameindex *if_nameindex(void);
-
-<netdb.h> int getaddrinfo(const char *, const char *,
- const struct addrinfo *,
- struct addrinfo **);
-<netdb.h> int getnameinfo(const struct sockaddr *, socklen_t,
- char *, socklen_t, char *, socklen_t, int);
-<netdb.h> void freeaddrinfo(struct addrinfo *);
-<netdb.h> const char *gai_strerror(int);
-
-<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-8. Security Considerations
-
- IPv6 provides a number of new security mechanisms, many of which need
- to be accessible to applications. Companion memos detailing the
- extensions to the socket interfaces to support IPv6 security are
- being written.
-
-9. Changes from RFC 2553
-
- 1. Add brief description of the history of this API and its relation
- to the Open Group/IEEE/ISO standards.
-
- 2. Alignments with [3].
-
- 3. Removed all references to getipnodebyname() and getipnodebyaddr(),
- which are deprecated in favor of getaddrinfo() and getnameinfo().
-
- 4. Added IPV6_V6ONLY IP level socket option to permit nodes to not
- process IPv4 packets as IPv4 Mapped addresses in implementations.
-
- 5. Added SIIT to references and added new contributors.
-
-
-
-
-Gilligan, et al. Informational [Page 35]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
- 6. In previous versions of this specification, the sin6_flowinfo
- field was associated with the IPv6 traffic class and flow label,
- but its usage was not completely specified. The complete
- definition of the sin6_flowinfo field, including its association
- with the traffic class or flow label, is now deferred to a future
- specification.
-
-10. Acknowledgments
-
- This specification's evolution and completeness were significantly
- influenced by the efforts of Richard Stevens, who has passed on.
- Richard's wisdom and talent made the specification what it is today.
- The co-authors will long think of Richard with great respect.
-
- Thanks to the many people who made suggestions and provided feedback
- to this document, including:
-
- Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
- Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves,
- Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino,
- Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema,
- Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan
- McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne,
- Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos,
- Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey
- Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie,
- David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig
- Venaas, and Brian Zill.
-
- The getaddrinfo() and getnameinfo() functions are taken from an
- earlier document by Keith Sklower. As noted in that document,
- William Durst, Steven Wise, Michael Karels, and Eric Allman provided
- many useful discussions on the subject of protocol-independent name-
- to-address translation, and reviewed early versions of Keith
- Sklower's original proposal. Eric Allman implemented the first
- prototype of getaddrinfo(). The observation that specifying the pair
- of name and service would suffice for connecting to a service
- independent of protocol details was made by Marshall Rose in a
- proposal to X/Open for a "Uniform Network Interface".
-
- Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
- Kacker made many contributions to this document. Ramesh Govindan
- made a number of contributions and co-authored an earlier version of
- this memo.
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 36]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-11. References
-
- [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
- Specification", RFC 2460, December 1998.
-
- [2] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [3] 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
-
- [4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
- 2292, February 1998.
-
- [5] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
- RFC 2765, February 2000.
-
- [6] The Open Group Base Working Group
- http://www.opengroup.org/platform/base.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 37]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-12. Authors' Addresses
-
- Bob Gilligan
- Intransa, Inc.
- 2870 Zanker Rd.
- San Jose, CA 95134
-
- Phone: 408-678-8647
- EMail: gilligan@intransa.com
-
-
- Susan Thomson
- Cisco Systems
- 499 Thornall Street, 8th floor
- Edison, NJ 08837
-
- Phone: 732-635-3086
- EMail: sethomso@cisco.com
-
-
- Jim Bound
- Hewlett-Packard Company
- 110 Spitbrook Road ZKO3-3/W20
- Nashua, NH 03062
-
- Phone: 603-884-0062
- EMail: Jim.Bound@hp.com
-
-
- Jack McCann
- Hewlett-Packard Company
- 110 Spitbrook Road ZKO3-3/W20
- Nashua, NH 03062
-
- Phone: 603-884-2608
- EMail: Jack.McCann@hp.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 38]
-
-RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al. Informational [Page 39]
-
diff --git a/contrib/bind9/doc/rfc/rfc3513.txt b/contrib/bind9/doc/rfc/rfc3513.txt
deleted file mode 100644
index 49c0fa4124778..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3513.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Hinden
-Request for Comments: 3513 Nokia
-Obsoletes: 2373 S. Deering
-Category: Standards Track Cisco Systems
- April 2003
-
-
- Internet Protocol Version 6 (IPv6) Addressing Architecture
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- This specification defines the addressing architecture of the IP
- Version 6 (IPv6) protocol. The document includes the IPv6 addressing
- model, text representations of IPv6 addresses, definition of IPv6
- unicast addresses, anycast addresses, and multicast addresses, and an
- IPv6 node's required addresses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 1]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-Table of Contents
-
- 1. Introduction.................................................3
- 2. IPv6 Addressing..............................................3
- 2.1 Addressing Model.........................................4
- 2.2 Text Representation of Addresses.........................4
- 2.3 Text Representation of Address Prefixes..................5
- 2.4 Address Type Identification..............................6
- 2.5 Unicast Addresses........................................7
- 2.5.1 Interface Identifiers..............................8
- 2.5.2 The Unspecified Address............................9
- 2.5.3 The Loopback Address...............................9
- 2.5.4 Global Unicast Addresses..........................10
- 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10
- 2.5.6 Local-use IPv6 Unicast Addresses..................11
- 2.6 Anycast Addresses.......................................12
- 2.6.1 Required Anycast Address..........................13
- 2.7 Multicast Addresses.....................................13
- 2.7.1 Pre-Defined Multicast Addresses...................15
- 2.8 A Node's Required Addresses.............................17
- 3. Security Considerations.....................................17
- 4. IANA Considerations.........................................18
- 5. References..................................................19
- 5.1 Normative References....................................19
- 5.2 Informative References..................................19
- APPENDIX A: Creating Modified EUI-64 format Interface IDs......21
- APPENDIX B: Changes from RFC-2373..............................24
- Authors' Addresses.............................................25
- Full Copyright Statement.......................................26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 2]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-1. Introduction
-
- This specification defines the addressing architecture of the IP
- Version 6 (IPv6) protocol. It includes the basic formats for the
- various types of IPv6 addresses (unicast, anycast, and multicast).
-
- The authors would like to acknowledge the contributions of Paul
- Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
- Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
- Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
- Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
- Sue Thomson, Markku Savela, and Larry Masinter.
-
-2. IPv6 Addressing
-
- IPv6 addresses are 128-bit identifiers for interfaces and sets of
- interfaces (where "interface" is as defined in section 2 of [IPV6]).
- There are three types of addresses:
-
- Unicast: An identifier for a single interface. A packet sent to a
- unicast address is delivered to the interface identified
- by that address.
-
- Anycast: An identifier for a set of interfaces (typically belonging
- to different nodes). A packet sent to an anycast address
- is delivered to one of the interfaces identified by that
- address (the "nearest" one, according to the routing
- protocols' measure of distance).
-
- Multicast: An identifier for a set of interfaces (typically belonging
- to different nodes). A packet sent to a multicast address
- is delivered to all interfaces identified by that address.
-
- There are no broadcast addresses in IPv6, their function being
- superseded by multicast addresses.
-
- In this document, fields in addresses are given a specific name, for
- example "subnet". When this name is used with the term "ID" for
- identifier after the name (e.g., "subnet ID"), it refers to the
- contents of the named field. When it is used with the term "prefix"
- (e.g., "subnet prefix") it refers to all of the address from the left
- up to and including this field.
-
- In IPv6, all zeros and all ones are legal values for any field,
- unless specifically excluded. Specifically, prefixes may contain, or
- end with, zero-valued fields.
-
-
-
-
-
-Hinden & Deering Standards Track [Page 3]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-2.1 Addressing Model
-
- IPv6 addresses of all types are assigned to interfaces, not nodes.
- An IPv6 unicast address refers to a single interface. Since each
- interface belongs to a single node, any of that node's interfaces'
- unicast addresses may be used as an identifier for the node.
-
- All interfaces are required to have at least one link-local unicast
- address (see section 2.8 for additional required addresses). A
- single interface may also have multiple IPv6 addresses of any type
- (unicast, anycast, and multicast) or scope. Unicast addresses with
- scope greater than link-scope are not needed for interfaces that are
- not used as the origin or destination of any IPv6 packets to or from
- non-neighbors. This is sometimes convenient for point-to-point
- interfaces. There is one exception to this addressing model:
-
- A unicast address or a set of unicast addresses may be assigned to
- multiple physical interfaces if the implementation treats the
- multiple physical interfaces as one interface when presenting it
- to the internet layer. This is useful for load-sharing over
- multiple physical interfaces.
-
- Currently IPv6 continues the IPv4 model that a subnet prefix is
- associated with one link. Multiple subnet prefixes may be assigned
- to the same link.
-
-2.2 Text Representation of Addresses
-
- There are three conventional forms for representing IPv6 addresses as
- text strings:
-
- 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
- hexadecimal values of the eight 16-bit pieces of the address.
-
- Examples:
-
- FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
- 1080:0:0:0:8:800:200C:417A
-
- Note that it is not necessary to write the leading zeros in an
- individual field, but there must be at least one numeral in every
- field (except for the case described in 2.).
-
- 2. Due to some methods of allocating certain styles of IPv6
- addresses, it will be common for addresses to contain long strings
- of zero bits. In order to make writing addresses containing zero
- bits easier a special syntax is available to compress the zeros.
-
-
-
-Hinden & Deering Standards Track [Page 4]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- The use of "::" indicates one or more groups of 16 bits of zeros.
- The "::" can only appear once in an address. The "::" can also be
- used to compress leading or trailing zeros in an address.
-
- For example, the following addresses:
-
- 1080:0:0:0:8:800:200C:417A a unicast address
- FF01:0:0:0:0:0:0:101 a multicast address
- 0:0:0:0:0:0:0:1 the loopback address
- 0:0:0:0:0:0:0:0 the unspecified addresses
-
- may be represented as:
-
- 1080::8:800:200C:417A a unicast address
- FF01::101 a multicast address
- ::1 the loopback address
- :: the unspecified addresses
-
- 3. An alternative form that is sometimes more convenient when dealing
- with a mixed environment of IPv4 and IPv6 nodes is
- x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
- the six high-order 16-bit pieces of the address, and the 'd's are
- the decimal values of the four low-order 8-bit pieces of the
- address (standard IPv4 representation). Examples:
-
- 0:0:0:0:0:0:13.1.68.3
-
- 0:0:0:0:0:FFFF:129.144.52.38
-
- or in compressed form:
-
- ::13.1.68.3
-
- ::FFFF:129.144.52.38
-
-2.3 Text Representation of Address Prefixes
-
- The text representation of IPv6 address prefixes is similar to the
- way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An
- IPv6 address prefix is represented by the notation:
-
- ipv6-address/prefix-length
-
- where
-
- ipv6-address is an IPv6 address in any of the notations listed
- in section 2.2.
-
-
-
-
-Hinden & Deering Standards Track [Page 5]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- prefix-length is a decimal value specifying how many of the
- leftmost contiguous bits of the address comprise
- the prefix.
-
- For example, the following are legal representations of the 60-bit
- prefix 12AB00000000CD3 (hexadecimal):
-
- 12AB:0000:0000:CD30:0000:0000:0000:0000/60
- 12AB::CD30:0:0:0:0/60
- 12AB:0:0:CD30::/60
-
- The following are NOT legal representations of the above prefix:
-
- 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros,
- within any 16-bit chunk of the address
-
- 12AB::CD30/60 address to left of "/" expands to
- 12AB:0000:0000:0000:0000:000:0000:CD30
-
- 12AB::CD3/60 address to left of "/" expands to
- 12AB:0000:0000:0000:0000:000:0000:0CD3
-
- When writing both a node address and a prefix of that node address
- (e.g., the node's subnet prefix), the two can combined as follows:
-
- the node address 12AB:0:0:CD30:123:4567:89AB:CDEF
- and its subnet number 12AB:0:0:CD30::/60
-
- can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
-
-2.4 Address Type Identification
-
- The type of an IPv6 address is identified by the high-order bits of
- the address, as follows:
-
- Address type Binary prefix IPv6 notation Section
- ------------ ------------- ------------- -------
- Unspecified 00...0 (128 bits) ::/128 2.5.2
- Loopback 00...1 (128 bits) ::1/128 2.5.3
- Multicast 11111111 FF00::/8 2.7
- Link-local unicast 1111111010 FE80::/10 2.5.6
- Site-local unicast 1111111011 FEC0::/10 2.5.6
- Global unicast (everything else)
-
- Anycast addresses are taken from the unicast address spaces (of any
- scope) and are not syntactically distinguishable from unicast
- addresses.
-
-
-
-
-Hinden & Deering Standards Track [Page 6]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- The general format of global unicast addresses is described in
- section 2.5.4. Some special-purpose subtypes of global unicast
- addresses which contain embedded IPv4 addresses (for the purposes of
- IPv4-IPv6 interoperation) are described in section 2.5.5.
-
- Future specifications may redefine one or more sub-ranges of the
- global unicast space for other purposes, but unless and until that
- happens, implementations must treat all addresses that do not start
- with any of the above-listed prefixes as global unicast addresses.
-
-2.5 Unicast Addresses
-
- IPv6 unicast addresses are aggregable with prefixes of arbitrary
- bit-length similar to IPv4 addresses under Classless Interdomain
- Routing.
-
- There are several types of unicast addresses in IPv6, in particular
- global unicast, site-local unicast, and link-local unicast. There
- are also some special-purpose subtypes of global unicast, such as
- IPv6 addresses with embedded IPv4 addresses or encoded NSAP
- addresses. Additional address types or subtypes can be defined in
- the future.
-
- IPv6 nodes may have considerable or little knowledge of the internal
- structure of the IPv6 address, depending on the role the node plays
- (for instance, host versus router). At a minimum, a node may
- consider that unicast addresses (including its own) have no internal
- structure:
-
- | 128 bits |
- +-----------------------------------------------------------------+
- | node address |
- +-----------------------------------------------------------------+
-
- A slightly sophisticated host (but still rather simple) may
- additionally be aware of subnet prefix(es) for the link(s) it is
- attached to, where different addresses may have different values for
- n:
-
- | n bits | 128-n bits |
- +------------------------------------------------+----------------+
- | subnet prefix | interface ID |
- +------------------------------------------------+----------------+
-
- Though a very simple router may have no knowledge of the internal
- structure of IPv6 unicast addresses, routers will more generally have
- knowledge of one or more of the hierarchical boundaries for the
- operation of routing protocols. The known boundaries will differ
-
-
-
-Hinden & Deering Standards Track [Page 7]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- from router to router, depending on what positions the router holds
- in the routing hierarchy.
-
-2.5.1 Interface Identifiers
-
- Interface identifiers in IPv6 unicast addresses are used to identify
- interfaces on a link. They are required to be unique within a subnet
- prefix. It is recommended that the same interface identifier not be
- assigned to different nodes on a link. They may also be unique over
- a broader scope. In some cases an interface's identifier will be
- derived directly from that interface's link-layer address. The same
- interface identifier may be used on multiple interfaces on a single
- node, as long as they are attached to different subnets.
-
- Note that the uniqueness of interface identifiers is independent of
- the uniqueness of IPv6 addresses. For example, a global unicast
- address may be created with a non-global scope interface identifier
- and a site-local address may be created with a global scope interface
- identifier.
-
- For all unicast addresses, except those that start with binary value
- 000, Interface IDs are required to be 64 bits long and to be
- constructed in Modified EUI-64 format.
-
- Modified EUI-64 format based Interface identifiers may have global
- scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
- IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
- global token is not available (e.g., serial links, tunnel end-points,
- etc.) or where global tokens are undesirable (e.g., temporary tokens
- for privacy [PRIV]).
-
- Modified EUI-64 format interface identifiers are formed by inverting
- the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
- forming the interface identifier from IEEE EUI-64 identifiers. In
- the resulting Modified EUI-64 format the "u" bit is set to one (1) to
- indicate global scope, and it is set to zero (0) to indicate local
- scope. The first three octets in binary of an IEEE EUI-64 identifier
- are as follows:
-
- 0 0 0 1 1 2
- |0 7 8 5 6 3|
- +----+----+----+----+----+----+
- |cccc|ccug|cccc|cccc|cccc|cccc|
- +----+----+----+----+----+----+
-
- written in Internet standard bit-order , where "u" is the
- universal/local bit, "g" is the individual/group bit, and "c" are the
- bits of the company_id. Appendix A: "Creating Modified EUI-64 format
-
-
-
-Hinden & Deering Standards Track [Page 8]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- Interface Identifiers" provides examples on the creation of Modified
- EUI-64 format based interface identifiers.
-
- The motivation for inverting the "u" bit when forming an interface
- identifier is to make it easy for system administrators to hand
- configure non-global identifiers when hardware tokens are not
- available. This is expected to be case for serial links, tunnel end-
- points, etc. The alternative would have been for these to be of the
- form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2,
- etc.
-
- The use of the universal/local bit in the Modified EUI-64 format
- identifier is to allow development of future technology that can take
- advantage of interface identifiers with global scope.
-
- The details of forming interface identifiers are defined in the
- appropriate "IPv6 over <link>" specification such as "IPv6 over
- Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-2.5.2 The Unspecified Address
-
- The address 0:0:0:0:0:0:0:0 is called the unspecified address. It
- must never be assigned to any node. It indicates the absence of an
- address. One example of its use is in the Source Address field of
- any IPv6 packets sent by an initializing host before it has learned
- its own address.
-
- The unspecified address must not be used as the destination address
- of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a
- source address of unspecified must never be forwarded by an IPv6
- router.
-
-2.5.3 The Loopback Address
-
- The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
- It may be used by a node to send an IPv6 packet to itself. It may
- never be assigned to any physical interface. It is treated as
- having link-local scope, and may be thought of as the link-local
- unicast address of a virtual interface (typically called "the
- loopback interface") to an imaginary link that goes nowhere.
-
- The loopback address must not be used as the source address in IPv6
- packets that are sent outside of a single node. An IPv6 packet with
- a destination address of loopback must never be sent outside of a
- single node and must never be forwarded by an IPv6 router. A packet
- received on an interface with destination address of loopback must be
- dropped.
-
-
-
-
-Hinden & Deering Standards Track [Page 9]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-2.5.4 Global Unicast Addresses
-
- The general format for IPv6 global unicast addresses is as follows:
-
- | n bits | m bits | 128-n-m bits |
- +------------------------+-----------+----------------------------+
- | global routing prefix | subnet ID | interface ID |
- +------------------------+-----------+----------------------------+
-
- where the global routing prefix is a (typically hierarchically-
- structured) value assigned to a site (a cluster of subnets/links),
- the subnet ID is an identifier of a link within the site, and the
- interface ID is as defined in section 2.5.1.
-
- All global unicast addresses other than those that start with binary
- 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
- described in section 2.5.1. Global unicast addresses that start with
- binary 000 have no such constraint on the size or structure of the
- interface ID field.
-
- Examples of global unicast addresses that start with binary 000 are
- the IPv6 address with embedded IPv4 addresses described in section
- 2.5.5 and the IPv6 address containing encoded NSAP addresses
- specified in [NSAP]. An example of global addresses starting with a
- binary value other than 000 (and therefore having a 64-bit interface
- ID field) can be found in [AGGR].
-
-2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
-
- The IPv6 transition mechanisms [TRAN] include a technique for hosts
- and routers to dynamically tunnel IPv6 packets over IPv4 routing
- infrastructure. IPv6 nodes that use this technique are assigned
- special IPv6 unicast addresses that carry a global IPv4 address in
- the low-order 32 bits. This type of address is termed an "IPv4-
- compatible IPv6 address" and has the format:
-
- | 80 bits | 16 | 32 bits |
- +--------------------------------------+--------------------------+
- |0000..............................0000|0000| IPv4 address |
- +--------------------------------------+----+---------------------+
-
- Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
- must be a globally-unique IPv4 unicast address.
-
- A second type of IPv6 address which holds an embedded IPv4 address is
- also defined. This address type is used to represent the addresses
- of IPv4 nodes as IPv6 addresses. This type of address is termed an
- "IPv4-mapped IPv6 address" and has the format:
-
-
-
-Hinden & Deering Standards Track [Page 10]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- | 80 bits | 16 | 32 bits |
- +--------------------------------------+--------------------------+
- |0000..............................0000|FFFF| IPv4 address |
- +--------------------------------------+----+---------------------+
-
-2.5.6 Local-Use IPv6 Unicast Addresses
-
- There are two types of local-use unicast addresses defined. These
- are Link-Local and Site-Local. The Link-Local is for use on a single
- link and the Site-Local is for use in a single site. Link-Local
- addresses have the following format:
-
- | 10 |
- | bits | 54 bits | 64 bits |
- +----------+-------------------------+----------------------------+
- |1111111010| 0 | interface ID |
- +----------+-------------------------+----------------------------+
-
- Link-Local addresses are designed to be used for addressing on a
- single link for purposes such as automatic address configuration,
- neighbor discovery, or when no routers are present.
-
- Routers must not forward any packets with link-local source or
- destination addresses to other links.
-
- Site-Local addresses have the following format:
-
- | 10 |
- | bits | 54 bits | 64 bits |
- +----------+-------------------------+----------------------------+
- |1111111011| subnet ID | interface ID |
- +----------+-------------------------+----------------------------+
-
- Site-local addresses are designed to be used for addressing inside of
- a site without the need for a global prefix. Although a subnet ID
- may be up to 54-bits long, it is expected that globally-connected
- sites will use the same subnet IDs for site-local and global
- prefixes.
-
- Routers must not forward any packets with site-local source or
- destination addresses outside of the site.
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 11]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-2.6 Anycast Addresses
-
- An IPv6 anycast address is an address that is assigned to more than
- one interface (typically belonging to different nodes), with the
- property that a packet sent to an anycast address is routed to the
- "nearest" interface having that address, according to the routing
- protocols' measure of distance.
-
- Anycast addresses are allocated from the unicast address space, using
- any of the defined unicast address formats. Thus, anycast addresses
- are syntactically indistinguishable from unicast addresses. When a
- unicast address is assigned to more than one interface, thus turning
- it into an anycast address, the nodes to which the address is
- assigned must be explicitly configured to know that it is an anycast
- address.
-
- For any assigned anycast address, there is a longest prefix P of that
- address that identifies the topological region in which all
- interfaces belonging to that anycast address reside. Within the
- region identified by P, the anycast address must be maintained as a
- separate entry in the routing system (commonly referred to as a "host
- route"); outside the region identified by P, the anycast address may
- be aggregated into the routing entry for prefix P.
-
- Note that in the worst case, the prefix P of an anycast set may be
- the null prefix, i.e., the members of the set may have no topological
- locality. In that case, the anycast address must be maintained as a
- separate routing entry throughout the entire internet, which presents
- a severe scaling limit on how many such "global" anycast sets may be
- supported. Therefore, it is expected that support for global anycast
- sets may be unavailable or very restricted.
-
- One expected use of anycast addresses is to identify the set of
- routers belonging to an organization providing internet service.
- Such addresses could be used as intermediate addresses in an IPv6
- Routing header, to cause a packet to be delivered via a particular
- service provider or sequence of service providers.
-
- Some other possible uses are to identify the set of routers attached
- to a particular subnet, or the set of routers providing entry into a
- particular routing domain.
-
- There is little experience with widespread, arbitrary use of internet
- anycast addresses, and some known complications and hazards when
- using them in their full generality [ANYCST]. Until more experience
- has been gained and solutions are specified, the following
- restrictions are imposed on IPv6 anycast addresses:
-
-
-
-
-Hinden & Deering Standards Track [Page 12]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- o An anycast address must not be used as the source address of an
- IPv6 packet.
-
- o An anycast address must not be assigned to an IPv6 host, that is,
- it may be assigned to an IPv6 router only.
-
-2.6.1 Required Anycast Address
-
- The Subnet-Router anycast address is predefined. Its format is as
- follows:
-
- | n bits | 128-n bits |
- +------------------------------------------------+----------------+
- | subnet prefix | 00000000000000 |
- +------------------------------------------------+----------------+
-
- The "subnet prefix" in an anycast address is the prefix which
- identifies a specific link. This anycast address is syntactically
- the same as a unicast address for an interface on the link with the
- interface identifier set to zero.
-
- Packets sent to the Subnet-Router anycast address will be delivered
- to one router on the subnet. All routers are required to support the
- Subnet-Router anycast addresses for the subnets to which they have
- interfaces.
-
- The subnet-router anycast address is intended to be used for
- applications where a node needs to communicate with any one of the
- set of routers.
-
-2.7 Multicast Addresses
-
- An IPv6 multicast address is an identifier for a group of interfaces
- (typically on different nodes). An interface may belong to any
- number of multicast groups. Multicast addresses have the following
- format:
-
- | 8 | 4 | 4 | 112 bits |
- +------ -+----+----+---------------------------------------------+
- |11111111|flgs|scop| group ID |
- +--------+----+----+---------------------------------------------+
-
- binary 11111111 at the start of the address identifies the
- address as being a multicast address.
-
- +-+-+-+-+
- flgs is a set of 4 flags: |0|0|0|T|
- +-+-+-+-+
-
-
-
-Hinden & Deering Standards Track [Page 13]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- The high-order 3 flags are reserved, and must be initialized
- to 0.
-
- T = 0 indicates a permanently-assigned ("well-known")
- multicast address, assigned by the Internet Assigned Number
- Authority (IANA).
-
- T = 1 indicates a non-permanently-assigned ("transient")
- multicast address.
-
- scop is a 4-bit multicast scope value used to limit the scope
- of the multicast group. The values are:
-
- 0 reserved
- 1 interface-local scope
- 2 link-local scope
- 3 reserved
- 4 admin-local scope
- 5 site-local scope
- 6 (unassigned)
- 7 (unassigned)
- 8 organization-local scope
- 9 (unassigned)
- A (unassigned)
- B (unassigned)
- C (unassigned)
- D (unassigned)
- E global scope
- F reserved
-
- interface-local scope spans only a single interface on a
- node, and is useful only for loopback transmission of
- multicast.
-
- link-local and site-local multicast scopes span the same
- topological regions as the corresponding unicast scopes.
-
- admin-local scope is the smallest scope that must be
- administratively configured, i.e., not automatically derived
- from physical connectivity or other, non- multicast-related
- configuration.
-
- organization-local scope is intended to span multiple sites
- belonging to a single organization.
-
- scopes labeled "(unassigned)" are available for
- administrators to define additional multicast regions.
-
-
-
-
-Hinden & Deering Standards Track [Page 14]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- group ID identifies the multicast group, either permanent or
- transient, within the given scope.
-
- The "meaning" of a permanently-assigned multicast address is
- independent of the scope value. For example, if the "NTP servers
- group" is assigned a permanent multicast address with a group ID of
- 101 (hex), then:
-
- FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
- (i.e., the same node) as the sender.
-
- FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
- sender.
-
- FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
- sender.
-
- FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
-
- Non-permanently-assigned multicast addresses are meaningful only
- within a given scope. For example, a group identified by the non-
- permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
- site bears no relationship to a group using the same address at a
- different site, nor to a non-permanent group using the same group ID
- with different scope, nor to a permanent group with the same group
- ID.
-
- Multicast addresses must not be used as source addresses in IPv6
- packets or appear in any Routing header.
-
- Routers must not forward any multicast packets beyond of the scope
- indicated by the scop field in the destination multicast address.
-
- Nodes must not originate a packet to a multicast address whose scop
- field contains the reserved value 0; if such a packet is received, it
- must be silently dropped. Nodes should not originate a packet to a
- multicast address whose scop field contains the reserved value F; if
- such a packet is sent or received, it must be treated the same as
- packets destined to a global (scop E) multicast address.
-
-2.7.1 Pre-Defined Multicast Addresses
-
- The following well-known multicast addresses are pre-defined. The
- group ID's defined in this section are defined for explicit scope
- values.
-
- Use of these group IDs for any other scope values, with the T flag
- equal to 0, is not allowed.
-
-
-
-Hinden & Deering Standards Track [Page 15]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0
- FF01:0:0:0:0:0:0:0
- FF02:0:0:0:0:0:0:0
- FF03:0:0:0:0:0:0:0
- FF04:0:0:0:0:0:0:0
- FF05:0:0:0:0:0:0:0
- FF06:0:0:0:0:0:0:0
- FF07:0:0:0:0:0:0:0
- FF08:0:0:0:0:0:0:0
- FF09:0:0:0:0:0:0:0
- FF0A:0:0:0:0:0:0:0
- FF0B:0:0:0:0:0:0:0
- FF0C:0:0:0:0:0:0:0
- FF0D:0:0:0:0:0:0:0
- FF0E:0:0:0:0:0:0:0
- FF0F:0:0:0:0:0:0:0
-
- The above multicast addresses are reserved and shall never be
- assigned to any multicast group.
-
- All Nodes Addresses: FF01:0:0:0:0:0:0:1
- FF02:0:0:0:0:0:0:1
-
- The above multicast addresses identify the group of all IPv6 nodes,
- within scope 1 (interface-local) or 2 (link-local).
-
- All Routers Addresses: FF01:0:0:0:0:0:0:2
- FF02:0:0:0:0:0:0:2
- FF05:0:0:0:0:0:0:2
-
- The above multicast addresses identify the group of all IPv6 routers,
- within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
-
- Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX
-
- Solicited-node multicast address are computed as a function of a
- node's unicast and anycast addresses. A solicited-node multicast
- address is formed by taking the low-order 24 bits of an address
- (unicast or anycast) and appending those bits to the prefix
- FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
- range
-
- FF02:0:0:0:0:1:FF00:0000
-
- to
-
- FF02:0:0:0:0:1:FFFF:FFFF
-
-
-
-
-Hinden & Deering Standards Track [Page 16]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- For example, the solicited node multicast address corresponding to
- the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6
- addresses that differ only in the high-order bits, e.g., due to
- multiple high-order prefixes associated with different aggregations,
- will map to the same solicited-node address thereby, reducing the
- number of multicast addresses a node must join.
-
- A node is required to compute and join (on the appropriate interface)
- the associated Solicited-Node multicast addresses for every unicast
- and anycast address it is assigned.
-
-2.8 A Node's Required Addresses
-
- A host is required to recognize the following addresses as
- identifying itself:
-
- o Its required Link-Local Address for each interface.
- o Any additional Unicast and Anycast Addresses that have been
- configured for the node's interfaces (manually or
- automatically).
- o The loopback address.
- o The All-Nodes Multicast Addresses defined in section 2.7.1.
- o The Solicited-Node Multicast Address for each of its unicast
- and anycast addresses.
- o Multicast Addresses of all other groups to which the node
- belongs.
-
- A router is required to recognize all addresses that a host is
- required to recognize, plus the following addresses as identifying
- itself:
-
- o The Subnet-Router Anycast Addresses for all interfaces for
- which it is configured to act as a router.
- o All other Anycast Addresses with which the router has been
- configured.
- o The All-Routers Multicast Addresses defined in section 2.7.1.
-
-3. Security Considerations
-
- IPv6 addressing documents do not have any direct impact on Internet
- infrastructure security. Authentication of IPv6 packets is defined
- in [AUTH].
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 17]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-4. IANA Considerations
-
- The table and notes at http://www.isi.edu/in-
- notes/iana/assignments/ipv6-address-space.txt should be replaced with
- the following:
-
- INTERNET PROTOCOL VERSION 6 ADDRESS SPACE
-
- The initial assignment of IPv6 address space is as follows:
-
- Allocation Prefix Fraction of
- (binary) Address Space
- ----------------------------------- -------- -------------
- Unassigned (see Note 1 below) 0000 0000 1/256
- Unassigned 0000 0001 1/256
- Reserved for NSAP Allocation 0000 001 1/128 [RFC1888]
- Unassigned 0000 01 1/64
- Unassigned 0000 1 1/32
- Unassigned 0001 1/16
- Global Unicast 001 1/8 [RFC2374]
- Unassigned 010 1/8
- Unassigned 011 1/8
- Unassigned 100 1/8
- Unassigned 101 1/8
- Unassigned 110 1/8
- Unassigned 1110 1/16
- Unassigned 1111 0 1/32
- Unassigned 1111 10 1/64
- Unassigned 1111 110 1/128
- Unassigned 1111 1110 0 1/512
- Link-Local Unicast Addresses 1111 1110 10 1/1024
- Site-Local Unicast Addresses 1111 1110 11 1/1024
- Multicast Addresses 1111 1111 1/256
-
- Notes:
-
- 1. The "unspecified address", the "loopback address", and the IPv6
- Addresses with Embedded IPv4 Addresses are assigned out of the
- 0000 0000 binary prefix space.
-
- 2. For now, IANA should limit its allocation of IPv6 unicast address
- space to the range of addresses that start with binary value 001.
- The rest of the global unicast address space (approximately 85% of
- the IPv6 address space) is reserved for future definition and use,
- and is not to be assigned by IANA at this time.
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 18]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-5. References
-
-5.1 Normative References
-
- [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9 , RFC 2026, October 1996.
-
-5.2 Informative References
-
- [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
- Service", RFC 1546, November 1993.
-
- [AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
- 2402, November 1998.
-
- [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable
- Global Unicast Address Format", RFC 2374, July 1998.
-
- [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
- Inter-Domain Routing (CIDR): An Address Assignment and
- Aggregation Strategy", RFC 1519, September 1993.
-
- [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
- Networks", RFC 2464, December 1998.
-
- [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
- Registration Authority",
- http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
- March 1997.
-
- [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
- Networks", RFC 2467, December 1998.
-
- [MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address
- Assignments", RFC 2375, July 1998.
-
- [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
- and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
-
- [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless
- Address Autoconfiguration in IPv6", RFC 3041, January 2001.
-
- [TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of
- IPv6 Packets over Token Ring Networks", RFC 2470, December
- 1998.
-
-
-
-Hinden & Deering Standards Track [Page 19]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- [TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
- IPv6 Hosts and Routers", RFC 2893, August 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 20]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
-
- Depending on the characteristics of a specific link or node there are
- a number of approaches for creating Modified EUI-64 format interface
- identifiers. This appendix describes some of these approaches.
-
-Links or Nodes with IEEE EUI-64 Identifiers
-
- The only change needed to transform an IEEE EUI-64 identifier to an
- interface identifier is to invert the "u" (universal/local) bit. For
- example, a globally unique IEEE EUI-64 identifier of the form:
-
- |0 1|1 3|3 4|4 6|
- |0 5|6 1|2 7|8 3|
- +----------------+----------------+----------------+----------------+
- |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
- +----------------+----------------+----------------+----------------+
-
- where "c" are the bits of the assigned company_id, "0" is the value
- of the universal/local bit to indicate global scope, "g" is
- individual/group bit, and "m" are the bits of the manufacturer-
- selected extension identifier. The IPv6 interface identifier would
- be of the form:
-
- |0 1|1 3|3 4|4 6|
- |0 5|6 1|2 7|8 3|
- +----------------+----------------+----------------+----------------+
- |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
- +----------------+----------------+----------------+----------------+
-
- The only change is inverting the value of the universal/local bit.
-
-Links or Nodes with IEEE 802 48 bit MAC's
-
- [EUI64] defines a method to create a IEEE EUI-64 identifier from an
- IEEE 48bit MAC identifier. This is to insert two octets, with
- hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC
- (between the company_id and vendor supplied id). For example, the 48
- bit IEEE MAC with global scope:
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 21]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- |0 1|1 3|3 4|
- |0 5|6 1|2 7|
- +----------------+----------------+----------------+
- |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
- +----------------+----------------+----------------+
-
- where "c" are the bits of the assigned company_id, "0" is the value
- of the universal/local bit to indicate global scope, "g" is
- individual/group bit, and "m" are the bits of the manufacturer-
- selected extension identifier. The interface identifier would be of
- the form:
-
- |0 1|1 3|3 4|4 6|
- |0 5|6 1|2 7|8 3|
- +----------------+----------------+----------------+----------------+
- |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
- +----------------+----------------+----------------+----------------+
-
- When IEEE 802 48bit MAC addresses are available (on an interface or a
- node), an implementation may use them to create interface identifiers
- due to their availability and uniqueness properties.
-
-Links with Other Kinds of Identifiers
-
- There are a number of types of links that have link-layer interface
- identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs. Examples
- include LocalTalk and Arcnet. The method to create an Modified EUI-
- 64 format identifier is to take the link identifier (e.g., the
- LocalTalk 8 bit node identifier) and zero fill it to the left. For
- example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F
- results in the following interface identifier:
-
- |0 1|1 3|3 4|4 6|
- |0 5|6 1|2 7|8 3|
- +----------------+----------------+----------------+----------------+
- |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
- +----------------+----------------+----------------+----------------+
-
- Note that this results in the universal/local bit set to "0" to
- indicate local scope.
-
-Links without Identifiers
-
- There are a number of links that do not have any type of built-in
- identifier. The most common of these are serial links and configured
- tunnels. Interface identifiers must be chosen that are unique within
- a subnet-prefix.
-
-
-
-
-Hinden & Deering Standards Track [Page 22]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- When no built-in identifier is available on a link the preferred
- approach is to use a global interface identifier from another
- interface or one which is assigned to the node itself. When using
- this approach no other interface connecting the same node to the same
- subnet-prefix may use the same identifier.
-
- If there is no global interface identifier available for use on the
- link the implementation needs to create a local-scope interface
- identifier. The only requirement is that it be unique within a
- subnet prefix. There are many possible approaches to select a
- subnet-prefix-unique interface identifier. These include:
-
- Manual Configuration
- Node Serial Number
- Other node-specific token
-
- The subnet-prefix-unique interface identifier should be generated in
- a manner that it does not change after a reboot of a node or if
- interfaces are added or deleted from the node.
-
- The selection of the appropriate algorithm is link and implementation
- dependent. The details on forming interface identifiers are defined
- in the appropriate "IPv6 over <link>" specification. It is strongly
- recommended that a collision detection algorithm be implemented as
- part of any automatic algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 23]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-APPENDIX B: Changes from RFC-2373
-
- The following changes were made from RFC-2373 "IP Version 6
- Addressing Architecture":
-
- - Clarified text in section 2.2 to allow "::" to represent one or
- more groups of 16 bits of zeros.
- - Changed uniqueness requirement of Interface Identifiers from
- unique on a link to unique within a subnet prefix. Also added a
- recommendation that the same interface identifier not be assigned
- to different machines on a link.
- - Change site-local format to make the subnet ID field 54-bit long
- and remove the 38-bit zero's field.
- - Added description of multicast scop values and rules to handle the
- reserved scop value 0.
- - Revised sections 2.4 and 2.5.6 to simplify and clarify how
- different address types are identified. This was done to insure
- that implementations do not build in any knowledge about global
- unicast format prefixes. Changes include:
- o Removed Format Prefix (FP) terminology
- o Revised list of address types to only include exceptions to
- global unicast and a singe entry that identifies everything
- else as Global Unicast.
- o Removed list of defined prefix exceptions from section 2.5.6
- as it is now the main part of section 2.4.
- - Clarified text relating to EUI-64 identifiers to distinguish
- between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-
- 64 identifiers.
- - Combined the sections on the Global Unicast Addresses and NSAP
- Addresses into a single section on Global Unicast Addresses,
- generalized the Global Unicast format, and cited [AGGR] and [NSAP]
- as examples.
- - Reordered sections 2.5.4 and 2.5.5.
- - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
- because this is being redefined elsewhere.
- - Added an IANA considerations section that updates the IANA IPv6
- address allocations and documents the NSAP and AGGR allocations.
- - Added clarification that the "IPv4-compatible IPv6 address" must
- use global IPv4 unicast addresses.
- - Divided references in to normative and non-normative sections.
- - Added reference to [PRIV] in section 2.5.1
- - Added clarification that routers must not forward multicast
- packets outside of the scope indicated in the multicast address.
- - Added clarification that routers must not forward packets with
- source address of the unspecified address.
- - Added clarification that routers must drop packets received on an
- interface with destination address of loopback.
- - Clarified the definition of IPv4-mapped addresses.
-
-
-
-Hinden & Deering Standards Track [Page 24]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
- - Removed the ABNF Description of Text Representations Appendix.
- - Removed the address block reserved for IPX addresses.
- - Multicast scope changes:
- o Changed name of scope value 1 from "node-local" to
- "interface-local"
- o Defined scope value 4 as "admin-local"
- - Corrected reference to RFC1933 and updated references.
- - Many small changes to clarify and make the text more consistent.
-
-Authors' Addresses
-
- Robert M. Hinden
- Nokia
- 313 Fairchild Drive
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 625-2004
- EMail: hinden@iprg.nokia.com
-
-
- Stephen E. Deering
- Cisco Systems, Inc.
- 170 West Tasman Drive
- San Jose, CA 95134-1706
- USA
-
- Phone: +1 408 527-8213
- EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 25]
-
-RFC 3513 IPv6 Addressing Architecture April 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering Standards Track [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc3596.txt b/contrib/bind9/doc/rfc/rfc3596.txt
deleted file mode 100644
index f65690c8875a8..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3596.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Thomson
-Request for Comments: 3596 Cisco
-Obsoletes: 3152, 1886 C. Huitema
-Category: Standards Track Microsoft
- V. Ksinant
- 6WIND
- M. Souissi
- AFNIC
- October 2003
-
-
- DNS Extensions to Support IP Version 6
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- This document defines the changes that need to be made to the Domain
- Name System (DNS) to support hosts running IP version 6 (IPv6). The
- changes include a resource record type to store an IPv6 address, a
- domain to support lookups based on an IPv6 address, and updated
- definitions of existing query types that return Internet addresses as
- part of additional section processing. The extensions are designed
- to be compatible with existing applications and, in particular, DNS
- implementations themselves.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. New resource record definition and domain. . . . . . . . . . . 2
- 2.1. AAAA record type . . . . . . . . . . . . . . . . . . . . 3
- 2.2. AAAA data format . . . . . . . . . . . . . . . . . . . . 3
- 2.3. AAAA query . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.4. Textual format of AAAA records . . . . . . . . . . . . . 3
- 2.5. IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . . 3
- 3. Modifications to existing query types. . . . . . . . . . . . . 4
- 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4
- 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 4
-
-
-
-Thomson, et al. Standards Track [Page 1]
-
-RFC 3596 DNS Extensions to Support IPv6 October 2003
-
-
- 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 4
- Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5
- Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . . 6
- Normative References . . . . . . . . . . . . . . . . . . . . . . . 6
- Informative References . . . . . . . . . . . . . . . . . . . . . . 6
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
-
-1. Introduction
-
- Current support for the storage of Internet addresses in the Domain
- Name System (DNS) [1,2] cannot easily be extended to support IPv6
- addresses [3] since applications assume that address queries return
- 32-bit IPv4 addresses only.
-
- To support the storage of IPv6 addresses in the DNS, this document
- defines the following extensions:
-
- o A resource record type is defined to map a domain name to an
- IPv6 address.
-
- o A domain is defined to support lookups based on address.
-
- o Existing queries that perform additional section processing to
- locate IPv4 addresses are redefined to perform additional
- section processing on both IPv4 and IPv6 addresses.
-
- The changes are designed to be compatible with existing software.
- The existing support for IPv4 addresses is retained. Transition
- issues related to the co-existence of both IPv4 and IPv6 addresses in
- the DNS are discussed in [4].
-
- 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.
-
- This document combines RFC 1886 [5] and changes to RFC 1886 made by
- RFC 3152 [6], obsoleting both. Changes mainly consist in replacing
- the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
-
-2. New resource record definition and domain
-
- A record type is defined to store a host's IPv6 address. A host that
- has more than one IPv6 address must have more than one such record.
-
-
-
-
-
-
-
-Thomson, et al. Standards Track [Page 2]
-
-RFC 3596 DNS Extensions to Support IPv6 October 2003
-
-
-2.1 AAAA record type
-
- The AAAA resource record type is a record specific to the Internet
- class that stores a single IPv6 address.
-
- The IANA assigned value of the type is 28 (decimal).
-
-2.2 AAAA data format
-
- A 128 bit IPv6 address is encoded in the data portion of an AAAA
- resource record in network byte order (high-order byte first).
-
-2.3 AAAA query
-
- An AAAA query for a specified domain name in the Internet class
- returns all associated AAAA resource records in the answer section of
- a response.
-
- A type AAAA query does not trigger additional section processing.
-
-2.4 Textual format of AAAA records
-
- The textual representation of the data portion of the AAAA resource
- record used in a master database file is the textual representation
- of an IPv6 address as defined in [3].
-
-2.5 IP6.ARPA Domain
-
- A special domain is defined to look up a record given an IPv6
- address. The intent of this domain is to provide a way of mapping an
- IPv6 address to a host name, although it may be used for other
- purposes as well. The domain is rooted at IP6.ARPA.
-
- An IPv6 address is represented as a name in the IP6.ARPA domain by a
- sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
- The sequence of nibbles is encoded in reverse order, i.e., the
- low-order nibble is encoded first, followed by the next low-order
- nibble and so on. Each nibble is represented by a hexadecimal digit.
- For example, the reverse lookup domain name corresponding to the
- address
-
- 4321:0:1:2:3:4:567:89ab
-
- would be
-
- b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
- ARPA.
-
-
-
-
-Thomson, et al. Standards Track [Page 3]
-
-RFC 3596 DNS Extensions to Support IPv6 October 2003
-
-
-3. Modifications to existing query types
-
- All existing query types that perform type A additional section
- processing, i.e., name server (NS), location of services (SRV) and
- mail exchange (MX) query types, must be redefined to perform both
- type A and type AAAA additional section processing. These
- definitions mean that a name server must add any relevant IPv4
- addresses and any relevant IPv6 addresses available locally to the
- additional section of a response when processing any one of the above
- queries.
-
-4. Security Considerations
-
- Any information obtained from the DNS must be regarded as unsafe
- unless techniques specified in [7] or [8] are used. The definitions
- of the AAAA record type and of the IP6.ARPA domain do not change the
- model for use of these techniques.
-
- So, this specification is not believed to cause any new security
- problems, nor to solve any existing ones.
-
-5. IANA Considerations
-
- There are no IANA assignments to be performed.
-
-6. 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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-Thomson, et al. Standards Track [Page 4]
-
-RFC 3596 DNS Extensions to Support IPv6 October 2003
-
-
-Acknowledgments
-
- Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
- Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin
- (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic
- Roudaut (IRISA) and G6 group for their help during the RFC 1886
- Interop tests sessions.
-
- Many thanks to Alain Durand and Olafur Gudmundsson for their support.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson, et al. Standards Track [Page 5]
-
-RFC 3596 DNS Extensions to Support IPv6 October 2003
-
-
-Appendix A: Changes from RFC 1886
-
- The following changes were made from RFC 1886 "DNS Extensions to
- support IP version 6":
-
- - Replaced the "IP6.INT" domain by "IP6.ARPA".
- - Mentioned SRV query types in section 3 "MODIFICATIONS TO
- EXISTING QUERY TYPES"
- - Added security considerations.
- - Updated references :
- * From RFC 1884 to RFC 3513 (IP Version 6 Addressing
- Architecture).
- * From "work in progress" to RFC 2893 (Transition Mechanisms for
- IPv6 Hosts and Routers).
- * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
- - Updated document abstract
- - Added table of contents
- - Added full copyright statement
- - Added IANA considerations section
- - Added Intellectual Property Statement
-
-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] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
- Addressing Architecture", RFC 3513, April 2003.
-
-Informative References
-
- [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
- Hosts and Routers", RFC 2893, August 2000.
-
- [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP
- version 6", RFC 1886, December 1995.
-
- [6] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
- 2001.
-
- [7] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999
-
-
-
-
-
-
-Thomson, et al. Standards Track [Page 6]
-
-RFC 3596 DNS Extensions to Support IPv6 October 2003
-
-
- [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
-Authors' Addresses
-
- Susan Thomson
- Cisco Systems
- 499 Thornall Street, 8th floor
- Edison, NJ 08837
-
- Phone: +1 732-635-3086
- EMail: sethomso@cisco.com
-
-
- Christian Huitema
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
-
- EMail: huitema@microsoft.com
-
-
- Vladimir Ksinant
- 6WIND S.A.
- Immeuble Central Gare - Bat.C
- 1, place Charles de Gaulle
- 78180, Montigny-Le-Bretonneux - France
-
- Phone: +33 1 39 30 92 36
- EMail: vladimir.ksinant@6wind.com
-
-
- Mohsen Souissi
- AFNIC
- Immeuble International
- 2, rue Stephenson,
- 78181, Saint-Quentin en Yvelines Cedex - France
-
- Phone: +33 1 39 30 83 40
- EMail: Mohsen.Souissi@nic.fr
-
-
-
-
-
-
-
-
-
-
-Thomson, et al. Standards Track [Page 7]
-
-RFC 3596 DNS Extensions to Support IPv6 October 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson, et al. Standards Track [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3597.txt b/contrib/bind9/doc/rfc/rfc3597.txt
deleted file mode 100644
index 19e9a55053d12..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3597.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Gustafsson
-Request for Comments: 3597 Nominum Inc.
-Category: Standards Track September 2003
-
-
- Handling of Unknown DNS Resource Record (RR) Types
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- Extending the Domain Name System (DNS) with new Resource Record (RR)
- types currently requires changes to name server software. This
- document specifies the changes necessary to allow future DNS
- implementations to handle new RR types transparently.
-
-1. Introduction
-
- The DNS is designed to be extensible to support new services through
- the introduction of new resource record (RR) types. In practice,
- deploying a new RR type currently requires changes to the name server
- software not only at the authoritative DNS server that is providing
- the new information and the client making use of it, but also at all
- slave servers for the zone containing it, and in some cases also at
- caching name servers and forwarders used by the client.
-
- Because the deployment of new server software is slow and expensive,
- the potential of the DNS in supporting new services has never been
- fully realized. This memo proposes changes to name servers and to
- procedures for defining new RR types aimed at simplifying the future
- deployment of new RR types.
-
- 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].
-
-
-
-
-
-
-Gustafsson Standards Track [Page 1]
-
-RFC 3597 Handling of Unknown DNS RR Types September 2003
-
-
-2. Definition
-
- An "RR of unknown type" is an RR whose RDATA format is not known to
- the DNS implementation at hand, and whose type is not an assigned
- QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
- within the range reserved in that section for assignment only to
- QTYPEs and Meta-TYPEs. Such an RR cannot be converted to a type-
- specific text format, compressed, or otherwise handled in a type-
- specific way.
-
- In the case of a type whose RDATA format is class specific, an RR is
- considered to be of unknown type when the RDATA format for that
- combination of type and class is not known.
-
-3. Transparency
-
- To enable new RR types to be deployed without server changes, name
- servers and resolvers MUST handle RRs of unknown type transparently.
- That is, they must treat the RDATA section of such RRs as
- unstructured binary data, storing and transmitting it without change
- [RFC1123].
-
- To ensure the correct operation of equality comparison (section 6)
- and of the DNSSEC canonical form (section 7) when an RR type is known
- to some but not all of the servers involved, servers MUST also
- exactly preserve the RDATA of RRs of known type, except for changes
- due to compression or decompression where allowed by section 4 of
- this memo. In particular, the character case of domain names that
- are not subject to compression MUST be preserved.
-
-4. Domain Name Compression
-
- RRs containing compression pointers in the RDATA part cannot be
- treated transparently, as the compression pointers are only
- meaningful within the context of a DNS message. Transparently
- copying the RDATA into a new DNS message would cause the compression
- pointers to point at the corresponding location in the new message,
- which now contains unrelated data. This would cause the compressed
- name to be corrupted.
-
- To avoid such corruption, servers MUST NOT compress domain names
- embedded in the RDATA of types that are class-specific or not well-
- known. This requirement was stated in [RFC1123] without defining the
- term "well-known"; it is hereby specified that only the RR types
- defined in [RFC1035] are to be considered "well-known".
-
-
-
-
-
-
-Gustafsson Standards Track [Page 2]
-
-RFC 3597 Handling of Unknown DNS RR Types September 2003
-
-
- The specifications of a few existing RR types have explicitly allowed
- compression contrary to this specification: [RFC2163] specified that
- compression applies to the PX RR, and [RFC2535] allowed compression
- in SIG RRs and NXT RRs records. Since this specification disallows
- compression in these cases, it is an update to [RFC2163] (section 4)
- and [RFC2535] (sections 4.1.7 and 5.2).
-
- Receiving servers MUST decompress domain names in RRs of well-known
- type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
- NXT, NAPTR, and SRV (although the current specification of the SRV RR
- in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
- servers following that earlier specification are still in use).
-
- Future specifications for new RR types that contain domain names
- within their RDATA MUST NOT allow the use of name compression for
- those names, and SHOULD explicitly state that the embedded domain
- names MUST NOT be compressed.
-
- As noted in [RFC1123], the owner name of an RR is always eligible for
- compression.
-
-5. Text Representation
-
- In the "type" field of a master file line, an unknown RR type is
- represented by the word "TYPE" immediately followed by the decimal RR
- type number, with no intervening whitespace. In the "class" field,
- an unknown class is similarly represented as the word "CLASS"
- immediately followed by the decimal class number.
-
- This convention allows types and classes to be distinguished from
- each other and from TTL values, allowing the "[<TTL>] [<class>]
- <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
- [RFC1035] to both be unambiguously parsed.
-
- The RDATA section of an RR of unknown type is represented as a
- sequence of white space separated words as follows:
-
- The special token \# (a backslash immediately followed by a hash
- sign), which identifies the RDATA as having the generic encoding
- defined herein rather than a traditional type-specific encoding.
-
- An unsigned decimal integer specifying the RDATA length in octets.
-
- Zero or more words of hexadecimal data encoding the actual RDATA
- field, each containing an even number of hexadecimal digits.
-
- If the RDATA is of zero length, the text representation contains only
- the \# token and the single zero representing the length.
-
-
-
-Gustafsson Standards Track [Page 3]
-
-RFC 3597 Handling of Unknown DNS RR Types September 2003
-
-
- An implementation MAY also choose to represent some RRs of known type
- using the above generic representations for the type, class and/or
- RDATA, which carries the benefit of making the resulting master file
- portable to servers where these types are unknown. Using the generic
- representation for the RDATA of an RR of known type can also be
- useful in the case of an RR type where the text format varies
- depending on a version, protocol, or similar field (or several)
- embedded in the RDATA when such a field has a value for which no text
- format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
- 0.
-
- Even though an RR of known type represented in the \# format is
- effectively treated as an unknown type for the purpose of parsing the
- RDATA text representation, all further processing by the server MUST
- treat it as a known type and take into account any applicable type-
- specific rules regarding compression, canonicalization, etc.
-
- The following are examples of RRs represented in this manner,
- illustrating various combinations of generic and type-specific
- encodings for the different fields of the master file format:
-
- a.example. CLASS32 TYPE731 \# 6 abcd (
- ef 01 23 45 )
- b.example. HS TYPE62347 \# 0
- e.example. IN A \# 4 0A000001
- e.example. CLASS1 TYPE1 10.0.0.2
-
-6. Equality Comparison
-
- Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
- to be compared for equality. Two RRs of the same unknown type are
- considered equal when their RDATA is bitwise equal. To ensure that
- the outcome of the comparison is identical whether the RR is known to
- the server or not, specifications for new RR types MUST NOT specify
- type-specific comparison rules.
-
- This implies that embedded domain names, being included in the
- overall bitwise comparison, are compared in a case-sensitive manner.
-
- As a result, when a new RR type contains one or more embedded domain
- names, it is possible to have multiple RRs owned by the same name
- that differ only in the character case of the embedded domain
- name(s). This is similar to the existing possibility of multiple TXT
- records differing only in character case, and not expected to cause
- any problems in practice.
-
-
-
-
-
-
-Gustafsson Standards Track [Page 4]
-
-RFC 3597 Handling of Unknown DNS RR Types September 2003
-
-
-7. DNSSEC Canonical Form and Ordering
-
- DNSSEC defines a canonical form and ordering for RRs [RFC2535]
- (section 8.1). In that canonical form, domain names embedded in the
- RDATA are converted to lower case.
-
- The downcasing is necessary to ensure the correctness of DNSSEC
- signatures when case distinctions in domain names are lost due to
- compression, but since it requires knowledge of the presence and
- position of embedded domain names, it cannot be applied to unknown
- types.
-
- To ensure continued consistency of the canonical form of RR types
- where compression is allowed, and for continued interoperability with
- existing implementations that already implement the [RFC2535]
- canonical form and apply it to their known RR types, the canonical
- form remains unchanged for all RR types whose whose initial
- publication as an RFC was prior to the initial publication of this
- specification as an RFC (RFC 3597).
-
- As a courtesy to implementors, it is hereby noted that the complete
- set of such previously published RR types that contain embedded
- domain names, and whose DNSSEC canonical form therefore involves
- downcasing according to the DNS rules for character comparisons,
- consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
- HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
- DNAME, and A6.
-
- This document specifies that for all other RR types (whether treated
- as unknown types or treated as known types according to an RR type
- definition RFC more recent than RFC 3597), the canonical form is such
- that no downcasing of embedded domain names takes place, and
- otherwise identical to the canonical form specified in [RFC2535]
- section 8.1.
-
- Note that the owner name is always set to lower case according to the
- DNS rules for character comparisons, regardless of the RR type.
-
- The DNSSEC canonical RR ordering is as specified in [RFC2535] section
- 8.3, where the octet sequence is the canonical form as revised by
- this specification.
-
-8. Additional Section Processing
-
- Unknown RR types cause no additional section processing. Future RR
- type specifications MAY specify type-specific additional section
- processing rules, but any such processing MUST be optional as it can
- only be performed by servers for which the RR type in case is known.
-
-
-
-Gustafsson Standards Track [Page 5]
-
-RFC 3597 Handling of Unknown DNS RR Types September 2003
-
-
-9. IANA Considerations
-
- This document does not require any IANA actions.
-
-10. Security Considerations
-
- This specification is not believed to cause any new security
- problems, nor to solve any existing ones.
-
-11. Normative References
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specifications", STD 13, RFC 1035, November 1987.
-
- [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts --
- Application and Support", STD 3, RFC 1123, October 1989.
-
- [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.
-
- [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute
- MIXER Conformant Global Address Mapping (MCGAM)", RFC
- 2163, January 1998.
-
- [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning,
- "Domain Name System (DNS) IANA Considerations", BCP 42,
- RFC 2929, September 2000.
-
-12. Informative References
-
- [RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
- Means for Expressing Location Information in the Domain
- Name System", RFC 1876, January 1996.
-
- [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
- the location of services (DNS SRV)", RFC 2052, October
- 1996.
-
- [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
-
-
-
-Gustafsson Standards Track [Page 6]
-
-RFC 3597 Handling of Unknown DNS RR Types September 2003
-
-
- [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
-13. 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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-14. Author's Address
-
- Andreas Gustafsson
- Nominum, Inc.
- 2385 Bay Rd
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
- EMail: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gustafsson Standards Track [Page 7]
-
-RFC 3597 Handling of Unknown DNS RR Types September 2003
-
-
-15. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gustafsson Standards Track [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3645.txt b/contrib/bind9/doc/rfc/rfc3645.txt
deleted file mode 100644
index 61266786a547b..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3645.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Kwan
-Request for Comments: 3645 P. Garg
-Updates: 2845 J. Gilroy
-Category: Standards Track L. Esibov
- J. Westhead
- Microsoft Corp.
- R. Hall
- Lucent Technologies
- October 2003
-
-
- Generic Security Service Algorithm for
- Secret Key Transaction Authentication for DNS (GSS-TSIG)
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- The Secret Key Transaction Authentication for DNS (TSIG) protocol
- provides transaction level authentication for DNS. TSIG is
- extensible through the definition of new algorithms. This document
- specifies an algorithm based on the Generic Security Service
- Application Program Interface (GSS-API) (RFC2743). This document
- updates RFC 2845.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 1]
-
-RFC 3645 GSS-TSIG October 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . . 3
- 2.1. GSS Details. . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2. Modifications to the TSIG protocol (RFC 2845). . . . . . 4
- 3. Client Protocol Details. . . . . . . . . . . . . . . . . . . . 5
- 3.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 5
- 3.1.1. Call GSS_Init_sec_context. . . . . . . . . . . . . 6
- 3.1.2. Send TKEY Query to Server. . . . . . . . . . . . . 8
- 3.1.3. Receive TKEY Query-Response from Server. . . . . . 8
- 3.2. Context Established. . . . . . . . . . . . . . . . . . . 11
- 3.2.1. Terminating a Context. . . . . . . . . . . . . . . 11
- 4. Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
- 4.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 12
- 4.1.1. Receive TKEY Query from Client . . . . . . . . . . 12
- 4.1.2. Call GSS_Accept_sec_context. . . . . . . . . . . . 12
- 4.1.3. Send TKEY Query-Response to Client . . . . . . . . 13
- 4.2. Context Established. . . . . . . . . . . . . . . . . . . 15
- 4.2.1. Terminating a Context. . . . . . . . . . . . . . . 15
- 5. Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
- 5.1. Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
- 5.2. Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
- 6. Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
- 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
- 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
- 9. Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
- 10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
- 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
- 12.1. Normative References. . . . . . . . . . . . . . . . . . 24
- 12.2. Informative References. . . . . . . . . . . . . . . . . 24
- 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
- 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
-
-1. Introduction
-
- The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
- protocol was developed to provide a lightweight authentication and
- integrity of messages between two DNS entities, such as client and
- server or server and server. TSIG can be used to protect dynamic
- update messages, authenticate regular message or to off-load
- complicated DNSSEC [RFC2535] processing from a client to a server and
- still allow the client to be assured of the integrity of the answers.
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 2]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- The TSIG protocol [RFC2845] is extensible through the definition of
- new algorithms. This document specifies an algorithm based on the
- Generic Security Service Application Program Interface (GSS-API)
- [RFC2743]. GSS-API is a framework that provides an abstraction of
- security to the application protocol developer. The security
- services offered can include authentication, integrity, and
- confidentiality.
-
- The GSS-API framework has several benefits:
-
- * Mechanism and protocol independence. The underlying mechanisms
- that realize the security services can be negotiated on the fly
- and varied over time. For example, a client and server MAY use
- Kerberos [RFC1964] for one transaction, whereas that same server
- MAY use SPKM [RFC2025] with a different client.
-
- * The protocol developer is removed from the responsibility of
- creating and managing a security infrastructure. For example, the
- developer does not need to create new key distribution or key
- management systems. Instead the developer relies on the security
- service mechanism to manage this on its behalf.
-
- The scope of this document is limited to the description of an
- authentication mechanism only. It does not discuss and/or propose an
- authorization mechanism. Readers that are unfamiliar with GSS-API
- concepts are encouraged to read the characteristics and concepts
- section of [RFC2743] before examining this protocol in detail. It is
- also assumed that the reader is familiar with [RFC2845], [RFC2930],
- [RFC1034] and [RFC1035].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
- "RECOMMENDED", and "MAY" in this document are to be interpreted as
- described in BCP 14, RFC 2119 [RFC2119].
-
-2. Algorithm Overview
-
- In GSS, client and server interact to create a "security context".
- The security context can be used to create and verify transaction
- signatures on messages between the two parties. A unique security
- context is required for each unique connection between client and
- server.
-
- Creating a security context involves a negotiation between client and
- server. Once a context has been established, it has a finite
- lifetime for which it can be used to secure messages. Thus there are
- three states of a context associated with a connection:
-
-
-
-
-
-Kwan, et al. Standards Track [Page 3]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- +----------+
- | |
- V |
- +---------------+ |
- | Uninitialized | |
- | | |
- +---------------+ |
- | |
- V |
- +---------------+ |
- | Negotiating | |
- | Context | |
- +---------------+ |
- | |
- V |
- +---------------+ |
- | Context | |
- | Established | |
- +---------------+ |
- | |
- +----------+
-
- Every connection begins in the uninitialized state.
-
-2.1. GSS Details
-
- Client and server MUST be locally authenticated and have acquired
- default credentials before using this protocol as specified in
- Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
-
- The GSS-TSIG algorithm consists of two stages:
-
- I. Establish security context. The Client and Server use the
- GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate
- the tokens that they pass to each other using [RFC2930] as a
- transport mechanism.
-
- II. Once the security context is established it is used to generate
- and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs.
- These signatures are exchanged by the Client and Server as a part
- of the TSIG records exchanged in DNS messages sent between the
- Client and Server, as described in [RFC2845].
-
-2.2. Modifications to the TSIG protocol (RFC 2845)
-
- Modification to RFC 2845 allows use of TSIG through signing server's
- response in an explicitly specified place in multi message exchange
- between two DNS entities even if client's request wasn't signed.
-
-
-
-Kwan, et al. Standards Track [Page 4]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
-
- Replace:
- "The server MUST not generate a signed response to an unsigned
- request."
-
- With:
- "The server MUST not generate a signed response to an unsigned
- request, except in case of response to client's unsigned TKEY
- query if secret key is established on server side after server
- processed client's query. Signing responses to unsigned TKEY
- queries MUST be explicitly specified in the description of an
- individual secret key establishment algorithm."
-
-3. Client Protocol Details
-
- A unique context is required for each server to which the client
- sends secure messages. A context is identified by a context handle.
- A client maintains a mapping of servers to handles:
-
- (target_name, key_name, context_handle)
-
- The value key_name also identifies a context handle. The key_name is
- the owner name of the TKEY and TSIG records sent between a client and
- a server to indicate to each other which context MUST be used to
- process the current request.
-
- DNS client and server MAY use various underlying security mechanisms
- to establish security context as described in sections 3 and 4. At
- the same time, in order to guarantee interoperability between DNS
- clients and servers that support GSS-TSIG it is REQUIRED that
- security mechanism used by client enables use of Kerberos v5 (see
- Section 9 for more information).
-
-3.1. Negotiating Context
-
- In GSS, establishing a security context involves the passing of
- opaque tokens between the client and the server. The client
- generates the initial token and sends it to the server. The server
- processes the token and if necessary, returns a subsequent token to
- the client. The client processes this token, and so on, until the
- negotiation is complete. The number of times the client and server
- exchange tokens depends on the underlying security mechanism. A
- completed negotiation results in a context handle.
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 5]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- The TKEY resource record [RFC2930] is used as the vehicle to transfer
- tokens between client and server. The TKEY record is a general
- mechanism for establishing secret keys for use with TSIG. For more
- information, see [RFC2930].
-
-3.1.1. Call GSS_Init_sec_context
-
- To obtain the first token to be sent to a server, a client MUST call
- GSS_Init_sec_context API.
-
- The following input parameters MUST be used. The outcome of the call
- is indicated with the output values below. Consult Sections 2.2.1,
- "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
-
- INPUTS
- CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
- default"). Client MAY instead specify some other valid
- handle to its credentials.
- CONTEXT HANDLE input_context_handle = 0
- INTERNAL NAME targ_name = "DNS@<target_server_name>"
- OBJECT IDENTIFIER mech_type = Underlying security
- mechanism chosen by implementers. To guarantee
- interoperability of the implementations of the GSS-TSIG
- mechanism client MUST specify a valid underlying security
- mechanism that enables use of Kerberos v5 (see Section 9 for
- more information).
- OCTET STRING input_token = NULL
- BOOLEAN replay_det_req_flag = TRUE
- BOOLEAN mutual_req_flag = TRUE
- BOOLEAN deleg_req_flag = TRUE
- BOOLEAN sequence_req_flag = TRUE
- BOOLEAN anon_req_flag = FALSE
- BOOLEAN integ_req_flag = TRUE
- INTEGER lifetime_req = 0 (0 requests a default
- value). Client MAY instead specify another upper bound for the
- lifetime of the context to be established in seconds.
- OCTET STRING chan_bindings = Any valid channel bindings
- as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
- OUTPUTS
- INTEGER major_status
- CONTEXT HANDLE output_context_handle
- OCTET STRING output_token
- BOOLEAN replay_det_state
- BOOLEAN mutual_state
- INTEGER minor_status
- OBJECT IDENTIFIER mech_type
- BOOLEAN deleg_state
-
-
-
-Kwan, et al. Standards Track [Page 6]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- BOOLEAN sequence_state
- BOOLEAN anon_state
- BOOLEAN trans_state
- BOOLEAN prot_ready_state
- BOOLEAN conf_avail
- BOOLEAN integ_avail
- INTEGER lifetime_rec
-
- If returned major_status is set to one of the following errors:
-
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_OLD_TOKEN
- GSS_S_DUPLICATE_TOKEN
- GSS_S_NO_CONTEXT
- GSS_S_BAD_NAMETYPE
- GSS_S_BAD_NAME
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
- then the client MUST abandon the algorithm and MUST NOT use the GSS-
- TSIG algorithm to establish this security context. This document
- does not prescribe which other mechanism could be used to establish a
- security context. Next time when this client needs to establish
- security context, the client MAY use GSS-TSIG algorithm.
-
- Success values of major_status are GSS_S_CONTINUE_NEEDED and
- GSS_S_COMPLETE. The exact success code is important during later
- processing.
-
- The values of replay_det_state and mutual_state indicate if the
- security package provides replay detection and mutual authentication,
- respectively. If returned major_status is GSS_S_COMPLETE AND one or
- both of these values are FALSE, the client MUST abandon this
- algorithm.
-
- Client's behavior MAY depend on other OUTPUT parameters according to
- the policy local to the client.
-
- The handle output_context_handle is unique to this negotiation and is
- stored in the client's mapping table as the context_handle that maps
- to target_name.
-
-
-
-
-
-Kwan, et al. Standards Track [Page 7]
-
-RFC 3645 GSS-TSIG October 2003
-
-
-3.1.2. Send TKEY Query to Server
-
- An opaque output_token returned by GSS_Init_sec_context is
- transmitted to the server in a query request with QTYPE=TKEY. The
- token itself will be placed in a Key Data field of the RDATA field in
- the TKEY resource record in the additional records section of the
- query. The owner name of the TKEY resource record set queried for
- and the owner name of the supplied TKEY resource record in the
- additional records section MUST be the same. This name uniquely
- identifies the security context to both the client and server, and
- thus the client SHOULD use a value which is globally unique as
- described in [RFC2930]. To achieve global uniqueness, the name MAY
- contain a UUID/GUID [ISO11578].
-
- TKEY Record
- NAME = client-generated globally unique domain name string
- (as described in [RFC2930])
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
- The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
- Error, Other Size and Data Fields, MUST be set according to
- [RFC2930].
-
- The query is transmitted to the server.
-
- Note: if the original client call to GSS_Init_sec_context returned
- any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE,
- then the client MUST NOT send TKEY query. Client's behavior in this
- case is described above in Section 3.1.1.
-
-3.1.3. Receive TKEY Query-Response from Server
-
- Upon the reception of the TKEY query the DNS server MUST respond
- according to the description in Section 4. This section specifies
- the behavior of the client after it receives the matching response to
- its query.
-
- The next processing step depends on the value of major_status from
- the most recent call that client performed to GSS_Init_sec_context:
- either GSS_S_COMPLETE or GSS_S_CONTINUE.
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 8]
-
-RFC 3645 GSS-TSIG October 2003
-
-
-3.1.3.1. Value of major_status == GSS_S_COMPLETE
-
- If the last call to GSS_Init_sec_context yielded a major_status value
- of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
- then the client side component of the negotiation is complete and the
- client is awaiting confirmation from the server.
-
- Confirmation is in the form of a query response with RCODE=NOERROR
- and with the last client supplied TKEY record in the answer section
- of the query. The response MUST be signed with a TSIG record. Note
- that the server is allowed to sign a response to unsigned client's
- query due to modification to the RFC 2845 specified in Section 2.2
- above. The signature in the TSIG record MUST be verified using the
- procedure detailed in section 5, Sending and Verifying Signed
- Messages. If the response is not signed, OR if the response is
- signed but the signature is invalid, then an attacker has tampered
- with the message in transit or has attempted to send the client a
- false response. In this case, the client MAY continue waiting for a
- response to its last TKEY query until the time period since the
- client sent last TKEY query expires. Such a time period is specified
- by the policy local to the client. This is a new option that allows
- the DNS client to accept multiple answers for one query ID and select
- one (not necessarily the first one) based on some criteria.
-
- If the signature is verified, the context state is advanced to
- Context Established. Proceed to section 3.2 for usage of the
- security context.
-
-3.1.3.2. Value of major_status == GSS_S_CONTINUE_NEEDED
-
- If the last call to GSS_Init_sec_context yielded a major_status value
- of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete.
- The server will return to the client a query response with a TKEY
- record in the Answer section. If the DNS message error is not
- NO_ERROR or error field in the TKEY record is not 0 (i.e., no error),
- then the client MUST abandon this negotiation sequence. The client
- MUST delete an active context by calling GSS_Delete_sec_context
- providing the associated context_handle. The client MAY repeat the
- negotiation sequence starting with the uninitialized state as
- described in section 3.1. To prevent infinite looping the number of
- attempts to establish a security context MUST be limited to ten or
- less.
-
- If the DNS message error is NO_ERROR and the error field in the TKEY
- record is 0 (i.e., no error), then the client MUST pass a token
- specified in the Key Data field in the TKEY resource record to
-
-
-
-
-
-Kwan, et al. Standards Track [Page 9]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- GSS_Init_sec_context using the same parameters values as in previous
- call except values for CONTEXT HANDLE input_context_handle and OCTET
- STRING input_token as described below:
-
- INPUTS
- CONTEXT HANDLE input_context_handle = context_handle (this is the
- context_handle corresponding to the key_name which is the
- owner name of the TKEY record in the answer section in the
- TKEY query response)
-
- OCTET STRING input_token = token from Key field of
- TKEY record
-
- Depending on the following OUTPUT values of GSS_Init_sec_context
-
- INTEGER major_status
- OCTET STRING output_token
-
- the client MUST take one of the following actions:
-
- If OUTPUT major_status is set to one of the following values:
-
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_OLD_TOKEN
- GSS_S_DUPLICATE_TOKEN
- GSS_S_NO_CONTEXT
- GSS_S_BAD_NAMETYPE
- GSS_S_BAD_NAME
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
- the client MUST abandon this negotiation sequence. This means that
- the client MUST delete an active context by calling
- GSS_Delete_sec_context providing the associated context_handle. The
- client MAY repeat the negotiation sequence starting with the
- uninitialized state as described in section 3.1. To prevent infinite
- looping the number of attempts to establish a security context MUST
- be limited to ten or less.
-
- If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE
- then client MUST act as described below.
-
-
-
-
-
-Kwan, et al. Standards Track [Page 10]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- If the response from the server was signed, and the OUTPUT
- major_status is GSS_S_COMPLETE,then the signature in the TSIG record
- MUST be verified using the procedure detailed in section 5, Sending
- and Verifying Signed Messages. If the signature is invalid, then the
- client MUST abandon this negotiation sequence. This means that the
- client MUST delete an active context by calling
- GSS_Delete_sec_context providing the associated context_handle. The
- client MAY repeat the negotiation sequence starting with the
- uninitialized state as described in section 3.1. To prevent infinite
- looping the number of attempts to establish a security context MUST
- be limited to ten or less.
-
- If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
- finished. The token output_token MUST be passed to the server in a
- TKEY record by repeating the negotiation sequence beginning with
- section 3.1.2. The client MUST place a limit on the number of
- continuations in a context negotiation to prevent endless looping.
- Such limit SHOULD NOT exceed value of 10.
-
- If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
- client-side component of the negotiation is complete but the token
- output_token MUST be passed to the server by repeating the
- negotiation sequence beginning with section 3.1.2.
-
- If major_status is GSS_S_COMPLETE and output_token is NULL, context
- negotiation is complete. The context state is advanced to Context
- Established. Proceed to section 3.2 for usage of the security
- context.
-
-3.2. Context Established
-
- When context negotiation is complete, the handle context_handle MUST
- be used for the generation and verification of transaction
- signatures.
-
- The procedures for sending and receiving signed messages are
- described in section 5, Sending and Verifying Signed Messages.
-
-3.2.1. Terminating a Context
-
- When the client is not intended to continue using the established
- security context, the client SHOULD delete an active context by
- calling GSS_Delete_sec_context providing the associated
- context_handle, AND client SHOULD delete the established context on
- the DNS server by using TKEY RR with the Mode field set to 5, i.e.,
- "key deletion" [RFC2930].
-
-
-
-
-
-Kwan, et al. Standards Track [Page 11]
-
-RFC 3645 GSS-TSIG October 2003
-
-
-4. Server Protocol Details
-
- As on the client-side, the result of a successful context negotiation
- is a context handle used in future generation and verification of the
- transaction signatures.
-
- A server MAY be managing several contexts with several clients.
- Clients identify their contexts by providing a key name in their
- request. The server maintains a mapping of key names to handles:
-
- (key_name, context_handle)
-
-4.1. Negotiating Context
-
- A server MUST recognize TKEY queries as security context negotiation
- messages.
-
-4.1.1. Receive TKEY Query from Client
-
- Upon receiving a query with QTYPE = TKEY, the server MUST examine
- whether the Mode and Algorithm Name fields of the TKEY record in the
- additional records section of the message contain values of 3 and
- gss-tsig, respectively. If they do, then the (key_name,
- context_handle) mapping table is searched for the key_name matching
- the owner name of the TKEY record in the additional records section
- of the query. If the name is found in the table and the security
- context for this name is established and not expired, then the server
- MUST respond to the query with BADNAME error in the TKEY error field.
- If the name is found in the table and the security context is not
- established, the corresponding context_handle is used in subsequent
- GSS operations. If the name is found but the security context is
- expired, then the server deletes this security context, as described
- in Section 4.2.1, and interprets this query as a start of new
- security context negotiation and performs operations described in
- Section 4.1.2 and 4.1.3. If the name is not found, then the server
- interprets this query as a start of new security context negotiation
- and performs operations described in Section 4.1.2 and 4.1.3.
-
-4.1.2. Call GSS_Accept_sec_context
-
- The server performs its side of a context negotiation by calling
- GSS_Accept_sec_context. The following input parameters MUST be used.
- The outcome of the call is indicated with the output values below.
- Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743
- [RFC2743] for syntax definitions.
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 12]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- INPUTS
- CONTEXT HANDLE input_context_handle = 0 if new negotiation,
- context_handle matching
- key_name if ongoing negotiation
- OCTET STRING input_token = token specified in the Key
- field from TKEY RR (from Additional records Section of
- the client's query)
-
- CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
- default"). Server MAY instead specify some other valid
- handle to its credentials.
- OCTET STRING chan_bindings = Any valid channel bindings
- as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
- OUTPUTS
- INTEGER major_status
- CONTEXT_HANDLE output_context_handle
- OCTET STRING output_token
- INTEGER minor_status
- INTERNAL NAME src_name
- OBJECT IDENTIFIER mech_type
- BOOLEAN deleg_state
- BOOLEAN mutual_state
- BOOLEAN replay_det_state
- BOOLEAN sequence_state
- BOOLEAN anon_state
- BOOLEAN trans_state
- BOOLEAN prot_ready_state
- BOOLEAN conf_avail
- BOOLEAN integ_avail
- INTEGER lifetime_rec
- CONTEXT_HANDLE delegated_cred_handle
-
- If this is the first call to GSS_Accept_sec_context in a new
- negotiation, then output_context_handle is stored in the server's
- key-mapping table as the context_handle that maps to the name of the
- TKEY record.
-
-4.1.3. Send TKEY Query-Response to Client
-
- The server MUST respond to the client with a TKEY query response with
- RCODE = NOERROR, that contains a TKEY record in the answer section.
-
- If OUTPUT major_status is one of the following errors the error field
- in the TKEY record set to BADKEY.
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 13]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_DUPLICATE_TOKEN
- GSS_S_OLD_TOKEN
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_NO_CONTEXT
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
- If OUTPUT major_status is set to GSS_S_COMPLETE or
- GSS_S_CONTINUE_NEEDED then server MUST act as described below.
-
- If major_status is GSS_S_COMPLETE the server component of the
- negotiation is finished. If output_token is non-NULL, then it MUST
- be returned to the client in a Key Data field of the RDATA in TKEY.
- The error field in the TKEY record is set to NOERROR. The message
- MUST be signed with a TSIG record as described in section 5, Sending
- and Verifying Signed Messages. Note that server is allowed to sign a
- response to unsigned client's query due to modification to the RFC
- 2845 specified in Section 2.2 above. The context state is advanced
- to Context Established. Section 4.2 discusses the usage of the
- security context.
-
- If major_status is GSS_S_COMPLETE and output_token is NULL, then the
- TKEY record received from the client MUST be returned in the Answer
- section of the response. The message MUST be signed with a TSIG
- record as described in section 5, Sending and Verifying Signed
- Messages. Note that server is allowed to sign a response to unsigned
- client's query due to modification to the RFC 2845 specified in
- section 2.2 above. The context state is advanced to Context
- Established. Section 4.2 discusses the usage of the security
- context.
-
- If major_status is GSS_S_CONTINUE_NEEDED, the server component of the
- negotiation is not yet finished. The server responds to the TKEY
- query with a standard query response, placing in the answer section a
- TKEY record containing output_token in the Key Data RDATA field. The
- error field in the TKEY record is set to NOERROR. The server MUST
- limit the number of times that a given context is allowed to repeat,
- to prevent endless looping. Such limit SHOULD NOT exceed value of
- 10.
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 14]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- In all cases, except if major_status is GSS_S_COMPLETE and
- output_token is NULL, other TKEY record fields MUST contain the
- following values:
-
- NAME = key_name
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
-
- The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
- Error, Other Size and Data Fields, MUST be set according to
- [RFC2930].
-
-4.2. Context Established
-
- When context negotiation is complete, the handle context_handle is
- used for the generation and verification of transaction signatures.
- The handle is valid for a finite amount of time determined by the
- underlying security mechanism. A server MAY unilaterally terminate a
- context at any time (see section 4.2.1).
-
- Server SHOULD limit the amount of memory used to cache established
- contexts.
-
- The procedures for sending and receiving signed messages are given in
- section 5, Sending and Verifying Signed Messages.
-
-4.2.1. Terminating a Context
-
- A server can terminate any established context at any time. The
- server MAY hint to the client that the context is being deleted by
- including a TKEY RR in a response with the Mode field set to 5, i.e.,
- "key deletion" [RFC2930]. An active context is deleted by calling
- GSS_Delete_sec_context providing the associated context_handle.
-
-5. Sending and Verifying Signed Messages
-
-5.1. Sending a Signed Message - Call GSS_GetMIC
-
- The procedure for sending a signature-protected message is specified
- in [RFC2845]. The data to be passed to the signature routine
- includes the whole DNS message with specific TSIG variables appended.
- For the exact format, see [RFC2845]. For this protocol, use the
- following TSIG variable values:
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 15]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- TSIG Record
- NAME = key_name that identifies this context
- RDATA
- Algorithm Name = gss-tsig
-
- Assign the remaining fields in the TSIG RDATA appropriate values as
- described in [RFC2845].
-
- The signature is generated by calling GSS_GetMIC. The following
- input parameters MUST be used. The outcome of the call is indicated
- with the output values specified below. Consult Sections 2.3.1
- "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
-
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for key_name
- OCTET STRING message = outgoing message plus TSIG
- variables (per [RFC2845])
- INTEGER qop_req = 0 (0 requests a default
- value). Caller MAY instead specify other valid value (for
- details see Section 1.2.4 in [RFC2743])
-
- OUTPUTS
- INTEGER major_status
- INTEGER minor_status
- OCTET STRING per_msg_token
-
- If major_status is GSS_S_COMPLETE, then signature generation
- succeeded. The signature in per_msg_token is inserted into the
- Signature field of the TSIG RR and the message is transmitted.
-
- If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED
- or GSS_S_FAILURE the caller MUST delete the security context, return
- to the uninitialized state and SHOULD negotiate a new security
- context, as described above in Section 3.1
-
- If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
- for key_name from the (target_ name, key_name, context_handle)
- mapping table, return to the uninitialized state and SHOULD negotiate
- a new security context, as described above in Section 3.1
-
- If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
- GSS_GetMIC call with allowed QOP value. The number of such
- repetitions MUST be limited to prevent infinite loops.
-
-5.2. Verifying a Signed Message - Call GSS_VerifyMIC
-
- The procedure for verifying a signature-protected message is
- specified in [RFC2845].
-
-
-
-Kwan, et al. Standards Track [Page 16]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- The NAME of the TSIG record determines which context_handle maps to
- the context that MUST be used to verify the signature. If the NAME
- does not map to an established context, the server MUST send a
- standard TSIG error response to the client indicating BADKEY in the
- TSIG error field (as described in [RFC2845]).
-
- For the GSS algorithm, a signature is verified by using
- GSS_VerifyMIC:
-
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for key_name
- OCTET STRING message = incoming message plus TSIG
- variables (per [RFC2845])
- OCTET STRING per_msg_token = Signature field from TSIG RR
-
- OUTPUTS
- INTEGER major_status
- INTEGER minor_status
- INTEGER qop_state
-
- If major_status is GSS_S_COMPLETE, the signature is authentic and the
- message was delivered intact. Per [RFC2845], the timer values of the
- TSIG record MUST also be valid before considering the message to be
- authentic. The caller MUST not act on the request or response in the
- message until these checks are verified.
-
- When a server is processing a client request, the server MUST send a
- standard TSIG error response to the client indicating BADKEY in the
- TSIG error field as described in [RFC2845], if major_status is set to
- one of the following values
-
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_DUPLICATE_TOKEN
- GSS_S_OLD_TOKEN
- GSS_S_UNSEQ_TOKEN
- GSS_S_GAP_TOKEN
- GSS_S_CONTEXT_EXPIRED
- GSS_S_NO_CONTEXT
- GSS_S_FAILURE
-
- If the timer values of the TSIG record are invalid, the message MUST
- NOT be considered authentic. If this error checking fails when a
- server is processing a client request, the appropriate error response
- MUST be sent to the client according to [RFC2845].
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 17]
-
-RFC 3645 GSS-TSIG October 2003
-
-
-6. Example usage of GSS-TSIG algorithm
-
- This Section describes an example where a Client, client.example.com,
- and a Server, server.example.com, establish a security context
- according to the algorithm described above.
-
- I. Client initializes security context negotiation
-
- To establish a security context with a server, server.example.com, the
- Client calls GSS_Init_sec_context with the following parameters.
- (Note that some INPUT and OUTPUT parameters not critical for this
- algorithm are not described in this example.)
-
- CONTEXT HANDLE input_context_handle = 0
- INTERNAL NAME targ_name = "DNS@server.example.com"
- OCTET STRING input_token = NULL
- BOOLEAN replay_det_req_flag = TRUE
- BOOLEAN mutual_req_flag = TRUE
-
- The OUTPUTS parameters returned by GSS_Init_sec_context include
- INTEGER major_status = GSS_S_CONTINUE_NEEDED
- CONTEXT HANDLE output_context_handle context_handle
- OCTET STRING output_token output_token
- BOOLEAN replay_det_state = TRUE
- BOOLEAN mutual_state = TRUE
-
- Client verifies that replay_det_state and mutual_state values are
- TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
- success OUTPUT major_status value, client stores context_handle that
- maps to "DNS@server.example.com" and proceeds to the next step.
-
- II. Client sends a query with QTYPE = TKEY to server
-
- Client sends a query with QTYPE = TKEY for a client-generated globally
- unique domain name string, 789.client.example.com.server.example.com.
- Query contains a TKEY record in its Additional records section with
- the following fields. (Note that some fields not specific to this
- algorithm are not specified.)
-
- NAME = 789.client.example.com.server.example.com.
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 18]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- After the key_name 789.client.example.com.server.example.com.
- is generated it is stored in the client's (target_name, key_name,
- context_handle) mapping table.
-
- III. Server receives a query with QTYPE = TKEY
-
- When server receives a query with QTYPE = TKEY, the server verifies
- that Mode and Algorithm fields in the TKEY record in the Additional
- records section of the query are set to 3 and "gss-tsig" respectively.
- It finds that the key_name 789.client.example.com.server.example.com.
- is not listed in its (key_name, context_handle) mapping table.
-
- IV. Server calls GSS_Accept_sec_context
-
- To continue security context negotiation server calls
- GSS_Accept_sec_context with the following parameters. (Note that
- some INPUT and OUTPUT parameters not critical for this algorithm
- are not described in this example.)
-
- INPUTS
- CONTEXT HANDLE input_context_handle = 0
- OCTET STRING input_token = token specified in the Key
- field from TKEY RR (from Additional
- records section of the client's query)
-
- The OUTPUTS parameters returned by GSS_Accept_sec_context include
- INTEGER major_status = GSS_S_CONTINUE_NEEDED
- CONTEXT_HANDLE output_context_handle context_handle
- OCTET STRING output_token output_token
-
- Server stores the mapping of the
- 789.client.example.com.server.example.com. to OUTPUT context_handle
- in its (key_name, context_handle) mapping table.
-
- V. Server responds to the TKEY query
-
- Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
- call to GSS_Accept_sec_context, the server responds to the TKEY query
- placing in the answer section a TKEY record containing output_token in
- the Key Data RDATA field. The error field in the TKEY record is set
- to 0. The RCODE in the query response is set to NOERROR.
-
- VI. Client processes token returned by server
-
- When the client receives the TKEY query response from the server, the
- client calls GSS_Init_sec_context with the following parameters.
- (Note that some INPUT and OUTPUT parameters not critical for this
- algorithm are not described in this example.)
-
-
-
-Kwan, et al. Standards Track [Page 19]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- CONTEXT HANDLE input_context_handle = the context_handle stored
- in the client's mapping table entry (DNS@server.example.com.,
- 789.client.example.com.server.example.com., context_handle)
- INTERNAL NAME targ_name = "DNS@server.example.com"
- OCTET STRING input_token = token from Key field of TKEY
- record from the Answer section of the server's response
- BOOLEAN replay_det_req_flag = TRUE
- BOOLEAN mutual_req_flag = TRUE
-
- The OUTPUTS parameters returned by GSS_Init_sec_context include
- INTEGER major_status = GSS_S_COMPLETE
- CONTEXT HANDLE output_context_handle = context_handle
- OCTET STRING output_token = output_token
- BOOLEAN replay_det_state = TRUE
- BOOLEAN mutual_state = TRUE
-
- Since the major_status is set to GSS_S_COMPLETE the client side
- security context is established, but since the output_token is not
- NULL client MUST send a TKEY query to the server as described below.
-
- VII. Client sends a query with QTYPE = TKEY to server
-
- Client sends to the server a TKEY query for the
- 789.client.example.com.server.example.com. name. Query contains a
- TKEY record in its Additional records section with the following
- fields. (Note that some INPUT and OUTPUT parameters not critical to
- this algorithm are not described in this example.)
-
- NAME = 789.client.example.com.server.example.com.
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
- VIII. Server receives a TKEY query
-
- When the server receives a TKEY query, the server verifies that Mode
- and Algorithm fields in the TKEY record in the Additional records
- section of the query are set to 3 and gss-tsig, respectively. It
- finds that the key_name 789.client.example.com.server.example.com. is
- listed in its (key_name, context_handle) mapping table.
-
-
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 20]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- IX. Server calls GSS_Accept_sec_context
-
- To continue security context negotiation server calls
- GSS_Accept_sec_context with the following parameters (Note that some
- INPUT and OUTPUT parameters not critical for this algorithm are not
- described in this example)
-
- INPUTS
- CONTEXT HANDLE input_context_handle = context_handle from the
- (789.client.example.com.server.example.com., context_handle)
- entry in the server's mapping table
- OCTET STRING input_token = token specified in the Key
- field of TKEY RR (from Additional records Section of
- the client's query)
-
- The OUTPUTS parameters returned by GSS_Accept_sec_context include
- INTEGER major_status = GSS_S_COMPLETE
- CONTEXT_HANDLE output_context_handle = context_handle
- OCTET STRING output_token = NULL
-
- Since major_status = GSS_S_COMPLETE, the security context on the
- server side is established, but the server still needs to respond to
- the client's TKEY query, as described below. The security context
- state is advanced to Context Established.
-
- X. Server responds to the TKEY query
-
- Since the major_status = GSS_S_COMPLETE in the last server's call to
- GSS_Accept_sec_context and the output_token is NULL, the server
- responds to the TKEY query placing in the answer section a TKEY record
- that was sent by the client in the Additional records section of the
- client's latest TKEY query. In addition, this server places a
- TSIG record in additional records section of its response. Server
- calls GSS_GetMIC to generate a signature to include it in the TSIG
- record. The server specifies the following GSS_GetMIC INPUT
- parameters:
-
- CONTEXT HANDLE context_handle = context_handle from the
- (789.client.example.com.server.example.com., context_handle)
- entry in the server's mapping table
- OCTET STRING message = outgoing message plus TSIG
- variables (as described in [RFC2845])
-
- The OUTPUTS parameters returned by GSS_GetMIC include
- INTEGER major_status = GSS_S_COMPLETE
- OCTET STRING per_msg_token
-
- Signature field in the TSIG record is set to per_msg_token.
-
-
-
-Kwan, et al. Standards Track [Page 21]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- XI. Client processes token returned by server
-
- Client receives the TKEY query response from the server. Since the
- major_status was GSS_S_COMPLETE in the last client's call to
- GSS_Init_sec_context, the client verifies that the server's response
- is signed. To validate the signature, the client calls
- GSS_VerifyMIC with the following parameters:
-
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for
- 789.client.example.com.server.example.com. key_name
- OCTET STRING message = incoming message plus TSIG
- variables (as described in [RFC2845])
- OCTET STRING per_msg_token = Signature field from TSIG RR
- included in the server's query response
-
- Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
- signature is validated, security negotiation is complete and the
- security context state is advanced to Context Established. These
- client and server will use the established security context to sign
- and validate the signatures when they exchange packets with each
- other until the context expires.
-
-7. Security Considerations
-
- This document describes a protocol for DNS security using GSS-API.
- The security provided by this protocol is only as effective as the
- security provided by the underlying GSS mechanisms.
-
- All the security considerations from RFC 2845, RFC 2930 and RFC 2743
- apply to the protocol described in this document.
-
-8. IANA Considerations
-
- The IANA has reserved the TSIG Algorithm name gss-tsig for the use in
- the Algorithm fields of TKEY and TSIG resource records. This
- Algorithm name refers to the algorithm described in this document.
- The requirement to have this name registered with IANA is specified
- in RFC 2845.
-
-9. Conformance
-
- The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
- choose the underlying security mechanisms that enables security
- context negotiation. GSS API using SPNEGO [RFC2478] enables client
- and server to negotiate and choose such underlying security
- mechanisms on the fly. To support such flexibility, DNS clients and
- servers SHOULD specify SPNEGO mech_type in their GSS API calls. At
-
-
-
-Kwan, et al. Standards Track [Page 22]
-
-RFC 3645 GSS-TSIG October 2003
-
-
- the same time, in order to guarantee interoperability between DNS
- clients and servers that support GSS-TSIG it is required that
-
- - DNS servers specify SPNEGO mech_type
- - GSS APIs called by DNS client support Kerberos v5
- - GSS APIs called by DNS server support SPNEGO [RFC2478] and
- Kerberos v5.
-
- In addition to these, GSS APIs used by DNS client and server MAY also
- support other underlying security mechanisms.
-
-10. 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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-11. Acknowledgements
-
- The authors of this document would like to thank the following people
- for their contribution to this specification: Chuck Chan, Mike
- Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd
- and Erik Nordmark.
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 23]
-
-RFC 3645 GSS-TSIG October 2003
-
-
-12. References
-
-12.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
- Negotiation Mechanism", RFC 2478, December 1998.
-
- [RFC2743] Linn, J., "Generic Security Service Application Program
- Interface, Version 2 , Update 1", RFC 2743, January 2000.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
-12.2. Informative References
-
-
- [ISO11578] "Information technology", "Open Systems Interconnection",
- "Remote Procedure Call", ISO/IEC 11578:1996,
- http://www.iso.ch/cate/d2229.html.
-
- [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 1034, November 1987.
-
- [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
- 1964, June 1996.
-
- [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
- (SPKM)", RFC 2025, October 1996.
-
- [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
- Update", RFC 2137, April 1997.
-
- [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 24]
-
-RFC 3645 GSS-TSIG October 2003
-
-
-13. Authors' Addresses
-
- Stuart Kwan
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
- USA
- EMail: skwan@microsoft.com
-
- Praerit Garg
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
- USA
- EMail: praeritg@microsoft.com
-
- James Gilroy
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
- USA
- EMail: jamesg@microsoft.com
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
- USA
- EMail: levone@microsoft.com
-
- Randy Hall
- Lucent Technologies
- 400 Lapp Road
- Malvern PA 19355
- USA
- EMail: randyhall@lucent.com
-
- Jeff Westhead
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
- USA
- EMail: jwesth@microsoft.com
-
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 25]
-
-RFC 3645 GSS-TSIG October 2003
-
-
-14. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al. Standards Track [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc3655.txt b/contrib/bind9/doc/rfc/rfc3655.txt
deleted file mode 100644
index 13e586bad0d71..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3655.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group B. Wellington
-Request for Comments: 3655 O. Gudmundsson
-Updates: 2535 November 2003
-Category: Standards Track
-
-
- Redefinition of DNS Authenticated Data (AD) bit
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- This document alters the specification defined in RFC 2535. Based on
- implementation experience, the Authenticated Data (AD) bit in the DNS
- header is not useful. This document redefines the AD bit such that
- it is only set if all answers or records proving that no answers
- exist in the response has been cryptographically verified or
- otherwise meets the server's local security policy.
-
-1. Introduction
-
- Familiarity with the DNS system [RFC1035] and DNS security extensions
- [RFC2535] is helpful but not necessary.
-
- As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
- bit indicates in a response that all data included in the answer and
- authority sections of the response have been authenticated by the
- server according to the policies of that server. This is not
- especially useful in practice, since a conformant server SHOULD never
- reply with data that failed its security policy.
-
- This document redefines the AD bit such that it is only set if all
- data in the response has been cryptographically verified or otherwise
- meets the server's local security policy. Thus, neither a response
- containing properly delegated insecure data, nor a server configured
- without DNSSEC keys, will have the AD set. As before, data that
- failed to verify will not be returned. An application running on a
- host that has a trust relationship with the server performing the
-
-
-
-Wellington & Gudmundsson Standards Track [Page 1]
-
-RFC 3655 Redefinition of DNS AD bit November 2003
-
-
- recursive query can now use the value of the AD bit to determine
- whether the data is secure.
-
-1.1. Motivation
-
- A full DNSSEC capable resolver called directly from an application
- can return to the application the security status of the RRsets in
- the answer. However, most applications use a limited stub resolver
- that relies on an external recursive name server which incorporates a
- full resolver. The recursive nameserver can use the AD bit in a
- response to indicate the security status of the data in the answer,
- and the local resolver can pass this information to the application.
- The application in this context can be either a human using a DNS
- tool or a software application.
-
- The AD bit SHOULD be used by the local resolver if and only if it has
- been explicitly configured to trust the remote resolver. The AD bit
- SHOULD be ignored when the recursive name server is not trusted.
-
- An alternate solution would be to embed a full DNSSEC resolver into
- every application, but this has several disadvantages.
-
- - DNSSEC validation is both CPU and network intensive, and caching
- SHOULD be used whenever possible.
-
- - DNSSEC requires non-trivial configuration - the root key must be
- configured, as well as keys for any "islands of security" that
- will exist until DNSSEC is fully deployed. The number of
- configuration points should be minimized.
-
-1.2. Requirements
-
- The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
- NOT", "RECOMMENDED", in this document are to be interpreted as
- described in BCP 14, RFC 2119 [RFC2119].
-
-1.3. Updated documents and sections
-
- The definition of the AD bit in RFC 2535, Section 6.1, is changed.
-
-2. Setting of AD bit
-
- The presence of the CD (Checking Disabled) bit in a query does not
- affect the setting of the AD bit in the response. If the CD bit is
- set, the server will not perform checking, but SHOULD still set the
- AD bit if the data has already been cryptographically verified or
-
-
-
-
-
-Wellington & Gudmundsson Standards Track [Page 2]
-
-RFC 3655 Redefinition of DNS AD bit November 2003
-
-
- complies with local policy. The AD bit MUST only be set if DNSSEC
- records have been requested via the DO bit [RFC3225] and relevant SIG
- records are returned.
-
-2.1. Setting of AD bit by recursive servers
-
- Section 6.1 of RFC 2535 says:
-
- "The AD bit MUST NOT be set on a response unless all of the RRs in
- the answer and authority sections of the response are either
- Authenticated or Insecure."
-
- The replacement text reads:
-
- "The AD bit MUST NOT be set on a response unless all of the RRsets in
- the answer and authority sections of the response are Authenticated."
-
- "The AD bit SHOULD be set if and only if all RRs in the answer
- section and any relevant negative response RRs in the authority
- section are Authenticated."
-
- A recursive DNS server following this modified specification will
- only set the AD bit when it has cryptographically verified the data
- in the answer.
-
-2.2. Setting of AD bit by authoritative servers
-
- A primary server for a secure zone MAY have the policy of treating
- authoritative secure zones as Authenticated. Secondary servers MAY
- have the same policy, but SHOULD NOT consider zone data Authenticated
- unless the zone was transferred securely and/or the data was
- verified. An authoritative server MUST only set the AD bit for
- authoritative answers from a secure zone if it has been explicitly
- configured to do so. The default for this behavior SHOULD be off.
-
- Note that having the AD bit clear on an authoritative answer is
- normal and expected behavior.
-
-2.2.1. Justification for setting AD bit w/o verifying data
-
- The setting of the AD bit by authoritative servers affects only the
- small set of resolvers that are configured to directly query and
- trust authoritative servers. This only affects servers that function
- as both recursive and authoritative. Iterative resolvers SHOULD
- ignore the AD bit.
-
- The cost of verifying all signatures on load by an authoritative
- server can be high and increases the delay before it can begin
-
-
-
-Wellington & Gudmundsson Standards Track [Page 3]
-
-RFC 3655 Redefinition of DNS AD bit November 2003
-
-
- answering queries. Verifying signatures at query time is also
- expensive and could lead to resolvers timing out on many queries
- after the server reloads zones.
-
- Organizations requiring that all DNS responses contain
- cryptographically verified data will need to separate the
- authoritative name server and signature verification functions, since
- name servers are not required to validate signatures of data for
- which they are authoritative.
-
-3. Interpretation of the AD bit
-
- A response containing data marked Insecure in the answer or authority
- section MUST never have the AD bit set. In this case, the resolver
- SHOULD treat the data as Insecure whether or not SIG records are
- present.
-
- A resolver MUST NOT blindly trust the AD bit unless it communicates
- with a recursive nameserver over a secure transport mechanism or
- using a message authentication such as TSIG [RFC2845] or SIG(0)
- [RFC2931] and is explicitly configured to trust this recursive name
- server.
-
-4. Applicability statement
-
- The AD bit is intended to allow the transmission of the indication
- that a resolver has verified the DNSSEC signatures accompanying the
- records in the Answer and Authority section. The AD bit MUST only be
- trusted when the end consumer of the DNS data has confidence that the
- intermediary resolver setting the AD bit is trustworthy. This can
- only be accomplished via an out of band mechanism such as:
-
- - Fiat: An organization that can dictate whether it is OK to trust
- certain DNS servers.
-
- - Personal: Because of a personal relationship or the reputation of
- a recursive nameserver operator, a DNS consumer can decide to
- trust that recursive nameserver.
-
- - Knowledge: If a recursive nameserver operator posts the configured
- policy of a recursive nameserver, a consumer can decide that
- recursive nameserver is trustworthy.
-
- In the absence of one or more of these factors AD bit from a
- recursive name server SHOULD NOT be trusted. For example, home users
- frequently depend on their ISP to provide recursive DNS service; it
-
-
-
-
-
-Wellington & Gudmundsson Standards Track [Page 4]
-
-RFC 3655 Redefinition of DNS AD bit November 2003
-
-
- is not advisable to trust these recursive nameservers. A
- roaming/traveling host SHOULD not use recursive DNS servers offered
- by DHCP when looking up information where security status matters.
-
- In the latter two cases, the end consumer must also completely trust
- the path to the trusted recursive name servers, or a secure transport
- must be employed to protect the traffic.
-
- When faced with a situation where there are no satisfactory recursive
- nameservers available, running one locally is RECOMMENDED. This has
- the advantage that it can be trusted, and the AD bit can still be
- used to allow applications to use stub resolvers.
-
-5. Security Considerations
-
- This document redefines a bit in the DNS header. If a resolver
- trusts the value of the AD bit, it must be sure that the responder is
- using the updated definition, which is any DNS server/resolver
- supporting the DO bit [RFC3225].
-
- Authoritative servers can be explicitly configured to set the AD bit
- on answers without doing cryptographic checks. This behavior MUST be
- off by default. The only affected resolvers are those that directly
- query and trust the authoritative server, and this functionality
- SHOULD only be used on servers that act both as authoritative and
- recursive name servers.
-
- Resolvers (full or stub) that blindly trust the AD bit without
- knowing the security policy of the server generating the answer can
- not be considered security aware.
-
- A resolver MUST NOT blindly trust the AD bit unless it communicates
- such as IPsec, or using message authentication such as TSIG [RFC2845]
- or SIG(0) [RFC2931]. In addition, the resolver must have been
- explicitly configured to trust this recursive name server.
-
-6. IANA Considerations
-
- None.
-
-7. Internationalization Considerations
-
- None. This document does not change any textual data in any
- protocol.
-
-
-
-
-
-
-
-Wellington & Gudmundsson Standards Track [Page 5]
-
-RFC 3655 Redefinition of DNS AD bit November 2003
-
-
-8. Intellectual Property Rights Notice
-
- 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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-9. Acknowledgments
-
- The following people have provided input on this document: Robert
- Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
- Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
-
-10. Normative References
-
- [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.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, 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, D., "DNS Request and Transaction Signatures
- (SIG(0))", RFC 2931, September 2000.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
-
-
-Wellington & Gudmundsson Standards Track [Page 6]
-
-RFC 3655 Redefinition of DNS AD bit November 2003
-
-
-11. Authors' Addresses
-
- Brian Wellington
- Nominum Inc.
- 2385 Bay Road
- Redwood City, CA, 94063
- USA
-
- EMail: Brian.Wellington@nominum.com
-
-
- Olafur Gudmundsson
- 3821 Village Park Drive
- Chevy Chase, MD, 20815
- USA
-
- EMail: ogud@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington & Gudmundsson Standards Track [Page 7]
-
-RFC 3655 Redefinition of DNS AD bit November 2003
-
-
-12. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington & Gudmundsson Standards Track [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3658.txt b/contrib/bind9/doc/rfc/rfc3658.txt
deleted file mode 100644
index 88cfb5af2425a..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3658.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group O. Gudmundsson
-Request for Comments: 3658 December 2003
-Updates: 3090, 3008, 2535, 1035
-Category: Standards Track
-
-
- Delegation Signer (DS) Resource Record (RR)
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- The delegation signer (DS) resource record (RR) is inserted at a zone
- cut (i.e., a delegation point) to indicate that the delegated zone is
- digitally signed and that the delegated zone recognizes the indicated
- key as a valid zone key for the delegated zone. The DS RR is a
- modification to the DNS Security Extensions definition, motivated by
- operational considerations. The intent is to use this resource
- record as an explicit statement about the delegation, rather than
- relying on inference.
-
- This document defines the DS RR, gives examples of how it is used and
- describes the implications on resolvers. This change is not
- backwards compatible with RFC 2535. This document updates RFC 1035,
- RFC 2535, RFC 3008 and RFC 3090.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 1]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-Table of Contents
-
- 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2. Reserved Words. . . . . . . . . . . . . . . . . . . . . 4
- 2. Specification of the Delegation key Signer. . . . . . . . . . 4
- 2.1. Delegation Signer Record Model. . . . . . . . . . . . . 4
- 2.2. Protocol Change . . . . . . . . . . . . . . . . . . . . 5
- 2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations
- at Delegation Points . . . . . . . . . . . . . 6
- 2.2.1.1. Special processing for DS queries. . . 6
- 2.2.1.2. Special processing when child and an
- ancestor share nameserver. . . . . . . 7
- 2.2.1.3. Modification on use of KEY RR in the
- construction of Responses. . . . . . . 8
- 2.2.2. Signer's Name (replaces RFC3008 section 2.7). . 9
- 2.2.3. Changes to RFC 3090 . . . . . . . . . . . . . . 9
- 2.2.3.1. RFC 3090: Updates to section 1:
- Introduction . . . . . . . . . . . . . 9
- 2.2.3.2. RFC 3090 section 2.1: Globally
- Secured. . . . . . . . . . . . . . . . 10
- 2.2.3.3. RFC 3090 section 3: Experimental
- Status . . . . . . . . . . . . . . . . 10
- 2.2.4. NULL KEY elimination. . . . . . . . . . . . . . 10
- 2.3. Comments on Protocol Changes. . . . . . . . . . . . . . 10
- 2.4. Wire Format of the DS record. . . . . . . . . . . . . . 11
- 2.4.1. Justifications for Fields . . . . . . . . . . . 12
- 2.5. Presentation Format of the DS Record. . . . . . . . . . 12
- 2.6. Transition Issues for Installed Base. . . . . . . . . . 12
- 2.6.1. Backwards compatibility with RFC 2535 and
- RFC 1035. . . . . . . . . . . . . . . . . . . . 12
- 2.7. KEY and corresponding DS record example . . . . . . . . 13
- 3. Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 3.1. DS Example" . . . . . . . . . . . . . . . . . . . . . . 14
- 3.2. Resolver Cost Estimates for DS Records" . . . . . . . . 15
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
- 6. Intellectual Property Statement . . . . . . . . . . . . . . . 16
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
- 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 8.1. Normative References. . . . . . . . . . . . . . . . . . 17
- 8.2. Informational References. . . . . . . . . . . . . . . . 17
- 9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18
- 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
-
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 2]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-1. Introduction
-
- Familiarity with the DNS system [RFC1035], DNS security extensions
- [RFC2535], and DNSSEC terminology [RFC3090] is important.
-
- Experience shows that when the same data can reside in two
- administratively different DNS zones, the data frequently gets out of
- sync. The presence of an NS RRset in a zone anywhere other than at
- the apex indicates a zone cut or delegation. The RDATA of the NS
- RRset specifies the authoritative nameservers for the delegated or
- "child" zone. Based on actual measurements, 10-30% of all
- delegations on the Internet have differing NS RRsets at parent and
- child. There are a number of reasons for this, including a lack of
- communication between parent and child and bogus name servers being
- listed to meet registry requirements.
-
- DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
- to have its KEY RRset signed by its parent to create a verifiable
- chain of KEYs. There has been some debate on where the signed KEY
- RRset should reside, whether at the child [RFC2535] or at the parent.
- If the KEY RRset resides at the child, maintaining the signed KEY
- RRset in the child requires frequent two-way communication between
- the two parties. First, the child transmits the KEY RRset to the
- parent and then the parent sends the signature(s) to the child.
- Storing the KEY RRset at the parent was thought to simplify the
- communication.
-
- DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
- an unsecure child zone to indicate that the child is unsecure. A
- NULL KEY record is a waste: an entire signed RRset is used to
- communicate effectively one bit of information - that the child is
- unsecure. Chasing down NULL KEY RRsets complicates the resolution
- process in many cases, because nameservers for both parent and child
- need to be queried for the KEY RRset if the child nameserver does not
- return it. Storing the KEY RRset only in the parent zone simplifies
- this and would allow the elimination of the NULL KEY RRsets entirely.
- For large delegation zones, the cost of NULL keys is a significant
- barrier to deployment.
-
- Prior to the restrictions imposed by RFC 3445 [RFC3445], another
- implication of the DNSSEC key model is that the KEY record could be
- used to store public keys for other protocols in addition to DNSSEC
- keys. There are a number of potential problems with this, including:
-
- 1. The KEY RRset can become quite large if many applications and
- protocols store their keys at the zone apex. Possible protocols
- are IPSEC, HTTP, SMTP, SSH and others that use public key
- cryptography.
-
-
-
-Gudmundsson Standards Track [Page 3]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- 2. The KEY RRset may require frequent updates.
-
- 3. The probability of compromised or lost keys, which trigger
- emergency key roll-over procedures, increases.
-
- 4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
- keys.
-
- 5. The parent may not meet the child's expectations of turnaround
- time for resigning the KEY RRset.
-
- Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
-
-1.2. Reserved Words
-
- 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 [RFC2119].
-
-2. Specification of the Delegation key Signer
-
- This section defines the Delegation Signer (DS) RR type (type code
- 43) and the changes to DNS to accommodate it.
-
-2.1. Delegation Signer Record Model
-
- This document presents a replacement for the DNSSEC KEY record chain
- of trust [RFC2535] that uses a new RR that resides only at the
- parent. This record identifies the key(s) that the child uses to
- self-sign its own KEY RRset.
-
- Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
- and Zone Signing Key (ZSK), there is no requirement that zone uses
- two different keys for these roles. It is expected that many small
- zones will only use one key, while larger zones will be more likely
- to use multiple keys.
-
- The chain of trust is now established by verifying the parent KEY
- RRset, the DS RRset from the parent and the KEY RRset at the child.
- This is cryptographically equivalent to using just KEY records.
-
- Communication between the parent and child is greatly reduced, since
- the child only needs to notify the parent about changes in keys that
- sign its apex KEY RRset. The parent is ignorant of all other keys in
- the child's apex KEY RRset. Furthermore, the child maintains full
- control over the apex KEY RRset and its content. The child can
- maintain any policies regarding its KEY usage for DNSSEC with minimal
- impact on the parent. Thus, if the child wants to have frequent key
-
-
-
-Gudmundsson Standards Track [Page 4]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- roll-over for its DNS zone keys, the parent does not need to be aware
- of it. The child can use one key to sign only its apex KEY RRset and
- a different key to sign the other RRsets in the zone.
-
- This model fits well with a slow roll out of DNSSEC and the islands
- of security model. In this model, someone who trusts "good.example."
- can preconfigure a key from "good.example." as a trusted key, and
- from then on trusts any data signed by that key or that has a chain
- of trust to that key. If "example." starts advertising DS records,
- "good.example." does not have to change operations by suspending
- self-signing. DS records can be used in configuration files to
- identify trusted keys instead of KEY records. Another significant
- advantage is that the amount of information stored in large
- delegation zones is reduced: rather than the NULL KEY record at every
- unsecure delegation demanded by RFC 2535, only secure delegations
- require additional information in the form of a signed DS RRset.
-
- The main disadvantage of this approach is that verifying a zone's KEY
- RRset requires two signature verification operations instead of the
- one in RFC 2535 chain of trust. There is no impact on the number of
- signatures verified for other types of RRsets.
-
-2.2. Protocol Change
-
- All DNS servers and resolvers that support DS MUST support the OK bit
- [RFC3225] and a larger message size [RFC3226]. In order for a
- delegation to be considered secure the delegation MUST contain a DS
- RRset. If a query contains the OK bit, a nameserver returning a
- referral for the delegation MUST include the following RRsets in the
- authority section in this order:
-
- If DS RRset is present:
- parent's copy of child's NS RRset
- DS and SIG(DS)
-
- If no DS RRset is present:
- parent's copy of child's NS RRset
- parent's zone NXT and SIG(NXT)
-
- This increases the size of referral messages, possibly causing some
- or all glue to be omitted. If the DS or NXT RRsets with signatures
- do not fit in the DNS message, the TC bit MUST be set. Additional
- section processing is not changed.
-
- A DS RRset accompanying a NS RRset indicates that the child zone is
- secure. If a NS RRset exists without a DS RRset, the child zone is
- unsecure (from the parents point of view). DS RRsets MUST NOT appear
- at non-delegation points or at a zone's apex.
-
-
-
-Gudmundsson Standards Track [Page 5]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- Section 2.2.1 defines special considerations related to authoritative
- nameservers responding to DS queries and replaces RFC 2535 sections
- 2.3.4 and 3.4. Section 2.2.2 replaces RFC 3008 section 2.7, and
- section 2.2.3 updates RFC 3090.
-
-2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
- Points
-
- DNS security views each zone as a unit of data completely under the
- control of the zone owner with each entry (RRset) signed by a special
- private key held by the zone manager. But the DNS protocol views the
- leaf nodes in a zone that are also the apex nodes of a child zone
- (i.e., delegation points) as "really" belonging to the child zone.
- The corresponding domain names appear in two master files and might
- have RRsets signed by both the parent and child zones' keys. A
- retrieval could get a mixture of these RRsets and SIGs, especially
- since one nameserver could be serving both the zone above and below a
- delegation point [RFC2181].
-
- Each DS RRset stored in the parent zone MUST be signed by at least
- one of the parent zone's private keys. The parent zone MUST NOT
- contain a KEY RRset at any delegation point. Delegations in the
- parent MAY contain only the following RR types: NS, DS, NXT and SIG.
- The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
- case: it will always appear differently and authoritatively in both
- the parent and child zones, if both are secure.
-
- A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
- verifying the DS RRset from the parent, a resolver MAY trust any KEY
- identified in the DS RRset as a valid signer of the child's apex KEY
- RRset. Resolvers configured to trust one of the keys signing the KEY
- RRset MAY now treat any data signed by the zone keys in the KEY RRset
- as secure. In all other cases, resolvers MUST consider the zone
- unsecure.
-
- An authoritative nameserver queried for type DS MUST return the DS
- RRset in the answer section.
-
-2.2.1.1. Special processing for DS queries
-
- When a nameserver is authoritative for the parent zone at a
- delegation point and receives a query for the DS record at that name,
- it MUST answer based on data in the parent zone, return DS or
- negative answer. This is true whether or not it is also
- authoritative for the child zone.
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 6]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- When the nameserver is authoritative for the child zone at a
- delegation point but not the parent zone, there is no natural
- response, since the child zone is not authoritative for the DS record
- at the zone's apex. As these queries are only expected to originate
- from recursive nameservers which are not DS-aware, the authoritative
- nameserver MUST answer with:
-
- RCODE: NOERROR
- AA bit: set
- Answer Section: Empty
- Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
- That is, it answers as if it is authoritative and the DS record does
- not exist. DS-aware recursive nameservers will query the parent zone
- at delegation points, so will not be affected by this.
-
- A nameserver authoritative for only the child zone, that is also a
- caching server MAY (if the RD bit is set in the query) perform
- recursion to find the DS record at the delegation point, or MAY
- return the DS record from its cache. In this case, the AA bit MUST
- NOT be set in the response.
-
-2.2.1.2. Special processing when child and an ancestor share
- nameserver
-
- Special rules are needed to permit DS RR aware nameservers to
- gracefully interact with older caches which otherwise might falsely
- label a nameserver as lame because of the placement of the DS RR set.
-
- Such a situation might arise when a nameserver is authoritative for
- both a zone and it's grandparent, but not the parent. This sounds
- like an obscure example, but it is very real. The root zone is
- currently served on 13 machines, and "root-servers.net." is served on
- 4 of the 13, but "net." is severed on different nameservers.
-
- When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the
- response MUST be determined from reading these rules in order:
-
- 1) If the nameserver is authoritative for the zone that holds the DS
- RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
- zone), the response contains the DS RR set as an authoritative
- answer.
-
- 2) If the nameserver is offering recursive service and the RD bit is
- set in the query, the nameserver performs the query itself
- (according to the rules for resolvers described below) and returns
- its findings.
-
-
-
-
-Gudmundsson Standards Track [Page 7]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- 3) If the nameserver is authoritative for the zone that holds the
- <QNAME>'s SOA RR set, the response is an authoritative negative
- answer as described in 2.2.1.1.
-
- 4) If the nameserver is authoritative for a zone or zones above the
- QNAME, a referral to the most enclosing (deepest match) zone's
- servers is made.
-
- 5) If the nameserver is not authoritative for any part of the QNAME,
- a response indicating a lame nameserver for QNAME is given.
-
- Using these rules will require some special processing on the part of
- a DS RR aware resolver. To illustrate this, an example is used.
-
- Assuming a nameserver is authoritative for roots.example.net. and for
- the root zone but not the intervening two zones (or the intervening
- two label deep zone). Assume that QNAME=roots.example.net.,
- QTYPE=DS, and QCLASS=IN.
-
- The resolver will issue this request (assuming no cached data)
- expecting a referral to a nameserver for .net. Instead, rule number
- 3 above applies and a negative answer is returned by the nameserver.
- The reaction by the resolver is not to accept this answer as final,
- as it can determine from the SOA RR in the negative answer the
- context within which the nameserver has answered.
-
- A solution would be to instruct the resolver to hunt for the
- authoritative zone of the data in a brute force manner.
-
- This can be accomplished by taking the owner name of the returned SOA
- RR and striping off enough left-hand labels until a successful NS
- response is obtained. A successful response here means that the
- answer has NS records in it. (Entertaining the possibility that a
- cut point can be two labels down in a zone.)
-
- Returning to the example, the response will include a negative answer
- with either the SOA RR for "roots.example.net." or "example.net."
- depending on whether roots.example.net is a delegated domain. In
- either case, removing the left most label of the SOA owner name will
- lead to the location of the desired data.
-
-2.2.1.3. Modification on use of KEY RR in the construction of Responses
-
- This section updates RFC 2535 section 3.5 by replacing it with the
- following:
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 8]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- A query for KEY RR MUST NOT trigger any additional section
- processing. Security aware resolvers will include corresponding SIG
- records in the answer section.
-
- KEY records SHOULD NOT be added to the additional records section in
- response to any query.
-
- RFC 2535 specified that KEY records be added to the additional
- section when SOA or NS records were included in an answer. This was
- done to reduce round trips (in the case of SOA) and to force out NULL
- KEYs (in the NS case). As this document obsoletes NULL keys, there
- is no need for the inclusion of KEYs with NSs. Furthermore, as SOAs
- are included in the authority section of negative answers, including
- the KEYs each time will cause redundant transfers of KEYs.
-
- RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
- the response for a query for A and AAAA types. As Restrict KEY
- [RFC3445] eliminated use of KEY RR by all applications, this rule is
- no longer needed.
-
-2.2.2. Signer's Name (replaces RFC 3008 section 2.7)
-
- The signer's name field of a SIG RR MUST contain the name of the zone
- to which the data and signature belong. The combination of signer's
- name, key tag, and algorithm MUST identify a zone key if the SIG is
- to be considered material. This document defines a standard policy
- for DNSSEC validation; local policy MAY override the standard policy.
-
- There are no restrictions on the signer field of a SIG(0) record. The
- combination of signer's name, key tag, and algorithm MUST identify a
- key if this SIG(0) is to be processed.
-
-2.2.3. Changes to RFC 3090
-
- A number of sections in RFC 3090 need to be updated to reflect the DS
- record.
-
-2.2.3.1. RFC 3090: Updates to section 1: Introduction
-
- Most of the text is still relevant but the words "NULL key" are to be
- replaced with "missing DS RRset". In section 1.3, the last three
- paragraphs discuss the confusion in sections of RFC 2535 that are
- replaced in section 2.2.1 above. Therefore, these paragraphs are now
- obsolete.
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 9]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-2.2.3.2. RFC 3090 section 2.1: Globally Secured
-
- Rule 2.1.b is replaced by the following rule:
-
- 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
- private key whose public counterpart MUST appear in a zone signing
- KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
- implement algorithm. This KEY RR MUST be identified by a DS RR in a
- signed DS RRset in the parent zone.
-
- If a zone cannot get its parent to advertise a DS record for it, the
- child zone cannot be considered globally secured. The only exception
- to this is the root zone, for which there is no parent zone.
-
-2.2.3.3. RFC 3090 section 3: Experimental Status.
-
- The only difference between experimental status and globally secured
- is the missing DS RRset in the parent zone. All locally secured
- zones are experimental.
-
-2.2.4. NULL KEY elimination
-
- RFC 3445 section 3 eliminates the top two bits in the flags field of
- KEY RR. These two bits were used to indicate NULL KEY or NO KEY. RFC
- 3090 defines that zone as either secure or not and these rules
- eliminate the need to put NULL keys in the zone apex to indicate that
- the zone is not secured for a algorithm. Along with this document,
- these other two eliminate all uses for the NULL KEY. This document
- obsoletes NULL KEY.
-
-2.3. Comments on Protocol Changes
-
- Over the years, there have been various discussions surrounding the
- DNS delegation model, declaring it to be broken because there is no
- good way to assert if a delegation exists. In the RFC 2535 version
- of DNSSEC, the presence of the NS bit in the NXT bit map proves there
- is a delegation at this name. Something more explicit is required
- and the DS record addresses this need for secure delegations.
-
- The DS record is a major change to DNS: it is the first resource
- record that can appear only on the upper side of a delegation.
- Adding it will cause interoperability problems and requires a flag
- day for DNSSEC. Many old nameservers and resolvers MUST be upgraded
- to take advantage of DS. Some old nameservers will be able to be
- authoritative for zones with DS records but will not add the NXT or
- DS records to the authority section. The same is true for caching
- nameservers; in fact, some might even refuse to pass on the DS or NXT
- records.
-
-
-
-Gudmundsson Standards Track [Page 10]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-2.4. Wire Format of the DS record
-
- The DS (type=43) record contains these fields: key tag, algorithm,
- digest type, and the digest of a public key KEY record that is
- allowed and/or used to sign the child's apex KEY RRset. Other keys
- MAY sign the child's apex KEY RRset.
-
- 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 (length depends on type) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | (SHA-1 digest is 20 bytes) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The key tag is calculated as specified in RFC 2535. Algorithm MUST
- be allowed to sign DNS data. The digest type is an identifier for
- the digest algorithm used. The digest is calculated over the
- canonical name of the delegated domain name followed by the whole
- RDATA of the KEY record (all four fields).
-
- digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
-
- KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
-
- Digest type value 0 is reserved, value 1 is SHA-1, and reserving
- other types requires IETF standards action. For interoperability
- reasons, keeping number of digest algorithms low is strongly
- RECOMMENDED. The only reason to reserve additional digest types is
- to increase security.
-
- DS records MUST point to zone KEY records that are allowed to
- authenticate DNS data. The indicated KEY records protocol field MUST
- be set to 3; flag field bit 7 MUST be set to 1. The value of other
- flag bits is not significant for the purposes of this document.
-
- The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
- of key size. New digest types probably will have larger digests.
-
-
-
-
-
-Gudmundsson Standards Track [Page 11]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-2.4.1. Justifications for Fields
-
- The algorithm and key tag fields are present to allow resolvers to
- quickly identify the candidate KEY records to examine. SHA-1 is a
- strong cryptographic checksum: it is computationally infeasible for
- an attacker to generate a KEY record that has the same SHA-1 digest.
- Combining the name of the key and the key rdata as input to the
- digest provides stronger assurance of the binding. Having the key
- tag in the DS record adds greater assurance than the SHA-1 digest
- alone, as there are now two different mapping functions.
-
- This format allows concise representation of the keys that the child
- will use, thus keeping down the size of the answer for the
- delegation, reducing the probability of DNS message overflow. The
- SHA-1 hash is strong enough to uniquely identify the key and is
- similar to the PGP key footprint. The digest type field is present
- for possible future expansion.
-
- The DS record is well suited to listing trusted keys for islands of
- security in configuration files.
-
-2.5. Presentation Format of the DS Record
-
- The presentation format of the DS record consists of three numbers
- (key tag, algorithm, and digest type) followed by the digest itself
- presented in hex:
-
- example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
-
-2.6. Transition Issues for Installed Base
-
- No backwards compatibility with RFC 2535 is provided.
-
- RFC 2535-compliant resolvers will assume that all DS-secured
- delegations are locally secure. This is bad, but the DNSEXT Working
- Group has determined that rather than dealing with both RFC 2535-
- secured zones and DS-secured zones, a rapid adoption of DS is
- preferable. Thus, the only option for early adopters is to upgrade
- to DS as soon as possible.
-
-2.6.1. Backwards compatibility with RFC 2535 and RFC 1035
-
- This section documents how a resolver determines the type of
- delegation.
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 12]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- RFC 1035 delegation (in parent) has:
-
- RFC 1035 NS
-
- RFC 2535 adds the following two cases:
-
- Secure RFC 2535: NS + NXT + SIG(NXT)
- NXT bit map contains: NS SIG NXT
- Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
- NXT bit map contains: NS SIG KEY NXT
- KEY must be a NULL key.
-
- DNSSEC with DS has the following two states:
-
- Secure DS: NS + DS + SIG(DS)
- NXT bit map contains: NS SIG NXT DS
- Unsecure DS: NS + NXT + SIG(NXT)
- NXT bit map contains: NS SIG NXT
-
- It is difficult for a resolver to determine if a delegation is secure
- RFC 2535 or unsecure DS. This could be overcome by adding a flag to
- the NXT bit map, but only upgraded resolvers would understand this
- flag, anyway. Having both parent and child signatures for a KEY
- RRset might allow old resolvers to accept a zone as secure, but the
- cost of doing this for a long time is much higher than just
- prohibiting RFC 2535-style signatures at child zone apexes and
- forcing rapid deployment of DS-enabled nameservers and resolvers.
-
- RFC 2535 and DS can, in theory, be deployed in parallel, but this
- would require resolvers to deal with RFC 2535 configurations forever.
- This document obsoletes the NULL KEY in parent zones, which is a
- difficult enough change that to cause a flag day.
-
-2.7. KEY and corresponding DS record example
-
- This is an example of a KEY record and the corresponding DS record.
-
- dskey.example. KEY 256 3 1 (
- AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
- 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
- ) ; key id = 28668
- DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
-
-
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 13]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-3. Resolver
-
-3.1. DS Example
-
- To create a chain of trust, a resolver goes from trusted KEY to DS to
- KEY.
-
- Assume the key for domain "example." is trusted. Zone "example."
- contains at least the following records:
- example. SOA <soa stuff>
- example. NS ns.example.
- example. KEY <stuff>
- example. NXT secure.example. NS SOA KEY SIG NXT
- example. SIG(SOA)
- example. SIG(NS)
- example. SIG(NXT)
- example. SIG(KEY)
- secure.example. NS ns1.secure.example.
- secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo>
- secure.example. NXT unsecure.example. NS SIG NXT DS
- secure.example. SIG(NXT)
- secure.example. SIG(DS)
- unsecure.example NS ns1.unsecure.example.
- unsecure.example. NXT example. NS SIG NXT
- unsecure.example. SIG(NXT)
-
- In zone "secure.example." following records exist:
- secure.example. SOA <soa stuff>
- secure.example. NS ns1.secure.example.
- secure.example. KEY <tag=12345 alg=3>
- secure.example. KEY <tag=54321 alg=5>
- secure.example. NXT <nxt stuff>
- secure.example. SIG(KEY) <key-tag=12345 alg=3>
- secure.example. SIG(SOA) <key-tag=54321 alg=5>
- secure.example. SIG(NS) <key-tag=54321 alg=5>
- secure.example. SIG(NXT) <key-tag=54321 alg=5>
-
- In this example, the private key for "example." signs the DS record
- for "secure.example.", making that a secure delegation. The DS
- record states which key is expected to sign the KEY RRset at
- "secure.example.". Here "secure.example." signs its KEY RRset with
- the KEY identified in the DS RRset, thus the KEY RRset is validated
- and trusted.
-
- This example has only one DS record for the child, but parents MUST
- allow multiple DS records to facilitate key roll-over and multiple
- KEY algorithms.
-
-
-
-
-Gudmundsson Standards Track [Page 14]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- The resolver determines the security status of "unsecure.example." by
- examining the parent zone's NXT record for this name. The absence of
- the DS bit indicates an unsecure delegation. Note the NXT record
- SHOULD only be examined after verifying the corresponding signature.
-
-3.2. Resolver Cost Estimates for DS Records
-
- From a RFC 2535 recursive resolver point of view, for each delegation
- followed to chase down an answer, one KEY RRset has to be verified.
- Additional RRsets might also need to be verified based on local
- policy (e.g., the contents of the NS RRset). Once the resolver gets
- to the appropriate delegation, validating the answer might require
- verifying one or more signatures. A simple A record lookup requires
- at least N delegations to be verified and one RRset. For a DS-
- enabled recursive resolver, the cost is 2N+1. For an MX record,
- where the target of the MX record is in the same zone as the MX
- record, the costs are N+2 and 2N+2, for RFC 2535 and DS,
- respectively. In the case of a negative answer, the same ratios hold
- true.
-
- The recursive resolver has to do an extra query to get the DS record,
- which will increase the overall cost of resolving this question, but
- it will never be worse than chasing down NULL KEY records from the
- parent in RFC 2535 DNSSEC.
-
- DS adds processing overhead on resolvers and increases the size of
- delegation answers, but much less than storing signatures in the
- parent zone.
-
-4. Security Considerations
-
- This document proposes a change to the validation chain of KEY
- records in DNSSEC. The change is not believed to reduce security in
- the overall system. In RFC 2535 DNSSEC, the child zone has to
- communicate keys to its parent and prudent parents will require some
- authentication with that transaction. The modified protocol will
- require the same authentication, but allows the child to exert more
- local control over its own KEY RRset.
-
- There is a remote possibility that an attacker could generate a valid
- KEY that matches all the DS fields, of a specific DS set, and thus
- forge data from the child. This possibility is considered
- impractical, as on average more than
-
- 2 ^ (160 - <Number of keys in DS set>)
-
- keys would have to be generated before a match would be found.
-
-
-
-
-Gudmundsson Standards Track [Page 15]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
- An attacker that wants to match any DS record will have to generate
- on average at least 2^80 keys.
-
- The DS record represents a change to the DNSSEC protocol and there is
- an installed base of implementations, as well as textbooks on how to
- set up secure delegations. Implementations that do not understand
- the DS record will not be able to follow the KEY to DS to KEY chain
- and will consider all zones secured that way as unsecure.
-
-5. IANA Considerations
-
- IANA has allocated an RR type code for DS from the standard RR type
- space (type 43).
-
- IANA has established a new registry for the DS RR type for digest
- algorithms. Defined types are:
-
- 0 is Reserved,
- 1 is SHA-1.
-
- Adding new reservations requires IETF standards action.
-
-6. 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 standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- 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 practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 16]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-7. Acknowledgments
-
- Over the last few years a number of people have contributed ideas
- that are captured in this document. The core idea of using one key
- to sign only the KEY RRset comes from discussions with Bill Manning
- and Perry Metzger on how to put in a single root key in all
- resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie,
- Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt
- Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker,
- Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
- Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
- Andrews, Harald Alvestrand, and others have provided useful comments.
-
-8. References
-
-8.1. Normative References
-
- [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.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [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.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
- [RFC3445] Massey, D. and S. Rose, "Limiting the scope of the KEY
- Resource Record (RR)", RFC 3445, December 2002.
-
-8.2. Informational References
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 17]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-9. Author's Address
-
- Olafur Gudmundsson
- 3821 Village Park Drive
- Chevy Chase, MD, 20815
-
- EMail: ds-rfc@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 18]
-
-RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
-
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson Standards Track [Page 19]
-
diff --git a/contrib/bind9/doc/rfc/rfc3757.txt b/contrib/bind9/doc/rfc/rfc3757.txt
deleted file mode 100644
index 31890a4bcbeb6..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3757.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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/rfc3833.txt b/contrib/bind9/doc/rfc/rfc3833.txt
deleted file mode 100644
index 8ce4d34e34198..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3833.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Atkins
-Request for Comments: 3833 IHTFP Consulting
-Category: Informational R. Austein
- ISC
- August 2004
-
-
- Threat Analysis of the Domain Name System (DNS)
-
-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 (2004).
-
-Abstract
-
- Although the DNS Security Extensions (DNSSEC) have been under
- development for most of the last decade, the IETF has never written
- down the specific set of threats against which DNSSEC is designed to
- protect. Among other drawbacks, this cart-before-the-horse situation
- has made it difficult to determine whether DNSSEC meets its design
- goals, since its design goals are not well specified. This note
- attempts to document some of the known threats to the DNS, and, in
- doing so, attempts to measure to what extent (if any) DNSSEC is a
- useful tool in defending against these threats.
-
-1. Introduction
-
- The earliest organized work on DNSSEC within the IETF was an open
- design team meeting organized by members of the DNS working group in
- November 1993 at the 28th IETF meeting in Houston. The broad
- outlines of DNSSEC as we know it today are already clear in Jim
- Galvin's summary of the results of that meeting [Galvin93]:
-
- - While some participants in the meeting were interested in
- protecting against disclosure of DNS data to unauthorized parties,
- the design team made an explicit decision that "DNS data is
- `public'", and ruled all threats of data disclosure explicitly out
- of scope for DNSSEC.
-
- - While some participants in the meeting were interested in
- authentication of DNS clients and servers as a basis for access
- control, this work was also ruled out of scope for DNSSEC per se.
-
-
-
-Atkins & Austein Informational [Page 1]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- - Backwards compatibility and co-existence with "insecure DNS" was
- listed as an explicit requirement.
-
- - The resulting list of desired security services was
- 1) data integrity, and
- 2) data origin authentication.
-
- - The design team noted that a digital signature mechanism would
- support the desired services.
-
- While a number of detail decisions were yet to be made (and in some
- cases remade after implementation experience) over the subsequent
- decade, the basic model and design goals have remained fixed.
-
- Nowhere, however, does any of the DNSSEC work attempt to specify in
- any detail the sorts of attacks against which DNSSEC is intended to
- protect, or the reasons behind the list of desired security services
- that came out of the Houston meeting. For that, we have to go back
- to a paper originally written by Steve Bellovin in 1990 but not
- published until 1995, for reasons that Bellovin explained in the
- paper's epilogue [Bellovin95].
-
- While it may seem a bit strange to publish the threat analysis a
- decade after starting work on the protocol designed to defend against
- it, that is, nevertheless, what this note attempts to do. Better
- late than never.
-
- This note assumes that the reader is familiar with both the DNS and
- with DNSSEC, and does not attempt to provide a tutorial on either.
- The DNS documents most relevant to the subject of this note are:
- [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
- [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
-
- For purposes of discussion, this note uses the term "DNSSEC" to refer
- to the core hierarchical public key and signature mechanism specified
- in the DNSSEC documents, and refers to TKEY and TSIG as separate
- mechanisms, even though channel security mechanisms such as TKEY and
- TSIG are also part of the larger problem of "securing DNS" and thus
- are often considered part of the overall set of "DNS security
- extensions". This is an arbitrary distinction that in part reflects
- the way in which the protocol has evolved (introduction of a
- putatively simpler channel security model for certain operations such
- as zone transfers and dynamic update requests), and perhaps should be
- changed in a future revision of this note.
-
-
-
-
-
-
-
-Atkins & Austein Informational [Page 2]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
-2. Known Threats
-
- There are several distinct classes of threats to the DNS, most of
- which are DNS-related instances of more general problems, but a few
- of which are specific to peculiarities of the DNS protocol.
-
-2.1. Packet Interception
-
- Some of the simplest threats against DNS are various forms of packet
- interception: monkey-in-the-middle attacks, eavesdropping on requests
- combined with spoofed responses that beat the real response back to
- the resolver, and so forth. In any of these scenarios, the attacker
- can simply tell either party (usually the resolver) whatever it wants
- that party to believe. While packet interception attacks are far
- from unique to DNS, DNS's usual behavior of sending an entire query
- or response in a single unsigned, unencrypted UDP packet makes these
- attacks particularly easy for any bad guy with the ability to
- intercept packets on a shared or transit network.
-
- To further complicate things, the DNS query the attacker intercepts
- may just be a means to an end for the attacker: the attacker might
- even choose to return the correct result in the answer section of a
- reply message while using other parts of the message to set the stage
- for something more complicated, for example, a name chaining attack
- (see section 2.3).
-
- While it certainly would be possible to sign DNS messages using a
- channel security mechanism such as TSIG or IPsec, or even to encrypt
- them using IPsec, this would not be a very good solution for
- interception attacks. First, this approach would impose a fairly
- high processing cost per DNS message, as well as a very high cost
- associated with establishing and maintaining bilateral trust
- relationships between all the parties that might be involved in
- resolving any particular query. For heavily used name servers (such
- as the servers for the root zone), this cost would almost certainly
- be prohibitively high. Even more important, however, is that the
- underlying trust model in such a design would be wrong, since at best
- it would only provide a hop-by-hop integrity check on DNS messages
- and would not provide any sort of end-to-end integrity check between
- the producer of DNS data (the zone administrator) and the consumer of
- DNS data (the application that triggered the query).
-
- By contrast, DNSSEC (when used properly) does provide an end-to-end
- data integrity check, and is thus a much better solution for this
- class of problems during basic DNS lookup operations.
-
-
-
-
-
-
-Atkins & Austein Informational [Page 3]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- TSIG does have its place in corners of the DNS protocol where there's
- a specific trust relationship between a particular client and a
- particular server, such as zone transfer, dynamic update, or a
- resolver (stub or otherwise) that is not going to check all the
- DNSSEC signatures itself.
-
- Note that DNSSEC does not provide any protection against modification
- of the DNS message header, so any properly paranoid resolver must:
-
- - Perform all of the DNSSEC signature checking on its own,
-
- - Use TSIG (or some equivalent mechanism) to ensure the integrity of
- its communication with whatever name servers it chooses to trust,
- or
-
- - Resign itself to the possibility of being attacked via packet
- interception (and via other techniques discussed below).
-
-2.2. ID Guessing and Query Prediction
-
- Since DNS is for the most part used over UDP/IP, it is relatively
- easy for an attacker to generate packets which will match the
- transport protocol parameters. The ID field in the DNS header is
- only a 16-bit field and the server UDP port associated with DNS is a
- well-known value, so there are only 2**32 possible combinations of ID
- and client UDP port for a given client and server. This is not a
- particularly large range, and is not sufficient to protect against a
- brute force search; furthermore, in practice both the client UDP port
- and the ID can often be predicted from previous traffic, and it is
- not uncommon for the client port to be a known fixed value as well
- (due to firewalls or other restrictions), thus frequently reducing
- the search space to a range smaller than 2**16.
-
- By itself, ID guessing is not enough to allow an attacker to inject
- bogus data, but combined with knowledge (or guesses) about QNAMEs and
- QTYPEs for which a resolver might be querying, this leaves the
- resolver only weakly defended against injection of bogus responses.
-
- Since this attack relies on predicting a resolver's behavior, it's
- most likely to be successful when the victim is in a known state,
- whether because the victim rebooted recently, or because the victim's
- behavior has been influenced by some other action by the attacker, or
- because the victim is responding (in a predictable way) to some third
- party action known to the attacker.
-
-
-
-
-
-
-
-Atkins & Austein Informational [Page 4]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- This attack is both more and less difficult for the attacker than the
- simple interception attack described above: more difficult, because
- the attack only works when the attacker guesses correctly; less
- difficult, because the attacker doesn't need to be on a transit or
- shared network.
-
- In most other respects, this attack is similar to a packet
- interception attack. A resolver that checks DNSSEC signatures will
- be able to detect the forged response; resolvers that do not perform
- DNSSEC signature checking themselves should use TSIG or some
- equivalent mechanism to ensure the integrity of their communication
- with a recursive name server that does perform DNSSEC signature
- checking.
-
-2.3. Name Chaining
-
- Perhaps the most interesting class of DNS-specific threats are the
- name chaining attacks. These are a subset of a larger class of
- name-based attacks, sometimes called "cache poisoning" attacks. Most
- name-based attacks can be partially mitigated by the long-standing
- defense of checking RRs in response messages for relevance to the
- original query, but such defenses do not catch name chaining attacks.
- There are several variations on the basic attack, but what they all
- have in common is that they all involve DNS RRs whose RDATA portion
- (right hand side) includes a DNS name (or, in a few cases, something
- that is not a DNS name but which directly maps to a DNS name). Any
- such RR is, at least in principle, a hook that lets an attacker feed
- bad data into a victim's cache, thus potentially subverting
- subsequent decisions based on DNS names.
-
- The worst examples in this class of RRs are CNAME, NS, and DNAME RRs
- because they can redirect a victim's query to a location of the
- attacker's choosing. RRs like MX and SRV are somewhat less
- dangerous, but in principle they can also be used to trigger further
- lookups at a location of the attacker's choosing. Address RR types
- such as A or AAAA don't have DNS names in their RDATA, but since the
- IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of
- IPv4 and IPv6 addresses, these record types can also be used in a
- name chaining attack.
-
- The general form of a name chaining attack is something like this:
-
- - Victim issues a query, perhaps at the instigation of the attacker
- or some third party; in some cases the query itself may be
- unrelated to the name under attack (that is, the attacker is just
- using this query as a means to inject false information about some
- other name).
-
-
-
-
-Atkins & Austein Informational [Page 5]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- - Attacker injects response, whether via packet interception, query
- guessing, or by being a legitimate name server that's involved at
- some point in the process of answering the query that the victim
- issued.
-
- - Attacker's response includes one or more RRs with DNS names in
- their RDATA; depending on which particular form this attack takes,
- the object may be to inject false data associated with those names
- into the victim's cache via the Additional section of this
- response, or may be to redirect the next stage of the query to a
- server of the attacker's choosing (in order to inject more complex
- lies into the victim's cache than will fit easily into a single
- response, or in order to place the lies in the Authority or Answer
- section of a response where they will have a better chance of
- sneaking past a resolver's defenses).
-
- Any attacker who can insert resource records into a victim's cache
- can almost certainly do some kind of damage, so there are cache
- poisoning attacks which are not name chaining attacks in the sense
- discussed here. However, in the case of name chaining attacks, the
- cause and effect relationship between the initial attack and the
- eventual result may be significantly more complex than in the other
- forms of cache poisoning, so name chaining attacks merit special
- attention.
-
- The common thread in all of the name chaining attacks is that
- response messages allow the attacker to introduce arbitrary DNS names
- of the attacker's choosing and provide further information that the
- attacker claims is associated with those names; unless the victim has
- better knowledge of the data associated with those names, the victim
- is going to have a hard time defending against this class of attacks.
-
- This class of attack is particularly insidious given that it's quite
- easy for an attacker to provoke a victim into querying for a
- particular name of the attacker's choosing, for example, by embedding
- a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
- to the victim. If the victim's mail reading program attempts to
- follow such a link, the result will be a DNS query for a name chosen
- by the attacker.
-
- DNSSEC should provide a good defense against most (all?) variations
- on this class of attack. By checking signatures, a resolver can
- determine whether the data associated with a name really was inserted
- by the delegated authority for that portion of the DNS name space.
- More precisely, a resolver can determine whether the entity that
- injected the data had access to an allegedly secret key whose
-
-
-
-
-
-Atkins & Austein Informational [Page 6]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- corresponding public key appears at an expected location in the DNS
- name space with an expected chain of parental signatures that start
- with a public key of which the resolver has prior knowledge.
-
- DNSSEC signatures do not cover glue records, so there's still a
- possibility of a name chaining attack involving glue, but with DNSSEC
- it is possible to detect the attack by temporarily accepting the glue
- in order to fetch the signed authoritative version of the same data,
- then checking the signatures on the authoritative version.
-
-2.4. Betrayal By Trusted Server
-
- Another variation on the packet interception attack is the trusted
- server that turns out not to be so trustworthy, whether by accident
- or by intent. Many client machines are only configured with stub
- resolvers, and use trusted servers to perform all of their DNS
- queries on their behalf. In many cases the trusted server is
- furnished by the user's ISP and advertised to the client via DHCP or
- PPP options. Besides accidental betrayal of this trust relationship
- (via server bugs, successful server break-ins, etc), the server
- itself may be configured to give back answers that are not what the
- user would expect, whether in an honest attempt to help the user or
- to promote some other goal such as furthering a business partnership
- between the ISP and some third party.
-
- This problem is particularly acute for frequent travelers who carry
- their own equipment and expect it to work in much the same way
- wherever they go. Such travelers need trustworthy DNS service
- without regard to who operates the network into which their equipment
- is currently plugged or what brand of middle boxes the local
- infrastructure might use.
-
- While the obvious solution to this problem would be for the client to
- choose a more trustworthy server, in practice this may not be an
- option for the client. In many network environments a client machine
- has only a limited set of recursive name servers from which to
- choose, and none of them may be particularly trustworthy. In extreme
- cases, port filtering or other forms of packet interception may
- prevent the client host from being able to run an iterative resolver
- even if the owner of the client machine is willing and able to do so.
- Thus, while the initial source of this problem is not a DNS protocol
- attack per se, this sort of betrayal is a threat to DNS clients, and
- simply switching to a different recursive name server is not an
- adequate defense.
-
- Viewed strictly from the DNS protocol standpoint, the only difference
- between this sort of betrayal and a packet interception attack is
- that in this case the client has voluntarily sent its request to the
-
-
-
-Atkins & Austein Informational [Page 7]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- attacker. The defense against this is the same as with a packet
- interception attack: the resolver must either check DNSSEC signatures
- itself or use TSIG (or equivalent) to authenticate the server that it
- has chosen to trust. Note that use of TSIG does not by itself
- guarantee that a name server is at all trustworthy: all TSIG can do
- is help a resolver protect its communication with a name server that
- it has already decided to trust for other reasons. Protecting a
- resolver's communication with a server that's giving out bogus
- answers is not particularly useful.
-
- Also note that if the stub resolver does not trust the name server
- that is doing work on its behalf and wants to check the DNSSEC
- signatures itself, the resolver really does need to have independent
- knowledge of the DNSSEC public key(s) it needs in order to perform
- the check. Usually the public key for the root zone is enough, but
- in some cases knowledge of additional keys may also be appropriate.
-
- It is difficult to escape the conclusion that a properly paranoid
- resolver must always perform its own signature checking, and that
- this rule even applies to stub resolvers.
-
-2.5. Denial of Service
-
- As with any network service (or, indeed, almost any service of any
- kind in any domain of discourse), DNS is vulnerable to denial of
- service attacks. DNSSEC does not help this, and may in fact make the
- problem worse for resolvers that check signatures, since checking
- signatures both increases the processing cost per DNS message and in
- some cases can also increase the number of messages needed to answer
- a query. TSIG (and similar mechanisms) have equivalent problems.
-
- DNS servers are also at risk of being used as denial of service
- amplifiers, since DNS response packets tend to be significantly
- longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help
- here either.
-
-2.6. Authenticated Denial of Domain Names
-
- Much discussion has taken place over the question of authenticated
- denial of domain names. The particular question is whether there is
- a requirement for authenticating the non-existence of a name. The
- issue is whether the resolver should be able to detect when an
- attacker removes RRs from a response.
-
- General paranoia aside, the existence of RR types whose absence
- causes an action other than immediate failure (such as missing MX and
- SRV RRs, which fail over to A RRs) constitutes a real threat.
- Arguably, in some cases, even the absence of an RR might be
-
-
-
-Atkins & Austein Informational [Page 8]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- considered a problem. The question remains: how serious is this
- threat? Clearly the threat does exist; general paranoia says that
- some day it'll be on the front page of some major newspaper, even if
- we cannot conceive of a plausible scenario involving this attack
- today. This implies that some mitigation of this risk is required.
-
- Note that it's necessary to prove the non-existence of applicable
- wildcard RRs as part of the authenticated denial mechanism, and that,
- in a zone that is more than one label deep, such a proof may require
- proving the non-existence of multiple discrete sets of wildcard RRs.
-
- DNSSEC does include mechanisms which make it possible to determine
- which authoritative names exist in a zone, and which authoritative
- resource record types exist at those names. The DNSSEC protections
- do not cover non-authoritative data such as glue records.
-
-2.7. Wildcards
-
- Much discussion has taken place over whether and how to provide data
- integrity and data origin authentication for "wildcard" DNS names.
- Conceptually, RRs with wildcard names are patterns for synthesizing
- RRs on the fly according to the matching rules described in section
- 4.3.2 of RFC 1034. While the rules that control the behavior of
- wildcard names have a few quirks that can make them a trap for the
- unwary zone administrator, it's clear that a number of sites make
- heavy use of wildcard RRs, particularly wildcard MX RRs.
-
- In order to provide the desired services for wildcard RRs, we need to
- do two things:
-
- - We need a way to attest to the existence of the wildcard RR itself
- (that is, we need to show that the synthesis rule exists), and
-
- - We need a way to attest to the non-existence of any RRs which, if
- they existed, would make the wildcard RR irrelevant according to
- the synthesis rules that govern the way in which wildcard RRs are
- used (that is, we need to show that the synthesis rule is
- applicable).
-
- Note that this makes the wildcard mechanisms dependent upon the
- authenticated denial mechanism described in the previous section.
-
- DNSSEC includes mechanisms along the lines described above, which
- make it possible for a resolver to verify that a name server applied
- the wildcard expansion rules correctly when generating an answer.
-
-
-
-
-
-
-Atkins & Austein Informational [Page 9]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
-3. Weaknesses of DNSSEC
-
- DNSSEC has some problems of its own:
-
- - DNSSEC is complex to implement and includes some nasty edge cases
- at the zone cuts that require very careful coding. Testbed
- experience to date suggests that trivial zone configuration errors
- or expired keys can cause serious problems for a DNSSEC-aware
- resolver, and that the current protocol's error reporting
- capabilities may leave something to be desired.
-
- - DNSSEC significantly increases the size of DNS response packets;
- among other issues, this makes DNSSEC-aware DNS servers even more
- effective as denial of service amplifiers.
-
- - DNSSEC answer validation increases the resolver's work load, since
- a DNSSEC-aware resolver will need to perform signature validation
- and in some cases will also need to issue further queries. This
- increased workload will also increase the time it takes to get an
- answer back to the original DNS client, which is likely to trigger
- both timeouts and re-queries in some cases. Arguably, many current
- DNS clients are already too impatient even before taking the
- further delays that DNSSEC will impose into account, but that topic
- is beyond the scope of this note.
-
- - Like DNS itself, DNSSEC's trust model is almost totally
- hierarchical. While DNSSEC does allow resolvers to have special
- additional knowledge of public keys beyond those for the root, in
- the general case the root key is the one that matters. Thus any
- compromise in any of the zones between the root and a particular
- target name can damage DNSSEC's ability to protect the integrity of
- data owned by that target name. This is not a change, since
- insecure DNS has the same model.
-
- - Key rollover at the root is really hard. Work to date has not even
- come close to adequately specifying how the root key rolls over, or
- even how it's configured in the first place.
-
- - DNSSEC creates a requirement of loose time synchronization between
- the validating resolver and the entity creating the DNSSEC
- signatures. Prior to DNSSEC, all time-related actions in DNS could
- be performed by a machine that only knew about "elapsed" or
- "relative" time. Because the validity period of a DNSSEC signature
- is based on "absolute" time, a validating resolver must have the
- same concept of absolute time as the zone signer in order to
- determine whether the signature is within its validity period or
- has expired. An attacker that can change a resolver's opinion of
- the current absolute time can fool the resolver using expired
-
-
-
-Atkins & Austein Informational [Page 10]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- signatures. An attacker that can change the zone signer's opinion
- of the current absolute time can fool the zone signer into
- generating signatures whose validity period does not match what the
- signer intended.
-
- - The possible existence of wildcard RRs in a zone complicates the
- authenticated denial mechanism considerably. For most of the
- decade that DNSSEC has been under development these issues were
- poorly understood. At various times there have been questions as
- to whether the authenticated denial mechanism is completely
- airtight and whether it would be worthwhile to optimize the
- authenticated denial mechanism for the common case in which
- wildcards are not present in a zone. However, the main problem is
- just the inherent complexity of the wildcard mechanism itself.
- This complexity probably makes the code for generating and checking
- authenticated denial attestations somewhat fragile, but since the
- alternative of giving up wildcards entirely is not practical due to
- widespread use, we are going to have to live with wildcards. The
- question just becomes one of whether or not the proposed
- optimizations would make DNSSEC's mechanisms more or less fragile.
-
- - Even with DNSSEC, the class of attacks discussed in section 2.4 is
- not easy to defeat. In order for DNSSEC to be effective in this
- case, it must be possible to configure the resolver to expect
- certain categories of DNS records to be signed. This may require
- manual configuration of the resolver, especially during the initial
- DNSSEC rollout period when the resolver cannot reasonably expect
- the root and TLD zones to be signed.
-
-4. Topics for Future Work
-
- This section lists a few subjects not covered above which probably
- need additional study, additional mechanisms, or both.
-
-4.1. Interactions With Other Protocols
-
- The above discussion has concentrated exclusively on attacks within
- the boundaries of the DNS protocol itself, since those are (some of)
- the problems against which DNSSEC was intended to protect. There
- are, however, other potential problems at the boundaries where DNS
- interacts with other protocols.
-
-4.2. Securing DNS Dynamic Update
-
- DNS dynamic update opens a number of potential problems when combined
- with DNSSEC. Dynamic update of a non-secure zone can use TSIG to
- authenticate the updating client to the server. While TSIG does not
- scale very well (it requires manual configuration of shared keys
-
-
-
-Atkins & Austein Informational [Page 11]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- between the DNS name server and each TSIG client), it works well in a
- limited or closed environment such as a DHCP server updating a local
- DNS name server.
-
- Major issues arise when trying to use dynamic update on a secure
- zone. TSIG can similarly be used in a limited fashion to
- authenticate the client to the server, but TSIG only protects DNS
- transactions, not the actual data, and the TSIG is not inserted into
- the DNS zone, so resolvers cannot use the TSIG as a way of verifying
- the changes to the zone. This means that either:
-
- a) The updating client must have access to a zone-signing key in
- order to sign the update before sending it to the server, or
-
- b) The DNS name server must have access to an online zone-signing key
- in order to sign the update.
-
- In either case, a zone-signing key must be available to create signed
- RRsets to place in the updated zone. The fact that this key must be
- online (or at least available) is a potential security risk.
-
- Dynamic update also requires an update to the SERIAL field of the
- zone's SOA RR. In theory, this could also be handled via either of
- the above options, but in practice (a) would almost certainly be
- extremely fragile, so (b) is the only workable mechanism.
-
- There are other threats in terms of describing the policy of who can
- make what changes to which RRsets in the zone. The current access
- control scheme in Secure Dynamic Update is fairly limited. There is
- no way to give fine-grained access to updating DNS zone information
- to multiple entities, each of whom may require different kinds of
- access. For example, Alice may need to be able to add new nodes to
- the zone or change existing nodes, but not remove them; Bob may need
- to be able to remove zones but not add them; Carol may need to be
- able to add, remove, or modify nodes, but only A records.
-
- Scaling properties of the key management problem here are a
- particular concern that needs more study.
-
-4.3. Securing DNS Zone Replication
-
- As discussed in previous sections, DNSSEC per se attempts to provide
- data integrity and data origin authentication services on top of the
- normal DNS query protocol. Using the terminology discussed in
- [RFC3552], DNSSEC provides "object security" for the normal DNS query
- protocol. For purposes of replicating entire DNS zones, however,
- DNSSEC does not provide object security, because zones include
- unsigned NS RRs and glue at delegation points. Use of TSIG to
-
-
-
-Atkins & Austein Informational [Page 12]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- protect zone transfer (AXFR or IXFR) operations provides "channel
- security", but still does not provide object security for complete
- zones. The trust relationships involved in zone transfer are still
- very much a hop-by-hop matter of name server operators trusting other
- name server operators rather than an end-to-end matter of name server
- operators trusting zone administrators.
-
- Zone object security was not an explicit design goal of DNSSEC, so
- failure to provide this service should not be a surprise.
- Nevertheless, there are some zone replication scenarios for which
- this would be a very useful additional service, so this seems like a
- useful area for future work. In theory it should not be difficult to
- add zone object security as a backwards compatible enhancement to the
- existing DNSSEC model, but the DNSEXT WG has not yet discussed either
- the desirability of or the requirements for such an enhancement.
-
-5. Conclusion
-
- Based on the above analysis, the DNSSEC extensions do appear to solve
- a set of problems that do need to be solved, and are worth deploying.
-
-Security Considerations
-
- This entire document is about security considerations of the DNS.
- The authors believe that deploying DNSSEC will help to address some,
- but not all, of the known threats to the DNS.
-
-Acknowledgments
-
- This note is based both on previous published works by others and on
- a number of discussions both public and private over a period of many
- years, but particular thanks go to
-
- Jaap Akkerhuis,
- Steve Bellovin,
- Dan Bernstein,
- Randy Bush,
- Steve Crocker,
- Olafur Gudmundsson,
- Russ Housley,
- Rip Loomis,
- Allison Mankin,
- Paul Mockapetris,
- Thomas Narten
- Mans Nilsson,
- Pekka Savola,
- Paul Vixie,
- Xunhua Wang,
-
-
-
-Atkins & Austein Informational [Page 13]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
- and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
- groups whose names and contributions the authors have forgotten, none
- of whom are responsible for what the authors did with their ideas.
-
- As with any work of this nature, the authors of this note acknowledge
- that we are standing on the toes of those who have gone before us.
- Readers interested in this subject may also wish to read
- [Bellovin95], [Schuba93], and [Vixie95].
-
-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.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts -
- Application and Support", STD 3, RFC 1123, October 1989.
-
- [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.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for
- DNS (TSIG)", RFC 2845, May 2000.
-
- [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS
- (TKEY RR)", RFC 2930, September 2000.
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [RFC2535] Eastlake 3rd, D., "Domain Name System Security
- Extensions", RFC 2535, March 1999.
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein Informational [Page 14]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
-Informative References
-
- [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
- Text on Security Considerations", BCP 72, RFC 3552, July
- 2003.
-
- [Bellovin95] Bellovin, S., "Using the Domain Name System for System
- Break-Ins", Proceedings of the Fifth Usenix Unix
- Security Symposium, June 1995.
-
- [Galvin93] Design team meeting summary message posted to dns-
- security@tis.com mailing list by Jim Galvin on 19
- November 1993.
-
- [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name
- System Protocol", Master's thesis, Purdue University
- Department of Computer Sciences, August 1993.
-
- [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
- the Fifth Usenix Unix Security Symposium, June 1995.
-
-Authors' Addresses
-
- Derek Atkins
- IHTFP Consulting, Inc.
- 6 Farragut Ave
- Somerville, MA 02144
- USA
-
- EMail: derek@ihtfp.com
-
-
- Rob Austein
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- EMail: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein Informational [Page 15]
-
-RFC 3833 DNS Threat Analysis August 2004
-
-
-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.
-
-
-
-
-
-
-
-
-
-Atkins & Austein Informational [Page 16]
-
diff --git a/contrib/bind9/doc/rfc/rfc3845.txt b/contrib/bind9/doc/rfc/rfc3845.txt
deleted file mode 100644
index 9887a20af0b5e..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3845.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Schlyter, Ed.
-Request for Comments: 3845 August 2004
-Updates: 3755, 2535
-Category: Standards Track
-
-
- DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
-
-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).
-
-Abstract
-
- This document redefines the wire format of the "Type Bit Map" field
- in the DNS NextSECure (NSEC) resource record RDATA format to cover
- the full resource record (RR) type space.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 2
- 2.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . 3
- 2.1.1. The Next Domain Name Field . . . . . . . . . . . 3
- 2.1.2. The List of Type Bit Map(s) Field . . . . . . . 3
- 2.1.3. Inclusion of Wildcard Names in NSEC RDATA . . . 4
- 2.2. The NSEC RR Presentation Format . . . . . . . . . . . . 4
- 2.3. NSEC RR Example . . . . . . . . . . . . . . . . . . . . 5
- 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
- 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5.1. Normative References . . . . . . . . . . . . . . . . . . 6
- 5.2. Informative References . . . . . . . . . . . . . . . . . 6
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
- 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
- 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
-
-
-
-
-
-
-
-Schlyter, Ed. Standards Track [Page 1]
-
-RFC 3845 DNSSEC NSEC RDATA Format August 2004
-
-
-1. Introduction
-
- The DNS [6][7] NSEC [5] Resource Record (RR) is used for
- authenticated proof of the non-existence of DNS owner names and
- types. The NSEC RR is based on the NXT RR as described in RFC 2535
- [2], and is similar except for the name and typecode. The RDATA
- format for the NXT RR has the limitation in that the RDATA could only
- carry information about the existence of the first 127 types. RFC
- 2535 did reserve a bit to specify an extension mechanism, but the
- mechanism was never actually defined.
-
- In order to avoid needing to develop an extension mechanism into a
- deployed base of DNSSEC aware servers and resolvers once the first
- 127 type codes are allocated, this document redefines the wire format
- of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
- type space.
-
- This document introduces a new format for the type bit map. The
- properties of the type bit map format are that it can cover the full
- possible range of typecodes, that it is relatively economical in the
- amount of space it uses for the common case of a few types with an
- owner name, that it can represent owner names with all possible types
- present in packets of approximately 8.5 kilobytes, and that the
- representation is simple to implement. Efficient searching of the
- type bitmap for the presence of certain types is not a requirement.
-
- For convenience and completeness, this document presents the syntax
- and semantics for the NSEC RR based on the specification in RFC 2535
- [2] and as updated by RFC 3755 [5], thereby not introducing changes
- except for the syntax of the type bit map.
-
- This document updates RFC 2535 [2] and RFC 3755 [5].
-
- 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, RFC 2119 [1].
-
-2. The NSEC Resource Record
-
- The NSEC resource record lists two separate things: the owner name of
- the next RRset in the canonical ordering of the zone, and the set of
- RR types present at the NSEC RR's owner name. The complete set of
- NSEC RRs in a zone indicate which RRsets exist in a zone, and form a
- chain of owner names in the zone. This information is used to
- provide authenticated denial of existence for DNS data, as described
- in RFC 2535 [2].
-
- The type value for the NSEC RR is 47.
-
-
-
-Schlyter, Ed. Standards Track [Page 2]
-
-RFC 3845 DNSSEC NSEC RDATA Format August 2004
-
-
- The NSEC RR RDATA format is class independent and defined for all
- classes.
-
- The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirit of negative caching [8].
-
-2.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 /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / List of Type Bit Map(s) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-2.1.1. The Next Domain Name Field
-
- The Next Domain Name field contains the owner name of the next RR in
- the canonical ordering of the zone. 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).
-
- A sender MUST NOT use DNS name compression on the Next Domain Name
- field when transmitting an NSEC RR.
-
- Owner names of RRsets that are not authoritative for the given zone
- (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.
-
-2.1.2. The List of Type Bit Map(s) Field
-
- 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.
-
- Window blocks are present in the NSEC RR RDATA in increasing
- numerical order.
-
- "|" denotes concatenation
-
- Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-Schlyter, Ed. Standards Track [Page 3]
-
-RFC 3845 DNSSEC NSEC RDATA Format August 2004
-
-
- 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 to 1, it indicates that an RRset of that type is present for the
- NSEC RR's owner name. If a bit is set to 0, it indicates that no
- RRset of that type is present for the NSEC RR's owner name.
-
- 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 [3]
- (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 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
- NSEC RR's owner name. Trailing zero octets not specified MUST be
- interpreted as zero octets.
-
-2.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 purposes of generating NSEC RRs. Wildcard owner names
- appear in the Next Domain Name field without any wildcard expansion.
- RFC 2535 [2] describes the impact of wildcards on authenticated
- denial of existence.
-
-2.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 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 [4] (section 5) MUST be used.
-
-
-
-
-
-
-
-
-Schlyter, Ed. Standards Track [Page 4]
-
-RFC 3845 DNSSEC NSEC RDATA Format August 2004
-
-
-2.3. NSEC RR Example
-
- The following NSEC RR identifies the RRsets associated with
- alfa.example.com. and 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 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 resolver can authenticate this NSEC record, it
- could be used to prove that beta.example.com does not exist, or could
- be used to prove that there is no AAAA record associated with
- alfa.example.com. Authenticated denial of existence is discussed in
- RFC 2535 [2].
-
-3. IANA Considerations
-
- This document introduces no new IANA considerations, because all of
- the protocol parameters used in this document have already been
- assigned by RFC 3755 [5].
-
-4. Security Considerations
-
- The update of the RDATA format and encoding does not affect the
- security of the use of NSEC RRs.
-
-
-
-
-
-
-
-
-
-Schlyter, Ed. Standards Track [Page 5]
-
-RFC 3845 DNSSEC NSEC RDATA Format August 2004
-
-
-5. References
-
-5.1. Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [3] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain
- Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
- September 2000.
-
- [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
- [5] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
- (DS)", RFC 3755, May 2004.
-
-5.2. Informative References
-
- [6] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [7] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
- 2308, March 1998.
-
-6. Acknowledgements
-
- The encoding described in this document was initially proposed by
- Mark Andrews. Other encodings where proposed by David Blacka and
- Michael Graff.
-
-7. Author's Address
-
- Jakob Schlyter (editor)
- NIC-SE
- Box 5774
- Stockholm SE-114 87
- Sweden
-
- EMail: jakob@nic.se
- URI: http://www.nic.se/
-
-
-
-
-Schlyter, Ed. Standards Track [Page 6]
-
-RFC 3845 DNSSEC NSEC RDATA Format August 2004
-
-
-8. 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.
-
-
-
-
-
-
-
-Schlyter, Ed. Standards Track [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3901.txt b/contrib/bind9/doc/rfc/rfc3901.txt
deleted file mode 100644
index 43b7356e6adfc..0000000000000
--- a/contrib/bind9/doc/rfc/rfc3901.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 92e7f40079562..0000000000000
--- a/contrib/bind9/doc/rfc/rfc4025.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 7f0a46477319d..0000000000000
--- a/contrib/bind9/doc/rfc/rfc4033.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Arends
-Request for Comments: 4033 Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
- 3755, 3757, 3845 ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
- 3007, 3597, 3226 VeriSign
-Category: Standards Track D. Massey
- Colorado State University
- S. Rose
- NIST
- March 2005
-
-
- DNS Security Introduction and Requirements
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- The Domain Name System Security Extensions (DNSSEC) add data origin
- authentication and data integrity to the Domain Name System. This
- document introduces these extensions and describes their capabilities
- and limitations. This document also discusses the services that the
- DNS security extensions do and do not provide. Last, this document
- describes the interrelationships between the documents that
- collectively describe DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 1]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3
- 3. Services Provided by DNS Security . . . . . . . . . . . . . 7
- 3.1. Data Origin Authentication and Data Integrity . . . . 7
- 3.2. Authenticating Name and Type Non-Existence . . . . . . 9
- 4. Services Not Provided by DNS Security . . . . . . . . . . . 9
- 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9
- 6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10
- 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11
- 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12
- 8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13
- 8.2. New Temporal Dependency Issues for Zones . . . . . . . 13
- 9. Name Server Considerations . . . . . . . . . . . . . . . . . 13
- 10. DNS Security Document Family . . . . . . . . . . . . . . . . 14
- 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
- 12. Security Considerations . . . . . . . . . . . . . . . . . . 15
- 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
- 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 14.1. Normative References . . . . . . . . . . . . . . . . . 17
- 14.2. Informative References . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
-
-1. Introduction
-
- This document introduces the Domain Name System Security Extensions
- (DNSSEC). This document and its two companion documents ([RFC4034]
- and [RFC4035]) update, clarify, and refine the security extensions
- defined in [RFC2535] and its predecessors. These security extensions
- consist of a set of new resource record types and modifications to
- the existing DNS protocol ([RFC1035]). The new records and protocol
- modifications are not fully described in this document, but are
- described in a family of documents outlined in Section 10. Sections
- 3 and 4 describe the capabilities and limitations of the security
- extensions in greater detail. Section 5 discusses the scope of the
- document set. Sections 6, 7, 8, and 9 discuss the effect that these
- security extensions will have on resolvers, stub resolvers, zones,
- and name servers.
-
- This document and its two companions obsolete [RFC2535], [RFC3008],
- [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
- [RFC3845]. This document set also updates but does not obsolete
- [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
- [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
- DNSSEC.
-
-
-
-
-Arends, et al. Standards Track [Page 2]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- The DNS security extensions provide origin authentication and
- integrity protection for DNS data, as well as a means of public key
- distribution. These extensions do not provide confidentiality.
-
-2. Definitions of Important DNSSEC Terms
-
- This section defines a number of terms used in this document set.
- Because this is intended to be useful as a reference while reading
- the rest of the document set, first-time readers may wish to skim
- this section quickly, read the rest of this document, and then come
- back to this section.
-
- Authentication Chain: An alternating sequence of DNS public key
- (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
- signed data, with each link in the chain vouching for the next. A
- DNSKEY RR is used to verify the signature covering a DS RR and
- allows the DS RR to be authenticated. The DS RR contains a hash
- of another DNSKEY RR and this new DNSKEY RR is authenticated by
- matching the hash in the DS RR. This new DNSKEY RR in turn
- authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
- this set may be used to authenticate another DS RR, and so forth
- until the chain finally ends with a DNSKEY RR whose corresponding
- private key signs the desired DNS data. For example, the root
- DNSKEY RRset can be used to authenticate the DS RRset for
- "example." The "example." DS RRset contains a hash that matches
- some "example." DNSKEY, and this DNSKEY's corresponding private
- key signs the "example." DNSKEY RRset. Private key counterparts
- of the "example." DNSKEY RRset sign data records such as
- "www.example." and DS RRs for delegations such as
- "subzone.example."
-
- Authentication Key: A public key that a security-aware resolver has
- verified and can therefore use to authenticate data. A
- security-aware resolver can obtain authentication keys in three
- ways. First, the resolver is generally configured to know about
- at least one public key; this configured data is usually either
- the public key itself or a hash of the public key as found in the
- DS RR (see "trust anchor"). Second, the resolver may use an
- authenticated public key to verify a DS RR and the DNSKEY RR to
- which the DS RR refers. Third, the resolver may be able to
- determine that a new public key has been signed by the private key
- corresponding to another public key that the resolver has
- verified. Note that the resolver must always be guided by local
- policy when deciding whether to authenticate a new public key,
- even if the local policy is simply to authenticate any new public
- key for which the resolver is able verify the signature.
-
-
-
-
-
-Arends, et al. Standards Track [Page 3]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- Authoritative RRset: Within the context of a particular zone, an
- RRset is "authoritative" if and only if the owner name of the
- RRset lies within the subset of the name space that is at or below
- the zone apex and at or above the cuts that separate the zone from
- its children, if any. All RRsets at the zone apex are
- authoritative, except for certain RRsets at this domain name that,
- if present, belong to this zone's parent. These RRset could
- include a DS RRset, the NSEC RRset referencing this DS RRset (the
- "parental NSEC"), and RRSIG RRs associated with these RRsets, all
- of which are authoritative in the parent zone. Similarly, if this
- zone contains any delegation points, only the parental NSEC RRset,
- DS RRsets, and any RRSIG RRs associated with these RRsets are
- authoritative for this zone.
-
- Delegation Point: Term used to describe the name at the parental side
- of a zone cut. That is, the delegation point for "foo.example"
- would be the foo.example node in the "example" zone (as opposed to
- the zone apex of the "foo.example" zone). See also zone apex.
-
- Island of Security: Term used to describe a signed, delegated zone
- that does not have an authentication chain from its delegating
- parent. That is, there is no DS RR containing a hash of a DNSKEY
- RR for the island in its delegating parent zone (see [RFC4034]).
- An island of security is served by security-aware name servers and
- may provide authentication chains to any delegated child zones.
- Responses from an island of security or its descendents can only
- be authenticated if its authentication keys can be authenticated
- by some trusted means out of band from the DNS protocol.
-
- Key Signing Key (KSK): An authentication key that corresponds to a
- private key used to sign one or more other authentication keys for
- a given zone. Typically, the private key corresponding to a key
- signing key will sign a zone signing key, which in turn has a
- corresponding private key that will sign other zone data. Local
- policy may require that the zone signing key be changed
- frequently, while the key signing key may have a longer validity
- period in order to provide a more stable secure entry point into
- the zone. Designating an authentication key as a key signing key
- is purely an operational issue: DNSSEC validation does not
- distinguish between key signing keys and other DNSSEC
- authentication keys, and it is possible to use a single key as
- both a key signing key and a zone signing key. Key signing keys
- are discussed in more detail in [RFC3757]. Also see zone signing
- key.
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 4]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- Non-Validating Security-Aware Stub Resolver: A security-aware stub
- resolver that trusts one or more security-aware recursive name
- servers to perform most of the tasks discussed in this document
- set on its behalf. In particular, a non-validating security-aware
- stub resolver is an entity that sends DNS queries, receives DNS
- responses, and is capable of establishing an appropriately secured
- channel to a security-aware recursive name server that will
- provide these services on behalf of the security-aware stub
- resolver. See also security-aware stub resolver, validating
- security-aware stub resolver.
-
- Non-Validating Stub Resolver: A less tedious term for a
- non-validating security-aware stub resolver.
-
- Security-Aware Name Server: An entity acting in the role of a name
- server (defined in section 2.4 of [RFC1034]) that understands the
- DNS security extensions defined in this document set. In
- particular, a security-aware name server is an entity that
- receives DNS queries, sends DNS responses, supports the EDNS0
- ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
- supports the RR types and message header bits defined in this
- document set.
-
- Security-Aware Recursive Name Server: An entity that acts in both the
- security-aware name server and security-aware resolver roles. A
- more cumbersome but equivalent phrase would be "a security-aware
- name server that offers recursive service".
-
- Security-Aware Resolver: An entity acting in the role of a resolver
- (defined in section 2.4 of [RFC1034]) that understands the DNS
- security extensions defined in this document set. In particular,
- a security-aware resolver is an entity that sends DNS queries,
- receives DNS responses, supports the EDNS0 ([RFC2671]) message
- size extension and the DO bit ([RFC3225]), and is capable of using
- the RR types and message header bits defined in this document set
- to provide DNSSEC services.
-
- Security-Aware Stub Resolver: An entity acting in the role of a stub
- resolver (defined in section 5.3.1 of [RFC1034]) that has enough
- of an understanding the DNS security extensions defined in this
- document set to provide additional services not available from a
- security-oblivious stub resolver. Security-aware stub resolvers
- may be either "validating" or "non-validating", depending on
- whether the stub resolver attempts to verify DNSSEC signatures on
- its own or trusts a friendly security-aware name server to do so.
- See also validating stub resolver, non-validating stub resolver.
-
-
-
-
-
-Arends, et al. Standards Track [Page 5]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- Security-Oblivious <anything>: An <anything> that is not
- "security-aware".
-
- Signed Zone: A zone whose RRsets are signed and that contains
- properly constructed DNSKEY, Resource Record Signature (RRSIG),
- Next Secure (NSEC), and (optionally) DS records.
-
- Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A
- validating security-aware resolver uses this public key or hash as
- a starting point for building the authentication chain to a signed
- DNS response. In general, a validating resolver will have to
- obtain the initial values of its trust anchors via some secure or
- trusted means outside the DNS protocol. Presence of a trust
- anchor also implies that the resolver should expect the zone to
- which the trust anchor points to be signed.
-
- Unsigned Zone: A zone that is not signed.
-
- Validating Security-Aware Stub Resolver: A security-aware resolver
- that sends queries in recursive mode but that performs signature
- validation on its own rather than just blindly trusting an
- upstream security-aware recursive name server. See also
- security-aware stub resolver, non-validating security-aware stub
- resolver.
-
- Validating Stub Resolver: A less tedious term for a validating
- security-aware stub resolver.
-
- Zone Apex: Term used to describe the name at the child's side of a
- zone cut. See also delegation point.
-
- Zone Signing Key (ZSK): An authentication key that corresponds to a
- private key used to sign a zone. Typically, a zone signing key
- will be part of the same DNSKEY RRset as the key signing key whose
- corresponding private key signs this DNSKEY RRset, but the zone
- signing key is used for a slightly different purpose and may
- differ from the key signing key in other ways, such as validity
- lifetime. Designating an authentication key as a zone signing key
- is purely an operational issue; DNSSEC validation does not
- distinguish between zone signing keys and other DNSSEC
- authentication keys, and it is possible to use a single key as
- both a key signing key and a zone signing key. See also key
- signing key.
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 6]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
-3. Services Provided by DNS Security
-
- The Domain Name System (DNS) security extensions provide origin
- authentication and integrity assurance services for DNS data,
- including mechanisms for authenticated denial of existence of DNS
- data. These mechanisms are described below.
-
- These mechanisms require changes to the DNS protocol. DNSSEC adds
- four new resource record types: Resource Record Signature (RRSIG),
- DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
- (NSEC). It also adds two new message header bits: Checking Disabled
- (CD) and Authenticated Data (AD). In order to support the larger DNS
- message sizes that result from adding the DNSSEC RRs, DNSSEC also
- requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support
- for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
- security-aware resolver can indicate in its queries that it wishes to
- receive DNSSEC RRs in response messages.
-
- These services protect against most of the threats to the Domain Name
- System described in [RFC3833]. Please see Section 12 for a
- discussion of the limitations of these extensions.
-
-3.1. Data Origin Authentication and Data Integrity
-
- DNSSEC provides authentication by associating cryptographically
- generated digital signatures with DNS RRsets. These digital
- signatures are stored in a new resource record, the RRSIG record.
- Typically, there will be a single private key that signs a zone's
- data, but multiple keys are possible. For example, there may be keys
- for each of several different digital signature algorithms. If a
- security-aware resolver reliably learns a zone's public key, it can
- authenticate that zone's signed data. An important DNSSEC concept is
- that the key that signs a zone's data is associated with the zone
- itself and not with the zone's authoritative name servers. (Public
- keys for DNS transaction authentication mechanisms may also appear in
- zones, as described in [RFC2931], but DNSSEC itself is concerned with
- object security of DNS data, not channel security of DNS
- transactions. The keys associated with transaction security may be
- stored in different RR types. See [RFC3755] for details.)
-
- A security-aware resolver can learn a zone's public key either by
- having a trust anchor configured into the resolver or by normal DNS
- resolution. To allow the latter, public keys are stored in a new
- type of resource record, the DNSKEY RR. Note that the private keys
- used to sign zone data must be kept secure and should be stored
- offline when practical. To discover a public key reliably via DNS
- resolution, the target key itself has to be signed by either a
- configured authentication key or another key that has been
-
-
-
-Arends, et al. Standards Track [Page 7]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- authenticated previously. Security-aware resolvers authenticate zone
- information by forming an authentication chain from a newly learned
- public key back to a previously known authentication public key,
- which in turn either has been configured into the resolver or must
- have been learned and verified previously. Therefore, the resolver
- must be configured with at least one trust anchor.
-
- If the configured trust anchor is a zone signing key, then it will
- authenticate the associated zone; if the configured key is a key
- signing key, it will authenticate a zone signing key. If the
- configured trust anchor is the hash of a key rather than the key
- itself, the resolver may have to obtain the key via a DNS query. To
- help security-aware resolvers establish this authentication chain,
- security-aware name servers attempt to send the signature(s) needed
- to authenticate a zone's public key(s) in the DNS reply message along
- with the public key itself, provided that there is space available in
- the message.
-
- The Delegation Signer (DS) RR type simplifies some of the
- administrative tasks involved in signing delegations across
- organizational boundaries. The DS RRset resides at a delegation
- point in a parent zone and indicates the public key(s) corresponding
- to the private key(s) used to self-sign the DNSKEY RRset at the
- delegated child zone's apex. The administrator of the child zone, in
- turn, uses the private key(s) corresponding to one or more of the
- public keys in this DNSKEY RRset to sign the child zone's data. The
- typical authentication chain is therefore
- DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
- DS->DNSKEY subchains. DNSSEC permits more complex authentication
- chains, such as additional layers of DNSKEY RRs signing other DNSKEY
- RRs within a zone.
-
- A security-aware resolver normally constructs this authentication
- chain from the root of the DNS hierarchy down to the leaf zones based
- on configured knowledge of the public key for the root. Local
- policy, however, may also allow a security-aware resolver to use one
- or more configured public keys (or hashes of public keys) other than
- the root public key, may not provide configured knowledge of the root
- public key, or may prevent the resolver from using particular public
- keys for arbitrary reasons, even if those public keys are properly
- signed with verifiable signatures. DNSSEC provides mechanisms by
- which a security-aware resolver can determine whether an RRset's
- signature is "valid" within the meaning of DNSSEC. In the final
- analysis, however, authenticating both DNS keys and data is a matter
- of local policy, which may extend or even override the protocol
- extensions defined in this document set. See Section 5 for further
- discussion.
-
-
-
-
-Arends, et al. Standards Track [Page 8]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
-3.2. Authenticating Name and Type Non-Existence
-
- The security mechanism described in Section 3.1 only provides a way
- to sign existing RRsets in a zone. The problem of providing negative
- responses with the same level of authentication and integrity
- requires the use of another new resource record type, the NSEC
- record. The NSEC record allows a security-aware resolver to
- authenticate a negative reply for either name or type non-existence
- with the same mechanisms used to authenticate other DNS replies. Use
- of NSEC records requires a canonical representation and ordering for
- domain names in zones. Chains of NSEC records explicitly describe
- the gaps, or "empty space", between domain names in a zone and list
- the types of RRsets present at existing names. Each NSEC record is
- signed and authenticated using the mechanisms described in Section
- 3.1.
-
-4. Services Not Provided by DNS Security
-
- DNS was originally designed with the assumptions that the DNS will
- return the same answer to any given query regardless of who may have
- issued the query, and that all data in the DNS is thus visible.
- Accordingly, DNSSEC is not designed to provide confidentiality,
- access control lists, or other means of differentiating between
- inquirers.
-
- DNSSEC provides no protection against denial of service attacks.
- Security-aware resolvers and security-aware name servers are
- vulnerable to an additional class of denial of service attacks based
- on cryptographic operations. Please see Section 12 for details.
-
- The DNS security extensions provide data and origin authentication
- for DNS data. The mechanisms outlined above are not designed to
- protect operations such as zone transfers and dynamic update
- ([RFC2136], [RFC3007]). Message authentication schemes described in
- [RFC2845] and [RFC2931] address security operations that pertain to
- these transactions.
-
-5. Scope of the DNSSEC Document Set and Last Hop Issues
-
- The specification in this document set defines the behavior for zone
- signers and security-aware name servers and resolvers in such a way
- that the validating entities can unambiguously determine the state of
- the data.
-
- A validating resolver can determine the following 4 states:
-
- Secure: The validating resolver has a trust anchor, has a chain of
- trust, and is able to verify all the signatures in the response.
-
-
-
-Arends, et al. Standards Track [Page 9]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- Insecure: The validating resolver has a trust anchor, a chain of
- trust, and, at some delegation point, signed proof of the
- non-existence of a DS record. This indicates that subsequent
- branches in the tree are provably insecure. A validating resolver
- may have a local policy to mark parts of the domain space as
- insecure.
-
- Bogus: The validating resolver has a trust anchor and a secure
- delegation indicating that subsidiary data is signed, but the
- response fails to validate for some reason: missing signatures,
- expired signatures, signatures with unsupported algorithms, data
- missing that the relevant NSEC RR says should be present, and so
- forth.
-
- Indeterminate: There is no trust anchor that would indicate that a
- specific portion of the tree is secure. This is the default
- operation mode.
-
- This specification only defines how security-aware name servers can
- signal non-validating stub resolvers that data was found to be bogus
- (using RCODE=2, "Server Failure"; see [RFC4035]).
-
- There is a mechanism for security-aware name servers to signal
- security-aware stub resolvers that data was found to be secure (using
- the AD bit; see [RFC4035]).
-
- This specification does not define a format for communicating why
- responses were found to be bogus or marked as insecure. The current
- signaling mechanism does not distinguish between indeterminate and
- insecure states.
-
- A method for signaling advanced error codes and policy between a
- security-aware stub resolver and security-aware recursive nameservers
- is a topic for future work, as is the interface between a security-
- aware resolver and the applications that use it. Note, however, that
- the lack of the specification of such communication does not prohibit
- deployment of signed zones or the deployment of security aware
- recursive name servers that prohibit propagation of bogus data to the
- applications.
-
-6. Resolver Considerations
-
- A security-aware resolver has to be able to perform cryptographic
- functions necessary to verify digital signatures using at least the
- mandatory-to-implement algorithm(s). Security-aware resolvers must
- also be capable of forming an authentication chain from a newly
- learned zone back to an authentication key, as described above. This
- process might require additional queries to intermediate DNS zones to
-
-
-
-Arends, et al. Standards Track [Page 10]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- obtain necessary DNSKEY, DS, and RRSIG records. A security-aware
- resolver should be configured with at least one trust anchor as the
- starting point from which it will attempt to establish authentication
- chains.
-
- If a security-aware resolver is separated from the relevant
- authoritative name servers by a recursive name server or by any sort
- of intermediary device that acts as a proxy for DNS, and if the
- recursive name server or intermediary device is not security-aware,
- the security-aware resolver may not be capable of operating in a
- secure mode. For example, if a security-aware resolver's packets are
- routed through a network address translation (NAT) device that
- includes a DNS proxy that is not security-aware, the security-aware
- resolver may find it difficult or impossible to obtain or validate
- signed DNS data. The security-aware resolver may have a particularly
- difficult time obtaining DS RRs in such a case, as DS RRs do not
- follow the usual DNS rules for ownership of RRs at zone cuts. Note
- that this problem is not specific to NATs: any security-oblivious DNS
- software of any kind between the security-aware resolver and the
- authoritative name servers will interfere with DNSSEC.
-
- If a security-aware resolver must rely on an unsigned zone or a name
- server that is not security aware, the resolver may not be able to
- validate DNS responses and will need a local policy on whether to
- accept unverified responses.
-
- A security-aware resolver should take a signature's validation period
- into consideration when determining the TTL of data in its cache, to
- avoid caching signed data beyond the validity period of the
- signature. However, it should also allow for the possibility that
- the security-aware resolver's own clock is wrong. Thus, a
- security-aware resolver that is part of a security-aware recursive
- name server will have to pay careful attention to the DNSSEC
- "checking disabled" (CD) bit ([RFC4034]). This is in order to avoid
- blocking valid signatures from getting through to other
- security-aware resolvers that are clients of this recursive name
- server. See [RFC4035] for how a secure recursive server handles
- queries with the CD bit set.
-
-7. Stub Resolver Considerations
-
- Although not strictly required to do so by the protocol, most DNS
- queries originate from stub resolvers. Stub resolvers, by
- definition, are minimal DNS resolvers that use recursive query mode
- to offload most of the work of DNS resolution to a recursive name
- server. Given the widespread use of stub resolvers, the DNSSEC
-
-
-
-
-
-Arends, et al. Standards Track [Page 11]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- architecture has to take stub resolvers into account, but the
- security features needed in a stub resolver differ in some respects
- from those needed in a security-aware iterative resolver.
-
- Even a security-oblivious stub resolver may benefit from DNSSEC if
- the recursive name servers it uses are security-aware, but for the
- stub resolver to place any real reliance on DNSSEC services, the stub
- resolver must trust both the recursive name servers in question and
- the communication channels between itself and those name servers.
- The first of these issues is a local policy issue: in essence, a
- security-oblivious stub resolver has no choice but to place itself at
- the mercy of the recursive name servers that it uses, as it does not
- perform DNSSEC validity checks on its own. The second issue requires
- some kind of channel security mechanism; proper use of DNS
- transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
- TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
- Particular implementations may have other choices available, such as
- operating system specific interprocess communication mechanisms.
- Confidentiality is not needed for this channel, but data integrity
- and message authentication are.
-
- A security-aware stub resolver that does trust both its recursive
- name servers and its communication channel to them may choose to
- examine the setting of the Authenticated Data (AD) bit in the message
- header of the response messages it receives. The stub resolver can
- use this flag bit as a hint to find out whether the recursive name
- server was able to validate signatures for all of the data in the
- Answer and Authority sections of the response.
-
- There is one more step that a security-aware stub resolver can take
- if, for whatever reason, it is not able to establish a useful trust
- relationship with the recursive name servers that it uses: it can
- perform its own signature validation by setting the Checking Disabled
- (CD) bit in its query messages. A validating stub resolver is thus
- able to treat the DNSSEC signatures as trust relationships between
- the zone administrators and the stub resolver itself.
-
-8. Zone Considerations
-
- There are several differences between signed and unsigned zones. A
- signed zone will contain additional security-related records (RRSIG,
- DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be
- generated by a signing process prior to serving the zone. The RRSIG
- records that accompany zone data have defined inception and
- expiration times that establish a validity period for the signatures
- and the zone data the signatures cover.
-
-
-
-
-
-Arends, et al. Standards Track [Page 12]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
-8.1. TTL Values vs. RRSIG Validity Period
-
- It is important to note the distinction between a RRset's TTL value
- and the signature validity period specified by the RRSIG RR covering
- that RRset. DNSSEC does not change the definition or function of the
- TTL value, which is intended to maintain database coherency in
- caches. A caching resolver purges RRsets from its cache no later
- than the end of the time period specified by the TTL fields of those
- RRsets, regardless of whether the resolver is security-aware.
-
- The inception and expiration fields in the RRSIG RR ([RFC4034]), on
- the other hand, specify the time period during which the signature
- can be used to validate the covered RRset. The signatures associated
- with signed zone data are only valid for the time period specified by
- these fields in the RRSIG RRs in question. TTL values cannot extend
- the validity period of signed RRsets in a resolver's cache, but the
- resolver may use the time remaining before expiration of the
- signature validity period of a signed RRset as an upper bound for the
- TTL of the signed RRset and its associated RRSIG RR in the resolver's
- cache.
-
-8.2. New Temporal Dependency Issues for Zones
-
- Information in a signed zone has a temporal dependency that did not
- exist in the original DNS protocol. A signed zone requires regular
- maintenance to ensure that each RRset in the zone has a current valid
- RRSIG RR. The signature validity period of an RRSIG RR is an
- interval during which the signature for one particular signed RRset
- can be considered valid, and the signatures of different RRsets in a
- zone may expire at different times. Re-signing one or more RRsets in
- a zone will change one or more RRSIG RRs, which will in turn require
- incrementing the zone's SOA serial number to indicate that a zone
- change has occurred and re-signing the SOA RRset itself. Thus,
- re-signing any RRset in a zone may also trigger DNS NOTIFY messages
- and zone transfer operations.
-
-9. Name Server Considerations
-
- A security-aware name server should include the appropriate DNSSEC
- records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
- from resolvers that have signaled their willingness to receive such
- records via use of the DO bit in the EDNS header, subject to message
- size limitations. Because inclusion of these DNSSEC RRs could easily
- cause UDP message truncation and fallback to TCP, a security-aware
- name server must also support the EDNS "sender's UDP payload"
- mechanism.
-
-
-
-
-
-Arends, et al. Standards Track [Page 13]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- If possible, the private half of each DNSSEC key pair should be kept
- offline, but this will not be possible for a zone for which DNS
- dynamic update has been enabled. In the dynamic update case, the
- primary master server for the zone will have to re-sign the zone when
- it is updated, so the private key corresponding to the zone signing
- key will have to be kept online. This is an example of a situation
- in which the ability to separate the zone's DNSKEY RRset into zone
- signing key(s) and key signing key(s) may be useful, as the key
- signing key(s) in such a case can still be kept offline and may have
- a longer useful lifetime than the zone signing key(s).
-
- By itself, DNSSEC is not enough to protect the integrity of an entire
- zone during zone transfer operations, as even a signed zone contains
- some unsigned, nonauthoritative data if the zone has any children.
- Therefore, zone maintenance operations will require some additional
- mechanisms (most likely some form of channel security, such as TSIG,
- SIG(0), or IPsec).
-
-10. DNS Security Document Family
-
- The DNSSEC document set can be partitioned into several main groups,
- under the larger umbrella of the DNS base protocol documents.
-
- The "DNSSEC protocol document set" refers to the three documents that
- form the core of the DNS security extensions:
-
- 1. DNS Security Introduction and Requirements (this document)
-
- 2. Resource Records for DNS Security Extensions [RFC4034]
-
- 3. Protocol Modifications for the DNS Security Extensions [RFC4035]
-
- Additionally, any document that would add to or change the core DNS
- Security extensions would fall into this category. This includes any
- future work on the communication between security-aware stub
- resolvers and upstream security-aware recursive name servers.
-
- The "Digital Signature Algorithm Specification" document set refers
- to the group of documents that describe how specific digital
- signature algorithms should be implemented to fit the DNSSEC resource
- record format. Each document in this set deals with a specific
- digital signature algorithm. Please see the appendix on "DNSSEC
- Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
- that were defined when this core specification was written.
-
- The "Transaction Authentication Protocol" document set refers to the
- group of documents that deal with DNS message authentication,
- including secret key establishment and verification. Although not
-
-
-
-Arends, et al. Standards Track [Page 14]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- strictly part of the DNSSEC specification as defined in this set of
- documents, this group is noted because of its relationship to DNSSEC.
-
- The final document set, "New Security Uses", refers to documents that
- seek to use proposed DNS Security extensions for other security
- related purposes. DNSSEC does not provide any direct security for
- these new uses but may be used to support them. Documents that fall
- in this category include those describing the use of DNS in the
- storage and distribution of certificates ([RFC2538]).
-
-11. IANA Considerations
-
- This overview document introduces no new IANA considerations. Please
- see [RFC4034] for a complete review of the IANA considerations
- introduced by DNSSEC.
-
-12. Security Considerations
-
- This document introduces DNS security extensions and describes the
- document set that contains the new security records and DNS protocol
- modifications. The extensions provide data origin authentication and
- data integrity using digital signatures over resource record sets.
- This section discusses the limitations of these extensions.
-
- In order for a security-aware resolver to validate a DNS response,
- all zones along the path from the trusted starting point to the zone
- containing the response zones must be signed, and all name servers
- and resolvers involved in the resolution process must be
- security-aware, as defined in this document set. A security-aware
- resolver cannot verify responses originating from an unsigned zone,
- from a zone not served by a security-aware name server, or for any
- DNS data that the resolver is only able to obtain through a recursive
- name server that is not security-aware. If there is a break in the
- authentication chain such that a security-aware resolver cannot
- obtain and validate the authentication keys it needs, then the
- security-aware resolver cannot validate the affected DNS data.
-
- This document briefly discusses other methods of adding security to a
- DNS query, such as using a channel secured by IPsec or using a DNS
- transaction authentication mechanism such as TSIG ([RFC2845]) or
- SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
- per se.
-
- A non-validating security-aware stub resolver, by definition, does
- not perform DNSSEC signature validation on its own and thus is
- vulnerable both to attacks on (and by) the security-aware recursive
- name servers that perform these checks on its behalf and to attacks
- on its communication with those security-aware recursive name
-
-
-
-Arends, et al. Standards Track [Page 15]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- servers. Non-validating security-aware stub resolvers should use
- some form of channel security to defend against the latter threat.
- The only known defense against the former threat would be for the
- security-aware stub resolver to perform its own signature validation,
- at which point, again by definition, it would no longer be a
- non-validating security-aware stub resolver.
-
- DNSSEC does not protect against denial of service attacks. DNSSEC
- makes DNS vulnerable to a new class of denial of service attacks
- based on cryptographic operations against security-aware resolvers
- and security-aware name servers, as an attacker can attempt to use
- DNSSEC mechanisms to consume a victim's resources. This class of
- attacks takes at least two forms. An attacker may be able to consume
- resources in a security-aware resolver's signature validation code by
- tampering with RRSIG RRs in response messages or by constructing
- needlessly complex signature chains. An attacker may also be able to
- consume resources in a security-aware name server that supports DNS
- dynamic update, by sending a stream of update messages that force the
- security-aware name server to re-sign some RRsets in the zone more
- frequently than would otherwise be necessary.
-
- Due to a deliberate design choice, DNSSEC does not provide
- confidentiality.
-
- DNSSEC introduces the ability for a hostile party to enumerate all
- the names in a zone by following the NSEC chain. NSEC RRs assert
- which names do not exist in a zone by linking from existing name to
- existing name along a canonical ordering of all the names within a
- zone. Thus, an attacker can query these NSEC RRs in sequence to
- obtain all the names in a zone. Although this is not an attack on
- the DNS itself, it could allow an attacker to map network hosts or
- other resources by enumerating the contents of a zone.
-
- DNSSEC introduces significant additional complexity to the DNS and
- thus introduces many new opportunities for implementation bugs and
- misconfigured zones. In particular, enabling DNSSEC signature
- validation in a resolver may cause entire legitimate zones to become
- effectively unreachable due to DNSSEC configuration errors or bugs.
-
- DNSSEC does not protect against tampering with unsigned zone data.
- Non-authoritative data at zone cuts (glue and NS RRs in the parent
- zone) are not signed. This does not pose a problem when validating
- the authentication chain, but it does mean that the non-authoritative
- data itself is vulnerable to tampering during zone transfer
- operations. Thus, while DNSSEC can provide data origin
- authentication and data integrity for RRsets, it cannot do so for
- zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
- used to protect zone transfer operations.
-
-
-
-Arends, et al. Standards Track [Page 16]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- Please see [RFC4034] and [RFC4035] for additional security
- considerations.
-
-13. Acknowledgements
-
- This document was created from the input and ideas of the members of
- the DNS Extensions Working Group. Although explicitly listing
- everyone who has contributed during the decade in which DNSSEC has
- been under development would be impossible, the editors would
- particularly like to thank the following people for their
- contributions to and comments on this document set: Jaap Akkerhuis,
- Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
- David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
- Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
- Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip
- Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
- Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
- Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
- Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
- Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
- Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
- Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
- Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
- Brian Wellington, and Suzanne Woolf.
-
- No doubt the above list is incomplete. We apologize to anyone we
- left out.
-
-14. References
-
-14.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2535] Eastlake 3rd, D., "Domain Name System Security
- Extensions", RFC 2535, March 1999.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
-
-
-
-
-Arends, et al. Standards Track [Page 17]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
- [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
- Resource Record (RR)", RFC 3445, December 2002.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for DNS Security Extensions", RFC
- 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-14.2. Informative References
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates
- in the Domain Name System (DNS)", RFC 2538, March 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
- ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
- Signing Authority", RFC 3008, November 2000.
-
- [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
-
-
-
-Arends, et al. Standards Track [Page 18]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
- [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
- Authenticated Data (AD) bit", RFC 3655, November 2003.
-
- [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
- (RR)", RFC 3658, December 2003.
-
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer (DS)", RFC 3755, May 2004.
-
- [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
- System KEY (DNSKEY) Resource Record (RR) Secure Entry
- Point (SEP) Flag", RFC 3757, April 2004.
-
- [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
- Name System (DNS)", RFC 3833, August 2004.
-
- [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
- RDATA Format", RFC 3845, August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 19]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Brouwerijstraat 1
- 7523 XC Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Rob Austein
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- EMail: sra@isc.org
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Dan Massey
- Colorado State University
- Department of Computer Science
- Fort Collins, CO 80523-1873
-
- EMail: massey@cs.colostate.edu
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 20]
-
-RFC 4033 DNS Security Introduction and Requirements March 2005
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 21]
-
diff --git a/contrib/bind9/doc/rfc/rfc4034.txt b/contrib/bind9/doc/rfc/rfc4034.txt
deleted file mode 100644
index 6a12c6b8efc58..0000000000000
--- a/contrib/bind9/doc/rfc/rfc4034.txt
+++ /dev/null
@@ -1,1627 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index b701cd2f235b4..0000000000000
--- a/contrib/bind9/doc/rfc/rfc4035.txt
+++ /dev/null
@@ -1,2971 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Arends
-Request for Comments: 4035 Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
- 3755, 3757, 3845 ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
- 3007, 3597, 3226 VeriSign
-Category: Standards Track D. Massey
- Colorado State University
- S. Rose
- NIST
- March 2005
-
-
- Protocol Modifications for the DNS Security Extensions
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document is part of a family of documents that describe the DNS
- Security Extensions (DNSSEC). The DNS Security Extensions are a
- collection of new resource records and protocol modifications that
- add data origin authentication and data integrity to the DNS. This
- document describes the DNSSEC protocol modifications. This document
- defines the concept of a signed zone, along with the requirements for
- serving and resolving by using DNSSEC. These techniques allow a
- security-aware resolver to authenticate both DNS resource records and
- authoritative DNS error indications.
-
- This document obsoletes RFC 2535 and incorporates changes from all
- updates to RFC 2535.
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 1]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Background and Related Documents . . . . . . . . . . . . 4
- 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
- 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5
- 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5
- 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6
- 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7
- 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7
- 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8
- 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8
- 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9
- 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10
- 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11
- 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11
- 3.1.4. Including DS RRs in a Response . . . . . . . . . 14
- 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15
- 3.1.6. The AD and CD Bits in an Authoritative Response. 16
- 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17
- 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17
- 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17
- 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18
- 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
- 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
- 4.2. Signature Verification Support . . . . . . . . . . . . . 19
- 4.3. Determining Security Status of Data . . . . . . . . . . 20
- 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21
- 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21
- 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22
- 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
- 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
- 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
- 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24
- 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24
- 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24
- 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
- 5.1. Special Considerations for Islands of Security . . . . . 26
- 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26
- 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28
- 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28
- 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29
- 5.3.3. Checking the Signature . . . . . . . . . . . . . 31
- 5.3.4. Authenticating a Wildcard Expanded RRset
- Positive Response. . . . . . . . . . . . . . . . 32
-
-
-
-Arends, et al. Standards Track [Page 2]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32
- 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33
- 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
- 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
- 9.2. Informative References . . . . . . . . . . . . . . . . . 35
- A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36
- B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41
- B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
- B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
- B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44
- B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44
- B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45
- B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
- B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
- B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48
- C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49
- C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49
- C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49
- C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
- C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50
- C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50
- C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51
- C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
- C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
- C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) are a collection of new resource
- records and protocol modifications that add data origin
- authentication and data integrity to the DNS. This document defines
- the DNSSEC protocol modifications. Section 2 of this document
- defines the concept of a signed zone and lists the requirements for
- zone signing. Section 3 describes the modifications to authoritative
- name server behavior necessary for handling signed zones. Section 4
- describes the behavior of entities that include security-aware
- resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
- to authenticate a response.
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 3]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-1.1. Background and Related Documents
-
- This document is part of a family of documents defining DNSSEC that
- should be read together as a set.
-
- [RFC4033] contains an introduction to DNSSEC and definitions of
- common terms; the reader is assumed to be familiar with this
- document. [RFC4033] also contains a list of other documents updated
- by and obsoleted by this document set.
-
- [RFC4034] defines the DNSSEC resource records.
-
- The reader is also assumed to be familiar with the basic DNS concepts
- described in [RFC1034], [RFC1035], and the subsequent documents that
- update them; particularly, [RFC2181] and [RFC2308].
-
- This document defines the DNSSEC protocol operations.
-
-1.2. Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-2. Zone Signing
-
- DNSSEC introduces the concept of signed zones. A signed zone
- includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
- Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
- according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
- respectively. A zone that does not include these records according
- to the rules in this section is an unsigned zone.
-
- DNSSEC requires a change to the definition of the CNAME resource
- record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG
- and NSEC RRs to appear at the same owner name as does a CNAME RR.
-
- DNSSEC specifies the placement of two new RR types, NSEC and DS,
- which can be placed at the parental side of a zone cut (that is, at a
- delegation point). This is an exception to the general prohibition
- against putting data in the parent zone at a zone cut. Section 2.6
- describes this change.
-
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 4]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-2.1. Including DNSKEY RRs in a Zone
-
- To sign a zone, the zone's administrator generates one or more
- public/private key pairs and uses the private key(s) to sign
- authoritative RRsets in the zone. For each private key used to
- create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
- containing the corresponding public key. A zone key DNSKEY RR MUST
- have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
- of [RFC4034]). Public keys associated with other DNS operations MAY
- be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
- be used to verify RRSIGs.
-
- If the zone administrator intends a signed zone to be usable other
- than as an island of security, the zone apex MUST contain at least
- one DNSKEY RR to act as a secure entry point into the zone. This
- secure entry point could then be used as the target of a secure
- delegation via a corresponding DS RR in the parent zone (see
- [RFC4034]).
-
-2.2. Including RRSIG RRs in a Zone
-
- For each authoritative RRset in a signed zone, there MUST be at least
- one RRSIG record that meets the following requirements:
-
- o The RRSIG owner name is equal to the RRset owner name.
-
- o The RRSIG class is equal to the RRset class.
-
- o The RRSIG Type Covered field is equal to the RRset type.
-
- o The RRSIG Original TTL field is equal to the TTL of the RRset.
-
- o The RRSIG RR's TTL is equal to the TTL of the RRset.
-
- o The RRSIG Labels field is equal to the number of labels in the
- RRset owner name, not counting the null root label and not
- counting the leftmost label if it is a wildcard.
-
- o The RRSIG Signer's Name field is equal to the name of the zone
- containing the RRset.
-
- o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
- zone key DNSKEY record at the zone apex.
-
- The process for constructing the RRSIG RR for a given RRset is
- described in [RFC4034]. An RRset MAY have multiple RRSIG RRs
- associated with it. Note that as RRSIG RRs are closely tied to the
- RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
-
-
-
-Arends, et al. Standards Track [Page 5]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- RR types, do not form RRsets. In particular, the TTL values among
- RRSIG RRs with a common owner name do not follow the RRset rules
- described in [RFC2181].
-
- An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
- add no value and would create an infinite loop in the signing
- process.
-
- The NS RRset that appears at the zone apex name MUST be signed, but
- the NS RRsets that appear at delegation points (that is, the NS
- RRsets in the parent zone that delegate the name to the child zone's
- name servers) MUST NOT be signed. Glue address RRsets associated
- with delegations MUST NOT be signed.
-
- There MUST be an RRSIG for each RRset using at least one DNSKEY of
- each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
- itself MUST be signed by each algorithm appearing in the DS RRset
- located at the delegating parent (if any).
-
-2.3. Including NSEC RRs in a Zone
-
- Each owner name in the zone that has authoritative data or a
- delegation point NS RRset MUST have an NSEC resource record. The
- format of NSEC RRs and the process for constructing the NSEC RR for a
- given name is described in [RFC4034].
-
- The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
- value field in the zone SOA RR.
-
- An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
- RRset at any particular owner name. That is, the signing process
- MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
- the owner name of any RRset before the zone was signed. The main
- reasons for this are a desire for namespace consistency between
- signed and unsigned versions of the same zone and a desire to reduce
- the risk of response inconsistency in security oblivious recursive
- name servers.
-
- The type bitmap of every NSEC resource record in a signed zone MUST
- indicate the presence of both the NSEC record itself and its
- corresponding RRSIG record.
-
- The difference between the set of owner names that require RRSIG
- records and the set of owner names that require NSEC records is
- subtle and worth highlighting. RRSIG records are present at the
- owner names of all authoritative RRsets. NSEC records are present at
- the owner names of all names for which the signed zone is
- authoritative and also at the owner names of delegations from the
-
-
-
-Arends, et al. Standards Track [Page 6]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- signed zone to its children. Neither NSEC nor RRSIG records are
- present (in the parent zone) at the owner names of glue address
- RRsets. Note, however, that this distinction is for the most part
- visible only during the zone signing process, as NSEC RRsets are
- authoritative data and are therefore signed. Thus, any owner name
- that has an NSEC RRset will have RRSIG RRs as well in the signed
- zone.
-
- The bitmap for the NSEC RR at a delegation point requires special
- attention. Bits corresponding to the delegation NS RRset and any
- RRsets for which the parent zone has authoritative data MUST be set;
- bits corresponding to any non-NS RRset for which the parent is not
- authoritative MUST be clear.
-
-2.4. Including DS RRs in a Zone
-
- The DS resource record establishes authentication chains between DNS
- zones. A DS RRset SHOULD be present at a delegation point when the
- child zone is signed. The DS RRset MAY contain multiple records,
- each referencing a public key in the child zone used to verify the
- RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS
- RRsets MUST NOT appear at a zone's apex.
-
- A DS RR SHOULD point to a DNSKEY RR that is present in the child's
- apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
- by the corresponding private key. DS RRs that fail to meet these
- conditions are not useful for validation, but because the DS RR and
- its corresponding DNSKEY RR are in different zones, and because the
- DNS is only loosely consistent, temporary mismatches can occur.
-
- The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
- (that is, the NS RRset from the same zone containing the DS RRset).
-
- Construction of a DS RR requires knowledge of the corresponding
- DNSKEY RR in the child zone, which implies communication between the
- child and parent zones. This communication is an operational matter
- not covered by this document.
-
-2.5. Changes to the CNAME Resource Record
-
- If a CNAME RRset is present at a name in a signed zone, appropriate
- RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
- name for secure dynamic update purposes is also allowed ([RFC3007]).
- Other types MUST NOT be present at that name.
-
- This is a modification to the original CNAME definition given in
- [RFC1034]. The original definition of the CNAME RR did not allow any
- other types to coexist with a CNAME record, but a signed zone
-
-
-
-Arends, et al. Standards Track [Page 7]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- requires NSEC and RRSIG RRs for every authoritative name. To resolve
- this conflict, this specification modifies the definition of the
- CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
-
-2.6. DNSSEC RR Types Appearing at Zone Cuts
-
- DNSSEC introduced two new RR types that are unusual in that they can
- appear at the parental side of a zone cut. At the parental side of a
- zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
- the owner name. A DS RR could also be present if the zone being
- delegated is signed and seeks to have a chain of authentication to
- the parent zone. This is an exception to the original DNS
- specification ([RFC1034]), which states that only NS RRsets could
- appear at the parental side of a zone cut.
-
- This specification updates the original DNS specification to allow
- NSEC and DS RR types at the parent side of a zone cut. These RRsets
- are authoritative for the parent when they appear at the parent side
- of a zone cut.
-
-2.7. Example of a Secure Zone
-
- Appendix A shows a complete example of a small signed zone.
-
-3. Serving
-
- This section describes the behavior of entities that include
- security-aware name server functions. In many cases such functions
- will be part of a security-aware recursive name server, but a
- security-aware authoritative name server has some of the same
- requirements. Functions specific to security-aware recursive name
- servers are described in Section 3.2; functions specific to
- authoritative servers are described in Section 3.1.
-
- In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
- are as used in [RFC1034].
-
- A security-aware name server MUST support the EDNS0 ([RFC2671])
- message size extension, MUST support a message size of at least 1220
- octets, and SHOULD support a message size of 4000 octets. As IPv6
- packets can only be fragmented by the source host, a security aware
- name server SHOULD take steps to ensure that UDP datagrams it
- transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
- MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460],
- and [RFC3226] for further discussion of packet size and fragmentation
- issues.
-
-
-
-
-
-Arends, et al. Standards Track [Page 8]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- A security-aware name server that receives a DNS query that does not
- include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
- treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
- MUST NOT perform any of the additional processing described below.
- Because the DS RR type has the peculiar property of only existing in
- the parent zone at delegation points, DS RRs always require some
- special processing, as described in Section 3.1.4.1.
-
- Security aware name servers that receive explicit queries for
- security RR types that match the content of more than one zone that
- it serves (for example, NSEC and RRSIG RRs above and below a
- delegation point where the server is authoritative for both zones)
- should behave self-consistently. As long as the response is always
- consistent for each query to the name server, the name server MAY
- return one of the following:
-
- o The above-delegation RRsets.
- o The below-delegation RRsets.
- o Both above and below-delegation RRsets.
- o Empty answer section (no records).
- o Some other response.
- o An error.
-
- DNSSEC allocates two new bits in the DNS message header: the CD
- (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
- is controlled by resolvers; a security-aware name server MUST copy
- the CD bit from a query into the corresponding response. The AD bit
- is controlled by name servers; a security-aware name server MUST
- ignore the setting of the AD bit in queries. See Sections 3.1.6,
- 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
-
- A security aware name server that synthesizes CNAME RRs from DNAME
- RRs as described in [RFC2672] SHOULD NOT generate signatures for the
- synthesized CNAME RRs.
-
-3.1. Authoritative Name Servers
-
- Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
- pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
- server for a signed zone MUST include additional RRSIG, NSEC, and DS
- RRs, according to the following rules:
-
- o RRSIG RRs that can be used to authenticate a response MUST be
- included in the response according to the rules in Section 3.1.1.
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 9]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- o NSEC RRs that can be used to provide authenticated denial of
- existence MUST be included in the response automatically according
- to the rules in Section 3.1.3.
-
- o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
- be included in referrals automatically according to the rules in
- Section 3.1.4.
-
- These rules only apply to responses where the semantics convey
- information about the presence or absence of resource records. That
- is, these rules are not intended to rule out responses such as RCODE
- 4 ("Not Implemented") or RCODE 5 ("Refused").
-
- DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
- discusses zone transfer requirements.
-
-3.1.1. Including RRSIG RRs in a Response
-
- When responding to a query that has the DO bit set, a security-aware
- authoritative name server SHOULD attempt to send RRSIG RRs that a
- security-aware resolver can use to authenticate the RRsets in the
- response. A name server SHOULD make every attempt to keep the RRset
- and its associated RRSIG(s) together in a response. Inclusion of
- RRSIG RRs in a response is subject to the following rules:
-
- o When placing a signed RRset in the Answer section, the name server
- MUST also place its RRSIG RRs in the Answer section. The RRSIG
- RRs have a higher priority for inclusion than any other RRsets
- that may have to be included. If space does not permit inclusion
- of these RRSIG RRs, the name server MUST set the TC bit.
-
- o When placing a signed RRset in the Authority section, the name
- server MUST also place its RRSIG RRs in the Authority section.
- The RRSIG RRs have a higher priority for inclusion than any other
- RRsets that may have to be included. If space does not permit
- inclusion of these RRSIG RRs, the name server MUST set the TC bit.
-
- o When placing a signed RRset in the Additional section, the name
- server MUST also place its RRSIG RRs in the Additional section.
- If space does not permit inclusion of both the RRset and its
- associated RRSIG RRs, the name server MAY retain the RRset while
- dropping the RRSIG RRs. If this happens, the name server MUST NOT
- set the TC bit solely because these RRSIG RRs didn't fit.
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 10]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-3.1.2. Including DNSKEY RRs in a Response
-
- When responding to a query that has the DO bit set and that requests
- the SOA or NS RRs at the apex of a signed zone, a security-aware
- authoritative name server for that zone MAY return the zone apex
- DNSKEY RRset in the Additional section. In this situation, the
- DNSKEY RRset and associated RRSIG RRs have lower priority than does
- any other information that would be placed in the additional section.
- The name server SHOULD NOT include the DNSKEY RRset unless there is
- enough space in the response message for both the DNSKEY RRset and
- its associated RRSIG RR(s). If there is not enough space to include
- these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
- NOT set the TC bit solely because these RRs didn't fit (see Section
- 3.1.1).
-
-3.1.3. Including NSEC RRs in a Response
-
- When responding to a query that has the DO bit set, a security-aware
- authoritative name server for a signed zone MUST include NSEC RRs in
- each of the following cases:
-
- No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
- but does not contain any RRsets that exactly match <SNAME, SCLASS,
- STYPE>.
-
- Name Error: The zone does not contain any RRsets that match <SNAME,
- SCLASS> either exactly or via wildcard name expansion.
-
- Wildcard Answer: The zone does not contain any RRsets that exactly
- match <SNAME, SCLASS> but does contain an RRset that matches
- <SNAME, SCLASS, STYPE> via wildcard name expansion.
-
- Wildcard No Data: The zone does not contain any RRsets that exactly
- match <SNAME, SCLASS> and does contain one or more RRsets that
- match <SNAME, SCLASS> via wildcard name expansion, but does not
- contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
- name expansion.
-
- In each of these cases, the name server includes NSEC RRs in the
- response to prove that an exact match for <SNAME, SCLASS, STYPE> was
- not present in the zone and that the response that the name server is
- returning is correct given the data in the zone.
-
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 11]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-3.1.3.1. Including NSEC RRs: No Data Response
-
- If the zone contains RRsets matching <SNAME, SCLASS> but contains no
- RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
- include the NSEC RR for <SNAME, SCLASS> along with its associated
- RRSIG RR(s) in the Authority section of the response (see Section
- 3.1.1). If space does not permit inclusion of the NSEC RR or its
- associated RRSIG RR(s), the name server MUST set the TC bit (see
- Section 3.1.1).
-
- Since the search name exists, wildcard name expansion does not apply
- to this query, and a single signed NSEC RR suffices to prove that the
- requested RR type does not exist.
-
-3.1.3.2. Including NSEC RRs: Name Error Response
-
- If the zone does not contain any RRsets matching <SNAME, SCLASS>
- either exactly or via wildcard name expansion, then the name server
- MUST include the following NSEC RRs in the Authority section, along
- with their associated RRSIG RRs:
-
- o An NSEC RR proving that there is no exact match for <SNAME,
- SCLASS>.
-
- o An NSEC RR proving that the zone contains no RRsets that would
- match <SNAME, SCLASS> via wildcard name expansion.
-
- In some cases, a single NSEC RR may prove both of these points. If
- it does, the name server SHOULD only include the NSEC RR and its
- RRSIG RR(s) once in the Authority section.
-
- If space does not permit inclusion of these NSEC and RRSIG RRs, the
- name server MUST set the TC bit (see Section 3.1.1).
-
- The owner names of these NSEC and RRSIG RRs are not subject to
- wildcard name expansion when these RRs are included in the Authority
- section of the response.
-
- Note that this form of response includes cases in which SNAME
- corresponds to an empty non-terminal name within the zone (a name
- that is not the owner name for any RRset but that is the parent name
- of one or more RRsets).
-
-3.1.3.3. Including NSEC RRs: Wildcard Answer Response
-
- If the zone does not contain any RRsets that exactly match <SNAME,
- SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
- via wildcard name expansion, the name server MUST include the
-
-
-
-Arends, et al. Standards Track [Page 12]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- wildcard-expanded answer and the corresponding wildcard-expanded
- RRSIG RRs in the Answer section and MUST include in the Authority
- section an NSEC RR and associated RRSIG RR(s) proving that the zone
- does not contain a closer match for <SNAME, SCLASS>. If space does
- not permit inclusion of the answer, NSEC and RRSIG RRs, the name
- server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.4. Including NSEC RRs: Wildcard No Data Response
-
- This case is a combination of the previous cases. The zone does not
- contain an exact match for <SNAME, SCLASS>, and although the zone
- does contain RRsets that match <SNAME, SCLASS> via wildcard
- expansion, none of those RRsets matches STYPE. The name server MUST
- include the following NSEC RRs in the Authority section, along with
- their associated RRSIG RRs:
-
- o An NSEC RR proving that there are no RRsets matching STYPE at the
- wildcard owner name that matched <SNAME, SCLASS> via wildcard
- expansion.
-
- o An NSEC RR proving that there are no RRsets in the zone that would
- have been a closer match for <SNAME, SCLASS>.
-
- In some cases, a single NSEC RR may prove both of these points. If
- it does, the name server SHOULD only include the NSEC RR and its
- RRSIG RR(s) once in the Authority section.
-
- The owner names of these NSEC and RRSIG RRs are not subject to
- wildcard name expansion when these RRs are included in the Authority
- section of the response.
-
- If space does not permit inclusion of these NSEC and RRSIG RRs, the
- name server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.5. Finding the Right NSEC RRs
-
- As explained above, there are several situations in which a
- security-aware authoritative name server has to locate an NSEC RR
- that proves that no RRsets matching a particular SNAME exist.
- Locating such an NSEC RR within an authoritative zone is relatively
- simple, at least in concept. The following discussion assumes that
- the name server is authoritative for the zone that would have held
- the non-existent RRsets matching SNAME. The algorithm below is
- written for clarity, not for efficiency.
-
- To find the NSEC that proves that no RRsets matching name N exist in
- the zone Z that would have held them, construct a sequence, S,
- consisting of the owner names of every RRset in Z, sorted into
-
-
-
-Arends, et al. Standards Track [Page 13]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- canonical order ([RFC4034]), with no duplicate names. Find the name
- M that would have immediately preceded N in S if any RRsets with
- owner name N had existed. M is the owner name of the NSEC RR that
- proves that no RRsets exist with owner name N.
-
- The algorithm for finding the NSEC RR that proves that a given name
- is not covered by any applicable wildcard is similar but requires an
- extra step. More precisely, the algorithm for finding the NSEC
- proving that no RRsets exist with the applicable wildcard name is
- precisely the same as the algorithm for finding the NSEC RR that
- proves that RRsets with any other owner name do not exist. The part
- that's missing is a method of determining the name of the non-
- existent applicable wildcard. In practice, this is easy, because the
- authoritative name server has already checked for the presence of
- precisely this wildcard name as part of step (1)(c) of the normal
- lookup algorithm described in Section 4.3.2 of [RFC1034].
-
-3.1.4. Including DS RRs in a Response
-
- When responding to a query that has the DO bit set, a security-aware
- authoritative name server returning a referral includes DNSSEC data
- along with the NS RRset.
-
- If a DS RRset is present at the delegation point, the name server
- MUST return both the DS RRset and its associated RRSIG RR(s) in the
- Authority section along with the NS RRset.
-
- If no DS RRset is present at the delegation point, the name server
- MUST return both the NSEC RR that proves that the DS RRset is not
- present and the NSEC RR's associated RRSIG RR(s) along with the NS
- RRset. The name server MUST place the NS RRset before the NSEC RRset
- and its associated RRSIG RR(s).
-
- Including these DS, NSEC, and RRSIG RRs increases the size of
- referral messages and may cause some or all glue RRs to be omitted.
- If space does not permit inclusion of the DS or NSEC RRset and
- associated RRSIG RRs, the name server MUST set the TC bit (see
- Section 3.1.1).
-
-3.1.4.1. Responding to Queries for DS RRs
-
- The DS resource record type is unusual in that it appears only on the
- parent zone's side of a zone cut. For example, the DS RRset for the
- delegation of "foo.example" is stored in the "example" zone rather
- than in the "foo.example" zone. This requires special processing
- rules for both name servers and resolvers, as the name server for the
- child zone is authoritative for the name at the zone cut by the
- normal DNS rules but the child zone does not contain the DS RRset.
-
-
-
-Arends, et al. Standards Track [Page 14]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- A security-aware resolver sends queries to the parent zone when
- looking for a needed DS RR at a delegation point (see Section 4.2).
- However, special rules are necessary to avoid confusing
- security-oblivious resolvers which might become involved in
- processing such a query (for example, in a network configuration that
- forces a security-aware resolver to channel its queries through a
- security-oblivious recursive name server). The rest of this section
- describes how a security-aware name server processes DS queries in
- order to avoid this problem.
-
- The need for special processing by a security-aware name server only
- arises when all the following conditions are met:
-
- o The name server has received a query for the DS RRset at a zone
- cut.
-
- o The name server is authoritative for the child zone.
-
- o The name server is not authoritative for the parent zone.
-
- o The name server does not offer recursion.
-
- In all other cases, the name server either has some way of obtaining
- the DS RRset or could not have been expected to have the DS RRset
- even by the pre-DNSSEC processing rules, so the name server can
- return either the DS RRset or an error response according to the
- normal processing rules.
-
- If all the above conditions are met, however, the name server is
- authoritative for SNAME but cannot supply the requested RRset. In
- this case, the name server MUST return an authoritative "no data"
- response showing that the DS RRset does not exist in the child zone's
- apex. See Appendix B.8 for an example of such a response.
-
-3.1.5. Responding to Queries for Type AXFR or IXFR
-
- DNSSEC does not change the DNS zone transfer process. A signed zone
- will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
- records have no special meaning with respect to a zone transfer
- operation.
-
- An authoritative name server is not required to verify that a zone is
- properly signed before sending or accepting a zone transfer.
- However, an authoritative name server MAY choose to reject the entire
- zone transfer if the zone fails to meet any of the signing
- requirements described in Section 2. The primary objective of a zone
- transfer is to ensure that all authoritative name servers have
- identical copies of the zone. An authoritative name server that
-
-
-
-Arends, et al. Standards Track [Page 15]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- chooses to perform its own zone validation MUST NOT selectively
- reject some RRs and accept others.
-
- DS RRsets appear only on the parental side of a zone cut and are
- authoritative data in the parent zone. As with any other
- authoritative RRset, the DS RRset MUST be included in zone transfers
- of the zone in which the RRset is authoritative data. In the case of
- the DS RRset, this is the parent zone.
-
- NSEC RRs appear in both the parent and child zones at a zone cut and
- are authoritative data in both the parent and child zones. The
- parental and child NSEC RRs at a zone cut are never identical to each
- other, as the NSEC RR in the child zone's apex will always indicate
- the presence of the child zone's SOA RR whereas the parental NSEC RR
- at the zone cut will never indicate the presence of an SOA RR. As
- with any other authoritative RRs, NSEC RRs MUST be included in zone
- transfers of the zone in which they are authoritative data. The
- parental NSEC RR at a zone cut MUST be included in zone transfers of
- the parent zone, and the NSEC at the zone apex of the child zone MUST
- be included in zone transfers of the child zone.
-
- RRSIG RRs appear in both the parent and child zones at a zone cut and
- are authoritative in whichever zone contains the authoritative RRset
- for which the RRSIG RR provides the signature. That is, the RRSIG RR
- for a DS RRset or a parental NSEC RR at a zone cut will be
- authoritative in the parent zone, and the RRSIG for any RRset in the
- child zone's apex will be authoritative in the child zone. Parental
- and child RRSIG RRs at a zone cut will never be identical to each
- other, as the Signer's Name field of an RRSIG RR in the child zone's
- apex will indicate a DNSKEY RR in the child zone's apex whereas the
- same field of a parental RRSIG RR at the zone cut will indicate a
- DNSKEY RR in the parent zone's apex. As with any other authoritative
- RRs, RRSIG RRs MUST be included in zone transfers of the zone in
- which they are authoritative data.
-
-3.1.6. The AD and CD Bits in an Authoritative Response
-
- The CD and AD bits are designed for use in communication between
- security-aware resolvers and security-aware recursive name servers.
- These bits are for the most part not relevant to query processing by
- security-aware authoritative name servers.
-
- A security-aware name server does not perform signature validation
- for authoritative data during query processing, even when the CD bit
- is clear. A security-aware name server SHOULD clear the CD bit when
- composing an authoritative response.
-
-
-
-
-
-Arends, et al. Standards Track [Page 16]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- A security-aware name server MUST NOT set the AD bit in a response
- unless the name server considers all RRsets in the Answer and
- Authority sections of the response to be authentic. A security-aware
- name server's local policy MAY consider data from an authoritative
- zone to be authentic without further validation. However, the name
- server MUST NOT do so unless the name server obtained the
- authoritative zone via secure means (such as a secure zone transfer
- mechanism) and MUST NOT do so unless this behavior has been
- configured explicitly.
-
- A security-aware name server that supports recursion MUST follow the
- rules for the CD and AD bits given in Section 3.2 when generating a
- response that involves data obtained via recursion.
-
-3.2. Recursive Name Servers
-
- As explained in [RFC4033], a security-aware recursive name server is
- an entity that acts in both the security-aware name server and
- security-aware resolver roles. This section uses the terms "name
- server side" and "resolver side" to refer to the code within a
- security-aware recursive name server that implements the
- security-aware name server role and the code that implements the
- security-aware resolver role, respectively.
-
- The resolver side follows the usual rules for caching and negative
- caching that would apply to any security-aware resolver.
-
-3.2.1. The DO Bit
-
- The resolver side of a security-aware recursive name server MUST set
- the DO bit when sending requests, regardless of the state of the DO
- bit in the initiating request received by the name server side. If
- the DO bit in an initiating query is not set, the name server side
- MUST strip any authenticating DNSSEC RRs from the response but MUST
- NOT strip any DNSSEC RR types that the initiating query explicitly
- requested.
-
-3.2.2. The CD Bit
-
- The CD bit exists in order to allow a security-aware resolver to
- disable signature validation in a security-aware name server's
- processing of a particular query.
-
- The name server side MUST copy the setting of the CD bit from a query
- to the corresponding response.
-
- The name server side of a security-aware recursive name server MUST
- pass the state of the CD bit to the resolver side along with the rest
-
-
-
-Arends, et al. Standards Track [Page 17]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- of an initiating query, so that the resolver side will know whether
- it is required to verify the response data it returns to the name
- server side. If the CD bit is set, it indicates that the originating
- resolver is willing to perform whatever authentication its local
- policy requires. Thus, the resolver side of the recursive name
- server need not perform authentication on the RRsets in the response.
- When the CD bit is set, the recursive name server SHOULD, if
- possible, return the requested data to the originating resolver, even
- if the recursive name server's local authentication policy would
- reject the records in question. That is, by setting the CD bit, the
- originating resolver has indicated that it takes responsibility for
- performing its own authentication, and the recursive name server
- should not interfere.
-
- If the resolver side implements a BAD cache (see Section 4.7) and the
- name server side receives a query that matches an entry in the
- resolver side's BAD cache, the name server side's response depends on
- the state of the CD bit in the original query. If the CD bit is set,
- the name server side SHOULD return the data from the BAD cache; if
- the CD bit is not set, the name server side MUST return RCODE 2
- (server failure).
-
- The intent of the above rule is to provide the raw data to clients
- that are capable of performing their own signature verification
- checks while protecting clients that depend on the resolver side of a
- security-aware recursive name server to perform such checks. Several
- of the possible reasons why signature validation might fail involve
- conditions that may not apply equally to the recursive name server
- and the client that invoked it. For example, the recursive name
- server's clock may be set incorrectly, or the client may have
- knowledge of a relevant island of security that the recursive name
- server does not share. In such cases, "protecting" a client that is
- capable of performing its own signature validation from ever seeing
- the "bad" data does not help the client.
-
-3.2.3. The AD Bit
-
- The name server side of a security-aware recursive name server MUST
- NOT set the AD bit in a response unless the name server considers all
- RRsets in the Answer and Authority sections of the response to be
- authentic. The name server side SHOULD set the AD bit if and only if
- the resolver side considers all RRsets in the Answer section and any
- relevant negative response RRs in the Authority section to be
- authentic. The resolver side MUST follow the procedure described in
- Section 5 to determine whether the RRs in question are authentic.
- However, for backward compatibility, a recursive name server MAY set
- the AD bit when a response includes unsigned CNAME RRs if those CNAME
-
-
-
-
-Arends, et al. Standards Track [Page 18]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- RRs demonstrably could have been synthesized from an authentic DNAME
- RR that is also included in the response according to the synthesis
- rules described in [RFC2672].
-
-3.3. Example DNSSEC Responses
-
- See Appendix B for example response packets.
-
-4. Resolving
-
- This section describes the behavior of entities that include
- security-aware resolver functions. In many cases such functions will
- be part of a security-aware recursive name server, but a stand-alone
- security-aware resolver has many of the same requirements. Functions
- specific to security-aware recursive name servers are described in
- Section 3.2.
-
-4.1. EDNS Support
-
- A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
- pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
-
- A security-aware resolver MUST support a message size of at least
- 1220 octets, SHOULD support a message size of 4000 octets, and MUST
- use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
- to advertise the message size that it is willing to accept. A
- security-aware resolver's IP layer MUST handle fragmented UDP packets
- correctly regardless of whether any such fragmented packets were
- received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and
- [RFC3226] for discussion of these requirements.
-
-4.2. Signature Verification Support
-
- A security-aware resolver MUST support the signature verification
- mechanisms described in Section 5 and SHOULD apply them to every
- received response, except when:
-
- o the security-aware resolver is part of a security-aware recursive
- name server, and the response is the result of recursion on behalf
- of a query received with the CD bit set;
-
- o the response is the result of a query generated directly via some
- form of application interface that instructed the security-aware
- resolver not to perform validation for this query; or
-
- o validation for this query has been disabled by local policy.
-
-
-
-
-
-Arends, et al. Standards Track [Page 19]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- A security-aware resolver's support for signature verification MUST
- include support for verification of wildcard owner names.
-
- Security-aware resolvers MAY query for missing security RRs in an
- attempt to perform validation; implementations that choose to do so
- must be aware that the answers received may not be sufficient to
- validate the original response. For example, a zone update may have
- changed (or deleted) the desired information between the original and
- follow-up queries.
-
- When attempting to retrieve missing NSEC RRs that reside on the
- parental side at a zone cut, a security-aware iterative-mode resolver
- MUST query the name servers for the parent zone, not the child zone.
-
- When attempting to retrieve a missing DS, a security-aware
- iterative-mode resolver MUST query the name servers for the parent
- zone, not the child zone. As explained in Section 3.1.4.1,
- security-aware name servers need to apply special processing rules to
- handle the DS RR, and in some situations the resolver may also need
- to apply special rules to locate the name servers for the parent zone
- if the resolver does not already have the parent's NS RRset. To
- locate the parent NS RRset, the resolver can start with the
- delegation name, strip off the leftmost label, and query for an NS
- RRset by that name. If no NS RRset is present at that name, the
- resolver then strips off the leftmost remaining label and retries the
- query for that name, repeating this process of walking up the tree
- until it either finds the NS RRset or runs out of labels.
-
-4.3. Determining Security Status of Data
-
- A security-aware resolver MUST be able to determine whether it should
- expect a particular RRset to be signed. More precisely, a
- security-aware resolver must be able to distinguish between four
- cases:
-
- Secure: An RRset for which the resolver is able to build a chain of
- signed DNSKEY and DS RRs from a trusted security anchor to the
- RRset. In this case, the RRset should be signed and is subject to
- signature validation, as described above.
-
- Insecure: An RRset for which the resolver knows that it has no chain
- of signed DNSKEY and DS RRs from any trusted starting point to the
- RRset. This can occur when the target RRset lies in an unsigned
- zone or in a descendent of an unsigned zone. In this case, the
- RRset may or may not be signed, but the resolver will not be able
- to verify the signature.
-
-
-
-
-
-Arends, et al. Standards Track [Page 20]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- Bogus: An RRset for which the resolver believes that it ought to be
- able to establish a chain of trust but for which it is unable to
- do so, either due to signatures that for some reason fail to
- validate or due to missing data that the relevant DNSSEC RRs
- indicate should be present. This case may indicate an attack but
- may also indicate a configuration error or some form of data
- corruption.
-
- Indeterminate: An RRset for which the resolver is not able to
- determine whether the RRset should be signed, as the resolver is
- not able to obtain the necessary DNSSEC RRs. This can occur when
- the security-aware resolver is not able to contact security-aware
- name servers for the relevant zones.
-
-4.4. Configured Trust Anchors
-
- A security-aware resolver MUST be capable of being configured with at
- least one trusted public key or DS RR and SHOULD be capable of being
- configured with multiple trusted public keys or DS RRs. Since a
- security-aware resolver will not be able to validate signatures
- without such a configured trust anchor, the resolver SHOULD have some
- reasonably robust mechanism for obtaining such keys when it boots;
- examples of such a mechanism would be some form of non-volatile
- storage (such as a disk drive) or some form of trusted local network
- configuration mechanism.
-
- Note that trust anchors also cover key material that is updated in a
- secure manner. This secure manner could be through physical media, a
- key exchange protocol, or some other out-of-band means.
-
-4.5. Response Caching
-
- A security-aware resolver SHOULD cache each response as a single
- atomic entry containing the entire answer, including the named RRset
- and any associated DNSSEC RRs. The resolver SHOULD discard the
- entire atomic entry when any of the RRs contained in it expire. In
- most cases the appropriate cache index for the atomic entry will be
- the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
- form described in Section 3.1.3.2 the appropriate cache index will be
- the double <QNAME,QCLASS>.
-
- The reason for these recommendations is that, between the initial
- query and the expiration of the data from the cache, the
- authoritative data might have been changed (for example, via dynamic
- update).
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 21]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- There are two situations for which this is relevant:
-
- 1. By using the RRSIG record, it is possible to deduce that an
- answer was synthesized from a wildcard. A security-aware
- recursive name server could store this wildcard data and use it
- to generate positive responses to queries other than the name for
- which the original answer was first received.
-
- 2. NSEC RRs received to prove the non-existence of a name could be
- reused by a security-aware resolver to prove the non-existence of
- any name in the name range it spans.
-
- In theory, a resolver could use wildcards or NSEC RRs to generate
- positive and negative responses (respectively) until the TTL or
- signatures on the records in question expire. However, it seems
- prudent for resolvers to avoid blocking new authoritative data or
- synthesizing new data on their own. Resolvers that follow this
- recommendation will have a more consistent view of the namespace.
-
-4.6. Handling of the CD and AD Bits
-
- A security-aware resolver MAY set a query's CD bit in order to
- indicate that the resolver takes responsibility for performing
- whatever authentication its local policy requires on the RRsets in
- the response. See Section 3.2 for the effect this bit has on the
- behavior of security-aware recursive name servers.
-
- A security-aware resolver MUST clear the AD bit when composing query
- messages to protect against buggy name servers that blindly copy
- header bits that they do not understand from the query message to the
- response message.
-
- A resolver MUST disregard the meaning of the CD and AD bits in a
- response unless the response was obtained by using a secure channel
- or the resolver was specifically configured to regard the message
- header bits without using a secure channel.
-
-4.7. Caching BAD Data
-
- While many validation errors will be transient, some are likely to be
- more persistent, such as those caused by administrative error
- (failure to re-sign a zone, clock skew, and so forth). Since
- requerying will not help in these cases, validating resolvers might
- generate a significant amount of unnecessary DNS traffic as a result
- of repeated queries for RRsets with persistent validation failures.
-
- To prevent such unnecessary DNS traffic, security-aware resolvers MAY
- cache data with invalid signatures, with some restrictions.
-
-
-
-Arends, et al. Standards Track [Page 22]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- Conceptually, caching such data is similar to negative caching
- ([RFC2308]), except that instead of caching a valid negative
- response, the resolver is caching the fact that a particular answer
- failed to validate. This document refers to a cache of data with
- invalid signatures as a "BAD cache".
-
- Resolvers that implement a BAD cache MUST take steps to prevent the
- cache from being useful as a denial-of-service attack amplifier,
- particularly the following:
-
- o Since RRsets that fail to validate do not have trustworthy TTLs,
- the implementation MUST assign a TTL. This TTL SHOULD be small,
- in order to mitigate the effect of caching the results of an
- attack.
-
- o In order to prevent caching of a transient validation failure
- (which might be the result of an attack), resolvers SHOULD track
- queries that result in validation failures and SHOULD only answer
- from the BAD cache after the number of times that responses to
- queries for that particular <QNAME, QTYPE, QCLASS> have failed to
- validate exceeds a threshold value.
-
- Resolvers MUST NOT return RRsets from the BAD cache unless the
- resolver is not required to validate the signatures of the RRsets in
- question under the rules given in Section 4.2 of this document. See
- Section 3.2.2 for discussion of how the responses returned by a
- security-aware recursive name server interact with a BAD cache.
-
-4.8. Synthesized CNAMEs
-
- A validating security-aware resolver MUST treat the signature of a
- valid signed DNAME RR as also covering unsigned CNAME RRs that could
- have been synthesized from the DNAME RR, as described in [RFC2672],
- at least to the extent of not rejecting a response message solely
- because it contains such CNAME RRs. The resolver MAY retain such
- CNAME RRs in its cache or in the answers it hands back, but is not
- required to do so.
-
-4.9. Stub Resolvers
-
- A security-aware stub resolver MUST support the DNSSEC RR types, at
- least to the extent of not mishandling responses just because they
- contain DNSSEC RRs.
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 23]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-4.9.1. Handling of the DO Bit
-
- A non-validating security-aware stub resolver MAY include the DNSSEC
- RRs returned by a security-aware recursive name server as part of the
- data that the stub resolver hands back to the application that
- invoked it, but is not required to do so. A non-validating stub
- resolver that seeks to do this will need to set the DO bit in order
- to receive DNSSEC RRs from the recursive name server.
-
- A validating security-aware stub resolver MUST set the DO bit,
- because otherwise it will not receive the DNSSEC RRs it needs to
- perform signature validation.
-
-4.9.2. Handling of the CD Bit
-
- A non-validating security-aware stub resolver SHOULD NOT set the CD
- bit when sending queries unless it is requested by the application
- layer, as by definition, a non-validating stub resolver depends on
- the security-aware recursive name server to perform validation on its
- behalf.
-
- A validating security-aware stub resolver SHOULD set the CD bit,
- because otherwise the security-aware recursive name server will
- answer the query using the name server's local policy, which may
- prevent the stub resolver from receiving data that would be
- acceptable to the stub resolver's local policy.
-
-4.9.3. Handling of the AD Bit
-
- A non-validating security-aware stub resolver MAY chose to examine
- the setting of the AD bit in response messages that it receives in
- order to determine whether the security-aware recursive name server
- that sent the response claims to have cryptographically verified the
- data in the Answer and Authority sections of the response message.
- Note, however, that the responses received by a security-aware stub
- resolver are heavily dependent on the local policy of the
- security-aware recursive name server. Therefore, there may be little
- practical value in checking the status of the AD bit, except perhaps
- as a debugging aid. In any case, a security-aware stub resolver MUST
- NOT place any reliance on signature validation allegedly performed on
- its behalf, except when the security-aware stub resolver obtained the
- data in question from a trusted security-aware recursive name server
- via a secure channel.
-
- A validating security-aware stub resolver SHOULD NOT examine the
- setting of the AD bit in response messages, as, by definition, the
- stub resolver performs its own signature validation regardless of the
- setting of the AD bit.
-
-
-
-Arends, et al. Standards Track [Page 24]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-5. Authenticating DNS Responses
-
- To use DNSSEC RRs for authentication, a security-aware resolver
- requires configured knowledge of at least one authenticated DNSKEY or
- DS RR. The process for obtaining and authenticating this initial
- trust anchor is achieved via some external mechanism. For example, a
- resolver could use some off-line authenticated exchange to obtain a
- zone's DNSKEY RR or to obtain a DS RR that identifies and
- authenticates a zone's DNSKEY RR. The remainder of this section
- assumes that the resolver has somehow obtained an initial set of
- trust anchors.
-
- An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
- RRset. To authenticate an apex DNSKEY RRset by using an initial key,
- the resolver MUST:
-
- 1. verify that the initial DNSKEY RR appears in the apex DNSKEY
- RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
- bit 7) set; and
-
- 2. verify that there is some RRSIG RR that covers the apex DNSKEY
- RRset, and that the combination of the RRSIG RR and the initial
- DNSKEY RR authenticates the DNSKEY RRset. The process for using
- an RRSIG RR to authenticate an RRset is described in Section 5.3.
-
- Once the resolver has authenticated the apex DNSKEY RRset by using an
- initial DNSKEY RR, delegations from that zone can be authenticated by
- using DS RRs. This allows a resolver to start from an initial key
- and use DS RRsets to proceed recursively down the DNS tree, obtaining
- other apex DNSKEY RRsets. If the resolver were configured with a
- root DNSKEY RR, and if every delegation had a DS RR associated with
- it, then the resolver could obtain and validate any apex DNSKEY
- RRset. The process of using DS RRs to authenticate referrals is
- described in Section 5.2.
-
- Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
- DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
- RRsets in the zone once the resolver has authenticated a zone's apex
- DNSKEY RRset. Section 5.4 shows how the resolver can use
- authenticated NSEC RRsets from the zone to prove that an RRset is not
- present in the zone.
-
- When a resolver indicates support for DNSSEC (by setting the DO bit),
- a security-aware name server should attempt to provide the necessary
- DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
- However, a security-aware resolver may still receive a response that
- lacks the appropriate DNSSEC RRs, whether due to configuration issues
- such as an upstream security-oblivious recursive name server that
-
-
-
-Arends, et al. Standards Track [Page 25]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- accidentally interferes with DNSSEC RRs or due to a deliberate attack
- in which an adversary forges a response, strips DNSSEC RRs from a
- response, or modifies a query so that DNSSEC RRs appear not to be
- requested. The absence of DNSSEC data in a response MUST NOT by
- itself be taken as an indication that no authentication information
- exists.
-
- A resolver SHOULD expect authentication information from signed
- zones. A resolver SHOULD believe that a zone is signed if the
- resolver has been configured with public key information for the
- zone, or if the zone's parent is signed and the delegation from the
- parent contains a DS RRset.
-
-5.1. Special Considerations for Islands of Security
-
- Islands of security (see [RFC4033]) are signed zones for which it is
- not possible to construct an authentication chain to the zone from
- its parent. Validating signatures within an island of security
- requires that the validator have some other means of obtaining an
- initial authenticated zone key for the island. If a validator cannot
- obtain such a key, it SHOULD switch to operating as if the zones in
- the island of security are unsigned.
-
- All the normal processes for validating responses apply to islands of
- security. The only difference between normal validation and
- validation within an island of security is in how the validator
- obtains a trust anchor for the authentication chain.
-
-5.2. Authenticating Referrals
-
- Once the apex DNSKEY RRset for a signed parent zone has been
- authenticated, DS RRsets can be used to authenticate the delegation
- to a signed child zone. A DS RR identifies a DNSKEY RR in the child
- zone's apex DNSKEY RRset and contains a cryptographic digest of the
- child zone's DNSKEY RR. Use of a strong cryptographic digest
- algorithm ensures that it is computationally infeasible for an
- adversary to generate a DNSKEY RR that matches the digest. Thus,
- authenticating the digest allows a resolver to authenticate the
- matching DNSKEY RR. The resolver can then use this child DNSKEY RR
- to authenticate the entire child apex DNSKEY RRset.
-
- Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
- can be authenticated if all of the following hold:
-
- o The DS RR has been authenticated using some DNSKEY RR in the
- parent's apex DNSKEY RRset (see Section 5.3).
-
-
-
-
-
-Arends, et al. Standards Track [Page 26]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- o The Algorithm and Key Tag in the DS RR match the Algorithm field
- and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
- RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
- using the digest algorithm specified in the DS RR's Digest Type
- field, the resulting digest value matches the Digest field of the
- DS RR.
-
- o The matching DNSKEY RR in the child zone has the Zone Flag bit
- set, the corresponding private key has signed the child zone's
- apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
- child zone's apex DNSKEY RRset.
-
- If the referral from the parent zone did not contain a DS RRset, the
- response should have included a signed NSEC RRset proving that no DS
- RRset exists for the delegated name (see Section 3.1.4). A
- security-aware resolver MUST query the name servers for the parent
- zone for the DS RRset if the referral includes neither a DS RRset nor
- a NSEC RRset proving that the DS RRset does not exist (see Section
- 4).
-
- If the validator authenticates an NSEC RRset that proves that no DS
- RRset is present for this zone, then there is no authentication path
- leading from the parent to the child. If the resolver has an initial
- DNSKEY or DS RR that belongs to the child zone or to any delegation
- below the child zone, this initial DNSKEY or DS RR MAY be used to
- re-establish an authentication path. If no such initial DNSKEY or DS
- RR exists, the validator cannot authenticate RRsets in or below the
- child zone.
-
- If the validator does not support any of the algorithms listed in an
- authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- Note that, for a signed delegation, there are two NSEC RRs associated
- with the delegated name. One NSEC RR resides in the parent zone and
- can be used to prove whether a DS RRset exists for the delegated
- name. The second NSEC RR resides in the child zone and identifies
- which RRsets are present at the apex of the child zone. The parent
- NSEC RR and child NSEC RR can always be distinguished because the SOA
- bit will be set in the child NSEC RR and clear in the parent NSEC RR.
- A security-aware resolver MUST use the parent NSEC RR when attempting
- to prove that a DS RRset does not exist.
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 27]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- If the resolver does not support any of the algorithms listed in an
- authenticated DS RRset, then the resolver will not be able to verify
- the authentication path to the child zone. In this case, the
- resolver SHOULD treat the child zone as if it were unsigned.
-
-5.3. Authenticating an RRset with an RRSIG RR
-
- A validator can use an RRSIG RR and its corresponding DNSKEY RR to
- attempt to authenticate RRsets. The validator first checks the RRSIG
- RR to verify that it covers the RRset, has a valid time interval, and
- identifies a valid DNSKEY RR. The validator then constructs the
- canonical form of the signed data by appending the RRSIG RDATA
- (excluding the Signature Field) with the canonical form of the
- covered RRset. Finally, the validator uses the public key and
- signature to authenticate the signed data. Sections 5.3.1, 5.3.2,
- and 5.3.3 describe each step in detail.
-
-5.3.1. Checking the RRSIG RR Validity
-
- A security-aware resolver can use an RRSIG RR to authenticate an
- RRset if all of the following conditions hold:
-
- o The RRSIG RR and the RRset MUST have the same owner name and the
- same class.
-
- o The RRSIG RR's Signer's Name field MUST be the name of the zone
- that contains the RRset.
-
- o The RRSIG RR's Type Covered field MUST equal the RRset's type.
-
- o The number of labels in the RRset owner name MUST be greater than
- or equal to the value in the RRSIG RR's Labels field.
-
- o The validator's notion of the current time MUST be less than or
- equal to the time listed in the RRSIG RR's Expiration field.
-
- o The validator's notion of the current time MUST be greater than or
- equal to the time listed in the RRSIG RR's Inception field.
-
- o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
- match the owner name, algorithm, and key tag for some DNSKEY RR in
- the zone's apex DNSKEY RRset.
-
- o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
- RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
- set.
-
-
-
-
-
-Arends, et al. Standards Track [Page 28]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- It is possible for more than one DNSKEY RR to match the conditions
- above. In this case, the validator cannot predetermine which DNSKEY
- RR to use to authenticate the signature, and it MUST try each
- matching DNSKEY RR until either the signature is validated or the
- validator has run out of matching public keys to try.
-
- Note that this authentication process is only meaningful if the
- validator authenticates the DNSKEY RR before using it to validate
- signatures. The matching DNSKEY RR is considered to be authentic if:
-
- o the apex DNSKEY RRset containing the DNSKEY RR is considered
- authentic; or
-
- o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
- and the DNSKEY RR either matches an authenticated DS RR from the
- parent zone or matches a trust anchor.
-
-5.3.2. Reconstructing the Signed Data
-
- Once the RRSIG RR has met the validity requirements described in
- Section 5.3.1, the validator has to reconstruct the original signed
- data. The original signed data includes RRSIG RDATA (excluding the
- Signature field) and the canonical form of the RRset. Aside from
- being ordered, the canonical form of the RRset might also differ from
- the received RRset due to DNS name compression, decremented TTLs, or
- wildcard expansion. The validator should use the following to
- reconstruct the original signed data:
-
- signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
-
- "|" denotes concatenation
-
- RRSIG_RDATA is the wire format of the RRSIG RDATA fields
- with the Signature field excluded and the Signer's Name
- in canonical form.
-
- RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
-
- name is calculated according to the function below
-
- class is the RRset's class
-
- type is the RRset type and all RRs in the class
-
- OrigTTL is the value from the RRSIG Original TTL field
-
- All names in the RDATA field are in canonical form
-
-
-
-
-Arends, et al. Standards Track [Page 29]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- The set of all RR(i) is sorted into canonical order.
-
- To calculate the name:
- let rrsig_labels = the value of the RRSIG Labels field
-
- let fqdn = RRset's fully qualified domain name in
- canonical form
-
- let fqdn_labels = Label count of the fqdn above.
-
- if rrsig_labels = fqdn_labels,
- name = fqdn
-
- if rrsig_labels < fqdn_labels,
- name = "*." | the rightmost rrsig_label labels of the
- fqdn
-
- if rrsig_labels > fqdn_labels
- the RRSIG RR did not pass the necessary validation
- checks and MUST NOT be used to authenticate this
- RRset.
-
- The canonical forms for names and RRsets are defined in [RFC4034].
-
- NSEC RRsets at a delegation boundary require special processing.
- There are two distinct NSEC RRsets associated with a signed delegated
- name. One NSEC RRset resides in the parent zone, and specifies which
- RRsets are present at the parent zone. The second NSEC RRset resides
- at the child zone and identifies which RRsets are present at the apex
- in the child zone. The parent NSEC RRset and child NSEC RRset can
- always be distinguished as only a child NSEC RR will indicate that an
- SOA RRset exists at the name. When reconstructing the original NSEC
- RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
- be combined with NSEC RRs from the child zone. When reconstructing
- the original NSEC RRset for the apex of the child zone, the NSEC RRs
- MUST NOT be combined with NSEC RRs from the parent zone.
-
- Note that each of the two NSEC RRsets at a delegation point has a
- corresponding RRSIG RR with an owner name matching the delegated
- name, and each of these RRSIG RRs is authoritative data associated
- with the same zone that contains the corresponding NSEC RRset. If
- necessary, a resolver can tell these RRSIG RRs apart by checking the
- Signer's Name field.
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 30]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-5.3.3. Checking the Signature
-
- Once the resolver has validated the RRSIG RR as described in Section
- 5.3.1 and reconstructed the original signed data as described in
- Section 5.3.2, the validator can attempt to use the cryptographic
- signature to authenticate the signed data, and thus (finally!)
- authenticate the RRset.
-
- The Algorithm field in the RRSIG RR identifies the cryptographic
- algorithm used to generate the signature. The signature itself is
- contained in the Signature field of the RRSIG RDATA, and the public
- key used to verify the signature is contained in the Public Key field
- of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034]
- provides a list of algorithm types and provides pointers to the
- documents that define each algorithm's use.
-
- Note that it is possible for more than one DNSKEY RR to match the
- conditions in Section 5.3.1. In this case, the validator can only
- determine which DNSKEY RR is correct by trying each matching public
- key until the validator either succeeds in validating the signature
- or runs out of keys to try.
-
- If the Labels field of the RRSIG RR is not equal to the number of
- labels in the RRset's fully qualified owner name, then the RRset is
- either invalid or the result of wildcard expansion. The resolver
- MUST verify that wildcard expansion was applied properly before
- considering the RRset to be authentic. Section 5.3.4 describes how
- to determine whether a wildcard was applied properly.
-
- If other RRSIG RRs also cover this RRset, the local resolver security
- policy determines whether the resolver also has to test these RRSIG
- RRs and how to resolve conflicts if these RRSIG RRs lead to differing
- results.
-
- If the resolver accepts the RRset as authentic, the validator MUST
- set the TTL of the RRSIG RR and each RR in the authenticated RRset to
- a value no greater than the minimum of:
-
- o the RRset's TTL as received in the response;
-
- o the RRSIG RR's TTL as received in the response;
-
- o the value in the RRSIG RR's Original TTL field; and
-
- o the difference of the RRSIG RR's Signature Expiration time and the
- current time.
-
-
-
-
-
-Arends, et al. Standards Track [Page 31]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-5.3.4. Authenticating a Wildcard Expanded RRset Positive Response
-
- If the number of labels in an RRset's owner name is greater than the
- Labels field of the covering RRSIG RR, then the RRset and its
- covering RRSIG RR were created as a result of wildcard expansion.
- Once the validator has verified the signature, as described in
- Section 5.3, it must take additional steps to verify the non-
- existence of an exact match or closer wildcard match for the query.
- Section 5.4 discusses these steps.
-
- Note that the response received by the resolver should include all
- NSEC RRs needed to authenticate the response (see Section 3.1.3).
-
-5.4. Authenticated Denial of Existence
-
- A resolver can use authenticated NSEC RRs to prove that an RRset is
- not present in a signed zone. Security-aware name servers should
- automatically include any necessary NSEC RRs for signed zones in
- their responses to security-aware resolvers.
-
- Denial of existence is determined by the following rules:
-
- o If the requested RR name matches the owner name of an
- authenticated NSEC RR, then the NSEC RR's type bit map field lists
- all RR types present at that owner name, and a resolver can prove
- that the requested RR type does not exist by checking for the RR
- type in the bit map. If the number of labels in an authenticated
- NSEC RR's owner name equals the Labels field of the covering RRSIG
- RR, then the existence of the NSEC RR proves that wildcard
- expansion could not have been used to match the request.
-
- o If the requested RR name would appear after an authenticated NSEC
- RR's owner name and before the name listed in that NSEC RR's Next
- Domain Name field according to the canonical DNS name order
- defined in [RFC4034], then no RRsets with the requested name exist
- in the zone. However, it is possible that a wildcard could be
- used to match the requested RR owner name and type, so proving
- that the requested RRset does not exist also requires proving that
- no possible wildcard RRset exists that could have been used to
- generate a positive response.
-
- In addition, security-aware resolvers MUST authenticate the NSEC
- RRsets that comprise the non-existence proof as described in Section
- 5.3.
-
- To prove the non-existence of an RRset, the resolver must be able to
- verify both that the queried RRset does not exist and that no
- relevant wildcard RRset exists. Proving this may require more than
-
-
-
-Arends, et al. Standards Track [Page 32]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- one NSEC RRset from the zone. If the complete set of necessary NSEC
- RRsets is not present in a response (perhaps due to message
- truncation), then a security-aware resolver MUST resend the query in
- order to attempt to obtain the full collection of NSEC RRs necessary
- to verify the non-existence of the requested RRset. As with all DNS
- operations, however, the resolver MUST bound the work it puts into
- answering any particular query.
-
- Since a validated NSEC RR proves the existence of both itself and its
- corresponding RRSIG RR, a validator MUST ignore the settings of the
- NSEC and RRSIG bits in an NSEC RR.
-
-5.5. Resolver Behavior When Signatures Do Not Validate
-
- If for whatever reason none of the RRSIGs can be validated, the
- response SHOULD be considered BAD. If the validation was being done
- to service a recursive query, the name server MUST return RCODE 2 to
- the originating client. However, it MUST return the full response if
- and only if the original query had the CD bit set. Also see Section
- 4.7 on caching responses that do not validate.
-
-5.6. Authentication Example
-
- Appendix C shows an example of the authentication process.
-
-6. IANA Considerations
-
- [RFC4034] contains a review of the IANA considerations introduced by
- DNSSEC. The following are additional IANA considerations discussed
- in this document:
-
- [RFC2535] reserved the CD and AD bits in the message header. The
- meaning of the AD bit was redefined in [RFC3655], and the meaning of
- both the CD and AD bit are restated in this document. No new bits in
- the DNS message header are defined in this document.
-
- [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
- and defined its use. The use is restated but not altered in this
- document.
-
-7. Security Considerations
-
- This document describes how the DNS security extensions use public
- key cryptography to sign and authenticate DNS resource record sets.
- Please see [RFC4033] for terminology and general security
- considerations related to DNSSEC; see [RFC4034] for considerations
- specific to the DNSSEC resource record types.
-
-
-
-
-Arends, et al. Standards Track [Page 33]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- An active attacker who can set the CD bit in a DNS query message or
- the AD bit in a DNS response message can use these bits to defeat the
- protection that DNSSEC attempts to provide to security-oblivious
- recursive-mode resolvers. For this reason, use of these control bits
- by a security-aware recursive-mode resolver requires a secure
- channel. See Sections 3.2.2 and 4.9 for further discussion.
-
- The protocol described in this document attempts to extend the
- benefits of DNSSEC to security-oblivious stub resolvers. However, as
- recovery from validation failures is likely to be specific to
- particular applications, the facilities that DNSSEC provides for stub
- resolvers may prove inadequate. Operators of security-aware
- recursive name servers will have to pay close attention to the
- behavior of the applications that use their services when choosing a
- local validation policy; failure to do so could easily result in the
- recursive name server accidentally denying service to the clients it
- is intended to support.
-
-8. Acknowledgements
-
- This document was created from the input and ideas of the members of
- the DNS Extensions Working Group and working group mailing list. The
- editors would like to express their thanks for the comments and
- suggestions received during the revision of these security extension
- specifications. Although explicitly listing everyone who has
- contributed during the decade in which DNSSEC has been under
- development would be impossible, [RFC4033] includes a list of some of
- the participants who were kind enough to comment on these documents.
-
-9. References
-
-9.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC1122] Braden, R., "Requirements for Internet Hosts -
- Communication Layers", STD 3, RFC 1122, October 1989.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-
-
-
-Arends, et al. Standards Track [Page 34]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
- 2672, August 1999.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
- [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC
- 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for DNS Security Extensions", RFC
- 4034, March 2005.
-
-9.2. Informative References
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2535] Eastlake 3rd, D., "Domain Name System Security
- Extensions", RFC 2535, March 1999.
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
- Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 35]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-Appendix A. Signed Zone Example
-
- The following example shows a (small) complete signed zone.
-
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1081539377
- 3600
- 300
- 3600000
- 3600
- )
- 3600 RRSIG SOA 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
- 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
- vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
- DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
- jV7j86HyQgM5e7+miRAz8V01b0I= )
- 3600 NS ns1.example.
- 3600 NS ns2.example.
- 3600 RRSIG NS 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
- EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
- 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
- RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
- 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
- 3600 MX 1 xx.example.
- 3600 RRSIG MX 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
- 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
- VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
- 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
- W6OISukd1EQt7a0kygkg+PEDxdI= )
- 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- 3600 RRSIG NSEC 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
- FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
- Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
- SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
- jfFJ5arXf4nPxp/kEowGgBRzY/U= )
- 3600 DNSKEY 256 3 5 (
- AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
- rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
- k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
- vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
-
-
-
-Arends, et al. Standards Track [Page 36]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
- )
- 3600 DNSKEY 257 3 5 (
- AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
- LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
- syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
- RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
- Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
- )
- 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
- 20040409183619 9465 example.
- ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
- xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
- XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
- hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
- NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
- 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
- DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
- bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
- eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
- 7z5OXogYVaFzHKillDt3HRxHIZM= )
- a.example. 3600 IN NS ns1.a.example.
- 3600 IN NS ns2.a.example.
- 3600 DS 57855 5 1 (
- B6DCD485719ADCA18E5F3D48A2331627FDD3
- 636B )
- 3600 RRSIG DS 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
- oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
- kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
- EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
- Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
- 3600 NSEC ai.example. NS DS RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
- U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
- 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
- BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
- sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
- ai.example. 3600 IN A 192.0.2.9
- 3600 RRSIG A 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
-
-
-
-Arends, et al. Standards Track [Page 37]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
- ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
- hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
- ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
- 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
- 3600 HINFO "KLH-10" "ITS"
- 3600 RRSIG HINFO 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
- e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
- ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
- AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
- FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
- 3600 AAAA 2001:db8::f00:baa9
- 3600 RRSIG AAAA 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
- kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
- 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
- cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
- sZM6QjBBLmukH30+w1z3h8PUP2o= )
- 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
- CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
- P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
- 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
- AhS+JOVfDI/79QtyTI0SaDWcg8U= )
- b.example. 3600 IN NS ns1.b.example.
- 3600 IN NS ns2.b.example.
- 3600 NSEC ns1.example. NS RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
- 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
- xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
- 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
- vhRXgWT7OuFXldoCG6TfVFMs9xE= )
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
- ns1.example. 3600 IN A 192.0.2.1
- 3600 RRSIG A 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
- 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
- im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
- +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
-
-
-
-Arends, et al. Standards Track [Page 38]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- v/iVXSYC0b7mPSU+EOlknFpVECs= )
- 3600 NSEC ns2.example. A RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
- 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
- jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
- ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
- IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
- ns2.example. 3600 IN A 192.0.2.2
- 3600 RRSIG A 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
- Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
- yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
- 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
- rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
- 3600 NSEC *.w.example. A RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
- VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
- 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
- l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
- Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
- *.w.example. 3600 IN MX 1 ai.example.
- 3600 RRSIG MX 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
- f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
- tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
- TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
- 4kX18MMR34i8lC36SR5xBni8vHI= )
- 3600 NSEC x.w.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
- HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
- 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
- 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
- s1InQ2UoIv6tJEaaKkP701j8OLA= )
- x.w.example. 3600 IN MX 1 xx.example.
- 3600 RRSIG MX 5 3 3600 20040509183619 (
- 20040409183619 38519 example.
- Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
- XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
- H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
- kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
-
-
-
-Arends, et al. Standards Track [Page 39]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
- 3600 NSEC x.y.w.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 5 3 3600 20040509183619 (
- 20040409183619 38519 example.
- aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
- vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
- mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
- NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
- IjgiM8PXkBQtxPq37wDKALkyn7Q= )
- x.y.w.example. 3600 IN MX 1 xx.example.
- 3600 RRSIG MX 5 4 3600 20040509183619 (
- 20040409183619 38519 example.
- k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
- t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
- q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
- GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
- +gLcMZBnHJ326nb/TOOmrqNmQQE= )
- 3600 NSEC xx.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 5 4 3600 20040509183619 (
- 20040409183619 38519 example.
- OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
- ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
- xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
- a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
- QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
- xx.example. 3600 IN A 192.0.2.10
- 3600 RRSIG A 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
- 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
- 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
- VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
- kbIDV6GPPSZVusnZU6OMgdgzHV4= )
- 3600 HINFO "KLH-10" "TOPS-20"
- 3600 RRSIG HINFO 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
- t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
- BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
- 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
- RgNvuwbioFSEuv2pNlkq0goYxNY= )
- 3600 AAAA 2001:db8::f00:baaa
- 3600 RRSIG AAAA 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
- aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
- ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
- U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
-
-
-
-Arends, et al. Standards Track [Page 40]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- xS9cL2QgW7FChw16mzlkH6/vsfs= )
- 3600 NSEC example. A HINFO AAAA RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
- 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
- mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
- asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
- GghLahumFIpg4MO3LS/prgzVVWo= )
-
- The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
- Flags indicate that each of these DNSKEY RRs is a zone key. One of
- these DNSKEY RRs also has the SEP flag set and has been used to sign
- the apex DNSKEY RRset; this is the key that should be hashed to
- generate a DS record to be inserted into the parent zone. The other
- DNSKEY is used to sign all the other RRsets in the zone.
-
- The zone includes a wildcard entry, "*.w.example". Note that the
- name "*.w.example" is used in constructing NSEC chains, and that the
- RRSIG covering the "*.w.example" MX RRset has a label count of 2.
-
- The zone also includes two delegations. The delegation to
- "b.example" includes an NS RRset, glue address records, and an NSEC
- RR; note that only the NSEC RRset is signed. The delegation to
- "a.example" provides a DS RR; note that only the NSEC and DS RRsets
- are signed.
-
-Appendix B. Example Responses
-
- The examples in this section show response messages using the signed
- zone example in Appendix A.
-
-B.1. Answer
-
- A successful query to an authoritative server.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- x.w.example. IN MX
-
- ;; Answer
- x.w.example. 3600 IN MX 1 xx.example.
- x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
- 20040409183619 38519 example.
- Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
- XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
- H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
-
-
-
-Arends, et al. Standards Track [Page 41]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
- jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
-
- ;; Authority
- example. 3600 NS ns1.example.
- example. 3600 NS ns2.example.
- example. 3600 RRSIG NS 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
- EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
- 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
- RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
- 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-
- ;; Additional
- xx.example. 3600 IN A 192.0.2.10
- xx.example. 3600 RRSIG A 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
- 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
- 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
- VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
- kbIDV6GPPSZVusnZU6OMgdgzHV4= )
- xx.example. 3600 AAAA 2001:db8::f00:baaa
- xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
- aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
- ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
- U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
- xS9cL2QgW7FChw16mzlkH6/vsfs= )
- ns1.example. 3600 IN A 192.0.2.1
- ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
- 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
- im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
- +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
- v/iVXSYC0b7mPSU+EOlknFpVECs= )
- ns2.example. 3600 IN A 192.0.2.2
- ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
- Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
- yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
- 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
- rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
-
-
-
-
-Arends, et al. Standards Track [Page 42]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-B.2. Name Error
-
- An authoritative name error. The NSEC RRs prove that the name does
- not exist and that no covering wildcard exists.
-
- ;; Header: QR AA DO RCODE=3
- ;;
- ;; Question
- ml.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1081539377
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
- 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
- vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
- DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
- jV7j86HyQgM5e7+miRAz8V01b0I= )
- b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
- b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
- 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
- xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
- 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
- vhRXgWT7OuFXldoCG6TfVFMs9xE= )
- example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
- FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
- Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
- SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
- jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
- ;; Additional
- ;; (empty)
-
-
-
-
-Arends, et al. Standards Track [Page 43]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-B.3. No Data Error
-
- A "no data" response. The NSEC RR proves that the name exists and
- that the requested RR type does not.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- ns1.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1081539377
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
- 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
- vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
- DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
- jV7j86HyQgM5e7+miRAz8V01b0I= )
- ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
- ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
- 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
- jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
- ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
- IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
-
- ;; Additional
- ;; (empty)
-
-B.4. Referral to Signed Zone
-
- Referral to a signed zone. The DS RR contains the data which the
- resolver will need to validate the corresponding DNSKEY RR in the
- child zone's apex.
-
- ;; Header: QR DO RCODE=0
- ;;
-
-
-
-Arends, et al. Standards Track [Page 44]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- ;; Question
- mc.a.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- a.example. 3600 IN NS ns1.a.example.
- a.example. 3600 IN NS ns2.a.example.
- a.example. 3600 DS 57855 5 1 (
- B6DCD485719ADCA18E5F3D48A2331627FDD3
- 636B )
- a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
- oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
- kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
- EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
- Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
-
- ;; Additional
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
-
-B.5. Referral to Unsigned Zone
-
- Referral to an unsigned zone. The NSEC RR proves that no DS RR for
- this delegation exists in the parent zone.
-
- ;; Header: QR DO RCODE=0
- ;;
- ;; Question
- mc.b.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- b.example. 3600 IN NS ns1.b.example.
- b.example. 3600 IN NS ns2.b.example.
- b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
- b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
- 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
- xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
- 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
- vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-
-
-
-Arends, et al. Standards Track [Page 45]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- ;; Additional
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
-
-B.6. Wildcard Expansion
-
- A successful query that was answered via wildcard expansion. The
- label count in the answer's RRSIG RR indicates that a wildcard RRset
- was expanded to produce this response, and the NSEC RR proves that no
- closer match exists in the zone.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN MX
-
- ;; Answer
- a.z.w.example. 3600 IN MX 1 ai.example.
- a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
- f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
- tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
- TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
- 4kX18MMR34i8lC36SR5xBni8vHI= )
-
- ;; Authority
- example. 3600 NS ns1.example.
- example. 3600 NS ns2.example.
- example. 3600 RRSIG NS 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
- EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
- 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
- RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
- 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
- x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
- x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
- 20040409183619 38519 example.
- OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
- ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
- xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
- a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
- QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-
- ;; Additional
- ai.example. 3600 IN A 192.0.2.9
- ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
-
-
-
-Arends, et al. Standards Track [Page 46]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- 20040409183619 38519 example.
- pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
- ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
- hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
- ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
- 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
- ai.example. 3600 AAAA 2001:db8::f00:baa9
- ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
- kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
- 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
- cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
- sZM6QjBBLmukH30+w1z3h8PUP2o= )
-
-B.7. Wildcard No Data Error
-
- A "no data" response for a name covered by a wildcard. The NSEC RRs
- prove that the matching wildcard name does not have any RRs of the
- requested type and that no closer match exists in the zone.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN AAAA
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1081539377
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
- 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
- vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
- DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
- jV7j86HyQgM5e7+miRAz8V01b0I= )
- x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
- x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
- 20040409183619 38519 example.
- OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-
-
-
-Arends, et al. Standards Track [Page 47]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
- xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
- a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
- QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
- *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
- *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
- 20040409183619 38519 example.
- r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
- HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
- 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
- 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
- s1InQ2UoIv6tJEaaKkP701j8OLA= )
-
- ;; Additional
- ;; (empty)
-
-B.8. DS Child Zone No Data Error
-
- A "no data" response for a QTYPE=DS query that was mistakenly sent to
- a name server for the child zone.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- example. IN DS
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1081539377
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
- 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
- vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
- DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
- jV7j86HyQgM5e7+miRAz8V01b0I= )
- example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
- 20040409183619 38519 example.
- O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-
-
-
-Arends, et al. Standards Track [Page 48]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
- Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
- SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
- jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
- ;; Additional
- ;; (empty)
-
-Appendix C. Authentication Examples
-
- The examples in this section show how the response messages in
- Appendix B are authenticated.
-
-C.1. Authenticating an Answer
-
- The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
- The corresponding RRSIG indicates that the MX RRset was signed by an
- "example" DNSKEY with algorithm 5 and key tag 38519. The resolver
- needs the corresponding DNSKEY RR in order to authenticate this
- answer. The discussion below describes how a resolver might obtain
- this DNSKEY RR.
-
- The RRSIG indicates the original TTL of the MX RRset was 3600, and,
- for the purpose of authentication, the current TTL is replaced by
- 3600. The RRSIG labels field value of 3 indicates that the answer
- was not the result of wildcard expansion. The "x.w.example.com" MX
- RRset is placed in canonical form, and, assuming the current time
- falls between the signature inception and expiration dates, the
- signature is authenticated.
-
-C.1.1. Authenticating the Example DNSKEY RR
-
- This example shows the logical authentication process that starts
- from the a configured root DNSKEY (or DS RR) and moves down the tree
- to authenticate the desired "example" DNSKEY RR. Note that the
- logical order is presented for clarity. An implementation may choose
- to construct the authentication as referrals are received or to
- construct the authentication chain only after all RRsets have been
- obtained, or in any other combination it sees fit. The example here
- demonstrates only the logical process and does not dictate any
- implementation rules.
-
- We assume the resolver starts with a configured DNSKEY RR for the
- root zone (or a configured DS RR for the root zone). The resolver
- checks whether this configured DNSKEY RR is present in the root
- DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
- DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
- RRset, and whether the signature lifetime is valid. If all these
-
-
-
-Arends, et al. Standards Track [Page 49]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- conditions are met, all keys in the DNSKEY RRset are considered
- authenticated. The resolver then uses one (or more) of the root
- DNSKEY RRs to authenticate the "example" DS RRset. Note that the
- resolver may have to query the root zone to obtain the root DNSKEY
- RRset or "example" DS RRset.
-
- Once the DS RRset has been authenticated using the root DNSKEY, the
- resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
- RR that matches one of the authenticated "example" DS RRs. If such a
- matching "example" DNSKEY is found, the resolver checks whether this
- DNSKEY RR has signed the "example" DNSKEY RRset and the signature
- lifetime is valid. If these conditions are met, all keys in the
- "example" DNSKEY RRset are considered authenticated.
-
- Finally, the resolver checks that some DNSKEY RR in the "example"
- DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This
- DNSKEY is used to authenticate the RRSIG included in the response.
- If multiple "example" DNSKEY RRs match this algorithm and key tag,
- then each DNSKEY RR is tried, and the answer is authenticated if any
- of the matching DNSKEY RRs validate the signature as described above.
-
-C.2. Name Error
-
- The query in Appendix B.2 returned NSEC RRs that prove that the
- requested data does not exist and no wildcard applies. The negative
- reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
- authenticated in a manner identical to that of the MX RRset discussed
- above.
-
-C.3. No Data Error
-
- The query in Appendix B.3 returned an NSEC RR that proves that the
- requested name exists, but the requested RR type does not exist. The
- negative reply is authenticated by verifying the NSEC RR. The NSEC
- RR is authenticated in a manner identical to that of the MX RRset
- discussed above.
-
-C.4. Referral to Signed Zone
-
- The query in Appendix B.4 returned a referral to the signed
- "a.example." zone. The DS RR is authenticated in a manner identical
- to that of the MX RRset discussed above. This DS RR is used to
- authenticate the "a.example" DNSKEY RRset.
-
- Once the "a.example" DS RRset has been authenticated using the
- "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
- for some "a.example" DNSKEY RR that matches the DS RR. If such a
- matching "a.example" DNSKEY is found, the resolver checks whether
-
-
-
-Arends, et al. Standards Track [Page 50]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
- this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
- the signature lifetime is valid. If all these conditions are met,
- all keys in the "a.example" DNSKEY RRset are considered
- authenticated.
-
-C.5. Referral to Unsigned Zone
-
- The query in Appendix B.5 returned a referral to an unsigned
- "b.example." zone. The NSEC proves that no authentication leads from
- "example" to "b.example", and the NSEC RR is authenticated in a
- manner identical to that of the MX RRset discussed above.
-
-C.6. Wildcard Expansion
-
- The query in Appendix B.6 returned an answer that was produced as a
- result of wildcard expansion. The answer section contains a wildcard
- RRset expanded as it would be in a traditional DNS response, and the
- corresponding RRSIG indicates that the expanded wildcard MX RRset was
- signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
- The RRSIG indicates that the original TTL of the MX RRset was 3600,
- and, for the purpose of authentication, the current TTL is replaced
- by 3600. The RRSIG labels field value of 2 indicates that the answer
- is the result of wildcard expansion, as the "a.z.w.example" name
- contains 4 labels. The name "a.z.w.w.example" is replaced by
- "*.w.example", the MX RRset is placed in canonical form, and,
- assuming that the current time falls between the signature inception
- and expiration dates, the signature is authenticated.
-
- The NSEC proves that no closer match (exact or closer wildcard) could
- have been used to answer this query, and the NSEC RR must also be
- authenticated before the answer is considered valid.
-
-C.7. Wildcard No Data Error
-
- The query in Appendix B.7 returned NSEC RRs that prove that the
- requested data does not exist and no wildcard applies. The negative
- reply is authenticated by verifying both NSEC RRs.
-
-C.8. DS Child Zone No Data Error
-
- The query in Appendix B.8 returned NSEC RRs that shows the requested
- was answered by a child server ("example" server). The NSEC RR
- indicates the presence of an SOA RR, showing that the answer is from
- the child . Queries for the "example" DS RRset should be sent to the
- parent servers ("root" servers).
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 51]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Brouwerijstraat 1
- 7523 XC Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Rob Austein
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- EMail: sra@isc.org
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Dan Massey
- Colorado State University
- Department of Computer Science
- Fort Collins, CO 80523-1873
-
- EMail: massey@cs.colostate.edu
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 52]
-
-RFC 4035 DNSSEC Protocol Modifications March 2005
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Arends, et al. Standards Track [Page 53]
-
diff --git a/contrib/bind9/doc/rfc/rfc4074.txt b/contrib/bind9/doc/rfc/rfc4074.txt
deleted file mode 100644
index d9252b39eb595..0000000000000
--- a/contrib/bind9/doc/rfc/rfc4074.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group Y. Morishita
-Request for Comments: 4074 JPRS
-Category: Informational T. Jinmei
- Toshiba
- May 2005
-
-
- Common Misbehavior Against DNS Queries for IPv6 Addresses
-
-Status of This Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- There is some known misbehavior of DNS authoritative servers when
- they are queried for AAAA resource records. Such behavior can block
- IPv4 communication that should actually be available, cause a
- significant delay in name resolution, or even make a denial of
- service attack. This memo describes details of known cases and
- discusses their effects.
-
-1. Introduction
-
- Many existing DNS clients (resolvers) that support IPv6 first search
- for AAAA Resource Records (RRs) of a target host name, and then for A
- RRs of the same name. This fallback mechanism is based on the DNS
- specifications, which if not obeyed by authoritative servers, can
- produce unpleasant results. In some cases, for example, a web
- browser fails to connect to a web server it could otherwise reach.
- In the following sections, this memo describes some typical cases of
- such misbehavior and its (bad) effects.
-
- Note that the misbehavior is not specific to AAAA RRs. In fact, all
- known examples also apply to the cases of queries for MX, NS, and SOA
- RRs. The authors believe this can be generalized for all types of
- queries other than those for A RRs. In this memo, however, we
- concentrate on the case for AAAA queries, since the problem is
- particularly severe for resolvers that support IPv6, which thus
- affects many end users. Resolvers at end users normally send A
- and/or AAAA queries only, so the problem for the other cases is
- relatively minor.
-
-
-
-Morishita & Jinmei Informational [Page 1]
-
-RFC 4074 Common Misbehavior Against DNS Queries May 2005
-
-
-2. Network Model
-
- In this memo, we assume a typical network model of name resolution
- environment using DNS. It consists of three components: stub
- resolvers, caching servers, and authoritative servers. A stub
- resolver issues a recursive query to a caching server, which then
- handles the entire name resolution procedure recursively. The
- caching server caches the result of the query and sends the result to
- the stub resolver. The authoritative servers respond to queries for
- names for which they have the authority, normally in a non-recursive
- manner.
-
-3. Expected Behavior
-
- Suppose that an authoritative server has an A RR but has no AAAA RR
- for a host name. Then, the server should return a response to a
- query for an AAAA RR of the name with the response code (RCODE) being
- 0 (indicating no error) and with an empty answer section (see
- Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that
- there is at least one RR of a different type than AAAA for the
- queried name, and the stub resolver can then look for A RRs.
-
- This way, the caching server can cache the fact that the queried name
- has no AAAA RR (but may have other types of RRs), and thus improve
- the response time to further queries for an AAAA RR of the name.
-
-4. Problematic Behaviors
-
- There are some known cases at authoritative servers that do not
- conform to the expected behavior. This section describes those
- problematic cases.
-
-4.1. Ignore Queries for AAAA
-
- Some authoritative servers seem to ignore queries for an AAAA RR,
- causing a delay at the stub resolver to fall back to a query for an A
- RR. This behavior may cause a fatal timeout at the resolver or at
- the application that calls the resolver. Even if the resolver
- eventually falls back, the result can be an unacceptable delay for
- the application user, especially with interactive applications like
- web browsing.
-
-4.2. Return "Name Error"
-
- This type of server returns a response with RCODE 3 ("Name Error") to
- a query for an AAAA RR, indicating that it does not have any RRs of
- any type for the queried name.
-
-
-
-
-Morishita & Jinmei Informational [Page 2]
-
-RFC 4074 Common Misbehavior Against DNS Queries May 2005
-
-
- With this response, the stub resolver may immediately give up and
- never fall back. Even if the resolver retries with a query for an A
- RR, the negative response for the name has been cached in the caching
- server, and the caching server will simply return the negative
- response. As a result, the stub resolver considers this to be a
- fatal error in name resolution.
-
- Several examples of this behavior are known to the authors. As of
- this writing, all have been fixed.
-
-4.3. Return Other Erroneous Codes
-
- Other authoritative servers return a response with erroneous response
- codes other than RCODE 3 ("Name Error"). One such RCODE is 4 ("Not
- Implemented"), indicating that the servers do not support the
- requested type of query.
-
- These cases are less harmful than the previous one; if the stub
- resolver falls back to querying for an A RR, the caching server will
- process the query correctly and return an appropriate response.
-
- However, these can still cause a serious effect. There was an
- authoritative server implementation that returned RCODE 2 ("Server
- failure") to queries for AAAA RRs. One widely deployed mail server
- implementation with a certain type of resolver library interpreted
- this result as an indication of retry and did not fall back to
- queries for A RRs, causing message delivery failure.
-
- If the caching server receives a response with these response codes,
- it does not cache the fact that the queried name has no AAAA RR,
- resulting in redundant queries for AAAA RRs in the future. The
- behavior will waste network bandwidth and increase the load of the
- authoritative server.
-
- Using RCODE 1 ("Format error") would cause a similar effect, though
- the authors have not seen such implementations yet.
-
-4.4. Return a Broken Response
-
- Another type of authoritative servers returns broken responses to
- AAAA queries. Returning a response whose RR type is AAAA with the
- length of the RDATA being 4 bytes is a known behavior of this
- category. The 4-byte data looks like the IPv4 address of the queried
- host name.
-
-
-
-
-
-
-
-Morishita & Jinmei Informational [Page 3]
-
-RFC 4074 Common Misbehavior Against DNS Queries May 2005
-
-
- That is, the RR in the answer section would be described as follows:
-
- www.bad.example. 600 IN AAAA 192.0.2.1
-
- which is, of course, bogus (or at least meaningless).
-
- A widely deployed caching server implementation transparently returns
- the broken response (and caches it) to the stub resolver. Another
- known server implementation parses the response by itself, and sends
- a separate response with RCODE 2 ("Server failure").
-
- In either case, the broken response does not affect queries for an A
- RR of the same name. If the stub resolver falls back to A queries,
- it will get an appropriate response.
-
- The latter case, however, causes the same bad effect as that
- described in the previous section: redundant queries for AAAA RRs.
-
-4.5. Make Lame Delegation
-
- Some authoritative servers respond to AAAA queries in a way that
- causes lame delegation. In this case, the parent zone specifies that
- the authoritative server should have the authority of a zone, but the
- server should not return an authoritative response for AAAA queries
- within the zone (i.e., the AA bit in the response is not set). On
- the other hand, the authoritative server returns an authoritative
- response for A queries.
-
- When a caching server asks the server for AAAA RRs in the zone, it
- recognizes the delegation is lame, and returns a response with RCODE
- 2 ("Server failure") to the stub resolver.
-
- Furthermore, some caching servers record the authoritative server as
- lame for the zone and will not use it for a certain period of time.
- With this type of caching server, even if the stub resolver falls
- back to querying for an A RR, the caching server will simply return a
- response with RCODE 2, since all the servers are known to be "lame."
-
- There is also an implementation that relaxes the behavior a little
- bit. It tries to avoid using the lame server, but continues to try
- it as a last resort. With this type of caching server, the stub
- resolver will get a correct response if it falls back after Server
- failure. However, this still causes redundant AAAA queries, as
- explained in the previous sections.
-
-
-
-
-
-
-
-Morishita & Jinmei Informational [Page 4]
-
-RFC 4074 Common Misbehavior Against DNS Queries May 2005
-
-
-5. Security Considerations
-
- The CERT/CC pointed out that the response with RCODE 3 ("Name
- Error"), described in Section 4.2, can be used for a denial of
- service attack [2]. The same argument applies to the case of "lame
- delegation", described in Section 4.5, with a certain type of caching
- server.
-
-6. Acknowledgements
-
- Erik Nordmark encouraged the authors to publish this document as an
- RFC. Akira Kato and Paul Vixie reviewed a preliminary version of
- this document. Pekka Savola carefully reviewed a previous version
- and provided detailed comments. Bill Fenner, Scott Hollenbeck,
- Thomas Narten, and Alex Zinin reviewed and helped improve the
- document at the last stage for publication.
-
-7. Informative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from
- AAAA queries could cause denial-of-service conditions",
- March 2003, <http://www.kb.cert.org/vuls/id/714121>.
-
-Authors' Addresses
-
- MORISHITA Orange Yasuhiro
- Research and Development Department, Japan Registry Services Co.,Ltd.
- Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
- Chiyoda-ku, Tokyo 101-0065
- Japan
-
- EMail: yasuhiro@jprs.co.jp
-
-
- JINMEI Tatuya
- Corporate Research & Development Center, Toshiba Corporation
- 1 Komukai Toshiba-cho, Saiwai-ku
- Kawasaki-shi, Kanagawa 212-8582
- Japan
-
- EMail: jinmei@isl.rdc.toshiba.co.jp
-
-
-
-
-
-
-
-Morishita & Jinmei Informational [Page 5]
-
-RFC 4074 Common Misbehavior Against DNS Queries May 2005
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Morishita & Jinmei Informational [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc4159.txt b/contrib/bind9/doc/rfc/rfc4159.txt
deleted file mode 100644
index 1ab4bd1ae3404..0000000000000
--- a/contrib/bind9/doc/rfc/rfc4159.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-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/doc/rfc/rfc952.txt b/contrib/bind9/doc/rfc/rfc952.txt
deleted file mode 100644
index 7df339a272e27..0000000000000
--- a/contrib/bind9/doc/rfc/rfc952.txt
+++ /dev/null
@@ -1,340 +0,0 @@
-Network Working Group K. Harrenstien (SRI)
-Request for Comments: 952 M. Stahl (SRI)
- E. Feinler (SRI)
-Obsoletes: RFC 810, 608 October 1985
-
- DOD INTERNET HOST TABLE SPECIFICATION
-
-
-STATUS OF THIS MEMO
-
- This RFC is the official specification of the format of the Internet
- Host Table. This edition of the specification includes minor
- revisions to RFC-810 which brings it up to date. Distribution of this
- memo is unlimited.
-
-INTRODUCTION
-
- The DoD Host Table is utilized by the DoD Hostname Server maintained
- by the DDN Network Information Center (NIC) on behalf of the Defense
- Communications Agency (DCA) [See RFC-953].
-
-LOCATION OF THE STANDARD DOD ONLINE HOST TABLE
-
- A machine-translatable ASCII text version of the DoD Host Table is
- online in the file NETINFO:HOSTS.TXT on the SRI-NIC host. It can be
- obtained via FTP from your local host by connecting to host
- SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user =
- ANONYMOUS, password = GUEST, and retrieving the file
- "NETINFO:HOSTS.TXT". The same table may also be obtained via the NIC
- Hostname Server, as described in RFC-953. The latter method is
- faster and easier, but requires a user program to make the necessary
- connection to the Name Server.
-
-ASSUMPTIONS
-
- 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
- to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
- sign (-), and period (.). Note that periods are only allowed when
- they serve to delimit components of "domain style names". (See
- RFC-921, "Domain Name System Implementation Schedule", for
- background). No blank or space characters are permitted as part of a
- name. No distinction is made between upper and lower case. The first
- character must be an alpha character. The last character must not be
- a minus sign or period. A host which serves as a GATEWAY should have
- "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as
- Internet gateways should not use "-GATEWAY" and "-GW" as part of
- their names. A host which is a TAC should have "-TAC" as the last
- part of its host name, if it is a DoD host. Single character names
- or nicknames are not allowed.
-
- 2. Internet Addresses are 32-bit addresses [See RFC-796]. In the
-
-
-Harrenstien & Stahl & Feinler [Page 1]
-
-
-
-RFC 952 October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
- host table described herein each address is represented by four
- decimal numbers separated by a period. Each decimal number
- represents 1 octet.
-
- 3. If the first bit of the first octet of the address is 0 (zero),
- then the next 7 bits of the first octet indicate the network number
- (Class A Address). If the first two bits are 1,0 (one,zero), then
- the next 14 bits define the net number (Class B Address). If the
- first 3 bits are 1,1,0 (one,one,zero), then the next 21 bits define
- the net number (Class C Address) [See RFC-943].
-
- This is depicted in the following diagram:
-
- +-+------------+--------------+--------------+--------------+
- |0| NET <-7-> | LOCAL ADDRESS <-24-> |
- +-+------------+--------------+--------------+--------------+
-
- +---+----------+--------------+--------------+--------------+
- |1 0| NET <-14-> | LOCAL ADDRESS <-16-> |
- +---+----------+--------------+--------------+--------------+
-
- +-----+--------+--------------+--------------+--------------+
- |1 1 0| NET <-21-> | LOCAL ADDRESS|
- +-----+--------+--------------+--------------+--------------+
-
- 4. The LOCAL ADDRESS portion of the internet address identifies a
- host within the network specified by the NET portion of the address.
-
- 5. The ARPANET and MILNET are both Class A networks. The NET portion
- is 10 decimal for ARPANET, 26 decimal for MILNET, and the LOCAL
- ADDRESS maps as follows: the second octet identifies the physical
- host, the third octet identifies the logical host, and the fourth
- identifies the Packet Switching Node (PSN), formerly known as an
- Interface Message Processor (IMP).
-
- +-+------------+--------------+--------------+--------------+
- |0| 10 or 26 | HOST | LOGICAL HOST | PSN (IMP) |
- +-+------------+--------------+--------------+--------------+
-
- (NOTE: RFC-796 also describes the local address mappings for
- several other networks.)
-
- 6. It is the responsibility of the users of this host table to
- translate it into whatever format is needed for their purposes.
-
- 7. Names and addresses for DoD hosts and gateways will be negotiated
- and registered with the DDN PMO, and subsequently with the NIC,
-
-
-Harrenstien & Stahl & Feinler [Page 2]
-
-
-
-RFC 952 October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
- before being used and before traffic is passed by a DoD host. Names
- and addresses for domains and networks are to be registered with the
- DDN Network Information Center (HOSTMASTER@SRI-NIC.ARPA) or
- 800-235-3155.
-
- The NIC will attempt to keep similar information for non-DoD networks
- and hosts, if this information is provided, and as long as it is
- needed, i.e., until intercommunicating network name servers are in
- place.
-
-EXAMPLE OF HOST TABLE FORMAT
-
- NET : 10.0.0.0 : ARPANET :
- NET : 128.10.0.0 : PURDUE-CS-NET :
- GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW.ARPA,MIT-GATEWAY : PDP-11 :
- MOS : IP/GW,EGP :
- HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 :
- TOPS20 :TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
- HOST : 10.2.0.11 : SU-TAC.ARPA,SU-TAC : C/30 : TAC : TCP :
-
-SYNTAX AND CONVENTIONS
-
- ; (semicolon) is used to denote the beginning of a comment.
- Any text on a given line following a ';' is a
- comment, and not part of the host table.
-
- NET keyword introducing a network entry
-
- GATEWAY keyword introducing a gateway entry
-
- HOST keyword introducing a host entry
-
- DOMAIN keyword introducing a domain entry
-
- :(colon) is used as a field delimiter
-
- ::(2 colons) indicates a null field
-
- ,(comma) is used as a data element delimiter
-
- XXX/YYY indicates protocol information of the type
- TRANSPORT/SERVICE.
-
- where TRANSPORT/SERVICE options are specified as
-
- "FOO/BAR" both transport and service known
-
-
-
-Harrenstien & Stahl & Feinler [Page 3]
-
-
-
-RFC 952 October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
- "FOO" transport known; services not known
-
- "BAR" service is known, transport not known
-
- NOTE: See "Assigned Numbers" for specific options and acronyms
- for machine types, operating systems, and protocol/services.
-
- Each host table entry is an ASCII text string comprised of 6 fields,
- where
-
- Field 1 KEYWORD indicating whether this entry pertains to
- a NET, GATEWAY, HOST, or DOMAIN. NET entries are
- assigned and cannot have alternate addresses or
- nicknames. DOMAIN entries do not use fields 4, 5,
- or 6.
-
- Field 2 Internet Address of Network, Gateway, or Host
- followed by alternate addresses. Addresses for a
- Domain are those where a Domain Name Server exists
- for that domain.
-
- Field 3 Official Name of Network, Gateway, Host, or Domain
- (with optional nicknames, where permitted).
-
- Field 4 Machine Type
-
- Field 5 Operating System
-
- Field 6 Protocol List
-
- Fields 4, 5 and 6 are optional. For a Domain they are not used.
-
- Fields 3-6, if included, pertain to the first address in Field 2.
-
- 'Blanks' (spaces and tabs) are ignored between data elements or
- fields, but are disallowed within a data element.
-
- Each entry ends with a colon.
-
- The entries in the table are grouped by types in the order Domain,
- Net, Gateway, and Host. Within each type the ordering is
- unspecified.
-
- Note that although optional nicknames are allowed for hosts, they are
- discouraged, except in the case where host names have been changed
-
-
-
-
-Harrenstien & Stahl & Feinler [Page 4]
-
-
-
-RFC 952 October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
- and both the new and the old names are maintained for a suitable
- period of time to effect a smooth transition. Nicknames are not
- permitted for NET names.
-
-GRAMMATICAL HOST TABLE SPECIFICATION
-
- A. Parsing grammar
-
- <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
- [":" [<opsys>] [":" [<protocol list>] ]]] ":"
- <addresses> ::= <address> *["," <address>]
- <address> ::= <octet> "." <octet> "." <octet> "." <octet>
- <octet> ::= <0 to 255 decimal>
- <names> ::= <netname> | <gatename> | <domainname> *[","
- <nicknames>]
- | <official hostname> *["," <nicknames>]
- <netname> ::= <name>
- <gatename> ::= <hname>
- <domainname> ::= <hname>
- <official hostname> ::= <hname>
- <nickname> ::= <hname>
- <protocol list> ::= <protocol spec> *["," <protocol spec>]
- <protocol spec> ::= <transport name> "/" <service name>
- | <raw protocol name>
-
- B. Lexical grammar
-
- <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
- <entry-text> ::= <print-char> *<text>
- <blank> ::= <space-or-tab> [<blank>]
- <keyword> ::= NET | GATEWAY | HOST | DOMAIN
- <hname> ::= <name>*["."<name>]
- <name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
- <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
- <opsys> ::= ITS | MULTICS | TOPS20 | UNIX...etc.
- <transport name> ::= TCP | NCP | UDP | IP...etc.
- <service name> ::= TELNET | FTP | SMTP | MTP...etc.
- <raw protocol name> ::= <name>
- <comment> ::= ";" <text><cr><lf>
- <text> ::= *[<print-char> | <blank>]
- <print-char> ::= <any printing char (not space or tab)>
-
- Notes:
-
- 1. Zero or more 'blanks' between separators " , : " are allowed.
- 'Blanks' are spaces and tabs.
-
-
-
-Harrenstien & Stahl & Feinler [Page 5]
-
-
-
-RFC 952 October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
- 2. Continuation lines are lines that begin with at least one
- blank. They may be used anywhere 'blanks' are legal to split an
- entry across lines.
-
-BIBLIOGRAPHY
-
- 1. Feinler, E., Harrenstien, K., Su, Z. and White, V., "Official DoD
- Internet Host Table Specification", RFC-810, Network Information
- Center, SRI International, March 1982.
-
- 2. Harrenstien, K., Stahl, M., and Feinler, E., "Hostname Server",
- RFC-953, Network Information Center, SRI International, October
- 1985.
-
- 3. Kudlick, M. "Host Names Online", RFC-608, Network Information
- Center, SRI International, January 1973.
-
- 4. Postel, J., "Internet Protocol", RFC-791, Information Sciences
- Institute, University of Southern California, Marina del Rey,
- September 1981.
-
- 5. Postel, J., "Address Mappings", RFC-796, Information Sciences
- Institute, University of Southern California, Marina del Rey,
- September 1981.
-
- 6. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
- Information Sciences Institute, University of Southern California,
- Marina del Rey, October 1984.
-
- 7. Reynolds, J. and Postel, J., "Assigned Numbers", RFC-943,
- Information Sciences Institute, University of Southern California,
- Marina del Rey, April 1985.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrenstien & Stahl & Feinler [Page 6]
-