summaryrefslogtreecommitdiff
path: root/dist/bind/doc
diff options
context:
space:
mode:
Diffstat (limited to 'dist/bind/doc')
-rw-r--r--dist/bind/doc/arm/Bv9ARM-book.xml189
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch01.html234
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch02.html40
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch03.html580
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch04.html444
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch05.html24
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch06.html4522
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch07.html76
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch08.html58
-rw-r--r--dist/bind/doc/arm/Bv9ARM.ch09.html536
-rw-r--r--dist/bind/doc/arm/Bv9ARM.html144
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt561
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt1457
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt3193
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt1849
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt639
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt335
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt1559
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt466
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt1344
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt1321
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt1969
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt391
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt485
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt617
-rw-r--r--dist/bind/doc/draft/update10
-rw-r--r--dist/bind/doc/misc/ipv637
-rw-r--r--dist/bind/doc/misc/options4
-rw-r--r--dist/bind/doc/rfc/index7
-rw-r--r--dist/bind/doc/rfc/rfc3833.txt899
-rw-r--r--dist/bind/doc/rfc/rfc3845.txt395
31 files changed, 19878 insertions, 4507 deletions
diff --git a/dist/bind/doc/arm/Bv9ARM-book.xml b/dist/bind/doc/arm/Bv9ARM-book.xml
index ace940f4a15..2dbd4e0693f 100644
--- a/dist/bind/doc/arm/Bv9ARM-book.xml
+++ b/dist/bind/doc/arm/Bv9ARM-book.xml
@@ -2,7 +2,7 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd">
-<!-- File: Id: Bv9ARM-book.xml,v 1.155.2.27.2.40 2004/04/15 23:56:27 marka Exp -->
+<!-- File: Id: Bv9ARM-book.xml,v 1.155.2.27.2.49 2004/08/16 00:55:29 marka Exp -->
<book>
<title>BIND 9 Administrator Reference Manual</title>
@@ -989,7 +989,7 @@ protocol is specified in RFC 1996.
<command>zone</command> statement.</para>
<para>Updating of secure zones (zones using DNSSEC) follows
- RFC 3007: SIG and NXT records affected by updates are automatically
+ 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>
@@ -1433,8 +1433,8 @@ allow-update { key host1-host2. ;};
<title>DNSSEC</title>
<para>Cryptographic authentication of DNS information is possible
- through the DNS Security (<emphasis>DNSSEC</emphasis>) extensions,
- defined in RFC 2535. This section describes the creation and use
+ 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
@@ -1443,15 +1443,17 @@ allow-update { key host1-host2. ;};
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 and signedkey files to be in the working directory or 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.0.x are not fully compatible
+ 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 and signatures. A
- zone's security status must be indicated by the parent zone for a
- DNSSEC capable resolver to trust its data.</para>
+ 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
@@ -1470,16 +1472,16 @@ allow-update { key host1-host2. ;};
<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
- these are RSASHA1 and DSA.</para>
+ the only one is RSASHA1.</para>
- <para>The following command will generate a 768 bit DSA key for
+ <para>The following command will generate a 768 bit RSASHA1 key for
the <filename>child.example</filename> zone:</para>
- <para><userinput>dnssec-keygen -a DSA -b 768 -n ZONE child.example.</userinput></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.+003+12345.key</filename> and
- <filename>Kchild.example.+003+12345.private</filename> (where
+ <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).
@@ -1498,78 +1500,18 @@ allow-update { key host1-host2. ;};
</sect2>
<sect2>
- <title>Creating a Keyset</title>
-
- <para>The <command>dnssec-makekeyset</command> program is used
- to create a key set from one or more keys.</para>
-
- <para>Once the zone keys have been generated, a key set must be
- built for transmission to the administrator of the parent zone,
- so that the parent zone can sign the keys with its own zone key
- and correctly indicate the security status of this zone. When
- building a key set, the list of keys to be included and the TTL
- of the set must be specified, and the desired signature validity
- period of the parent's signature may also be specified.</para>
-
- <para>The list of keys to be inserted into the key set may also
- included non-zone keys present at the top of the zone.
- <command>dnssec-makekeyset</command> may also be used at other
- names in the zone.</para>
-
- <para>The following command generates a key set containing the
- above key and another key similarly generated, with a TTL of
- 3600 and a signature validity period of 10 days starting from
- now.</para>
-
-<para><userinput>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para>
-
- <para>One output file is produced:
- <filename>keyset-child.example.</filename>. This file should be
- transmitted to the parent to be signed. It includes the keys,
- as well as signatures over the key set generated by the zone
- keys themselves, which are used to prove ownership of the
- private keys and encode the desired validity period.</para>
-
- </sect2>
- <sect2>
- <title>Signing the Child's Keyset</title>
-
- <para>The <command>dnssec-signkey</command> program is used to
- sign one child's keyset.</para>
-
- <para>If the <filename>child.example</filename> zone has any
- delegations which are secure, for example,
- <filename>grand.child.example</filename>, the
- <filename>child.example</filename> administrator should receive
- keyset files for each secure subzone. These keys must be signed
- by this zone's zone keys.</para>
-
- <para>The following command signs the child's key set with the
- zone keys:</para>
-
-<para><userinput>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para>
-
- <para>One output file is produced:
- <filename>signedkey-grand.child.example.</filename>. This file
- should be both transmitted back to the child and retained. It
- includes all keys (the child's keys) from the keyset file and
- signatures generated by this zone's zone keys.</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>signedkey</filename> files corresponding to
- secure subzones should be present, as well as a
- <filename>signedkey</filename> file for this zone generated by
- the parent (if there is one). The zone signer will generate
- <literal>NXT</literal> and <literal>SIG</literal> records for
- the zone, as well as incorporate the zone key signature from the
- parent and indicate the security status at all delegation
- points.</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
@@ -1583,6 +1525,12 @@ allow-update { key host1-host2. ;};
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>
@@ -1641,7 +1589,7 @@ statement, as described later in this document. </para>
<programlisting>
$ORIGIN example.com.
-host 3600 IN AAAA 2001:4f8:201:1860:42::1
+host 3600 IN AAAA 2001:db8::1
</programlisting>
<para>It is recommended that IPv4-in-IPv6 mapped addresses not
@@ -1657,11 +1605,11 @@ host 3600 IN AAAA 2001:4f8:201:1860:42::1
<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:4f8:201:1860:42::1</literal>.</para>
+ <literal>2001:db8::1</literal>.</para>
<programlisting>
-$ORIGIN 0.6.8.1.1.0.2.0.8.f.4.0.1.0.0.2.ip6.arpa.
-1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.example.com.
+$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>
@@ -1764,7 +1712,7 @@ 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:ffff::200:f8ff:fe01:9742</command>.
+<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.
@@ -2632,7 +2580,16 @@ the <command>null</command> channel.</para></entry>
At startup, specifing the category <command>queries</command> will also
enable query logging unless <command>querylog</command> option has been
specified.
-</para></entry>
+</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>
+<programlisting><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
+<computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
+</programlisting>
+</entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><command>dispatch</command></para></entry>
@@ -2758,7 +2715,7 @@ statement in the <filename>named.conf</filename> file:</para>
<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>; </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 { <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>
@@ -2985,10 +2942,12 @@ Only the most specific will be applied.
<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 set the domain specified by
-<command>dnssec-lookaside</command> is appended to DNSKEY's
-name and a DLV record is looked up. If the DLV record validates
-a DNSKEY (similarly to the way a DS record does) the DNSKEY RRset is deemed to be trusted.
+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>
@@ -3416,8 +3375,8 @@ 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>6 to 4 Servers</title>
-<para>6 to 4 servers are used as servers of last resort to work around
+<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>
@@ -3534,28 +3493,40 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; };
<para>If no <command>listen-on</command> is specified, the
server will listen on port 53 on all interfaces.</para>
-<para>By default, the server does not bind a separate socket to each
-IPv6 interface address as it does for IPv4. Instead, it listens on the
-IPv6 wildcard address.
-Alternatively, a list of IPv6 addresses can be specified, in which case
-the server listens on a separate socket for each specified address.</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 { !3ffe::/16; 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
-3ffe::/16 (with separate sockets for each matched address.)</para>
+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> statement is specified,
+<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>
@@ -3563,7 +3534,7 @@ the server will not listen on any IPv6 address.</para></sect3>
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,
+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>
@@ -3577,6 +3548,9 @@ query-source-v6 address * port *;
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>
@@ -4752,10 +4726,9 @@ The default is the empty list.</para>
<varlistentry><term><command>check-names</command></term>
<listitem><para>
-This option was used in BIND 8 to restrict the character set of
-domain names in master files and/or DNS responses received from the
-network. BIND 9 does not restrict the character set of domain names
-and does not implement the <command>check-names</command> option.
+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.
</para>
</listitem></varlistentry>
@@ -6006,7 +5979,7 @@ 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:4f8:201:9:a00:20ff:fe81:2b32</command></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
diff --git a/dist/bind/doc/arm/Bv9ARM.ch01.html b/dist/bind/doc/arm/Bv9ARM.ch01.html
index c79a1fcf36d..5b3659e6101 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch01.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch01.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Introduction </TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -70,8 +70,8 @@ CLASS="chapter"
><H1
><A
NAME="ch01"
->Chapter 1. Introduction </A
-></H1
+></A
+>Chapter 1. Introduction </H1
><DIV
CLASS="TOC"
><DL
@@ -97,24 +97,24 @@ HREF="Bv9ARM.ch01.html#AEN42"
><DT
>1.4. <A
HREF="Bv9ARM.ch01.html#AEN107"
->The Domain Name System (<SPAN
+>The Domain Name System (<ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
>)</A
></DT
></DL
></DIV
><P
->The Internet Domain Name System (<SPAN
+>The Internet Domain Name System (<ACRONYM
CLASS="acronym"
->DNS</SPAN
+>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. <SPAN
+ addresses. <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> data is maintained in a group of distributed
hierarchical databases.</P
><DIV
@@ -126,19 +126,19 @@ NAME="AEN15"
>1.1. Scope of Document</A
></H1
><P
->The Berkeley Internet Name Domain (<SPAN
+>The Berkeley Internet Name Domain (<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 (<SPAN
+ care of the Internet Software Consortium (<ACRONYM
CLASS="acronym"
->ISC</SPAN
+>ISC</ACRONYM
>)
- <SPAN
+ <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> version 9 software package for system
administrators.</P
><P
@@ -160,12 +160,12 @@ CLASS="emphasis"
>Section 1</I
></SPAN
> introduces
- the basic <SPAN
+ the basic <ACRONYM
CLASS="acronym"
->DNS</SPAN
-> and <SPAN
+>DNS</ACRONYM
+> and <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> concepts. <SPAN
CLASS="emphasis"
><I
@@ -173,9 +173,9 @@ CLASS="emphasis"
>Section 2</I
></SPAN
>
- describes resource requirements for running <SPAN
+ describes resource requirements for running <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> in various
environments. Information in <SPAN
CLASS="emphasis"
@@ -192,9 +192,9 @@ CLASS="emphasis"
></SPAN
> in its presentation and is
organized functionally, to aid in the process of installing the
- <SPAN
+ <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 software. The task-oriented section is followed by
<SPAN
CLASS="emphasis"
@@ -211,9 +211,9 @@ CLASS="emphasis"
>Section 5</I
></SPAN
>
- describes the <SPAN
+ describes the <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 lightweight
resolver. The contents of <SPAN
CLASS="emphasis"
@@ -253,9 +253,9 @@ CLASS="emphasis"
>Bibliography</I
></SPAN
> and
- historic information related to <SPAN
+ historic information related to <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> and the Domain Name
System.</P
></DIV
@@ -272,11 +272,11 @@ NAME="AEN42"
conventions:</P
><DIV
CLASS="informaltable"
+><P
+></P
><A
NAME="AEN45"
></A
-><P
-></P
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -284,9 +284,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="288"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
>&#13;<P
><SPAN
CLASS="emphasis"
@@ -298,9 +295,6 @@ describe:</I
></P
></TD
><TD
-WIDTH="252"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
>&#13;<P
><SPAN
CLASS="emphasis"
@@ -313,17 +307,11 @@ CLASS="emphasis"
></TR
><TR
><TD
-WIDTH="288"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
>&#13;<P
>a pathname, filename, URL, hostname,
mailing list name, or new term or concept</P
></TD
><TD
-WIDTH="252"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><TT
CLASS="filename"
@@ -333,42 +321,28 @@ CLASS="filename"
></TR
><TR
><TD
-WIDTH="288"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>literal user
input</P
></TD
><TD
-WIDTH="252"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><KBD
CLASS="userinput"
-><B
->Fixed Width Bold</B
-></TT
+>Fixed Width Bold</KBD
></P
></TD
></TR
><TR
><TD
-WIDTH="288"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>program output</P
></TD
><TD
-WIDTH="252"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><SAMP
CLASS="computeroutput"
->Fixed Width</TT
+>Fixed Width</SAMP
></P
></TD
></TR
@@ -379,16 +353,16 @@ CLASS="computeroutput"
></DIV
><P
>The following conventions are used in descriptions of the
-<SPAN
+<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> configuration file:<DIV
CLASS="informaltable"
+><P
+></P
><A
NAME="AEN77"
></A
-><P
-></P
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -396,9 +370,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="288"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><SPAN
CLASS="emphasis"
@@ -410,9 +381,6 @@ describe:</I
></P
></TD
><TD
-WIDTH="252"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><SPAN
CLASS="emphasis"
@@ -425,54 +393,36 @@ CLASS="emphasis"
></TR
><TR
><TD
-WIDTH="288"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>keywords</P
></TD
><TD
-WIDTH="252"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->Fixed Width</TT
+>Fixed Width</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="288"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>variables</P
></TD
><TD
-WIDTH="252"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->Fixed Width</TT
+>Fixed Width</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="288"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Optional input</P
></TD
><TD
-WIDTH="252"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>[<SPAN
CLASS="optional"
@@ -493,24 +443,24 @@ CLASS="sect1"
CLASS="sect1"
><A
NAME="AEN107"
->1.4. The Domain Name System (<SPAN
+>1.4. The Domain Name System (<ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
>)</A
></H1
><P
>The purpose of this document is to explain the installation
-and upkeep of the <SPAN
+and upkeep of the <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> software package, and we
begin by reviewing the fundamentals of the Domain Name System
-(<SPAN
+(<ACRONYM
CLASS="acronym"
->DNS</SPAN
->) as they relate to <SPAN
+>DNS</ACRONYM
+>) as they relate to <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>.
</P
><DIV
@@ -542,9 +492,9 @@ CLASS="emphasis"
>name servers</I
></SPAN
> and interprets the responses.
-The <SPAN
+The <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 software distribution contains a
name server, <B
CLASS="command"
@@ -604,30 +554,30 @@ CLASS="emphasis"
>Example, Inc.</I
></SPAN
> could be
-<TT
+<VAR
CLASS="literal"
->mail.example.com</TT
+>mail.example.com</VAR
>,
-where <TT
+where <VAR
CLASS="literal"
->com</TT
+>com</VAR
> is the
top level domain to which
-<TT
+<VAR
CLASS="literal"
->ourhost.example.com</TT
+>ourhost.example.com</VAR
> belongs,
-<TT
+<VAR
CLASS="literal"
->example</TT
+>example</VAR
> is
-a subdomain of <TT
+a subdomain of <VAR
CLASS="literal"
->com</TT
+>com</VAR
>, and
-<TT
+<VAR
CLASS="literal"
->ourhost</TT
+>ourhost</VAR
> is the
name of the host.</P
><P
@@ -664,9 +614,9 @@ CLASS="emphasis"
CLASS="emphasis"
>resource records</I
></SPAN
-> (<SPAN
+> (<ACRONYM
CLASS="acronym"
->RR</SPAN
+>RR</ACRONYM
>s).
Some of the supported resource record types are described in
<A
@@ -707,9 +657,9 @@ CLASS="emphasis"
>.</P
><P
>As we stated previously, a zone is a point of delegation in
-the <SPAN
+the <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>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
@@ -726,36 +676,36 @@ CLASS="emphasis"
parent zone, which should be matched by equivalent NS records at
the root of the delegated zone.</P
><P
->For instance, consider the <TT
+>For instance, consider the <VAR
CLASS="literal"
->example.com</TT
+>example.com</VAR
>
domain which includes names
-such as <TT
+such as <VAR
CLASS="literal"
->host.aaa.example.com</TT
+>host.aaa.example.com</VAR
> and
-<TT
+<VAR
CLASS="literal"
->host.bbb.example.com</TT
+>host.bbb.example.com</VAR
> even though
-the <TT
+the <VAR
CLASS="literal"
->example.com</TT
+>example.com</VAR
> zone includes
-only delegations for the <TT
+only delegations for the <VAR
CLASS="literal"
->aaa.example.com</TT
+>aaa.example.com</VAR
> and
-<TT
+<VAR
CLASS="literal"
->bbb.example.com</TT
+>bbb.example.com</VAR
> 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
+name servers. Every name in the <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> tree is a
<SPAN
CLASS="emphasis"
@@ -783,9 +733,9 @@ 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
+>Though <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> is called a "domain name server",
it deals primarily in terms of zones. The master and slave
declarations in the <TT
@@ -1056,14 +1006,14 @@ 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
+of internal <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>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 <SPAN
+that can do it, and that server would query the Internet <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>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
@@ -1080,9 +1030,9 @@ NAME="AEN218"
>1.4.6. Name Servers in Multiple Roles</A
></H2
><P
->The <SPAN
+>The <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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.</P
@@ -1169,9 +1119,9 @@ VALIGN="top"
WIDTH="33%"
ALIGN="right"
VALIGN="top"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> Resource Requirements</TD
></TR
></TABLE
diff --git a/dist/bind/doc/arm/Bv9ARM.ch02.html b/dist/bind/doc/arm/Bv9ARM.ch02.html
index 8e4e686147b..0b293c7edfd 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch02.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch02.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>BIND Resource Requirements</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -70,11 +70,11 @@ CLASS="chapter"
><H1
><A
NAME="ch02"
->Chapter 2. <SPAN
+></A
+>Chapter 2. <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> Resource Requirements</A
-></H1
+>BIND</ACRONYM
+> Resource Requirements</H1
><DIV
CLASS="TOC"
><DL
@@ -118,25 +118,25 @@ NAME="AEN228"
>2.1. Hardware requirements</A
></H1
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>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 <SPAN
+active duty have performed admirably as <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> servers.</P
><P
->The DNSSEC and IPv6 features of <SPAN
+>The DNSSEC and IPv6 features of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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.
-<SPAN
+<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 is fully multithreaded, allowing full utilization of
multiprocessor systems for installations that need it.</P
></DIV
@@ -149,9 +149,9 @@ NAME="AEN236"
>2.2. CPU Requirements</A
></H1
><P
->CPU requirements for <SPAN
+>CPU requirements for <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -172,9 +172,9 @@ CLASS="command"
>max-cache-size</B
>
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
+at the expense of reducing cache hit rates and causing more <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
>
traffic. It is still good practice to have enough memory to load
all zone and cache data into memory &#8212; unfortunately, the best way
@@ -212,9 +212,9 @@ NAME="AEN248"
>2.5. Supported Operating Systems</A
></H1
><P
->ISC <SPAN
+>ISC <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
diff --git a/dist/bind/doc/arm/Bv9ARM.ch03.html b/dist/bind/doc/arm/Bv9ARM.ch03.html
index f73d942d0ed..204d64ced91 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch03.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch03.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Name Server Configuration</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -70,8 +70,8 @@ CLASS="chapter"
><H1
><A
NAME="ch03"
->Chapter 3. Name Server Configuration</A
-></H1
+></A
+>Chapter 3. Name Server Configuration</H1
><DIV
CLASS="TOC"
><DL
@@ -203,9 +203,9 @@ NAME="AEN268"
></H1
><P
>A primitive form of load balancing can be achieved in
-the <SPAN
+the <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> by using multiple A records for one name.</P
><P
>For example, if you have three WWW servers with network addresses
@@ -214,11 +214,11 @@ following means that clients will connect to each machine one third
of the time:</P
><DIV
CLASS="informaltable"
+><P
+></P
><A
NAME="AEN273"
></A
-><P
-></P
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -226,188 +226,128 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Name</P
></TD
><TD
-WIDTH="48"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>TTL</P
></TD
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>CLASS</P
></TD
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>TYPE</P
></TD
><TD
-WIDTH="195"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Resource Record (RR) Data</P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->www</TT
+>www</VAR
></P
></TD
><TD
-WIDTH="48"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->600</TT
+>600</VAR
></P
></TD
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN</TT
+>IN</VAR
></P
></TD
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="195"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10.0.0.1</TT
+>10.0.0.1</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="48"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->600</TT
+>600</VAR
></P
></TD
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN</TT
+>IN</VAR
></P
></TD
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="195"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10.0.0.2</TT
+>10.0.0.2</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="48"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->600</TT
+>600</VAR
></P
></TD
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN</TT
+>IN</VAR
></P
></TD
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="195"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10.0.0.3</TT
+>10.0.0.3</VAR
></P
></TD
></TR
@@ -417,9 +357,9 @@ CLASS="literal"
></P
></DIV
><P
->When a resolver queries for these records, <SPAN
+>When a resolver queries for these records, <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -442,9 +382,9 @@ HREF="Bv9ARM.ch06.html#rrset_ordering"
></A
>.
This substatement is not supported in
- <SPAN
+ <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9, and only the ordering scheme described above is
available.</P
></DIV
@@ -517,41 +457,27 @@ from the command line.</P
><B
CLASS="command"
>dig</B
-> [@<TT
+> [@<VAR
CLASS="replaceable"
-><I
->server</I
-></TT
->] <TT
+>server</VAR
+>] <VAR
CLASS="replaceable"
-><I
->domain</I
-></TT
-> [<TT
+>domain</VAR
+> [<VAR
CLASS="replaceable"
-><I
->query-type</I
-></TT
->] [<TT
+>query-type</VAR
+>] [<VAR
CLASS="replaceable"
-><I
->query-class</I
-></TT
->] [+<TT
+>query-class</VAR
+>] [+<VAR
CLASS="replaceable"
-><I
->query-option</I
-></TT
->] [-<TT
+>query-option</VAR
+>] [-<VAR
CLASS="replaceable"
-><I
->dig-option</I
-></TT
->] [%<TT
+>dig-option</VAR
+>] [%<VAR
CLASS="replaceable"
-><I
->comment</I
-></TT
+>comment</VAR
>]</P
><P
>The usual simple use of dig will take the form</P
@@ -585,41 +511,27 @@ can be extended with the use of options.</P
><B
CLASS="command"
>host</B
-> [-aCdlrTwv] [-c <TT
+> [-aCdlrTwv] [-c <VAR
CLASS="replaceable"
-><I
->class</I
-></TT
->] [-N <TT
+>class</VAR
+>] [-N <VAR
CLASS="replaceable"
-><I
->ndots</I
-></TT
->] [-t <TT
+>ndots</VAR
+>] [-t <VAR
CLASS="replaceable"
-><I
->type</I
-></TT
->] [-W <TT
+>type</VAR
+>] [-W <VAR
CLASS="replaceable"
-><I
->timeout</I
-></TT
->] [-R <TT
+>timeout</VAR
+>] [-R <VAR
CLASS="replaceable"
-><I
->retries</I
-></TT
->] <TT
+>retries</VAR
+>] <VAR
CLASS="replaceable"
-><I
->hostname</I
-></TT
-> [<TT
+>hostname</VAR
+> [<VAR
CLASS="replaceable"
-><I
->server</I
-></TT
+>server</VAR
>]</P
><P
>For more information and a list of available commands and
@@ -647,11 +559,9 @@ the name and requested information for a host or domain.</P
><B
CLASS="command"
>nslookup</B
-> [-option...] [<TT
+> [-option...] [<VAR
CLASS="replaceable"
-><I
->host-to-find</I
-></TT
+>host-to-find</VAR
> | - [server]]</P
><P
>Interactive mode is entered when no arguments are given (the
@@ -695,10 +605,10 @@ CLASS="variablelist"
><DT
><A
NAME="named-checkconf"
+></A
><B
CLASS="command"
>named-checkconf</B
-></A
></DT
><DD
><P
@@ -714,25 +624,21 @@ CLASS="filename"
><B
CLASS="command"
>named-checkconf</B
-> [-t <TT
+> [-t <VAR
CLASS="replaceable"
-><I
->directory</I
-></TT
->] [<TT
+>directory</VAR
+>] [<VAR
CLASS="replaceable"
-><I
->filename</I
-></TT
+>filename</VAR
>]</P
></DD
><DT
><A
NAME="named-checkzone"
+></A
><B
CLASS="command"
>named-checkzone</B
-></A
></DT
><DD
><P
@@ -745,30 +651,24 @@ CLASS="command"
><B
CLASS="command"
>named-checkzone</B
-> [-dq] [-c <TT
+> [-dq] [-c <VAR
CLASS="replaceable"
-><I
->class</I
-></TT
->] <TT
+>class</VAR
+>] <VAR
CLASS="replaceable"
-><I
->zone</I
-></TT
-> [<TT
+>zone</VAR
+> [<VAR
CLASS="replaceable"
-><I
->filename</I
-></TT
+>filename</VAR
>]</P
></DD
><DT
><A
NAME="rndc"
+></A
><B
CLASS="command"
>rndc</B
-></A
></DT
><DD
><P
@@ -787,36 +687,24 @@ CLASS="command"
><B
CLASS="command"
>rndc</B
-> [-c <TT
+> [-c <VAR
CLASS="replaceable"
-><I
->config</I
-></TT
->] [-s <TT
+>config</VAR
+>] [-s <VAR
CLASS="replaceable"
-><I
->server</I
-></TT
->] [-p <TT
+>server</VAR
+>] [-p <VAR
CLASS="replaceable"
-><I
->port</I
-></TT
->] [-y <TT
+>port</VAR
+>] [-y <VAR
CLASS="replaceable"
-><I
->key</I
-></TT
->] <TT
+>key</VAR
+>] <VAR
CLASS="replaceable"
-><I
->command</I
-></TT
-> [<TT
+>command</VAR
+> [<VAR
CLASS="replaceable"
-><I
->command</I
-></TT
+>command</VAR
>...]</P
><P
><B
@@ -829,147 +717,113 @@ CLASS="command"
CLASS="variablelist"
><DL
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->reload</B
-></TT
+>reload</KBD
></DT
><DD
><P
>Reload configuration file and zones.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->reload <TT
+>reload <VAR
CLASS="replaceable"
-><I
->zone</I
-></TT
+>zone</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->class</I
-></TT
+>class</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->view</I
-></TT
+>view</VAR
></SPAN
>]</SPAN
->]</B
-></TT
+>]</KBD
></DT
><DD
><P
>Reload the given zone.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->refresh <TT
+>refresh <VAR
CLASS="replaceable"
-><I
->zone</I
-></TT
+>zone</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->class</I
-></TT
+>class</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->view</I
-></TT
+>view</VAR
></SPAN
>]</SPAN
->]</B
-></TT
+>]</KBD
></DT
><DD
><P
>Schedule zone maintenance for the given zone.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->retransfer <TT
+>retransfer <VAR
CLASS="replaceable"
-><I
->zone</I
-></TT
+>zone</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->class</I
-></TT
+>class</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->view</I
-></TT
+>view</VAR
></SPAN
>]</SPAN
->]</B
-></TT
+>]</KBD
></DT
><DD
><P
>Retransfer the given zone from the master.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->freeze <TT
+>freeze <VAR
CLASS="replaceable"
-><I
->zone</I
-></TT
+>zone</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->class</I
-></TT
+>class</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->view</I
-></TT
+>view</VAR
></SPAN
>]</SPAN
->]</B
-></TT
+>]</KBD
></DT
><DD
><P
@@ -980,34 +834,26 @@ CLASS="replaceable"
be refused while the zone is frozen.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->unfreeze <TT
+>unfreeze <VAR
CLASS="replaceable"
-><I
->zone</I
-></TT
+>zone</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->class</I
-></TT
+>class</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->view</I
-></TT
+>view</VAR
></SPAN
>]</SPAN
->]</B
-></TT
+>]</KBD
></DT
><DD
><P
@@ -1017,11 +863,9 @@ CLASS="replaceable"
will no longer be refused.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->reconfig</B
-></TT
+>reconfig</KBD
></DT
><DD
><P
@@ -1036,22 +880,18 @@ CLASS="command"
</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->stats</B
-></TT
+>stats</KBD
></DT
><DD
><P
>Write server statistics to the statistics file.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->querylog</B
-></TT
+>querylog</KBD
></DT
><DD
><P
@@ -1077,22 +917,18 @@ CLASS="filename"
>.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->dumpdb</B
-></TT
+>dumpdb</KBD
></DT
><DD
><P
>Dump the server's caches to the dump file. </P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->stop</B
-></TT
+>stop</KBD
></DT
><DD
><P
@@ -1102,11 +938,9 @@ CLASS="userinput"
of the updated zones.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->halt</B
-></TT
+>halt</KBD
></DT
><DD
><P
@@ -1116,27 +950,21 @@ CLASS="userinput"
is restarted.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->trace</B
-></TT
+>trace</KBD
></DT
><DD
><P
>Increment the servers debugging level by one. </P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->trace <TT
+>trace <VAR
CLASS="replaceable"
-><I
->level</I
-></TT
-></B
-></TT
+>level</VAR
+></KBD
></DT
><DD
><P
@@ -1144,33 +972,27 @@ CLASS="replaceable"
value.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->notrace</B
-></TT
+>notrace</KBD
></DT
><DD
><P
>Sets the server's debugging level to 0.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->flush</B
-></TT
+>flush</KBD
></DT
><DD
><P
>Flushes the server's cache.</P
></DD
><DT
-><TT
+><KBD
CLASS="userinput"
-><B
->status</B
-></TT
+>status</KBD
></DT
><DD
><P
@@ -1188,9 +1010,9 @@ explicit root zone configured.</P
></DL
></DIV
><P
->In <SPAN
+>In <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9.2, <B
CLASS="command"
>rndc</B
@@ -1225,9 +1047,9 @@ CLASS="command"
CLASS="filename"
>/etc/rndc.conf</TT
>, but an alternate
-location can be specified with the <TT
+location can be specified with the <VAR
CLASS="option"
->-c</TT
+>-c</VAR
>
option. If the configuration file is not found,
<B
@@ -1238,13 +1060,13 @@ CLASS="command"
CLASS="filename"
>/etc/rndc.key</TT
> (or whatever
-<TT
+<VAR
CLASS="varname"
->sysconfdir</TT
+>sysconfdir</VAR
> was defined when
-the <SPAN
+the <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> build was configured).
The <TT
CLASS="filename"
@@ -1304,9 +1126,9 @@ CLASS="command"
>default-server</B
> takes a
host name or address argument and represents the server that will
-be contacted if no <TT
+be contacted if no <VAR
CLASS="option"
->-s</TT
+>-s</VAR
>
option is provided on the command line.
<B
@@ -1347,19 +1169,15 @@ CLASS="command"
CLASS="command"
>key</B
> statement in named.conf.
-The keyword <TT
+The keyword <KBD
CLASS="userinput"
-><B
->key</B
-></TT
+>key</KBD
> is
followed by a key name, which must be a valid
domain name, though it need not actually be hierarchical; thus,
-a string like "<TT
+a string like "<KBD
CLASS="userinput"
-><B
->rndc_key</B
-></TT
+>rndc_key</KBD
>" is a valid name.
The <B
CLASS="command"
@@ -1373,11 +1191,9 @@ CLASS="command"
>secret</B
>.
While the configuration parser will accept any string as the argument
-to algorithm, currently only the string "<TT
+to algorithm, currently only the string "<KBD
CLASS="userinput"
-><B
->hmac-md5</B
-></TT
+>hmac-md5</KBD
>"
has any meaning. The secret is a base-64 encoded string.</P
><P
@@ -1389,11 +1205,9 @@ defined using the <B
CLASS="command"
>key</B
> statement with a server.
-The keyword <TT
+The keyword <KBD
CLASS="userinput"
-><B
->server</B
-></TT
+>server</KBD
> is followed by a
host name or address. The <B
CLASS="command"
@@ -1440,14 +1254,12 @@ CLASS="filename"
>,
would allow the command:</P
><P
-><TT
+><SAMP
CLASS="prompt"
->$ </TT
-><TT
+>$ </SAMP
+><KBD
CLASS="userinput"
-><B
->rndc reload</B
-></TT
+>rndc reload</KBD
></P
><P
>to connect to 127.0.0.1 port 953 and cause the name server
@@ -1461,9 +1273,9 @@ CLASS="programlisting"
</PRE
><P
>and it had an identical key statement for
-<TT
+<VAR
CLASS="literal"
->rndc_key</TT
+>rndc_key</VAR
>.</P
><P
>Running the <B
@@ -1518,11 +1330,11 @@ CLASS="command"
> command.</P
><DIV
CLASS="informaltable"
+><P
+></P
><A
NAME="AEN683"
></A
-><P
-></P
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -1530,9 +1342,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1540,9 +1349,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Causes the server to read <TT
CLASS="filename"
@@ -1553,9 +1359,6 @@ reload the database. </P
></TR
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1563,18 +1366,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Causes the server to clean up and exit.</P
></TD
></TR
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
>&#13;<P
><B
CLASS="command"
@@ -1583,9 +1380,6 @@ CLASS="command"
>
</TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Causes the server to clean up and exit.</P
></TD
@@ -1642,9 +1436,9 @@ ACCESSKEY="N"
WIDTH="33%"
ALIGN="left"
VALIGN="top"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> Resource Requirements</TD
><TD
WIDTH="34%"
diff --git a/dist/bind/doc/arm/Bv9ARM.ch04.html b/dist/bind/doc/arm/Bv9ARM.ch04.html
index 496c45b43fa..a1f90b4c512 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch04.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch04.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Advanced DNS Features</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -70,8 +70,8 @@ CLASS="chapter"
><H1
><A
NAME="ch04"
->Chapter 4. Advanced DNS Features</A
-></H1
+></A
+>Chapter 4. Advanced DNS Features</H1
><DIV
CLASS="TOC"
><DL
@@ -121,10 +121,10 @@ HREF="Bv9ARM.ch04.html#DNSSEC"
></DT
><DT
>4.9. <A
-HREF="Bv9ARM.ch04.html#AEN1019"
->IPv6 Support in <SPAN
+HREF="Bv9ARM.ch04.html#AEN1001"
+>IPv6 Support in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9</A
></DT
></DL
@@ -138,9 +138,9 @@ NAME="notify"
>4.1. Notify</A
></H1
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>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 <B
@@ -150,9 +150,9 @@ CLASS="command"
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
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
>
For more information about
<B
@@ -209,7 +209,7 @@ CLASS="command"
> statement.</P
><P
>Updating of secure zones (zones using DNSSEC) follows
- RFC 3007: SIG and NXT records affected by updates are automatically
+ 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
@@ -261,11 +261,9 @@ CLASS="command"
to the zone using
<B
CLASS="command"
->rndc freeze <TT
+>rndc freeze <VAR
CLASS="replaceable"
-><I
->zone</I
-></TT
+>zone</VAR
></B
>.
This will also remove the zone's <TT
@@ -275,11 +273,9 @@ CLASS="filename"
and update the master file. Edit the zone file. Run
<B
CLASS="command"
->rndc unfreeze <TT
+>rndc unfreeze <VAR
CLASS="replaceable"
-><I
->zone</I
-></TT
+>zone</VAR
></B
>
to reload the changed zone and re-enable dynamic updates.</P
@@ -302,9 +298,9 @@ HREF="Bv9ARM.ch09.html#proposed_standards"
>Proposed Standards</A
>.</P
><P
->When acting as a master, <SPAN
+>When acting as a master, <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9
supports IXFR for those zones
where the necessary change history information is available. These
@@ -316,17 +312,15 @@ transfer (AXFR), IXFR is supported only if the option
CLASS="command"
>ixfr-from-differences</B
> is set
-to <TT
+to <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>.
</P
><P
->When acting as a slave, <SPAN
+>When acting as a slave, <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 will
attempt to use IXFR unless
it is explicitly disabled. For more information about disabling
@@ -381,9 +375,9 @@ CLASS="emphasis"
>Example, Inc.</I
></SPAN
>
-(<TT
+(<VAR
CLASS="literal"
->example.com</TT
+>example.com</VAR
>)
has several corporate sites that have an internal network with reserved
Internet Protocol (IP) space and an external demilitarized zone (DMZ),
@@ -495,9 +489,9 @@ internal hosts.</P
>Here's an example of a wildcard MX record:</P
><PRE
CLASS="programlisting"
-><TT
+><VAR
CLASS="literal"
->* IN MX 10 external1.example.com.</TT
+>* IN MX 10 external1.example.com.</VAR
></PRE
><P
>Now that they accept mail on behalf of anything in the internal
@@ -534,24 +528,24 @@ internal clients will now be able to:</P
><UL
><LI
><P
->Look up any hostnames in the <TT
+>Look up any hostnames in the <VAR
CLASS="literal"
->site1</TT
+>site1</VAR
> and
-<TT
+<VAR
CLASS="literal"
->site2.example.com</TT
+>site2.example.com</VAR
> zones.</P
></LI
><LI
><P
->Look up any hostnames in the <TT
+>Look up any hostnames in the <VAR
CLASS="literal"
->site1.internal</TT
+>site1.internal</VAR
> and
-<TT
+<VAR
CLASS="literal"
->site2.internal</TT
+>site2.internal</VAR
> domains.</P
></LI
><LI
@@ -570,24 +564,24 @@ CLASS="literal"
><UL
><LI
><P
->Look up any hostnames in the <TT
+>Look up any hostnames in the <VAR
CLASS="literal"
->site1</TT
+>site1</VAR
> and
-<TT
+<VAR
CLASS="literal"
->site2.example.com</TT
+>site2.example.com</VAR
> zones.</P
></LI
><LI
><P
->Exchange mail with anyone in the <TT
+>Exchange mail with anyone in the <VAR
CLASS="literal"
->site1</TT
+>site1</VAR
> and
-<TT
+<VAR
CLASS="literal"
->site2.example.com</TT
+>site2.example.com</VAR
> zones.</P
></LI
></UL
@@ -605,9 +599,9 @@ CLASS="programlisting"
>&#13;
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-acl externals { <TT
+acl externals { <VAR
CLASS="varname"
->bastion-ips-go-here</TT
+>bastion-ips-go-here</VAR
>; };
options {
@@ -615,9 +609,9 @@ options {
...
forward only;
forwarders { // forward to external servers
- <TT
+ <VAR
CLASS="varname"
->bastion-ips-go-here</TT
+>bastion-ips-go-here</VAR
>;
};
allow-transfer { none; }; // sample allow-transfer (no one)
@@ -719,25 +713,25 @@ NAME="tsig"
></H1
><P
>This is a short guide to setting up Transaction SIGnatures
-(TSIG) based transaction security in <SPAN
+(TSIG) based transaction security in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+keys and using transaction signatures with <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>.</P
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+Resolvers based on newer versions of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 have limited support
for TSIG.</P
><P
@@ -749,13 +743,13 @@ for TSIG.</P
CLASS="command"
>nsupdate</B
>
- program supports TSIG via the <TT
+ program supports TSIG via the <VAR
CLASS="option"
->-k</TT
+>-k</VAR
> and
- <TT
+ <VAR
CLASS="option"
->-y</TT
+>-y</VAR
> command line options.</P
><DIV
CLASS="sect2"
@@ -796,11 +790,9 @@ 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
-><TT
+><KBD
CLASS="userinput"
-><B
->dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</B
-></TT
+>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</KBD
></P
><P
>The key is in the file <TT
@@ -808,18 +800,18 @@ CLASS="filename"
>Khost1-host2.+157+00000.private</TT
>.
Nothing directly uses this file, but the base-64 encoded string
-following "<TT
+following "<VAR
CLASS="literal"
->Key:</TT
+>Key:</VAR
>"
can be extracted from the file and used as a shared secret:</P
><PRE
CLASS="programlisting"
>Key: La/E5CjG9O+os1jq0a2jdA==</PRE
><P
->The string "<TT
+>The string "<VAR
CLASS="literal"
->La/E5CjG9O+os1jq0a2jdA==</TT
+>La/E5CjG9O+os1jq0a2jdA==</VAR
>" can
be used as the shared secret.</P
></DIV
@@ -890,9 +882,9 @@ CLASS="programlisting"
};
</PRE
><P
->The algorithm, hmac-md5, is the only one supported by <SPAN
+>The algorithm, hmac-md5, is the only one supported by <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>.
The secret is the one generated above. Since this is a secret, it
is recommended that either <TT
@@ -1003,9 +995,9 @@ NAME="AEN900"
>4.5.5. TSIG Key Based Access Control</A
></H2
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> allows IP addresses and ranges to be specified in ACL
definitions and
<B
@@ -1087,9 +1079,9 @@ CLASS="command"
CLASS="command"
>TKEY</B
> that specify how the key is
- generated or assigned. <SPAN
+ generated or assigned. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9
implements only one of these modes,
the Diffie-Hellman key exchange. Both hosts are required to have
@@ -1145,9 +1137,9 @@ NAME="AEN932"
>4.7. SIG(0)</A
></H1
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -1161,9 +1153,9 @@ CLASS="acronym"
>SIG(0) signing of multiple-message TCP streams is not
supported.</P
><P
->The only tool shipped with <SPAN
+>The only tool shipped with <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 that
generates SIG(0) signed messages is <B
CLASS="command"
@@ -1184,36 +1176,41 @@ NAME="DNSSEC"
CLASS="emphasis"
><I
CLASS="emphasis"
->DNSSEC</I
+>DNSSEC-bis</I
></SPAN
>) extensions,
- defined in RFC 2535. This section describes the creation and use
+ defined in RFC &#60;TBA&#62;. 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
+ of steps which must be followed. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 ships
with several tools
that are used in this process, which are explained in more detail
- below. In all cases, the <TT
+ below. In all cases, the <VAR
CLASS="option"
->-h</TT
+>-h</VAR
> option prints a
full list of parameters. Note that the DNSSEC tools require the
- keyset and signedkey files to be in the working directory or the
- directory specified by the <TT
+ keyset files to be in the working directory or the
+ directory specified by the <VAR
CLASS="option"
->-h</TT
+>-h</VAR
> option, and
- that the tools shipped with BIND 9.0.x are not fully compatible
+ 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 and signatures. A
- zone's security status must be indicated by the parent zone for a
- DNSSEC capable resolver to trust its data.</P
+ 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 <VAR
+CLASS="literal"
+>DS</VAR
+> 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
@@ -1223,7 +1220,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN951"
+NAME="AEN952"
>4.8.1. Generating Keys</A
></H2
><P
@@ -1243,29 +1240,27 @@ CLASS="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
- these are RSASHA1 and DSA.</P
+ the only one is RSASHA1.</P
><P
->The following command will generate a 768 bit DSA key for
+>The following command will generate a 768 bit RSASHA1 key for
the <TT
CLASS="filename"
>child.example</TT
> zone:</P
><P
-><TT
+><KBD
CLASS="userinput"
-><B
->dnssec-keygen -a DSA -b 768 -n ZONE child.example.</B
-></TT
+>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</KBD
></P
><P
>Two output files will be produced:
<TT
CLASS="filename"
->Kchild.example.+003+12345.key</TT
+>Kchild.example.+005+12345.key</TT
> and
<TT
CLASS="filename"
->Kchild.example.+003+12345.private</TT
+>Kchild.example.+005+12345.private</TT
> (where
12345 is an example of a key tag). The key file names contain
the key name (<TT
@@ -1303,111 +1298,8 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN971"
->4.8.2. Creating a Keyset</A
-></H2
-><P
->The <B
-CLASS="command"
->dnssec-makekeyset</B
-> program is used
- to create a key set from one or more keys.</P
-><P
->Once the zone keys have been generated, a key set must be
- built for transmission to the administrator of the parent zone,
- so that the parent zone can sign the keys with its own zone key
- and correctly indicate the security status of this zone. When
- building a key set, the list of keys to be included and the TTL
- of the set must be specified, and the desired signature validity
- period of the parent's signature may also be specified.</P
-><P
->The list of keys to be inserted into the key set may also
- included non-zone keys present at the top of the zone.
- <B
-CLASS="command"
->dnssec-makekeyset</B
-> may also be used at other
- names in the zone.</P
-><P
->The following command generates a key set containing the
- above key and another key similarly generated, with a TTL of
- 3600 and a signature validity period of 10 days starting from
- now.</P
-><P
-><TT
-CLASS="userinput"
-><B
->dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</B
-></TT
-></P
-><P
->One output file is produced:
- <TT
-CLASS="filename"
->keyset-child.example.</TT
->. This file should be
- transmitted to the parent to be signed. It includes the keys,
- as well as signatures over the key set generated by the zone
- keys themselves, which are used to prove ownership of the
- private keys and encode the desired validity period.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN983"
->4.8.3. Signing the Child's Keyset</A
-></H2
-><P
->The <B
-CLASS="command"
->dnssec-signkey</B
-> program is used to
- sign one child's keyset.</P
-><P
->If the <TT
-CLASS="filename"
->child.example</TT
-> zone has any
- delegations which are secure, for example,
- <TT
-CLASS="filename"
->grand.child.example</TT
->, the
- <TT
-CLASS="filename"
->child.example</TT
-> administrator should receive
- keyset files for each secure subzone. These keys must be signed
- by this zone's zone keys.</P
-><P
->The following command signs the child's key set with the
- zone keys:</P
-><P
-><TT
-CLASS="userinput"
-><B
->dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</B
-></TT
-></P
-><P
->One output file is produced:
- <TT
-CLASS="filename"
->signedkey-grand.child.example.</TT
->. This file
- should be both transmitted back to the child and retained. It
- includes all keys (the child's keys) from the keyset file and
- signatures generated by this zone's zone keys.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN996"
->4.8.4. Signing the Zone</A
+NAME="AEN972"
+>4.8.2. Signing the Zone</A
></H2
><P
>The <B
@@ -1418,24 +1310,29 @@ CLASS="command"
><P
>Any <TT
CLASS="filename"
->signedkey</TT
-> files corresponding to
- secure subzones should be present, as well as a
- <TT
-CLASS="filename"
->signedkey</TT
-> file for this zone generated by
- the parent (if there is one). The zone signer will generate
- <TT
+>keyset</TT
+> files corresponding
+ to secure subzones should be present. The zone signer will
+ generate <VAR
CLASS="literal"
->NXT</TT
-> and <TT
+>NSEC</VAR
+> and <VAR
+CLASS="literal"
+>RRSIG</VAR
+>
+ records for the zone, as well as <VAR
+CLASS="literal"
+>DS</VAR
+> for
+ the child zones if <VAR
+CLASS="literal"
+>'-d'</VAR
+> is specified.
+ If <VAR
CLASS="literal"
->SIG</TT
-> records for
- the zone, as well as incorporate the zone key signature from the
- parent and indicate the security status at all delegation
- points.</P
+>'-d'</VAR
+> 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 <TT
@@ -1445,11 +1342,9 @@ CLASS="filename"
default, all zone keys which have an available private key are
used to generate signatures.</P
><P
-><TT
+><KBD
CLASS="userinput"
-><B
->dnssec-signzone -o child.example zone.child.example</B
-></TT
+>dnssec-signzone -o child.example zone.child.example</KBD
></P
><P
>One output file is produced:
@@ -1462,23 +1357,38 @@ CLASS="filename"
>named.conf</TT
> as the
input file for the zone.</P
+><P
+><B
+CLASS="command"
+>dnssec-signzone</B
+> will also produce a
+ keyset and dsset files and optionally a dlvset file. These
+ are used to provide the parent zone administators with the
+ <VAR
+CLASS="literal"
+>DNSKEYs</VAR
+> (or their corresponding <VAR
+CLASS="literal"
+>DS</VAR
+>
+ records) that are the secure entry point to the zone.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1012"
->4.8.5. Configuring Servers</A
+NAME="AEN994"
+>4.8.3. Configuring Servers</A
></H2
><P
->Unlike <SPAN
+>Unlike <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8,
-<SPAN
+<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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.</P
@@ -1496,42 +1406,42 @@ CLASS="sect1"
><H1
CLASS="sect1"
><A
-NAME="AEN1019"
->4.9. IPv6 Support in <SPAN
+NAME="AEN1001"
+>4.9. IPv6 Support in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9</A
></H1
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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.</P
><P
->For forward lookups, <SPAN
+>For forward lookups, <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 supports only AAAA
records. The use of A6 records is deprecated by RFC 3363, and the
- support for forward lookups in <SPAN
+ support for forward lookups in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 is
removed accordingly.
- However, authoritative <SPAN
+ However, authoritative <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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.</P
><P
->For IPv6 reverse lookups, <SPAN
+>For IPv6 reverse lookups, <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 supports
the traditional "nibble" format used in the
<SPAN
@@ -1548,21 +1458,21 @@ CLASS="emphasis"
>ip6.int</I
></SPAN
> domain.
- <SPAN
+ <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+ Any applications in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 do not understand
the format any more, and will return an error if given.
- In particular, an authoritative <SPAN
+ In particular, an authoritative <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 name
server rejects to load a zone file containing binary labels.</P
><P
@@ -1576,7 +1486,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1037"
+NAME="AEN1019"
>4.9.1. Address Lookups Using AAAA Records</A
></H2
><P
@@ -1586,14 +1496,14 @@ NAME="AEN1037"
><PRE
CLASS="programlisting"
>&#13;$ORIGIN example.com.
-host 3600 IN AAAA 2001:4f8:201:1860:42::1
+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 <TT
+ a AAAA, with <VAR
CLASS="literal"
->::ffff:192.168.42.1</TT
+>::ffff:192.168.42.1</VAR
> as the
address.</P
></DIV
@@ -1602,26 +1512,26 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1043"
+NAME="AEN1025"
>4.9.2. Address to Name Lookups Using Nibble Format</A
></H2
><P
>When looking up an address in nibble format, the address
components are simply reversed, just as in IPv4, and
- <TT
+ <VAR
CLASS="literal"
->ip6.arpa.</TT
+>ip6.arpa.</VAR
> is appended to the resulting name.
For example, the following would provide reverse name lookup for
a host with address
- <TT
+ <VAR
CLASS="literal"
->2001:4f8:201:1860:42::1</TT
+>2001:db8::1</VAR
>.</P
><PRE
CLASS="programlisting"
->&#13;$ORIGIN 0.6.8.1.1.0.2.0.8.f.4.0.1.0.0.2.ip6.arpa.
-1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.example.com.
+>&#13;$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
@@ -1680,9 +1590,9 @@ VALIGN="top"
WIDTH="33%"
ALIGN="right"
VALIGN="top"
->The <SPAN
+>The <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Lightweight Resolver</TD
></TR
></TABLE
diff --git a/dist/bind/doc/arm/Bv9ARM.ch05.html b/dist/bind/doc/arm/Bv9ARM.ch05.html
index 1153c053d41..2ae7f2ec130 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch05.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch05.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>The BIND 9 Lightweight Resolver</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -70,11 +70,11 @@ CLASS="chapter"
><H1
><A
NAME="ch05"
->Chapter 5. The <SPAN
+></A
+>Chapter 5. The <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> 9 Lightweight Resolver</A
-></H1
+>BIND</ACRONYM
+> 9 Lightweight Resolver</H1
><DIV
CLASS="TOC"
><DL
@@ -84,7 +84,7 @@ CLASS="TOC"
></DT
><DT
>5.1. <A
-HREF="Bv9ARM.ch05.html#AEN1052"
+HREF="Bv9ARM.ch05.html#AEN1034"
>The Lightweight Resolver Library</A
></DT
><DT
@@ -99,7 +99,7 @@ CLASS="sect1"
><H1
CLASS="sect1"
><A
-NAME="AEN1052"
+NAME="AEN1034"
>5.1. The Lightweight Resolver Library</A
></H1
><P
@@ -113,9 +113,9 @@ 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
+>Instead, <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -253,9 +253,9 @@ VALIGN="top"
WIDTH="33%"
ALIGN="right"
VALIGN="top"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Configuration Reference</TD
></TR
></TABLE
diff --git a/dist/bind/doc/arm/Bv9ARM.ch06.html b/dist/bind/doc/arm/Bv9ARM.ch06.html
index d8ab5775469..a83ec38ef3f 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch06.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch06.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>BIND 9 Configuration Reference</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -70,11 +70,11 @@ CLASS="chapter"
><H1
><A
NAME="ch06"
->Chapter 6. <SPAN
+></A
+>Chapter 6. <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> 9 Configuration Reference</A
-></H1
+>BIND</ACRONYM
+> 9 Configuration Reference</H1
><DIV
CLASS="TOC"
><DL
@@ -94,38 +94,38 @@ HREF="Bv9ARM.ch06.html#Configuration_File_Grammar"
></DT
><DT
>6.3. <A
-HREF="Bv9ARM.ch06.html#AEN4019"
+HREF="Bv9ARM.ch06.html#AEN4015"
>Zone File</A
></DT
></DL
></DIV
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 configuration is broadly similar
-to <SPAN
+to <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8; however, there are a few new areas
-of configuration, such as views. <SPAN
+of configuration, such as views. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>
-8 configuration files should work with few alterations in <SPAN
+8 configuration files should work with few alterations in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+found in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9.</P
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 4 configuration files can be converted to the new format
using the shell script
<TT
@@ -141,18 +141,18 @@ NAME="configuration_file_elements"
>6.1. Configuration File Elements</A
></H1
><P
->Following is a list of elements used throughout the <SPAN
+>Following is a list of elements used throughout the <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> configuration
file documentation:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN1094"
-></A
><P
></P
+><A
+NAME="AEN1076"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -160,23 +160,17 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->acl_name</TT
+>acl_name</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->The name of an <TT
+>The name of an <VAR
CLASS="varname"
->address_match_list</TT
+>address_match_list</VAR
> as
defined by the <B
CLASS="command"
@@ -186,34 +180,28 @@ CLASS="command"
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->address_match_list</TT
+>address_match_list</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->A list of one or more <TT
+>A list of one or more <VAR
CLASS="varname"
->ip_addr</TT
+>ip_addr</VAR
>,
-<TT
+<VAR
CLASS="varname"
->ip_prefix</TT
->, <TT
+>ip_prefix</VAR
+>, <VAR
CLASS="varname"
->key_id</TT
+>key_id</VAR
>,
-or <TT
+or <VAR
CLASS="varname"
->acl_name</TT
+>acl_name</VAR
> elements, see
<A
HREF="Bv9ARM.ch06.html#address_match_lists"
@@ -223,42 +211,30 @@ HREF="Bv9ARM.ch06.html#address_match_lists"
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->domain_name</TT
+>domain_name</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>A quoted string which will be used as
-a DNS name, for example "<TT
+a DNS name, for example "<VAR
CLASS="literal"
->my.test.domain</TT
+>my.test.domain</VAR
>".</P
></TD
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->dotted_decimal</TT
+>dotted_decimal</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>One to four integers valued 0 through
255 separated by dots (`.'), such as <B
@@ -276,46 +252,34 @@ CLASS="command"
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->ip4_addr</TT
+>ip4_addr</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>An IPv4 address with exactly four elements
-in <TT
+in <VAR
CLASS="varname"
->dotted_decimal</TT
+>dotted_decimal</VAR
> notation.</P
></TD
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->ip6_addr</TT
+>ip6_addr</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>An IPv6 address, such as <B
CLASS="command"
->2001:ffff::200:f8ff:fe01:9742</B
+>2001:db8::1234</B
>.
IPv6 scoped addresses that have ambiguity on their scope zones must be
disambiguated by an appropriate zone ID with the percent character
@@ -344,52 +308,40 @@ ambiguity, and need to be disambiguated.</P
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->ip_addr</TT
+>ip_addr</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->An <TT
+>An <VAR
CLASS="varname"
->ip4_addr</TT
-> or <TT
+>ip4_addr</VAR
+> or <VAR
CLASS="varname"
->ip6_addr</TT
+>ip6_addr</VAR
>.</P
></TD
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->ip_port</TT
+>ip_port</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->An IP port <TT
+>An IP port <VAR
CLASS="varname"
->number</TT
+>number</VAR
>.
-<TT
+<VAR
CLASS="varname"
->number</TT
+>number</VAR
> 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
@@ -398,28 +350,22 @@ select a random high-numbered port.</P
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->ip_prefix</TT
+>ip_prefix</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->An IP network specified as an <TT
+>An IP network specified as an <VAR
CLASS="varname"
->ip_addr</TT
+>ip_addr</VAR
>,
followed by a slash (`/') and then the number of bits in the netmask.
-Trailing zeros in a <TT
+Trailing zeros in a <VAR
CLASS="varname"
->ip_addr</TT
+>ip_addr</VAR
> may omitted.
For example, <B
CLASS="command"
@@ -446,65 +392,47 @@ CLASS="command"
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->key_id</TT
+>key_id</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->A <TT
+>A <VAR
CLASS="varname"
->domain_name</TT
+>domain_name</VAR
> representing
the name of a shared key, to be used for transaction security.</P
></TD
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->key_list</TT
+>key_list</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->A list of one or more <TT
+>A list of one or more <VAR
CLASS="varname"
->key_id</TT
+>key_id</VAR
>s,
separated by semicolons and ending with a semicolon.</P
></TD
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->number</TT
+>number</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>A non-negative 32 bit integer
(i.e., a number between 0 and 4294967295, inclusive).
@@ -514,19 +442,13 @@ be limited by the context in which it is used.</P
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->path_name</TT
+>path_name</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>A quoted string which will be used as
a pathname, such as <TT
@@ -537,212 +459,148 @@ CLASS="filename"
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->size_spec</TT
+>size_spec</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->A number, the word <TT
+>A number, the word <KBD
CLASS="userinput"
-><B
->unlimited</B
-></TT
+>unlimited</KBD
>,
-or the word <TT
+or the word <KBD
CLASS="userinput"
-><B
->default</B
-></TT
+>default</KBD
>.</P
><P
->&#13;An <TT
+>&#13;An <VAR
CLASS="varname"
->unlimited</TT
-> <TT
+>unlimited</VAR
+> <VAR
CLASS="varname"
->size_spec</TT
+>size_spec</VAR
> requests unlimited
-use, or the maximum available amount. A <TT
+use, or the maximum available amount. A <VAR
CLASS="varname"
->default size_spec</TT
+>default size_spec</VAR
> uses
the limit that was in force when the server was started.</P
><P
->A <TT
+>A <VAR
CLASS="varname"
->number</TT
+>number</VAR
> can
-optionally be followed by a scaling factor: <TT
+optionally be followed by a scaling factor: <KBD
CLASS="userinput"
-><B
->K</B
-></TT
-> or <TT
+>K</KBD
+> or <KBD
CLASS="userinput"
-><B
->k</B
-></TT
+>k</KBD
> for
-kilobytes, <TT
+kilobytes, <KBD
CLASS="userinput"
-><B
->M</B
-></TT
-> or <TT
+>M</KBD
+> or <KBD
CLASS="userinput"
-><B
->m</B
-></TT
+>m</KBD
> for
-megabytes, and <TT
+megabytes, and <KBD
CLASS="userinput"
-><B
->G</B
-></TT
-> or <TT
+>G</KBD
+> or <KBD
CLASS="userinput"
-><B
->g</B
-></TT
+>g</KBD
> 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 <TT
+Using <VAR
CLASS="varname"
->unlimited</TT
+>unlimited</VAR
> is the best way
to safely set a really large number.</P
></TD
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->yes_or_no</TT
+>yes_or_no</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->Either <TT
+>Either <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
-> or <TT
+>yes</KBD
+> or <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>.
-The words <TT
+The words <KBD
CLASS="userinput"
-><B
->true</B
-></TT
-> and <TT
+>true</KBD
+> and <KBD
CLASS="userinput"
-><B
->false</B
-></TT
+>false</KBD
> are
-also accepted, as are the numbers <TT
+also accepted, as are the numbers <KBD
CLASS="userinput"
-><B
->1</B
-></TT
-> and <TT
+>1</KBD
+> and <KBD
CLASS="userinput"
-><B
->0</B
-></TT
+>0</KBD
>.</P
></TD
></TR
><TR
><TD
-WIDTH="178"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->dialup_option</TT
+>dialup_option</VAR
></P
></TD
><TD
-WIDTH="362"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->One of <TT
+>One of <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>,
-<TT
+<KBD
CLASS="userinput"
-><B
->no</B
-></TT
->, <TT
+>no</KBD
+>, <KBD
CLASS="userinput"
-><B
->notify</B
-></TT
+>notify</KBD
>,
-<TT
+<KBD
CLASS="userinput"
-><B
->notify-passive</B
-></TT
->, <TT
+>notify-passive</KBD
+>, <KBD
CLASS="userinput"
-><B
->refresh</B
-></TT
+>refresh</KBD
> or
-<TT
+<KBD
CLASS="userinput"
-><B
->passive</B
-></TT
+>passive</KBD
>.
-When used in a zone, <TT
+When used in a zone, <KBD
CLASS="userinput"
-><B
->notify-passive</B
-></TT
+>notify-passive</KBD
>,
-<TT
+<KBD
CLASS="userinput"
-><B
->refresh</B
-></TT
->, and <TT
+>refresh</KBD
+>, and <KBD
CLASS="userinput"
-><B
->passive</B
-></TT
+>passive</KBD
>
are restricted to slave and stub zones.</P
></TD
@@ -765,22 +623,22 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN1259"
+NAME="AEN1241"
>6.1.1.1. Syntax</A
></H3
><PRE
CLASS="programlisting"
-><TT
+><VAR
CLASS="varname"
->address_match_list</TT
+>address_match_list</VAR
> = address_match_list_element ;
[<SPAN
CLASS="optional"
> address_match_list_element; ... </SPAN
>]
-<TT
+<VAR
CLASS="varname"
->address_match_list_element</TT
+>address_match_list_element</VAR
> = [<SPAN
CLASS="optional"
> ! </SPAN
@@ -796,7 +654,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN1267"
+NAME="AEN1249"
>6.1.1.2. Definition and Usage</A
></H3
><P
@@ -910,17 +768,17 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1298"
+NAME="AEN1280"
>6.1.2. Comment Syntax</A
></H2
><P
->The <SPAN
+>The <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 comment syntax allows for comments to appear
-anywhere that white space may appear in a <SPAN
+anywhere that white space may appear in a <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> configuration
file. To appeal to programmers of all kinds, they can be written
in the C, C++, or shell/perl style.</P
@@ -929,29 +787,29 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN1303"
+NAME="AEN1285"
>6.1.2.1. Syntax</A
></H3
><P
><PRE
CLASS="programlisting"
->/* This is a <SPAN
+>/* This is a <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> comment as in C */</PRE
>
<PRE
CLASS="programlisting"
->// This is a <SPAN
+>// This is a <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> comment as in C++</PRE
>
<PRE
CLASS="programlisting"
-># This is a <SPAN
+># This is a <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> comment as in common UNIX shells and perl</PRE
>
</P
@@ -961,14 +819,14 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN1312"
+NAME="AEN1294"
>6.1.2.2. Definition and Usage</A
></H3
><P
>Comments may appear anywhere that whitespace may appear in
-a <SPAN
+a <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> configuration file.</P
><P
>C-style comments start with the two characters /* (slash,
@@ -1004,9 +862,9 @@ CLASS="programlisting"
></P
><P
>Shell-style (or perl-style, if you prefer) comments start
-with the character <TT
+with the character <VAR
CLASS="literal"
->#</TT
+>#</VAR
> (number sign) and continue to the end of the
physical line, as in C++ comments.</P
><P
@@ -1059,9 +917,9 @@ NAME="Configuration_File_Grammar"
>6.2. Configuration File Grammar</A
></H1
><P
->A <SPAN
+>A <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -1071,11 +929,11 @@ CLASS="acronym"
>The following statements are supported:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN1336"
-></A
><P
></P
+><A
+NAME="AEN1318"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -1083,9 +941,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1093,9 +948,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>defines a named IP address
matching list, for access control and other uses.</P
@@ -1103,9 +955,6 @@ matching list, for access control and other uses.</P
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1113,9 +962,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>declares control channels to be used
by the <B
@@ -1126,9 +972,6 @@ CLASS="command"
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1136,18 +979,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>includes a file.</P
></TD
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1155,9 +992,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>specifies key information for use in
authentication and authorization using TSIG.</P
@@ -1165,9 +999,6 @@ authentication and authorization using TSIG.</P
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1175,9 +1006,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>specifies what the server logs, and where
the log messages are sent.</P
@@ -1185,9 +1013,6 @@ the log messages are sent.</P
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1195,9 +1020,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>configures <B
CLASS="command"
@@ -1211,9 +1033,6 @@ CLASS="command"
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1221,9 +1040,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>defines a named masters list for
inclusion in stub and slave zone masters clauses.</P
@@ -1231,9 +1047,6 @@ inclusion in stub and slave zone masters clauses.</P
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1241,9 +1054,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>controls global server configuration
options and sets defaults for other statements.</P
@@ -1251,9 +1061,6 @@ options and sets defaults for other statements.</P
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1261,9 +1068,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>sets certain configuration options on
a per-server basis.</P
@@ -1271,9 +1075,6 @@ a per-server basis.</P
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1281,18 +1082,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>defines trusted DNSSEC keys.</P
></TD
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1300,18 +1095,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>defines a view.</P
></TD
></TR
><TR
><TD
-WIDTH="128"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1319,9 +1108,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="363"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>defines a zone.</P
></TD
@@ -1346,7 +1132,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1419"
+NAME="AEN1401"
>6.2.1. <B
CLASS="command"
>acl</B
@@ -1392,11 +1178,11 @@ CLASS="command"
>The following ACLs are built-in:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN1432"
-></A
><P
></P
+><A
+NAME="AEN1414"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -1404,9 +1190,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1414,18 +1197,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Matches all hosts.</P
></TD
></TR
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1433,18 +1210,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Matches no hosts.</P
></TD
></TR
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1452,9 +1223,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Matches the IPv4 and IPv6 addresses of all network
interfaces on the system.</P
@@ -1462,9 +1230,6 @@ interfaces on the system.</P
></TR
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -1472,9 +1237,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Matches any host on an IPv4 or IPv6 network
for which the system has an interface.
@@ -1502,7 +1264,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1463"
+NAME="AEN1445"
>6.2.3. <B
CLASS="command"
>controls</B
@@ -1517,17 +1279,13 @@ CLASS="command"
inet ( ip_addr | * ) [<SPAN
CLASS="optional"
> port ip_port </SPAN
->] allow { <TT
+>] allow { <VAR
CLASS="replaceable"
-><I
-> address_match_list </I
-></TT
+> address_match_list </VAR
> }
- keys { <TT
+ keys { <VAR
CLASS="replaceable"
-><I
-> key_list </I
-></TT
+> key_list </VAR
> };
[<SPAN
CLASS="optional"
@@ -1577,38 +1335,38 @@ CLASS="command"
CLASS="command"
>ip_addr</B
>
- of <TT
+ of <VAR
CLASS="literal"
->*</TT
+>*</VAR
> 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 <B
CLASS="command"
>ip_addr</B
-> of <TT
+> of <VAR
CLASS="literal"
->::</TT
+>::</VAR
>.
If you will only use <B
CLASS="command"
>rndc</B
> on the local host,
- using the loopback address (<TT
+ using the loopback address (<VAR
CLASS="literal"
->127.0.0.1</TT
+>127.0.0.1</VAR
>
- or <TT
+ or <VAR
CLASS="literal"
->::1</TT
+>::1</VAR
>) is recommended for maximum
security.
</P
><P
>&#13; If no port is specified, port 953
- is used. "<TT
+ is used. "<VAR
CLASS="literal"
->*</TT
+>*</VAR
>" cannot be used for
<B
CLASS="command"
@@ -1700,23 +1458,21 @@ CLASS="filename"
<TT
CLASS="filename"
>/etc</TT
-> (or whatever <TT
+> (or whatever <VAR
CLASS="varname"
->sysconfdir</TT
+>sysconfdir</VAR
>
-was specified as when <SPAN
+was specified as when <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> was built).
To create a <TT
CLASS="filename"
>rndc.key</TT
> file, run
-<TT
+<KBD
CLASS="userinput"
-><B
->rndc-confgen -a</B
-></TT
+>rndc-confgen -a</KBD
>.
</P
><P
@@ -1724,9 +1480,9 @@ CLASS="userinput"
CLASS="filename"
>rndc.key</TT
> feature was created to
- ease the transition of systems from <SPAN
+ ease the transition of systems from <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8,
which did not have digital signatures on its command channel messages
and thus did not have a <B
@@ -1734,13 +1490,13 @@ CLASS="command"
>keys</B
> clause.
-It makes it possible to use an existing <SPAN
+It makes it possible to use an existing <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8
-configuration file in <SPAN
+configuration file in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 unchanged,
and still have <B
CLASS="command"
@@ -1750,11 +1506,9 @@ CLASS="command"
CLASS="command"
>ndc</B
> worked in BIND 8, simply by executing the
-command <TT
+command <KBD
CLASS="userinput"
-><B
->rndc-confgen -a</B
-></TT
+>rndc-confgen -a</KBD
> after BIND 9 is
installed.
</P
@@ -1764,9 +1518,9 @@ CLASS="filename"
>rndc.key</TT
> feature
is only intended to allow the backward-compatible usage of
- <SPAN
+ <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -1794,18 +1548,18 @@ CLASS="filename"
> 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
+>The UNIX control channel type of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 is not supported
- in <SPAN
+ in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9, and is not expected to be added in future
releases. If it is present in the controls statement from a
- <SPAN
+ <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 configuration file, it is ignored
and a warning is logged.</P
><P
@@ -1824,7 +1578,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1542"
+NAME="AEN1524"
>6.2.5. <B
CLASS="command"
>include</B
@@ -1832,11 +1586,9 @@ CLASS="command"
></H2
><PRE
CLASS="programlisting"
->include <TT
+>include <VAR
CLASS="replaceable"
-><I
->filename</I
-></TT
+>filename</VAR
>;</PRE
></DIV
><DIV
@@ -1844,7 +1596,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1547"
+NAME="AEN1529"
>6.2.6. <B
CLASS="command"
>include</B
@@ -1873,7 +1625,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1554"
+NAME="AEN1536"
>6.2.7. <B
CLASS="command"
>key</B
@@ -1881,23 +1633,17 @@ CLASS="command"
></H2
><PRE
CLASS="programlisting"
->key <TT
+>key <VAR
CLASS="replaceable"
-><I
->key_id</I
-></TT
+>key_id</VAR
> {
- algorithm <TT
+ algorithm <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
>;
- secret <TT
+ secret <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
>;
};
</PRE
@@ -1907,7 +1653,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1561"
+NAME="AEN1543"
>6.2.8. <B
CLASS="command"
>key</B
@@ -1953,11 +1699,9 @@ HREF="Bv9ARM.ch06.html#controls_statement_definition_and_usage"
must be defined at the top level.
</P
><P
->The <TT
+>The <VAR
CLASS="replaceable"
-><I
->key_id</I
-></TT
+>key_id</VAR
>, also known as the
key name, is a domain name uniquely identifying the key. It can
be used in a <B
@@ -1969,23 +1713,19 @@ 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 <TT
+>The <VAR
CLASS="replaceable"
-><I
->algorithm_id</I
-></TT
+>algorithm_id</VAR
> is a string
that specifies a security/authentication algorithm. The only
algorithm currently supported with TSIG authentication is
-<TT
+<VAR
CLASS="literal"
->hmac-md5</TT
+>hmac-md5</VAR
>. The
-<TT
+<VAR
CLASS="replaceable"
-><I
->secret_string</I
-></TT
+>secret_string</VAR
> is the secret to be
used by the algorithm, and is treated as a base-64 encoded
string.</P
@@ -1995,7 +1735,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1581"
+NAME="AEN1563"
>6.2.9. <B
CLASS="command"
>logging</B
@@ -2010,50 +1750,40 @@ CLASS="command"
[ <B
CLASS="command"
>channel</B
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->channel_name</I
-></TT
+>channel_name</VAR
> {
( <B
CLASS="command"
>file</B
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->path name</I
-></TT
+>path name</VAR
>
[ <B
CLASS="command"
>versions</B
-> ( <TT
+> ( <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> | <TT
+>number</VAR
+> | <VAR
CLASS="literal"
->unlimited</TT
+>unlimited</VAR
> ) ]
[ <B
CLASS="command"
>size</B
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->size spec</I
-></TT
+>size spec</VAR
> ]
| <B
CLASS="command"
>syslog</B
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->syslog_facility</I
-></TT
+>syslog_facility</VAR
>
| <B
CLASS="command"
@@ -2066,84 +1796,76 @@ CLASS="command"
[ <B
CLASS="command"
>severity</B
-> (<TT
+> (<VAR
CLASS="option"
->critical</TT
-> | <TT
+>critical</VAR
+> | <VAR
CLASS="option"
->error</TT
-> | <TT
+>error</VAR
+> | <VAR
CLASS="option"
->warning</TT
-> | <TT
+>warning</VAR
+> | <VAR
CLASS="option"
->notice</TT
+>notice</VAR
> |
- <TT
+ <VAR
CLASS="option"
->info</TT
-> | <TT
+>info</VAR
+> | <VAR
CLASS="option"
->debug</TT
-> [ <TT
+>debug</VAR
+> [ <VAR
CLASS="replaceable"
-><I
->level</I
-></TT
-> ] | <TT
+>level</VAR
+> ] | <VAR
CLASS="option"
->dynamic</TT
+>dynamic</VAR
> ); ]
[ <B
CLASS="command"
>print-category</B
-> <TT
+> <VAR
CLASS="option"
->yes</TT
-> or <TT
+>yes</VAR
+> or <VAR
CLASS="option"
->no</TT
+>no</VAR
>; ]
[ <B
CLASS="command"
>print-severity</B
-> <TT
+> <VAR
CLASS="option"
->yes</TT
-> or <TT
+>yes</VAR
+> or <VAR
CLASS="option"
->no</TT
+>no</VAR
>; ]
[ <B
CLASS="command"
>print-time</B
-> <TT
+> <VAR
CLASS="option"
->yes</TT
-> or <TT
+>yes</VAR
+> or <VAR
CLASS="option"
->no</TT
+>no</VAR
>; ]
}; ]
[ <B
CLASS="command"
>category</B
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->category_name</I
-></TT
+>category_name</VAR
> {
- <TT
+ <VAR
CLASS="replaceable"
-><I
->channel_name</I
-></TT
-> ; [ <TT
+>channel_name</VAR
+> ; [ <VAR
CLASS="replaceable"
-><I
->channel_nam</I
-></TT
+>channel_nam</VAR
>e ; ... ]
}; ]
...
@@ -2155,7 +1877,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1621"
+NAME="AEN1603"
>6.2.10. <B
CLASS="command"
>logging</B
@@ -2194,13 +1916,13 @@ CLASS="programlisting"
};
</PRE
><P
->In <SPAN
+>In <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9, the logging configuration is only established when
-the entire configuration file has been parsed. In <SPAN
+the entire configuration file has been parsed. In <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8, it was
established as soon as the <B
CLASS="command"
@@ -2208,9 +1930,9 @@ CLASS="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 "<TT
+channels, or to standard error if the "<VAR
CLASS="option"
->-g</TT
+>-g</VAR
>" option
was specified.</P
><DIV
@@ -2218,7 +1940,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN1637"
+NAME="AEN1619"
>6.2.10.1. The <B
CLASS="command"
>channel</B
@@ -2520,9 +2242,9 @@ level is set either by starting the <B
CLASS="command"
>named</B
> server
-with the <TT
+with the <VAR
CLASS="option"
->-d</TT
+>-d</VAR
> flag followed by a positive integer,
or by running <B
CLASS="command"
@@ -2587,9 +2309,9 @@ CLASS="command"
> options
are on:</P
><P
-><TT
+><SAMP
CLASS="computeroutput"
->28-Feb-2000 15:05:32.863 general: notice: running</TT
+>28-Feb-2000 15:05:32.863 general: notice: running</SAMP
></P
><P
>There are four predefined channels that are used for
@@ -2645,9 +2367,9 @@ CLASS="filename"
>
in the server's working directory.</P
><P
->For security reasons, when the "<TT
+>For security reasons, when the "<VAR
CLASS="option"
->-u</TT
+>-u</VAR
>"
command line option is used, the <TT
CLASS="filename"
@@ -2662,9 +2384,9 @@ CLASS="command"
>named</B
> is
starting up and still running as root is discarded. If you need
-to capture this output, you must run the server with the "<TT
+to capture this output, you must run the server with the "<VAR
CLASS="option"
->-g</TT
+>-g</VAR
>"
option and redirect standard error to a file.</P
><P
@@ -2725,17 +2447,17 @@ category notify { null; };
><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
+categories may be added in future <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> releases.</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN1761"
-></A
><P
></P
+><A
+NAME="AEN1743"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -2743,9 +2465,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2753,9 +2472,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The default category defines the logging
options for those categories where no specific configuration has been
@@ -2764,9 +2480,6 @@ defined.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2774,9 +2487,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The catch-all. Many things still aren't
classified into categories, and they all end up here.</P
@@ -2784,9 +2494,6 @@ classified into categories, and they all end up here.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2794,9 +2501,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Messages relating to the databases used
internally by the name server to store zone and cache data.</P
@@ -2804,9 +2508,6 @@ internally by the name server to store zone and cache data.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2814,18 +2515,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Approval and denial of requests.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2833,18 +2528,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Configuration file parsing and processing.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2852,9 +2541,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>DNS resolution, such as the recursive
lookups performed on behalf of clients by a caching name server.</P
@@ -2862,9 +2548,6 @@ lookups performed on behalf of clients by a caching name server.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2872,18 +2555,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Zone transfers the server is receiving.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2891,18 +2568,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Zone transfers the server is sending.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2910,18 +2581,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The NOTIFY protocol.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2929,18 +2594,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Processing of client requests.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2948,9 +2607,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Messages that named was unable to determine the
class of or for which there was no matching <B
@@ -2970,9 +2626,6 @@ CLASS="command"
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2980,18 +2633,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Network operations.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -2999,18 +2646,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Dynamic updates.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -3018,18 +2659,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Approval and denial of update requests.</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -3037,9 +2672,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Specify where queries should be logged to.</P
>
@@ -3054,13 +2686,29 @@ CLASS="command"
> option has been
specified.
</P
-></TD
+>
+<P
+>&#13;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
+>
+<PRE
+CLASS="programlisting"
+><SAMP
+CLASS="computeroutput"
+>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</SAMP
+>
+<SAMP
+CLASS="computeroutput"
+>client ::1#62537: query: www.example.net IN AAAA -SE</SAMP
+>
+</PRE
+>
+</TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -3068,9 +2716,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Dispatching of incoming packets to the
server modules where they are to be processed.
@@ -3079,9 +2724,6 @@ server modules where they are to be processed.
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -3089,9 +2731,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>DNSSEC and TSIG protocol processing.
</P
@@ -3099,9 +2738,6 @@ VALIGN="MIDDLE"
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -3109,9 +2745,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Lame servers. These are misconfigurations
in remote servers, discovered by BIND 9 when trying to query
@@ -3121,9 +2754,6 @@ those servers during resolution.
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -3131,9 +2761,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Delegation only. Logs queries that have have
been forced to NXDOMAIN as the result of a delegation-only zone or
@@ -3156,7 +2783,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1887"
+NAME="AEN1873"
>6.2.11. <B
CLASS="command"
>lwres</B
@@ -3179,70 +2806,54 @@ CLASS="command"
> {
[<SPAN
CLASS="optional"
-> listen-on { <TT
+> listen-on { <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; ... </SPAN
>] }; </SPAN
>]
[<SPAN
CLASS="optional"
-> view <TT
+> view <VAR
CLASS="replaceable"
-><I
->view_name</I
-></TT
+>view_name</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> search { <TT
+> search { <VAR
CLASS="replaceable"
-><I
->domain_name</I
-></TT
+>domain_name</VAR
> ; [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->domain_name</I
-></TT
+>domain_name</VAR
> ; ... </SPAN
>] }; </SPAN
>]
[<SPAN
CLASS="optional"
-> ndots <TT
+> ndots <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
};
@@ -3253,7 +2864,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1911"
+NAME="AEN1897"
>6.2.12. <B
CLASS="command"
>lwres</B
@@ -3327,7 +2938,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1930"
+NAME="AEN1916"
>6.2.13. <B
CLASS="command"
>masters</B
@@ -3338,44 +2949,32 @@ CLASS="programlisting"
>&#13;<B
CLASS="command"
>masters</B
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->name</I
-></TT
+>name</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
->] { ( <TT
+>] { ( <VAR
CLASS="replaceable"
-><I
->masters_list</I
-></TT
-> | <TT
+>masters_list</VAR
+> | <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] [<SPAN
CLASS="optional"
->key <TT
+>key <VAR
CLASS="replaceable"
-><I
->key</I
-></TT
+>key</VAR
></SPAN
>] ) ; [<SPAN
CLASS="optional"
@@ -3388,7 +2987,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1945"
+NAME="AEN1931"
>6.2.14. <B
CLASS="command"
>masters</B
@@ -3406,7 +3005,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN1950"
+NAME="AEN1936"
>6.2.15. <B
CLASS="command"
>options</B
@@ -3426,336 +3025,261 @@ CLASS="programlisting"
>options {
[<SPAN
CLASS="optional"
-> version <TT
+> version <VAR
CLASS="replaceable"
-><I
->version_string</I
-></TT
+>version_string</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> hostname <TT
+> hostname <VAR
CLASS="replaceable"
-><I
->hostname_string</I
-></TT
+>hostname_string</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> server-id <TT
+> server-id <VAR
CLASS="replaceable"
-><I
->server_id_string</I
-></TT
+>server_id_string</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> directory <TT
+> directory <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> key-directory <TT
+> key-directory <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> named-xfer <TT
+> named-xfer <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> tkey-domain <TT
+> tkey-domain <VAR
CLASS="replaceable"
-><I
->domainname</I
-></TT
+>domainname</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> tkey-dhkey <TT
+> tkey-dhkey <VAR
CLASS="replaceable"
-><I
->key_name</I
-></TT
-> <TT
+>key_name</VAR
+> <VAR
CLASS="replaceable"
-><I
->key_tag</I
-></TT
+>key_tag</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> dump-file <TT
+> dump-file <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> memstatistics-file <TT
+> memstatistics-file <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> pid-file <TT
+> pid-file <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> statistics-file <TT
+> statistics-file <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> zone-statistics <TT
+> zone-statistics <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> auth-nxdomain <TT
+> auth-nxdomain <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> deallocate-on-exit <TT
+> deallocate-on-exit <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> dialup <TT
+> dialup <VAR
CLASS="replaceable"
-><I
->dialup_option</I
-></TT
+>dialup_option</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> fake-iquery <TT
+> fake-iquery <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> fetch-glue <TT
+> fetch-glue <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> flush-zones-on-shutdown <TT
+> flush-zones-on-shutdown <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> has-old-clients <TT
+> has-old-clients <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> host-statistics <TT
+> host-statistics <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> minimal-responses <TT
+> minimal-responses <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> multiple-cnames <TT
+> multiple-cnames <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> notify <TT
+> notify <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
-> | <TT
+>yes_or_no</VAR
+> | <VAR
CLASS="replaceable"
-><I
->explicit</I
-></TT
+>explicit</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> recursion <TT
+> recursion <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> rfc2308-type1 <TT
+> rfc2308-type1 <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> use-id-pool <TT
+> use-id-pool <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> maintain-ixfr-base <TT
+> maintain-ixfr-base <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> dnssec-enable <TT
+> dnssec-enable <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> dnssec-lookaside <TT
+> dnssec-lookaside <VAR
CLASS="replaceable"
-><I
->domain</I
-></TT
+>domain</VAR
+> trust-anchor <VAR
+CLASS="replaceable"
+>domain</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> dnssec-must-be-secure <TT
+> dnssec-must-be-secure <VAR
CLASS="replaceable"
-><I
->domain yes_or_no</I
-></TT
+>domain yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> forward ( <TT
+> forward ( <VAR
CLASS="replaceable"
-><I
->only</I
-></TT
-> | <TT
+>only</VAR
+> | <VAR
CLASS="replaceable"
-><I
->first</I
-></TT
+>first</VAR
> ); </SPAN
>]
[<SPAN
CLASS="optional"
-> forwarders { <TT
+> forwarders { <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; ... </SPAN
>] }; </SPAN
@@ -3764,216 +3288,160 @@ CLASS="replaceable"
CLASS="optional"
> dual-stack-servers [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
->] { ( <TT
+>] { ( <VAR
CLASS="replaceable"
-><I
->domain_name</I
-></TT
+>domain_name</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
->] | <TT
+>] | <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ) ; ... }; </SPAN
>]
[<SPAN
CLASS="optional"
-> check-names ( <TT
+> check-names ( <VAR
CLASS="replaceable"
-><I
->master</I
-></TT
-> | <TT
+>master</VAR
+> | <VAR
CLASS="replaceable"
-><I
->slave</I
-></TT
-> | <TT
+>slave</VAR
+> | <VAR
CLASS="replaceable"
-><I
-> response</I
-></TT
-> )( <TT
+> response</VAR
+> )( <VAR
CLASS="replaceable"
-><I
->warn</I
-></TT
-> | <TT
+>warn</VAR
+> | <VAR
CLASS="replaceable"
-><I
->fail</I
-></TT
-> | <TT
+>fail</VAR
+> | <VAR
CLASS="replaceable"
-><I
->ignore</I
-></TT
+>ignore</VAR
> ); </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-notify { <TT
+> allow-notify { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-query { <TT
+> allow-query { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-transfer { <TT
+> allow-transfer { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-recursion { <TT
+> allow-recursion { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-update-forwarding { <TT
+> allow-update-forwarding { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-v6-synthesis { <TT
+> allow-v6-synthesis { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
-> blackhole { <TT
+> blackhole { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
-> avoid-v4-udp-ports { <TT
+> avoid-v4-udp-ports { <VAR
CLASS="replaceable"
-><I
->port_list</I
-></TT
+>port_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
-> avoid-v6-udp-ports { <TT
+> avoid-v6-udp-ports { <VAR
CLASS="replaceable"
-><I
->port_list</I
-></TT
+>port_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
> listen-on [<SPAN
CLASS="optional"
-> port <TT
+> port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
> </SPAN
->] { <TT
+>] { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
> listen-on-v6 [<SPAN
CLASS="optional"
-> port <TT
+> port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
> </SPAN
->] { <TT
+>] { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }; </SPAN
>]
[<SPAN
CLASS="optional"
> query-source [<SPAN
CLASS="optional"
-> address ( <TT
+> address ( <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
-> | <TT
+>ip_addr</VAR
+> | <VAR
CLASS="replaceable"
-><I
->*</I
-></TT
+>*</VAR
> ) </SPAN
>] [<SPAN
CLASS="optional"
-> port ( <TT
+> port ( <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
-> | <TT
+>ip_port</VAR
+> | <VAR
CLASS="replaceable"
-><I
->*</I
-></TT
+>*</VAR
> ) </SPAN
>]; </SPAN
>]
@@ -3981,676 +3449,524 @@ CLASS="replaceable"
CLASS="optional"
> query-source-v6 [<SPAN
CLASS="optional"
-> address ( <TT
+> address ( <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
-> | <TT
+>ip_addr</VAR
+> | <VAR
CLASS="replaceable"
-><I
->*</I
-></TT
+>*</VAR
> ) </SPAN
>] [<SPAN
CLASS="optional"
-> port ( <TT
+> port ( <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
-> | <TT
+>ip_port</VAR
+> | <VAR
CLASS="replaceable"
-><I
->*</I
-></TT
+>*</VAR
> ) </SPAN
>]; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-transfer-time-in <TT
+> max-transfer-time-in <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-transfer-time-out <TT
+> max-transfer-time-out <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-transfer-idle-in <TT
+> max-transfer-idle-in <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-transfer-idle-out <TT
+> max-transfer-idle-out <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> tcp-clients <TT
+> tcp-clients <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> recursive-clients <TT
+> recursive-clients <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> serial-query-rate <TT
+> serial-query-rate <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> serial-queries <TT
+> serial-queries <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> tcp-listen-queue <TT
+> tcp-listen-queue <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfer-format <TT
+> transfer-format <VAR
CLASS="replaceable"
-><I
->( one-answer | many-answers )</I
-></TT
+>( one-answer | many-answers )</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfers-in <TT
+> transfers-in <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfers-out <TT
+> transfers-out <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfers-per-ns <TT
+> transfers-per-ns <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfer-source (<TT
+> transfer-source (<VAR
CLASS="replaceable"
-><I
->ip4_addr</I
-></TT
-> | <TT
+>ip4_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfer-source-v6 (<TT
+> transfer-source-v6 (<VAR
CLASS="replaceable"
-><I
->ip6_addr</I
-></TT
-> | <TT
+>ip6_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> alt-transfer-source (<TT
+> alt-transfer-source (<VAR
CLASS="replaceable"
-><I
->ip4_addr</I
-></TT
-> | <TT
+>ip4_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> alt-transfer-source-v6 (<TT
+> alt-transfer-source-v6 (<VAR
CLASS="replaceable"
-><I
->ip6_addr</I
-></TT
-> | <TT
+>ip6_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> use-alt-transfer-source <TT
+> use-alt-transfer-source <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> notify-source (<TT
+> notify-source (<VAR
CLASS="replaceable"
-><I
->ip4_addr</I
-></TT
-> | <TT
+>ip4_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> notify-source-v6 (<TT
+> notify-source-v6 (<VAR
CLASS="replaceable"
-><I
->ip6_addr</I
-></TT
-> | <TT
+>ip6_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> also-notify { <TT
+> also-notify { <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; ... </SPAN
>] }; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-ixfr-log-size <TT
+> max-ixfr-log-size <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-journal-size <TT
+> max-journal-size <VAR
CLASS="replaceable"
-><I
->size_spec</I
-></TT
+>size_spec</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> coresize <TT
+> coresize <VAR
CLASS="replaceable"
-><I
->size_spec</I
-></TT
+>size_spec</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> datasize <TT
+> datasize <VAR
CLASS="replaceable"
-><I
->size_spec</I
-></TT
+>size_spec</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> files <TT
+> files <VAR
CLASS="replaceable"
-><I
->size_spec</I
-></TT
+>size_spec</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> stacksize <TT
+> stacksize <VAR
CLASS="replaceable"
-><I
->size_spec</I
-></TT
+>size_spec</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> cleaning-interval <TT
+> cleaning-interval <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> heartbeat-interval <TT
+> heartbeat-interval <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> interface-interval <TT
+> interface-interval <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> statistics-interval <TT
+> statistics-interval <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> topology { <TT
+> topology { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }</SPAN
>];
[<SPAN
CLASS="optional"
-> sortlist { <TT
+> sortlist { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> }</SPAN
>];
[<SPAN
CLASS="optional"
-> rrset-order { <TT
+> rrset-order { <VAR
CLASS="replaceable"
-><I
->order_spec</I
-></TT
+>order_spec</VAR
> ; [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->order_spec</I
-></TT
+>order_spec</VAR
> ; ... </SPAN
>] </SPAN
>] };
[<SPAN
CLASS="optional"
-> lame-ttl <TT
+> lame-ttl <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-ncache-ttl <TT
+> max-ncache-ttl <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-cache-ttl <TT
+> max-cache-ttl <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> sig-validity-interval <TT
+> sig-validity-interval <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> min-roots <TT
+> min-roots <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> use-ixfr <TT
+> use-ixfr <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> provide-ixfr <TT
+> provide-ixfr <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> request-ixfr <TT
+> request-ixfr <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> treat-cr-as-space <TT
+> treat-cr-as-space <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> min-refresh-time <TT
+> min-refresh-time <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-refresh-time <TT
+> max-refresh-time <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> min-retry-time <TT
+> min-retry-time <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-retry-time <TT
+> max-retry-time <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> port <TT
+> port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> additional-from-auth <TT
+> additional-from-auth <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> additional-from-cache <TT
+> additional-from-cache <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> random-device <TT
+> random-device <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-cache-size <TT
+> max-cache-size <VAR
CLASS="replaceable"
-><I
->size_spec</I
-></TT
+>size_spec</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> match-mapped-addresses <TT
+> match-mapped-addresses <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> preferred-glue ( <TT
+> preferred-glue ( <VAR
CLASS="replaceable"
-><I
->A</I
-></TT
-> | <TT
+>A</VAR
+> | <VAR
CLASS="replaceable"
-><I
->AAAA</I
-></TT
-> | <TT
+>AAAA</VAR
+> | <VAR
CLASS="replaceable"
-><I
->NONE</I
-></TT
+>NONE</VAR
> ); </SPAN
>]
[<SPAN
CLASS="optional"
-> edns-udp-size <TT
+> edns-udp-size <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
> root-delegation-only [<SPAN
CLASS="optional"
-> exclude { <TT
+> exclude { <VAR
CLASS="replaceable"
-><I
->namelist</I
-></TT
+>namelist</VAR
> } </SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> querylog <TT
+> querylog <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
};
[<SPAN
CLASS="optional"
-> disable-algorithms <TT
+> disable-algorithms <VAR
CLASS="replaceable"
-><I
->domain</I
-></TT
-> { <TT
+>domain</VAR
+> { <VAR
CLASS="replaceable"
-><I
->algorithm</I
-></TT
+>algorithm</VAR
>; [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->algorithm</I
-></TT
+>algorithm</VAR
>; </SPAN
>] }; </SPAN
>]
@@ -4672,9 +3988,9 @@ CLASS="command"
CLASS="command"
>options</B
> statement sets up global options
-to be used by <SPAN
+to be used by <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>. This statement may appear only
once in a configuration file. If there is no <B
CLASS="command"
@@ -4734,17 +4050,17 @@ CLASS="emphasis"
>This option is obsolete.</I
></SPAN
>
-It was used in <SPAN
+It was used in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 to
specify the pathname to the <B
CLASS="command"
>named-xfer</B
> program.
-In <SPAN
+In <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9, no separate <B
CLASS="command"
>named-xfer</B
@@ -4768,21 +4084,21 @@ CLASS="command"
>TKEY</B
> exchange, it may or may not specify
the desired name for the key. If present, the name of the shared
-key will be "<TT
+key will be "<VAR
CLASS="varname"
->client specified part</TT
+>client specified part</VAR
>" +
-"<TT
+"<VAR
CLASS="varname"
->tkey-domain</TT
+>tkey-domain</VAR
>".
-Otherwise, the name of the shared key will be "<TT
+Otherwise, the name of the shared key will be "<VAR
CLASS="varname"
>random hex
-digits</TT
->" + "<TT
+digits</VAR
+>" + "<VAR
CLASS="varname"
->tkey-domain</TT
+>tkey-domain</VAR
>". In most cases,
the <B
CLASS="command"
@@ -4982,13 +4298,15 @@ CLASS="command"
>dnssec-lookaside</B
> provides the
validator with an alternate method to validate DNSKEY records at the
-top of a zone. When set the domain specified by
-<B
+top of a zone. When a DNSKEY is at or below a domain specified by the
+deepest <B
CLASS="command"
>dnssec-lookaside</B
-> is appended to DNSKEY's
-name and a DLV record is looked up. If the DLV record validates
-a DNSKEY (similarly to the way a DS record does) the DNSKEY RRset is deemed to be trusted.
+>, 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
@@ -4999,18 +4317,14 @@ CLASS="command"
><DD
><P
>&#13;Specify heirachies which must / may not be secure (signed and validated).
-If <TT
+If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
> then named will only accept answers if they
are secure.
-If <TT
+If <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
> then normal dnssec validation applies
allowing for insecure answers to be accepted.
The specified domain must be under a <B
@@ -5045,31 +4359,25 @@ CLASS="command"
></DT
><DD
><P
->If <TT
+>If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>, then the <B
CLASS="command"
>AA</B
> bit
is always set on NXDOMAIN responses, even if the server is not actually
-authoritative. The default is <TT
+authoritative. The default is <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>; this is
-a change from <SPAN
+a change from <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8. If you are using very old DNS software, you
-may need to set it to <TT
+may need to set it to <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>.</P
></DD
><DT
@@ -5079,13 +4387,13 @@ CLASS="command"
></DT
><DD
><P
->This option was used in <SPAN
+>This option was used in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 to enable checking
-for memory leaks on exit. <SPAN
+for memory leaks on exit. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 ignores the option and always performs
the checks.</P
></DD
@@ -5096,11 +4404,9 @@ CLASS="command"
></DT
><DD
><P
->If <TT
+>If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>, 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
@@ -5111,11 +4417,9 @@ CLASS="command"
>heartbeat-interval</B
> and
hopefully during the one call. It also suppresses some of the normal
-zone maintenance traffic. The default is <TT
+zone maintenance traffic. The default is <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>.</P
><P
>The <B
@@ -5159,43 +4463,35 @@ CLASS="command"
NOTIFY requests.</P
><P
>Finer control can be achieved by using
-<TT
+<KBD
CLASS="userinput"
-><B
->notify</B
-></TT
+>notify</KBD
> which only sends NOTIFY messages,
-<TT
+<KBD
CLASS="userinput"
-><B
->notify-passive</B
-></TT
+>notify-passive</KBD
> which sends NOTIFY messages and
-suppresses the normal refresh queries, <TT
+suppresses the normal refresh queries, <KBD
CLASS="userinput"
-><B
->refresh</B
-></TT
+>refresh</KBD
>
which suppresses normal refresh processing and sends refresh queries
when the <B
CLASS="command"
>heartbeat-interval</B
> expires, and
-<TT
+<KBD
CLASS="userinput"
-><B
->passive</B
-></TT
+>passive</KBD
> which just disables normal refresh
processing.</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN2403"
-></A
><P
></P
+><A
+NAME="AEN2390"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -5203,39 +4499,24 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>dialup mode</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>normal refresh</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>heart-beat refresh</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>heart-beat notify</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -5243,32 +4524,20 @@ CLASS="command"
> (default)</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>yes</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -5276,32 +4545,20 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>yes</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>yes</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -5309,32 +4566,20 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>yes</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>yes</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -5342,32 +4587,20 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>yes</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -5375,32 +4608,20 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -5408,23 +4629,14 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>no</P
></TD
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>yes</P
></TD
@@ -5448,14 +4660,14 @@ CLASS="command"
></DT
><DD
><P
->In <SPAN
+>In <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8, this option
enabled simulating the obsolete DNS query type
-IQUERY. <SPAN
+IQUERY. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 never does IQUERY simulation.
</P
></DD
@@ -5467,11 +4679,9 @@ CLASS="command"
><DD
><P
>This option is obsolete.
-In BIND 8, <TT
+In BIND 8, <KBD
CLASS="userinput"
-><B
->fetch-glue yes</B
-></TT
+>fetch-glue yes</KBD
>
caused the server to attempt to fetch glue resource records it
didn't have when constructing the additional
@@ -5490,11 +4700,9 @@ flush / do not flush any pending zone writes. The default is
<B
CLASS="command"
>flush-zones-on-shutdown</B
-> <TT
+> <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>.
</P
></DD
@@ -5506,41 +4714,35 @@ CLASS="command"
><DD
><P
>This option was incorrectly implemented
-in <SPAN
+in <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> 8, and is ignored by <SPAN
+>BIND</ACRONYM
+> 8, and is ignored by <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9.
To achieve the intended effect
of
<B
CLASS="command"
>has-old-clients</B
-> <TT
+> <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>, specify
the two separate options <B
CLASS="command"
>auth-nxdomain</B
-> <TT
+> <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>
and <B
CLASS="command"
>rfc2308-type1</B
-> <TT
+> <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
> instead.
</P
></DD
@@ -5570,23 +4772,21 @@ CLASS="emphasis"
>This option is obsolete</I
></SPAN
>.
- It was used in <SPAN
+ It was used in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 to determine whether a transaction log was
-kept for Incremental Zone Transfer. <SPAN
+kept for Incremental Zone Transfer. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 maintains a transaction
log whenever possible. If you need to disable outgoing incremental zone
transfers, use <B
CLASS="command"
>provide-ixfr</B
-> <TT
+> <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>.
</P
></DD
@@ -5597,20 +4797,16 @@ CLASS="command"
></DT
><DD
><P
->If <TT
+>If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>, 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 <TT
+The default is <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>.
</P
></DD
@@ -5621,14 +4817,14 @@ CLASS="command"
></DT
><DD
><P
->This option was used in <SPAN
+>This option was used in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 to allow
a domain name to have multiple CNAME records in violation of the
-DNS standards. <SPAN
+DNS standards. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9.2 always strictly
enforces the CNAME rules both in master files and dynamic updates.
</P
@@ -5640,11 +4836,9 @@ CLASS="command"
></DT
><DD
><P
->If <TT
+>If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
> (the default),
DNS NOTIFY messages are sent when a zone the server is authoritative for
changes, see <A
@@ -5659,21 +4853,17 @@ CLASS="command"
> option.
</P
><P
->&#13;If <TT
+>&#13;If <KBD
CLASS="userinput"
-><B
->explicit</B
-></TT
+>explicit</KBD
>, notifies are sent only to
servers explicitly listed using <B
CLASS="command"
>also-notify</B
>.
-If <TT
+If <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>, no notifies are sent.
</P
><P
@@ -5699,20 +4889,16 @@ CLASS="command"
></DT
><DD
><P
->If <TT
+>If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>, 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 <TT
+referral response. The default is <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>.
Note that setting <B
CLASS="command"
@@ -5735,18 +4921,14 @@ CLASS="command"
></DT
><DD
><P
->Setting this to <TT
+>Setting this to <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
> will
cause the server to send NS records along with the SOA record for negative
-answers. The default is <TT
+answers. The default is <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>.</P
><DIV
CLASS="note"
@@ -5755,9 +4937,9 @@ CLASS="note"
><P
><B
>Note: </B
->Not yet implemented in <SPAN
+>Not yet implemented in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9.</P
></BLOCKQUOTE
></DIV
@@ -5776,9 +4958,9 @@ CLASS="emphasis"
>This option is obsolete</I
></SPAN
>.
-<SPAN
+<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 always allocates query IDs from a pool.
</P
></DD
@@ -5789,11 +4971,9 @@ CLASS="command"
></DT
><DD
><P
->If <TT
+>If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>, the server will collect
statistical data on all zones (unless specifically turned off
on a per-zone basis by specifying <B
@@ -5889,9 +5069,9 @@ CLASS="command"
></DT
><DD
><P
->This option was used in <SPAN
+>This option was used in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 to make
the server treat carriage return ("<B
CLASS="command"
@@ -5899,9 +5079,9 @@ CLASS="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 <SPAN
+on an NT or DOS machine. In <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9, both UNIX "<B
CLASS="command"
>\n</B
@@ -5927,11 +5107,9 @@ answering queries which have additional data, or when following CNAME
and DNAME chains.
</P
><P
->&#13;When both of these options are set to <TT
+>&#13;When both of these options are set to <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>
(the default) and a
query is being answered from authoritative data (a zone
@@ -5946,17 +5124,17 @@ at the possible expense of additional queries to resolve what would
otherwise be provided in the additional section.
</P
><P
->&#13;For example, if a query asks for an MX record for host <TT
+>&#13;For example, if a query asks for an MX record for host <VAR
CLASS="literal"
->foo.example.com</TT
+>foo.example.com</VAR
>,
-and the record found is "<TT
+and the record found is "<VAR
CLASS="literal"
->MX 10 mail.example.net</TT
+>MX 10 mail.example.net</VAR
>", normally the address
-records (A and AAAA) for <TT
+records (A and AAAA) for <VAR
CLASS="literal"
->mail.example.net</TT
+>mail.example.net</VAR
> will be provided as well,
if known, even though they are not in the example.com zone.
Setting these options to <B
@@ -6010,11 +5188,9 @@ CLASS="command"
></DT
><DD
><P
->If <TT
+>If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>, then an
IPv4-mapped IPv6 address will match any address match
list entries that match the corresponding IPv4 address.
@@ -6063,11 +5239,9 @@ CLASS="command"
>&#13;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 <TT
+has. The default is <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>.
</P
></DD
@@ -6078,18 +5252,14 @@ CLASS="command"
></DT
><DD
><P
->&#13;Enable DNSSEC support in named. Unless set to <TT
+>&#13;Enable DNSSEC support in named. Unless set to <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>
named behaves as if it does not support DNSSEC.
-The default is <TT
+The default is <KBD
CLASS="userinput"
-><B
->no</B
-></TT
+>no</KBD
>.
</P
></DD
@@ -6119,7 +5289,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN2682"
+NAME="AEN2669"
>6.2.16.2. Forwarding</A
></H3
><P
@@ -6143,15 +5313,15 @@ CLASS="command"
><DD
><P
>This option is only meaningful if the
-forwarders list is not empty. A value of <TT
+forwarders list is not empty. A value of <VAR
CLASS="varname"
->first</TT
+>first</VAR
>,
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 <TT
+the answer itself. If <VAR
CLASS="varname"
->only</TT
+>only</VAR
> is specified, the
server will only query the forwarders.
</P
@@ -6187,11 +5357,11 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN2701"
->6.2.16.3. 6 to 4 Servers</A
+NAME="AEN2688"
+>6.2.16.3. Dual-stack Servers</A
></H3
><P
->6 to 4 servers are used as servers of last resort to work around
+>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
><P
@@ -6312,31 +5482,23 @@ CLASS="command"
><P
>Specifies which hosts are allowed to
submit Dynamic DNS updates to slave zones to be forwarded to the
-master. The default is <TT
+master. The default is <KBD
CLASS="userinput"
-><B
->{ none; }</B
-></TT
+>{ none; }</KBD
>, which
means that no update forwarding will be performed. To enable
update forwarding, specify
-<TT
+<KBD
CLASS="userinput"
-><B
->allow-update-forwarding { any; };</B
-></TT
+>allow-update-forwarding { any; };</KBD
>.
-Specifying values other than <TT
+Specifying values other than <KBD
CLASS="userinput"
-><B
->{ none; }</B
-></TT
+>{ none; }</KBD
> or
-<TT
+<KBD
CLASS="userinput"
-><B
->{ any; }</B
-></TT
+>{ any; }</KBD
> is usually counterproductive, since
the responsibility for update access control should rest with the
master server, not the slaves.</P
@@ -6394,11 +5556,9 @@ CLASS="command"
><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 <TT
+from these addresses will not be responded to. The default is <KBD
CLASS="userinput"
-><B
->none</B
-></TT
+>none</KBD
>.</P
></DD
></DL
@@ -6409,7 +5569,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN2768"
+NAME="AEN2755"
>6.2.16.5. Interfaces</A
></H3
><P
@@ -6421,9 +5581,9 @@ CLASS="command"
CLASS="command"
>listen-on</B
> takes
-an optional port, and an <TT
+an optional port, and an <VAR
CLASS="varname"
->address_match_list</TT
+>address_match_list</VAR
>.
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
@@ -6449,11 +5609,35 @@ CLASS="command"
> is specified, the
server will listen on port 53 on all interfaces.</P
><P
->By default, the server does not bind a separate socket to each
-IPv6 interface address as it does for IPv4. Instead, it listens on the
-IPv6 wildcard address.
-Alternatively, a list of IPv6 addresses can be specified, in which case
-the server listens on a separate socket for each specified address.</P
+>The <B
+CLASS="command"
+>listen-on-v6</B
+> 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 <PRE
+CLASS="programlisting"
+>{ any; }</PRE
+> is specified
+as the <VAR
+CLASS="varname"
+>address_match_list</VAR
+> for the
+<B
+CLASS="command"
+>listen-on-v6</B
+> 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 <B
CLASS="command"
@@ -6463,13 +5647,13 @@ For example,</P
><PRE
CLASS="programlisting"
>listen-on-v6 { any; };
-listen-on-v6 port 1234 { !3ffe::/16; 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
-3ffe::/16 (with separate sockets for each matched address.)</P
+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
@@ -6480,7 +5664,7 @@ CLASS="programlisting"
>If no <B
CLASS="command"
>listen-on-v6</B
-> statement is specified,
+> option is specified,
the server will not listen on any IPv6 address.</P
></DIV
><DIV
@@ -6488,7 +5672,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN2789"
+NAME="AEN2782"
>6.2.16.6. Query Address</A
></H3
><P
@@ -6502,7 +5686,7 @@ IPv6, there is a separate <B
CLASS="command"
>query-source-v6</B
> option.
- If <B
+If <B
CLASS="command"
>address</B
> is <B
@@ -6550,6 +5734,23 @@ UDP queries. TCP queries always use a random
unprivileged port.</P
></BLOCKQUOTE
></DIV
+><DIV
+CLASS="note"
+><BLOCKQUOTE
+CLASS="note"
+><P
+><B
+>Note: </B
+>See also <B
+CLASS="command"
+>transfer-source</B
+> and
+<B
+CLASS="command"
+>notify-source</B
+>.</P
+></BLOCKQUOTE
+></DIV
></DIV
><DIV
CLASS="sect3"
@@ -6560,9 +5761,9 @@ NAME="zone_transfers"
>6.2.16.7. Zone Transfers</A
></H3
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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.</P
@@ -6729,16 +5930,16 @@ CLASS="command"
>many-answers</B
> is more
efficient, but is only supported by relatively new slave servers,
-such as <SPAN
+such as <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> 9, <SPAN
+>BIND</ACRONYM
+> 9, <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8.x and patched
-versions of <SPAN
+versions of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 4.9.5. The default is
<B
CLASS="command"
@@ -6762,9 +5963,9 @@ CLASS="command"
><DD
><P
>The maximum number of inbound zone transfers
-that can be running concurrently. The default value is <TT
+that can be running concurrently. The default value is <VAR
CLASS="literal"
->10</TT
+>10</VAR
>.
Increasing <B
CLASS="command"
@@ -6781,9 +5982,9 @@ CLASS="command"
><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 <TT
+of the limit will be refused. The default value is <VAR
CLASS="literal"
->10</TT
+>10</VAR
>.</P
></DD
><DT
@@ -6795,9 +5996,9 @@ CLASS="command"
><P
>The maximum number of inbound zone transfers
that can be concurrently transferring from a given remote name server.
-The default value is <TT
+The default value is <VAR
CLASS="literal"
->2</TT
+>2</VAR
>. Increasing <B
CLASS="command"
>transfers-per-ns</B
@@ -6979,7 +6180,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN2951"
+NAME="AEN2948"
>6.2.16.8. Bad UDP Port Lists</A
></H3
><P
@@ -7003,7 +6204,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN2956"
+NAME="AEN2953"
>6.2.16.9. Operating System Resource Limits</A
></H3
><P
@@ -7051,9 +6252,9 @@ CLASS="command"
><DD
><P
>The maximum size of a core dump. The default
-is <TT
+is <VAR
CLASS="literal"
->default</TT
+>default</VAR
>.</P
></DD
><DT
@@ -7064,9 +6265,9 @@ CLASS="command"
><DD
><P
>The maximum amount of data memory the server
-may use. The default is <TT
+may use. The default is <VAR
CLASS="literal"
->default</TT
+>default</VAR
>.
This is a hard limit on server memory usage.
If the server attempts to allocate memory in excess of this
@@ -7096,9 +6297,9 @@ CLASS="command"
><DD
><P
>The maximum number of files the server
-may have open concurrently. The default is <TT
+may have open concurrently. The default is <VAR
CLASS="literal"
->unlimited</TT
+>unlimited</VAR
>.
</P
></DD
@@ -7110,9 +6311,9 @@ CLASS="command"
><DD
><P
>The maximum amount of stack memory the server
-may use. The default is <TT
+may use. The default is <VAR
CLASS="literal"
->default</TT
+>default</VAR
>.</P
></DD
></DL
@@ -7123,7 +6324,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN2993"
+NAME="AEN2990"
>6.2.16.10. Server Resource Limits</A
></H3
><P
@@ -7165,9 +6366,9 @@ HREF="Bv9ARM.ch04.html#journal"
>). When the journal file approaches
the specified size, some of the oldest transactions in the journal
will be automatically removed. The default is
-<TT
+<VAR
CLASS="literal"
->unlimited</TT
+>unlimited</VAR
>.</P
></DD
><DT
@@ -7179,9 +6380,9 @@ CLASS="command"
><P
>The maximum number of simultaneous recursive lookups
the server will perform on behalf of clients. The default is
-<TT
+<VAR
CLASS="literal"
->1000</TT
+>1000</VAR
>. Because each recursing client uses a fair
bit of memory, on the order of 20 kilobytes, the value of the
<B
@@ -7200,9 +6401,9 @@ CLASS="command"
><P
>The maximum number of simultaneous client TCP
connections that the server will accept.
-The default is <TT
+The default is <VAR
CLASS="literal"
->100</TT
+>100</VAR
>.</P
></DD
><DT
@@ -7217,9 +6418,9 @@ 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 <TT
+view. The default is <VAR
CLASS="literal"
->unlimited</TT
+>unlimited</VAR
>, meaning that
records are purged from the cache only when their TTLs expire.
</P
@@ -7246,7 +6447,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN3034"
+NAME="AEN3031"
>6.2.16.11. Periodic Task Intervals</A
></H3
><P
@@ -7329,9 +6530,9 @@ CLASS="note"
><P
><B
>Note: </B
->Not yet implemented in <SPAN
+>Not yet implemented in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>9.</P
></BLOCKQUOTE
></DIV
@@ -7395,9 +6596,9 @@ CLASS="note"
CLASS="command"
>topology</B
> option
-is not implemented in <SPAN
+is not implemented in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9.
</P
></BLOCKQUOTE
@@ -7516,9 +6717,9 @@ CLASS="programlisting"
><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
+to the behavior of the address sort in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -7566,34 +6767,26 @@ CLASS="command"
CLASS="programlisting"
>[<SPAN
CLASS="optional"
-> class <TT
+> class <VAR
CLASS="replaceable"
-><I
->class_name</I
-></TT
+>class_name</VAR
> </SPAN
>][<SPAN
CLASS="optional"
-> type <TT
+> type <VAR
CLASS="replaceable"
-><I
->type_name</I
-></TT
+>type_name</VAR
> </SPAN
>][<SPAN
CLASS="optional"
-> name <TT
+> name <VAR
CLASS="replaceable"
-><I
->"domain_name"</I
-></TT
+>"domain_name"</VAR
></SPAN
>]
- order <TT
+ order <VAR
CLASS="replaceable"
-><I
->ordering</I
-></TT
+>ordering</VAR
>
</PRE
><P
@@ -7616,11 +6809,11 @@ CLASS="command"
> are:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN3122"
-></A
><P
></P
+><A
+NAME="AEN3119"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -7628,9 +6821,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -7638,9 +6828,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="360"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Records are returned in the order they
are defined in the zone file.</P
@@ -7648,9 +6835,6 @@ are defined in the zone file.</P
></TR
><TR
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -7658,18 +6842,12 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="360"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Records are returned in some random order.</P
></TD
></TR
><TR
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -7677,9 +6855,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="360"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Records are returned in a round-robin
order.</P
@@ -7701,9 +6876,9 @@ CLASS="programlisting"
</PRE
><P
>will cause any responses for type A records in class IN that
-have "<TT
+have "<VAR
CLASS="literal"
->host.example.com</TT
+>host.example.com</VAR
>" as a suffix, to always be returned
in random order. All other records are returned in cyclic order.</P
><P
@@ -7723,9 +6898,9 @@ CLASS="note"
CLASS="command"
>rrset-order</B
> statement
-is not yet fully implemented in <SPAN
+is not yet fully implemented in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9.
BIND 9 currently does not support "fixed" ordering.
</P
@@ -7761,13 +6936,13 @@ CLASS="emphasis"
>NOT</B
></SPAN
> recommended.)
-Default is <TT
+Default is <VAR
CLASS="literal"
->600</TT
+>600</VAR
> (10 minutes). Maximum value is
-<TT
+<VAR
CLASS="literal"
->1800</TT
+>1800</VAR
> (30 minutes).</P
></DD
><DT
@@ -7787,9 +6962,9 @@ in seconds. The default
<B
CLASS="command"
>max-ncache-ttl</B
-> is <TT
+> is <VAR
CLASS="literal"
->10800</TT
+>10800</VAR
> seconds (3 hours).
<B
CLASS="command"
@@ -7820,11 +6995,9 @@ CLASS="command"
><P
>The minimum number of root servers that
is required for a request for the root servers to be accepted. Default
-is <TT
+is <KBD
CLASS="userinput"
-><B
->2</B
-></TT
+>2</KBD
>.</P
><DIV
CLASS="note"
@@ -7833,9 +7006,9 @@ CLASS="note"
><P
><B
>Note: </B
->Not implemented in <SPAN
+>Not implemented in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>9.</P
></BLOCKQUOTE
></DIV
@@ -7853,9 +7026,9 @@ of dynamic updates (<A
HREF="Bv9ARM.ch04.html#dynamic_update"
>Section 4.2</A
>)
-will expire. The default is <TT
+will expire. The default is <VAR
CLASS="literal"
->30</TT
+>30</VAR
> days.
The maximum value is 10 years (3660 days). The signature
inception time is unconditionally set to one hour before the current time
@@ -7922,9 +7095,9 @@ NAME="builtin"
><P
>The server provides some helpful diagnostic information
through a number of built-in zones under the
-pseudo-top-level-domain <TT
+pseudo-top-level-domain <VAR
CLASS="literal"
->bind</TT
+>bind</VAR
> in the
<B
CLASS="command"
@@ -7969,9 +7142,9 @@ CLASS="command"
><DD
><P
>The version the server should report
-via a query of the name <TT
+via a query of the name <VAR
CLASS="literal"
->version.bind</TT
+>version.bind</VAR
>
with type <B
CLASS="command"
@@ -8067,14 +7240,14 @@ NAME="statsfile"
>6.2.16.17. The Statistics File</A
></H3
><P
->The statistics file generated by <SPAN
+>The statistics file generated by <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9
is similar, but not identical, to that
-generated by <SPAN
+generated by <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8.
</P
><P
@@ -8098,11 +7271,11 @@ number is identical to the number in the beginning line.</P
>The following statistics counters are maintained:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN3266"
-></A
><P
></P
+><A
+NAME="AEN3263"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -8110,9 +7283,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -8120,9 +7290,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The number of
successful queries made to the server or zone. A successful query
@@ -8132,9 +7299,6 @@ one answer RR.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -8142,9 +7306,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The number of queries which resulted
in referral responses.</P
@@ -8152,9 +7313,6 @@ in referral responses.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -8162,9 +7320,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The number of queries which resulted in
NOERROR responses with no data.</P
@@ -8172,9 +7327,6 @@ NOERROR responses with no data.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -8182,9 +7334,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The number
of queries which resulted in NXDOMAIN responses.</P
@@ -8192,9 +7341,6 @@ of queries which resulted in NXDOMAIN responses.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -8202,9 +7348,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The number of queries which resulted in a
failure response other than those above.</P
@@ -8212,9 +7355,6 @@ failure response other than those above.</P
></TR
><TR
><TD
-WIDTH="110"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -8222,9 +7362,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="322"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The number of queries which caused the server
to perform recursion in order to find the final answer.</P
@@ -8278,118 +7415,94 @@ CLASS="command"
></H2
><PRE
CLASS="programlisting"
->server <TT
+>server <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> {
[<SPAN
CLASS="optional"
-> bogus <TT
+> bogus <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> provide-ixfr <TT
+> provide-ixfr <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> request-ixfr <TT
+> request-ixfr <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> edns <TT
+> edns <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfers <TT
+> transfers <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfer-format <TT
+> transfer-format <VAR
CLASS="replaceable"
-><I
->( one-answer | many-answers )</I
-></TT
+>( one-answer | many-answers )</VAR
> ; ]</SPAN
>]
[<SPAN
CLASS="optional"
-> keys <TT
+> keys <VAR
CLASS="replaceable"
-><I
>{ string ; [<SPAN
CLASS="optional"
> string ; [<SPAN
CLASS="optional"
>...</SPAN
>]</SPAN
->] }</I
-></TT
+>] }</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfer-source (<TT
+> transfer-source (<VAR
CLASS="replaceable"
-><I
->ip4_addr</I
-></TT
-> | <TT
+>ip4_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfer-source-v6 (<TT
+> transfer-source-v6 (<VAR
CLASS="replaceable"
-><I
->ip6_addr</I
-></TT
-> | <TT
+>ip6_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
@@ -8526,16 +7639,16 @@ as many resource records as possible into a message. <B
CLASS="command"
>many-answers</B
> is
-more efficient, but is only known to be understood by <SPAN
+more efficient, but is only known to be understood by <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> 9, <SPAN
+>BIND</ACRONYM
+> 9, <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>
-8.x, and patched versions of <SPAN
+8.x, and patched versions of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 4.9.5. You can specify which method
to use for a server with the <B
CLASS="command"
@@ -8633,7 +7746,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN3405"
+NAME="AEN3402"
>6.2.19. <B
CLASS="command"
>trusted-keys</B
@@ -8642,59 +7755,39 @@ CLASS="command"
><PRE
CLASS="programlisting"
>trusted-keys {
- <TT
+ <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
-> <TT
+>string</VAR
+> <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
> ;
[<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
-> <TT
+>string</VAR
+> <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
> ; [<SPAN
CLASS="optional"
>...</SPAN
@@ -8708,7 +7801,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN3421"
+NAME="AEN3418"
>6.2.20. <B
CLASS="command"
>trusted-keys</B
@@ -8751,55 +7844,41 @@ CLASS="command"
></H2
><PRE
CLASS="programlisting"
->view <TT
+>view <VAR
CLASS="replaceable"
-><I
->view_name</I
-></TT
+>view_name</VAR
>
[<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->class</I
-></TT
+>class</VAR
></SPAN
>] {
- match-clients { <TT
+ match-clients { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> } ;
- match-destinations { <TT
+ match-destinations { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> } ;
- match-recursive-only <TT
+ match-recursive-only <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ;
[<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->view_option</I
-></TT
+>view_option</VAR
>; ...</SPAN
>]
[<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->zone_statement</I
-></TT
+>zone_statement</VAR
>; ...</SPAN
>]
};
@@ -8810,7 +7889,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN3443"
+NAME="AEN3440"
>6.2.22. <B
CLASS="command"
>view</B
@@ -8821,9 +7900,9 @@ CLASS="command"
CLASS="command"
>view</B
> statement is a powerful new feature
-of <SPAN
+of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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.</P
@@ -8834,17 +7913,17 @@ CLASS="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
-<TT
+<VAR
CLASS="varname"
->address_match_list</TT
+>address_match_list</VAR
> of the view's
<B
CLASS="command"
>match-clients</B
> clause and its destination IP address matches
-the <TT
+the <VAR
CLASS="varname"
->address_match_list</TT
+>address_match_list</VAR
> of the view's
<B
CLASS="command"
@@ -9003,18 +8082,14 @@ Statement Grammar</A
></H2
><PRE
CLASS="programlisting"
->zone <TT
+>zone <VAR
CLASS="replaceable"
-><I
->zone_name</I
-></TT
+>zone_name</VAR
> [<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->class</I
-></TT
+>class</VAR
></SPAN
>] [<SPAN
CLASS="optional"
@@ -9022,47 +8097,37 @@ CLASS="optional"
type ( master | slave | hint | stub | forward | delegation-only ) ;
[<SPAN
CLASS="optional"
-> allow-notify { <TT
+> allow-notify { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> } ; </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-query { <TT
+> allow-query { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> } ; </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-transfer { <TT
+> allow-transfer { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> } ; </SPAN
>]
[<SPAN
CLASS="optional"
-> allow-update { <TT
+> allow-update { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> } ; </SPAN
>]
[<SPAN
CLASS="optional"
-> update-policy { <TT
+> update-policy { <VAR
CLASS="replaceable"
-><I
->update_policy_rule</I
-></TT
+>update_policy_rule</VAR
> [<SPAN
CLASS="optional"
>...</SPAN
@@ -9070,191 +8135,151 @@ CLASS="optional"
>]
[<SPAN
CLASS="optional"
-> allow-update-forwarding { <TT
+> allow-update-forwarding { <VAR
CLASS="replaceable"
-><I
->address_match_list</I
-></TT
+>address_match_list</VAR
> } ; </SPAN
>]
[<SPAN
CLASS="optional"
-> also-notify { <TT
+> also-notify { <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; ... </SPAN
>] }; </SPAN
>]
[<SPAN
CLASS="optional"
-> check-names (<TT
+> check-names (<CODE
CLASS="constant"
->warn</TT
->|<TT
+>warn</CODE
+>|<CODE
CLASS="constant"
->fail</TT
->|<TT
+>fail</CODE
+>|<CODE
CLASS="constant"
->ignore</TT
+>ignore</CODE
>) ; </SPAN
>]
[<SPAN
CLASS="optional"
-> dialup <TT
+> dialup <VAR
CLASS="replaceable"
-><I
->dialup_option</I
-></TT
+>dialup_option</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> delegation-only <TT
+> delegation-only <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> file <TT
+> file <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> forward (<TT
+> forward (<CODE
CLASS="constant"
->only</TT
->|<TT
+>only</CODE
+>|<CODE
CLASS="constant"
->first</TT
+>first</CODE
>) ; </SPAN
>]
[<SPAN
CLASS="optional"
-> forwarders { <TT
+> forwarders { <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; ... </SPAN
>] }; </SPAN
>]
[<SPAN
CLASS="optional"
-> ixfr-base <TT
+> ixfr-base <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> ixfr-tmp-file <TT
+> ixfr-tmp-file <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> maintain-ixfr-base <TT
+> maintain-ixfr-base <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
> masters [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
->] { ( <TT
+>] { ( <VAR
CLASS="replaceable"
-><I
->masters_list</I
-></TT
-> | <TT
+>masters_list</VAR
+> | <VAR
CLASS="replaceable"
-><I
->ip_addr</I
-></TT
+>ip_addr</VAR
> [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] [<SPAN
CLASS="optional"
->key <TT
+>key <VAR
CLASS="replaceable"
-><I
->key</I
-></TT
+>key</VAR
></SPAN
>] ) ; [<SPAN
CLASS="optional"
@@ -9263,295 +8288,229 @@ CLASS="optional"
>]
[<SPAN
CLASS="optional"
-> max-ixfr-log-size <TT
+> max-ixfr-log-size <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-transfer-idle-in <TT
+> max-transfer-idle-in <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-transfer-idle-out <TT
+> max-transfer-idle-out <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-transfer-time-in <TT
+> max-transfer-time-in <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-transfer-time-out <TT
+> max-transfer-time-out <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> notify <TT
+> notify <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
-> | <TT
+>yes_or_no</VAR
+> | <VAR
CLASS="replaceable"
-><I
->explicit</I
-></TT
+>explicit</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> pubkey <TT
+> pubkey <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
-> <TT
+>number</VAR
+> <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfer-source (<TT
+> transfer-source (<VAR
CLASS="replaceable"
-><I
->ip4_addr</I
-></TT
-> | <TT
+>ip4_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> transfer-source-v6 (<TT
+> transfer-source-v6 (<VAR
CLASS="replaceable"
-><I
->ip6_addr</I
-></TT
-> | <TT
+>ip6_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> alt-transfer-source (<TT
+> alt-transfer-source (<VAR
CLASS="replaceable"
-><I
->ip4_addr</I
-></TT
-> | <TT
+>ip4_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> alt-transfer-source-v6 (<TT
+> alt-transfer-source-v6 (<VAR
CLASS="replaceable"
-><I
->ip6_addr</I
-></TT
-> | <TT
+>ip6_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> use-alt-transfer-source <TT
+> use-alt-transfer-source <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
>; </SPAN
>]
[<SPAN
CLASS="optional"
-> notify-source (<TT
+> notify-source (<VAR
CLASS="replaceable"
-><I
->ip4_addr</I
-></TT
-> | <TT
+>ip4_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> notify-source-v6 (<TT
+> notify-source-v6 (<VAR
CLASS="replaceable"
-><I
->ip6_addr</I
-></TT
-> | <TT
+>ip6_addr</VAR
+> | <CODE
CLASS="constant"
->*</TT
+>*</CODE
>) [<SPAN
CLASS="optional"
->port <TT
+>port <VAR
CLASS="replaceable"
-><I
->ip_port</I
-></TT
+>ip_port</VAR
></SPAN
>] ; </SPAN
>]
[<SPAN
CLASS="optional"
-> zone-statistics <TT
+> zone-statistics <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> sig-validity-interval <TT
+> sig-validity-interval <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> database <TT
+> database <VAR
CLASS="replaceable"
-><I
->string</I
-></TT
+>string</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> min-refresh-time <TT
+> min-refresh-time <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-refresh-time <TT
+> max-refresh-time <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> min-retry-time <TT
+> min-retry-time <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> max-retry-time <TT
+> max-retry-time <VAR
CLASS="replaceable"
-><I
->number</I
-></TT
+>number</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> multi-master <TT
+> multi-master <VAR
CLASS="replaceable"
-><I
->yes_or_no</I
-></TT
+>yes_or_no</VAR
> ; </SPAN
>]
[<SPAN
CLASS="optional"
-> key-directory <TT
+> key-directory <VAR
CLASS="replaceable"
-><I
->path_name</I
-></TT
+>path_name</VAR
>; </SPAN
>]
@@ -9564,7 +8523,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN3617"
+NAME="AEN3614"
>6.2.24. <B
CLASS="command"
>zone</B
@@ -9575,16 +8534,16 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN3620"
+NAME="AEN3617"
>6.2.24.1. Zone Types</A
></H3
><DIV
CLASS="informaltable"
-><A
-NAME="AEN3622"
-></A
><P
></P
+><A
+NAME="AEN3619"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -9592,19 +8551,13 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="87"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->master</TT
+>master</VAR
></P
></TD
><TD
-WIDTH="405"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The server has a master copy of the data
for the zone and will be able to provide authoritative answers for
@@ -9613,19 +8566,13 @@ it.</P
></TR
><TR
><TD
-WIDTH="87"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->slave</TT
+>slave</VAR
></P
></TD
><TD
-WIDTH="405"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>A slave zone is a replica of a master
zone. The <B
@@ -9645,9 +8592,9 @@ 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 <TT
+a slave server for the zone <VAR
CLASS="literal"
->example.com</TT
+>example.com</VAR
> might place
the zone contents into a file called
<TT
@@ -9664,26 +8611,20 @@ a single directory.)</P
></TR
><TR
><TD
-WIDTH="87"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->stub</TT
+>stub</VAR
></P
></TD
><TD
-WIDTH="405"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><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
+they are a feature specific to the <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> implementation.
</P
>
@@ -9697,20 +8638,20 @@ CLASS="filename"
>.
This usage is not recommended for new configurations, and BIND 9
supports it only in a limited way.
-In <SPAN
+In <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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. <SPAN
+only in the master server for the parent zone. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>
9 never mixes together zone data from different zones in this
-way. Therefore, if a <SPAN
+way. Therefore, if a <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -9722,9 +8663,9 @@ configured.</P
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
-<TT
+<VAR
CLASS="literal"
->10.in-addr.arpa</TT
+>10.in-addr.arpa</VAR
>
to use a set of internal name servers as the authoritative
servers for that domain.</P
@@ -9733,19 +8674,13 @@ servers for that domain.</P
></TR
><TR
><TD
-WIDTH="87"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->forward</TT
+>forward</VAR
></P
></TD
><TD
-WIDTH="405"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>A "forward zone" is a way to configure
forwarding on a per-domain basis. A <B
@@ -9788,19 +8723,13 @@ servers as set globally) you need to re-specify the global forwarders.</P
></TR
><TR
><TD
-WIDTH="87"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->hint</TT
+>hint</VAR
></P
></TD
><TD
-WIDTH="405"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The initial set of root name servers is
specified using a "hint zone". When the server starts up, it uses
@@ -9812,19 +8741,13 @@ Classes other than IN have no built-in defaults hints.</P
></TR
><TR
><TD
-WIDTH="87"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->delegation-only</TT
+>delegation-only</VAR
></P
></TD
><TD
-WIDTH="405"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>This is used to enforce the delegation only
status of infrastructure zones (e.g. COM, NET, ORG). Any answer that
@@ -9833,9 +8756,9 @@ section will be treated as NXDOMAIN. This does not apply to the zone
apex. This SHOULD NOT be applied to leaf zones.</P
>
<P
-><TT
+><VAR
CLASS="varname"
->delegation-only</TT
+>delegation-only</VAR
> has no effect on answers received
from forwarders.</P
></TD
@@ -9851,37 +8774,37 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN3685"
+NAME="AEN3682"
>6.2.24.2. Class</A
></H3
><P
>The zone's name may optionally be followed by a class. If
-a class is not specified, class <TT
+a class is not specified, class <VAR
CLASS="literal"
->IN</TT
-> (for <TT
+>IN</VAR
+> (for <VAR
CLASS="varname"
->Internet</TT
+>Internet</VAR
>),
is assumed. This is correct for the vast majority of cases.</P
><P
->The <TT
+>The <VAR
CLASS="literal"
->hesiod</TT
+>hesiod</VAR
> 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
-<TT
+<VAR
CLASS="literal"
->HS</TT
+>HS</VAR
> 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 <TT
+in the mid-1970s. Zone data for it can be specified with the <VAR
CLASS="literal"
->CHAOS</TT
+>CHAOS</VAR
> class.</P
></DIV
><DIV
@@ -9889,7 +8812,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN3695"
+NAME="AEN3692"
>6.2.24.3. Zone Options</A
></H3
><P
@@ -10003,9 +8926,9 @@ CLASS="command"
>notify</B
> is
active for this zone. The set of machines that will receive a
-<TT
+<VAR
CLASS="literal"
->DNS NOTIFY</TT
+>DNS NOTIFY</VAR
> 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
@@ -10031,13 +8954,9 @@ CLASS="command"
></DT
><DD
><P
->&#13;This option was used in BIND 8 to restrict the character set of
-domain names in master files and/or DNS responses received from the
-network. BIND 9 does not restrict the character set of domain names
-and does not implement the <B
-CLASS="command"
->check-names</B
-> option.
+>&#13;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.
</P
></DD
><DT
@@ -10057,11 +8976,9 @@ 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 <TT
+>The default is <KBD
CLASS="userinput"
-><B
->"rbt"</B
-></TT
+>"rbt"</KBD
>, BIND 9's native in-memory
red-black-tree database. This database does not take arguments.</P
><P
@@ -10093,11 +9010,9 @@ CLASS="command"
><DD
><P
>The flag only applies to hint and stub zones. If set
-to <TT
+to <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
> then the zone will also be treated as if it
is also a delegation-only type zone.
</P
@@ -10141,14 +9056,14 @@ CLASS="command"
></DT
><DD
><P
->Was used in <SPAN
+>Was used in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8 to specify the name
of the transaction log (journal) file for dynamic update and IXFR.
-<SPAN
+<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 ignores the option and constructs the name of the journal
file by appending "<TT
CLASS="filename"
@@ -10163,13 +9078,13 @@ CLASS="command"
></DT
><DD
><P
->Was an undocumented option in <SPAN
+>Was an undocumented option in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 8.
-Ignored in <SPAN
+Ignored in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9.</P
></DD
><DT
@@ -10259,14 +9174,14 @@ CLASS="command"
></DT
><DD
><P
->In <SPAN
+>In <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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. <SPAN
+zones when they are loaded from disk. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 does not verify signatures
on load and ignores the option.</P
></DD
@@ -10277,11 +9192,9 @@ CLASS="command"
></DT
><DD
><P
->If <TT
+>If <KBD
CLASS="userinput"
-><B
->yes</B
-></TT
+>yes</KBD
>, the server will keep statistical
information for this zone, which can be dumped to the
<B
@@ -10506,9 +9419,9 @@ NAME="dynamic_update_policies"
>6.2.24.4. Dynamic Update Policies</A
></H3
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 supports two alternative methods of granting clients
the right to perform dynamic updates to a zone,
configured by the <B
@@ -10524,18 +9437,18 @@ CLASS="command"
CLASS="command"
>allow-update</B
> clause works the same
-way as in previous versions of <SPAN
+way as in previous versions of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>. It grants given clients the
permission to update any record of any name in the zone.</P
><P
>The <B
CLASS="command"
>update-policy</B
-> clause is new in <SPAN
+> clause is new in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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
@@ -10571,28 +9484,20 @@ CLASS="command"
> | <B
CLASS="command"
>deny</B
-> ) <TT
+> ) <VAR
CLASS="replaceable"
-><I
->identity</I
-></TT
-> <TT
+>identity</VAR
+> <VAR
CLASS="replaceable"
-><I
->nametype</I
-></TT
-> <TT
+>nametype</VAR
+> <VAR
CLASS="replaceable"
-><I
->name</I
-></TT
+>name</VAR
> [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->types</I
-></TT
+>types</VAR
> </SPAN
>]
</PRE
@@ -10608,49 +9513,43 @@ the types specified in the type field.</P
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 <TT
+TKEY exchange. When the <VAR
CLASS="replaceable"
-><I
->identity</I
-></TT
+>identity</VAR
> field specifies a
wildcard name, it is subject to DNS wildcard expansion, so the rule will apply
-to multiple identities. The <TT
+to multiple identities. The <VAR
CLASS="replaceable"
-><I
->identity</I
-></TT
+>identity</VAR
> field must
contain a fully qualified domain name.</P
><P
->The <TT
+>The <VAR
CLASS="replaceable"
-><I
->nametype</I
-></TT
+>nametype</VAR
> field has 4 values:
-<TT
+<VAR
CLASS="varname"
->name</TT
->, <TT
+>name</VAR
+>, <VAR
CLASS="varname"
->subdomain</TT
+>subdomain</VAR
>,
-<TT
+<VAR
CLASS="varname"
->wildcard</TT
->, and <TT
+>wildcard</VAR
+>, and <VAR
CLASS="varname"
->self</TT
+>self</VAR
>.
</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN3978"
-></A
><P
></P
+><A
+NAME="AEN3974"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -10658,77 +9557,53 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="79"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->name</TT
+>name</VAR
></P
></TD
><TD
-WIDTH="353"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Exact-match semantics. This rule matches when the
name being updated is identical to the contents of the
-<TT
+<VAR
CLASS="replaceable"
-><I
->name</I
-></TT
+>name</VAR
> field.</P
></TD
></TR
><TR
><TD
-WIDTH="79"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->subdomain</TT
+>subdomain</VAR
></P
></TD
><TD
-WIDTH="353"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>This rule matches when the name being updated
is a subdomain of, or identical to, the contents of the
-<TT
+<VAR
CLASS="replaceable"
-><I
->name</I
-></TT
+>name</VAR
> field.</P
></TD
></TR
><TR
><TD
-WIDTH="79"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->wildcard</TT
+>wildcard</VAR
></P
></TD
><TD
-WIDTH="353"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
->The <TT
+>The <VAR
CLASS="replaceable"
-><I
->name</I
-></TT
+>name</VAR
> 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
@@ -10736,53 +9611,39 @@ being updated name is a valid expansion of the wildcard.</P
></TR
><TR
><TD
-WIDTH="79"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="varname"
->self</TT
+>self</VAR
></P
></TD
><TD
-WIDTH="353"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>This rule matches when the name being updated
-matches the contents of the <TT
+matches the contents of the <VAR
CLASS="replaceable"
-><I
->identity</I
-></TT
+>identity</VAR
> field.
-The <TT
+The <VAR
CLASS="replaceable"
-><I
->name</I
-></TT
+>name</VAR
> field is ignored, but should be
-the same as the <TT
+the same as the <VAR
CLASS="replaceable"
-><I
->identity</I
-></TT
+>identity</VAR
> field. The
-<TT
+<VAR
CLASS="varname"
->self</TT
+>self</VAR
> 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 <TT
+to be updated. The <VAR
CLASS="replaceable"
-><I
->identity</I
-></TT
+>identity</VAR
> would be
-specified as <TT
+specified as <CODE
CLASS="constant"
->*</TT
+>*</CODE
> in this case.</P
></TD
></TR
@@ -10792,11 +9653,9 @@ CLASS="constant"
></P
></DIV
><P
->In all cases, the <TT
+>In all cases, the <VAR
CLASS="replaceable"
-><I
->name</I
-></TT
+>name</VAR
> field must
specify a fully qualified domain name.</P
><P
@@ -10814,7 +9673,7 @@ CLASS="sect1"
><H1
CLASS="sect1"
><A
-NAME="AEN4019"
+NAME="AEN4015"
>6.3. Zone File</A
></H1
><DIV
@@ -10835,7 +9694,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN4024"
+NAME="AEN4020"
>6.3.1.1. Resource Records</A
></H3
><P
@@ -10857,11 +9716,11 @@ HREF="Bv9ARM.ch06.html#rrset_ordering"
>The components of a Resource Record are:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4030"
-></A
><P
></P
+><A
+NAME="AEN4026"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -10869,32 +9728,20 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="96"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>owner name</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>the domain name where the RR is found.</P
></TD
></TR
><TR
><TD
-WIDTH="96"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>type</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>an encoded 16 bit value that specifies
the type of the resource record.</P
@@ -10902,16 +9749,10 @@ the type of the resource record.</P
></TR
><TR
><TD
-WIDTH="96"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>TTL</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>the time to live of the RR. This field
is a 32 bit integer in units of seconds, and is primarily used by
@@ -10921,16 +9762,10 @@ be cached before it should be discarded.</P
></TR
><TR
><TD
-WIDTH="96"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>class</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>an encoded 16 bit value that identifies
a protocol family or instance of a protocol.</P
@@ -10938,16 +9773,10 @@ a protocol family or instance of a protocol.</P
></TR
><TR
><TD
-WIDTH="96"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>RDATA</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>the resource data. The format of the
data is type (and sometimes class) specific.</P
@@ -10968,11 +9797,11 @@ CLASS="emphasis"
> of valid RRs:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4062"
-></A
><P
></P
+><A
+NAME="AEN4058"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -10980,16 +9809,10 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>A</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>a host address. In the IN class, this is a
32-bit IP address. Described in RFC 1035.</P
@@ -10997,32 +9820,20 @@ VALIGN="MIDDLE"
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>AAAA</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>IPv6 address. Described in RFC 1886.</P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>A6</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>IPv6 address. This can be a partial
address (a suffix) and an indirection to the name where the rest of the
@@ -11031,16 +9842,10 @@ address (the prefix) can be found. Experimental. Described in RFC 2874.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>AFSDB</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>location of AFS database servers.
Experimental. Described in RFC 1183.</P
@@ -11048,16 +9853,10 @@ Experimental. Described in RFC 1183.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>APL</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>address prefix list. Experimental.
Described in RFC 3123.</P
@@ -11065,16 +9864,10 @@ Described in RFC 3123.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>CERT</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>holds a digital certificate.
Described in RFC 2538.</P
@@ -11082,16 +9875,10 @@ Described in RFC 2538.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>CNAME</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>identifies the canonical name of an alias.
Described in RFC 1035.</P
@@ -11099,16 +9886,10 @@ Described in RFC 1035.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>DNAME</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Replaces the domain name specified with
another name to be looked up, effectively aliasing an entire
@@ -11119,32 +9900,20 @@ Described in RFC 2672.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>GPOS</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Specifies the global position. Superseded by LOC.</P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>HINFO</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>identifies the CPU and OS used by a host.
Described in RFC 1035.</P
@@ -11152,16 +9921,10 @@ Described in RFC 1035.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>ISDN</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>representation of ISDN addresses.
Experimental. Described in RFC 1183.</P
@@ -11169,16 +9932,10 @@ Experimental. Described in RFC 1183.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>KEY</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>stores a public key associated with a
DNS name. Described in RFC 2535.</P
@@ -11186,16 +9943,10 @@ DNS name. Described in RFC 2535.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>KX</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>identifies a key exchanger for this
DNS name. Described in RFC 2230.</P
@@ -11203,16 +9954,10 @@ DNS name. Described in RFC 2230.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>LOC</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>for storing GPS info. Described in RFC 1876.
Experimental.</P
@@ -11220,16 +9965,10 @@ Experimental.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>MX</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>identifies a mail exchange for the domain.
a 16 bit preference value (lower is better)
@@ -11239,32 +9978,20 @@ Described in RFC 974, RFC 1035.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>NAPTR</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>name authority pointer. Described in RFC 2915.</P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>NSAP</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>a network service access point.
Described in RFC 1706.</P
@@ -11272,16 +9999,10 @@ Described in RFC 1706.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>NS</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>the authoritative name server for the
domain. Described in RFC 1035.</P
@@ -11289,16 +10010,10 @@ domain. Described in RFC 1035.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>NXT</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>used in DNSSEC to securely indicate that
RRs with an owner name in a certain name interval do not exist in
@@ -11308,16 +10023,10 @@ Described in RFC 2535.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>PTR</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>a pointer to another part of the domain
name space. Described in RFC 1035.</P
@@ -11325,16 +10034,10 @@ name space. Described in RFC 1035.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>PX</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>provides mappings between RFC 822 and X.400
addresses. Described in RFC 2163.</P
@@ -11342,16 +10045,10 @@ addresses. Described in RFC 2163.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>RP</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>information on persons responsible
for the domain. Experimental. Described in RFC 1183.</P
@@ -11359,16 +10056,10 @@ for the domain. Experimental. Described in RFC 1183.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>RT</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>route-through binding for hosts that
do not have their own direct wide area network addresses.
@@ -11377,16 +10068,10 @@ Experimental. Described in RFC 1183.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>SIG</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>("signature") contains data authenticated
in the secure DNS. Described in RFC 2535.</P
@@ -11394,16 +10079,10 @@ in the secure DNS. Described in RFC 2535.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>SOA</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>identifies the start of a zone of authority.
Described in RFC 1035.</P
@@ -11411,16 +10090,10 @@ Described in RFC 1035.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>SRV</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>information about well known network
services (replaces WKS). Described in RFC 2782.</P
@@ -11428,32 +10101,20 @@ services (replaces WKS). Described in RFC 2782.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>TXT</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>text records. Described in RFC 1035.</P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>WKS</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>information about which well known
network services, such as SMTP, that a domain supports. Historical.
@@ -11462,16 +10123,10 @@ network services, such as SMTP, that a domain supports. Historical.
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>X25</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>representation of X.25 network addresses.
Experimental. Described in RFC 1183.</P
@@ -11493,11 +10148,11 @@ CLASS="emphasis"
are currently valid in the DNS:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4214"
-></A
><P
></P
+><A
+NAME="AEN4210"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -11505,55 +10160,37 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>IN</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The Internet.</P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>CH</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>&#13;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.,
-<TT
+<VAR
CLASS="literal"
->version.bind</TT
+>version.bind</VAR
>.
</P
></TD
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>HS</P
></TD
><TD
-WIDTH="348"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>&#13;Hesiod, an information service
developed by MIT's Project Athena. It is used to share information
@@ -11596,7 +10233,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN4238"
+NAME="AEN4234"
>6.3.1.2. Textual expression of RRs</A
></H3
><P
@@ -11625,11 +10262,11 @@ knowledge of the typical representation for the data.</P
>For example, we might show the RRs carried in a message as:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4245"
-></A
><P
></P
+><A
+NAME="AEN4241"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -11637,184 +10274,130 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="133"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->ISI.EDU.</TT
+>ISI.EDU.</VAR
></P
></TD
><TD
-WIDTH="98"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->MX</TT
+>MX</VAR
></P
></TD
><TD
-WIDTH="202"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10 VENERA.ISI.EDU.</TT
+>10 VENERA.ISI.EDU.</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="133"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="98"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->MX</TT
+>MX</VAR
></P
></TD
><TD
-WIDTH="202"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10 VAXA.ISI.EDU</TT
+>10 VAXA.ISI.EDU</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="133"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->VENERA.ISI.EDU</TT
+>VENERA.ISI.EDU</VAR
></P
></TD
><TD
-WIDTH="98"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="202"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->128.9.0.32</TT
+>128.9.0.32</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="133"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="98"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="202"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10.1.0.52</TT
+>10.1.0.52</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="133"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->VAXA.ISI.EDU</TT
+>VAXA.ISI.EDU</VAR
></P
></TD
><TD
-WIDTH="98"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="202"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10.2.0.27</TT
+>10.2.0.27</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="133"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="98"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="202"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->128.9.0.33</TT
+>128.9.0.33</VAR
></P
></TD
></TR
@@ -11834,11 +10417,11 @@ domain names.</P
>Similarly we might see:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4311"
-></A
><P
></P
+><A
+NAME="AEN4307"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -11846,65 +10429,47 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="143"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->XX.LCS.MIT.EDU. IN</TT
+>XX.LCS.MIT.EDU. IN</VAR
></P
></TD
><TD
-WIDTH="102"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="198"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10.0.0.44</TT
+>10.0.0.44</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="143"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->CH</TT
+>CH</VAR
></P
></TD
><TD
-WIDTH="102"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="198"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->MIT.EDU. 2420</TT
+>MIT.EDU. 2420</VAR
></P
></TD
></TR
@@ -11914,9 +10479,9 @@ CLASS="literal"
></P
></DIV
><P
->This example shows two addresses for <TT
+>This example shows two addresses for <VAR
CLASS="literal"
->XX.LCS.MIT.EDU</TT
+>XX.LCS.MIT.EDU</VAR
>,
each of a different class.</P
></DIV
@@ -11926,7 +10491,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN4339"
+NAME="AEN4335"
>6.3.2. Discussion of MX Records</A
></H2
><P
@@ -11961,11 +10526,11 @@ the mail will be delivered to the server specified in the MX record
pointed to by the CNAME.</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4345"
-></A
><P
></P
+><A
+NAME="AEN4341"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -11973,248 +10538,173 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="164"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->example.com.</TT
+>example.com.</VAR
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN</TT
+>IN</VAR
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->MX</TT
+>MX</VAR
></P
></TD
><TD
-WIDTH="94"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10</TT
+>10</VAR
></P
></TD
><TD
-WIDTH="149"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->mail.example.com.</TT
+>mail.example.com.</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="164"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN</TT
+>IN</VAR
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->MX</TT
+>MX</VAR
></P
></TD
><TD
-WIDTH="94"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10</TT
+>10</VAR
></P
></TD
><TD
-WIDTH="149"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->mail2.example.com.</TT
+>mail2.example.com.</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="164"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN</TT
+>IN</VAR
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->MX</TT
+>MX</VAR
></P
></TD
><TD
-WIDTH="94"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->20</TT
+>20</VAR
></P
></TD
><TD
-WIDTH="149"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->mail.backup.org.</TT
+>mail.backup.org.</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="164"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->mail.example.com.</TT
+>mail.example.com.</VAR
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN</TT
+>IN</VAR
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="94"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10.0.0.1</TT
+>10.0.0.1</VAR
></P
></TD
><TD
-WIDTH="149"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
></TR
><TR
><TD
-WIDTH="164"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->mail2.example.com.</TT
+>mail2.example.com.</VAR
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN</TT
+>IN</VAR
></P
></TD
><TD
-WIDTH="43"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->A</TT
+>A</VAR
></P
></TD
><TD
-WIDTH="94"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->10.0.0.2</TT
+>10.0.0.2</VAR
></P
></TD
><TD
-WIDTH="149"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
@@ -12227,17 +10717,17 @@ VALIGN="MIDDLE"
><P
>For example:</P
><P
->Mail delivery will be attempted to <TT
+>Mail delivery will be attempted to <VAR
CLASS="literal"
->mail.example.com</TT
+>mail.example.com</VAR
> and
-<TT
+<VAR
CLASS="literal"
->mail2.example.com</TT
+>mail2.example.com</VAR
> (in
-any order), and if neither of those succeed, delivery to <TT
+any order), and if neither of those succeed, delivery to <VAR
CLASS="literal"
->mail.backup.org</TT
+>mail.backup.org</VAR
> will
be attempted.</P
></DIV
@@ -12257,11 +10747,11 @@ should be discarded. The following three types of TTL are currently
used in a zone file.</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4437"
-></A
><P
></P
+><A
+NAME="AEN4433"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -12269,16 +10759,10 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>SOA</P
></TD
><TD
-WIDTH="420"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The last field in the SOA is the negative
caching TTL. This controls how long other servers will cache no-such-domain
@@ -12290,16 +10774,10 @@ negative caching is 3 hours (3h).</P
></TR
><TR
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>$TTL</P
></TD
><TD
-WIDTH="420"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>The $TTL directive at the top of the
zone file (before the SOA) gives a default TTL for every RR without
@@ -12308,16 +10786,10 @@ a specific TTL set.</P
></TR
><TR
><TD
-WIDTH="72"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>RR TTLs</P
></TD
><TD
-WIDTH="420"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Each RR can have a TTL as the second
field in the RR, which will control how long other servers can cache
@@ -12331,9 +10803,9 @@ the it.</P
></DIV
><P
>All of these TTLs default to units of seconds, though units
-can be explicitly specified, for example, <TT
+can be explicitly specified, for example, <VAR
CLASS="literal"
->1h30m</TT
+>1h30m</VAR
>. </P
></DIV
><DIV
@@ -12341,7 +10813,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN4460"
+NAME="AEN4456"
>6.3.4. Inverse Mapping in IPv4</A
></H2
><P
@@ -12367,11 +10839,11 @@ CLASS="optional"
>] domain:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4465"
-></A
><P
></P
+><A
+NAME="AEN4461"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -12379,45 +10851,33 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->$ORIGIN</TT
+>$ORIGIN</VAR
></P
></TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->2.1.10.in-addr.arpa</TT
+>2.1.10.in-addr.arpa</VAR
></P
></TD
></TR
><TR
><TD
-WIDTH="108"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->3</TT
+>3</VAR
></P
></TD
><TD
-WIDTH="384"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
-><TT
+><VAR
CLASS="literal"
->IN PTR foo.example.com.</TT
+>IN PTR foo.example.com.</VAR
></P
></TD
></TR
@@ -12448,7 +10908,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN4487"
+NAME="AEN4483"
>6.3.5. Other Zone File Directives</A
></H2
><P
@@ -12473,7 +10933,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN4494"
+NAME="AEN4490"
>6.3.5.1. The <B
CLASS="command"
>$ORIGIN</B
@@ -12484,18 +10944,14 @@ CLASS="command"
CLASS="command"
>$ORIGIN
</B
-><TT
+><VAR
CLASS="replaceable"
-><I
->domain-name</I
-></TT
+>domain-name</VAR
> [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->comment</I
-></TT
+>comment</VAR
></SPAN
>]</P
><P
@@ -12507,9 +10963,9 @@ be appended to any unqualified records. When a zone is first read
in there is an implicit <B
CLASS="command"
>$ORIGIN</B
-> &#60;<TT
+> &#60;<VAR
CLASS="varname"
->zone-name</TT
+>zone-name</VAR
>&#62;<B
CLASS="command"
>.</B
@@ -12524,18 +10980,18 @@ CLASS="command"
> argument if it is not absolute.</P
><PRE
CLASS="programlisting"
-><TT
+><VAR
CLASS="literal"
>$ORIGIN example.com.
-WWW CNAME MAIN-SERVER</TT
+WWW CNAME MAIN-SERVER</VAR
></PRE
><P
>is equivalent to</P
><PRE
CLASS="programlisting"
-><TT
+><VAR
CLASS="literal"
->WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</TT
+>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</VAR
></PRE
></DIV
><DIV
@@ -12543,7 +10999,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN4514"
+NAME="AEN4510"
>6.3.5.2. The <B
CLASS="command"
>$INCLUDE</B
@@ -12554,26 +11010,20 @@ CLASS="command"
CLASS="command"
>$INCLUDE</B
>
-<TT
+<VAR
CLASS="replaceable"
-><I
->filename</I
-></TT
+>filename</VAR
> [<SPAN
CLASS="optional"
->&#13;<TT
+>&#13;<VAR
CLASS="replaceable"
-><I
->origin</I
-></TT
+>origin</VAR
> </SPAN
>] [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->comment</I
-></TT
+>comment</VAR
> </SPAN
>]</P
><P
@@ -12625,7 +11075,7 @@ CLASS="sect3"
><H3
CLASS="sect3"
><A
-NAME="AEN4534"
+NAME="AEN4530"
>6.3.5.3. The <B
CLASS="command"
>$TTL</B
@@ -12636,18 +11086,14 @@ CLASS="command"
CLASS="command"
>$TTL</B
>
-<TT
+<VAR
CLASS="replaceable"
-><I
->default-ttl</I
-></TT
+>default-ttl</VAR
> [<SPAN
CLASS="optional"
->&#13;<TT
+>&#13;<VAR
CLASS="replaceable"
-><I
->comment</I
-></TT
+>comment</VAR
> </SPAN
>]</P
><P
@@ -12665,10 +11111,10 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN4545"
->6.3.6. <SPAN
+NAME="AEN4541"
+>6.3.6. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> Master File Extension: the <B
CLASS="command"
>$GENERATE</B
@@ -12678,49 +11124,35 @@ CLASS="command"
>Syntax: <B
CLASS="command"
>$GENERATE</B
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->range</I
-></TT
-> <TT
+>range</VAR
+> <VAR
CLASS="replaceable"
-><I
->lhs</I
-></TT
+>lhs</VAR
> [<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->ttl</I
-></TT
+>ttl</VAR
></SPAN
>] [<SPAN
CLASS="optional"
-><TT
+><VAR
CLASS="replaceable"
-><I
->class</I
-></TT
+>class</VAR
></SPAN
->] <TT
+>] <VAR
CLASS="replaceable"
-><I
->type</I
-></TT
-> <TT
+>type</VAR
+> <VAR
CLASS="replaceable"
-><I
->rhs</I
-></TT
+>rhs</VAR
> [<SPAN
CLASS="optional"
-> <TT
+> <VAR
CLASS="replaceable"
-><I
->comment</I
-></TT
+>comment</VAR
> </SPAN
>]</P
><P
@@ -12737,17 +11169,17 @@ sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA
delegation.</P
><PRE
CLASS="programlisting"
-><TT
+><VAR
CLASS="literal"
>$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
-$GENERATE 1-127 $ CNAME $.0</TT
+$GENERATE 1-127 $ CNAME $.0</VAR
></PRE
><P
>is equivalent to</P
><PRE
CLASS="programlisting"
-><TT
+><VAR
CLASS="literal"
>0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
@@ -12755,15 +11187,15 @@ CLASS="literal"
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.
-</TT
+</VAR
></PRE
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4569"
-></A
><P
></P
+><A
+NAME="AEN4565"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -12771,9 +11203,6 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12781,9 +11210,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="408"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><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
@@ -12792,9 +11218,6 @@ or start-stop/step. If the first form is used then step is set to
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12802,9 +11225,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="408"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12889,9 +11309,6 @@ recognized a indicating a literal $ in the output.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12899,9 +11316,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="408"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12923,9 +11337,6 @@ CLASS="command"
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12933,9 +11344,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="408"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12957,9 +11365,6 @@ CLASS="command"
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12967,9 +11372,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="408"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>At present the only supported types are
PTR, CNAME, DNAME, A, AAAA and NS.</P
@@ -12977,9 +11379,6 @@ PTR, CNAME, DNAME, A, AAAA and NS.</P
></TR
><TR
><TD
-WIDTH="84"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
><B
CLASS="command"
@@ -12987,9 +11386,6 @@ CLASS="command"
></P
></TD
><TD
-WIDTH="408"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>rhs is a domain name. It is processed
similarly to lhs.</P
@@ -13004,9 +11400,9 @@ similarly to lhs.</P
>The <B
CLASS="command"
>$GENERATE</B
-> directive is a <SPAN
+> directive is a <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> extension
and not part of the standard zone file format.</P
><P
@@ -13058,9 +11454,9 @@ ACCESSKEY="N"
WIDTH="33%"
ALIGN="left"
VALIGN="top"
->The <SPAN
+>The <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Lightweight Resolver</TD
><TD
WIDTH="34%"
@@ -13071,9 +11467,9 @@ VALIGN="top"
WIDTH="33%"
ALIGN="right"
VALIGN="top"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Security Considerations</TD
></TR
></TABLE
diff --git a/dist/bind/doc/arm/Bv9ARM.ch07.html b/dist/bind/doc/arm/Bv9ARM.ch07.html
index 68312509f66..a7c47077387 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch07.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch07.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>BIND 9 Security Considerations</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -70,11 +70,11 @@ CLASS="chapter"
><H1
><A
NAME="ch07"
->Chapter 7. <SPAN
+></A
+>Chapter 7. <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> 9 Security Considerations</A
-></H1
+>BIND</ACRONYM
+> 9 Security Considerations</H1
><DIV
CLASS="TOC"
><DL
@@ -89,7 +89,7 @@ HREF="Bv9ARM.ch07.html#Access_Control_Lists"
></DT
><DT
>7.2. <A
-HREF="Bv9ARM.ch07.html#AEN4662"
+HREF="Bv9ARM.ch07.html#AEN4658"
><B
CLASS="command"
>chroot</B
@@ -197,7 +197,7 @@ CLASS="sect1"
><H1
CLASS="sect1"
><A
-NAME="AEN4662"
+NAME="AEN4658"
>7.2. <B
CLASS="command"
>chroot</B
@@ -208,9 +208,9 @@ CLASS="command"
UNIX servers)</A
></H1
><P
->On UNIX servers, it is possible to run <SPAN
+>On UNIX servers, it is possible to run <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> in a <SPAN
CLASS="emphasis"
><I
@@ -221,37 +221,35 @@ CLASS="emphasis"
(<B
CLASS="command"
>chroot()</B
->) by specifying the "<TT
+>) by specifying the "<VAR
CLASS="option"
->-t</TT
+>-t</VAR
>"
-option. This can help improve system security by placing <SPAN
+option. This can help improve system security by placing <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 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
+>Another useful feature in the UNIX version of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> is the
-ability to run the daemon as an unprivileged user ( <TT
+ability to run the daemon as an unprivileged user ( <VAR
CLASS="option"
->-u</TT
-> <TT
+>-u</VAR
+> <VAR
CLASS="replaceable"
-><I
->user</I
-></TT
+>user</VAR
> ).
We suggest running as an unprivileged user when using the <B
CLASS="command"
>chroot</B
> feature.</P
><P
->Here is an example command line to load <SPAN
+>Here is an example command line to load <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> in a <B
CLASS="command"
>chroot()</B
@@ -268,18 +266,16 @@ CLASS="command"
> to
user 202:</P
><P
-><TT
+><KBD
CLASS="userinput"
-><B
->/usr/local/bin/named -u 202 -t /var/named</B
-></TT
+>/usr/local/bin/named -u 202 -t /var/named</KBD
></P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN4685"
+NAME="AEN4681"
>7.2.1. The <B
CLASS="command"
>chroot</B
@@ -296,13 +292,13 @@ CLASS="filename"
>/var/named</TT
>),
you will need to set up an environment that includes everything
-<SPAN
+<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> needs to run.
-From <SPAN
+From <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>'s point of view, <TT
CLASS="filename"
>/var/named</TT
@@ -355,7 +351,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN4703"
+NAME="AEN4699"
>7.2.2. Using the <B
CLASS="command"
>setuid</B
@@ -375,9 +371,9 @@ CLASS="command"
>chown</B
> utility (to
set the user id and/or group id) on files
-to which you want <SPAN
+to which you want <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>
to write. Note that if the <B
CLASS="command"
@@ -398,9 +394,9 @@ NAME="dynamic_update_security"
><P
>Access to the dynamic
update facility should be strictly limited. In earlier versions of
-<SPAN
+<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <B
@@ -482,9 +478,9 @@ ACCESSKEY="N"
WIDTH="33%"
ALIGN="left"
VALIGN="top"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Configuration Reference</TD
><TD
WIDTH="34%"
diff --git a/dist/bind/doc/arm/Bv9ARM.ch08.html b/dist/bind/doc/arm/Bv9ARM.ch08.html
index 72e1b2a8139..fe173a8f47a 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch08.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch08.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Troubleshooting</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -70,8 +70,8 @@ CLASS="chapter"
><H1
><A
NAME="ch08"
->Chapter 8. Troubleshooting</A
-></H1
+></A
+>Chapter 8. Troubleshooting</H1
><DIV
CLASS="TOC"
><DL
@@ -81,17 +81,17 @@ CLASS="TOC"
></DT
><DT
>8.1. <A
-HREF="Bv9ARM.ch08.html#AEN4724"
+HREF="Bv9ARM.ch08.html#AEN4720"
>Common Problems</A
></DT
><DT
>8.2. <A
-HREF="Bv9ARM.ch08.html#AEN4729"
+HREF="Bv9ARM.ch08.html#AEN4725"
>Incrementing and Changing the Serial Number</A
></DT
><DT
>8.3. <A
-HREF="Bv9ARM.ch08.html#AEN4734"
+HREF="Bv9ARM.ch08.html#AEN4730"
>Where Can I Get Help?</A
></DT
></DL
@@ -101,7 +101,7 @@ CLASS="sect1"
><H1
CLASS="sect1"
><A
-NAME="AEN4724"
+NAME="AEN4720"
>8.1. Common Problems</A
></H1
><DIV
@@ -109,7 +109,7 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN4726"
+NAME="AEN4722"
>8.1.1. It's not working; how can I figure out what's wrong?</A
></H2
><P
@@ -125,7 +125,7 @@ CLASS="sect1"
><H1
CLASS="sect1"
><A
-NAME="AEN4729"
+NAME="AEN4725"
>8.2. Incrementing and Changing the Serial Number</A
></H1
><P
@@ -154,39 +154,39 @@ CLASS="sect1"
><H1
CLASS="sect1"
><A
-NAME="AEN4734"
+NAME="AEN4730"
>8.3. Where Can I Get Help?</A
></H1
><P
->The Internet Software Consortium (<SPAN
+>The Internet Software Consortium (<ACRONYM
CLASS="acronym"
->ISC</SPAN
+>ISC</ACRONYM
>) offers a wide range
- of support and service agreements for <SPAN
+ of support and service agreements for <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> and <SPAN
+>BIND</ACRONYM
+> and <ACRONYM
CLASS="acronym"
->DHCP</SPAN
+>DHCP</ACRONYM
> servers. Four
levels of premium support are available and each level includes
- support for all <SPAN
+ support for all <ACRONYM
CLASS="acronym"
->ISC</SPAN
+>ISC</ACRONYM
> programs, significant discounts on products
and training, and a recognized priority on bug fixes and
- non-funded feature requests. In addition, <SPAN
+ non-funded feature requests. In addition, <ACRONYM
CLASS="acronym"
->ISC</SPAN
+>ISC</ACRONYM
> offers a standard
support agreement package which includes services ranging from bug
fix announcements to remote support. It also includes training in
- <SPAN
+ <ACRONYM
CLASS="acronym"
->BIND</SPAN
-> and <SPAN
+>BIND</ACRONYM
+> and <ACRONYM
CLASS="acronym"
->DHCP</SPAN
+>DHCP</ACRONYM
>.</P
><P
>To discuss arrangements for support, contact
@@ -195,9 +195,9 @@ HREF="mailto:info@isc.org"
TARGET="_top"
>info@isc.org</A
> or visit the
- <SPAN
+ <ACRONYM
CLASS="acronym"
->ISC</SPAN
+>ISC</ACRONYM
> web page at <A
HREF="http://www.isc.org/services/support/"
TARGET="_top"
@@ -250,9 +250,9 @@ ACCESSKEY="N"
WIDTH="33%"
ALIGN="left"
VALIGN="top"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Security Considerations</TD
><TD
WIDTH="34%"
diff --git a/dist/bind/doc/arm/Bv9ARM.ch09.html b/dist/bind/doc/arm/Bv9ARM.ch09.html
index 0de54ed6026..130257c2411 100644
--- a/dist/bind/doc/arm/Bv9ARM.ch09.html
+++ b/dist/bind/doc/arm/Bv9ARM.ch09.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Appendices</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
@@ -63,8 +63,8 @@ CLASS="appendix"
><H1
><A
NAME="ch09"
->Appendix A. Appendices</A
-></H1
+></A
+>Appendix A. Appendices</H1
><DIV
CLASS="TOC"
><DL
@@ -74,15 +74,15 @@ CLASS="TOC"
></DT
><DT
>A.1. <A
-HREF="Bv9ARM.ch09.html#AEN4750"
+HREF="Bv9ARM.ch09.html#AEN4746"
>Acknowledgments</A
></DT
><DT
>A.2. <A
HREF="Bv9ARM.ch09.html#historical_dns_information"
->General <SPAN
+>General <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Reference Information</A
></DT
><DT
@@ -97,7 +97,7 @@ CLASS="sect1"
><H1
CLASS="sect1"
><A
-NAME="AEN4750"
+NAME="AEN4746"
>A.1. Acknowledgments</A
></H1
><DIV
@@ -105,13 +105,13 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN4752"
->A.1.1. A Brief History of the <SPAN
+NAME="AEN4748"
+>A.1.1. A Brief History of the <ACRONYM
CLASS="acronym"
->DNS</SPAN
-> and <SPAN
+>DNS</ACRONYM
+> and <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
></A
></H2
><P
@@ -126,9 +126,9 @@ CLASS="acronym"
incorporate improvements based on the working model. RFC 1034,
"Domain Names-Concepts and Facilities", and RFC 1035, "Domain
Names-Implementation and Specification" were published and
- became the standards upon which all <SPAN
+ became the standards upon which all <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> implementations are
built.
</P
@@ -137,80 +137,80 @@ CLASS="acronym"
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
+Center (SRI-NIC). A <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> server for Unix machines, the Berkeley Internet
-Name Domain (<SPAN
+Name Domain (<ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+(DARPA). Versions of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+Painter, David Riggle and Songnian Zhou made up the initial <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+employee on loan to the CSRG, worked on <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> for 2 years, from 1985
-to 1987. Many other people also contributed to <SPAN
+to 1987. Many other people also contributed to <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> development
during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell,
-Mike Muuss, Jim Bloom and Mike Schwartz. <SPAN
+Mike Muuss, Jim Bloom and Mike Schwartz. <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> maintenance was subsequently
handled by Mike Karels and O. Kure.</P
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+a DEC employee, became <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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.</P
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> Version 4.9.2 was sponsored by Vixie Enterprises. Paul
-Vixie became <SPAN
+Vixie became <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
>'s principal architect/programmer.</P
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>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 <SPAN
+Paul Vixie released the first production-ready version of <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> version
8 in May 1997.</P
><P
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> development work is made possible today by the sponsorship
of several corporations, and by the tireless work efforts of numerous
individuals.</P
@@ -222,9 +222,9 @@ CLASS="sect1"
CLASS="sect1"
><A
NAME="historical_dns_information"
->A.2. General <SPAN
+>A.2. General <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Reference Information</A
></H1
><DIV
@@ -237,9 +237,9 @@ NAME="ipv6addresses"
></H2
><P
>IPv6 addresses are 128-bit identifiers for interfaces and
-sets of interfaces which were introduced in the <SPAN
+sets of interfaces which were introduced in the <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> to facilitate
scalable Internet routing. There are three types of addresses: <SPAN
CLASS="emphasis"
@@ -268,11 +268,11 @@ Unicast address scheme. For more information, see RFC 2374.</P
>The aggregatable global Unicast address format is as follows:</P
><DIV
CLASS="informaltable"
-><A
-NAME="AEN4788"
-></A
><P
></P
+><A
+NAME="AEN4784"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -280,88 +280,52 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="46"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>3</P
></TD
><TD
-WIDTH="48"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>13</P
></TD
><TD
-WIDTH="50"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>8</P
></TD
><TD
-WIDTH="70"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>24</P
></TD
><TD
-WIDTH="129"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>16</P
></TD
><TD
-WIDTH="243"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>64 bits</P
></TD
></TR
><TR
><TD
-WIDTH="46"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>FP</P
></TD
><TD
-WIDTH="48"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>TLA ID</P
></TD
><TD
-WIDTH="50"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>RES</P
></TD
><TD
-WIDTH="70"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>NLA ID</P
></TD
><TD
-WIDTH="129"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>SLA ID</P
></TD
><TD
-WIDTH="243"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Interface ID</P
></TD
@@ -369,111 +333,67 @@ VALIGN="MIDDLE"
><TR
><TD
COLSPAN="4"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>&#60;------ Public Topology
------&#62;</P
></TD
><TD
-WIDTH="129"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="243"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
></TR
><TR
><TD
-WIDTH="46"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="48"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="50"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="70"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="129"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>&#60;-Site Topology-&#62;</P
></TD
><TD
-WIDTH="243"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
></TR
><TR
><TD
-WIDTH="46"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="48"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="50"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="70"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="129"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
></P
></TD
><TD
-WIDTH="243"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>&#60;------ Interface Identifier ------&#62;</P
></TD
@@ -487,11 +407,11 @@ VALIGN="MIDDLE"
>Where
<DIV
CLASS="informaltable"
-><A
-NAME="AEN4857"
-></A
><P
></P
+><A
+NAME="AEN4853"
+></A
><TABLE
CELLPADDING="3"
BORDER="1"
@@ -499,138 +419,84 @@ CLASS="CALSTABLE"
><TBODY
><TR
><TD
-WIDTH="132"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>FP</P
></TD
><TD
-WIDTH="24"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Format Prefix (001)</P
></TD
></TR
><TR
><TD
-WIDTH="132"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>TLA ID</P
></TD
><TD
-WIDTH="24"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Top-Level Aggregation Identifier</P
></TD
></TR
><TR
><TD
-WIDTH="132"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>RES</P
></TD
><TD
-WIDTH="24"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Reserved for future use</P
></TD
></TR
><TR
><TD
-WIDTH="132"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>NLA ID</P
></TD
><TD
-WIDTH="24"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Next-Level Aggregation Identifier</P
></TD
></TR
><TR
><TD
-WIDTH="132"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>SLA ID</P
></TD
><TD
-WIDTH="24"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Site-Level Aggregation Identifier</P
></TD
></TR
><TR
><TD
-WIDTH="132"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>INTERFACE ID</P
></TD
><TD
-WIDTH="24"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
-WIDTH="336"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
><P
>Interface Identifier</P
></TD
@@ -688,7 +554,7 @@ of a block may be omitted, for example:</P
><P
><B
CLASS="command"
->2001:4f8:201:9:a00:20ff:fe81:2b32</B
+>2001:db8:201:9:a00:20ff:fe81:2b32</B
></P
><P
>IPv6 address specifications are likely to contain long strings
@@ -715,9 +581,9 @@ NAME="rfcs"
></H2
><P
>Specification documents for the Internet protocol suite, including
-the <SPAN
+the <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>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
@@ -725,17 +591,13 @@ 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<TT
+>ftp://www.isi.edu/in-notes/RFC<VAR
CLASS="replaceable"
-><I
->xxx</I
-></TT
+>xxx</VAR
>.txt</A
-> (where <TT
+> (where <VAR
CLASS="replaceable"
-><I
->xxx</I
-></TT
+>xxx</VAR
> is
the number of the RFC). RFCs are also available via the Web at
<A
@@ -746,19 +608,19 @@ TARGET="_top"
</P
><H3
><A
-NAME="AEN4925"
+NAME="AEN4921"
>Bibliography</A
></H3
><H2
CLASS="bibliodiv"
><A
-NAME="AEN4926"
+NAME="AEN4922"
>Standards</A
></H2
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4928"
+NAME="AEN4924"
></A
><P
>[RFC974]&nbsp;<SPAN
@@ -769,13 +631,13 @@ CLASS="AUTHOR"
>, January 1986.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4935"
+NAME="AEN4931"
></A
><P
>[RFC1034]&nbsp;<SPAN
@@ -786,13 +648,13 @@ CLASS="AUTHOR"
>, November 1987.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4942"
+NAME="AEN4938"
></A
><P
>[RFC1035]&nbsp;<SPAN
@@ -804,7 +666,7 @@ Specification</I
>, November 1987.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><H2
@@ -816,67 +678,67 @@ NAME="proposed_standards"
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4951"
+NAME="AEN4947"
></A
><P
>[RFC2181]&nbsp;<SPAN
CLASS="AUTHOR"
>R., R. Bush Elz</SPAN
>, <I
->Clarifications to the <SPAN
+>Clarifications to the <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Specification</I
>, July 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4959"
+NAME="AEN4955"
></A
><P
>[RFC2308]&nbsp;<SPAN
CLASS="AUTHOR"
>M. Andrews</SPAN
>, <I
->Negative Caching of <SPAN
+>Negative Caching of <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Queries</I
>, March 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4967"
+NAME="AEN4963"
></A
><P
>[RFC1995]&nbsp;<SPAN
CLASS="AUTHOR"
>M. Ohta</SPAN
>, <I
->Incremental Zone Transfer in <SPAN
+>Incremental Zone Transfer in <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
></I
>, August 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4975"
+NAME="AEN4971"
></A
><P
>[RFC1996]&nbsp;<SPAN
@@ -887,13 +749,13 @@ CLASS="AUTHOR"
>, August 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4982"
+NAME="AEN4978"
></A
><P
>[RFC2136]&nbsp;<SPAN
@@ -913,13 +775,13 @@ CLASS="AUTHOR"
>, April 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN4999"
+NAME="AEN4995"
></A
><P
>[RFC2845]&nbsp;<SPAN
@@ -935,26 +797,26 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and B. Wellington</SPAN
>, <I
->Secret Key Transaction Authentication for <SPAN
+>Secret Key Transaction Authentication for <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> (TSIG)</I
>, May 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><H2
CLASS="bibliodiv"
><A
-NAME="AEN5018"
+NAME="AEN5014"
>Proposed Standards Still Under Development</A
></H2
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5023"
+NAME="AEN5019"
></A
><P
>[RFC1886]&nbsp;<SPAN
@@ -964,20 +826,20 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and C. Huitema</SPAN
>, <I
-><SPAN
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Extensions to support IP version 6</I
>, December 1995.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5035"
+NAME="AEN5031"
></A
><P
>[RFC2065]&nbsp;<SPAN
@@ -991,13 +853,13 @@ CLASS="AUTHOR"
>, January 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5047"
+NAME="AEN5043"
></A
><P
>[RFC2137]&nbsp;<SPAN
@@ -1008,42 +870,42 @@ CLASS="AUTHOR"
>, April 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><H2
CLASS="bibliodiv"
><A
-NAME="AEN5055"
->Other Important RFCs About <SPAN
+NAME="AEN5051"
+>Other Important RFCs About <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Implementation</A
></H2
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5058"
+NAME="AEN5054"
></A
><P
>[RFC1535]&nbsp;<SPAN
CLASS="AUTHOR"
>E. Gavron</SPAN
>, <I
->A Security Problem and Proposed Correction With Widely Deployed <SPAN
+>A Security Problem and Proposed Correction With Widely Deployed <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Software.</I
>, October 1993.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5066"
+NAME="AEN5062"
></A
><P
>[RFC1536]&nbsp;<SPAN
@@ -1062,20 +924,20 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and S. Miller</SPAN
>, <I
->Common <SPAN
+>Common <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Implementation Errors and Suggested Fixes</I
>, October 1993.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5087"
+NAME="AEN5083"
></A
><P
>[RFC1982]&nbsp;<SPAN
@@ -1089,19 +951,19 @@ CLASS="AUTHOR"
>, August 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><H2
CLASS="bibliodiv"
><A
-NAME="AEN5098"
+NAME="AEN5094"
>Resource Record Types</A
></H2
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5100"
+NAME="AEN5096"
></A
><P
>[RFC1183]&nbsp;<SPAN
@@ -1117,20 +979,20 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and P. Mockapetris</SPAN
>, <I
->New <SPAN
+>New <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> RR Definitions</I
>, October 1990.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5118"
+NAME="AEN5114"
></A
><P
>[RFC1706]&nbsp;<SPAN
@@ -1140,20 +1002,20 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and R. Colella</SPAN
>, <I
-><SPAN
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> NSAP Resource Records</I
>, October 1994.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5130"
+NAME="AEN5126"
></A
><P
>[RFC2168]&nbsp;<SPAN
@@ -1168,13 +1030,13 @@ the Domain Name System</I
>, June 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5141"
+NAME="AEN5137"
></A
><P
>[RFC1876]&nbsp;<SPAN
@@ -1195,13 +1057,13 @@ Name System</I
>, January 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5158"
+NAME="AEN5154"
></A
><P
>[RFC2052]&nbsp;<SPAN
@@ -1211,91 +1073,91 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and P. Vixie</SPAN
>, <I
->A <SPAN
+>A <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> RR for Specifying the Location of
Services.</I
>, October 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5170"
+NAME="AEN5166"
></A
><P
>[RFC2163]&nbsp;<SPAN
CLASS="AUTHOR"
>A. Allocchio</SPAN
>, <I
->Using the Internet <SPAN
+>Using the Internet <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> to Distribute MIXER
Conformant Global Address Mapping</I
>, January 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5178"
+NAME="AEN5174"
></A
><P
>[RFC2230]&nbsp;<SPAN
CLASS="AUTHOR"
>R. Atkinson</SPAN
>, <I
->Key Exchange Delegation Record for the <SPAN
+>Key Exchange Delegation Record for the <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
></I
>, October 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><H2
CLASS="bibliodiv"
><A
-NAME="AEN5186"
-><SPAN
+NAME="AEN5182"
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> and the Internet</A
></H2
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5189"
+NAME="AEN5185"
></A
><P
>[RFC1101]&nbsp;<SPAN
CLASS="AUTHOR"
>P. V. Mockapetris</SPAN
>, <I
-><SPAN
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Encoding of Network Names and Other Types</I
>, April 1989.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5197"
+NAME="AEN5193"
></A
><P
>[RFC1123]&nbsp;<SPAN
@@ -1306,13 +1168,13 @@ CLASS="AUTHOR"
>, October 1989.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5204"
+NAME="AEN5200"
></A
><P
>[RFC1591]&nbsp;<SPAN
@@ -1323,13 +1185,13 @@ CLASS="AUTHOR"
>, March 1994.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5211"
+NAME="AEN5207"
></A
><P
>[RFC2317]&nbsp;<SPAN
@@ -1346,62 +1208,62 @@ CLASS="AUTHOR"
>, March 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><H2
CLASS="bibliodiv"
><A
-NAME="AEN5225"
-><SPAN
+NAME="AEN5221"
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Operations</A
></H2
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5228"
+NAME="AEN5224"
></A
><P
>[RFC1537]&nbsp;<SPAN
CLASS="AUTHOR"
>P. Beertema</SPAN
>, <I
->Common <SPAN
+>Common <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Data File Configuration Errors</I
>, October 1993.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5236"
+NAME="AEN5232"
></A
><P
>[RFC1912]&nbsp;<SPAN
CLASS="AUTHOR"
>D. Barr</SPAN
>, <I
->Common <SPAN
+>Common <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Operational and Configuration Errors</I
>, February 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5244"
+NAME="AEN5240"
></A
><P
>[RFC2010]&nbsp;<SPAN
@@ -1415,13 +1277,13 @@ CLASS="AUTHOR"
>, October 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5255"
+NAME="AEN5251"
></A
><P
>[RFC2219]&nbsp;<SPAN
@@ -1431,29 +1293,29 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and R. Wright</SPAN
>, <I
->Use of <SPAN
+>Use of <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Aliases for Network Services.</I
>, October 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><H2
CLASS="bibliodiv"
><A
-NAME="AEN5267"
->Other <SPAN
+NAME="AEN5263"
+>Other <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
>-related RFCs</A
></H2
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5273"
+NAME="AEN5269"
></A
><P
>[RFC1464]&nbsp;<SPAN
@@ -1464,53 +1326,53 @@ CLASS="AUTHOR"
>, May 1993.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5280"
+NAME="AEN5276"
></A
><P
>[RFC1713]&nbsp;<SPAN
CLASS="AUTHOR"
>A. Romao</SPAN
>, <I
->Tools for <SPAN
+>Tools for <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Debugging</I
>, November 1994.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5288"
+NAME="AEN5284"
></A
><P
>[RFC1794]&nbsp;<SPAN
CLASS="AUTHOR"
>T. Brisco</SPAN
>, <I
-><SPAN
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Support for Load Balancing</I
>, April 1995.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5296"
+NAME="AEN5292"
></A
><P
>[RFC2240]&nbsp;<SPAN
@@ -1521,13 +1383,13 @@ CLASS="AUTHOR"
>, November 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5303"
+NAME="AEN5299"
></A
><P
>[RFC2345]&nbsp;<SPAN
@@ -1544,13 +1406,13 @@ CLASS="AUTHOR"
>, May 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5317"
+NAME="AEN5313"
></A
><P
>[RFC2352]&nbsp;<SPAN
@@ -1561,19 +1423,19 @@ CLASS="AUTHOR"
>, May 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
><H2
CLASS="bibliodiv"
><A
-NAME="AEN5324"
+NAME="AEN5320"
>Obsolete and Unimplemented Experimental RRs</A
></H2
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5326"
+NAME="AEN5322"
></A
><P
>[RFC1712]&nbsp;<SPAN
@@ -1589,15 +1451,15 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and D. Baldoni</SPAN
>, <I
-><SPAN
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Encoding of Geographical
Location</I
>, November 1994.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
></DIV
@@ -1624,23 +1486,23 @@ CLASS="sect2"
><H2
CLASS="sect2"
><A
-NAME="AEN5347"
->A.3.3. Other Documents About <SPAN
+NAME="AEN5343"
+>A.3.3. Other Documents About <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
></A
></H2
><P
></P
><H3
><A
-NAME="AEN5351"
+NAME="AEN5347"
>Bibliography</A
></H3
><DIV
CLASS="biblioentry"
><A
-NAME="AEN5352"
+NAME="AEN5348"
></A
><P
><SPAN
@@ -1650,17 +1512,17 @@ CLASS="AUTHOR"
CLASS="AUTHOR"
>and Cricket Liu</SPAN
>, <I
-><SPAN
+><ACRONYM
CLASS="acronym"
->DNS</SPAN
-> and <SPAN
+>DNS</ACRONYM
+> and <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
></I
>, 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left=0.5in"
+STYLE="margin-left: 0.5in"
></DIV
></DIV
></DIV
diff --git a/dist/bind/doc/arm/Bv9ARM.html b/dist/bind/doc/arm/Bv9ARM.html
index 65c1012d986..bf8b49e9679 100644
--- a/dist/bind/doc/arm/Bv9ARM.html
+++ b/dist/bind/doc/arm/Bv9ARM.html
@@ -1,11 +1,11 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>BIND 9 Administrator Reference Manual</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="NEXT"
TITLE="Introduction "
HREF="Bv9ARM.ch01.html"></HEAD
@@ -31,10 +31,10 @@ NAME="AEN1"
></H1
><P
CLASS="copyright"
->Copyright &copy; 2004 by Internet Systems Consortium, Inc. ("ISC")</P
+>Copyright &copy; 2004 Internet Systems Consortium, Inc. ("ISC")</P
><P
CLASS="copyright"
->Copyright &copy; 2000-2003 by Internet Software Consortium</P
+>Copyright &copy; 2000-2003 Internet Software Consortium</P
><HR></DIV
><DIV
CLASS="TOC"
@@ -68,9 +68,9 @@ HREF="Bv9ARM.ch01.html#AEN42"
><DT
>1.4. <A
HREF="Bv9ARM.ch01.html#AEN107"
->The Domain Name System (<SPAN
+>The Domain Name System (<ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
>)</A
></DT
><DD
@@ -112,9 +112,9 @@ HREF="Bv9ARM.ch01.html#AEN218"
><DT
>2. <A
HREF="Bv9ARM.ch02.html"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> Resource Requirements</A
></DT
><DD
@@ -292,49 +292,39 @@ HREF="Bv9ARM.ch04.html#DNSSEC"
><DL
><DT
>4.8.1. <A
-HREF="Bv9ARM.ch04.html#AEN951"
+HREF="Bv9ARM.ch04.html#AEN952"
>Generating Keys</A
></DT
><DT
>4.8.2. <A
-HREF="Bv9ARM.ch04.html#AEN971"
->Creating a Keyset</A
-></DT
-><DT
->4.8.3. <A
-HREF="Bv9ARM.ch04.html#AEN983"
->Signing the Child's Keyset</A
-></DT
-><DT
->4.8.4. <A
-HREF="Bv9ARM.ch04.html#AEN996"
+HREF="Bv9ARM.ch04.html#AEN972"
>Signing the Zone</A
></DT
><DT
->4.8.5. <A
-HREF="Bv9ARM.ch04.html#AEN1012"
+>4.8.3. <A
+HREF="Bv9ARM.ch04.html#AEN994"
>Configuring Servers</A
></DT
></DL
></DD
><DT
>4.9. <A
-HREF="Bv9ARM.ch04.html#AEN1019"
->IPv6 Support in <SPAN
+HREF="Bv9ARM.ch04.html#AEN1001"
+>IPv6 Support in <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9</A
></DT
><DD
><DL
><DT
>4.9.1. <A
-HREF="Bv9ARM.ch04.html#AEN1037"
+HREF="Bv9ARM.ch04.html#AEN1019"
>Address Lookups Using AAAA Records</A
></DT
><DT
>4.9.2. <A
-HREF="Bv9ARM.ch04.html#AEN1043"
+HREF="Bv9ARM.ch04.html#AEN1025"
>Address to Name Lookups Using Nibble Format</A
></DT
></DL
@@ -344,16 +334,16 @@ HREF="Bv9ARM.ch04.html#AEN1043"
><DT
>5. <A
HREF="Bv9ARM.ch05.html"
->The <SPAN
+>The <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Lightweight Resolver</A
></DT
><DD
><DL
><DT
>5.1. <A
-HREF="Bv9ARM.ch05.html#AEN1052"
+HREF="Bv9ARM.ch05.html#AEN1034"
>The Lightweight Resolver Library</A
></DT
><DT
@@ -366,9 +356,9 @@ HREF="Bv9ARM.ch05.html#lwresd"
><DT
>6. <A
HREF="Bv9ARM.ch06.html"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Configuration Reference</A
></DT
><DD
@@ -387,7 +377,7 @@ HREF="Bv9ARM.ch06.html#address_match_lists"
></DT
><DT
>6.1.2. <A
-HREF="Bv9ARM.ch06.html#AEN1298"
+HREF="Bv9ARM.ch06.html#AEN1280"
>Comment Syntax</A
></DT
></DL
@@ -401,7 +391,7 @@ HREF="Bv9ARM.ch06.html#Configuration_File_Grammar"
><DL
><DT
>6.2.1. <A
-HREF="Bv9ARM.ch06.html#AEN1419"
+HREF="Bv9ARM.ch06.html#AEN1401"
><B
CLASS="command"
>acl</B
@@ -418,7 +408,7 @@ Usage</A
></DT
><DT
>6.2.3. <A
-HREF="Bv9ARM.ch06.html#AEN1463"
+HREF="Bv9ARM.ch06.html#AEN1445"
><B
CLASS="command"
>controls</B
@@ -434,7 +424,7 @@ CLASS="command"
></DT
><DT
>6.2.5. <A
-HREF="Bv9ARM.ch06.html#AEN1542"
+HREF="Bv9ARM.ch06.html#AEN1524"
><B
CLASS="command"
>include</B
@@ -442,7 +432,7 @@ CLASS="command"
></DT
><DT
>6.2.6. <A
-HREF="Bv9ARM.ch06.html#AEN1547"
+HREF="Bv9ARM.ch06.html#AEN1529"
><B
CLASS="command"
>include</B
@@ -450,7 +440,7 @@ CLASS="command"
></DT
><DT
>6.2.7. <A
-HREF="Bv9ARM.ch06.html#AEN1554"
+HREF="Bv9ARM.ch06.html#AEN1536"
><B
CLASS="command"
>key</B
@@ -458,7 +448,7 @@ CLASS="command"
></DT
><DT
>6.2.8. <A
-HREF="Bv9ARM.ch06.html#AEN1561"
+HREF="Bv9ARM.ch06.html#AEN1543"
><B
CLASS="command"
>key</B
@@ -466,7 +456,7 @@ CLASS="command"
></DT
><DT
>6.2.9. <A
-HREF="Bv9ARM.ch06.html#AEN1581"
+HREF="Bv9ARM.ch06.html#AEN1563"
><B
CLASS="command"
>logging</B
@@ -474,7 +464,7 @@ CLASS="command"
></DT
><DT
>6.2.10. <A
-HREF="Bv9ARM.ch06.html#AEN1621"
+HREF="Bv9ARM.ch06.html#AEN1603"
><B
CLASS="command"
>logging</B
@@ -482,7 +472,7 @@ CLASS="command"
></DT
><DT
>6.2.11. <A
-HREF="Bv9ARM.ch06.html#AEN1887"
+HREF="Bv9ARM.ch06.html#AEN1873"
><B
CLASS="command"
>lwres</B
@@ -490,7 +480,7 @@ CLASS="command"
></DT
><DT
>6.2.12. <A
-HREF="Bv9ARM.ch06.html#AEN1911"
+HREF="Bv9ARM.ch06.html#AEN1897"
><B
CLASS="command"
>lwres</B
@@ -498,7 +488,7 @@ CLASS="command"
></DT
><DT
>6.2.13. <A
-HREF="Bv9ARM.ch06.html#AEN1930"
+HREF="Bv9ARM.ch06.html#AEN1916"
><B
CLASS="command"
>masters</B
@@ -506,7 +496,7 @@ CLASS="command"
></DT
><DT
>6.2.14. <A
-HREF="Bv9ARM.ch06.html#AEN1945"
+HREF="Bv9ARM.ch06.html#AEN1931"
><B
CLASS="command"
>masters</B
@@ -514,7 +504,7 @@ CLASS="command"
></DT
><DT
>6.2.15. <A
-HREF="Bv9ARM.ch06.html#AEN1950"
+HREF="Bv9ARM.ch06.html#AEN1936"
><B
CLASS="command"
>options</B
@@ -546,7 +536,7 @@ CLASS="command"
></DT
><DT
>6.2.19. <A
-HREF="Bv9ARM.ch06.html#AEN3405"
+HREF="Bv9ARM.ch06.html#AEN3402"
><B
CLASS="command"
>trusted-keys</B
@@ -554,7 +544,7 @@ CLASS="command"
></DT
><DT
>6.2.20. <A
-HREF="Bv9ARM.ch06.html#AEN3421"
+HREF="Bv9ARM.ch06.html#AEN3418"
><B
CLASS="command"
>trusted-keys</B
@@ -571,7 +561,7 @@ CLASS="command"
></DT
><DT
>6.2.22. <A
-HREF="Bv9ARM.ch06.html#AEN3443"
+HREF="Bv9ARM.ch06.html#AEN3440"
><B
CLASS="command"
>view</B
@@ -588,7 +578,7 @@ Statement Grammar</A
></DT
><DT
>6.2.24. <A
-HREF="Bv9ARM.ch06.html#AEN3617"
+HREF="Bv9ARM.ch06.html#AEN3614"
><B
CLASS="command"
>zone</B
@@ -598,7 +588,7 @@ CLASS="command"
></DD
><DT
>6.3. <A
-HREF="Bv9ARM.ch06.html#AEN4019"
+HREF="Bv9ARM.ch06.html#AEN4015"
>Zone File</A
></DT
><DD
@@ -610,7 +600,7 @@ HREF="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them"
></DT
><DT
>6.3.2. <A
-HREF="Bv9ARM.ch06.html#AEN4339"
+HREF="Bv9ARM.ch06.html#AEN4335"
>Discussion of MX Records</A
></DT
><DT
@@ -620,20 +610,20 @@ HREF="Bv9ARM.ch06.html#Setting_TTLs"
></DT
><DT
>6.3.4. <A
-HREF="Bv9ARM.ch06.html#AEN4460"
+HREF="Bv9ARM.ch06.html#AEN4456"
>Inverse Mapping in IPv4</A
></DT
><DT
>6.3.5. <A
-HREF="Bv9ARM.ch06.html#AEN4487"
+HREF="Bv9ARM.ch06.html#AEN4483"
>Other Zone File Directives</A
></DT
><DT
>6.3.6. <A
-HREF="Bv9ARM.ch06.html#AEN4545"
-><SPAN
+HREF="Bv9ARM.ch06.html#AEN4541"
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> Master File Extension: the <B
CLASS="command"
>$GENERATE</B
@@ -646,9 +636,9 @@ CLASS="command"
><DT
>7. <A
HREF="Bv9ARM.ch07.html"
-><SPAN
+><ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
> 9 Security Considerations</A
></DT
><DD
@@ -660,7 +650,7 @@ HREF="Bv9ARM.ch07.html#Access_Control_Lists"
></DT
><DT
>7.2. <A
-HREF="Bv9ARM.ch07.html#AEN4662"
+HREF="Bv9ARM.ch07.html#AEN4658"
><B
CLASS="command"
>chroot</B
@@ -674,7 +664,7 @@ UNIX servers)</A
><DL
><DT
>7.2.1. <A
-HREF="Bv9ARM.ch07.html#AEN4685"
+HREF="Bv9ARM.ch07.html#AEN4681"
>The <B
CLASS="command"
>chroot</B
@@ -682,7 +672,7 @@ CLASS="command"
></DT
><DT
>7.2.2. <A
-HREF="Bv9ARM.ch07.html#AEN4703"
+HREF="Bv9ARM.ch07.html#AEN4699"
>Using the <B
CLASS="command"
>setuid</B
@@ -706,26 +696,26 @@ HREF="Bv9ARM.ch08.html"
><DL
><DT
>8.1. <A
-HREF="Bv9ARM.ch08.html#AEN4724"
+HREF="Bv9ARM.ch08.html#AEN4720"
>Common Problems</A
></DT
><DD
><DL
><DT
>8.1.1. <A
-HREF="Bv9ARM.ch08.html#AEN4726"
+HREF="Bv9ARM.ch08.html#AEN4722"
>It's not working; how can I figure out what's wrong?</A
></DT
></DL
></DD
><DT
>8.2. <A
-HREF="Bv9ARM.ch08.html#AEN4729"
+HREF="Bv9ARM.ch08.html#AEN4725"
>Incrementing and Changing the Serial Number</A
></DT
><DT
>8.3. <A
-HREF="Bv9ARM.ch08.html#AEN4734"
+HREF="Bv9ARM.ch08.html#AEN4730"
>Where Can I Get Help?</A
></DT
></DL
@@ -739,20 +729,20 @@ HREF="Bv9ARM.ch09.html"
><DL
><DT
>A.1. <A
-HREF="Bv9ARM.ch09.html#AEN4750"
+HREF="Bv9ARM.ch09.html#AEN4746"
>Acknowledgments</A
></DT
><DD
><DL
><DT
>A.1.1. <A
-HREF="Bv9ARM.ch09.html#AEN4752"
->A Brief History of the <SPAN
+HREF="Bv9ARM.ch09.html#AEN4748"
+>A Brief History of the <ACRONYM
CLASS="acronym"
->DNS</SPAN
-> and <SPAN
+>DNS</ACRONYM
+> and <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
></A
></DT
></DL
@@ -760,9 +750,9 @@ CLASS="acronym"
><DT
>A.2. <A
HREF="Bv9ARM.ch09.html#historical_dns_information"
->General <SPAN
+>General <ACRONYM
CLASS="acronym"
->DNS</SPAN
+>DNS</ACRONYM
> Reference Information</A
></DT
><DD
@@ -793,10 +783,10 @@ HREF="Bv9ARM.ch09.html#internet_drafts"
></DT
><DT
>A.3.3. <A
-HREF="Bv9ARM.ch09.html#AEN5347"
->Other Documents About <SPAN
+HREF="Bv9ARM.ch09.html#AEN5343"
+>Other Documents About <ACRONYM
CLASS="acronym"
->BIND</SPAN
+>BIND</ACRONYM
></A
></DT
></DL
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
new file mode 100644
index 00000000000..09776618f2a
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
@@ -0,0 +1,561 @@
+
+
+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/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
new file mode 100644
index 00000000000..0783e7b26e1
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
@@ -0,0 +1,1457 @@
+
+
+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/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
new file mode 100644
index 00000000000..5728b35c9ba
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
@@ -0,0 +1,3193 @@
+
+
+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/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
new file mode 100644
index 00000000000..79a17284357
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
@@ -0,0 +1,1849 @@
+
+
+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/dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt
new file mode 100644
index 00000000000..4cfd417804d
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt
@@ -0,0 +1,639 @@
+
+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/dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt
new file mode 100644
index 00000000000..123d3cc0961
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt
@@ -0,0 +1,335 @@
+
+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/dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt b/dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt
new file mode 100644
index 00000000000..8dcacc8bb9e
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt
@@ -0,0 +1,1559 @@
+
+
+
+
+
+
+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/dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
new file mode 100644
index 00000000000..1133b0c87d4
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
@@ -0,0 +1,466 @@
+
+
+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/dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
new file mode 100644
index 00000000000..04815175fdb
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
@@ -0,0 +1,1344 @@
+
+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/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
new file mode 100644
index 00000000000..42c3c0b7c7e
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
@@ -0,0 +1,1321 @@
+
+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/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
new file mode 100644
index 00000000000..b14f711d531
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
@@ -0,0 +1,1969 @@
+
+
+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/dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
new file mode 100644
index 00000000000..2311ee6c18a
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
@@ -0,0 +1,391 @@
+
+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/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt
new file mode 100644
index 00000000000..f6ece882103
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt
@@ -0,0 +1,485 @@
+ 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/dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt b/dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt
new file mode 100644
index 00000000000..b593c57179e
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt
@@ -0,0 +1,617 @@
+
+
+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/dist/bind/doc/draft/update b/dist/bind/doc/draft/update
index 766f15b08e6..6ac20904ab2 100644
--- a/dist/bind/doc/draft/update
+++ b/dist/bind/doc/draft/update
@@ -1,4 +1,5 @@
#!/bin/sh
+commit=
for i
do
z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
@@ -34,9 +35,12 @@ do
then
rm $old
cvs delete $old
- else
- old=
+ commit="$commit $old"
fi
- cvs commit -m "new draft" $i $old
+ commit="$commit $i"
fi
done
+if test -n "$commit"
+then
+ cvs commit -m "new draft" $commit
+fi
diff --git a/dist/bind/doc/misc/ipv6 b/dist/bind/doc/misc/ipv6
index 21c90eedaf1..735f3dcaaaf 100644
--- a/dist/bind/doc/misc/ipv6
+++ b/dist/bind/doc/misc/ipv6
@@ -29,27 +29,40 @@ 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
+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
+::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.
-In bind9, we always bind to the ipv6 wildcard port for both TCP and
-UDP, and specific addresses for ipv4 sockets. This causes some
-interesting behavior depending on the system implementation of ipv6.
+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 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.
+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
@@ -90,11 +103,11 @@ packets.
RELEVANT RFCs
-------------
-2373: IP Version 6 Addressing Architecture
+3513: Internet Protocol Version 6 (IPv6) Addressing Architecture
-2553: Basic Socket Interface Extensions for IPv6
+3493: Basic Socket Interface Extensions for IPv6
-draft-ietf-ipngwg-rfc2292bis-01: Advanced Sockets API for IPv6 (draft)
+3542: Advanced Sockets Application Program Interface (API) for IPv6
-Id: ipv6,v 1.5.206.1 2004/03/06 13:16:19 marka Exp
+Id: ipv6,v 1.5.206.4 2004/08/10 04:28:15 jinmei Exp
diff --git a/dist/bind/doc/misc/options b/dist/bind/doc/misc/options
index 8eec93f4cae..f77e4940c58 100644
--- a/dist/bind/doc/misc/options
+++ b/dist/bind/doc/misc/options
@@ -82,7 +82,7 @@ options {
root-delegation-only [ exclude { <quoted_string>; ... } ];
disable-algorithms <string> { <string>; ... };
dnssec-enable <boolean>;
- dnssec-lookaside <string>;
+ dnssec-lookaside <string> trust-anchor <string>;
dnssec-must-be-secure <string> <boolean>;
allow-query { <address_match_element>; ... };
allow-transfer { <address_match_element>; ... };
@@ -262,7 +262,7 @@ view <string> <optional_class> {
root-delegation-only [ exclude { <quoted_string>; ... } ];
disable-algorithms <string> { <string>; ... };
dnssec-enable <boolean>;
- dnssec-lookaside <string>;
+ dnssec-lookaside <string> trust-anchor <string>;
dnssec-must-be-secure <string> <boolean>;
allow-query { <address_match_element>; ... };
allow-transfer { <address_match_element>; ... };
diff --git a/dist/bind/doc/rfc/index b/dist/bind/doc/rfc/index
index fd66d2472ce..fb72ccc314d 100644
--- a/dist/bind/doc/rfc/index
+++ b/dist/bind/doc/rfc/index
@@ -61,8 +61,9 @@
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
+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)
@@ -89,3 +90,5 @@
Secret Key Transaction Authentication for DNS (GSS-TSIG)
3655: Redefinition of DNS Authenticated Data (AD) bit
3658: Delegation Signer (DS) Resource Record (RR)
+3833: Threat Analysis of the Domain Name System (DNS)
+3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
diff --git a/dist/bind/doc/rfc/rfc3833.txt b/dist/bind/doc/rfc/rfc3833.txt
new file mode 100644
index 00000000000..8ce4d34e341
--- /dev/null
+++ b/dist/bind/doc/rfc/rfc3833.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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/dist/bind/doc/rfc/rfc3845.txt b/dist/bind/doc/rfc/rfc3845.txt
new file mode 100644
index 00000000000..9887a20af0b
--- /dev/null
+++ b/dist/bind/doc/rfc/rfc3845.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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]
+