diff options
| author | LaMont Jones <lamont@debian.org> | 2009-11-16 19:28:07 -0600 |
|---|---|---|
| committer | LaMont Jones <lamont@debian.org> | 2009-11-16 19:28:07 -0600 |
| commit | 8326481b01c0e7a76fe04c2ded97d375c319004a (patch) | |
| tree | 2470e488e2d08798913bf12075657c5c0cecedc9 /doc | |
| parent | b2492ab7a9f3eb7cc37ac3f1fd6b173979ffd2b0 (diff) | |
| download | bind9-8326481b01c0e7a76fe04c2ded97d375c319004a.tar.gz | |
9.7.0b2
Diffstat (limited to 'doc')
29 files changed, 4351 insertions, 454 deletions
diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index c92446a2..9ea53bcc 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -18,7 +18,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- File: $Id: Bv9ARM-book.xml,v 1.437 2009/10/16 02:59:41 each Exp $ --> +<!-- File: $Id: Bv9ARM-book.xml,v 1.440 2009/10/26 23:14:53 each Exp $ --> <book xmlns:xi="http://www.w3.org/2001/XInclude"> <title>BIND 9 Administrator Reference Manual</title> @@ -5000,6 +5000,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] <optional> random-device <replaceable>path_name</replaceable> ; </optional> <optional> max-cache-size <replaceable>size_spec</replaceable> ; </optional> <optional> match-mapped-addresses <replaceable>yes_or_no</replaceable>; </optional> + <optional> match-mapped-addresses <replaceable>yes_or_no</replaceable>; </optional> + <optional> disable-aaaa-on-v4-transport ( <replaceable>yes_or_no</replaceable> | <replaceable>break-dnssec</replaceable> ); </optional> <optional> preferred-glue ( <replaceable>A</replaceable> | <replaceable>AAAA</replaceable> | <replaceable>NONE</replaceable> ); </optional> <optional> edns-udp-size <replaceable>number</replaceable>; </optional> <optional> max-udp-size <replaceable>number</replaceable>; </optional> @@ -5165,9 +5167,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] When performing dynamic update of secure zones, the directory where the public and private DNSSEC key files should be found, if different than the current working - directory. The directory specified must be an absolute - path. (Note that this option has no effect on the paths - for files containing non-DNSSEC keys such as + directory. (Note that this option has no effect on the + paths for files containing non-DNSSEC keys such as <filename>bind.keys</filename>, <filename>rndc.key</filename> or <filename>session.key</filename>.) @@ -6234,6 +6235,59 @@ options { </varlistentry> <varlistentry> + <term><command>filter-aaaa-on-v4</command></term> + <listitem> + <para> + This option is only available when + <acronym>BIND</acronym> 9 is compiled with the + <userinput>--with-filter-aaaa</userinput> option on the + "configure" command line. It is intended to help the + transition from IPv4 to IPv6 by not giving IPv6 addresses + to DNS clients unless they have connections to the IPv6 + Internet. This is not recommended unless absolutely + necessary. The default is <userinput>no</userinput>. + </para> + <para> + If <userinput>yes</userinput>, + the DNS client is at an IPv4 address, + and if the response does not include DNSSEC signatures, + then all AAAA records are deleted from the response. + This filtering applies to all responses and not only + authoritative responses. + </para> + <para> + If <userinput>break-dnssec</userinput>, + then AAAA records are deleted even when dnssec is enabled. + As suggested by the name, this makes the response not verify, + because the DNSSEC protocol is designed detect deletions. + </para> + <para> + This mechanism can erroneously cause other servers to + not give AAAA records to their clients. + A recursing server with both IPv6 and IPv4 network connections + that queries an authoritative server using this mechanism + via IPv4 will be denied AAAA records even if its client is + using IPv6. + </para> + <para> + This mechanism is applied to authoritative as well as + non-authoritative records. + A client using IPv4 that is not allowed recursion can + erroneously be given AAAA records because the server is not + allowed to check for A records. + </para> + <para> + Some AAAA records are given to IPv4 clients in glue records. + IPv4 clients that are servers can then erroneously + answer requests for AAAA records received via IPv4. + </para> + <para> + security + </para> + </listitem> + </varlistentry> + + <varlistentry> <term><command>ixfr-from-differences</command></term> <listitem> <para> @@ -9232,6 +9286,21 @@ deny-answer-aliases { "example.net"; }; <command>managed-keys</command> may only be set at the top level of <filename>named.conf</filename>, not within a view. </para> + <para> + In the current implementation, the managed keys database is + stored as a master-format zone file called + <filename>managed-keys.bind</filename>. When the key database + is changed, the zone is updated. As with any other dynamic + zone, changes will be written into a journal file, + <filename>managed-keys.bind.jnl</filename>. They are committed + to the master file as soon as possible afterward; in the case + of the managed key database, this will usually occur within 30 + seconds. So, whenever <command>named</command> is using + automatic key maintenace, those two files can be expected to + exist in the working directory. (For this reason among others, + the working directory should be always be writable by + <command>named</command>.) + </para> <para> If the <command>dnssec-lookaside</command> option is set to <userinput>auto</userinput>, <command>named</command> diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html index b5a0dd3c..eb14f33e 100644 --- a/doc/arm/Bv9ARM.ch06.html +++ b/doc/arm/Bv9ARM.ch06.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: Bv9ARM.ch06.html,v 1.238 2009/10/16 04:20:33 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch06.html,v 1.240 2009/10/27 01:14:46 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -78,28 +78,28 @@ <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and Usage</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#statschannels"><span><strong class="command">statistics-channels</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587829"><span><strong class="command">statistics-channels</strong></span> Statement Definition and +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587897"><span><strong class="command">statistics-channels</strong></span> Statement Definition and Usage</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587984"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588035"><span><strong class="command">trusted-keys</strong></span> Statement Definition +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588052"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588171"><span><strong class="command">trusted-keys</strong></span> Statement Definition and Usage</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588082"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588133"><span><strong class="command">managed-keys</strong></span> Statement Definition +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588218"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588269"><span><strong class="command">managed-keys</strong></span> Statement Definition and Usage</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588489"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588573"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590199"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590147"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt> </dl></dd> -<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2592933">Zone File</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2593017">Zone File</a></span></dt> <dd><dl> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595027">Discussion of MX Records</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595111">Discussion of MX Records</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595710">Inverse Mapping in IPv4</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595906">Other Zone File Directives</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596179"><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595795">Inverse Mapping in IPv4</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595922">Other Zone File Directives</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596195"><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt> </dl></dd> <dt><span class="sect1"><a href="Bv9ARM.ch06.html#statistics">BIND9 Statistics</a></span></dt> @@ -2220,6 +2220,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] [<span class="optional"> random-device <em class="replaceable"><code>path_name</code></em> ; </span>] [<span class="optional"> max-cache-size <em class="replaceable"><code>size_spec</code></em> ; </span>] [<span class="optional"> match-mapped-addresses <em class="replaceable"><code>yes_or_no</code></em>; </span>] + [<span class="optional"> match-mapped-addresses <em class="replaceable"><code>yes_or_no</code></em>; </span>] + [<span class="optional"> disable-aaaa-on-v4-transport ( <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>break-dnssec</code></em> ); </span>] [<span class="optional"> preferred-glue ( <em class="replaceable"><code>A</code></em> | <em class="replaceable"><code>AAAA</code></em> | <em class="replaceable"><code>NONE</code></em> ); </span>] [<span class="optional"> edns-udp-size <em class="replaceable"><code>number</code></em>; </span>] [<span class="optional"> max-udp-size <em class="replaceable"><code>number</code></em>; </span>] @@ -2363,9 +2365,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] When performing dynamic update of secure zones, the directory where the public and private DNSSEC key files should be found, if different than the current working - directory. The directory specified must be an absolute - path. (Note that this option has no effect on the paths - for files containing non-DNSSEC keys such as + directory. (Note that this option has no effect on the + paths for files containing non-DNSSEC keys such as <code class="filename">bind.keys</code>, <code class="filename">rndc.key</code> or <code class="filename">session.key</code>.) @@ -3208,6 +3209,56 @@ options { internally. The use of this option is discouraged. </p> </dd> +<dt><span class="term"><span><strong class="command">filter-aaaa-on-v4</strong></span></span></dt> +<dd> +<p> + This option is only available when + <acronym class="acronym">BIND</acronym> 9 is compiled with the + <strong class="userinput"><code>--with-filter-aaaa</code></strong> option on the + "configure" command line. It is intended to help the + transition from IPv4 to IPv6 by not giving IPv6 addresses + to DNS clients unless they have connections to the IPv6 + Internet. This is not recommended unless absolutely + necessary. The default is <strong class="userinput"><code>no</code></strong>. + </p> +<p> + If <strong class="userinput"><code>yes</code></strong>, + the DNS client is at an IPv4 address, + and if the response does not include DNSSEC signatures, + then all AAAA records are deleted from the response. + This filtering applies to all responses and not only + authoritative responses. + </p> +<p> + If <strong class="userinput"><code>break-dnssec</code></strong>, + then AAAA records are deleted even when dnssec is enabled. + As suggested by the name, this makes the response not verify, + because the DNSSEC protocol is designed detect deletions. + </p> +<p> + This mechanism can erroneously cause other servers to + not give AAAA records to their clients. + A recursing server with both IPv6 and IPv4 network connections + that queries an authoritative server using this mechanism + via IPv4 will be denied AAAA records even if its client is + using IPv6. + </p> +<p> + This mechanism is applied to authoritative as well as + non-authoritative records. + A client using IPv4 that is not allowed recursion can + erroneously be given AAAA records because the server is not + allowed to check for A records. + </p> +<p> + Some AAAA records are given to IPv4 clients in glue records. + IPv4 clients that are servers can then erroneously + answer requests for AAAA records received via IPv4. + </p> +<p> + security + </p> +</dd> <dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt> <dd> <p> @@ -3430,7 +3481,7 @@ options { </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2582679"></a>Forwarding</h4></div></div></div> +<a name="id2582747"></a>Forwarding</h4></div></div></div> <p> The forwarding facility can be used to create a large site-wide cache on a few servers, reducing traffic over links to external @@ -3474,7 +3525,7 @@ options { </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2582738"></a>Dual-stack Servers</h4></div></div></div> +<a name="id2582874"></a>Dual-stack Servers</h4></div></div></div> <p> Dual-stack servers are used as servers of last resort to work around @@ -3671,7 +3722,7 @@ options { </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2583243"></a>Interfaces</h4></div></div></div> +<a name="id2583380"></a>Interfaces</h4></div></div></div> <p> The interfaces and ports that the server will answer queries from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes @@ -4123,7 +4174,7 @@ avoid-v6-udp-ports {}; </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2584378"></a>UDP Port Lists</h4></div></div></div> +<a name="id2584583"></a>UDP Port Lists</h4></div></div></div> <p> <span><strong class="command">use-v4-udp-ports</strong></span>, <span><strong class="command">avoid-v4-udp-ports</strong></span>, @@ -4165,7 +4216,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2584438"></a>Operating System Resource Limits</h4></div></div></div> +<a name="id2584643"></a>Operating System Resource Limits</h4></div></div></div> <p> The server's usage of many system resources can be limited. Scaled values are allowed when specifying resource limits. For @@ -4327,7 +4378,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2584929"></a>Periodic Task Intervals</h4></div></div></div> +<a name="id2585065"></a>Periodic Task Intervals</h4></div></div></div> <div class="variablelist"><dl> <dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt> <dd><p> @@ -5123,7 +5174,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2587009"></a>Content Filtering</h4></div></div></div> +<a name="id2587077"></a>Content Filtering</h4></div></div></div> <p> <acronym class="acronym">BIND</acronym> 9 provides the ability to filter out DNS responses from external DNS servers containing @@ -5453,7 +5504,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2587829"></a><span><strong class="command">statistics-channels</strong></span> Statement Definition and +<a name="id2587897"></a><span><strong class="command">statistics-channels</strong></span> Statement Definition and Usage</h3></div></div></div> <p> The <span><strong class="command">statistics-channels</strong></span> statement @@ -5504,7 +5555,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2587984"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div> +<a name="id2588052"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div> <pre class="programlisting"><span><strong class="command">trusted-keys</strong></span> { <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional"> <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>] @@ -5513,7 +5564,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588035"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition +<a name="id2588171"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition and Usage</h3></div></div></div> <p> The <span><strong class="command">trusted-keys</strong></span> statement defines @@ -5553,7 +5604,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588082"></a><span><strong class="command">managed-keys</strong></span> Statement Grammar</h3></div></div></div> +<a name="id2588218"></a><span><strong class="command">managed-keys</strong></span> Statement Grammar</h3></div></div></div> <pre class="programlisting"><span><strong class="command">managed-keys</strong></span> { <em class="replaceable"><code>string</code></em> initial-key <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional"> <em class="replaceable"><code>string</code></em> initial-key <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>] @@ -5562,7 +5613,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588133"></a><span><strong class="command">managed-keys</strong></span> Statement Definition +<a name="id2588269"></a><span><strong class="command">managed-keys</strong></span> Statement Definition and Usage</h3></div></div></div> <p> The <span><strong class="command">managed-keys</strong></span> statement, like @@ -5649,6 +5700,21 @@ deny-answer-aliases { "example.net"; }; level of <code class="filename">named.conf</code>, not within a view. </p> <p> + In the current implementation, the managed keys database is + stored as a master-format zone file called + <code class="filename">managed-keys.bind</code>. When the key database + is changed, the zone is updated. As with any other dynamic + zone, changes will be written into a journal file, + <code class="filename">managed-keys.bind.jnl</code>. They are committed + to the master file as soon as possible afterward; in the case + of the managed key database, this will usually occur within 30 + seconds. So, whenever <span><strong class="command">named</strong></span> is using + automatic key maintenace, those two files can be expected to + exist in the working directory. (For this reason among others, + the working directory should be always be writable by + <span><strong class="command">named</strong></span>.) + </p> +<p> If the <span><strong class="command">dnssec-lookaside</strong></span> option is set to <strong class="userinput"><code>auto</code></strong>, <span><strong class="command">named</strong></span> will automatically initialize a managed key for the @@ -5673,7 +5739,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588489"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div> +<a name="id2588573"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div> <p> The <span><strong class="command">view</strong></span> statement is a powerful feature @@ -5953,10 +6019,10 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2590199"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div> +<a name="id2590147"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2590206"></a>Zone Types</h4></div></div></div> +<a name="id2590154"></a>Zone Types</h4></div></div></div> <div class="informaltable"><table border="1"> <colgroup> <col> @@ -6167,7 +6233,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2590634"></a>Class</h4></div></div></div> +<a name="id2590650"></a>Class</h4></div></div></div> <p> The zone's name may optionally be followed by a class. If a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>), @@ -6189,7 +6255,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2590667"></a>Zone Options</h4></div></div></div> +<a name="id2590752"></a>Zone Options</h4></div></div></div> <div class="variablelist"><dl> <dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt> <dd><p> @@ -6859,7 +6925,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="id2592933"></a>Zone File</h2></div></div></div> +<a name="id2593017"></a>Zone File</h2></div></div></div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div> @@ -6872,7 +6938,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </p> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2592951"></a>Resource Records</h4></div></div></div> +<a name="id2593035"></a>Resource Records</h4></div></div></div> <p> A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource @@ -7609,7 +7675,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2594506"></a>Textual expression of RRs</h4></div></div></div> +<a name="id2594659"></a>Textual expression of RRs</h4></div></div></div> <p> RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form @@ -7812,7 +7878,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2595027"></a>Discussion of MX Records</h3></div></div></div> +<a name="id2595111"></a>Discussion of MX Records</h3></div></div></div> <p> As described above, domain servers store information as a series of resource records, each of which contains a particular @@ -8068,7 +8134,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2595710"></a>Inverse Mapping in IPv4</h3></div></div></div> +<a name="id2595795"></a>Inverse Mapping in IPv4</h3></div></div></div> <p> Reverse name resolution (that is, translation from IP address to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> domain @@ -8129,7 +8195,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2595906"></a>Other Zone File Directives</h3></div></div></div> +<a name="id2595922"></a>Other Zone File Directives</h3></div></div></div> <p> The Master File Format was initially defined in RFC 1035 and has subsequently been extended. While the Master File Format @@ -8144,7 +8210,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </p> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2595996"></a>The <span><strong class="command">@</strong></span> (at-sign)</h4></div></div></div> +<a name="id2595944"></a>The <span><strong class="command">@</strong></span> (at-sign)</h4></div></div></div> <p> When used in the label (or name) field, the asperand or at-sign (@) symbol represents the current origin. @@ -8155,7 +8221,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2596012"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div> +<a name="id2595960"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div> <p> Syntax: <span><strong class="command">$ORIGIN</strong></span> <em class="replaceable"><code>domain-name</code></em> @@ -8184,7 +8250,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2596073"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div> +<a name="id2596089"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div> <p> Syntax: <span><strong class="command">$INCLUDE</strong></span> <em class="replaceable"><code>filename</code></em> @@ -8220,7 +8286,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2596142"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div> +<a name="id2596158"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div> <p> Syntax: <span><strong class="command">$TTL</strong></span> <em class="replaceable"><code>default-ttl</code></em> @@ -8239,7 +8305,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2596179"></a><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div> +<a name="id2596195"></a><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div> <p> Syntax: <span><strong class="command">$GENERATE</strong></span> <em class="replaceable"><code>range</code></em> @@ -8663,7 +8729,7 @@ HOST-127.EXAMPLE. MX 0 . </p> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2597132"></a>Name Server Statistics Counters</h4></div></div></div> +<a name="id2597148"></a>Name Server Statistics Counters</h4></div></div></div> <div class="informaltable"><table border="1"> <colgroup> <col> @@ -9220,7 +9286,7 @@ HOST-127.EXAMPLE. MX 0 . </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2598674"></a>Zone Maintenance Statistics Counters</h4></div></div></div> +<a name="id2598758"></a>Zone Maintenance Statistics Counters</h4></div></div></div> <div class="informaltable"><table border="1"> <colgroup> <col> @@ -9374,7 +9440,7 @@ HOST-127.EXAMPLE. MX 0 . </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2599125"></a>Resolver Statistics Counters</h4></div></div></div> +<a name="id2599209"></a>Resolver Statistics Counters</h4></div></div></div> <div class="informaltable"><table border="1"> <colgroup> <col> @@ -9757,7 +9823,7 @@ HOST-127.EXAMPLE. MX 0 . </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2600147"></a>Socket I/O Statistics Counters</h4></div></div></div> +<a name="id2600231"></a>Socket I/O Statistics Counters</h4></div></div></div> <p> Socket I/O statistics counters are defined per socket types, which are @@ -9912,7 +9978,7 @@ HOST-127.EXAMPLE. MX 0 . </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2600588"></a>Compatibility with <span class="emphasis"><em>BIND</em></span> 8 Counters</h4></div></div></div> +<a name="id2600673"></a>Compatibility with <span class="emphasis"><em>BIND</em></span> 8 Counters</h4></div></div></div> <p> Most statistics counters that were available in <span><strong class="command">BIND</strong></span> 8 are also supported in diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html index 836f16fb..50a850e1 100644 --- a/doc/arm/Bv9ARM.ch07.html +++ b/doc/arm/Bv9ARM.ch07.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: Bv9ARM.ch07.html,v 1.211 2009/10/16 04:20:33 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch07.html,v 1.212 2009/10/23 01:14:48 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -46,10 +46,10 @@ <p><b>Table of Contents</b></p> <dl> <dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt> -<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2600830"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2600915"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt> <dd><dl> -<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2600912">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2600971">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2600996">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2601056">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt> </dl></dd> <dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt> </dl> @@ -122,7 +122,7 @@ zone "example.com" { </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="id2600830"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span> +<a name="id2600915"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span> </h2></div></div></div> <p> On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym> @@ -148,7 +148,7 @@ zone "example.com" { </p> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2600912"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div> +<a name="id2600996"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div> <p> In order for a <span><strong class="command">chroot</strong></span> environment to @@ -176,7 +176,7 @@ zone "example.com" { </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2600971"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div> +<a name="id2601056"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div> <p> Prior to running the <span><strong class="command">named</strong></span> daemon, use diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html index d79c282d..239c5553 100644 --- a/doc/arm/Bv9ARM.ch08.html +++ b/doc/arm/Bv9ARM.ch08.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: Bv9ARM.ch08.html,v 1.210 2009/10/16 04:20:33 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch08.html,v 1.212 2009/10/27 01:14:46 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -45,18 +45,18 @@ <div class="toc"> <p><b>Table of Contents</b></p> <dl> -<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601120">Common Problems</a></span></dt> -<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2601125">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd> -<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601137">Incrementing and Changing the Serial Number</a></span></dt> -<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601154">Where Can I Get Help?</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601136">Common Problems</a></span></dt> +<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2601141">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601153">Incrementing and Changing the Serial Number</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601306">Where Can I Get Help?</a></span></dt> </dl> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="id2601120"></a>Common Problems</h2></div></div></div> +<a name="id2601136"></a>Common Problems</h2></div></div></div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2601125"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div> +<a name="id2601141"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div> <p> The best solution to solving installation and configuration issues is to take preventative measures by setting @@ -68,7 +68,7 @@ </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="id2601137"></a>Incrementing and Changing the Serial Number</h2></div></div></div> +<a name="id2601153"></a>Incrementing and Changing the Serial Number</h2></div></div></div> <p> Zone serial numbers are just numbers — they aren't date related. A lot of people set them to a number that @@ -95,7 +95,7 @@ </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="id2601154"></a>Where Can I Get Help?</h2></div></div></div> +<a name="id2601306"></a>Where Can I Get Help?</h2></div></div></div> <p> The Internet Systems Consortium (<acronym class="acronym">ISC</acronym>) offers a wide range diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html index 2aca0934..10c71407 100644 --- a/doc/arm/Bv9ARM.ch09.html +++ b/doc/arm/Bv9ARM.ch09.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: Bv9ARM.ch09.html,v 1.212 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch09.html,v 1.214 2009/10/27 01:14:44 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -45,21 +45,21 @@ <div class="toc"> <p><b>Table of Contents</b></p> <dl> -<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601216">Acknowledgments</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601368">Acknowledgments</a></span></dt> <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd> -<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601524">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601608">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt> <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd> <dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt> <dd><dl> <dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2604804">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2604888">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt> </dl></dd> </dl> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="id2601216"></a>Acknowledgments</h2></div></div></div> +<a name="id2601368"></a>Acknowledgments</h2></div></div></div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="historical_dns_information"></a>A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> @@ -162,7 +162,7 @@ </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="id2601524"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div> +<a name="id2601608"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="ipv6addresses"></a>IPv6 addresses (AAAA)</h3></div></div></div> @@ -250,17 +250,17 @@ </p> <div class="bibliography"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2601780"></a>Bibliography</h4></div></div></div> +<a name="id2601864"></a>Bibliography</h4></div></div></div> <div class="bibliodiv"> <h3 class="title">Standards</h3> <div class="biblioentry"> -<a name="id2601790"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p> +<a name="id2601875"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p> </div> <div class="biblioentry"> -<a name="id2601814"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names — Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p> +<a name="id2601898"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names — Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p> </div> <div class="biblioentry"> -<a name="id2601837"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names — Implementation and +<a name="id2601922"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names — Implementation and Specification</i>. </span><span class="pubdate">November 1987. </span></p> </div> </div> @@ -268,42 +268,42 @@ <h3 class="title"> <a name="proposed_standards"></a>Proposed Standards</h3> <div class="biblioentry"> -<a name="id2601874"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym> +<a name="id2601958"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym> Specification</i>. </span><span class="pubdate">July 1997. </span></p> </div> <div class="biblioentry"> -<a name="id2601900"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym> +<a name="id2601985"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym> Queries</i>. </span><span class="pubdate">March 1998. </span></p> </div> <div class="biblioentry"> -<a name="id2601926"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p> +<a name="id2602010"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p> </div> <div class="biblioentry"> -<a name="id2601950"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p> +<a name="id2602035"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p> </div> <div class="biblioentry"> -<a name="id2601974"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p> +<a name="id2602058"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p> </div> <div class="biblioentry"> -<a name="id2602029"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p> +<a name="id2602114"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p> </div> <div class="biblioentry"> -<a name="id2602056"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p> +<a name="id2602140"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p> </div> <div class="biblioentry"> -<a name="id2602083"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p> +<a name="id2602167"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2602145"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p> +<a name="id2602229"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2602174"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p> +<a name="id2602259"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2602204"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p> +<a name="id2602289"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2602231"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret +<a name="id2602315"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)</i>. </span><span class="pubdate">October 2003. </span></p> </div> @@ -312,19 +312,19 @@ <h3 class="title"> <acronym class="acronym">DNS</acronym> Security Proposed Standards</h3> <div class="biblioentry"> -<a name="id2602313"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p> +<a name="id2602397"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p> </div> <div class="biblioentry"> -<a name="id2602340"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p> +<a name="id2602424"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p> </div> <div class="biblioentry"> -<a name="id2602376"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p> +<a name="id2602460"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p> </div> <div class="biblioentry"> -<a name="id2602441"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p> +<a name="id2602525"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p> </div> <div class="biblioentry"> -<a name="id2602506"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS +<a name="id2602590"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p> </div> </div> @@ -332,146 +332,146 @@ <h3 class="title">Other Important RFCs About <acronym class="acronym">DNS</acronym> Implementation</h3> <div class="biblioentry"> -<a name="id2602580"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely +<a name="id2602664"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely Deployed <acronym class="acronym">DNS</acronym> Software.</i>. </span><span class="pubdate">October 1993. </span></p> </div> <div class="biblioentry"> -<a name="id2602605"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation +<a name="id2602690"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p> </div> <div class="biblioentry"> -<a name="id2602674"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p> +<a name="id2602758"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p> </div> <div class="biblioentry"> -<a name="id2602709"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym> +<a name="id2602793"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym> Queries for IPv6 Addresses</i>. </span><span class="pubdate">May 2005. </span></p> </div> </div> <div class="bibliodiv"> <h3 class="title">Resource Record Types</h3> <div class="biblioentry"> -<a name="id2602755"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p> +<a name="id2602839"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p> </div> <div class="biblioentry"> -<a name="id2602812"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p> +<a name="id2602897"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p> </div> <div class="biblioentry"> -<a name="id2602850"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using +<a name="id2602934"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using the Domain Name System</i>. </span><span class="pubdate">June 1997. </span></p> </div> <div class="biblioentry"> -<a name="id2602885"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the +<a name="id2602969"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the Domain Name System</i>. </span><span class="pubdate">January 1996. </span></p> </div> <div class="biblioentry"> -<a name="id2602939"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the +<a name="id2603024"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the Location of Services.</i>. </span><span class="pubdate">October 1996. </span></p> </div> <div class="biblioentry"> -<a name="id2602978"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to +<a name="id2603062"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to Distribute MIXER Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p> </div> <div class="biblioentry"> -<a name="id2603003"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p> +<a name="id2603088"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p> </div> <div class="biblioentry"> -<a name="id2603029"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p> +<a name="id2603113"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p> </div> <div class="biblioentry"> -<a name="id2603056"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p> +<a name="id2603140"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p> </div> <div class="biblioentry"> -<a name="id2603082"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p> +<a name="id2603166"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p> </div> <div class="biblioentry"> -<a name="id2603122"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p> +<a name="id2603206"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p> </div> <div class="biblioentry"> -<a name="id2603152"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p> +<a name="id2603236"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p> </div> <div class="biblioentry"> -<a name="id2603181"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p> +<a name="id2603266"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2603224"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p> +<a name="id2603308"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2603257"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p> +<a name="id2603341"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p> </div> <div class="biblioentry"> -<a name="id2603284"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p> +<a name="id2603368"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p> </div> <div class="biblioentry"> -<a name="id2603307"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP +<a name="id2603392"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP version 6</i>. </span><span class="pubdate">October 2003. </span></p> </div> <div class="biblioentry"> -<a name="id2603365"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p> +<a name="id2603449"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p> </div> </div> <div class="bibliodiv"> <h3 class="title"> <acronym class="acronym">DNS</acronym> and the Internet</h3> <div class="biblioentry"> -<a name="id2603397"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names +<a name="id2603481"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names and Other Types</i>. </span><span class="pubdate">April 1989. </span></p> </div> <div class="biblioentry"> -<a name="id2603422"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and +<a name="id2603507"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and Support</i>. </span><span class="pubdate">October 1989. </span></p> </div> <div class="biblioentry"> -<a name="id2603445"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p> +<a name="id2603529"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p> </div> <div class="biblioentry"> -<a name="id2603468"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p> +<a name="id2603553"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p> </div> <div class="biblioentry"> -<a name="id2603514"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p> +<a name="id2603598"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2603538"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p> +<a name="id2603622"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p> </div> </div> <div class="bibliodiv"> <h3 class="title"> <acronym class="acronym">DNS</acronym> Operations</h3> <div class="biblioentry"> -<a name="id2603595"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p> +<a name="id2603680"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p> </div> <div class="biblioentry"> -<a name="id2603619"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File +<a name="id2603771"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p> </div> <div class="biblioentry"> -<a name="id2603645"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and +<a name="id2603798"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p> </div> <div class="biblioentry"> -<a name="id2603672"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p> +<a name="id2603825"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p> </div> <div class="biblioentry"> -<a name="id2603708"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for +<a name="id2603861"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for Network Services.</i>. </span><span class="pubdate">October 1997. </span></p> </div> </div> <div class="bibliodiv"> <h3 class="title">Internationalized Domain Names</h3> <div class="biblioentry"> -<a name="id2603754"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names, +<a name="id2603907"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols</i>. </span><span class="pubdate">May 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2603786"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p> +<a name="id2603939"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p> </div> <div class="biblioentry"> -<a name="id2603832"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p> +<a name="id2603985"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p> </div> <div class="biblioentry"> -<a name="id2603867"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode +<a name="id2604020"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p> </div> @@ -487,47 +487,47 @@ </p> </div> <div class="biblioentry"> -<a name="id2603912"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String +<a name="id2604133"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String Attributes</i>. </span><span class="pubdate">May 1993. </span></p> </div> <div class="biblioentry"> -<a name="id2603934"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p> +<a name="id2604155"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p> </div> <div class="biblioentry"> -<a name="id2603960"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load +<a name="id2604181"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load Balancing</i>. </span><span class="pubdate">April 1995. </span></p> </div> <div class="biblioentry"> -<a name="id2604054"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p> +<a name="id2604206"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p> </div> <div class="biblioentry"> -<a name="id2604077"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p> +<a name="id2604230"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p> </div> <div class="biblioentry"> -<a name="id2604123"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p> +<a name="id2604276"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p> </div> <div class="biblioentry"> -<a name="id2604147"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p> +<a name="id2604299"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p> </div> <div class="biblioentry"> -<a name="id2604173"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via +<a name="id2604326"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via Shared Unicast Addresses</i>. </span><span class="pubdate">April 2002. </span></p> </div> <div class="biblioentry"> -<a name="id2604199"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p> +<a name="id2604352"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p> </div> </div> <div class="bibliodiv"> <h3 class="title">Obsolete and Unimplemented Experimental RFC</h3> <div class="biblioentry"> -<a name="id2604311"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical +<a name="id2604395"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical Location</i>. </span><span class="pubdate">November 1994. </span></p> </div> <div class="biblioentry"> -<a name="id2604369"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p> +<a name="id2604453"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p> </div> <div class="biblioentry"> -<a name="id2604395"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation +<a name="id2604480"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation and Renumbering</i>. </span><span class="pubdate">July 2000. </span></p> </div> </div> @@ -541,39 +541,39 @@ </p> </div> <div class="biblioentry"> -<a name="id2604443"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p> +<a name="id2604528"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p> </div> <div class="biblioentry"> -<a name="id2604483"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p> +<a name="id2604567"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p> </div> <div class="biblioentry"> -<a name="id2604509"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p> +<a name="id2604594"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p> </div> <div class="biblioentry"> -<a name="id2604539"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC) +<a name="id2604624"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC) Signing Authority</i>. </span><span class="pubdate">November 2000. </span></p> </div> <div class="biblioentry"> -<a name="id2604565"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p> +<a name="id2604649"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p> </div> <div class="biblioentry"> -<a name="id2604592"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p> +<a name="id2604676"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p> </div> <div class="biblioentry"> -<a name="id2604628"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p> +<a name="id2604712"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p> </div> <div class="biblioentry"> -<a name="id2604664"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p> +<a name="id2604748"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p> </div> <div class="biblioentry"> -<a name="id2604691"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p> +<a name="id2604775"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p> </div> <div class="biblioentry"> -<a name="id2604717"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record +<a name="id2604802"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag</i>. </span><span class="pubdate">April 2004. </span></p> </div> <div class="biblioentry"> -<a name="id2604762"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p> +<a name="id2604846"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p> </div> </div> </div> @@ -594,14 +594,14 @@ </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2604804"></a>Other Documents About <acronym class="acronym">BIND</acronym> +<a name="id2604888"></a>Other Documents About <acronym class="acronym">BIND</acronym> </h3></div></div></div> <p></p> <div class="bibliography"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2604813"></a>Bibliography</h4></div></div></div> +<a name="id2604898"></a>Bibliography</h4></div></div></div> <div class="biblioentry"> -<a name="id2604816"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p> +<a name="id2604900"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p> </div> </div> </div> diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html index 0727e92c..1d45adf2 100644 --- a/doc/arm/Bv9ARM.html +++ b/doc/arm/Bv9ARM.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: Bv9ARM.html,v 1.229 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: Bv9ARM.html,v 1.231 2009/10/27 01:14:45 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -157,28 +157,28 @@ <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and Usage</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#statschannels"><span><strong class="command">statistics-channels</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587829"><span><strong class="command">statistics-channels</strong></span> Statement Definition and +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587897"><span><strong class="command">statistics-channels</strong></span> Statement Definition and Usage</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587984"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588035"><span><strong class="command">trusted-keys</strong></span> Statement Definition +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588052"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588171"><span><strong class="command">trusted-keys</strong></span> Statement Definition and Usage</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588082"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588133"><span><strong class="command">managed-keys</strong></span> Statement Definition +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588218"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588269"><span><strong class="command">managed-keys</strong></span> Statement Definition and Usage</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588489"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588573"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590199"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590147"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt> </dl></dd> -<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2592933">Zone File</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2593017">Zone File</a></span></dt> <dd><dl> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595027">Discussion of MX Records</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595111">Discussion of MX Records</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595710">Inverse Mapping in IPv4</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595906">Other Zone File Directives</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596179"><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595795">Inverse Mapping in IPv4</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595922">Other Zone File Directives</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596195"><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt> </dl></dd> <dt><span class="sect1"><a href="Bv9ARM.ch06.html#statistics">BIND9 Statistics</a></span></dt> @@ -187,31 +187,31 @@ <dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</a></span></dt> <dd><dl> <dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt> -<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2600830"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2600915"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt> <dd><dl> -<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2600912">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2600971">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2600996">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2601056">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt> </dl></dd> <dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt> </dl></dd> <dt><span class="chapter"><a href="Bv9ARM.ch08.html">8. Troubleshooting</a></span></dt> <dd><dl> -<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601120">Common Problems</a></span></dt> -<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2601125">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd> -<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601137">Incrementing and Changing the Serial Number</a></span></dt> -<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601154">Where Can I Get Help?</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601136">Common Problems</a></span></dt> +<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2601141">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601153">Incrementing and Changing the Serial Number</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601306">Where Can I Get Help?</a></span></dt> </dl></dd> <dt><span class="appendix"><a href="Bv9ARM.ch09.html">A. Appendices</a></span></dt> <dd><dl> -<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601216">Acknowledgments</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601368">Acknowledgments</a></span></dt> <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd> -<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601524">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601608">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt> <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd> <dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt> <dd><dl> <dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt> <dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2604804">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2604888">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt> </dl></dd> </dl></dd> <dt><span class="reference"><a href="Bv9ARM.ch10.html">I. Manual pages</a></span></dt> diff --git a/doc/arm/man.ddns-confgen.html b/doc/arm/man.ddns-confgen.html index c4ae4d9d..7f54b3b9 100644 --- a/doc/arm/man.ddns-confgen.html +++ b/doc/arm/man.ddns-confgen.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.ddns-confgen.html,v 1.29 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.ddns-confgen.html,v 1.32 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -48,7 +48,7 @@ <div class="cmdsynopsis"><p><code class="command">ddns-confgen</code> [<code class="option">-a <em class="replaceable"><code>algorithm</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [ -s <em class="replaceable"><code>name</code></em> | -z <em class="replaceable"><code>zone</code></em> ] [<code class="option">-q</code>] [name]</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2636823"></a><h2>DESCRIPTION</h2> +<a name="id2637416"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">ddns-confgen</strong></span> generates a key for use by <span><strong class="command">nsupdate</strong></span> and <span><strong class="command">named</strong></span>. It simplifies configuration @@ -75,7 +75,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2636910"></a><h2>OPTIONS</h2> +<a name="id2637504"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt> <dd><p> @@ -142,7 +142,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2637111"></a><h2>SEE ALSO</h2> +<a name="id2637704"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">nsupdate</span>(1)</span>, <span class="citerefentry"><span class="refentrytitle">named.conf</span>(5)</span>, <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>, @@ -150,7 +150,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2637149"></a><h2>AUTHOR</h2> +<a name="id2637742"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html index 4f82e997..2160379f 100644 --- a/doc/arm/man.dig.html +++ b/doc/arm/man.dig.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.dig.html,v 1.129 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.dig.html,v 1.131 2009/10/27 01:14:45 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -52,7 +52,7 @@ <div class="cmdsynopsis"><p><code class="command">dig</code> [global-queryopt...] [query...]</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2563850"></a><h2>DESCRIPTION</h2> +<a name="id2563934"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">dig</strong></span> (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and @@ -98,7 +98,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2572205"></a><h2>SIMPLE USAGE</h2> +<a name="id2572290"></a><h2>SIMPLE USAGE</h2> <p> A typical invocation of <span><strong class="command">dig</strong></span> looks like: </p> @@ -144,7 +144,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2572316"></a><h2>OPTIONS</h2> +<a name="id2572401"></a><h2>OPTIONS</h2> <p> The <code class="option">-b</code> option sets the source IP address of the query to <em class="parameter"><code>address</code></em>. This must be a valid @@ -248,7 +248,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2631914"></a><h2>QUERY OPTIONS</h2> +<a name="id2632135"></a><h2>QUERY OPTIONS</h2> <p><span><strong class="command">dig</strong></span> provides a number of query options which affect the way in which lookups are made and the results displayed. Some of @@ -573,7 +573,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2633051"></a><h2>MULTIPLE QUERIES</h2> +<a name="id2633136"></a><h2>MULTIPLE QUERIES</h2> <p> The BIND 9 implementation of <span><strong class="command">dig </strong></span> supports @@ -619,7 +619,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr </p> </div> <div class="refsect1" lang="en"> -<a name="id2633137"></a><h2>IDN SUPPORT</h2> +<a name="id2633221"></a><h2>IDN SUPPORT</h2> <p> If <span><strong class="command">dig</strong></span> has been built with IDN (internationalized domain name) support, it can accept and display non-ASCII domain names. @@ -633,14 +633,14 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr </p> </div> <div class="refsect1" lang="en"> -<a name="id2633165"></a><h2>FILES</h2> +<a name="id2633250"></a><h2>FILES</h2> <p><code class="filename">/etc/resolv.conf</code> </p> <p><code class="filename">${HOME}/.digrc</code> </p> </div> <div class="refsect1" lang="en"> -<a name="id2633187"></a><h2>SEE ALSO</h2> +<a name="id2633271"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>, <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>, @@ -648,7 +648,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr </p> </div> <div class="refsect1" lang="en"> -<a name="id2633224"></a><h2>BUGS</h2> +<a name="id2633308"></a><h2>BUGS</h2> <p> There are probably too many query options. </p> diff --git a/doc/arm/man.dnssec-dsfromkey.html b/doc/arm/man.dnssec-dsfromkey.html index 173a778d..122e2b1c 100644 --- a/doc/arm/man.dnssec-dsfromkey.html +++ b/doc/arm/man.dnssec-dsfromkey.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.dnssec-dsfromkey.html,v 1.42 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.dnssec-dsfromkey.html,v 1.44 2009/10/27 01:14:44 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -51,14 +51,14 @@ <div class="cmdsynopsis"><p><code class="command">dnssec-dsfromkey</code> {-s} [<code class="option">-1</code>] [<code class="option">-2</code>] [<code class="option">-a <em class="replaceable"><code>alg</code></em></code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-s</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-f <em class="replaceable"><code>file</code></em></code>] [<code class="option">-A</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {dnsname}</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2605901"></a><h2>DESCRIPTION</h2> +<a name="id2605986"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">dnssec-dsfromkey</strong></span> outputs the Delegation Signer (DS) resource record (RR), as defined in RFC 3658 and RFC 4509, for the given key(s). </p> </div> <div class="refsect1" lang="en"> -<a name="id2605915"></a><h2>OPTIONS</h2> +<a name="id2606000"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-1</span></dt> <dd><p> @@ -119,7 +119,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2606104"></a><h2>EXAMPLE</h2> +<a name="id2606188"></a><h2>EXAMPLE</h2> <p> To build the SHA-256 DS RR from the <strong class="userinput"><code>Kexample.com.+003+26160</code></strong> @@ -134,7 +134,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2606140"></a><h2>FILES</h2> +<a name="id2606225"></a><h2>FILES</h2> <p> The keyfile can be designed by the key identification <code class="filename">Knnnn.+aaa+iiiii</code> or the full file name @@ -148,13 +148,13 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2606182"></a><h2>CAVEAT</h2> +<a name="id2606266"></a><h2>CAVEAT</h2> <p> A keyfile error can give a "file not found" even if the file exists. </p> </div> <div class="refsect1" lang="en"> -<a name="id2606192"></a><h2>SEE ALSO</h2> +<a name="id2606276"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>, <em class="citetitle">BIND 9 Administrator Reference Manual</em>, @@ -164,7 +164,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2606231"></a><h2>AUTHOR</h2> +<a name="id2606520"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.dnssec-keyfromlabel.html b/doc/arm/man.dnssec-keyfromlabel.html index 349fc51a..5836a1cf 100644 --- a/doc/arm/man.dnssec-keyfromlabel.html +++ b/doc/arm/man.dnssec-keyfromlabel.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.dnssec-keyfromlabel.html,v 1.71 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.dnssec-keyfromlabel.html,v 1.74 2009/10/27 01:14:44 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">dnssec-keyfromlabel</code> {-l <em class="replaceable"><code>label</code></em>} [<code class="option">-3</code>] [<code class="option">-a <em class="replaceable"><code>algorithm</code></em></code>] [<code class="option">-A <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-D <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-G</code>] [<code class="option">-I <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-k</code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-n <em class="replaceable"><code>nametype</code></em></code>] [<code class="option">-P <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-R <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {name}</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2606640"></a><h2>DESCRIPTION</h2> +<a name="id2606788"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">dnssec-keyfromlabel</strong></span> gets keys with the given label from a crypto hardware and builds key files for DNSSEC (Secure DNS), as defined in RFC 2535 @@ -63,20 +63,22 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2606660"></a><h2>OPTIONS</h2> +<a name="id2606808"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt> <dd> <p> Selects the cryptographic algorithm. The value of - <code class="option">algorithm</code> must be one of RSAMD5 (RSA), - RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA or DH (Diffie Hellman). + <code class="option">algorithm</code> must be one of RSAMD5, RSASHA1, + DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256 or RSASHA512. These values are case insensitive. </p> <p> If no algorithm is specified, then RSASHA1 will be used by default, unless the <code class="option">-3</code> option is specified, - in which case NSEC3RSASHA1 will be used instead. + in which case NSEC3RSASHA1 will be used instead. (If + <code class="option">-3</code> is used and an algorithm is specified, + that algorithm will be checked for compatibility with NSEC3.) </p> <p> Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement @@ -172,7 +174,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2607422"></a><h2>TIMING OPTIONS</h2> +<a name="id2607846"></a><h2>TIMING OPTIONS</h2> <p> Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS. If the argument begins with a '+' or '-', it is interpreted as @@ -194,7 +196,7 @@ <dt><span class="term">-A <em class="replaceable"><code>date/offset</code></em></span></dt> <dd><p> Sets the date on which the key is to be activated. After that - date, the key will be included and the zone and used to sign + date, the key will be included in the zone and used to sign it. If not set, and if the -G option has not been used, the default is "now". </p></dd> @@ -219,7 +221,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2610115"></a><h2>GENERATED KEY FILES</h2> +<a name="id2609856"></a><h2>GENERATED KEY FILES</h2> <p> When <span><strong class="command">dnssec-keyfromlabel</strong></span> completes successfully, @@ -258,17 +260,15 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2610209"></a><h2>SEE ALSO</h2> +<a name="id2650773"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>, <em class="citetitle">BIND 9 Administrator Reference Manual</em>, - <em class="citetitle">RFC 2539</em>, - <em class="citetitle">RFC 2845</em>, - <em class="citetitle">RFC 4033</em>. + <em class="citetitle">RFC 4034</em>. </p> </div> <div class="refsect1" lang="en"> -<a name="id2610248"></a><h2>AUTHOR</h2> +<a name="id2650806"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.dnssec-keygen.html b/doc/arm/man.dnssec-keygen.html index 8d6bf885..926ac96f 100644 --- a/doc/arm/man.dnssec-keygen.html +++ b/doc/arm/man.dnssec-keygen.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.dnssec-keygen.html,v 1.139 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.dnssec-keygen.html,v 1.143 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -47,10 +47,10 @@ </div> <div class="refsynopsisdiv"> <h2>Synopsis</h2> -<div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code> [<code class="option">-a <em class="replaceable"><code>algorithm</code></em></code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-n <em class="replaceable"><code>nametype</code></em></code>] [<code class="option">-3</code>] [<code class="option">-A <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-C</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-D <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-G</code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-I <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-k</code>] [<code class="option">-P <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-R <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {name}</p></div> +<div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code> [<code class="option">-a <em class="replaceable"><code>algorithm</code></em></code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-n <em class="replaceable"><code>nametype</code></em></code>] [<code class="option">-3</code>] [<code class="option">-A <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-C</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-D <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-G</code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-I <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-k</code>] [<code class="option">-P <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-q</code>] [<code class="option">-R <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {name}</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2608011"></a><h2>DESCRIPTION</h2> +<a name="id2608272"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">dnssec-keygen</strong></span> generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 and RFC 4034. It can also generate keys for use with @@ -64,14 +64,15 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2608032"></a><h2>OPTIONS</h2> +<a name="id2608292"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt> <dd> <p> Selects the cryptographic algorithm. For DNSSEC keys, the value of <code class="option">algorithm</code> must be one of RSAMD5, RSASHA1, - DSA, NSEC3RSASHA1, or NSEC3DSA. For TSIG/TKEY, the value must + DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256 or RSASHA512. + For TSIG/TKEY, the value must be DH (Diffie Hellman), HMAC-MD5, HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512. These values are case insensitive. @@ -79,7 +80,9 @@ <p> If no algorithm is specified, then RSASHA1 will be used by default, unless the <code class="option">-3</code> option is specified, - in which case NSEC3RSASHA1 will be used instead. + in which case NSEC3RSASHA1 will be used instead. (If + <code class="option">-3</code> is used and an algorithm is specified, + that algorithm will be checked for compatibility with NSEC3.) </p> <p> Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement @@ -95,10 +98,10 @@ <dd> <p> Specifies the number of bits in the key. The choice of key - size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be + size depends on the algorithm used. RSA keys must be between 512 and 2048 bits. Diffie Hellman keys must be between 128 and 4096 bits. DSA keys must be between 512 and 1024 - bits and an exact multiple of 64. HMAC-MD5 keys must be + bits and an exact multiple of 64. HMAC keys must be between 1 and 512 bits. </p> <p> @@ -126,7 +129,8 @@ Use an NSEC3-capable algorithm to generate a DNSSEC key. If this option is used and no algorithm is explicitly set on the command line, NSEC3RSASHA1 will be used by - default. + default. Note that RSASHA256 and RSASHA512 algorithms + are NSEC3-capable. </p></dd> <dt><span class="term">-C</span></dt> <dd><p> @@ -191,6 +195,20 @@ Other possible values for this argument are listed in RFC 2535 and its successors. </p></dd> +<dt><span class="term">-q</span></dt> +<dd><p> + Quiet mode: Suppresses unnecessary output, including + progress indication. Without this option, when + <span><strong class="command">dnssec-keygen</strong></span> is run interactively + to generate an RSA or DSA key pair, it will print a string + of symbols to <code class="filename">stderr</code> indicating the + progress of the key generation. A '.' indicates that a + random number has been found which passed an initial + sieve test; '+' means a number has passed a single + round of the Miller-Rabin primality test; a space + means that the number has passed all the tests and is + a satisfactory key. + </p></dd> <dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt> <dd><p> Specifies the source of randomness. If the operating @@ -238,7 +256,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2660317"></a><h2>TIMING OPTIONS</h2> +<a name="id2655962"></a><h2>TIMING OPTIONS</h2> <p> Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS. If the argument begins with a '+' or '-', it is interpreted as @@ -260,7 +278,7 @@ <dt><span class="term">-A <em class="replaceable"><code>date/offset</code></em></span></dt> <dd><p> Sets the date on which the key is to be activated. After that - date, the key will be included and the zone and used to sign + date, the key will be included in the zone and used to sign it. If not set, and if the -G option has not been used, the default is "now". </p></dd> @@ -285,7 +303,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2660416"></a><h2>GENERATED KEYS</h2> +<a name="id2656060"></a><h2>GENERATED KEYS</h2> <p> When <span><strong class="command">dnssec-keygen</strong></span> completes successfully, @@ -331,7 +349,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2660592"></a><h2>EXAMPLE</h2> +<a name="id2656236"></a><h2>EXAMPLE</h2> <p> To generate a 768-bit DSA key for the domain <strong class="userinput"><code>example.com</code></strong>, the following command would be @@ -352,16 +370,16 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2660648"></a><h2>SEE ALSO</h2> +<a name="id2656361"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>, <em class="citetitle">BIND 9 Administrator Reference Manual</em>, <em class="citetitle">RFC 2539</em>, <em class="citetitle">RFC 2845</em>, - <em class="citetitle">RFC 4033</em>. + <em class="citetitle">RFC 4034</em>. </p> </div> <div class="refsect1" lang="en"> -<a name="id2660679"></a><h2>AUTHOR</h2> +<a name="id2656392"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.dnssec-revoke.html b/doc/arm/man.dnssec-revoke.html index c86cd8c7..eb6a800b 100644 --- a/doc/arm/man.dnssec-revoke.html +++ b/doc/arm/man.dnssec-revoke.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.dnssec-revoke.html,v 1.23 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.dnssec-revoke.html,v 1.26 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">dnssec-revoke</code> [<code class="option">-hr</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-f</code>] {keyfile}</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2609203"></a><h2>DESCRIPTION</h2> +<a name="id2609523"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">dnssec-revoke</strong></span> reads a DNSSEC key file, sets the REVOKED bit on the key as defined in RFC 5011, and creates a new pair of key files containing the @@ -58,7 +58,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2609217"></a><h2>OPTIONS</h2> +<a name="id2609537"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-h</span></dt> <dd><p> @@ -91,14 +91,14 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2609324"></a><h2>SEE ALSO</h2> +<a name="id2609644"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>, <em class="citetitle">BIND 9 Administrator Reference Manual</em>, <em class="citetitle">RFC 5011</em>. </p> </div> <div class="refsect1" lang="en"> -<a name="id2609349"></a><h2>AUTHOR</h2> +<a name="id2609669"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.dnssec-settime.html b/doc/arm/man.dnssec-settime.html index 2a12858f..6d4c3a45 100644 --- a/doc/arm/man.dnssec-settime.html +++ b/doc/arm/man.dnssec-settime.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.dnssec-settime.html,v 1.17 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.dnssec-settime.html,v 1.21 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">dnssec-settime</code> [<code class="option">-f</code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-P <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-A <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-R <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-I <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-D <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-h</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] {keyfile}</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2609845"></a><h2>DESCRIPTION</h2> +<a name="id2610165"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">dnssec-settime</strong></span> reads a DNSSEC private key file and sets the key timing metadata as specified by the <code class="option">-P</code>, <code class="option">-A</code>, @@ -75,7 +75,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2610450"></a><h2>OPTIONS</h2> +<a name="id2610224"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-f</span></dt> <dd><p> @@ -106,7 +106,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2610544"></a><h2>TIMING OPTIONS</h2> +<a name="id2610454"></a><h2>TIMING OPTIONS</h2> <p> Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS. If the argument begins with a '+' or '-', it is interpreted as @@ -127,7 +127,7 @@ <dt><span class="term">-A <em class="replaceable"><code>date/offset</code></em></span></dt> <dd><p> Sets the date on which the key is to be activated. After that - date, the key will be included and the zone and used to sign + date, the key will be included in the zone and used to sign it. </p></dd> <dt><span class="term">-R <em class="replaceable"><code>date/offset</code></em></span></dt> @@ -151,7 +151,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2610710"></a><h2>PRINTING OPTIONS</h2> +<a name="id2610552"></a><h2>PRINTING OPTIONS</h2> <p> <span><strong class="command">dnssec-settime</strong></span> can also be used to print the timing metadata associated with a key. @@ -177,7 +177,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2610858"></a><h2>SEE ALSO</h2> +<a name="id2610632"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>, <em class="citetitle">BIND 9 Administrator Reference Manual</em>, @@ -185,7 +185,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2610891"></a><h2>AUTHOR</h2> +<a name="id2610665"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.dnssec-signzone.html b/doc/arm/man.dnssec-signzone.html index 6935cda1..ed082794 100644 --- a/doc/arm/man.dnssec-signzone.html +++ b/doc/arm/man.dnssec-signzone.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.dnssec-signzone.html,v 1.140 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.dnssec-signzone.html,v 1.143 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">dnssec-signzone</code> [<code class="option">-a</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-e <em class="replaceable"><code>end-time</code></em></code>] [<code class="option">-f <em class="replaceable"><code>output-file</code></em></code>] [<code class="option">-g</code>] [<code class="option">-h</code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</code></em></code>] [<code class="option">-p</code>] [<code class="option">-P</code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-S</code>] [<code class="option">-s <em class="replaceable"><code>start-time</code></em></code>] [<code class="option">-T <em class="replaceable"><code>ttl</code></em></code>] [<code class="option">-t</code>] [<code class="option">-u</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-x</code>] [<code class="option">-z</code>] [<code class="option">-3 <em class="replaceable"><code>salt</code></em></code>] [<code class="option">-H <em class="replaceable"><code>iterations</code></em></code>] [<code class="option">-A</code>] {zonefile} [key...]</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2611936"></a><h2>DESCRIPTION</h2> +<a name="id2611914"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">dnssec-signzone</strong></span> signs a zone. It generates NSEC and RRSIG records and produces a signed version of the @@ -61,7 +61,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2611955"></a><h2>OPTIONS</h2> +<a name="id2611933"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-a</span></dt> <dd><p> @@ -397,7 +397,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2661634"></a><h2>EXAMPLE</h2> +<a name="id2663865"></a><h2>EXAMPLE</h2> <p> The following command signs the <strong class="userinput"><code>example.com</code></strong> zone with the DSA key generated by <span><strong class="command">dnssec-keygen</strong></span> @@ -427,14 +427,14 @@ db.example.com.signed %</pre> </div> <div class="refsect1" lang="en"> -<a name="id2661713"></a><h2>SEE ALSO</h2> +<a name="id2663944"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>, <em class="citetitle">BIND 9 Administrator Reference Manual</em>, <em class="citetitle">RFC 4033</em>. </p> </div> <div class="refsect1" lang="en"> -<a name="id2661737"></a><h2>AUTHOR</h2> +<a name="id2663969"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.host.html b/doc/arm/man.host.html index 82f1d0b4..3a0f1c91 100644 --- a/doc/arm/man.host.html +++ b/doc/arm/man.host.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.host.html,v 1.127 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.host.html,v 1.129 2009/10/27 01:14:45 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">host</code> [<code class="option">-aCdlnrsTwv</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-N <em class="replaceable"><code>ndots</code></em></code>] [<code class="option">-R <em class="replaceable"><code>number</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-W <em class="replaceable"><code>wait</code></em></code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] {name} [server]</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2605152"></a><h2>DESCRIPTION</h2> +<a name="id2605168"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">host</strong></span> is a simple utility for performing DNS lookups. It is normally used to convert names to IP addresses and vice versa. @@ -202,7 +202,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2605529"></a><h2>IDN SUPPORT</h2> +<a name="id2605613"></a><h2>IDN SUPPORT</h2> <p> If <span><strong class="command">host</strong></span> has been built with IDN (internationalized domain name) support, it can accept and display non-ASCII domain names. @@ -216,12 +216,12 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2605558"></a><h2>FILES</h2> +<a name="id2605642"></a><h2>FILES</h2> <p><code class="filename">/etc/resolv.conf</code> </p> </div> <div class="refsect1" lang="en"> -<a name="id2605572"></a><h2>SEE ALSO</h2> +<a name="id2605656"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>, <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>. </p> diff --git a/doc/arm/man.named-checkconf.html b/doc/arm/man.named-checkconf.html index afbeff79..f4f8ea67 100644 --- a/doc/arm/man.named-checkconf.html +++ b/doc/arm/man.named-checkconf.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.named-checkconf.html,v 1.136 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.named-checkconf.html,v 1.138 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,14 +50,14 @@ <div class="cmdsynopsis"><p><code class="command">named-checkconf</code> [<code class="option">-h</code>] [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-p</code>] [<code class="option">-z</code>]</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2612403"></a><h2>DESCRIPTION</h2> +<a name="id2612381"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">named-checkconf</strong></span> checks the syntax, but not the semantics, of a named configuration file. </p> </div> <div class="refsect1" lang="en"> -<a name="id2612417"></a><h2>OPTIONS</h2> +<a name="id2612395"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-h</span></dt> <dd><p> @@ -96,21 +96,21 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2612551"></a><h2>RETURN VALUES</h2> +<a name="id2612530"></a><h2>RETURN VALUES</h2> <p><span><strong class="command">named-checkconf</strong></span> returns an exit status of 1 if errors were detected and 0 otherwise. </p> </div> <div class="refsect1" lang="en"> -<a name="id2612565"></a><h2>SEE ALSO</h2> +<a name="id2612544"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>, <em class="citetitle">BIND 9 Administrator Reference Manual</em>. </p> </div> <div class="refsect1" lang="en"> -<a name="id2612595"></a><h2>AUTHOR</h2> +<a name="id2612573"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.named-checkzone.html b/doc/arm/man.named-checkzone.html index 081fa671..5bec81bd 100644 --- a/doc/arm/man.named-checkzone.html +++ b/doc/arm/man.named-checkzone.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.named-checkzone.html,v 1.143 2009/10/16 04:20:33 tbox Exp $ --> +<!-- $Id: man.named-checkzone.html,v 1.146 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -51,7 +51,7 @@ <div class="cmdsynopsis"><p><code class="command">named-compilezone</code> [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-C <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2613175"></a><h2>DESCRIPTION</h2> +<a name="id2614041"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">named-checkzone</strong></span> checks the syntax and integrity of a zone file. It performs the same checks as <span><strong class="command">named</strong></span> does when loading a @@ -71,7 +71,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2613225"></a><h2>OPTIONS</h2> +<a name="id2614091"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-d</span></dt> <dd><p> @@ -257,14 +257,14 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2664139"></a><h2>RETURN VALUES</h2> +<a name="id2664732"></a><h2>RETURN VALUES</h2> <p><span><strong class="command">named-checkzone</strong></span> returns an exit status of 1 if errors were detected and 0 otherwise. </p> </div> <div class="refsect1" lang="en"> -<a name="id2664153"></a><h2>SEE ALSO</h2> +<a name="id2664746"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>, <em class="citetitle">RFC 1035</em>, @@ -272,7 +272,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2664186"></a><h2>AUTHOR</h2> +<a name="id2664779"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.named.html b/doc/arm/man.named.html index 339722af..58d36a16 100644 --- a/doc/arm/man.named.html +++ b/doc/arm/man.named.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.named.html,v 1.145 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.named.html,v 1.148 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">named</code> [<code class="option">-4</code>] [<code class="option">-6</code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine-name</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-S <em class="replaceable"><code>#max-socks</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>] [<code class="option">-V</code>] [<code class="option">-x <em class="replaceable"><code>cache-file</code></em></code>]</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2613776"></a><h2>DESCRIPTION</h2> +<a name="id2614369"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">named</strong></span> is a Domain Name System (DNS) server, part of the BIND 9 distribution from ISC. For more @@ -65,7 +65,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2613806"></a><h2>OPTIONS</h2> +<a name="id2614400"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-4</span></dt> <dd><p> @@ -246,7 +246,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2656276"></a><h2>SIGNALS</h2> +<a name="id2635024"></a><h2>SIGNALS</h2> <p> In routine operation, signals should not be used to control the nameserver; <span><strong class="command">rndc</strong></span> should be used @@ -267,7 +267,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2664245"></a><h2>CONFIGURATION</h2> +<a name="id2635074"></a><h2>CONFIGURATION</h2> <p> The <span><strong class="command">named</strong></span> configuration file is too complex to describe in detail here. A complete description is provided @@ -284,7 +284,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2664294"></a><h2>FILES</h2> +<a name="id2635123"></a><h2>FILES</h2> <div class="variablelist"><dl> <dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt> <dd><p> @@ -297,7 +297,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2664338"></a><h2>SEE ALSO</h2> +<a name="id2669573"></a><h2>SEE ALSO</h2> <p><em class="citetitle">RFC 1033</em>, <em class="citetitle">RFC 1034</em>, <em class="citetitle">RFC 1035</em>, @@ -310,7 +310,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2664476"></a><h2>AUTHOR</h2> +<a name="id2669643"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.nsupdate.html b/doc/arm/man.nsupdate.html index 09347347..5262a328 100644 --- a/doc/arm/man.nsupdate.html +++ b/doc/arm/man.nsupdate.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.nsupdate.html,v 1.69 2009/10/16 04:20:33 tbox Exp $ --> +<!-- $Id: man.nsupdate.html,v 1.72 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">nsupdate</code> [<code class="option">-d</code>] [<code class="option">-D</code>] [[<code class="option">-g</code>] | [<code class="option">-o</code>] | [<code class="option">-l</code>] | [<code class="option">-y <em class="replaceable"><code>[<span class="optional">hmac:</span>]keyname:secret</code></em></code>] | [<code class="option">-k <em class="replaceable"><code>keyfile</code></em></code>]] [<code class="option">-t <em class="replaceable"><code>timeout</code></em></code>] [<code class="option">-u <em class="replaceable"><code>udptimeout</code></em></code>] [<code class="option">-r <em class="replaceable"><code>udpretries</code></em></code>] [<code class="option">-R <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-v</code>] [filename]</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2615081"></a><h2>DESCRIPTION</h2> +<a name="id2615128"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">nsupdate</strong></span> is used to submit Dynamic DNS Update requests as defined in RFC 2136 to a name server. @@ -210,7 +210,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2616644"></a><h2>INPUT FORMAT</h2> +<a name="id2635259"></a><h2>INPUT FORMAT</h2> <p><span><strong class="command">nsupdate</strong></span> reads input from <em class="parameter"><code>filename</code></em> @@ -474,7 +474,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2665463"></a><h2>EXAMPLES</h2> +<a name="id2672132"></a><h2>EXAMPLES</h2> <p> The examples below show how <span><strong class="command">nsupdate</strong></span> @@ -528,7 +528,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2665513"></a><h2>FILES</h2> +<a name="id2672182"></a><h2>FILES</h2> <div class="variablelist"><dl> <dt><span class="term"><code class="constant">/etc/resolv.conf</code></span></dt> <dd><p> @@ -551,7 +551,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2665665"></a><h2>SEE ALSO</h2> +<a name="id2672265"></a><h2>SEE ALSO</h2> <p> <em class="citetitle">RFC 2136</em>, <em class="citetitle">RFC 3007</em>, @@ -566,7 +566,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2665722"></a><h2>BUGS</h2> +<a name="id2672323"></a><h2>BUGS</h2> <p> The TSIG key is redundantly stored in two separate files. This is a consequence of nsupdate using the DST library diff --git a/doc/arm/man.rndc-confgen.html b/doc/arm/man.rndc-confgen.html index b087a9a7..ae70fb76 100644 --- a/doc/arm/man.rndc-confgen.html +++ b/doc/arm/man.rndc-confgen.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.rndc-confgen.html,v 1.149 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.rndc-confgen.html,v 1.152 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">rndc-confgen</code> [<code class="option">-a</code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-c <em class="replaceable"><code>keyfile</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [<code class="option">-s <em class="replaceable"><code>address</code></em></code>] [<code class="option">-t <em class="replaceable"><code>chrootdir</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>]</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2634931"></a><h2>DESCRIPTION</h2> +<a name="id2636548"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">rndc-confgen</strong></span> generates configuration files for <span><strong class="command">rndc</strong></span>. It can be used as a @@ -66,7 +66,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2635338"></a><h2>OPTIONS</h2> +<a name="id2636614"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-a</span></dt> <dd> @@ -173,7 +173,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2637568"></a><h2>EXAMPLES</h2> +<a name="id2638365"></a><h2>EXAMPLES</h2> <p> To allow <span><strong class="command">rndc</strong></span> to be used with no manual configuration, run @@ -190,7 +190,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2637624"></a><h2>SEE ALSO</h2> +<a name="id2638422"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>, <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>, @@ -198,7 +198,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2637662"></a><h2>AUTHOR</h2> +<a name="id2638529"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.rndc.conf.html b/doc/arm/man.rndc.conf.html index 2c8df276..4d418ece 100644 --- a/doc/arm/man.rndc.conf.html +++ b/doc/arm/man.rndc.conf.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.rndc.conf.html,v 1.150 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.rndc.conf.html,v 1.153 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div> </div> <div class="refsect1" lang="en"> -<a name="id2610003"></a><h2>DESCRIPTION</h2> +<a name="id2629301"></a><h2>DESCRIPTION</h2> <p><code class="filename">rndc.conf</code> is the configuration file for <span><strong class="command">rndc</strong></span>, the BIND 9 name server control utility. This file has a similar structure and syntax to @@ -135,7 +135,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2629289"></a><h2>EXAMPLE</h2> +<a name="id2631111"></a><h2>EXAMPLE</h2> <pre class="programlisting"> options { default-server localhost; @@ -209,7 +209,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2633575"></a><h2>NAME SERVER CONFIGURATION</h2> +<a name="id2631233"></a><h2>NAME SERVER CONFIGURATION</h2> <p> The name server must be configured to accept rndc connections and to recognize the key specified in the <code class="filename">rndc.conf</code> @@ -219,7 +219,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2633601"></a><h2>SEE ALSO</h2> +<a name="id2631258"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">mmencode</span>(1)</span>, @@ -227,7 +227,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2633639"></a><h2>AUTHOR</h2> +<a name="id2635529"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.rndc.html b/doc/arm/man.rndc.html index a09d5bfc..7367778e 100644 --- a/doc/arm/man.rndc.html +++ b/doc/arm/man.rndc.html @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: man.rndc.html,v 1.148 2009/10/16 04:20:32 tbox Exp $ --> +<!-- $Id: man.rndc.html,v 1.151 2009/10/28 01:14:38 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -50,7 +50,7 @@ <div class="cmdsynopsis"><p><code class="command">rndc</code> [<code class="option">-b <em class="replaceable"><code>source-address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key-file</code></em></code>] [<code class="option">-s <em class="replaceable"><code>server</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-V</code>] [<code class="option">-y <em class="replaceable"><code>key_id</code></em></code>] {command}</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2619257"></a><h2>DESCRIPTION</h2> +<a name="id2615549"></a><h2>DESCRIPTION</h2> <p><span><strong class="command">rndc</strong></span> controls the operation of a name server. It supersedes the <span><strong class="command">ndc</strong></span> utility @@ -79,7 +79,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2619307"></a><h2>OPTIONS</h2> +<a name="id2615600"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-b <em class="replaceable"><code>source-address</code></em></span></dt> <dd><p> @@ -151,7 +151,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2628270"></a><h2>LIMITATIONS</h2> +<a name="id2625723"></a><h2>LIMITATIONS</h2> <p><span><strong class="command">rndc</strong></span> does not yet support all the commands of the BIND 8 <span><strong class="command">ndc</strong></span> utility. @@ -165,7 +165,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2628301"></a><h2>SEE ALSO</h2> +<a name="id2625754"></a><h2>SEE ALSO</h2> <p><span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>, <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>, <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>, @@ -175,7 +175,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2635252"></a><h2>AUTHOR</h2> +<a name="id2635435"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt new file mode 100644 index 00000000..f15b069b --- /dev/null +++ b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt @@ -0,0 +1,785 @@ + + + +IPv6 Maintenance Working Group S. Kawamura +Internet-Draft NEC BIGLOBE, Ltd. +Intended status: Informational M. Kawashima +Expires: April 21, 2010 NEC AccessTechnica, Ltd. + October 18, 2009 + + + A Recommendation for IPv6 Address Text Representation + draft-ietf-6man-text-addr-representation-01 + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 21, 2010. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + As IPv6 network grows, there will be more engineers and also non- + engineers who will have the need to use an IPv6 address in text. + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 1] + +Internet-Draft IPv6 Text Representation October 2009 + + + While the IPv6 address architecture RFC 4291 section 2.2 depicts a + flexible model for text representation of an IPv6 address, this + flexibility has been causing problems for operators, system + engineers, and users. This document will describe the problems that + a flexible text representation has been causing. This document also + recommends a canonical representation format that best avoids + confusion. It is expected that the canonical format is followed by + humans and systems when representing IPv6 addresses as text, but all + implementations must accept and be able to handle any legitimate + RFC4291 format. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 + 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 + 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 + 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 + 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 + 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 + 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 + 3.1.4. Searching for an Address in a Network Diagram . . . . 7 + 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 + 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 + 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8 + 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 + 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 + 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 + 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9 + 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 + 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 + 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 + 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10 + 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10 + 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 + 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 + 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 + 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 + 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11 + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 2] + +Internet-Draft IPv6 Text Representation October 2009 + + + 5. Text Representation of Special Addresses . . . . . . . . . . . 11 + 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 + 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 + Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 3] + +Internet-Draft IPv6 Text Representation October 2009 + + +1. Introduction + + A single IPv6 address can be text represented in many ways. Examples + are shown below. + + 2001:db8:0:0:1:0:0:1 + + 2001:0db8:0:0:1:0:0:1 + + 2001:db8::1:0:0:1 + + 2001:db8::0:1:0:0:1 + + 2001:0db8::1:0:0:1 + + 2001:db8:0:0:1::1 + + 2001:db8:0000:0:1::1 + + 2001:DB8:0:0:1::1 + + All the above point to the same IPv6 address. This flexibility has + caused many problems for operators, systems engineers, and customers. + The problems will be noted in Section 3. Also, a canonical + representation format to avoid problems will be introduced in + Section 4. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + +2. Text Representation Flexibility of RFC4291 + + Examples of flexibility in Section 2.2 of [RFC4291] are described + below. + +2.1. Leading Zeros in a 16 Bit Field + + 'It is not necessary to write the leading zeros in an individual + field.' + + In other words, it is also not necessary to omit leading zeros. This + means that, it is possible to select from such as the following + example. The final 16 bit field is different, but all these + addresses mean the same. + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 4] + +Internet-Draft IPv6 Text Representation October 2009 + + + 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 + + 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001 + + 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01 + + 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 + +2.2. Zero Compression + + 'A special syntax is available to compress the zeros. The use of + "::" indicates one or more groups of 16 bits of zeros.' + + It is possible to select whether or not to omit just one 16 bits of + zeros. + + 2001:db8:aaaa:bbbb:cccc:dddd::1 + + 2001:db8:aaaa:bbbb:cccc:dddd:0:1 + + In case where there are more than one zero fields, there is a choice + of how many fields can be shortened. Examples follow. + + 2001:db8:0:0:0::1 + + 2001:db8:0:0::1 + + 2001:db8:0::1 + + 2001:db8::1 + + In addition, [RFC4291] in section 2.2 notes, + + 'The "::" can only appear once in an address.' + + This gives a choice on where, in a single address to compress the + zero. Examples are shown below. + + 2001:db8::aaaa:0:0:1 + + 2001:db8:0:0:aaaa::1 + +2.3. Uppercase or Lowercase + + [RFC4291] does not mention about preference of uppercase or + lowercase. Various flavors are shown below. + + + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 5] + +Internet-Draft IPv6 Text Representation October 2009 + + + 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa + + 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA + + 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa + + +3. Problems Encountered with the Flexible Model + +3.1. Searching + +3.1.1. General Summary + + A search of an IPv6 address if conducted through a UNIX system is + usually case sensitive and extended options to allow for regular + expression use will come in handy. However, there are many + applications in the Internet today that do not provide this + capability. When searching for an IPv6 address in such systems, the + system engineer will have to try each and every possibility to search + for an address. This has critical impacts especially when trying to + deploy IPv6 over an enterprise network. + +3.1.2. Searching Spreadsheets and Text Files + + Spreadsheet applications and text editors on GUI systems, rarely have + the ability to search for a text using regular expression. Moreover, + there are many non-engineers (who are not aware of case sensitivity + and regular expression use) that use these application to manage IP + addresses. This has worked quite well with IPv4 since text + representation in IPv4 has very little flexibility. There is no + incentive to encourage these non-engineers to change their tool or + learn regular expression when they decide to go dual-stack. If the + entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was + conducted as 2001:db8:0:0:1::1, this will show a result of no match. + One example where this will cause problem is, when the search is + being conducted to assign a new address from a pool, and a check was + being done to see if it was not in use. This may cause problems to + the end-hosts or end-users. This type of address management is very + often seen in enterprise networks and also in ISPs. + +3.1.3. Searching with Whois + + The "whois" utility is used by a wide range of people today. When a + record is set to a database, one will likely check the output to see + if the entry is correct. If an entity was recorded as 2001:db8::/48, + but the whois output showed 2001:0db8:0000::/48, most non-engineers + would think that their input was wrong, and will likely retry several + times or make a frustrated call to the database hostmaster. If there + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 6] + +Internet-Draft IPv6 Text Representation October 2009 + + + was a need to register the same address on different systems, and + each system showed a different text representation, this would + confuse people even more. Although this document focuses on + addresses rather than prefixes, this is worth mentioning since + problems encountered are mostly equal. + +3.1.4. Searching for an Address in a Network Diagram + + Network diagrams and blue-prints contain IP addresses as allocated to + system devices. In times of trouble shooting, there may be a need to + search through a diagram to find the point of failure (for example, + if a traceroute stopped at 2001:db8::1, one would search the diagram + for that address). This is a technique quite often in use in + enterprise networks and managed services. Again, the different + flavors of text representation will result in a time-consuming + search, leading to longer MTTR in times of trouble. + +3.2. Parsing and Modifying + +3.2.1. General Summary + + With all the possible text representation ways, each application must + include a module, object, link, etc. to a function that will parse + IPv6 addresses in a manner that no matter how it is represented, they + will mean the same address. This is not too much a problem if the + output is to be just 'read' or 'managed' by a network engineer. + However, many system engineers who integrate complex computer systems + to corporate customers will have difficulties finding that their + favorite tool will not have this function, or will encounter + difficulties such as having to rewrite their macro's or scripts for + their customers. It must be noted that each additional line of a + program will result in increased development fees that will be + charged to the customers. + +3.2.2. Logging + + If an application were to output a log summary that represented the + address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), + the output would be highly unreadable compared to the IPv4 output. + The address would have to be parsed and reformed to make it useful + for human reading. This will result in additional code on the + applications which will result in extra fees charged to the + customers. Sometimes, logging for critical systems is done by + mirroring the same traffic to two different systems. Care must be + taken that no matter what the log output is, the logs should be + parsed so they will mean the same. + + + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 7] + +Internet-Draft IPv6 Text Representation October 2009 + + +3.2.3. Auditing: Case 1 + + When a router or any other network appliance machine configuration is + audited, there are many methods to compare the configuration + information of a node. Sometimes, auditing will be done by just + comparing the changes made each day. In this case, if configuration + was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: + 0000:0000:0000:0001 just because the new engineer on the block felt + it was better, a simple diff will tell you that a different address + was configured. If this was done on a wide scale network, people + will be focusing on 'why the extra zeros were put in' instead of + doing any real auditing. Lots of tools are just plain 'diff's that + do not take into account address representation rules. + +3.2.4. Auditing: Case 2 + + Node configurations will be matched against an information system + that manages IP addresses. If output notation is different, there + will need to be a script that is implemented to cover for this. An + SNMP GET of an interface address and text representation in a humanly + written text file is highly unlikely to match on first try. + +3.2.5. Verification + + Some protocols require certain data fields to be verified. One + example of this is X.509 certificates. If an IPv6 address was + embedded in one of the fields in a certificate, and the verification + was done by just a simple textual comparison, the certificate may be + maistakenly shown as being invalid due to a difference in text + representation methods. + +3.2.6. Unexpected Modifying + + Sometimes, a system will take an address and modify it as a + convenience. For example, a system may take an input of + 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some + RIR databases). If the zeros were input for a reason, the outcome + may be somewhat unexpected. + +3.3. Operating + +3.3.1. General Summary + + When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: + 0:0:1, the system may take the address and show the configuration + result as 2001:DB8::1:0:0:1. A distinguished engineer will know that + the right address is set, but an operator, or a customer that is + communicating with the operator to solve a problem, is usually not as + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 8] + +Internet-Draft IPv6 Text Representation October 2009 + + + distinguished as we would like. Again, the extra load in checking + that the IP address is the same as was intended, will result in fees + that will be charged to the customers. + +3.3.2. Customer Calls + + When a customer calls to inquire about a suspected outage, IPv6 + address representation should be handled with care. Not all + customers are engineers nor have the same skill in IPv6 technology. + The NOC will have to take extra steps to humanly parse the address to + avoid having to explain to the customers that 2001:db8:0:1::1 is the + same as 2001:db8::1:0:0:0:1. This is one thing that will never + happen in IPv4 because IPv4 address cannot be abbreviated. + +3.3.3. Abuse + + Network abuse is reported along with the abusing IP address. This + 'reporting' could take any shape or form of the flexible model. A + team that handles network abuse must be able to tell the difference + between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the + placement of the "::" will result in a critical situation. A system + that handles these incidents should be able to handle any type of + input and parse it in a correct manner. Also, incidents are reported + over the phone. It is unnecessary to report if the letter is an + uppercase or lowercase. However, when a letter is spelled uppercase, + people tend to clarify that it is uppercase, which is unnecessary + information. + +3.4. Other Minor Problems + +3.4.1. Changing Platforms + + When an engineer decides to change the platform of a running service, + the same code may not work as expected due to the difference in IPv6 + address text representation. Usually, a change in a platform (e.g. + Unix to Windows, Cisco to Juniper) will result in a major change of + code, but flexibility in address representation will increase the + work load which will again, result in fees that will be charged to + the customers, and also longer down time of systems. + +3.4.2. Preference in Documentation + + A document that is edited by more than one author, may become harder + to read. + + + + + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 9] + +Internet-Draft IPv6 Text Representation October 2009 + + +3.4.3. Legibility + + Capital case D and 0 can be quite often misread. Capital B and 8 can + also be misread. + + +4. A Recommendation for IPv6 Text Representation + + A recommendation for a canonical text representation format of IPv6 + addresses is presented in this section. The recommendation in this + document is one that, complies fully with [RFC4291], is implemented + by various operating systems, and is human friendly. The + recommendation in this document SHOULD be followed by humans and + systems when generating an address to represent as text, but all + implementations MUST accept any legitimate [RFC4291] format. + +4.1. Handling Leading Zeros in a 16 Bit Field + + Leading zeros should be chopped for human legibility and easier + searching. Also, a single 16 bit 0000 field should be represented as + just 0. Place holder zeros are often cause of misreading. + +4.2. "::" Usage + +4.2.1. Shorten As Much As Possible + + The use of "::" should be used to its maximum capability (i.e. 2001: + db8::0:1 is not considered as clean representation). + +4.2.2. Handling One 16 Bit 0 Field + + "::" should not be used to shorten just one 16 bit 0 field for it + would tend to mislead that there are more than one 16 bit field that + is shortened. + +4.2.3. Choice in Placement of "::" + + When there is an alternative choice in the placement of a "::", the + longest run of consecutive 16 bit 0 fields should be shortened (i.e. + latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the + consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1), + the former is shortened. This is consistent with many current + implementations. One idea to avoid any confusion, is for the + operator to not use 16 bit field 0 in the first 64 bits. By nature + IPv6 addresses are usually assigned or allocated to end-users as + longer than 32 bits (typically 48 bits or longer). + + + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 10] + +Internet-Draft IPv6 Text Representation October 2009 + + +4.3. Lower Case + + Recent implementations tend to represent IPv6 address as lower case. + It is better to use lower case to avoid problems such as described in + section 3.3.3 and 3.4.3. + + +5. Text Representation of Special Addresses + + Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and + IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in + the low-order 32 bits of the address. These addresses have special + representation that may mix hexadecimal and decimal notations. In + cases where there is a choice of whether to express the address as + fully hexadecimal or hexadecimal and decimal mixed, and if the + address type can be distinguished as having IPv4 addresses embedded + in the lower 32 bits solely from the 128bits of the address field + itself, mixed notation is the better choice. However, there may be + situations where hexadecimal representation is chosen to meet certain + needs. Addressing those needs is out of the scope of this document. + The text representation method noted in Section 4 should be applied + for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of + 0:0:0:0:0:ffff:192.0.2.1). + + +6. Notes on Combining IPv6 Addresses with Port Numbers + + When IPv6 addresses and port numbers are represented in text combined + together, there seems to be many different ways to do so. Examples + are shown below. + + o [2001:db8::1]:80 + + o 2001:db8::1:80 + + o 2001:db8::1.80 + + o 2001:db8::1 port 80 + + o 2001:db8::1p80 + + o 2001:db8::1#80 + + The situation is not much different in IPv4, but the most ambiguous + case with IPv6 is the second bullet. This is due to the "::"usage in + IPv6 addresses. This style is not recommended for its ambiguity. + The [] style as expressed in [RFC3986] is recommended. Other styles + are acceptable when cross-platform portability does not become an + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 11] + +Internet-Draft IPv6 Text Representation October 2009 + + + issue. + + +7. Conclusion + + The recommended format of text representing an IPv6 address is + summarized as follows. + + (1) omit leading zeros in a 16 bit field + + (2) when using "::", shorten consecutive zero fields to their + maximum extent (leave no zero fields behind). + + (3) "::" used where shortens address the most + + (4) "::" used in the former part in case of a tie breaker + + (5) do not shorten one 16 bit 0 field, but always shorten when + there are two or more consecutive 16 bit 0 fields + + (6) use lower case + + Hints for developers are written in the Appendix section. + + +8. Security Considerations + + None. + + +9. IANA Considerations + + None. + + +10. Acknowledgements + + The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, + Toshimitsu Matsuura for their generous and helpful comments in kick + starting this document. We also would like to thank Brian Carpenter, + Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, + Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki + Vatiainen for their input. Also a very special thanks to Ron Bonica, + Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt + Lindqvist for their support in bringing this document to the light of + IETF working groups. + + + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 12] + +Internet-Draft IPv6 Text Representation October 2009 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + +11.2. Informative References + + [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm + (SIIT)", RFC 2765, February 2000. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. + Castro, "Application Aspects of IPv6 Transition", + RFC 4038, March 2005. + + [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, + March 2008. + + +Appendix A. For Developers + + We recommend that developers use display routines that conform to + these rules. For example, the usage of getnameinfo() with flags + argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, + except for the special addresses notes in Section 5. The function + inet_ntop() of FreeBSD7.0 is a good C code reference, but should not + be called directly. See [RFC4038] for details. + + +Appendix B. Prefix Issues + + Problems with prefixes are just the same as problems encountered with + addresses. Text representation method of IPv6 prefixes should be no + different from that of IPv6 addresses. + + + + + + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 13] + +Internet-Draft IPv6 Text Representation October 2009 + + +Authors' Addresses + + Seiichi Kawamura + NEC BIGLOBE, Ltd. + 14-22, Shibaura 4-chome + Minatoku, Tokyo 108-8558 + JAPAN + + Phone: +81 3 3798 6085 + Email: kawamucho@mesh.ad.jp + + + Masanobu Kawashima + NEC AccessTechnica, Ltd. + 800, Shimomata + Kakegawa-shi, Shizuoka 436-8501 + JAPAN + + Phone: +81 537 23 9655 + Email: kawashimam@necat.nec.co.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kawamura & Kawashima Expires April 21, 2010 [Page 14] + + diff --git a/doc/draft/draft-ietf-behave-dns64-01.txt b/doc/draft/draft-ietf-behave-dns64-01.txt new file mode 100644 index 00000000..25a6dd4d --- /dev/null +++ b/doc/draft/draft-ietf-behave-dns64-01.txt @@ -0,0 +1,1624 @@ + + + +BEHAVE WG M. Bagnulo +Internet-Draft UC3M +Intended status: Standards Track A. Sullivan +Expires: April 22, 2010 Shinkuro + P. Matthews + Alcatel-Lucent + I. van Beijnum + IMDEA Networks + October 19, 2009 + + +DNS64: DNS extensions for Network Address Translation from IPv6 Clients + to IPv4 Servers + draft-ietf-behave-dns64-01 + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 22, 2010. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + + +Bagnulo, et al. Expires April 22, 2010 [Page 1] + +Internet-Draft DNS64 October 2009 + + +Abstract + + DNS64 is a mechanism for synthesizing AAAA records from A records. + DNS64 is used with an IPv6/IPv4 translator to enable client-server + communication between an IPv6-only client and an IPv4-only server, + without requiring any changes to either the IPv6 or the IPv4 node, + for the class of applications that work through NATs. This document + specifies DNS64, and provides suggestions on how it should be + deployed in conjunction with IPv6/IPv4 translators. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6 + 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9 + 5.1. Resolving AAAA queries and the answer section . . . . . . 9 + 5.1.1. The answer when there is AAAA data available . . . . . 9 + 5.1.2. The answer when there is an error . . . . . . . . . . 9 + 5.1.3. Data for the answer when performing synthesis . . . . 9 + 5.1.4. Performing the synthesis . . . . . . . . . . . . . . . 10 + 5.1.5. Querying in parallel . . . . . . . . . . . . . . . . . 11 + 5.2. Generation of the IPv6 representations of IPv4 + addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.3. Handling other RRs . . . . . . . . . . . . . . . . . . . . 12 + 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 12 + 5.3.2. Handling the additional section . . . . . . . . . . . 13 + 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 13 + 5.4. Assembling a synthesized response to a AAAA query . . . . 14 + 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14 + 5.6. DNS64 and multihoming . . . . . . . . . . . . . . . . . . 15 + 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16 + 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Appendix A. Deployment scenarios and examples . . . . . . . . . . 20 + A.1. Embed and Zero-Pad algorithm description . . . . . . . . . 21 + A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in + DNS server mode . . . . . . . . . . . . . . . . . . . . . 22 + A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in + stub-resolver mode . . . . . . . . . . . . . . . . . . . . 23 + + + +Bagnulo, et al. Expires April 22, 2010 [Page 2] + +Internet-Draft DNS64 October 2009 + + + A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS + server mode . . . . . . . . . . . . . . . . . . . . . . . 25 + Appendix B. Motivations and Implications of synthesizing AAAA + RR when real AAAA RR exists . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 3] + +Internet-Draft DNS64 October 2009 + + +1. Introduction + + This document specifies DNS64, a mechanism that is part of the + toolbox for IPv6-IPv4 transition and co-existence. DNS64, used + together with an IPv6/IPv4 translator such as NAT64 + [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate + communications by name to an IPv4-only server. + + DNS64 is a mechanism for synthesizing AAAA resource records (RRs) + from A RRs. A synthetic AAAA RR created by the DNS64 from an + original A RR contains the same FQDN of the original A RR but it + contains an IPv6 address instead of an IPv4 address. The IPv6 + address is an IPv6 representation of the IPv4 address contained in + the original A RR. The IPv6 representation of the IPv4 address is + algorithmically generated from the IPv4 address returned in the A RR + and a set of parameters configured in the DNS64 (typically, an IPv6 + prefix used by IPv6 representations of IPv4 addresses and optionally + other parameters). + + Together with a IPv6/IPv4 translator, these two mechanisms allow an + IPv6-only client to initiate communications to an IPv4-only server + using the FQDN of the server. + + These mechanisms are expected to play a critical role in the IPv4- + IPv6 transition and co-existence. Due to IPv4 address depletion, it + is likely that in the future, many IPv6-only clients will want to + connect to IPv4-only servers. In the typical case, the approach only + requires the deployment of IPv6/IPv4 translators that connect an + IPv6-only network to an IPv4-only network, along with the deployment + of one or more DNS64-enabled name servers. However, some advanced + features require performing the DNS64 function directly by the end- + hosts themselves. + + +2. Overview + + This section provides a non-normative introduction to the DNS64 + mechanism. + + We assume that we have an IPv6/IPv4 translator box connecting an IPv4 + network and an IPv6 network. The IPv6/IPv4 translator device + provides translation services between the two networks enabling + communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By + IPv6-only hosts we mean hosts running IPv6-only applications, hosts + that can only use IPv6, as well as the cases where only IPv6 + connectivity is available to the client. By IPv4-only servers we + mean servers running IPv4-only applications, servers that can only + use IPv4, as well as the cases where only IPv4 connectivity is + + + +Bagnulo, et al. Expires April 22, 2010 [Page 4] + +Internet-Draft DNS64 October 2009 + + + available to the server). The IPv6/IPv4 translator used in + conjunction with DNS64 must allow communications initiated from the + IPv6-only host to the IPv4-only host. + + To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to + learn the address of the responder, DNS64 is used to synthesize a + AAAA record from an A record containing a real IPv4 address of the + responder, whenever the DNS64 service cannot retrieve a AAAA record + for the requested host name. The DNS64 device appears as a regular + recursive resolver for the IPv6 initiator. The DNS64 box receives an + AAAA DNS query generated by the IPv6 initiator. It first attempts a + recursive resolution for the requested AAAA records. If there is no + AAAA record available for the target node (which is the normal case + when the target node is an IPv4-only node), DNS64 performs a query + for A records. If any A records are discovered, DNS64 creates a + synthetic AAAA RR from the information retrieved in each A RR. + + The FQDN of a synthetic AAAA RR is the same as that of the original A + RR, but an IPv6 representation of the IPv4 address contained in the + original A RR is included in the AAAA RR. The IPv6 representation of + the IPv4 address is algorithmically generated from the IPv4 address + and additional parameters configured in the DNS64. Among those + parameters configured in the DNS64, there is at least one IPv6 + prefix, called Pref64::/n. The IPv6 address representing IPv4 + addresses included in the AAAA RR synthesized by the DNS64 function + contain Pref64::/n and they also embed the original IPv4 address. + + The same algorithm and the same Pref64::/n prefix or prefixes must be + configured both in the DNS64 device and the IPv6/IPv4 translator, so + that both can algorithmically generate the same IPv6 representation + for a given IPv4 address. In addition, it is required that IPv6 + packets addressed to an IPv6 destination that contains the Pref64::/n + be delivered to the IPv6/IPv4 translator, so they can be translated + into IPv4 packets. + + Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is + passed back to the IPv6 initiator, which will initiate an IPv6 + communication with the IPv6 address associated with the IPv4 + receiver. The packet will be routed to the IPv6/IPv4 translator + which will forward it to the IPv4 network . + + In general, the only shared state between the DNS64 and the IPv6/IPv4 + translator is the Pref64::/n and an optional set of static + parameters. The Pref64::/n and the set of static parameters must be + configured to be the same on both; there is no communication between + the DNS64 device and IPv6/IPv4 translator functions. The mechanism + to be used for configuring the parameters of the DNS64 is beyond the + scope of this memo. + + + +Bagnulo, et al. Expires April 22, 2010 [Page 5] + +Internet-Draft DNS64 October 2009 + + + The DNS64 function can be performed in two places. + + One option is to locate the DNS64 function in recursive name + servers serving end hosts. In this case, when an IPv6-only host + queries the name server for AAAA RRs for an IPv4-only host, the + name server can perform the synthesis of AAAA RRs and pass them + back to the IPv6 only initiator. The main advantage of this mode + is that current IPv6 nodes can use this mechanism without + requiring any modification. This mode is called "DNS64 in DNS + server mode". + + The other option is to place the DNS64 function in the end hosts + themselves, coupled to the local stub resolver. In this case, the + stub resolver will try to obtain (real) AAAA RRs and in case they + are not available, the DNS64 function will synthesize AAAA RRs for + internal usage. This mode is compatible with some advanced + functions like DNSSEC validation in the end host. The main + drawback of this mode is its deployability, since it requires + changes in the end hosts. This mode is called "DNS64 in stub- + resolver mode"". + + +3. Background to DNS64 - DNSSEC interaction + + DNSSEC presents a special challenge for DNS64, because DNSSEC is + designed to detect changes to DNS answers, and DNS64 may alter + answers coming from an authoritative server. + + A recursive resolver can be security-aware or security-oblivious. + Moreover, a security-aware recursive name server can be validating or + non-validating, according to operator policy. In the cases below, + the recursive server is also performing DNS64, and has a local policy + to validate. We call this general case vDNS64, but in all the cases + below the DNS64 functionality should be assumed needed. + + DNSSEC includes some signaling bits that offer some indicators of + what the query originator understands. + + If a query arrives at a vDNS64 device with the DO bit set, the query + originator is signaling that it understands DNSSEC. The DO bit does + not indicate that the query originator will validate the response. + It only means that the query originator can understand responses + containing DNSSEC data. Conversely, if the DO bit is clear, that is + evidence that the querying agent is not aware of DNSSEC. + + If a query arrives at a vDNS64 device with the CD bit set, it is an + indication that the querying agent wants all the validation data so + it can do checking itself. By local policy, vDNS64 could still + + + +Bagnulo, et al. Expires April 22, 2010 [Page 6] + +Internet-Draft DNS64 October 2009 + + + validate, but it must return all data to the querying agent anyway. + + Here are the possible cases: + + 1. A security-oblivious DNS64 node receives a query with the DO bit + clear. In this case, DNSSEC is not a concern, because the + querying agent does not understand DNSSEC responses. + + 2. A security-oblivious DNS64 node receives a query with the DO bit + set, and the CD bit clear. This is just like the case of a non- + DNS64 case: the server doesn't support it, so the querying agent + is out of luck. + + 3. A security-aware and non-validating DNS64 node receives a query + with the DO bit set and the CD bit clear. Such a resolver is not + validating responses, likely due to local policy (see [RFC4035], + section 4.2). For that reason, this case amounts to the same as + the previous case, and no validation happens. + + 4. A security-aware and non-validating DNS64 node receives a query + with the DO bit set and the CD bit set. In this case, the + resolver is supposed to pass on all the data it gets to the query + initiator (see section 3.2.2 of [RFC4035]). This case will be + problematic with DNS64. If the DNS64 server modifies the record, + the client will get the data back and try to validate it, and the + data will be invalid as far as the client is concerned. + + 5. A security-aware and validating DNS64 node receives a query with + the DO bit clear and CD clear. In this case, the resolver + validates the data. If it fails, it returns RCODE 2 (SERVFAIL); + otherwise, it returns the answer. This is the ideal case for + vDNS64. The resolver validates the data, and then synthesizes + the new record and passes that to the client. The client, which + is presumably not validating (else it would have set DO and CD), + cannot tell that DNS64 is involved. + + 6. A security-aware and validating DNS64 node receives a query with + the DO bit set and CD clear. In principle, this ought to work + like the previous case, except that the resolver should also set + the AD bit on the response. + + 7. A security-aware and validating DNS64 node receives a query with + the DO bit set and CD set. This is effectively the same as the + case where a security-aware and non-validating recursive resolver + receives a similar query, and the same thing will happen: the + downstream validator will mark the data as invalid if DNS64 has + performed synthesis. + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 7] + +Internet-Draft DNS64 October 2009 + + +4. Terminology + + This section provides definitions for the special terms used in the + document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + Authoritative server: A DNS server that can answer authoritatively a + given DNS question. + + DNS64: A logical function that synthesizes DNS resource records (e.g + AAAA records containing IPv6 addresses) from DNS resource records + actually contained in the global DNS (e.g. A records containing + IPv4 addresses). + + DNS64 recursor: A recursive resolver that provides the DNS64 + functionality as part of its operation. + + Recursive resolver: A DNS server that accepts requests from one + resolver, and asks another resolver for the answer on behalf of + the first resolver. In the context of this document, "the + recursive resolver" means a recursive resolver immediately next in + the DNS resolution chain from an end point. The end point usually + has only a stub resolver available.[[anchor5: I can't actually + remember why we needed the sentences following "In the context of + this document. . ." Unless someone has a reason, I'll take it + out. --ajs@shinkuro.com]] + + Synthetic RR: A DNS resource record (RR) that is not contained in + any zone data file, but has been synthesized from other RRs. An + example is a synthetic AAAA record created from an A record. + + Stub resolver: A resolver with minimum functionality, typically for + use in end points that depend on a recursive resolver. Most end + points on the Internet as of this writing use stub + resolvers.[[anchor6: Do we need this in the document? I don't + think so. 1034 defines this term. --ajs@shinkuro.com]] + + IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 + packets and vice-versa. It is only required that the + communication initiated from the IPv6 side be supported. + + For a detailed understanding of this document, the reader should also + be familiar with DNS terminology from [RFC1034],[RFC1035] and current + NAT terminology from [RFC4787]. Some parts of this document assume + familiarity with the terminology of the DNS security extensions + + + +Bagnulo, et al. Expires April 22, 2010 [Page 8] + +Internet-Draft DNS64 October 2009 + + + outlined in [RFC4035]. + + +5. DNS64 Normative Specification + + A DNS64 is a logical function that synthesizes AAAA records from A + records. The DNS64 function may be implemented in a stub resolver, + in a recursive resolver, or in an authoritative name server. + + The implementation SHOULD support mapping of IPv4 address ranges to + separate IPv6 prefixes for AAAA record synthesis. This allows + handling of special use IPv4 addresses [I-D.iana-rfc3330bis]. + Multicast address handling is further specified in + [I-D.venaas-behave-mcast46]. + +5.1. Resolving AAAA queries and the answer section + + When the DNS64 receives a query for RRs of type AAAA and class IN, it + first attempts to retrieve non-synthetic RRs of this type and class, + either by performing a query or, in the case of an authoritative + server, by examining its own results. + +5.1.1. The answer when there is AAAA data available + + If the query results in one or more AAAA records in the answer + section, the result is returned to the requesting client as per + normal DNS semantics (except in the case where the AAAA falls in the + ::ffff/96 network; see below for treatment of that network). In this + case, DNS64 SHOULD NOT include synthetic AAAA RRs in the response + (see Appendix B for an analysis of the motivations for and the + implications of not complying with this recommendation). By default + DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs + exist. + +5.1.2. The answer when there is an error + + If the query results in a response with an error code other than 0, + the result is handled according to normal DNS operation -- that is, + either the resolver tries again using a different server from the + authoritative NS RRSet, or it returns the error to the client. This + stage is still prior to any synthesis having happened, so a response + to be returned to the client does not need any special assembly than + would usually happen in DNS operation. + +5.1.3. Data for the answer when performing synthesis + + If the query results in no error but an empty answer section in the + response, the DNS64 resolver attempts to retrieve A records for the + + + +Bagnulo, et al. Expires April 22, 2010 [Page 9] + +Internet-Draft DNS64 October 2009 + + + name in question. If this new A RR query results in an empty answer + or in an error, then the empty result or error is used as the basis + for the answer returned to the querying client. (Transient errors + may result in retrying the query, depening on the operation of the + resolver; this is just as in Section 5.1.2.) If instead the query + results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on + the A RRs according to the procedure outlined in Section 5.1.4. The + DNS64 resolver then returns the synthesized AAAA records in the + answer section to the client, removing the A records that form the + basis of the synthesis. + + As an exception to the general rule about always returning the AAAA + records if they are returned in the answer, AAAA records with + addresses in the ::ffff/96 network are treated just like the case + where there is neither an error nor an empty answer section. This is + because a real IPv6-only node will not be any more able to reach the + addresses in ::ffff/96 than it is able to reach an IPv4 address + without assistance. An implementation MAY use the address in + ::ffff/96 as the basis of synthesis without querying for an A record, + by using the last 32 bits of the address provided in the AAAA record. + [[anchor10: I changed this to say "neither. . .nor" because the + previous version suggested that it would return the error-or-empty- + answer to the querying client, and that can't be right. Correct? + --ajs@shinkuro.com]] + +5.1.4. Performing the synthesis + + A synthetic AAAA record is created from an A record as follows: + + o The NAME field is set to the NAME field from the A record + + o The TYPE field is set to 28 (AAAA) + + o The CLASS field is set to 1 (IN) + + o The TTL field is set to the minimum of the TTL of the original A + RR and the SOA RR for the queried domain. (Note that in order to + obtain the TTL of the SOA RR the DNS64 does not need to perform a + new query, but it can remember the TTL from the SOA RR in the + negative response to the AAAA query). + + o The RDLENGTH field is set to 16 + + o The RDATA field is set to the IPv6 representation of the IPv4 + address from the RDATA field of the A record. The DNS64 SHOULD + check each A RR against IPv4 address ranges and select the + corresponding IPv6 prefix to use in synthesizing the AAAA RR. See + Section 5.2 for discussion of the algorithms to be used in + + + +Bagnulo, et al. Expires April 22, 2010 [Page 10] + +Internet-Draft DNS64 October 2009 + + + effecting the transformation. + +5.1.5. Querying in parallel + + DNS64 MAY perform the query for the AAAA RR and for the A RR in + parallel, in order to minimize the delay. However, this would result + in performing unnecessary A RR queries in the case no AAAA RR + synthesis is required. A possible trade-off would be to perform them + sequentially but with a very short interval between them, so if we + obtain a fast reply, we avoid doing the additional query. (Note that + this discussion is relevant only if the DNS64 function needs to + perform external queries to fetch the RR. If the needed RR + information is available locally, as in the case of an authoritative + server, the issue is no longer relevant.) + +5.2. Generation of the IPv6 representations of IPv4 addresses + + DNS64 supports multiple algorithms for the generation of the IPv6 + representation of an IPv4 address. The constraints imposed on the + generation algorithms are the following: + + The same algorithm to create an IPv6 address from an IPv4 address + MUST be used by both the DNS64 to create the IPv6 address to be + returned in the synthetic AAAA RR from the IPv4 address contained + in original A RR, and by the IPv6/IPv4 translator to create the + IPv6 address to be included in the destination address field of + the outgoing IPv6 packets from the IPv4 address included in the + destination address field of the incoming IPv4 packet. + + The algorithm MUST be reversible, i.e. it MUST be possible to + extract the original IPv4 address from the IPv6 representation. + + The input for the algorithm MUST be limited to the IPv4 address, + the IPv6 prefix (denoted Pref64::/n) used in the IPv6 + representations and optionally a set of stable parameters that are + configured in the DNS64 (such as fixed string to be used as a + suffix). + + If we note n the length of the prefix Pref64::/n, then n MUST + the less or equal than 96. If a Pref64::/n is configured + through any means in the DNS64 (such as manually configured, or + other automatic mean not specified in this document), the + default algorithm MUST use this prefix. If no prefix is + available, the algorithm MUST use the Well-Known prefix TBD1 + defined in [I-D.thaler-behave-translator-addressing] + + [[anchor12: Note in document: TBD1 in the passage above is to be + substituted by whatever prefix is assigned by IANA to be the well- + + + +Bagnulo, et al. Expires April 22, 2010 [Page 11] + +Internet-Draft DNS64 October 2009 + + + known prefix.]] + + DNS64 MUST support the following algorithms for generating IPv6 + representations of IPv4 addresses defined in + [I-D.thaler-behave-translator-addressing]: + + Zero-Pad And Embed, defined in section 3.2.3 of + [I-D.thaler-behave-translator-addressing] + + Compensation-Pad And Embed, defined in section of 3.2.4 of + [I-D.thaler-behave-translator-addressing] + + Embed And Zero-Pad, defined in section of 3.2.5 of + [I-D.thaler-behave-translator-addressing] + + Preconfigured Mapping Table, defined in section of 3.2.6 of + [I-D.thaler-behave-translator-addressing] + + The default algorithm used by DNS64 must be Embed and Zero-Pad. + While the normative description of the algorithms is provided in + [I-D.thaler-behave-translator-addressing], an sample description of + the algorithm and its application to different scenarios is provided + in Appendix A for illustration purposes. + +5.3. Handling other RRs + +5.3.1. PTR queries + + If a DNS64 nameserver receives a PTR query for a record in the + IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, + reverse the address portion of the QNAME according to the encoding + scheme outlined in section 2.5 of [RFC3596] , and examine the + resulting address to see whether its prefix matches the locally- + configured Pref64::/n. There are two alternatives for a DNS64 + nameserver to respond to such PTR queries. A DNS64 node MUST provide + one of these, and SHOULD NOT provide both at the same time unless + different IP6.ARPA zones require answers of different sorts. + + The first option is for the DNS64 nameserver to respond + authoritatively for its prefixes. If the address prefix matches any + Pref64::/n used in the site, either a LIR prefix or a well-known + prefix used for NAT64 as defined in + [I-D.thaler-behave-translator-addressing], then the DNS64 server MAY + answer the query using locally-appropriate RDATA. The DNS64 server + MAY use the same RDATA for all answers. Note that the requirement is + to match any Pref64::/n used at the site, and not merely the locally- + configured Pref64::/n. This is because end clients could ask for a + PTR record matching an address received through a different (site- + + + +Bagnulo, et al. Expires April 22, 2010 [Page 12] + +Internet-Draft DNS64 October 2009 + + + provided) DNS64, and if this strategy is in effect, those queries + should never be sent to the global DNS. The advantage of this + strategy is that it makes plain to the querying client that the + prefix is one operated by the DNS64 site, and that the answers the + client is getting are generated by the DNS64. The disadvantage is + that any useful reverse-tree information that might be in the global + DNS is unavailable to the clients querying the DNS64. + + The second option is for the DNS64 nameserver to synthesize a CNAME + mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA + name. The rest of the response would be the normal DNS processing. + The CNAME can be signed on the fly if need be. The advantage of this + approach is that any useful information in the reverse tree is + available to the querying client. The disadvantage is that it adds + additional load to the DNS64 (because CNAMEs have to be synthesized + for each PTR query that matches the Pref64::/n), and that it may + require signing on the fly. [[anchor15: what are we supposed to do + here when the in-addr.arpa zone is unmaintained, as it may be. If + there is no data at the target name, then we'll get a CNAME with a + map to an empty namespace, I think? Isn't that bad? + --ajs@shinkuro.com]] + + If the address prefix does not match any of the Pref64::/n, then the + DNS64 server MUST process the query as though it were any other query + -- i.e. a recursive nameserver MUST attempt to resolve the query as + though it were any other (non-A/AAAA) query, and an authoritative + server MUST respond authoritatively or with a referral, as + appropriate. + +5.3.2. Handling the additional section + + DNS64 synthesis MUST NOT be performed on any records in the + additional section of synthesized answers. The DNS64 MUST pass the + additional section unchanged. + + [[anchor16: We had some discussion, as an alternative to the above, + of allowing the DNS64 to truncate the additional section completely, + on the grounds that the additional section could break mixed-mode + iterative/forwarding resolvers that happen to end up behind DNS64. + Nobody else seemed to like that plan, so I haven't included it. + --ajs@shinkuro.com]] + +5.3.3. Other records + + If the DNS64 is in recursive resolver mode, then it SHOULD also serve + the zones specified in [I-D.ietf-dnsop-default-local-zones], rather + than forwarding those queries elsewhere to be handled. + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 13] + +Internet-Draft DNS64 October 2009 + + + All other RRs MUST be returned unchanged. + +5.4. Assembling a synthesized response to a AAAA query + + The DNS64 uses different pieces of data to build the response + returned to the querying client. + + The query that is used as the basis for synthesis results either in + an error, an answer that can be used as a basis for synthesis, or an + empty (authoritative) answer. If there is an empty answer, then the + DNS64 responds to the original querying client with the answer the + DNS64 received to the original AAAA query. Otherwise, the response + is assembled as follows. + + The header fields are set according to the usual rules for recursive + or authoritative servers, depending on the role that the DNS64 is + serving. The question section is copied from the original AAAA + query. The answer section is populated according to the rules in + Section 5.1.4. The authority section is copied from the response to + the A query that the DNS64 performed. The additional section is + populated according to the rules in Section 5.3.2. + + [[anchor18: The cross-reference to how to do the additional section + can be removed, and replaced by "copied from the response to the A + query that the DNS64 performed" if we don't want to allow the DNS64 + to truncate the additional section. See the note above. If I hear + no more feedback on this topic, then I'll make this change in the + next version. --ajs@shinkuro.com]] + +5.5. DNSSEC processing: DNS64 in recursive server mode + + We consider the case where the recursive server that is performing + DNS64 also has a local policy to validate the answers according to + the procedures outlined in [RFC4035] Section 5. We call this general + case vDNS64. + + The vDNS64 uses the presence of the DO and CD bits to make some + decisions about what the query originator needs, and can react + accordingly: + + 1. If CD is not set and DO is not set, vDNS64 SHOULD perform + validation and do synthesis as needed. + + 2. If CD is not set and DO is set, then vDNS64 SHOULD perform + validation. Whenever vDNS64 performs validation, it MUST + validate the negative answer for AAAA queries before proceeding + to query for A records for the same name, in order to be sure + that there is not a legitimate AAAA record on the Internet. + + + +Bagnulo, et al. Expires April 22, 2010 [Page 14] + +Internet-Draft DNS64 October 2009 + + + Failing to observe this step would allow an attacker to use DNS64 + as a mechanism to circumvent DNSSEC. If the negative response + validates, and the response to the A query validates, then the + vDNS64 MAY perform synthesis and SHOULD set the AD bit in the + answer to the client. This is acceptable, because [RFC4035], + section 3.2.3 says that the AD bit is set by the name server side + of a security-aware recursive name server if and only if it + considers all the RRSets in the Answer and Authority sections to + be authentic. In this case, the name server has reason to + believe the RRSets are all authentic, so it SHOULD set the AD + bit. If the data does not validate, the vDNS64 MUST respond with + RCODE=2 (server failure). + A security-aware end point might take the presence of the AD bit + as an indication that the data is valid, and may pass the DNS + (and DNSSEC) data to an application. If the application attempts + to validate the synthesized data, of course, the validation will + fail. One could argue therefore that this approach is not + desirable. But security aware stub resolvers MUST NOT place any + reliance on data received from resolvers and validated on their + behalf without certain criteria established by [RFC4035], section + 4.9.3. An application that wants to perform validation on its + own should use the CD bit. + + 3. If the CD bit is set and DO is set, then vDNS64 MAY perform + validation, but MUST NOT perform synthesis. It MUST hand the + data back to the query initiator, just like a regular recursive + resolver, and depend on the client to do the validation and the + synthesis itself. + The disadvantage to this approach is that an end point that is + translation-oblivious but security-aware and validating will not + be able to use the DNS64 functionality. In this case, the end + point will not have the desired benefit of NAT64. In effect, + this strategy means that any end point that wishes to do + validation in a NAT64 context must be upgraded to be translation- + aware as well. + +5.6. DNS64 and multihoming + + Synthetic AAAA records may be constructed on the basis of the network + context in which they were constructed. Therefore, a synthetic AAAA + received from one interface MUST NOT be used to resolve hosts via + another network interface. [[anchor21: This seems to be the result of + the discussion on-list starting with message id 18034D4D7FE9AE48BF19A + B1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com, but it's pretty + strange when stated baldly. In particular, how is the multi-homed + host supposed to know that a given AAAA is synthetic? + --ajs@shinkuro.com]] + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 15] + +Internet-Draft DNS64 October 2009 + + +6. Deployment notes + + While DNS64 is intended to be part of a strategy for aiding IPv6 + deployment in an internetworking environment with some IPv4-only and + IPv6-only networks, it is important to realise that it is + incompatible with some things that may be deployed in an IPv4-only or + dual-stack context. + +6.1. DNS resolvers and DNS64 + + Full-service resolvers that are unaware of the DNS64 function can be + (mis)configured to act as mixed-mode iterative and forwarding + resolvers. In a native-IPv4 context, this sort of configuration may + appear to work. It is impossible to make it work properly without it + being aware of the DNS64 function, because it will likely at some + point obtain IPv4-only glue records and attempt to use them for + resolution. The result that is returned will contain only A records, + and without the ability to perform the DNS64 function the resolver + will simply be unable to answer the necessary AAAA queries. + +6.2. DNSSEC validators and DNS64 + + Existing DNSSEC validators (i.e. that are unaware of DNS64) will + reject all the data that comes from the DNS64 as having been tampered + with. If it is necessary to have validation behind the DNS64, then + the validator must know how to perform the DNS64 function itself. + Alternatively, the validating host may establish a trusted connection + with the DNS64, and allow the DNS64 to do all validation on its + behalf. + + +7. Security Considerations + + See the discussion on the usage of DNSSEC and DNS64 described in the + document. + + +8. Contributors + + Dave Thaler + + Microsoft + + dthaler@windows.microsoft.com + + + + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 16] + +Internet-Draft DNS64 October 2009 + + +9. Acknowledgements + + This draft contains the result of discussions involving many people, + including the participants of the IETF BEHAVE Working Group. The + following IETF participants made specific contributions to parts of + the text, and their help is gratefully acknowledged: Mark Andrews, + Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet, + Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed + Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs + Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki + Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund, + Florian Weimer, Dan Wing, Xu Xiaohu. + + Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by + Trilogy, a research project supported by the European Commission + under its Seventh Framework Program. + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", + RFC 2672, August 1999. + + [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm + (SIIT)", RFC 2765, February 2000. + + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [I-D.ietf-behave-tcp] + Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. + Srisuresh, "NAT Behavioral Requirements for TCP", + draft-ietf-behave-tcp-08 (work in progress), + + + +Bagnulo, et al. Expires April 22, 2010 [Page 17] + +Internet-Draft DNS64 October 2009 + + + September 2008. + + [I-D.ietf-behave-nat-icmp] + Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT + Behavioral Requirements for ICMP protocol", + draft-ietf-behave-nat-icmp-12 (work in progress), + January 2009. + + [I-D.thaler-behave-translator-addressing] + Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators", + draft-thaler-behave-translator-addressing-00 (work in + progress), July 2009. + +10.2. Informative References + + [I-D.bagnulo-behave-nat64] + Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network + Address and Protocol Translation from IPv6 Clients to IPv4 + Servers", draft-bagnulo-behave-nat64-03 (work in + progress), March 2009. + + [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security + Considerations for IP Fragment Filtering", RFC 1858, + October 1995. + + [RFC3128] Miller, I., "Protection Against a Variant of the Tiny + Fragment Attack (RFC 1858)", RFC 3128, June 2001. + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + January 2001. + + [RFC3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + + + +Bagnulo, et al. Expires April 22, 2010 [Page 18] + +Internet-Draft DNS64 October 2009 + + + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network + Address Translator - Protocol Translator (NAT-PT) to + Historic Status", RFC 4966, July 2007. + + [I-D.iana-rfc3330bis] + Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", + draft-iana-rfc3330bis-06 (work in progress), + February 2009. + + [I-D.ietf-mmusic-ice] + Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", + draft-ietf-mmusic-ice-19 (work in progress), October 2007. + + [I-D.ietf-6man-addr-select-sol] + Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, + "Solution approaches for address-selection problems", + draft-ietf-6man-addr-select-sol-01 (work in progress), + June 2008. + + [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of + Managed Objects for Synchronous Optical Network (SONET) + Linear Automatic Protection Switching (APS) + Architectures", RFC 3498, March 2003. + + [I-D.wing-behave-learn-prefix] + Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix + of an IPv6/IPv4 Translator", + draft-wing-behave-learn-prefix-02 (work in progress), + May 2009. + + [I-D.miyata-behave-prefix64] + Miyata, H. and M. Bagnulo, "PREFIX64 Comparison", + draft-miyata-behave-prefix64-02 (work in progress), + March 2009. + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 19] + +Internet-Draft DNS64 October 2009 + + + [I-D.venaas-behave-mcast46] + Venaas, S., "An IPv4 - IPv6 multicast translator", + draft-venaas-behave-mcast46-00 (work in progress), + December 2008. + + [I-D.ietf-dnsop-default-local-zones] + Andrews, M., "Locally-served DNS Zones", + draft-ietf-dnsop-default-local-zones-08 (work in + progress), February 2009. + + +Appendix A. Deployment scenarios and examples + + In this section, we first provide a description of the default + address transformation algorithm and then we walk through some sample + scenarios that are expected to be common deployment cases. It should + be noted that is provided for illustrative purposes and this section + is not normative. The normative definition of DNS64 is provided in + Section 5 and the normative definition of the address transformation + algorithm is provided in [I-D.thaler-behave-translator-addressing]. + + There are two main different setups where DNS64 is expected to be + used (other setups are possible as well, but these two are the main + ones identified at the time of this writing). + + One possible setup that is expected to be common is the case of an + end site or an ISP that is providing IPv6-only connectivity or + connectivity to IPv6-only hosts that wants to allow the + communication from these IPv6-only connected hosts to the IPv4 + Internet. This case is called An-IPv6-network-to-IPv4-Internet. + In this case, the IPv6/IPv4 Translator is used to connect the end + site or the ISP to the IPv4 Internet and the DNS64 function is + provided by the end site or the ISP. + + The other possible setup that is expected is an IPv4 site that + wants that its IPv4 servers to be reachable from the IPv6 + Internet. This case is called IPv6-Internet-to-an-IPv4-network. + It should be noted that the IPv4 addresses used in the IPv4 site + can be either public or private. In this case, the IPv6/IPv4 + Translator is used to connect the IPv4 end site to the IPv6 + Internet and the DNS64 function is provided by the end site + itself. + + In this section we illustrate how the DNS64 behaves in the different + scenarios that are expected to be common. We consider then 3 + possible scenarios, namely: + + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 20] + +Internet-Draft DNS64 October 2009 + + + 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server + mode + + 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- + resolver mode + + 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server + mode + + The notation used is the following: upper case letters are IPv4 + addresses; upper case letters with a prime(') are IPv6 addresses; + lower case letters are ports; prefixes are indicated by "P::X", which + is an IPv6 address built from an IPv4 address X by adding the prefix + P, mappings are indicated as "(X,x) <--> (Y',y)". + +A.1. Embed and Zero-Pad algorithm description + + In this section we describe the default algorithm for the generation + of IPv6 address from IPv4 address to be implemented in the DNS64. + + The only parameter required by the default algorithm is an IPv6 + prefix. This prefix is used to map IPv4 addresses into IPv6 + addresses, and is denoted Pref64. If we note n the length of the + prefix Pref64, then n must the less or equal than 96. If an Pref64 + is configured through any means in the DNS64 (such as manually + configured, or other automatic mean not specified in this document), + the default algorithm must use this prefix. If no prefix is + available the algorithm must use the Well-Know prefix (include here + the prefix to be assigned by IANA) defined in + [I-D.thaler-behave-translator-addressing] + + The input for the algorithm are: + + The IPv4 address: X + + The IPv6 prefix: Pref64::/n + + The IPv6 address is generated by concatenating the prefix Pref64::/n, + the IPv4 address X and optionally (in case n is strictly smaller than + 96) an all-zero suffix. So, the resulting IPv6 address would be + Pref64:X:: + + Reverse algorithm + + We next describe the reverse algorithm of the algorithm described in + the previous section. This algorithm allows to generate and IPv4 + address from an IPv6 address. This reverse algorithm is NOT + implemented by the DNS64 but it is implemented in the IPv6/IPv4 + + + +Bagnulo, et al. Expires April 22, 2010 [Page 21] + +Internet-Draft DNS64 October 2009 + + + translator that is serving the same domain the DNS64. + + The only parameter required by the default algorithm is an IPv6 + prefix. This prefix is the one originally used to map IPv4 addresses + into IPv6 addresses, and is denoted Pref64. + + The input for the algorithm are: + + The IPv6 address: X' + + The IPv6 prefix: Pref64::/n + + First, the algorithm checks that the fist n bits of the IPv6 address + X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n = + X'/n. + + If this is not the case, the algorithm ends and no IPv4 address is + generated. + + If the verification is successful, then the bits between the n+1 + and the n+32 of the IPv6 address X' are extracted to form the IPv4 + address. + +A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server + mode + + In this example, we consider an IPv6 node located in an IPv6-only + site that initiates a communication to an IPv4 node located in the + IPv4 Internet. + + The scenario for this case is depicted in the following figure: + + + +---------------------------------------+ +-----------+ + |IPv6 site +-------------+ |IP Addr: | | + | +----+ | Name server | +-------+ T | IPv4 | + | | H1 | | with DNS64 | |64Trans|------| Internet | + | +----+ +-------------+ +-------+ +-----------+ + | |IP addr: Y' | | | |IP addr: X + | --------------------------------- | +----+ + +---------------------------------------+ | H2 | + +----+ + + The figure shows an IPv6 node H1 which has an IPv6 address Y' and an + IPv4 node H2 with IPv4 address X. + + A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 + Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n) + + + +Bagnulo, et al. Expires April 22, 2010 [Page 22] + +Internet-Draft DNS64 October 2009 + + + an IPv4 address T assigned to its IPv4 interface. + + The other element involved is the local name server. The name server + is a dual-stack node, so that H1 can contact it via IPv6, while it + can contact IPv4-only name servers via IPv4. + + The local name server needs to know the prefix assigned to the local + IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example, + we assume it learns this through manual configuration. + + For this example, assume the typical DNS situation where IPv6 hosts + have only stub resolvers, and always query a name server that + performs recursive lookups (henceforth called "the recursive + nameserver"). + + The steps by which H1 establishes communication with H2 are: + + 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS + query for an AAAA record for H2 to the recursive name server. + The recursive name server implements DNS64 functionality. + + 2. The recursive name server resolves the query, and discovers that + there are no AAAA records for H2. + + 3. The recursive name server queries for an A record for H2 and gets + back an A record containing the IPv4 address X. The name server + then synthesizes an AAAA record. The IPv6 address in the AAAA + record contains the prefix assigned to the IPv6/IPv4 Translator + in the upper n bits then the IPv4 address X and then an all-zero + padding i.e. the resulting IPv6 address is Pref64:X:: + + 4. H1 receives the synthetic AAAA record and sends a packet towards + H2. The packet is sent from a source transport address of (Y',y) + to a destination transport address of (Pref64:X::,x), where y and + x are ports chosen by H2. + + 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 + Translator and the subsequent communication flows by means of the + IPv6/IPv4 Translator mechanisms. + +A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver + mode + + The scenario for this case is depicted in the following figure: + + + + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 23] + +Internet-Draft DNS64 October 2009 + + + +---------------------------------------+ +-----------+ + |IPv6 site +-------+ |IP addr: | | + | +---------------+ | Name | +-------+ T | IPv4 | + | | H1 with DNS64 | | Server| |64Trans|------| Internet | + | +---------------+ +-------+ +-------+ +-----------+ + | |IP addr: Y' | | | |IP addr: X + | --------------------------------- | +----+ + +---------------------------------------+ | H2 | + +----+ + + The figure shows an IPv6 node H1 which has an IPv6 address Y' and an + IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64 + function. + + A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 + Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n) + and an IPv4 address T assigned to its IPv4 interface. + + H1 needs to know the prefix assigned to the local IPv6/IPv4 + Translator (Pref64::/n). For the purpose of this example, we assume + it learns this through manual configuration. + + Also shown is a name server. For the purpose of this example, we + assume that the name server is a dual-stack node, so that H1 can + contact it via IPv6, while it can contact IPv4-only name servers via + IPv4. + + For this example, assume the typical situation where IPv6 hosts have + only stub resolvers and always query a name server that provides + recursive lookups (henceforth called "the recursive name server"). + The recursive name server does not perform the DNS64 function. + + The steps by which H1 establishes communication with H2 are: + + 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS + query for a AAAA record for H2 to the recursive name server. + + 2. The recursive DNS server resolves the query, and returns the + answer to H1. Because there are no AAAA records in the global + DNS for H2, the answer is empty. + + 3. The stub resolver at H1 then queries for an A record for H2 and + gets back an A record containing the IPv4 address X. The DNS64 + function within H1 then synthesizes a AAAA record. The IPv6 + address in the AAAA record contains the prefix assigned to the + IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X + and then an all-zero padding i.e. the resulting IPv6 address is + Pref64:X::. + + + +Bagnulo, et al. Expires April 22, 2010 [Page 24] + +Internet-Draft DNS64 October 2009 + + + 4. H1 sends a packet towards H2. The packet is sent from a source + transport address of (Y',y) to a destination transport address of + (Pref64:X::,x), where y and x are ports chosen by H2. + + 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 + Translator and the subsequent communication flows using the IPv6/ + IPv4 Translator mechanisms. + +A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode + + In this example, we consider an IPv6 node located in the IPv6 + Internet site that initiates a communication to a IPv4 node located + in the IPv4 site. + + This scenario can be addressed without using any form of DNS64 + function. This is so because it is possible to assign a fixed IPv6 + address to each of the IPv4 servers. Such an IPv6 address would be + constructed as the Pref64::/n concatenated with the IPv4 address of + the IPv4 server and an all-zero padding. Note that the IPv4 address + can be a public or a private address; the latter does not present any + additional difficulty, since the LIR prefix must be used a Pref64 (in + this scenario the usage of the WK prefix is not supported). Once + these IPv6 addresses have been assigned to represent the IPv4 servers + in the IPv6 Internet, real AAAA RRs containing these addresses can be + published in the DNS under the site's domain. This is the + recommended approach to handle this scenario, because it does not + involve synthesizing AAAA records at the time of query. Such a + configuration is easier to troubleshoot in the event of problems, + because it always provides the same answer to every query. + + However, there are some more dynamic scenarios, where synthesizing + AAAA RRs in this setup may be needed. In particular, when DNS Update + [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 + servers, there are two options: One option is to modify the server + that receives the dynamic DNS updates. That would normally be the + authoritative server for the zone. So the authoritative zone would + have normal AAAA RRs that are synthesized as dynamic updates occur. + The other option is modify the authoritative server to generate + synthetic AAAA records for a zone, possibly based on additional + constraints, upon the receipt of a DNS query for the AAAA RR. The + first option -- in which the AAAA is synthesized when the DNS update + message is received, and the data published in the relevant zone -- + is recommended over the second option (i.e. the synthesis upon + receipt of the AAAA DNS query). This is because it is usually easier + to solve problems of misconfiguration and so on when the DNS + responses are not being generated dynamically. For completeness, the + DNS64 behavior that we describe in this section covers the case of + synthesizing the AAAA RR when the DNS query arrives. Nevertheless, + + + +Bagnulo, et al. Expires April 22, 2010 [Page 25] + +Internet-Draft DNS64 October 2009 + + + such a configuration is NOT RECOMMENDED. Troubleshooting + configurations that change the data depending on the query they + receive is notoriously hard, and the IPv4/IPv6 translation scenario + is complicated enough without adding additional opportunities for + possible malfunction. + + The scenario for this case is depicted in the following figure: + + + +-----------+ +----------------------------------------+ + | | | IPv4 site +-------------+ | + | IPv6 | +-------+ +----+ | Name server | | + | Internet |------|64Trans| | H2 | | with DNS64 | | + +-----------+ +-------+ +----+ +-------------+ | + |IP addr: Y' | | |IP addr: X | | + +----+ | ----------------------------------- | + | H1 | +----------------------------------------+ + +----+ + + The figure shows an IPv6 node H1 which has an IPv6 address Y' and an + IPv4 node H2 with IPv4 address X. + + A IPv6/IPv4 Translator connects the IPv4 network to the IPv6 + Internet. This IPv6/IPv4 Translator has a prefix (called + Pref64::/n). + + Also shown is the authoritative name server for the local domain with + DNS64 functionality. For the purpose of this example, we assume that + the name server is a dual-stack node, so that H1 or a recursive + resolver acting on the request of H1 can contact it via IPv6, while + it can be contacted by IPv4-only nodes to receive dynamic DNS updates + via IPv4. + + The local name server needs to know the prefix assigned to the local + IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example, + we assume it learns this through manual configuration. + + The steps by which H1 establishes communication with H2 are: + + 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS + query for an AAAA record for H2. The query is eventually + forwarded to the server in the IPv4 site. + + 2. The local DNS server resolves the query (locally), and discovers + that there are no AAAA records for H2. + + 3. The name server verifies that FQDN(H2) and its A RR are among + those that the local policy defines as allowed to generate a AAAA + + + +Bagnulo, et al. Expires April 22, 2010 [Page 26] + +Internet-Draft DNS64 October 2009 + + + RR from. If that is the case, the name server synthesizes an + AAAA record from the A RR and the relevant Pref64::/n. The IPv6 + address in the AAAA record contains the prefix assigned to the + IPv6/IPv4 Translator in the first n bits and the IPv4 address X + and then an all-zero padding. + + 4. H1 receives the synthetic AAAA record and sends a packet towards + H2. The packet is sent from a source transport address of (Y',y) + to a destination transport address of (Pref64:X::,x), where y and + x are ports chosen by H2. + + 5. The packet is routed through the IPv6 Internet to the IPv6 + interface of the IPv6/IPv4 Translator and the communication flows + using the IPv6/IPv4 Translator mechanisms. + + +Appendix B. Motivations and Implications of synthesizing AAAA RR when + real AAAA RR exists + + The motivation for synthesizing AAAA RR when a real AAAA RR exists is + to support the following scenario: + + An IPv4-only server application (e.g. web server software) is + running on a dual-stack host. There may also be dual-stack server + applications also running on the same host. That host has fully + routable IPv4 and IPv6 addresses and hence the authoritative DNS + server has an A and a AAAA record as a result. + + An IPv6-only client (regardless of whether the client application + is IPv6-only, the client stack is IPv6-only, or it only has an + IPv6 address) wants to access the above server. + + The client issues a DNS query to a DNS64 recursor. + + If the DNS64 only generates a synthetic AAAA if there's no real AAAA, + then the communication will fail. Even though there's a real AAAA, + the only way for communication to succeed is with the translated + address. So, in order to support this scenario, the administrator of + a DNS64 service may want to enable the synthesis of AAAA RR even when + real AAAA RR exist. + + The implication of including synthetic AAAA RR when real AAAA RR + exist is that translated connectivity may be preferred over native + connectivity in some cases where the DNS64 is operated in DNS server + mode. + + RFC3484 [RFC3484] rules use longest prefix match to select which is + the preferred destination address to use. So, if the DNS64 recursor + + + +Bagnulo, et al. Expires April 22, 2010 [Page 27] + +Internet-Draft DNS64 October 2009 + + + returns both the synthetic AAAA RR and the real AAAA RR, then if the + DNS64 is operated by the same domain as the initiating host, and a + global unicast prefix (called the LIR prefix as defined in + [I-D.thaler-behave-translator-addressing]) is used, then the + synthetic AAAA RR is likely to be preferred. + + This means that without further configuration: + + In the case of An IPv6 network to the IPv4 internet, the host will + prefer translated connectivity if LIR prefix is used. If the + Well-Known (WK) prefix defined in + [I-D.thaler-behave-translator-addressing] is used, it will + probably prefer native connectivity. + + In the case of the IPv6 Internet to an IPv4 network, it is + possible to bias the selection towards the real AAAA RR if the + DNS64 recursor returns the real AAAA first in the DNS reply, when + the LIR prefix is used (the WK prefix usage is not recommended in + this case) + + In the case of the IPv6 to IPv4 in the same network, for local + destinations (i.e., target hosts inside the local site), it is + likely that the LIR prefix and the destination prefix are the + same, so we can use the order of RR in the DNS reply to bias the + selection through native connectivity. If a WK prefix is used, + the longest prefix match rule will select native connectivity. + + So this option introduces problems in the following cases: + + An IPv6 network to the IPv4 internet with the LIR prefix + + IPv6 to IPv4 in the same network when reaching external + destinations and the LIR prefix is used. + + In any case, the problem can be solved by properly configuring the + RFC3484 [RFC3484] policy table, but this requires effort on the part + of the site operator. + + + + + + + + + + + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 28] + +Internet-Draft DNS64 October 2009 + + +Authors' Addresses + + Marcelo Bagnulo + UC3M + Av. Universidad 30 + Leganes, Madrid 28911 + Spain + + Phone: +34-91-6249500 + Fax: + Email: marcelo@it.uc3m.es + URI: http://www.it.uc3m.es/marcelo + + + Andrew Sullivan + Shinkuro + 4922 Fairmont Avenue, Suite 250 + Bethesda, MD 20814 + USA + + Phone: +1 301 961 3131 + Email: ajs@shinkuro.com + + + Philip Matthews + Unaffiliated + 600 March Road + Ottawa, Ontario + Canada + + Phone: +1 613-592-4343 x224 + Fax: + Email: philip_matthews@magma.ca + URI: + + + Iljitsch van Beijnum + IMDEA Networks + Av. Universidad 30 + Leganes, Madrid 28911 + Spain + + Phone: +34-91-6246245 + Email: iljitsch@muada.com + + + + + + + +Bagnulo, et al. Expires April 22, 2010 [Page 29] + diff --git a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-00.txt b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt index c1dc5fbc..41ae72ec 100644 --- a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-00.txt +++ b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt @@ -3,14 +3,14 @@ DNSEXT R. Bellis Internet-Draft Nominet UK -Updates: 1123, 1035 October 6, 2009 +Updates: 1035, 1123 October 26, 2009 (if approved) Intended status: Standards Track -Expires: April 9, 2010 +Expires: April 29, 2010 DNS Transport over TCP - draft-ietf-dnsext-dns-tcp-requirements-00 + draft-ietf-dnsext-dns-tcp-requirements-01 Status of this Memo @@ -33,7 +33,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 9, 2010. + This Internet-Draft will expire on April 29, 2010. Copyright Notice @@ -52,7 +52,7 @@ Abstract -Bellis Expires April 9, 2010 [Page 1] +Bellis Expires April 29, 2010 [Page 1] Internet-Draft DNS Transport over TCP October 2009 @@ -108,7 +108,7 @@ Table of Contents -Bellis Expires April 9, 2010 [Page 2] +Bellis Expires April 29, 2010 [Page 2] Internet-Draft DNS Transport over TCP October 2009 @@ -117,7 +117,7 @@ Internet-Draft DNS Transport over TCP October 2009 Most DNS [RFC1035] transactions take place over the UDP [RFC0792] protocol. The TCP [RFC0793] protocol is used for zone transfers and - is supported by some implementations for the transfer of other + is supported by many implementations for the transfer of other packets which exceed the protocol's original 512 byte packet-size limit. @@ -126,6 +126,9 @@ Internet-Draft DNS Transport over TCP October 2009 DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. + However, some implementors have taken the text quoted above to mean + that TCP support is truly optional for typical DNS operation. + This document normatively updates the core DNS protocol specifications such that (except in very limited circumstances) support for the TCP protocol is henceforth REQUIRED. @@ -140,36 +143,15 @@ Internet-Draft DNS Transport over TCP October 2009 3. Discussion - Some implementors have taken the [RFC1123] text quoted above to mean - that TCP support is truly optional for typical DNS operation. - - However, whilst RFC 1123 predates the current RFC 2119 terminology - document it uses exactly the same text: - - SHOULD - This word, or the adjective "RECOMMENDED", mean that - there may exist valid reasons in particular circumstances to - ignore a particular item, but the full implications must be - understood and carefully weighed before choosing a different - course. - In the absence of EDNS0 (see below) the normal behaviour of any DNS - server needing to send a UDP response that exceeds that 512 limit is - for the server to truncate the response at the 512 byte limit and set - the TC flag in the response header. When the client receives such a - response it takes the TC flag as notice that it should retry over TCP - instead. + server needing to send a UDP response that exceeds that 512 byte + limit is for the server to truncate the response at the 512 byte + limit and set the TC flag in the response header. When the client + receives such a response it takes the TC flag as notice that it + should retry over TCP instead. RFC 1123 also says: - - - -Bellis Expires April 9, 2010 [Page 3] - -Internet-Draft DNS Transport over TCP October 2009 - - - ... it is also clear that some new DNS record types defined in the future will contain information exceeding the 512 byte limit that applies to UDP, and hence will require TCP. Thus, resolvers and @@ -179,11 +161,19 @@ Internet-Draft DNS Transport over TCP October 2009 Existing deployments of DNSSEC [RFC4033] have shown that truncation at the 512 byte boundary is now commonplace. For example an NXDOMAIN + + + +Bellis Expires April 29, 2010 [Page 3] + +Internet-Draft DNS Transport over TCP October 2009 + + (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155] is almost invariably longer than 512 bytes. - Since the original core specifications for DNS were written the - Extension Mechanisms for DNS EDNS0 [RFC2671] have been introduced. + Since the original core specifications for DNS were written, the + Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. These extensions can be used to indicate that the client is prepared to receive UDP responses longer than 512 bytes. An EDNS0 compatible server receiving a request from an EDNS0 compatible client may send @@ -203,30 +193,22 @@ Internet-Draft DNS Transport over TCP October 2009 1500 bytes, and even that limit is routinely exceeded by DNSSEC signed responses. - The future that was anticipated in RFC 1123 is now here, and the only + The future that was anticipated in RFC 1123 has arrived, and the only standardised mechanism which may have resolved the packet size issue has been found inadequate. 4. Transport Protocol Selection - On a case by case basis, authoritative DNS server operators MAY elect - to disable DNS transport over TCP if all of the conditions below are - satisfied: - - o the server is authoritative - - - - - -Bellis Expires April 9, 2010 [Page 4] - -Internet-Draft DNS Transport over TCP October 2009 + All DNS implementations MUST support both UDP and TCP transport + protocols, except as set out below. + On a case by case basis, authoritative DNS server operators MAY elect + to disable DNS transport over TCP if all of the following conditions + are satisfied: + o the server is authoritative only o the server does not support AXFR - o the server does not support DNSSEC o all requests and responses are guaranteed to be <= 512 bytes A general purpose stub resolver implementation (e.g. an operating @@ -235,25 +217,31 @@ Internet-Draft DNS Transport over TCP October 2009 with upstream servers. A proprietary stub resolver implementation MAY omit support for TCP - if it is operating in an environment where truncation will not occur, - or if it is prepared to accept a DNS lookup failure should truncation - occur. + + + +Bellis Expires April 29, 2010 [Page 4] + +Internet-Draft DNS Transport over TCP October 2009 + + + if it is operating in an environment where truncation can never + occur, or if it is prepared to accept a DNS lookup failure should + truncation occur. A recursive resolver or forwarder MUST support TCP so that it does not prevent long responses from a TCP-capable server from reaching its TCP-capable clients. - Otherwise, all DNS implementations MUST support TCP transport. - Regarding the choice of when to use UDP or TCP, RFC 1123 says: ... a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first. - This requirement is no longer mandatory. A resolver SHOULD send a - UDP query first, but MAY elect to send a TCP query instead if it has - good reason to expect the response would be truncated if it were sent - over UDP, or other operational considerations suggest otherwise. + That requirement is hereby relaxed. A resolver SHOULD send a UDP + query first, but MAY elect to send a TCP query instead if it has good + reason to expect the response would be truncated if it were sent over + UDP (with or without EDNS0) or for other operational reasons. 5. Dormant Connection Handling @@ -271,31 +259,42 @@ Internet-Draft DNS Transport over TCP October 2009 them dormant can trivially create a "denial of service" attack. This document therefore RECOMMENDS that the idle period should be of - the order of TBD seconds. With modern high performance networks 2 to - 4 seconds should be sufficient to allow significant numbers (i.e. + the order of TBD seconds. + Servers MAY allow dormant connections to remain open for longer + periods, but for the avoidance of doubt persistent DNS connections + should generally be considered to be as much for the server's benefit + as for the client's. Therefore if the server needs to unilaterally + close a dormant TCP connection it MUST be free to do so whenever + required. + Further recommendations for the tuning of TCP parameters to allow + higher throughput or improved resiliency against denial of service + attacks are (currently) outside the scope of this document. -Bellis Expires April 9, 2010 [Page 5] - -Internet-Draft DNS Transport over TCP October 2009 - thousands) of concurrent dormant connections without impacting - service performance. - Servers MAY allow idle connections to remain open for longer periods, - but for the avoidance of doubt persistent DNS connections should - generally be considered to be as much for the server's benefit as for - the client's. Therefore if the server needs to unilaterally close a - dormant TCP connection it MUST be free to do so whenever required. + +Bellis Expires April 29, 2010 [Page 5] + +Internet-Draft DNS Transport over TCP October 2009 6. Response re-ordering - [Potential text to be added regarding whether TCP responses can come - back in a different order to requests. I'm not aware whether this is - specified anywhere] + RFC 1035 is ambiguous on the question of whether TCP queries may be + re-ordered - the only relevant text is in Section 4.2.1 which relates + to UDP: + + Queries or their responses may be reordered by the network, or by + processing in name servers, so resolvers should not depend on them + being returned in order. + + For the avoidance of future doubt, this requirement is clarified. + Client resolvers MUST be able to process responses which arrive in a + different order to that in which the requests were sent, regardless + of the transport protocol in use. 7. Security Considerations @@ -329,16 +328,15 @@ Internet-Draft DNS Transport over TCP October 2009 RFC 792, September 1981. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. -Bellis Expires April 9, 2010 [Page 6] +Bellis Expires April 29, 2010 [Page 6] Internet-Draft DNS Transport over TCP October 2009 - RFC 793, September 1981. - [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. @@ -377,6 +375,10 @@ Appendix A. Change Log NB: to be removed by the RFC Editor before publication. + draft-ietf-dnsext-dns-tcp-requirements-01 + Addition of response ordering section + Various minor editorial changes from WG reviewers + draft-ietf-dnsext-dns-tcp-requirements-00 Initial draft @@ -386,9 +388,7 @@ Appendix A. Change Log - - -Bellis Expires April 9, 2010 [Page 7] +Bellis Expires April 29, 2010 [Page 7] Internet-Draft DNS Transport over TCP October 2009 @@ -444,5 +444,5 @@ Author's Address -Bellis Expires April 9, 2010 [Page 8] +Bellis Expires April 29, 2010 [Page 8] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-01.txt new file mode 100644 index 00000000..c7ffbce4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-gost-01.txt @@ -0,0 +1,435 @@ +DNS Extensions working group V.Dolmatov, Ed. +Internet-Draft Cryptocom Ltd. +Intended status: Standards Track October 18, 2009 +Expires: April 18, 2010 + + + Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records + for DNSSEC + draft-ietf-dnsext-dnssec-gost-01 + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 18 2010. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + This document describes how to produce GOST signature and hash + algorithms DNSKEY and RRSIG resource records for use in the Domain + Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, + and RFC 4035). + +V.Dolmatov Expires April 18, 2010 [Page 1] + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Using a public key with existing cryptographic libraries. . 3 + 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 3 + 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 + 3.1 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 4 + 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 + 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 + 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Implementation Considerations . . . . . . . . . . . . . . . . . 5 + 6.1. Support for GOST signatures . . . . . . . . . . . . . . . . 5 + 6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 5 + 6.3. Byte order . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical distributed + database for Internet Naming. The DNS has been extended to use + cryptographic keys and digital signatures for the verification of the + authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 + [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security + Extensions, called DNSSEC. + + RFC 4034 describes how to store DNSKEY and RRSIG resource records, + and specifies a list of cryptographic algorithms to use. This + document extends that list with the signature and hash algorithms + GOST [GOST3410, GOST3411], + and specifies how to store DNSKEY data and how to produce + RRSIG resource records with these hash algorithms. + + Familiarity with DNSSEC and GOST signature and hash + algorithms is assumed in this document. + + The term "GOST" is not officially defined, but is usually used to + refer to the collection of the Russian cryptographic algorithms + GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. + Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to + the GOST R 34.10-2001 and GOST R 34.11-94 in this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +V.Dolmatov Expires April 18, 2010 [Page 2] + +2. DNSKEY Resource Records + + The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. + + GOST R 34.10-2001 public keys are stored with the algorithm number + {TBA1}. + + The wire format of the public key is compatible with + RFC 4491 [RFC4491]: + + According to [GOSTR341001], a public key is a point on the elliptic + curve Q = (x,y). + + The wire representation of a public key MUST contain 66 octets, + where the first octet designates public key parameters, the second + octet designates digest parameters next 32 octets contain the + little-endian representation of x and the second 32 octets contain + the little-endian representation of y. + This corresponds to the binary representation of (<y>256||<x>256) + from [GOSTR341001], ch. 5.3. + + The only valid value for both parameters octets is 0. + Other parameters octets values are reserved for future use. + + Corresponding public key parameters are those identified by + id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357], + and the digest parameters are those identified by + id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357]. + +2.1. Using a public key with existing cryptographic libraries + + Existing GOST-aware cryptographic libraries at the time of this + document writing are capable to read GOST public keys via a generic + X509 API if the key is encoded according to RFC 4491 [RFC4491], + section 2.3.2. + + To make this encoding from the wire format of a GOST public key + with the parameters used in this document, prepend last 64 octets + of key data (in other words, substitute first two parameter octets) + with the following 37-byte sequence: + + 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 + 0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a + 0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40 + +2.2. GOST DNSKEY RR Example + + Given a private key with the following value: + + Private-key-format: v1.2 + Algorithm: {TBA1} (GOST) + GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEE + IgQgAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= + + (corresponding to private key value 1) + +V.Dolmatov Expires April 18, 2010 [Page 3] + + The following DNSKEY RR stores a DNS zone key for example.net + + example.net. 86400 IN DNSKEY 256 3 {TBA1} ( AAABAAAAAAAAAAAAAAAAAAAA + AAAAAAAAAAAAAAAAAAAAABQe + n56cyawiseMj3y1PKTV2Kz9F + WlDfJ9qcmOBx5JGN ) + +3. RRSIG Resource Records + + The value of the signature field in the RRSIG RR follows RFC 4490 + [RFC4490] and is calculated as follows. The values for the RDATA + fields that precede the signature data are specified + in RFC 4034 [RFC4034]. + + hash = GOSTR3411(data) + + where "data" is the wire format data of the resource record set + that is signed, as specified in RFC 4034 [RFC4034]. + + Hash MUST be calculated with GOST R 34.11-94 parameters identified + by id-GostR3411-94-CryptoProParamSet [RFC4357]. + + Signature is calculated from the hash according to the + GOST R 34.10-2001 standard and its wire format is compatible with + RFC 4490 [RFC4490]. + + Quoting RFC 4490: + + "The signature algorithm GOST R 34.10-2001 generates a digital + signature in the form of two 256-bit numbers, r and s. Its octet + string representation consists of 64 octets, where the first 32 + octets contain the big-endian representation of s and the second 32 + octets contain the big-endian representation of r." + +3.1. RRSIG RR Example + + With the private key from section 2.2 sign the following RRSet, + consisting of one A record: + + www.example.net. 3600 IN A 192.0.32.10 + + Setting the inception date to 2000-01-01 00:00:00 UTC and the + expiration date to 2030-01-01 00:00:00 UTC, the following signature + should be created (assuming {TBA1}==249 until proped code is + assigned by IANA) + + www.example.net. 3600 IN RRSIG ( A {TBA1} 3 3600 + 20300101000000 20000101000000 9033 example.net. + 96ObOt5gR6Xln8g42w70OZvi6BZoQvLIhrN9F+VBc29mp+ap + DQov1re0hApGenYDd2zLaHecw4H2vnPj0NhhxA== ) + +4. DS Resource Records + + GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest + type {TBA2}. The wire format of a digest value is compatible with + RFC 4490 [RFC4490]. + +V.Dolmatov Expires April 18, 2010 [Page 4] + + Quoting RFC 4490: + + "A 32-byte digest in little-endian representation." + + The digest MUST always be calculated with GOST R 34.11-94 parameters + identified by id-GostR3411-94-CryptoProParamSet [RFC4357]. + +4.1. DS RR Example + + example.net. 3600 IN DS 9033 {TBA1} {TBA2} ( Su0ToNow7Lwex+wqac+cTQ + djJ733qubhan+KqUrselc= ) + +5. Deployment Considerations + +5.1. Key Sizes + + According to RFC4357 [RFC4357], the key size of GOST public keys + MUST be 512 bits. + +5.2. Signature Sizes + + According to the GOST signature algorithm specification [GOST3410], + the size of a GOST signature is 512 bits. + +5.3. Digest Sizes + + According to the GOST R 34.11-94 [GOST3411], the size of a GOST digest + is 256 bits. + +6. Implementation Considerations + +6.1. Support for GOST signatures + + DNSSEC aware implementations SHOULD be able to support RRSIG and + DNSKEY resource records created with the GOST algorithms as + defined in this document. + +6.2. Support for NSEC3 Denial of Existence + + Any DNSSEC-GOST implementation is required to have either NSEC or + NSEC3 support. + +6.3 Byte order + + Due to the fact that all existing industry implementations of GOST + cryptographic libraries are returning GOST blobs in little-endian + format and in order to avoid the necessity for DNSSEC developers + to hanlde different cryptographic algorithms differently, it was + chosen to send these blobs on the wire "as is" without + transformation of endianness. + +7. Security considerations + + Currently, the cryptographic resistance of the GOST 34.10-2001 + digital signature algorithm is estimated as 2**128 operations + of multiple elliptic curve point computations on prime modulus + 2**256. + +V.Dolmatov Expires April 18, 2010 [Page 5] + + Currently, the cryptographic resistance of GOST 34.11-94 hash + algorithm is estimated as 2**128 operations of computations of a + step hash function. (There is known method to reduce this + estimate to 2**105 operations, but it demands padding the + colliding message with 1024 random bit blocks each of 256 bit + length, thus it cannot be used in any practical implementation). + +8. IANA Considerations + + This document updates the IANA registry "DNS SECURITY ALGORITHM + NUMBERS -- per [RFC4035] " + (http://www.iana.org/assignments/dns-sec-alg-numbers). The + following entries are added to the registry: + Zone Trans. + Value Algorithm Mnemonic Signing Sec. References Status + {TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL + + This document updates the RFC 4034 [RFC4034] Digest Types assignment + (RFC 4034, section A.2): + + Value Algorithm Status + {TBA2} GOST R 34.11-94 OPTIONAL + +9. Acknowledgments + + This document is a minor extension to RFC 4034 [RFC4034]. Also, we + tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509], + and RFC 4357 [RFC4357] for consistency. The authors of and + contributors to these documents are gratefully acknowledged for + their hard work. + + The following people provided additional feedback and text: Dmitry + Burkov, Jaap Akkerhuis, Olafur Gundmundsson,Jelte Jansen + and Wouter Wijngaards. + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC3110] Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC4033] Arends R., Austein R., Larson M., Massey D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends R., Austein R., Larson M., Massey D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + +V.Dolmatov Expires April 18, 2010 [Page 6] + + [RFC4035] Arends R., Austein R., Larson M., Massey D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [GOST3410] "Information technology. Cryptographic data security. + Signature and verification processes of [electronic] + digital signature.", GOST R 34.10-2001, Gosudarstvennyi + Standard of Russian Federation, Government Committee of + the Russia for Standards, 2001. (In Russian) + + [GOST3411] "Information technology. Cryptographic Data Security. + Hashing function.", GOST R 34.11-94, Gosudarstvennyi + Standard of Russian Federation, Government Committee of + the Russia for Standards, 1994. (In Russian) + + [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional + Cryptographic Algorithms for Use with GOST 28147-89, + GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 + Algorithms", RFC 4357, January 2006. + + [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, + GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 + Algorithms with Cryptographic Message Syntax (CMS)", + RFC 4490, May 2006. + + [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST + R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 + Algorithms with the Internet X.509 Public Key + Infrastructure Certificate and CRL Profile", RFC 4491, + May 2006. + + + +10.2. Informative References + + [NIST800-57] + Barker E., Barker W., Burr W., Polk W., and M. Smid, + "Recommendations for Key Management", NIST SP 800-57, + March 2007. + + [RFC3447] Jonsson J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [RFC4509] Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + + [DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., + "GOST R 34.10-2001 digital signature algorithm" + draft-dolmatov-cryptocom-gost3410-2001-05, + work in progress +V.Dolmatov Expires April 18, 2010 [Page 7] + + [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., + "GOST R 34.11-94 Hash function algorithm" + draft-dolmatov-cryptocom-gost341194-03, work in progress + + [DRAFT3] Dolmatov V., Kabelev D., Ustinov I., Emelyanova I., + "GOST 28147-89 encryption, decryption and MAC algorithms" + draft-dolmatov-cryptocom-gost2814789-03, work in progress + +Authors' Addresses + + +Vasily Dolmatov, Ed. +Cryptocom Ltd. +Bolotnikovskaya, 23 +Moscow, 117303, Russian Federation + +EMail: dol@cryptocom.ru + +Artem Chuprina +Cryptocom Ltd. +Bolotnikovskaya, 23 +Moscow, 117303, Russian Federation + +EMail: ran@cryptocom.ru + +Igor Ustinov +Cryptocom Ltd. +Bolotnikovskaya, 23 +Moscow, 117303, Russian Federation + +EMail: igus@cryptocom.ru + +V.Dolmatov Expires April 18, 2010 [Page 8] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-13.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-14.txt index bab65653..57bc52bc 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-13.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-14.txt @@ -3,13 +3,13 @@ DNS Extensions working group J. Jansen Internet-Draft NLnet Labs -Intended status: Standards Track April 24, 2009 -Expires: October 26, 2009 +Intended status: Standards Track June 04, 2009 +Expires: December 6, 2009 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC - draft-ietf-dnsext-dnssec-rsasha256-13 + draft-ietf-dnsext-dnssec-rsasha256-14 Status of this Memo @@ -32,7 +32,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 26, 2009. + This Internet-Draft will expire on December 6, 2009. Copyright Notice @@ -52,9 +52,9 @@ Abstract -Jansen Expires October 26, 2009 [Page 1] +Jansen Expires December 6, 2009 [Page 1] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). @@ -77,7 +77,7 @@ Table of Contents 5.2. Support for NSEC3 Denial of Existence . . . . . . . . . . 5 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. RSA/SHA-256 Key and Signature . . . . . . . . . . . . . . 6 - 6.2. RSA/SHA-512 Key and Signature . . . . . . . . . . . . . . 6 + 6.2. RSA/SHA-512 Key and Signature . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource @@ -108,9 +108,9 @@ Table of Contents -Jansen Expires October 26, 2009 [Page 2] +Jansen Expires December 6, 2009 [Page 2] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 1. Introduction @@ -164,9 +164,9 @@ Internet-Draft DNSSEC RSA/SHA-2 April 2009 -Jansen Expires October 26, 2009 [Page 3] +Jansen Expires December 6, 2009 [Page 3] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 2.2. RSA/SHA-512 DNSKEY Resource Records @@ -220,9 +220,9 @@ Internet-Draft DNSSEC RSA/SHA-2 April 2009 -Jansen Expires October 26, 2009 [Page 4] +Jansen Expires December 6, 2009 [Page 4] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 3.2. RSA/SHA-512 RRSIG Resource Records @@ -276,14 +276,15 @@ Internet-Draft DNSSEC RSA/SHA-2 April 2009 -Jansen Expires October 26, 2009 [Page 5] +Jansen Expires December 6, 2009 [Page 5] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 - both NSEC and NSEC3 [RFC5155] negative answers. An authoritative - server that does not implement NSEC3 MAY still serve zones that use - RSA/SHA-2 with NSEC denial of existence. + negative answers in the form of both NSEC and NSEC3 with hash + algorithm 1, as defined in [RFC5155]. An authoritative server that + does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 + with NSEC denial of existence. 6. Examples @@ -313,84 +314,83 @@ Internet-Draft DNSSEC RSA/SHA-2 April 2009 With this key, sign the following RRSet, consisting of 1 A record: - www.example.net. 3600 IN A 123.123.123.123 + www.example.net. 3600 IN A 192.0.2.91 If the inception date is set at 00:00 hours on January 1st, 2000, and the expiration date at 00:00 hours on January 1st, 2030, the following signature should be created: www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000 - 20000101000000 9033 example.net. KWgSIg3khRfyrHmtJU - 5pzpsANyy27+HOZ6waMQ5kV690ljVmbHmGc8ULOfXw3aWmP0wJB - ND/TQhjCvrb3T9ffQ== );{id = 9033} + 20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9 + l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa + cFYK/lPtPiVYP4bwg== ;{id = 9033} + -6.2. RSA/SHA-512 Key and Signature - Given a private key with the following values (in Base64): -Jansen Expires October 26, 2009 [Page 6] +Jansen Expires December 6, 2009 [Page 6] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 +6.2. RSA/SHA-512 Key and Signature + + Given a private key with the following values (in Base64): + Private-key-format: v1.2 - Algorithm: 9 (RSASHA512) - Modulus: 8Du9YHEwFNjO5iG9jrrNyKwRs5mAzJgXBrjbA49R/ESWJKw6eHH - XfZaxnP+gVhZBDmqwND/SFwrEkN5LyH3HZ+/d/ECW+vT8Lxprqf - haTfxQkV4OFjw/ikuTcBMoUIYfhO1NVPBcH1mWh34DWmu6eedzH - IbdeNZnIkWSv4muchs= + Algorithm: 10 (RSASHA512) + Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf + Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk + 8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V + jXZlNKdyit99waaE4s= PublicExponent: AQAB - PrivateExponent: sRm5YLHQ2m2DCdDx55j7P+bqHdcaRroQr5nzi8pKjIkbjumRKV3 - zmNhRFAa3cv9w8mnggIRUIzyC8LGQeLuRFjbv6uXDzoPX2O321j - PlTUOwCYMTVnbkZUem6c+7iRd2v5zNNe9uiXex6T8CDXyhQhqYb - 8q2AajPrTlRzv6uW8E= - Prime1: +DPVg2OlfYqcNlm67T42608gjyqWFdVc0UtDDDBo+ABWavqp+Yk - Fb/z/Ig+iBE901Q8RWdqVLND3PtGwWipIyw== - Prime2: 98fQbOaWH3D/WFhnu47f1qOgaob/ss3FQ12QbUdRDpgfmdryHH7 - j1UGR2Xs0aRPwBASXYhgtamXtxLorXIFh8Q== - Exponent1: j0UsbGlqr6sBPQZStnuBLBdCziFg/T1qFI4DJ9gR34YiXCJRV29 - Wqiw6AalQdnh/EjVeaKWaEoKVFbfoukNKPQ== - Exponent2: 4YTy9ftVjd5p+f3UxEgBATnCatLebd6NeYfySRQM+YyJzp4RmNA - BC/t3BQv3IuBrpyyKoFTDGUEWjOSpTLPR8Q== - Coefficient: BpIAEwh5rlw9M8FpGHjpF5TxSdhCjnA8NT0tB+MB/k0msceyBbx - avjzJXTi/QPk9PIO8Wv6eCzMQEM0QDZO53Q== + PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6 + AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj + yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3 + SEIAsrB043XzGrKIVE= + Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x + nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ== + Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK + Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw== + Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM + MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q== + Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J + PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w== + Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q + /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ== The DNSKEY record for this key would be: - example.net. 3600 IN DNSKEY (256 3 9 AwEAAfA7vWBxMBTYzuYhvY66z - cisEbOZgMyYFwa42wOPUfxEliSsOnhx132WsZz/oFYWQQ5qsDQ/0 - hcKxJDeS8h9x2fv3fxAlvr0/C8aa6n4Wk38UJFeDhY8P4pLk3ATK - FCGH4TtTVTwXB9Zlod+A1prunnncxyG3XjWZyJFkr+JrnIb - );{id = 28237 (zsk), size = 1024b} + example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD + p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD + xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g + pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL + );{id = 3740 (zsk), size = 1024b} With this key, sign the following RRSet, consisting of 1 A record: - www.example.net. 3600 IN A 123.123.123.123 + www.example.net. 3600 IN A 192.0.2.91 If the inception date is set at 00:00 hours on January 1st, 2000, and the expiration date at 00:00 hours on January 1st, 2030, the following signature should be created: - www.example.net. 3600 IN RRSIG (A 9 3 3600 20300101000000 - 20000101000000 28237 example.net. mCanSdkQztEUOmslG - z7VvfkKPMp4ftz3K1PTf2jdla4vUu/tRE585xymurMB+wXhrFcK - dhm0egnPq8X/gmm0cmui/GQwFT5hmP5bL1ETuQsM3HOu3j9E3tq - 4sFWIsUv3N6ohpYEbhj5jk0b/01EMUPM9y5rLzFHmYYujzKQwqu - M= );{id = 28237} - - - - + www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000 + 20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t + 6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa + eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL + DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw + =);{id = 3740} -Jansen Expires October 26, 2009 [Page 7] +Jansen Expires December 6, 2009 [Page 7] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 7. IANA Considerations @@ -444,9 +444,9 @@ Internet-Draft DNSSEC RSA/SHA-2 April 2009 -Jansen Expires October 26, 2009 [Page 8] +Jansen Expires December 6, 2009 [Page 8] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 9. Acknowledgments @@ -500,9 +500,9 @@ Internet-Draft DNSSEC RSA/SHA-2 April 2009 -Jansen Expires October 26, 2009 [Page 9] +Jansen Expires December 6, 2009 [Page 9] -Internet-Draft DNSSEC RSA/SHA-2 April 2009 +Internet-Draft DNSSEC RSA/SHA-2 June 2009 Version 2.1", RFC 3447, February 2003. @@ -556,5 +556,5 @@ Author's Address -Jansen Expires October 26, 2009 [Page 10] +Jansen Expires December 6, 2009 [Page 10] diff --git a/doc/rfc/index b/doc/rfc/index index 2c9eea95..53b42128 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -20,6 +20,7 @@ 1750: Randomness Recommendations for Security 1876: A Means for Expressing Location Information in the Domain Name System 1886: DNS Extensions to support IP version 6 +1912: Common DNS Operational and Configuration Errors 1982: Serial Number Arithmetic 1995: Incremental Zone Transfer in DNS 1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) @@ -120,5 +121,5 @@ Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) 4892: Requirements for a Mechanism Identifying a Name Server Instance 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence -5295: Host Identity Protocol (HIP) Domain Name System (DNS) Extension +5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extension 5507: Design Choices When Expanding the DNS diff --git a/doc/rfc/rfc1912.txt b/doc/rfc/rfc1912.txt new file mode 100644 index 00000000..8ace7d26 --- /dev/null +++ b/doc/rfc/rfc1912.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group D. Barr +Request for Comments: 1912 The Pennsylvania State University +Obsoletes: 1537 February 1996 +Category: Informational + + + Common DNS Operational and Configuration Errors + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This memo describes errors often found in both the operation of + Domain Name System (DNS) servers, and in the data that these DNS + servers contain. This memo tries to summarize current Internet + requirements as well as common practice in the operation and + configuration of the DNS. This memo also tries to summarize or + expand upon issues raised in [RFC 1537]. + +1. Introduction + + Running a nameserver is not a trivial task. There are many things + that can go wrong, and many decisions have to be made about what data + to put in the DNS and how to set up servers. This memo attempts to + address many of the common mistakes and pitfalls that are made in DNS + data as well as in the operation of nameservers. Discussions are + also made regarding some other relevant issues such as server or + resolver bugs, and a few political issues with respect to the + operation of DNS on the Internet. + +2. DNS Data + + This section discusses problems people typically have with the DNS + data in their nameserver, as found in the zone data files that the + nameserver loads into memory. + +2.1 Inconsistent, Missing, or Bad Data + + Every Internet-reachable host should have a name. The consequences + of this are becoming more and more obvious. Many services available + on the Internet will not talk to you if you aren't correctly + registered in the DNS. + + + + + +Barr Informational [Page 1] + +RFC 1912 Common DNS Errors February 1996 + + + Make sure your PTR and A records match. For every IP address, there + should be a matching PTR record in the in-addr.arpa domain. If a + host is multi-homed, (more than one IP address) make sure that all IP + addresses have a corresponding PTR record (not just the first one). + Failure to have matching PTR and A records can cause loss of Internet + services similar to not being registered in the DNS at all. Also, + PTR records must point back to a valid A record, not a alias defined + by a CNAME. It is highly recommended that you use some software + which automates this checking, or generate your DNS data from a + database which automatically creates consistent data. + + DNS domain names consist of "labels" separated by single dots. The + DNS is very liberal in its rules for the allowable characters in a + domain name. However, if a domain name is used to name a host, it + should follow rules restricting host names. Further if a name is + used for mail, it must follow the naming rules for names in mail + addresses. + + Allowable characters in a label for a host name are only ASCII + letters, digits, and the `-' character. Labels may not be all + numbers, but may have a leading digit (e.g., 3com.com). Labels must + end and begin only with a letter or digit. See [RFC 1035] and [RFC + 1123]. (Labels were initially restricted in [RFC 1035] to start with + a letter, and some older hosts still reportedly have problems with + the relaxation in [RFC 1123].) Note there are some Internet + hostnames which violate this rule (411.org, 1776.com). The presence + of underscores in a label is allowed in [RFC 1033], except [RFC 1033] + is informational only and was not defining a standard. There is at + least one popular TCP/IP implementation which currently refuses to + talk to hosts named with underscores in them. It must be noted that + the language in [1035] is such that these rules are voluntary -- they + are there for those who wish to minimize problems. Note that the + rules for Internet host names also apply to hosts and addresses used + in SMTP (See RFC 821). + + If a domain name is to be used for mail (not involving SMTP), it must + follow the rules for mail in [RFC 822], which is actually more + liberal than the above rules. Labels for mail can be any ASCII + character except "specials", control characters, and whitespace + characters. "Specials" are specific symbols used in the parsing of + addresses. They are the characters "()<>@,;:\".[]". (The "!" + character wasn't in [RFC 822], however it also shouldn't be used due + to the conflict with UUCP mail as defined in RFC 976) However, since + today almost all names which are used for mail on the Internet are + also names used for hostnames, one rarely sees addresses using these + relaxed standard, but mail software should be made liberal and robust + enough to accept them. + + + + +Barr Informational [Page 2] + +RFC 1912 Common DNS Errors February 1996 + + + You should also be careful to not have addresses which are valid + alternate syntaxes to the inet_ntoa() library call. For example 0xe + is a valid name, but if you were to type "telnet 0xe", it would try + to connect to IP address 0.0.0.14. It is also rumored that there + exists some broken inet_ntoa() routines that treat an address like + x400 as an IP address. + + Certain operating systems have limitations on the length of their own + hostname. While not strictly of issue to the DNS, you should be + aware of your operating system's length limits before choosing the + name of a host. + + Remember that many resource records (abbreviated RR) take on more + than one argument. HINFO requires two arguments, as does RP. If you + don't supply enough arguments, servers sometime return garbage for + the missing fields. If you need to include whitespace within any + data, you must put the string in quotes. + +2.2 SOA records + + In the SOA record of every zone, remember to fill in the e-mail + address that will get to the person who maintains the DNS at your + site (commonly referred to as "hostmaster"). The `@' in the e-mail + must be replaced by a `.' first. Do not try to put an `@' sign in + this address. If the local part of the address already contains a + `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by + preceding it with `\' character. (e.g., to become + John\.Smith.widget.xx) Alternately (and preferred), you can just use + the generic name `hostmaster', and use a mail alias to redirect it to + the appropriate persons. There exists software which uses this field + to automatically generate the e-mail address for the zone contact. + This software will break if this field is improperly formatted. It + is imperative that this address get to one or more real persons, + because it is often used for everything from reporting bad DNS data + to reporting security incidents. + + Even though some BIND versions allow you to use a decimal in a serial + number, don't. A decimal serial number is converted to an unsigned + 32-bit integer internally anyway. The formula for a n.m serial + number is n*10^(3+int(0.9+log10(m))) + m which translates to + something rather unexpected. For example it's routinely possible + with a decimal serial number (perhaps automatically generated by + SCCS) to be incremented such that it is numerically larger, but after + the above conversion yield a serial number which is LOWER than + before. Decimal serial numbers have been officially deprecated in + recent BIND versions. The recommended syntax is YYYYMMDDnn + (YYYY=year, MM=month, DD=day, nn=revision number. This won't + overflow until the year 4294. + + + +Barr Informational [Page 3] + +RFC 1912 Common DNS Errors February 1996 + + + Choose logical values for the timer values in the SOA record (note + values below must be expressed as seconds in the zone data): + + Refresh: How often a secondary will poll the primary server to see + if the serial number for the zone has increased (so it knows + to request a new copy of the data for the zone). Set this to + how long your secondaries can comfortably contain out-of-date + data. You can keep it short (20 mins to 2 hours) if you + aren't worried about a small increase in bandwidth used, or + longer (2-12 hours) if your Internet connection is slow or is + started on demand. Recent BIND versions (4.9.3) have optional + code to automatically notify secondaries that data has + changed, allowing you to set this TTL to a long value (one + day, or more). + + Retry: If a secondary was unable to contact the primary at the + last refresh, wait the retry value before trying again. This + value isn't as important as others, unless the secondary is on + a distant network from the primary or the primary is more + prone to outages. It's typically some fraction of the refresh + interval. + + + Expire: How long a secondary will still treat its copy of the zone + data as valid if it can't contact the primary. This value + should be greater than how long a major outage would typically + last, and must be greater than the minimum and retry + intervals, to avoid having a secondary expire the data before + it gets a chance to get a new copy. After a zone is expired a + secondary will still continue to try to contact the primary, + but it will no longer provide nameservice for the zone. 2-4 + weeks are suggested values. + + Minimum: The default TTL (time-to-live) for resource records -- + how long data will remain in other nameservers' cache. ([RFC + 1035] defines this to be the minimum value, but servers seem + to always implement this as the default value) This is by far + the most important timer. Set this as large as is comfortable + given how often you update your nameserver. If you plan to + make major changes, it's a good idea to turn this value down + temporarily beforehand. Then wait the previous minimum value, + make your changes, verify their correctness, and turn this + value back up. 1-5 days are typical values. Remember this + value can be overridden on individual resource records. + + + + + + + +Barr Informational [Page 4] + +RFC 1912 Common DNS Errors February 1996 + + + As you can see, the typical values above for the timers vary widely. + Popular documentation like [RFC 1033] recommended a day for the + minimum TTL, which is now considered too low except for zones with + data that vary regularly. Once a DNS stabilizes, values on the order + of 3 or more days are recommended. It is also recommended that you + individually override the TTL on certain RRs which are often + referenced and don't often change to have very large values (1-2 + weeks). Good examples of this are the MX, A, and PTR records of your + mail host(s), the NS records of your zone, and the A records of your + nameservers. + +2.3 Glue A Records + + Glue records are A records that are associated with NS records to + provide "bootstrapping" information to the nameserver. For example: + + podunk.xx. in ns ns1.podunk.xx. + in ns ns2.podunk.xx. + ns1.podunk.xx. in a 1.2.3.4 + ns2.podunk.xx. in a 1.2.3.5 + + Here, the A records are referred to as "Glue records". + + Glue records are required only in forward zone files for nameservers + that are located in the subdomain of the current zone that is being + delegated. You shouldn't have any A records in an in-addr.arpa zone + file (unless you're using RFC 1101-style encoding of subnet masks). + + If your nameserver is multi-homed (has more than one IP address), you + must list all of its addresses in the glue to avoid cache + inconsistency due to differing TTL values, causing some lookups to + not find all addresses for your nameserver. + + Some people get in the bad habit of putting in a glue record whenever + they add an NS record "just to make sure". Having duplicate glue + records in your zone files just makes it harder when a nameserver + moves to a new IP address, or is removed. You'll spend hours trying + to figure out why random people still see the old IP address for some + host, because someone forgot to change or remove a glue record in + some other file. Newer BIND versions will ignore these extra glue + records in local zone files. + + Older BIND versions (4.8.3 and previous) have a problem where it + inserts these extra glue records in the zone transfer data to + secondaries. If one of these glues is wrong, the error can be + propagated to other nameservers. If two nameservers are secondaries + for other zones of each other, it's possible for one to continually + pass old glue records back to the other. The only way to get rid of + + + +Barr Informational [Page 5] + +RFC 1912 Common DNS Errors February 1996 + + + the old data is to kill both of them, remove the saved backup files, + and restart them. Combined with that those same versions also tend + to become infected more easily with bogus data found in other non- + secondary nameservers (like the root zone data). + +2.4 CNAME records + + A CNAME record is not allowed to coexist with any other data. In + other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you + can't also have an MX record for suzy.podunk.edu, or an A record, or + even a TXT record. Especially do not try to combine CNAMEs and NS + records like this!: + + + podunk.xx. IN NS ns1 + IN NS ns2 + IN CNAME mary + mary IN A 1.2.3.4 + + + This is often attempted by inexperienced administrators as an obvious + way to allow your domain name to also be a host. However, DNS + servers like BIND will see the CNAME and refuse to add any other + resources for that name. Since no other records are allowed to + coexist with a CNAME, the NS entries are ignored. Therefore all the + hosts in the podunk.xx domain are ignored as well! + + If you want to have your domain also be a host, do the following: + + podunk.xx. IN NS ns1 + IN NS ns2 + IN A 1.2.3.4 + mary IN A 1.2.3.4 + + Don't go overboard with CNAMEs. Use them when renaming hosts, but + plan to get rid of them (and inform your users). However CNAMEs are + useful (and encouraged) for generalized names for servers -- `ftp' + for your ftp server, `www' for your Web server, `gopher' for your + Gopher server, `news' for your Usenet news server, etc. + + Don't forget to delete the CNAMEs associated with a host if you + delete the host it is an alias for. Such "stale CNAMEs" are a waste + of resources. + + + + + + + + +Barr Informational [Page 6] + +RFC 1912 Common DNS Errors February 1996 + + + Don't use CNAMEs in combination with RRs which point to other names + like MX, CNAME, PTR and NS. (PTR is an exception if you want to + implement classless in-addr delegation.) For example, this is + strongly discouraged: + + podunk.xx. IN MX mailhost + mailhost IN CNAME mary + mary IN A 1.2.3.4 + + + [RFC 1034] in section 3.6.2 says this should not be done, and [RFC + 974] explicitly states that MX records shall not point to an alias + defined by a CNAME. This results in unnecessary indirection in + accessing the data, and DNS resolvers and servers need to work more + to get the answer. If you really want to do this, you can accomplish + the same thing by using a preprocessor such as m4 on your host files. + + Also, having chained records such as CNAMEs pointing to CNAMEs may + make administration issues easier, but is known to tickle bugs in + some resolvers that fail to check loops correctly. As a result some + hosts may not be able to resolve such names. + + Having NS records pointing to a CNAME is bad and may conflict badly + with current BIND servers. In fact, current BIND implementations + will ignore such records, possibly leading to a lame delegation. + There is a certain amount of security checking done in BIND to + prevent spoofing DNS NS records. Also, older BIND servers reportedly + will get caught in an infinite query loop trying to figure out the + address for the aliased nameserver, causing a continuous stream of + DNS requests to be sent. + +2.5 MX records + + It is a good idea to give every host an MX record, even if it points + to itself! Some mailers will cache MX records, but will always need + to check for an MX before sending mail. If a site does not have an + MX, then every piece of mail may result in one more resolver query, + since the answer to the MX query often also contains the IP addresses + of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to + support the MX mechanism. + + Put MX records even on hosts that aren't intended to send or receive + e-mail. If there is a security problem involving one of these hosts, + some people will mistakenly send mail to postmaster or root at the + site without checking first to see if it is a "real" host or just a + terminal or personal computer that's not set up to accept e-mail. If + you give it an MX record, then the e-mail can be redirected to a real + person. Otherwise mail can just sit in a queue for hours or days + + + +Barr Informational [Page 7] + +RFC 1912 Common DNS Errors February 1996 + + + until the mailer gives up trying to send it. + + Don't forget that whenever you add an MX record, you need to inform + the target mailer if it is to treat the first host as "local". (The + "Cw" flag in sendmail, for example) + + If you add an MX record which points to an external host (e.g., for + the purposes of backup mail routing) be sure to ask permission from + that site first. Otherwise that site could get rather upset and take + action (like throw your mail away, or appeal to higher authorities + like your parent DNS administrator or network provider.) + +2.6 Other Resource Records + +2.6.1 WKS + + WKS records are deprecated in [RFC 1123]. They serve no known useful + function, except internally among LISP machines. Don't use them. + +2.6.2 HINFO + + On the issue HINFO records, some will argue that these is a security + problem (by broadcasting what vendor hardware and operating system + you so people can run systematic attacks on known vendor security + holes). If you do use them, you should keep up to date with known + vendor security problems. However, they serve a useful purpose. + Don't forget that HINFO requires two arguments, the hardware type, + and the operating system. + + HINFO is sometimes abused to provide other information. The record + is meant to provide specific information about the machine itself. + If you need to express other information about the host in the DNS, + use TXT. + +2.6.3 TXT + + TXT records have no specific definition. You can put most anything + in them. Some use it for a generic description of the host, some put + specific information like its location, primary user, or maybe even a + phone number. + +2.6.4 RP + + RP records are relatively new. They are used to specify an e-mail + address (see first paragraph of section 2.2) of the "Responsible + Person" of the host, and the name of a TXT record where you can get + more information. See [RFC 1183]. + + + + +Barr Informational [Page 8] + +RFC 1912 Common DNS Errors February 1996 + + +2.7 Wildcard records + + Wildcard MXs are useful mostly for non IP-connected sites. A common + mistake is thinking that a wildcard MX for a zone will apply to all + hosts in the zone. A wildcard MX will apply only to names in the + zone which aren't listed in the DNS at all. e.g., + + podunk.xx. IN NS ns1 + IN NS ns2 + mary IN A 1.2.3.4 + *.podunk.xx. IN MX 5 sue + + Mail for mary.podunk.xx will be sent to itself for delivery. Only + mail for jane.podunk.xx or any hosts you don't see above will be sent + to the MX. For most Internet sites, wildcard MX records are not + useful. You need to put explicit MX records on every host. + + Wildcard MXs can be bad, because they make some operations succeed + when they should fail instead. Consider the case where someone in + the domain "widget.com" tries to send mail to "joe@larry". If the + host "larry" doesn't actually exist, the mail should in fact bounce + immediately. But because of domain searching the address gets + resolved to "larry.widget.com", and because of the wildcard MX this + is a valid address according to DNS. Or perhaps someone simply made + a typo in the hostname portion of the address. The mail message then + gets routed to the mail host, which then rejects the mail with + strange error messages like "I refuse to talk to myself" or "Local + configuration error". + + Wildcard MX records are good for when you have a large number of + hosts which are not directly Internet-connected (for example, behind + a firewall) and for administrative or political reasons it is too + difficult to have individual MX records for every host, or to force + all e-mail addresses to be "hidden" behind one or more domain names. + In that case, you must divide your DNS into two parts, an internal + DNS, and an external DNS. The external DNS will have only a few + hosts and explicit MX records, and one or more wildcard MXs for each + internal domain. Internally the DNS will be complete, with all + explicit MX records and no wildcards. + + Wildcard As and CNAMEs are possible too, and are really confusing to + users, and a potential nightmare if used without thinking first. It + could result (due again to domain searching) in any telnet/ftp + attempts from within the domain to unknown hosts to be directed to + one address. One such wildcard CNAME (in *.edu.com) caused + Internet-wide loss of services and potential security nightmares due + to unexpected interactions with domain searching. It resulted in + swift fixes, and even an RFC ([RFC 1535]) documenting the problem. + + + +Barr Informational [Page 9] + +RFC 1912 Common DNS Errors February 1996 + + +2.8 Authority and Delegation Errors (NS records) + + You are required to have at least two nameservers for every domain, + though more is preferred. Have secondaries outside your network. If + the secondary isn't under your control, periodically check up on them + and make sure they're getting current zone data from you. Queries to + their nameserver about your hosts should always result in an + "authoritative" response. If not, this is called a "lame + delegation". A lame delegations exists when a nameserver is + delegated responsibility for providing nameservice for a zone (via NS + records) but is not performing nameservice for that zone (usually + because it is not set up as a primary or secondary for the zone). + + The "classic" lame delegation can be illustrated in this example: + + podunk.xx. IN NS ns1.podunk.xx. + IN NS ns0.widget.com. + + "podunk.xx" is a new domain which has recently been created, and + "ns1.podunk.xx" has been set up to perform nameservice for the zone. + They haven't quite finished everything yet and haven't made sure that + the hostmaster at "ns0.widget.com" has set up to be a proper + secondary, and thus has no information about the podunk.xx domain, + even though the DNS says it is supposed to. Various things can + happen depending on which nameserver is used. At best, extra DNS + traffic will result from a lame delegation. At worst, you can get + unresolved hosts and bounced e-mail. + + Also, sometimes a nameserver is moved to another host or removed from + the list of secondaries. Unfortunately due to caching of NS records, + many sites will still think that a host is a secondary after that + host has stopped providing nameservice. In order to prevent lame + delegations while the cache is being aged, continue to provide + nameservice on the old nameserver for the length of the maximum of + the minimum plus refresh times for the zone and the parent zone. + (See section 2.2) + + Whenever a primary or secondary is removed or changed, it takes a + fair amount of human coordination among the parties involved. (The + site itself, it's parent, and the site hosting the secondary) When a + primary moves, make sure all secondaries have their named.boot files + updated and their servers reloaded. When a secondary moves, make + sure the address records at both the primary and parent level are + changed. + + It's also been reported that some distant sites like to pick popular + nameservers like "ns.uu.net" and just add it to their list of NS + records in hopes that they will magically perform additional + + + +Barr Informational [Page 10] + +RFC 1912 Common DNS Errors February 1996 + + + nameservice for them. This is an even worse form of lame delegation, + since this adds traffic to an already busy nameserver. Please + contact the hostmasters of sites which have lame delegations. + Various tools can be used to detect or actively find lame + delegations. See the list of contributed software in the BIND + distribution. + + Make sure your parent domain has the same NS records for your zone as + you do. (Don't forget your in-addr.arpa zones too!). Do not list + too many (7 is the recommended maximum), as this just makes things + harder to manage and is only really necessary for very popular top- + level or root zones. You also run the risk of overflowing the 512- + byte limit of a UDP packet in the response to an NS query. If this + happens, resolvers will "fall back" to using TCP requests, resulting + in increased load on your nameserver. + + It's important when picking geographic locations for secondary + nameservers to minimize latency as well as increase reliability. + Keep in mind network topologies. For example if your site is on the + other end of a slow local or international link, consider a secondary + on the other side of the link to decrease average latency. Contact + your Internet service provider or parent domain contact for more + information about secondaries which may be available to you. + +3. BIND operation + + This section discusses common problems people have in the actual + operation of the nameserver (specifically, BIND). Not only must the + data be correct as explained above, but the nameserver must be + operated correctly for the data to be made available. + +3.1 Serial numbers + + Each zone has a serial number associated with it. Its use is for + keeping track of who has the most current data. If and only if the + primary's serial number of the zone is greater will the secondary ask + the primary for a copy of the new zone data (see special case below). + + Don't forget to change the serial number when you change data! If + you don't, your secondaries will not transfer the new zone + information. Automating the incrementing of the serial number with + software is also a good idea. + + If you make a mistake and increment the serial number too high, and + you want to reset the serial number to a lower value, use the + following procedure: + + + + + +Barr Informational [Page 11] + +RFC 1912 Common DNS Errors February 1996 + + + Take the `incorrect' serial number and add 2147483647 to it. If + the number exceeds 4294967296, subtract 4294967296. Load the + resulting number. Then wait 2 refresh periods to allow the zone + to propagate to all servers. + + Repeat above until the resulting serial number is less than the + target serial number. + + Up the serial number to the target serial number. + + This procedure won't work if one of your secondaries is running an + old version of BIND (4.8.3 or earlier). In this case you'll have to + contact the hostmaster for that secondary and have them kill the + secondary servers, remove the saved backup file, and restart the + server. Be careful when editing the serial number -- DNS admins + don't like to kill and restart nameservers because you lose all that + cached data. + +3.2 Zone file style guide + + Here are some useful tips in structuring your zone files. Following + these will help you spot mistakes, and avoid making more. + + Be consistent with the style of entries in your DNS files. If your + $ORIGIN is podunk.xx., try not to write entries like: + + mary IN A 1.2.3.1 + sue.podunk.xx. IN A 1.2.3.2 + + or: + + bobbi IN A 1.2.3.2 + IN MX mary.podunk.xx. + + + Either use all FQDNs (Fully Qualified Domain Names) everywhere or + used unqualified names everywhere. Or have FQDNs all on the right- + hand side but unqualified names on the left. Above all, be + consistent. + + Use tabs between fields, and try to keep columns lined up. It makes + it easier to spot missing fields (note some fields such as "IN" are + inherited from the previous record and may be left out in certain + circumstances.) + + + + + + + +Barr Informational [Page 12] + +RFC 1912 Common DNS Errors February 1996 + + + Remember you don't need to repeat the name of the host when you are + defining multiple records for one host. Be sure also to keep all + records associated with a host together in the file. It will make + things more straightforward when it comes time to remove or rename a + host. + + Always remember your $ORIGIN. If you don't put a `.' at the end of + an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then + the nameserver will append $ORIGIN to the name. Double check, triple + check, those trailing dots, especially in in-addr.arpa zone files, + where they are needed the most. + + Be careful with the syntax of the SOA and WKS records (the records + which use parentheses). BIND is not very flexible in how it parses + these records. See the documentation for BIND. + +3.3 Verifying data + + Verify the data you just entered or changed by querying the resolver + with dig (or your favorite DNS tool, many are included in the BIND + distribution) after a change. A few seconds spent double checking + can save hours of trouble, lost mail, and general headaches. Also be + sure to check syslog output when you reload the nameserver. If you + have grievous errors in your DNS data or boot file, named will report + it via syslog. + + It is also highly recommended that you automate this checking, either + with software which runs sanity checks on the data files before they + are loaded into the nameserver, or with software which checks the + data already loaded in the nameserver. Some contributed software to + do this is included in the BIND distribution. + +4. Miscellaneous Topics + +4.1 Boot file setup + + Certain zones should always be present in nameserver configurations: + + primary localhost localhost + primary 0.0.127.in-addr.arpa 127.0 + primary 255.in-addr.arpa 255 + primary 0.in-addr.arpa 0 + + These are set up to either provide nameservice for "special" + addresses, or to help eliminate accidental queries for broadcast or + local address to be sent off to the root nameservers. All of these + files will contain NS and SOA records just like the other zone files + you maintain, the exception being that you can probably make the SOA + + + +Barr Informational [Page 13] + +RFC 1912 Common DNS Errors February 1996 + + + timers very long, since this data will never change. + + The "localhost" address is a "special" address which always refers to + the local host. It should contain the following line: + + localhost. IN A 127.0.0.1 + + The "127.0" file should contain the line: + + 1 PTR localhost. + + There has been some extensive discussion about whether or not to + append the local domain to it. The conclusion is that "localhost." + would be the best solution. The reasons given include: + + "localhost" by itself is used and expected to work in some + systems. + + Translating 127.0.0.1 into "localhost.dom.ain" can cause some + software to connect back to the loopback interface when it didn't + want to because "localhost" is not equal to "localhost.dom.ain". + + The "255" and "0" files should not contain any additional data beyond + the NS and SOA records. + + Note that future BIND versions may include all or some of this data + automatically without additional configuration. + +4.2 Other Resolver and Server bugs + + Very old versions of the DNS resolver have a bug that cause queries + for names that look like IP addresses to go out, because the user + supplied an IP address and the software didn't realize that it didn't + need to be resolved. This has been fixed but occasionally it still + pops up. It's important because this bug means that these queries + will be sent directly to the root nameservers, adding to an already + heavy DNS load. + + While running a secondary nameserver off another secondary nameserver + is possible, it is not recommended unless necessary due to network + topologies. There are known cases where it has led to problems like + bogus TTL values. While this may be caused by older or flawed DNS + implementations, you should not chain secondaries off of one another + since this builds up additional reliability dependencies as well as + adds additional delays in updates of new zone data. + + + + + + +Barr Informational [Page 14] + +RFC 1912 Common DNS Errors February 1996 + + +4.3 Server issues + + DNS operates primarily via UDP (User Datagram Protocol) messages. + Some UNIX operating systems, in an effort to save CPU cycles, run + with UDP checksums turned off. The relative merits of this have long + been debated. However, with the increase in CPU speeds, the + performance considerations become less and less important. It is + strongly encouraged that you turn on UDP checksumming to avoid + corrupted data not only with DNS but with other services that use UDP + (like NFS). Check with your operating system documentation to verify + that UDP checksumming is enabled. + +References + + [RFC 974] Partridge, C., "Mail routing and the domain system", STD + 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986. + + [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC + 1033, USC/Information Sciences Institute, November 1987. + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, USC/Information Sciences Institute, + November 1987. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + [RFC 1123] Braden, R., "Requirements for Internet Hosts -- + Application and Support", STD 3, RFC 1123, IETF, October + 1989. + + [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC + 1178, Integrated Systems Group/NIST, August 1990. + + [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart, + "New DNS RR Definitions", RFC 1183, October 1990. + + [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction + With Widely Deployed DNS Software", RFC 1535, ACES + Research Inc., October 1993. + + [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. + Miller, "Common DNS Implementation Errors and Suggested + Fixes", RFC 1536, USC/Information Sciences Institute, USC, + October 1993. + + + + + +Barr Informational [Page 15] + +RFC 1912 Common DNS Errors February 1996 + + + [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors", + RFC 1537, CWI, October 1993. + + [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN, + November 1994. + + [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND", + Vixie Enterprises, July 1994. + +5. Security Considerations + + Security issues are not discussed in this memo. + +6. Author's Address + + David Barr + The Pennsylvania State University + Department of Mathematics + 334 Whitmore Building + University Park, PA 16802 + + Voice: +1 814 863 7374 + Fax: +1 814 863-8311 + EMail: barr@math.psu.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barr Informational [Page 16] + |