diff options
| author | Internet Software Consortium, Inc <@isc.org> | 2009-12-26 18:04:05 -0700 |
|---|---|---|
| committer | Internet Software Consortium, Inc <@isc.org> | 2009-12-26 18:04:05 -0700 |
| commit | 2d27fb027f207bdec109fad8c9c65f9d6278b3db (patch) | |
| tree | 114b1faecb63eeee27fb44da040d619cac686d72 /doc | |
| parent | 76d4794687ff55c501dc8f09f200494ef1ac429d (diff) | |
| download | bind9-2d27fb027f207bdec109fad8c9c65f9d6278b3db.tar.gz | |
9.7.0rc1
Diffstat (limited to 'doc')
68 files changed, 894 insertions, 33750 deletions
diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 66eb7525..510e4cc5 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.445 2009/11/10 19:49:32 each Exp $ --> +<!-- File: $Id: Bv9ARM-book.xml,v 1.450 2009/12/04 21:59:23 marka Exp $ --> <book xmlns:xi="http://www.w3.org/2001/XInclude"> <title>BIND 9 Administrator Reference Manual</title> @@ -4906,6 +4906,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] ... }; </optional> <optional> check-names ( <replaceable>master</replaceable> | <replaceable>slave</replaceable> | <replaceable>response</replaceable> ) ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional> + <optional> check-dup-records ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional> <optional> check-mx ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional> <optional> check-wildcard <replaceable>yes_or_no</replaceable>; </optional> <optional> check-integrity <replaceable>yes_or_no</replaceable>; </optional> @@ -4923,8 +4924,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] <optional> allow-update { <replaceable>address_match_list</replaceable> }; </optional> <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional> <optional> update-check-ksk <replaceable>yes_or_no</replaceable>; </optional> - <optional> dnskey-ksk-only <replaceable>yes_or_no</replaceable>; </optional> - <optional> secure-to-insecure <replaceable>yes_or_no</replaceable> ;</optional> + <optional> dnssec-dnskey-kskonly <replaceable>yes_or_no</replaceable>; </optional> + <optional> dnssec-secure-to-insecure <replaceable>yes_or_no</replaceable> ;</optional> <optional> try-tcp-refresh <replaceable>yes_or_no</replaceable>; </optional> <optional> allow-v6-synthesis { <replaceable>address_match_list</replaceable> }; </optional> <optional> blackhole { <replaceable>address_match_list</replaceable> }; </optional> @@ -6251,6 +6252,10 @@ options { to DNS clients unless they have connections to the IPv6 Internet. This is not recommended unless absolutely necessary. The default is <userinput>no</userinput>. + The <command>filter-aaaa-on-v4</command> option + may also be specified in <command>view</command> statements + to override the global <command>filter-aaaa-on-v4</command> + option. </para> <para> If <userinput>yes</userinput>, @@ -6421,6 +6426,30 @@ options { </varlistentry> <varlistentry> + <term><command>check-dup-records</command></term> + <listitem> + <para> + Check master zones for records that are treated as different + by DNSSEC but are semantically equal in plain DNS. The + default is to <command>warn</command>. Other possible + values are <command>fail</command> and + <command>ignore</command>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>check-mx</command></term> + <listitem> + <para> + Check whether the MX record appears to refer to a IP address. + The default is to <command>warn</command>. Other possible + values are <command>fail</command> and + <command>ignore</command>. + </para> + </listitem> + </varlistentry> + <varlistentry> <term><command>check-mx</command></term> <listitem> <para> @@ -6552,7 +6581,7 @@ options { </varlistentry> <varlistentry> - <term><command>dnskey-ksk-only</command></term> + <term><command>dnssec-dnskey-kskonly</command></term> <listitem> <para> When this option and <command>update-check-ksk</command> @@ -6584,7 +6613,7 @@ options { </varlistentry> <varlistentry> - <term><command>secure-to-insecure</command></term> + <term><command>dnssec-secure-to-insecure</command></term> <listitem> <para> Allow a zone to transition from secure to insecure by @@ -9516,8 +9545,8 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional> <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional> <optional> update-check-ksk <replaceable>yes_or_no</replaceable>; </optional> - <optional> dnskey-ksk-only <replaceable>yes_or_no</replaceable>; </optional> - <optional> secure-to-insecure <replaceable>yes_or_no</replaceable> ; </optional> + <optional> dnssec-dnskey-kskonly <replaceable>yes_or_no</replaceable>; </optional> + <optional> dnssec-secure-to-insecure <replaceable>yes_or_no</replaceable> ; </optional> <optional> try-tcp-refresh <replaceable>yes_or_no</replaceable>; </optional> <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional> @@ -10030,11 +10059,11 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea </varlistentry> <varlistentry> - <term><command>dnskey-ksk-only</command></term> + <term><command>dnssec-dnskey-kskonly</command></term> <listitem> <para> See the description of - <command>dnskey-ksk-only</command> in <xref linkend="boolean_options"/>. + <command>dnssec-dnskey-kskonly</command> in <xref linkend="boolean_options"/>. </para> </listitem> </varlistentry> @@ -10431,7 +10460,8 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea <para> <command>auto-dnssec allow;</command> permits keys to be updated and the zone re-signed whenever the - user issues the command <command>rndc sign</command>. + user issues the command <command>rndc sign + <replaceable>zonename</replaceable></command>. </para> <para> <command>auto-dnssec maintain;</command> includes the @@ -10474,11 +10504,11 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea </varlistentry> <varlistentry> - <term><command>secure-to-insecure</command></term> + <term><command>dnssec-secure-to-insecure</command></term> <listitem> <para> See the description of - <command>secure-to-insecure</command> in <xref linkend="boolean_options"/>. + <command>dnssec-secure-to-insecure</command> in <xref linkend="boolean_options"/>. </para> </listitem> </varlistentry> @@ -15617,12 +15647,16 @@ zone "example.com" { <xi:include href="../../bin/check/named-checkconf.docbook"/> <xi:include href="../../bin/check/named-checkzone.docbook"/> <xi:include href="../../bin/named/named.docbook"/> + <xi:include href="../../bin/tools/named-journalprint.docbook"/> <!-- named.conf.docbook and others? --> <xi:include href="../../bin/nsupdate/nsupdate.docbook"/> <xi:include href="../../bin/rndc/rndc.docbook"/> <xi:include href="../../bin/rndc/rndc.conf.docbook"/> <xi:include href="../../bin/confgen/rndc-confgen.docbook"/> <xi:include href="../../bin/confgen/ddns-confgen.docbook"/> + <xi:include href="../../bin/tools/arpaname.docbook"/> + <xi:include href="../../bin/tools/genrandom.docbook"/> + <xi:include href="../../bin/tools/nsec3hash.docbook"/> </reference> </book> diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html index 580aeaa4..ab9e955e 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.245 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch06.html,v 1.249 2009/12/04 22:22:26 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#id2587892"><span><strong class="command">statistics-channels</strong></span> Statement Definition and +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588103"><span><strong class="command">statistics-channels</strong></span> Statement Definition and Usage</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588046"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588166"><span><strong class="command">trusted-keys</strong></span> Statement Definition +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588326"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588377"><span><strong class="command">trusted-keys</strong></span> Statement Definition and Usage</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588213"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588264"><span><strong class="command">managed-keys</strong></span> Statement Definition +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588424"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588475"><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#id2588568"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588848"><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#id2590278"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590421"><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#id2593012">Zone File</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2593225">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#id2595242">Discussion of MX Records</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595387">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#id2595858">Inverse Mapping in IPv4</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596053">Other Zone File Directives</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596326"><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#id2596003">Inverse Mapping in IPv4</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596130">Other Zone File Directives</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596403"><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> @@ -2121,6 +2121,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] ... }; </span>] [<span class="optional"> check-names ( <em class="replaceable"><code>master</code></em> | <em class="replaceable"><code>slave</code></em> | <em class="replaceable"><code>response</code></em> ) ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>] + [<span class="optional"> check-dup-records ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>] [<span class="optional"> check-mx ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>] [<span class="optional"> check-wildcard <em class="replaceable"><code>yes_or_no</code></em>; </span>] [<span class="optional"> check-integrity <em class="replaceable"><code>yes_or_no</code></em>; </span>] @@ -2138,8 +2139,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] [<span class="optional"> allow-update { <em class="replaceable"><code>address_match_list</code></em> }; </span>] [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>] [<span class="optional"> update-check-ksk <em class="replaceable"><code>yes_or_no</code></em>; </span>] - [<span class="optional"> dnskey-ksk-only <em class="replaceable"><code>yes_or_no</code></em>; </span>] - [<span class="optional"> secure-to-insecure <em class="replaceable"><code>yes_or_no</code></em> ;</span>] + [<span class="optional"> dnssec-dnskey-kskonly <em class="replaceable"><code>yes_or_no</code></em>; </span>] + [<span class="optional"> dnssec-secure-to-insecure <em class="replaceable"><code>yes_or_no</code></em> ;</span>] [<span class="optional"> try-tcp-refresh <em class="replaceable"><code>yes_or_no</code></em>; </span>] [<span class="optional"> allow-v6-synthesis { <em class="replaceable"><code>address_match_list</code></em> }; </span>] [<span class="optional"> blackhole { <em class="replaceable"><code>address_match_list</code></em> }; </span>] @@ -3220,6 +3221,10 @@ options { 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>. + The <span><strong class="command">filter-aaaa-on-v4</strong></span> option + may also be specified in <span><strong class="command">view</strong></span> statements + to override the global <span><strong class="command">filter-aaaa-on-v4</strong></span> + option. </p> <p> If <strong class="userinput"><code>yes</code></strong>, @@ -3356,6 +3361,21 @@ options { (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT). </p> </dd> +<dt><span class="term"><span><strong class="command">check-dup-records</strong></span></span></dt> +<dd><p> + Check master zones for records that are treated as different + by DNSSEC but are semantically equal in plain DNS. The + default is to <span><strong class="command">warn</strong></span>. Other possible + values are <span><strong class="command">fail</strong></span> and + <span><strong class="command">ignore</strong></span>. + </p></dd> +<dt><span class="term"><span><strong class="command">check-mx</strong></span></span></dt> +<dd><p> + Check whether the MX record appears to refer to a IP address. + The default is to <span><strong class="command">warn</strong></span>. Other possible + values are <span><strong class="command">fail</strong></span> and + <span><strong class="command">ignore</strong></span>. + </p></dd> <dt><span class="term"><span><strong class="command">check-mx</strong></span></span></dt> <dd><p> Check whether the MX record appears to refer to a IP address. @@ -3444,7 +3464,7 @@ options { for that algorithm. </p> </dd> -<dt><span class="term"><span><strong class="command">dnskey-ksk-only</strong></span></span></dt> +<dt><span class="term"><span><strong class="command">dnssec-dnskey-kskonly</strong></span></span></dt> <dd> <p> When this option and <span><strong class="command">update-check-ksk</strong></span> @@ -3468,7 +3488,7 @@ options { For BIND 8 compatibility, the default is <span><strong class="command">yes</strong></span>. </p></dd> -<dt><span class="term"><span><strong class="command">secure-to-insecure</strong></span></span></dt> +<dt><span class="term"><span><strong class="command">dnssec-secure-to-insecure</strong></span></span></dt> <dd><p> Allow a zone to transition from secure to insecure by deleting all DNSKEY records. The default is @@ -3478,7 +3498,7 @@ options { </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2582605"></a>Forwarding</h4></div></div></div> +<a name="id2582885"></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 @@ -3522,7 +3542,7 @@ options { </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2582732"></a>Dual-stack Servers</h4></div></div></div> +<a name="id2583012"></a>Dual-stack Servers</h4></div></div></div> <p> Dual-stack servers are used as servers of last resort to work around @@ -3719,7 +3739,7 @@ options { </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2583238"></a>Interfaces</h4></div></div></div> +<a name="id2583449"></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 @@ -4171,7 +4191,7 @@ avoid-v6-udp-ports {}; </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2584441"></a>UDP Port Lists</h4></div></div></div> +<a name="id2584652"></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>, @@ -4213,7 +4233,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="id2584501"></a>Operating System Resource Limits</h4></div></div></div> +<a name="id2584780"></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 @@ -4375,7 +4395,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="id2585060"></a>Periodic Task Intervals</h4></div></div></div> +<a name="id2585134"></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> @@ -5171,7 +5191,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="id2587072"></a>Content Filtering</h4></div></div></div> +<a name="id2587214"></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 @@ -5501,7 +5521,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2587892"></a><span><strong class="command">statistics-channels</strong></span> Statement Definition and +<a name="id2588103"></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 @@ -5552,7 +5572,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588046"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div> +<a name="id2588326"></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>] @@ -5561,7 +5581,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588166"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition +<a name="id2588377"></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 @@ -5601,7 +5621,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588213"></a><span><strong class="command">managed-keys</strong></span> Statement Grammar</h3></div></div></div> +<a name="id2588424"></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>] @@ -5610,7 +5630,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588264"></a><span><strong class="command">managed-keys</strong></span> Statement Definition +<a name="id2588475"></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 @@ -5736,7 +5756,7 @@ deny-answer-aliases { "example.net"; }; </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2588568"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div> +<a name="id2588848"></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 @@ -5914,8 +5934,8 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>] [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>] [<span class="optional"> update-check-ksk <em class="replaceable"><code>yes_or_no</code></em>; </span>] - [<span class="optional"> dnskey-ksk-only <em class="replaceable"><code>yes_or_no</code></em>; </span>] - [<span class="optional"> secure-to-insecure <em class="replaceable"><code>yes_or_no</code></em> ; </span>] + [<span class="optional"> dnssec-dnskey-kskonly <em class="replaceable"><code>yes_or_no</code></em>; </span>] + [<span class="optional"> dnssec-secure-to-insecure <em class="replaceable"><code>yes_or_no</code></em> ; </span>] [<span class="optional"> try-tcp-refresh <em class="replaceable"><code>yes_or_no</code></em>; </span>] [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>] @@ -6016,10 +6036,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="id2590278"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div> +<a name="id2590421"></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="id2590285"></a>Zone Types</h4></div></div></div> +<a name="id2590428"></a>Zone Types</h4></div></div></div> <div class="informaltable"><table border="1"> <colgroup> <col> @@ -6230,7 +6250,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="id2590713"></a>Class</h4></div></div></div> +<a name="id2590856"></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>), @@ -6252,7 +6272,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="id2590746"></a>Zone Options</h4></div></div></div> +<a name="id2590889"></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> @@ -6349,10 +6369,10 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" See the description of <span><strong class="command">update-check-ksk</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</a>. </p></dd> -<dt><span class="term"><span><strong class="command">dnskey-ksk-only</strong></span></span></dt> +<dt><span class="term"><span><strong class="command">dnssec-dnskey-kskonly</strong></span></span></dt> <dd><p> See the description of - <span><strong class="command">dnskey-ksk-only</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</a>. + <span><strong class="command">dnssec-dnskey-kskonly</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</a>. </p></dd> <dt><span class="term"><span><strong class="command">try-tcp-refresh</strong></span></span></dt> <dd><p> @@ -6584,7 +6604,8 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" <p> <span><strong class="command">auto-dnssec allow;</strong></span> permits keys to be updated and the zone re-signed whenever the - user issues the command <span><strong class="command">rndc sign</strong></span>. + user issues the command <span><strong class="command">rndc sign + <em class="replaceable"><code>zonename</code></em></strong></span>. </p> <p> <span><strong class="command">auto-dnssec maintain;</strong></span> includes the @@ -6614,10 +6635,10 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional" See the description of <span><strong class="command">masterfile-format</strong></span> in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called “Tuning”</a>. </p></dd> -<dt><span class="term"><span><strong class="command">secure-to-insecure</strong></span></span></dt> +<dt><span class="term"><span><strong class="command">dnssec-secure-to-insecure</strong></span></span></dt> <dd><p> See the description of - <span><strong class="command">secure-to-insecure</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</a>. + <span><strong class="command">dnssec-secure-to-insecure</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</a>. </p></dd> </dl></div> </div> @@ -6922,7 +6943,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="id2593012"></a>Zone File</h2></div></div></div> +<a name="id2593225"></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> @@ -6935,7 +6956,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="id2593030"></a>Resource Records</h4></div></div></div> +<a name="id2593243"></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 @@ -7672,7 +7693,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="id2594653"></a>Textual expression of RRs</h4></div></div></div> +<a name="id2594730"></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 @@ -7875,7 +7896,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="id2595242"></a>Discussion of MX Records</h3></div></div></div> +<a name="id2595387"></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 @@ -8131,7 +8152,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="id2595858"></a>Inverse Mapping in IPv4</h3></div></div></div> +<a name="id2596003"></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 @@ -8192,7 +8213,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="id2596053"></a>Other Zone File Directives</h3></div></div></div> +<a name="id2596130"></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 @@ -8207,7 +8228,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="id2596075"></a>The <span><strong class="command">@</strong></span> (at-sign)</h4></div></div></div> +<a name="id2596152"></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. @@ -8218,7 +8239,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="id2596091"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div> +<a name="id2596168"></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> @@ -8247,7 +8268,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="id2596220"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div> +<a name="id2596229"></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> @@ -8283,7 +8304,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="id2596290"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div> +<a name="id2596298"></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> @@ -8302,7 +8323,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="id2596326"></a><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div> +<a name="id2596403"></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> @@ -8726,7 +8747,7 @@ HOST-127.EXAMPLE. MX 0 . </p> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2597348"></a>Name Server Statistics Counters</h4></div></div></div> +<a name="id2597356"></a>Name Server Statistics Counters</h4></div></div></div> <div class="informaltable"><table border="1"> <colgroup> <col> @@ -9283,7 +9304,7 @@ HOST-127.EXAMPLE. MX 0 . </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2598821"></a>Zone Maintenance Statistics Counters</h4></div></div></div> +<a name="id2598898"></a>Zone Maintenance Statistics Counters</h4></div></div></div> <div class="informaltable"><table border="1"> <colgroup> <col> @@ -9437,7 +9458,7 @@ HOST-127.EXAMPLE. MX 0 . </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2599272"></a>Resolver Statistics Counters</h4></div></div></div> +<a name="id2599417"></a>Resolver Statistics Counters</h4></div></div></div> <div class="informaltable"><table border="1"> <colgroup> <col> @@ -9820,7 +9841,7 @@ HOST-127.EXAMPLE. MX 0 . </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2600362"></a>Socket I/O Statistics Counters</h4></div></div></div> +<a name="id2600439"></a>Socket I/O Statistics Counters</h4></div></div></div> <p> Socket I/O statistics counters are defined per socket types, which are @@ -9975,7 +9996,7 @@ HOST-127.EXAMPLE. MX 0 . </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="id2600736"></a>Compatibility with <span class="emphasis"><em>BIND</em></span> 8 Counters</h4></div></div></div> +<a name="id2600881"></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 bd89bede..a6e0e47a 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.216 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch07.html,v 1.220 2009/12/04 22:22:27 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#id2600978"><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#id2601054"><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#id2601059">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2601118">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2601136">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2601195">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="id2600978"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span> +<a name="id2601054"></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="id2601059"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div> +<a name="id2601136"></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="id2601118"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div> +<a name="id2601195"></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 546b7f3b..551256cd 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.216 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch08.html,v 1.220 2009/12/04 22:22:27 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#id2601198">Common Problems</a></span></dt> -<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2601204">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#id2601216">Incrementing and Changing the Serial Number</a></span></dt> -<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601301">Where Can I Get Help?</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601275">Common Problems</a></span></dt> +<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2601281">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#id2601292">Incrementing and Changing the Serial Number</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601378">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="id2601198"></a>Common Problems</h2></div></div></div> +<a name="id2601275"></a>Common Problems</h2></div></div></div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="id2601204"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div> +<a name="id2601281"></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="id2601216"></a>Incrementing and Changing the Serial Number</h2></div></div></div> +<a name="id2601292"></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="id2601301"></a>Where Can I Get Help?</h2></div></div></div> +<a name="id2601378"></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 fe3f8a99..820fe28b 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.218 2009/11/11 01:14:41 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch09.html,v 1.222 2009/12/04 22:22:25 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#id2601363">Acknowledgments</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601576">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#id2601739">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601816">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#id2604951">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2605028">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="id2601363"></a>Acknowledgments</h2></div></div></div> +<a name="id2601576"></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="id2601739"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div> +<a name="id2601816"></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="id2601927"></a>Bibliography</h4></div></div></div> +<a name="id2602004"></a>Bibliography</h4></div></div></div> <div class="bibliodiv"> <h3 class="title">Standards</h3> <div class="biblioentry"> -<a name="id2601938"></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="id2602014"></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="id2601961"></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="id2602038"></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="id2601985"></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="id2602061"></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="id2602021"></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="id2602098"></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="id2602048"></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="id2602124"></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="id2602073"></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="id2602150"></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="id2602098"></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="id2602174"></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="id2602121"></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="id2602198"></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="id2602177"></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="id2602253"></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="id2602203"></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="id2602280"></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="id2602230"></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="id2602307"></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="id2602292"></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="id2602369"></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="id2602322"></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="id2602398"></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="id2602352"></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="id2602428"></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="id2602378"></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="id2602455"></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="id2602460"></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="id2602537"></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="id2602487"></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="id2602564"></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="id2602523"></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="id2602600"></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="id2602588"></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="id2602665"></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="id2602653"></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="id2602730"></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="id2602727"></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="id2602804"></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="id2602753"></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="id2602829"></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="id2602821"></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="id2602898"></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="id2602856"></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="id2602933"></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="id2602902"></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="id2602979"></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="id2602960"></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="id2603036"></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="id2602997"></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="id2603074"></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="id2603032"></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="id2603109"></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="id2603086"></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="id2603232"></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="id2603125"></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="id2603270"></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="id2603150"></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="id2603296"></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="id2603176"></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="id2603321"></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="id2603203"></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="id2603348"></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="id2603229"></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="id2603374"></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="id2603269"></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="id2603414"></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="id2603299"></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="id2603444"></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="id2603329"></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="id2603474"></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="id2603371"></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="id2603516"></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="id2603404"></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="id2603549"></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="id2603431"></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="id2603576"></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="id2603454"></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="id2603600"></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="id2603512"></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="id2603657"></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="id2603544"></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="id2603689"></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="id2603570"></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="id2603715"></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="id2603592"></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="id2603737"></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="id2603616"></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="id2603761"></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="id2603661"></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="id2603806"></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="id2603685"></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="id2603830"></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="id2603742"></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="id2603888"></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="id2603834"></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="id2603911"></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="id2603861"></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="id2603938"></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="id2603888"></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="id2603964"></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="id2603924"></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="id2604001"></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="id2603970"></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="id2604046"></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="id2604002"></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="id2604078"></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="id2604048"></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="id2604193"></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="id2604083"></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="id2604228"></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="id2604196"></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="id2604273"></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="id2604218"></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="id2604295"></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="id2604244"></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="id2604321"></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="id2604269"></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="id2604346"></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="id2604293"></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="id2604370"></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="id2604339"></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="id2604416"></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="id2604362"></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="id2604439"></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="id2604389"></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="id2604466"></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="id2604414"></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="id2604491"></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="id2604458"></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="id2604535"></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="id2604516"></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="id2604593"></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="id2604542"></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="id2604619"></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="id2604590"></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="id2604667"></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="id2604630"></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="id2604707"></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="id2604657"></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="id2604733"></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="id2604686"></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="id2604763"></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="id2604712"></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="id2604789"></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="id2604739"></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="id2604816"></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="id2604775"></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="id2604852"></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="id2604811"></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="id2604888"></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="id2604838"></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="id2604915"></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="id2604865"></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="id2604941"></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="id2604909"></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="id2604986"></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="id2604951"></a>Other Documents About <acronym class="acronym">BIND</acronym> +<a name="id2605028"></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="id2604961"></a>Bibliography</h4></div></div></div> +<a name="id2605037"></a>Bibliography</h4></div></div></div> <div class="biblioentry"> -<a name="id2604963"></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="id2605040"></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.ch10.html b/doc/arm/Bv9ARM.ch10.html index 246b30fd..5814e135 100644 --- a/doc/arm/Bv9ARM.ch10.html +++ b/doc/arm/Bv9ARM.ch10.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.ch10.html,v 1.17 2009/07/19 04:27:56 tbox Exp $ --> +<!-- $Id: Bv9ARM.ch10.html,v 1.18 2009/12/04 22:22:27 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -82,6 +82,9 @@ <span class="refentrytitle"><a href="man.named.html"><span class="application">named</span></a></span><span class="refpurpose"> — Internet domain name server</span> </dt> <dt> +<span class="refentrytitle"><a href="man.named-journalprint.html"><span class="application">named-journalprint</span></a></span><span class="refpurpose"> — print zone journal in human-readable form</span> +</dt> +<dt> <span class="refentrytitle"><a href="man.nsupdate.html"><span class="application">nsupdate</span></a></span><span class="refpurpose"> — Dynamic DNS update utility</span> </dt> <dt> @@ -96,6 +99,15 @@ <dt> <span class="refentrytitle"><a href="man.ddns-confgen.html"><span class="application">ddns-confgen</span></a></span><span class="refpurpose"> — ddns key generation tool</span> </dt> +<dt> +<span class="refentrytitle"><a href="man.arpaname.html"><span class="application">arpaname</span></a></span><span class="refpurpose"> — translate IP addresses to the corresponding ARPA names</span> +</dt> +<dt> +<span class="refentrytitle"><a href="man.genrandom.html"><span class="application">genrandom</span></a></span><span class="refpurpose"> — generate a file containing random data</span> +</dt> +<dt> +<span class="refentrytitle"><a href="man.nsec3hash.html"><span class="application">nsec3hash</span></a></span><span class="refpurpose"> — generate NSEC3 hash</span> +</dt> </dl> </div> </div> diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html index dedc24c5..5743844a 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.235 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: Bv9ARM.html,v 1.239 2009/12/04 22:22:26 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#id2587892"><span><strong class="command">statistics-channels</strong></span> Statement Definition and +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588103"><span><strong class="command">statistics-channels</strong></span> Statement Definition and Usage</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588046"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588166"><span><strong class="command">trusted-keys</strong></span> Statement Definition +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588326"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588377"><span><strong class="command">trusted-keys</strong></span> Statement Definition and Usage</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588213"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588264"><span><strong class="command">managed-keys</strong></span> Statement Definition +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588424"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588475"><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#id2588568"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588848"><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#id2590278"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590421"><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#id2593012">Zone File</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2593225">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#id2595242">Discussion of MX Records</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2595387">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#id2595858">Inverse Mapping in IPv4</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596053">Other Zone File Directives</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596326"><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#id2596003">Inverse Mapping in IPv4</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596130">Other Zone File Directives</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2596403"><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#id2600978"><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#id2601054"><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#id2601059">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2601118">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2601136">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2601195">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#id2601198">Common Problems</a></span></dt> -<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2601204">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#id2601216">Incrementing and Changing the Serial Number</a></span></dt> -<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601301">Where Can I Get Help?</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601275">Common Problems</a></span></dt> +<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2601281">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#id2601292">Incrementing and Changing the Serial Number</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2601378">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#id2601363">Acknowledgments</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601576">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#id2601739">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2601816">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#id2604951">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2605028">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> @@ -250,6 +250,9 @@ <span class="refentrytitle"><a href="man.named.html"><span class="application">named</span></a></span><span class="refpurpose"> — Internet domain name server</span> </dt> <dt> +<span class="refentrytitle"><a href="man.named-journalprint.html"><span class="application">named-journalprint</span></a></span><span class="refpurpose"> — print zone journal in human-readable form</span> +</dt> +<dt> <span class="refentrytitle"><a href="man.nsupdate.html"><span class="application">nsupdate</span></a></span><span class="refpurpose"> — Dynamic DNS update utility</span> </dt> <dt> @@ -264,6 +267,15 @@ <dt> <span class="refentrytitle"><a href="man.ddns-confgen.html"><span class="application">ddns-confgen</span></a></span><span class="refpurpose"> — ddns key generation tool</span> </dt> +<dt> +<span class="refentrytitle"><a href="man.arpaname.html"><span class="application">arpaname</span></a></span><span class="refpurpose"> — translate IP addresses to the corresponding ARPA names</span> +</dt> +<dt> +<span class="refentrytitle"><a href="man.genrandom.html"><span class="application">genrandom</span></a></span><span class="refpurpose"> — generate a file containing random data</span> +</dt> +<dt> +<span class="refentrytitle"><a href="man.nsec3hash.html"><span class="application">nsec3hash</span></a></span><span class="refpurpose"> — generate NSEC3 hash</span> +</dt> </dl></dd> </dl> </div> diff --git a/doc/arm/man.arpaname.html b/doc/arm/man.arpaname.html new file mode 100644 index 00000000..670b6a71 --- /dev/null +++ b/doc/arm/man.arpaname.html @@ -0,0 +1,91 @@ +<!-- + - Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") + - + - Permission to use, copy, modify, and/or distribute this software for any + - purpose with or without fee is hereby granted, provided that the above + - copyright notice and this permission notice appear in all copies. + - + - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + - PERFORMANCE OF THIS SOFTWARE. +--> + +<!-- $Id: man.arpaname.html,v 1.2 2009/12/04 22:32:31 tbox Exp $ --> +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> +<title>arpaname</title> +<meta name="generator" content="DocBook XSL Stylesheets V1.71.1"> +<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> +<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages"> +<link rel="prev" href="man.ddns-confgen.html" title="ddns-confgen"> +<link rel="next" href="man.genrandom.html" title="genrandom"> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> +<div class="navheader"> +<table width="100%" summary="Navigation header"> +<tr><th colspan="3" align="center"><span class="application">arpaname</span></th></tr> +<tr> +<td width="20%" align="left"> +<a accesskey="p" href="man.ddns-confgen.html">Prev</a> </td> +<th width="60%" align="center">Manual pages</th> +<td width="20%" align="right"> <a accesskey="n" href="man.genrandom.html">Next</a> +</td> +</tr> +</table> +<hr> +</div> +<div class="refentry" lang="en"> +<a name="man.arpaname"></a><div class="titlepage"></div> +<div class="refnamediv"> +<h2>Name</h2> +<p><span class="application">arpaname</span> — translate IP addresses to the corresponding ARPA names</p> +</div> +<div class="refsynopsisdiv"> +<h2>Synopsis</h2> +<div class="cmdsynopsis"><p><code class="command">arpaname</code> {<em class="replaceable"><code>ipaddress </code></em>...}</p></div> +</div> +<div class="refsect1" lang="en"> +<a name="id2610966"></a><h2>DESCRIPTION</h2> +<p> + <span><strong class="command">arpaname</strong></span> translates IP addresses (IPv4 and + IPv6) to the corresponding IN-ADDR.ARPA or IP6.ARPA names. + </p> +</div> +<div class="refsect1" lang="en"> +<a name="id2610981"></a><h2>SEE ALSO</h2> +<p> + <em class="citetitle">BIND 9 Administrator Reference Manual</em>. + </p> +</div> +<div class="refsect1" lang="en"> +<a name="id2647449"></a><h2>AUTHOR</h2> +<p><span class="corpauthor">Internet Systems Consortium</span> + </p> +</div> +</div> +<div class="navfooter"> +<hr> +<table width="100%" summary="Navigation footer"> +<tr> +<td width="40%" align="left"> +<a accesskey="p" href="man.ddns-confgen.html">Prev</a> </td> +<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td> +<td width="40%" align="right"> <a accesskey="n" href="man.genrandom.html">Next</a> +</td> +</tr> +<tr> +<td width="40%" align="left" valign="top"> +<span class="application">ddns-confgen</span> </td> +<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> +<td width="40%" align="right" valign="top"> <span class="application">genrandom</span> +</td> +</tr> +</table> +</div> +</body> +</html> diff --git a/doc/arm/man.ddns-confgen.html b/doc/arm/man.ddns-confgen.html index 7091a1d1..37194b76 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.36 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.ddns-confgen.html,v 1.40 2009/12/04 22:22:26 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -23,6 +23,7 @@ <link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> <link rel="up" href="Bv9ARM.ch10.html" title="Manual pages"> <link rel="prev" href="man.rndc-confgen.html" title="rndc-confgen"> +<link rel="next" href="man.arpaname.html" title="arpaname"> </head> <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> <div class="navheader"> @@ -32,7 +33,8 @@ <td width="20%" align="left"> <a accesskey="p" href="man.rndc-confgen.html">Prev</a> </td> <th width="60%" align="center">Manual pages</th> -<td width="20%" align="right"> </td> +<td width="20%" align="right"> <a accesskey="n" href="man.arpaname.html">Next</a> +</td> </tr> </table> <hr> @@ -48,7 +50,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="id2638776"></a><h2>DESCRIPTION</h2> +<a name="id2639866"></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 +77,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2638864"></a><h2>OPTIONS</h2> +<a name="id2640022"></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 +144,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2639269"></a><h2>SEE ALSO</h2> +<a name="id2643772"></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 +152,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2639307"></a><h2>AUTHOR</h2> +<a name="id2643811"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> @@ -162,13 +164,15 @@ <td width="40%" align="left"> <a accesskey="p" href="man.rndc-confgen.html">Prev</a> </td> <td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td> -<td width="40%" align="right"> </td> +<td width="40%" align="right"> <a accesskey="n" href="man.arpaname.html">Next</a> +</td> </tr> <tr> <td width="40%" align="left" valign="top"> <span class="application">rndc-confgen</span> </td> <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> -<td width="40%" align="right" valign="top"> </td> +<td width="40%" align="right" valign="top"> <span class="application">arpaname</span> +</td> </tr> </table> </div> diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html index f4abfd72..0e3e38aa 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.135 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.dig.html,v 1.138 2009/12/04 22:22:26 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="id2563929"></a><h2>DESCRIPTION</h2> +<a name="id2580077"></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="id2584845"></a><h2>SIMPLE USAGE</h2> +<a name="id2580172"></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="id2584956"></a><h2>OPTIONS</h2> +<a name="id2631961"></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="id2632130"></a><h2>QUERY OPTIONS</h2> +<a name="id2632304"></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="id2633130"></a><h2>MULTIPLE QUERIES</h2> +<a name="id2633372"></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="id2633216"></a><h2>IDN SUPPORT</h2> +<a name="id2633458"></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="id2633244"></a><h2>FILES</h2> +<a name="id2633486"></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="id2633266"></a><h2>SEE ALSO</h2> +<a name="id2633508"></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="id2633303"></a><h2>BUGS</h2> +<a name="id2633545"></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 a788ee19..2c46a4d3 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.47 2009/11/11 01:14:41 tbox Exp $ --> +<!-- $Id: man.dnssec-dsfromkey.html,v 1.50 2009/12/04 22:22:25 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="id2606049"></a><h2>DESCRIPTION</h2> +<a name="id2606086"></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="id2606062"></a><h2>OPTIONS</h2> +<a name="id2606100"></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="id2606251"></a><h2>EXAMPLE</h2> +<a name="id2606357"></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="id2606288"></a><h2>FILES</h2> +<a name="id2606393"></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="id2606329"></a><h2>CAVEAT</h2> +<a name="id2606571"></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="id2606339"></a><h2>SEE ALSO</h2> +<a name="id2606581"></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="id2606651"></a><h2>AUTHOR</h2> +<a name="id2606620"></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 2a2c26bd..a587f68f 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.79 2009/11/11 01:14:41 tbox Exp $ --> +<!-- $Id: man.dnssec-keyfromlabel.html,v 1.83 2009/12/04 22:22:25 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="id2606851"></a><h2>DESCRIPTION</h2> +<a name="id2607025"></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,7 +63,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2606871"></a><h2>OPTIONS</h2> +<a name="id2607250"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt> <dd> @@ -174,7 +174,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2607977"></a><h2>TIMING OPTIONS</h2> +<a name="id2610336"></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 @@ -221,7 +221,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2610260"></a><h2>GENERATED KEY FILES</h2> +<a name="id2610434"></a><h2>GENERATED KEY FILES</h2> <p> When <span><strong class="command">dnssec-keyfromlabel</strong></span> completes successfully, @@ -260,7 +260,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2650904"></a><h2>SEE ALSO</h2> +<a name="id2651283"></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>, @@ -268,7 +268,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2650937"></a><h2>AUTHOR</h2> +<a name="id2651316"></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 a4cf2c8e..bb5f0372 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.148 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.dnssec-keygen.html,v 1.152 2009/12/04 22:22:26 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-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="id2608539"></a><h2>DESCRIPTION</h2> +<a name="id2608508"></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,7 +64,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2608560"></a><h2>OPTIONS</h2> +<a name="id2608529"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt> <dd> @@ -256,7 +256,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2655889"></a><h2>TIMING OPTIONS</h2> +<a name="id2660568"></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 @@ -303,7 +303,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2656123"></a><h2>GENERATED KEYS</h2> +<a name="id2660734"></a><h2>GENERATED KEYS</h2> <p> When <span><strong class="command">dnssec-keygen</strong></span> completes successfully, @@ -349,7 +349,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2656231"></a><h2>EXAMPLE</h2> +<a name="id2660979"></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 @@ -370,7 +370,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2656288"></a><h2>SEE ALSO</h2> +<a name="id2661035"></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>, @@ -379,7 +379,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2656318"></a><h2>AUTHOR</h2> +<a name="id2661066"></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 cbb59291..b17f7a39 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.31 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.dnssec-revoke.html,v 1.35 2009/12/04 22:22:26 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="id2609654"></a><h2>DESCRIPTION</h2> +<a name="id2607165"></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="id2609668"></a><h2>OPTIONS</h2> +<a name="id2609500"></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="id2609776"></a><h2>SEE ALSO</h2> +<a name="id2609608"></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="id2609800"></a><h2>AUTHOR</h2> +<a name="id2609633"></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 53e7c303..5608d208 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.26 2009/11/11 01:14:41 tbox Exp $ --> +<!-- $Id: man.dnssec-settime.html,v 1.30 2009/12/04 22:22:25 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="id2610501"></a><h2>DESCRIPTION</h2> +<a name="id2609787"></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="id2610560"></a><h2>OPTIONS</h2> +<a name="id2609846"></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="id2610858"></a><h2>TIMING OPTIONS</h2> +<a name="id2610554"></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 @@ -151,7 +151,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2610956"></a><h2>PRINTING OPTIONS</h2> +<a name="id2610652"></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="id2611036"></a><h2>SEE ALSO</h2> +<a name="id2611552"></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="id2611069"></a><h2>AUTHOR</h2> +<a name="id2611585"></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 d9012f4b..604b7e1e 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.148 2009/11/11 01:14:41 tbox Exp $ --> +<!-- $Id: man.dnssec-signzone.html,v 1.152 2009/12/04 22:22:25 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="id2612045"></a><h2>DESCRIPTION</h2> +<a name="id2612219"></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="id2612065"></a><h2>OPTIONS</h2> +<a name="id2612238"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-a</span></dt> <dd><p> @@ -346,7 +346,7 @@ <dd><p> Only sign the DNSKEY RRset with key-signing keys, and omit signatures from zone-signing keys. (This is similar to the - <span><strong class="command">dnskey-ksk-only yes;</strong></span> zone option in + <span><strong class="command">dnssec-dnskey-kskonly yes;</strong></span> zone option in <span><strong class="command">named</strong></span>.) </p></dd> <dt><span class="term">-z</span></dt> @@ -397,7 +397,7 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2661197"></a><h2>EXAMPLE</h2> +<a name="id2661917"></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="id2661276"></a><h2>SEE ALSO</h2> +<a name="id2662133"></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="id2661301"></a><h2>AUTHOR</h2> +<a name="id2662157"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.genrandom.html b/doc/arm/man.genrandom.html new file mode 100644 index 00000000..8741c8f5 --- /dev/null +++ b/doc/arm/man.genrandom.html @@ -0,0 +1,107 @@ +<!-- + - Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") + - + - Permission to use, copy, modify, and/or distribute this software for any + - purpose with or without fee is hereby granted, provided that the above + - copyright notice and this permission notice appear in all copies. + - + - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + - PERFORMANCE OF THIS SOFTWARE. +--> + +<!-- $Id: man.genrandom.html,v 1.2 2009/12/04 22:32:31 tbox Exp $ --> +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> +<title>genrandom</title> +<meta name="generator" content="DocBook XSL Stylesheets V1.71.1"> +<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> +<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages"> +<link rel="prev" href="man.arpaname.html" title="arpaname"> +<link rel="next" href="man.nsec3hash.html" title="nsec3hash"> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> +<div class="navheader"> +<table width="100%" summary="Navigation header"> +<tr><th colspan="3" align="center"><span class="application">genrandom</span></th></tr> +<tr> +<td width="20%" align="left"> +<a accesskey="p" href="man.arpaname.html">Prev</a> </td> +<th width="60%" align="center">Manual pages</th> +<td width="20%" align="right"> <a accesskey="n" href="man.nsec3hash.html">Next</a> +</td> +</tr> +</table> +<hr> +</div> +<div class="refentry" lang="en"> +<a name="man.genrandom"></a><div class="titlepage"></div> +<div class="refnamediv"> +<h2>Name</h2> +<p><span class="application">genrandom</span> — generate a file containing random data</p> +</div> +<div class="refsynopsisdiv"> +<h2>Synopsis</h2> +<div class="cmdsynopsis"><p><code class="command">genrandom</code> {<em class="replaceable"><code>size</code></em>} {<em class="replaceable"><code>filename</code></em>}</p></div> +</div> +<div class="refsect1" lang="en"> +<a name="id2611162"></a><h2>DESCRIPTION</h2> +<p> + <span><strong class="command">genrandom</strong></span> + generates a file containing a specified quantity of pseudo-random + data, which can be used as a source of entropy for other commands + on systems with no random device. + </p> +</div> +<div class="refsect1" lang="en"> +<a name="id2611177"></a><h2>ARGUMENTS</h2> +<div class="variablelist"><dl> +<dt><span class="term">size</span></dt> +<dd><p> + The size of the file, in kilobytes, to generate. + </p></dd> +<dt><span class="term">domain</span></dt> +<dd><p> + The file name into which random data should be written. + </p></dd> +</dl></div> +</div> +<div class="refsect1" lang="en"> +<a name="id2647530"></a><h2>SEE ALSO</h2> +<p> + <span class="citerefentry"><span class="refentrytitle">rand</span>(3)</span>, + <span class="citerefentry"><span class="refentrytitle">arc4random</span>(3)</span> + </p> +</div> +<div class="refsect1" lang="en"> +<a name="id2647557"></a><h2>AUTHOR</h2> +<p><span class="corpauthor">Internet Systems Consortium</span> + </p> +</div> +</div> +<div class="navfooter"> +<hr> +<table width="100%" summary="Navigation footer"> +<tr> +<td width="40%" align="left"> +<a accesskey="p" href="man.arpaname.html">Prev</a> </td> +<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td> +<td width="40%" align="right"> <a accesskey="n" href="man.nsec3hash.html">Next</a> +</td> +</tr> +<tr> +<td width="40%" align="left" valign="top"> +<span class="application">arpaname</span> </td> +<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> +<td width="40%" align="right" valign="top"> <span class="application">nsec3hash</span> +</td> +</tr> +</table> +</div> +</body> +</html> diff --git a/doc/arm/man.host.html b/doc/arm/man.host.html index d75023bd..fb3adb43 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.132 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.host.html,v 1.136 2009/12/04 22:22:26 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="id2605299"></a><h2>DESCRIPTION</h2> +<a name="id2605336"></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="id2605745"></a><h2>IDN SUPPORT</h2> +<a name="id2605782"></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="id2605773"></a><h2>FILES</h2> +<a name="id2605879"></a><h2>FILES</h2> <p><code class="filename">/etc/resolv.conf</code> </p> </div> <div class="refsect1" lang="en"> -<a name="id2605787"></a><h2>SEE ALSO</h2> +<a name="id2605893"></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 0dff65f0..b47370e2 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.142 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.named-checkconf.html,v 1.146 2009/12/04 22:22:26 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="id2612308"></a><h2>DESCRIPTION</h2> +<a name="id2612686"></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="id2612322"></a><h2>OPTIONS</h2> +<a name="id2612700"></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="id2612456"></a><h2>RETURN VALUES</h2> +<a name="id2612835"></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="id2612470"></a><h2>SEE ALSO</h2> +<a name="id2612849"></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="id2612500"></a><h2>AUTHOR</h2> +<a name="id2612878"></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 e60a9418..878d20e8 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.150 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.named-checkzone.html,v 1.154 2009/12/04 22:22:26 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -47,11 +47,11 @@ </div> <div class="refsynopsisdiv"> <h2>Synopsis</h2> -<div class="cmdsynopsis"><p><code class="command">named-checkzone</code> [<code class="option">-d</code>] [<code class="option">-h</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">-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">-M <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-S <em class="replaceable"><code>mode</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 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>] {<code class="option">-o <em class="replaceable"><code>filename</code></em></code>} {zonename} {filename}</p></div> +<div class="cmdsynopsis"><p><code class="command">named-checkzone</code> [<code class="option">-d</code>] [<code class="option">-h</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">-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">-M <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-r <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-S <em class="replaceable"><code>mode</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 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">-r <em class="replaceable"><code>mode</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>] {<code class="option">-o <em class="replaceable"><code>filename</code></em></code>} {zonename} {filename}</p></div> </div> <div class="refsect1" lang="en"> -<a name="id2613080"></a><h2>DESCRIPTION</h2> +<a name="id2613543"></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="id2613130"></a><h2>OPTIONS</h2> +<a name="id2662199"></a><h2>OPTIONS</h2> <div class="variablelist"><dl> <dt><span class="term">-d</span></dt> <dd><p> @@ -195,6 +195,14 @@ write to standard out. This is mandatory for <span><strong class="command">named-compilezone</strong></span>. </p></dd> +<dt><span class="term">-r <em class="replaceable"><code>mode</code></em></span></dt> +<dd><p> + Check for records that are treated as different by DNSSEC but + are semantically equal in plain DNS. + Possible modes are <span><strong class="command">"fail"</strong></span>, + <span><strong class="command">"warn"</strong></span> (default) and + <span><strong class="command">"ignore"</strong></span>. + </p></dd> <dt><span class="term">-s <em class="replaceable"><code>style</code></em></span></dt> <dd><p> Specify the style of the dumped zone file. @@ -257,14 +265,14 @@ </dl></div> </div> <div class="refsect1" lang="en"> -<a name="id2662065"></a><h2>RETURN VALUES</h2> +<a name="id2662970"></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="id2662078"></a><h2>SEE ALSO</h2> +<a name="id2662984"></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 +280,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2662112"></a><h2>AUTHOR</h2> +<a name="id2663017"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/arm/man.named-journalprint.html b/doc/arm/man.named-journalprint.html new file mode 100644 index 00000000..f5a3f604 --- /dev/null +++ b/doc/arm/man.named-journalprint.html @@ -0,0 +1,112 @@ +<!-- + - Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") + - + - Permission to use, copy, modify, and/or distribute this software for any + - purpose with or without fee is hereby granted, provided that the above + - copyright notice and this permission notice appear in all copies. + - + - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + - PERFORMANCE OF THIS SOFTWARE. +--> + +<!-- $Id: man.named-journalprint.html,v 1.2 2009/12/04 22:32:31 tbox Exp $ --> +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> +<title>named-journalprint</title> +<meta name="generator" content="DocBook XSL Stylesheets V1.71.1"> +<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> +<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages"> +<link rel="prev" href="man.named.html" title="named"> +<link rel="next" href="man.nsupdate.html" title="nsupdate"> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> +<div class="navheader"> +<table width="100%" summary="Navigation header"> +<tr><th colspan="3" align="center"><span class="application">named-journalprint</span></th></tr> +<tr> +<td width="20%" align="left"> +<a accesskey="p" href="man.named.html">Prev</a> </td> +<th width="60%" align="center">Manual pages</th> +<td width="20%" align="right"> <a accesskey="n" href="man.nsupdate.html">Next</a> +</td> +</tr> +</table> +<hr> +</div> +<div class="refentry" lang="en"> +<a name="man.named-journalprint"></a><div class="titlepage"></div> +<div class="refnamediv"> +<h2>Name</h2> +<p><span class="application">named-journalprint</span> — print zone journal in human-readable form</p> +</div> +<div class="refsynopsisdiv"> +<h2>Synopsis</h2> +<div class="cmdsynopsis"><p><code class="command">named-journalprint</code> {<em class="replaceable"><code>journal</code></em>}</p></div> +</div> +<div class="refsect1" lang="en"> +<a name="id2608829"></a><h2>DESCRIPTION</h2> +<p> + <span><strong class="command">named-journalprint</strong></span> + prints the contents of a zone journal file in a human-readable + form. + </p> +<p> + Journal files are automatically created by <span><strong class="command">named</strong></span> + when changes are made to dynamic zones (e.g., by + <span><strong class="command">nsupdate</strong></span>). They record each addition + or deletion of a resource record, in binary format, allowing the + changes to be re-applied to the zone when the server is + restarted after a shutdown or crash. By default, the name of + the journal file is formed by appending the extension + <code class="filename">.jnl</code> to the name of the corresponding + zone file. + </p> +<p> + <span><strong class="command">named-journalprint</strong></span> converts the contents of a given + journal file into a human-readable text format. Each line begins + with "add" or "del", to indicate whether the record was added or + deleted, and continues with the resource record in master-file + format. + </p> +</div> +<div class="refsect1" lang="en"> +<a name="id2608875"></a><h2>SEE ALSO</h2> +<p> + <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>, + <span class="citerefentry"><span class="refentrytitle">nsupdate</span>(8)</span>, + <em class="citetitle">BIND 9 Administrator Reference Manual</em>. + </p> +</div> +<div class="refsect1" lang="en"> +<a name="id2615869"></a><h2>AUTHOR</h2> +<p><span class="corpauthor">Internet Systems Consortium</span> + </p> +</div> +</div> +<div class="navfooter"> +<hr> +<table width="100%" summary="Navigation footer"> +<tr> +<td width="40%" align="left"> +<a accesskey="p" href="man.named.html">Prev</a> </td> +<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td> +<td width="40%" align="right"> <a accesskey="n" href="man.nsupdate.html">Next</a> +</td> +</tr> +<tr> +<td width="40%" align="left" valign="top"> +<span class="application">named</span> </td> +<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> +<td width="40%" align="right" valign="top"> <span class="application">nsupdate</span> +</td> +</tr> +</table> +</div> +</body> +</html> diff --git a/doc/arm/man.named.html b/doc/arm/man.named.html index 4fdad63b..1f9cfed0 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.152 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.named.html,v 1.156 2009/12/04 22:22:26 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -23,7 +23,7 @@ <link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> <link rel="up" href="Bv9ARM.ch10.html" title="Manual pages"> <link rel="prev" href="man.named-checkzone.html" title="named-checkzone"> -<link rel="next" href="man.nsupdate.html" title="nsupdate"> +<link rel="next" href="man.named-journalprint.html" title="named-journalprint"> </head> <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> <div class="navheader"> @@ -33,7 +33,7 @@ <td width="20%" align="left"> <a accesskey="p" href="man.named-checkzone.html">Prev</a> </td> <th width="60%" align="center">Manual pages</th> -<td width="20%" align="right"> <a accesskey="n" href="man.nsupdate.html">Next</a> +<td width="20%" align="right"> <a accesskey="n" href="man.named-journalprint.html">Next</a> </td> </tr> </table> @@ -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="id2613954"></a><h2>DESCRIPTION</h2> +<a name="id2614459"></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="id2613985"></a><h2>OPTIONS</h2> +<a name="id2614490"></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="id2629625"></a><h2>SIGNALS</h2> +<a name="id2635114"></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="id2629675"></a><h2>CONFIGURATION</h2> +<a name="id2668137"></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="id2629724"></a><h2>FILES</h2> +<a name="id2668186"></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="id2664925"></a><h2>SEE ALSO</h2> +<a name="id2668230"></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="id2664996"></a><h2>AUTHOR</h2> +<a name="id2668300"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> @@ -322,14 +322,14 @@ <td width="40%" align="left"> <a accesskey="p" href="man.named-checkzone.html">Prev</a> </td> <td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td> -<td width="40%" align="right"> <a accesskey="n" href="man.nsupdate.html">Next</a> +<td width="40%" align="right"> <a accesskey="n" href="man.named-journalprint.html">Next</a> </td> </tr> <tr> <td width="40%" align="left" valign="top"> <span class="application">named-checkzone</span> </td> <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> -<td width="40%" align="right" valign="top"> <span class="application">nsupdate</span> +<td width="40%" align="right" valign="top"> <span class="application">named-journalprint</span> </td> </tr> </table> diff --git a/doc/arm/man.nsec3hash.html b/doc/arm/man.nsec3hash.html new file mode 100644 index 00000000..6802d52c --- /dev/null +++ b/doc/arm/man.nsec3hash.html @@ -0,0 +1,113 @@ +<!-- + - Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") + - + - Permission to use, copy, modify, and/or distribute this software for any + - purpose with or without fee is hereby granted, provided that the above + - copyright notice and this permission notice appear in all copies. + - + - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + - PERFORMANCE OF THIS SOFTWARE. +--> + +<!-- $Id: man.nsec3hash.html,v 1.2 2009/12/04 22:32:31 tbox Exp $ --> +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> +<title>nsec3hash</title> +<meta name="generator" content="DocBook XSL Stylesheets V1.71.1"> +<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> +<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages"> +<link rel="prev" href="man.genrandom.html" title="genrandom"> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> +<div class="navheader"> +<table width="100%" summary="Navigation header"> +<tr><th colspan="3" align="center"><span class="application">nsec3hash</span></th></tr> +<tr> +<td width="20%" align="left"> +<a accesskey="p" href="man.genrandom.html">Prev</a> </td> +<th width="60%" align="center">Manual pages</th> +<td width="20%" align="right"> </td> +</tr> +</table> +<hr> +</div> +<div class="refentry" lang="en"> +<a name="man.nsec3hash"></a><div class="titlepage"></div> +<div class="refnamediv"> +<h2>Name</h2> +<p><span class="application">nsec3hash</span> — generate NSEC3 hash</p> +</div> +<div class="refsynopsisdiv"> +<h2>Synopsis</h2> +<div class="cmdsynopsis"><p><code class="command">nsec3hash</code> {<em class="replaceable"><code>salt</code></em>} {<em class="replaceable"><code>algorithm</code></em>} {<em class="replaceable"><code>iterations</code></em>} {<em class="replaceable"><code>domain</code></em>}</p></div> +</div> +<div class="refsect1" lang="en"> +<a name="id2648474"></a><h2>DESCRIPTION</h2> +<p> + <span><strong class="command">nsec3hash</strong></span> generates an NSEC3 hash based on + a set of NSEC3 parameters. This can be used to check the validity + of NSEC3 records in a signed zone. + </p> +</div> +<div class="refsect1" lang="en"> +<a name="id2648489"></a><h2>ARGUMENTS</h2> +<div class="variablelist"><dl> +<dt><span class="term">salt</span></dt> +<dd><p> + The salt provided to the hash algorithm. + </p></dd> +<dt><span class="term">algorithm</span></dt> +<dd><p> + A number indicating the hash algorithm. Currently the + only supported hash algorithm for NSEC3 is SHA-1, which is + indicated by the number 1; consequently "1" is the only + useful value for this argument. + </p></dd> +<dt><span class="term">iterations</span></dt> +<dd><p> + The number of additional times the hash should be performed. + </p></dd> +<dt><span class="term">domain</span></dt> +<dd><p> + The domain name to be hashed. + </p></dd> +</dl></div> +</div> +<div class="refsect1" lang="en"> +<a name="id2648551"></a><h2>SEE ALSO</h2> +<p> + <em class="citetitle">BIND 9 Administrator Reference Manual</em>, + <em class="citetitle">RFC 5155</em>. + </p> +</div> +<div class="refsect1" lang="en"> +<a name="id2648568"></a><h2>AUTHOR</h2> +<p><span class="corpauthor">Internet Systems Consortium</span> + </p> +</div> +</div> +<div class="navfooter"> +<hr> +<table width="100%" summary="Navigation footer"> +<tr> +<td width="40%" align="left"> +<a accesskey="p" href="man.genrandom.html">Prev</a> </td> +<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td> +<td width="40%" align="right"> </td> +</tr> +<tr> +<td width="40%" align="left" valign="top"> +<span class="application">genrandom</span> </td> +<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> +<td width="40%" align="right" valign="top"> </td> +</tr> +</table> +</div> +</body> +</html> diff --git a/doc/arm/man.nsupdate.html b/doc/arm/man.nsupdate.html index 69440bb2..d497796c 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.76 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.nsupdate.html,v 1.80 2009/12/04 22:22:25 tbox Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> @@ -22,7 +22,7 @@ <meta name="generator" content="DocBook XSL Stylesheets V1.71.1"> <link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> <link rel="up" href="Bv9ARM.ch10.html" title="Manual pages"> -<link rel="prev" href="man.named.html" title="named"> +<link rel="prev" href="man.named-journalprint.html" title="named-journalprint"> <link rel="next" href="man.rndc.html" title="rndc"> </head> <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> @@ -31,7 +31,7 @@ <tr><th colspan="3" align="center"><span class="application">nsupdate</span></th></tr> <tr> <td width="20%" align="left"> -<a accesskey="p" href="man.named.html">Prev</a> </td> +<a accesskey="p" href="man.named-journalprint.html">Prev</a> </td> <th width="60%" align="center">Manual pages</th> <td width="20%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a> </td> @@ -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="id2614781"></a><h2>DESCRIPTION</h2> +<a name="id2616486"></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="id2635186"></a><h2>INPUT FORMAT</h2> +<a name="id2629654"></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="id2666119"></a><h2>EXAMPLES</h2> +<a name="id2672807"></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="id2666169"></a><h2>FILES</h2> +<a name="id2672857"></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="id2666252"></a><h2>SEE ALSO</h2> +<a name="id2673009"></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="id2666310"></a><h2>BUGS</h2> +<a name="id2673066"></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 @@ -580,14 +580,14 @@ <table width="100%" summary="Navigation footer"> <tr> <td width="40%" align="left"> -<a accesskey="p" href="man.named.html">Prev</a> </td> +<a accesskey="p" href="man.named-journalprint.html">Prev</a> </td> <td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td> <td width="40%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a> </td> </tr> <tr> <td width="40%" align="left" valign="top"> -<span class="application">named</span> </td> +<span class="application">named-journalprint</span> </td> <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> <td width="40%" align="right" valign="top"> <span class="application">rndc</span> </td> diff --git a/doc/arm/man.rndc-confgen.html b/doc/arm/man.rndc-confgen.html index 911024fe..d87ca424 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.156 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.rndc-confgen.html,v 1.160 2009/12/04 22:22:26 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="id2637566"></a><h2>DESCRIPTION</h2> +<a name="id2638110"></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="id2637633"></a><h2>OPTIONS</h2> +<a name="id2638177"></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="id2638360"></a><h2>EXAMPLES</h2> +<a name="id2639587"></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="id2648793"></a><h2>SEE ALSO</h2> +<a name="id2644081"></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="id2648832"></a><h2>AUTHOR</h2> +<a name="id2644119"></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 ab39c610..4a16e904 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.157 2009/11/11 01:14:41 tbox Exp $ --> +<!-- $Id: man.rndc.conf.html,v 1.161 2009/12/04 22:22:26 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="id2636532"></a><h2>DESCRIPTION</h2> +<a name="id2637349"></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="id2636704"></a><h2>EXAMPLE</h2> +<a name="id2637521"></a><h2>EXAMPLE</h2> <pre class="programlisting"> options { default-server localhost; @@ -209,7 +209,7 @@ </p> </div> <div class="refsect1" lang="en"> -<a name="id2637030"></a><h2>NAME SERVER CONFIGURATION</h2> +<a name="id2637642"></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="id2637056"></a><h2>SEE ALSO</h2> +<a name="id2637668"></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="id2637094"></a><h2>AUTHOR</h2> +<a name="id2637774"></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 cdb4f9df..0ffce38e 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.155 2009/11/11 01:14:42 tbox Exp $ --> +<!-- $Id: man.rndc.html,v 1.159 2009/12/04 22:22:26 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="id2635341"></a><h2>DESCRIPTION</h2> +<a name="id2635271"></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="id2635392"></a><h2>OPTIONS</h2> +<a name="id2635321"></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="id2636299"></a><h2>LIMITATIONS</h2> +<a name="id2636161"></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="id2636330"></a><h2>SEE ALSO</h2> +<a name="id2636192"></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="id2636386"></a><h2>AUTHOR</h2> +<a name="id2636247"></a><h2>AUTHOR</h2> <p><span class="corpauthor">Internet Systems Consortium</span> </p> </div> diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt deleted file mode 100644 index 1030e578..00000000 --- a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt +++ /dev/null @@ -1,336 +0,0 @@ - - - - -Internet-Draft T. Baba -Expires: March 11, 2004 NTT Data - September 11, 2003 - - - Requirements for Access Control in Domain Name Systems - draft-baba-dnsext-acl-reqts-01.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - Distribution of this memo is unlimited. - - This Internet-Draft will expire on March 11, 2004. - -Abstract - - This document describes the requirements for access control - mechanisms in the Domain Name System (DNS), which authenticate - clients and then allow or deny access to resource records in the - zone according to the access control list (ACL). - -1. Introduction - - The Domain Name System (DNS) is a hierarchical, distributed, highly - available database used for bi-directional mapping between domain - names and IP addresses, for email routing, and for other information - [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined - to authenticate the data in DNS and provide key distribution services - using SIG, KEY, and NXT resource records (RRs) [RFC2535]. - - - -Baba Expires March 11, 2004 [Page 1] - -Internet-Draft DNS Access Control Requirements September 2003 - - - At the 28th IETF Meeting in Houston in 1993, DNS security design team - started a discussion about DNSSEC and agreed to accept the assumption - that "DNS data is public". Accordingly, confidentiality for queries - or responses is not provided by DNSSEC, nor are any sort of access - control lists or other means to differentiate inquirers. However, - about ten years has passed, access control in DNS has been more - important than before. Currently, new RRs are proposed to add new - functionality to DNS such as ENUM [RFC2916]. Such new RRs may - contain private information. Thus, DNS access control will be - needed. - - Furthermore, with DNS access control mechanism, access from - unauthorized clients can be blocked when they perform DNS name - resolution. Thus, for example, Denial of Service (DoS) attacks - against a server used by a closed user group can be prevented using - this mechanism if IP address of the server is not revealed by other - sources. - - This document describes the requirements for access control - mechanisms in DNS. - -2. Terminology - - AC-aware client - This is the client that understands the DNS access control - extensions. This client may be an end host which has a stub - resolver, or a cashing/recursive name server which has a - full-service resolver. - - AC-aware server - This is the authoritative name server that understands the DNS - access control extensions. - - ACE - An Access Control Entry. This is the smallest unit of access - control policy. It grants or denies a given set of access - rights to a set of principals. An ACE is a component of an ACL, - which is associated with a resource. - - ACL - An Access Control List. This contains all of the access control - policies which are directly associated with a particular - resource. These policies are expressed as ACEs. - - Client - A program or host which issues DNS requests and accepts its - responses. A client may be an end host or a cashing/recursive name - server. - - - -Baba Expires March 11, 2004 [Page 2] - -Internet-Draft DNS Access Control Requirements September 2003 - - - RRset - All resource records (RRs) having the same NAME, CLASS and TYPE - are called a Resource Record Set (RRset). - -3. Requirements - - This section describes the requirements for access control in DNS. - -3.1 Authentication - -3.1.1 Client Authentication Mechanism - - The AC-aware server must identify AC-aware clients based on IP - address and/or domain name (user ID or host name), and must - authenticate them using strong authentication mechanism such as - digital signature or message authentication code (MAC). - - SIG(0) RR [RFC2931] contains a domain name associated with sender's - public key in its signer's name field, and TSIG RR [RFC2845] also - contains a domain name associated with shared secret key in its key - name field. Each of these domain names can be a host name or a user - name, and can be used as a sender's identifier for access control. - Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for - message authentication. These mechanisms can be used to authenticate - AC-aware clients. - - Server authentication may be also provided. - -3.1.2 End-to-End Authentication - - In current DNS model, caching/recursive name servers are deployed - between end hosts and authoritative name servers. Although - authoritative servers can authenticate caching/recursive name servers - using SIG(0) or TSIG, they cannot authenticate end hosts behind them. - For end-to-end authentication, the mechanism for an end host to - discover the target authoritative name server and directly access to - it bypassing caching/recursive name servers is needed. For example, - an end host can get the IP addresses of the authoritative name - servers by retrieving NS RRs for the zone via local caching/recursive - name server. - - In many enterprise networks, however, there are firewalls that block - all DNS packets other than those going to/from the particular - caching/recursive servers. To deal with this problem, one can - implement packet forwarding function on the caching/recursive servers - and enable end-to-end authentication via the caching/recursive - servers. - - - - -Baba Expires March 11, 2004 [Page 3] - -Internet-Draft DNS Access Control Requirements September 2003 - - -3.1.3 Authentication Key Retrieval - - Keys which are used to authenticate clients should be able to be - automatically retrieved. The KEY RR is used to store a public key - for a zone or a host that is associated with a domain name. SIG(0) - RR uses a public key in KEY RR for verifying the signature. If - DNSSEC is available, the KEY RR would be protected by the SIG RR. - KEY RR or newly defined RR can be used to automatic key retrieval. - -3.2 Confidentiality - -3.2.1 Data Encryption - - To avoid disclosure to eavesdroppers, the response containing the - RRsets which are restricted to access from particular users should be - encrypted. Currently, no encryption mechanism is specified in DNS. - Therefore, new RRs should be defined for DNS message encryption. - Instead, IPsec [RFC2401] can be used to provide confidentiality if - name server and resolver can set up security associations dynamically - using IPsec API [IPSECAPI] when encryption is required. - - In case encryption is applied, entire DNS message including DNS - header should be encrypted to hide information including error code. - - Query encryption may be also provided for hiding query information. - -3.2.2 Key Exchange - - If DNS message encryption is provided, automatic key exchange - mechanism should be also provided. [RFC2930] specifies a TKEY RR - that can be used to establish and delete shared secret keys used by - TSIG between a client and a server. With minor extensions, TKEY can - be used to establish shared secret keys used for message encryption. - -3.2.3 Caching - - The RRset that is restricted to access from particular users must not - be cached. To avoid caching, the TTL of the RR that is restricted to - access should be set to zero during transit. - -3.3 Access Control - -3.3.1 Granularity of Access Control - - Control of access on a per-user/per-host granularity must be - supported. Control of access to individual RRset (not just the - entire zone) must be also supported. However, SOA, NS, SIG, NXT, - KEY, and DS RRs must be publicly accessible to avoid unexpected - results. - - -Baba Expires March 11, 2004 [Page 4] - -Internet-Draft DNS Access Control Requirements September 2003 - - -3.3.2 ACL Representation - - Access Control List (ACL) format must be standardized so that both - the primary and secondary AC-aware servers can recognize the same - ACL. Although ACL may appear in or out of zone data, it must be - transferred to the secondary AC-aware server with associated zone - data. It is a good idea to contain ACL in zone data, because ACL can - be transferred with zone data using existing zone transfer mechanisms - automatically. However, ACL must not be published except for - authorized secondary master servers. - - In zone data master files, ACL should be specified using TXT RRs or - newly defined RRs. In each access control entry (ACE), authorized - entities (host or user) must be described using domain name (host - name, user name, or IP address in in-addr.arpa/ip6.arpa format). - There may be other access control attributes such as access time. - - It must be possible to create publicly readable entries, which may be - read even by unauthenticated clients. - -3.3.3 Zone/ACL Transfer - - As mentioned above, ACL should be transferred from a primary AC-aware - server to a secondary AC-aware server with associated zone data. - When an AC-aware server receives a zone/ACL transfer request, the - server must authenticate the client, and should encrypt the zone - data and associated ACL during transfer. - -3.4 Backward/co-existence Compatibility - - Any new protocols to be defined for access control in DNS must be - backward compatible with existing DNS protocol. AC-aware servers - must be able to process normal DNS query without authentication, and - must respond if retrieving RRset is publicly accessible. - - Modifications to root/gTLD/ccTLD name servers are not allowed. - -4. Security Considerations - - This document discusses the requirements for access control - mechanisms in DNS. - -5. Acknowledgements - - This work is funded by the Telecommunications Advancement - Organization of Japan (TAO). - - The author would like to thank the members of the NTT DATA network - security team for their important contribution to this work. - - -Baba Expires March 11, 2004 [Page 5] - -Internet-Draft DNS Access Control Requirements September 2003 - - -6. References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, - September 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", - RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - - [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API", - draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in - Progress. - - -Author's Address - - Tatsuya Baba - NTT Data Corporation - Research and Development Headquarters - Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku, - Tokyo 104-0033, Japan - - Tel: +81 3 3523 8081 - Fax: +81 3 3523 8090 - Email: babatt@nttdata.co.jp - - - - - - - - -Baba Expires March 11, 2004 [Page 6] diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt deleted file mode 100644 index fffa8a5f..00000000 --- a/doc/draft/draft-daigle-napstr-04.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - -Network Working Group L. Daigle -Internet-Draft A. Newton -Expires: August 15, 2004 VeriSign, Inc. - February 15, 2004 - - - Domain-based Application Service Location Using SRV RRs and the - Dynamic Delegation Discovery Service (DDDS) - draft-daigle-napstr-04.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 15, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This memo defines a generalized mechanism for application service - naming that allows service location without relying on rigid domain - naming conventions (so-called name hacks). The proposal defines a - Dynamic Delegation Discovery System (DDDS) Application to map domain - name, application service name, and application protocol to target - server and port, dynamically. - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 1] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4 - 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5 - 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5 - 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5 - 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5 - 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6 - 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6 - 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1 Guidelines for Application Protocol Developers . . . . . . . 7 - 3.1.1 Registration of application service and protocol tags . . . 7 - 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8 - 3.1.3 Server identification and handshake . . . . . . . . . . . . 8 - 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8 - 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9 - 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10 - 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10 - 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12 - 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12 - 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14 - 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15 - 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 16 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 - A. Application Service Location Application of DDDS . . . . . . 18 - A.1 Application Unique String . . . . . . . . . . . . . . . . . 18 - A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18 - A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18 - A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19 - A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19 - A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20 - A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20 - A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20 - B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20 - B.1 Finding the first (best) target . . . . . . . . . . . . . . 20 - B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 - - - - -Daigle & Newton Expires August 15, 2004 [Page 2] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -1. Introduction - - This memo defines a generalized mechanism for application service - naming that allows service location without relying on rigid domain - naming conventions (so-called name hacks). The proposal defines a - Dynamic Delegation Discovery System (DDDS -- see [6]) Application to - map domain name, application service name, and application protocol - to target server and port, dynamically. - - As discussed in Section 5, existing approaches to using DNS records - to dynamically determining the current host for a given application - service are limited in terms of the use cases supported. To address - some of the limitations, this document defines a DDDS Application to - map service+protocol+domain to specific server addresses using both - NAPTR [7] and SRV ([5]) DNS resource records. This can be viewed as - a more general version of the use of SRV and/or a very restricted - application of the use of NAPTR resource records. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC2119 ([2]). - -2. Straightforward-NAPTR (S-NAPTR) Specification - - The precise details of the specification of this DDDS application are - given in Appendix A. This section defines the usage of the DDDS - application. - -2.1 Key Terms - - An "application service" is a generic term for some type of - application, indpendent of the protocol that may be used to offer it. - Each application service will be associated with an IANA-registered - tag. For example, instant messaging is a type of application - service, which can be implemented by many different application-layer - protocols, and the tag "IM" (used as an illustration here) could be - registered for it. - - An "application protocol" is used to implement the application - service. These are also associated with IANA-registered tags. In - the case where multiple transports are available for the application, - separate tags should be defined for each transport. - - The intention is that the combination of application service and - protocol tags should be specific enough that finding a known pair - (e.g., "IM:ProtC") is sufficient for a client to identify a server - with which it can communicate. - - - - -Daigle & Newton Expires August 15, 2004 [Page 3] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - Some protocols support multiple application services. For example, - LDAP is an application protocol, and can be found supporting various - services (e.g., "whitepages", "directory enabled networking", etc). - -2.2 S-NAPTR DDDS Application Usage - - As outlined in Appendix A, NAPTR records are used to store - application service+protocol information for a given domain. - Following the DDDS standard, these records are looked up, and the - rewrite rules (contained in the NAPTR records) are used to determine - the successive DNS lookups, until a desirable target is found. - - For the rest of this section, refer to the set of NAPTR resource - records for example.com shown in the figure below. - - example.com. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example. - IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com. - IN NAPTR 200 10 "" "IM:protA" "" someisp.example. - IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com. - - -2.2.1 Ordering and Preference - - A client retrieves all of the NAPTR records associated with the - target domain name (example.com, above). These are to be sorted in - terms of increasing ORDER, and increasing PREF within each ORDER. - -2.2.2 Matching and non-Matching NAPTR Records - - Starting with the first sorted NAPTR record, the client examines the - SERVICE field to find a match. In the case of the S-NAPTR DDDS - application, that means a SERVICE field that includes the tags for - the desired application service and a supported application protocol. - - If more than one NAPTR record matches, they are processed in - increasing sort order. - -2.2.3 Terminal and Non-Terminal NAPTR Records - - A NAPTR record with an empty FLAG field is "non-terminal". That is, - more NAPTR RR lookups are to be performed. Thus, to process a NAPTR - record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is - used as the target of the next DNS lookup -- for NAPTR RRs. - - In S-NAPTR, the only terminal flags are "S" and "A". These are - called "terminal" NAPTR lookups because they denote the end of the - - - -Daigle & Newton Expires August 15, 2004 [Page 4] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - DDDS/NAPTR processing rules. In the case of an "S" flag, the - REPLACEMENT field is used as the target of a DNS query for SRV RRs, - and normal SRV processing is applied. In the case of an "A" flag, an - address record is sought for the REPLACEMENT field target (and the - default protocol port is assumed). - -2.2.4 S-NAPTR and Successive Resolution - - As shown in the example NAPTR RR set above, it is possible to have - multiple possible targets for a single application service+protocol - pair. These are to be pursued in order until a server is - successfully contacted or all possible matching NAPTR records have - been successively pursued to terminal lookups and servers contacted. - That is, a client must backtrack and attempt other resolution paths - in the case of failure. - - "Failure" is declared, and backtracking must be used when - - o the designated remote server (host and port) fail to provide - appropriate security credentials for the *originating* domain - - o connection to the designated remote server otherwise fails -- the - specifics terms of which are defined when an application protocol - is registered - - o the S-NAPTR-designated DNS lookup fails to yield expected results - -- e.g., no A RR for an "A" target, no SRV record for an "S" - target, or no NAPTR record with appropriate application service - and protocol for a NAPTR lookup. Except in the case of the very - first NAPTR lookup, this last is a configuration error: the fact - that example.com has a NAPTR record pointing to "bunyip.example" - for the "WP:Whois++" service and protocol means the administrator - of example.com believes that service exists. If bunyip.example - has no "WP:Whois++" NAPTR record, the application client MUST - backtrack and try the next available "WP:Whois++" option from - example.com. As there is none, the whole resolution fails. - - An application client first queries for the NAPTR RRs for the domain - of a named application service. The application client MUST select - one protocol to choose The PREF field of the NAPTR RRs may be used by - the domain administrator to The first DNS query is for the NAPTR RRs - in the original target domain (example.com, above). - -2.2.5 Clients Supporting Multiple Protocols - - In the case of an application client that supports more than one - protocol for a given application service, it MUST pursue S-NAPTR - resolution completely for one protocol before trying another.j It MAY - - - -Daigle & Newton Expires August 15, 2004 [Page 5] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - choose which protocol to try first based on its own preference, or - from the PREF ranking in the first set of NAPTR records (i.e., those - for the target named domain). However, the chosen protocol MUST be - listed in that first NAPTR RR set. - - That is, what the client MUST NOT do is start looking for one - protocol, observe that a successive NAPTR RR set supports another of - its preferred protocols, and continue the S-NAPTR resolution based on - that protocol. For example, even if someisp.example offers the "IM" - service with protocol "ProtB", there is no reason to believe it does - so on behalf of example.com (since there is no such pointer in - example.com's NAPTR RR set). - -3. Guidelines - -3.1 Guidelines for Application Protocol Developers - - The purpose of S-NAPTR is to provide application standards developers - with a more powerful framework (than SRV RRs alone) for naming - service targets, without requiring each application protocol (or - service) standard to define a separate DDDS application. - - Note that this approach is intended specifically for use when it - makes sense to associate services with particular domain names (e.g., - e-mail addresses, SIP addresses, etc). A non-goal is having all - manner of label mapped into domain names in order to use this. - - Specifically not addressed in this document is how to select the - domain for which the service+protocol is being sought. It is up to - other conventions to define how that might be used (e.g., instant - messaging standards can define what domain to use from IM URIs, how - to step down from foobar.example.com to example.com, and so on, if - that is applicable). - - Although this document proposes a DDDS application that does not use - all the features of NAPTR resource records, it does not mean to imply - that DNS resolvers should fail to implement all aspects of the NAPTR - RR standard. A DDDS application is a client use convention. - - The rest of this section outlines the specific elements that protocol - developers must determine and document in order to make use of S- - NAPTR. - -3.1.1 Registration of application service and protocol tags - - Application protocol developers that wish to make use of S-NAPTR must - make provision to register any relevant application service and - application protocol tags, as described in Section 6. - - - -Daigle & Newton Expires August 15, 2004 [Page 6] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -3.1.2 Definition of conditions for retry/failure - - One other important aspect that must be defined is the expected - behaviour for interacting with the servers that are reached via S- - NAPTR. Specifically, under what circumstances should the client - retry a target that was found via S-NAPTR? What should it consider a - failure that causes it to return to the S-NAPTR process to determine - the next serviceable target (a less preferred target)? - - For example, if the client gets a "connection refused" from a server, - should it retry for some (protocol-dependent) period of time? Or, - should it try the next-preferred target in the S-NAPTR chain of - resolution? Should it only try the next-preferred target if it - receives a protocol-specific permanent error message? - - The most important thing is to select one expected behaviour and - document it as part of the use of S-NAPTR. - - As noted earlier, failure to provide appropriate credentials to - identify the server as being authoritative for the original taret - domain is always considered a failure condition. - -3.1.3 Server identification and handshake - - As noted in Section 7, use of the DNS for server location increases - the importance of using protocol-specific handshakes to determine and - confirm the identity of the server that is eventually reached. - - Therefore, application protocol developers using S-NAPTR should - identify the mechanics of the expected identification handshake when - the client connects to a server found through S-NAPTR. - -3.2 Guidelines for Domain Administrators - - Although S-NAPTR aims to provide a "straightforward" application of - DDDS and use of NAPTR records, it is still possible to create very - complex chains and dependencies with the NAPTR and SRV records. - - Therefore, domain administrators are called upon to use S-NAPTR with - as much restraint as possible, while still achieving their service - design goals. - - The complete set of NAPTR, SRV and A RRs that are "reachable" through - the S-NAPTR process for a particular application service can be - thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR - or SRV records; each SRV record points to several A record lookups. - Even though a particular client can "prune" the tree to use only - those records referring to application protocols supported by the - - - -Daigle & Newton Expires August 15, 2004 [Page 7] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - client, the tree could be quite deep, and retracing the tree to retry - other targets can become expensive if the tree has many branches. - - Therefore, - - o Fewer branches is better: for both NAPTR and SRV records, provide - different targets with varying preferences where appropriate - (e.g., to provide backup services, etc), but don't look for - reasons to provide more. - - o Shallower is better: avoid using NAPTR records to "rename" - services within a zone. Use NAPTR records to identify services - hosted elsewhere (i.e., where you cannot reasonably provide the - SRV records in your own zone). - - -3.3 Guidelines for Client Software Writers - - To properly understand DDDS/NAPTR, an implementor must read [6]. - However, the most important aspect to keep in mind is that, if one - target fails to work for the application, it is expected that the - application will continue through the S-NAPTR tree to try the (less - preferred) alternatives. - -4. Illustrations - -4.1 Use Cases - - The basic intended use cases for which S-NAPTR has been developed - are: - - o Service discovery within a domain. For example, this can be used - to find the "authoritative" server for some type of service within - a domain (see the specific example in Section 4.2). - - o Multiple protocols. This is increasingly common as new - application services are defined. This includes the case of - instant messaging (a service) which can be offered with multiple - protocols (see Section 4.3). - - o Remote hosting. Each of the above use cases applies within the - administration of a single domain. However, one domain operator - may elect to engage another organization to provide an application - service. See Section 4.4 for an example that cannot be served by - SRV records alone. - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 8] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -4.2 Service Discovery within a Domain - - There are occasions when it is useful to be able to determine the - "authoritative" server for a given application service within a - domain. This is "discovery", because there is no a priori knowledge - as to whether or where the service is offered; it is therefore - important to determine the location and characteristics of the - offered service. - - For example, there is growing discussion of having a generic - mechanism for locating the keys or certificates associated with - particular application (servers) operated in (or for) a particular - domain. Here's a hypothetical case for storing application key or - certificate data for a given domain. The premise is that some - credentials registry (CredReg) service has been defined to be a leaf - node service holding the keys/certs for the servers operated by (or - for) the domain. Furthermore, it is assumed that more than one - protocol is available to provide the service for a particular domain. - This DDDS-based approach is used to find the CredReg server that - holds the information. - - Thus, the set of NAPTR records for thinkingcat.example might look - like this: - - thinkingcat.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example. - - Note that another domain, offering the same application service, - might offer it using a different set of application protocols: - - anotherdomain.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example. - - -4.3 Multiple Protocols - - As it stands, there are several different protocols proposed for - offering "instant message" services. Assuming that "IM" was - registered as an application service, this DDDS application could be - used to determine the available services for delivering to a target. - - Two particular features of instant messaging should be noted: - - 1. gatewaying is expected to bridge communications across protocols - - 2. instant messaging servers are likely to be operated out of a - - - -Daigle & Newton Expires August 15, 2004 [Page 9] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - different domain than the instant messaging address, and servers - of different protocols may be offered by independent - organizations - - For example, "thinkingcat.example" may support its own servers for - the "ProtA" instant messaging protocol, but rely on outsourcing from - "example.com" for "ProtC" and "ProtB" servers. - - Using this DDDS-based approach, thinkingcat.example can indicate a - preference ranking for the different types of servers for the instant - messaging service, and yet the out-sourcer can independently rank the - preference and ordering of servers. This independence is not - achievable through the use of SRV records alone. - - Thus, to find the IM services for thinkingcat.example, the NAPTR - records for thinkingcat.example are retrieved: - - thinkingcat.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. - IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. - IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com. - - and then the administrators at example.com can manage the preference - rankings of the servers they use to support the ProtB service: - - _ProtB._tcp.example.com. - ;; Pref Weight Port Target - IN SRV 10 0 10001 bigiron.example.com - IN SRV 20 0 10001 backup.im.example.com - IN SRV 30 0 10001 nuclearfallout.australia-isp.example - - -4.4 Remote Hosting - - In the Instant Message hosting example in Section 4.3, the service - owner (thinkingcat.example) had to host pointers to the hosting - service's SRV records in the thinkingcat.example domain. - - A better way to approach this is to have one NAPTR RR in the - thinkingcat.example domain pointing to all the hosted services, and - the hosting domain has NAPTR records for each service to map them to - whatever local hosts it chooses (and may change from time to time). - - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 10] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - thinkingcat.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. - IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com. - - - and then the administrators at example.com can break out the - individual application protocols and manage the preference rankings - of the servers they use to support the ProtB service (as before): - - thinkingcat.example.com. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com. - IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. - - - - _ProtC._tcp.example.com. - ;; Pref Weight Port Target - IN SRV 10 0 10001 bigiron.example.com - IN SRV 20 0 10001 backup.im.example.com - IN SRV 30 0 10001 nuclearfallout.australia-isp.example - - -4.5 Sets of NAPTR RRs - - Note that the above sections assumed that there was one service - available (via S-NAPTR) per domain. Often, that will not be the - case. Assuming thinkingcat.example had the CredReg service set up as - described in Section 4.2 and the instant messaging service set up as - described in Section 4.4, then a client querying for the NAPTR RR set - from thinkingcat.com would get the following answer: - - thinkingcat.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. - IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com. - IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example. - - Sorting them by increasing "ORDER", the client would look through the - SERVICE strings to determine if there was a NAPTR RR that matched the - application service it was looking for, with an application protocol - it could use. The first (lowest PREF) record that so matched is the - one the client would use to continue. - -4.6 Sample sequence diagram - - Consider the example in Section 4.3. Visually, the sequence of steps - - - -Daigle & Newton Expires August 15, 2004 [Page 11] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - required for the client to reach the final server for a "ProtB" - service for IM for the thinkingcat.example domain is as follows: - - - Client NS for NS for - thinkingcat.example example.com backup.im.example.com - | | | - 1 -------->| | | - 2 <--------| | | - 3 ------------------------------>| | - 4 <------------------------------| | - 5 ------------------------------>| | - 6 <------------------------------| | - 7 ------------------------------>| | - 8 <------------------------------| | - 9 ------------------------------------------------->| - 10 <-------------------------------------------------| - 11 ------------------------------------------------->| - 12 <-------------------------------------------------| - (...) - - - - 1. the name server (NS) for thinkingcat.example is reached with a - request for all NAPTR records - - 2. the server responds with the NAPTR records shown in Section 4.3. - - 3. the second NAPTR record matches the desired criteria; that has an - "s" flag and a replacement fields of "_ProtB._tcp.example.com". - So, the client looks up SRV records for that target, ultimately - making the request of the NS for example.com. - - 4. the response includes the SRV records listed in Section 4.3. - - 5. the client attempts to reach the server with the lowest PREF in - the SRV list -- looking up the A record for the SRV record's - target (bigiron.example.com). - - 6. the example.com NS responds with an error message -- no such - machine! - - 7. the client attempts to reach the second server in the SRV list, - and looks up the A record for backup.im.example.com - - 8. the client gets the A record with the IP address for - backup.im.example.com from example.com's NS. - - - - -Daigle & Newton Expires August 15, 2004 [Page 12] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - 9. the client connects to that IP address, on port 10001 (from the - SRV record), using ProtB over tcp. - - 10. the server responds with an "OK" message. - - 11. the client uses ProtB to challenge that this server has - credentials to operate the service for the original domain - (thinkingcat.example) - - 12. the server responds, and the rest is IM. - - -5. Motivation and Discussion - - Increasingly, application protocol standards are using domain names - to identify server targets, and stipulating that clients should look - up SRV resource records to determine the host and port providing the - server. This enables a distinction between naming an application - service target and actually hosting the server. It also increases - flexibility in hosting the target service: - - o the server may be operated by a completely different organization - without having to list the details of that organization's DNS - setup (SRVs) - - o multiple instances can be set up (e.g., for load balancing or - secondaries) - - o it can be moved from time to time without disrupting clients' - access, etc. - - This is quite useful, but Section 5.1 outlines some of the - limitations inherent in the approach. - - That is, while SRV records can be used to map from a specific service - name and protocol for a specific domain to a specific server, SRV - records are limited to one layer of indirection, and are focused on - server administration rather than on application naming. And, while - the DDDS specification and use of NAPTR allows multiple levels of - redirection before locating the target server machine with an SRV - record, this proposal requires only a subset of NAPTR strictly bound - to domain names, without making use of the REGEXP field of NAPTR. - These restrictions make the client's resolution process much more - predictable and efficient than with some potential uses of NAPTR - records. This is dubbed "S-NAPTR" -- a "S"traightforward use of - NAPTR records. - - - - - -Daigle & Newton Expires August 15, 2004 [Page 13] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -5.1 So, why not just SRV records? - - An expected question at this point is: this is so similar in - structure to SRV records, why are we doing this with DDDS/NAPTR? - - Limitations of SRV include: - - o SRV provides a single layer of indirection -- the outcome of an - SRV lookup is a new domain name for which the A RR is to be found. - - o the purpose of SRV is focused on individual server administration, - not application naming: as stated in [5] "The SRV RR allows - administrators to use several servers for a single domain, to move - services from host to host with little fuss, and to designate some - hosts as primary servers for a service and others as backups." - - o target servers by "service" (e.g., "ldap") and "protocol" (e.g., - "tcp") in a given domain. The definition of these terms implies - specific things (e.g., that protocol should be one of UDP or TCP) - without being precise. Restriction to UDP and TCP is insufficient - for the uses described here. - - The basic answer is that SRV records provide mappings from protocol - names to host and port. The use cases described herein require an - additional layer -- from some service label to servers that may in - fact be hosted within different administrative domains. We could - tweak SRV to say that the next lookup could be something other than - an address record, but that is more complex than is necessary for - most applications of SRV. - -5.2 So, why not just NAPTR records? - - That's a trick question. NAPTR records cannot appear in the wild -- - see [6]. They must be part of a DDDS application. - - The purpose here is to define a single, common mechanism (the DDDS - application) to use NAPTR when all that is desired is simple DNS- - based location of services. This should be easy for applications to - use -- some simple IANA registrations and it's done. - - Also, NAPTR has very powerful tools for expressing "rewrite" rules. - That power (==complexity) makes some protocol designers and service - administrators nervous. The concern is that it can translate into - unintelligible, noodle-like rule sets that are difficult to test and - administer. - - This proposed DDDS application specifically uses a subset of NAPTR's - abilities. Only "replacement" expressions are allowed, not "regular - - - -Daigle & Newton Expires August 15, 2004 [Page 14] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - expressions". - -6. IANA Considerations - - This document calls for 2 IANA registries: one for application - service tags, and one for application protocol tags. - - Application service and protocol tags should be defined in an RFC - (unless the "x-" experimental form is used, in which case they are - unregistered). There are no restrictions placed on the tags other - than that they must conform with the syntax defined below (Appendix - A.5). The IANA registries should list the tags and the RFC that - defines their use. - -7. Security Considerations - - The security of this approach to application service location is only - as good as the security of the DNS servers along the way. If any of - them is compromised, bogus NAPTR and SRV records could be inserted to - redirect clients to unintended destinations. This problem is hardly - unique to S-NAPTR (or NAPTR in general). - - To protect against DNS-vectored attacks, applications should define - some form of end-to-end authentication to ensure that the correct - destination has been reached. Many application protocols such as - HTTPS, BEEP, IMAP, etc... define the necessary handshake mechansims - to accomplish this task. - - The basic mechanism works in the following way: - - 1. During some portion of the protocol handshake, the client sends - to the server the original name of the desired destination (i.e. - no transformations that may have resulted from NAPTR - replacements, SRV targets, or CNAME changes). In certain cases - where the application protocol does not have such a feature but - TLS may be used, it is possible to use the "server_name" TLS - extension. - - 2. The server sends back to the client a credential with the - appropriate name. For X.509 certificates, the name would either - be in the subjectDN or subjectAltName fields. For Kerberos, the - name would be a service principle name. - - 3. Using the matching semantics defined by the application protocol, - the client compares the name in the credential with the name sent - to the server. - - 4. If the names match, there is reasonable assurance that the - - - -Daigle & Newton Expires August 15, 2004 [Page 15] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - correct end point has been reached. - - It is important to note that this document does not define either the - handshake mechanism, the specific credenential naming fields, nor the - name matching semantics. Definitions of S-NAPTR for particular - application protocols MUST define these. - -8. Acknowledgements - - Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for - discussion and input that has (hopefully!) provoked clarifying - revisions of this document. - -References - - [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource - Identifiers (URI): Generic Syntax", RFC 2396, August 1998. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part - One: The Comprehensive DDDS", RFC 3401, October 2002. - - [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part - Three: The Domain Name System (DNS) Database", RFC 3403, October - 2002. - - [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part - Four: The Uniform Resource Identifiers (URI)", RFC 3404, October - 2002. - - - - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 16] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -Authors' Addresses - - Leslie Daigle - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - EMail: leslie@verisignlabs.com; leslie@thinkingcat.com - - - Andrew Newton - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - EMail: anewton@verisignlabs.com - -Appendix A. Application Service Location Application of DDDS - - This section defines the DDDS application, as described in [6]. - -A.1 Application Unique String - - The Application Unique String is domain label for which an - authoritative server for a particular service is sought. - -A.2 First Well Known Rule - - The "First Well Known Rule" is identity -- that is, the output of the - rule is the Application Unique String, the domain label for which the - authoritative server for a particular service is sought. - -A.3 Expected Output - - The expected output of this Application is the information necessary - to connect to authoritative server(s) (host, port, protocol) for an - application service within a given a given domain. - -A.4 Flags - - This DDDS Application uses only 2 of the Flags defined for the - URI/URN Resolution Application ([8]): "S" and "A". No other Flags - are valid. - - Both are for terminal lookups. This means that the Rule is the last - one and that the flag determines what the next stage should be. The - - - -Daigle & Newton Expires August 15, 2004 [Page 17] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - "S" flag means that the output of this Rule is a domain label for - which one or more SRV [5] records exist. "A" means that the output - of the Rule is a domain name and should be used to lookup address - records for that domain. - - Consistent with the DDDS algorithm, if the Flag string is empty the - next lookup is for another NAPTR record (for the replacement target). - -A.5 Service Parameters - - Service Parameters for this Application take the form of a string of - characters that follow this ABNF ([3]): - - service-parms = [ [app-service] *(":" app-protocol)] - app-service = experimental-service / iana-registered-service - app-protocol = experimental-protocol / iana-registered-protocol - experimental-service = "x-" 1*30ALPHANUMSYM - experimental-protocol = "x-" 1*30ALPHANUMSYM - iana-registered-service = ALPHA *31ALPHANUMSYM - iana-registered-protocol = ALPHA *31ALPHANUM - ALPHA = %x41-5A / %x61-7A ; A-Z / a-z - DIGIT = %x30-39 ; 0-9 - SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." - ALPHANUMSYM = ALPHA / DIGIT / SYM - ; The app-service and app-protocol tags are limited to 32 - ; characters and must start with an alphabetic character. - ; The service-parms are considered case-insensitive. - - Thus, the Service Parameters may consist of an empty string, just an - app-service, or an app-service with one or more app-protocol - specifications separated by the ":" symbol. - - Note that this is similar to, but not the same as the syntax used in - the URI DDDS application ([8]). The DDDS DNS database requires each - DDDS application to define the syntax of allowable service strings. - The syntax here is expanded to allow the characters that are valid in - any URI scheme name (see [1]). Since "+" (the separator used in the - RFC3404 service parameter string) is an allowed character for URI - scheme names, ":" is chosen as the separator here. - -A.5.1 Application Services - - The "app-service" must be a registered service [this will be an IANA - registry; this is not the IANA port registry, because we want to - define services for which there is no single protocol, and we don't - want to use up port space for nothing]. - - - - - -Daigle & Newton Expires August 15, 2004 [Page 18] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -A.5.2 Application Protocols - - The protocol identifiers that are valid for the "app-protocol" - production are any standard, registered protocols [IANA registry - again -- is this the list of well known/registered ports?]. - -A.6 Valid Rules - - Only substitution Rules are permitted for this application. That is, - no regular expressions are allowed. - -A.7 Valid Databases - - At present only one DDDS Database is specified for this Application. - [7] specifies a DDDS Database that uses the NAPTR DNS resource record - to contain the rewrite rules. The Keys for this database are encoded - as domain-names. - - The First Well Known Rule produces a domain name, and this is the Key - that is used for the first lookup -- the NAPTR records for that - domain are requested. - - DNS servers MAY interpret Flag values and use that information to - include appropriate NAPTR, SRV or A records in the Additional - Information portion of the DNS packet. Clients are encouraged to - check for additional information but are not required to do so. See - the Additional Information Processing section of [7] for more - information on NAPTR records and the Additional Information section - of a DNS response packet. - -Appendix B. Pseudo pseudocode for S-NAPTR - -B.1 Finding the first (best) target - - Assuming the client supports 1 protocol for a particular application - service, the following pseudocode outlines the expected process to - find the first (best) target for the client, using S-NAPTR. - - - target = [initial domain] - naptr-done = false - - while (not naptr-done) - { - NAPTR-RRset = [DNSlookup of NAPTR RRs for target] - [sort NAPTR-RRset by ORDER, and PREF within each ORDER] - rr-done = false - cur-rr = [first NAPTR RR] - - - -Daigle & Newton Expires August 15, 2004 [Page 19] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - while (not rr-done) - if ([SERVICE field of cur-rr contains desired application - service and application protocol]) - rr-done = true - target= [REPLACEMENT target of NAPTR RR] - else - cur-rr = [next rr in list] - - if (not empty [FLAG in cur-rr]) - naptr-done = true - } - - port = -1 - - if ([FLAG in cur-rr is "S"]) - { - SRV-RRset = [DNSlookup of SRV RRs for target] - [sort SRV-RRset based on PREF] - target = [target of first RR of SRV-RRset] - port = [port in first RR of SRV-RRset] - } - - ; now, whether it was an "S" or an "A" in the NAPTR, we - ; have the target for an A record lookup - - host = [DNSlookup of target] - - return (host, port) - - - -B.2 Finding subsequent targets - - The pseudocode in Appendix B is crafted to find the first, most - preferred, host-port pair for a particular application service an - protocol. If, for any reason, that host-port pair did not work - (connection refused, application-level error), the client is expected - to try the next host-port in the S-NAPTR tree. - - The pseudocode above does not permit retries -- once complete, it - sheds all context of where in the S-NAPTR tree it finished. - Therefore, client software writers could - - o entwine the application-specific protocol with the DNS lookup and - RRset processing described in the pseudocode and continue the S- - NAPTR processing if the application code fails to connect to a - located host-port pair; - - - - -Daigle & Newton Expires August 15, 2004 [Page 20] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - o use callbacks for the S-NAPTR processing; - - o use an S-NAPTR resolution routine that finds *all* valid servers - for the required application service and protocol from the - originating domain, and provides them in sorted order for the - application to try in order. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 21] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 22] - diff --git a/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/doc/draft/draft-danisch-dns-rr-smtp-03.txt deleted file mode 100644 index 4a01d91b..00000000 --- a/doc/draft/draft-danisch-dns-rr-smtp-03.txt +++ /dev/null @@ -1,1960 +0,0 @@ - - - -INTERNET-DRAFT Hadmut Danisch -Category: Experimental Oct 2003 -Expires: Apr 1, 2004 - - The RMX DNS RR and method for lightweight SMTP sender authorization - draft-danisch-dns-rr-smtp-03.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - -Abstract - - This memo introduces a new authorization scheme for SMTP e-mail - transport. It is designed to be a simple and robust protection - against e-mail fraud, spam and worms. It is based solely on - organisational security mechanisms and does not require but still - allow use of cryptography. This memo also focuses on security and - privacy problems and requirements in context of spam defense. In - contrast to prior versions of the draft a new RR type is not - required anymore. - - - - - - - - - - - - -Hadmut Danisch Experimental [Page 1] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Table of Contents - - -1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 -2. Problem and threat description . . . . . . . . . . . . . . . . . 4 - 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4 - 2.1.1 Definition of sender forgery . . . . . . . . . . . 4 - 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5 - 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5 - 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6 - 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6 - 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7 -3. A DNS based sender address verification . . . . . . . . . . . . 7 - 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9 - 3.3. Domain part vs. full sender address . . . . . . . . . . . 9 -4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10 - 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10 - 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11 -5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11 - 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11 - 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12 - 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13 - 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14 - 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14 - 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15 - 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15 - 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16 -6. Optional and experimental entry types . . . . . . . . . . . . . 16 - 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16 - 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16 - 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17 - 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17 -7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17 - 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18 - 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18 - 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18 - 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18 - 7.2.5 Encoding of unused and full query . . . . . . . . . 19 - 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19 -8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19 - - - -Hadmut Danisch Experimental [Page 2] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20 -10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20 - 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20 - 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21 - 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21 -11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 - 11.1. Draft specific considerations . . . . . . . . . . . . . . 22 - 11.1.1 Authentication strength . . . . . . . . . . . . . 22 - 11.1.2 Where Authentication and Authorization end . . . . 22 - 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23 - 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25 - 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25 - 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25 - 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26 - 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26 - 11.2. General Considerations about spam defense . . . . . . . . 27 - 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27 - 11.2.2 Content based Denial of Service attacks . . . . . 27 -12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 - 12.1. Draft specific considerations . . . . . . . . . . . . . . 28 - 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28 - 12.1.2 Message reception and sender domain . . . . . . . 28 - 12.1.3 Network structure . . . . . . . . . . . . . . . . 29 - 12.1.4 Owner information distribution . . . . . . . . . . 29 - 12.2. General Considerations about spam defense . . . . . . . . 29 - 12.2.1 Content leaking of content filters . . . . . . . . 29 - 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30 -13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30 - 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30 - 13.1.1 Compatibility with old mail receivers . . . . . . 30 - 13.1.2 Compatibility with old mail senders . . . . . . . 30 - 13.1.3 Compatibility with old DNS clients . . . . . . . . 30 - 13.1.4 Compatibility with old DNS servers . . . . . . . . 30 - 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31 -14. General considerations about fighting spam . . . . . . . . . . 31 - 14.1. The economical problem . . . . . . . . . . . . . . . . . 31 - 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32 - 14.3. The network structure problem . . . . . . . . . . . . . . 33 - 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33 - 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33 - 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34 -Implementation and further Information . . . . . . . . . . . . . . . 34 -References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 -Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 -Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - - - - - - -Hadmut Danisch Experimental [Page 3] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -1. General Issues - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in RFC 2119 [1]. - -2. Problem and threat description - -2.1. Mail sender forgery - - The amount of e-mails with forged sender addresses has dramatically - increased. As a consequence, damages and annoyances caused by such - e-mails increased as well. In the majority of examined e-mails the - domain name of the envelope sender address was forged, and the e- - mail was sent from an IP address which does not belong to a network - used by the actual owner of the domain. - -2.1.1. Definition of sender forgery - - As discussions, comments to prior versions of this draft, and - different approaches to stop forgery showed, different perceptions - of "mail forgery" exist. For example, there are mechanisms to - verify e-mail addresses for mailing lists, web servers, or to stop - spam, which do send a message with a random number to the given - address and expect the user to send a reply. Here, someone is - considered to be allowed to use a particular e-mail address, if and - only if he is able to receive informations sent to this address, - and is able to reply to such a message. While this definition - appears to be quite plausible and natural, it can't be used for a - simple technical solution. Sending back a challenge and expecting a - reply is simply too much overhead and time delay, and not every - authorized sender is able or willing to reply (e.g. because he went - offline or is not a human). - - Within the scope of this memo, sender forgery means that the - initiator of an e-mail transfer (which is the original sender in - contrast to relays) uses a sender address which he was not - authorized to use. Being authorized to use an address means that - the owner (administrator) of the internet domain has given - permission, i.e. agrees with the use of the address by that - particular sender. This memo will cover both the permission of the - full e-mail address and the domain part only for simplicity. - - Within context of Internet and SMTP, the sender address usually - occurs twice, once as the envelope sender address in SMTP, and once - as the address given in the RFC822 mail header. While the following - considerations apply to both addresses in principle, it is - important to stress that both addresses have distinct semantics and - - - -Hadmut Danisch Experimental [Page 4] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - are not neccessarily the same. The envelope address identifies the - initiator of the transport, while the header identifies the author - of the message content. Since this memo deals with the message - transport only and completely ignores the message content, the - method should naturally be applied to the envelope sender address. - -2.1.2. Spam - - A common and well known problem is the dramatic increase of - unsolicited e-mail, commonly called "spam". Again, the majority of - examined e-mails had forged sender addresses. The abused domains - were mainly those of common webmailers as hotmail or yahoo, or - well-known companies. - - Unfortunately, there is no accurate definition of spam availabe - yet, and neither are the concise technical criterions to filter or - block spam with technical mechanisms. There are efforts to design - content based filters, but these filters are expensive in - calculation time (and sometimes money), and they do not reliably - provide predictable results. Usually they give false positives - and/or require user interaction. Content filters in general suffer - from a design problem described later in this memo. Therefore, - this proposal does not use the content based approach to block - spam. - - As analysis of spam messages showed, most of spam messages were - sent with forged envelope sender addresses. This has mainly three - reasons. The first reason is, that spam senders usually do not - want to be contacted by e-mail. The second reason is, that they do - not want to be blacklisted easily. The third reason is, that spam - is or is going to be unlawful in many countries, and the sender - does not want to reveal his identity. Therefore, spam is considered - to be a special case of sender forgery. - -2.1.3. E-Mail Worms - - Another example of sender forgery is the reproduction of e-mail - worms. Most worms do choose random sender addresses, e.g. using - the addresses found in mailboxes on the infected system. In most - cases analyzed by the author, the e-mails sent by the reproduction - process can also be categorized as forged, since the infected - system would under normal circumstances not be authorized to send - e-mails with such e-mail addresses. So forgery does not require a - malicious human to be directly involved. This memo covers any kind - of e-mail sender address forgery, included those generated by - malicious software. - -2.1.4. E-Mail spoofing and fraud - - - -Hadmut Danisch Experimental [Page 5] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Forging e-mail sender addresses for fraud or other kinds of - deception ("human engineering") has also dramatically increased. - There are many known cases where single or mass e-mails were sent - with wrong sender addresses, pretending to come from service - provider, software manufacturers etc., and asking the receiver to - install any software or patches, or to reply with any confidential - information. The Internet is becoming more and more a scene of - crime, and so are it's services, including e-mail. It is obvious - that crime based on e-mail is eased by the fact that SMTP allows - arbitrary sender address spoofing. - -2.2. Indirect damage caused by forgery - - As observed by the author, mass mails and worms with forged sender - addresses can cause a severe damage for the real owner of the - abused sender addresses. If a sender A is sending an e-mail to the - receiver B, pretending to be C by using a sender address of C's - domain, then C has currently no chance to prevent this, since C's - machines and software are not involved in any way in the delivery - process between A and B. B will nevertheless send any error - messages (virus/spam alert, "no such user", etc.) to C, erroneously - assuming that the message was sent by C. The author found several - cases where this flood of error messages caused a severe denial of - service or a dramatic increase of costs, e.g. when C was - downloading the e-mail through expensive or low bandwidth - connections (e.g. modem or mobile phones), or where disk space was - limited. The author examined mass mailings, where several tens or - hundreds of thousands of messages were sent to several addresses - around the world, where these messages caused only annoyance. But - since several thousands of these addresses were invalid or didn't - accept the message, the owner of the DNS domain which was abused by - the spammer to forge sender addresses was flooded for several - months with thousands of error messages, jamming the e-mail system - and causing severe costs and damages. - - As a consequence, when A sends a message to B, pretending to be C, - there must be any mechanism to allow C to inform B about the fact, - that A is not authorized to use C as a sender address. This is what - this memo is about. - -2.3. Technical problem analysis - - Why does e-mail forgery actually exist? Because of the lack of the - Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender - authentication, authorisation, or verification. This protocol was - designed at a time where security was not an issue. Efforts have - been made to block forged e-mails by requiring the sender address - domain part to be resolvable. This method provides protection from - - - -Hadmut Danisch Experimental [Page 6] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - e-mails with non-existing sender domains, and indeed, for some time - it blocked most spam e-mails. However, since attackers and spam - senders began to abuse existing domain names, this method was - rendered ineffective. - -2.4. Shortcomings of cryptographical approaches - - At a first glance, the problem of sender address forgery might - appear to be solvable with cryptographic methods such as challenge - response authentications or digital signatures. A deeper analysis - shows that only a small, closed user group could be covered with - cryptographical methods. Any method used to stop spam forgery must - be suitable to detect forgery not only for a small number of - particular addresses, but for all addresses on the world. An - attacker does not need to know the secrets belonging to a - particular address. It is sufficient to be able to forge any - address and thus to know any secret key. Since there are several - hundreds of millions of users, there will always be a large amount - of compromised keys, thus spoiling any common cryptographic method. - Furthermore, cryptography has proven to be far too complicated and - error prone to be commonly administered and reliably implemented. - Many e-mail and DNS administrators do not have the knowledge - required to deal with cryptographic mechanisms. Many legislations - do not allow the general deployment of cryptography and a directory - service with public keys. For these reasons, cryptography is - applicable only to a small and closed group of users, but not to - all participants of the e-mail service. - -3. A DNS based sender address verification - -3.1. Overview - - To gain improvement in e-mail authenticity while keeping as much - SMTP compatibility as possible, a method is suggested which doesn't - change SMTP at all. - - The idea is to store informations about how to verify who is - authorized to transmit e-mails through SMTP with a particular - sender address (either full address or - for simplicity - only the - domain part of the address) in a directory service, which is - currently the DNS. To be precise, the verification consists of two - steps, the classical pair of authentication and authorization: - - The first step is the authentication. While several methods are - possible to perform authentication (see below), the most important - and robust method is the verification of the sender's IP address. - This is done implicitely by TCP/IP and the TCP sequence number. The - authenticated identity is the IP address. It has to be stressed - - - -Hadmut Danisch Experimental [Page 7] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - that this TCP/IP "authentication" is a weak authentication and - vulnerable to several attacks. It is nevertheless sufficient for - this purpose, especially for blocking spam. It doesn't take any - implementation and it doesn't cost: It is already there, it is a - functionality of TCP/IP. An incoming SMTP connection based on - TCP/IP already carries the sender's IP address without any - modification of SMTP. See below (section Entry types) for more - details about authentication methods. - - The second step is the authorization. It is based on the identity - given by the previous authentication step, e.g. the IP address of - the originator of the incoming SMTP connection, and on the - envelope sender address. The mechanism proposed in this memo - answers the question "Is that particular sender (IP address,...) - allowed to send with that sender address" by querying and - processing informations stored in a directory service, which is - DNS. - - When the sender has issued the "MAIL FROM:" SMTP command, the - receiving mail transfer agent (MTA) can - and modern MTAs do - - perform some authorization checks, e.g. run a local rule database - or check whether the sender domain is resolvable. - - The suggested method is to let the DNS server for the sender domain - provide informations about who - this means for example which IP - address - is authorized to use an address or a domain as a part of - it. After receiving the "MAIL FROM:" SMTP command, the receiving - MTA can verify, whether e. g. the IP address of the sending MTA is - authorized to send mails with this domain name. Therefore, a list - of entries with authorized IP addresses or other informations is - provided by the authoritative DNS server of that domain. The entry - types are described in the subsequent chapters. Some of these - methods are - - - An IPv4 or IPv6 network address and mask - - A fully qualified domain name referring to an A record - - A fully qualified domain name referring to an APL record - - RMX records of these types would look like this: - - somedomain.de. IN RMX ipv4:10.0.0.0/8 - rmxtest.de. IN RMX host:relay.provider.com - danisch.de. IN RMX apl:relays.rackland.de - relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24 - - where the machine with the example address 213.133.101.23 and the - machines in the example subnet 1.2.3.0/24 are the only machines - allowed to send e-mails with an envelope sender address of domain - - - -Hadmut Danisch Experimental [Page 8] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - danisch.de. Since the APL records do not necessarily belong to the - same domain or zone table as the RMX records, this easily allows to - refer to APL records defined by someone else, e.g. the internet - access or server hosting provider, thus reducing administrative - overhead to a minimum. In the example given above, the domain - danisch.de and several other domains are hosted by the service - provider Rackland. So if the relay structure of Rackland is - modified, only the zone of rackland.de needs to be modified. The - domain owners don't need to care about such details. - -3.2. Envelope vs. header sender address - - Questions were raised why the proposed mechanism is based on the - envelope sender address, and not on the sender address given in the - message header. Technically, both can be used. Actually, it makes - sense to use the envelope address. - - In common, the header sender address identifies the author of the - content, while the envelope sender tells who caused the - transmission. The approach proposed in this memo is transmission - based, not content based. We can not authorize the author of a - message if we don't have contact with him, if the message does not - already contain a signature. In contrast, the sending MTA is linked - to an IP address which can be used for authentication. This - mechanism might not be very strong, but it is available and - sufficient to solve today's e-mail security problems. - - Some people argued that it is the header address and not the sender - address, which is displayed in common mail readers (MUAs), and - where the receiver believes the mail comes from. That's true, but - it doesn't help. There are many cases where the header sender - differs from the envelope sender for good reasons (see below in the - consequences chapter for the discussion about relaying). Relaying, - mailing lists etc. require to replace the sender address used for - RMX. If this were the header address, the message header would have - to be modified. This is undesirable. - -3.3. Domain part vs. full sender address - - Former versions of this draft were limited to the domain part of - the sender address. The first reason is that it is common and MX- - like, to lookup only the domain part of an e-mail address in DNS. - The second reason is, that it was left to the private business of - the domain administration to handle details of user verification. - The idea was that the domain administration takes care to verify - the left part of an e-mail address with an arbitrary method of - their individual taste. RMX was originally designed to ignore the - left part of the address and to expect the domain administration to - - - -Hadmut Danisch Experimental [Page 9] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - take over responsibility for enforcing their policy. If, e.g., a - spam message arrived and passed the RMX mechanism, it is known to - be authorized by the domain administration and they can be blamed, - no matter what is on the left side of the sender address - it's - their private problem what happens on the left side of the @. By - far the most of the comments to prior versions of this draft agreed - with that. A few comments asked for a finer granularity. - - And indeed, there is no technical reason against a finer - granularity. All it takes is a mapping from a given envelope - sender address to a DNS name, and the RMX lookup for that - particular e-mail address could be done instead of a lookup for the - domain part only. However, to my knowledge, most domain - administrators would not like to provide an RMX entry for every - single e-mail address. In many cases, this would also overload DNS - servers. - - It is to be discussed how to cover both views. One method could be - to query the full address, and if no RMX records were found to - query the domain part only. A different approach would be to query - the domain part only, and if it's RMX record contain a special - entry, then a new query for the full address is triggered. A third - way would be to always query the full address and to leave the - problem to the wildcard mechanism of DNS. This still has to be - discussed and will be described in future versions of this draft. - - - - - - - - - - - -4. Mapping of E-Mail addresses to DNS names - - To perform the RMX query, a mapping is needed from E-Mail addresses - to DNS fully qualified domain names. - - This chapter is under development and just a first approach. - -4.1. Domain part only - - Mapping of the domain part is trivial, since the domain part of an - e-mail address itself is a valid DNS name and does not need - translation. It might be nevertheless desirable to distinguish the - - - -Hadmut Danisch Experimental [Page 10] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - RMX entries from other entries, depending of the encoding of the - records. If the RMX entries are encoded in TXT record types, they - might collide with other uses of TXT records. It might be - necessary to prepend the domain part with a special prefix, e.g. - _rmx. So the e-mail address some.user@example.com could be mapped - to example.com or _rmx.example.com. - -4.2. Full address - - Mapping a full address is slightly more difficult. The @ sign must - be unambiguously translated, and therefore can not be simply - translated into a dot. The e-mail addresses some.user@example.com - and some@user.example.com must have different mappings. Therefore, - the @ sign could be translated into _rmx, implicitely assuming that - this is not an allowed domain name component of normal domain - names. Then the rightmost _rmx in the mapped DNS name always - corresponds to the @ sign. some.user@example.com would e translated - into some.user._rmx.example.com and can be covered by a wildcard - entry like *._rmx.example.com. - - Character encoding and character sets are still to be discussed. - -4.3. Empty address - - Unfortunately, SMTP allows empty envelope sender addresses to be - used for error messages. Empty sender addresses can therefore not - be prohibited. As observed, a significant amount of spam was sent - with such an empty sender address. To solve this problem, the host - name given in the HELO or EHLO command is taken to lookup the RMX - records instead. This makes sense, since such messages were - generated by the machine, not a human. - - - - -5. Mandatory entry types and their syntax - - The entry types described in this section MUST be supported by any - implementation of this draft. - -5.1. Overall structure - - Similar to APL, an RMX record is just a concatenation of zero or - more RMX entries. The entries within one record form an ordered - rule base as commonly usual in packet filtes and firewall rulesets, - i. e. they are processed one ofter another until the first entry - matches. This entry determines the result of the query. Once a - matching entry is found, the RMX processing is finished. - - - -Hadmut Danisch Experimental [Page 11] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - For any domain name there should not exist more than a single RMX - record. Due to the structure of DNS, it is nevertheless possible to - have more than a single RMX record. Multiple RMX records are - treated as a single record consisting of the concatenation of all - records. While the entries in a record are ordered, the records are - not ordered and may be processed in arbitrary order. If the order - of the entries matters, it is the zone maintainer's responsibility - to keep those entries in a single record. For example, there are - negative entries, which exclude IP addresses from authorization. - It is important that these entries are processed before positive - entries giving permission to a wider address range. Since order is - guaranteed only within a record, corresponding negative and - positive entries must be put in the same record. - - An RMX record may consist of one or more entries, where the entries - are separated by whitespace. An entry must not contain white space. - Each entry consists of an optional exclamation sign, a tag, a - colon, and the entry data: - - [!] TAG : ENTRY-SPECIFIC-DATA - - If the entry starts with an exclamation sign, the entry is negated. - See the entry type description below for details. - - The TAG is the mnemonic type identifier or the decimal number of - the entry. The TAG is case-insensitive. It is immediately followed - by a colon. - - The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the - entry type. See description below. - - Example: - - danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5 - ipv4:1.2.3.0/24 - -5.2. Unused - - This is a primitive entry which just says that this sender address - will never be used as a sender address under any circumstances. - Example: - - testdomain.danisch.de IN RMX unused: - -5.3. IPv4 and IPv6 address ranges - - These entry types contain a bit sequence representing a CIDR - address part. If that bit sequence matches the given IP address, - - - -Hadmut Danisch Experimental [Page 12] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - authorization is granted or denied, depending on the negation flag. - - The entry is prepended with the tag "IPv4" or "IPv6". The colon is - followed with an IPv4 or IPv6 address in standard notation, - optionally followed by a slash and a mask length. If the negation - flag is set, then the given address range is excluded. Examples: - - danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0 - IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16 - IN RMX !ipv4:1.2.3.4 - - (Please note that it does not make much sense to use - RFC1918-Addresses in RMX records, this is just to give a syntax - example.) - - -5.4. DNS Hostname - - This entry type simply contains a regular DNS name, which is to be - resolved as a host name (fetch the A record or IPv6 equivalent). If - the given IP address matches the result, authorization is granted - or denied, depending on the negation flag. It is still to be - defined how to treat unresolvable entries. - - The entry is prepended with the tag "host", followed by a colon and - the hostname. Examples: - - danisch.de IN RMX host:relay.provider.de - IN RMX !host:badmachine.domain.de apl:relays.domain.de - -5.4.1. Road warriors and DynDNS entries - - Several people argued against RMX that it would break their - existing installation which delivers e-mail from dynamically - assigned IP addresses, because their IP providers didn't assign a - static address, or because they are a road warrior, plugging their - notebook in any hotel room on the world. - - RMX provides a simple solution. If such a machine has a dynamically - updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of - the hostname type pointing to this dynamic DNS entry. - - The cleaner solution would be to deliver mail the same way as it is - received: If downloaded by POP from a central relay with a static - address, where the MX points to, then it would be a good idea to - deliver e-mail the same way in reverse direction. Unfortunately, - plain POP does not support uploading yet. - - - - -Hadmut Danisch Experimental [Page 13] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -5.5. APL Reference - - This entry type simply contains a regular DNS name, which is to be - resolved as an APL record index (fetch the APL record). If the - given IP address positively matches the APL, authorization is - granted. Details of the semantic (espially when the negation bit is - set) are still to be defined. It is still to be defined how to - treat unresolvable entries. - - The entry is prepended with the tag "host", followed by a colon and - the hostname. Example: - - danisch.de IN RMX apl:relays.rackland.de - -5.6. Domain Member - - In many cases it is desirable to cover all hosts of a given domain - with an RMX record without the need to duplicate the list of these - hosts. This entry type does it (thanks to Eric A. Hall for pointing - out this entry type). It contains a regular DNS name. - - If this entry type is given, a reverse DNS query for the IP address - of the sending MTA is performed to find its official fully - qualified domain name. To prevent spoofing, this domain name is - accepted only if a subsequent address query to the given domain - name points to exactly the IP address of the sending MTA (the usual - procedure to verify PTR records). - - The entry matches if the fully qualified domain name of the sending - MTA ends in the given domain. The negation flag works as usual. - - The tag for this entry type is "domain". After the colon the domain - name is given, but might be empty, thus pointing to itself. - Example: - - somedomain.org IN RMX domain:somedomain.org domain:provider.com - - would authorize all machines which's hostname can be verified - through an PTR and A query, and which ends in "somedomain.org" or - "provider.com". - - With such an entry, large companies with different networks can - easily be covered with just a single and simple RMX entry. - Obviously, it requires proper PTR records. - - As a special shortcut, the DNS name may be empty. In this case the - domain name of the zone itself is taken. Thus, with a very simple - entry of the type - - - -Hadmut Danisch Experimental [Page 14] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - somecompany.com IN RMX domain: - - a company could authorize all machines which's IP addresses map to - DNS names end in somecompany.com, which applies in the majority of - companies. - - - - -5.7. Full Address Query - - As described above, RMX records will in most cases apply to the - domain part of the sender address. In special cases it might be - desirable to query the RMX record for a particular address. An RMX - entry of the Full Address Query type may occur in a domain RMX - record only. It signals that the RMX record for the full address is - to be fetched and processed. - - This entry type does not take arguments. The negation flag is not - supported. The tag is "full". - - If such a full address query is to be performed, the mail address - must be mapped to a valid and non-ambiguos DNS name. This mapping - is still to be defined. It is not sufficient to simply replace the - @ with a dot, because of case sensitivity, character sets, etc. The - e-mail addresses - - john.doe@example.org - John.Doe@example.org - john@doe.example.org - - must all be mapped to different DNS entries. This entry type might - vanish in future versions of the draft, depending on the discussion - about whether to query the domain name part only or the full - address. - -5.8. DNS mapped authorization - - As I learned from comments to prior versions of the draft and from - alternative proposals, many users wish to have a DNS mapped - authorization table, i. e. the client queries a DNS entry of the - form a.b.c.d.domain, where a.b.c.d is the sender's IP address. - Since people wish to have this, RMX will now include such a mapping - entry. The entry has a parameter giving the DNS domain name where - to look at. If the parameter is empty, then the same domain is - taken as for the RMX lookup. - - As this is currently under construction and discussion in an IETF - - - -Hadmut Danisch Experimental [Page 15] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - group, details will be published in future versions of this draft. - -5.9. RMX reference - - This entry type has no parameters. It means that all those machines - are authorized, which are pointed to by an MX record. - -6. Optional and experimental entry types - - The following subsections roughly describe further entry types - which might not be supported by all implementations and might not - be allowed in all legislations. These methods might vanish in - future versions of the draft and are just considerations about what - to include in RMX and what to not include. The main purpose of this - section is to start discussion about such entry types. - - The disadvantage of the following methods is that they violate the - basic idea of RMX, i. e. to be simple, robust, easy to implement - and easy to administer. I personally do not believe that it is a - good idea or even feasible to implement cryptography for a world - wide e-mail transfer network. Keep in mind that cryptographic keys - can be copied. If only <0.1% of cryptographic keys were revealed, - this completely compromises and spoils RMX. Cryptography is simply - the wrong tool for the problem RMX is intended to solve. I - nevertheless like to discuss these methods. - -6.1. TLS fingerprint - - The sender is considered to be authorized if the message was - transmitted through SMTP and TLS, and the sender used a certificate - matching the fingerprint given in the RMX record. - -6.2. TLS and LDAP - - This means that the receiver should perform an LDAP query for the - sender address (through the LDAP SRV record or given in the RMX - record), fetch the X.509 certificate for the sender. The sender is - considered to be authorized when the message was transmitted - through SMTP and TLS using this certificate. - -6.3. PGP or S/MIME signature - - It would be possible to accept a message only if it was signed with - PGP or S/MIME with a key which's fingerprint is given in the RMX - record or to be fetched from LDAP or any PGP database. This is - just for discussion, since it violates the idea of RMX to focus on - the transport, not on the content. It would also allow replay - attacks and not cover the envelope sender address or message - - - -Hadmut Danisch Experimental [Page 16] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - header. - -6.4. Transparent Challenge/Response - - It would also be possible to implement a challenge-response - mechanism without modifying the syntax of SMTP. For example, the - receiving MTA could issue a challenge with it's very first greeting - message, the sending MTA could hide the response in the HELO - parameter and when the receiving MTA later learns the sender - envelope address, it could verify the response based on - informations in the RMX record. - -6.5. SASL Challenge/Response - - Modern SMTP implementations already include a SASL mechanisms, - which easily allows to plugin new authentication mechanisms. While - common SASL mechanisms require to use a previously shared password, - a new mechanism could perform a challenge response authentication - as a SASL method. - - - - - - -7. Encoding - -7.1. Alternative encoding as TXT records - - The main objection against the prior versions of this draft was - that it requires a new RR entry type and upgrading all DNS servers. - - Therefore and alternative encoding is proposed. Instead of using a - new RR type, the TXT record type is used to contain the RMX record. - The records would simply look as described in the entry type - chapters above, e.g. - - _rmx.danisch.de. IN TXT "apl:relays.rackland.de" - - To allow smooth introduction of RMX without the need to immediately - upgrade all DNS servers, all clients (which have to be newly - installed anyway) MUST support both the TXT and the RMX records. A - client has to perform an ANY or a TXT and a RMX query. Servers/zone - tables may currently use TXT entries but SHOULD use RMX entries in - future. - -7.2. RMX Records - - - - -Hadmut Danisch Experimental [Page 17] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -7.2.1. Overall structure - - Each entry starts with an octet containting the entry type and the - negation flag: - - +---+---+---+---+---+---+---+---+------ - | N | Entry Type Code | Parameters... - +---+---+---+---+---+---+---+---+------ - - N If this bit (MSB) is set, an IP address - matching this entry is not authorized, - but explicitely rejected. See entry - type descriptions for details. - - Entry Type A 7bit number simply determining the entry - type. - - - Currently, entries do not have an explicit length field, the entry - length is determined implicitely by the entry type. Applications - are required to abort if an unknown entry type is found, instead of - skipping unknown entries. - -7.2.2. Record encoding - - A RMX record is simply a concatenation of RMX entries. - -7.2.3. Encoding of IPv4 and IPv6 address ranges - - After the entry type tag as described above, one octet follows - giving the length L of the bit sequence. Then a sequence of exactly - as many octets follows as needed to carry L bits of information (= - trunc((L+7)/8) ). - - +---+---+---+---+---+---+---+---+ - | N | Entry Type Code (1 or 2) | - +---+---+---+---+---+---+---+---+ - | Length Field L | - +---+---+---+---+---+---+---+---+ - | Bit Field | - / ((L+7)/8) Octets / - +---+---+---+---+---+---+---+---+ - - -7.2.4. Encoding of DNS - - After the entry type tag immediately follows a DNS encoded and - compressed [3] domain name. - - - -Hadmut Danisch Experimental [Page 18] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - +---+---+---+---+---+---+---+---+ - | N | Entry Type Code (3..5) | - +---+---+---+---+---+---+---+---+ - | Length Field L | - +---+---+---+---+---+---+---+---+ - | Encoded DNS | - / Name as described in RFC1035 / - +---+---+---+---+---+---+---+---+ - - In contrast to earlier versions of this draft, the DNS name cannot - be compressed, since this would cause decompression errors when a - DNS server is part of the query chain which does not know this - particular RR type. - -7.2.5. Encoding of unused and full query - - These entries do not contain parameters and does not allow the - negation flag. So the encoding is quite simple: - - +---+---+---+---+---+---+---+---+ - | 0 | Entry Type Code (6 or 7)| - +---+---+---+---+---+---+---+---+ - - - -7.2.6. Additional Records - - In order to avoid the need of a second query to resolve the given - host name, a DNS server should enclose the A record for that domain - name in the additional section of the additional section of the DNS - reply, if the server happens to be authoritative. - - In order to avoid the need of a second query to resolve the given - host name, a DNS server should enclose the APL record for that - domain name in the additional section of the additional section of - the DNS reply, if the server happens to be authoritative. - - - -8. Message Headers - - An RMX query must be followed by any kind of action depending on - the RMX result. One action might be to reject the message. Another - action might be to add a header line to the message body, thus - allowing MUAs and delivery programs to filter or sort messages. - - In future, the RMX result might be melted into the Received: header - line. - - - -Hadmut Danisch Experimental [Page 19] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - The details of such entries are to be discussed. As a proposal the - following form is suggested: - - X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM - - where - - RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX", - "TempFail", "BadData", "Trusted". - - ADDRESS is the IP address of the sending machine - - HOST is the name of the machine performing the RMX query. - - DATE is the date of the query. - - MECHANISM is the RMX method used to authorize the sender. - - - -9. SMTP error messages - - If a message is rejected because of RMX records, an error message - should be issued which explains the details. It is to be discussed - whether new SMTP error codes are to be defined. - - -10. Message relaying and forwarding - -10.1. Problem description - - Message forwarding and relaying means that an MTA which received an - e-mail by SMTP does not deliver it locally, but resends the message - - usually unchanged except for an additional Received header line - and maybe the recipient's address rewritten - to the next SMTP MTA. - Message forwarding is an essential functionality of e-mail - transport services, for example: - - - Message transport from outer MX relay to the intranet - - Message forwarding and Cc-ing by .forward or .procmail-alike - mechanisms - - Mailing list processing - - Message reception by mail relays with low MX priority, - usually provided by third parties as a stand-by service - in case of relay failure or maintenance - - "Forwarding" and "Bouncing" as a MUA functionality - - In all these cases a message is sent by SMTP from a host which is - - - -Hadmut Danisch Experimental [Page 20] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - not covered by the original sender domain's RMX records. While the - RMX records would forbid accepting this message, it still must be - accepted. The following subsections explain how to cope with - relaying. - -10.2. Trusted relaying/forwarding - - In some cases the receiving MTA trusts the sending MTA to not fake - messages and to already have checked the RMX records at message - reception. As a typical example, a company might have an outer mail - relay which receives messages from the Internet and checks the RMX - records. This relay then forwards the messages to the different - department's mail servers. It does not make sense for these - department mail servers to check the RMX record, since the RMX - records have already been checked and - since the message was - relayed by the outer relay - always would deny the message. In this - case there is a trust relationship between the department relays - and the outer relay. So RMX checking is turned off for trusted - relays. In this example, the department relays would not check - messages from the outer relay (but for intranet security, they - could still check RMX records of the other departments sub-domains - to avoid internal forgery between departments). - - Another common example are the low-priority MX relays, which - receive and cache e-mails when the high-priority relays are down. - In this case, the high-priority relay would trust the low-priority - relay to have verified the sender authorization and would not - perform another RMX verification (which would obviously fail). - - When a relay forwards a message to a trusting machine, the envelope - sender address should remain unchanged. - -10.3. Untrusted relaying/forwarding - - If the receiving MTA does not trust the forwarding MTA, then there - is no chance to leave the sender envelope address unchanged. At a - first glance this might appear impracticable, but this is - absolutely necessary. If an untrusted MTA could claim to have - forwarded a message from a foreign sender address, it could have - forged the message as well. Spammers and forgers would just have to - act as such a relay. - - Therefore, it is required that, when performing untrusted - forwarding, the envelope sender address has to be replaced by the - sender address of someone responsible for the relaying mechanism, - e.g. the owner of the mailing list or the mail address of the user - who's .forward caused the transmission. It is important to stress - that untrusted relaying/forwarding means taking over responsibility - - - -Hadmut Danisch Experimental [Page 21] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - for the message. It is the idea of RMX records to tie - responsibility to message transmission. Untrusted relaying without - replacing the sender address would mean to transmit without taking - responsibility. - - The disadvantage is that the original sender address is lost. - Therefore, whenever a sender address replacement happens, the - Received-Line must contain the old address. Many of today's MTAs - already insert the envelope recipient address, but not the sender - address into the Received header line. It seems reasonable to - require every Received line to include both the sender and - recipient address of the incoming SMTP connection. - - -11. Security Considerations - -11.1. Draft specific considerations - -11.1.1. Authentication strength - - It is important to stress, that the suggested method does not - provide high level security and does not completely prevent forged - e-mails or spam under any circumstances. It is a robust, but not - highly reliable and completely secure security mechanism. Keep in - mind that it is based on DNS, and DNS is not secure today. - Authorization is based on the IP address. The very same machine - with the very same IP address could be authorized to send e-mail - with a given sender address and sending spam at the same time. - Maybe because several users are logged in. Or because several - customers use the same relay of the same ISP, where one customer - could use the sender address of a different customer. It is up to - the ISP to prevent this or not. Machines can still be hijacked. - Spammers are also domain owners. They can simply use their own - domain and authorize themselves. You will always find people on the - world who do not care about security and open their relays and RMX - records for others to abuse them. RMX is to be considered as a - very cheap and simple light weight mechanism, which can - nevertheless provide a significant improvement in mail security - against a certain class of attacks, until a successor of SMTP has - been defined and commonly accepted. - -11.1.2. Where Authentication and Authorization end - - Previous versions of RMX records did not cover the local part of - the e-mail address, i.e. what's on the left side of the @ sign. - This is still to be discussed. Authentication and authorization are - limited to the sending MTA's IP address. The authentication is - limited to the TCP functionality, which is sufficient for light - - - -Hadmut Danisch Experimental [Page 22] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - weight authentication. The RMX records authorize the IP address of - the sending host only, not the particular sender of the message. So - if a machine is authorized to use sender addresses of more than a - single domain, the authentication scheme does not prevent that any - user on this machine can send with any of these domains. RMX is not - a substitute for the host security of the involved machines. - - The proposed authentication scheme can be seen as a "half way - authentication": It does not track back an e-mail to the effective - sender. It tracks only half of the way, i. e. it tracks back to the - domain and it's DNS administrators who authorized that particular - sender IP address to use it for sending e-mail. How the party - responsible for that domain performs user authentication, whom it - grants access to, how it helds people responsible for abuse, is - completely left as the private business of those who are in charge - of that domain. So this draft does not interfere with the domain's - individual security policy or any legislation about such policies. - On the other hand, the proposed authentication scheme does not give - any statement about the nature and quality of the domain's security - policy. This is an essential feature of the proposal: E-mail - authentication must be deployed world wide, otherwise it won't do - the job. Any security scheme interfering with the local - legislations or the domain's security policy will not be accepted - and can't effectively deployed. Therefore, the security policy must - remain the domain's private business, no matter how lousy the - policy might be. - - In order to achieve this and to make use of the only existing world - wide Internet directory scheme (DNS), the approach of this proposal - is to just ignore the local part of the sender address (i.e. what's - left of the @ part) and limit view to the domain part. After all, - that's what we do anyway when delivering to a given address with - SMTP. - -11.1.3. Vulnerability of DNS - - DNS is an essential part of the proposed authentication scheme, - since it requires any directory service, and DNS is currently the - only one available. Unfortunately, DNS is vulnerable and can be - spoofed and poisoned. This flaw is commonly known and weakens many - network services, but for reasons beyond that draft DNS has not - been significantly improved yet. After the first version of this - draft, I received several comments who asked me not to use DNS - because of its lack of security. I took this into consideration, - but came to the conclusion that this is unfeasible: Any - authentication scheme linked to some kind of symbolic identity (in - this case the domain name) needs some kind of infrastructure and - trusted assignment. There are basically two ways to do it: Do it - - - -Hadmut Danisch Experimental [Page 23] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - yourself and trust nobody else, or let someone else do it. There - are methods to do it the former way, e.g. to give someone some kind - of authentication information after a first successful e-mail - exchange, e.g. some kind of cookie or special e-mail address. This - is certainly interesting and powerful, but it does not solve the - problem on a world wide scale and is far to complicated and error - prone for the average user, i. e. 99% of the users. - - The latter method to let someone else do the symbolic name - assignment and create the authentication framework is well known. - It context of public key cryptography, this is called a Public Key - Infrastructure (PKI). On of the best known facts about PKIs is - that, until now, we don't have any covering a significant part of - the Internet. And we won't have any in near future. The complexity - is far too high, it is too expensive, and it involves cooperation - of every single user, which is simply unrealistic and extremely - error prone. So what do we have we can use? All we have is the DNS - and the Whois database. And we have countries who don't allow - cryptography. So the proposal was designed to use DNS without - cryptography. It does not avoid DNS because of its vulnerability, - it asks for a better DNS, but accepts the DNS as it is for the - moment. Currently there are two main threats caused by the DNS - weakness: - - - A spammer/forger could spoof DNS in order to gain false - authorization to send fake e-mails. - - - An attacker could spoof DNS in order to block delivery from - authorized machines, i. e. perform a Denial of Service attack. - - The first one is rather unrealistic, because it would require an - average spammer to poison a significant part of the DNS servers of - its victims. A spammer sending messages to one million receipients - would need to poison at least 1-10% which is 10,000 to 100,000 - receipient's DNS servers. This should be unfeasible in most cases. - - In contrast, the second threat is a severe one. If an attacker - wanted to block messages from one company to another, he just needs - to poison the recipients DNS server with a wrong RMX record in - order to make the recipient's SMTP machine reject all messages. And - this is feasible since the attacker needs to poison only a single - DNS server. But does this make SMTP more vulnerable? No. Because - the attacker can already do even more without RMX. By poisoning the - sender's DNS server with wrong MX records, the attacker can also - block message delivery or even redirect the messages to the - attacker's machine, thus preventing any delivery error messages and - furthermore getting access to the messages. - - - - -Hadmut Danisch Experimental [Page 24] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - As a consequence, e-mail delivery by SMTP requires a better DNS - anyway. The requirements are not significantly expanded by RMX. - -11.1.4. Sneaking RMX attack? - - While writing a test implementation, a certain kind of attack came - into my mind. I'm still not sure, whether this attack is possible - on any DNS server, but I believe it should be mentioned: - - Imagine an unauthorized sender is sending a forged mail (e.g. - spam). At connection time, before querying the RMX record, the - receiving MTA usually performs a PTR query for the IP address of - the sending MTA. If the sender has control over the authoritative - name server for that particular IP address, the sender could give a - normal PTR answer, but could append a wrong RMX, APL, or A record - in the additional section of the query. A subsequent RMX query - could receive wrong DNS data if the DNS server used by the - receiving MTA accepted those forged records. - -11.1.5. Open SMTP relays - - Open SMTP relays (i.e. machines who accept any e-mail message from - anyone and deliver to the world) abused by spammers are a one of - the main problems of spam defense and sender backtracking. In most - cases this problem just vanishes because foreign open relay - machines will not be covered by the RMX records of the forged - sender address. But there are two special cases: - - If the spammer knows about a domain which authorizes this - particular machine, that domain can be used for forgery. But in - this case, the IP address of the relay machine and the RMX records - of the domain track back to the persons responsible. Both can be - demanded to fix the relay or remove the RMX record for this - machine. An open relay is a security flaw like leaving the machine - open for everybody to login and send random mails from inside. Once - the administrative persons refuse to solve the problem, they can be - identified as spammers and held responsible. - - The second special case is when a domain authorizes all IP - addresses by having the network 0.0.0.0/0 in the RMX/APL record. In - this case, open relays don't make things worse. It's up to the - recipient's MTA to reject mails from domains with loose security - policies. - -11.1.6. Unforged Spam - - This proposal does not prevent spam (which is, by the way, not yet - exactly defined), it prevents forgery. Since spam is against law - - - -Hadmut Danisch Experimental [Page 25] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - and violates the recipients rights, spam depends on untracability - of the sender. In practice the sender forges the sender address - (other cases see below). This proposal is designed to detect such - forgeries. - - However, the RMX approach is rendered ineffective, if the sender - doesn't forge. If the sender uses just a normal address of it's own - domain, this is just a plain, normal e-mail, which needs to be let - through. Since it is up to the human's taste whether this is spam - or not, there's no technical way to reliably identify this as spam. - But since the sender domain is known, this domain can be - blacklisted or legal steps can be gone into. - -11.1.7. Reliability of Whois Entries - - Once the RMX infrastructure gets deployed, what's the security - gain? It allows to determine the domain which's DNS zone - authorized the sending machine. What's that good for? There are - some immediate uses of the domain name, e.g. in black- and - whitelisting. But in most cases this is just the starting point of - further investigations, either performed automatically before - message acceptance, or manually after spam has been received and - complainted about. - - The next step after determining the domain is determining the - people responsible for this domain. This can sometimes be achieved - by querying the Whois databases. Unfortunately, many whois entries - are useless because they are incomplete, wrong, obsolete, or in - uncommon languages. Furthermore, there are several formats of - address informations which make it difficult to automatically - extract the address. Sometimes the whois entry identifies the - provider and not the owner of the domain. Whois servers are not - built for high availability and sometimes unreachable. - - Therefore, a mandatory standard is required about the contents and - the format of whois entries, and the availability of the servers. - After receiving the MAIL FROM SMTP command with the sender envelope - address, the receiving MTA could check the RMX record and Whois - entry. If it doesn't point to a real human, the message could be - rejected and an error message like "Ask your provider to fix your - Whois entry" could be issued. Obviously, domain providers must be - held responsible for wrong entries. It might still be acceptable to - allow anonymous domains, i. e. domains which don't point to a - responsible human. But it is the receivers choice to accept e-mails - from such domains or not. - -11.1.8. Hazards for Freedom of Speech - - - - -Hadmut Danisch Experimental [Page 26] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Currently, some governments try to enforce limitations of internet - traffic in order to cut unwanted content providers from the - network. Some of these governments try to hide a whole country - behind firewalls, others try to force Internet providers to poison - DNS servers with wrong A records for web servers, e.g. one county - administration in Germany tries to do so. If message reception - depends on DNS entries, the same governments will try to block not - only HTTP, but SMTP also. - - However, since most MTAs already reject messages from unresolvable - domain names this is not a new threat. - -11.2. General Considerations about spam defense - - After discussing security requirements of the proposal, now the - security advantages of the RMX approach over content based filters - will be explained. Basically, there are three kinds of content - filters: - - - Those who upload the message or some digest to an external - third party and ask "Is this spam"? - - - Those who download a set of patterns and rules from a third - party and apply this set to incoming messages in order to - determine whether it is spam. - - - Those who are independent and don't contact any third party, - but try to learn themselves what is spam and what isn't. - - - The message filters provided by some e-mail service providers are - usually not a kind of their own, but a combination of the first two - kinds. - -11.2.1. Action vs. reaction - - Content filters suffer from a fundamental design problem: They are - late. They need to see some content of the same kind before in - order to learn and to block further distribution. - - This works for viruses and worms, which redistribute. This doesn't - work for spam, since spam is usually not redistributed after the - first delivery. When the filters have learned or downloaded new - pattern sets, it's too late. - - This proposal does not have this problem. - -11.2.2. Content based Denial of Service attacks - - - -Hadmut Danisch Experimental [Page 27] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - All three kinds of content filters, but especially the second and - the third kind are vulnerable to content based Denial of Service - attacks. - - If some kind of third party (e.g. non-democratic government, - intellectual property warriors, religious groups, military, secret - services, patriots, public relation agents, etc.) wants certain - contents not to be distributed, they could either poison the - pattern/rule databases or feed wrong sets to particular receivers. - - Such pattern/rule sets are the perfect tool for censoring e-mail - traffic and denial of service attacks by governments and other - parties, and a similar threat are virus filters. E. g. the content - industry could demand to teach all virus and spam filters to delete - all e-mails containing the URL of an MP3 web server outside the - legislations. Software manufacturers could try to block all e-mails - containing software license keys, thus trying to make unallowed - distribution more difficult. Governments could try to block - distribution of unwanted informations. - - This proposal does not have this problem. - - -12. Privacy Considerations - - (It was proposed on the 56th IETF meeting to have a privacy section - in drafts and RFCs.) - -12.1. Draft specific considerations - -12.1.1. No content leaking - - Since the RMX approach doesn't touch the contents of a message in - any way, there is obviously no way of leaking out any information - about the content of the message. RMX is based solely on the - envelope recipient address. However, methods to fix problems not - covered by RMX might allow content leaking, e.g. if the acceptance - of a message with an empty sender address requires the reference to - the message id of an e-mail recently sent, this allows an attacker - to verify whether a certain message was delivered from there. - -12.1.2. Message reception and sender domain - - Message delivery triggers RMX and APL requests by the recipient. - Thus, the admin of the DNS server or an eavesdropper could learn - that the given machine has just received a message with a sender - from this address, even if the SMTP traffic itself had been - encrypted. - - - -Hadmut Danisch Experimental [Page 28] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - However, most of today's MTAs do query the MX and A records of the - domain after the MAIL FROM command, so this is not a real new - threat. - -12.1.3. Network structure - - Since RMX and its associated APL records provide a complete list of - all IP addresses of hosts authorized to send messages from this - address, they do reveal informations about the network structure - and maybe the lifestyle of the domain owner, since a growing number - of domains are owned by single persons or families. E.g. the RMX - records could reveal where someone has his job or spends his time - at weekends. - - If such informations are to be kept secret, it is the user's job to - not sent e-mails from there and to relay them from non-compromising - IP addresses. - -12.1.4. Owner information distribution - - As described above, RMX depends partly on the reliability of the - whois database entries. It does not make anonymous domains - impossible, but it requires to keep the database entries "true", i. - e. if a whois entry does not contain informations about the - responsible person, this must be unambigously labeled as anonymous. - It must not contain fake names and addresses to pretend a non- - existing person. However, since most Internet users on the world - feel extremely annoyed by spam, they will urge their MTA admin to - reject messages from anonymous domains. The domain owner will have - the choice to either remain anonymous but be not able to send e- - mail to everyone in the world, or to be able but to reveal his - identity to everyone on the world. - - It would be possible to provide whois-like services only to - recipients of recent messages, but this would make things too - complicated to be commonly adopted. - -12.2. General Considerations about spam defense - -12.2.1. Content leaking of content filters - - As described above in the Security chapter, there are spam filters - which inherently allow leakage of the message body. Those filters - upload either the message body, or in most cases just some kind of - checksum to a third party, which replies whether this is to be seen - as spam or not. The idea is to keep a databases of all digests of - all messages. If a message is sent more often than some threshold, - it is to be considered as a mass mail and therefore tagged as spam. - - - -Hadmut Danisch Experimental [Page 29] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - While the digest itself does not reveal the content of the message, - it perfectly reveals where a particular message has been delivered - to. If a government finds just a single unwanted message, if a - software manufacturer finds a single message with a stolen product - license key, if someone finds a message with unpatriotic content, - it takes just a single database lookup to get a list of all people - who received this particular message. Content filters with digest - upload are the perfect "Big Brother". - -12.2.2. Black- and Whitelists - - Some proposals against spam are based on a central database of - white- or blacklisted IP addresses, Sender names, Message IDs or - whatever. Again, there is a central database which learns who has - received which e-mail or from which sender with every query. This - allows tracking relations between persons, which is also a breach - of privacy. - - - -13. Deployment Considerations - -13.1. Compatibility - -13.1.1. Compatibility with old mail receivers - - Since the suggested extension doesn't change the SMTP protocol at - all, it is fully compatible with old mail receivers. They simply - don't ask for the RMX records and don't perform the check. - -13.1.2. Compatibility with old mail senders - - Since the SMTP protocol is unchanged and the SMTP sender is not - involved in the check, the method is fully compatible with old mail - senders. - -13.1.3. Compatibility with old DNS clients - - Since the RMX is a new RR, the existing DNS protocol and zone - informations remain completely untouched. - - If RMX is provided as a TXT record instead, it must be ensured that - no other software is misinterpreting this entry. - -13.1.4. Compatibility with old DNS servers - - Full compatibility: If the server does not support RMX records, RMX - in TXT records can be used. - - - -Hadmut Danisch Experimental [Page 30] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -13.2. Enforcement policy - - Obviously, for reasons of backward compatibility and smooth - introduction of this scheme, RMX records can't be required - immediately. Domains without RMX records must temporarily be - treated the same way as they are treated right now, i.e. e-mail - must be accepted from anywhere. But once the scheme becomes - sufficiently widespread, mail relays can start to refuse e-mails - with sender addresses from domains without RMX records, thus - forcing the owner of the domain to include a statement of - authorization into the domain's zone table. Domain owners will - still be free to have an RMX record with a network and mask - 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere. - On the other hand, mail receivers will be free to refuse mails from - domains without RMX records or RMX records which are too loose. - Advanced MTAs might have a configuration option to set the maximum - number of IP addresses authorized to use a domain. E-mails from a - domain, which's RMX records exceed this limit, would be rejected. - For example, a relay could reject e-mails from domains which - authorize more than 8 IP addresses. That allows to accept e-mails - only from domains with a reasonable security policy. - - - -14. General considerations about fighting spam - - Is there a concise technical solution against spam? Yes. - - Will it be deployed? Certainly not. - - Why not? Because of the strong non-technical interests of several - parties against a solution to the problem, as described below. - Since these are non-technical reasons, they might be beyond the - scope of such a draft. But since they are the main problems that - prevent fighting spam, it is unavoidable to address them. This - chapter exists temporarily only and should support the discussion - of solutions. It is not supposed to be included in a later RFC. - -14.1. The economical problem - - As has been recently illustrated in the initial session of the - IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, - sending spam is a business with significant revenues. - - But a much bigger business is selling Anti-Spam software. This is a - billion dollar market, and it is rapidly growing. Any simple and - effective solution against spam would defeat revenues and drive - several companies into bankrupt, would make consultants jobless. - - - -Hadmut Danisch Experimental [Page 31] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Therefore, spam is essential for the Anti-Spam business. If there - is no spam, then no Anti-Spam software can be sold, similar to the - Anti-Virus business. There are extremely strong efforts to keep - this market growing. Viruses, Worms, and now spam are just perfect - to keep this market alive: It is not sufficient to just buy a - software. Databases need to be updated continuously, thus making - the cash flow continuously. Have a single, simple, and permanent - solution to the problem and - boom - this billion dollar market is - dead. - - That's one of the reasons why people are expected to live with - spam. They have to live with it to make them buy Anti-Spam - software. Content filters are perfect products to keep this market - alive. - -14.2. The POP problem - - Another problem is the history of mail delivery. Once upon a time, - there used to be very few SMTP relays which handled the e-mail - traffic of all the world, and everybody was happy with that. Then - odd things like Personal Computers, which are sometimes switched - off, portable computers, dynamicly assigned IP addresses, IP access - from hotel rooms, etc. was invented, and people became unhappy, - because SMTP does not support delivery to such machines. To make - them happy again, the Post Office Protocol[4] was invented, which - turned the last part of message delivery from SMTP's push style - into a pull style, thus making virtually every computer on the - world with any random IP address a potential receiver of mails for - random domains. Unfortunately, only receiving e-mail was covered, - but sending e-mail was left to SMTP. - - The result is that today we have only very few SMTP relays pointed - to by MX records, but an extreme number of hosts sending e-mail - with SMTP from any IP address with sender addresses from any - domain. Mail delivery has become very asymmetric. Insecurity, - especially forgeability, has become an essential part of mail - transport. - - That problem could easily be fixed: Use protocols which allow - uploading of messages to be delivered. If a host doesn't receive - messages by SMTP, it shouldn't deliver by SMTP. Mail delivery - should go the same way back that incoming mail went in. This is - not a limitation to those people on the road who plug their - portable computer in any hotel room's phone plug and use any - provider. If there is a POP server granting download access from - anywhere, then the same server should be ready to accept uploading - of outgoing messages. - - - - -Hadmut Danisch Experimental [Page 32] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - But as I saw from the comments on the first version of this draft, - people religiously insist on sending e-mail with their domain from - any computer with any IP address in the world, e.g. when visiting a - friend using her computer. It appears to be impossible to convince - people that stopping mail forgery requires every one of them to - give up forging. - -14.3. The network structure problem - - A subsequent problem is that many organisations failed to implement - a proper mail delivery structure and heavily based their network on - this asymmetry. I received harsh comments from Universities who - were unable to give their network a good structure. While they do - have a central mail relay for incoming mail to the universities - domain, they developed a structure where every member of the - University randomly sends e-mails with that University's domain as - a sender address from home or everywhere in the world with any - dynamically assigned IP address from any provider. So this domain - is to be used from every possible IP address on earth, and they are - unable to operate any authentication scheme. Furthermore, they were - unable to understand that such a policy heavily supports spam and - that they have to expect that people don't accept such e-mails - anymore once they become blacklisted. - - As long as organisations insist on having such policies, spammers - will have a perfect playground. - -14.4. The mentality problem - - Another problem is the mentality of many internet users of certain - countries. I received harsh comments from people who strongly - insisted on the freedom to send any e-mail with any sender address - from anywhere, and who heavily refused any kind of authentication - step or any limitation, because they claimed that this would - infringe their constitutional "Freedom of speech". They are - undeviatingly convinced that "Freedom of speech" guarantees their - right to talk to everybody with any sender address, and that is has - to be kept the recipient's own problem to sort out what he doesn't - want to read - on the recipient's expense. - - It requires a clear statement that the constitutional "Freedom of - Speech" does not cover molesting people with unsolicited e-mail - with forged sender address. - -14.5. The identity problem - - How does one fight against mail forgery? With authentication. What - is authentication? In simple words: Making sure that the sender's - - - -Hadmut Danisch Experimental [Page 33] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - real identity meets the recipients idea of who is the sender, based - on the sender address which came with the message. - - What is identity? It is the main problem. Several countries have - different ideas of "identity", which turn out to be somehow - incompatible. In some countries people have identity cards and - never change their name and birthday. Identities are created by - human birth, not by identity changes. Other countries do not have - such a tight idea about identity. People's temporary identity is - based on nothing more than a driving license and a social security - number. With this background, it is virtually impossible to create - a trustworthy PKI covering all Internet users. I learned that it is - extremely difficult to convince some people to give up random e- - mail sending. - -14.6. The multi-legislation problem - - Many proposals about fighting spam are feasible under certain - legislations only, and are inacceptable under some of the - legislations. But a world wide applicable method is required. - That's why the approach to ask everone on the world to sign - messages with cryptographic keys is not feasible. - - -Implementation and further Information - - Further informations and a test implementation are available at - - http://www.danisch.de/work/security/antispam.html - http://www.danisch.de/software/rmx/ - - - Additional informations and a technology overview are also - available at - - http://www.mikerubel.org/computers/rmx_records/ - - -References - - - -1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- - els," RFC 2119 (March 1997). - -2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001). - - - - - -Hadmut Danisch Experimental [Page 34] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," - RFC 1035 (November 1987). - -4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939 - (May 1996). - - -Draft History - - 00 Dec 2002 - 01 Apr 2003 - 02 Jun 2003 - 03 Oct 2003 - -Author's Address - - Hadmut Danisch - - Tennesseeallee 58 - 76149 Karlsruhe - Germany - - Phone: ++49-721-843004 or ++49-351-4850477 - E-Mail: rfc@danisch.de - -Comments - - Please send comments to rfc@danisch.de. - -Expiry - - This drafts expires on Apr 1, 2004. - - - - - - - - - - - - - - - - - - - -Hadmut Danisch Experimental [Page 35] - diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt deleted file mode 100644 index 7b5e8cc4..00000000 --- a/doc/draft/draft-dnsext-opcode-discover-02.txt +++ /dev/null @@ -1,241 +0,0 @@ - -IETF DNSEXT WG Bill Manning -draft-dnsext-opcode-discover-02.txt ep.net - Paul Vixie - ISC - 13 Oct 2003 - - - The DISCOVER opcode - -This document is an Internet-Draft and is subject to all provisions of -Section 10 of RFC2026. - -Comments may be submitted to the group mailing list at "mdns@zocalo.net" -or the authors. - -Distribution of this memo is unlimited. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months and -may be updated, replaced, or obsoleted by other documents at any time. It -is inappropriate to use Internet-Drafts as reference material or to cite -them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in RFC 2119 - -0. Abstract: - - The QUERY opcode in the DNS is designed for unicast. With the - development of multicast capabilities in the DNS, it is desireable - to have a more robust opcode for server interactions since a single - request may generate replies from multiple responders. So DISCOVER - is defined to deal with replies from multiple responders. - - As such, this document extends the core DNS specifications to allow - clients to have a method for coping with replies from multiple - responders. Use of this new opcode may facilitate DNS operations in - modern networking topologies. A prototype of the DISCOVER opcode - was developed during the TBDS project (1999-2000), funded under DARPA - grant F30602-99-1-0523. - -1. Introduction: - - This document describes an experimental extension to the DNS to receive - multiple responses which is the likely result when using DNS that has - enabled multicast queries. This approach was developed as part of the - TBDS research project, funded under DARPA grant F30602-99-1-0523. The - full processing rules used by TBDS are documented here for possible - incorporation in a future revision of the DNS specification." - -2. Method: - - DISCOVER works like QUERY except: - - 1. it can be sent to a broadcast or multicast destination. QUERY - isn't defined for non-unicast, and arguably shouldn't be. - - 2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA> - tuples. TBDS tried to augment this structure as follows: - <QNAME=service,QTYPE=SRV>. While this worked for our purposes in - TBDS, it is cleaner to place the SRV question in a separate pass. - - 3. if QDCOUNT equals 0 then only servers willing to do recursion should - answer. Other servers must silently discard the DISCOVER request. - - 4. if QDCOUNT is not equal to 0 then only servers who are authoritative - for the zones named by some QNAME should answer. - - 5. responses may echo the request's Question section or leave it blank, - just like QUERY. - - 6. responses have standard Answer, Authority, and Additional sections. - e.g. the response is the same as that to a QUERY. It is desireable - that zero content answers not be sent to avoid badly formed or - unfulfilled requests. Responses should be sent to the unicast - address of the requester and the source address should reflect - the unicast address of the responder. - - Example usage for gethostby{name,addr}-style requestors: - - Compute the zone name of the enclosing in-addr.arpa, ip6.int, or - ip6.arpa domain. - - DISCOVER whether anyone in-scope is authoritative for this zone. - - If so, query these authoritative servers for local - in-addr/ip6 names. - - If not, DISCOVER whether there are recursive servers available. - - If so, query these recursive servers for local - in-addr/ip6 names. - - So, a node will issue a multicast request with the DISCOVER opcode at - some particular multicast scope. Then determine, from the replies, - whether there are any DNS servers which are authoritative (or support - recursion) for the zone. Replies to DISCOVER requests MUST set the - Recursion Available (RA) flag in the DNS message header. - - It is important to recognize that a requester must be prepared to - receive multiple replies from multiple responders. We expect that - there will be a single response per responder. - - Once one learns a host's FQDN by the above means, repeat the process - for discovering the closest enclosing authoritative server of such - local name. - - Cache all NS and A data learned in this process, respecting TTL's. - - TBDS usage for SRV requestors: - - Do the gethostbyaddr() and gethostbyname() on one's own link-local - address, using the above process. - - Assume that the closest enclosing zone for which an authority server - answers an in-scope DISCOVER packet is "this host's parent domain". - - Compute the SRV name as _service._transport.*.parentdomain. - - This is a change to the definition as defined in RFC 1034. - A wildcard label ("*") in the QNAME used in a DNS message with - opcode DISCOVER SHOULD be evaluated with special rules. The - wildcard matches any label for which the DNS server data is - authoritative. For example 'x.*.example.com.' would match - 'x.y.example.com.' and 'x.yy.example.com.' provided that the - server was authoritative for 'example.com.' In this particular - case, we suggest the follwing considerations be made: - - getservbyname() can be satisfied by issuing a request with - this computed SRV name. This structure can be - populated by values returned from a request as follows: - - s_name The name of the service, "_service" without the - preceding underscore. - s_aliases The names returned in the SRV RRs in replies - to the query. - s_port The port number in the SRV RRs replies to the - query. If these port numbers disagree - one - of the port numbers is chosen, and only those - names which correspond are returned. - s_proto The transport protocol from named by the - "_transport" label, without the preceding - underscore. - - Send SRV query for this name to discovered local authoritative servers. - - Usage for disconnected networks with no authoritative servers: - - Hosts should run a "stub server" which acts as though its FQDN is a - zone name. Computed SOA gives the host's FQDN as MNAME, "." as the - ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE - and the other timers. Compute NS as the host's FQDN. Compute the - glue as the host's link-local address. Or Hosts may run a - "DNS stub server" which acts as though its FQDN is a zone name. The - rules governing the behavior of this stub server are given elsewhere - [1] [2]. - - Such stub servers should answer DISCOVER packets for its zone, and - will be found by the iterative "discover closest enclosing authority - server" by DISCOVER clients, either in the gethostbyname() or SRV - cases described above. Note that stub servers only answer with - zone names which exactly match QNAME's, not with zone names which - are owned by QNAME's. - - The main deviation from the DNS[3][4] model is that a host (like, say, a - printer offering LPD services) has a DNS server which answers authoritatively - for something which hasn't been delegated to it. However, the only way that - such DNS servers can be discovered is with a new opcode, DISCOVER, which - is explicitly defined to discover undelegated zones for tightly scoped - purposes. Therefore this isn't officially a violation of DNS's coherency - principles. In some cases a responder to DISCOVER may not be traditional - DNS software, it could be special purpose software. - -3. IANA Considerations - - As a new opcode, the IANA will need to assign a numeric value - for the memnonic. The last OPCODE assigned was "5", for UPDATE. - Test implementations have used OPCODE "6". - -4. Security Considerations - - No new security considerations are known to be introduced with any new - opcode, however using multicast for service discovery has the potential - for denial of service, primarly from flooding attacks. It may also be - possible to enable deliberate misconfiguration of clients simply by - running a malicious DNS resolver that claims to be authoritative for - things that it is not. One possible way to mitigate this effect is by - use of credentials, such as CERT resource records within an RR set. - The TBDS project took this approach. - -5. Attribution: - - This material was generated in discussions on the mdns mailing list -hosted by Zocalo in March 2000. Updated by discussion in September/October -2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, -Erik Guttman, Bill Manning and Paul Vixie were active contributors. - -6. Author's Address - - Bill Manning - PO 12317 - Marina del Rey, CA. 90295 - +1.310.322.8102 - bmanning@karoshi.com - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 7001 - <vixie@isc.org> - -7. References - -Informational References: - -[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS", - draft-ietf-dnsext-mdns-00.txt, November 2000. Expired - -[2] Woodcock, B., Manning, B., "Multicast Domain Name Service", - draft-manning-dnsext-mdns-00.txt, August 2000. Expired. - -Normative References: -[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", - RFC 1034, November 1987. -[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", - RFC 1035, November 1987 - - ----------------------------EOL----------------------- - diff --git a/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt b/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt deleted file mode 100644 index 3e08247f..00000000 --- a/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt +++ /dev/null @@ -1,370 +0,0 @@ -DNS Extensions working group V.Dolmatov, Ed. -Internet-Draft Cryptocom Ltd. -Intended status: Standards Track April 8, 2009 -Expires: December 31, 2009 - - - Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records - for DNSSEC - draft-dolmatov-dnsext-dnssec-gost-00 - -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 31 December 2009. - -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). - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . - 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . - 2.1. Using a public key with existing cryptographic libraries. . - 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . - 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . - 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . - 5. NSEC3 Resource Records . . . . . . . . . . . . . . . . . . . . - 6. Deployment Considerations . . . . . . . . . . . . . . . . . . . - 6.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . - 6.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . - 6.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . - 7. Implementation Considerations . . . . . . . . . . . . . . . . . - 7.1. Support for GOST signatures . . . . . . . . . . . . . . . . - 7.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . - 7.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . . - 7.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . . - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . - 10.1. Normative References . . . . . . . . . . . . . . . . . . . - 10.2. Informative References . . . . . . . . . . . . . . . . . . - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . - - -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 GOST R 34.10-2001 - (signatire algorithm) and GOST R 34.11-94 (hash algorithm) 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]. - - -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 public key parameters are those identified by - id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357]. - The digest parameters for signature are those identified by - id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357]. - - 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 64 octets, where the - first 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. - -2.1. Using a public key with existing cryptographic libraries - - Existing GOST-aware cryptographic libraries at time of this document - writing are capable to read GOST public keys via 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, prepend - a key data 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 - - The following DNSKEY RR stores a DNS zone key for example.com - - example.com. 86400 IN DNSKEY 256 3 {TBA1} ( RamuUwTG1r4RUqsgXu/xF6B+Y - tJLzZEykiZ4C2Fa1gV1pI/8GA - el2Wm69Cz5h1T9eYAQKFAGwzW - m4Lke0E26aw== ) - -3. RRSIG Resource Records - - The value of the signature field in the RRSIG RR follows the 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." - -4. DS Resource Records - - GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest type - {TBA2}. The wire format of a digest value is compatible with RFC 4490 - [RFC4490]. 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]. - -5. NSEC3 Resource Records - - GOST R 34.11-94 digest algorithm is denoted in NSEC3 RR by the digest type - {TBA2}. The wire format of a digest value is compatible with RFC 4490 - [RFC4490]. 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]. - -6. Deployment Considerations - -6.1. Key Sizes - - According to RFC4357 [RFC4357] key size of GOST public keys MUST - be 512 bits. - -6.2. Signature Sizes - - According to GOST signature algorithm [GOST3410] size of GOST signature - is 512 bit. - -6.3. Digest Sizes - - According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256 bit. - -7. Implementation Considerations - -7.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. - -7.2. Support for NSEC3 Denial of Existence - - RFC5155 [RFC5155] defines new algorithm identifiers for existing - signing algorithms, to indicate that zones signed with these - algorithm identifiers use NSEC3 instead of NSEC records to provide - denial of existence. That mechanism was chosen to protect - implementations predating RFC5155 from encountering resource records - they could not know about. This document does not define such - algorithm aliases, and support for NSEC3 denial of existence is - implicitly signaled with support for one of the algorithms defined in - this document. - -7.2.1. NSEC3 in Authoritative servers - - An authoritative server that does not implement NSEC3 MAY still serve - zones that use GOST with NSEC denial of existence. - -7.2.2. NSEC3 in Validators - - A DNSSEC validator that implements GOST MUST be able to handle - both NSEC and NSEC3 [RFC5155] negative answers. If this is not the - case, the validator MUST treat a zone signed with GOST - as signed with an unknown algorithm, and thus as insecure. - - -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 - try 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, 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. - - [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. - -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 - - Expires December 31, 2009 [Page ] - - diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt deleted file mode 100644 index 224e7ad1..00000000 --- a/doc/draft/draft-durand-dnsop-dynreverse-00.txt +++ /dev/null @@ -1,240 +0,0 @@ -Internet Engineering Task Force Alain Durand -INTERNET-DRAFT SUN Microsystems -Feb 21, 2003 -Expires Aug 2, 2003 - - - - Dynamic reverse DNS for IPv6 - <draft-durand-dnsop-dynreverse-00.txt> - - - -Status of this memo - - - This memo provides information to the Internet community. It does - not specify an Internet standard of any kind. This memo is in full - conformance with all provisions of Section 10 of RFC2026 [RFC2026]. - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Abstract - - This document describes a method to dynamically generate PTR records - and corresponding A or AAAA records when the reverse path DNS tree is - not populated. - - A special domain dynrev.arpa. is reserved for that purpose. - - -1. Introduction - - In IPv4, the reverse path tree of the DNS under in-addr.arpa. - although not perfectly maintained, is still mostly usable and its - existence is important for a number of applications that relies on - its existence and decent status. Some applications performs some - (very) weak security checks based on it. Mail relays relies on it for - some anti-spams checks an some FTP server will not let you in unless - your IP address resolve properly with a PTR record. - - IPv6 addresses being much longer (and cumbersome) than IPv4 - addresses, it is to fear that the reverse path tree under ip6.arpa. - would not be as well maintained. Also, tools like 6to4, Isatap and - others have made creative use of the 128 bits of an IPv6 address to - automatically embed an IPv4 address to enable seamless connection to - the IPv6 Internet. However, no provision has been made to make sure - the reverse path tree gets automatically updated as well for those - new IPv6 addresses. One step furter, RFC3041 describes a mechanism - to basically use random bits in the bottom part of an IPv6 address to - preserver anonymity. If those addresses are to resolve in the reverse - path tree, it obviously has to be with anonymous data as well. - Another point to note is that home customer ISPs in IPv4 have a - current practice to pre-populate the reverse path tree with names - automatically derived from the IP addresses. This practice is no - longer possible in IPv6, where IP address allocation is not dense as - it is the case in IPv4. The mere size of typical customer allocation - (2^48 according to the recommendation of RFC3177) makes it - impossible. - - Applications that check the existence of PTR records usually follow - this by checking if the name pointed by the PTR resolve in a A (or - AAAA for IPv6) that match the original IP address. Thus the forward - path tree must also include the corresponding data. - - One simple approach of this problem is to simply declare the usage of - the reverse path DNS as described above obsolete. The author believe - this is too strong an approach for now. - - Similarly, a completely different approach would be to deprecate the - usage of DNS for the reverse tree altogether and replace it by - something inspired from ICMP name-info messages. The author believes - that this approached is an important departure from the current - practise and thus not very realistic. Also, there are some concerns - about the the security implications of this method as any node could - easily impersonate any name. This approach would fundamentally change - the underlying assumption of "I trust what has been put in the DNS by - the local administrators" to "I trust what has been configured on - each machine I query directly". - - - -2. Dynamic record generation - - If static pre-population of the tree is not possible anymore and data - still need to be returned to applications using getnameinfo(), the - alternative is dynamic record generation. This can be done is two - places: in the DNS servers responsible for the allocated space (/64 - or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the - sub resolver library or the recursive DNS server). - - 2.1. On the resolver side. - - The resolver, either in the recursive DNS server or in the stub - library could theoretically generate this data. - - In case DNSsec is in place, the recursive DNS server would have to - pretend these records are authentic. - - If the synthesis is done in the stub-resolver library, no record - needs to be actually generated, only the right information needs to - be passed to getnameinfo() and getaddrinfo(). If the synthesis is - done in the recursive DNS server, no modification is required to - existing stub resolvers. - - -2.2. On the server side. - - PTR records could be generated automatically by the server - responsible for the reverse path tree of an IPv6 prefix (a /64 or /48 - prefixes or basically anything in between) when static data is not - available. - - There could be impact on DNSsec as the zone or some parts of the zone - may need to be resigned each time a DNS query is made for an - unpopulated address. This can be seen as a DOS attack on a DNSsec - zone, so server side synthesis is not recommended if DNSsec is - deployed. - - - -3. Synthesis - - The algorithm is simple: Do the normal queries. If the query returns - No such domain, replace this answer by the synthetized one if - possible. - -3.1. PTR synthesis - - The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa. - where [X] is any valid DNS name. - - The fact that the synthetized PTR points to the dynrev.arpa. domain - is an indication to the applications that this record has been - dynamically generated. - - -3.2. A synthesis - - If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A - record for the string [X].dynrev.arpa. which value is d.c.b.a. with - a,b,c & d being integer [0..255] - - -3.3. AAAA synthesis - - If [X] is in the form - a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in- - addr.arpa, one can synthetized a AAAA record for the string - [X].dynrev.arpa. which value is - FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with - a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits. - - -3.4. Server side synthesis - - If synthesis is done on the server side, PTR could be set not to use - the dynrev.arpa domain but the local domain name instead. It culd be - for instance dynrev.mydomain.com. - - Note also that server side synthesis is not incompatible with - resolver side synthesis. - - - -4. IANA considerations - - The dynrev.arpa. domain is reserved for the purpose of this document. - - - -5. Security considerations - - Section 2. discusses the the interactions with DNSsec. - - - -6. Authors addresses - - Alain Durand - SUN Microsystems, Inc - 17, Network Circle - UMPK17-202 - Menlo Park, CA 94025 - USA - Mail: Alain.Durand@sun.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt deleted file mode 100644 index fa41e763..00000000 --- a/doc/draft/draft-ietf-dnsext-2929bis-01.txt +++ /dev/null @@ -1,928 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories -Expires: February 2006 August 2005 - - - - Domain Name System (DNS) IANA Considerations - ------ ---- ------ ----- ---- -------------- - <draft-ietf-dnsext-2929bis-01.txt> - - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this draft is unlimited. It is intended to become - the new BCP 42 obsoleting RFC 2929. Comments should be sent to the - DNS Working Group mailing list <namedroppers@ops.ietf.org>. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than a "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - - -Abstract - - Internet Assigned Number Authority (IANA) parameter assignment - considerations are given for the allocation of Domain Name System - (DNS) classes, RR types, operation codes, error codes, RR header - bits, and AFSDB subtypes. - - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. DNS Query/Response Headers..............................3 - 2.1 One Spare Bit?.........................................4 - 2.2 Opcode Assignment......................................4 - 2.3 RCODE Assignment.......................................5 - 3. DNS Resource Records....................................6 - 3.1 RR TYPE IANA Considerations............................7 - 3.1.1 DNS TYPE Allocation Policy...........................8 - 3.1.2 Special Note on the OPT RR...........................9 - 3.1.3 The AFSDB RR Subtype Field...........................9 - 3.2 RR CLASS IANA Considerations...........................9 - 3.3 RR NAME Considerations................................11 - 4. Security Considerations................................11 - - Appendix: Changes from RFC 2929...........................12 - - Copyright and Disclaimer..................................13 - Normative References......................................13 - Informative References....................................14 - - Authors Addresses.........................................16 - Expiration and File Name..................................16 - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -1. Introduction - - The Domain Name System (DNS) provides replicated distributed secure - hierarchical databases which hierarchically store "resource records" - (RRs) under domain names. DNS data is structured into CLASSes and - zones which can be independently maintained. See [RFC 1034, 1035, - 2136, 2181, 4033] familiarity with which is assumed. - - This document provides, either directly or by reference, general IANA - parameter assignment considerations applying across DNS query and - response headers and all RRs. There may be additional IANA - considerations that apply to only a particular RR type or - query/response opcode. See the specific RFC defining that RR type or - query/response opcode for such considerations if they have been - defined, except for AFSDB RR considerations [RFC 1183] which are - included herein. This RFC obsoletes [RFC 2929]. - - IANA currently maintains a web page of DNS parameters. See - <http://www.iana.org/numbers.htm>. - - "IETF Standards Action", "IETF Consensus", "Specification Required", - and "Private Use" are as defined in [RFC 2434]. - - - -2. DNS Query/Response Headers - - The header for DNS queries and responses contains field/bits in the - following diagram taken from [RFC 2136, 2929]: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT/ZOCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT/PRCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT/UPCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The ID field identifies the query and is echoed in the response so - they can be matched. - - The QR bit indicates whether the header is for a query or a response. - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful - only in queries or only in responses, depending on the bit. However, - many DNS implementations copy the query header as the initial value - of the response header without clearing bits. Thus any attempt to - use a "query" bit with a different meaning in a response or to define - a query meaning for a "response" bit is dangerous given existing - implementation. Such meanings may only be assigned by an IETF - Standards Action. - - The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), - authority count (NSCOUNT), and additional information count (ARCOUNT) - express the number of records in each section for all opcodes except - Update. These fields have the same structure and data type for - Update but are instead the counts for the zone (ZOCOUNT), - prerequisite (PRCOUNT), update (UPCOUNT), and additional information - (ARCOUNT) sections. - - - -2.1 One Spare Bit? - - There have been ancient DNS implementations for which the Z bit being - on in a query meant that only a response from the primary server for - a zone is acceptable. It is believed that current DNS - implementations ignore this bit. - - Assigning a meaning to the Z bit requires an IETF Standards Action. - - - -2.2 Opcode Assignment - - Currently DNS OpCodes are assigned as follows: - - OpCode Name Reference - - 0 Query [RFC 1035] - 1 IQuery (Inverse Query, Obsolete) [RFC 3425] - 2 Status [RFC 1035] - 3 available for assignment - 4 Notify [RFC 1996] - 5 Update [RFC 2136] - 6-15 available for assignment - - New OpCode assignments require an IETF Standards Action as modified - by [RFC 4020]. - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -2.3 RCODE Assignment - - It would appear from the DNS header above that only four bits of - RCODE, or response/error code are available. However, RCODEs can - appear not only at the top level of a DNS response but also inside - OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. - The OPT RR provides an eight bit extension resulting in a 12 bit - RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. - - Error codes appearing in the DNS header and in these three RR types - all refer to the same error code space with the single exception of - error code 16 which has a different meaning in the OPT RR from its - meaning in other contexts. See table below. - - RCODE Name Description Reference - Decimal - Hexadecimal - 0 NoError No Error [RFC 1035] - 1 FormErr Format Error [RFC 1035] - 2 ServFail Server Failure [RFC 1035] - 3 NXDomain Non-Existent Domain [RFC 1035] - 4 NotImp Not Implemented [RFC 1035] - 5 Refused Query Refused [RFC 1035] - 6 YXDomain Name Exists when it should not [RFC 2136] - 7 YXRRSet RR Set Exists when it should not [RFC 2136] - 8 NXRRSet RR Set that should exist does not [RFC 2136] - 9 NotAuth Server Not Authoritative for zone [RFC 2136] - 10 NotZone Name not contained in zone [RFC 2136] - 11 - 15 Available for assignment - 16 BADVERS Bad OPT Version [RFC 2671] - 16 BADSIG TSIG Signature Failure [RFC 2845] - 17 BADKEY Key not recognized [RFC 2845] - 18 BADTIME Signature out of time window [RFC 2845] - 19 BADMODE Bad TKEY Mode [RPC 2930] - 20 BADNAME Duplicate key name [RPF 2930] - 21 BADALG Algorithm not supported [RPF 2930] - - 22 - 3,840 - 0x0016 - 0x0F00 Available for assignment - - 3,841 - 4,095 - 0x0F01 - 0x0FFF Private Use - - 4,096 - 65,534 - 0x1000 - 0xFFFE Available for assignment - - 65,535 - 0xFFFF Reserved, can only be allocated by an IETF - Standards Action. - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - Since it is important that RCODEs be understood for interoperability, - assignment of new RCODE listed above as "available for assignment" - requires an IETF Consensus. - - - -3. DNS Resource Records - - All RRs have the same top level format shown in the figure below - taken from [RFC 1035]: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / / - / NAME / - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TYPE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | CLASS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TTL | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RDLENGTH | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| - / RDATA / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - NAME is an owner name, i.e., the name of the node to which this - resource record pertains. NAMEs are specific to a CLASS as described - in section 3.2. NAMEs consist of an ordered sequence of one or more - labels each of which has a label type [RFC 1035, 2671]. - - TYPE is a two octet unsigned integer containing one of the RR TYPE - codes. See section 3.1. - - CLASS is a two octet unsigned integer containing one of the RR CLASS - codes. See section 3.2. - - TTL is a four octet (32 bit) bit unsigned integer that specifies the - number of seconds that the resource record may be cached before the - source of the information should again be consulted. Zero is - interpreted to mean that the RR can only be used for the transaction - in progress. - - RDLENGTH is an unsigned 16 bit integer that specifies the length in - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - octets of the RDATA field. - - RDATA is a variable length string of octets that constitutes the - resource. The format of this information varies according to the TYPE - and in some cases the CLASS of the resource record. - - - -3.1 RR TYPE IANA Considerations - - There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, - and MetaTYPEs. - - Data TYPEs are the primary means of storing data. QTYPES can only be - used in queries. Meta-TYPEs designate transient data associated with - an particular DNS message and in some cases can also be used in - queries. Thus far, data TYPEs have been assigned from 1 upwards plus - the block from 100 through 103 while Q and Meta Types have been - assigned from 255 downwards except for the OPT Meta-RR which is - assigned TYPE 41. There have been DNS implementations which made - caching decisions based on the top bit of the bottom byte of the RR - TYPE. - - There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG - [RFC 2845], and TKEY [RFC 2930]. - - There are currently five QTYPEs assigned: * (all), MAILA, MAILB, - AXFR, and IXFR. - - Considerations for the allocation of new RR TYPEs are as follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC - 2535] and in other circumstances and must never be allocated - for ordinary use. - - 1 - 127 - 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data - TYPEs by the DNS TYPE Allocation Policy as specified in - section 3.1.1. - - 128 - 255 - 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and - Meta TYPEs by the DNS TYPE Allocation Policy as specified in - section 3.1.1. - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - 256 - 32,767 - 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS - TYPE Allocation Policy as specified in section 3.1.1. - - 32,768 - 65,279 - 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. - - 65,280 - 65534 - 0xFF00 - 0xFFFE - Private Use. - - 65,535 - 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. - - - -3.1.1 DNS TYPE Allocation Policy - - Parameter values specified above as assigned based on DNS TYPE - Allocation Policy. That is, Expert Review with the additional - requirement that the review be based on a complete template as - specified below which has been posted for three weeks to the - namedroppers@ops.ietf.org mailing list. - - Partial or draft templates may be posted with the intend of - soliciting feedback. - - - DNS RR TYPE PARAMETER ALLOCATION TEMPLATE - - Date: - - Name and email of originator: - - Pointer to internet-draft or other document giving a detailed - description of the protocol use of the new RR Type: - - What need is the new RR TYPE intended to fix? - - What existing RR TYPE(s) come closest to filling that need and why are - they unsatisfactory? - - Does the proposed RR TYPR require special handling within the DNS - different from an Unknown RR TYPE? - - Comments: - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -3.1.2 Special Note on the OPT RR - - The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its - primary purpose is to extend the effective field size of various DNS - fields including RCODE, label type, OpCode, flag bits, and RDATA - size. In particular, for resolvers and servers that recognize it, it - extends the RCODE field from 4 to 12 bits. - - - -3.1.3 The AFSDB RR Subtype Field - - The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same - RDATA field structure as the MX RR but the 16 bit unsigned integer - field at the beginning of the RDATA is interpreted as a subtype as - follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - Allocation requires IETF Standards Action. - - 1 - 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183]. - - 2 - 0x0002 - DCE/NCA root cell directory node [RFC 1183]. - - 3 - 65,279 - 0x0003 - 0xFEFF - Allocation by IETF Consensus. - - 65,280 - 65,534 - 0xFF00 - 0xFFFE - Private Use. - - 65,535 - 0xFFFF - Reserved, allocation requires IETF Standards Action. - - - -3.2 RR CLASS IANA Considerations - - DNS CLASSes have been little used but constitute another dimension of - the DNS distributed database. In particular, there is no necessary - relationship between the name space or root servers for one CLASS and - those for another CLASS. The same name can have completely different - meanings in different CLASSes; however, the label types are the same - and the null label is usable only as root in every CLASS. However, - as global networking and DNS have evolved, the IN, or Internet, CLASS - has dominated DNS use. - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - There are two subcategories of DNS CLASSes: normal data containing - classes and QCLASSes that are only meaningful in queries or updates. - - The current CLASS assignments and considerations for future - assignments are as follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - Reserved, assignment requires an IETF Standards Action. - - 1 - 0x0001 - Internet (IN). - - 2 - 0x0002 - Available for assignment by IETF Consensus as a data CLASS. - - 3 - 0x0003 - Chaos (CH) [Moon 1981]. - - 4 - 0x0004 - Hesiod (HS) [Dyer 1987]. - - 5 - 127 - 0x0005 - 0x007F - available for assignment by IETF Consensus for data - CLASSes only. - - 128 - 253 - 0x0080 - 0x00FD - available for assignment by IETF Consensus for - QCLASSes only. - - 254 - 0x00FE - QCLASS None [RFC 2136]. - - 255 - 0x00FF - QCLASS Any [RFC 1035]. - - 256 - 32,767 - 0x0100 - 0x7FFF - Assigned by IETF Consensus. - - 32,768 - 65,279 - 0x8000 - 0xFEFF - Assigned based on Specification Required as defined - in [RFC 2434]. - - 65,280 - 65,534 - 0xFF00 - 0xFFFE - Private Use. - - 65,535 - 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -3.3 RR NAME Considerations - - DNS NAMEs are sequences of labels [RFC 1035]. The last label in each - NAME is "ROOT" which is the zero length label. By definition, the - null or ROOT label can not be used for any other NAME purpose. - - At the present time, there are two categories of label types, data - labels and compression labels. Compression labels are pointers to - data labels elsewhere within an RR or DNS message and are intended to - shorten the wire encoding of NAMEs. The two existing data label - types are sometimes referred to as Text and Binary. Text labels can, - in fact, include any octet value including zero value octets but most - current uses involve only [US-ASCII]. For retrieval, Text labels are - defined to treat ASCII upper and lower case letter codes as matching - [insensitive]. Binary labels are bit sequences [RFC 2673]. The - Binary label type is Experimental [RFC 3363]. - - IANA considerations for label types are given in [RFC 2671]. - - NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon - 1981] CLASSes are essentially for local use. The IN or Internet - CLASS is thus the only DNS CLASS in global use on the Internet at - this time. - - A somewhat out-of-date description of name allocation in the IN Class - is given in [RFC 1591]. Some information on reserved top level - domain names is in BCP 32 [RFC 2606]. - - - -4. Security Considerations - - This document addresses IANA considerations in the allocation of - general DNS parameters, not security. See [RFC 4033, 4034, 4035] for - secure DNS considerations. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 11] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -Appendix: Changes from RFC 2929 - - RFC Editor: This Appendix should be deleted for publication. - - Changes from RFC 2929 to this draft: - - 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE - Allocation Policy" and add the specification of that policy. Change - some remaining "IETF Standards Action" allocation requirements to say - "as modified by [RFC 4020]". - - 2. Updated various RFC references. - - 3. Mentioned that the Binary label type is now Experimental and - IQuery is Obsolete. - - 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be - IETF Standards Action required. - - 5. Add an IANA allocation policy for the AFSDB RR Subtype field. - - 6. Addition of reference to case insensitive draft. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 12] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -Copyright and Disclaimer - - Copyright (C) The Internet Society (2005). This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Normative References - - [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. - Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. - - [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC 1996, August 1996. - - [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System", - RFC 2673, August 1999. - - [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - -D. Eastlake 3rd [Page 13] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", September 2000. - - [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in - the Domain Name System (DNS)", RFC 3363, August 2002. - - [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November - 2002. - - [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of - Standards Track Code Points", BCP 100, RFC 4020, February 2005. - - [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", - X3.4, American National Standards Institute: New York, 1968. - - - -Informative References - - [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena - Technical Plan - Name Service, April 1987, - - [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts - Institute of Technology Artificial Intelligence Laboratory, June - 1981. - - [RFC 1591] - Postel, J., "Domain Name System Structure and - Delegation", RFC 1591, March 1994. - - [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, - September 2000. - - [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS - Names", RFC 2606, June 1999. - - [insensitive] - Eastlake, D., "Domain Name System (DNS) Case - - -D. Eastlake 3rd [Page 14] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt, - work in progress. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 15] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -Authors Addresses - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 (w) - email: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires February 2006. - - Its file name is draft-ietf-dnsext-2929bis-01.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 16] - diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt deleted file mode 100644 index 438e8008..00000000 --- a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt +++ /dev/null @@ -1,1397 +0,0 @@ -DNS Extensions Working Group G. Sisson -Internet-Draft B. Laurie -Expires: January 11, 2006 Nominet - July 10, 2005 - - - Derivation of DNS Name Predecessor and Successor - draft-ietf-dnsext-dns-name-p-s-00 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 11, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes two methods for deriving the canonically- - ordered predecessor and successor of a DNS name. These methods may - be used for dynamic NSEC resource record synthesis, enabling - security-aware name servers to provide authenticated denial of - existence without disclosing other owner names in a DNSSEC-secured - zone. - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 1] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 - 3. Absolute Method . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 4 - 3.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 4 - 4. Modified Method . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 6 - 4.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 6 - 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5.1. Case Considerations . . . . . . . . . . . . . . . . . . . 7 - 5.2. Choice of Range . . . . . . . . . . . . . . . . . . . . . 7 - 5.3. Wild Card Considerations . . . . . . . . . . . . . . . . . 8 - 5.4. Possible Modifications . . . . . . . . . . . . . . . . . . 8 - 5.4.1. Restriction of Effective Maximum DNS Name Length . . . 8 - 5.4.2. Use of Modified Method With Zones Containing - SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 9 - 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.1. Examples of Immediate Predecessors Using Absolute - Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.2. Examples of Immediate Successors Using Absolute Method . . 13 - 6.3. Examples of Predecessors Using Modified Method . . . . . . 19 - 6.4. Examples of Successors Using Modified Method . . . . . . . 20 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 - Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 - A.1. Changes from sisson-02 to ietf-00 . . . . . . . . . . . . 22 - A.2. Changes from sisson-01 to sisson-02 . . . . . . . . . . . 23 - A.3. Changes from sisson-00 to sisson-01 . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 - Intellectual Property and Copyright Statements . . . . . . . . . . 25 - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 2] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - -1. Introduction - - One of the proposals for avoiding the exposure of zone information - during the deployment DNSSEC is dynamic NSEC resource record (RR) - synthesis. This technique is described in [I-D.ietf-dnsext-dnssec- - trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the - generation of NSEC RRs that just span the query name for non-existent - owner names. In order to do this, the DNS names which would occur - just prior to and just following a given query name must be - calculated in real time, as maintaining a list of all possible owner - names that might occur in a zone would be impracticable. - - Section 6.1 of [RFC4034] defines canonical DNS name order. This - document does not amend or modify this definition. However, the - derivation of immediate predecessor and successor, while trivial, is - non-obvious. Accordingly, several methods are described here as an - aid to implementors and a reference to other interested parties. - - This document describes two methods: - - 1. An ``absolute method'', which returns the immediate predecessor - or successor of a domain name such that no valid DNS name could - exist between that DNS name and the predecessor or successor. - - 2. A ``modified method'', which returns a predecessor and successor - which are more economical in size and computation. This method - is restricted to use with zones consisting only of single-label - owner names where a maximum-length owner name would not result in - a DNS name exceeding the maximum DNS name length. This is, - however, the type of zone for which the technique of online- - signing is most likely to be used. - - -2. Notational Conventions - - The following notational conventions are used in this document for - economy of expression: - - N: An unspecified DNS name. - - P(N): Immediate predecessor to N (absolute method). - - S(N): Immediate successor to N (absolute method). - - P'(N): Predecessor to N (modified method). - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 3] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - S'(N): Successor to N (modified method). - - -3. Absolute Method - - These derivations assume that all uppercase US-ASCII letters in N - have already been replaced by their corresponding lowercase - equivalents. Unless otherwise specified, processing stops after the - first step in which a condition is met. - -3.1. Derivation of DNS Name Predecessor - - To derive P(N): - - 1. If N is the same as the owner name of the zone apex, prepend N - repeatedly with labels of the maximum length possible consisting - of octets of the maximum sort value (e.g. 0xff) until N is the - maximum length possible; otherwise continue to the next step. - - 2. If the least significant (left-most) label of N consists of a - single octet of the minimum sort value (e.g. 0x00), remove that - label; otherwise continue to the next step. - - 3. If the least significant (right-most) octet in the least - significant (left-most) label of N is the minimum sort value, - remove the least significant octet and continue with step 5. - - 4. Decrement the value of the least significant (right-most) octet, - skipping any values that correspond to uppercase US-ASCII - letters, and then append the label with as many octets as - possible of the maximum sort value. Continue to the next step. - - 5. Prepend N repeatedly with labels of as long a length as possible - consisting of octets of the maximum sort value until N is the - maximum length possible. - -3.2. Derivation of DNS Name Successor - - To derive S(N): - - 1. If N is two or more octets shorter than the maximum DNS name - length, prepend N with a label containing a single octet of the - minimum sort value (e.g. 0x00); otherwise continue to the next - step. - - 2. If N is one or more octets shorter than the maximum DNS name - length and the least significant (left-most) label is one or more - octets shorter than the maximum label length, append an octet of - - - -Sisson & Laurie Expires January 11, 2006 [Page 4] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - the minimum sort value to the least significant label; otherwise - continue to the next step. - - 3. Increment the value of the least significant (right-most) octet - in the least significant (left-most) label that is less than the - maximum sort value (e.g. 0xff), skipping any values that - correspond to uppercase US-ASCII letters, and then remove any - octets to the right of that one. If all octets in the label are - the maximum sort value, then continue to the next step. - - 4. Remove the least significant (left-most) label. If N is now the - same as the owner name of the zone apex, do nothing. (This will - occur only if N is the maximum possible name in canonical DNS - name order, and thus has wrapped to the owner name of zone apex.) - Otherwise repeat starting at step 2. - - -4. Modified Method - - This method is for use with zones consisting only of single-label - owner names where an owner name consisting of label of maximum length - would not result in a DNS name which exceeded the maximum DNS name - length. This method is computationally simpler and returns values - which are more economical in size than the absolute method. It - differs from the absolute method detailed above in the following - ways: - - 1. Step 1 of the derivation P(N) has been omitted as the existence - of the owner name of the zone apex never requires denial. - - 2. A new step 1 has been introduced which removes unnecessary - labels. - - 3. Step 4 of the derivation P(N) has been omitted as it is only - necessary for zones containing owner names consisting of more - than one label. This omission generally results in a significant - reduction of the length of derived predecessors. - - 4. Step 1 of the derivation S(N) had been omitted as it is only - necessary for zones containing owner names consisting of more - than one label. This omission results in a tiny reduction of the - length of derived successors, and maintains consistency with the - modification of step 4 of the derivation P(N) described above. - - 5. Steps 2 and 4 of the derivation S(N) have been modified to - eliminate checks for maximum DNS name length, as it is an - assumption of this method that no DNS name in the zone can exceed - the maximum DNS name length. - - - -Sisson & Laurie Expires January 11, 2006 [Page 5] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - These derivations assume that all uppercase US-ASCII letters in N - have already been replaced by their corresponding lowercase - equivalents. Unless otherwise specified, processing stops after the - first step in which a condition is met. - -4.1. Derivation of DNS Name Predecessor - - To derive P'(N): - - 1. If N has more labels than the number of labels in the owner name - of the apex + 1, repeatedly remove the least significant (left- - most) label until N has no more labels than the number of labels - in the owner name of the apex + 1; otherwise continue to next - step. - - 2. If the least significant (left-most) label of N consists of a - single octet of the minimum sort value (e.g. 0x00), remove that - label; otherwise continue to the next step. - - 3. If the least significant (right-most) octet in the least - significant (left-most) label of N is the minimum sort value, - remove the least significant octet. - - 4. Decrement the value of the least significant (right-most) octet, - skipping any values which correspond to uppercase US-ASCII - letters, and then append the label with as many octets as - possible of the maximum sort value. - -4.2. Derivation of DNS Name Successor - - To derive S'(N): - - 1. If N has more labels than the number of labels in the owner name - of the apex + 1, repeatedly remove the least significant (left- - most) label until N has no more labels than the number of labels - in the owner name of the apex + 1. Continue to next step. - - 2. If the least significant (left-most) label of N is one or more - octets shorter than the maximum label length, append an octet of - the minimum sort value to the least significant label; otherwise - continue to the next step. - - 3. Increment the value of the least significant (right-most) octet - in the least significant (left-most) label that is less than the - maximum sort value (e.g. 0xff), skipping any values which - correspond to uppercase US-ASCII letters, and then remove any - octets to the right of that one. If all octets in the label are - the maximum sort value, then continue to the next step. - - - -Sisson & Laurie Expires January 11, 2006 [Page 6] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - 4. Remove the least significant (left-most) label. (This will occur - only if the least significant label is the maximum label length - and consists entirely of octets of the maximum sort value, and - thus has wrapped to the owner name of the zone apex.) - - -5. Notes - -5.1. Case Considerations - - Section 3.5 of [RFC1034] specifies that "while upper and lower case - letters are allowed in [DNS] names, no significance is attached to - the case". Additionally, Section 6.1 of [RFC4034] states that when - determining canonical DNS name order, "uppercase US-ASCII letters are - treated as if they were lowercase US-ASCII letters". Consequently, - values corresponding to US-ASCII uppercase letters must be skipped - when decrementing and incrementing octets in the derivations - described in Section 3.1 and Section 3.2. - - The following pseudo-code is illustrative: - - Decrement the value of an octet: - - if (octet == '[') // '[' is just after uppercase 'Z' - octet = '@'; // '@' is just prior to uppercase 'A' - else - octet--; - - Increment the value of an octet: - - if (octet == '@') // '@' is just prior to uppercase 'A' - octet = '['; // '[' is just after uppercase 'Z' - else - octet++; - -5.2. Choice of Range - - [RFC2181] makes the clarification that "any binary string whatever - can be used as the label of any resource record". Consequently the - minimum sort value may be set as 0x00 and the maximum sort value as - 0xff, and the range of possible values will be any DNS name which - contains octets of any value other than those corresponding to - uppercase US-ASCII letters. - - However, if all owner names in a zone are in the letter-digit-hyphen, - or LDH, format specified in [RFC1034], it may be desirable to - restrict the range of possible values to DNS names containing only - LDH values. This has the effect of: - - - -Sisson & Laurie Expires January 11, 2006 [Page 7] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - 1. making the output of tools such as `dig' and `nslookup' less - subject to confusion; - - 2. minimising the impact that NSEC RRs containing DNS names with - non-LDH values (or non-printable values) might have on faulty DNS - resolver implementations; and - - 3. preventing the possibility of results which are wildcard DNS - names (see Section 5.3). - - This may be accomplished by using a minimum sort value of 0x1f (US- - ASCII character `-') and a maximum sort value of 0x7a (US-ASCII - character lowercase `z'), and then skipping non-LDH, non-lowercase - values when incrementing or decrementing octets. - -5.3. Wild Card Considerations - - Neither derivation avoids the possibility that the result may be a - DNS name containing a wildcard label, i.e. a label containing a - single octet with the value 0x2a (US-ASCII character `*'). With - additional tests, wildcard DNS names may be explicitly avoided; - alternatively, if the range of octet values can be restricted to - those corresponding to letter-digit-hyphen, or LDH, characters (see - Section 5.2), such DNS names will not occur. - - Note that it is improbable that a result which is a wildcard DNS name - will occur unintentionally; even if one does occur either as the - owner name of, or in the RDATA of an NSEC RR, it is treated as a - literal DNS name with no special meaning. - -5.4. Possible Modifications - -5.4.1. Restriction of Effective Maximum DNS Name Length - - [RFC1034] specifies that "the total number of octets that represent a - [DNS] name (i.e., the sum of all label octets and label lengths) is - limited to 255", including the null (zero-length) label which - represents the root. For the purpose of deriving predecessors and - successors during NSEC RR synthesis, the maximum DNS name length may - be effectively restricted to the length of the longest DNS name in - the zone. This will minimise the size of responses containing - synthesised NSEC RRs but, especially in the case of the modified - method, may result in some additional computational complexity. - - Note that this modification will have the effect of revealing - information about the longest name in the zone. Moreover, when the - contents of the zone changes, e.g. during dynamic updates and zone - transfers, care must be taken to ensure that the effective maximum - - - -Sisson & Laurie Expires January 11, 2006 [Page 8] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - DNS name length agrees with the new contents. - -5.4.2. Use of Modified Method With Zones Containing SRV RRs - - Normally the modified method cannot be used in zones that contain - SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple - labels. However the use of SRV RRs can be accommodated by various - techniques. There are at least four possible ways to do this: - - 1. Use conventional NSEC RRs for the region of the zone that - contains first-level labels beginning with the underscore (`_') - character. For the purposes of generating these NSEC RRs, the - existence of (possibly fictional) ownernames `9{63}' and `a' - could be assumed, providing a lower and upper bound for this - region. Then all queries where the QNAME doesn't exist but - contains a first-level label beginning with an underscore could - be handled using the normal DNSSEC protocol. - - This approach would make it possible to enumerate all DNS names - in the zone containing a first-level label beginning with - underscore, including all SRV RRs, but this may be of less a - concern to the zone administrator than incurring the overhead of - the absolute method or of the following variants of the modified - method. - - 2. The absolute method could be used for synthesising NSEC RRs for - all queries where the QNAME contains a leading underscore. - However this re-introduces the susceptibility of the absolute - method to denial of service activity, as an attacker could send - queries for an effectively inexhaustible supply of domain names - beginning with a leading underscore. - - 3. A variant of the modified method could be used for synthesising - NSEC RRs for all queries where the QNAME contains a leading - underscore. This variant would assume that all predecessors and - successors to queries where the QNAME contains a leading - underscore may consist of two lablels rather than only one. This - introduces a little additional complexity without incurring the - full increase in response size and computational complexity as - the absolute method. - - 4. Finally, a variant the modified method which assumes that all - owner names in the zone consist of one or two labels could be - used. However this negates much of the reduction in response - size of the modified method and may be nearly as computationally - complex as the absolute method. - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 9] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - -6. Examples - - In the following examples: - - the owner name of the zone apex is "example.com."; - - the range of octet values is 0x00 - 0xff excluding values - corresponding to uppercase US-ASCII letters; and - - non-printable octet values are expressed as three-digit decimal - numbers preceded by a backslash (as specified in Section 5.1 of - [RFC1035]). - -6.1. Examples of Immediate Predecessors Using Absolute Method - - Example of typical case: - - P(foo.example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.fon\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255.example.com. - - or, in alternate notation: - - \255{49}.\255{63}.\255{63}.fon\255{60}.example.com. - - where {n} represents the number of repetitions of an octet. - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 10] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where least significant (left-most) label of DNS name - consists of a single octet of the minimum sort value: - - P(\000.foo.example.com.) = foo.example.com. - - Example where least significant (right-most) octet of least - significant (left-most) label has the minimum sort value: - - P(foo\000.example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.foo.example.com. - - or, in alternate notation: - - \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com. - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 11] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name contains an octet which must be decremented by - skipping values corresponding to US-ASCII uppercase letters: - - P(fo\[.example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.fo\@\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255.example.com. - - or, in alternate notation: - - \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com. - - where {n} represents the number of repetitions of an octet. - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 12] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name is the owner name of the zone apex, and - consequently wraps to the DNS name with the maximum possible sort - order in the zone: - - P(example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com. - - or, in alternate notation: - - \255{49}.\255{63}.\255{63}.\255{63}.example.com. - -6.2. Examples of Immediate Successors Using Absolute Method - - Example of typical case: - - S(foo.example.com.) = \000.foo.example.com. - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 13] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name is one octet short of the maximum DNS name - length: - - N = fooooooooooooooooooooooooooooooooooooooooooooooo - .ooooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooo.ooooooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooo.ooooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo.example.com. - - or, in alternate notation: - - fo{47}.o{63}.o{63}.o{63}.example.com. - - S(N) = - - fooooooooooooooooooooooooooooooooooooooooooooooo - \000.ooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooooooo.ooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooooooo.ooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oooo.example.com. - - or, in alternate notation: - - fo{47}\000.o{63}.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 14] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name is the maximum DNS name length: - - N = fooooooooooooooooooooooooooooooooooooooooooooooo - o.oooooooooooooooooooooooooooooooooooooooooooooo - ooooooooooooooooo.oooooooooooooooooooooooooooooo - ooooooooooooooooooooooooooooooooo.oooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - o.example.com. - - or, in alternate notation: - - fo{48}.o{63}.o{63}.o{63}.example.com. - - S(N) = - - fooooooooooooooooooooooooooooooooooooooooooooooo - p.oooooooooooooooooooooooooooooooooooooooooooooo - ooooooooooooooooo.oooooooooooooooooooooooooooooo - ooooooooooooooooooooooooooooooooo.oooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - o.example.com. - - or, in alternate notation: - - fo{47}p.o{63}.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 15] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name is the maximum DNS name length and the least - significant (left-most) label has the maximum sort value: - - N = \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.ooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooooooo.ooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooooooo.ooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oooo.example.com. - - or, in alternate notation: - - \255{49}.o{63}.o{63}.o{63}.example.com. - - S(N) = - - oooooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooop.oooooooooooooooooooooooooooooooo - ooooooooooooooooooooooooooooooo.oooooooooooooooo - ooooooooooooooooooooooooooooooooooooooooooooooo. - example.com. - - or, in alternate notation: - - o{62}p.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 16] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name is the maximum DNS name length and the eight - least significant (right-most) octets of the least significant (left- - most) label have the maximum sort value: - - N = foooooooooooooooooooooooooooooooooooooooo\255 - \255\255\255\255\255\255\255.ooooooooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooo.ooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooo.ooooooooooooooooooooooooooooooooooo - oooooooooooooooooooooooooooo.example.com. - - or, in alternate notation: - - fo{40}\255{8}.o{63}.o{63}.o{63}.example.com. - - S(N) = - - fooooooooooooooooooooooooooooooooooooooop.oooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - ooooooooo.oooooooooooooooooooooooooooooooooooooo - ooooooooooooooooooooooooo.oooooooooooooooooooooo - ooooooooooooooooooooooooooooooooooooooooo.example.com. - - or, in alternate notation: - - fo{39}p.o{63}.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 17] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name is the maximum DNS name length and contains an - octet which must be incremented by skipping values corresponding to - US-ASCII uppercase letters: - - N = fooooooooooooooooooooooooooooooooooooooooooooooo - \@.ooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooooo.ooooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooooo.ooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oo.example.com. - - or, in alternate notation: - - fo{47}\@.o{63}.o{63}.o{63}.example.com. - - S(N) = - - fooooooooooooooooooooooooooooooooooooooooooooooo - \[.ooooooooooooooooooooooooooooooooooooooooooooo - oooooooooooooooooo.ooooooooooooooooooooooooooooo - oooooooooooooooooooooooooooooooooo.ooooooooooooo - oooooooooooooooooooooooooooooooooooooooooooooooo - oo.example.com. - - or, in alternate notation: - - fo{47}\[.o{63}.o{63}.o{63}.example.com. - - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 18] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name has the maximum possible sort order in the - zone, and consequently wraps to the owner name of the zone apex: - - N = \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255.\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255.\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com. - - or, in alternate notation: - - \255{49}.\255{63}.\255{63}.\255{63}.example.com. - - S(N) = example.com. - -6.3. Examples of Predecessors Using Modified Method - - Example of typical case: - - P'(foo.example.com.) = - - fon\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com. - - or, in alternate notation: - - fon\255{60}.example.com. - - - - -Sisson & Laurie Expires January 11, 2006 [Page 19] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where DNS name contains more labels than DNS names in the - zone: - - P'(bar.foo.example.com.) = foo.example.com. - - Example where least significant (right-most) octet of least - significant (left-most) label has the minimum sort value: - - P'(foo\000.example.com.) = foo.example.com. - - Example where least significant (left-most) label has the minimum - sort value: - - P'(\000.example.com.) = example.com. - - Example where DNS name is the owner name of the zone apex, and - consequently wraps to the DNS name with the maximum possible sort - order in the zone: - - P'(example.com.) = - - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255.example.com. - - or, in alternate notation: - - \255{63}.example.com. - -6.4. Examples of Successors Using Modified Method - - Example of typical case: - - S'(foo.example.com.) = foo\000.example.com. - - Example where DNS name contains more labels than DNS names in the - zone: - - S'(bar.foo.example.com.) = foo\000.example.com. - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 20] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - Example where least significant (left-most) label has the maximum - sort value, and consequently wraps to the owner name of the zone - apex: - - N = \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255.example.com. - - or, in alternate notation: - - \255{63}.example.com. - - S'(N) = example.com. - - -7. Security Considerations - - The derivation of some predecessors/successors requires the testing - of more conditions than others. Consequently the effectiveness of a - denial-of-service attack may be enhanced by sending queries that - require more conditions to be tested. The modified method involves - the testing of fewer conditions than the absolute method and - consequently is somewhat less susceptible to this exposure. - - -8. IANA Considerations - - This document has no IANA actions. - - Note to RFC Editor: This section is included to make it clear during - pre-publication review that this document has no IANA actions. It - may therefore be removed should it be published as an RFC. - - -9. Acknowledgments - - The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and - Niall O'Reilly for their review and input. - - -10. References - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 21] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - -10.1 Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - -10.2 Informative References - - [I-D.ietf-dnsext-dnssec-online-signing] - Ihren, J. and S. Weiler, "Minimally Covering NSEC Records - and DNSSEC On-line Signing", - draft-ietf-dnsext-dnssec-online-signing-00 (work in - progress), May 2005. - - [I-D.ietf-dnsext-dnssec-trans] - Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC - Transition Mechanisms", - draft-ietf-dnsext-dnssec-trans-02 (work in progress), - February 2005. - - -Appendix A. Change History - -A.1. Changes from sisson-02 to ietf-00 - - o Added notes on use of SRV RRs with modified method. - - o Changed reference from weiler-dnssec-online-signing to ietf- - dnsext-dnssec-online-signing. - - o Changed reference from ietf-dnsext-dnssec-records to RFC 4034. - - o Miscellaneous minor changes to text. - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 22] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - -A.2. Changes from sisson-01 to sisson-02 - - o Added modified version of derivation (with supporting examples). - - o Introduced notational conventions N, P(N), S(N), P'(N) and S'(N). - - o Added clarification to derivations about when processing stops. - - o Miscellaneous minor changes to text. - -A.3. Changes from sisson-00 to sisson-01 - - o Split step 3 of derivation of DNS name predecessor into two - distinct steps for clarity. - - o Added clarifying text and examples related to the requirement to - avoid uppercase characters when decrementing or incrementing - octets. - - o Added optimisation using restriction of effective maximum DNS name - length. - - o Changed examples to use decimal rather than octal notation as per - [RFC1035]. - - o Corrected DNS name length of some examples. - - o Added reference to weiler-dnssec-online-signing. - - o Miscellaneous minor changes to text. - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 23] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - -Authors' Addresses - - Geoffrey Sisson - Nominet - Sandford Gate - Sandy Lane West - Oxford - OX4 6LB - GB - - Phone: +44 1865 332339 - Email: geoff@nominet.org.uk - - - Ben Laurie - Nominet - 17 Perryn Road - London - W3 7LR - GB - - Phone: +44 20 8735 0686 - Email: ben@algroup.co.uk - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 24] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Sisson & Laurie Expires January 11, 2006 [Page 25] - diff --git a/doc/draft/draft-ietf-dnsext-dnsproxy-05.txt b/doc/draft/draft-ietf-dnsext-dnsproxy-05.txt deleted file mode 100644 index c5858c00..00000000 --- a/doc/draft/draft-ietf-dnsext-dnsproxy-05.txt +++ /dev/null @@ -1,728 +0,0 @@ - - - -DNSEXT R. Bellis -Internet-Draft Nominet UK -Intended status: BCP April 23, 2009 -Expires: October 25, 2009 - - - DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-05 - -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 October 25, 2009. - -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 provides guidelines for the implementation of DNS - proxies, as found in broadband gateways and other similar network - devices. - - - -Bellis Expires October 25, 2009 [Page 1] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3 - - 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4 - 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4 - 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4 - 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5 - 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5 - 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 6 - 4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6 - 4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6 - 4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7 - - 5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7 - 5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 8 - 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8 - 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8 - - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9 - 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10 - 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10 - - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - - 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 - - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - -Bellis Expires October 25, 2009 [Page 2] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - -1. Introduction - - Research has found ([SAC035], [DOTSE]) that many commonly-used - broadband gateways (and similar devices) contain DNS proxies which - are incompatible in various ways with current DNS standards. - - These proxies are usually simple DNS forwarders, but typically do not - have any caching capabilities. The proxy serves as a convenient - default DNS resolver for clients on the LAN, but relies on an - upstream resolver (e.g. at an ISP) to perform recursive DNS lookups. - - Note that to ensure full DNS protocol interoperability it is - preferred that client stub resolvers should communicate directly with - full-feature upstream recursive resolvers wherever possible. - - That notwithstanding, this document describes the incompatibilities - that have been discovered and offers guidelines to implementors on - how to provide better interoperability in those cases where the - client must use the broadband gateway's DNS proxy. - - -2. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -3. The Transparency Principle - - It is not considered practical for a simple DNS proxy to implement - all current and future DNS features. - - There are several reasons why this is the case: - - o broadband gateways usually have limited hardware resources - o firmware upgrade cycles are long, and many users do not routinely - apply upgrades when they become available - o no-one knows what those future DNS features will be, nor how they - might be implemented - o it would substantially complicate the configuration UI of the - device - - Furthermore some modern DNS protocol extensions (see e.g. EDNS0, - below) are intended to be used as "hop-by-hop" mechanisms. If the - DNS proxy is considered to be such a "hop" in the resolution chain, - then for it to function correctly, it would need to be fully - compliant with all such mechanisms. - - - -Bellis Expires October 25, 2009 [Page 3] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - [SAC035] shows that the more actively a proxy participates in the DNS - protocol then the more likely it is that it will somehow interfere - with the flow of messages between the DNS client and the upstream - recursive resolvers. - - The role of the proxy should therefore be no more and no less than to - receive DNS requests from clients on the LAN side, forward those - verbatim to one of the known upstream recursive resolvers on the WAN - side, and ensure that the whole response is returned verbatim to the - original client. - - It is RECOMMENDED that proxies should be as transparent as possible, - such that any "hop-by-hop" mechanisms or newly introduced protocol - extensions operate as if the proxy were not there. - - Except when required to enforce an active security or network policy - (such as maintaining a pre-authentication "walled garden"), end-users - SHOULD be able to send their DNS queries to specified upstream - resolvers, thereby bypassing the proxy altogether. In this case, the - gateway SHOULD NOT modify the DNS request or response packets in any - way. - - -4. Protocol Conformance - -4.1. Unexpected Flags and Data - - The Transparency Principle above, when combined with Postel's - Robustness Principle [RFC0793], suggests that DNS proxies should not - arbitrarily reject or otherwise drop requests or responses based on - perceived non-compliance with standards. - - For example, some proxies have been observed to drop any packet - containing either the "Authentic Data" (AD) or "Checking Disabled" - (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] - originally specified that these unused "Z" flag bits "MUST" be zero. - However these flag bits were always intended to be reserved for - future use, so refusing to proxy any packet containing these flags - (now that uses for those flags have indeed been defined) is not - appropriate. - - Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown - DNS flags and proxy those packets as usual. - -4.2. Label Compression - - Compression of labels as per Section 4.1.4 of [RFC1035] is optional. - - - - -Bellis Expires October 25, 2009 [Page 4] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - Proxies MUST forward packets regardless of the presence or absence of - compressed labels therein. - -4.3. Unknown Resource Record Types - - [RFC3597] requires that resolvers MUST handle Resource Records (RRs) - of unknown type transparently. - - All requests and responses MUST be proxied regardless of the values - of the QTYPE and QCLASS fields. - - Similarly all responses MUST be proxied regardless of the values of - the TYPE and CLASS fields of any Resource Record therein. - -4.4. Packet Size Limits - - [RFC1035] specifies that the maximum size of the DNS payload in a UDP - packet is 512 octets. Where the required portions of a response - would not fit inside that limit the DNS server MUST set the - "TrunCation" (TC) bit in the DNS response header to indicate that - truncation has occurred. There are however two standard mechanisms - (described in Section 4.4.1 and Section 4.4.2) for transporting - responses larger than 512 octets. - - Many proxies have been observed to truncate all responses at 512 - octets, and others at a packet size related to the WAN MTU, in either - case doing so without correctly setting the TC bit. - - Other proxies have been observed to remove the TC bit in server - responses which correctly had the TC bit set by the server. - - If a DNS response is truncated but the TC bit is not set then client - failures may result. In particular a naive DNS client library might - suffer crashes due to reading beyond the end of the data actually - received. - - Since UDP packets larger than 512 octets are now expected in normal - operation, proxies SHOULD NOT truncate UDP packets that exceed that - size. See Section 4.4.3 for recommendations for packet sizes - exceeding the WAN MTU. - - If a proxy must unilaterally truncate a response then the proxy MUST - set the TC bit. Similarly, proxies MUST NOT remove the TC bit from - responses. - - - - - - - -Bellis Expires October 25, 2009 [Page 5] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - -4.4.1. TCP Transport - - Should a UDP query fail because of truncation, the standard fail-over - mechanism is to retry the query using TCP, as described in section - 6.1.3.2 of [RFC1123]. - - DNS proxies SHOULD therefore be prepared to receive and forward - queries over TCP. - - Note that it is unlikely that a client would send a request over TCP - unless it had already received a truncated UDP response. Some - "smart" proxies have been observed to first forward any request - received over TCP to an upstream resolver over UDP, only for the - response to be truncated, causing the proxy to retry over TCP. Such - behaviour increases network traffic and causes delay in DNS - resolution since the initial UDP request is doomed to fail. - - Therefore whenever a proxy receives a request over TCP, the proxy - SHOULD forward the query over TCP and SHOULD NOT attempt the same - query over UDP first. - -4.4.2. Extension Mechanisms for DNS (EDNS0) - - The Extension Mechanism for DNS [RFC2671] was introduced to allow the - transport of larger DNS packets over UDP and also to allow for - additional request and response flags. - - A client may send an OPT Resource Record (OPT RR) in the Additional - Section of a request to indicate that it supports a specific receive - buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used - by DNSSEC to indicate that DNSSEC-related RRs should be returned to - the client. - - However some proxies have been observed to either reject (with a - FORMERR response code) or black-hole any packet containing an OPT RR. - As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets. - -4.4.3. IP Fragmentation - - Support for UDP packet sizes exceeding the WAN MTU depends on the - gateway's algorithm for handling fragmented IP packets. Several - methods are possible: - - 1. fragments are dropped - 2. fragments are forwarded individually as they're received - 3. complete packets are reassembled on the gateway, and then re- - fragmented (if necessary) as they're forwarded to the client - - - - -Bellis Expires October 25, 2009 [Page 6] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - Method 1 above will cause compatibility problems with EDNS0 unless - the DNS client is configured to advertise an EDNS0 buffer size - limited to the WAN MTU less the size of the IP header. Note that RFC - 2671 does recommend that the path MTU should be taken into account - when using EDNS0. - - Also, whilst the EDNS0 specification allows for a buffer size of up - to 65535 octets, most common DNS server implementations do not - support a buffer size above 4096 octets. - - Therefore (irrespective of which of the methods above is in use) - proxies SHOULD be capable of forwarding UDP packets up to a payload - size of at least 4096 octets. - - NB: in theory IP fragmentation may also occur if the LAN MTU is - smaller than the WAN MTU, although the author has not observed such a - configuration in use on any residential broadband service. - -4.5. Secret Key Transaction Authentication for DNS (TSIG) - - [RFC2845] defines TSIG, which is a mechanism for authenticating DNS - requests and responses at the packet level. - - Any modifications made to the DNS portions of a TSIG-signed query or - response packet (with the exception of the Query ID) will cause a - TSIG authentication failure. - - DNS proxies MUST implement Section 4.7 of [RFC2845] and either - forward packets unchanged (as recommended above) or fully implement - TSIG. - - As per Section 4.3, DNS proxies MUST be capable of proxying packets - containing TKEY [RFC2930] Resource Records. - - NB: any DNS proxy (such as those commonly found in WiFi hotspot - "walled gardens") which transparently intercepts all DNS queries, and - which returns unsigned responses to signed queries, will also cause - TSIG authentication failures. - - -5. DHCP's Interaction with DNS - - Whilst this document is primarily about DNS proxies, most consumers - rely on DHCP [RFC2131] to obtain network configuration settings. - Such settings include the client machine's IP address, subnet mask - and default gateway, but also include DNS related settings. - - It is therefore appropriate to examine how DHCP affects client DNS - - - -Bellis Expires October 25, 2009 [Page 7] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - configuration. - -5.1. Domain Name Server (DHCP Option 6) - - Most gateways default to supplying their own IP address in the DHCP - "Domain Name Server" option [RFC2132]. The net result is that - without explicit re-configuration many DNS clients will by default - send queries to the gateway's DNS proxy. This is understandable - behaviour given that the correct upstream settings are not usually - known at boot time. - - Most gateways learn their own DNS settings via values supplied by an - ISP via DHCP or PPP over the WAN interface. However whilst many - gateways do allow the device administrator to override those values, - some gateways only use those supplied values to affect the proxy's - own forwarding function, and do not offer these values via DHCP. - - When using such a device the only way to avoid using the DNS proxy is - to hard-code the required values in the client operating system. - This may be acceptable for a desktop system but it is inappropriate - for mobile devices which are regularly used on many different - networks. - - As per Section 3, end-users SHOULD be able to send their DNS queries - directly to specified upstream resolvers, ideally without hard-coding - those settings in their stub resolver. - - It is therefore RECOMMENDED that gateways SHOULD support device - administrator configuration of values for the "Domain Name Server" - DHCP option. - -5.2. Domain Name (DHCP Option 15) - - A significant amount of traffic to the DNS Root Name Servers is for - invalid top-level domain names, and some of that traffic can be - attributed to particular equipment vendors whose firmware defaults - this DHCP option to specific values. - - Since no standard exists for a "local" scoped domain name suffix it - is RECOMMENDED that the default value for this option SHOULD be - empty, and that this option MUST NOT be sent to clients when no value - is configured. - -5.3. DHCP Leases - - It is noted that some DHCP servers in broadband gateways by default - offer their own IP address for the "Domain Name Server" option (as - described above) but then automatically start offering the upstream - - - -Bellis Expires October 25, 2009 [Page 8] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - servers' addresses once they've been learnt over the WAN interface. - - In general this behaviour is highly desirable, but the effect for the - end-user is that the settings used depend on whether the DHCP lease - was obtained before or after the WAN link was established. - - If the DHCP lease is obtained whilst the WAN link is down then the - DHCP client (and hence the DNS client) will not receive the correct - values until the DHCP lease is renewed. - - Whilst no specific recommendations are given here, vendors may wish - to give consideration to the length of DHCP leases, and whether some - mechanism for forcing a DHCP lease renewal might be appropriate. - - Another possibility is that the learnt upstream values might be - persisted in non-volatile memory such that on reboot the same values - can be automatically offered via DHCP. However this does run the - risk that incorrect values are initially offered if the device is - moved or connected to another ISP. - - Alternatively, the DHCP server might only issue very short (i.e. 60 - second) leases while the WAN link is down, only reverting to more - typical lease lengths once the WAN link is up and the upstream DNS - servers are known. Indeed with such a configuration it may be - possible to avoid the need to implement a DNS proxy function in the - broadband gateway at all. - - -6. Security Considerations - - This document introduces no new protocols. However there are some - security related recommendations for vendors that are listed here. - -6.1. Forgery Resilience - - Whilst DNS proxies are not usually full-feature resolvers they - nevertheless share some characteristics with them. - - Notwithstanding the recommendations above about transparency many DNS - proxies are observed to pick a new Query ID for outbound requests to - ensure that responses are directed to the correct client. - - NB: Changing the Query ID is acceptable and compatible with proxying - TSIG-signed packets since the TSIG signature calculation is based on - the original message ID which is carried in the TSIG RR. - - It has been standard guidance for many years that each DNS query - should use a randomly generated Query ID. However many proxies have - - - -Bellis Expires October 25, 2009 [Page 9] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - been observed picking sequential Query IDs for successive requests. - - It is strongly RECOMMENDED that DNS proxies follow the relevant - recommendations in [RFC5452], particularly those in Section 9.2 - relating to randomisation of Query IDs and source ports. This also - applies to source port selection within any NAT function. - - If a DNS proxy is running on a broadband gateway with NAT that is - compliant with [RFC4787] then it SHOULD also follow the - recommendations in Section 10 of [RFC5452] concerning how long DNS - state is kept. - -6.2. Interface Binding - - Some gateways have been observed to have their DNS proxy listening on - both internal (LAN) and external (WAN) interfaces. In this - configuration it is possible for the proxy to be used to mount - reflector attacks as described in [RFC5358]. - - The DNS proxy in a gateway SHOULD NOT by default be accessible from - the WAN interfaces of the device. - -6.3. Packet Filtering - - The Transparency and Robustness Principles are not entirely - compatible with the deep packet inspection features of security - appliances such as firewalls which are intended to protect systems on - the inside of a network from rogue traffic. - - However a clear distinction may be made between traffic that is - intrinsically malformed and that which merely contains unexpected - data. - - Examples of malformed packets which MAY be dropped include: - - o invalid compression pointers (i.e. those that point outside of the - current packet, or which might cause a parsing loop). - o incorrect counts for the Question, Answer, Authority and - Additional Sections (although care should be taken where - truncation is a possibility). - - Since dropped packets will cause the client to repeatedly retransmit - the original request, it is RECOMMENDED that proxies SHOULD instead - return a suitable DNS error response to the client (i.e. SERVFAIL) - instead of dropping the packet completely. - - - - - - -Bellis Expires October 25, 2009 [Page 10] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - -7. IANA Considerations - - This document requests no IANA actions. - - -8. Change Log - - NB: to be removed by the RFC Editor before publication. - - draft-ietf-dnsproxy-05 - Removed specific reference to 28 byte IP headers (from Mark - Andrews) - - draft-ietf-dnsproxy-04 - post WGLC - Introduction expanded - Section 5.2 - changed SHOULD to MUST - Section 4.5 - changed SHOULD to MUST (Alex Bligh) - Editorial nits (from Andrew Sullivan, Alfred Hones) - Clarificaton on end-user vs device administrator (Alan Barrett, - Paul Selkirk) - - draft-ietf-dnsproxy-03 - Editorial nits and mention of LAN MTU (from Alex Bligh) - - draft-ietf-dnsproxy-02 - Changed "router" to "gateway" throughout (David Oran) - Updated forgery resilience reference - Elaboration on bypassability (from Nicholas W.) - Elaboration on NAT source port randomisation (from Nicholas W.) - Mention of using short DHCP leases while the WAN link is down - (from Ralph Droms) - Further clarification on permissibility of altering QID when using - TSIG - - draft-ietf-dnsproxy-01 - Strengthened recommendations about truncation (from Shane Kerr) - New TSIG text (with help from Olafur) - Additional forgery resilience text (from Olafur) - Compression support (from Olafur) - Correction of text re: QID changes and compatibility with TSIG - - draft-ietf-dnsproxy-00 - Changed recommended DPI error to SERVFAIL (from Jelte) - Changed example for invalid compression pointers (from Wouter). - Note about TSIG implications of changing Query ID (from Wouter). - Clarified TC-bit text (from Wouter) - - - - - -Bellis Expires October 25, 2009 [Page 11] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - Extra text about proxy bypass (Nicholas W.) - - draft-bellis-dnsproxy-00 - Initial draft - - -9. Acknowledgements - - The author would particularly like to acknowledge the assistance of - Lisa Phifer of Core Competence. In addition the author is grateful - for the feedback from the members of the DNSEXT Working Group. - - -10. References - -10.1. Normative References - - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", - RFC 2131, March 1997. - - [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - - - -Bellis Expires October 25, 2009 [Page 12] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4787] Audet, F. and C. Jennings, "Network Address Translation - (NAT) Behavioral Requirements for Unicast UDP", BCP 127, - RFC 4787, January 2007. - - [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive - Nameservers in Reflector Attacks", BCP 140, RFC 5358, - October 2008. - - [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More - Resilient against Forged Answers", RFC 5452, January 2009. - -10.2. Informative References - - [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband - Routers", February 2008, - <http://www.iis.se/docs/Routertester_en.pdf>. - - [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on - Broadband Routers and Firewalls", September 2008, - <http://www.icann.org/committees/security/sac035.pdf>. - - -Author's Address - - Ray Bellis - Nominet UK - Edmund Halley Road - Oxford OX4 4DQ - United Kingdom - - Phone: +44 1865 332211 - Email: ray.bellis@nominet.org.uk - URI: http://www.nominet.org.uk/ - - - - - - - - - - - - - - -Bellis Expires October 25, 2009 [Page 13] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt deleted file mode 100644 index bcc2b4ec..00000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt +++ /dev/null @@ -1,442 +0,0 @@ - - -INTERNET-DRAFT Samuel Weiler -Expires: June 2004 December 15, 2003 -Updates: RFC 2535, [DS] - - Legacy Resolver Compatibility for Delegation Signer - draft-ietf-dnsext-dnssec-2535typecode-change-06.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - Comments should be sent to the author or to the DNSEXT WG mailing - list: namedroppers@ops.ietf.org - -Abstract - - As the DNS Security (DNSSEC) specifications have evolved, the - syntax and semantics of the DNSSEC resource records (RRs) have - changed. Many deployed nameservers understand variants of these - semantics. Dangerous interactions can occur when a resolver that - understands an earlier version of these semantics queries an - authoritative server that understands the new delegation signer - semantics, including at least one failure scenario that will cause - an unsecured zone to be unresolvable. This document changes the - type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to - avoid those interactions. - -Changes between 05 and 06: - - Signifigantly reworked the IANA section -- went back to one - algorithm registry. - - Removed Diffie-Hellman from the list of zone-signing algorithms - (leaving only DSA, RSA/SHA-1, and private algorithms). - - Added a DNSKEY flags field registry. - -Changes between 04 and 05: - - IESG approved publication. - - Cleaned up an internal reference in the acknowledgements section. - - Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference. - - Changed the names of both new registries. Added algorithm - mnemonics to the new zone signing algorithm registry. Minor - rewording in the IANA section for clarity. - - Cleaned up formatting of references. Replaced unknown-rr draft - references with RFC3597. Bumped DS version number. - -Changes between 03 and 04: - - Clarified that RRSIG(0) may be defined by standards action. - - Created a new algorithm registry and renamed the old algorithm - registry for SIG(0) only. Added references to the appropriate - crypto algorithm and format specifications. - - Several minor rephrasings. - -Changes between 02 and 03: - - KEY (as well as SIG) retained for SIG(0) use only. - -Changes between 01 and 02: - - SIG(0) still uses SIG, not RRSIG. Added 2931 reference. - - Domain names embedded in NSECs and RRSIGs are not compressible and - are not downcased. Added unknown-rrs reference (as informative). - - Simplified the last paragraph of section 3 (NSEC doesn't always - signal a negative answer). - - Changed the suggested type code assignments. - - Added 2119 reference. - - Added definitions of "unsecure delegation" and "unsecure referral", - since they're not clearly defined elsewhere. - - Moved 2065 to informative references, not normative. - -1. Introduction - - The DNSSEC protocol has been through many iterations whose syntax - and semantics are not completely compatible. This has occurred as - part of the ordinary process of proposing a protocol, implementing - it, testing it in the increasingly complex and diverse environment - of the Internet, and refining the definitions of the initial - Proposed Standard. In the case of DNSSEC, the process has been - complicated by DNS's criticality and wide deployment and the need - to add security while minimizing daily operational complexity. - - A weak area for previous DNS specifications has been lack of detail - in specifying resolver behavior, leaving implementors largely on - their own to determine many details of resolver function. This, - combined with the number of iterations the DNSSEC spec has been - through, has resulted in fielded code with a wide variety of - behaviors. This variety makes it difficult to predict how a - protocol change will be handled by all deployed resolvers. The - risk that a change will cause unacceptable or even catastrophic - failures makes it difficult to design and deploy a protocol change. - One strategy for managing that risk is to structure protocol - changes so that existing resolvers can completely ignore input that - might confuse them or trigger undesirable failure modes. - - This document addresses a specific problem caused by Delegation - Signer's [DS] introduction of new semantics for the NXT RR that are - incompatible with the semantics in RFC 2535 [RFC2535]. Answers - provided by DS-aware servers can trigger an unacceptable failure - mode in some resolvers that implement RFC 2535, which provides a - great disincentive to sign zones with DS. The changes defined in - this document allow for the incremental deployment of DS. - -1.1 Terminology - - In this document, the term "unsecure delegation" means any - delegation for which no DS record appears at the parent. An - "unsecure referral" is an answer from the parent containing an NS - RRset and a proof that no DS record exists for that name. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -1.2 The Problem - - Delegation Signer introduces new semantics for the NXT RR that are - incompatible with the semantics in RFC 2535. In RFC 2535, NXT - records were only required to be returned as part of a - non-existence proof. With DS, an unsecure referral returns, in - addition to the NS, a proof of non-existence of a DS RR in the form - of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was - to interpret a response with both an NS and an NXT in the authority - section, RCODE=0, and AA=0. Some widely deployed 2535-aware - resolvers interpret any answer with an NXT as a proof of - non-existence of the requested record. This results in unsecure - delegations being invisible to 2535-aware resolvers and violates - the basic architectural principle that DNSSEC must do no harm -- - the signing of zones must not prevent the resolution of unsecured - delegations. - -2. Possible Solutions - - This section presents several solutions that were considered. - Section 3 describes the one selected. - -2.1. Change SIG, KEY, and NXT type codes - - To avoid the problem described above, legacy (RFC2535-aware) - resolvers need to be kept from seeing unsecure referrals that - include NXT records in the authority section. The simplest way to - do that is to change the type codes for SIG, KEY, and NXT. - - The obvious drawback to this is that new resolvers will not be able - to validate zones signed with the old RRs. This problem already - exists, however, because of the changes made by DS, and resolvers - that understand the old RRs (and have compatibility issues with DS) - are far more prevalent than 2535-signed zones. - -2.2. Change a subset of type codes - - The observed problem with unsecure referrals could be addressed by - changing only the NXT type code or another subset of the type codes - that includes NXT. This has the virtue of apparent simplicity, but - it risks introducing new problems or not going far enough. It's - quite possible that more incompatibilities exist between DS and - earlier semantics. Legacy resolvers may also be confused by seeing - records they recognize (SIG and KEY) while being unable to find - NXTs. Although it may seem unnecessary to fix that which is not - obviously broken, it's far cleaner to change all of the type codes - at once. This will leave legacy resolvers and tools completely - blinded to DNSSEC -- they will see only unknown RRs. - -2.3. Replace the DO bit - - Another way to keep legacy resolvers from ever seeing DNSSEC - records with DS semantics is to have authoritative servers only - send that data to DS-aware resolvers. It's been proposed that - assigning a new EDNS0 flag bit to signal DS-awareness (tentatively - called "DA"), and having authoritative servers send DNSSEC data - only in response to queries with the DA bit set, would accomplish - this. This bit would presumably supplant the DO bit described in - RFC 3225. - - This solution is sufficient only if all 2535-aware resolvers zero - out EDNS0 flags that they don't understand. If one passed through - the DA bit unchanged, it would still see the new semantics, and it - would probably fail to see unsecure delegations. Since it's - impractical to know how every DNS implementation handles unknown - EDNS0 flags, this is not a universal solution. It could, though, - be considered in addition to changing the RR type codes. - -2.4. Increment the EDNS version - - Another possible solution is to increment the EDNS version number - as defined in RFC 2671 [RFC2671], on the assumption that all - existing implementations will reject higher versions than they - support, and retain the DO bit as the signal for DNSSEC awareness. - This approach has not been tested. - -2.5. Do nothing - - There is a large deployed base of DNS resolvers that understand - DNSSEC as defined by the standards track RFC 2535 and RFC 2065 - and, due to under specification in those documents, interpret any - answer with an NXT as a non-existence proof. So long as that is - the case, zone owners will have a strong incentive to not sign any - zones that contain unsecure delegations, lest those delegations be - invisible to such a large installed base. This will dramatically - slow DNSSEC adoption. - - Unfortunately, without signed zones there's no clear incentive for - operators of resolvers to upgrade their software to support the new - version of DNSSEC, as defined in [DS]. Historical data suggests - that resolvers are rarely upgraded, and that old nameserver code - never dies. - - Rather than wait years for resolvers to be upgraded through natural - processes before signing zones with unsecure delegations, - addressing this problem with a protocol change will immediately - remove the disincentive for signing zones and allow widespread - deployment of DNSSEC. - -3. Protocol changes - - This document changes the type codes of SIG, KEY, and NXT. This - approach is the cleanest and safest of those discussed above, - largely because the behavior of resolvers that receive unknown type - codes is well understood. This approach has also received the most - testing. - - To avoid operational confusion, it's also necessary to change the - mnemonics for these RRs. DNSKEY will be the replacement for KEY, - with the mnemonic indicating that these keys are not for - application use, per [RFC3445]. RRSIG (Resource Record SIGnature) - will replace SIG, and NSEC (Next SECure) will replace NXT. These - new types completely replace the old types, except that SIG(0) - [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY. - - The new types will have exactly the same syntax and semantics as - specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for - the following: - - 1) Consistent with [RFC3597], domain names embedded in - RRSIG and NSEC RRs MUST NOT be compressed, - - 2) Embedded domain names in RRSIG and NSEC RRs are not downcased - for purposes of DNSSEC canonical form and ordering nor for - equality comparison, and - - 3) An RRSIG with a type-covered field of zero has undefined - semantics. The meaning of such a resource record may only be - defined by IETF Standards Action. - - If a resolver receives the old types, it SHOULD treat them as - unknown RRs and SHOULD NOT assign any special meaning to them or - give them any special treatment. It MUST NOT use them for DNSSEC - validations or other DNS operational decision making. For example, - a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to - validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, - they MUST NOT receive special treatment. As an example, if a SIG - is included in a signed zone, there MUST be an RRSIG for it. - Authoritative servers may wish to give error messages when loading - zones containing SIG or NXT records (KEY records may be included - for SIG(0) or TKEY). - - As a clarification to previous documents, some positive responses, - particularly wildcard proofs and unsecure referrals, will contain - NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as - negative answers merely because they contain an NSEC. - -4. IANA Considerations - -4.1 DNS Resource Record Types - - This document updates the IANA registry for DNS Resource Record - Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and - DNSKEY RRs, respectively. - - Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and - TKEY [RFC2930] use only. - - Type 30 (NXT) should be marked as Obsolete. - -4.2 DNS Security Algorithm Numbers - - To allow zone signing (DNSSEC) and transaction security mechanisms - (SIG(0) and TKEY) to use different sets of algorithms, the existing - "DNS Security Algorithm Numbers" registry is modified to include - the applicability of each algorithm. Specifically, two new columns - are added to the registry, showing whether each algorithm may be - used for zone signing, transaction security mechanisms, or both. - Only algorithms usable for zone signing may be used in DNSKEY, - RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG - may be used in SIG and KEY RRs. - - All currently defined algorithms remain usable for transaction - security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private - algorithms (types 253 and 254) may be used for zone signing. Note - that the registry does not contain the requirement level of each - algorithm, only whether or not an algorithm may be used for the - given purposes. For example, RSA/MD5, while allowed for - transaction security mechanisms, is NOT RECOMMENDED, per RFC3110. - - Additionally, the presentation format algorithm mnemonics from - RFC2535 Section 7 are added to the registry. This document assigns - RSA/SHA-1 the mnemonic RSASHA1. - - As before, assignment of new algorithms in this registry requires - IETF Standards Action. Additionally, modification of algorithm - mnemonics or applicability requires IETF Standards Action. - Documents defining a new algorithm must address the applicability - of the algorithm and should assign a presentation mnemonic to the - algorithm. - -4.3 DNSKEY Flags - - Like the KEY resource record, DNSKEY contains a 16-bit flags field. - This document creates a new registry for the DNSKEY flags field. - - Initially, this registry only contains an assignment for bit 7 (the - ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF - Standards Action. - -4.4 DNSKEY Protocol Octet - - Like the KEY resource record, DNSKEY contains an eight bit protocol - field. The only defined value for this field is 3 (DNSSEC). No - other values are allowed, hence no IANA registry is needed for this - field. - -5. Security Considerations - - The changes introduced here do not materially affect security. - The implications of trying to use both new and legacy types - together are not well understood, and attempts to do so would - probably lead to unintended and dangerous results. - - Changing type codes will leave code paths in legacy resolvers that - are never exercised. Unexercised code paths are a frequent source - of security holes, largely because those code paths do not get - frequent scrutiny. - - Doing nothing, as described in section 2.5, will slow DNSSEC - deployment. While this does not decrease security, it also fails - to increase it. - -6. Normative references - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [DS] Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-15.txt, work in - progress, June 2003. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name - System (DNS)", RFC 2436, March 1999. - - [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the - Domain Name System (DNS)", RFC 2539, March 1999. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the - Domain Name System (DNS)", RFC 3110, May 2001. - -7. Informative References - - [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, - RFC 2929, September 2000. - - [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource - Record (RR) Types", RFC 3597, September 2003. - -8. Acknowledgments - - The changes introduced here and the analysis of alternatives had - many contributors. With apologies to anyone overlooked, those - include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed - Lewis, Bill Manning, and Suzanne Woolf. - - Thanks to Jakob Schlyter and Mark Andrews for identifying the - incompatibility described in section 1.2. - - In addition to the above, the author would like to thank Scott - Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive - comments. - -9. Author's Address - - Samuel Weiler - SPARTA, Inc. - 7075 Samuel Morse Drive - Columbia, MD 21046 - USA - weiler@tislabs.com - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt deleted file mode 100644 index c8db7091..00000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt +++ /dev/null @@ -1,840 +0,0 @@ - - - -DNSEXT D. Blacka -Internet-Draft VeriSign, Inc. -Intended status: Standards Track April 7, 2006 -Expires: October 9, 2006 - - - DNSSEC Experiments - draft-ietf-dnsext-dnssec-experiments-03 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on October 9, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 1] - -Internet-Draft DNSSEC Experiments April 2006 - - -Abstract - - This document describes a methodology for deploying alternate, non- - backwards-compatible, DNSSEC methodologies in an experimental fashion - without disrupting the deployment of standard DNSSEC. - - -Table of Contents - - 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8 - 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 10.2. Informative References . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 2] - -Internet-Draft DNSSEC Experiments April 2006 - - -1. Definitions and Terminology - - Throughout this document, familiarity with the DNS system (RFC 1035 - [5]) and the DNS security extensions ([2], [3], and [4] is assumed. - - The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 3] - -Internet-Draft DNSSEC Experiments April 2006 - - -2. Overview - - Historically, experimentation with DNSSEC alternatives has been a - problematic endeavor. There has typically been a desire to both - introduce non-backwards-compatible changes to DNSSEC and to try these - changes on real zones in the public DNS. This creates a problem when - the change to DNSSEC would make all or part of the zone using those - changes appear bogus (bad) or otherwise broken to existing security- - aware resolvers. - - This document describes a standard methodology for setting up DNSSEC - experiments. This methodology addresses the issue of co-existence - with standard DNSSEC and DNS by using unknown algorithm identifiers - to hide the experimental DNSSEC protocol modifications from standard - security-aware resolvers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 4] - -Internet-Draft DNSSEC Experiments April 2006 - - -3. Experiments - - When discussing DNSSEC experiments, it is necessary to classify these - experiments into two broad categories: - - Backwards-Compatible: describes experimental changes that, while not - strictly adhering to the DNSSEC standard, are nonetheless - interoperable with clients and servers that do implement the - DNSSEC standard. - - Non-Backwards-Compatible: describes experiments that would cause a - standard security-aware resolver to (incorrectly) determine that - all or part of a zone is bogus, or to otherwise not interoperate - with standard DNSSEC clients and servers. - - Not included in these terms are experiments with the core DNS - protocol itself. - - The methodology described in this document is not necessary for - backwards-compatible experiments, although it certainly may be used - if desired. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 5] - -Internet-Draft DNSSEC Experiments April 2006 - - -4. Method - - The core of the methodology is the use of strictly unknown algorithm - identifiers when signing the experimental zone, and more importantly, - having only unknown algorithm identifiers in the DS records for the - delegation to the zone at the parent. - - This technique works because of the way DNSSEC-compliant validators - are expected to work in the presence of a DS set with only unknown - algorithm identifiers. From [4], Section 5.2: - - If the validator does not support any of the algorithms listed in - an authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - And further: - - If the resolver does not support any of the algorithms listed in - an authenticated DS RRset, then the resolver will not be able to - verify the authentication path to the child zone. In this case, - the resolver SHOULD treat the child zone as if it were unsigned. - - While this behavior isn't strictly mandatory (as marked by MUST), it - is likely that a validator would implement this behavior, or, more to - the point, it would handle this situation in a safe way (see below - (Section 6).) - - Because we are talking about experiments, it is RECOMMENDED that - private algorithm numbers be used (see [3], appendix A.1.1. Note - that secure handling of private algorithms requires special handing - by the validator logic. See [6] for further details.) Normally, - instead of actually inventing new signing algorithms, the recommended - path is to create alternate algorithm identifiers that are aliases - for the existing, known algorithms. While, strictly speaking, it is - only necessary to create an alternate identifier for the mandatory - algorithms, it is suggested that all optional defined algorithms be - aliased as well. - - It is RECOMMENDED that for a particular DNSSEC experiment, a - particular domain name base is chosen for all new algorithms, then - the algorithm number (or name) is prepended to it. For example, for - experiment A, the base name of "dnssec-experiment-a.example.com" is - chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are - defined to be "3.dnssec-experiment-a.example.com" and - "5.dnssec-experiment-a.example.com". However, any unique identifier - - - -Blacka Expires October 9, 2006 [Page 6] - -Internet-Draft DNSSEC Experiments April 2006 - - - will suffice. - - Using this method, resolvers (or, more specifically, DNSSEC - validators) essentially indicate their ability to understand the - DNSSEC experiment's semantics by understanding what the new algorithm - identifiers signify. - - This method creates two classes of security-aware servers and - resolvers: servers and resolvers that are aware of the experiment - (and thus recognize the experiment's algorithm identifiers and - experimental semantics), and servers and resolvers that are unaware - of the experiment. - - This method also precludes any zone from being both in an experiment - and in a classic DNSSEC island of security. That is, a zone is - either in an experiment and only experimentally validatable, or it is - not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 7] - -Internet-Draft DNSSEC Experiments April 2006 - - -5. Defining an Experiment - - The DNSSEC experiment MUST define the particular set of (previously - unknown) algorithm identifiers that identify the experiment, and - define what each unknown algorithm identifier means. Typically, - unless the experiment is actually experimenting with a new DNSSEC - algorithm, this will be a mapping of private algorithm identifiers to - existing, known algorithms. - - Normally the experiment will choose a DNS name as the algorithm - identifier base. This DNS name SHOULD be under the control of the - authors of the experiment. Then the experiment will define a mapping - between known mandatory and optional algorithms into this private - algorithm identifier space. Alternately, the experiment MAY use the - OID private algorithm space instead (using algorithm number 254), or - MAY choose non-private algorithm numbers, although this would require - an IANA allocation. - - For example, an experiment might specify in its description the DNS - name "dnssec-experiment-a.example.com" as the base name, and declare - that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC - algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an - alias of DNSSEC algorithm 5 (RSASHA1). - - Resolvers MUST only recognize the experiment's semantics when present - in a zone signed by one or more of these algorithm identifiers. This - is necessary to isolate the semantics of one experiment from any - others that the resolver might understand. - - In general, resolvers involved in the experiment are expected to - understand both standard DNSSEC and the defined experimental DNSSEC - protocol, although this isn't required. - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 8] - -Internet-Draft DNSSEC Experiments April 2006 - - -6. Considerations - - There are a number of considerations with using this methodology. - - 1. Under some circumstances, it may be that the experiment will not - be sufficiently masked by this technique and may cause resolution - problem for resolvers not aware of the experiment. For instance, - the resolver may look at a non-validatable response and conclude - that the response is bogus, either due to local policy or - implementation details. This is not expected to be a common - case, however. - - 2. It will not be possible for security-aware resolvers unaware of - the experiment to build a chain of trust through an experimental - zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 9] - -Internet-Draft DNSSEC Experiments April 2006 - - -7. Use in Non-Experiments - - This general methodology MAY be used for non-backwards compatible - DNSSEC protocol changes that start out as or become standards. In - this case: - - o The protocol change SHOULD use public IANA allocated algorithm - identifiers instead of private algorithm identifiers. This will - help identify the protocol change as a standard, rather than an - experiment. - - o Resolvers MAY recognize the protocol change in zones not signed - (or not solely signed) using the new algorithm identifiers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 10] - -Internet-Draft DNSSEC Experiments April 2006 - - -8. Security Considerations - - Zones using this methodology will be considered insecure by all - resolvers except those aware of the experiment. It is not generally - possible to create a secure delegation from an experimental zone that - will be followed by resolvers unaware of the experiment. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 11] - -Internet-Draft DNSSEC Experiments April 2006 - - -9. IANA Considerations - - This document has no IANA actions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 12] - -Internet-Draft DNSSEC Experiments April 2006 - - -10. References - -10.1. Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - -10.2. Informative References - - [5] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [6] Austein, R. and S. Weiler, "Clarifications and Implementation - Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02 - (work in progress), January 2006. - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 13] - -Internet-Draft DNSSEC Experiments April 2006 - - -Author's Address - - David Blacka - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - Email: davidb@verisign.com - URI: http://www.verisignlabs.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 14] - -Internet-Draft DNSSEC Experiments April 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Blacka Expires October 9, 2006 [Page 15] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-03.txt deleted file mode 100644 index 061df679..00000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-gost-03.txt +++ /dev/null @@ -1,455 +0,0 @@ -DNS Extensions working group V.Dolmatov, Ed. -Internet-Draft Cryptocom Ltd. -Intended status: Standards Track November 10, 2009 -Expires: May 10, 2010 - - - Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records - for DNSSEC - draft-ietf-dnsext-dnssec-gost-03 - -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 May 10 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 signature and hash using - GOST algorithms for DNSKEY, RRSIG and DS resource records for use in - the Domain Name System Security Extensions (DNSSEC, RFC 4033, - RFC 4034, and RFC 4035). - -V.Dolmatov Expires May 10, 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 May 10, 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 the 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 (the value of GostAsn1 - field is split here into two lines to simplify reading; in the - private key file it must be in one line): - - Private-key-format: v1.2 - Algorithm: {TBA1} (GOST) - GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S - 2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E= - -V.Dolmatov Expires May 10, 2010 [Page 3] - - The following DNSKEY RR stores a DNS zone key for example.net - - example.net. 86400 IN DNSKEY 256 3 {TBA1} ( - AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq - tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6 - yB7i836EfzmJo5LP - ) ; key id = 15820 - -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 proper code is - assigned by IANA) - - www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 ( - 20000101000000 15820 example.net. - K4sw+TOJz47xqP6685ItDfPhkktyvgxXrLdX - aQLX01mMZbJUp6tzetBYGpdHciAW5RLvHLVB - P8RtFK8Qv5DRsA== ) - - Note: Several GOST signatures calculated for the same message text - differ because of using of a random element is used in signature - generation process. - -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], that is digest is in little-endian representation. - -V.Dolmatov Expires May 10, 2010 [Page 4] - - 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 - - For key signing key (assuming {TBA1}==249 until proper code is - assigned by IANA) - - example.net. 86400 DNSKEY 257 3 {TBA1} ( - AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C - RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu - 9tCz5oSsZl0cL0R2 - ) ; key id = 21649 - - The DS RR will be - - example.net. 3600 IN DS 21649 {TBA1} {TBA2} ( - A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A - A44649C6 ) - - -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 handle 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 May 10, 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 [RFC4034]" - (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 Digest Types assignment - (section A.2)by adding the value and status for the GOST R 34.11-94 - algorithm: - - 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 May 10, 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-06, 11.10.09 - work in progress. -V.Dolmatov Expires May 10, 2010 [Page 7] - - [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., - "GOST R 34.11-94 Hash function algorithm" - draft-dolmatov-cryptocom-gost341194-04, 11.10.09 - work in progress. - - [DRAFT3] Dolmatov V., Kabelev D., Ustinov I., Emelyanova I., - "GOST 28147-89 encryption, decryption and MAC algorithms" - draft-dolmatov-cryptocom-gost2814789-04, 11.10.09 - 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 May 10, 2010 [Page 8] - - - - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-04.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt index 1733c7d5..152d96ef 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-gost-04.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt @@ -1,12 +1,12 @@ DNS Extensions working group V.Dolmatov, Ed. Internet-Draft Cryptocom Ltd. -Intended status: Standards Track November 22, 2009 -Expires: May 22, 2010 +Intended status: Standards Track November 30, 2009 +Expires: May 30, 2010 Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC - draft-ietf-dnsext-dnssec-gost-04 + draft-ietf-dnsext-dnssec-gost-05 Status of this Memo @@ -45,11 +45,11 @@ Copyright Notice Abstract This document describes how to produce signature and hash using - GOST algorithms for DNSKEY, RRSIG and DS resource records for use in - the Domain Name System Security Extensions (DNSSEC, RFC 4033, - RFC 4034, and RFC 4035). + GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS + resource records for use in the Domain Name System Security + Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). -V.Dolmatov Expires May 22, 2010 [Page 1] +V.Dolmatov Expires May 30, 2010 [Page 1] Table of Contents @@ -59,7 +59,7 @@ Table of Contents 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 3 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 3.1 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 4 - 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 4 + 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5 4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 @@ -75,7 +75,7 @@ Table of Contents 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction @@ -106,7 +106,7 @@ Table of Contents "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. -V.Dolmatov Expires May 22, 2010 [Page 2] +V.Dolmatov Expires May 30, 2010 [Page 2] 2. DNSKEY Resource Records @@ -118,7 +118,7 @@ V.Dolmatov Expires May 22, 2010 [Page 2] 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 + According to [GOST3410], a public key is a point on the elliptic curve Q = (x,y). The wire representation of a public key MUST contain 66 octets, @@ -127,7 +127,7 @@ V.Dolmatov Expires May 22, 2010 [Page 2] 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. + from [GOST3410], ch. 5.3. The only valid value for both parameters octets is 0. Other parameters octets values are reserved for future use. @@ -162,17 +162,17 @@ V.Dolmatov Expires May 22, 2010 [Page 2] Private-key-format: v1.2 Algorithm: {TBA1} (GOST) GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S - 2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E= + 2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E= -V.Dolmatov Expires May 22, 2010 [Page 3] +V.Dolmatov Expires May 30, 2010 [Page 3] The following DNSKEY RR stores a DNS zone key for example.net example.net. 86400 IN DNSKEY 256 3 {TBA1} ( AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq - tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6 - yB7i836EfzmJo5LP - ) ; key id = 15820 + tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6 + yB7i836EfzmJo5LP + ) ; key id = 15820 3. RRSIG Resource Records @@ -206,7 +206,7 @@ V.Dolmatov Expires May 22, 2010 [Page 3] 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 + www.example.net. 3600 IN A 192.0.2.1 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 @@ -215,9 +215,11 @@ V.Dolmatov Expires May 22, 2010 [Page 3] www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 ( 20000101000000 15820 example.net. - K4sw+TOJz47xqP6685ItDfPhkktyvgxXrLdX - aQLX01mMZbJUp6tzetBYGpdHciAW5RLvHLVB - P8RtFK8Qv5DRsA== ) + 2MIsZWtEx6pcfQrdl376B8sFg0qxsR8XMHpl + jHh+V6U7Qte7WwI4C3Z1nFMRVf//C9rO2dGB + rdp+C7wVoOHBqA== ) + +V.Dolmatov Expires May 30, 2010 [Page 4] Note: Several GOST signatures calculated for the same message text differ because of using of a random element is used in signature @@ -226,12 +228,11 @@ V.Dolmatov Expires May 22, 2010 [Page 3] 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], that is digest is in little-endian representation. + type {TBA2}.The wire format of a digest value is compatible with + RFC4490 [RFC4490], that is digest is in little-endian representation. -V.Dolmatov Expires May 22, 2010 [Page 4] - The digest MUST always be calculated with GOST R 34.11-94 parameters + 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 @@ -249,8 +250,7 @@ V.Dolmatov Expires May 22, 2010 [Page 4] example.net. 3600 IN DS 21649 {TBA1} {TBA2} ( A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A - A44649C6 ) - + A44649C6 ) 5. Deployment Considerations @@ -266,8 +266,8 @@ V.Dolmatov Expires May 22, 2010 [Page 4] 5.3. Digest Sizes - According to the GOST R 34.11-94 [GOST3411], the size of a GOST digest - is 256 bits. + According to the GOST R 34.11-94 [GOST3411], the size of a GOST + digest is 256 bits. 6. Implementation Considerations @@ -277,6 +277,8 @@ V.Dolmatov Expires May 22, 2010 [Page 4] DNSKEY resource records created with the GOST algorithms as defined in this document. +V.Dolmatov Expires May 30, 2010 [Page 5] + 6.2. Support for NSEC3 Denial of Existence Any DNSSEC-GOST implementation is required to have either NSEC or @@ -298,7 +300,6 @@ V.Dolmatov Expires May 22, 2010 [Page 4] of multiple elliptic curve point computations on prime modulus of order 2**256. -V.Dolmatov Expires May 22, 2010 [Page 5] Currently, the cryptographic resistance of GOST 34.11-94 hash algorithm is estimated as 2**128 operations of computations of a @@ -311,8 +312,8 @@ V.Dolmatov Expires May 22, 2010 [Page 5] This document updates the IANA registry "DNS Security Algorithm Numbers [RFC4034]" - (http://www.iana.org/assignments/dns-sec-alg-numbers). The - following entries are added to the registry: + (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 @@ -332,6 +333,8 @@ V.Dolmatov Expires May 22, 2010 [Page 5] contributors to these documents are gratefully acknowledged for their hard work. +V.Dolmatov Expires May 30, 2010 [Page 6] + The following people provided additional feedback and text: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen and Wouter Wijngaards. @@ -355,8 +358,6 @@ V.Dolmatov Expires May 22, 2010 [Page 5] Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. -V.Dolmatov Expires May 22, 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. @@ -378,7 +379,7 @@ V.Dolmatov Expires May 22, 2010 [Page 6] 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 + 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. @@ -388,31 +389,19 @@ V.Dolmatov Expires May 22, 2010 [Page 6] Infrastructure Certificate and CRL Profile", RFC 4491, May 2006. +V.Dolmatov Expires May 30, 2010 [Page 7] 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-06, 11.10.09 + draft-dolmatov-cryptocom-gost34102001-06, 11.10.09 work in progress. -V.Dolmatov Expires May 10, 2010 [Page 7] + [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., "GOST R 34.11-94 Hash function algorithm" @@ -424,31 +413,34 @@ V.Dolmatov Expires May 10, 2010 [Page 7] draft-dolmatov-cryptocom-gost2814789-04, 11.10.09 work in progress. +V.Dolmatov Expires May 30, 2010 [Page 8] + + Authors' Addresses Vasily Dolmatov, Ed. Cryptocom Ltd. -Bolotnikovskaya, 23 -Moscow, 117303, Russian Federation +Kedrova 14, bld.2 +Moscow, 117218, Russian Federation EMail: dol@cryptocom.ru Artem Chuprina Cryptocom Ltd. -Bolotnikovskaya, 23 -Moscow, 117303, Russian Federation +Kedrova 14, bld.2 +Moscow, 117218, Russian Federation EMail: ran@cryptocom.ru Igor Ustinov Cryptocom Ltd. -Bolotnikovskaya, 23 -Moscow, 117303, Russian Federation +Kedrova 14, bld.2 +Moscow, 117218, Russian Federation EMail: igus@cryptocom.ru -V.Dolmatov Expires May 22, 2010 [Page 8] +V.Dolmatov Expires May 30, 2010 [Page 9] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt deleted file mode 100644 index 7503c66a..00000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc -Updates: 4034, 4035 (if approved) J. Ihren -Expires: July 24, 2006 Autonomica AB - January 20, 2006 - - - Minimally Covering NSEC Records and DNSSEC On-line Signing - draft-ietf-dnsext-dnssec-online-signing-02 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 24, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes how to construct DNSSEC NSEC resource records - that cover a smaller range of names than called for by RFC4034. By - generating and signing these records on demand, authoritative name - servers can effectively stop the disclosure of zone contents - otherwise made possible by walking the chain of NSEC records in a - signed zone. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 1] - -Internet-Draft NSEC Epsilon January 2006 - - -Changes from ietf-01 to ietf-02 - - Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG - and NSEC bits set, to be consistent with DNSSECbis -- previous text - said SHOULD. - - Made the applicability statement a little less oppressive. - -Changes from ietf-00 to ietf-01 - - Added an applicability statement, making reference to ongoing work on - NSEC3. - - Added the phrase "epsilon functions", which has been commonly used to - describe the technique and already appeared in the header of each - page, in place of "increment and decrement functions". Also added an - explanatory sentence. - - Corrected references from 4034 section 6.2 to section 6.1. - - Fixed an out-of-date reference to [-bis] and other typos. - - Replaced IANA Considerations text. - - Escaped close parentheses in examples. - - Added some more acknowledgements. - -Changes from weiler-01 to ietf-00 - - Inserted RFC numbers for 4033, 4034, and 4035. - - Specified contents of bitmap field in synthesized NSEC RR's, pointing - out that this relaxes a constraint in 4035. Added 4035 to the - Updates header. - -Changes from weiler-00 to weiler-01 - - Clarified that this updates RFC4034 by relaxing requirements on the - next name field. - - Added examples covering wildcard names. - - In the 'better functions' section, reiterated that perfect functions - aren't needed. - - Added a reference to RFC 2119. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 2] - -Internet-Draft NSEC Epsilon January 2006 - - -Table of Contents - - 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 - 2. Applicability of This Technique . . . . . . . . . . . . . . . 4 - 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5 - 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 - Intellectual Property and Copyright Statements . . . . . . . . . . 11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 3] - -Internet-Draft NSEC Epsilon January 2006 - - -1. Introduction and Terminology - - With DNSSEC [1], an NSEC record lists the next instantiated name in - its zone, proving that no names exist in the "span" between the - NSEC's owner name and the name in the "next name" field. In this - document, an NSEC record is said to "cover" the names between its - owner name and next name. - - Through repeated queries that return NSEC records, it is possible to - retrieve all of the names in the zone, a process commonly called - "walking" the zone. Some zone owners have policies forbidding zone - transfers by arbitrary clients; this side-effect of the NSEC - architecture subverts those policies. - - This document presents a way to prevent zone walking by constructing - NSEC records that cover fewer names. These records can make zone - walking take approximately as many queries as simply asking for all - possible names in a zone, making zone walking impractical. Some of - these records must be created and signed on demand, which requires - on-line private keys. Anyone contemplating use of this technique is - strongly encouraged to review the discussion of the risks of on-line - signing in Section 6. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [4]. - - -2. Applicability of This Technique - - The technique presented here may be useful to a zone owner that wants - to use DNSSEC, is concerned about exposure of its zone contents via - zone walking, and is willing to bear the costs of on-line signing. - - As discussed in Section 6, on-line signing has several security - risks, including an increased likelihood of private keys being - disclosed and an increased risk of denial of service attack. Anyone - contemplating use of this technique is strongly encouraged to review - the discussion of the risks of on-line signing in Section 6. - - Furthermore, at the time this document was published, the DNSEXT - working group was actively working on a mechanism to prevent zone - walking that does not require on-line signing (tentatively called - NSEC3). The new mechanism is likely to expose slightly more - information about the zone than this technique (e.g. the number of - instantiated names), but it may be preferable to this technique. - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 4] - -Internet-Draft NSEC Epsilon January 2006 - - -3. Minimally Covering NSEC Records - - This mechanism involves changes to NSEC records for instantiated - names, which can still be generated and signed in advance, as well as - the on-demand generation and signing of new NSEC records whenever a - name must be proven not to exist. - - In the 'next name' field of instantiated names' NSEC records, rather - than list the next instantiated name in the zone, list any name that - falls lexically after the NSEC's owner name and before the next - instantiated name in the zone, according to the ordering function in - RFC4034 [2] section 6.1. This relaxes the requirement in section - 4.1.1 of RFC4034 that the 'next name' field contains the next owner - name in the zone. This change is expected to be fully compatible - with all existing DNSSEC validators. These NSEC records are returned - whenever proving something specifically about the owner name (e.g. - that no resource records of a given type appear at that name). - - Whenever an NSEC record is needed to prove the non-existence of a - name, a new NSEC record is dynamically produced and signed. The new - NSEC record has an owner name lexically before the QNAME but - lexically following any existing name and a 'next name' lexically - following the QNAME but before any existing name. - - The generated NSEC record's type bitmap MUST have the RRSIG and NSEC - bits set and SHOULD NOT have any other bits set. This relaxes the - requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at - names that did not exist before the zone was signed. - - The functions to generate the lexically following and proceeding - names need not be perfect nor consistent, but the generated NSEC - records must not cover any existing names. Furthermore, this - technique works best when the generated NSEC records cover as few - names as possible. In this document, the functions that generate the - nearby names are called 'epsilon' functions, a reference to the - mathematical convention of using the greek letter epsilon to - represent small deviations. - - An NSEC record denying the existence of a wildcard may be generated - in the same way. Since the NSEC record covering a non-existent - wildcard is likely to be used in response to many queries, - authoritative name servers using the techniques described here may - want to pregenerate or cache that record and its corresponding RRSIG. - - For example, a query for an A record at the non-instantiated name - example.com might produce the following two NSEC records, the first - denying the existence of the name example.com and the second denying - the existence of a wildcard: - - - -Weiler & Ihren Expires July 24, 2006 [Page 5] - -Internet-Draft NSEC Epsilon January 2006 - - - exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) - - \).com 3600 IN NSEC +.com ( RRSIG NSEC ) - - Before answering a query with these records, an authoritative server - must test for the existence of names between these endpoints. If the - generated NSEC would cover existing names (e.g. exampldd.com or - *bizarre.example.com), a better epsilon function may be used or the - covered name closest to the QNAME could be used as the NSEC owner - name or next name, as appropriate. If an existing name is used as - the NSEC owner name, that name's real NSEC record MUST be returned. - Using the same example, assuming an exampldd.com delegation exists, - this record might be returned from the parent: - - exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) - - Like every authoritative record in the zone, each generated NSEC - record MUST have corresponding RRSIGs generated using each algorithm - (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as - described in RFC4035 [3] section 2.2. To minimize the number of - signatures that must be generated, a zone may wish to limit the - number of algorithms in its DNSKEY RRset. - - -4. Better Epsilon Functions - - Section 6.1 of RFC4034 defines a strict ordering of DNS names. - Working backwards from that definition, it should be possible to - define epsilon functions that generate the immediately following and - preceding names, respectively. This document does not define such - functions. Instead, this section presents functions that come - reasonably close to the perfect ones. As described above, an - authoritative server should still ensure than no generated NSEC - covers any existing name. - - To increment a name, add a leading label with a single null (zero- - value) octet. - - To decrement a name, decrement the last character of the leftmost - label, then fill that label to a length of 63 octets with octets of - value 255. To decrement a null (zero-value) octet, remove the octet - -- if an empty label is left, remove the label. Defining this - function numerically: fill the left-most label to its maximum length - with zeros (numeric, not ASCII zeros) and subtract one. - - In response to a query for the non-existent name foo.example.com, - these functions produce NSEC records of: - - - - -Weiler & Ihren Expires July 24, 2006 [Page 6] - -Internet-Draft NSEC Epsilon January 2006 - - - fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) - - \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) - - The first of these NSEC RRs proves that no exact match for - foo.example.com exists, and the second proves that there is no - wildcard in example.com. - - Both of these functions are imperfect: they don't take into account - constraints on number of labels in a name nor total length of a name. - As noted in the previous section, though, this technique does not - depend on the use of perfect epsilon functions: it is sufficient to - test whether any instantiated names fall into the span covered by the - generated NSEC and, if so, substitute those instantiated owner names - for the NSEC owner name or next name, as appropriate. - - -5. IANA Considerations - - This document specifies no IANA Actions. - - -6. Security Considerations - - This approach requires on-demand generation of RRSIG records. This - creates several new vulnerabilities. - - First, on-demand signing requires that a zone's authoritative servers - have access to its private keys. Storing private keys on well-known - internet-accessible servers may make them more vulnerable to - unintended disclosure. - - Second, since generation of digital signatures tends to be - computationally demanding, the requirement for on-demand signing - makes authoritative servers vulnerable to a denial of service attack. - - Lastly, if the epsilon functions are predictable, on-demand signing - may enable a chosen-plaintext attack on a zone's private keys. Zones - using this approach should attempt to use cryptographic algorithms - that are resistant to chosen-plaintext attacks. It's worth noting - - - -Weiler & Ihren Expires July 24, 2006 [Page 7] - -Internet-Draft NSEC Epsilon January 2006 - - - that while DNSSEC has a "mandatory to implement" algorithm, that is a - requirement on resolvers and validators -- there is no requirement - that a zone be signed with any given algorithm. - - The success of using minimally covering NSEC record to prevent zone - walking depends greatly on the quality of the epsilon functions - chosen. An increment function that chooses a name obviously derived - from the next instantiated name may be easily reverse engineered, - destroying the value of this technique. An increment function that - always returns a name close to the next instantiated name is likewise - a poor choice. Good choices of epsilon functions are the ones that - produce the immediately following and preceding names, respectively, - though zone administrators may wish to use less perfect functions - that return more human-friendly names than the functions described in - Section 4 above. - - Another obvious but misguided concern is the danger from synthesized - NSEC records being replayed. It's possible for an attacker to replay - an old but still validly signed NSEC record after a new name has been - added in the span covered by that NSEC, incorrectly proving that - there is no record at that name. This danger exists with DNSSEC as - defined in [3]. The techniques described here actually decrease the - danger, since the span covered by any NSEC record is smaller than - before. Choosing better epsilon functions will further reduce this - danger. - -7. Normative References - - [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - -Appendix A. Acknowledgments - - Many individuals contributed to this design. They include, in - addition to the authors of this document, Olaf Kolkman, Ed Lewis, - - - -Weiler & Ihren Expires July 24, 2006 [Page 8] - -Internet-Draft NSEC Epsilon January 2006 - - - Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, - Jakob Schlyter, Bill Manning, and Joao Damas. - - In addition, the editors would like to thank Ed Lewis, Scott Rose, - and David Blacka for their careful review of the document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 9] - -Internet-Draft NSEC Epsilon January 2006 - - -Authors' Addresses - - Samuel Weiler - SPARTA, Inc - 7075 Samuel Morse Drive - Columbia, Maryland 21046 - US - - Email: weiler@tislabs.com - - - Johan Ihren - Autonomica AB - Bellmansgatan 30 - Stockholm SE-118 47 - Sweden - - Email: johani@autonomica.se - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 10] - -Internet-Draft NSEC Epsilon January 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 11] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt deleted file mode 100644 index 17e28e82..00000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt +++ /dev/null @@ -1,896 +0,0 @@ - - - -DNSEXT R. Arends -Internet-Draft Telematica Instituut -Expires: January 19, 2006 M. Kosters - D. Blacka - Verisign, Inc. - July 18, 2005 - - - DNSSEC Opt-In - draft-ietf-dnsext-dnssec-opt-in-07 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 19, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC - 4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are - cryptographically secured. Maintaining this cryptography is not - practical or necessary. This document describes an experimental - "Opt-In" model that allows administrators to omit this cryptography - and manage the cost of adopting DNSSEC with large zones. - - - -Arends, et al. Expires January 19, 2006 [Page 1] - -Internet-Draft DNSSEC Opt-In July 2005 - - -Table of Contents - - 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4 - 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4 - 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5 - 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5 - 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6 - 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6 - 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7 - 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7 - 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7 - 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7 - 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8 - 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8 - 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . 13 - 11.2 Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 - A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . 16 - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 19, 2006 [Page 2] - -Internet-Draft DNSSEC Opt-In July 2005 - - -1. Definitions and Terminology - - Throughout this document, familiarity with the DNS system (RFC 1035 - [1]), DNS security extensions ([3], [4], and [5], referred to in this - document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090 - [10]) is assumed. - - The following abbreviations and terms are used in this document: - - RR: is used to refer to a DNS resource record. - RRset: refers to a Resource Record Set, as defined by [8]. In this - document, the RRset is also defined to include the covering RRSIG - records, if any exist. - signed name: refers to a DNS name that has, at minimum, a (signed) - NSEC record. - unsigned name: refers to a DNS name that does not (at least) have a - NSEC record. - covering NSEC record/RRset: is the NSEC record used to prove - (non)existence of a particular name or RRset. This means that for - a RRset or name 'N', the covering NSEC record has the name 'N', or - has an owner name less than 'N' and "next" name greater than 'N'. - delegation: refers to a NS RRset with a name different from the - current zone apex (non-zone-apex), signifying a delegation to a - subzone. - secure delegation: refers to a signed name containing a delegation - (NS RRset), and a signed DS RRset, signifying a delegation to a - signed subzone. - insecure delegation: refers to a signed name containing a delegation - (NS RRset), but lacking a DS RRset, signifying a delegation to an - unsigned subzone. - Opt-In insecure delegation: refers to an unsigned name containing - only a delegation NS RRset. The covering NSEC record uses the - Opt-In methodology described in this document. - - The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [7]. - -2. Overview - - The cost to cryptographically secure delegations to unsigned zones is - high for large delegation-centric zones and zones where insecure - delegations will be updated rapidly. For these zones, the costs of - maintaining the NSEC record chain may be extremely high relative to - the gain of cryptographically authenticating existence of unsecured - zones. - - This document describes an experimental method of eliminating the - - - -Arends, et al. Expires January 19, 2006 [Page 3] - -Internet-Draft DNSSEC Opt-In July 2005 - - - superfluous cryptography present in secure delegations to unsigned - zones. Using "Opt-In", a zone administrator can choose to remove - insecure delegations from the NSEC chain. This is accomplished by - extending the semantics of the NSEC record by using a redundant bit - in the type map. - -3. Experimental Status - - This document describes an EXPERIMENTAL extension to DNSSEC. It - interoperates with non-experimental DNSSEC using the technique - described in [6]. This experiment is identified with the following - private algorithms (using algorithm 253): - - "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, - and - "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, - RSASHA1. - - Servers wishing to sign and serve zones that utilize Opt-In MUST sign - the zone with only one or more of these private algorithms. This - requires the signing tools and servers to support private algorithms, - as well as Opt-In. - - Resolvers wishing to validate Opt-In zones MUST only do so when the - zone is only signed using one or more of these private algorithms. - - The remainder of this document assumes that the servers and resolvers - involved are aware of and are involved in this experiment. - -4. Protocol Additions - - In DNSSEC, delegation NS RRsets are not signed, but are instead - accompanied by a NSEC RRset of the same name and (possibly) a DS - record. The security status of the subzone is determined by the - presence or absence of the DS RRset, cryptographically proven by the - NSEC record. Opt-In expands this definition by allowing insecure - delegations to exist within an otherwise signed zone without the - corresponding NSEC record at the delegation's owner name. These - insecure delegations are proven insecure by using a covering NSEC - record. - - Since this represents a change of the interpretation of NSEC records, - resolvers must be able to distinguish between RFC standard DNSSEC - NSEC records and Opt-In NSEC records. This is accomplished by - "tagging" the NSEC records that cover (or potentially cover) insecure - delegation nodes. This tag is indicated by the absence of the NSEC - bit in the type map. Since the NSEC bit in the type map merely - indicates the existence of the record itself, this bit is redundant - - - -Arends, et al. Expires January 19, 2006 [Page 4] - -Internet-Draft DNSSEC Opt-In July 2005 - - - and safe for use as a tag. - - An Opt-In tagged NSEC record does not assert the (non)existence of - the delegations that it covers (except for a delegation with the same - name). This allows for the addition or removal of these delegations - without recalculating or resigning records in the NSEC chain. - However, Opt-In tagged NSEC records do assert the (non)existence of - other RRsets. - - An Opt-In NSEC record MAY have the same name as an insecure - delegation. In this case, the delegation is proven insecure by the - lack of a DS bit in type map and the signed NSEC record does assert - the existence of the delegation. - - Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC - records and standard DNSSEC NSEC records. If a NSEC record is not - Opt-In, there MUST NOT be any insecure delegations (or any other - records) between it and the RRsets indicated by the 'next domain - name' in the NSEC RDATA. If it is Opt-In, there MUST only be - insecure delegations between it and the next node indicated by the - 'next domain name' in the NSEC RDATA. - - In summary, - - o An Opt-In NSEC type is identified by a zero-valued (or not- - specified) NSEC bit in the type bit map of the NSEC record. - o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in - the type bit map of the NSEC record. - - and, - - o An Opt-In NSEC record does not assert the non-existence of a name - between its owner name and "next" name, although it does assert - that any name in this span MUST be an insecure delegation. - o An Opt-In NSEC record does assert the (non)existence of RRsets - with the same owner name. - -4.1 Server Considerations - - Opt-In imposes some new requirements on authoritative DNS servers. - -4.1.1 Delegations Only - - This specification dictates that only insecure delegations may exist - between the owner and "next" names of an Opt-In tagged NSEC record. - Signing tools SHOULD NOT generate signed zones that violate this - restriction. Servers SHOULD refuse to load and/or serve zones that - violate this restriction. Servers also SHOULD reject AXFR or IXFR - - - -Arends, et al. Expires January 19, 2006 [Page 5] - -Internet-Draft DNSSEC Opt-In July 2005 - - - responses that violate this restriction. - -4.1.2 Insecure Delegation Responses - - When returning an Opt-In insecure delegation, the server MUST return - the covering NSEC RRset in the Authority section. - - In standard DNSSEC, NSEC records already must be returned along with - the insecure delegation. The primary difference that this proposal - introduces is that the Opt-In tagged NSEC record will have a - different owner name from the delegation RRset. This may require - implementations to search for the covering NSEC RRset. - -4.1.3 Wildcards and Opt-In - - Standard DNSSEC describes the practice of returning NSEC records to - prove the non-existence of an applicable wildcard in non-existent - name responses. This NSEC record can be described as a "negative - wildcard proof". The use of Opt-In NSEC records changes the - necessity for this practice. For non-existent name responses when - the query name (qname) is covered by an Opt-In tagged NSEC record, - servers MAY choose to omit the wildcard proof record, and clients - MUST NOT treat the absence of this NSEC record as a validation error. - - The intent of the standard DNSSEC negative wildcard proof requirement - is to prevent malicious users from undetectably removing valid - wildcard responses. In order for this cryptographic proof to work, - the resolver must be able to prove: - - 1. The exact qname does not exist. This is done by the "normal" - NSEC record. - 2. No applicable wildcard exists. This is done by returning a NSEC - record proving that the wildcard does not exist (this is the - negative wildcard proof). - - However, if the NSEC record covering the exact qname is an Opt-In - NSEC record, the resolver will not be able to prove the first part of - this equation, as the qname might exist as an insecure delegation. - Thus, since the total proof cannot be completed, the negative - wildcard proof NSEC record is not useful. - - The negative wildcard proof is also not useful when returned as part - of an Opt-In insecure delegation response for a similar reason: the - resolver cannot prove that the qname does or does not exist, and - therefore cannot prove that a wildcard expansion is valid. - - The presence of an Opt-In tagged NSEC record does not change the - practice of returning a NSEC along with a wildcard expansion. Even - - - -Arends, et al. Expires January 19, 2006 [Page 6] - -Internet-Draft DNSSEC Opt-In July 2005 - - - though the Opt-In NSEC will not be able to prove that the wildcard - expansion is valid, it will prove that the wildcard expansion is not - masking any signed records. - -4.1.4 Dynamic Update - - Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In - particular, it introduces the need for rules that describe when to - add or remove a delegation name from the NSEC chain. This document - does not attempt to define these rules. Until these rules are - defined, servers MUST NOT process DNS Dynamic Update requests against - zones that use Opt-In NSEC records. Servers SHOULD return responses - to update requests with RCODE=REFUSED. - -4.2 Client Considerations - - Opt-In imposes some new requirements on security-aware resolvers - (caching or otherwise). - -4.2.1 Delegations Only - - As stated in the "Server Considerations" section above, this - specification restricts the namespace covered by Opt-In tagged NSEC - records to insecure delegations only. Thus, resolvers MUST reject as - invalid any records that fall within an Opt-In NSEC record's span - that are not NS records or corresponding glue records. - -4.2.2 Validation Process Changes - - This specification does not change the resolver's resolution - algorithm. However, it does change the DNSSEC validation process. - Resolvers MUST be able to use Opt-In tagged NSEC records to - cryptographically prove the validity and security status (as - insecure) of a referral. Resolvers determine the security status of - the referred-to zone as follows: - - o In standard DNSSEC, the security status is proven by the existence - or absence of a DS RRset at the same name as the delegation. The - existence of the DS RRset indicates that the referred-to zone is - signed. The absence of the DS RRset is proven using a verified - NSEC record of the same name that does not have the DS bit set in - the type map. This NSEC record MAY also be tagged as Opt-In. - o Using Opt-In, the security status is proven by the existence of a - DS record (for signed) or the presence of a verified Opt-In tagged - NSEC record that covers the delegation name. That is, the NSEC - record does not have the NSEC bit set in the type map, and the - delegation name falls between the NSEC's owner and "next" name. - - - - -Arends, et al. Expires January 19, 2006 [Page 7] - -Internet-Draft DNSSEC Opt-In July 2005 - - - Using Opt-In does not substantially change the nature of following - referrals within DNSSEC. At every delegation point, the resolver - will have cryptographic proof that the referred-to subzone is signed - or unsigned. - - When receiving either an Opt-In insecure delegation response or a - non-existent name response where that name is covered by an Opt-In - tagged NSEC record, the resolver MUST NOT require proof (in the form - of a NSEC record) that a wildcard did not exist. - -4.2.3 NSEC Record Caching - - Caching resolvers MUST be able to retrieve the appropriate covering - Opt-In NSEC record when returning referrals that need them. This - requirement differs from standard DNSSEC in that the covering NSEC - will not have the same owner name as the delegation. Some - implementations may have to use new methods for finding these NSEC - records. - -4.2.4 Use of the AD bit - - The AD bit, as defined by [2] and [5], MUST NOT be set when: - - o sending a Name Error (RCODE=3) response where the covering NSEC is - tagged as Opt-In. - o sending an Opt-In insecure delegation response, unless the - covering (Opt-In) NSEC record's owner name equals the delegation - name. - - This rule is based on what the Opt-In NSEC record actually proves: - for names that exist between the Opt-In NSEC record's owner and - "next" names, the Opt-In NSEC record cannot prove the non-existence - or existence of the name. As such, not all data in the response has - been cryptographically verified, so the AD bit cannot be set. - -5. Benefits - - Using Opt-In allows administrators of large and/or changing - delegation-centric zones to minimize the overhead involved in - maintaining the security of the zone. - - Opt-In accomplishes this by eliminating the need for NSEC records for - insecure delegations. This, in a zone with a large number of - delegations to unsigned subzones, can lead to substantial space - savings (both in memory and on disk). Additionally, Opt-In allows - for the addition or removal of insecure delegations without modifying - the NSEC record chain. Zones that are frequently updating insecure - delegations (e.g., TLDs) can avoid the substantial overhead of - - - -Arends, et al. Expires January 19, 2006 [Page 8] - -Internet-Draft DNSSEC Opt-In July 2005 - - - modifying and resigning the affected NSEC records. - -6. Example - - Consider the zone EXAMPLE, shown below. This is a zone where all of - the NSEC records are tagged as Opt-In. - - Example A: Fully Opt-In Zone. - - EXAMPLE. SOA ... - EXAMPLE. RRSIG SOA ... - EXAMPLE. NS FIRST-SECURE.EXAMPLE. - EXAMPLE. RRSIG NS ... - EXAMPLE. DNSKEY ... - EXAMPLE. RRSIG DNSKEY ... - EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. ( - SOA NS RRSIG DNSKEY ) - EXAMPLE. RRSIG NSEC ... - - FIRST-SECURE.EXAMPLE. A ... - FIRST-SECURE.EXAMPLE. RRSIG A ... - FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG - FIRST-SECURE.EXAMPLE. RRSIG NSEC ... - - NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. - NS.NOT-SECURE.EXAMPLE. A ... - - NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. - NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG - NOT-SECURE-2.EXAMPLE RRSIG NSEC ... - - SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. - SECOND-SECURE.EXAMPLE. DS ... - SECOND-SECURE.EXAMPLE. RRSIG DS ... - SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY - SECOND-SECURE.EXAMPLE. RRSIG NSEC ... - - UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. - NS.UNSIGNED.EXAMPLE. A ... - - - In this example, a query for a signed RRset (e.g., "FIRST- - SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- - SECURE.EXAMPLE A") will result in a standard DNSSEC response. - - A query for a nonexistent RRset will result in a response that - differs from standard DNSSEC by: the NSEC record will be tagged as - Opt-In, there may be no NSEC record proving the non-existence of a - - - -Arends, et al. Expires January 19, 2006 [Page 9] - -Internet-Draft DNSSEC Opt-In July 2005 - - - matching wildcard record, and the AD bit will not be set. - - A query for an insecure delegation RRset (or a referral) will return - both the answer (in the Authority section) and the corresponding - Opt-In NSEC record to prove that it is not secure. - - Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A - - - RCODE=NOERROR, AD=0 - - Answer Section: - - Authority Section: - UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE - SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS - SECOND-SECURE.EXAMPLE. RRSIG NSEC ... - - Additional Section: - NS.UNSIGNED.EXAMPLE. A ... - - In the Example A.1 zone, the EXAMPLE. node MAY use either style of - NSEC record, because there are no insecure delegations that occur - between it and the next node, FIRST-SECURE.EXAMPLE. In other words, - Example A would still be a valid zone if the NSEC record for EXAMPLE. - was changed to the following RR: - - EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS - RRSIG DNSKEY NSEC ) - - However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND- - SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure - delegations in the range they define. (NOT-SECURE.EXAMPLE. and - UNSIGNED.EXAMPLE., respectively). - - NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is - part of the NSEC chain and also covered by an Opt-In tagged NSEC - record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be - removed from the zone without modifying and resigning the prior NSEC - record. Delegations with names that fall between NOT-SECURE- - 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without - resigning any NSEC records. - -7. Transition Issues - - Opt-In is not backwards compatible with standard DNSSEC and is - considered experimental. Standard DNSSEC compliant implementations - would not recognize Opt-In tagged NSEC records as different from - - - -Arends, et al. Expires January 19, 2006 [Page 10] - -Internet-Draft DNSSEC Opt-In July 2005 - - - standard NSEC records. Because of this, standard DNSSEC - implementations, if they were to validate Opt-In style responses, - would reject all Opt-In insecure delegations within a zone as - invalid. However, by only signing with private algorithms, standard - DNSSEC implementations will treat Opt-In responses as unsigned. - - It should be noted that all elements in the resolution path between - (and including) the validator and the authoritative name server must - be aware of the Opt-In experiment and implement the Opt-In semantics - for successful validation to be possible. In particular, this - includes any caching middleboxes between the validator and - authoritative name server. - -8. Security Considerations - - Opt-In allows for unsigned names, in the form of delegations to - unsigned subzones, to exist within an otherwise signed zone. All - unsigned names are, by definition, insecure, and their validity or - existence cannot by cryptographically proven. - - In general: - - o Records with unsigned names (whether existing or not) suffer from - the same vulnerabilities as records in an unsigned zone. These - vulnerabilities are described in more detail in [12] (note in - particular sections 2.3, "Name Games" and 2.6, "Authenticated - Denial"). - o Records with signed names have the same security whether or not - Opt-In is used. - - Note that with or without Opt-In, an insecure delegation may have its - contents undetectably altered by an attacker. Because of this, the - primary difference in security that Opt-In introduces is the loss of - the ability to prove the existence or nonexistence of an insecure - delegation within the span of an Opt-In NSEC record. - - In particular, this means that a malicious entity may be able to - insert or delete records with unsigned names. These records are - normally NS records, but this also includes signed wildcard - expansions (while the wildcard record itself is signed, its expanded - name is an unsigned name). - - For example, if a resolver received the following response from the - example zone above: - - - - - - - -Arends, et al. Expires January 19, 2006 [Page 11] - -Internet-Draft DNSSEC Opt-In July 2005 - - - Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A - - RCODE=NOERROR - - Answer Section: - - Authority Section: - DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. - EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ - RRSIG DNSKEY - EXAMPLE. RRSIG NSEC ... - - Additional Section: - - - The resolver would have no choice but to believe that the referral to - NS.FORGED. is valid. If a wildcard existed that would have been - expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could - have undetectably removed it and replaced it with the forged - delegation. - - Note that being able to add a delegation is functionally equivalent - to being able to add any record type: an attacker merely has to forge - a delegation to nameserver under his/her control and place whatever - records needed at the subzone apex. - - While in particular cases, this issue may not present a significant - security problem, in general it should not be lightly dismissed. - Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. - In particular, zone signing tools SHOULD NOT default to Opt-In, and - MAY choose to not support Opt-In at all. - -9. IANA Considerations - - None. - -10. Acknowledgments - - The contributions, suggestions and remarks of the following persons - (in alphabetic order) to this draft are acknowledged: - - Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf - Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, - Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian - Wellington. - -11. References - - - - -Arends, et al. Expires January 19, 2006 [Page 12] - -Internet-Draft DNSSEC Opt-In July 2005 - - -11.1 Normative References - - [1] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [6] Blacka, D., "DNSSEC Experiments", - draft-ietf-dnsext-dnssec-experiments-01 (work in progress), - July 2005. - -11.2 Informative References - - [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [9] Eastlake, D., "Secure Domain Name System Dynamic Update", - RFC 2137, April 1997. - - [10] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, - December 2001. - - [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name - System (DNS)", RFC 3833, August 2004. - - - - - - - - -Arends, et al. Expires January 19, 2006 [Page 13] - -Internet-Draft DNSSEC Opt-In July 2005 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - Email: roy.arends@telin.nl - - - Mark Kosters - Verisign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - Email: markk@verisign.com - URI: http://www.verisignlabs.com - - - David Blacka - Verisign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - Email: davidb@verisign.com - URI: http://www.verisignlabs.com - -Appendix A. Implementing Opt-In using "Views" - - In many cases, it may be convenient to implement an Opt-In zone by - combining two separately maintained "views" of a zone at request - time. In this context, "view" refers to a particular version of a - zone, not to any specific DNS implementation feature. - - In this scenario, one view is the secure view, the other is the - insecure (or legacy) view. The secure view consists of an entirely - signed zone using Opt-In tagged NSEC records. The insecure view - contains no DNSSEC information. It is helpful, although not - necessary, for the secure view to be a subset (minus DNSSEC records) - of the insecure view. - - In addition, the only RRsets that may solely exist in the insecure - view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and - - - -Arends, et al. Expires January 19, 2006 [Page 14] - -Internet-Draft DNSSEC Opt-In July 2005 - - - the zone apex NS RRset) MUST be signed and in the secure view. - - These two views may be combined at request time to provide a virtual, - single Opt-In zone. The following algorithm is used when responding - to each query: - V_A is the secure view as described above. - V_B is the insecure view as described above. - R_A is a response generated from V_A, following RFC 2535bis. - R_B is a response generated from V_B, following DNS resolution as - per RFC 1035 [1]. - R_C is the response generated by combining R_A with R_B, as - described below. - A query is DNSSEC-aware if it either has the DO bit [11] turned - on, or is for a DNSSEC-specific record type. - - - - 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, - generate and return R_B, otherwise - 2. Generate R_A. - 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise - 4. Generate R_B and combine it with R_A to form R_C: - For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the - records from R_A into R_B, EXCEPT the AUTHORITY section SOA - record, if R_B's RCODE = NOERROR. - 5. Return R_C. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 19, 2006 [Page 15] - -Internet-Draft DNSSEC Opt-In July 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires January 19, 2006 [Page 16] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt deleted file mode 100644 index dd8cbf06..00000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt +++ /dev/null @@ -1,839 +0,0 @@ - -DNS Extensions Working Group R. Arends -Internet-Draft Telematica Instituut -Expires: August 25, 2005 P. Koch - DENIC eG - J. Schlyter - NIC-SE - February 21, 2005 - - - Evaluating DNSSEC Transition Mechanisms - draft-ietf-dnsext-dnssec-trans-02.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 25, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document collects and summarizes different proposals for - alternative and additional strategies for authenticated denial in DNS - responses, evaluates these proposals and gives a recommendation for a - - - -Arends, et al. Expires August 25, 2005 [Page 1] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - way forward. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 - 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 - 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 - 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5 - 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 - 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 - 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 - 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 - 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 - 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 - 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 - 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10 - 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11 - 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11 - 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 - 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 25, 2005 [Page 2] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -1. Introduction - - This report shall document the process of dealing with the NSEC - walking problem late in the Last Call for - [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, - I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion - that took place in the DNSEXT WG during the first half of June 2004 - as well as some additional ideas that came up subsequently. - - This is an edited excerpt of the chairs' mail to the WG: - The working group consents on not including NSEC-alt in the - DNSSEC-bis documents. The working group considers to take up - "prevention of zone enumeration" as a work item. - There may be multiple mechanisms to allow for co-existence with - DNSSEC-bis. The chairs allow the working group a little over a - week (up to June 12, 2004) to come to consensus on a possible - modification to the document to enable gentle rollover. If that - consensus cannot be reached the DNSSEC-bis documents will go out - as-is. - - To ease the process of getting consensus, a summary of the proposed - solutions and analysis of the pros and cons were written during the - weekend. - - This summary includes: - - An inventory of the proposed mechanisms to make a transition to - future work on authenticated denial of existence. - List the known Pros and Cons, possibly provide new arguments, and - possible security considerations of these mechanisms. - Provide a recommendation on a way forward that is least disruptive - to the DNSSEC-bis specifications as they stand and keep an open - path to other methods for authenticated denial of existence. - - The descriptions of the proposals in this document are coarse and do - not cover every detail necessary for implementation. In any case, - documentation and further study is needed before implementaion and/or - deployment, including those which seem to be solely operational in - nature. - -2. Transition Mechanisms - - In the light of recent discussions and past proposals, we have found - several ways to allow for transition to future expansion of - authenticated denial. We tried to illuminate the paths and pitfalls - in these ways forward. Some proposals lead to a versioning of - DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other - proposals are 'clean' but may cause delay, while again others may be - - - -Arends, et al. Expires August 25, 2005 [Page 3] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - plain hacks. - - Some paths do not introduce versioning, and might require the current - DNSSEC-bis documents to be fully updated to allow for extensions to - authenticated denial mechanisms. Other paths introduce versioning - and do not (or minimally) require DNSSEC-bis documents to be updated, - allowing DNSSEC-bis to be deployed, while future versions can be - drafted independent from or partially depending on DNSSEC-bis. - -2.1 Mechanisms With Need of Updating DNSSEC-bis - - Mechanisms in this category demand updates to the DNSSEC-bis document - set. - -2.1.1 Dynamic NSEC Synthesis - - This proposal assumes that NSEC RRs and the authenticating RRSIG will - be generated dynamically to just cover the (non existent) query name. - The owner name is (the) one preceding the name queried for, the Next - Owner Name Field has the value of the Query Name Field + 1 (first - successor in canonical ordering). A separate key (the normal ZSK or - a separate ZSK per authoritative server) would be used for RRSIGs on - NSEC RRs. This is a defense against enumeration, though it has the - presumption of online signing. - -2.1.1.1 Coexistence and Migration - - There is no change in interpretation other then that the next owner - name might or might not exist. - -2.1.1.2 Limitations - - This introduces an unbalanced cost between query and response - generation due to dynamic generation of signatures. - -2.1.1.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents might need to be updated to indicate - that the next owner name might not be an existing name in the zone. - This is not a real change to the spec since implementers have been - warned not to synthesize with previously cached NSEC records. A - specific bit to identify the dynamic signature generating key might - be useful as well, to prevent it from being used to fake positive - data. - -2.1.1.4 Cons - - Unbalanced cost is a ground for DDoS. Though this protects against - - - -Arends, et al. Expires August 25, 2005 [Page 4] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - enumeration, it is not really a path for versioning. - -2.1.1.5 Pros - - Hardly any amendments to DNSSEC-bis. - -2.1.2 Add Versioning/Subtyping to Current NSEC - - This proposal introduces versioning for the NSEC RR type (a.k.a. - subtyping) by adding a (one octet) version field to the NSEC RDATA. - Version number 0 is assigned to the current (DNSSEC-bis) meaning, - making this an 'Must Be Zero' (MBZ) for the to be published docset. - -2.1.2.1 Coexistence and Migration - - Since the versioning is done inside the NSEC RR, different versions - may coexist. However, depending on future methods, that may or may - not be useful inside a single zone. Resolvers cannot ask for - specific NSEC versions but may be able to indicate version support by - means of a to be defined EDNS option bit. - -2.1.2.2 Limitations - - There are no technical limitations, though it will cause delay to - allow testing of the (currently unknown) new NSEC interpretation. - - Since the versioning and signaling is done inside the NSEC RR, future - methods will likely be restricted to a single RR type authenticated - denial (as opposed to e.g. NSEC-alt, which currently proposes three - RR types). - -2.1.2.3 Amendments to DNSSEC-bis - - Full Update of the current DNSSEC-bis documents to provide for new - fields in NSEC, while specifying behavior in case of unknown field - values. - -2.1.2.4 Cons - - Though this is a clean and clear path without versioning DNSSEC, it - takes some time to design, gain consensus, update the current - dnssec-bis document, test and implement a new authenticated denial - record. - -2.1.2.5 Pros - - Does not introduce an iteration to DNSSEC while providing a clear and - clean migration strategy. - - - -Arends, et al. Expires August 25, 2005 [Page 5] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.1.3 Type Bit Map NSEC Indicator - - Bits in the type-bit-map are reused or allocated to signify the - interpretation of NSEC. - - This proposal assumes that future extensions make use of the existing - NSEC RDATA syntax, while it may need to change the interpretation of - the RDATA or introduce an alternative denial mechanism, invoked by - the specific type-bit-map-bits. - -2.1.3.1 Coexistence and migration - - Old and new NSEC meaning could coexist, depending how the signaling - would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR - types are available as well as those covering meta/query types or - types to be specifically allocated. - -2.1.3.2 Limitations - - This mechanism uses an NSEC field that was not designed for that - purpose. Similar methods were discussed during the Opt-In discussion - and the Silly-State discussion. - -2.1.3.3 Amendments to DNSSEC-bis - - The specific type-bit-map-bits must be allocated and they need to be - specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) - interpretation. Also, behaviour of the resolver and validator must - be documented in case unknown values are encountered for the MBZ - field. Currently the protocol document specifies that the validator - MUST ignore the setting of the NSEC and the RRSIG bits, while other - bits are only used for the specific purpose of the type-bit-map field - -2.1.3.4 Cons - - The type-bit-map was not designed for this purpose. It is a - straightforward hack. Text in protocol section 5.4 was put in - specially to defend against this usage. - -2.1.3.5 Pros - - No change needed to the on-the-wire protocol as specified in the - current docset. - -2.1.4 New Apex Type - - This introduces a new Apex type (parallel to the zone's SOA) - indicating the DNSSEC version (or authenticated denial) used in or - - - -Arends, et al. Expires August 25, 2005 [Page 6] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - for this zone. - -2.1.4.1 Coexistence and Migration - - Depending on the design of this new RR type multiple denial - mechanisms may coexist in a zone. Old validators will not understand - and thus ignore the new type, so interpretation of the new NSEC - scheme may fail, negative responses may appear 'bogus'. - -2.1.4.2 Limitations - - A record of this kind is likely to carry additional - feature/versioning indications unrelated to the current question of - authenticated denial. - -2.1.4.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents need to be updated to indicate that - the absence of this type indicates dnssec-bis, and that the (mere) - presence of this type indicated unknown versions. - -2.1.4.4 Cons - - The only other 'zone' or 'apex' record is the SOA record. Though - this proposal is not new, it is yet unknown how it might fulfill - authenticated denial extensions. This new RR type would only provide - for a generalized signaling mechanism, not the new authenticated - denial scheme. Since it is likely to be general in nature, due to - this generality consensus is not to be reached soon. - -2.1.4.5 Pros - - This approach would allow for a lot of other per zone information to - be transported or signaled to both (slave) servers and resolvers. - -2.1.5 NSEC White Lies - - This proposal disables one part of NSEC (the pointer part) by means - of a special target (root, apex, owner, ...), leaving intact only the - ability to authenticate denial of existence of RR sets, not denial of - existence of domain names (NXDOMAIN). It may be necessary to have - one working NSEC to prove the absence of a wildcard. - -2.1.5.1 Coexistence and Migration - - The NSEC target can be specified per RR, so standard NSEC and 'white - lie' NSEC can coexist in a zone. There is no need for migration - because no versioning is introduced or intended. - - - -Arends, et al. Expires August 25, 2005 [Page 7] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.1.5.2 Limitations - - This proposal breaks the protocol and is applicable to certain types - of zones only (no wildcard, no deep names, delegation only). Most of - the burden is put on the resolver side and operational consequences - are yet to be studied. - -2.1.5.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents need to be updated to indicate that - the NXDOMAIN responses may be insecure. - -2.1.5.4 Cons - - Strictly speaking this breaks the protocol and doesn't fully fulfill - the requirements for authenticated denial of existence. Security - implications need to be carefully documented: search path problems - (forged denial of existence may lead to wrong expansion of non-FQDNs - [RFC1535]) and replay attacks to deny existence of records. - -2.1.5.5 Pros - - Hardly any amendments to DNSSEC-bis. Operational "trick" that is - available anyway. - -2.1.6 NSEC Optional via DNSSKEY Flag - - A new DNSKEY may be defined to declare NSEC optional per zone. - -2.1.6.1 Coexistence and Migration - - Current resolvers/validators will not understand the Flag bit and - will have to treat negative responses as bogus. Otherwise, no - migration path is needed since NSEC is simply turned off. - -2.1.6.2 Limitations - - NSEC can only be made completely optional at the cost of being unable - to prove unsecure delegations (absence of a DS RR [RFC3658]). A next - to this approach would just disable authenticated denial for - non-existence of nodes. - -2.1.6.3 Amendments to DNSSEC-bis - - New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to - be specified in the light of absence of authenticated denial. - - - - - -Arends, et al. Expires August 25, 2005 [Page 8] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.1.6.4 Cons - - Doesn't fully meet requirements. Operational consequences to be - studied. - -2.1.6.5 Pros - - Official version of the "trick" presented in (8). Operational - problems can be addressed during future work on validators. - -2.1.7 New Answer Pseudo RR Type - - A new pseudo RR type may be defined that will be dynamically created - (and signed) by the responding authoritative server. The RR in the - response will cover the QNAME, QCLASS and QTYPE and will authenticate - both denial of existence of name (NXDOMAIN) or RRset. - -2.1.7.1 Coexistence and Migration - - Current resolvers/validators will not understand the pseudo RR and - will thus not be able to process negative responses so testified. A - signaling or solicitation method would have to be specified. - -2.1.7.2 Limitations - - This method can only be used with online keys and online signing - capacity. - -2.1.7.3 Amendments to DNSSEC-bis - - Signaling method needs to be defined. - -2.1.7.4 Cons - - Keys have to be held and processed online with all security - implications. An additional flag for those keys identifying them as - online or negative answer only keys should be considered. - -2.1.7.5 Pros - - Expands DNSSEC authentication to the RCODE. - -2.1.8 SIG(0) Based Authenticated Denial - - -2.1.8.1 Coexistence and Migration - - - - - -Arends, et al. Expires August 25, 2005 [Page 9] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.1.8.2 Limitations - - -2.1.8.3 Amendments to DNSSEC-bis - - -2.1.8.4 Cons - - -2.1.8.5 Pros - - -2.2 Mechanisms Without Need of Updating DNSSEC-bis - -2.2.1 Partial Type-code and Signal Rollover - - Carefully crafted type code/signal rollover to define a new - authenticated denial space that extends/replaces DNSSEC-bis - authenticated denial space. This particular path is illuminated by - Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> - posted to <namedroppers@ops.ietf.org> 2004-06-02. - -2.2.1.1 Coexistence and Migration - - To protect the current resolver for future versions, a new DNSSEC-OK - bit must be allocated to make clear it does or does not understand - the future version. Also, a new DS type needs to be allocated to - allow differentiation between a current signed delegation and a - 'future' signed delegation. Also, current NSEC needs to be rolled - into a new authenticated denial type. - -2.2.1.2 Limitations - - None. - -2.2.1.3 Amendments to DNSSEC-bis - - None. - -2.2.1.4 Cons - - It is cumbersome to carefully craft an TCR that 'just fits'. The - DNSSEC-bis protocol has many 'borderline' cases that needs special - consideration. It might be easier to do a full TCR, since a few of - the types and signals need upgrading anyway. - - - - - - -Arends, et al. Expires August 25, 2005 [Page 10] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.2.1.5 Pros - - Graceful adoption of future versions of NSEC, while there are no - amendments to DNSSEC-bis. - -2.2.2 A Complete Type-code and Signal Rollover - - A new DNSSEC space is defined which can exist independent of current - DNSSEC-bis space. - - This proposal assumes that all current DNSSEC type-codes - (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any - future versions of DNSSEC. Any future version of DNSSEC has its own - types to allow for keys, signatures, authenticated denial, etcetera. - -2.2.2.1 Coexistence and Migration - - Both spaces can co-exist. They can be made completely orthogonal. - -2.2.2.2 Limitations - - None. - -2.2.2.3 Amendments to DNSSEC-bis - - None. - -2.2.2.4 Cons - - With this path we abandon the current DNSSEC-bis. Though it is easy - to role specific well-known and well-tested parts into the re-write, - once deployment has started this path is very expensive for - implementers, registries, registrars and registrants as well as - resolvers/users. A TCR is not to be expected to occur frequently, so - while a next generation authenticated denial may be enabled by a TCR, - it is likely that that TCR will only be agreed upon if it serves a - whole basket of changes or additions. A quick introduction of - NSEC-ng should not be expected from this path. - -2.2.2.5 Pros - - No amendments/changes to current DNSSEC-bis docset needed. It is - always there as last resort. - -2.2.3 Unknown Algorithm in RRSIG - - This proposal assumes that future extensions make use of the existing - NSEC RDATA syntax, while it may need to change the interpretation of - - - -Arends, et al. Expires August 25, 2005 [Page 11] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - the RDATA or introduce an alternative denial mechanism, invoked by - the specific unknown signing algorithm. The different interpretation - would be signaled by use of different signature algorithms in the - RRSIG records covering the NSEC RRs. - - When an entire zone is signed with a single unknown algorithm, it - will cause implementations that follow current dnssec-bis documents - to treat individual RRsets as unsigned. - -2.2.3.1 Coexistence and migration - - Old and new NSEC RDATA interpretation or known and unknown Signatures - can NOT coexist in a zone since signatures cover complete (NSEC) - RRSets. - -2.2.3.2 Limitations - - Validating resolvers agnostic of new interpretation will treat the - NSEC RRset as "not signed". This affects wildcard and non-existence - proof, as well as proof for (un)secured delegations. Also, all - positive signatures (RRSIGs on RRSets other than DS, NSEC) appear - insecure/bogus to an old validator. - - The algorithm version space is split for each future version of - DNSSEC. Violation of the 'modular components' concept. We use the - 'validator' to protect the 'resolver' from unknown interpretations. - -2.2.3.3 Amendments to DNSSEC-bis - - None. - -2.2.3.4 Cons - - The algorithm field was not designed for this purpose. This is a - straightforward hack. - -2.2.3.5 Pros - - No amendments/changes to current DNSSEC-bis docset needed. - -3. Recommendation - - The authors recommend that the working group commits to and starts - work on a partial TCR, allowing graceful transition towards a future - version of NSEC. Meanwhile, to accomodate the need for an - immediately, temporary, solution against zone-traversal, we recommend - On-Demand NSEC synthesis. - - - - -Arends, et al. Expires August 25, 2005 [Page 12] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - This approach does not require any mandatory changes to DNSSEC-bis, - does not violate the protocol and fulfills the requirements. As a - side effect, it moves the cost of implementation and deployment to - the users (zone owners) of this mechanism. - -4. Acknowledgements - - The authors would like to thank Sam Weiler and Mark Andrews for their - input and constructive comments. - -5. References - -5.1 Normative References - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Massey, D., Larson, M. and S. - Rose, "DNS Security Introduction and Requirements", - Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October - 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., "Protocol Modifications for the DNS Security - Extensions", - Internet-Draft draft-ietf-dnsext-dnssec-protocol-09, - October 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., "Resource Records for the DNS Security - Extensions", - Internet-Draft draft-ietf-dnsext-dnssec-records-11, - October 2004. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - -5.2 Informative References - - [RFC1535] Gavron, E., "A Security Problem and Proposed Correction - With Widely Deployed DNS Software", RFC 1535, October - 1993. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - - - -Arends, et al. Expires August 25, 2005 [Page 13] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - RFC 2535, March 1999. - - [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, - June 1999. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Brouwerijstraat 1 - Enschede 7523 XC - The Netherlands - - Phone: +31 53 4850485 - Email: roy.arends@telin.nl - - - Peter Koch - DENIC eG - Wiesenh"uttenplatz 26 - Frankfurt 60329 - Germany - - Phone: +49 69 27235 0 - Email: pk@DENIC.DE - - - Jakob Schlyter - NIC-SE - Box 5774 - Stockholm SE-114 87 - Sweden - - Email: jakob@nic.se - URI: http://www.nic.se/ - - - - - - - - - - - - -Arends, et al. Expires August 25, 2005 [Page 14] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires August 25, 2005 [Page 15] - - diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt deleted file mode 100644 index 2460cb61..00000000 --- a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - -Network Working Group W. Hardaker -Internet-Draft Sparta -Expires: August 25, 2006 February 21, 2006 - - - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) - draft-ietf-dnsext-ds-sha256-05.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 25, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document specifies how to use the SHA-256 digest type in DNS - Delegation Signer (DS) Resource Records (RRs). DS records, when - stored in a parent zone, point to key signing DNSKEY key(s) in a - child zone. - - - - - - - - -Hardaker Expires August 25, 2006 [Page 1] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Implementing the SHA-256 algorithm for DS record support . . . 3 - 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3 - 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3 - 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4 - 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4 - 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5 - 6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 - Intellectual Property and Copyright Statements . . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 2] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -1. Introduction - - The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent - zones to distribute a cryptographic digest of a child's Key Signing - Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the - parent zone's private zone data signing keys for each algorithm in - use by the parent. Each signature is published in an RRSIG resource - record, owned by the same domain as the DS RRset and with a type - covered of DS. - - 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. Implementing the SHA-256 algorithm for DS record support - - This document specifies that the digest type code [XXX: To be - assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] - [SHA256CODE] for use within DS records. The results of the digest - algorithm MUST NOT be truncated and the entire 32 byte digest result - is to be published in the DS record. - -2.1. DS record field values - - Using the SHA-256 digest algorithm within a DS record will make use - of the following DS-record fields: - - Digest type: [XXX: To be assigned by IANA; likely 2] - - Digest: A SHA-256 bit digest value calculated by using the following - formula ("|" denotes concatenation). The resulting value is not - truncated and the entire 32 byte result is to used in the - resulting DS record and related calculations. - - digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) - - where DNSKEY RDATA is defined by [RFC4034] as: - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key - - The Key Tag field and Algorithm fields remain unchanged by this - document and are specified in the [RFC4034] specification. - -2.2. DS Record with SHA-256 Wire Format - - The resulting on-the-wire format for the resulting DS record will be - [XXX: IANA assignment should replace the 2 below]: - - - -Hardaker Expires August 25, 2006 [Page 3] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | DigestType=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest (length for SHA-256 is 32 bytes) / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - -2.3. Example DS Record Using SHA-256 - - The following is an example DNSKEY and matching DS record. This - DNSKEY record comes from the example DNSKEY/DS records found in - section 5.4 of [RFC4034]. - - The DNSKEY record: - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - The resulting DS record covering the above DNSKEY record using a SHA- - 256 digest: [RFC Editor: please replace XXX with the assigned digest - type (likely 2):] - - dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C - CEB1E3E0614B93C4F9E99B83 - 83F6A1E4469DA50A ) - - -3. Implementation Requirements - - Implementations MUST support the use of the SHA-256 algorithm in DS - RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 - digests if DS RRs with SHA-256 digests are present in the DS RRset. - - -4. Deployment Considerations - - If a validator does not support the SHA-256 digest type and no other - DS RR exists in a zone's DS RRset with a supported digest type, then - - - -Hardaker Expires August 25, 2006 [Page 4] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - the validator has no supported authentication path leading from the - parent to the child. The resolver should treat this case as it would - the case of an authenticated NSEC RRset proving that no DS RRset - exists, as described in [RFC4035], section 5.2. - - Because zone administrators can not control the deployment speed of - support for SHA-256 in validators that may be referencing any of - their zones, zone operators should consider deploying both SHA-1 and - SHA-256 based DS records. This should be done for every DNSKEY for - which DS records are being generated. Whether to make use of both - digest types and for how long is a policy decision that extends - beyond the scope of this document. - - -5. IANA Considerations - - Only one IANA action is required by this document: - - The Digest Type to be used for supporting SHA-256 within DS records - needs to be assigned by IANA. This document requests that the Digest - Type value of 2 be assigned to the SHA-256 digest algorithm. - - At the time of this writing, the current digest types assigned for - use in DS records are as follows: - - VALUE Digest Type Status - 0 Reserved - - 1 SHA-1 MANDATORY - 2 SHA-256 MANDATORY - 3-255 Unassigned - - - -6. Security Considerations - -6.1. Potential Digest Type Downgrade Attacks - - A downgrade attack from a stronger digest type to a weaker one is - possible if all of the following are true: - - o A zone includes multiple DS records for a given child's DNSKEY, - each of which use a different digest type. - - o A validator accepts a weaker digest even if a stronger one is - present but invalid. - - For example, if the following conditions are all true: - - - - - -Hardaker Expires August 25, 2006 [Page 5] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - o Both SHA-1 and SHA-256 based digests are published in DS records - within a parent zone for a given child zone's DNSKEY. - - o The DS record with the SHA-1 digest matches the digest computed - using the child zone's DNSKEY. - - o The DS record with the SHA-256 digest fails to match the digest - computed using the child zone's DNSKEY. - - Then if the validator accepts the above situation as secure then this - can be used as a downgrade attack since the stronger SHA-256 digest - is ignored. - -6.2. SHA-1 vs SHA-256 Considerations for DS Records - - Users of DNSSEC are encouraged to deploy SHA-256 as soon as software - implementations allow for it. SHA-256 is widely believed to be more - resilient to attack than SHA-1, and confidence in SHA-1's strength is - being eroded by recently-announced attacks. Regardless of whether or - not the attacks on SHA-1 will affect DNSSEC, it is believed (at the - time of this writing) that SHA-256 is the better choice for use in DS - records. - - At the time of this publication, the SHA-256 digest algorithm is - considered sufficiently strong for the immediate future. It is also - considered sufficient for use in DNSSEC DS RRs for the immediate - future. However, future published attacks may weaken the usability - of this algorithm within the DS RRs. It is beyond the scope of this - document to speculate extensively on the cryptographic strength of - the SHA-256 digest algorithm. - - Likewise, it is also beyond the scope of this document to specify - whether or for how long SHA-1 based DS records should be - simultaneously published alongside SHA-256 based DS records. - - -7. Acknowledgments - - This document is a minor extension to the existing DNSSEC documents - and those authors are gratefully appreciated for the hard work that - went into the base documents. - - The following people contributed to portions of this document in some - fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, - Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam - Weiler. - - - - - -Hardaker Expires August 25, 2006 [Page 6] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [SHA256] National Institute of Standards and Technology, "Secure - Hash Algorithm. NIST FIPS 180-2", August 2002. - -8.2. Informative References - - [SHA256CODE] - Eastlake, D., "US Secure Hash Algorithms (SHA)", - June 2005. - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 7] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Author's Address - - Wes Hardaker - Sparta - P.O. Box 382 - Davis, CA 95617 - US - - Email: hardaker@tislabs.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 8] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Hardaker Expires August 25, 2006 [Page 9] - diff --git a/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt b/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt deleted file mode 100644 index 87bce00b..00000000 --- a/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt +++ /dev/null @@ -1,17 +0,0 @@ - -This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted -from the Internet-Drafts directory. An Internet-Draft expires 185 days from -the date that it is posted unless it is replaced by an updated version, or the -Secretariat has been notified that the document is under official review by the -IESG or has been passed to the RFC Editor for review and/or publication as an -RFC. This Internet-Draft was not published as an RFC. - -Internet-Drafts are not archival documents, and copies of Internet-Drafts that have -been deleted from the directory are not available. The Secretariat does not have -any information regarding the future plans of the author(s) or working group, if -applicable, with respect to this deleted Internet-Draft. For more information, or -to request a copy of the document, please contact the author(s) directly. - -Draft Author(s): -Remco van Mook <remco@virtu.nl>, -Bert Hubert <bert.hubert@netherlabs.nl> diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt deleted file mode 100644 index 6bffb704..00000000 --- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt +++ /dev/null @@ -1,560 +0,0 @@ - -DNS Extensions O. Kolkman -Internet-Draft RIPE NCC -Expires: June 17, 2004 J. Schlyter - - E. Lewis - ARIN - December 18, 2003 - - - DNSKEY RR Secure Entry Point Flag - draft-ietf-dnsext-keyrr-key-signing-flag-12 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on June 17, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - With the Delegation Signer (DS) resource record the concept of a - public key acting as a secure entry point has been introduced. During - exchanges of public keys with the parent there is a need to - differentiate secure entry point keys from other public keys in the - DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is - defined to indicate that DNSKEY is to be used as a secure entry - point. The flag bit is intended to assist in operational procedures - to correctly generate DS resource records, or to indicate what - DNSKEYs are intended for static configuration. The flag bit is not to - - - -Kolkman, et al. Expires June 17, 2004 [Page 1] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - be used in the DNS verification protocol. This document updates RFC - 2535 and RFC 3445. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4 - 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 - 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Internationalization Considerations . . . . . . . . . . . . . . 6 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 - Normative References . . . . . . . . . . . . . . . . . . . . . . 7 - Informative References . . . . . . . . . . . . . . . . . . . . . 7 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman, et al. Expires June 17, 2004 [Page 2] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - -1. Introduction - - "All keys are equal but some keys are more equal than others" [6] - - With the definition of the Delegation Signer Resource Record (DS RR) - [5] it has become important to differentiate between the keys in the - DNSKEY RR set that are (to be) pointed to by parental DS RRs and the - other keys in the DNSKEY RR set. We refer to these public keys as - Secure Entry Point (SEP) keys. A SEP key either used to generate a - DS RR or is distributed to resolvers that use the key as the root of - a trusted subtree[3]. - - In early deployment tests, the use of two (kinds of) key pairs for - each zone has been prevalent. For one kind of key pair the private - key is used to sign just the zone's DNSKEY resource record (RR) set. - Its public key is intended to be referenced by a DS RR at the parent - or configured statically in a resolver. The private key of the other - kind of key pair is used to sign the rest of the zone's data sets. - The former key pair is called a key-signing key (KSK) and the latter - is called a zone-signing key (ZSK). In practice there have been - usually one of each kind of key pair, but there will be multiples of - each at times. - - It should be noted that division of keys pairs into KSK's and ZSK's - is not mandatory in any definition of DNSSEC, not even with the - introduction of the DS RR. But, in testing, this distinction has - been helpful when designing key roll over (key super-cession) - schemes. Given that the distinction has proven helpful, the labels - KSK and ZSK have begun to stick. - - There is a need to differentiate the public keys for the key pairs - that are used for key signing from keys that are not used key signing - (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to - be sent for generating DS RRs, which DNSKEYs are to be distributed to - resolvers, and which keys are fed to the signer application at the - appropriate time. - - In other words, the SEP bit provides an in-band method to communicate - a DNSKEY RR's intended use to third parties. As an example we present - 3 use cases in which the bit is useful: - - The parent is a registry, the parent and the child use secured DNS - queries and responses, with a preexisting trust-relation, or plain - DNS over a secured channel to exchange the child's DNSKEY RR - sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset - the SEP bit can be used to isolate the DNSKEYs for which a DS RR - needs to be created. - - - - -Kolkman, et al. Expires June 17, 2004 [Page 3] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - An administrator has configured a DNSKEY as root for a trusted - subtree into security aware resolver. Using a special purpose tool - that queries for the KEY RRs from that domain's apex, the - administrator will be able to notice the roll over of the trusted - anchor by a change of the subset of KEY RRs with the DS flag set. - - A signer might use the SEP bit on the public key to determine - which private key to use to exclusively sign the DNSKEY RRset and - which private key to use to sign the other RRsets in the zone. - - As demonstrated in the above examples it is important to be able to - differentiate the SEP keys from the other keys in a DNSKEY RR set in - the flow between signer and (parental) key-collector and in the flow - between the signer and the resolver configuration. The SEP flag is to - be of no interest to the flow between the verifier and the - authoritative data store. - - The reason for the term "SEP" is a result of the observation that the - distinction between KSK and ZSK key pairs is made by the signer, a - key pair could be used as both a KSK and a ZSK at the same time. To - be clear, the term SEP was coined to lessen the confusion caused by - the overlap. ( Once this label was applied, it had the side effect of - removing the temptation to have both a KSK flag bit and a ZSK flag - bit.) - - The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", - "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be - interpreted as described in RFC2119 [1]. - -2. The Secure Entry Point (SEP) Flag - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | flags |S| protocol | algorithm | - | |E| | | - | |P| | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - DNSKEY RR Format - - - - - - -Kolkman, et al. Expires June 17, 2004 [Page 4] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - This document assigns the 15'th bit in the flags field as the secure - entry point (SEP) bit. If the the bit is set to 1 the key is - intended to be used as secure entry point key. One SHOULD NOT assign - special meaning to the key if the bit is set to 0. Operators can - recognize the secure entry point key by the even or odd-ness of the - decimal representation of the flag field. - -3. DNSSEC Protocol Changes - - The bit MUST NOT be used during the resolving and verification - process. The SEP flag is only used to provide a hint about the - different administrative properties of the key and therefore the use - of the SEP flag does not change the DNS resolution protocol or the - resolution process. - -4. Operational Guidelines - - The SEP bit is set by the key-pair-generator and MAY be used by the - zone signer to decide whether the public part of the key pair is to - be prepared for input to a DS RR generation function. The SEP bit is - recommended to be set (to 1) whenever the public key of the key pair - will be distributed to the parent zone to build the authentication - chain or if the public key is to be distributed for static - configuration in verifiers. - - When a key pair is created, the operator needs to indicate whether - the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within - the data that is used to compute the 'key tag field' in the SIG RR, - changing the SEP bit will change the identity of the key within DNS. - In other words, once a key is used to generate signatures, the - setting of the SEP bit is to remain constant. If not, a verifier will - not be able to find the relevant KEY RR. - - When signing a zone, it is intended that the key(s) with the SEP bit - set (if such keys exist) are used to sign the KEY RR set of the zone. - The same key can be used to sign the rest of the zone data too. It - is conceivable that not all keys with a SEP bit set will sign the - DNSKEY RR set, such keys might be pending retirement or not yet in - use. - - When verifying a RR set, the SEP bit is not intended to play a role. - How the key is used by the verifier is not intended to be a - consideration at key creation time. - - Although the SEP flag provides a hint on which public key is to be - used as trusted root, administrators can choose to ignore the fact - that a DNSKEY has its SEP bit set or not when configuring a trusted - root for their resolvers. - - - -Kolkman, et al. Expires June 17, 2004 [Page 5] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - Using the SEP flag a key roll over can be automated. The parent can - use an existing trust relation to verify DNSKEY RR sets in which a - new DNSKEY RR with the SEP flag appears. - -5. Security Considerations - - As stated in Section 3 the flag is not to be used in the resolution - protocol or to determine the security status of a key. The flag is to - be used for administrative purposes only. - - No trust in a key should be inferred from this flag - trust MUST be - inferred from an existing chain of trust or an out-of-band exchange. - - Since this flag might be used for automating public key exchanges, we - think the following consideration is in place. - - Automated mechanisms for roll over of the DS RR might be vulnerable - to a class of replay attacks. This might happen after a public key - exchange where a DNSKEY RR set, containing two DNSKEY RRs with the - SEP flag set, is sent to the parent. The parent verifies the DNSKEY - RR set with the existing trust relation and creates the new DS RR - from the DNSKEY RR that the current DS RR is not pointing to. This - key exchange might be replayed. Parents are encouraged to implement a - replay defense. A simple defense can be based on a registry of keys - that have been used to generate DS RRs during the most recent roll - over. These same considerations apply to entities that configure keys - in resolvers. - -6. IANA Considerations - - The flag bits in the DNSKEY RR are assigned by IETF consensus and - registered in the DNSKEY Flags registry (created by [4]). This - document assigns the 15th bit in the DNSKEY RR as the Secure Entry - Point (SEP) bit. - -7. Internationalization Considerations - - Although SEP is a popular acronym in many different languages, there - are no internationalization considerations. - -8. Acknowledgments - - The ideas documented in this document are inspired by communications - we had with numerous people and ideas published by other folk. Among - others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, - Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler - have contributed ideas and provided feedback. - - - - -Kolkman, et al. Expires June 17, 2004 [Page 6] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - This document saw the light during a workshop on DNSSEC operations - hosted by USC/ISI in August 2002. - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [3] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [4] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work - in progress), October 2003. - -Informative References - - [5] Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-15 (work in progress), June - 2003. - - [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy - Story", ISBN 0151002177 (50th anniversary edition), April 1996. - - -Authors' Addresses - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - NL - - Phone: +31 20 535 4444 - EMail: olaf@ripe.net - URI: http://www.ripe.net/ - - - Jakob Schlyter - Karl Gustavsgatan 15 - Goteborg SE-411 25 - Sweden - - EMail: jakob@schlyter.se - - - - -Kolkman, et al. Expires June 17, 2004 [Page 7] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - Edward P. Lewis - ARIN - 3635 Concorde Parkway Suite 200 - Chantilly, VA 20151 - US - - Phone: +1 703 227 9854 - EMail: edlewis@arin.net - URI: http://www.arin.net/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman, et al. Expires June 17, 2004 [Page 8] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Kolkman, et al. Expires June 17, 2004 [Page 9] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman, et al. Expires June 17, 2004 [Page 10] - - diff --git a/doc/draft/draft-ietf-dnsext-mdns-46.txt b/doc/draft/draft-ietf-dnsext-mdns-46.txt deleted file mode 100644 index 63d0b23a..00000000 --- a/doc/draft/draft-ietf-dnsext-mdns-46.txt +++ /dev/null @@ -1,1801 +0,0 @@ - - - - - - -DNSEXT Working Group Bernard Aboba -INTERNET-DRAFT Dave Thaler -Category: Standards Track Levon Esibov -<draft-ietf-dnsext-mdns-46.txt> Microsoft Corporation -16 April 2006 - - Linklocal Multicast Name Resolution (LLMNR) - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on October 15, 2006. - -Copyright Notice - - Copyright (C) The Internet Society 2006. - -Abstract - - The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable - name resolution in scenarios in which conventional DNS name - resolution is not possible. LLMNR supports all current and future - DNS formats, types and classes, while operating on a separate port - from DNS, and with a distinct resolver cache. Since LLMNR only - operates on the local link, it cannot be considered a substitute for - DNS. - - - - - -Aboba, Thaler & Esibov Standards Track [Page 1] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -Table of Contents - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 - 1.2 Terminology ..................................... 4 -2. Name Resolution Using LLMNR ........................... 4 - 2.1 LLMNR Packet Format ............................. 5 - 2.2 Sender Behavior ................................. 8 - 2.3 Responder Behavior .............................. 8 - 2.4 Unicast Queries and Responses ................... 11 - 2.5 Off-link Detection .............................. 11 - 2.6 Responder Responsibilities ...................... 12 - 2.7 Retransmission and Jitter ....................... 13 - 2.8 DNS TTL ......................................... 14 - 2.9 Use of the Authority and Additional Sections .... 14 -3. Usage model ........................................... 15 - 3.1 LLMNR Configuration ............................. 16 -4. Conflict Resolution ................................... 18 - 4.1 Uniqueness Verification ......................... 18 - 4.2 Conflict Detection and Defense .................. 19 - 4.3 Considerations for Multiple Interfaces .......... 20 - 4.4 API issues ...................................... 22 -5. Security Considerations ............................... 22 - 5.1 Denial of Service ............................... 22 - 5.2 Spoofing ...............,........................ 23 - 5.3 Authentication .................................. 24 - 5.4 Cache and Port Separation ....................... 24 -6. IANA considerations ................................... 25 -7. Constants ............................................. 25 -8. References ............................................ 26 - 8.1 Normative References ............................ 26 - 8.2 Informative References .......................... 26 -Acknowledgments .............................................. 28 -Authors' Addresses ........................................... 28 -Intellectual Property Statement .............................. 29 -Disclaimer of Validity ....................................... 29 -Copyright Statement .......................................... 29 - - - - - - - - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 2] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -1. Introduction - - This document discusses Link Local Multicast Name Resolution (LLMNR), - which is based on the DNS packet format and supports all current and - future DNS formats, types and classes. LLMNR operates on a separate - port from the Domain Name System (DNS), with a distinct resolver - cache. - - Since LLMNR only operates on the local link, it cannot be considered - a substitute for DNS. Link-scope multicast addresses are used to - prevent propagation of LLMNR traffic across routers, potentially - flooding the network. LLMNR queries can also be sent to a unicast - address, as described in Section 2.4. - - Propagation of LLMNR packets on the local link is considered - sufficient to enable name resolution in small networks. In such - networks, if a network has a gateway, then typically the network is - able to provide DNS server configuration. Configuration issues are - discussed in Section 3.1. - - In the future, it may be desirable to consider use of multicast name - resolution with multicast scopes beyond the link-scope. This could - occur if LLMNR deployment is successful, the need arises for - multicast name resolution beyond the link-scope, or multicast routing - becomes ubiquitous. For example, expanded support for multicast name - resolution might be required for mobile ad-hoc networks. - - Once we have experience in LLMNR deployment in terms of - administrative issues, usability and impact on the network, it will - be possible to reevaluate which multicast scopes are appropriate for - use with multicast name resolution. IPv4 administratively scoped - multicast usage is specified in "Administratively Scoped IP - Multicast" [RFC2365]. - - Service discovery in general, as well as discovery of DNS servers - using LLMNR in particular, is outside of the scope of this document, - as is name resolution over non-multicast capable media. - -1.1. Requirements - - In this document, several words are used to signify the requirements - of the specification. The key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -1.2. Terminology - - This document assumes familiarity with DNS terminology defined in - [RFC1035]. Other terminology used in this document includes: - -Routable Address - An address other than a Link-Local address. This includes globally - routable addresses, as well as private addresses. - -Reachable - An LLMNR responder considers one of its addresses reachable over a - link if it will respond to an ARP or Neighbor Discovery query for - that address received on that link. - -Responder - A host that listens to LLMNR queries, and responds to those for - which it is authoritative. - -Sender - A host that sends an LLMNR query. - -UNIQUE - There are some scenarios when multiple responders may respond to - the same query. There are other scenarios when only one responder - may respond to a query. Names for which only a single responder is - anticipated are referred to as UNIQUE. Name uniqueness is - configured on the responder, and therefore uniqueness verification - is the responder's responsibility. - -2. Name Resolution Using LLMNR - - LLMNR queries are sent to and received on port 5355. The IPv4 link- - scope multicast address a given responder listens to, and to which a - sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast - address a given responder listens to, and to which a sender sends all - queries, is FF02:0:0:0:0:0:1:3. - - Typically a host is configured as both an LLMNR sender and a - responder. A host MAY be configured as a sender, but not a - responder. However, a host configured as a responder MUST act as a - sender, if only to verify the uniqueness of names as described in - Section 4. This document does not specify how names are chosen or - configured. This may occur via any mechanism, including DHCPv4 - [RFC2131] or DHCPv6 [RFC3315]. - - A typical sequence of events for LLMNR usage is as follows: - - [a] An LLMNR sender sends an LLMNR query to the link-scope - - - -Aboba, Thaler & Esibov Standards Track [Page 4] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - multicast address(es), unless a unicast query is indicated, - as specified in Section 2.4. - - [b] A responder responds to this query only if it is authoritative - for the name in the query. A responder responds to a - multicast query by sending a unicast UDP response to the sender. - Unicast queries are responded to as indicated in Section 2.4. - - [c] Upon reception of the response, the sender processes it. - - The sections that follow provide further details on sender and - responder behavior. - -2.1. LLMNR Packet Format - - LLMNR is based on the DNS packet format defined in [RFC1035] Section - 4 for both queries and responses. LLMNR implementations SHOULD send - UDP queries and responses only as large as are known to be - permissible without causing fragmentation. When in doubt a maximum - packet size of 512 octets SHOULD be used. LLMNR implementations MUST - accept UDP queries and responses as large as the smaller of the link - MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 - octets for the header, VLAN tag and CRC). - -2.1.1. LLMNR Header Format - - LLMNR queries and responses utilize the DNS header format defined in - [RFC1035] with exceptions noted below: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - - - - - -Aboba, Thaler & Esibov Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -ID A 16 bit identifier assigned by the program that generates any kind - of query. This identifier is copied from the query to the response - and can be used by the sender to match responses to outstanding - queries. The ID field in a query SHOULD be set to a pseudo-random - value. For advice on generation of pseudo-random values, please - consult [RFC1750]. - -QR Query/Response. A one bit field, which if set indicates that the - message is an LLMNR response; if clear then the message is an LLMNR - query. - -OPCODE - A four bit field that specifies the kind of query in this message. - This value is set by the originator of a query and copied into the - response. This specification defines the behavior of standard - queries and responses (opcode value of zero). Future - specifications may define the use of other opcodes with LLMNR. - LLMNR senders and responders MUST support standard queries (opcode - value of zero). LLMNR queries with unsupported OPCODE values MUST - be silently discarded by responders. - -C Conflict. When set within a request, the 'C'onflict bit indicates - that a sender has received multiple LLMNR responses to this query. - In an LLMNR response, if the name is considered UNIQUE, then the - 'C' bit is clear, otherwise it is set. LLMNR senders do not - retransmit queries with the 'C' bit set. Responders MUST NOT - respond to LLMNR queries with the 'C' bit set, but may start the - uniqueness verification process, as described in Section 4.2. - -TC TrunCation - specifies that this message was truncated due to - length greater than that permitted on the transmission channel. - The TC bit MUST NOT be set in an LLMNR query and if set is ignored - by an LLMNR responder. If the TC bit is set in an LLMNR response, - then the sender SHOULD resend the LLMNR query over TCP using the - unicast address of the responder as the destination address. If - the sender receives a response to the TCP query, then it SHOULD - discard the UDP response with the TC bit set. See [RFC2181] and - Section 2.4 of this specification for further discussion of the TC - bit. - -T Tentative. The 'T'entative bit is set in a response if the - responder is authoritative for the name, but has not yet verified - the uniqueness of the name. A responder MUST ignore the 'T' bit in - a query, if set. A response with the 'T' bit set is silently - discarded by the sender, except if it is a uniqueness query, in - which case a conflict has been detected and a responder MUST - resolve the conflict as described in Section 4.1. - - - - -Aboba, Thaler & Esibov Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -Z Reserved for future use. Implementations of this specification - MUST set these bits to zero in both queries and responses. If - these bits are set in a LLMNR query or response, implementations of - this specification MUST ignore them. Since reserved bits could - conceivably be used for different purposes than in DNS, - implementors are advised not to enable processing of these bits in - an LLMNR implementation starting from a DNS code base. - -RCODE - Response code -- this 4 bit field is set as part of LLMNR - responses. In an LLMNR query, the sender MUST set RCODE to zero; - the responder ignores the RCODE and assumes it to be zero. The - response to a multicast LLMNR query MUST have RCODE set to zero. A - sender MUST silently discard an LLMNR response with a non-zero - RCODE sent in response to a multicast query. - - If an LLMNR responder is authoritative for the name in a multicast - query, but an error is encountered, the responder SHOULD send an - LLMNR response with an RCODE of zero, no RRs in the answer section, - and the TC bit set. This will cause the query to be resent using - TCP, and allow the inclusion of a non-zero RCODE in the response to - the TCP query. Responding with the TC bit set is preferable to not - sending a response, since it enables errors to be diagnosed. This - may be required, for example, when an LLMNR query includes a TSIG - RR in the additional section, and the responder encounters a - problem that requires returning a non-zero RCODE. TSIG error - conditions defined in [RFC2845] include a TSIG RR in an - unacceptable position (RCODE=1) or a TSIG RR which does not - validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)). - - Since LLMNR responders only respond to LLMNR queries for names for - which they are authoritative, LLMNR responders MUST NOT respond - with an RCODE of 3; instead, they should not respond at all. - - LLMNR implementations MUST support EDNS0 [RFC2671] and extended - RCODE values. - -QDCOUNT - An unsigned 16 bit integer specifying the number of entries in the - question section. A sender MUST place only one question into the - question section of an LLMNR query. LLMNR responders MUST silently - discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders - MUST silently discard LLMNR responses with QDCOUNT not equal to - one. - -ANCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the answer section. LLMNR responders MUST silently - - - -Aboba, Thaler & Esibov Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - discard LLMNR queries with ANCOUNT not equal to zero. - -NSCOUNT - An unsigned 16 bit integer specifying the number of name server - resource records in the authority records section. Authority - record section processing is described in Section 2.9. LLMNR - responders MUST silently discard LLMNR queries with NSCOUNT not - equal to zero. - -ARCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the additional records section. Additional record - section processing is described in Section 2.9. - -2.2. Sender Behavior - - A sender MAY send an LLMNR query for any legal resource record type - (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. - As described in Section 2.4, a sender MAY also send a unicast query. - - The sender MUST anticipate receiving no replies to some LLMNR - queries, in the event that no responders are available within the - link-scope. If no response is received, a resolver treats it as a - response that the name does not exist (RCODE=3 is returned). A - sender can handle duplicate responses by discarding responses with a - source IP address and ID field that duplicate a response already - received. - - When multiple valid LLMNR responses are received with the 'C' bit - set, they SHOULD be concatenated and treated in the same manner that - multiple RRs received from the same DNS server would be. However, - responses with the 'C' bit set SHOULD NOT be concatenated with - responses with the 'C' bit clear; instead, only the responses with - the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are - received along with error response(s), then the error responses are - silently discarded. - - Since the responder may order the RRs in the response so as to - indicate preference, the sender SHOULD preserve ordering in the - response to the querying application. - -2.3. Responder Behavior - - An LLMNR response MUST be sent to the sender via unicast. - - Upon configuring an IP address, responders typically will synthesize - corresponding A, AAAA and PTR RRs so as to be able to respond to - LLMNR queries for these RRs. An SOA RR is synthesized only when a - - - -Aboba, Thaler & Esibov Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - responder has another RR in addition to the SOA RR; the SOA RR MUST - NOT be the only RR that a responder has. However, in general whether - RRs are manually or automatically created is an implementation - decision. - - For example, a host configured to have computer name "host1" and to - be a member of the "example.com" domain, and with IPv4 address - 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be - authoritative for the following records: - - host1. IN A 192.0.2.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - host1.example.com. IN A 192.0.2.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - 1.2.0.192.in-addr.arpa. IN PTR host1. - IN PTR host1.example.com. - - 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. - ip6.arpa IN PTR host1. (line split for formatting reasons) - IN PTR host1.example.com. - - An LLMNR responder might be further manually configured with the name - of a local mail server with an MX RR included in the "host1." and - "host1.example.com." records. - - In responding to queries: - -[a] Responders MUST listen on UDP port 5355 on the link-scope multicast - address(es) defined in Section 2, and on TCP port 5355 on the - unicast address(es) that could be set as the source address(es) - when the responder responds to the LLMNR query. - -[b] Responders MUST direct responses to the port from which the query - was sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - responder MUST take note of the source port and use that as the - destination port in the response. Responses MUST always be sent - from the port to which they were directed. - -[c] Responders MUST respond to LLMNR queries for names and addresses - they are authoritative for. This applies to both forward and - reverse lookups, with the exception of queries with the 'C' bit - set, which do not elicit a response. - -[d] Responders MUST NOT respond to LLMNR queries for names they are not - authoritative for. - - - -Aboba, Thaler & Esibov Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -[e] Responders MUST NOT respond using data from the LLMNR or DNS - resolver cache. - -[f] If a DNS server is running on a host that supports LLMNR, the DNS - server MUST respond to LLMNR queries only for the RRSets relating - to the host on which the server is running, but MUST NOT respond - for other records for which the server is authoritative. DNS - servers also MUST NOT send LLMNR queries in order to resolve DNS - queries. - -[g] If a responder is authoritative for a name, it MUST respond with - RCODE=0 and an empty answer section, if the type of query does not - match a RR that the responder has. - - As an example, a host configured to respond to LLMNR queries for the - name "foo.example.com." is authoritative for the name - "foo.example.com.". On receiving an LLMNR query for an A RR with the - name "foo.example.com." the host authoritatively responds with A - RR(s) that contain IP address(es) in the RDATA of the resource - record. If the responder has a AAAA RR, but no A RR, and an A RR - query is received, the responder would respond with RCODE=0 and an - empty answer section. - - In conventional DNS terminology a DNS server authoritative for a zone - is authoritative for all the domain names under the zone apex except - for the branches delegated into separate zones. Contrary to - conventional DNS terminology, an LLMNR responder is authoritative - only for the zone apex. - - For example the host "foo.example.com." is not authoritative for the - name "child.foo.example.com." unless the host is configured with - multiple names, including "foo.example.com." and - "child.foo.example.com.". As a result, "foo.example.com." cannot - reply to an LLMNR query for "child.foo.example.com." with RCODE=3 - (authoritative name error). The purpose of limiting the name - authority scope of a responder is to prevent complications that could - be caused by coexistence of two or more hosts with the names - representing child and parent (or grandparent) nodes in the DNS tree, - for example, "foo.example.com." and "child.foo.example.com.". - - Without the restriction on authority an LLMNR query for an A resource - record for the name "child.foo.example.com." would result in two - authoritative responses: RCODE=3 (authoritative name error) received - from "foo.example.com.", and a requested A record - from - "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled - hosts could perform a dynamic update of the parent (or grandparent) - zone with a delegation to a child zone; for example a host - "child.foo.example.com." could send a dynamic update for the NS and - - - -Aboba, Thaler & Esibov Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - glue A record to "foo.example.com.". However, this approach - significantly complicates implementation of LLMNR and would not be - acceptable for lightweight hosts. - -2.4. Unicast Queries and Responses - - Unicast queries SHOULD be sent when: - - [a] A sender repeats a query after it received a response - with the TC bit set to the previous LLMNR multicast query, or - - [b] The sender queries for a PTR RR of a fully formed IP address - within the "in-addr.arpa" or "ip6.arpa" zones. - - Unicast LLMNR queries MUST be done using TCP and the responses MUST - be sent using the same TCP connection as the query. Senders MUST - support sending TCP queries, and responders MUST support listening - for TCP queries. If the sender of a TCP query receives a response to - that query not using TCP, the response MUST be silently discarded. - - Unicast UDP queries MUST be silently discarded. - - A unicast PTR RR query for an off-link address will not elicit a - response, but instead an ICMP TTL or Hop Limit exceeded message will - be received. An implementation receiving an ICMP message in response - to a TCP connection setup attempt can return immediately, treating - this as a response that no such name exists (RCODE=3 is returned). - An implementation that cannot process ICMP messages MAY send - multicast UDP queries for PTR RRs. Since TCP implementations will - not retransmit prior to RTOmin, a considerable period will elapse - before TCP retransmits multiple times, resulting in a long timeout - for TCP PTR RR queries sent to an off-link destination. - -2.5. "Off link" Detection - - A sender MUST select a source address for LLMNR queries that is - assigned on the interface on which the query is sent. The - destination address of an LLMNR query MUST be a link-scope multicast - address or a unicast address. - - A responder MUST select a source address for responses that is - assigned on the interface on which the query was received. The - destination address of an LLMNR response MUST be a unicast address. - - On receiving an LLMNR query, the responder MUST check whether it was - sent to a LLMNR multicast addresses defined in Section 2. If it was - sent to another multicast address, then the query MUST be silently - discarded. - - - -Aboba, Thaler & Esibov Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - Section 2.4 discusses use of TCP for LLMNR queries and responses. In - composing an LLMNR query using TCP, the sender MUST set the Hop Limit - field in the IPv6 header and the TTL field in the IPv4 header of the - response to one (1). The responder SHOULD set the TTL or Hop Limit - settings on the TCP listen socket to one (1) so that SYN-ACK packets - will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This - prevents an incoming connection from off-link since the sender will - not receive a SYN-ACK from the responder. - - For UDP queries and responses, the Hop Limit field in the IPv6 header - and the TTL field in the IPV4 header MAY be set to any value. - However, it is RECOMMENDED that the value 255 be used for - compatibility with early implementations of [RFC3927]. - - Implementation note: - - In the sockets API for IPv4 [POSIX], the IP_TTL and - IP_MULTICAST_TTL socket options are used to set the TTL of - outgoing unicast and multicast packets. The IP_RECVTTL socket - option is available on some platforms to retrieve the IPv4 TTL of - received packets with recvmsg(). [RFC2292] specifies similar - options for setting and retrieving the IPv6 Hop Limit. - -2.6. Responder Responsibilities - - It is the responsibility of the responder to ensure that RRs returned - in LLMNR responses MUST only include values that are valid on the - local interface, such as IPv4 or IPv6 addresses valid on the local - link or names defended using the mechanism described in Section 4. - IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local - addresses are defined in [RFC2373]. In particular: - - [a] If a link-scope IPv6 address is returned in a AAAA RR, - that address MUST be valid on the local link over which - LLMNR is used. - - [b] If an IPv4 address is returned, it MUST be reachable - through the link over which LLMNR is used. - - [c] If a name is returned (for example in a CNAME, MX - or SRV RR), the name MUST be resolvable on the local - link over which LLMNR is used. - - Where multiple addresses represent valid responses to a query, the - order in which the addresses are returned is as follows: - - [d] If the source address of the query is a link-scope address, - then the responder SHOULD include a link-scope address first - - - -Aboba, Thaler & Esibov Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - in the response, if available. - - [e] If the source address of the query is a routable address, - then the responder MUST include a routable address first - in the response, if available. - -2.7. Retransmission and Jitter - - An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine - when to retransmit an LLMNR query. An LLMNR sender SHOULD either - estimate the LLMNR_TIMEOUT for each interface, or set a reasonably - high initial timeout. Suggested constants are described in Section - 7. - - If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, - then a sender SHOULD repeat the transmission of the query in order to - assure that it was received by a host capable of responding to it. - An LLMNR query SHOULD NOT be sent more than three times. - - Where LLMNR queries are sent using TCP, retransmission is handled by - the transport layer. Queries with the 'C' bit set MUST be sent using - multicast UDP and MUST NOT be retransmitted. - - An LLMNR sender cannot know in advance if a query sent using - multicast will receive no response, one response, or more than one - response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response - has been received, or if it is necessary to collect all potential - responses, such as if a uniqueness verification query is being made. - Otherwise an LLMNR sender SHOULD consider a multicast query answered - after the first response is received, if that response has the 'C' - bit clear. - - However, if the first response has the 'C' bit set, then the sender - SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect - all possible responses. When multiple valid answers are received, - they may first be concatenated, and then treated in the same manner - that multiple RRs received from the same DNS server would. A unicast - query sender considers the query answered after the first response is - received. - - Since it is possible for a response with the 'C' bit clear to be - followed by a response with the 'C' bit set, an LLMNR sender SHOULD - be prepared to process additional responses for the purposes of - conflict detection, even after it has considered a query answered. - - In order to avoid synchronization, the transmission of each LLMNR - query and response SHOULD delayed by a time randomly selected from - the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by - - - -Aboba, Thaler & Esibov Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - responders responding with names which they have previously - determined to be UNIQUE (see Section 4 for details). - -2.8. DNS TTL - - The responder should insert a pre-configured TTL value in the records - returned in an LLMNR response. A default value of 30 seconds is - RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc - networks), the TTL value may need to be reduced. - - Due to the TTL minimalization necessary when caching an RRset, all - TTLs in an RRset MUST be set to the same value. - -2.9. Use of the Authority and Additional Sections - - Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a - concept of delegation. In LLMNR, the NS resource record type may be - stored and queried for like any other type, but it has no special - delegation semantics as it does in the DNS. Responders MAY have NS - records associated with the names for which they are authoritative, - but they SHOULD NOT include these NS records in the authority - sections of responses. - - Responders SHOULD insert an SOA record into the authority section of - a negative response, to facilitate negative caching as specified in - [RFC2308]. The TTL of this record is set from the minimum of the - MINIMUM field of the SOA record and the TTL of the SOA itself, and - indicates how long a resolver may cache the negative answer. The - owner name of the SOA record (MNAME) MUST be set to the query name. - The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored - by senders. Negative responses without SOA records SHOULD NOT be - cached. - - In LLMNR, the additional section is primarily intended for use by - EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, - senders MAY only include pseudo RR-types in the additional section of - a query; unless the 'C' bit is set, responders MUST ignore the - additional section of queries containing other RR types. - - In queries where the 'C' bit is set, the sender SHOULD include the - conflicting RRs in the additional section. Since conflict - notifications are advisory, responders SHOULD log information from - the additional section, but otherwise MUST ignore the additional - section. - - Senders MUST NOT cache RRs from the authority or additional section - of a response as answers, though they may be used for other purposes - such as negative caching. - - - -Aboba, Thaler & Esibov Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -3. Usage Model - - LLMNR is a peer-to-peer name resolution protocol that is not intended - as a replacement for DNS; rather, it enables name resolution in - scenarios in which conventional DNS name resolution is not possible. - This includes situations in which hosts are not configured with the - address of a DNS server; where the DNS server is unavailable or - unreachable; where there is no DNS server authoritative for the name - of a host, or where the authoritative DNS server does not have the - desired RRs. - - By default, an LLMNR sender SHOULD send LLMNR queries only for - single-label names. In order to reduce unnecessary DNS queries, stub - resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS - queries for single-label names. An LLMNR sender SHOULD NOT be - enabled to send a query for any name, except where security - mechanisms (described in Section 5.3) can be utilized. - - Regardless of whether security mechanisms can be utilized, LLMNR - queries SHOULD NOT be sent unless one of the following conditions are - met: - - [1] No manual or automatic DNS configuration has been performed. - If DNS server address(es) have been configured, a - host SHOULD attempt to reach DNS servers over all protocols - on which DNS server address(es) are configured, prior to sending - LLMNR queries. For dual stack hosts configured with DNS server - address(es) for one protocol but not another, this implies that - DNS queries SHOULD be sent over the protocol configured with - a DNS server, prior to sending LLMNR queries. - - [2] All attempts to resolve the name via DNS on all interfaces - have failed after exhausting the searchlist. This can occur - because DNS servers did not respond, or because they - responded to DNS queries with RCODE=3 (Authoritative Name - Error) or RCODE=0, and an empty answer section. Where a - single resolver call generates DNS queries for A and AAAA RRs, - an implementation MAY choose not to send LLMNR queries if any - of the DNS queries is successful. An LLMNR query SHOULD only - be sent for the originally requested name; a searchlist - is not used to form additional LLMNR queries. - - Since LLMNR is a secondary name resolution mechanism, its usage is in - part determined by the behavior of DNS implementations. In general, - robust DNS resolver implementations are more likely to avoid - unnecessary LLMNR queries. - - As noted in [DNSPerf], even when DNS servers are configured, a - - - -Aboba, Thaler & Esibov Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - significant fraction of DNS queries do not receive a response, or - result in negative responses due to missing inverse mappings or NS - records that point to nonexistent or inappropriate hosts. This has - the potential to result in a large number of unnecessary LLMNR - queries. - - [RFC1536] describes common DNS implementation errors and fixes. If - the proposed fixes are implemented, unnecessary LLMNR queries will be - reduced substantially, and so implementation of [RFC1536] is - recommended. - - For example, [RFC1536] Section 1 describes issues with retransmission - and recommends implementation of a retransmission policy based on - round trip estimates, with exponential back-off. [RFC1536] Section 4 - describes issues with failover, and recommends that resolvers try - another server when they don't receive a response to a query. These - policies are likely to avoid unnecessary LLMNR queries. - - [RFC1536] Section 3 describes zero answer bugs, which if addressed - will also reduce unnecessary LLMNR queries. - - [RFC1536] Section 6 describes name error bugs and recommended - searchlist processing that will reduce unnecessary RCODE=3 - (authoritative name) errors, thereby also reducing unnecessary LLMNR - queries. - - If error responses are received from both DNS and LLMNR, then the - lowest RCODE value should be returned. For example, if either DNS or - LLMNR receives a response with RCODE=0, then this should returned to - the caller. - -3.1. LLMNR Configuration - - LLMNR usage MAY be configured manually or automatically on a per - interface basis. By default, LLMNR responders SHOULD be enabled on - all interfaces, at all times. Enabling LLMNR for use in situations - where a DNS server has been configured will result in a change in - default behavior without a simultaneous update to configuration - information. Where this is considered undesirable, LLMNR SHOULD NOT - be enabled by default, so that hosts will neither listen on the link- - scope multicast address, nor will they send queries to that address. - - Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is - possible for a dual stack host to be configured with the address of a - DNS server over IPv4, while remaining unconfigured with a DNS server - suitable for use over IPv6. - - In these situations, a dual stack host will send AAAA queries to the - - - -Aboba, Thaler & Esibov Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - configured DNS server over IPv4. However, an IPv6-only host - unconfigured with a DNS server suitable for use over IPv6 will be - unable to resolve names using DNS. Automatic IPv6 DNS configuration - mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely - deployed, and not all DNS servers support IPv6. Therefore lack of - IPv6 DNS configuration may be a common problem in the short term, and - LLMNR may prove useful in enabling link-local name resolution over - IPv6. - - Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], - IPv6-only hosts may not be configured with a DNS server. Where there - is no DNS server authoritative for the name of a host or the - authoritative DNS server does not support dynamic client update over - IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not - be able to do DNS dynamic update, and other hosts will not be able to - resolve its name. - - For example, if the configured DNS server responds to a AAAA RR query - sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or - RCODE=0 and an empty answer section, then a AAAA RR query sent using - LLMNR over IPv6 may be successful in resolving the name of an - IPv6-only host on the local link. - - Similarly, if a DHCPv4 server is available providing DNS server - configuration, and DNS server(s) exist which are authoritative for - the A RRs of local hosts and support either dynamic client update - over IPv4 or DHCPv4-based dynamic update, then the names of local - IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no - DNS server is authoritative for the names of local hosts, or the - authoritative DNS server(s) do not support dynamic update, then LLMNR - enables linklocal name resolution over IPv4. - - Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to - configure LLMNR on an interface. The LLMNR Enable Option, described - in [LLMNREnable], can be used to explicitly enable or disable use of - LLMNR on an interface. The LLMNR Enable Option does not determine - whether or in which order DNS itself is used for name resolution. - The order in which various name resolution mechanisms should be used - can be specified using the Name Service Search Option (NSSO) for DHCP - [RFC2937], using the LLMNR Enable Option code carried in the NSSO - data. - - It is possible that DNS configuration mechanisms will go in and out - of service. In these circumstances, it is possible for hosts within - an administrative domain to be inconsistent in their DNS - configuration. - - For example, where DHCP is used for configuring DNS servers, one or - - - -Aboba, Thaler & Esibov Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - more DHCP servers can fail. As a result, hosts configured prior to - the outage will be configured with a DNS server, while hosts - configured after the outage will not. Alternatively, it is possible - for the DNS configuration mechanism to continue functioning while - configured DNS servers fail. - - An outage in the DNS configuration mechanism may result in hosts - continuing to use LLMNR even once the outage is repaired. Since - LLMNR only enables linklocal name resolution, this represents a - degradation in capabilities. As a result, hosts without a configured - DNS server may wish to periodically attempt to obtain DNS - configuration if permitted by the configuration mechanism in use. In - the absence of other guidance, a default retry interval of one (1) - minute is RECOMMENDED. - -4. Conflict Resolution - - By default, a responder SHOULD be configured to behave as though its - name is UNIQUE on each interface on which LLMNR is enabled. However, - it is also possible to configure multiple responders to be - authoritative for the same name. For example, multiple responders - MAY respond to a query for an A or AAAA type record for a cluster - name (assigned to multiple hosts in the cluster). - - To detect duplicate use of a name, an administrator can use a name - resolution utility which employs LLMNR and lists both responses and - responders. This would allow an administrator to diagnose behavior - and potentially to intervene and reconfigure LLMNR responders who - should not be configured to respond to the same name. - -4.1. Uniqueness Verification - - Prior to sending an LLMNR response with the 'T' bit clear, a - responder configured with a UNIQUE name MUST verify that there is no - other host within the scope of LLMNR query propagation that is - authoritative for the same name on that interface. - - Once a responder has verified that its name is UNIQUE, if it receives - an LLMNR query for that name, with the 'C' bit clear, it MUST - respond, with the 'T' bit clear. Prior to verifying that its name is - UNIQUE, a responder MUST set the 'T' bit in responses. - - Uniqueness verification is carried out when the host: - - - starts up or is rebooted - - wakes from sleep (if the network interface was inactive - during sleep) - - is configured to respond to LLMNR queries on an interface - - - -Aboba, Thaler & Esibov Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - enabled for transmission and reception of IP traffic - - is configured to respond to LLMNR queries using additional - UNIQUE resource records - - verifies the acquisition of a new IP address and configuration - on an interface - - To verify uniqueness, a responder MUST send an LLMNR query with the - 'C' bit clear, over all protocols on which it responds to LLMNR - queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify - uniqueness of a name by sending a query for the name with type='ANY'. - - If no response is received, the sender retransmits the query, as - specified in Section 2.7. If a response is received, the sender MUST - check if the source address matches the address of any of its - interfaces; if so, then the response is not considered a conflict, - since it originates from the sender. To avoid triggering conflict - detection, a responder that detects that it is connected to the same - link on multiple interfaces SHOULD set the 'C' bit in responses. - - If a response is received with the 'T' bit clear, the responder MUST - NOT use the name in response to LLMNR queries received over any - protocol (IPv4 or IPv6). If a response is received with the 'T' bit - set, the responder MUST check if the source IP address in the - response, interpreted as an unsigned integer, is less than the source - IP address in the query. If so, the responder MUST NOT use the name - in response to LLMNR queries received over any protocol (IPv4 or - IPv6). For the purpose of uniqueness verification, the contents of - the answer section in a response is irrelevant. - - Periodically carrying out uniqueness verification in an attempt to - detect name conflicts is not necessary, wastes network bandwidth, and - may actually be detrimental. For example, if network links are - joined only briefly, and are separated again before any new - communication is initiated, temporary conflicts are benign and no - forced reconfiguration is required. LLMNR responders SHOULD NOT - periodically attempt uniqueness verification. - -4.2. Conflict Detection and Defense - - Hosts on disjoint network links may configure the same name for use - with LLMNR. If these separate network links are later joined or - bridged together, then there may be multiple hosts which are now on - the same link, trying to use the same name. - - In order to enable ongoing detection of name conflicts, when an LLMNR - sender receives multiple LLMNR responses to a query, it MUST check if - the 'C' bit is clear in any of the responses. If so, the sender - SHOULD send another query for the same name, type and class, this - - - -Aboba, Thaler & Esibov Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - time with the 'C' bit set, with the potentially conflicting resource - records included in the additional section. - - Queries with the 'C' bit set are considered advisory and responders - MUST verify the existence of a conflict before acting on it. A - responder receiving a query with the 'C' bit set MUST NOT respond. - - If the query is for a UNIQUE name, then the responder MUST send its - own query for the same name, type and class, with the 'C' bit clear. - If a response is received, the sender MUST check if the source - address matches the address of any of its interfaces; if so, then the - response is not considered a conflict, since it originates from the - sender. To avoid triggering conflict detection, a responder that - detects that it is connected to the same link on multiple interfaces - SHOULD set the 'C' bit in responses. - - An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD - log them. Upon detecting a conflict, an LLMNR responder MUST - immediately stop using the conflicting name in response to LLMNR - queries received over any supported protocol, if the source IP - address in the response, interpreted as an unsigned integer, is less - than the source IP address in the uniqueness verification query. - - After stopping the use of a name, the responder MAY elect to - configure a new name. However, since name reconfiguration may be - disruptive, this is not required, and a responder may have been - configured to respond to multiple names so that alternative names may - already be available. A host that has stopped the use of a name may - attempt uniqueness verification again after the expiration of the TTL - of the conflicting response. - -4.3. Considerations for Multiple Interfaces - - A multi-homed host may elect to configure LLMNR on only one of its - active interfaces. In many situations this will be adequate. - However, should a host need to configure LLMNR on more than one of - its active interfaces, there are some additional precautions it MUST - take. Implementers who are not planning to support LLMNR on multiple - interfaces simultaneously may skip this section. - - Where a host is configured to issue LLMNR queries on more than one - interface, each interface maintains its own independent LLMNR - resolver cache, containing the responses to LLMNR queries. - - A multi-homed host checks the uniqueness of UNIQUE records as - described in Section 4. The situation is illustrated in figure 1. - - - - - -Aboba, Thaler & Esibov Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - ---------- ---------- - | | | | - [A] [myhost] [myhost] - - Figure 1. Link-scope name conflict - - In this situation, the multi-homed myhost will probe for, and defend, - its host name on both interfaces. A conflict will be detected on one - interface, but not the other. The multi-homed myhost will not be - able to respond with a host RR for "myhost" on the interface on the - right (see Figure 1). The multi-homed host may, however, be - configured to use the "myhost" name on the interface on the left. - - Since names are only unique per-link, hosts on different links could - be using the same name. If an LLMNR client sends requests over - multiple interfaces, and receives replies from more than one, the - result returned to the client is defined by the implementation. The - situation is illustrated in figure 2. - - ---------- ---------- - | | | | - [A] [myhost] [A] - - - Figure 2. Off-segment name conflict - - If host myhost is configured to use LLMNR on both interfaces, it will - send LLMNR queries on both interfaces. When host myhost sends a - query for the host RR for name "A" it will receive a response from - hosts on both interfaces. - - Host myhost cannot distinguish between the situation shown in Figure - 2, and that shown in Figure 3 where no conflict exists. - - [A] - | | - ----- ----- - | | - [myhost] - - Figure 3. Multiple paths to same host - - This illustrates that the proposed name conflict resolution mechanism - does not support detection or resolution of conflicts between hosts - on different links. This problem can also occur with DNS when a - multi-homed host is connected to two different networks with - separated name spaces. It is not the intent of this document to - address the issue of uniqueness of names within DNS. - - - -Aboba, Thaler & Esibov Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -4.4. API Issues - - [RFC2553] provides an API which can partially solve the name - ambiguity problem for applications written to use this API, since the - sockaddr_in6 structure exposes the scope within which each scoped - address exists, and this structure can be used for both IPv4 (using - v4-mapped IPv6 addresses) and IPv6 addresses. - - Following the example in Figure 2, an application on 'myhost' issues - the request getaddrinfo("A", ...) with ai_family=AF_INET6 and - ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both - interfaces and the resolver library will return a list containing - multiple addrinfo structures, each with an associated sockaddr_in6 - structure. This list will thus contain the IPv4 and IPv6 addresses - of both hosts responding to the name 'A'. Link-local addresses will - have a sin6_scope_id value that disambiguates which interface is used - to reach the address. Of course, to the application, Figures 2 and 3 - are still indistinguishable, but this API allows the application to - communicate successfully with any address in the list. - -5. Security Considerations - - LLMNR is a peer-to-peer name resolution protocol designed for use on - the local link. While LLMNR limits the vulnerability of responders - to off-link senders, it is possible for an off-link responder to - reach a sender. - - In scenarios such as public "hotspots" attackers can be present on - the same link. These threats are most serious in wireless networks - such as 802.11, since attackers on a wired network will require - physical access to the network, while wireless attackers may mount - attacks from a distance. Link-layer security such as [IEEE-802.11i] - can be of assistance against these threats if it is available. - - This section details security measures available to mitigate threats - from on and off-link attackers. - -5.1. Denial of Service - - Attackers may take advantage of LLMNR conflict detection by - allocating the same name, denying service to other LLMNR responders - and possibly allowing an attacker to receive packets destined for - other hosts. By logging conflicts, LLMNR responders can provide - forensic evidence of these attacks. - - An attacker may spoof LLMNR queries from a victim's address in order - to mount a denial of service attack. Responders setting the IPv6 Hop - Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP - - - -Aboba, Thaler & Esibov Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - response may be able to reach the victim across the Internet. - - While LLMNR responders only respond to queries for which they are - authoritative and LLMNR does not provide wildcard query support, an - LLMNR response may be larger than the query, and an attacker can - generate multiple responses to a query for a name used by multiple - responders. A sender may protect itself against unsolicited - responses by silently discarding them as rapidly as possible. - -5.2. Spoofing - - LLMNR is designed to prevent reception of queries sent by an off-link - attacker. LLMNR requires that responders receiving UDP queries check - that they are sent to a link-scope multicast address. However, it is - possible that some routers may not properly implement link-scope - multicast, or that link-scope multicast addresses may leak into the - multicast routing system. To prevent successful setup of TCP - connections by an off-link sender, responders receiving a TCP SYN - reply with a TCP SYN-ACK with TTL set to one (1). - - While it is difficult for an off-link attacker to send an LLMNR query - to a responder, it is possible for an off-link attacker to spoof a - response to a query (such as an A or AAAA query for a popular - Internet host), and by using a TTL or Hop Limit field larger than one - (1), for the forged response to reach the LLMNR sender. Since the - forged response will only be accepted if it contains a matching ID - field, choosing a pseudo-random ID field within queries provides some - protection against off-link responders. - - Since LLMNR queries can be sent when DNS server(s) do not respond, an - attacker can execute a denial of service attack on the DNS server(s) - and then poison the LLMNR cache by responding to an LLMNR query with - incorrect information. As noted in "Threat Analysis of the Domain - Name System (DNS)" [RFC3833] these threats also exist with DNS, since - DNS response spoofing tools are available that can allow an attacker - to respond to a query more quickly than a distant DNS server. - However, while switched networks or link layer security may make it - difficult for an on-link attacker to snoop unicast DNS queries, - multicast LLMNR queries are propagated to all hosts on the link, - making it possible for an on-link attacker to spoof LLMNR responses - without having to guess the value of the ID field in the query. - - Since LLMNR queries are sent and responded to on the local-link, an - attacker will need to respond more quickly to provide its own - response prior to arrival of the response from a legitimate - responder. If an LLMNR query is sent for an off-link host, spoofing - a response in a timely way is not difficult, since a legitimate - response will never be received. - - - -Aboba, Thaler & Esibov Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - This vulnerability can be reduced by limiting use of LLMNR to - resolution of single-label names as described in Section 3, or by - implementation of authentication (see Section 5.3). - -5.3. Authentication - - LLMNR is a peer-to-peer name resolution protocol, and as a result, - it is often deployed in situations where no trust model can be - assumed. Where a pre-arranged security configuration is possible, - the following security mechanisms may be used: - -[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) - [RFC2931] security mechanisms. "DNS Name Service based on Secure - Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes - the use of TSIG to secure LLMNR, based on group keys. While group - keys can be used to demonstrate membership in a group, they do not - protect against forgery by an attacker that is a member of the - group. - -[b] IPsec ESP with a null-transform MAY be used to authenticate unicast - LLMNR queries and responses or LLMNR responses to multicast - queries. In a small network without a certificate authority, this - can be most easily accomplished through configuration of a group - pre-shared key for trusted hosts. As with TSIG, this does not - protect against forgery by an attacker with access to the group - pre-shared key. - -[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to - support DNSSEC, LLMNR implementations MAY be configured with trust - anchors, or they MAY make use of keys obtained from DNS queries. - Since LLMNR does not support "delegated trust" (CD or AD bits), - LLMNR implementations cannot make use of DNSSEC unless they are - DNSSEC-aware and support validation. Unlike approaches [a] or [b], - DNSSEC permits a responder to demonstrate ownership of a name, not - just membership within a trusted group. As a result, it enables - protection against forgery. - -5.4. Cache and Port Separation - - In order to prevent responses to LLMNR queries from polluting the DNS - cache, LLMNR implementations MUST use a distinct, isolated cache for - LLMNR on each interface. The use of separate caches is most - effective when LLMNR is used as a name resolution mechanism of last - resort, since this minimizes the opportunities for poisoning the - LLMNR cache, and decreases reliance on it. - - LLMNR operates on a separate port from DNS, reducing the likelihood - that a DNS server will unintentionally respond to an LLMNR query. - - - -Aboba, Thaler & Esibov Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - If LLMNR is given higher priority than DNS among the enabled name - resolution mechanisms, a denial of service attack on the DNS server - would not be necessary in order to poison the LLMNR cache, since - LLMNR queries would be sent even when the DNS server is available. - In addition, the LLMNR cache, once poisoned, would take precedence - over the DNS cache, eliminating the benefits of cache separation. As - a result, LLMNR SHOULD NOT be used as a primary name resolution - mechanism. - -6. IANA Considerations - - LLMNR requires allocation of port 5355 for both TCP and UDP. - - LLMNR requires allocation of link-scope multicast IPv4 address - 224.0.0.252, as well as link-scope multicast IPv6 address - FF02:0:0:0:0:0:1:3. - - This specification creates two new name spaces: the LLMNR namespace - and the reserved bits in the LLMNR header. The reserved bits in the - LLMNR header are allocated by IETF Consensus, in accordance with BCP - 26 [RFC2434]. - - In order to to avoid creating any new administrative procedures, - administration of the LLMNR namespace will piggyback on the - administration of the DNS namespace. - - The rights to use a fully qualified domain name (FQDN) within LLMNR - are obtained coincident with acquiring the rights to use that name - within DNS. Those wishing to use a FQDN within LLMNR should first - acquire the rights to use the corresponding FQDN within DNS. Using a - FQDN within LLMNR without ownership of the corresponding name in DNS - creates the possibility of conflict and therefore is discouraged. - - LLMNR responders may self-allocate a name within the single-label - name space, first defined in [RFC1001]. Since single-label names are - not unique, no registration process is required. - -7. Constants - - The following timing constants are used in this protocol; they are - not intended to be user configurable. - - JITTER_INTERVAL 100 ms - LLMNR_TIMEOUT 1 second (if set statically on all interfaces) - 100 ms (IEEE 802 media, including IEEE 802.11) - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -8. References - -8.1. Normative References - -[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS - Service on a TCP/UDP Transport: Concepts and Methods", RFC - 1001, March 1987. - -[RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. - -[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - -[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - -[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - -[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - -[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - -[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - -[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - -8.2. Informative References - -[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of - Caching", IEEE/ACM Transactions on Networking, Volume 10, - Number 5, pp. 589, October 2002. - -[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local - unicast addresses to communicate with recursive DNS servers", - Internet draft (work in progress), draft-ietf-ipv6-dns- - discovery-07.txt, October 2002. - - - - -Aboba, Thaler & Esibov Standards Track [Page 26] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -[IEEE-802.11i] - Institute of Electrical and Electronics Engineers, "Supplement - to Standard for Telecommunications and Information Exchange - Between Systems - LAN/MAN Specific Requirements - Part 11: - Wireless LAN Medium Access Control (MAC) and Physical Layer - (PHY) Specifications: Specification for Enhanced Security", - IEEE 802.11i, July 2004. - -[LLMNREnable] - Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work - in progress), draft-guttman-mdns-enable-02.txt, April 2002. - -[LLMNRSec] - Jeong, J., Park, J. and H. Kim, "DNS Name Service based on - Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT - 2004, Phoenix Park, Korea, February 9-11, 2004. - -[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December - 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin - -[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested - Fixes", RFC 1536, October 1993. - -[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - -[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - -[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - -[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - -[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic - Socket Interface Extensions for IPv6", RFC 2553, March 1999. - -[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC - 2937, September 2000. - -[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - -[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name - System (DNS)", RFC 3833, August 2004. - - - -Aboba, Thaler & Esibov Standards Track [Page 27] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of Link-Local IPv4 Addresses", RFC 3927, October 2004. - -[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "DNS Security Introduction and Requirement", RFC 4033, March - 2005. - -Acknowledgments - - This work builds upon original work done on multicast DNS by Bill - Manning and Bill Woodcock. Bill Manning's work was funded under - DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge - their contribution to the current specification. Constructive input - has also been received from Mark Andrews, Rob Austein, Randy Bush, - Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur - Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, - Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, - Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike - St. Johns, Sander Van-Valkenburg, and Brian Zill. - -Authors' Addresses - - Bernard Aboba - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 706 6605 - EMail: bernarda@microsoft.com - - Dave Thaler - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 703 8835 - EMail: dthaler@microsoft.com - - Levon Esibov - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - EMail: levone@microsoft.com - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 28] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 29] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -Open Issues - - Open issues with this specification are tracked on the following web - site: - - http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 30] - - - diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt deleted file mode 100644 index 90d1a060..00000000 --- a/doc/draft/draft-ietf-dnsext-nsid-01.txt +++ /dev/null @@ -1,840 +0,0 @@ - - - -Network Working Group R. Austein -Internet-Draft ISC -Expires: July 15, 2006 January 11, 2006 - - - DNS Name Server Identifier Option (NSID) - draft-ietf-dnsext-nsid-01 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 15, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. While existing ad-hoc - mechanism allow an operator to send follow-up queries when it is - necessary to debug such a configuration, the only completely reliable - way to obtain the identity of the name server which responded is to - have the name server include this information in the response itself. - This note defines a protocol extension to support this functionality. - - - -Austein Expires July 15, 2006 [Page 1] - -Internet-Draft DNS NSID January 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4 - 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 - 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5 - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8 - 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8 - 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 2] - -Internet-Draft DNS NSID January 2006 - - -1. Introduction - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. - - Existing ad-hoc mechanisms allow an operator to send follow-up - queries when it is necessary to debug such a configuration, but there - are situations in which this is not a totally satisfactory solution, - since anycast routing may have changed, or the server pool in - question may be behind some kind of extremely dynamic load balancing - hardware. Thus, while these ad-hoc mechanisms are certainly better - than nothing (and have the advantage of already being deployed), a - better solution seems desirable. - - Given that a DNS query is an idempotent operation with no retained - state, it would appear that the only completely reliable way to - obtain the identity of the name server which responded to a - particular query is to have that name server include identifying - information in the response itself. This note defines a protocol - enhancement to achieve this. - -1.1. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 3] - -Internet-Draft DNS NSID January 2006 - - -2. Protocol - - This note uses an EDNS [RFC2671] option to signal the resolver's - desire for information identifying the name server and to hold the - name server's response, if any. - -2.1. Resolver Behavior - - A resolver signals its desire for information identifying a name - server by sending an empty NSID option (Section 2.3) in an EDNS OPT - pseudo-RR in the query message. - - The resolver MUST NOT include any NSID payload data in the query - message. - - The semantics of an NSID request are not transitive. That is: the - presence of an NSID option in a query is a request that the name - server which receives the query identify itself. If the name server - side of a recursive name server receives an NSID request, the client - is asking the recursive name server to identify itself; if the - resolver side of the recursive name server wishes to receive - identifying information, it is free to add NSID requests in its own - queries, but that is a separate matter. - -2.2. Name Server Behavior - - A name server which understands the NSID option and chooses to honor - a particular NSID request responds by including identifying - information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR - in the response message. - - The name server MUST ignore any NSID payload data that might be - present in the query message. - - The NSID option is not transitive. A name server MUST NOT send an - NSID option back to a resolver which did not request it. In - particular, while a recursive name server may choose to add an NSID - option when sending a query, this has no effect on the presence or - absence of the NSID option in the recursive name server's response to - the original client. - - As stated in Section 2.1, this mechanism is not restricted to - authoritative name servers; the semantics are intended to be equally - applicable to recursive name servers. - -2.3. The NSID Option - - The OPTION-CODE for the NSID option is [TBD]. - - - -Austein Expires July 15, 2006 [Page 4] - -Internet-Draft DNS NSID January 2006 - - - The OPTION-DATA for the NSID option is an opaque byte string the - semantics of which are deliberately left outside the protocol. See - Section 3.1 for discussion. - -2.4. Presentation Format - - User interfaces MUST read and write the content of the NSID option as - a sequence of hexadecimal digits, two digits per payload octet. - - The NSID payload is binary data. Any comparison between NSID - payloads MUST be a comparison of the raw binary data. Copy - operations MUST NOT assume that the raw NSID payload is null- - terminated. Any resemblance between raw NSID payload data and any - form of text is purely a convenience, and does not change the - underlying nature of the payload data. - - See Section 3.3 for discussion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 5] - -Internet-Draft DNS NSID January 2006 - - -3. Discussion - - This section discusses certain aspects of the protocol and explains - considerations that led to the chosen design. - -3.1. The NSID Payload - - The syntax and semantics of the content of the NSID option is - deliberately left outside the scope of this specification. This - section describe some of the kinds of data that server administrators - might choose to provide as the content of the NSID option, and - explains the reasoning behind choosing a simple opaque byte string. - - There are several possibilities for the payload of the NSID option: - - o It could be the "real" name of the specific name server within the - name server pool. - - o It could be the "real" IP address (IPv4 or IPv6) of the name - server within the name server pool. - - o It could be some sort of pseudo-random number generated in a - predictable fashion somehow using the server's IP address or name - as a seed value. - - o It could be some sort of probabilisticly unique identifier - initially derived from some sort of random number generator then - preserved across reboots of the name server. - - o It could be some sort of dynamicly generated identifier so that - only the name server operator could tell whether or not any two - queries had been answered by the same server. - - o It could be a blob of signed data, with a corresponding key which - might (or might not) be available via DNS lookups. - - o It could be a blob of encrypted data, the key for which could be - restricted to parties with a need to know (in the opinion of the - server operator). - - o It could be an arbitrary string of octets chosen at the discretion - of the name server operator. - - Each of these options has advantages and disadvantages: - - o Using the "real" name is simple, but the name server may not have - a "real" name. - - - - -Austein Expires July 15, 2006 [Page 6] - -Internet-Draft DNS NSID January 2006 - - - o Using the "real" address is also simple, and the name server - almost certainly does have at least one non-anycast IP address for - maintenance operations, but the operator of the name server may - not be willing to divulge its non-anycast address. - - o Given that one common reason for using anycast DNS techniques is - an attempt to harden a critical name server against denial of - service attacks, some name server operators are likely to want an - identifier other than the "real" name or "real" address of the - name server instance. - - o Using a hash or pseudo-random number can provide a fixed length - value that the resolver can use to tell two name servers apart - without necessarily being able to tell where either one of them - "really" is, but makes debugging more difficult if one happens to - be in a friendly open environment. Furthermore, hashing might not - add much value, since a hash based on an IPv4 address still only - involves a 32-bit search space, and DNS names used for servers - that operators might have to debug at 4am tend not to be very - random. - - o Probabilisticly unique identifiers have similar properties to - hashed identifiers, but (given a sufficiently good random number - generator) are immune to the search space issues. However, the - strength of this approach is also its weakness: there is no - algorithmic transformation by which even the server operator can - associate name server instances with identifiers while debugging, - which might be annoying. This approach also requires the name - server instance to preserve the probabilisticly unique identifier - across reboots, but this does not appear to be a serious - restriction, since authoritative nameservers almost always have - some form of nonvolatile storage in any case, and in the rare case - of a name server that does not have any way to store such an - identifier, nothing terrible will happen if the name server just - generates a new identifier every time it reboots. - - o Using an arbitrary octet string gives name server operators yet - another thing to configure, or mis-configure, or forget to - configure. Having all the nodes in an anycast name server - constellation identify themselves as "My Name Server" would not be - particularly useful. - - Given all of the issues listed above, there does not appear to be a - single solution that will meet all needs. Section 2.3 therefore - defines the NSID payload to be an opaque byte string and leaves the - choice up to the implementor and name server operator. The following - guidelines may be useful to implementors and server operators: - - - - -Austein Expires July 15, 2006 [Page 7] - -Internet-Draft DNS NSID January 2006 - - - o Operators for whom divulging the unicast address is an issue could - use the raw binary representation of a probabilisticly unique - random number. This should probably be the default implementation - behavior. - - o Operators for whom divulging the unicast address is not an issue - could just use the raw binary representation of a unicast address - for simplicity. This should only be done via an explicit - configuration choice by the operator. - - o Operators who really need or want the ability to set the NSID - payload to an arbitrary value could do so, but this should only be - done via an explicit configuration choice by the operator. - - This approach appears to provide enough information for useful - debugging without unintentionally leaking the maintenance addresses - of anycast name servers to nogoodniks, while also allowing name - server operators who do not find such leakage threatening to provide - more information at their own discretion. - -3.2. NSID Is Not Transitive - - As specified in Section 2.1 and Section 2.2, the NSID option is not - transitive. This is strictly a hop-by-hop mechanism. - - Most of the discussion of name server identification to date has - focused on identifying authoritative name servers, since the best - known cases of anycast name servers are a subset of the name servers - for the root zone. However, given that anycast DNS techniques are - also applicable to recursive name servers, the mechanism may also be - useful with recursive name servers. The hop-by-hop semantics support - this. - - While there might be some utility in having a transitive variant of - this mechanism (so that, for example, a stub resolver could ask a - recursive server to tell it which authoritative name server provided - a particular answer to the recursive name server), the semantics of - such a variant would be more complicated, and are left for future - work. - -3.3. User Interface Issues - - Given the range of possible payload contents described in - Section 3.1, it is not possible to define a single presentation - format for the NSID payload that is efficient, convenient, - unambiguous, and aesthetically pleasing. In particular, while it is - tempting to use a presentation format that uses some form of textual - strings, attempting to support this would significantly complicate - - - -Austein Expires July 15, 2006 [Page 8] - -Internet-Draft DNS NSID January 2006 - - - what's intended to be a very simple debugging mechanism. - - In some cases the content of the NSID payload may be binary data - meaningful only to the name server operator, and may not be - meaningful to the user or application, but the user or application - must be able to capture the entire content anyway in order for it to - be useful. Thus, the presentation format must support arbitrary - binary data. - - In cases where the name server operator derives the NSID payload from - textual data, a textual form such as US-ASCII or UTF-8 strings might - at first glance seem easier for a user to deal with. There are, - however, a number of complex issues involving internationalized text - which, if fully addressed here, would require a set of rules - significantly longer than the rest of this specification. See - [RFC2277] for an overview of some of these issues. - - It is much more important for the NSID payload data to be passed - unambiguously from server administrator to user and back again than - it is for the payload data data to be pretty while in transit. In - particular, it's critical that it be straightforward for a user to - cut and paste an exact copy of the NSID payload output by a debugging - tool into other formats such as email messages or web forms without - distortion. Hexadecimal strings, while ugly, are also robust. - -3.4. Truncation - - In some cases, adding the NSID option to a response message may - trigger message truncation. This specification does not change the - rules for DNS message truncation in any way, but implementors will - need to pay attention to this issue. - - Including the NSID option in a response is always optional, so this - specification never requires name servers to truncate response - messages. - - By definition, a resolver that requests NSID responses also supports - EDNS, so a resolver that requests NSID responses can also use the - "sender's UDP payload size" field of the OPT pseudo-RR to signal a - receive buffer size large enough to make truncation unlikely. - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 9] - -Internet-Draft DNS NSID January 2006 - - -4. IANA Considerations - - This mechanism requires allocation of one ENDS option code for the - NSID option (Section 2.3). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 10] - -Internet-Draft DNS NSID January 2006 - - -5. Security Considerations - - This document describes a channel signaling mechanism, intended - primarily for debugging. Channel signaling mechanisms are outside - the scope of DNSSEC per se. Applications that require integrity - protection for the data being signaled will need to use a channel - security mechanism such as TSIG [RFC2845]. - - Section 3.1 discusses a number of different kinds of information that - a name server operator might choose to provide as the value of the - NSID option. Some of these kinds of information are security - sensitive in some environments. This specification deliberately - leaves the syntax and semantics of the NSID option content up to the - implementation and the name server operator. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 11] - -Internet-Draft DNS NSID January 2006 - - -6. Acknowledgements - - Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve - Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg, - Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and - Suzanne Woolf. Apologies to anyone inadvertently omitted from the - above list. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 12] - -Internet-Draft DNS NSID January 2006 - - -7. References - -7.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - -7.2. Informative References - - [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and - Languages", RFC 2277, BCP 18, January 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 13] - -Internet-Draft DNS NSID January 2006 - - -Author's Address - - Rob Austein - ISC - 950 Charter Street - Redwood City, CA 94063 - USA - - Email: sra@isc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 14] - -Internet-Draft DNS NSID January 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Austein Expires July 15, 2006 [Page 15] - diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt deleted file mode 100644 index e169da86..00000000 --- a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt +++ /dev/null @@ -1,464 +0,0 @@ - -INTERNET-DRAFT DSA Information in the DNS -OBSOLETES: RFC 2536 Donald E. Eastlake 3rd - Motorola Laboratories -Expires: September 2006 March 2006 - - - DSA Keying and Signature Information in the DNS - --- ------ --- --------- ----------- -- --- --- - <draft-ietf-dnsext-rfc2536bis-dsa-07.txt> - Donald E. Eastlake 3rd - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this document is unlimited. Comments should be sent - to the DNS extensions working group mailing list - <namedroppers@ops.ietf.org>. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - - -Abstract - - The standard method of encoding US Government Digital Signature - Algorithm keying and signature information for use in the Domain Name - System is specified. - - - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DSA Information in the DNS - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. DSA Keying Information..................................3 - 3. DSA Signature Information...............................4 - 4. Performance Considerations..............................4 - 5. Security Considerations.................................5 - 6. IANA Considerations.....................................5 - Copyright, Disclaimer, and Additional IPR Provisions.......5 - - Normative References.......................................7 - Informative References.....................................7 - - Author's Address...........................................8 - Expiration and File Name...................................8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DSA Information in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information [RFC 1034, 1035]. The DNS has been extended to - include digital signatures and cryptographic keys as described in - [RFC 4033, 4034, 4035] and additional work is underway which would - require the storage of keying and signature information in the DNS. - - This document describes how to encode US Government Digital Signature - Algorithm (DSA) keys and signatures in the DNS. Familiarity with the - US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier]. - - - -2. DSA Keying Information - - When DSA public keys are stored in the DNS, the structure of the - relevant part of the RDATA part of the RR being used is the fields - listed below in the order given. - - The period of key validity is not included in this data but is - indicated separately, for example by an RR such as RRSIG which signs - and authenticates the RR containing the keying information. - - Field Size - ----- ---- - T 1 octet - Q 20 octets - P 64 + T*8 octets - G 64 + T*8 octets - Y 64 + T*8 octets - - As described in [FIPS 186-2] and [Schneier], T is a key size - parameter chosen such that 0 <= T <= 8. (The meaning if the T octet - is greater than 8 is reserved and the remainder of the data may have - a different format in that case.) Q is a prime number selected at - key generation time such that 2**159 < Q < 2**160. Thus Q is always - 20 octets long and, as with all other fields, is stored in "big- - endian" network order. P, G, and Y are calculated as directed by the - [FIPS 186-2] key generation algorithm [Schneier]. P is in the range - 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G - and Y are quantities modulo P and so can be up to the same length as - P and are allocated fixed size fields with the same number of octets - as P. - - During the key generation process, a random number X must be - generated such that 1 <= X <= Q-1. X is the private key and is used - in the final step of public key generation where Y is computed as - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DSA Information in the DNS - - - Y = G**X mod P - - - -3. DSA Signature Information - - The portion of the RDATA area used for US Digital Signature Algorithm - signature information is shown below with fields in the order they - are listed and the contents of each multi-octet field in "big-endian" - network order. - - Field Size - ----- ---- - T 1 octet - R 20 octets - S 20 octets - - First, the data signed must be determined. Then the following steps - are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as - specified in the public key [Schneier]: - - hash = SHA-1 ( data ) - - Generate a random K such that 0 < K < Q. - - R = ( G**K mod P ) mod Q - - S = ( K**(-1) * (hash + X*R) ) mod Q - - For information on the SHA-1 hash function see [FIPS 180-2] and [RFC - 3174]. - - Since Q is 160 bits long, R and S can not be larger than 20 octets, - which is the space allocated. - - T is copied from the public key. It is not logically necessary in - the SIG but is present so that values of T > 8 can more conveniently - be used as an escape for extended versions of DSA or other algorithms - as later standardized. - - - -4. Performance Considerations - - General signature generation speeds are roughly the same for RSA [RFC - 3110] and DSA. With sufficient pre-computation, signature generation - with DSA is faster than RSA. Key generation is also faster for DSA. - However, signature verification is an order of magnitude slower than - RSA when the RSA public exponent is chosen to be small, as is - recommended for some applications. - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DSA Information in the DNS - - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including DNS overhead. Larger - transfers will perform correctly and extensions have been - standardized [RFC 2671] to make larger transfers more efficient, it - is still advisable at this time to make reasonable efforts to - minimize the size of RR sets containing keying and/or signature - inforamtion consistent with adequate security. - - - -5. Security Considerations - - Keys retrieved from the DNS should not be trusted unless (1) they - have been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. As with all cryptographic algorithms, - evaluating the necessary strength of the key is essential and - dependent on local policy. - - The key size limitation of a maximum of 1024 bits ( T = 8 ) in the - current DSA standard may limit the security of DSA. For particular - applications, implementors are encouraged to consider the range of - available algorithms and key sizes. - - DSA assumes the ability to frequently generate high quality random - numbers. See [random] for guidance. DSA is designed so that if - biased rather than random numbers are used, high bandwidth covert - channels are possible. See [Schneier] and more recent research. The - leakage of an entire DSA private key in only two DSA signatures has - been demonstrated. DSA provides security only if trusted - implementations, including trusted random number generation, are - used. - - - -6. IANA Considerations - - Allocation of meaning to values of the T parameter that are not - defined herein (i.e., > 8 ) requires an IETF standards actions. It - is intended that values unallocated herein be used to cover future - extensions of the DSS standard. - - - -Copyright, Disclaimer, and Additional IPR Provisions - - Copyright (C) The Internet Society (2006). This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DSA Information in the DNS - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DSA Information in the DNS - - -Normative References - - [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital - Signature Standard, 27 January 2000. - - [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - - -Informative References - - [RFC 1034] - "Domain names - concepts and facilities", P. - Mockapetris, 11/01/1987. - - [RFC 1035] - "Domain names - implementation and specification", P. - Mockapetris, 11/01/1987. - - [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August - 1999. - - [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System - (DNS)", D. Eastlake 3rd. May 2001. - - [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P. - Jones, September 2001. - - [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. - - [Schneier] - "Applied Cryptography Second Edition: protocols, - algorithms, and source code in C" (second edition), Bruce Schneier, - 1996, John Wiley and Sons, ISBN 0-471-11709-9. - - - - - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DSA Information in the DNS - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Labortories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554(w) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in September 2006. - - Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt deleted file mode 100644 index f6e8588e..00000000 --- a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt +++ /dev/null @@ -1,580 +0,0 @@ - -INTERNET-DRAFT Diffie-Hellman Information in the DNS -OBSOLETES: RFC 2539 Donald E. Eastlake 3rd - Motorola Laboratories -Expires: September 2006 March 2006 - - - - - Storage of Diffie-Hellman Keying Information in the DNS - ------- -- -------------- ------ ----------- -- --- --- - <draft-ietf-dnsext-rfc2539bis-dhk-07.txt> - - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this document is unlimited. Comments should be sent - to the DNS extensions working group mailing list - <namedroppers@ops.ietf.org>. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - The standard method for encoding Diffie-Hellman keys in the Domain - Name System is specified. - - - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Acknowledgements - - Part of the format for Diffie-Hellman keys and the description - thereof was taken from a work in progress by Ashar Aziz, Tom Markson, - and Hemma Prafullchandra. In addition, the following persons - provided useful comments that were incorporated into the predecessor - of this document: Ran Atkinson, Thomas Narten. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Acknowledgements...........................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 1.1 About This Document....................................3 - 1.2 About Diffie-Hellman...................................3 - 2. Encoding Diffie-Hellman Keying Information..............4 - 3. Performance Considerations..............................5 - 4. IANA Considerations.....................................5 - 5. Security Considerations.................................5 - Copyright, Disclaimer, and Additional IPR Provisions.......5 - - Normative References.......................................7 - Informative Refences.......................................7 - - Author's Address...........................................8 - Expiration and File Name...................................8 - - Appendix A: Well known prime/generator pairs...............9 - A.1. Well-Known Group 1: A 768 bit prime..................9 - A.2. Well-Known Group 2: A 1024 bit prime.................9 - A.3. Well-Known Group 3: A 1536 bit prime................10 - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - similar information [RFC 1034, 1035]. The DNS has been extended to - include digital signatures and cryptographic keys as described in - [RFC 4033, 4034, 4035] and additonal work is underway which would use - the storage of keying information in the DNS. - - - -1.1 About This Document - - This document describes how to store Diffie-Hellman keys in the DNS. - Familiarity with the Diffie-Hellman key exchange algorithm is assumed - [Schneier, RFC 2631]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. - - - -1.2 About Diffie-Hellman - - Diffie-Hellman requires two parties to interact to derive keying - information which can then be used for authentication. Thus Diffie- - Hellman is inherently a key agreement algorithm. As a result, no - format is defined for Diffie-Hellman "signature information". For - example, assume that two parties have local secrets "i" and "j". - Assume they each respectively calculate X and Y as follows: - - X = g**i ( mod p ) - - Y = g**j ( mod p ) - - They exchange these quantities and then each calculates a Z as - follows: - - Zi = Y**i ( mod p ) - - Zj = X**j ( mod p ) - - Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared - secret between the two parties that an adversary who does not know i - or j will not be able to learn from the exchanged messages (unless - the adversary can derive i or j by performing a discrete logarithm - mod p which is hard for strong p and g). - - The private key for each party is their secret i (or j). The public - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - - key is the pair p and g, which is the same for both parties, and - their individual X (or Y). - - For further information about Diffie-Hellman and precautions to take - in deciding on a p and g, see [RFC 2631]. - - - -2. Encoding Diffie-Hellman Keying Information - - When Diffie-Hellman keys appear within the RDATA portion of a RR, - they are encoded as shown below. - - The period of key validity is not included in this data but is - indicated separately, for example by an RR such as RRSIG which signs - and authenticates the RR containing the keying information. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | KEY flags | protocol | algorithm=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | prime length (or flag) | prime (p) (or special) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / prime (p) (variable length) | generator length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | generator (g) (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | public value length | public value (variable length)/ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / public value (g^i mod p) (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Prime length is the length of the Diffie-Hellman prime (p) in bytes - if it is 16 or greater. Prime contains the binary representation of - the Diffie-Hellman prime with most significant byte first (i.e., in - network order). If "prime length" field is 1 or 2, then the "prime" - field is actually an unsigned index into a table of 65,536 - prime/generator pairs and the generator length SHOULD be zero. See - Appedix A for defined table entries and Section 4 for information on - allocating additional table entries. The meaning of a zero or 3 - through 15 value for "prime length" is reserved. - - Generator length is the length of the generator (g) in bytes. - Generator is the binary representation of generator with most - significant byte first. PublicValueLen is the Length of the Public - Value (g**i (mod p)) in bytes. PublicValue is the binary - representation of the DH public value with most significant byte - first. - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -3. Performance Considerations - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including DNS overhead. Larger - transfers will perform correctly and extensions have been - standardized [RFC 2671] to make larger transfers more efficient. But - it is still advisable at this time to make reasonable efforts to - minimize the size of RR sets containing keying information consistent - with adequate security. - - - -4. IANA Considerations - - Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires - an IETF consensus as defined in [RFC 2434]. - - Well known prime/generator pairs number 0x0000 through 0x07FF can - only be assigned by an IETF standards action. [RFC 2539], the - Proposed Standard predecessor of this document, assigned 0x0001 - through 0x0002. This document additionally assigns 0x0003. Pairs - number 0s0800 through 0xBFFF can be assigned based on RFC - documentation. Pairs number 0xC000 through 0xFFFF are available for - private use and are not centrally coordinated. Use of such private - pairs outside of a closed environment may result in conflicts and/or - security failures. - - - -5. Security Considerations - - Keying information retrieved from the DNS should not be trusted - unless (1) it has been securely obtained from a secure resolver or - independently verified by the user and (2) this secure resolver and - secure obtainment or independent verification conform to security - policies acceptable to the user. As with all cryptographic - algorithms, evaluating the necessary strength of the key is important - and dependent on security policy. - - In addition, the usual Diffie-Hellman key strength considerations - apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p - SHOULD be "large", etc. See [RFC 2631, Schneier]. - - - -Copyright, Disclaimer, and Additional IPR Provisions - - Copyright (C) The Internet Society (2006). This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Normative References - - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2434] - "Guidelines for Writing an IANA Considerations Section - in RFCs", T. Narten, H. Alvestrand, October 1998. - - [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June - 1999. - - [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - - -Informative Refences - - [RFC 1034] - "Domain names - concepts and facilities", P. - Mockapetris, November 1987. - - [RFC 1035] - "Domain names - implementation and specification", P. - Mockapetris, November 1987. - - [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name - System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC. - - [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August - 1999. - - [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley - and Sons. - - - - - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in September 2006. - - Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Appendix A: Well known prime/generator pairs - - These numbers are copied from the IPSEC effort where the derivation - of these values is more fully explained and additional information is - available. Richard Schroeppel performed all the mathematical and - computational work for this appendix. - - - -A.1. Well-Known Group 1: A 768 bit prime - - The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its - decimal value is - 155251809230070893513091813125848175563133404943451431320235 - 119490296623994910210725866945387659164244291000768028886422 - 915080371891804634263272761303128298374438082089019628850917 - 0691316593175367469551763119843371637221007210577919 - - Prime modulus: Length (32 bit words): 24, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - -A.2. Well-Known Group 2: A 1024 bit prime - - The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. - Its decimal value is - 179769313486231590770839156793787453197860296048756011706444 - 423684197180216158519368947833795864925541502180565485980503 - 646440548199239100050792877003355816639229553136239076508735 - 759914822574862575007425302077447712589550957937778424442426 - 617334727629299387668709205606050270810842907692932019128194 - 467627007 - - Prime modulus: Length (32 bit words): 32, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 - FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -A.3. Well-Known Group 3: A 1536 bit prime - - The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. - Its decimal value is - 241031242692103258855207602219756607485695054850245994265411 - 694195810883168261222889009385826134161467322714147790401219 - 650364895705058263194273070680500922306273474534107340669624 - 601458936165977404102716924945320037872943417032584377865919 - 814376319377685986952408894019557734611984354530154704374720 - 774996976375008430892633929555996888245787241299381012913029 - 459299994792636526405928464720973038494721168143446471443848 - 8520940127459844288859336526896320919633919 - - Prime modulus Length (32 bit words): 48, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 10] - diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt deleted file mode 100644 index 8f84fd4d..00000000 --- a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt +++ /dev/null @@ -1,480 +0,0 @@ - - - - - - -DNSEXT Working Group Paul Vixie, ISC -INTERNET-DRAFT -<draft-ietf-dnsext-rfc2671bis-edns0-01.txt> March 17, 2008 - -Intended Status: Standards Track -Obsoletes: 2671 (if approved) - - - Revised extension mechanisms for DNS (EDNS0) - - -Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - Abstract - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - allow clients to advertise their capabilities to servers. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - - - -Expires September 2008 [Page 1] - -INTERNET-DRAFT EDNS0 March 2008 - - -1 - Introduction - -1.1. DNS (see [RFC1035]) specifies a Message Format and within such -messages there are standard formats for encoding options, errors, and -name compression. The maximum allowable size of a DNS Message is fixed. -Many of DNS's protocol limits are too small for uses which are or which -are desired to become common. There is no way for implementations to -advertise their capabilities. - -1.2. Unextended agents will not know how to interpret the protocol -extensions detailed here. In practice, these clients will be upgraded -when they have need of a new feature, and only new features will make -use of the extensions. Extended agents must be prepared for behaviour -of unextended clients in the face of new protocol elements, and fall -back gracefully to unextended DNS. RFC 2671 originally has proposed -extensions to the basic DNS protocol to overcome these deficiencies. -This memo refines that specification and obsoletes RFC 2671. - -1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in RFC 2119 [RFC2119]. - -2 - Affected Protocol Elements - -2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit -word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of -1-bit flags. The original reserved Z bits have been allocated to -various purposes, and most of the RCODE values are now in use. More -flags and more possible RCODEs are needed. The OPT pseudo-RR specified -in Section 4 contains subfields that carry a bit field extension of the -RCODE field and additional flag bits, respectively; for details see -Section 4.6 below. - -2.2. The first two bits of a wire format domain label are used to denote -the type of the label. [RFC1035 4.1.4] allocates two of the four -possible types and reserves the other two. Proposals for use of the -remaining types far outnumber those available. More label types were -needed, and an extension mechanism was proposed in RFC 2671 [RFC2671 -Section 3]. Section 3 of this document reserves DNS labels with a first -octet in the range of 64-127 decimal (label type 01) for future -standardization of Extended DNS Labels. - - - - - - - -Expires September 2008 [Page 2] - -INTERNET-DRAFT EDNS0 March 2008 - - -2.3. DNS Messages are limited to 512 octets in size when sent over UDP. -While the minimum maximum reassembly buffer size still allows a limit of -512 octets of UDP payload, most of the hosts now connected to the -Internet are able to reassemble larger datagrams. Some mechanism must -be created to allow requestors to advertise larger buffer sizes to -responders. To this end, the OPT pseudo-RR specified in Section 4 -contains a maximum payload size field; for details see Section 4.5 -below. - -3 - Extended Label Types - -The first octet in the on-the-wire representation of a DNS label -specifies the label type; the basic DNS specification [RFC1035] -dedicates the two most significant bits of that octet for this purpose. - -This document reserves DNS label type 0b01 for use as an indication for -Extended Label Types. A specific extended label type is selected by the -6 least significant bits of the first octet. Thus, Extended Label Types -are indicated by the values 64-127 (0b01xxxxxx) in the first octet of -the label. - -Allocations from this range are to be made for IETF documents fully -describing the syntax and semantics as well as the applicability of the -particular Extended Label Type. - -This document does not describe any specific Extended Label Type. - -4 - OPT pseudo-RR - -4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data -section of a request, and to responses to such requests. An OPT is -called a pseudo-RR because it pertains to a particular transport level -message and not to any actual DNS data. OPT RRs MUST NOT be cached, -forwarded, or stored in or loaded from master files. The quantity of -OPT pseudo-RRs per message MUST be either zero or one, but not greater. - -4.2. An OPT RR has a fixed part and a variable set of options expressed -as {attribute, value} pairs. The fixed part holds some DNS meta data -and also a small collection of new protocol elements which we expect to -be so popular that it would be a waste of wire space to encode them as -{attribute, value} pairs. - - - - - - - -Expires September 2008 [Page 3] - -INTERNET-DRAFT EDNS0 March 2008 - - -4.3. The fixed part of an OPT RR is structured as follows: - -Field Name Field Type Description ------------------------------------------------------- -NAME domain name empty (root domain) -TYPE u_int16_t OPT (41) -CLASS u_int16_t sender's UDP payload size -TTL u_int32_t extended RCODE and flags -RDLEN u_int16_t describes RDATA -RDATA octet stream {attribute,value} pairs - - -4.4. The variable part of an OPT RR is encoded in its RDATA and is -structured as zero or more of the following: - - : +0 (MSB) : +1 (LSB) : - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - -OPTION-CODE (Assigned by IANA.) - -OPTION-LENGTH Size (in octets) of OPTION-DATA. - -OPTION-DATA Varies per OPTION-CODE. - -4.4.1. Order of appearance of option tuples is never relevant. Any -option whose meaning is affected by other options is so affected no -matter which one comes first in the OPT RDATA. - -4.4.2. Any OPTION-CODE values not understood by a responder or requestor -MUST be ignored. So, specifications of such options might wish to -include some kind of signalled acknowledgement. For example, an option -specification might say that if a responder sees option XYZ, it SHOULD -include option XYZ in its response. - - - - - - -Expires September 2008 [Page 4] - -INTERNET-DRAFT EDNS0 March 2008 - - -4.5. The sender's UDP payload size (which OPT stores in the RR CLASS -field) is the number of octets of the largest UDP payload that can be -reassembled and delivered in the sender's network stack. Note that path -MTU, with or without fragmentation, may be smaller than this. Values -lower than 512 are undefined, and may be treated as format errors, or -may be treated as equal to 512, at the implementor's discretion. - -4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP -reassembly buffer. Choosing 1280 on an Ethernet connected requestor -would be reasonable. The consequence of choosing too large a value may -be an ICMP message from an intermediate gateway, or even a silent drop -of the response message. - -4.5.2. Both requestors and responders are advised to take account of the -path's discovered MTU (if already known) when considering message sizes. - -4.5.3. The requestor's maximum payload size can change over time, and -therefore MUST NOT be cached for use beyond the transaction in which it -is advertised. - -4.5.4. The responder's maximum payload size can change over time, but -can be reasonably expected to remain constant between two sequential -transactions; for example, a meaningless QUERY to discover a responder's -maximum UDP payload size, followed immediately by an UPDATE which takes -advantage of this size. (This is considered preferrable to the outright -use of TCP for oversized requests, if there is any reason to suspect -that the responder implements EDNS, and if a request will not fit in the -default 512 payload size limit.) - -4.5.5. Due to transaction overhead, it is unwise to advertise an -architectural limit as a maximum UDP payload size. Just because your -stack can reassemble 64KB datagrams, don't assume that you want to spend -more than about 4KB of state memory per ongoing transaction. - -4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) -are structured as follows: - - : +0 (MSB) : +1 (LSB) : - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | DO| Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - - - -Expires September 2008 [Page 5] - -INTERNET-DRAFT EDNS0 March 2008 - - -EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that - EXTENDED-RCODE value zero (0) indicates that an - unextended RCODE is in use (values zero (0) through - fifteen (15)). - -VERSION Indicates the implementation level of whoever sets it. - Full conformance with this specification is indicated by - version zero (0). Requestors are encouraged to set this - to the lowest implemented level capable of expressing a - transaction, to minimize the responder and network load - of discovering the greatest common implementation level - between requestor and responder. A requestor's version - numbering strategy should ideally be a run time - configuration option. - - If a responder does not implement the VERSION level of - the request, then it answers with RCODE=BADVERS. All - responses MUST be limited in format to the VERSION level - of the request, but the VERSION of each response MUST be - the highest implementation level of the responder. In - this way a requestor will learn the implementation level - of a responder as a side effect of every response, - including error responses, including RCODE=BADVERS. - -DO DNSSEC OK bit [RFC3225]. - -Z Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification [IANAFLAGS]. - -5 - Transport Considerations - -5.1. The presence of an OPT pseudo-RR in a request is an indication that -the requestor fully implements the given version of EDNS, and can -correctly understand any response that conforms to that feature's -specification. - -5.2. Lack of use of these features in a request is an indication that -the requestor does not implement any part of this specification and that -the responder SHOULD NOT use any protocol extension described here in -its response. - -5.3. Responders who do not understand these protocol extensions are -expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or -to appear to "time out" due to inappropriate action by a "middle box" -such as a NAT, or to ignore extensions and respond only to unextended - - - -Expires September 2008 [Page 6] - -INTERNET-DRAFT EDNS0 March 2008 - - -protocol elements. Therefore use of extensions SHOULD be "probed" such -that a responder who isn't known to support them be allowed a retry with -no extensions if it responds with such an RCODE, or does not respond. -If a responder's capability level is cached by a requestor, a new probe -SHOULD be sent periodically to test for changes to responder capability. - -5.4. If EDNS is used in a request, and the response arrives with TC set -and with no EDNS OPT RR, a requestor should assume that truncation -prevented the OPT RR from being appended by the responder, and further, -that EDNS is not used in the response. Correspondingly, an EDNS -responder who cannot fit all necessary elements (including an OPT RR) -into a response, should respond with a normal (unextended) DNS response, -possibly setting TC if the response will not fit in the unextended -response message's 512-octet size. - -6 - Security Considerations - -Requestor-side specification of the maximum buffer size may open a new -DNS denial of service attack if responders can be made to send messages -which are too large for intermediate gateways to forward, thus leading -to potential ICMP storms between gateways and responders. - -7 - IANA Considerations - -IANA has allocated RR type code 41 for OPT. - -This document controls the following IANA sub-registries in registry -"DOMAIN NAME SYSTEM PARAMETERS": - - "EDNS Extended Label Type" - "EDNS Option Codes" - "EDNS Version Numbers" - "Domain System Response Code" - -IANA is advised to re-parent these subregistries to this document. - -This document assigns label type 0b01xxxxxx as "EDNS Extended Label -Type." We request that IANA record this assignment. - -This document assigns option code 65535 to "Reserved for future -expansion." - -This document assigns EDNS Extended RCODE "16" to "BADVERS". - - - - - -Expires September 2008 [Page 7] - -INTERNET-DRAFT EDNS0 March 2008 - - -IESG approval is required to create new entries in the EDNS Extended -Label Type or EDNS Version Number registries, while any published RFC -(including Informational, Experimental, or BCP) is grounds for -allocation of an EDNS Option Code. - -8 - Acknowledgements - -Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, -Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten, -Alfred Hoenes and Markku Savela were each instrumental in creating and -refining this specification. - -9 - References - -[RFC1035] P. Mockapetris, "Domain Names - Implementation and - Specification," RFC 1035, USC/Information Sciences - Institute, November 1987. - -[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119, Harvard University, March - 1997. - -[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671, - Internet Software Consortium, August 1999. - -[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC - 3225, Nominum Inc., December 2001. - -[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site - http://www.iana.org/assignments/dns-header-flags, as of - June 2005 or later. - -10 - Author's Address - -Paul Vixie - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 423 1301 - EMail: vixie@isc.org - - - - - - - - -Expires September 2008 [Page 8] - -INTERNET-DRAFT EDNS0 March 2008 - - -Full Copyright Statement - -Copyright (C) IETF Trust (2007). - -This document is subject to the rights, licenses and restrictions -contained in BCP 78, and except as set forth therein, the authors retain -all their rights. - -This document and the information contained herein are provided on an -"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR -IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE -INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE -INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED -WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - -The IETF takes no position regarding the validity or scope of any -Intellectual Property Rights or other rights that might be claimed to -pertain to the implementation or use of the technology described in this -document or the extent to which any license under such rights might or -might not be available; nor does it represent that it has made any -independent effort to identify any such rights. Information on the -procedures with respect to rights in RFC documents can be found in BCP -78 and BCP 79. - -Copies of IPR disclosures made to the IETF Secretariat and any -assurances of licenses to be made available, or the result of an attempt -made to obtain a general license or permission for the use of such -proprietary rights by implementers or users of this specification can be -obtained from the IETF on-line IPR repository at -http://www.ietf.org/ipr. - -The IETF invites any interested party to bring to its attention any -copyrights, patents or patent applications, or other proprietary rights -that may cover technology that may be required to implement this -standard. Please address the information to the IETF at -ietf-ipr@ietf.org. - -Acknowledgement - -Funding for the RFC Editor function is provided by the IETF -Administrative Support Activity (IASA). - - - - -Expires September 2008 [Page 9] -
\ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt deleted file mode 100644 index 0af13c61..00000000 --- a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt +++ /dev/null @@ -1,755 +0,0 @@ - - -Network Working Group B. Laurie -Internet-Draft Nominet -Expires: March 2, 2005 R. Loomis - SAIC - September 2004 - - - - Requirements related to DNSSEC Signed Proof of Non-Existence - draft-ietf-dnsext-signed-nonexistence-requirements-01 - - -Status of this Memo - - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - This Internet-Draft will expire on March 2, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). - - -Abstract - - - DNSSEC-bis uses the NSEC record to provide authenticated denial of - existence of RRsets. NSEC also has the side-effect of permitting - zone enumeration, even if zone transfers have been forbidden. - Because some see this as a problem, this document has been assembled - to detail the possible requirements for denial of existence A/K/A - signed proof of non-existence. - - - - -Laurie & Loomis Expires March 2, 2005 [Page 1] -Internet-Draft signed-nonexistence-requirements September 2004 - - - -Table of Contents - - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3 - 4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4 - 5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4 - 6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4 - 7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5 - 9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5 - 10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6 - 11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6 - 12. Non-overlap of denial records with possible zone records . . 7 - 13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7 - 14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8 - 15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8 - 16. Minimisation of Client Complexity . . . . . . . . . . . . . 8 - 17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8 - 18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8 - 19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8 - 20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8 - 21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9 - 22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9 - 23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9 - 24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9 - 25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9 - 26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 28. Requirements notation . . . . . . . . . . . . . . . . . . . 9 - 29. Security Considerations . . . . . . . . . . . . . . . . . . 10 - 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 30.1 Normative References . . . . . . . . . . . . . . . . . . . 10 - 30.2 Informative References . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 - Intellectual Property and Copyright Statements . . . . . . . 11 - - - - - - - - - - - - - - - - -Laurie & Loomis Expires March 2, 2005 [Page 2] -Internet-Draft signed-nonexistence-requirements September 2004 - - - -1. Introduction - - - NSEC records allow trivial enumeration of zones - a situation that - has existed for several years but which has recently been raised as a - significant concern for DNSSECbis deployment in several zones. - Alternate proposals have been made that make zone enumeration more - difficult, and some previous proposals to modify DNSSEC had related - requirements/desirements that are relevant to the discussion. In - addition the original designs for NSEC/NXT records were based on - working group discussions and the choices made were not always - documented with context and requirements-- so some of those choices - may need to be restated as requirements. Overall, the working group - needs to better understand the requirements for denial of existence - (and certain other requirements related to DNSSECbis deployment) in - order to evaluate the proposals that may replace NSEC. - - - In the remainder of this document, "NSEC++" is used as shorthand for - "a denial of existence proof that will replace NSEC". "NSECbis" has - also been used as shorthand for this, but we avoid that usage since - NSECbis will not be part of DNSSECbis and therefore there might be - some confusion. - - -2. Non-purposes - - - This document does not currently document the reasons why zone - enumeration might be "bad" from a privacy, security, business, or - other perspective--except insofar as those reasons result in - requirements. Once the list of requirements is complete and vaguely - coherent, the trade-offs (reducing zone enumeration will have X cost, - while providing Y benefit) may be revisited. The editors of this - compendium received inputs on the potential reasons why zone - enumeration is bad (and there was significant discussion on the - DNSEXT WG mailing list) but that information fell outside the scope - of this document. - - - Note also that this document does not assume that NSEC *must* be - replaced with NSEC++, if the requirements can be met through other - methods (e.g., "white lies" with the current NSEC). As is stated - above, this document is focused on requirements collection and - (ideally) prioritization rather than on the actual implementation. - - -3. Zone Enumeration - - - Authenticated denial should not permit trivial zone enumeration. - - - Additional discussion: NSEC (and NXT before it) provide a linked - list that could be "walked" to trivially enumerate all the signed - records in a zone. This requirement is primarily (though not - - - - -Laurie & Loomis Expires March 2, 2005 [Page 3] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - exclusively) important for zones that either are delegation-only/ - -mostly or do not have reverse lookup (PTR) records configured, since - enterprises that have PTR records for all A records have already - provided a similar capability to enumerate the contents of DNS zones. - - - Contributor: various - - -4. Zone Enumeration II - - - Zone enumeration should be at least as difficult as it would be to - effect a dictionary attack using simple DNS queries to do the same in - an unsecured zone. - - - (Editor comment: it is not clear how to measure difficulty in this - case. Some examples could be monetary cost, bandwidth, processing - power or some combination of these. It has also been suggested that - the requirement is that the graph of difficulty of enumeration vs. - the fraction of the zone enumerated should be approximately the same - shape in the two cases) - - - Contributor: Nominet - - -5. Zone Enumeration III - - - Enumeration of a zone with random contents should computationally - infeasible. - - - Editor comment: this is proposed as a way of evaluating the - effectiveness of a proposal rather than as a requirement anyone would - actually have in practice. - - - Contributor: Alex Bligh - - -6. Exposure of Contents - - - NSEC++ should not expose any of the contents of the zone (apart from - the NSEC++ records themselves, of course). - - - Editor comment: this is a weaker requirement than prevention of - enumeration, but certainly any zone that satisfied this requirement - would also satisfy the trivial prevention of enumeration requirement. - - - Contributor: Ed Lewis - - -7. Zone Size - - - Requirement: NSEC++ should make it possible to take precautions - against trivial zone size estimates. Since not all zone owners care - - - - -Laurie & Loomis Expires March 2, 2005 [Page 4] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - about others estimation of the size of a zone, it is not always - necessary to prohibit trivial estimation of the size of the zone but - NSEC++ should allow such measures. - - - Additional Discussion: Even with proposals based on obfuscating names - with hashes it is trivial to give very good estimates of the number - of domains in a certain zone. Just send 10 random queries and look - at the range between the two hash values returned in each NSEC++. As - hash output can be assumed to follow a rectangular random - distribution, using the mean difference between the two values, you - can estimate the total number of records. It is probably sufficient - to look at even one NSEC++, since the two hash values should follow a - (I believe) Poisson distribution. - - - The concern is motivated by some wording remembered from NSEC, which - stated that NSEC MUST only be present for existing owner names in the - zone, and MUST NOT be present for non-existing owner names. If - similar wording were carried over to NSEC++, introducing bogus owner - names in the hash chain (an otherwise simple solution to guard - against trivial estimates of zone size) wouldn't be allowed. - - - One simple attempt at solving this is to describe in the - specifications how zone signer tools can add a number of random - "junk" records. - - - Editor's comment: it is interesting that obfuscating names might - actually make it easier to estimate zone size. - - - Contributor: Simon Josefsson. - - -8. Single Method - - - Requirement: A single NSEC++ method must be able to carry both - old-style denial (i.e. plain labels) and whatever the new style - looks like. Having two separate denial methods could result in - cornercases where one method can deny the other and vice versa. - - - Additional discussion: This requirement can help -bis folks to a - smooth upgrade to -ter. First they'd change the method while the - content is the same, then they can change content of the method. - - - Contributor: Roy Arends. - - -9. Empty Non-terminals - - - Requirement: Empty-non-terminals (ENT) should remain empty. In - other words, adding NSEC++ records to an existing DNS structure - should not cause the creation of NSEC++ records (or related records) - - - - -Laurie & Loomis Expires March 2, 2005 [Page 5] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - at points that are otherwise ENT. - - - Additional discussion: Currently NSEC complies with ENT requirement: - b.example.com NSEC a.c.example.com implies the existence of an ENT - with ownername c.example.com. NSEC2 breaks that requirement, since - the ownername is entirely hashed causing the structure to disappear. - This is why EXIST was introduced. But EXIST causes ENT to be - non-empty-terminals. Next to the dissappearance of ENT, it causes - (some) overhead since an EXIST record needs a SIG, NSEC2 and - SIG(NSEC2). DNSNR honours this requirement by hashing individual - labels instead of ownernames. However this causes very long labels. - Truncation is a measure against very long ownernames, but that is - controversial. There is a fair discussion of the validity of - truncation in the DNSNR draft, but that hasn't got proper review yet. - - - Contributor: Roy Arends. - - - (Editor comment: it is not clear to us that an EXIST record needs an - NSEC2 record, since it is a special purpose record only used for - denial of existence) - - -10. Prevention of Precomputed Dictionary Attacks - - - Requirement: NSEC++ needs to provide a method to reduce the - effectiveness of precomputed dictionary attacks. - - - Additional Discussion: Salt is a measure against dictionary attacks. - There are other possible measures (such as iterating hashes in - NSEC2). The salt needs to be communicated in every response, since - it is needed in every verification. Some have suggested to move the - salt to a special record instead of the denial record. I think this - is not wise. Response size has more priority over zone size. An - extra record causes a larger response than a larger existing record. - - - Contributor: Roy Arends. - - - (Editor comment: the current version of NSEC2 also has the salt in - every NSEC2 record) - - -11. DNSSEC-Adoption and Zone-Growth Relationship - - - Background: Currently with NSEC, when a delegation centric zone - deploys DNSSEC, the zone-size multiplies by a non-trivial factor even - when the DNSSEC-adoption rate of the subzones remains low--because - each delegation point creates at least one NSEC record and - corresponding signature in the parent even if the child is not - signed. - - - - - -Laurie & Loomis Expires March 2, 2005 [Page 6] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - Requirements: A delegation-only (or delegation-mostly) zone that is - signed but which has no signed child zones should initially need only - to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some - minimal set of NSEC++ records to cover zone contents. Further, - during the transition of a delegation-only zone from 0% signed - children to 100% signed children, the growth in the delegation-only - zone should be roughly proportional to the percentage of signed child - zones. - - - Additional Discussion: This is why DNSNR has the Authoritative Only - bit. This is similar to opt-in for delegations only. This (bit) is - currently the only method to help delegation-centric zone cope with - zone-growth due to DNSSEC adoption. As an example, A delegation only - zone which deploys DNSSEC with the help of this bit, needs to add - SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No - more than that. - - - Contributor: Roy Arends. - - -12. Non-overlap of denial records with possible zone records - - - Requirement: NSEC++ records should in some way be differentiated - from regular zone records, so that there is no possibility that a - record in the zone could be duplicated by a non-existence proof - (NSEC++) record. - - - Additional discussion: This requirement is derived from a discussion - on the DNSEXT mailing list related to copyrights and domain names. - As was outlined there, one solution is to put NSEC++ records in a - separate namespace, e.g.: $ORIGIN co.uk. - 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your - delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... - ; for amazon.co.uk. - - - Contributor: various - - - (Editor comment: One of us still does not see why a conflict - matters. Even if there is an apparent conflict or overlap, the - "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the - other name _never_ appears in NSEC2 records.) - - -13. Exposure of Private Keys - - - Private keys associated with the public keys in the DNS should be - exposed as little as possible. It is highly undesirable for private - keys to be distributed to nameservers, or to otherwise be available - in the run-time environment of nameservers. - - - - - -Laurie & Loomis Expires March 2, 2005 [Page 7] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - Contributors: Nominet, Olaf Kolkman, Ed Lewis - - -14. Minimisation of Zone Signing Cost - - - The additional cost of creating an NSEC++ signed zone should not - significantly exceed the cost of creating an ordinary signed zone. - - - Contributor: Nominet - - -15. Minimisation of Asymmetry - - - Nameservers should have to do as little additional work as necessary. - More precisely, it is desirable for any increase in cost incurred by - the nameservers to be offset by a proportionate increase in cost to - DNS `clients', e.g. stub and/or `full-service' resolvers. - - - Contributor: Nominet - - -16. Minimisation of Client Complexity - - - Caching, wildcards, CNAMEs, DNAMEs should continue to work without - adding too much complexity at the client side. - - - Contributor: Olaf Kolkman - - -17. Completeness - - - A proof of nonexistence should be possible for all nonexistent data - in the zone. - - - Contributor: Olaf Kolkman - - -18. Purity of Namespace - - - The name space should not be muddied with fake names or data sets. - - - Contributor: Ed Lewis - - -19. Replay Attacks - - - NSEC++ should not allow a replay to be used to deny existence of an - RR that actually exists. - - - Contributor: Ed Lewis - - -20. Compatibility with NSEC - - - NSEC++ should not introduce changes incompatible with NSEC. - - - - -Laurie & Loomis Expires March 2, 2005 [Page 8] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - Contributor: Ed Lewis - - -21. Compatibility with NSEC II - - - NSEC++ should differ from NSEC in a way that is transparent to the - resolver or validator. - - - Contributor: Ed Lewis - - -22. Compatibility with NSEC III - - - NSEC++ should differ from NSEC as little as possible whilst achieving - other requirements. - - - Contributor: Alex Bligh - - -23. Coexistence with NSEC - - - NSEC++ should be optional, allowing NSEC to be used instead. - - - Contributor: Ed Lewis, Alex Bligh - - -24. Coexistence with NSEC II - - - NSEC++ should not impose extra work on those content with NSEC. - - - Contributor: Ed Lewis - - -25. Protocol Design - - - A good security protocol would allow signing the nonexistence of some - selected names without revealing anything about other names. - - - Contributor: Dan Bernstein - - -26. Process - - - Clearly not all of these requirements can be met. Therefore the next - phase of this document will be to either prioritise them or narrow - them down to a non-contradictory set, which should then allow us to - judge proposals on the basis of their fit. - - -27. Acknowledgements - - -28. Requirements notation - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - - -Laurie & Loomis Expires March 2, 2005 [Page 9] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - document are to be interpreted as described in [RFC2119]. - - -29. Security Considerations - - - There are currently no security considerations called out in this - draft. There will be security considerations in the choice of which - requirements will be implemented, but there are no specific security - requirements during the requirements collection process. - - -30. References - - -30.1 Normative References - - - [dnssecbis-protocol] - "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some - Month 2004. - - -30.2 Informative References - - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - [RFC2418] Bradner, S., "IETF Working Group Guidelines and - Procedures", BCP 25, RFC 2418, September 1998. - - - -Authors' Addresses - - - Ben Laurie - Nominet - 17 Perryn Road - London W3 7LR - England - - - Phone: +44 (20) 8735 0686 - EMail: ben@algroup.co.uk - - - - Rip Loomis - Science Applications International Corporation - 7125 Columbia Gateway Drive, Suite 300 - Columbia, MD 21046 - US - - - EMail: gilbert.r.loomis@saic.com - - - - -Laurie & Loomis Expires March 2, 2005 [Page 10] -Internet-Draft signed-nonexistence-requirements September 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - -Laurie & Loomis Expires March 2, 2005 [Page 11]
\ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt deleted file mode 100644 index 9c73c68b..00000000 --- a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt +++ /dev/null @@ -1,1292 +0,0 @@ - - - - - -DNS Extensions Yuji Kamite -Internet-Draft NTT Communications -Expires: April 15, 2005 Masaya Nakayama - The University of Tokyo - October 14, 2004 - - - - TKEY Secret Key Renewal Mode - draft-ietf-dnsext-tkey-renewal-mode-05 - - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 15, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - This document defines a new mode in TKEY and proposes an atomic - method for changing secret keys used for TSIG periodically. - Originally, TKEY provides methods of setting up shared secrets other - - - -Kamite, et. al. Expires April 15, 2005 [Page 1] - -INTERNET-DRAFT October 2004 - - - than manual exchange, but it cannot control timing of key renewal - very well though it can add or delete shared keys separately. This - proposal is a systematical key renewal procedure intended for - preventing signing DNS messages with old and non-safe keys - permanently. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4 - 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4 - 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5 - 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5 - 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7 - 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7 - 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7 - 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8 - 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8 - 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10 - 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10 - 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10 - 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11 - 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11 - 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12 - 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13 - 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14 - 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15 - 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15 - 4.2 Authentication Methods Considerations . . . . . . . . . . 15 - 5. Special Considerations for Two Servers' Case . . . . . . . . 16 - 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16 - 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17 - 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 - 11.2 Informative References . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 - Intellectual Property and Copyright Statements . . . . . . . . 23 - - - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 2] - -INTERNET-DRAFT October 2004 - - -1. Introduction - - TSIG [RFC2845] provides DNS message integrity and the - request/transaction authentication by means of message authentication - codes (MAC). TSIG is a practical solution in view of calculation - speed and availability. However, TSIG does not have exchanging - mechanism of shared secret keys between server and resolver, and - administrators might have to exchange secret keys manually. TKEY - [RFC2930] is introduced to solve such problem and it can exchange - secrets for TSIG via networks. - - In various modes of TKEY, a server and a resolver can add or delete a - secret key be means of TKEY message exchange. However, the existing - TKEY does not care fully about the management of keys which became - too old, or dangerous after long time usage. - - It is ideal that the number of secret which a pair of hosts share - should be limited only one, because having too many keys for the same - purpose might not only be a burden to resolvers for managing and - distinguishing according to servers to query, but also does not seem - to be safe in terms of storage and protection against attackers. - Moreover, perhaps holding old keys long time might give attackers - chances to compromise by scrupulous calculation. - - Therefore, when a new shared secret is established by TKEY, the - previous old secret should be revoked immediately. To accomplish - this, DNS servers must support a protocol for key renewal. This - document specifies procedure to refresh secret keys between two hosts - which is defined within the framework of TKEY, and it is called "TKEY - Secret Key Renewal Mode". - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and - "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - - -1.1. Defined Words - - * Inception Time: Beginning of the shared secret key lifetime. This - value is determined when the key is generated. - - * Expiry Limit: Time limit of the key's validity. This value is - determined when a new key is generated. After Expiry Limit, server - and client (resolver) must not authenticate TSIG signed with the key. - Therefore, Renewal to the next key should be carried out before - Expiry Limit. - - * Partial Revocation Time: Time when server judges the key is too old - - - -Kamite, et. al. Expires April 15, 2005 [Page 3] - -INTERNET-DRAFT October 2004 - - - and must be updated. It must be between Inception Time and Expiry - Limit. This value is determined by server freely following its - security policy. e.g., If the time from Inception to Partial - Revocation is short, renewal will be carried out more often, which - might be safer. - - * Revocation Time: Time when the key becomes invalid and can be - removed. This value is not determined in advance because it is the - actual time when revocation is completed. - - * Adoption Time: Time when the new key is adopted as the next key - formally. After Adoption, the key is valid and server and client can - generate or verify TSIG making use of it. Adoption Time also means - the time when it becomes possible to remove the previous key, so - Revocation and Adoption are usually done at the same time. - - - Partial - Inception Revocation Revocation Expiry Limit - | | | | - |----------------|- - - - - - >>|- (revoked) -| - | | | | - previous key | | | - |- - - -|-------------------->> time - | | new key - Inception Adoption - - -1.2. New Format and Assigned Numbers - - TSIG - ERROR = (PartialRevoke), TBD - - TKEY - Mode = (server assignment for key renewal), TBD - Mode = (Diffie-Hellman exchange for key renewal), TBD - Mode = (resolver assignment for key renewal), TBD - Mode = (key adoption), TBD - - -1.3. Overview of Secret Key Renewal Mode - - When a server receives a query from a client signed with a TSIG key, - It always checks if the present time is within the range of usage - duration it considers safe. If it is judged that the key is too old, - i.e., after Partial Revocation Time, the server comes to be in - Partial Revocation state about the key, and this key is called - partially revoked. - - - -Kamite, et. al. Expires April 15, 2005 [Page 4] - -INTERNET-DRAFT October 2004 - - - In this state, if a client sends a normal query (e.g., question about - A RR) other than TKEY Renewal request with TSIG signed with the old - key, the server returns an error message to notify that the time to - renew has come. This is called "PartialRevoke" error message. It is - server's choice whether it returns PartialRevoke or not. If and only - if the server is ready for changing its own key, it decides to return - PartialRevoke. - - The client which got this error is able to notice that it is - necessary to refresh the secret. To make a new shared secret, it - sends a TKEY Renewal request, in which several keying methods are - available. It can make use of TSIG authentication signed with the - partially revoked key mentioned above. - - After new secret establishment, the client sends a TKEY Adoption - request for renewal confirmation. This can also be authenticated with - the partially revoked key. If this is admitted by the server, the new - key is formally adopted, and at the same time the corresponding old - secret is invalidated. Then the client can send the first query again - signed with the new key. - - Key renewal procedure is executed based on two-phase commit - mechanism. The first phase is the TKEY Renewal request and its - response, which means preparatory confirmation for key update. The - second phase is Adoption request and its response. If the server gets - request and client receives the response successfully, they can - finish renewal process. If any error happens and renewal process - fails during these phases, client should roll back to the beginning - of the first phase, and send TKEY Renewal request again. This - rollback can be done until the Expiry Limit of the key. - - -2. Shared Secret Key Renewal - - Suppose a server and a client agree to change their TSIG keys - periodically. Key renewal procedure is defined between two hosts. - -2.1. Key Usage Time Check - - Whenever a server receives a query with TSIG and can find a key that - is used for signing it, the server checks its Inception Time, Partial - Revocation Time and Expiry Limit (this information is usually - memorized by the server). - - When the present time is before Inception Time, the server MUST NOT - verify TSIG with the key, and server acts the same way as when the - key used by the client is not recognized. It follows [RFC2845] 4.5.1. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 5] - -INTERNET-DRAFT October 2004 - - - When the present time is equal to Inception Time, or between - Inception Time and Partial Revocation Time, the behavior of the - server is the same as when a valid key is found. It follows [RFC2845] - 4.5.2 and 4.5.3. - - When the present time is the same as the Partial Revocation Time, or - between the Partial Revocation Time and Expiry Limit, the server - comes to be in Partial Revocation state about the TSIG key and - behaves according to the next section. - - When the present time is the same as the Expiry Time or after it, the - server MUST NOT verify TSIG with the key, and returns error messages - in the same way as when the key used by the client is not recognized. - It follows [RFC2845] 4.5.1. - - -2.2. Partial Revocation - - In Partial Revocation state, we say the server has partially revoked - the key and the key has become a "partially revoked key". - - If server has received a query signed with the partially revoked key - for TKEY Renewal request (See section 2.3.) or Key Adoption request - (See section 2.4.), then server does proper process following each - specification. If it is for TKEY key deletion request ([RFC2930] - 4.2), server MAY process usual deletion operation defined therein. - - If server receives other types of query signed with the partially - revoked key, and both the corresponding MAC and signed TIME are - verified, then server begins returning answer whose TSIG error code - is "PartialRevoke" (See section 9.). Server MUST randomly but with - increasing frequency return PartialRevoke when in the Partial - Revocation state. - - Server can decide when it actually sends PartialRevoke, checking if - it is appropriate time for renewal. Server MUST NOT return - PartialRevoke if this is apart long lived TSIG transaction (such as - AXFR) that started before the Partial Revocation Time. - - If the client receives PartialRevoke and understands it, then it MUST - retry the query with the old key unless a new key has been adopted. - Client SHOULD start the process to renew the TSIG key. For key - renewal procedure, see details in Section 2.3 and 2.4. - - PartialRevoke period (i.e., time while server returns PartialRevoke - randomely) SHOULD be small, say 2-5% of key lifetime. This is - server's choice. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 6] - -INTERNET-DRAFT October 2004 - - - Server MUST keep track of clients ignoring PartialRevoke, thus - indicating ignorance of this TKEY mode. - - PartialRevoke error messages have the role to inform clients of the - keys' partial revocation and urge them to send TKEY Renewal requests. - These error responses MUST be signed with those partial revoked keys - if the queries are signed with them. They are sent only when the - signing keys are found to be partially revoked. If the MAC of TSIG - cannot be verified with the partially revoked keys, servers MUST NOT - return PartialRevoke error with MAC, but MUST return another error - such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other - words, a server informs its key's partial revocation only when the - MAC in the received query is valid. - - -2.3. Key Renewal Message Exchange - -2.3.1. Query for Key Renewal - - If a client has received a PartialRevoke error and authenticated the - response based on TSIG MAC, it sends a TKEY query for Key Renewal (in - this document, we call it Renewal request, too.) to the server. The - request MUST be signed with TSIG or SIG(0) [RFC2931] for - authentication. If TSIG is selected, the client can sign it with the - partial revoked key. - - Key Renewal can use one of several keying methods which is indicated - in "Mode" field of TKEY RR, and its message structure is dependent on - that method. - - -2.3.2. Response for Key Renewal - - The server which has received Key Renewal request first tries to - verify TSIG or SIG(0) accompanying it. If the TSIG is signed and - verified with the partially revoked key, the request MUST be - authenticated. - - After authentication, server must check existing old key's validity. - If the partially revoked key indicated in the request TKEY's OldName - and OldAlgorithm field (See section 2.3.4.) does not exist at the - server, "BADKEY" [RFC2845] is given in Error field for response. If - any other error happens, server returns appropriate error messages - following the specification described in section 2.5. If there are no - errors, server returns a Key Renewal answer. This answer MUST be - signed with TSIG or SIG(0) for authentication. - - When this answer is successfully returned and no error is detected by - - - -Kamite, et. al. Expires April 15, 2005 [Page 7] - -INTERNET-DRAFT October 2004 - - - client, a new shared secret can be established. The details of - concrete keying procedure are given in the section 2.5. - - Note: - Sometimes Adoption message and new Renewal request will cross on - the wire. In this case the newly generated key Adoption message is - resent. - - -2.3.3. Attributes of Generated Key - - As a result of this message exchange, client comes to know the newly - generated key's attributes such as key's name, Inception Time and - Expiry Limit. They are decided by the server and told to the client; - in particular, however, once the server has decided Expiry Limit and - returned a response, it should obey the decision as far as it can. In - other words, they SHOULD NOT change time values for checking Expiry - Limit in the future without any special reason, such as security - issue like "Emergency Compulsory Revocation" described in section 8. - - On the other hand, Partial Revocation Time of this generated key is - not decided based on the request, and not informed to the client. The - server can determine any value as long as it is between Inception - Time and Expiry Limit. However, the period from Inception to Partial - Revocation SHOULD be fixed as the server side's configuration or be - set the same as the corresponding old key's one. - - Note: - Even if client sends Key Renewal request though the key described - in OldName has not been partially revoked yet, server does renewal - processes. At the moment when the server accepts such requests - with valid authentication, it MUST forcibly consider the key is - already partially revoked, that is, the key's Partial Revocation - Time must be changed into the present time (i.e., the time when - the server receives the request). - - -2.3.4. TKEY RR structure - - TKEY RR for Key Renewal message has the structure given below. In - principle, format and definition for each field follows [RFC2930]. - Note that each keying scheme sometimes needs different interpretation - of RDATA field; for detail, see section 2.5. - - Field Type Comment - ------- ------ ------- - NAME domain used for a new key, see below - TYPE u_int16_t (defined in [RFC2930]) - - - -Kamite, et. al. Expires April 15, 2005 [Page 8] - -INTERNET-DRAFT October 2004 - - - CLASS u_int16_t (defined in [RFC2930]) - TTL u_int32_t (defined in [RFC2930]) - RDLEN u_int16_t (defined in [RFC2930]) - RDATA: - Algorithm: domain algorithm for a new key - Inception: u_int32_t about the keying material - Expiration: u_int32_t about the keying material - Mode: u_int16_t scheme for key agreement - see section 9. - Error: u_int16_t see description below - Key Size: u_int16_t see description below - Key Data: octet-stream - Other Size: u_int16_t (defined in [RFC2930]) - size of other data - Other Data: newly defined: see description below - - - For "NAME" field, both non-root and root name are allowed. It may - be used for a new key's name in the same manner as [RFC2930] 2.1. - - "Algorithm" specifies which algorithm is used for agreed keying - material, which is used for identification of the next key. - - "Inception" and "Expiration" are used for the valid period of - keying material. The meanings differ somewhat according to whether - the message is request or answer, and its keying scheme. - - "Key Data" has different meanings according to keying schemes. - - "Mode" field stores the value in accordance with the keying method, - and see section 2.5. Servers and clients supporting TKEY Renewal - method MUST implement "Diffie-Hellman exchange for key renewal" - scheme. All other modes are OPTIONAL. - - "Error" is an extended RCODE which includes "PartialRevoke" value - too. See section 9. - - "Other Data" field has the structure given below. They describe - attributes of the key to be renewed. - - in Other Data filed: - - Field Type Comment - ------- ------ ------- - OldNAME domain name of the old key - OldAlgorithm domain algorithm of the old key - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 9] - -INTERNET-DRAFT October 2004 - - - "OldName" indicates the name of the previous key (usually, - this is partially revoked key's name that client noticed by - PartialRevoke answer from server), and "OldAlogirthm" - indicates its algorithm. - - -2.4. Key Adoption - -2.4.1. Query for Key Adoption - - After receiving a TKEY Renewal answer, the client gets the same - secret as the server. Then, it sends a TKEY Adoption request. The - request's question section's QNAME field is the same as the NAME - filed of TKEY written below. In additional section, there is one TKEY - RR that has the structure and values described below. - - "NAME" field is the new key's name to be adopted which was already - generated by Renewal message exchange. "Algorithm" is its - algorithm. "Inception" means the key's Inception Time, and - "Expiration" means Expiry Limit. - - "Mode" field is the value of "key adoption". See section 9. - - "Other Data" field in Adoption has the same structure as that of - Renewal request message. "OldName" means the previous old key, and - "OldAlogirthm" means its algorithm. - - Key Adoption request MUST be signed with TSIG or SIG(0) for - authentication. The client can sign TSIG with the previous key. Note - that until Adoption is finished, the new key is treated as invalid, - thus it cannot be used for authentication immediately. - - -2.4.2. Response for Key Adoption - - The server which has received Adoption request, it verifies TSIG or - SIG(0) accompanying it. If the TSIG is signed with the partially - revoked key and can be verified, the message MUST be authenticated. - - If the next new key indicated by the request TKEY's "NAME" is not - present at the server, BADNAME [RFC2845] is given in Error field and - the error message is returned. - - If the next key exists but it has not been adopted formally yet, the - server confirms the previous key's existence indicated by the - "OldName" and "OldAlgorithm" field. If it succeeds, the server - executes Adoption of the next key and Revocation of the previous key. - Response message duplicates the request's TKEY RR with NOERROR, - - - -Kamite, et. al. Expires April 15, 2005 [Page 10] - -INTERNET-DRAFT October 2004 - - - including "OldName" and "OldAlgorithm" that indicate the revoked key. - - If the next key exists but it is already adopted, the server returns - a response message regardless of the substance of the request TKEY's - "OldName". In this response, Response TKEY RR has the same data as - the request's one except as to its "Other Data" that is changed into - null (i.e., "Other Size" is zero), which is intended for telling the - client that the previous key name was ignored, and the new key is - already available. - - Client sometimes has to retry Adoption request. Suppose the client - sent request signed with the partially revoked key, but its response - did not return successfully (e.g., due to the drop of UDP packet). - Client will probably retry Adoption request; however, the request - will be refused in the form of TSIG "BADKEY" error because the - previous key was already revoked. In this case, client will - retransmit Adoption request signed with the next key, and expect a - response which has null "Other Data" for confirming the completion of - renewal. - - -2.5. Keying Schemes - - In Renewal message exchanges, there are no limitations as to which - keying method is actually used. The specification of keying - algorithms is independent of the general procedure of Renewal that is - described in section 2.3. - - Now this document specifies three algorithms in this section, but - other future documents can make extensions defining other methods. - - -2.5.1. DH Exchange for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.1. This - specification only describes the difference from it and special - notice; assume that all other points, such as keying material - computation, are the exactly same as the specification of [RFC2930] - 4.1. - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. KEY RR is - the client's Diffie-Hellman public key [RFC2539]. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 11] - -INTERNET-DRAFT October 2004 - - - TKEY "Mode" field stores the value of "DH exchange for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is used as a random, following [RFC2930] 4.1. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. If - any incompatible DH key is found in the request, "BADKEY" - [RFC2845] is given in Error field for response. "FORMERR" is given - if the query included no DH KEY. - - If there are no errors, the server processes a response according - to Diffie-Hellman algorithm and returns the answer. In this - answer, there is one TKEY RR in answer section and KEY RR(s) in - additional section. - - As long as no error has occurred, all values of TKEY are equal to - that of the request message except TKEY NAME, TKEY RDLEN, RDATA's - Inception, Expiration, Key Size and Key Data. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - TKEY "Key Data" is used as an additional nonce, following - [RFC2930] 4.1. - - The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in - the additional section and a server Diffie-Hellman KEY RR will - also be present in the answer section, following [RFC2930] 4.1. - - -2.5.2. Server Assigned Keying for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.4. This - specification only describes the difference from it and special - notice; assume that all other points, such as secret encrypting - method, are the exactly same as the specification of [RFC2930] 4.4. - - - -Kamite, et. al. Expires April 15, 2005 [Page 12] - -INTERNET-DRAFT October 2004 - - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. KEY RR is - used in encrypting the response. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - TKEY "Mode" field stores the value of "server assignment for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is provided following the specification of - [RFC2930] 4.4. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. - "FORMERR" is given if the query specified no encryption key. - - If there are no errors, the server response contains one TKEY RR - in the answer section, and echoes the KEY RR provided in the query - in the additional information section. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - TKEY "Key Data" is the assigned keying data encrypted under the - public key in the resolver provided KEY RR, which is the same as - [RFC2930] 4.4. - - -2.5.3. Resolver Assigned Keying for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.5. This - specification only describes the difference from it and special - notice; assume that all other points, such as secret encrypting - method, are the exactly same as the specification of [RFC2930] 4.5. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 13] - -INTERNET-DRAFT October 2004 - - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. TKEY RR - has the encrypted keying material and KEY RR is the server public - key used to encrypt the data. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - TKEY "Mode" field stores the value of "resolver assignment for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is the encrypted keying material. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. - "FORMERR" is given if the server does not have the corresponding - private key for the KEY RR that was shown sin the request. - - If there are no errors, the server returns a response. The - response contains a TKEY RR in the answer section to tell the - shared key's name and its usage time values. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - -2.6. Considerations about Non-compliant Hosts - - Key Renewal requests and responses must be exchanged between hosts - which can understand them and do proper processes. PartialRevoke - error messages will be only ignored if they should be returned to - non-compliant hosts. - - Note that server does not inform actively the necessity of renewal to - clients, but inform it as responses invoked by client's query. - Server needs not care whether the PartialRevoke errors has reached - - - -Kamite, et. al. Expires April 15, 2005 [Page 14] - -INTERNET-DRAFT October 2004 - - - client or not. If client has not received yet because of any reasons - such as packet drops, it will resend the queries, and finally will be - able to get PartialRevoke information. - - -3. Secret Storage - - Every server keeps all secrets and attached information, e.g., - Inception Time, Expiry Limit, etc. safely to be able to recover from - unexpected stop. To accomplish this, formally adopted keys SHOULD be - memorized not only on memory, but also be stored in the form of some - files. It will become more secure if they are stored in ecrypted - form. - - -4. Compulsory Key Revocation - -4.1. Compulsory Key Revocation by Server - - There is a rare but possible case that although servers have already - partially revoked keys, clients do not try to send any Renewal - requests. If this state continues, in the future it will become the - time of Expiry Limit. After Expiry Limit, the keys will be expired - and completely removed, so this is called Compulsory Key Revocation - by server. - - If Expiry Limit is too distant from the Partial Revocation Time, then - even though very long time passes, clients will be able to refresh - secrets only if they add TSIG signed with those old partially revoked - keys into requests, which is not safe. - - On the other hand, if Expiry Limit is too close to Partial Revocation - Time, perhaps clients might not be able to notice their keys' Partial - Revocation by getting "PartialRevoke" errors. - - Therefore, servers should set proper Expiry Limit to their keys, - considering both their keys' safety, and enough time for clients to - send requests and process renewal. - - -4.2. Authentication Methods Considerations - - It might be ideal to provide both SIG(0) and TSIG as authentication - methods. For example: - - A client and a server start SIG(0) authentication at first, to - establish TSIG shared keys by means of "Query for Diffie-Hellman - Exchanged Keying" as described in [RFC2930] 4.1. Once they get - - - -Kamite, et. al. Expires April 15, 2005 [Page 15] - -INTERNET-DRAFT October 2004 - - - shared secret, they keep using TSIG for queries and responses. - After a while the server returns a "ParitalRevoke" error and they - begin a key renewal process. Both TSIG signed with partially - revoked keys and SIG(0) are okay for authentication, but TSIG would - be easier to use considering calculation efficiency. - - Suppose now client is halted for long time with some reason. - Because server does not execute any renewal process, it will - finally do Compulsory Revocation. Even if client restarts and sends - a key Renewal request, it will fail because old key is already - deleted at server. - - At this moment, however, if client also uses SIG(0) as another - authentication method, it can make a new shared key again and - recover successfully by sending "Query for Diffie-Hellman Exchanged - Keying" with SIG(0). - - -5. Special Considerations for Two servers' Case - - This section refers to the case where both hosts are DNS servers - which can act as full resolvers as well and using one shared key - only. If one server (called Server A) wants to refresh a shared key - (called "Key A-B"), it will await a TKEY Renewal request from the - other server (called Server B). However, perhaps Server A wants to - refresh the key right now. - - In this case, Server A is allowed to send a Renewal request to Server - B, if Server A knows the Key A-B is too old and wants to renew it - immediately. - - Note that the initiative in key renewal belongs to Server A because - it can notice the Partial Revocation Time and decide key renewal. If - Server B has information about Partial Revocation Time as well, it - can also decide for itself to send Renewal request to Server A. - However, it is not essential for both two servers have information - about key renewal timing. - -5.1. To Cope with Collisions of Renewal Requests - - At least one of two hosts which use Key Renewal must know their key - renewal information such as Partial Revocation Time. It is okay that - both hosts have it. - - Provided that both two servers know key renewal timing information, - there is possibility for them to begin partial revocation and sending - Renewal requests to each other at the same time. Such collisions will - not happen so often because Renewal requests are usually invoked when - - - -Kamite, et. al. Expires April 15, 2005 [Page 16] - -INTERNET-DRAFT October 2004 - - - hosts want to send queries, but it is possible. - - When one of two servers tries to send Renewal requests, it MUST - protect old secrets that it has partially revoked and prevent it from - being refreshed by any requests from the other server (i.e., it must - lock the old secret during the process of renewal). While the server - is sending Renewal requests and waiting responses, it ignores the - other server's Renewal requests. - - Therefore, servers might fail to change secrets by means of their own - requests to others. After failure they will try to resend, but they - should wait for random delays by the next retries. If they get any - Renewal requests from others while they are waiting, their shared - keys may be refreshed, then they do not need to send any Renewal - requests now for themselves. - - -6. Key Name Considerations - - Since both servers and clients have only to distinguish new secrets - and old ones, keys' names do not need to be specified strictly. - However, it is recommended that some serial number or key generation - time be added to the name and that the names of keys between the same - pair of hosts should have some common labels among their keys. For - example, suppose A.example.com. and B.example.com. share the key - "<serial number>.A.example.com.B.example.com." such as - "10010.A.example.com.B.example.com.". After key renewal, they change - their secret and name into "10011.A.example.com.B.example.com." - - Servers and clients must be able to use keys properly for each query. - Because TSIG secret keys themselves do not have any particular IDs to - be distinguished and would be identified by their names and - algorithm, it must be understood correctly what keys are refreshed. - - -7. Example Usage of Secret Key Renewal Mode - - This is an example of Renewal mode usage where a Server, - server.example.com, and a Client, client.exmple.com have an initial - shared secret key named "00.client.example.com.server.example.com". - - (1) The time values for key - "00.client.example.com.server.example.com" was set as follows: - Inception Time is at 1:00, Expiry Limit is at 21:00. - - (2) At Server, renewal time has been set: Partial Revocation Time - is at 20:00. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 17] - -INTERNET-DRAFT October 2004 - - - (3) Suppose the present time is 19:55. If Client sends a query - signed with key "00.client.example.com.server.example.com" to ask - the IP address of "www.example.com", finally it will get a proper - answer from Server with valid TSIG (NOERROR). - - (4) At 20:05. Client sends a query to ask the IP address of - "www2.example.com". It is signed with key - "00.client.example.com.server.example.com". Server returns an - answer for the IP address. However, server has begun retuning - PartialRevoke Error randomely. This answer includes valid TSIG MAC - signed with "00.client.example.com.server.example.com", and its - Error Code indicates PartialRevoke. Client understands that the - current key is partially revoked. - - (5) At 20:06. Client sends a Renewal request to Server. This - request is signed with key - "00.client.example.com.server.example.com". It includes data such - as: - - Question Section: - QNAME = 01.client.example.com. (Client can set this freely) - TYPE = TKEY - - Additional Section: - 01.client.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (DH exchange for key renewal) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - Additional Section also contains a KEY RR for DH and a TSIG RR. - - (6) As soon as Server receives this request, it verifies TSIG. It - is signed with the partially revoked key - "00.client.example.com.server.example.com". and Server accepts the - request. It creates a new key by Diffie-Hellman calculation and - returns an answer which includes data such as: - - Answer Section: - 01.client.example.com.server.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (DH exchange for key renewal) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - - -Kamite, et. al. Expires April 15, 2005 [Page 18] - -INTERNET-DRAFT October 2004 - - - Answer Section also contains KEY RRs for DH. - - Additional Section also contains a TSIG RR. - This response is signed with key - "00.client.example.com.server.example.com" without error. - - At the same time, Server decides to set the Partial Revocation Time - of this new key "01.client.example.com.server.example.com." as next - day's 15:00. - - (7) Client gets the response and checks TSIG MAC, and calculates - Diffie-Hellman. It will get a new key, and it has been named - "01.client.example.com.server.example.com" by Server. - - (8) At 20:07. Client sends an Adoption request to Server. This - request is signed with the previous key - "00.client.example.com.server.example.com". It includes: - - Question Section: - QNAME = 01.client.example.com.server.example.com. - TYPE = TKEY - - Additional Section: - 01.client.example.com.server.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (key adoption) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - Additional Section also contains a TSIG RR. - - (9) Server verifies the query's TSIG. It is signed with the - previous key and authenticated. It returns a response whose TKEY RR - is the same as the request's one. The response is signed with key - "00.client.example.com.server.example.com.". As soon as the - response is sent, Server revokes and removes the previous key. At - the same time, key "01.client.example.com.server.example.com." is - validated. - - (10) Client acknowledges the success of Adoption by receiving the - response. Then, it retries to send an original question about - "www2.example.com". It is signed with the adopted key - "01.client.example.com.server.example.com", so Server authenticates - it and returns an answer. - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 19] - -INTERNET-DRAFT October 2004 - - - (11) This key is used until next day's 15:00. After that, it will - be partially revoked again. - - -8. Security Considerations - - This document considers about how to refresh shared secret. Secret - changed by this method is used at servers in support of TSIG - [RFC2845]. - - [RFC2104] says that current attacks to HMAC do not indicate a - specific recommended frequency for key changes but periodic key - refreshment is a fundamental security practice that helps against - potential weaknesses of the function and keys, and limits the damage - of an exposed key. TKEY Secret Key Renewal provides the method of - periodical key refreshment. - - In TKEY Secret Key Renewal, clients need to send two requests - (Renewal and Adoption) and spend time to finish their key renewal - processes. Thus the usage period of secrets should be considered - carefully based on both TKEY processing performance and security. - - This document specifies the procedure of periodical key renewal, but - actually there is possibility for servers to have no choice other - than revoking their secret keys immediately especially when the keys - are found to be compromised by attackers. This is called "Emergency - Compulsory Revocation". For example, suppose the original Expiry - Limit was set at 21:00, Partial Revocation Time at 20:00 and - Inception Time at 1:00. if at 11:00 the key is found to be - compromised, the server sets Expiry Limit forcibly to be 11:00 or - before it. - - Consequently, once Compulsory Revocation (See section 4.) is carried - out, normal renewal process described in this document cannot be done - any more as far as the key is concerned. However, after such - accidents happened, the two hosts are able to establish secret keys - and begin renewal procedure only if they have other (non-compromised) - shared TSIG keys or safe SIG(0) keys for the authentication of - initial secret establishment such as Diffie-Hellman Exchanged Keying. - - -9. IANA Considerations - - IANA needs to allocate a value for "DH exchange for key renewal", - "server assignment for key renewal", "resolver assignment for key - renewal" and "key adoption" in the mode filed of TKEY. It also needs - to allocate a value for "PartialRevoke" from the extended RCODE - space. - - - -Kamite, et. al. Expires April 15, 2005 [Page 20] - -INTERNET-DRAFT October 2004 - - -10. Acknowledgements - - The authors would like to thank Olafur Gudmundsson, whose helpful - input and comments contributed greatly to this document. - - -11. References - -11.1. Normative References - -[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - -[RFC2539] - D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name - System (DNS)", RFC 2539, March 1999. - -[RFC2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, - May 2000. - -[RFC2930] - D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', - RFC 2930, September 2000. - -[RFC2931] - D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s - )", RFC 2931, September 2000. - -11.2. Informative References - -[RFC2104] - H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message - Authentication", RFC2104, February 1997. - - - - - - - - - - - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 21] - -INTERNET-DRAFT October 2004 - - -Authors' Addresses - - Yuji Kamite - NTT Communications Corporation - Tokyo Opera City Tower - 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo - 163-1421, Japan - EMail: y.kamite@ntt.com - - - Masaya Nakayama - Information Technology Center, The University of Tokyo - 2-11-16 Yayoi, Bunkyo-ku, Tokyo - 113-8658, Japan - EMail: nakayama@nc.u-tokyo.ac.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 22] - -INTERNET-DRAFT October 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 23] - - - diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt deleted file mode 100644 index eaf68656..00000000 --- a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt +++ /dev/null @@ -1,1501 +0,0 @@ -Network Working Group J. Ihren -Internet-Draft Autonomica AB -Expires: April 18, 2005 O. Kolkman - RIPE NCC - B. Manning - EP.net - October 18, 2004 - - - - An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for - DNSSEC Trust Anchors. - draft-ietf-dnsext-trustupdate-threshold-00 - - -Status of this Memo - - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - This Internet-Draft will expire on April 18, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - -Abstract - - - The DNS Security Extensions (DNSSEC) works by validating so called - chains of authority. The start of these chains of authority are - usually public keys that are anchored in the DNS clients. These keys - are known as the so called trust anchors. - - - - - -Ihren, et al. Expires April 18, 2005 [Page 1] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - This memo describes a method how these client trust anchors can be - replaced using the DNS validation and querying mechanisms (in-band) - when the key pairs used for signing by zone owner are rolled. - - - This memo also describes a method to establish the validity of trust - anchors for initial configuration, or priming, using out of band - mechanisms. - - -Table of Contents - - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry - Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction and Background . . . . . . . . . . . . . . . . . 5 - 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5 - 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7 - 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8 - 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9 - 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10 - 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11 - 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12 - 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12 - 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12 - 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12 - 3.6 Removal of trust anchors for a trust point . . . . . . . . 12 - 3.7 No need for resolver-side overlap of old and new keys . . 13 - 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14 - 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.1.1 Bootstrapping trust anchors using a priming key . . . 14 - 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15 - 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 6.1 Threshold-based Trust Update Security Considerations . . . 17 - 6.2 Priming Key Security Considerations . . . . . . . . . . . 17 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 - 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 - A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 - B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23 - B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23 - B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . 24 - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 2] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -1. Terminology - - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in - RFC2119 [1]. - - - The term "zone" refers to the unit of administrative control in the - Domain Name System. In this document "name server" denotes a DNS - name server that is authoritative (i.e. knows all there is to know) - for a DNS zone. A "zone owner" is the entity responsible for signing - and publishing a zone on a name server. The terms "authentication - chain", "bogus", "trust anchors" and "Island of Security" are defined - in [4]. Throughout this document we use the term "resolver" to mean - "Validating Stub Resolvers" as defined in [4]. - - - We use the term "security apex" as the zone for which a trust anchor - has been configured (by validating clients) and which is therefore, - by definition, at the root of an island of security. The - configuration of trust anchors is a client side issue. Therefore a - zone owner may not always know if their zone has become a security - apex. - - - A "stale anchor" is a trust anchor (a public key) that relates to a - key that is not used for signing. Since trust anchors indicate that - a zone is supposed to be secure a validator will mark the all data in - an island of security as bogus when all trust anchors become stale. - - - It is assumed that the reader is familiar with public key - cryptography concepts [REF: Schneier Applied Cryptography] and is - able to distinguish between the private and public parts of a key - based on the context in which we use the term "key". If there is a - possible ambiguity we will explicitly mention if a private or a - public part of a key is used. - - - The term "administrator" is used loosely throughout the text. In - some cases an administrator is meant to be a person, in other cases - the administrator may be a process that has been delegated certain - responsibilities. - - -1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points - - - Although the DNSSEC protocol does not make a distinction between - different keys the operational practice is that a distinction is made - between zone signing keys and key signing keys. A key signing key is - used to exclusively sign the DNSKEY Resource Record (RR) set at the - apex of a zone and the zone signing keys sign all the data in the - zone (including the DNSKEY RRset at the apex). - - - - - -Ihren, et al. Expires April 18, 2005 [Page 3] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - Keys that are intended to be used as the start of the authentication - chain for a particular zone, either because they are pointed to by a - parental DS RR or because they are configured as a trust anchor, are - called Secure Entry Point (SEP) keys. In practice these SEP keys - will be key signing keys. - - - In order for the mechanism described herein to work the keys that are - intended to be used as secure entry points MUST have the SEP [2] flag - set. In the examples it is assumed that keys with the SEP flag set - are used as key signing keys and thus exclusively sign the DNSKEY - RRset published at the apex of the zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 4] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -2. Introduction and Background - - - When DNSSEC signatures are validated the resolver constructs a chain - of authority from a pre-configured trust anchor to the DNSKEY - Resource Record (RR), which contains the public key that validates - the signature stored in an RRSIG RR. DNSSEC is designed so that the - administrator of a resolver can validate data in multiple islands of - security by configuring multiple trust anchors. - - - It is expected that resolvers will have more than one trust anchor - configured. Although there is no deployment experience it is not - unreasonable to expect resolvers to be configured with a number of - trust anchors that varies between order 1 and order 1000. Because - zone owners are expected to roll their keys, trust anchors will have - to be maintained (in the resolver end) in order not to become stale. - - - Since there is no global key maintenance policy for zone owners and - there are no mechanisms in the DNS to signal the key maintenance - policy it may be very hard for resolvers administrators to keep their - set of trust anchors up to date. For instance, if there is only one - trust anchor configured and the key maintenance policy is clearly - published, through some out of band trusted channel, then a resolver - administrator can probably keep track of key rollovers and update the - trust anchor manually. However, with an increasing number of trust - anchors all rolled according to individual policies that are all - published through different channels this soon becomes an - unmanageable problem. - - -2.1 Dangers of Stale Trust Anchors - - - Whenever a SEP key at a security apex is rolled there exists a danger - that "stale anchors" are created. A stale anchor is a trust anchor - (i.e. a public key configured in a validating resolver) that relates - to a private key that is no longer used for signing. - - - The problem with a stale anchors is that they will (from the - validating resolvers point of view) prove data to be false even - though it is actually correct. This is because the data is either - signed by a new key or is no longer signed and the resolver expects - data to be signed by the old (now stale) key. - - - This situation is arguably worse than not having a trusted key - configured for the secure entry point, since with a stale key no - lookup is typically possible (presuming that the default - configuration of a validating recursive nameserver is to not give out - data that is signed but failed to verify. - - - The danger of making configured trust anchors become stale anchors - - - - -Ihren, et al. Expires April 18, 2005 [Page 5] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - may be a reason for zone owners not to roll their keys. If a - resolver is configured with many trust anchors that need manual - maintenance it may be easy to not notice a key rollover at a security - apex, resulting in a stale anchor. - - - In Section 3 this memo sets out a lightweight, in-DNS, mechanism to - track key rollovers and modify the configured trust anchors - accordingly. The mechanism is stateless and does not need protocol - extensions. The proposed design is that this mechanism is - implemented as a "trust updating machine" that is run entirely - separate from the validating resolver except that the trust updater - will have influence over the trust anchors used by the latter. - - - In Section 4 we describe a method [Editors note: for now only the - frame work and a set of requirements] to install trust anchors. This - method can be used at first configuration or when the trust anchors - became stale (typically due to a failure to track several rollover - events). - - - The choice for which domains trust anchors are to be configured is a - local policy issue. So is the choice which trust anchors has - prevalence if there are multiple chains of trust to a given piece of - DNS data (e.g. when a parent zone and its child both have trust - anchors configured). Both issues are out of the scope of this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 6] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -3. Threshold-based Trust Anchor Rollover - - -3.1 The Rollover - - - When a key pair is replaced all signatures (in DNSSEC these are the - RRSIG records) created with the old key will be replaced by new - signatures created by the new key. Access to the new public key is - needed to verify these signatures. - - - Since zone signing keys are in "the middle" of a chain of authority - they can be verified using the signature made by a key signing key. - Rollover of zone signing keys is therefore transparent to validators - and requires no action in the validator end. - - - But if a key signing key is rolled a resolver can determine its - authenticity by either following the authorization chain from the - parents DS record, an out-of-DNS authentication mechanism or by - relying on other trust anchors known for the zone in which the key is - rolled. - - - The threshold trust anchor rollover mechanism (or trust update), - described below, is based on using existing trust anchors to verify a - subset of the available signatures. This is then used as the basis - for a decision to accept the new keys as valid trust anchors. - - - Our example pseudo zone below contains a number of key signing keys - numbered 1 through Y and two zone signing keys A and B. During a key - rollover key 2 is replaced by key Y+1. The zone content changes - from: - - - example.com. DNSKEY key1 - example.com. DNSKEY key2 - example.com. DNSKEY key3 - ... - example.com. DNSKEY keyY - - - example.com. DNSKEY keyA - example.com. DNSKEY keyB - - - example.com. RRSIG DNSKEY ... (key1) - example.com. RRSIG DNSKEY ... (key2) - example.com. RRSIG DNSKEY ... (key3) - ... - example.com. RRSIG DNSKEY ... (keyY) - example.com. RRSIG DNSKEY ... (keyA) - example.com. RRSIG DNSKEY ... (keyB) - - - to: - - - - -Ihren, et al. Expires April 18, 2005 [Page 7] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - example.com. DNSKEY key1 - example.com. DNSKEY key3 - ... - example.com. DNSKEY keyY - example.com. DNSKEY keyY+1 - - - example.com. RRSIG DNSKEY ... (key1) - example.com. RRSIG DNSKEY ... (key3) - ... - example.com. RRSIG DNSKEY ... (keyY) - example.com. RRSIG DNSKEY ... (keyY+1) - example.com. RRSIG DNSKEY ... (keyA) - example.com. RRSIG DNSKEY ... (keyB) - - - When the rollover becomes visible to the verifying stub resolver it - will be able to verify the RRSIGs associated with key1, key3 ... - keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will - not be used for validation, since that key is previously unknown and - therefore not trusted. - - - Note that this example is simplified. Because of operational - considerations described in [5] having a period during which the two - key signing keys are both available is necessary. - - -3.2 Threshold-based Trust Update - - - The threshold-based trust update algorithm applies as follows. If - for a particular secure entry point - o if the DNSKEY RRset in the zone has been replaced by a more recent - one (as determined by comparing the RRSIG inception dates) - and - o if at least M configured trust anchors directly verify the related - RRSIGs over the new DNSKEY RRset - and - o the number of configured trust anchors that verify the related - RRSIGs over the new DNSKEY RRset exceed a locally defined minimum - number that should be greater than one - then all the trust anchors for the particular secure entry point are - replaced by the set of keys from the zones DNSKEY RRset that have the - SEP flag set. - - - The choices for the rollover acceptance policy parameter M is left to - the administrator of the resolver. To be certain that a rollover is - accepted up by resolvers using this mechanism zone owners should roll - as few SEP keys at a time as possible (preferably just one). That - way they comply to the most strict rollover acceptance policy of - M=N-1. - - - - - -Ihren, et al. Expires April 18, 2005 [Page 8] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - The value of M has an upper bound, limited by the number of of SEP - keys a zone owner publishes (i.e. N). But there is also a lower - bound, since it will not be safe to base the trust in too few - signatures. The corner case is M=1 when any validating RRSIG will be - sufficient for a complete replacement of the trust anchors for that - secure entry point. This is not a recommended configuration, since - that will allow an attacker to initiate rollover of the trust anchors - himself given access to just one compromised key. Hence M should in - be strictly larger than 1 as shown by the third requirement above. - - - If the rollover acceptance policy is M=1 then the result for the - rollover in our example above should be that the local database of - trust anchors is updated by removing key "key2" from and adding key - "keyY+1" to the key store. - - -3.3 Possible Trust Update States - - - We define five states for trust anchor configuration at the client - side. - PRIMING: There are no trust anchors configured. There may be priming - keys available for initial priming of trust anchors. - IN-SYNC: The set of trust anchors configured exactly matches the set - of SEP keys used by the zone owner to sign the zone. - OUT-OF-SYNC: The set of trust anchors is not exactly the same as the - set of SEP keys used by the zone owner to sign the zone but there - are enough SEP key in use by the zone owner that is also in the - trust anchor configuration. - UNSYNCABLE: There is not enough overlap between the configured trust - anchors and the set of SEP keys used to sign the zone for the new - set to be accepted by the validator (i.e. the number of - signatures that verify is not sufficient). - STALE: There is no overlap between the configured trust anchors and - the set of SEP keys used to sign the zone. Here validation of - data is no longer possible and hence we are in a situation where - the trust anchors are stale. - - - Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of - the automatic trust update mechanism. The PRIMING state is where a - validator is located before acquiring an up-to-date set of trust - anchors. The transition from PRIMING to IN-SYNC is manual (see - Section 4 below). - - - Example: assume a secure entry point with four SEP keys and a - validator with the policy that it will accept any update to the set - of trust anchors as long as no more than two signatures fail to - validate (i.e. M >= N-2) and at least two signature does validate - (i.e. M >= 2). In this case the rollover of a single key will move - the validator from IN-SYNC to OUT-OF-SYNC. When the trust update - - - - -Ihren, et al. Expires April 18, 2005 [Page 9] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - state machine updates the trust anchors it returns to state IN-SYNC. - - - If if for some reason it fails to update the trust anchors then the - next rollover (of a different key) will move the validator from - OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys - that are configured as trust anchors and that is sufficient to accpt - an automatic update of the trust anchors. - - - The UNSYNCABLE state is where a validator is located if it for some - reason fails to incorporate enough updates to the trust anchors to be - able to accept new updates according to its local policy. In this - example (i.e. with the policy specified above) this will either be - because M < N-2 or M < 2, which does not suffice to authenticate a - successful update of trust anchors. - - - Continuing with the previous example where two of the four SEP keys - have already rolled, but the validator has failed to update the set - of trust anchors. When the third key rolls over there will only be - one trust anchor left that can do successful validation. This is not - sufficient to enable automatic update of the trust anchors, hence the - new state is UNSYNCABLE. Note, however, that the remaining - up-to-date trust anchor is still enough to do successful validation - so the validator is still "working" from a DNSSEC point of view. - - - The STALE state, finally, is where a validator ends up when it has - zero remaining current trust anchors. This is a dangerous state, - since the stale trust anchors will cause all validation to fail. The - escape is to remove the stale trust anchors and thereby revert to the - PRIMING state. - - -3.4 Implementation notes - - - The DNSSEC protocol specification ordains that a DNSKEY to which a DS - record points should be self-signed. Since the keys that serve as - trust anchors and the keys that are pointed to by DS records serve - the same purpose, they are both secure entry points, we RECOMMEND - that zone owners who want to facilitate the automated rollover scheme - documented herein self-sign DNSKEYs with the SEP bit set and that - implementation check that DNSKEYs with the SEP bit set are - self-signed. - - - In order to maintain a uniform way of determining that a keyset in - the zone has been replaced by a more recent set the automatic trust - update machine SHOULD only accept new DNSKEY RRsets if the - accompanying RRSIGs show a more recent inception date than the - present set of trust anchors. This is also needed as a safe guard - against possible replay attacks where old updates are replayed - "backwards" (i.e. one change at a time, but going in the wrong - - - - -Ihren, et al. Expires April 18, 2005 [Page 10] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - direction, thereby luring the validator into the UNSYNCABLE and - finally STALE states). - - - In order to be resilient against failures the implementation should - collect the DNSKEY RRsets from (other) authoritative servers if - verification of the self signatures fails. - - - The threshold-based trust update mechanism SHOULD only be applied to - algorithms, as represented in the algorithm field in the DNSKEY/RRSIG - [3], that the resolver is aware of. In other words the SEP keys of - unknown algorithms should not be used when counting the number of - available signatures (the N constant) and the SEP keys of unknown - algorithm should not be entered as trust anchors. - - - When in state UNSYNCABLE or STALE manual intervention will be needed - to return to the IN-SYNC state. These states should be flagged. The - most appropriate action is human audit possibly followed by - re-priming (Section 4) the keyset (i.e. manual transfer to the - PRIMING state through removal of the configured trust anchors). - - - An implementation should regularly probe the the authoritative - nameservers for new keys. Since there is no mechanism to publish - rollover frequencies this document RECOMMENDS zone owners not to roll - their key signing keys more often than once per month and resolver - administrators to probe for key rollsovers (and apply the threshold - criterion for acceptance of trust update) not less often than once - per month. If the rollover frequency is higher than the probing - frequency then trust anchors may become stale. The exact relation - between the frequencies depends on the number of SEP keys rolled by - the zone owner and the value M configured by the resolver - administrator. - - - In all the cases below a transaction where the threshold criterion is - not satisfied should be considered bad (i.e. possibly spoofed or - otherwise corrupted data). The most appropriate action is human - audit. - - - There is one case where a "bad" state may be escaped from in an - automated fashion. This is when entering the STALE state where all - DNSSEC validation starts to fail. If this happens it is concievable - that it is better to completely discard the stale trust anchors - (thereby reverting to the PRIMING state where validation is not - possible). A local policy that automates removal of stale trust - anchors is therefore suggested. - - -3.5 Possible transactions - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 11] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -3.5.1 Single DNSKEY replaced - - - This is probably the most typical transaction on the zone owners - part. The result should be that if the threshold criterion is - satisfied then the key store is updated by removal of the old trust - anchor and addition of the new key as a new trust anchor. Note that - if the DNSKEY RRset contains exactly M keys replacement of keys is - not possible, i.e. for automatic rollover to work M must be stricly - less than N. - - -3.5.2 Addition of a new DNSKEY (no removal) - - - If the threshold criterion is satisfied then the new key is added as - a configured trust anchor. Not more than N-M keys can be added at - once, since otherwise the algorithm will fail. - - -3.5.3 Removal of old DNSKEY (no addition) - - - If the threshold criterion is satisfied then the old key is removed - from being a configured trust anchor. Note that it is not possible - to reduce the size of the DNSKEY RRset to a size smaller than the - minimum required value for M. - - -3.5.4 Multiple DNSKEYs replaced - - - Arguably it is not a good idea for the zone administrator to replace - several keys at the same time, but from the resolver point of view - this is exactly what will happen if the validating resolver for some - reason failed to notice a previous rollover event. - - - Not more than N-M keys can be replaced at one time or the threshold - criterion will not be satisfied. Or, expressed another way: as long - as the number of changed keys is less than or equal to N-M the - validator is in state OUT-OF-SYNC. When the number of changed keys - becomes greater than N-M the state changes to UNSYNCABLE and manual - action is needed. - - -3.6 Removal of trust anchors for a trust point - - - If the parent of a secure entry point gets signed and it's trusted - keys get configured in the key store of the validating resolver then - the configured trust anchors for the child should be removed entirely - unless explicitly configured (in the utility configuration) to be an - exception. - - - The reason for such a configuration would be that the resolver has a - local policy that requires maintenance of trusted keys further down - the tree hierarchy than strictly needed from the point of view. - - - - -Ihren, et al. Expires April 18, 2005 [Page 12] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - The default action when the parent zone changes from unsigned to - signed should be to remove the configured trust anchors for the - child. This form of "garbage collect" will ensure that the automatic - rollover machinery scales as DNSSEC deployment progresses. - - -3.7 No need for resolver-side overlap of old and new keys - - - It is worth pointing out that there is no need for the resolver to - keep state about old keys versus new keys, beyond the requirement of - tracking signature inception time for the covering RRSIGs as - described in Section 3.4. - - - From the resolver point of view there are only trusted and not - trusted keys. The reason is that the zone owner needs to do proper - maintenance of RRSIGs regardless of the resolver rollover mechanism - and hence must ensure that no key rolled out out the DNSKEY set until - there cannot be any RRSIGs created by this key still legally cached. - - - Hence the rollover mechanism is entirely stateless with regard to the - keys involved: as soon as the resolver (or in this case the rollover - tracking utility) detects a change in the DNSKEY RRset (i.e. it is - now in the state OUT-OF-SYNC) with a sufficient number of matching - RRSIGs the configured trust anchors are immediately updated (and - thereby the machine return to state IN-SYNC). I.e. the rollover - machine changes states (mostly oscillating between IN-SYNC and - OUT-OF-SYNC), but the status of the DNSSEC keys is stateless. - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 13] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -4. Bootstrapping automatic rollovers - - - It is expected that with the ability to automatically roll trust - anchors at trust points will follow a diminished unwillingness to - roll these keys, since the risks associated with stale keys are - minimized. - - - The problem of "priming" the trust anchors, or bringing them into - sync (which could happen if a resolver is off line for a long period - in which a set of SEP keys in a zone 'evolve' away from its trust - anchor configuration) remains. - - - For (re)priming we can rely on out of band technology and we propose - the following framework. - - -4.1 Priming Keys - - - If all the trust anchors roll somewhat frequently (on the order of - months or at most about a year) then it will not be possible to - design a device, or a software distribution that includes trust - anchors, that after being manufactured is put on a shelf for several - key rollover periods before being brought into use (since no trust - anchors that were known at the time of manufacture remain active). - - - To alleviate this we propose the concept of "priming keys". Priming - keys are ordinary DNSSEC Key Signing Keys with the characteristic - that - o The private part of a priming key signs the DNSKEY RRset at the - security apex, i.e. at least one RRSIG DNSKEY is created by a - priming key rather than by an "ordinary" trust anchor - o the public parts of priming keys are not included in the DNSKEY - RRset. Instead the public parts of priming keys are only - available out-of-band. - o The public parts of the priming keys have a validity period. - Within this period they can be used to obtain trust anchors. - o The priming key pairs are long lived (relative to the key rollover - period.) - - -4.1.1 Bootstrapping trust anchors using a priming key - - - To install the trust anchors for a particular security apex an - administrator of a validating resolver will need to: - o query for the DNSKEY RRset of the zone at the security apex; - o verify the self signatures of all DNSKEYs in the RRset; - o verify the signature of the RRSIG made with a priming key -- - verification using one of the public priming keys that is valid at - that moment is sufficient; - - - - - -Ihren, et al. Expires April 18, 2005 [Page 14] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - o create the trust anchors by extracting the DNSKEY RRs with the SEP - flag set. - The SEP keys with algorithms unknown to the validating resolver - SHOULD be ignored during the creation of the trust anchors. - - -4.1.2 Distribution of priming keys - - - The public parts of the priming keys SHOULD be distributed - exclusively through out-of-DNS mechanisms. The requirements for a - distribution mechanism are: - o it can carry the "validity" period for the priming keys; - o it can carry the self-signature of the priming keys; - o and it allows for verification using trust relations outside the - DNS. - A distribution mechanism would benefit from: - o the availability of revocation lists; - o the ability of carrying zone owners policy information such as - recommended values for "M" and "N" and a rollover frequency; - o and the technology on which is based is readily available. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 15] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -5. The Threshold Rollover Mechanism vs Priming - - - There is overlap between the threshold-based trust updater and the - Priming method. One could exclusively use the Priming method for - maintaining the trust anchors. However the priming method probably - relies on "non-DNS' technology and may therefore not be available for - all devices that have a resolver. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 16] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -6. Security Considerations - - -6.1 Threshold-based Trust Update Security Considerations - - - A clear issue for resolvers will be how to ensure that they track all - rollover events for the zones they have configure trust anchors for. - Because of temporary outages validating resolvers may have missed a - rollover of a KSK. The parameters that determine the robustness - against failures are: the length of the period between rollovers - during which the KSK set is stable and validating resolvers can - actually notice the change; the number of available KSKs (i.e. N) - and the number of signatures that may fail to validate (i.e. N-M). - - - With a large N (i.e. many KSKs) and a small value of M this - operation becomes more robust since losing one key, for whatever - reason, will not be crucial. Unfortunately the choice for the number - of KSKs is a local policy issue for the zone owner while the choice - for the parameter M is a local policy issue for the resolver - administrator. - - - Higher values of M increase the resilience against attacks somewhat; - more signatures need to verify for a rollover to be approved. On the - other hand the number of rollover events that may pass unnoticed - before the resolver reaches the UNSYNCABLE state goes down. - - - The threshold-based trust update intentionally does not provide a - revocation mechanism. In the case that a sufficient number of - private keys of a zone owner are simultaneously compromised the the - attacker may use these private keys to roll the trust anchors of (a - subset of) the resolvers. This is obviously a bad situation but it - is not different from most other public keys systems. - - - However, it is important to point out that since any reasonable trust - anchor rollover policy (in validating resolvers) will require more - than one RRSIG to validate this proposal does provide security - concious zone administrators with the option of not storing the - individual private keys in the same location and thereby decreasing - the likelihood of simultaneous compromise. - - -6.2 Priming Key Security Considerations - - - Since priming keys are not included in the DNSKEY RR set they are - less sensitive to packet size constraints and can be chosen - relatively large. The private parts are only needed to sign the - DNSKEY RR set during the validity period of the particular priming - key pair. Note that the private part of the priming key is used each - time when a DNSKEY RRset has to be resigned. In practice there is - therefore little difference between the usage pattern of the private - - - - -Ihren, et al. Expires April 18, 2005 [Page 17] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - part of key signing keys and priming keys. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 18] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -7. IANA Considerations - - - NONE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 19] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -8. References - - -8.1 Normative References - - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - - [3] Arends, R., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-10 (work in progress), - September 2004. - - -8.2 Informative References - - - [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-12 (work in progress), September - 2004. - - - [5] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practices-01 (work in - progress), May 2004. - - - [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 - Public Key Infrastructure Certificate and CRL Profile", RFC - 2459, January 1999. - - - -Authors' Addresses - - - Johan Ihren - Autonomica AB - Bellmansgatan 30 - Stockholm SE-118 47 - Sweden - - - EMail: johani@autonomica.se - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 20] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - NL - - - Phone: +31 20 535 4444 - EMail: olaf@ripe.net - URI: http://www.ripe.net/ - - - - Bill Manning - EP.net - Marina del Rey, CA 90295 - USA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 21] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Appendix A. Acknowledgments - - - The present design for in-band automatic rollovers of DNSSEC trust - anchors is the result of many conversations and it is no longer - possible to remember exactly who contributed what. - - - In addition we've also had appreciated help from (in no particular - order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt - Larson and Mark Kosters. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 22] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Appendix B. Document History - - - This appendix will be removed if and when the document is submitted - to the RFC editor. - - - The version you are reading is tagged as $Revision: 1.1 $. - - - Text between square brackets, other than references, are editorial - comments and will be removed. - - -B.1 prior to version 00 - - - This draft was initially published as a personal submission under the - name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt. - - - Kolkman documented the ideas provided by Ihren and Manning. In the - process of documenting (and prototyping) Kolkman changed some of the - details of the M-N algorithms working. Ihren did not have a chance - to review the draft before Kolkman posted; - - - Kolkman takes responsibilities for omissions, fuzzy definitions and - mistakes. - - -B.2 version 00 - o The name of the draft was changed as a result of the draft being - adopted as a working group document. - o A small section on the concept of stale trust anchors was added. - o The different possible states are more clearly defined, including - examples of transitions between states. - o The terminology is changed throughout the document. The old term - "M-N" is replaced by "threshold" (more or less). Also the - interpretation of the constants M and N is significantly - simplified to bring the usage more in line with "standard" - threshold terminlogy. - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 23] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Ihren, et al. Expires April 18, 2005 [Page 24]
\ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt deleted file mode 100644 index 02852591..00000000 --- a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt +++ /dev/null @@ -1,729 +0,0 @@ - - - -Network Working Group M. StJohns -Internet-Draft Nominum, Inc. -Intended status: Informational November 29, 2006 -Expires: June 2, 2007 - - - Automated Updates of DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-timers-05 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on June 2, 2007. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes a means for automated, authenticated and - authorized updating of DNSSEC "trust anchors". The method provides - protection against N-1 key compromises of N keys in the trust point - key set. Based on the trust established by the presence of a current - anchor, other anchors may be added at the same place in the - hierarchy, and, ultimately, supplant the existing anchor(s). - - This mechanism will require changes to resolver management behavior - - - -StJohns Expires June 2, 2007 [Page 1] - -Internet-Draft trustanchor-update November 2006 - - - (but not resolver resolution behavior), and the addition of a single - flag bit to the DNSKEY record. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 - 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5 - 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 - 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 - 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 - 2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 - 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 - 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8 - 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9 - 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9 - 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 - 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 - 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 - 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 - 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 - 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11 - 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 - 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 - Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . . . 13 - - - - - - - - - - - - - - -StJohns Expires June 2, 2007 [Page 2] - -Internet-Draft trustanchor-update November 2006 - - -1. Introduction - - As part of the reality of fielding DNSSEC (Domain Name System - Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has - come to the realization that there will not be one signed name space, - but rather islands of signed name space each originating from - specific points (i.e. 'trust points') in the DNS tree. Each of those - islands will be identified by the trust point name, and validated by - at least one associated public key. For the purpose of this document - we'll call the association of that name and a particular key a 'trust - anchor'. A particular trust point can have more than one key - designated as a trust anchor. - - For a DNSSEC-aware resolver to validate information in a DNSSEC - protected branch of the hierarchy, it must have knowledge of a trust - anchor applicable to that branch. It may also have more than one - trust anchor for any given trust point. Under current rules, a chain - of trust for DNSSEC-protected data that chains its way back to ANY - known trust anchor is considered 'secure'. - - Because of the probable balkanization of the DNSSEC tree due to - signing voids at key locations, a resolver may need to know literally - thousands of trust anchors to perform its duties. (e.g. Consider an - unsigned ".COM".) Requiring the owner of the resolver to manually - manage this many relationships is problematic. It's even more - problematic when considering the eventual requirement for key - replacement/update for a given trust anchor. The mechanism described - herein won't help with the initial configuration of the trust anchors - in the resolvers, but should make trust point key replacement/ - rollover more viable. - - As mentioned above, this document describes a mechanism whereby a - resolver can update the trust anchors for a given trust point, mainly - without human intervention at the resolver. There are some corner - cases discussed (e.g. multiple key compromise) that may require - manual intervention, but they should be few and far between. This - document DOES NOT discuss the general problem of the initial - configuration of trust anchors for the resolver. - -1.1. Compliance Nomenclature - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, [RFC2119]. - - - - - - - -StJohns Expires June 2, 2007 [Page 3] - -Internet-Draft trustanchor-update November 2006 - - -2. Theory of Operation - - The general concept of this mechanism is that existing trust anchors - can be used to authenticate new trust anchors at the same point in - the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a - DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section - 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is - validated by an existing trust anchor, then the resolver can add the - new key to its valid set of trust anchors for that trust point. - - There are some issues with this approach which need to be mitigated. - For example, a compromise of one of the existing keys could allow an - attacker to add their own 'valid' data. This implies a need for a - method to revoke an existing key regardless of whether or not that - key is compromised. As another example, assuming a single key - compromise, we need to prevent an attacker from adding a new key and - revoking all the other old keys. - -2.1. Revocation - - Assume two trust anchor keys A and B. Assume that B has been - compromised. Without a specific revocation bit, B could invalidate A - simply by sending out a signed trust point key set which didn't - contain A. To fix this, we add a mechanism which requires knowledge - of the private key of a DNSKEY to revoke that DNSKEY. - - A key is considered revoked when the resolver sees the key in a self- - signed RRSet and the key has the REVOKE bit (see Section 7 below) set - to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this - key as a trust anchor or for any other purposes except validating the - RRSIG it signed over the DNSKEY RRSet specifically for the purpose of - validating the revocation. Unlike the 'Add' operation below, - revocation is immediate and permanent upon receipt of a valid - revocation at the resolver. - - A self-signed RRSet is a DNSKEY RRSet which contains the specific - DNSKEY and for which there is a corresponding validated RRSIG record. - It's not a special DNSKEY RRSet, just a way of describing the - validation requirements for that RRSet. - - N.B. A DNSKEY with the REVOKE bit set has a different fingerprint - than one without the bit set. This affects the matching of a DNSKEY - to DS records in the parent, or the fingerprint stored at a resolver - used to configure a trust point. - - In the given example, the attacker could revoke B because it has - knowledge of B's private key, but could not revoke A. - - - - -StJohns Expires June 2, 2007 [Page 4] - -Internet-Draft trustanchor-update November 2006 - - -2.2. Add Hold-Down - - Assume two trust point keys A and B. Assume that B has been - compromised. An attacker could generate and add a new trust anchor - key - C (by adding C to the DNSKEY RRSet and signing it with B), and - then invalidate the compromised key. This would result in both the - attacker and owner being able to sign data in the zone and have it - accepted as valid by resolvers. - - To mitigate but not completely solve this problem, we add a hold-down - time to the addition of the trust anchor. When the resolver sees a - new SEP key in a validated trust point DNSKEY RRSet, the resolver - starts an acceptance timer, and remembers all the keys that validated - the RRSet. If the resolver ever sees the DNSKEY RRSet without the - new key but validly signed, it stops the acceptance process for that - key and resets the acceptance timer. If all of the keys which were - originally used to validate this key are revoked prior to the timer - expiring, the resolver stops the acceptance process and resets the - timer. - - Once the timer expires, the new key will be added as a trust anchor - the next time the validated RRSet with the new key is seen at the - resolver. The resolver MUST NOT treat the new key as a trust anchor - until the hold down time expires AND it has retrieved and validated a - DNSKEY RRSet after the hold down time which contains the new key. - - N.B.: Once the resolver has accepted a key as a trust anchor, the key - MUST be considered a valid trust anchor by that resolver until - explictly revoked as described above. - - In the given example, the zone owner can recover from a compromise by - revoking B and adding a new key D and signing the DNSKEY RRSet with - both A and B. - - The reason this does not completely solve the problem has to do with - the distributed nature of DNS. The resolver only knows what it sees. - A determined attacker who holds one compromised key could keep a - single resolver from realizing that key had been compromised by - intercepting 'real' data from the originating zone and substituting - their own (e.g. using the example, signed only by B). This is no - worse than the current situation assuming a compromised key. - -2.3. Active Refresh - - A resolver which has been configured for automatic update of keys - from a particular trust point MUST query that trust point (e.g. do a - lookup for the DNSKEY RRSet and related RRSIG records) no less often - than the lesser of 15 days or half the original TTL for the DNSKEY - - - -StJohns Expires June 2, 2007 [Page 5] - -Internet-Draft trustanchor-update November 2006 - - - RRSet or half the RRSIG expiration interval and no more often than - once per hour. The expiration interval is the amount of time from - when the RRSIG was last retrieved until the expiration time in the - RRSIG. - - If the query fails, the resolver MUST repeat the query until - satisfied no more often than once an hour and no less often than the - lesser of 1 day or 10% of the original TTL or 10% of the original - expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 * - origTTL, .1 * expireInterval)). - -2.4. Resolver Parameters - -2.4.1. Add Hold-Down Time - - The add hold-down time is 30 days or the expiration time of the - original TTL of the first trust point DNSKEY RRSet which contained - the new key, whichever is greater. This ensures that at least two - validated DNSKEY RRSets which contain the new key MUST be seen by the - resolver prior to the key's acceptance. - -2.4.2. Remove Hold-Down Time - - The remove hold-down time is 30 days. This parameter is solely a key - management database bookeeping parameter. Failure to remove - information about the state of defunct keys from the database will - not adversely impact the security of this protocol, but may end up - with a database cluttered with obsolete key information. - -2.4.3. Minimum Trust Anchors per Trust Point - - A compliant resolver MUST be able to manage at least five SEP keys - per trust point. - - -3. Changes to DNSKEY RDATA Wire Format - - Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE' - flag. If this bit is set to '1', AND the resolver sees an - RRSIG(DNSKEY) signed by the associated key, then the resolver MUST - consider this key permanently invalid for all purposes except for - validating the revocation. - - -4. State Table - - The most important thing to understand is the resolver's view of any - key at a trust point. The following state table describes that view - - - -StJohns Expires June 2, 2007 [Page 6] - -Internet-Draft trustanchor-update November 2006 - - - at various points in the key's lifetime. The table is a normative - part of this specification. The initial state of the key is 'Start'. - The resolver's view of the state of the key changes as various events - occur. - - This is the state of a trust point key as seen from the resolver. - The column on the left indicates the current state. The header at - the top shows the next state. The intersection of the two shows the - event that will cause the state to transition from the current state - to the next. - - - NEXT STATE - -------------------------------------------------- - FROM |Start |AddPend |Valid |Missing|Revoked|Removed| - ---------------------------------------------------------- - Start | |NewKey | | | | | - ---------------------------------------------------------- - AddPend |KeyRem | |AddTime| | | - ---------------------------------------------------------- - Valid | | | |KeyRem |Revbit | | - ---------------------------------------------------------- - Missing | | |KeyPres| |Revbit | | - ---------------------------------------------------------- - Revoked | | | | | |RemTime| - ---------------------------------------------------------- - Removed | | | | | | | - ---------------------------------------------------------- - - - State Table - -4.1. Events - NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. - That key will become a new trust anchor for the named trust point - after it's been present in the RRSet for at least 'add time'. - KeyPres The key has returned to the valid DNSKEY RRSet. - KeyRem The resolver sees a valid DNSKEY RRSet that does not contain - this key. - AddTime The key has been in every valid DNSKEY RRSet seen for at - least the 'add time'. - RemTime A revoked key has been missing from the trust point DNSKEY - RRSet for sufficient time to be removed from the trust set. - RevBit The key has appeared in the trust anchor DNSKEY RRSet with - its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet - signed by this key. - - - - - -StJohns Expires June 2, 2007 [Page 7] - -Internet-Draft trustanchor-update November 2006 - - -4.2. States - Start The key doesn't yet exist as a trust anchor at the resolver. - It may or may not exist at the zone server, but either hasn't yet - been seen at the resolver or was seen but was absent from the last - DNSKEY RRSet (e.g. KeyRem event). - AddPend The key has been seen at the resolver, has its 'SEP' bit - set, and has been included in a validated DNSKEY RRSet. There is - a hold-down time for the key before it can be used as a trust - anchor. - Valid The key has been seen at the resolver and has been included in - all validated DNSKEY RRSets from the time it was first seen up - through the hold-down time. It is now valid for verifying RRSets - that arrive after the hold down time. Clarification: The DNSKEY - RRSet does not need to be continuously present at the resolver - (e.g. its TTL might expire). If the RRSet is seen, and is - validated (i.e. verifies against an existing trust anchor), this - key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. - Missing This is an abnormal state. The key remains as a valid trust - point key, but was not seen at the resolver in the last validated - DNSKEY RRSet. This is an abnormal state because the zone operator - should be using the REVOKE bit prior to removal. - Revoked This is the state a key moves to once the resolver sees an - RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains - this key with its REVOKE bit set to '1'. Once in this state, this - key MUST permanently be considered invalid as a trust anchor. - Removed After a fairly long hold-down time, information about this - key may be purged from the resolver. A key in the removed state - MUST NOT be considered a valid trust anchor. (Note: this state is - more or less equivalent to the "Start" state, except that it's bad - practice to re-introduce previously used keys - think of this as - the holding state for all the old keys for which the resolver no - longer needs to track state.) - - -5. Trust Point Deletion - - A trust point which has all of its trust anchors revoked is - considered deleted and is treated as if the trust point was never - configured. If there are no superior configured trust points, data - at and below the deleted trust point are considered insecure by the - resolver. If there ARE superior configured trust points, data at and - below the deleted trust point are evaluated with respect to the - superior trust point(s). - - Alternately, a trust point which is subordinate to another configured - trust point MAY be deleted by a resolver after 180 days where such - subordinate trust point validly chains to a superior trust point. - The decision to delete the subordinate trust anchor is a local - - - -StJohns Expires June 2, 2007 [Page 8] - -Internet-Draft trustanchor-update November 2006 - - - configuration decision. Once the subordinate trust point is deleted, - validation of the subordinate zone is dependent on validating the - chain of trust to the superior trust point. - - -6. Scenarios - Informative - - The suggested model for operation is to have one active key and one - stand-by key at each trust point. The active key will be used to - sign the DNSKEY RRSet. The stand-by key will not normally sign this - RRSet, but the resolver will accept it as a trust anchor if/when it - sees the signature on the trust point DNSKEY RRSet. - - Since the stand-by key is not in active signing use, the associated - private key may (and should) be provided with additional protections - not normally available to a key that must be used frequently. E.g. - locked in a safe, split among many parties, etc. Notionally, the - stand-by key should be less subject to compromise than an active key, - but that will be dependent on operational concerns not addressed - here. - -6.1. Adding a Trust Anchor - - Assume an existing trust anchor key 'A'. - 1. Generate a new key pair. - 2. Create a DNSKEY record from the key pair and set the SEP and Zone - Key bits. - 3. Add the DNSKEY to the RRSet. - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - - 'A'. - 5. Wait a while (i.e. for various resolvers timers to go off and for - them to retrieve the new DNSKEY RRSet and signatures). - 6. The new trust anchor will be populated at the resolvers on the - schedule described by the state table and update algorithm - see - Section 2 above - -6.2. Deleting a Trust Anchor - - Assume existing trust anchors 'A' and 'B' and that you want to revoke - and delete 'A'. - 1. Set the revocation bit on key 'A'. - 2. Sign the DNSKEY RRSet with both 'A' and 'B'. - 'A' is now revoked. The operator should include the revoked 'A' in - the RRSet for at least the remove hold-down time, but then may remove - it from the DNSKEY RRSet. - - - - - - -StJohns Expires June 2, 2007 [Page 9] - -Internet-Draft trustanchor-update November 2006 - - -6.3. Key Roll-Over - - Assume existing keys A and B. 'A' is actively in use (i.e. has been - signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been - in the DNSKEY RRSet and is a valid trust anchor, but wasn't being - used to sign the RRSet.) - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'A'. - 4. Sign the RRSet with 'A' and 'B'. - 'A' is now revoked, 'B' is now the active key, and 'C' will be the - stand-by key once the hold-down expires. The operator should include - the revoked 'A' in the RRSet for at least the remove hold-down time, - but may then remove it from the DNSKEY RRSet. - -6.4. Active Key Compromised - - This is the same as the mechanism for Key Roll-Over (Section 6.3) - above assuming 'A' is the active key. - -6.5. Stand-by Key Compromised - - Using the same assumptions and naming conventions as Key Roll-Over - (Section 6.3) above: - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'B'. - 4. Sign the RRSet with 'A' and 'B'. - 'B' is now revoked, 'A' remains the active key, and 'C' will be the - stand-by key once the hold-down expires. 'B' should continue to be - included in the RRSet for the remove hold-down time. - -6.6. Trust Point Deletion - - To delete a trust point which is subordinate to another configured - trust point (e.g. example.com to .com) requires some juggling of the - data. The specific process is: - 1. Generate a new DNSKEY and DS record and provide the DS record to - the parent along with DS records for the old keys - 2. Once the parent has published the DSs, add the new DNSKEY to the - RRSet and revoke ALL of the old keys at the same time while - signing the DNSKEY RRSet with all of the old and new keys. - 3. After 30 days stop publishing the old, revoked keys and remove - any corresponding DS records in the parent. - Revoking the old trust point keys at the same time as adding new keys - that chain to a superior trust prevents the resolver from adding the - new keys as trust anchors. Adding DS records for the old keys avoids - a race condition where either the subordinate zone becomes unsecure - - - -StJohns Expires June 2, 2007 [Page 10] - -Internet-Draft trustanchor-update November 2006 - - - (because the trust point was deleted) or becomes bogus (because it - didn't chain to the superior zone). - - -7. IANA Considerations - - The IANA will need to assign a bit in the DNSKEY flags field (see - section 4.3 of [RFC3755]) for the REVOKE bit. There are no other - IANA actions required. - - -8. Security Considerations - - In addition to the following sections, see also Theory of Operation - above and especially Section 2.2 for related discussions. - -8.1. Key Ownership vs Acceptance Policy - - The reader should note that, while the zone owner is responsible for - creating and distributing keys, it's wholly the decision of the - resolver owner as to whether to accept such keys for the - authentication of the zone information. This implies the decision to - update trust anchor keys based on trust for a current trust anchor - key is also the resolver owner's decision. - - The resolver owner (and resolver implementers) MAY choose to permit - or prevent key status updates based on this mechanism for specific - trust points. If they choose to prevent the automated updates, they - will need to establish a mechanism for manual or other out-of-band - updates outside the scope of this document. - -8.2. Multiple Key Compromise - - This scheme permits recovery as long as at least one valid trust - anchor key remains uncompromised. E.g. if there are three keys, you - can recover if two of them are compromised. The zone owner should - determine their own level of comfort with respect to the number of - active valid trust anchors in a zone and should be prepared to - implement recovery procedures once they detect a compromise. A - manual or other out-of-band update of all resolvers will be required - if all trust anchor keys at a trust point are compromised. - -8.3. Dynamic Updates - - Allowing a resolver to update its trust anchor set based on in-band - key information is potentially less secure than a manual process. - However, given the nature of the DNS, the number of resolvers that - would require update if a trust anchor key were compromised, and the - - - -StJohns Expires June 2, 2007 [Page 11] - -Internet-Draft trustanchor-update November 2006 - - - lack of a standard management framework for DNS, this approach is no - worse than the existing situation. - - -9. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -Editorial Comments - - [msj2] msj: To be assigned. - - -Author's Address - - Michael StJohns - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - USA - - Phone: +1-301-528-4729 - Email: Mike.StJohns@nominum.com - URI: www.nominum.com - - - - - - - - - - - -StJohns Expires June 2, 2007 [Page 12] - -Internet-Draft trustanchor-update November 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -StJohns Expires June 2, 2007 [Page 13] - - diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt deleted file mode 100644 index 9cf88a58..00000000 --- a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt +++ /dev/null @@ -1,1063 +0,0 @@ -Internet-Draft dnsext-wcard January 9, 2006 - -DNSEXT Working Group E. Lewis -INTERNET DRAFT NeuStar -Expiration Date: July 9, 2006 January 9, 2006 -Updates RFC 1034, RFC 2672 - - The Role of Wildcards - in the Domain Name System - draft-ietf-dnsext-wcard-clarify-10.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that - any applicable patent or other IPR claims of which he or she is - aware have been or will be disclosed, and any of which he or she - becomes aware will be disclosed, in accordance with Section 6 of - BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on July 9, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This is an update to the wildcard definition of RFC 1034. The - interaction with wildcards and CNAME is changed, an error - condition removed, and the words defining some concepts central - to wildcards are changed. The overall goal is not to change - wildcards, but to refine the definition of RFC 1034. - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 1] - -Internet-Draft dnsext-wcard January 9, 2006 - -Table of Contents - -1. Introduction . . . . . . . . . . . . . . . . 3 -1 1 Motivation 3 -1 2 The Original Definition 3 -1 3 Roadmap to This Document 4 -1 3 1 New Terms 4 -1.3.2 Changed Text 5 -1.3.3 Considerations with Special Types 5 -1.4 Standards Terminology 5 -2. Wildcard Syntax . . . . . . . . . . . . . . . 6 -2.1 Identifying a Wildcard 6 -2.1.1 Wild Card Domain Name and Asterisk Label 6 -2.1.2 Asterisks and Other Characters 6 -2.1.3 Non-terminal Wild Card Domain Names 6 -2.2 Existence Rules 7 -2.2.1 An Example 7 -2.2.2 Empty Non-terminals 9 -2.2.3 Yet Another Definition of Existence 10 -2.3 When is a Wild Card Domain Name Not Special 10 -3. Impact of a Wild Card Domain Name On a Response . . . . . 10 -3.1 Step 2 10 -3.2 Step 3 11 -3.3 Part 'c' 11 -3.3.1 Closest Encloser and the Source of Synthesis 12 -3.3.2 Closest Encloser and Source of Synthesis Examples 12 -3.3.3 Type Matching 13 -4. Considerations with Special Types . . . . . . . . . 13 -4.1 SOA RRSet at a Wild Card Domain Name 13 -4.2 NS RRSet at a Wild Card Domain Name 14 -4.2.1 Discarded Notions 14 -4.3 CNAME RRSet at a Wild Card Domain Name 15 -4.4 DNAME RRSet at a Wild Card Domain Name 15 -4.5 SRV RRSet at a Wild Card Domain Name 16 -4.6 DS RRSet at a Wild Card Domain Name 16 -4.7 NSEC RRSet at a Wild Card Domain Name 17 -4.8 RRSIG at a Wild Card Domain Name 17 -4.9 Empty Non-terminal Wild Card Domain Name 17 -5. Security Considerations . . . . . . . . . . . . . 17 -6. IANA Considerations . . . . . . . . . . . . . 17 -7. References . . . . . . . . . . . . . 17 -8. Editor . . . . . . . . . . . . . 18 -9. Others Contributing to the Document . . . . . . . . 18 -10. Trailing Boilerplate . . . . . . . . . . . . . 19 - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 2] - -Internet-Draft dnsext-wcard January 9, 2006 - -1. Introduction - - In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the - synthesis of answers from special resource records called - wildcards. The definition in RFC 1034 is incomplete and has - proven to be confusing. This document describes the wildcard - synthesis by adding to the discussion and making limited - modifications. Modifications are made to close inconsistencies - that have led to interoperability issues. This description - does not expand the service intended by the original definition. - - Staying within the spirit and style of the original documents, - this document avoids specifying rules for DNS implementations - regarding wildcards. The intention is to only describe what is - needed for interoperability, not restrict implementation choices. - In addition, consideration is given to minimize any backwards - compatibility issues with implementations that comply with RFC - 1034's definition. - - This document is focused on the concept of wildcards as defined - in RFC 1034. Nothing is implied regarding alternative means of - synthesizing resource record sets, nor are alternatives discussed. - -1.1 Motivation - - Many DNS implementations diverge, in different ways, from the - original definition of wildcards. Although there is clearly a - need to clarify the original documents in light of this alone, - the impetus for this document lay in the engineering of the DNS - security extensions [RFC4033]. With an unclear definition of - wildcards the design of authenticated denial became entangled. - - This document is intended to limit its changes, documenting only - those based on implementation experience, and to remain as close - to the original document as possible. To reinforce that this - document is meant to clarify and adjust and not redefine wildcards, - relevant sections of RFC 1034 are repeated verbatim to facilitate - comparison of the old and new text. - -1.2 The Original Definition - - The definition of the wildcard concept is comprised by the - documentation of the algorithm by which a name server prepares - a response (in RFC 1034's section 4.3.2) and the way in which - a resource record (set) is identified as being a source of - synthetic data (section 4.3.3). - - This is the definition of the term "wildcard" as it appears in - RFC 1034, section 4.3.3. - - - -DNSEXT Working Group Expires July 9, 2006 [Page 3] - -Internet-Draft dnsext-wcard January 9, 2006 - -# In the previous algorithm, special treatment was given to RRs with -# owner names starting with the label "*". Such RRs are called -# wildcards. Wildcard RRs can be thought of as instructions for -# synthesizing RRs. When the appropriate conditions are met, the name -# server creates RRs with an owner name equal to the query name and -# contents taken from the wildcard RRs. - - This passage follows the algorithm in which the term wildcard - is first used. In this definition, wildcard refers to resource - records. In other usage, wildcard has referred to domain names, - and it has been used to describe the operational practice of - relying on wildcards to generate answers. It is clear from this - that there is a need to define clear and unambiguous terminology - in the process of discussing wildcards. - - The mention of the use of wildcards in the preparation of a - response is contained in step 3c of RFC 1034's section 4.3.2 - entitled "Algorithm." Note that "wildcard" does not appear in - the algorithm, instead references are made to the "*" label. - The portion of the algorithm relating to wildcards is - deconstructed in detail in section 3 of this document, this is - the beginning of the relevant portion of the "Algorithm." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - The scope of this document is the RFC 1034 definition of - wildcards and the implications of updates to those documents, - such as DNSSEC. Alternate schemes for synthesizing answers are - not considered. (Note that there is no reference listed. No - document is known to describe any alternate schemes, although - there has been some mention of them in mailing lists.) - -1.3 Roadmap to This Document - - This document accomplishes these three items. - o Defines new terms - o Makes minor changes to avoid conflicting concepts - o Describes the actions of certain resource records as wildcards - -1.3.1 New Terms - - To help in discussing what resource records are wildcards, two - terms will be defined - "asterisk label" and "wild card domain - name". These are defined in section 2.1.1. - - To assist in clarifying the role of wildcards in the name server - algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest - encloser" are defined. These definitions are in section 3.3.2. - "Label match" is defined in section 3.2. - -DNSEXT Working Group Expires July 9, 2006 [Page 4] - -Internet-Draft dnsext-wcard January 9, 2006 - - The new terms are used to make discussions of wildcards clearer. - Terminology doesn't directly have an impact on implementations. - -1.3.2 Changed Text - - The definition of "existence" is changed superficially. This - change will not be apparent to implementations; it is needed to - make descriptions more precise. The change appears in section - 2.2.3. - - RFC 1034, section 4.3.3., seems to prohibit having two asterisk - labels in a wildcard owner name. With this document the - restriction is removed entirely. This change and its implications - are in section 2.1.3. - - The actions when a source of synthesis owns a CNAME RR are - changed to mirror the actions if an exact match name owns a - CNAME RR. This is an addition to the words in RFC 1034, - section 4.3.2, step 3, part c. The discussion of this is in - section 3.3.3. - - Only the latter change represents an impact to implementations. - The definition of existence is not a protocol impact. The change - to the restriction on names is unlikely to have an impact, as - RFC 1034 contained no specification on when and how to enforce the - restriction. - -1.3.3 Considerations with Special Types - - This document describes semantics of wildcard RRSets for - "interesting" types as well as empty non-terminal wildcards. - Understanding these situations in the context of wildcards has - been clouded because these types incur special processing if - they are the result of an exact match. This discussion is in - section 4. - - These discussions do not have an implementation impact, they cover - existing knowledge of the types, but to a greater level of detail. - -1.4 Standards Terminology - - This document does not use terms as defined in "Key words for use - in RFCs to Indicate Requirement Levels." [RFC2119] - - Quotations of RFC 1034 are denoted by a '#' in the leftmost - column. References to section "4.3.2" are assumed to refer - to RFC 1034's section 4.3.2, simply titled "Algorithm." - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 5] - -Internet-Draft dnsext-wcard January 9, 2006 - -2. Wildcard Syntax - - The syntax of a wildcard is the same as any other DNS resource - record, across all classes and types. The only significant - feature is the owner name. - - Because wildcards are encoded as resource records with special - names, they are included in zone transfers and incremental zone - transfers[RFC1995] just as non-wildcard resource records are. - This feature has been under appreciated until discussions on - alternative approaches to wildcards appeared on mailing lists. - -2.1 Identifying a Wildcard - - To provide a more accurate description of wildcards, the - definition has to start with a discussion of the domain names - that appear as owners. Two new terms are needed, "Asterisk - Label" and "Wild Card Domain Name." - -2.1.1 Wild Card Domain Name and Asterisk Label - - A "wild card domain name" is defined by having its initial - (i.e., left-most or least significant) label be, in binary format: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC20] - for the '*' character. - - A descriptive name of a label equaling that value is an "asterisk - label." - - RFC 1034's definition of wildcard would be "a resource record - owned by a wild card domain name." - -2.1.2 Asterisks and Other Characters - - No label values other than that in section 2.1.1 are asterisk - labels, hence names beginning with other labels are never wild - card domain names. Labels such as 'the*' and '**' are not - asterisk labels so these labels do not start wild card domain - names. - -2.1.3 Non-terminal Wild Card Domain Names - - In section 4.3.3, the following is stated: - -# .......................... The owner name of the wildcard RRs is of -# the form "*.<anydomain>", where <anydomain> is any domain name. -# <anydomain> should not contain other * labels...................... - -DNSEXT Working Group Expires July 9, 2006 [Page 6] - -Internet-Draft dnsext-wcard January 9, 2006 - - The restriction is now removed. The original documentation of it - is incomplete and the restriction does not serve any purpose - given years of operational experience. - - There are three possible reasons for putting the restriction in - place, but none of the three has held up over time. One is - that the restriction meant that there would never be subdomains - of wild card domain names, but the restriciton as stated still - permits "example.*.example." for instance. Another is that - wild card domain names are not intended to be empty non-terminals, - but this situation does not disrupt the algorithm in 4.3.2. - Finally, "nested" wild card domain names are not ambiguous once - the concept of the closest encloser had been documented. - - A wild card domain name can have subdomains. There is no need - to inspect the subdomains to see if there is another asterisk - label in any subdomain. - - A wild card domain name can be an empty non-terminal. (See the - upcoming sections on empty non-terminals.) In this case, any - lookup encountering it will terminate as would any empty - non-terminal match. - -2.2 Existence Rules - - The notion that a domain name 'exists' is mentioned in the - definition of wildcards. In section 4.3.3 of RFC 1034: - -# Wildcard RRs do not apply: -# -... -# - When the query name or a name between the wildcard domain and -# the query name is know[n] to exist. For example, if a wildcard - - "Existence" is therefore an important concept in the understanding - of wildcards. Unfortunately, the definition of what exists, in RFC - 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is - taken at the definition of existence. - -2.2.1 An Example - - To illustrate what is meant by existence consider this complete - zone: - - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 7] - -Internet-Draft dnsext-wcard January 9, 2006 - - $ORIGIN example. - example. 3600 IN SOA <SOA RDATA> - example. 3600 NS ns.example.com. - example. 3600 NS ns.example.net. - *.example. 3600 TXT "this is a wild card" - *.example. 3600 MX 10 host1.example. - sub.*.example. 3600 TXT "this is not a wild card" - host1.example. 3600 A 192.0.4.1 - _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> - _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> - subdel.example. 3600 NS ns.example.com. - subdel.example. 3600 NS ns.example.net. - - A look at the domain names in a tree structure is helpful: - - | - -------------example------------ - / / \ \ - / / \ \ - / / \ \ - * host1 host2 subdel - | | | - | | | - sub _tcp _tcp - | | - | | - _ssh _ssh - - The following responses would be synthesized from one of the - wildcards in the zone: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*.example.' - - QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN - the answer will be "foo.bar.example. IN TXT ..." - because bar.example. does not exist, but the wildcard - does. - - The following responses would not be synthesized from any of the - wildcards in the zone: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - - QNAME=sub.*.example., QTYPE=MX, QCLASS=IN - because sub.*.example. exists - -DNSEXT Working Group Expires July 9, 2006 [Page 8] - -Internet-Draft dnsext-wcard January 9, 2006 - - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists (and is a zone cut) - - QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN - because *.example. exists - - The final example highlights one common misconception about - wildcards. A wildcard "blocks itself" in the sense that a - wildcard does not match its own subdomains. I.e. "*.example." - does not match all names in the "example." zone, it fails to - match the names below "*.example." To cover names under - "*.example.", another wild card domain name is needed - - "*.*.example." - which covers all but it's own subdomains. - -2.2.2 Empty Non-terminals - - Empty non-terminals [RFC2136, Section 7.16] are domain names - that own no resource records but have subdomains that do. In - section 2.2.1, "_tcp.host1.example." is an example of a empty - non-terminal name. Empty non-terminals are introduced by this - text in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on -# the tree corresponds to a resource set (which may be empty). The -# domain system makes no distinctions between the uses of the -# interior nodes and leaves, and this memo uses the term "node" to -# refer to both. - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized, and that empty non-terminals - "exist." - - Pedantically reading the above paragraph can lead to an - interpretation that all possible domains exist - up to the - suggested limit of 255 octets for a domain name [RFC1035]. - For example, www.example. may have an A RR, and as far as is - practically concerned, is a leaf of the domain tree. But the - definition can be taken to mean that sub.www.example. also - exists, albeit with no data. By extension, all possible domains - exist, from the root on down. - - As RFC 1034 also defines "an authoritative name error indicating - that the name does not exist" in section 4.3.1, so this apparently - is not the intent of the original definition, justifying the - need for an updated definition in the next section. - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 9] - -Internet-Draft dnsext-wcard January 9, 2006 - -2.2.3 Yet Another Definition of Existence - - RFC1034's wording is fixed by the following paragraph: - - The domain name space is a tree structure. Nodes in the tree - either own at least one RRSet and/or have descendants that - collectively own at least one RRSet. A node may exist with no - RRSets only if it has descendents that do, this node is an empty - non-terminal. - - A node with no descendants is a leaf node. Empty leaf nodes do - not exist. - - Note that at a zone boundary, the domain name owns data, - including the NS RR set. In the delegating zone, the NS RR - set is not authoritative, but that is of no consequence here. - The domain name owns data, therefore, it exists. - -2.3 When is a Wild Card Domain Name Not Special - - When a wild card domain name appears in a message's query section, - no special processing occurs. An asterisk label in a query name - only matches a single, corresponding asterisk label in the - existing zone tree when the 4.3.2 algorithm is being followed. - - When a wild card domain name appears in the resource data of a - record, no special processing occurs. An asterisk label in that - context literally means just an asterisk. - -3. Impact of a Wild Card Domain Name On a Response - - RFC 1034's description of how wildcards impact response - generation is in its section 4.3.2. That passage contains the - algorithm followed by a server in constructing a response. - Within that algorithm, step 3, part 'c' defines the behavior of - the wildcard. - - The algorithm in section 4.3.2. is not intended to be pseudo-code, - i.e., its steps are not intended to be followed in strict order. - The "algorithm" is a suggested means of implementing the - requirements. As such, in step 3, parts a, b, and c, do not have - to be implemented in that order, provided that the result of the - implemented code is compliant with the protocol's specification. - -3.1 Step 2 - - Step 2 of section 4.3.2 reads: - -# 2. Search the available zones for the zone which is the nearest -# ancestor to QNAME. If such a zone is found, go to step 3, -# otherwise step 4. - -DNSEXT Working Group Expires July 9, 2006 [Page 10] - -Internet-Draft dnsext-wcard January 9, 2006 - - In this step, the most appropriate zone for the response is - chosen. The significance of this step is that it means all of - step 3 is being performed within one zone. This has significance - when considering whether or not an SOA RR can be ever be used for - synthesis. - -3.2 Step 3 - - Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. - But the beginning of the step is important and needs explanation. - -# 3. Start matching down, label by label, in the zone. The -# matching process can terminate several ways: - - The word 'matching' refers to label matching. The concept - is based in the view of the zone as the tree of existing names. - The query name is considered to be an ordered sequence of - labels - as if the name were a path from the root to the owner - of the desired data. (Which it is - 3rd paragraph of RFC 1034, - section 3.1.) - - The process of label matching a query name ends in exactly one of - three choices, the parts 'a', 'b', and 'c'. Either the name is - found, the name is below a cut point, or the name is not found. - - Once one of the parts is chosen, the other parts are not - considered. (E.g., do not execute part 'c' and then change - the execution path to finish in part 'b'.) The process of label - matching is also done independent of the query type (QTYPE). - - Parts 'a' and 'b' are not an issue for this clarification as they - do not relate to record synthesis. Part 'a' is an exact match - that results in an answer, part 'b' is a referral. - -3.3 Part 'c' - - The context of part 'c' is that the process of label matching the - labels of the query name has resulted in a situation in which - there is no corresponding label in the tree. It is as if the - lookup has "fallen off the tree." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - To help describe the process of looking 'to see if [...] the "*" - label exists' a term has been coined to describe the last domain - (node) matched. The term is "closest encloser." - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 11] - -Internet-Draft dnsext-wcard January 9, 2006 - -3.3.1 Closest Encloser and the Source of Synthesis - - The closest encloser is the node in the zone's tree of existing - domain names that has the most labels matching the query name - (consecutively, counting from the root label downward). Each match - is a "label match" and the order of the labels is the same. - - The closest encloser is, by definition, an existing name in the - zone. The closest encloser might be an empty non-terminal or even - be a wild card domain name itself. In no circumstances is the - closest encloser to be used to synthesize records for the current - query. - - The source of synthesis is defined in the context of a query - process as that wild card domain name immediately descending - from the closest encloser, provided that this wild card domain - name exists. "Immediately descending" means that the source - of synthesis has a name of the form: - <asterisk label>.<closest encloser>. - A source of synthesis does not guarantee having a RRSet to use - for synthesis. The source of synthesis could be an empty - non-terminal. - - If the source of synthesis does not exist (not on the domain - tree), there will be no wildcard synthesis. There is no search - for an alternate. - - The important concept is that for any given lookup process, there - is at most one place at which wildcard synthetic records can be - obtained. If the source of synthesis does not exist, the lookup - terminates, the lookup does not look for other wildcard records. - -3.3.2 Closest Encloser and Source of Synthesis Examples - - To illustrate, using the example zone in section 2.2.1 of this - document, the following chart shows QNAMEs and the closest - enclosers. - - QNAME Closest Encloser Source of Synthesis - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no source - _telnet._tcp.host2.example. host2.example. no source - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - foobar.*.example. *.example. no source - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 12] - -Internet-Draft dnsext-wcard January 9, 2006 - -3.3.3 Type Matching - - RFC 1034 concludes part 'c' with this: - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. -# -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - The final paragraph covers the role of the QTYPE in the lookup - process. - - Based on implementation feedback and similarities between step - 'a' and step 'c' a change to this passage has been made. - - The change is to add the following text to step 'c' prior to the - instructions to "go to step 6": - - If the data at the source of synthesis is a CNAME, and - QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response changing the owner name - to the QNAME, change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - This is essentially the same text in step a covering the - processing of CNAME RRSets. - -4. Considerations with Special Types - - Sections 2 and 3 of this document discuss wildcard synthesis - with respect to names in the domain tree and ignore the impact - of types. In this section, the implication of wildcards of - specific types are discussed. The types covered are those - that have proven to be the most difficult to understand. The - types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and - "none," i.e., empty non-terminal wild card domain names. - -4.1 SOA RRSet at a Wild Card Domain Name - - A wild card domain name owning an SOA RRSet means that the - domain is at the root of the zone (apex). The domain can not - be a source of synthesis because that is, by definition, a - descendent node (of the closest encloser) and a zone apex is - at the top of the zone. - - -DNSEXT Working Group Expires July 9, 2006 [Page 13] - -Internet-Draft dnsext-wcard January 9, 2006 - - Although a wild card domain name owning an SOA RRSet can never - be a source of synthesis, there is no reason to forbid the - ownership of an SOA RRSet. - - E.g., given this zone: - $ORIGIN *.example. - @ 3600 IN SOA <SOA RDATA> - 3600 NS ns1.example.com. - 3600 NS ns1.example.net. - www 3600 TXT "the www txt record" - - A query for www.*.example.'s TXT record would still find the - "the www txt record" answer. The asterisk label only becomes - significant when section 4.3.2, step 3 part 'c' is in effect. - - Of course, there would need to be a delegation in the parent - zone, "example." for this to work too. This is covered in the - next section. - -4.2 NS RRSet at a Wild Card Domain Name - - With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now - in place, the semantics of a wild card domain name owning an - NS RRSet has come to be poorly defined. The dilemma relates to - a conflict between the rules for synthesis in part 'c' and the - fact that the resulting synthesis generates a record for which - the zone is not authoritative. In a DNSSEC signed zone, the - mechanics of signature management (generation and inclusion - in a message) have become unclear. - - Salient points of the working group discussion on this topic is - summarized in section 4.2.1. - - As a result of these discussion, there is no definition given for - wild card domain names owning an NS RRSet. The semantics are - left undefined until there is a clear need to have a set defined, - and until there is a clear direction to proceed. Operationally, - inclusion of wild card NS RRSets in a zone is discouraged, but - not barred. - -4.2.1 Discarded Notions - - Prior to DNSSEC, a wild card domain name owning a NS RRSet - appeared to be workable, and there are some instances in which - it is found in deployments using implementations that support - this. Continuing to allow this in the specification is not - tenable with DNSSEC. The reason is that the synthesis of the - NS RRSet is being done in a zone that has delegated away the - responsibility for the name. This "unauthorized" synthesis is - not a problem for the base DNS protocol, but DNSSEC, in affirming - the authorization model for DNS exposes the problem. - -DNSEXT Working Group Expires July 9, 2006 [Page 14] - -Internet-Draft dnsext-wcard January 9, 2006 - - Outright banning of wildcards of type NS is also untenable as - the DNS protocol does not define how to handle "illegal" data. - Implementations may choose not to load a zone, but there is no - protocol definition. The lack of the definition is complicated - by having to cover dynamic update [RFC 2136], zone transfers, - as well as loading at the master server. The case of a client - (resolver, caching server) getting a wildcard of type NS in - a reply would also have to be considered. - - Given the daunting challenge of a complete definition of how to - ban such records, dealing with existing implementations that - permit the records today is a further complication. There are - uses of wild card domain name owning NS RRSets. - - One compromise proposed would have redefined wildcards of type - NS to not be used in synthesis, this compromise fell apart - because it would have required significant edits to the DNSSEC - signing and validation work. (Again, DNSSEC catches - unauthorized data.) - - With no clear consensus forming on the solution to this dilemma, - and the realization that wildcards of type NS are a rarity in - operations, the best course of action is to leave this open-ended - until "it matters." - -4.3 CNAME RRSet at a Wild Card Domain Name - - The issue of a CNAME RRSet owned by a wild card domain name has - prompted a suggested change to the last paragraph of step 3c of - the algorithm in 4.3.2. The changed text appears in section - 3.3.3 of this document. - -4.4 DNAME RRSet at a Wild Card Domain Name - - Ownership of a DNAME [RFC2672] RRSet by a wild card domain name - represents a threat to the coherency of the DNS and is to be - avoided or outright rejected. Such a DNAME RRSet represents - non-deterministic synthesis of rules fed to different caches. - As caches are fed the different rules (in an unpredictable - manner) the caches will cease to be coherent. ("As caches - are fed" refers to the storage in a cache of records obtained - in responses by recursive or iterative servers.) - - For example, assume one cache, responding to a recursive - request, obtains the record: - "a.b.example. DNAME foo.bar.example.net." - and another cache obtains: - "b.example. DNAME foo.bar.example.net." - both generated from the record: - "*.example. DNAME foo.bar.example.net." - by an authoritative server. - -DNSEXT Working Group Expires July 9, 2006 [Page 15] - -Internet-Draft dnsext-wcard January 9, 2006 - - The DNAME specification is not clear on whether DNAME records - in a cache are used to rewrite queries. In some interpretations, - the rewrite occurs, in some, it is not. Allowing for the - occurrence of rewriting, queries for "sub.a.b.example. A" may - be rewritten as "sub.foo.bar.tld. A" by the former caching - server and may be rewritten as "sub.a.foo.bar.tld. A" by the - latter. Coherency is lost, an operational nightmare ensues. - - Another justification for banning or avoiding wildcard DNAME - records is the observation that such a record could synthesize - a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." - There is a restriction in the DNAME definition that no domain - exist below a DNAME-owning domain, hence, the wildcard DNAME - is not to be permitted. - -4.5 SRV RRSet at a Wild Card Domain Name - - The definition of the SRV RRset is RFC 2782 [RFC2782]. In the - definition of the record, there is some confusion over the term - "Name." The definition reads as follows: - -# The format of the SRV RR -... -# _Service._Proto.Name TTL Class SRV Priority Weight Port Target -... -# Name -# The domain this RR refers to. The SRV RR is unique in that the -# name one searches for is not this name; the example near the end -# shows this clearly. - - Do not confuse the definition "Name" with the owner name. I.e., - once removing the _Service and _Proto labels from the owner name - of the SRV RRSet, what remains could be a wild card domain name - but this is immaterial to the SRV RRSet. - - E.g., If an SRV record is: - _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. - - *.example is a wild card domain name and although it is the Name - of the SRV RR, it is not the owner (domain name). The owner - domain name is "_foo._udp.*.example." which is not a wild card - domain name. - - The confusion is likely based on the mixture of the specification - of the SRV RR and the description of a "use case." - -4.6 DS RRSet at a Wild Card Domain Name - - A DS RRSet owned by a wild card domain name is meaningless and - harmless. This statement is made in the context that an NS RRSet - at a wild card domain name is undefined. At a non-delegation - -DNSEXT Working Group Expires July 9, 2006 [Page 16] - -Internet-Draft dnsext-wcard January 9, 2006 - - point, a DS RRSet has no value (no corresponding DNSKEY RRSet - will be used in DNSSEC validation). If there is a synthesized - DS RRSet, it alone will not be very useful as it exists in the - context of a delegation point. - -4.7 NSEC RRSet at a Wild Card Domain Name - - Wild card domain names in DNSSEC signed zones will have an NSEC - RRSet. Synthesis of these records will only occur when the - query exactly matches the record. Synthesized NSEC RR's will not - be harmful as they will never be used in negative caching or to - generate a negative response. [RFC2308] - -4.8 RRSIG at a Wild Card Domain Name - - RRSIG records will be present at a wild card domain name in a - signed zone, and will be synthesized along with data sought in a - query. The fact that the owner name is synthesized is not a - problem as the label count in the RRSIG will instruct the - verifying code to ignore it. - -4.9 Empty Non-terminal Wild Card Domain Name - - If a source of synthesis is an empty non-terminal, then the - response will be one of no error in the return code and no RRSet - in the answer section. - -5. Security Considerations - - This document is refining the specifications to make it more - likely that security can be added to DNS. No functional - additions are being made, just refining what is considered - proper to allow the DNS, security of the DNS, and extending - the DNS to be more predictable. - -6. IANA Considerations - - None. - -7. References - - Normative References - - [RFC20] ASCII Format for Network Interchange, V.G. Cerf, - Oct-16-1969 - - [RFC1034] Domain Names - Concepts and Facilities, - P.V. Mockapetris, Nov-01-1987 - - [RFC1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - -DNSEXT Working Group Expires July 9, 2006 [Page 17] - -Internet-Draft dnsext-wcard January 9, 2006 - - [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 - - [RFC2119] Key Words for Use in RFCs to Indicate Requirement - Levels, S Bradner, March 1997 - - [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), - M. Andrews, March 1998 - - [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, - August 1999. - - [RFC2782] A DNS RR for specifying the location of services (DNS - SRV), A. Gulbrandsen, et.al., February 2000 - - [RFC4033] DNS Security Introduction and Requirements, R. Arends, - et.al., March 2005 - - [RFC4034] Resource Records for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - [RFC4035] Protocol Modifications for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - Informative References - - [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - April 1997 - -8. Editor - - Name: Edward Lewis - Affiliation: NeuStar - Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US - Phone: +1-571-434-5468 - Email: ed.lewis@neustar.biz - - Comments on this document can be sent to the editor or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - -9. Others Contributing to the Document - - This document represents the work of a large working group. The - editor merely recorded the collective wisdom of the working group. - - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 17] - -Internet-Draft dnsext-wcard January 9, 2006 - -10. Trailing Boilerplate - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided - on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION - HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET - SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL - WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO - ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT - INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of - any Intellectual Property Rights or other rights that might - be claimed to pertain to the implementation or use of the - technology described in this document or the extent to which - any license under such rights might or might not be available; - nor does it represent that it has made any independent effort - to identify any such rights. Information on the procedures - with respect to rights in RFC documents can be found in BCP 78 - and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the - use of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR - repository at http://www.ietf.org/ipr. The IETF invites any - interested party to bring to its attention any copyrights, - patents or patent applications, or other proprietary rights - that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - -Expiration - - This document expires on or about July 9, 2006. - - - -DNSEXT Working Group Expires July 9, 2006 [Page 19] diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt deleted file mode 100644 index 230c0367..00000000 --- a/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt +++ /dev/null @@ -1,672 +0,0 @@ - - - -Network Working Group M. Andrews -Internet-Draft ISC -Intended status: BCP June 5, 2008 -Expires: December 7, 2008 - - - Locally-served DNS Zones - draft-ietf-dnsop-default-local-zones-05 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on December 7, 2008. - -Abstract - - Experience has shown that there are a number of DNS zones all - iterative resolvers and recursive nameservers should, unless - configured otherwise, automatically serve. RFC 4193 specifies that - this should occur for D.F.IP6.ARPA. This document extends the - practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space - and other well known zones with similar characteristics. - - - - - - - - - -Andrews Expires December 7, 2008 [Page 1] - -Internet-Draft Locally-served DNS Zones June 2008 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4 - 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4 - 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5 - 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6 - 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6 - 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6 - 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7 - 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 - Appendix A. Change History [To Be Removed on Publication] . . . . 10 - A.1. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 10 - A.2. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 10 - A.3. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10 - A.4. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10 - A.5. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11 - A.6. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11 - A.7. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11 - A.8. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11 - Appendix B. Proposed Status [To Be Removed on Publication] . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . . . 12 - - - - - - - - - - - - - - - - - - - - -Andrews Expires December 7, 2008 [Page 2] - -Internet-Draft Locally-served DNS Zones June 2008 - - -1. Introduction - - Experience has shown that there are a number of DNS [RFC 1034] [RFC - 1035] zones that all iterative resolvers and recursive nameservers - SHOULD, unless intentionally configured otherwise, automatically - serve. These zones include, but are not limited to, the IN-ADDR.ARPA - zones for the address space allocated by [RFC 1918] and the IP6.ARPA - zones for locally assigned unique local IPv6 addresses, [RFC 4193]. - - This recommendation is made because data has shown that significant - leakage of queries for these name spaces is occurring, despite - instructions to restrict them, and because it has therefore become - necessary to deploy sacrificial name servers to protect the immediate - parent name servers for these zones from excessive, unintentional, - query load [AS112] [I-D.draft-ietf-dnsop-as112-ops] - [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every - expectation that the query load will continue to increase unless - steps are taken as outlined here. - - Additionally, queries from clients behind badly configured firewalls - that allow outgoing queries for these name spaces but drop the - responses, put a significant load on the root servers (forward but no - reverse zones configured). They also cause operational load for the - root server operators as they have to reply to enquiries about why - the root servers are "attacking" these clients. Changing the default - configuration will address all these issues for the zones listed in - Section 4. - - [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled - locally. This document extends the recommendation to cover the IN- - ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and - IP6.ARPA zones for which queries should not appear on the public - Internet. - - It is hoped that by doing this the number of sacrificial servers - [AS112] will not have to be increased, and may in time be reduced. - - This recommendation should also help DNS responsiveness for sites - which are using [RFC 1918] addresses but do not follow the last - paragraph in Section 3 of [RFC 1918]. - -1.1. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - - - -Andrews Expires December 7, 2008 [Page 3] - -Internet-Draft Locally-served DNS Zones June 2008 - - -2. Effects on sites using RFC 1918 addresses. - - For most sites using [RFC 1918] addresses, the changes here will have - little or no detrimental effect. If the site does not already have - the reverse tree populated the only effect will be that the name - error responses will be generated locally rather than remotely. - - For sites that do have the reverse tree populated, most will either - have a local copy of the zones or will be forwarding the queries to - servers which have local copies of the zone. Therefore this - recommendation will not be relevant. - - The most significant impact will be felt at sites that make use of - delegations for [RFC 1918] addresses and have populated these zones. - These sites will need to override the default configuration expressed - in this document to allow resolution to continue. Typically, such - sites will be fully disconnected from the Internet and have their own - root servers for their own non-Internet DNS tree. - - -3. Changes to Iterative Resolver Behaviour. - - Unless configured otherwise, an iterative resolver will now return - authoritatively (aa=1) name errors (RCODE=3) for queries within the - zones in Section 4, with the obvious exception of queries for the - zone name itself where SOA, NS and "no data" responses will be - returned as appropriate to the query type. One common way to do this - is to serve empty (SOA and NS only) zones. - - An implementation of this recommendation MUST provide a mechanism to - disable this new behaviour, and SHOULD allow this decision on a zone - by zone basis. - - If using empty zones one SHOULD NOT use the same NS and SOA records - as used on the public Internet servers as that will make it harder to - detect the origin of the responses and thus any leakage to the public - Internet servers. This document recommends that the NS record - defaults to the name of the zone and the SOA MNAME defaults to the - name of the only NS RR's target. The SOA RNAME should default to - "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a - mechanism to set these values. No address records need to be - provided for the name server. - - Below is an example of a generic empty zone in master file format. - It will produce a negative cache TTL of 3 hours. - - @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 - @ 10800 IN NS @ - - - -Andrews Expires December 7, 2008 [Page 4] - -Internet-Draft Locally-served DNS Zones June 2008 - - - The SOA RR is needed to support negative caching [RFC 2308] of name - error responses and to point clients to the primary master for DNS - dynamic updates. - - SOA values of particular importance are the MNAME, the SOA RR's TTL - and the negTTL value. Both TTL values SHOULD match. The rest of the - SOA timer values MAY be chosen arbitrarily since they are not - intended to control any zone transfer activity. - - The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries - to discover the zone to be updated. Having no address records for - the name server is expected to abort UPDATE processing in the client. - - -4. Lists Of Zones Covered - - The following subsections are intended to seed the IANA registry as - requested in the IANA Considerations Section. The zone name is the - entity to be registered. - -4.1. RFC 1918 Zones - - The following zones correspond to the IPv4 address space reserved in - [RFC 1918]. - - +----------------------+ - | Zone | - +----------------------+ - | 10.IN-ADDR.ARPA | - | 16.172.IN-ADDR.ARPA | - | 17.172.IN-ADDR.ARPA | - | 18.172.IN-ADDR.ARPA | - | 19.172.IN-ADDR.ARPA | - | 20.172.IN-ADDR.ARPA | - | 21.172.IN-ADDR.ARPA | - | 22.172.IN-ADDR.ARPA | - | 23.172.IN-ADDR.ARPA | - | 24.172.IN-ADDR.ARPA | - | 25.172.IN-ADDR.ARPA | - | 26.172.IN-ADDR.ARPA | - | 27.172.IN-ADDR.ARPA | - | 28.172.IN-ADDR.ARPA | - | 29.172.IN-ADDR.ARPA | - | 30.172.IN-ADDR.ARPA | - | 31.172.IN-ADDR.ARPA | - | 168.192.IN-ADDR.ARPA | - +----------------------+ - - - - -Andrews Expires December 7, 2008 [Page 5] - -Internet-Draft Locally-served DNS Zones June 2008 - - -4.2. RFC 3330 Zones - - The following zones correspond to those address ranges from [RFC - 3330] that are not expected to appear as source or destination - addresses on the public Internet and to not have a unique name to - associate with. - - The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a - attempt to discourage any practice to provide a PTR RR for - 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse - mapping should exist, but the exact setup is out of the scope of this - document. Similar logic applies to the reverse mapping for ::1 - (Section 4.3). The recommendations made here simply assume no other - coverage for these domains exists. - - +------------------------------+------------------------+ - | Zone | Description | - +------------------------------+------------------------+ - | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK | - | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK | - | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL | - | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET | - | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST | - +------------------------------+------------------------+ - -4.3. Local IPv6 Unicast Addresses - - The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for - the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291], - Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones: - - +-------------------------------------------+ - | Zone | - +-------------------------------------------+ - | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | - | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | - | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | - | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | - +-------------------------------------------+ - - Note: Line breaks and a escapes '\' have been inserted above for - readability and to adhere to line width constraints. They are not - parts of the zone names. - -4.4. IPv6 Locally Assigned Local Addresses - - Section 4.4 of [RFC 4193] already required special treatment of: - - - - -Andrews Expires December 7, 2008 [Page 6] - -Internet-Draft Locally-served DNS Zones June 2008 - - - +--------------+ - | Zone | - +--------------+ - | D.F.IP6.ARPA | - +--------------+ - -4.5. IPv6 Link Local Addresses - - IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered - by four distinct reverse DNS zones: - - +----------------+ - | Zone | - +----------------+ - | 8.E.F.IP6.ARPA | - | 9.E.F.IP6.ARPA | - | A.E.F.IP6.ARPA | - | B.E.F.IP6.ARPA | - +----------------+ - - -5. Zones that are Out-Of-Scope - - IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and - IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered - here. It is expected that IPv6 site-local addresses will be self - correcting as IPv6 implementations remove support for site-local - addresses. However, sacrificial servers for C.E.F.IP6.ARPA through - F.E.F.IP6.ARPA may still need to be deployed in the short term if the - traffic becomes excessive. - - For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193], - there has been no decision made about whether the Regional Internet - Registries (RIRs) will provide delegations in this space or not. If - they don't, then C.F.IP6.ARPA will need to be added to the list in - Section 4.4. If they do, then registries will need to take steps to - ensure that name servers are provided for these addresses. - - This document also ignores IP6.INT. IP6.INT has been wound up with - only legacy resolvers now generating reverse queries under IP6.INT - [RFC 4159]. - - This document has also deliberately ignored names immediately under - the root domain. While there is a subset of queries to the root name - servers which could be addressed using the techniques described here - (e.g. .local, .workgroup and IPv4 addresses), there is also a vast - amount of traffic that requires a different strategy (e.g. lookups - for unqualified hostnames, IPv6 addresses). - - - -Andrews Expires December 7, 2008 [Page 7] - -Internet-Draft Locally-served DNS Zones June 2008 - - -6. IANA Considerations - - This document requests that IANA establish a registry of zones which - require this default behaviour. The initial contents of which are in - Section 4. Implementors are encouraged to check this registry and - adjust their implementations to reflect changes therein. - - This registry can be amended through "IETF Consensus" as per [RFC - 2434]. - - IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is - deployed in the reverse tree, delegations for these zones are made in - the manner described in Section 7. - - -7. Security Considerations - - During the initial deployment phase, particularly where [RFC 1918] - addresses are in use, there may be some clients that unexpectedly - receive a name error rather than a PTR record. This may cause some - service disruption until their recursive name server(s) have been re- - configured. - - As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA - namespaces, the zones listed above will need to be delegated as - insecure delegations, or be within insecure zones. This will allow - DNSSEC validation to succeed for queries in these spaces despite not - being answered from the delegated servers. - - It is recommended that sites actively using these namespaces secure - them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust - anchors. This will protect the clients from accidental import of - unsigned responses from the Internet. - - -8. Acknowledgements - - This work was supported by the US National Science Foundation - (research grant SCI-0427144) and DNS-OARC. - - -9. References - -9.1. Normative References - - [RFC 1034] - Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", - STD 13, RFC 1034, November 1987. - - - -Andrews Expires December 7, 2008 [Page 8] - -Internet-Draft Locally-served DNS Zones June 2008 - - - [RFC 1035] - Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND - SPECIFICATION", STD 13, RFC 1035, November 1987. - - [RFC 1918] - Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., - and E. Lear, "Address Allocation for Private Internets", - BCP 5, RFC 1918, February 1996. - - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2136] - Vixie, P., Thomson, A., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC 2308] - Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2398, March 1998. - - [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS - Names", BCP 32, RFC 2606, June 1999. - - [RFC 3596] - Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IPv6", RFC 3596, October 2003. - - [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC 4159] - Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, - August 2005. - - [RFC 4193] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", RFC 4193, October 2005. - - - - -Andrews Expires December 7, 2008 [Page 9] - -Internet-Draft Locally-served DNS Zones June 2008 - - - [RFC 4291] - Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - -9.2. Informative References - - [AS112] "AS112 Project", <http://www.as112.net/>. - - [I-D.draft-ietf-dnsop-as112-ops] - Abley, J. and W. Maton, "AS112 Nameserver Operations", - draft-ietf-dnsop-as112-ops-00 (work in progress), - February 2007. - - [I-D.draft-ietf-dnsop-as112-under-attack-help-help] - Abley, J. and W. Maton, "I'm Being Attacked by - PRISONER.IANA.ORG!", - draft-ietf-dnsop-as112-under-attack-help-help-00 (work in - progress), February 2007. - - [RFC 3330] - "Special-Use IPv4 Addresses", RFC 3330, September 2002. - - -Appendix A. Change History [To Be Removed on Publication] - -A.1. draft-ietf-dnsop-default-local-zones-05.txt - - none, expiry prevention - -A.2. draft-ietf-dnsop-default-local-zones-04.txt - - Centrally Assigned Local addresses -> Non-Locally Assigned Local - address - -A.3. draft-ietf-dnsop-default-local-zones-03.txt - - expanded section 4 descriptions - - Added references [RFC 2136], [RFC 3596], - [I-D.draft-ietf-dnsop-as112-ops] and - [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. - - Revised language. - -A.4. draft-ietf-dnsop-default-local-zones-02.txt - - RNAME now "nobody.invalid." - - - - -Andrews Expires December 7, 2008 [Page 10] - -Internet-Draft Locally-served DNS Zones June 2008 - - - Revised language. - -A.5. draft-ietf-dnsop-default-local-zones-01.txt - - Revised impact description. - - Updated to reflect change in IP6.INT status. - -A.6. draft-ietf-dnsop-default-local-zones-00.txt - - Adopted by DNSOP. - - "Author's Note" re-titled "Zones that are Out-Of-Scope" - - Add note that these zone are expected to seed the IANA registry. - - Title changed. - -A.7. draft-andrews-full-service-resolvers-03.txt - - Added "Proposed Status". - -A.8. draft-andrews-full-service-resolvers-02.txt - - Added 0.IN-ADDR.ARPA. - - -Appendix B. Proposed Status [To Be Removed on Publication] - - This Internet-Draft is being submitted for eventual publication as an - RFC with a proposed status of Best Current Practice. - - -Author's Address - - Mark P. Andrews - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - US - - Email: Mark_Andrews@isc.org - - - - - - - - - -Andrews Expires December 7, 2008 [Page 11] - -Internet-Draft Locally-served DNS Zones June 2008 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - - - - - - - -Andrews Expires December 7, 2008 [Page 12] - diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt deleted file mode 100644 index bf2afcdf..00000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt +++ /dev/null @@ -1,1848 +0,0 @@ - - - -DNS Operations WG J. Jeong, Ed. -Internet-Draft ETRI/University of Minnesota -Expires: November 6, 2005 May 5, 2005 - - - IPv6 Host Configuration of DNS Server Information Approaches - draft-ietf-dnsop-ipv6-dns-configuration-06.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 6, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes three approaches for IPv6 recursive DNS - server address configuration. It details the operational attributes - of three solutions: RA option, DHCPv6 option, and Well-known anycast - addresses for recursive DNS servers. Additionally, it suggests the - deployment scenarios in four kinds of networks, such as ISP, - Enterprise, 3GPP, and Unmanaged networks, considering multi-solution - resolution. Therefore, this document will give the audience a - - - -Jeong Expires November 6, 2005 [Page 1] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - guideline for IPv6 host DNS configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 2] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. IPv6 DNS Configuration Approaches . . . . . . . . . . . . . . 7 - 3.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 8 - 3.1.3 Observations . . . . . . . . . . . . . . . . . . . . . 9 - 3.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 12 - 3.2.3 Observations . . . . . . . . . . . . . . . . . . . . . 12 - 3.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 12 - 3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 13 - 3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 14 - 3.3.3 Observations . . . . . . . . . . . . . . . . . . . . . 14 - 4. Interworking among IPv6 DNS Configuration Approaches . . . . . 15 - 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 - 5.1 ISP Network . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.1.1 RA Option Approach . . . . . . . . . . . . . . . . . . 16 - 5.1.2 DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17 - 5.1.3 Well-known Anycast Addresses Approach . . . . . . . . 17 - 5.2 Enterprise Network . . . . . . . . . . . . . . . . . . . . 17 - 5.3 3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.3.1 Currently Available Mechanisms and Recommendations . . 19 - 5.3.2 RA Extension . . . . . . . . . . . . . . . . . . . . . 19 - 5.3.3 Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20 - 5.3.4 Well-known Addresses . . . . . . . . . . . . . . . . . 21 - 5.3.5 Recommendations . . . . . . . . . . . . . . . . . . . 21 - 5.4 Unmanaged Network . . . . . . . . . . . . . . . . . . . . 22 - 5.4.1 Case A: Gateway does not provide IPv6 at all . . . . . 22 - 5.4.2 Case B: A dual-stack gateway connected to a - dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22 - 5.4.3 Case C: A dual-stack gateway connected to an - IPv4-only ISP . . . . . . . . . . . . . . . . . . . . 22 - 5.4.4 Case D: A gateway connected to an IPv6-only ISP . . . 23 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 6.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 25 - 6.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 25 - 6.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 25 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29 - 9.2 Informative References . . . . . . . . . . . . . . . . . . 29 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 - A. Link-layer Multicast Acknowledgements for RA Option . . . . . 32 - - - -Jeong Expires November 6, 2005 [Page 3] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Intellectual Property and Copyright Statements . . . . . . . . 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 4] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -1. Introduction - - Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address - Autoconfiguration provide the ways to configure either fixed or - mobile nodes with one or more IPv6 addresses, default routes and some - other parameters [3][4]. To support the access to additional - services in the Internet that are identified by a DNS name, such as a - web server, the configuration of at least one recursive DNS server is - also needed for DNS name resolution. - - This document describes three approaches of recursive DNS server - address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 - option [5]-[7], and (c) Well-known anycast addresses for recursive - DNS servers [9]. Also, it suggests the applicable scenarios for four - kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP - network, and (d) Unmanaged network. - - This document is just an analysis of each possible approach, and does - not make any recommendation on a particular one or on a combination - of particular ones. Some approaches may even not be adopted at all - as a result of further discussion. - - Therefore, the objective of this document is to help the audience - select the approaches suitable for IPv6 host configuration of - recursive DNS servers. - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 5] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -2. Terminology - - This document uses the terminology described in [3]-[9]. In - addition, a new term is defined below: - - o Recursive DNS Server (RDNSS): A Recursive DNS Server is a name - server that offers the recursive service of DNS name resolution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 6] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3. IPv6 DNS Configuration Approaches - - In this section, the operational attributes of the three solutions - are described in detail. - -3.1 RA Option - - The RA approach is to define a new ND option called the RDNSS option - that contains a recursive DNS server address. Existing ND transport - mechanisms (i.e., advertisements and solicitations) are used. This - works in the same way that nodes learn about routers and prefixes. - An IPv6 host can configure the IPv6 addresses of one or more RDNSSes - via RA message periodically sent by a router or solicited by a Router - Solicitation (RS) [8]. - - This approach needs RDNSS information to be configured in the routers - doing the advertisements. The configuration of RDNSS addresses can - be performed manually by an operator or other ways, such as automatic - configuration through a DHCPv6 client running on the router. When - advertising more than one RDNSS option, an RA message includes as - many RDNSS options as RDNSSes. - - Through the ND protocol and RDNSS option along with a prefix - information option, an IPv6 host can perform its network - configuration of its IPv6 address and RDNSS simultaneously [3][4]. - The RA option for RDNSS can be used on any network that supports the - use of ND. - - However, it is worth noting that some link layers, such as Wireless - LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast, - which means that they cannot guarantee the timely delivery of RA - messages [25]-[28]. This is discussed in Appendix A. - - The RA approach is useful in some mobile environments where the - addresses of the RDNSSes are changing because the RA option includes - a lifetime field that allows client to use RDNSSes nearer to the - client. This can be configured to a value that will require the - client to time out the entry and switch over to another RDNSS address - [8]. However, from the viewpoint of implementation, the lifetime - field would seem to make matters a bit more complex. Instead of just - writing to a DNS configuration file, such as resolv.conf for the list - of RDNSS addresses, we have to have a daemon around (or a program - that is called at the defined intervals) that keeps monitoring the - lifetime of RDNSSes all the time. - - The preference value of RDNSS, included in the RDNSS option, allows - IPv6 hosts to select primary RDNSS among several RDNSSes; this can be - used for the load balancing of RDNSSes [8]. - - - -Jeong Expires November 6, 2005 [Page 7] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3.1.1 Advantages - - The RA option for RDNSS has a number of advantages. These include: - - 1. The RA option is an extension of existing ND/Autoconfig - mechanisms [3][4], and does not require a change in the base ND - protocol. - - 2. This approach, like ND, works well on a variety of link types - including point-to-point links, point-to-multipoint, and - multipoint-to-multipoint (i.e., Ethernet LANs), etc. RFC 2461 - [3] states, however, that there may be some link types on which - ND is not feasible; on such links, some other mechanisms will be - needed for DNS configuration. - - 3. All of the information a host needs to run the basic Internet - applications such as the email, web, ftp, etc., can be obtained - with the addition of this option to ND and address - autoconfiguration. The use of a single mechanism is more - reliable and easier to provide than when the RDNSS information is - learned via another protocol mechanism. Debugging problems when - multiple protocol mechanisms are being used is harder and much - more complex. - - 4. This mechanism works over a broad range of scenarios and - leverages IPv6 ND. This works well on links that support - broadcast reliably (e.g., Ethernet LANs) but not necessarily on - other links (e.g., Wireless LANs): Refer to Appendix A. Also, - this works well on links that are high performance (e.g., - Ethernet LANs) and low performance (e.g., Cellular networks). In - the latter case, by combining the RDNSS information with the - other information in the RA, the host can learn all of the - information needed to use most Internet applications, such as the - web in a single packet. This not only saves bandwidth where this - is an issue, but also minimizes the delay needed to learn the - RDNSS information. - - 5. The RA approach could be used as a model for other similar types - of configuration information. New RA options for other server - addresses, such as NTP server address, that are common to all - clients on a subnet would be easy to define. - - -3.1.2 Disadvantages - - 1. ND is mostly implemented in the kernel of operating system. - Therefore, if ND supports the configuration of some additional - services, such as DNS servers, ND should be extended in the - - - -Jeong Expires November 6, 2005 [Page 8] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - kernel, and complemented by a user-land process. DHCPv6, - however, has more flexibility for the extension of service - discovery because it is an application layer protocol. - - 2. The current ND framework should be modified to facilitate the - synchronization between another ND cache for RDNSSes in the - kernel space and the DNS configuration file in the user space. - Because it is unacceptable to write and rewrite to the DNS - configuration file (e.g., resolv.conf) from the kernel, another - approach is needed. One simple approach to solve this is to have - a daemon listening to what the kernel conveys, and to have the - daemon do these steps, but such a daemon is not needed with the - current ND framework. - - 3. It is necessary to configure RDNSS addresses at least at one - router on every link where this information needs to be - configured via the RA option. - - -3.1.3 Observations - - The proposed RDNSS RA option along with the IPv6 ND and - Autoconfiguration allows a host to obtain all of the information it - needs to access the basic Internet services like the web, email, ftp, - etc. This is preferable in the environments where hosts use RAs to - autoconfigure their addresses and all the hosts on the subnet share - the same router and server addresses. If the configuration - information can be obtained from a single mechanism, it is preferable - because it does not add additional delay, and it uses a minimum of - bandwidth. The environments like this include the homes, public - cellular networks, and enterprise environments where no per host - configuration is needed, but exclude public WLAN hot spots. - - DHCPv6 is preferable where it is being used for address configuration - and if there is a need for host specific configuration [5]-[7]. The - environments like this are most likely to be the enterprise - environments where the local administration chooses to have per host - configuration control. - -Note - - The observation section is based on what the proponents of each - approach think makes a good overall solution. - -3.2 DHCPv6 Option - - DHCPv6 [5] includes the "DNS Recursive Name Server" option, through - which a host can obtain a list of IP addresses of recursive DNS - - - -Jeong Expires November 6, 2005 [Page 9] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - servers [7]. The DNS Recursive Name Server option carries a list of - IPv6 addresses of RDNSSes to which the host may send DNS queries. - The DNS servers are listed in the order of preference for use by the - DNS resolver on the host. - - The DNS Recursive Name Server option can be carried in any DHCPv6 - Reply message, in response to either a Request or an Information - request message. Thus, the DNS Recursive Name Server option can be - used either when DHCPv6 is used for address assignment, or when - DHCPv6 is used only for other configuration information as stateless - DHCPv6 [6]. - - Stateless DHCPv6 can be deployed either using DHCPv6 servers running - on general-purpose computers, or on router hardware. Several router - vendors currently implement stateless DHCPv6 servers. Deploying - stateless DHCPv6 in routers has the advantage that no special - hardware is required, and should work well for networks where DHCPv6 - is needed for very straightforward configuration of network devices. - - However, routers can also act as DHCPv6 relay agents. In this case, - the DHCPv6 server need not be on the router - it can be on a general - purpose computer. This has the potential to give the operator of the - DHCPv6 server more flexibility in how the DHCPv6 server responds to - individual clients - clients can easily be given different - configuration information based on their identity, or for any other - reason. Nothing precludes adding this flexibility to a router, but - generally in current practice, DHCP servers running on general- - purpose hosts tend to have more configuration options than those that - are embedded in routers. - - DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 - clients that use a stateful configuration assignment. To do this, - the DHCPv6 server sends a Reconfigure message to the client. The - client validates the Reconfigure message, and then contacts the - DHCPv6 server to obtain updated configuration information. Using - this mechanism, it is currently possible to propagate new - configuration information to DHCPv6 clients as this information - changes. - - The DHC Working Group is currently studying an additional mechanism - through which configuration information, including the list of - RDNSSes, can be updated. The lifetime option for DHCPv6 [10] assigns - a lifetime to configuration information obtained through DHCPv6. At - the expiration of the lifetime, the host contacts the DHCPv6 server - to obtain updated configuration information, including the list of - RDNSSes. This lifetime gives the network administrator another - mechanism to configure hosts with new RDNSSes by controlling the time - at which the host refreshes the list. - - - -Jeong Expires November 6, 2005 [Page 10] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - The DHC Working Group has also discussed the possibility of defining - an extension to DHCPv6 that would allow the use of multicast to - provide configuration information to multiple hosts with a single - DHCPv6 message. Because of the lack of deployment experience, the WG - has deferred consideration of multicast DHCPv6 configuration at this - time. Experience with DHCPv4 has not identified a requirement for - multicast message delivery, even in large service provider networks - with tens of thousands of hosts that may initiate a DHCPv4 message - exchange simultaneously. - -3.2.1 Advantages - - The DHCPv6 option for RDNSS has a number of advantages. These - include: - - 1. DHCPv6 currently provides a general mechanism for conveying - network configuration information to clients. So configuring - DHCPv6 servers allows the network administrator to configure - RDNSSes along with the addresses of other network services, as - well as location-specific information like time zones. - - 2. As a consequence, when the network administrator goes to - configure DHCPv6, all the configuration information can be - managed through a single service, typically with a single user - interface and a single configuration database. - - 3. DHCPv6 allows for the configuration of a host with information - specific to that host, so that hosts on the same link can be - configured with different RDNSSes as well as with other - configuration information. This capability is important in some - network deployments such as service provider networks or WiFi hot - spots. - - 4. A mechanism exists for extending DHCPv6 to support the - transmission of additional configuration that has not yet been - anticipated. - - 5. Hosts that require other configuration information such as the - addresses of SIP servers and NTP servers are likely to need - DHCPv6 for other configuration information. - - 6. The specification for configuration of RDNSSes through DHCPv6 is - available as an RFC. No new protocol extensions such as new - options are necessary. - - 7. Interoperability among independent implementations has been - demonstrated. - - - - -Jeong Expires November 6, 2005 [Page 11] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3.2.2 Disadvantages - - The DHCPv6 option for RDNSS has a few disadvantages. These include: - - 1. Update currently requires message from server (however, see - [10]). - - 2. Because DNS information is not contained in RA messages, the host - must receive two messages from the router, and must transmit at - least one message to the router. On networks where bandwidth is - at a premium, this is a disadvantage, although on most networks - it is not a practical concern. - - 3. Increased latency for initial configuration - in addition to - waiting for an RA message, the client must now exchange packets - with a DHCPv6 server; even if it is locally installed on a - router, this will slightly extend the time required to configure - the client. For clients that are moving rapidly from one network - to another, this will be a disadvantage. - - -3.2.3 Observations - - In the general case, on general-purpose networks, stateless DHCPv6 - provides significant advantages and no significant disadvantages. - Even in the case where bandwidth is at a premium and low latency is - desired, if hosts require other configuration information in addition - to a list of RDNSSes or if hosts must be configured selectively, - those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive - name server option will be advantageous. - - However, we are aware of some applications where it would be - preferable to put the RDNSS information into an RA packet; for - example, on a cell phone network, where bandwidth is at a premium and - extremely low latency is desired. The final DNS configuration draft - should be written so as to allow these special applications to be - handled using DNS information in the RA packet. - -3.3 Well-known Anycast Addresses - - Anycast uses the same routing system as unicast [11]. However, - administrative entities are local ones. The local entities may - accept unicast routes (including default routes) to anycast servers - from adjacent entities. The administrative entities should not - advertise their peers routes to their internal anycast servers, if - they want to prohibit external access from some peers to the servers. - If some advertisement is inevitable (such as the case with default - routes), the packets to the servers should be blocked at the boundary - - - -Jeong Expires November 6, 2005 [Page 12] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - of the entities. Thus, for this anycast, not only unicast routing - but also unicast ND protocols can be used as is. - - First of all, the well-known anycast addresses approach is much - different from that discussed at IPv6 Working Group in the past [9]. - It should be noted that "anycast" in this memo is simpler than that - of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be - prohibited to have multiple servers on a single link sharing an - anycast address. That is, on a link, an anycast address is assumed - to be unique. DNS clients today already have redundancy by having - multiple well-known anycast addresses configured as RDNSS addresses. - There is no point in having multiple RDNSSes sharing an anycast - address on a single link. - - The approach with well-known anycast addresses is to set multiple - well-known anycast addresses in clients' resolver configuration files - from the beginning, say, as factory default. Thus, there is no - transport mechanism and no packet format [9]. - - An anycast address is an address shared by multiple servers (in this - case, the servers are RDNSSes). A request from a client to the - anycast address is routed to a server selected by the routing system. - However, it is a bad idea to mandate "site" boundary on anycast - addresses, because most users just do not have their own servers and - want to access their ISPs' across their site boundaries. Larger - sites may also depend on their ISPs or may have their own RDNSSes - within "site" boundaries. - -3.3.1 Advantages - - The basic advantage of the well-known addresses approach is that it - uses no transport mechanism. Thus, - - 1. There is no delay to get the response and no further delay by - packet losses. - - 2. The approach can be combined with any other configuration - mechanisms, such as the RA-based approach and DHCP based - approach, as well as the factory default configuration. - - 3. The approach works over any environment where DNS works. - - Another advantage is that the approach needs to configure DNS servers - as a router, but nothing else. Considering that DNS servers do need - configuration, the amount of overall configuration effort is - proportional to the number of the DNS servers and scales linearly. - It should be noted that, in the simplest case where a subscriber to - an ISP does not have any DNS server, the subscriber naturally - - - -Jeong Expires November 6, 2005 [Page 13] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - accesses DNS servers of the ISP even though the subscriber and the - ISP do nothing and there is no protocol to exchange DNS server - information between the subscriber and the ISP. - -3.3.2 Disadvantages - - Well-known anycast addresses approach requires that DNS servers (or - routers near it as a proxy) act as routers to advertise their anycast - addresses to the routing system, which requires some configuration - (see the last paragraph of the previous section on the scalability of - the effort). - -3.3.3 Observations - - If other approaches are used in addition, the well-known anycast - addresses should also be set in RA or DHCP configuration files to - reduce the configuration effort of users. - - The redundancy by multiple RDNSSes is better provided by multiple - servers having different anycast addresses than multiple servers - sharing the same anycast address because the former approach allows - stale servers to still generate routes to their anycast addresses. - Thus, in a routing domain (or domains sharing DNS servers), there - will be only one server having an anycast address unless the domain - is so large that load distribution is necessary. - - Small ISPs will operate one RDNSS at each anycast address which is - shared by all the subscribers. Large ISPs may operate multiple - RDNSSes at each anycast address to distribute and reduce load, where - the boundary between RDNSSes may be fixed (redundancy is still - provided by multiple addresses) or change dynamically. DNS packets - with the well-known anycast addresses are not expected (though not - prohibited) to cross ISP boundaries, as ISPs are expected to be able - to take care of themselves. - - Because "anycast" in this memo is simpler than that of RFC 1546 [11] - and RFC 3513 [12] where it is assumed to be administratively - prohibited to have multiple servers on a single link sharing an - anycast address, anycast in this memo should be implemented as - UNICAST of RFC 2461 [3] and RFC 3513 [12]. As a result, ND-related - instability disappears. Thus, anycast in well-known anycast - addresses approach can and should use the anycast address as a source - unicast (according to RFC 3513 [12]) address of packets of UDP and - TCP responses. With TCP, if a route flips and packets to an anycast - address are routed to a new server, it is expected that the flip is - detected by ICMP or sequence number inconsistency and the TCP - connection is reset and retried. - - - - -Jeong Expires November 6, 2005 [Page 14] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -4. Interworking among IPv6 DNS Configuration Approaches - - Three approaches can work together for IPv6 host configuration of - RDNSS. This section shows a consideration on how these approaches - can interwork each other. - - For ordering between RA and DHCP approaches, the O (Other stateful - configuration) flag in RA message can be used [8][32]. If no RDNSS - option is included, an IPv6 host may perform DNS configuration - through DHCPv6 [5]-[7] regardless of whether the O flag is set or - not. - - The well-known anycast addresses approach fully interworks with the - other approaches. That is, the other approaches can remove the - configuration effort on servers by using the well-known addresses as - the default configuration. Moreover, the clients preconfigured with - the well-known anycast addresses can be further configured to use - other approaches to override the well-known addresses, if the - configuration information from other approaches is available. - Otherwise, all the clients need to have the well-known anycast - addresses preconfigured. In order to use the anycast approach along - with two other approaches, there are three choices as follows: - - 1. The first choice is that well-known addresses are used as last - resort, when an IPv6 host cannot get RDNSS information through RA - and DHCP. The well-known anycast addresses have to be - preconfigured in all of IPv6 hosts' resolver configuration files. - - 2. The second is that an IPv6 host can configure well-known - addresses as the most preferable in its configuration file even - though either an RA option or DHCP option is available. - - 3. The last is that the well-known anycast addresses can be set in - RA or DHCP configuration to reduce the configuration effort of - users. According to either the RA or DHCP mechanism, the well- - known addresses can be obtained by an IPv6 host. Because this - approach is the most convenient for users, the last option is - recommended. - - -Note - - This section does not necessarily mean this document suggests - adopting all these three approaches and making them interwork in the - way described here. In fact, some approaches may even not be adopted - at all as a result of further discussion. - - - - - -Jeong Expires November 6, 2005 [Page 15] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5. Deployment Scenarios - - Regarding the DNS configuration on the IPv6 host, several mechanisms - are being considered at the DNSOP Working Group such as RA option, - DHCPv6 option and well-known preconfigured anycast addresses as of - today, and this document is a final result from the long thread. In - this section, we suggest four applicable scenarios of three - approaches for IPv6 DNS configuration. - -Note - - In the applicable scenarios, authors do not implicitly push any - specific approaches into the restricted environments. No enforcement - is in each scenario and all mentioned scenarios are probable. The - main objective of this work is to provide a useful guideline for IPv6 - DNS configuration. - -5.1 ISP Network - - A characteristic of ISP network is that multiple Customer Premises - Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) - routers and each PE connects multiple CPE devices to the backbone - network infrastructure [13]. The CPEs may be hosts or routers. - - In the case where the CPE is a router, there is a customer network - that is connected to the ISP backbone through the CPE. Typically, - each customer network gets a different IPv6 prefix from an IPv6 PE - router, but the same RDNSS configuration will be distributed. - - This section discusses how the different approaches to distributing - DNS information are compared in an ISP network. - -5.1.1 RA Option Approach - - When the CPE is a host, the RA option for RDNSS can be used to allow - the CPE to get RDNSS information as well as /64 prefix information - for stateless address autoconfiguration at the same time when the - host is attached to a new subnet [8]. Because an IPv6 host must - receive at least one RA message for stateless address - autoconfiguration and router configuration, the host could receive - RDNSS configuration information in that RA without the overhead of an - additional message exchange. - - When the CPE is a router, the CPE may accept the RDNSS information - from the RA on the interface connected to the ISP, and copy that - information into the RAs advertised in the customer network. - - This approach is more valuable in the mobile host scenario, in which - - - -Jeong Expires November 6, 2005 [Page 16] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - the host must receive at least an RA message for detecting a new - network, than in other scenarios generally although administrator - should configure RDNSS information on the routers. Secure ND [14] - can provide extended security when using RA messages. - -5.1.2 DHCPv6 Option Approach - - DHCPv6 can be used for RDNSS configuration through the use of the DNS - option, and can provide other configuration information in the same - message with RDNSS configuration [5]-[7]. The DHCPv6 DNS option is - already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or - stateless DHCP [6] is nowhere as complex as a full DHCPv6 - implementation. DHCP is a client-server model protocol, so ISPs can - handle user identification on its network intentionally, and also - authenticated DHCP [15] can be used for secure message exchange. - - The expected model for deployment of IPv6 service by ISPs is to - assign a prefix to each customer, which will be used by the customer - gateway to assign a /64 prefix to each network in the customer's - network. Prefix delegation with DHCP (DHCPv6 PD) has already been - adopted by ISPs for automating the assignment of the customer prefix - to the customer gateway [17]. DNS configuration can be carried in - the same DHCPv6 message exchange used for DHCPv6 to efficiently - provide that information, along with any other configuration - information needed by the customer gateway or customer network. This - service model can be useful to Home or SOHO subscribers. The Home or - SOHO gateway, which is a customer gateway for ISP, can then pass that - RDNSS configuration information to the hosts in the customer network - through DHCP. - -5.1.3 Well-known Anycast Addresses Approach - - The well-known anycast addresses approach is also a feasible and - simple mechanism for ISP [9]. The use of well-known anycast - addresses avoids some of the security risks in rogue messages sent - through an external protocol like RA or DHCPv6. The configuration of - hosts for the use of well-known anycast addresses requires no - protocol or manual configuration, but the configuration of routing - for the anycast addresses requires intervention on the part of the - network administrator. Also, the number of special addresses would - be equal to the number of RDNSSes that could be made available to - subscribers. - -5.2 Enterprise Network - - Enterprise network is defined as a network that has multiple internal - links, one or more router connections, to one or more Providers and - is actively managed by a network operations entity [16]. An - - - -Jeong Expires November 6, 2005 [Page 17] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - enterprise network can get network prefixes from an ISP by either - manual configuration or prefix delegation [17]. In most cases, - because an enterprise network manages its own DNS domains, it - operates its own DNS servers for the domains. These DNS servers - within enterprise network process recursive DNS name resolution - requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the - enterprise network can be performed like in Section 4, in which three - approaches can be used together as follows: - - 1. An IPv6 host can decide which approach is or may be used in its - subnet with the O flag in RA message [8][32]. As the first - choice in Section 4, well-known anycast addresses can be used as - a last resort when RDNSS information cannot be obtained through - either an RA option or DHCP option. This case needs IPv6 hosts - to preconfigure the well-known anycast addresses in their DNS - configuration files. - - 2. When the enterprise prefers the well-known anycast approach to - others, IPv6 hosts should preconfigure the well-known anycast - addresses like in the first choice. - - 3. The last choice, a more convenient and transparent way, does not - need IPv6 hosts to preconfigure the well-known anycast addresses - because the addresses are delivered to IPv6 hosts via either the - RA option or DHCPv6 option as if they were unicast addresses. - This way is most recommended for the sake of user's convenience. - - -5.3 3GPP Network - - The IPv6 DNS configuration is a missing part of IPv6 - autoconfiguration and an important part of the basic IPv6 - functionality in the 3GPP User Equipment (UE). The higher level - description of the 3GPP architecture can be found in [18], and - transition to IPv6 in 3GPP networks is analyzed in [19] and [20]. - - In the 3GPP architecture, there is a dedicated link between the UE - and the GGSN called the Packet Data Protocol (PDP) Context. This - link is created through the PDP Context activation procedure [21]. - There is a separate PDP context type for IPv4 and IPv6 traffic. If a - 3GPP UE user is communicating using IPv6 (having an active IPv6 PDP - context), it cannot be assumed that (s)he has simultaneously an - active IPv4 PDP context, and DNS queries could be done using IPv4. A - 3GPP UE can thus be an IPv6 node, and it needs to somehow discover - the address of the RDNSS. Before IP-based services (e.g., web - browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses - need to be discovered in the 3GPP UE. - - - - -Jeong Expires November 6, 2005 [Page 18] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Section 5.3.1 briefly summarizes currently available mechanisms in - 3GPP networks and recommendations. 5.3.2 analyzes the Router - Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 - mechanism, and 5.3.4 analyzes the Well-known addresses approach. - Section 5.3.5 finally summarizes the recommendations. - -5.3.1 Currently Available Mechanisms and Recommendations - - 3GPP has defined a mechanism, in which RDNSS addresses can be - received in the PDP context activation (a control plane mechanism). - That is called the Protocol Configuration Options Information Element - (PCO-IE) mechanism [22]. The RDNSS addresses can also be received - over the air (using text messages), or typed in manually in the UE. - Note that the two last mechanisms are not very well scalable. The UE - user most probably does not want to type IPv6 RDNSS addresses - manually in his/her UE. The use of well-known addresses is briefly - discussed in section 5.3.4. - - It is seen that the mechanisms above most probably are not sufficient - for the 3GPP environment. IPv6 is intended to operate in a zero- - configuration manner, no matter what the underlying network - infrastructure is. Typically, the RDNSS address is needed to make an - IPv6 node operational - and the DNS configuration should be as simple - as the address autoconfiguration mechanism. It must also be noted - that there will be additional IP interfaces in some near future 3GPP - UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such - as PCO-IE [22]) do not work for those IP interfaces. In other words, - a good IPv6 DNS configuration mechanism should also work in a multi- - access network environment. - - From a 3GPP point of view, the best IPv6 DNS configuration solution - is feasible for a very large number of IPv6-capable UEs (can be even - hundreds of millions in one operator's network), is automatic and - thus requires no user action. It is suggested to standardize a - lightweight, stateless mechanism that works in all network - environments. The solution could then be used for 3GPP, 3GPP2, WLAN - and other access network technologies. A light, stateless IPv6 DNS - configuration mechanism is thus not only needed in 3GPP networks, but - also 3GPP networks and UEs would certainly benefit from the new - mechanism. - -5.3.2 RA Extension - - Router Advertisement extension [8] is a lightweight IPv6 DNS - configuration mechanism that requires minor changes in the 3GPP UE - IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in - the 3GPP architecture) IPv6 stack. This solution can be specified in - the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs - - - -Jeong Expires November 6, 2005 [Page 19] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - and GGSNs - - In this solution, an IPv6-capable UE configures DNS information via - RA message sent by its default router (GGSN), i.e., RDNSS option for - recursive DNS server is included in the RA message. This solution is - easily scalable for a very large number of UEs. The operator can - configure the RDNSS addresses in the GGSN as a part of normal GGSN - configuration. The IPv6 RDNSS address is received in the Router - Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS - addresses can be avoided. - - If thinking about the cons, this mechanism still requires - standardization effort in the IETF, and the end nodes and routers - need to support this mechanism. The equipment software update - should, however, be pretty straightforward, and new IPv6 equipment - could support RA extension already from the beginning. - -5.3.3 Stateless DHCPv6 - - DHCPv6-based solution needs the implementation of Stateless DHCP [6] - and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the - operator's network. A possible configuration is such that the GGSN - works as a DHCP relay. - - Pros for Stateless DHCPv6-based solution are - - 1. Stateless DHCPv6 is a standardized mechanism. - - 2. DHCPv6 can be used for receiving other configuration information - than RDNSS addresses, e.g., SIP server addresses. - - 3. DHCPv6 works in different network environments. - - 4. When DHCPv6 service is deployed through a single, centralized - server, the RDNSS configuration information can be updated by the - network administrator at a single source. - - Some issues with DHCPv6 in 3GPP networks are listed below: - - 1. DHCPv6 requires an additional server in the network unless the - (Stateless) DHCPv6 functionality is integrated into a router - already existing, and that means one box more to be maintained. - - 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing - (3GPP Stateless Address Autoconfiguration is typically used), and - not automatically implemented in 3GPP IPv6 UEs. - - - - - -Jeong Expires November 6, 2005 [Page 20] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - 3. Scalability and reliability of DHCPv6 in very large 3GPP networks - (with tens or hundreds of millions of UEs) may be an issue, at - least the redundancy needs to be taken care of. However, if the - DHCPv6 service is integrated into the network elements, such as a - router operating system, scalability and reliability is - comparable with other DNS configuration approaches. - - 4. It is sub-optimal to utilize the radio resources in 3GPP networks - for DHCPv6 messages if there is a simpler alternative available. - - * The use of Stateless DHCPv6 adds one round trip delay to the - case in which the UE can start transmitting data right after - the Router Advertisement. - - 5. If the DNS information (suddenly) changes, Stateless DHCPv6 can - not automatically update the UE, see [23]. - - -5.3.4 Well-known Addresses - - Using well-known addresses is also a feasible and a light mechanism - for 3GPP UEs. Those well-known addresses can be preconfigured in the - UE software and the operator makes the corresponding configuration on - the network side. So this is a very easy mechanism for the UE, but - requires some configuration work in the network. When using well- - known addresses, UE forwards queries to any of the preconfigured - addresses. In the current proposal [9], IPv6 anycast addresses are - suggested. - -Note - - The IPv6 DNS configuration proposal based on the use of well-known - site-local addresses developed at the IPv6 Working Group was seen as - a feasible mechanism for 3GPP UEs, but opposition by some people in - the IETF and finally deprecating IPv6 site-local addresses made it - impossible to standardize it. Note that this mechanism is - implemented in some existing operating systems today (also in some - 3GPP UEs) as a last resort of IPv6 DNS configuration. - -5.3.5 Recommendations - - It is suggested that a lightweight, stateless DNS configuration - mechanism is specified as soon as possible. From a 3GPP UE and - network point of view, the Router Advertisement based mechanism looks - most promising. The sooner a light, stateless mechanism is - specified, the sooner we can get rid of using well-known site-local - addresses for IPv6 DNS configuration. - - - - -Jeong Expires November 6, 2005 [Page 21] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5.4 Unmanaged Network - - There are 4 deployment scenarios of interest in unmanaged networks - [24]: - - 1. A gateway which does not provide IPv6 at all; - - 2. A dual-stack gateway connected to a dual-stack ISP; - - 3. A dual-stack gateway connected to an IPv4-only ISP; and - - 4. A gateway connected to an IPv6-only ISP. - - -5.4.1 Case A: Gateway does not provide IPv6 at all - - In this case, the gateway does not provide IPv6; the ISP may or may - not provide IPv6. Automatic or Configured tunnels are the - recommended transition mechanisms for this scenario. - - The case where dual-stack hosts behind an NAT, that need access to an - IPv6 RDNSS, cannot be entirely ruled out. The DNS configuration - mechanism has to work over the tunnel, and the underlying tunneling - mechanism could be implementing NAT traversal. The tunnel server - assumes the role of a relay (both for DHCP and Well-known anycast - addresses approaches). - - RA-based mechanism is relatively straightforward in its operation, - assuming the tunnel server is also the IPv6 router emitting RAs. - Well-known anycast addresses approach seems also simple in operation - across the tunnel, but the deployment model using Well-known anycast - addresses in a tunneled environment is unclear or not well - understood. - -5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP - - This is similar to a typical IPv4 home user scenario, where DNS - configuration parameters are obtained using DHCP. Except that - Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the - DHCP server is stateful (maintains the state for clients). - -5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP - - This is similar to Case B. If a gateway provides IPv6 connectivity by - managing tunnels, then it is also supposed to provide access to an - RDNSS. Like this, the tunnel for IPv6 connectivity originates from - the dual-stack gateway instead of the host. - - - - -Jeong Expires November 6, 2005 [Page 22] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5.4.4 Case D: A gateway connected to an IPv6-only ISP - - This is similar to Case B. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 23] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -6. Security Considerations - - As security requirements depend solely on applications and are - different application by application, there can be no generic - requirement defined at IP or application layer for DNS. - - However, it should be noted that cryptographic security requires - configured secret information that full autoconfiguration and - cryptographic security are mutually exclusive. People insisting on - secure full autoconfiguration will get false security, false - autoconfiguration or both. - - In some deployment scenarios [19], where cryptographic security is - required for applications, the secret information for the - cryptographic security is preconfigured through which application - specific configuration data, including those for DNS, can be securely - configured. It should be noted that if applications requiring - cryptographic security depend on DNS, the applications also require - cryptographic security to DNS. Therefore, the full autoconfiguration - of DNS is not acceptable. - - However, with full autoconfiguration, weaker but still reasonable - security is being widely accepted and will continue to be acceptable. - That is, with full autoconfiguration, which means there is no - cryptographic security for the autoconfiguration, it is already - assumed that the local environment is secure enough that the - information from the local autoconfiguration server has acceptable - security even without cryptographic security. Thus, the - communication between the local DNS client and local DNS server has - acceptable security. - - In autoconfiguring recursive servers, DNSSEC may be overkill, because - DNSSEC [29] needs the configuration and reconfiguration of clients at - root key roll-over [30][31]. Even if additional keys for secure key - roll-over are added at the initial configuration, they are as - vulnerable as the original keys to some forms of attacks, such as - social hacking. Another problem of using DNSSEC and - autoconfiguration together is that DNSSEC requires secure time, which - means secure communication with autoconfigured time servers, which - requires configured secret information. Therefore, in order that the - autoconfiguration may be secure, it requires configured secret - information. - - If DNSSEC [29] is used and the signatures are verified on the client - host, the misconfiguration of a DNS server may be simply denial of - service. Also, if local routing environment is not reliable, clients - may be directed to a false resolver with the same IP address as the - true one. - - - -Jeong Expires November 6, 2005 [Page 24] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -6.1 RA Option - - The security of RA option for RDNSS is the same as the ND protocol - security [3][8]. The RA option does not add any new vulnerability. - - It should be noted that the vulnerability of ND is not worse and is a - subset of the attacks that any node attached to a LAN can do - independently of ND. A malicious node on a LAN can promiscuously - receive packets for any router's MAC address and send packets with - the router's MAC address as the source MAC address in the L2 header. - As a result, the L2 switches send packets addressed to the router to - the malicious node. Also, this attack can send redirects that tell - the hosts to send their traffic somewhere else. The malicious node - can send unsolicited RA or NA replies, answer RS or NS requests, etc. - All of this can be done independently of implementing ND. Therefore, - the RA option for RDNSS does not add to the vulnerability. - - Security issues regarding the ND protocol were discussed at IETF SEND - (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND - security has been published [14]. - -6.2 DHCPv6 Option - - The DNS Recursive Name Server option may be used by an intruder DHCP - server to cause DHCP clients to send DNS queries to an intruder DNS - recursive name server [7]. The results of these misdirected DNS - queries may be used to spoof DNS names. - - To avoid attacks through the DNS Recursive Name Server option, the - DHCP client SHOULD require DHCP authentication (see section - "Authentication of DHCP messages" in RFC 3315 [5]) before installing - a list of DNS recursive name servers obtained through authenticated - DHCP. - -6.3 Well-known Anycast Addresses - - Well-known anycast addresses does not require configuration security - since there is no protocol [9]. - - The DNS server with the preconfigured addresses are still reasonably - reliable, if local environment is reasonably secure, that is, there - is no active attackers receiving queries to the anycast addresses of - the servers and reply to them. - - - - - - - - -Jeong Expires November 6, 2005 [Page 25] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -7. Contributors - - Ralph Droms - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxboro, MA 01719 - US - - Phone: +1 978 936 1674 - Email: rdroms@cisco.com - - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - US - - Phone: +1 650 625 2004 - Email: bob.hinden@nokia.com - - - Ted Lemon - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94043 - US - - Email: Ted.Lemon@nominum.com - - - Masataka Ohta - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku - Tokyo 152-8552 - Japan - - Phone: +81 3 5734 3299 - Fax: +81 3 5734 3299 - Email: mohta@necom830.hpcl.titech.ac.jp - - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics - 416 Maetan-3dong, Yeongtong-Gu - Suwon, Gyeonggi-Do 443-742 - Korea - - - - -Jeong Expires November 6, 2005 [Page 26] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Phone: +82 31 200 4508 - Email: soohong.park@samsung.com - - - Suresh Satapati - Cisco Systems, Inc. - San Jose, CA 95134 - US - - Email: satapati@cisco.com - - - Juha Wiljakka - Nokia - Visiokatu 3 - FIN-33720, TAMPERE - Finland - - Phone: +358 7180 48372 - Email: juha.wiljakka@nokia.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 27] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -8. Acknowledgements - - This draft has greatly benefited from inputs by David Meyer, Rob - Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, - Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. - Also, Tony Bonanno proofread this draft. The authors appreciate - their contribution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 28] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -9. References - -9.1 Normative References - - [1] Bradner, S., "IETF Rights in Contributions", RFC 3667, - February 2004. - - [2] Bradner, S., "Intellectual Property Rights in IETF Technology", - RFC 3668, February 2004. - - [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery - for IP Version 6 (IPv6)", RFC 2461, December 1998. - - [4] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [5] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) - Service for IPv6", RFC 3736, April 2004. - - [7] Droms, R., Ed., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - -9.2 Informative References - - [8] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS - Discovery based on Router Advertisement", - draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress), - February 2005. - - [9] Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01.txt (Work in Progress), - February 2004. - - [10] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time - Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in - Progress), January 2005. - - [11] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - [13] Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6 - - - -Jeong Expires November 6, 2005 [Page 29] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - into ISP Networks", RFC 4029, March 2005. - - [14] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, - March 2005. - - [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", - RFC 3118, June 2001. - - [16] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", - draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress), - July 2004. - - [17] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host - Configuration Protocol (DHCP) version 6", RFC 3633, - December 2003. - - [18] Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP - Standards", RFC 3314, September 2002. - - [19] Soininen, J., Ed., "Transition Scenarios for 3GPP Networks", - RFC 3574, August 2003. - - [20] Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in - Progress), October 2004. - - [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); - Service description; Stage 2 (Release 5)", December 2002. - - [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 - specification; Core network protocols; Stage 3 (Release 5)", - June 2003. - - [23] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering - Requirements for Stateless DHCPv6", - draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in - Progress), October 2004. - - [24] Huitema, C., Ed., "Unmanaged Networks IPv6 Transition - Scenarios", RFC 3750, April 2004. - - [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access - Control (MAC) and Physical Layer (PHY) Specifications", - March 1999. - - [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) specifications: High-speed - Physical Layer in the 5 GHZ Band", September 1999. - - - -Jeong Expires November 6, 2005 [Page 30] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) specifications: Higher-Speed - Physical Layer Extension in the 2.4 GHz Band", September 1999. - - [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access - Control (MAC) and Physical Layer (PHY) specifications: Further - Higher Data Rate Extension in the 2.4 GHz Band", April 2003. - - [29] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [30] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in - Progress), December 2004. - - [31] Guette, G. and O. Courtay, "Requirements for Automated Key - Rollover in DNSSEC", - draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in - Progress), January 2005. - - [32] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M - and O Flags of IPv6 Router Advertisement", - draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress), - March 2005. - - -Author's Address - - Jaehoon Paul Jeong (editor) - ETRI/Department of Computer Science and Engineering - University of Minnesota - 117 Pleasant Street SE - Minneapolis, MN 55455 - US - - Phone: +1 651 587 7774 - Fax: +1 612 625 2002 - Email: jjeong@cs.umn.edu - URI: http://www.cs.umn.edu/~jjeong/ - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 31] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Appendix A. Link-layer Multicast Acknowledgements for RA Option - - One benefit of an RA option [8] is to be able to multicast the - advertisements, reducing the need for duplicated unicast - communications. - - However, some link-layers may not support this as well as others. - Consider, for example, WLAN networks where multicast is unreliable. - The unreliability problem is caused by lack of ACK for multicast, - especially on the path from the Access Point (AP) to the Station - (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11 - a/b/g [25]-[28]. That is, a multicast packet is unacknowledged on - the path from the AP to the STA, but acknowledged in the reverse - direction from the STA to the AP [25]. For example, when a router is - placed at wired network connected to an AP, a host may sometimes not - receive RA message advertised through the AP. Therefore, the RA - option solution might not work well on a congested medium that uses - unreliable multicast for RA. - - The fact that this problem has not been addressed in Neighbor - Discovery [3] indicates that the extra link-layer acknowledgements - have not been considered a serious problem till now. - - A possible mitigation technique could be to map all-nodes link- local - multicast address to the link-layer broadcast address, and to rely on - the ND retransmissions for message delivery in order to achieve more - reliability. - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 32] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Jeong Expires November 6, 2005 [Page 33] - diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt deleted file mode 100644 index 1276f9f9..00000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt +++ /dev/null @@ -1,1682 +0,0 @@ - - - - -DNS Operations WG A. Durand -Internet-Draft SUN Microsystems, Inc. -Expires: January 17, 2006 J. Ihren - Autonomica - P. Savola - CSC/FUNET - July 16, 2005 - - - Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-11.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 17, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This memo presents operational considerations and issues with IPv6 - Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehaviour, - recommendations and considerations on how to perform DNS naming for - service provisioning and for DNS resolver IPv6 support, - - - -Durand, et al. Expires January 17, 2006 [Page 1] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - considerations for DNS updates for both the forward and reverse - trees, and miscellaneous issues. This memo is aimed to include a - summary of information about IPv6 DNS considerations for those who - have experience with IPv4 DNS. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 - 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 - 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 - 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 - 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 - 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 - 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 - 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 - 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 - 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 - 4. Recommendations for Service Provisioning using DNS . . . . . . 7 - 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 - 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 - 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 - 4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10 - 4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10 - 4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 - 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 13 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 20 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20 - - - -Durand, et al. Expires January 17, 2006 [Page 2] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - 11.2 Informative References . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 - A. Unique Local Addressing Considerations for DNS . . . . . . . . 25 - B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25 - B.1 Description of Additional Data Scenarios . . . . . . . . . 26 - B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27 - B.3 Discussion of the Potential Problems . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . 30 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires January 17, 2006 [Page 3] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -1. Introduction - - This memo presents operational considerations and issues with IPv6 - DNS; it is meant to be an extensive summary and a list of pointers - for more information about IPv6 DNS considerations for those with - experience with IPv4 DNS. - - The purpose of this document is to give information about various - issues and considerations related to DNS operations with IPv6; it is - not meant to be a normative specification or standard for IPv6 DNS. - - The first section gives a brief overview of how IPv6 addresses and - names are represented in the DNS, how transport protocols and - resource records (don't) relate, and what IPv4/IPv6 name space - fragmentation means and how to avoid it; all of these are described - at more length in other documents. - - The second section summarizes the special IPv6 address types and how - they relate to DNS. The third section describes observed DNS - implementation misbehaviours which have a varying effect on the use - of IPv6 records with DNS. The fourth section lists recommendations - and considerations for provisioning services with DNS. The fifth - section in turn looks at recommendations and considerations about - providing IPv6 support in the resolvers. The sixth and seventh - sections describe considerations with forward and reverse DNS - updates, respectively. The eighth section introduces several - miscellaneous IPv6 issues relating to DNS for which no better place - has been found in this memo. Appendix A looks briefly at the - requirements for unique local addressing. - -1.1 Representing IPv6 Addresses in DNS Records - - In the forward zones, IPv6 addresses are represented using AAAA - records. In the reverse zones, IPv6 address are represented using - PTR records in the nibble format under the ip6.arpa. tree. See - [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] - for background information. - - In particular one should note that the use of A6 records in the - forward tree or Bitlabels in the reverse tree is not recommended - [RFC3363]. Using DNAME records is not recommended in the reverse - tree in conjunction with A6 records; the document did not mean to - take a stance on any other use of DNAME records [RFC3364]. - -1.2 Independence of DNS Transport and DNS Records - - DNS has been designed to present a single, globally unique name space - [RFC2826]. This property should be maintained, as described here and - - - -Durand, et al. Expires January 17, 2006 [Page 4] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - in Section 1.3. - - The IP version used to transport the DNS queries and responses is - independent of the records being queried: AAAA records can be queried - over IPv4, and A records over IPv6. The DNS servers must not make - any assumptions about what data to return for Answer and Authority - sections based on the underlying transport used in a query. - - However, there is some debate whether the addresses in Additional - section could be selected or filtered using hints obtained from which - transport was being used; this has some obvious problems because in - many cases the transport protocol does not correlate with the - requests, and because a "bad" answer is in a way worse than no answer - at all (consider the case where the client is led to believe that a - name received in the additional record does not have any AAAA records - at all). - - As stated in [RFC3596]: - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - - -1.3 Avoiding IPv4/IPv6 Name Space Fragmentation - - To avoid the DNS name space from fragmenting into parts where some - parts of DNS are only visible using IPv4 (or IPv6) transport, the - recommendation is to always keep at least one authoritative server - IPv4-enabled, and to ensure that recursive DNS servers support IPv4. - See DNS IPv6 transport guidelines [RFC3901] for more information. - -1.4 Query Type '*' and A/AAAA Records - - QTYPE=* is typically only used for debugging or management purposes; - it is worth keeping in mind that QTYPE=* ("ANY" queries) only return - any available RRsets, not *all* the RRsets, because the caches do not - necessarily have all the RRsets and have no way of guaranteeing that - they have all the RRsets. Therefore, to get both A and AAAA records - reliably, two separate queries must be made. - -2. DNS Considerations about Special IPv6 Addresses - - There are a couple of IPv6 address types which are somewhat special; - these are considered here. - - - - - - -Durand, et al. Expires January 17, 2006 [Page 5] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -2.1 Limited-scope Addresses - - The IPv6 addressing architecture [RFC3513] includes two kinds of - local-use addresses: link-local (fe80::/10) and site-local - (fec0::/10). The site-local addresses have been deprecated [RFC3879] - but are discussed with unique local addresses in Appendix A. - - Link-local addresses should never be published in DNS (whether in - forward or reverse tree), because they have only local (to the - connected link) significance [I-D.durand-dnsop-dont-publish]. - -2.2 Temporary Addresses - - Temporary addresses defined in RFC3041 [RFC3041] (sometimes called - "privacy addresses") use a random number as the interface identifier. - Having DNS AAAA records that are updated to always contain the - current value of a node's temporary address would defeat the purpose - of the mechanism and is not recommended. However, it would still be - possible to return a non-identifiable name (e.g., the IPv6 address in - hexadecimal format), as described in [RFC3041]. - -2.3 6to4 Addresses - - 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps - a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. - - If the reverse DNS population would be desirable (see Section 7.1 for - applicability), there are a number of possible ways to do so. - - The main proposal [I-D.huston-6to4-reverse-dns] aims to design an - autonomous reverse-delegation system that anyone being capable of - communicating using a specific 6to4 address would be able to set up a - reverse delegation to the corresponding 6to4 prefix. This could be - deployed by e.g., Regional Internet Registries (RIRs). This is a - practical solution, but may have some scalability concerns. - -2.4 Other Transition Mechanisms - - 6to4 is mentioned as a case of an IPv6 transition mechanism requiring - special considerations. In general, mechanisms which include a - special prefix may need a custom solution; otherwise, for example - when IPv4 address is embedded as the suffix or not embedded at all, - special solutions are likely not needed. - - Note that it does not seem feasible to provide reverse DNS with - another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops- - teredo]; this is because the IPv6 address is based on the IPv4 - address and UDP port of the current NAT mapping which is likely to be - - - -Durand, et al. Expires January 17, 2006 [Page 6] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - relatively short-lived. - -3. Observed DNS Implementation Misbehaviour - - Several classes of misbehaviour in DNS servers, load-balancers and - resolvers have been observed. Most of these are rather generic, not - only applicable to IPv6 -- but in some cases, the consequences of - this misbehaviour are extremely severe in IPv6 environments and - deserve to be mentioned. - -3.1 Misbehaviour of DNS Servers and Load-balancers - - There are several classes of misbehaviour in certain DNS servers and - load-balancers which have been noticed and documented [RFC4074]: some - implementations silently drop queries for unimplemented DNS records - types, or provide wrong answers to such queries (instead of a proper - negative reply). While typically these issues are not limited to - AAAA records, the problems are aggravated by the fact that AAAA - records are being queried instead of (mainly) A records. - - The problems are serious because when looking up a DNS name, typical - getaddrinfo() implementations, with AF_UNSPEC hint given, first try - to query the AAAA records of the name, and after receiving a - response, query the A records. This is done in a serial fashion -- - if the first query is never responded to (instead of properly - returning a negative answer), significant timeouts will occur. - - In consequence, this is an enormous problem for IPv6 deployments, and - in some cases, IPv6 support in the software has even been disabled - due to these problems. - - The solution is to fix or retire those misbehaving implementations, - but that is likely not going to be effective. There are some - possible ways to mitigate the problem, e.g., by performing the - lookups somewhat in parallel and reducing the timeout as long as at - least one answer has been received; but such methods remain to be - investigated; slightly more on this is included in Section 5. - -3.2 Misbehaviour of DNS Resolvers - - Several classes of misbehaviour have also been noticed in DNS - resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem - to directly impair IPv6 use, and are only referred to for - completeness. - -4. Recommendations for Service Provisioning using DNS - - When names are added in the DNS to facilitate a service, there are - - - -Durand, et al. Expires January 17, 2006 [Page 7] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - several general guidelines to consider to be able to do it as - smoothly as possible. - -4.1 Use of Service Names instead of Node Names - - It makes sense to keep information about separate services logically - separate in the DNS by using a different DNS hostname for each - service. There are several reasons for doing this, for example: - - o It allows more flexibility and ease for migration of (only a part - of) services from one node to another, - - o It allows configuring different properties (e.g., TTL) for each - service, and - - o It allows deciding separately for each service whether to publish - the IPv6 addresses or not (in cases where some services are more - IPv6-ready than others). - - Using SRV records [RFC2782] would avoid these problems. - Unfortunately, those are not sufficiently widely used to be - applicable in most cases. Hence an operation technique is to use - service names instead of node names (or, "hostnames"). This - operational technique is not specific to IPv6, but required to - understand the considerations described in Section 4.2 and - Section 4.3. - - For example, assume a node named "pobox.example.com" provides both - SMTP and IMAP service. Instead of configuring the MX records to - point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one could use - e.g., "smtp.example.com" for SMTP (for both message submission and - mail relaying between SMTP servers) and "imap.example.com" for IMAP. - Note that in the specific case of SMTP relaying, the server itself - must typically also be configured to know all its names to ensure - loops do not occur. DNS can provide a layer of indirection between - service names and where the service actually is, and using which - addresses. (Obviously, when wanting to reach a specific node, one - should use the hostname rather than a service name.) - -4.2 Separate vs the Same Service Names for IPv4 and IPv6 - - The service naming can be achieved in basically two ways: when a - service is named "service.example.com" for IPv4, the IPv6-enabled - service could either be added to "service.example.com", or added - separately under a different name, e.g., in a sub-domain, like, - "service.ipv6.example.com". - - - - -Durand, et al. Expires January 17, 2006 [Page 8] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - These two methods have different characteristics. Using a different - name allows for easier service piloting, minimizing the disturbance - to the "regular" users of IPv4 service; however, the service would - not be used transparently, without the user/application explicitly - finding it and asking for it -- which would be a disadvantage in most - cases. When the different name is under a sub-domain, if the - services are deployed within a restricted network (e.g., inside an - enterprise), it's possible to prefer them transparently, at least to - a degree, by modifying the DNS search path; however, this is a - suboptimal solution. Using the same service name is the "long-term" - solution, but may degrade performance for those clients whose IPv6 - performance is lower than IPv4, or does not work as well (see - Section 4.3 for more). - - In most cases, it makes sense to pilot or test a service using - separate service names, and move to the use of the same name when - confident enough that the service level will not degrade for the - users unaware of IPv6. - -4.3 Adding the Records Only when Fully IPv6-enabled - - The recommendation is that AAAA records for a service should not be - added to the DNS until all of following are true: - - 1. The address is assigned to the interface on the node. - - 2. The address is configured on the interface. - - 3. The interface is on a link which is connected to the IPv6 - infrastructure. - - In addition, if the AAAA record is added for the node, instead of - service as recommended, all the services of the node should be IPv6- - enabled prior to adding the resource record. - - For example, if an IPv6 node is isolated from an IPv6 perspective - (e.g., it is not connected to IPv6 Internet) constraint #3 would mean - that it should not have an address in the DNS. - - Consider the case of two dual-stack nodes, which both have IPv6 - enabled, but the server does not have (global) IPv6 connectivity. As - the client looks up the server's name, only A records are returned - (if the recommendations above are followed), and no IPv6 - communication, which would have been unsuccessful, is even attempted. - - The issues are not always so black-and-white. Usually it's important - that the service offered using both protocols is of roughly equal - quality, using the appropriate metrics for the service (e.g., - - - -Durand, et al. Expires January 17, 2006 [Page 9] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - latency, throughput, low packet loss, general reliability, etc.) -- - this is typically very important especially for interactive or real- - time services. In many cases, the quality of IPv6 connectivity may - not yet be equal to that of IPv4, at least globally -- this has to be - taken into consideration when enabling services. - -4.4 The Use of TTL for IPv4 and IPv6 RRs - - The behaviour of DNS caching when different TTL values are used for - different RRsets of the same name calls for explicit discussion. For - example, let's consider two unrelated zone fragments: - - example.com. 300 IN MX foo.example.com. - foo.example.com. 300 IN A 192.0.2.1 - foo.example.com. 100 IN AAAA 2001:db8::1 - - ... - - child.example.com. 300 IN NS ns.child.example.com. - ns.child.example.com. 300 IN A 192.0.2.1 - ns.child.example.com. 100 IN AAAA 2001:db8::1 - - In the former case, we have "courtesy" additional data; in the - latter, we have "critical" additional data. See more extensive - background discussion of additional data handling in Appendix B. - -4.4.1 TTL With Courtesy Additional Data - - When a caching resolver asks for the MX record of example.com, it - gets back "foo.example.com". It may also get back either one or both - of the A and AAAA records in the additional section. The resolver - must explicitly query for both A and AAAA records [RFC2821]. - - After 100 seconds, the AAAA record is removed from the cache(s) - because its TTL expired. It could be argued to be useful for the - caching resolvers to discard the A record when the shorter TTL (in - this case, for the AAAA record) expires; this would avoid the - situation where there would be a window of 200 seconds when - incomplete information is returned from the cache. Further argument - for discarding is that in the normal operation, the TTL values are so - high that very likely the incurred additional queries would not be - noticeable, compared to the obtained performance optimization. The - behaviour in this scenario is unspecified. - -4.4.2 TTL With Critical Additional Data - - The difference to courtesy additional data is that the A/AAAA records - served by the parent zone cannot be queried explicitly. Therefore - - - -Durand, et al. Expires January 17, 2006 [Page 10] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - after 100 seconds the AAAA record is removed from the cache(s), but - the A record remains. Queries for the remaining 200 seconds - (provided that there are no further queries from the parent which - could refresh the caches) only return the A record, leading to a - potential opererational situation with unreachable servers. - - Similar cache flushing strategies apply in this scenario; the record. - -4.5 IPv6 Transport Guidelines for DNS Servers - - As described in Section 1.3 and [RFC3901], there should continue to - be at least one authoritative IPv4 DNS server for every zone, even if - the zone has only IPv6 records. (Note that obviously, having more - servers with robust connectivity would be preferable, but this is the - minimum recommendation; also see [RFC2182].) - -5. Recommendations for DNS Resolver IPv6 Support - - When IPv6 is enabled on a node, there are several things to consider - to ensure that the process is as smooth as possible. - -5.1 DNS Lookups May Query IPv6 Records Prematurely - - The system library that implements the getaddrinfo() function for - looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavours: - - 1. The system library does not know whether IPv6 has been enabled in - the kernel of the operating system: it may start looking up AAAA - records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version which supports IPv6. - - 2. The system library might start to perform IPv6 queries with - getaddrinfo() only when IPv6 has been enabled in the kernel. - However, this does not guarantee that there exists any useful - IPv6 connectivity (e.g., the node could be isolated from the - other IPv6 networks, only having link-local addresses). - - 3. The system library might implement a toggle which would apply - some heuristics to the "IPv6-readiness" of the node before - starting to perform queries; for example, it could check whether - only link-local IPv6 address(es) exists, or if at least one - global IPv6 address exists. - - First, let us consider generic implications of unnecessary queries - for AAAA records: when looking up all the records in the DNS, AAAA - records are typically tried first, and then A records. These are - done in serial, and the A query is not performed until a response is - - - -Durand, et al. Expires January 17, 2006 [Page 11] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - received to the AAAA query. Considering the misbehaviour of DNS - servers and load-balancers, as described in Section 3.1, the look-up - delay for AAAA may incur additional unnecessary latency, and - introduce a component of unreliability. - - One option here could be to do the queries partially in parallel; for - example, if the final response to the AAAA query is not received in - 0.5 seconds, start performing the A query while waiting for the - result (immediate parallelism might be unoptimal, at least without - information sharing between the look-up threads, as that would - probably lead to duplicate non-cached delegation chain lookups). - - An additional concern is the address selection, which may, in some - circumstances, prefer AAAA records over A records even when the node - does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. - In some cases, the implementation may attempt to connect or send a - datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], - incurring very long protocol timeouts, instead of quickly failing - back to IPv4. - - Now, we can consider the issues specific to each of the three - possibilities: - - In the first case, the node performs a number of completely useless - DNS lookups as it will not be able to use the returned AAAA records - anyway. (The only exception is where the application desires to know - what's in the DNS, but not use the result for communication.) One - should be able to disable these unnecessary queries, for both latency - and reliability reasons. However, as IPv6 has not been enabled, the - connections to IPv6 addresses fail immediately, and if the - application is programmed properly, the application can fall - gracefully back to IPv4 [RFC4038]. - - The second case is similar to the first, except it happens to a - smaller set of nodes when IPv6 has been enabled but connectivity has - not been provided yet; similar considerations apply, with the - exception that IPv6 records, when returned, will be actually tried - first which may typically lead to long timeouts. - - The third case is a bit more complex: optimizing away the DNS lookups - with only link-locals is probably safe (but may be desirable with - different lookup services which getaddrinfo() may support), as the - link-locals are typically automatically generated when IPv6 is - enabled, and do not indicate any form of IPv6 connectivity. That is, - performing DNS lookups only when a non-link-local address has been - configured on any interface could be beneficial -- this would be an - indication that either the address has been configured either from a - router advertisement, DHCPv6 [RFC3315], or manually. Each would - - - -Durand, et al. Expires January 17, 2006 [Page 12] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - indicate at least some form of IPv6 connectivity, even though there - would not be guarantees of it. - - These issues should be analyzed at more depth, and the fixes found - consensus on, perhaps in a separate document. - -5.2 Obtaining a List of DNS Recursive Resolvers - - In scenarios where DHCPv6 is available, a host can discover a list of - DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" - option [RFC3646]. This option can be passed to a host through a - subset of DHCPv6 [RFC3736]. - - The IETF is considering the development of alternative mechanisms for - obtaining the list of DNS recursive name servers when DHCPv6 is - unavailable or inappropriate. No decision about taking on this - development work has been reached as of this writing (Aug 2004) - [I-D.ietf-dnsop-ipv6-dns-configuration]. - - In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms - under consideration for development include the use of well-known - addresses [I-D.ohta-preconfigured-dns] and the use of Router - Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns- - discovery]. - - Note that even though IPv6 DNS resolver discovery is a recommended - procedure, it is not required for dual-stack nodes in dual-stack - networks as IPv6 DNS records can be queried over IPv4 as well as - IPv6. Obviously, nodes which are meant to function without manual - configuration in IPv6-only networks must implement the DNS resolver - discovery function. - -5.3 IPv6 Transport Guidelines for Resolvers - - As described in Section 1.3 and [RFC3901], the recursive resolvers - should be IPv4-only or dual-stack to be able to reach any IPv4-only - DNS server. Note that this requirement is also fulfilled by an IPv6- - only stub resolver pointing to a dual-stack recursive DNS resolver. - -6. Considerations about Forward DNS Updating - - While the topic of how to enable updating the forward DNS, i.e., the - mapping from names to the correct new addresses, is not specific to - IPv6, it should be considered especially due to the advent of - Stateless Address Autoconfiguration [RFC2462]. - - Typically forward DNS updates are more manageable than doing them in - the reverse DNS, because the updater can often be assumed to "own" a - - - -Durand, et al. Expires January 17, 2006 [Page 13] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - certain DNS name -- and we can create a form of security relationship - with the DNS name and the node which is allowed to update it to point - to a new address. - - A more complex form of DNS updates -- adding a whole new name into a - DNS zone, instead of updating an existing name -- is considered out - of scope for this memo as it could require zone-wide authentication. - Adding a new name in the forward zone is a problem which is still - being explored with IPv4, and IPv6 does not seem to add much new in - that area. - -6.1 Manual or Custom DNS Updates - - The DNS mappings can also be maintained by hand, in a semi-automatic - fashion or by running non-standardized protocols. These are not - considered at more length in this memo. - -6.2 Dynamic DNS - - Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized - mechanism for dynamically updating the DNS. It works equally well - with stateless address autoconfiguration (SLAAC), DHCPv6 or manual - address configuration. It is important to consider how each of these - behave if IP address-based authentication, instead of stronger - mechanisms [RFC3007], was used in the updates. - - 1. manual addresses are static and can be configured - - 2. DHCPv6 addresses could be reasonably static or dynamic, depending - on the deployment, and could or could not be configured on the - DNS server for the long term - - 3. SLAAC addresses are typically stable for a long time, but could - require work to be configured and maintained. - - As relying on IP addresses for Dynamic DNS is rather insecure at - best, stronger authentication should always be used; however, this - requires that the authorization keying will be explicitly configured - using unspecified operational methods. - - Note that with DHCP it is also possible that the DHCP server updates - the DNS, not the host. The host might only indicate in the DHCP - exchange which hostname it would prefer, and the DHCP server would - make the appropriate updates. Nonetheless, while this makes setting - up a secure channel between the updater and the DNS server easier, it - does not help much with "content" security, i.e., whether the - hostname was acceptable -- if the DNS server does not include - policies, they must be included in the DHCP server (e.g., a regular - - - -Durand, et al. Expires January 17, 2006 [Page 14] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - host should not be able to state that its name is "www.example.com"). - DHCP-initiated DDNS updates have been extensively described in - [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and - [I-D.ietf-dnsext-dhcid-rr]. - - The nodes must somehow be configured with the information about the - servers where they will attempt to update their addresses, sufficient - security material for authenticating themselves to the server, and - the hostname they will be updating. Unless otherwise configured, the - first could be obtained by looking up the authoritative name servers - for the hostname; the second must be configured explicitly unless one - chooses to trust the IP address-based authentication (not a good - idea); and lastly, the nodename is typically pre-configured somehow - on the node, e.g., at install time. - - Care should be observed when updating the addresses not to use longer - TTLs for addresses than are preferred lifetimes for the addresses, so - that if the node is renumbered in a managed fashion, the amount of - stale DNS information is kept to the minimum. That is, if the - preferred lifetime of an address expires, the TTL of the record needs - be modified unless it was already done before the expiration. For - better flexibility, the DNS TTL should be much shorter (e.g., a half - or a third) than the lifetime of an address; that way, the node can - start lowering the DNS TTL if it seems like the address has not been - renewed/refreshed in a while. Some discussion on how an - administrator could manage the DNS TTL is included in [I-D.ietf- - v6ops-renumbering-procedure]; this could be applied to (smart) hosts - as well. - -7. Considerations about Reverse DNS Updating - - Updating the reverse DNS zone may be difficult because of the split - authority over an address. However, first we have to consider the - applicability of reverse DNS in the first place. - -7.1 Applicability of Reverse DNS - - Today, some applications use reverse DNS to either look up some hints - about the topological information associated with an address (e.g. - resolving web server access logs), or as a weak form of a security - check, to get a feel whether the user's network administrator has - "authorized" the use of the address (on the premises that adding a - reverse record for an address would signal some form of - authorization). - - One additional, maybe slightly more useful usage is ensuring that the - reverse and forward DNS contents match (by looking up the pointer to - the name by the IP address from the reverse tree, and ensuring that a - - - -Durand, et al. Expires January 17, 2006 [Page 15] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - record under the name in the forward tree points to the IP address) - and correspond to a configured name or domain. As a security check, - it is typically accompanied by other mechanisms, such as a user/ - password login; the main purpose of the reverse+forward DNS check is - to weed out the majority of unauthorized users, and if someone - managed to bypass the checks, he would still need to authenticate - "properly". - - It may also be desirable to store IPsec keying material corresponding - to an IP address in the reverse DNS, as justified and described in - [RFC4025]. - - It is not clear whether it makes sense to require or recommend that - reverse DNS records be updated. In many cases, it would just make - more sense to use proper mechanisms for security (or topological - information lookup) in the first place. At minimum, the applications - which use it as a generic authorization (in the sense that a record - exists at all) should be modified as soon as possible to avoid such - lookups completely. - - The applicability is discussed at more length in [I-D.ietf-dnsop- - inaddr-required]. - -7.2 Manual or Custom DNS Updates - - Reverse DNS can of course be updated using manual or custom methods. - These are not further described here, except for one special case. - - One way to deploy reverse DNS would be to use wildcard records, for - example, by configuring one name for a subnet (/64) or a site (/48). - As a concrete example, a site (or the site's ISP) could configure the - reverses of the prefix 2001:db8:f00::/48 to point to one name using a - wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR - site.example.com." Naturally, such a name could not be verified from - the forward DNS, but would at least provide some form of "topological - information" or "weak authorization" if that is really considered to - be useful. Note that this is not actually updating the DNS as such, - as the whole point is to avoid DNS updates completely by manually - configuring a generic name. - -7.3 DDNS with Stateless Address Autoconfiguration - - Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in - some regard, while being more difficult in another, as described - below. - - The address space administrator decides whether the hosts are trusted - to update their reverse DNS records or not. If they are trusted and - - - -Durand, et al. Expires January 17, 2006 [Page 16] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - deployed at the same site (e.g., not across the Internet), a simple - address-based authorization is typically sufficient (i.e., check that - the DNS update is done from the same IP address as the record being - updated); stronger security can also be used [RFC3007]. If they - aren't allowed to update the reverses, no update can occur. However, - such address-based update authorization operationally requires that - ingress filtering [RFC3704] has been set up at the border of the site - where the updates occur, and as close to the updater as possible. - - Address-based authorization is simpler with reverse DNS (as there is - a connection between the record and the address) than with forward - DNS. However, when a stronger form of security is used, forward DNS - updates are simpler to manage because the host can be assumed to have - an association with the domain. Note that the user may roam to - different networks, and does not necessarily have any association - with the owner of that address space -- so, assuming stronger form of - authorization for reverse DNS updates than an address association is - generally infeasible. - - Moreover, the reverse zones must be cleaned up by an unspecified - janitorial process: the node does not typically know a priori that it - will be disconnected, and cannot send a DNS update using the correct - source address to remove a record. - - A problem with defining the clean-up process is that it is difficult - to ensure that a specific IP address and the corresponding record are - no longer being used. Considering the huge address space, and the - unlikelihood of collision within 64 bits of the interface - identifiers, a process which would remove the record after no traffic - has been seen from a node in a long period of time (e.g., a month or - year) might be one possible approach. - - To insert or update the record, the node must discover the DNS server - to send the update to somehow, similar to as discussed in - Section 6.2. One way to automate this is looking up the DNS server - authoritative (e.g., through SOA record) for the IP address being - updated, but the security material (unless the IP address-based - authorization is trusted) must also be established by some other - means. - - One should note that Cryptographically Generated Addresses [RFC3972] - (CGAs) may require a slightly different kind of treatment. CGAs are - addresses where the interface identifier is calculated from a public - key, a modifier (used as a nonce), the subnet prefix, and other data. - Depending on the usage profile, CGAs might or might not be changed - periodically due to e.g., privacy reasons. As the CGA address is not - predicatable, a reverse record can only reasonably be inserted in the - DNS by the node which generates the address. - - - -Durand, et al. Expires January 17, 2006 [Page 17] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -7.4 DDNS with DHCP - - With DHCPv4, the reverse DNS name is typically already inserted to - the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One - can assume similar practice may become commonplace with DHCPv6 as - well; all such mappings would be pre-configured, and would require no - updating. - - If a more explicit control is required, similar considerations as - with SLAAC apply, except for the fact that typically one must update - a reverse DNS record instead of inserting one (if an address - assignment policy that reassigns disused addresses is adopted) and - updating a record seems like a slightly more difficult thing to - secure. However, it is yet uncertain how DHCPv6 is going to be used - for address assignment. - - Note that when using DHCP, either the host or the DHCP server could - perform the DNS updates; see the implications in Section 6.2. - - If disused addresses were to be reassigned, host-based DDNS reverse - updates would need policy considerations for DNS record modification, - as noted above. On the other hand, if disused address were not to be - assigned, host-based DNS reverse updates would have similar - considerations as SLAAC in Section 7.3. Server-based updates have - similar properties except that the janitorial process could be - integrated with DHCP address assignment. - -7.5 DDNS with Dynamic Prefix Delegation - - In cases where a prefix, instead of an address, is being used and - updated, one should consider what is the location of the server where - DDNS updates are made. That is, where the DNS server is located: - - 1. At the same organization as the prefix delegator. - - 2. At the site where the prefixes are delegated to. In this case, - the authority of the DNS reverse zone corresponding to the - delegated prefix is also delegated to the site. - - 3. Elsewhere; this implies a relationship between the site and where - DNS server is located, and such a relationship should be rather - straightforward to secure as well. Like in the previous case, - the authority of the DNS reverse zone is also delegated. - - In the first case, managing the reverse DNS (delegation) is simpler - as the DNS server and the prefix delegator are in the same - administrative domain (as there is no need to delegate anything at - all); alternatively, the prefix delegator might forgo DDNS reverse - - - -Durand, et al. Expires January 17, 2006 [Page 18] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - capability altogether, and use e.g., wildcard records (as described - in Section 7.2). In the other cases, it can be slighly more - difficult, particularly as the site will have to configure the DNS - server to be authoritative for the delegated reverse zone, implying - automatic configuration of the DNS server -- as the prefix may be - dynamic. - - Managing the DDNS reverse updates is typically simple in the second - case, as the updated server is located at the local site, and - arguably IP address-based authentication could be sufficient (or if - not, setting up security relationships would be simpler). As there - is an explicit (security) relationship between the parties in the - third case, setting up the security relationships to allow reverse - DDNS updates should be rather straightforward as well (but IP - address-based authentication might not be acceptable). In the first - case, however, setting up and managing such relationships might be a - lot more difficult. - -8. Miscellaneous DNS Considerations - - This section describes miscellaneous considerations about DNS which - seem related to IPv6, for which no better place has been found in - this document. - -8.1 NAT-PT with DNS-ALG - - The DNS-ALG component of NAT-PT mangles A records to look like AAAA - records to the IPv6-only nodes. Numerous problems have been - identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is - a strong reason not to use NAT-PT in the first place. - -8.2 Renumbering Procedures and Applications' Use of DNS - - One of the most difficult problems of systematic IP address - renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that - an application which looks up a DNS name disregards information such - as TTL, and uses the result obtained from DNS as long as it happens - to be stored in the memory of the application. For applications - which run for a long time, this could be days, weeks or even months; - some applications may be clever enough to organize the data - structures and functions in such a manner that look-ups get refreshed - now and then. - - While the issue appears to have a clear solution, "fix the - applications", practically this is not reasonable immediate advice; - the TTL information is not typically available in the APIs and - libraries (so, the advice becomes "fix the applications, APIs and - libraries"), and a lot more analysis is needed on how to practically - - - -Durand, et al. Expires January 17, 2006 [Page 19] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - go about to achieve the ultimate goal of avoiding using the names - longer than expected. - -9. Acknowledgements - - Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik - Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided - useful feedback and improvements. Scott Rose, Rob Austein, Masataka - Ohta, and Mark Andrews helped in clarifying the issues regarding - additional data and the use of TTL. Jefsey Morfin, Ralph Droms, - Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and - Rob Austein provided useful feedback during the WG last call. Thomas - Narten provided extensive feedback during the IESG evaluation. - -10. Security Considerations - - This document reviews the operational procedures for IPv6 DNS - operations and does not have security considerations in itself. - - However, it is worth noting that in particular with Dynamic DNS - Updates, security models based on the source address validation are - very weak and cannot be recommended -- they could only be considered - in the environments where ingress filtering [RFC3704] has been - deployed. On the other hand, it should be noted that setting up an - authorization mechanism (e.g., a shared secret, or public-private - keys) between a node and the DNS server has to be done manually, and - may require quite a bit of time and expertise. - - To re-emphasize what was already stated, the reverse+forward DNS - check provides very weak security at best, and the only - (questionable) security-related use for them may be in conjunction - with other mechanisms when authenticating a user. - -11. References - -11.1 Normative References - - [I-D.ietf-dnsop-ipv6-dns-configuration] - Jeong, J., "IPv6 Host Configuration of DNS Server - Information Approaches", - draft-ietf-dnsop-ipv6-dns-configuration-06 (work in - progress), May 2005. - - [I-D.ietf-ipv6-unique-local-addr] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in - progress), January 2005. - - - -Durand, et al. Expires January 17, 2006 [Page 20] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - [I-D.ietf-v6ops-renumbering-procedure] - Baker, F., "Procedures for Renumbering an IPv6 Network - without a Flag Day", - draft-ietf-v6ops-renumbering-procedure-05 (work in - progress), March 2005. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. - - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, - April 2001. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. - - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. - - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., - and M. Carney, "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) - - - -Durand, et al. Expires January 17, 2006 [Page 21] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. - - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. - - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, - October 2003. - - [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - - [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", RFC 3879, September 2004. - - [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational - Guidelines", BCP 91, RFC 3901, September 2004. - - [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. - Castro, "Application Aspects of IPv6 Transition", - RFC 4038, March 2005. - - [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against - DNS Queries for IPv6 Addresses", RFC 4074, May 2005. - -11.2 Informative References - - [I-D.durand-dnsop-dont-publish] - Durand, A. and T. Chown, "To publish, or not to publish, - that is the question.", draft-durand-dnsop-dont-publish-00 - (work in progress), February 2005. - - [I-D.huitema-v6ops-teredo] - Huitema, C., "Teredo: Tunneling IPv6 over UDP through - NATs", draft-huitema-v6ops-teredo-05 (work in progress), - April 2005. - - [I-D.huston-6to4-reverse-dns] - Huston, G., "6to4 Reverse DNS Delegation", - - - -Durand, et al. Expires January 17, 2006 [Page 22] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - draft-huston-6to4-reverse-dns-03 (work in progress), - October 2004. - - [I-D.ietf-dhc-ddns-resolution] - Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among - DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in - progress), June 2005. - - [I-D.ietf-dhc-fqdn-option] - Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", - draft-ietf-dhc-fqdn-option-10 (work in progress), - February 2005. - - [I-D.ietf-dnsext-dhcid-rr] - Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for - encoding DHCP information (DHCID RR)", - draft-ietf-dnsext-dhcid-rr-09 (work in progress), - February 2005. - - [I-D.ietf-dnsop-bad-dns-res] - Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in - progress), October 2004. - - [I-D.ietf-dnsop-inaddr-required] - Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", - draft-ietf-dnsop-inaddr-required-06 (work in progress), - February 2005. - - [I-D.ietf-v6ops-3gpp-analysis] - Wiljakka, J., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in - progress), October 2004. - - [I-D.ietf-v6ops-mech-v2] - Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms - for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 - (work in progress), March 2005. - - [I-D.ietf-v6ops-natpt-to-exprmntl] - Aoun, C. and E. Davies, "Reasons to Move NAT-PT to - Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work - in progress), July 2005. - - [I-D.ietf-v6ops-onlinkassumption] - Roy, S., "IPv6 Neighbor Discovery On-Link Assumption - Considered Harmful", draft-ietf-v6ops-onlinkassumption-03 - (work in progress), May 2005. - - - -Durand, et al. Expires January 17, 2006 [Page 23] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - [I-D.ietf-v6ops-v6onbydefault] - Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack - IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 - (work in progress), July 2004. - - [I-D.jeong-dnsop-ipv6-dns-discovery] - Jeong, J., "IPv6 DNS Configuration based on Router - Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04 - (work in progress), February 2005. - - [I-D.ohta-preconfigured-dns] - Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01 (work in progress), - February 2004. - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [RFC2826] Internet Architecture Board, "IAB Technical Comment on the - Unique DNS Root", RFC 2826, May 2000. - - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", BCP 84, RFC 3704, March 2004. - - [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", - RFC 3972, March 2005. - - [RFC4025] Richardson, M., "A Method for Storing IPsec Keying - Material in DNS", RFC 4025, March 2005. - - -Authors' Addresses - - Alain Durand - SUN Microsystems, Inc. - 17 Network circle UMPL17-202 - Menlo Park, CA 94025 - USA - - Email: Alain.Durand@sun.com - - - - - - -Durand, et al. Expires January 17, 2006 [Page 24] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - Email: johani@autonomica.se - - - Pekka Savola - CSC/FUNET - Espoo - Finland - - Email: psavola@funet.fi - -Appendix A. Unique Local Addressing Considerations for DNS - - Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have - replaced the now-deprecated site-local addresses [RFC3879]. From the - perspective of the DNS, the locally generated unique local addresses - (LUL) and site-local addresses have similar properties. - - The interactions with DNS come in two flavors: forward and reverse - DNS. - - To actually use local addresses within a site, this implies the - deployment of a "split-faced" or a fragmented DNS name space, for the - zones internal to the site, and the outsiders' view to it. The - procedures to achieve this are not elaborated here. The implication - is that local addresses must not be published in the public DNS. - - To faciliate reverse DNS (if desired) with local addresses, the stub - resolvers must look for DNS information from the local DNS servers, - not e.g. starting from the root servers, so that the local - information may be provided locally. Note that the experience of - private addresses in IPv4 has shown that the root servers get loaded - for requests for private address lookups in any case. This - requirement is discussed in [I-D.ietf-ipv6-unique-local-addr]. - -Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments - - DNS responses do not always fit in a single UDP packet. We'll - examine the cases which happen when this is due to too much data in - the Additional Section. - - - - - - -Durand, et al. Expires January 17, 2006 [Page 25] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -B.1 Description of Additional Data Scenarios - - There are two kinds of additional data: - - 1. "critical" additional data; this must be included in all - scenarios, with all the RRsets, and - - 2. "courtesy" additional data; this could be sent in full, with only - a few RRsets, or with no RRsets, and can be fetched separately as - well, but at the cost of additional queries. - - The responding server can algorithmically determine which type the - additional data is by checking whether it's at or below a zone cut. - - Only those additional data records (even if sometimes carelessly - termed "glue") are considered "critical" or real "glue" if and only - if they meet the abovementioned condition, as specified in Section - 4.2.1 of [RFC1034]. - - Remember that resource record sets (RRsets) are never "broken up", so - if a name has 4 A records and 5 AAAA records, you can either return - all 9, all 4 A records, all 5 AAAA records or nothing. In - particular, notice that for the "critical" additional data getting - all the RRsets can be critical. - - In particular, [RFC2181] specifies (in Section 9) that: - - a. if all the "critical" RRsets do not fit, the sender should set - the TC bit, and the recipient should discard the whole response - and retry using mechanism allowing larger responses such as TCP. - - b. "courtesy" additional data should not cause the setting of TC - bit, but instead all the non-fitting additional data RRsets - should be removed. - - An example of the "courtesy" additional data is A/AAAA records in - conjunction with MX records as shown in Section 4.4; an example of - the "critical" additional data is shown below (where getting both the - A and AAAA RRsets is critical w.r.t. to the NS RR): - - child.example.com. IN NS ns.child.example.com. - ns.child.example.com. IN A 192.0.2.1 - ns.child.example.com. IN AAAA 2001:db8::1 - - When there is too much "courtesy" additional data, at least the non- - fitting RRsets should be removed [RFC2181]; however, as the - additional data is not critical, even all of it could be safely - removed. - - - -Durand, et al. Expires January 17, 2006 [Page 26] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - When there is too much "critical" additional data, TC bit will have - to be set, and the recipient should ignore the response and retry - using TCP; if some data were to be left in the UDP response, the - issue is which data could be retained. - - Failing to discard the response with TC bit or omitting critical - information but not setting TC bit lead to an unrecoverable problem. - Omitting only some of the RRsets if all would not fit (but not - setting TC bit) leads to a performance problem. These are discussed - in the next two subsections. - -B.2 Which Additional Data to Keep, If Any? - - If the implementation decides to keep as much data (whether - "critical" or "courtesy") as possible in the UDP responses, it might - be tempting to use the transport of the DNS query as a hint in either - of these cases: return the AAAA records if the query was done over - IPv6, or return the A records if the query was done over IPv4. - However, this breaks the model of independence of DNS transport and - resource records, as noted in Section 1.2. - - With courtesy additional data, as long as enough RRsets will be - removed so that TC will not be set, it is allowed to send as many - complete RRsets as the implementations prefers. However, the - implementations are also free to omit all such RRsets, even if - complete. Omitting all the RRsets (when removing only some would - suffice) may create a performance penalty, whereby the client may - need to issue one or more additional queries to obtain necessary - and/or consistent information. - - With critical additional data, the alternatives are either returning - nothing (and absolutely requiring a retry with TCP) or returning - something (working also in the case if the recipient does not discard - the response and retry using TCP) in addition to setting the TC bit. - If the process for selecting "something" from the critical data would - otherwise be practically "flipping the coin" between A and AAAA - records, it could be argued that if one looked at the transport of - the query, it would have a larger possibility of being right than - just 50/50. In other words, if the returned critical additional data - would have to be selected somehow, using something more sophisticated - than a random process would seem justifiable. - - That is, leaving in some intelligently selected critical additional - data is a tradeoff between creating an optimization for those - resolvers which ignore the "should discard" recommendation, and - causing a protocol problem by propagating inconsistent information - about "critical" records in the caches. - - - - -Durand, et al. Expires January 17, 2006 [Page 27] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - Similarly, leaving in the complete courtesy additional data RRsets - instead of removing all the RRsets is a performance tradeoff as - described in the next section. - -B.3 Discussion of the Potential Problems - - As noted above, the temptation for omitting only some of the - additional data could be problematic. This is discussed more below. - - For courtesy additional data, this causes a potential performance - problem as this requires that the clients issue re-queries for the - potentially omitted RRsets. For critical additional data, this - causes a potential unrecoverable problem if the response is not - discarded and the query not re-tried with TCP, as the nameservers - might be reachable only through the omitted RRsets. - - If an implementation would look at the transport used for the query, - it is worth remembering that often the host using the records is - different from the node requesting them from the authoritative DNS - server (or even a caching resolver). So, whichever version the - requestor (e.g., a recursive server in the middle) uses makes no - difference to the ultimate user of the records, whose transport - capabilities might differ from those of the requestor. This might - result in e.g., inappropriately returning A records to an IPv6-only - node, going through a translation, or opening up another IP-level - session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). - Therefore, at least in many scenarios, it would be very useful if the - information returned would be consistent and complete -- or if that - is not feasible, return no misleading information but rather leave it - to the client to query again. - - The problem of too much additional data seems to be an operational - one: the zone administrator entering too many records which will be - returned either truncated (or missing some RRsets, depending on - implementations) to the users. A protocol fix for this is using - EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, - pushing up the relevant threshold. Further, DNS server - implementations should rather omit courtesy additional data - completely rather than including only some RRsets [RFC2181]. An - operational fix for this is having the DNS server implementations - return a warning when the administrators create zones which would - result in too much additional data being returned. Further, DNS - server implementations should warn of or disallow such zone - configurations which are recursive or otherwise difficult to manage - by the protocol. - - Additionally, to avoid the case where an application would not get an - address at all due to some of courtesy additional data being omitted, - - - -Durand, et al. Expires January 17, 2006 [Page 28] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - the resolvers should be able to query the specific records of the - desired protocol, not just rely on getting all the required RRsets in - the additional section. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires January 17, 2006 [Page 29] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Durand, et al. Expires January 17, 2006 [Page 30] - - diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt deleted file mode 100644 index b2e2341b..00000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt +++ /dev/null @@ -1,300 +0,0 @@ -Internet Engineering Task Force A.Durand -INTERNET-DRAFT SUN Microsystems,inc. -November, 24, 2003 J. Ihren -Expires May 25, 2004 Autonomica - - - DNS IPv6 transport operational guidelines - <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt> - - - -Status of this Memo - - This memo provides information to the Internet community. It does not - specify an Internet standard of any kind. This memo is in full - conformance with all provisions of Section 10 of RFC2026 - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - -Abstract - - This memo provides guidelines and Best Current Practice to operate - DNS in a world where queries and responses are carried in a mixed - environment of IPv4 and IPv6 networks. - - -Acknowledgment - - This document is the result of many conversations that happened in - the DNS community at IETF and elsewhere since 2001. During that - period of time, a number of Internet drafts have been published to - clarify various aspects of the issues at stake. This document focuses - on the conclusion of those discussions. - - The authors would like to acknowledge the role of Pekka Savola in his - thorough review of the document. - - -1. Terminology - - The phrase "IPv4 name server" indicates a name server available over - IPv4 transport. It does not imply anything about what DNS data is - served. Likewise, "IPv6 name server" indicates a name server - available over IPv6 transport. The phrase "dual-stack DNS server" - indicates a DNS server that is actually configured to run both - protocols, IPv4 and IPv6, and not merely a server running on a system - capable of running both but actually configured to run only one. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [2119]. - - -2. Introduction to the Problem of Name Space Fragmentation: - following the referral chain - - The caching resolver that tries to look up a name starts out at the - root, and follows referrals until it is referred to a nameserver that - is authoritative for the name. If somewhere down the chain of - referrals it is referred to a nameserver that is only accessible over - an unavailable type of transport, a traditional nameserver is unable - to finish the task. - - When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is - only a matter of time until this starts to happen. The complete DNS - hierarchy then starts to fragment into a graph where authoritative - nameservers for certain nodes are only accessible over a certain - transport. What is feared is that a node using only a particular - version of IP, querying information about another node using the same - version of IP can not do it because, somewhere in the chain of - servers accessed during the resolution process, one or more of them - will only be accessible with the other version of IP. - - With all DNS data only available over IPv4 transport everything is - simple. IPv4 resolvers can use the intended mechanism of following - referrals from the root and down while IPv6 resolvers have to work - through a "translator", i.e. they have to use a second name server on - a so-called "dual stack" host as a "forwarder" since they cannot - access the DNS data directly. - - With all DNS data only available over IPv6 transport everything would - be equally simple, with the exception of old legacy IPv4 name servers - having to switch to a forwarding configuration. - - However, the second situation will not arise in a foreseeable time. - Instead, it is expected that the transition will be from IPv4 only to - a mixture of IPv4 and IPv6, with DNS data of theoretically three - categories depending on whether it is available only over IPv4 - transport, only over IPv6 or both. - - Having DNS data available on both transports is the best situation. - The major question is how to ensure that it as quickly as possible - becomes the norm. However, while it is obvious that some DNS data - will only be available over v4 transport for a long time it is also - obvious that it is important to avoid fragmenting the name space - available to IPv4 only hosts. I.e. during transition it is not - acceptable to break the name space that we presently have available - for IPv4-only hosts. - - -3. Policy Based Avoidance of Name Space Fragmentation - - Today there are only a few DNS "zones" on the public Internet that - are available over IPv6 transport, and most of them can be regarded - as "experimental". However, as soon as the root and top level domains - are available over IPv6 transport, it is reasonable to expect that it - will become more common to have zones served by IPv6 servers. - - Having those zones served only by IPv6-only name server would not be - a good development, since this will fragment the previously - unfragmented IPv4 name space and there are strong reasons to find a - mechanism to avoid it. - - The RECOMMENDED approach to maintain name space continuity is to use - administrative policies, as described in the next section. - - -4. DNS IPv6 Transport RECOMMENDED Guidelines - - In order to preserve name space continuity, the following administrative - policies are RECOMMENDED: - - every recursive DNS server SHOULD be either IPv4-only or dual - stack, - - every single DNS zone SHOULD be served by at least one IPv4 - reachable DNS server. - - This rules out IPv6-only DNS servers performing full recursion and - DNS zones served only by IPv6-only DNS servers. However, one could - very well design a configuration where a chain of IPv6 only DNS - servers forward queries to a set of dual stack DNS servers actually - performing those recursive queries. This approach could be revisited - if/when translation techniques between IPv4 and IPv6 were to be - widely deployed. - - In order to help enforcing the second point, the optional operational - zone validation processes SHOULD ensure that there is at least one - IPv4 address record available for the name servers of any child - delegations within the zone. - - -5. Security Considerations - - Being a critical piece of the Internet infrastructure, the DNS is a - potential value target and thus should be protected. Great care - should be taken not to weaken the security of DNS while introducing - IPv6 operation. - - Keeping the DNS name space from fragmenting is a critical thing for - the availability and the operation of the Internet; this memo - addresses this issue by clear and simple operational guidelines. - - The RECOMMENDED guidelines are compatible with the operation of - DNSSEC and do not introduce any new security issues. - - -6. Author Addresses - - Alain Durand - SUN Microsystems, Inc - 17 Network circle UMPK17-202 - Menlo Park, CA, 94025 - USA - Mail: Alain.Durand@sun.com - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm, Sweden - Mail: johani@autonomica.se - - -7. Normative References - - [2119] Bradner, S., "Key Words for Use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - -8. Full Copyright Statement - - "Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt deleted file mode 100644 index 6bece561..00000000 --- a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt +++ /dev/null @@ -1,389 +0,0 @@ - -DNSOP G. Guette -Internet-Draft IRISA / INRIA -Expires: July 19, 2005 O. Courtay - Thomson R&D - January 18, 2005 - - Requirements for Automated Key Rollover in DNSSEC - draft-ietf-dnsop-key-rollover-requirements-02.txt - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 19, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). All Rights Reserved. - -Abstract - - This document describes problems that appear during an automated - rollover and gives the requirements for the design of communication - between parent zone and child zone during an automated rollover - process. This document is essentially about in-band key rollover. - - - - -Guette & Courtay Expires July 19, 2005 [Page 1] -Internet-Draft Automated Rollover Requirements January 2005 - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 - 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Messages authentication and information exchanged . . . . . . 5 - 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 - A. Documents details and changes . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . . 8 - - - - - - - - - - - - - - - - - - - -Guette & Courtay Expires July 19, 2005 [Page 2] -Internet-Draft Automated Rollover Requirements January 2005 - -1. Introduction - - The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key - cryptography and digital signatures. It stores the public part of - keys in DNSKEY Resource Records (RRs). Because old keys and - frequently used keys are vulnerable, they must be renewed - periodically. In DNSSEC, this is the case for Zone Signing Keys - (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key - exchanges between parents and children is necessary for large zones - because there are too many changes to handle. - - Let us consider for example a zone with 100000 secure delegations. - If the child zones change their keys once a year on average, that - implies 300 changes per day for the parent zone. This amount of - changes is hard to manage manually. - - Automated rollover is optional and resulting from an agreement - between the administrator of the parent zone and the administrator of - the child zone. Of course, key rollover can also be done manually by - administrators. - - This document describes the requirements for a protocol to perform - the automated key rollover process and focusses on interaction - between parent and child zone. - -2. The Key Rollover Process - - Key rollover consists of renewing the DNSSEC keys used to sign - resource records in a given DNS zone file. There are two types of - rollover, ZSK rollovers and KSK rollovers. - - During a ZSK rollover, all changes are local to the zone that renews - its key: there is no need to contact other zones administrators to - propagate the performed changes because a ZSK has no associated DS - record in the parent zone. - - During a KSK rollover, new DS RR(s) must be created and stored in the - parent zone. In consequence, data must be exchanged between child - and parent zones. - - The key rollover is built from two parts of different nature: - o An algorithm that generates new keys and signs the zone file. It - can be local to the zone, - o the interaction between parent and child zones. - - One example of manual key rollover [3] is: - o The child zone creates a new KSK, - - -Guette & Courtay Expires July 19, 2005 [Page 3] -Internet-Draft Automated Rollover Requirements January 2005 - - o the child zone waits for the creation of the DS RR in its parent - zone, - o the child zone deletes the old key, - o the parent zone deletes the old DS RR. - - This document concentrates on defining interactions between entities - present in key rollover process. - -3. Basic Requirements - - This section provides the requirements for automated key rollover in - case of normal use. Exceptional case like emergency rollover is - specifically described later in this document. - - The main condition during a key rollover is that the chain of trust - must be preserved to every validating DNS client. No matter if this - client retrieves some of the RRs from recursive caching name server - or from the authoritative servers for the zone involved in the - rollover. - - Automated key rollover solution may be interrupted by a manual - intervention. This manual intervention should not compromise the - security state of the chain of trust. If the chain is safe before - the manual intervention, the chain of trust must remain safe during - and after the manual intervention - - Two entities act during a KSK rollover: the child zone and its parent - zone. These zones are generally managed by different administrators. - These administrators should agree on some parameters like - availability of automated rollover, the maximum delay between - notification of changes in the child zone and the resigning of the - parent zone. The child zone needs to know this delay to schedule its - changes and/or to verify that the changes had been taken into account - in the parent zone. Hence, the child zone can also avoid some - critical cases where all child key are changed prior to the DS RR - creation. - - By keeping some resource records during a given time, the recursive - cache servers can act on the automated rollover. The existence of - recursive cache servers must be taken into account by automated - rollover solution. - - Indeed, during an automated key rollover a name server could have to - retrieve some DNSSEC data. An automated key rollover solution must - ensure that these data are not old DNSSEC material retrieved from a - recursive name server. - - - -Guette & Courtay Expires July 19, 2005 [Page 4] -Internet-Draft Automated Rollover Requirements January 2005 - -4. Messages authentication and information exchanged - - This section addresses in-band rollover, security of out-of-band - mechanisms is out of scope of this document. - - The security provided by DNSSEC must not be compromised by the key - rollover, thus every exchanged message must be authenticated to avoid - fake rollover messages from malicious parties. - - Once the changes related to a KSK are made in a child zone, there are - two ways for the parent zone to take this changes into account: - o the child zone notify directly or not directly its parent zone in - order to create the new DS RR and store this DS RR in parent zone - file, - o or the parent zone poll the child zone. - - In both cases, the parent zone must receive all the child keys that - need the creation of associated DS RRs in the parent zone. - - Because errors could occur during the transmission of keys between - child and parent, the key exchange protocol must be fault tolerant. - Should an error occured during the automated key rollover, an - automated key rollover solution must be able to keep the zone files - in a consistent state. - -5. Emergency Rollover - - Emergency key rollover is a special case of rollover decided by the - zone administrator generally for security reasons. In consequence, - emergency key rollover can break some of the requirement described - above. - - A zone key might be compromised and an attacker can use the - compromised key to create and sign fake records. To avoid this, the - zone administrator may change the compromised key or all its keys as - soon as possible, without waiting for the creation of new DS RRs in - its parent zone. - - Fast changes may break the chain of trust. The part of DNS tree - having this zone as apex can become unverifiable, but the break of - the chain of trust is necessary if the administrator wants to prevent - the compromised key from being used (to spoof DNS data). - - Parent and child zones sharing an automated rollover mechanism, - should have an out-of-band way to re-establish a consistent state at - the delegation point (DS and DNSKEY RRs). This allows to avoid that - a malicious party uses the compromised key to roll the zone keys. - - -Guette & Courtay Expires July 19, 2005 [Page 5] -Internet-Draft Automated Rollover Requirements January 2005 - -6. Security consideration - - The automated key rollover process in DNSSEC allows automated renewal - of any kind of DNS key (ZSK or KSK). It is essential that parent - side and child side can do mutual authentication. Moreover, - integrity of the material exchanged between the parent and child zone - must be provided to ensure the right DS are created. - - As in any application using public key cryptography, in DNSSEC a key - may be compromised. What to do in such a case can be describe in the - zone local policy and can violate some requirements described in this - draft. The emergency rollover can break the chain of trust in order - to protect the zone against the use of the compromised key. - -7. Acknowledgments - - The authors want to thank members of IDsA project for their - contribution to this document. - -8 Normative References - - [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - [3] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practice-01 (work in - progress), May 2004. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-11 (work in progress), October - 2004. - - [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-13 (work in progress), October - 2004. - - [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October - - -Guette & Courtay Expires July 19, 2005 [Page 6] -Internet-Draft Automated Rollover Requirements January 2005 - - 2004. - -Authors' Addresses - - Gilles Guette - IRISA / INRIA - Campus de Beaulieu - 35042 Rennes CEDEX - FR - - EMail: gilles.guette@irisa.fr - URI: http://www.irisa.fr - - Olivier Courtay - Thomson R&D - 1, avenue Belle Fontaine - 35510 Cesson S?vign? CEDEX - FR - - EMail: olivier.courtay@thomson.net - -Appendix A. Documents details and changes - - This section is to be removed by the RFC editor if and when the - document is published. - - Section about NS RR rollover has been removed - - Remarks from Samuel Weiler and Rip Loomis added - - Clarification about in-band rollover and in emergency section - - Section 3, details about recursive cache servers added - - - - - - - - -Guette & Courtay Expires July 19, 2005 [Page 7] -Internet-Draft Automated Rollover Requirements January 2005 - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described - in this document or the extent to which any license under such - rights might or might not be available; neither does it represent - that it has made any effort to identify any such rights. - Information on the IETF's procedures with respect to rights in - IETF Documents can be found in BCP 78 and 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights which may cover technology that may be required - to implement this standard. Please address the information to the - IETF at ietf-ipr.org. - - - Full Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - -Guette & Courtay Expires July 19, 2005 [Page 8] diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt deleted file mode 100644 index c6ec7e42..00000000 --- a/doc/draft/draft-ietf-dnsop-serverid-06.txt +++ /dev/null @@ -1,618 +0,0 @@ - - - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: September 6, 2006 D. Conrad - Nominum, Inc. - March 5, 2006 - - - Requirements for a Mechanism Identifying a Name Server Instance - draft-ietf-dnsop-serverid-06 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 6, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid for - administrators. Existing ad hoc mechanisms for addressing this need - - - -Woolf & Conrad Expires September 6, 2006 [Page 1] - -Internet-Draft Serverid March 2006 - - - have some shortcomings, not the least of which is the lack of prior - analysis of exactly how such a mechanism should be designed and - deployed. This document describes the existing convention used in - some widely deployed implementations of the DNS protocol, including - advantages and disadvantages, and discusses some attributes of an - improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 2] - -Internet-Draft Serverid March 2006 - - -1. Introduction and Rationale - - Identifying which name server is responding to queries is often - useful, particularly in attempting to diagnose name server - difficulties. This is most obviously useful for authoritative - nameservers in the attempt to diagnose the source or prevalence of - inaccurate data, but can also conceivably be useful for caching - resolvers in similar and other situations. Furthermore, the ability - to identify which server is responding to a query has become more - useful as DNS has become more critical to more Internet users, and as - network and server deployment topologies have become more complex. - - The traditional means for determining which of several possible - servers is answering a query has traditionally been based on the use - of the server's IP address as a unique identifier. However, the - modern Internet has seen the deployment of various load balancing, - fault-tolerance, or attack-resistance schemes such as shared use of - unicast IP addresses as documented in [RFC3258]. An unfortunate side - effect of these schemes has been to make the use of IP addresses as - identifiers somewhat problematic. Specifically, a dedicated DNS - query may not go to the same server as answered a previous query, - even though sent to the same IP address. Non-DNS methods such as - ICMP ping, TCP connections, or non-DNS UDP packets (such as those - generated by tools like "traceroute"), etc., may well be even less - certain to reach the same server as the one which receives the DNS - queries. - - There is a well-known and frequently-used technique for determining - an identity for a nameserver more specific than the possibly-non- - unique "server that answered the query I sent to IP address XXX". - The widespread use of the existing convention suggests a need for a - documented, interoperable means of querying the identity of a - nameserver that may be part of an anycast or load-balancing cluster. - At the same time, however, it also has some drawbacks that argue - against standardizing it as it's been practiced so far. - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 3] - -Internet-Draft Serverid March 2006 - - -2. Existing Conventions - - For some time, the commonly deployed Berkeley Internet Name Domain - implementation of the DNS protocol suite from the Internet Systems - Consortium [BIND] has supported a way of identifying a particular - server via the use of a standards-compliant, if somewhat unusual, DNS - query. Specifically, a query to a recent BIND server for a TXT - resource record in class 3 (CHAOS) for the domain name - "HOSTNAME.BIND." will return a string that can be configured by the - name server administrator to provide a unique identifier for the - responding server. (The value defaults to the result of a - gethostname() call). This mechanism, which is an extension of the - BIND convention of using CHAOS class TXT RR queries to sub-domains of - the "BIND." domain for version information, has been copied by - several name server vendors. - - A refinement to the BIND-based mechanism, which dropped the - implementation-specific string, replaces ".BIND" with ".SERVER". - Thus the query string to learn the unique name of a server may be - queried as "ID.SERVER". - - (For reference, the other well-known name used by recent versions of - BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A - query for a CHAOS TXT RR for this name will return an - administratively defined string which defaults to the version of the - server responding. This is, however, not generally implemented by - other vendors.) - -2.1. Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - - 1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is - within the DNS protocol itself. An identification mechanism that - relies on the DNS protocol is more likely to be successful - (although not guaranteed) in going to the same system as a - "normal" DNS query. - - 2. Since the identity information is requested and returned within - the DNS protocol, it doesn't require allowing any other query - mechanism to the server, such as holes in firewalls for - otherwise-unallowed ICMP Echo requests. Thus it is likely to - reach the same server over a path subject to the same routing, - resource, and security policy as the query, without any special - exceptions to site security policy. - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 4] - -Internet-Draft Serverid March 2006 - - - 3. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - - 4. It allows the administrator complete control of what information - is given out in the response, minimizing passive leakage of - implementation or configuration details. Such details are often - considered sensitive by infrastructure operators. - - 5. Hypothetically, since it's an ordinary DNS record and the - relevant DNSSEC RRs are class independent, the id.server response - RR could be signed, which has the advantages described in - [RFC4033]. - -2.2. Disadvantages - - At the same time, there are some serious drawbacks to the CHAOS/TXT - query mechanism that argue against standardizing it as it currently - operates. - - 1. It requires an additional query to correlate between the answer - to a DNS query under normal conditions and the supposed identity - of the server receiving the query. There are a number of - situations in which this simply isn't reliable. - - 2. It reserves an entire class in the DNS (CHAOS) for what amounts - to one zone. While CHAOS class is defined in [RFC1034] and - [RFC1035], it's not clear that supporting it solely for this - purpose is a good use of the namespace or of implementation - effort. - - 3. The initial and still common form, using .BIND, is implementation - specific. BIND is one DNS implementation. At the time of this - writing, it is probably the most prevalent for authoritative - servers. This does not justify standardizing on its ad hoc - solution to a problem shared across many operators and - implementors. Meanwhile, the proposed refinement changes the - string but preserves the ad hoc CHAOS/TXT mechanism. - - 4. There is no convention or shared understanding of what - information an answer to such a query for a server identity could - or should include, including a possible encoding or - authentication mechanism. - - The first of the listed disadvantages may be technically the most - serious. It argues for an attempt to design a good answer to the - problem that "I need to know what nameserver is answering my - queries", not simply a convenient one. - - - - -Woolf & Conrad Expires September 6, 2006 [Page 5] - -Internet-Draft Serverid March 2006 - - -2.3. Characteristics of an Implementation Neutral Convention - - The discussion above of advantages and disadvantages to the - HOSTNAME.BIND mechanism suggest some requirements for a better - solution to the server identification problem. These are summarized - here as guidelines for any effort to provide appropriate protocol - extensions: - - 1. The mechanism adopted must be in-band for the DNS protocol. That - is, it needs to allow the query for the server's identifying - information to be part of a normal, operational query. It should - also permit a separate, dedicated query for the server's - identifying information. But it should preserve the ability of - the CHAOS/TXT query-based mechanism to work through firewalls and - in other situations where only DNS can be relied upon to reach - the server of interest. - - 2. The new mechanism should not require dedicated namespaces or - other reserved values outside of the existing protocol mechanisms - for these, i.e. the OPT pseudo-RR. In particular, it should not - propagate the existing drawback of requiring support for a CLASS - and top level domain in the authoritative server (or the querying - tool) to be useful. - - 3. Support for the identification functionality should be easy to - implement and easy to enable. It must be easy to disable and - should lend itself to access controls on who can query for it. - - 4. It should be possible to return a unique identifier for a server - without requiring the exposure of information that may be non- - public and considered sensitive by the operator, such as a - hostname or unicast IP address maintained for administrative - purposes. - - 5. It should be possible to authenticate the received data by some - mechanism analogous to those provided by DNSSEC. In this - context, the need could be met by including encryption options in - the specification of a new mechanism. - - 6. The identification mechanism should not be implementation- - specific. - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 6] - -Internet-Draft Serverid March 2006 - - -3. IANA Considerations - - This document proposes no specific IANA action. Protocol extensions, - if any, to meet the requirements described are out of scope for this - document. A proposed extension, specified and adopted by normal IETF - process, is described in [NSID], including relevant IANA action. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 7] - -Internet-Draft Serverid March 2006 - - -4. Security Considerations - - Providing identifying information as to which server is responding to - a particular query from a particular location in the Internet can be - seen as information leakage and thus a security risk. This motivates - the suggestion above that a new mechanism for server identification - allow the administrator to disable the functionality altogether or - partially restrict availability of the data. It also suggests that - the serverid data should not be readily correlated with a hostname or - unicast IP address that may be considered private to the nameserver - operator's management infrastructure. - - Propagation of protocol or service meta-data can sometimes expose the - application to denial of service or other attack. As DNS is a - critically important infrastructure service for the production - Internet, extra care needs to be taken against this risk for - designers, implementors, and operators of a new mechanism for server - identification. - - Both authentication and confidentiality of serverid data are - potentially of interest to administrators-- that is, operators may - wish to make serverid data available and reliable to themselves and - their chosen associates only. This would imply both an ability to - authenticate it to themselves and keep it private from arbitrary - other parties. This led to Characteristics 4 and 5 of an improved - solution. - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 8] - -Internet-Draft Serverid March 2006 - - -5. Acknowledgements - - The technique for host identification documented here was initially - implemented by Paul Vixie of the Internet Software Consortium in the - Berkeley Internet Name Daemon package. Comments and questions on - earlier drafts were provided by Bob Halley, Brian Wellington, Andreas - Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the - ICANN Root Server System Advisory Committee. The newest version - takes a significantly different direction from previous versions, - owing to discussion among contributors to the DNSOP working group and - others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam - Weiler, and Rob Austein. - -6. References - - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", - RFC 1034, STD 0013, November 1987. - - [2] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, STD 0013, November 1987. - - [3] Hardie, T., "Distributing Authoritative Name Servers via Shared - Unicast Addresses", RFC 3258, April 2002. - - [4] ISC, "BIND 9 Configuration Reference". - - [5] Austein, S., "DNS Name Server Identifier Option (NSID)", - Internet Drafts http://www.ietf.org/internet-drafts/ - draft-ietf-dnsext-nsid-01.txt, January 2006. - - [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 9] - -Internet-Draft Serverid March 2006 - - -Authors' Addresses - - Suzanne Woolf - Internet Systems Consortium, Inc. - 950 Charter Street - Redwood City, CA 94063 - US - - Phone: +1 650 423-1333 - Email: woolf@isc.org - URI: http://www.isc.org/ - - - David Conrad - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - US - - Phone: +1 1 650 381 6003 - Email: david.conrad@nominum.com - URI: http://www.nominum.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 10] - -Internet-Draft Serverid March 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Woolf & Conrad Expires September 6, 2006 [Page 11] - - diff --git a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt deleted file mode 100644 index 3353b3bb..00000000 --- a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt +++ /dev/null @@ -1,1588 +0,0 @@ - - Mark Foster -Internet Draft Tom McGarry -Document: <draft-ietf-enum-e164-gstn-np-05.txt> James Yu - NeuStar, Inc. -Category: Informational June 24, 2002 - - - Number Portability in the GSTN: An Overview - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [RFC]. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. Internet-Drafts are draft documents valid for a maximum of - six months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet- Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - Copyright Notice - - Copyright (C) The Internet Society (2002). All rights reserved. - - - Abstract - - This document provides an overview of E.164 telephone number - portability (NP) in the Global Switched Telephone Network (GSTN). - NP is a regulatory imperative seeking to liberalize local telephony - service competition, by enabling end-users to retain telephone - numbers while changing service providers. NP changes the - fundamental nature of a dialed E.164 number from a hierarchical - physical routing address to a virtual address, thereby requiring the - transparent translation of the later to the former. In addition, - there are various regulatory constraints that establish relevant - parameters for NP implementation, most of which are not network - technology specific. Consequently, the implementation of NP - behavior consistent with applicable regulatory constraints, as well - as the need for interoperation with the existing GSTN NP - implementations, are relevant topics for numerous areas of IP - telephony work-in-progress at IETF. - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 1] - -Number Portability in the GSTN: An Overview June 24, 2002 - - - Table of Contents - - 1. Introduction ............................................... 2 - 2. Abbreviations and Acronyms ................................. 4 - 3. Types of Number Portability ................................ 5 - 4. Service Provider Number Portability Schemes ................ 7 - 4.1 All Call Query (ACQ) .................................. 7 - 4.2 Query on Release (QoR) ................................ 8 - 4.3 Call Dropback ......................................... 9 - 4.4 Onward Routing (OR) ................................... 9 - 4.5 Comparisons of the Four Schemes ....................... 10 - 5. Database Queries in the NP Environment ..................... 11 - 5.1 U.S. and Canada ....................................... 12 - 5.2 Europe ................................................ 13 - 6. Call Routing in the NP Environment ......................... 14 - 6.1 U.S. and Canada ....................................... 14 - 6.2 Europe ................................................ 15 - 7. NP Implementations for Geographic E.164 Numbers ............ 17 - 8. Number Conservation Method Enabled By NP ................... 20 - 8.1 Block Pooling ......................................... 20 - 8.2 ITN Pooling ........................................... 21 - 9. Potential Implications ..................................... 21 - 10. Security Considerations .................................... 24 - 11. IANA Considerations ........................................ 24 - 12. Normative References ....................................... 24 - 13. Informative References ..................................... 25 - 14. Acknowledgement ............................................ 25 - 15. AuthorsË Addresses ......................................... 25 - - - -1. Introduction - - This document provides an overview of E.164 telephone number - portability in the Global Switched Telephone Network (GSTN). There - are considered to be three types of number portability (NP): service - provider portability (SPNP), location portability (not to be - confused with terminal mobility), and service portability. - - Service provider portability (SPNP), the focus of the present draft, - is a regulatory imperative in many countries seeking to liberalize - telephony service competition, especially local service. - Historically, local telephony service (as compared to long distance - or international service) has been regulated as a utility-like form - of service. While a number of countries had begun liberalization - (e.g. privatization, de-regulation, or re-regulation) some years - ago, the advent of NP is relatively recent (since ~1995). - - E.164 numbers can be non-geographic and geographic numbers. Non- - geographic numbers do not reveal the locations information of those - numbers. Geographic E.164 numbers were intentionally designed as - hierarchical routing addresses which could systematically be digit- - analyzed to ascertain the country, serving network provider, serving - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 2] - -Number Portability in the GSTN: An Overview June 24, 2002 - - end-office switch, and specific line of the called party. As such, - without NP a subscriber wishing to change service providers would - incur a number change as a consequence of being served off of a - different end-office switch operated by the new service provider. - The cost and convenience impact to the subscriber of changing - numbers is seen as barrier to competition. Hence NP has become - associated with GSTN infrastructure enhancements associated with a - competitive environment driven by regulatory directives. - - Forms of SPNP have been deployed or are being deployed widely in the - GSTN in various parts of the world, including the U.S., Canada, - Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). - Other regions, such as South America (e.g. Brazil) are actively - considering it. - - Implementation of NP within a national telephony infrastructure - entails potentially significant changes to numbering administration, - network element signaling, call routing and processing, billing, - service management, and other functions. - - NP changes the fundamental nature of a dialed E.164 number from a - hierarchical physical routing address to a virtual address. NP - implementations attempt to encapsulate the impacts to the GSTN and - make NP transparent to subscribers by incorporating a translation - function to map a dialed, potentially ported E.164 address, into a - network routing address (either a number prefix or another E.164 - address) which can be hierarchically routed. - - This is roughly analogous to the use of network address translation - on IP addresses to enable IP address portability by containing the - impact of the address change to the edge of the network and retain - the use of CIDR blocks in the core which can be route aggregated by - the network service provider to the rest of the internet. - - NP bifurcates the historical role of a subscriberËs E.164 address - into two or more data elements (a dialed or virtual address, and a - network routing address) that must be made available to network - elements through an NP translations database, carried by forward - call signaling, and recorded on call detail records. Not only is - call processing and routing affected, but also so is SS7/C7 - messaging. A number of TCAP-based SS7 messaging sets utilize an - E.164 address as an application-level network element address in the - global title address (GTA) field of the SCCP message header. - Consequently, SS7/C7 signaling transfer points (STPs) and gateways - need to be able to perform n-digit global title translation (GTT) to - translate a dialed E.164 address into its network address - counterpart via the NP database. - - In addition, there are various national regulatory constraints that - establish relevant parameters for NP implementation, most of which - are not network technology specific. Consequently, implementations - of NP behavior in IP telephony consistent with applicable regulatory - constraints, as well as the need for interoperation with the - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 3] - -Number Portability in the GSTN: An Overview June 24, 2002 - - existing GSTN NP implementations, are relevant topics for numerous - areas of IP telephony work-in-progress at IETF. - - This document describes three types of number portability and the - four schemes that have been standardized to support SPNP for - geographic E.164 numbersspecifically. Following that, specific - information regarding the call routing and database query - implementations are described for several regions (North American - and Europe) and industries (wireless vs. wireline). The Number - Portability Database (NPDB) interfaces and the call routing schemes - that are used in the North America and Europe are described to show - the variety of standards that may be implemented worldwide. A - glance of the NP implementations worldwide is provided. Number - pooling is briefly discussed to show how NP is being enhanced in the - U.S. to conserve North American area codes. The conclusion briefly - touches the potential impacts of NP on IP & Telecommunications - Interoperability. Appendix A provides some specific technical and - regulatory information on NP in North America. Appendix B describes - the number portability administration process that manages the - number portability database in North America. - - -2. Abbreviations and Acronyms - - ACQ All Call Query - AIN Advanced Intelligent Network - AMPS Advanced Mobile Phone System - ANSI American National Standards Institute - CDMA Code Division Multiple Access - CdPA Called Party Address - CdPN Called Party Number - CH Code Holder - CMIP Common Management Information Protocol - CS1 Capability Set 1 - CS2 Capability Set 2 - DN Directory Number - DNS Domain Name System - ETSI European Technical Standards Institute - FCI Forward Call Indicator - GAP Generic Address Parameter - GMSC Gateway Mobile Services Switching Center or Gateway Mobile - Switching Center - GSM Global System for Mobile Communications - GSTN Global Switched Telephone Network - GW Gateways - HLR Home Location Register - IAM Initial Address Message - IETF Internet Engineering Task Force - ILNP Interim LNP - IN Intelligent Network - INAP Intelligent Network Application Part - INP Interim NP - IP Internet Protocol - IS-41 Interim Standards Number 41 - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 4] - -Number Portability in the GSTN: An Overview June 24, 2002 - - ISDN Integrated Services Digital Network - ISUP ISDN User Part - ITN Individual Telephony Number - ITU International Telecommunication Union - ITU-TS ITU-Telecommunication Sector - LDAP Lightweight Directory Access Protocol - LEC Local Exchange Carrier - LERG Local Exchange Routing Guide - LNP Local Number Portability - LRN Location Routing Number - MAP Mobile Application Part - MNP Mobile Number Portability - MSRN Mobile Station Roaming Number - MTP Message Transfer Part - NANP North American Numbering Plan - NP Number Portability - NPDB Number Portability Database - NRN Network Routing Number - OR Onward Routing - OSS Operation Support System - PCS Personal Communication Services - PNTI Ported Number Translation Indicator - PODP Public Office Dialing Plan - PUC Public Utility Commission - QoR Query on Release - RN Routing Number - RTP Return to Pivot - SCCP Signaling Connection Control Part - SCP Service Control Point - SIP Session Initiation Protocol - SMR Special Mobile Radio - SMS Service Management System - SPNP Service Provider Number Portability - SRF Signaling Relaying Function - SRI Send Routing Information - SS7 Signaling System Number 7 - STP Signaling Transfer Point - TCAP Transaction Capabilities Application Part - TDMA Time Division Multiple Access - TN Telephone Number - TRIP Telephony Routing Information Protocol - URL Universal Resource Locator - U.S. United States - - -3. Types of Number Portability - - As there are several types of E.164 numbers (telephone numbers, or - just TN) in the GSTN, there are correspondingly several types of - E.164 NP in the GSTN. First there are so-call non-geographic E.164 - numbers, commonly used for service-specific applications such as - freephone (800 or 0800). Portability of these numbers is called - non-geographic number portability (NGNP). NGNP, for example, was - deployed in the U.S. in 1986-92. - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 5] - -Number Portability in the GSTN: An Overview June 24, 2002 - - - Geographic number portability, which includes traditional fixed or - wireline numbers as well as mobile numbers which are allocated out - of geographic number range prefixes, is called NP or GNP or in the - U.S. local number portability (LNP). - - Number portability allows the telephony subscribers in the Global - Switched Telephone Network (GSTN) to keep their phone numbers when - they change their service providers or subscribed services, or when - they move to a new location. - - The ability to change the service provider while keeping the same - phone number is called service provider portability (SPNP) also - known as "operator portability." - - The ability to change the subscriberËs fixed service location while - keeping the same phone number is called location portability. - - The ability to change the subscribed services (e.g., from the plain - old telephone service to Integrated Services Digital Network (ISDN) - services) while keeping the same phone number is called service - portability. Another aspect of service portability is to allow the - subscribers to enjoy the subscribed services in the same way when - they roam outside their home networks as is supported by the - cellular/wireless networks. - - In addition, mobile number portability (MNP) refers to specific NP - implementation in mobile networks either as part of a broader NP - implementation in the GSTN or on a stand-alone basis. Where - interoperation of LNP and MNP is supported, service portability - between fixed and mobile service types is possible. - - At present, SPNP has been the primary form of NP deployed due to its - relevance in enabling local service competition. - - Also in use in the GSTN are the terms interim NP (INP) or Interim - LNP (ILNP) and true NP. Interim NP usually refers to the use of - remote call forwarding-like measures to forward calls to ported - numbers through the donor network to the new service network. These - are considered interim relative to true NP, which seeks to remove - the donor network or old service provider from the call or signaling - path altogether. Often the distinction between interim and true NP - is a national regulatory matter relative to the - technical/operational requirements imposed on NP in that country. - - Implementations of true NP in certain countries (e.g. U.S., Canada, - Spain, Belgium, Denmark) may pose specific requirements for IP - telephony implementations as a result of regulatory and industry - requirements for providing call routing and signaling independent of - the donor network or last previous serving network. - - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 6] - -Number Portability in the GSTN: An Overview June 24, 2002 - - -4. Service Provider Number Portability Schemes - - Four schemes can be used to support service provider portability and - are briefly described below. But first, some further terms are - introduced. - - The donor network is the network that first assigned a telephone - number (e.g., TN +1-202-533-1234) to a subscriber, out of a number - range administratively (e.g., +1 202-533) assigned to it. The - current service provider (new SP) or new serving network is the - network that currently serves the ported number. The old serving - network (or old SP) is the network that previously served the ported - number before the number was ported to the new serving network. - Since a TN can port a number of times, the old SP is not necessarily - the same as the donor network, except for the first time the TN - ports away, or if the TN ports back into the donor network and away - again. While the new SP and old SP roles are transitory as a TN - ports around, the donor network is always the same for any - particular TN based on the service provider to whom the subtending - number range was administratively assigned. See the discussion - below on number pooling, as this enhancement to NP further - bifurcates the role of donor network into two (the number range or - code holder network, and the block holder network). - - To simplify the illustration, all the transit networks are ignored, - the originating or donor network is the one that performs the - database queries or call redirection, and the dialed directory - number (TN) has been ported out of the donor network before. - - It is assumed that the old serving network, the new serving network - and the donor network are different networks so as to show which - networks are involved in call handling and routing and database - queries in each of four schemes. Please note that the port of the - number (process of moving it from one network to another) happened - prior to the call setup and is not included in the call steps. - Information carried in the signaling messages to support each of the - four schemes is not discussed to simplify the explanation. - - -4.1 All Call Query (ACQ) - - Figure 1 shows the call steps for the ACQ scheme. Those call steps - are as follows: - - (1) The Originating Network receives a call from the caller and - sends a query to a centrally administered Number Portability - Database (NPDB), a copy of which is usually resident on a - network element within its network or through a third party - provider. - (2) The NPDB returns the routing number associated with the dialed - directory number. The routing number is discussed later in - Section 6. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 7] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (3) The Originating Network uses the routing number to route the - call to the new serving network. - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | ported | Old Serv. | - | NPDB | +-------->| Network |<------------| Network | - +-------------+ | +-----------+ +-----------+ - ^ | | - | | | - 1| | 3.| - | | 2. | - | | | - | v | - +----------+ | +----------+ +----------+ - | Orig. |------+ | Donor | | Internal | - | Network | | Network | | NPDB | - +----------+ +----------+ +----------+ - - - Figure 1 - All Call Query (ACQ) Scheme. - - -4.2 Query on Release (QoR) - - Figure 2 shows the call steps for the QoR scheme. Those call steps - are as follows: - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | ported | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - ^ | ^ - | | 4. | - 3.| | 5. | - | | +----------------------+ - | | | - | v | - +----------+ 2. +----------+ +----------+ - | Orig. |<---------------| Donor | | Internal | - | Network |--------------->| Network | | NPDB | - +----------+ 1. +----------+ +----------+ - - - Figure 2 - Query on Release (QoR) Scheme. - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network releases the call and indicates that the - dialed directory number has been ported out of that switch. - (3) The Originating Network sends a query to its copy of the - centrally administered NPDB. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 8] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (4) The NPDB returns the routing number associated with the dialed - directory number. - (5) The Originating Network uses the routing number to route the - call to the new serving network. - - -4.3 Call Dropback - - Figure 3 shows the call steps for the Dropback scheme. This scheme - is also known as "Return to Pivot (RTP)." Those call steps are as - follows: - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network detects that the dialed directory number has - been ported out of the donor switch and checks with an internal - network-specific NPDB. - (3) The internal NPDB returns the routing number associated with the - dialed directory number. - (4) The donor network releases the call by providing the routing - number. - (5) The Originating Network uses the routing number to route the - call to the new serving network. - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | porting | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - /\ - | - 5. | - +------------------------+ - | - | - +----------+ 4. +----------+ 3. +----------+ - | Orig. |<---------------| Donor |<----------| Internal | - | Network |--------------->| Network |---------->| NPDB | - +----------+ 1. +----------+ 2. +----------+ - - - Figure 3 - Dropback Scheme. - - -4.4 Onward Routing (OR) - - Figure 4 shows the call steps for the OR scheme. Those call steps - are as follows: - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network detects that the dialed directory number has - been ported out of the donor switch and checks with an internal - network-specific NPDB. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 9] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (3) The internal NPDB returns the routing number associated with the - dialed directory number. - (4) The donor network uses the routing number to route the call to - the new serving network. - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | porting | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - /\ - | - 4.| - | - +----------+ +----------+ 3. +----------+ - | Orig. | | Donor |<----------| Internal | - | Network |--------------->| Network |---------->| NPDB | - +----------+ 1. +----------+ 2. +----------+ - - - Figure 4 - Onward Routing (OR) Scheme. - -4.5 Comparisons of the Four Schemes - - Only the ACQ scheme does not involve the donor network when routing - the call to the new serving network of the dialed ported number. - The other three schemes involve call setup to or signaling with the - donor network. - - Only the OR scheme requires the setup of two physical call segments, - one from the Originating Network to the donor network and the other - from the donor network to the new serving network. The OR scheme is - the least efficient in terms of using the network transmission - facilities. The QoR and Dropback schemes set up calls to the donor - network first but release the call back to the Originating Network - that then initiates a new call to the Current Serving Network. For - the QoR and Dropback schemes, circuits are still reserved one by one - between the Originating Network and the donor network when the - Originating Network sets up the call towards the donor network. - Those circuits are released one by one when the call is released - from the donor network back to the Originating Network. The ACQ - scheme is the most efficient in terms of using the switching and - transmission facilities for the call. - - Both the ACQ and QoR schemes involve Centralized NPDBs for the - Originating Network to retrieve the routing information. - Centralized NPDB means that the NPDB contains ported number - information from multiple networks. This is in contrast to the - internal network-specific NPDB that is used for the Dropback and OR - schemes. The internal NPDB only contains information about the - numbers that were ported out of the donor network. The internal - NPDB can be a stand-alone database that contains information about - all or some ported-out numbers from the donor network. It can also - reside on the donor switch and only contains information about those - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 10] - -Number Portability in the GSTN: An Overview June 24, 2002 - - numbers ported out of the donor switch. In that case, no query to a - stand-alone internal NPDB is required. The donor switch for a - particular phone number is the switch to which the number range is - assigned from which that phone number was originally assigned. - - For example, number ranges in the North American Numbering Plan - (NANP) are usually assigned in the form of central office codes (CO - codes) comprising a six-digit prefix formatted as a NPA+NXX. Thus a - switch serving +1-202-533 would typically serve +1-202-533-0000 - through +1-202-533-9999. In major cities, switches usually host - several CO codes. NPA stands for Numbering Plan Area that is also - known as the area code. It is three-digit long and has the format - of NXX where N is any digit from 2 to 9 and X is any digit from 0 to - 9. NXX in the NPA+NXX format is known as the office code that has - the same format as the NPA. When a NPA+NXX code is set as - Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a - "portable NPA+NXX" code. - - Similarly, in other national E.164 numbering plans, number ranges - cover a contiguous range of numbers within that range. Once a - number within that range has ported away from the donor network, all - numbers in that range are considered potentially ported and should - be queried in the NPDB. - - The ACQ scheme has two versions. One version is for the Originating - Network to always query the NPDB when a call is received from the - caller regardless whether the dialed directory number belongs to any - number range that is portable or has at least one number ported out. - The other version is to check whether the dialed directory number - belongs to any number range that is portable or has at least one - number ported out. If yes, an NPDB query is sent. If not, no NPDB - query is sent. The former performs better when there are many - portable number ranges. The latter performs better when there are - not too many portable number ranges at the expense of checking every - call to see whether NPDB query is needed. The latter ACQ scheme is - similar to the QoR scheme except that the QoR scheme uses call setup - and relies on the donor network to indicate "number ported out" - before launching the NPDB query. - - -5. Database Queries in the NP Environment - - As indicated earlier, the ACQ and QoR schemes require that a switch - query the NPDB for routing information. Various standards have been - defined for the switch-to-NPDB interface. Those interfaces with - their protocol stacks are briefly described below. The term "NPDB" - is used for a stand-alone database that may support just one or some - or all of the interfaces mentioned below. The NPDB query contains - the dialed directory number and the NPDB response contains the - routing number. There are certainly other information that is sent - in the query and response. The primary interest is to get the - routing number from the NPDB to the switch for call routing. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 11] - -Number Portability in the GSTN: An Overview June 24, 2002 - -5.1 U.S. and Canada - - One of the following five NPDB interfaces can be used to query an - NPDB: - - (a) Advanced Intelligent Network (AIN) using the American National - Standards Institute (ANSI) version of the Intelligent Network - Application Part (INAP) [ANSI SS] [ANSI DB]. The INAP is - carried on top of the protocol stack that includes the (ANSI) - Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling - Connection Control Part (SCCP), and ANSI Transaction - Capabilities Application Part (TCAP). This interface can be - used by the wireline or wireless switches, is specific to the NP - implementation in North America, and is modeled on the Public - Office Dialing Plan (PODP) trigger defined in the Advanced - Intelligent Network (AIN) 0.1 call model. - - (b) Intelligent Network (IN), which is similar to the one used for - querying the 800 databases. The IN protocol is carried on top - of the protocol stack that includes the ANSI MTP Levels 1 - through 3, ANSI SCCP, and ANSI TCAP. This interface can be used - by the wireline or wireless switches. - - (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the - protocol stack that includes the ANSI MTP Levels 1 through 3, - ANSI SCCP, and ANSI TCAP. This interface can be used by the IS- - 41 based cellular/Personal Communication Services (PCS) wireless - switches (e.g., AMPS, TDMA and CDMA). Cellular systems use - spectrum at 800 MHz range and PCS systems use spectrum at 1900 - MHz range. - - (d) Global System for Mobile Communication Mobile Application Part - (GSM MAP) [GSM], which is carried on top of the protocol stack - that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and - International Telecommunication Union - Telecommunication Sector - (ITU-TS) TCAP. It can be used by the PCS1900 wireless switches - that are based on the GSM technologies. GSM is a series of - wireless standards defined by the European Telecommunications - Standards Institute (ETSI). - - (e) ISUP triggerless translation. NP translations are performed - transparently to the switching network by the signaling network - (e.g. Signaling Transfer Points (STPs) or signaling gateways). - ISUP IAM messages are examined to determine if the CdPN field - has already been translated, and if not, an NPDB query is - performed, and the appropriate parameters in the IAM message - modified to reflect the results of the translation. The - modified IAM message is forwarded by the signaling node on to - the designated DPC in a transparent manner to continue call - setup. The NPDB can be integrated with the signaling node or be - accessed via an API locally or by a query to a remote NPDB using - a proprietary protocol or the schemes described above. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 12] - -Number Portability in the GSTN: An Overview June 24, 2002 - - Wireline switches have the choice of using either (a), (b), or (e). - IS-41 based wireless switches have the choice of using (a), (b), - (c), or (e). PCS1900 wireless switches have the choice of using - (a), (b), (d), or (e). In the United States, service provider - portability will be supported by both the wireline and wireless - systems, not only within the wireline or wireless domain but also - across the wireline/wireless boundary. However, this is not true in - Europe where service provider portability is usually supported only - within the wireline or wireless domain, not across the - wireline/wireless boundary due to explicit use of service-specific - number range prefixes. The reason is to avoid caller confusion - about the call charge. GSM systems in Europe are assigned - distinctive destination network codes, and the caller pays a higher - charge when calling a GSM directory number. - - -5.2 Europe - - One of the following two interfaces can be used to query an NPDB: - - (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is - carried on top of the protocol stack that includes the ITU-TS - MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. - - (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is - carried on top of the protocol stack that includes the ITU-TS - MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, - and ITU-TS TCAP. - - Wireline switches have the choice of using either (a) or (b); - however, all the implementations in Europe so far are based on CS1. - As indicated earlier that number portability in Europe does not go - across the wireline/wireless boundary. The wireless switches can - also use (a) or (b) to query the NPDBs if those NPDBs contains - ported wireless directory numbers. The term "Mobile Number - Portability (MNP)" is used for the support of service provider - portability by the GSM networks in Europe. - - In most, if not all, cases in Europe, the calls to the wireless - directory numbers are routed to the wireless donor network first. - Over there, an internal NPDB is queried to determine whether the - dialed wireless directory number has been ported out or not. In - this case, the interface to the internal NPDB is not subject to - standardization. - - MNP in Europe can also be supported via MNP Signaling Relay Function - (MNP-SRF). Again, an internal NPDB or a database integrated at the - MNP-SRF is used to modify the SCCP Called Party Address parameter in - the GSM MAP messages so that they can be re-directed to the wireless - serving network. Call routing involving MNP will be explained in - Section 6.2. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 13] - -Number Portability in the GSTN: An Overview June 24, 2002 - -6. Call Routing in the NP Environment - - This section discusses the call routing after the routing - information has been retrieved either through an NPDB query or an - internal database lookup at the donor switch, or from the Integrated - Services Digital Network User Part (ISUP) signaling message (e.g., - for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it - is the Originating Network that has the routing information and is - ready to route the call. For the OR scheme, it is the donor network - that has the routing information and is ready to route the call. - - A number of triggering schemes may be employed that determine where - in the call path the NPDB query is performed. In the U.S. an ŸN-1÷ - policy is used, which essentially says that for domestic calls, the - originating local carriers performs the query, otherwise, the long - distance carrier is expected to. To ensure independence of the - actual trigger policy employed in any one carrier, forward call - signaling is used to flag that an NPDB query has already been - performed and to therefore suppress any subsequent NP triggers that - may be encountered in downstream switches, in downstream networks. - This allows the earliest able network in the call path to perform - the query without introducing additional costs and call setup delays - were redundant queries performed downstream. - - -6.1 U.S. and Canada - - In the U.S. and Canada, a ten-digit North American Numbering Plan - (NANP) number called Location Routing Number (LRN) is assigned to - every switch involved in NP. In the NANP, a switch is not reachable - unless it has a unique number range (CO code) assigned to it. - Consequently, the LRN for a switch is always assigned out of a CO - code that is assigned to that switch. - - The LRN assigned to a switch currently serving a particular ported - telephone number is returned as the network routing address in the - NPDB response. The service portability scheme that was adopted in - the North America is very often referred to as the LRN scheme or - method. - - LRN serves as a network address for terminating calls served off - that switch using ported numbers. The LRN is assigned by the switch - operator using any of the unique CO codes (NPA+NXX) assigned to that - switch. The LRN is considered a non-dialable address, as the same - 10-digit number value may be assigned to a line on that switch. A - switch may have more than one LRN. - - During call routing/processing, a switch performs an NPDB query to - obtain the LRN associated with the dialed directory number. NPDB - queries are performed for all the dialed directory numbers whose - NPA+NXX codes are marked as portable NPA+NXX at that switch. When - formulating the ISUP Initial Address Message (IAM) to be sent to the - next switch, the switch puts the ten-digit LRN in the ISUP Called - Party Number (CdPN) parameter and the originally dialed directory - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 14] - -Number Portability in the GSTN: An Overview June 24, 2002 - - number in the ISUP Generic Address parameter (GAP). A new code in - the GAP was defined to indicate that the address information in the - GAP is the dialed directory number. A new bit in the ISUP Forward - Call Indicator (FCI) parameter, the Ported Number Translation - Indicator (PNTI) bit, is set to imply that NPDB query has already - been performed. All the switches in the downstream will not perform - the NPDB query if the PNTI bit is set. - - When the terminating switch receives the IAM and sees the PNTI bit - in the FCI parameter set and its own LRN in the CdPN parameter, it - retrieves the originally dialed directory number from the GAP and - uses the dialed directory number to terminate the call. - - A dialed directory number with a portable NPA+NXX does not imply - that directory number has been ported. The NPDBs currently do not - store records for non-ported directory numbers. In that case, the - NPDB will return the same dialed directory number instead of the - LRN. The switch will then set the PNTI bit but keep the dialed - directory number in the CdPN parameter. - - In the real world environment, the Originating Network is not always - the one that performs the NPDB query. For example, it is usually - the long distance carriers that query the NPDBs for long distance - calls. In that case, the Originating Network operated by the local - exchange carrier (LEC) simply routes the call to the long distance - carrier that is to handle that call. A wireless network acting as - the Originating Network can also route the call to the - interconnected local exchange carrier network if it does not want to - support the NPDB interface at its mobile switches. - - -6.2 Europe - - In some European countries, a routing number is prefixed to the - dialed directory number. The ISUP CdPN parameter in the IAM will - contain the routing prefix and the dialed directory number. For - example, United Kingdom uses routing prefixes with the format of - 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks - use the information in the ISUP CdPN parameter to route the call to - the New/Current Serving Network. - - The routing prefix can identify the Current Serving Network or the - Current Serving Switch of a ported number. For the former case, - another query to the "internal" NPDB at the Current Serving Network - is required to identify the Current Serving Switch before routing - the call to that switch. This shields the Current Serving Switch - information for a ported number from the other networks at the - expense of an additional NPDB query. Another routing number, may be - meaningful within the Current Serving Network, will replace the - previously prefixed routing number in the ISUP CdPN parameter. For - the latter case, the call is routed to the Current Serving Switch - without an additional NPDB query. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 15] - -Number Portability in the GSTN: An Overview June 24, 2002 - - When the terminating switch receives the IAM and sees its own - routing prefix in the CdPN parameter, it retrieves the originally - dialed directory number after the routing prefix, and uses the - dialed directory number to terminate the call. - - The call routing example described above shows one of the three - methods that can be used to transport the Directory Number (DN) and - the Routing Number (RN) in the ISUP IAM message. In addition, some - other information may be added/modified as is listed in the ETSI 302 - 097 document [ETSIISUP], which is based on the ITU-T Recommendation - Q.769.1 [ITUISUP]. The three methods and the enhancements in the - ISUP to support number portability are briefly described below - - (a) Two separate parameters with the CdPN parameter containing the - RN and a new Called Directory Number (CdDN) parameter containing - the DN. A new value for the Nature of Address (NOA) indicator in - the CdPN parameter is defined to indicate that the RN is in the - CdPN parameter. The switches use the CdPN parameter to route the - call as is done today. - - (b) Two separate parameters with the CdPN parameter containing the - DN and a new Network Routing Number (NRN) parameter containing - the RN. This method requires that the switches use the NRN - parameter to route the call. - - (c) Concatenated parameter with the CdPN parameter containing the RN - plus the DN. A new Nature of Address (NOA) indicator in the CdPN - parameter is defined to indicate that the RN is concatenated with - the DN in the CdPN parameter. Some countries may not use new NOA - value because the routing prefix does not overlap with the dialed - directory numbers. But if the routing prefix overlaps with the - dialed directory numbers, a new NOA value must be assigned. For - example, Spain uses "XXXXXX" as the routing prefix to identify - the new serving network and uses a new NOA value of 126. - - There is also a network option to add a new ISUP parameter called - Number Portability Forwarding Information parameter. This parameter - has a four-bit Number Portability Status Indicator field that can - provide an indication whether number portability query is done for - the called directory number and whether the called directory number - is ported or not if the number portability query is done. - - Please note that all those NP enhancements for a ported number can - only be used in the country that defined them. This is because - number portability is supported within a nation. Within each - nation, the telecommunications industry or the regulatory bodies can - decide which method or methods to use. Number portability related - parameters and coding are usually not passed across the national - boundaries unless the interconnection agreements allow that. For - example, a UK routing prefix can only be used in UK, and would cause - routing problem if it appears outside UK. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 16] - -Number Portability in the GSTN: An Overview June 24, 2002 - - As indicated earlier, an originating wireless network can query the - NPDB and concatenate the RN with DN in the CdPN parameter and route - the call directly to the Current Serving Network. - - If NPDBs do not contain information about the wireless directory - numbers, the call, originated from either a wireline or a wireless - network, will be routed to the Wireless donor network. Over there, - an internal NPDB is queried to retrieve the RN that then is - concatenated with the DN in the CdPN parameter. - - There are several ways of realizing MNP. When MNP-SRF is supported, - the Gateway Mobile Services Switching Center (GMSC) at the wireless - donor network, when receiving a call from the wireline network, can - send the GSM MAP Send Routing Information (SRI) message to the MNP- - SRF. The MNP-SRF interrogates an internal or integrated NPDB for - the RN of the MNP-SRF of the wireless Current Serving Network and - prefixes the RN to the dialed wireless directory number in the - global title address information in the SCCP Called Party Address - (CdPA) parameter. This SRI message will be routed to the MNP-SRF of - the wireless Current Serving Network, which then responds with an - acknowledgement by providing the RN plus the dialed wireless - directory number as the Mobile Station Roaming Number (MSRN). The - GMSC of the wireless donor network formulates the ISUP IAM with the - RN plus the dialed wireless directory number in the CdPN parameter - and routes the call to the wireless Current Serving Network. A GMSC - of the wireless Current Serving Network receives the call and sends - an SRI message to the associated MNP-SRF where the global title - address information of the SCCP CdPA parameter contains only the - dialed wireless directory number. The MNP-SRF then replaces the - global title address information in the SCCP CdPA parameter with the - address information associated with a Home Location Register (HLR) - that hosts the dialed wireless directory number and forwards the - message to that HLR after verifying that the dialed wireless - directory number is a ported-in number. The HLR then returns an - acknowledgement by providing an MSRN for the GMSC to route the call - to the MSC that currently serves the mobile station that is - associated with the dialed wireless directory number. Please see - [MNP] for details and additional scenarios. - - -7. NP Implementations for Geographic E.164 Numbers - - This section shows the known SPNP implementations worldwide. - - +-------------+----------------------------------------------------+ - + Country + SPNP Implementation + - +-------------+----------------------------------------------------+ - + Argentina + Analyzing operative viability now. Will determine + - + + whether portability should be made obligatory + - + + after a technical solution has been determined. + - +-------------+----------------------------------------------------+ - + Australia + NP supported by wireline operators since 11/30/99. + - + + NP among wireless operators in March/April 2000, + - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 17] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + but may be delayed to 1Q01. The access provider + - + + or long distance provider has the obligation to + - + + route the call to the correct destination. The + - + + donor network is obligated to maintain and make + - + + available a register of numbers ported away from + - + + its network. Telstra uses onward routing via an + - + + on-switch solution. + - +-------------+----------------------------------------------------+ - + Austria + Uses onward routing at the donor network. Routing + - + + prefix is "86xx" where "xx" identifies the + - + + recipient network. + - +-------------+----------------------------------------------------+ - + Belgium + ACQ selected by the industry. Routing prefix is + - + + "Cxxxx" where "xxxx" identifies the recipient + - + + switch. Another routing prefix is "C00xx" with "xx"+ - + + identifying the recipient network. Plan to use NOA+ - + + to identify concatenated numbers and abandon the + - + + hexadecimal routing prefix. + - +-------------+----------------------------------------------------+ - + Brazil + Considering NP for wireless users. + - +-------------+----------------------------------------------------+ - + Chile + There has been discussions lately on NP. + - +-------------+----------------------------------------------------+ - + Colombia + There was an Article 3.1 on NP to support NP prior + - + + to December 31, 1999 when NP became technically + - + + possible. Regulator has not yet issued regulations + - + + concerning this matter. + - +-------------+----------------------------------------------------+ - + Denmark + Uses ACQ. Routing number not passed between + - + + operators; however, NOA is set to "112" to + - + + indicate "ported number." QoR can be used based + - + + on bilateral agreements. + - +-------------+----------------------------------------------------+ - + Finland + Uses ACQ. Routing prefix is "1Dxxy" where "xxy" + - + + identifies the recipient network and service type. + - +-------------+----------------------------------------------------+ - + France + Uses onward routing. Routing prefix is "Z0xxx" + - + + where "xxx" identifies the recipient switch. + - +-------------+----------------------------------------------------+ - + Germany + The originating network needs to do necessary + - + + rerouting. Operators decide their own solution(s).+ - + + Deutsche Telekom uses ACQ. Routing prefix is + - + + "Dxxx" where "xxx" identifies the recipient + - + + network. + - +-------------+----------------------------------------------------+ - + Hong Kong + Recipient network informs other networks about + - + + ported-in numbers. Routing prefix is "14x" where + - + + "14x" identifies the recipient network, or a + - + + routing number of "4x" plus 7 or 8 digits is used + - + + where "4x" identifies the recipient network and + - + + the rest of digits identify the called party. + - +-------------+----------------------------------------------------+ - + Ireland + Operators choose their own solution but use onward + - + + routing now. Routing prefix is "1750" as the intra-+ - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 18] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + network routing code (network-specific) and + - + + "1752xxx" to "1759xxx" for GNP where "xxx" + - + + identifies the recipient switch. + - +-------------+----------------------------------------------------+ - + Italy + Uses onward routing. Routing prefix is "C600xxxxx" + - + + where "xxxxx" identifies the recipient switch. + - + + Telecom Italia uses IN solution and other operators+ - + + use on-switch solution. + - +-------------+----------------------------------------------------+ - + Japan + Uses onward routing. Donor switch uses IN to get + - + + routing number. + - +-------------+----------------------------------------------------+ - + Mexico + NP is considered in the Telecom law; however, the + - + + regulator (Cofetel) or the new local entrants have + - + + started no initiatives on this process. + - +-------------+----------------------------------------------------+ - + Netherlands + Operators decide NP scheme to use. Operators have + - + + chosen ACQ or QoR. KPN implemented IN solution + - + + similar to U.S. solution. Routing prefix is not + - + + passed between operators. + - +-------------+----------------------------------------------------+ - + Norway + OR for short-term and ACQ for long-term. QoR is + - + + optional. Routing prefix can be "xxx" with NOA=8, + - + + or "142xx" with NOA=3 where "xxx" or "xx" + - + + identifies the recipient network. + - +------------ +----------------------------------------------------+ - + Peru + Wireline NP may be supported in 2001. + - +-------------+----------------------------------------------------+ - + Portugal + No NP today. + - +-------------+----------------------------------------------------+ - + Spain + Uses ACQ. Telefonica uses QoR within its network. + - + + Routing prefix is "xxyyzz" where "xxyyzz" + - + + identifies the recipient network. NOA is set to + - + + 126. + - +-------------+----------------------------------------------------+ - + Sweden + Standardized the ACQ but OR for operators without + - + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + - + + with NOA=3 where "xxx" identifies the recipient + - + + network. But operators decide NP scheme to use. + - + + Telia uses onward routing between operators. + - +-------------+----------------------------------------------------+ - + Switzerland + Uses OR now and QoR in 2001. Routing prefix is + - + + "980xxx" where "xxx" identifies the recipient + - + + network. + - +-------------+----------------------------------------------------+ - + UK + Uses onward routing. Routing prefix is "5xxxxx" + - + + where "xxxxx" identifies the recipient switch. NOA + - + + is 126. BT uses the dropback scheme in some parts + - + + of its network. + - +-------------+----------------------------------------------------+ - + US + Uses ACQ. "Location Routing Number (LRN)" is used + - + + in the Called Party Number parameter. Called party+ - + + number is carried in the Generic Address Parameter + - + + Use a PNTI indicator in the Forward Call Indicator + - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 19] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + parameter to indicate that NPDB dip has been + - + + performed. + - +-------------+----------------------------------------------------+ - - -8. Number Conservation Methods Enabled by NP - - In addition to porting numbers NP provides the ability for number - administrators to assign numbering resources to operators in smaller - increments. Today it is common for numbering resources to be - assigned to telephone operators in a large block of consecutive - telephone numbers (TNs). For example, in North America each of - these blocks contains 10,000 TNs and is of the format NXX+0000 to - NXX+9999. Operators are assigned a specific NXX, or block. That - operator is referred to as the block holder. In that block there - are 10,000 TNs with line numbers ranging from 0000 to 9999. - - Instead of assigning an entire block to the operator NP allows the - administrator to assign a sub-block or even an individual telephone - number. This is referred to as block pooling and individual - telephone number (ITN) pooling, respectively. - - -8.1 Block Pooling - - Block Pooling refers to the process whereby the number administrator - assigns a range of numbers defined by a logical sub-block of the - existing block. Using North America as an example, block pooling - would allow the administrator to assign sub-blocks of 1,000 TNs to - multiple operators. That is, NXX+0000 to NXX+0999 can be assigned - to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, - NXX-2000 to 2999 can be assigned to operator C, etc. In this - example block pooling divides one block of 10,000 TNs into ten - blocks of 1,000 TNs. - - Porting the sub-blocks from the block holder enables block pooling. - Using the example above operator A is the block holder, as well as, - the holder of the first sub-block, NXX+0000 to NXX+0999. The second - sub-block, NXX+1000 to NXX+1999, is ported from operator A to - operator B. The third sub-block, NXX+2000 to NXX+2999, is ported - from operator A to operator C, and so on. NP administrative - processes and call processing will enable proper and efficient - routing. - - From a number administration and NP administration perspective block - pooling introduces a new concept, that of the sub-block holder. - Block pooling requires coordination between the number - administrator, the NP administrator, the block holder, and the sub- - block holder. Block pooling must be implemented in a manner that - allows for NP within the sub-blocks. Each TN can have a different - serving operator, sub-block holder, and block holder. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 20] - -Number Portability in the GSTN: An Overview June 24, 2002 - -8.2 ITN Pooling - - ITN pooling refers to the process whereby the number administrator - assigns individual telephone numbers to operators. Using the North - American example, one block of 10,000 TNs can be divided into 10,000 - ITNs. ITN is more commonly deployed in freephone services. - - In ITN the block is not assigned to an operator but to a central - administrator. The administrator then assigns ITNs to operators. - NP administrative processes and call processing will enable proper - and efficient routing. - - -9. Potential Implications - - There are three general areas of impact to IP telephony work-in- - progress at IETF: - - - Interoperation between NP in GSTN and IP telephony - - NP implementation or emulation in IP telephony - - Interconnection to NP administrative environment - - A good understanding of how number portability is supported in the - GSTN is important when addressing the interworking issues between - IP-based networks and the GSTN. This is especially important when - the IP-based network needs to route the calls to the GSTN. As shown - in Section 5, there are a variety of standards with various protocol - stacks for the switch-to-NPDB interface. Not only that, the - national variations of the protocol standards make it very - complicated to deal with in a global environment. If an entity in - the IP-based network needs to query those existing NPDBs for routing - number information to terminate the calls to the destination GSTN, - it would be impractical, if not an impossible, job for that entity - to support all those interface standards to access the NPDBs in many - countries. - - Several alternatives may address this particular problem. One - alternative is to use certain entities in the IP-based networks for - dealing with NP query, similar to the International Switches that - are used in the GSTN to interwork different national ISUP - variations. This will force signaling information associated with - the calls to certain NP-capable networks in the terminating GSTN to - be routed to those IP entities that support the NP functions. Those - IP entities then query the NPDBs in the terminating country. This - will limit the number of NPDB interfaces that certain IP entities - need to support. Another alternative can be to define a "common" - interface to be supported by all the NPDBs so that all the IP - entities use that standardized protocol to query them. The - existing NPDBs can support this additional interface, or new NPDBs - can be deployed that contain the same information but support the - common IP interface. The candidates for such a common interface - include Lightweight Directory Access Protocol (LDAP) and SIP - [SIP](e.g., using the SIP redirection capability). Certainly - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 21] - -Number Portability in the GSTN: An Overview June 24, 2002 - - another possibility is to use interworking function to convert from - one protocol to another. - - IP-based networks can handle the domestic calls between two GSTNs. - If the originating GSTN has performed NPDB query, SIP will need to - transport and make use of some of the ISUP signaling information - even if ISUP signaling may be encapsulated in SIP. Also, IP-based - networks may perform the NPDB queries, as the N-1 carrier. In that - case, SIP also needs to transport the NP related information while - the call is being routed to the destination GSTN. There are three - pieces of NP related information that SIP needs to transport. They - are 1) the called directory number, 2) a routing number, and 3) a - NPDB dip indicator. The NPDB dip indicator is needed so that the - terminating GSTN will not perform another NPDB dip. The routing - number is needed so that it is used to route the call to the - destination network or switch in the destination GSTN. The called - directory number is needed so that the terminating GSTN switch can - terminate the call. When the routing number is present, the NPDB - dip indicator may not be present because there are cases where - routing number is added for routing the call even if NP is not - involved. One issue is how to transport the NP related information - via SIP. The SIP Universal Resource Locator (URL) is one mechanism. - Another better choice may be to add an extension to the "tel" URL - [TEL] that is also supported by SIP. Please see [TELNP] for the - proposed extensions to the "tel" URL to support NP and freephone - service. Those extensions to the "tel" URL will be automatically - supported by SIP because they can be carried as the optional - parameters in the user portion of the "sip" URL. - - For a called directory number that belongs to a country that - supports NP, and if the IP-based network is to perform the NPDB - query, the logical step is to perform the NPDB dip first to retrieve - the routing number and use that routing number to select the correct - IP telephony gateways that can reach the serving switch that serves - the called directory number. Therefore, if the "rn" parameter is - present in the "tel" URL or sip URL in the SIP INVITE message, it - instead of the called directory number should be used for making - routing decisions assuming that no other higher priority routing- - related parameters such as the Ÿcic÷ are present. If "rn" is not - present, then the dialed directory number can be used as the routing - number for making routing decisions. - - Telephony Routing Information Protocol (TRIP) [TRIP] is a policy - driven inter-administrative domain protocol for advertising the - reachability of telephony destinations between location servers, and - for advertising attributes of the routes to those destinations. - With the NP in mind, it is very important to know that it is the - routing number, if present, not the called directory number that - should be used to check against the TRIP tables for making the - routing decisions. - - Overlap signaling exists in the GSTN today. For a call routing from - the originating GSTN to the IP-based network that involves overlap - signaling, NP will impact the call processing within the IP-based - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 22] - -Number Portability in the GSTN: An Overview June 24, 2002 - - networks if they must deal with the overlap signaling. The entities - in the IP-based networks that are to retrieve the NP information - (e.g., the routing number) must collect a complete called directory - number information before retrieving the NP information for a ported - number. Otherwise, the information retrieval won't be successful. - This is an issue for the IP-based networks if the originating GSTN - does not handle the overlap signaling by collecting the complete - called directory number. - - The IETF enum working group is defining the use of Domain Name - System (DNS) for identifying available services associated with a - particular E.164 number [ENUM]. [ENUMPO] outlines the principles - for the operation of a telephone number service that resolves - telephone numbers into Internet domain name addresses and service- - specific directory discovery. [ENUMPO] implements a three-level - approach where the first level is the mapping of the telephone - number delegation tree to the authority to which the number has been - delegated, the second level is the provision of the requested DNS - resource records from a service registrar, and the third level is - the provision of service specific data from the service provider - itself. NP certainly must be considered at the first level because - the telephony service providers do not "own" or control the - telephone numbers under the NP environment; therefore, they may not - be the proper entities to have the authority for a given E.164 - number. Not only that, there is a regulatory requirement on NP in - some countries that the donor network should not be relied on to - reach the delegated authority during the DNS process . The - delegated authority for a given E.164 number is likely to be an - entity designated by the end user that owns/controls a specific - telephone number or one that is designated by the service registrar. - - Since the telephony service providers may have the need to use ENUM - for their network-related services (e.g., map an E.164 number to a - HLR Identifier in the wireless networks), their ENUM records must be - collocated with those of the telephony subscribers. If that is the - case, NP will impact ENUM when a telephony subscriber who has ENUM - service changes the telephony service provider. This is because - that the ENUM records from the new telephony service provider must - replace those from the old telephony service provider. To avoid the - NP impact on ENUM, it is recommended that the telephony service - providers use a different domain tree for their network-related - service. For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a - domain tree different from e164.arpa should be used for Ÿcarrier÷ - ENUM. - - The IP-based networks also may need to support some forms of number - portability in the future if E.164 numbers [E164] are assigned to - the IP-based end users. One method is to assign a GSTN routing - number for each IP-based network domain or entity in a NP-capable - country. This may increase the number of digits in the routing - number to incorporate the IP entities and impact the existing - routing in the GSTN. Another method is to associate each IP entity - with a particular GSTN gateway. At that particular GSTN gateway, - the called directory number then is used to locate the IP-entity - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 23] - -Number Portability in the GSTN: An Overview June 24, 2002 - - that serves that dialed directory number. Yet, another method can - be to assign a special routing number so that the call to an end - user currently served by an IP entity is routed to the nearest GSTN - gateway. The called directory number then is used to locate the IP- - entity that serves that dialed directory number. A mechanism can be - developed or used for the IP-based network to locate the IP entity - that serves a particular dialed directory number. Many other types - of networks use E.164 numbers to identify the end users or terminals - in those networks. Number portability among GSTN, IP-based network - and those various types of networks may also need to be supported in - the future. - - -10. Security Considerations - - This document does not raise any security issues. - - -11. IANA Considerations - - This document introduces no new values for IANA registration. - - -12. Normative References - - [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability - - Operator Services Switching Systems," April 1999. - - [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability - - Switching Systems," April 1999. - - [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability - Database and Global Title Translation," April 1999. - - [CS1] ITU-T Q-series Recommendations - Supplement 4, "Number - portability Capability set 1 requirements for service provider - portability (All call query and onward routing)," May 1998. - - [CS2] ITU-T Q-series Recommendations - Supplement 5, "Number - portability -Capability set 2 requirements for service provider - portability (Query on release and Dropback)," March 1999. - - [E164] ITU-T Recommendation E.164, "The International Public - Telecommunications Numbering Plan," 1997. - - [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. - - [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital - Network (ISDN); Signalling System No.7 (SS7); ISDN User Part - (ISUP); Enhancement for support of Number Portability (NP) - [ITU-T Recommendation Q.769.1 (2000), modified] - - [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase - 2+); Mobile Application Part (MAP) specification". - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 24] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - - [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for - Wireless Number Portability Phase II (December 1998)"Number - Portability Network Support," April 1998. - - [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - - ISDN User Part Enhancements for the Support of Number - Portability," December 1999. - - [MNP] ETSI EN 301 716 (2000-10) European Standard - (Telecommunications series) Digital cellular telecommunications - system (Phase 2+); Support of Mobile Number Portability (MNP); - Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 - Release 1998). - - [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- - Revision 3," October 1996. - - -13. Informative References - - [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific - Provisioning: Principles of Operations," draft-ietf-enum- - operation-02.txt, February 23, 2001. - - [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: - Session Initiation Protocol," February 27, 2002. - - [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis- - 04.txt, "URIs for Telephone Calls," May 24, 2002. - - [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL - to support Number Portability and Freephone Service," June 14, - 2002. - - [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony - Routing Information Protocol (TRIP)," January 2002. - - -14. Acknowledgment - - The authors would like to thank Monika Muench for providing - information on ISUP and MNP. - - -15. Authors' Addresses - - Mark D. Foster - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 25] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - - Phone: +1-202-533-2800 - Fax: +1-202-533-2987 - Email: mark.foster@neustar.biz - - Tom McGarry - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - - Phone: +1-202-533-2810 - Fax: +1-202-533-2987 - Email: tom.mcgarry@neustar.biz - - James Yu - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - - Phone: +1-202-533-2814 - Fax: +1-202-533-2987 - Email: james.yu@neustar.biz - - - -Full Copyright Statement - - "Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 26] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 27] -
\ No newline at end of file diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt deleted file mode 100644 index 2d5c87eb..00000000 --- a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt +++ /dev/null @@ -1,1200 +0,0 @@ - - - - - - -IPv6 Working Group John Loughney (ed) -Internet-Draft Nokia - January 14, 2004 - -Expires: July 14, 2004 - - - - IPv6 Node Requirements - draft-ietf-ipv6-node-requirements-08.txt - - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document defines requirements for IPv6 nodes. It is expected - that IPv6 will be deployed in a wide range of devices and situations. - Specifying the requirements for IPv6 nodes allows IPv6 to function - well and interoperate in a large number of situations and - deployments. - - - - - -Loughney (editor) February 16, 2004 [Page 1] - - - - - -Internet-Draft - - -Table of Contents - - 1. Introduction - 1.1 Requirement Language - 1.2 Scope of this Document - 1.3 Description of IPv6 Nodes - 2. Abbreviations Used in This Document - 3. Sub-IP Layer - 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 - 3.2 IP version 6 over PPP - RFC2472 - 3.3 IPv6 over ATM Networks - RFC2492 - 4. IP Layer - 4.1 Internet Protocol Version 6 - RFC2460 - 4.2 Neighbor Discovery for IPv6 - RFC2461 - 4.3 Path MTU Discovery & Packet Size - 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 - 4.5 Addressing - 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 - 5. Transport and DNS - 5.1 Transport Layer - 5.2 DNS - 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - 6. IPv4 Support and Transition - 6.1 Transition Mechanisms - 7. Mobility - 8. Security - 8.1 Basic Architecture - 8.2 Security Protocols - 8.3 Transforms and Algorithms - 8.4 Key Management Methods - 9. Router Functionality - 9.1 General - 10. Network Management - 10.1 MIBs - 11. Security Considerations - 12. References - 12.1 Normative - 12.2 Non-Normative - 13. Authors and Acknowledgements - 14. Editor's Address - Notices - - - - - - - - - - -Loughney (editor) February 16, 2004 [Page 2] - - - - - -Internet-Draft - - -1. Introduction - - The goal of this document is to define the common functionality - required from both IPv6 hosts and routers. Many IPv6 nodes will - implement optional or additional features, but all IPv6 nodes can be - expected to implement the mandatory requirements listed in this - document. - - This document tries to avoid discussion of protocol details, and - references RFCs for this purpose. In case of any conflicting text, - this document takes less precedence than the normative RFCs, unless - additional clarifying text is included in this document. - - Although the document points to different specifications, it should - be noted that in most cases, the granularity of requirements are - smaller than a single specification, as many specifications define - multiple, independent pieces, some of which may not be mandatory. - - As it is not always possible for an implementer to know the exact - usage of IPv6 in a node, an overriding requirement for IPv6 nodes is - that they should adhere to Jon Postel's Robustness Principle: - - Be conservative in what you do, be liberal in what you accept from - others [RFC-793]. - -1.1 Requirement Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC-2119]. - -1.2 Scope of this Document - - IPv6 covers many specifications. It is intended that IPv6 will be - deployed in many different situations and environments. Therefore, - it is important to develop the requirements for IPv6 nodes, in order - to ensure interoperability. - - This document assumes that all IPv6 nodes meet the minimum - requirements specified here. - -1.3 Description of IPv6 Nodes - - From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we - have the following definitions: - - Description of an IPv6 Node - - - - -Loughney (editor) February 16, 2004 [Page 3] - - - - - -Internet-Draft - - - - a device that implements IPv6 - - Description of an IPv6 router - - - a node that forwards IPv6 packets not explicitly addressed to - itself. - - Description of an IPv6 Host - - - any node that is not a router. - -2. Abbreviations Used in This Document - - ATM Asynchronous Transfer Mode - - AH Authentication Header - - DAD Duplicate Address Detection - - ESP Encapsulating Security Payload - - ICMP Internet Control Message Protocol - - IKE Internet Key Exchange - - MIB Management Information Base - - MLD Multicast Listener Discovery - - MTU Maximum Transfer Unit - - NA Neighbor Advertisement - - NBMA Non-Broadcast Multiple Access - - ND Neighbor Discovery - - NS Neighbor Solicitation - - NUD Neighbor Unreachability Detection - - PPP Point-to-Point Protocol - - PVC Permanent Virtual Circuit - - SVC Switched Virtual Circuit - -3. Sub-IP Layer - - - -Loughney (editor) February 16, 2004 [Page 4] - - - - - -Internet-Draft - - - An IPv6 node must include support for one or more IPv6 link-layer - specifications. Which link-layer specifications are included will - depend upon what link-layers are supported by the hardware available - on the system. It is possible for a conformant IPv6 node to support - IPv6 on some of its interfaces and not on others. - - As IPv6 is run over new layer 2 technologies, it is expected that new - specifications will be issued. This section highlights some major - layer 2 technologies and is not intended to be complete. - -3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 - - Nodes supporting IPv6 over Ethernet interfaces MUST implement - Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. - -3.2 IP version 6 over PPP - RFC2472 - - Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- - 2472]. - -3.3 IPv6 over ATM Networks - RFC2492 - - Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM - Networks [RFC-2492]. Additionally, RFC 2492 states: - - A minimally conforming IPv6/ATM driver SHALL support the PVC mode - of operation. An IPv6/ATM driver that supports the full SVC mode - SHALL also support PVC mode of operation. - -4. IP Layer - -4.1 Internet Protocol Version 6 - RFC2460 - - The Internet Protocol Version 6 is specified in [RFC-2460]. This - specification MUST be supported. - - Unrecognized options in Hop-by-Hop Options or Destination Options - extensions MUST be processed as described in RFC 2460. - - The node MUST follow the packet transmission rules in RFC 2460. - - Nodes MUST always be able to send, receive and process fragment - headers. All conformant IPv6 implementations MUST be capable of - sending and receving IPv6 packets; forwarding functionality MAY be - supported - - RFC 2460 specifies extension headers and the processing for these - headers. - - - -Loughney (editor) February 16, 2004 [Page 5] - - - - - -Internet-Draft - - - A full implementation of IPv6 includes implementation of the - following extension headers: Hop-by-Hop Options, Routing (Type 0), - Fragment, Destination Options, Authentication and Encapsulating - Security Payload. [RFC-2460] - - An IPv6 node MUST be able to process these headers. It should be - noted that there is some discussion about the use of Routing Headers - and possible security threats [IPv6-RH] caused by them. - -4.2 Neighbor Discovery for IPv6 - RFC2461 - - Neighbor Discovery SHOULD be supported. RFC 2461 states: - - "Unless specified otherwise (in a document that covers operating - IP over a particular link type) this document applies to all link - types. However, because ND uses link-layer multicast for some of - its services, it is possible that on some link types (e.g., NBMA - links) alternative protocols or mechanisms to implement those - services will be specified (in the appropriate document covering - the operation of IP over a particular link type). The services - described in this document that are not directly dependent on - multicast, such as Redirects, Next-hop determination, Neighbor - Unreachability Detection, etc., are expected to be provided as - specified in this document. The details of how one uses ND on - NBMA links is an area for further study." - - Some detailed analysis of Neighbor Discovery follows: - - Router Discovery is how hosts locate routers that reside on an - attached link. Router Discovery MUST be supported for - implementations. - - Prefix Discovery is how hosts discover the set of address prefixes - that define which destinations are on-link for an attached link. - Prefix discovery MUST be supported for implementations. Neighbor - Unreachability Detection (NUD) MUST be supported for all paths - between hosts and neighboring nodes. It is not required for paths - between routers. However, when a node receives a unicast Neighbor - Solicitation (NS) message (that may be a NUD's NS), the node MUST - respond to it (i.e. send a unicast Neighbor Advertisement). - - Duplicate Address Detection MUST be supported on all links supporting - link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take - place on all unicast addresses). - - A host implementation MUST support sending Router Solicitations. - - Receiving and processing Router Advertisements MUST be supported for - - - -Loughney (editor) February 16, 2004 [Page 6] - - - - - -Internet-Draft - - - host implementations. The ability to understand specific Router - Advertisement options is dependent on supporting the specification - where the RA is specified. - - Sending and Receiving Neighbor Solicitation (NS) and Neighbor - Advertisement (NA) MUST be supported. NS and NA messages are required - for Duplicate Address Detection (DAD). - - Redirect functionality SHOULD be supported. If the node is a router, - Redirect functionality MUST be supported. - -4.3 Path MTU Discovery & Packet Size - -4.3.1 Path MTU Discovery - RFC1981 - - Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal - implementations MAY choose to not support it and avoid large packets. - The rules in RFC 2460 MUST be followed for packet fragmentation and - reassembly. - -4.3.2 IPv6 Jumbograms - RFC2675 - - IPv6 Jumbograms [RFC-2675] MAY be supported. - -4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 - - ICMPv6 [RFC-2463] MUST be supported. - -4.5 Addressing - -4.5.1 IP Version 6 Addressing Architecture - RFC3513 - - The IPv6 Addressing Architecture [RFC-3513] MUST be supported. - -4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 - - IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. - This specification MUST be supported for nodes that are hosts. - - Nodes that are routers MUST be able to generate link local addresses - as described in RFC 2462 [RFC-2462]. - - From 2462: - - The autoconfiguration process specified in this document applies - only to hosts and not routers. Since host autoconfiguration uses - information advertised by routers, routers will need to be - configured by some other means. However, it is expected that - - - -Loughney (editor) February 16, 2004 [Page 7] - - - - - -Internet-Draft - - - routers will generate link-local addresses using the mechanism - described in this document. In addition, routers are expected to - successfully pass the Duplicate Address Detection procedure - described in this document on all addresses prior to assigning - them to an interface. - - Duplicate Address Detection (DAD) MUST be supported. - -4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 - - Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] - SHOULD be supported. It is recommended that this behavior be - configurable on a connection basis within each application when - available. It is noted that a number of applications do not work - with addresses generated with this method, while other applications - work quite well with them. - -4.5.4 Default Address Selection for IPv6 - RFC3484 - - The rules specified in the Default Address Selection for IPv6 [RFC- - 3484] document MUST be implemented. It is expected that IPv6 nodes - will need to deal with multiple addresses. - -4.5.5 Stateful Address Autoconfiguration - - Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- - 3315] is the standard stateful address configuration protocol; see - section 5.3 for DHCPv6 support. - - Nodes which do not support Stateful Address Autoconfiguration may be - unable to obtain any IPv6 addresses aside from link-local addresses - when it receives a router advertisement with the 'M' flag (Managed - address configuration) set and which contains no prefixes advertised - for Stateless Address Autoconfiguration (see section 4.5.2). - Additionally, such nodes will be unable to obtain other configuration - information such as the addresses of DNS servers when it is connected - to a link over which the node receives a router advertisement in - which the 'O' flag ("Other stateful configuration") is set. - -4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 - - Nodes that need to join multicast groups SHOULD implement MLDv2 - [MLDv2]. However, if the node has applications, which only need - support for Any- Source Multicast [RFC3569], the node MAY implement - MLDv1 [MLDv1] instead. If the node has applications, which need - support for Source- Specific Multicast [RFC3569, SSMARCH], the node - MUST support MLDv2 [MLDv2]. - - - - -Loughney (editor) February 16, 2004 [Page 8] - - - - - -Internet-Draft - - - When MLD is used, the rules in "Source Address Selection for the - Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be - followed. - -5. Transport Layer and DNS - -5.1 Transport Layer - -5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 - - This specification MUST be supported if jumbograms are implemented - [RFC- 2675]. - -5.2 DNS - - DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] - and [RFC-3596] MAY be supported. Not all nodes will need to resolve - names. All nodes that need to resolve names SHOULD implement stub- - resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with - support for: - - - AAAA type Resource Records [RFC-3596]; - - reverse addressing in ip6.arpa using PTR records [RFC-3152]; - - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 - octets. - - Those nodes are RECOMMENDED to support DNS security extentions - [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. - - Those nodes are NOT RECOMMENDED to support the experimental A6 and - DNAME Resource Records [RFC-3363]. - -5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 - - RFC 2732 MUST be supported if applications on the node use URL's. - -5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 - -5.3.1 Managed Address Configuration - - Those IPv6 Nodes that use DHCP for address assignment initiate DHCP - to obtain IPv6 addresses and other configuration information upon - receipt of a Router Advertisement with the 'M' flag set, as described - in section 5.5.3 of RFC 2462. In addition, in the absence of a - router, those IPv6 Nodes that use DHCP for address assignment MUST - initiate DHCP to obtain IPv6 addresses and other configuration - information, as described in section 5.5.2 of RFC 2462. Those IPv6 - nodes that do not use DHCP for address assignment can ignore the 'M' - - - -Loughney (editor) February 16, 2004 [Page 9] - - - - - -Internet-Draft - - - flag in Router Advertisements. - -5.3.2 Other Configuration Information - - Those IPv6 Nodes that use DHCP to obtain other configuration - information initiate DHCP for other configuration information upon - receipt of a Router Advertisement with the 'O' flag set, as described - in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP - for other configuration information can ignore the 'O' flag in Router - Advertisements. - - An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to - obtain other configuration information. - -6. IPv4 Support and Transition - - IPv6 nodes MAY support IPv4. - -6.1 Transition Mechanisms - -6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 - - If an IPv6 node implements dual stack and tunneling, then RFC2893 - MUST be supported. - - RFC 2893 is currently being updated. - -7. Mobile IP - - The Mobile IPv6 [MIPv6] specification defines requirements for the - following types of nodes: - - - mobile nodes - - correspondent nodes with support for route optimization - - home agents - - all IPv6 routers - - Hosts MAY support mobile node functionality described in Section 8.5 - of [MIPv6], including support of generic packet tunneling [RFC-2473] - and secure home agent communications [MIPv6-HASEC]. - - Hosts SHOULD support route optimization requirements for - correspondent nodes described in Section 8.2 of [MIPv6]. - - Routers SHOULD support the generic mobility-related requirements for - all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY - support the home agent functionality described in Section 8.4 of - [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. - - - -Loughney (editor) February 16, 2004 [Page 10] - - - - - -Internet-Draft - - -8. Security - - This section describes the specification of IPsec for the IPv6 node. - -8.1 Basic Architecture - - Security Architecture for the Internet Protocol [RFC-2401] MUST be - supported. RFC-2401 is being updated by the IPsec Working Group. - -8.2 Security Protocols - - ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. - RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group. - - -8.3 Transforms and Algorithms - - Current IPsec RFCs specify the support of certain transforms and - algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. - The requirements for these are discussed first, and then additional - algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed. - - NULL encryption algorithm [RFC-2410] MUST be supported for providing - integrity service and also for debugging use. - - The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD - NOT be supported. Security issues related to the use of DES are - discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as - required by the existing IPsec RFCs, but as it is currently viewed as - an inherently weak algorithm, and no longer fulfills its intended - role. - - The NULL authentication algorithm [RFC-2406] MUST be supported within - ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- - 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP, - described in [RFC-2403] MUST be supported. An implementer MUST refer - to Keyed- Hashing for Message Authentication [RFC-2104]. - - 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC - and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES- - CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected - to be a widely available, secure algorithm that is required for - interoperability. It is not required by the current IPsec RFCs, but - is expected to become required in the future. - - In addition to the above requirements, "Cryptographic Algorithm - Implementation Requirements For ESP And AH" [CRYPTREQ] contains the - current set of mandatory to implement algorithms for ESP and AH as - - - -Loughney (editor) February 16, 2004 [Page 11] - - - - - -Internet-Draft - - - well as specifying algorithms that should be implemented because they - may be promoted to mandatory at some future time. It is RECOMMENDED - that IPv6 nodes conform to the requirements in this document. - -8.4 Key Management Methods - - Manual keying MUST be supported. - - IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast - traffic. Where key refresh, anti-replay features of AH and ESP, or - on- demand creation of Security Associations (SAs) is required, - automated keying MUST be supported. Note that the IPsec WG is working - on the successor to IKE [IKE2]. Key management methods for multicast - traffic are also being worked on by the MSEC WG. - - "Cryptographic Algorithms for use in the Internet Key Exchange - Version 2" [IKEv2ALGO] defines the current set of mandatory to - implement algorithms for use of IKEv2 as well as specifying - algorithms that should be implemented because they made be promoted - to mandatory at some future time. It is RECOMMENDED that IPv6 nodes - implementing IKEv2 conform to the requirements in this - document. - -9. Router-Specific Functionality - - This section defines general host considerations for IPv6 nodes that - act as routers. Currently, this section does not discuss routing- - specific requirements. - -9.1 General - -9.1.1 IPv6 Router Alert Option - RFC2711 - - - The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- - Hop Header that is used in conjunction with some protocols (e.g., - RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will - need to be implemented whenever protocols that mandate its usage are - implemented. See Section 4.6. - -9.1.2 Neighbor Discovery for IPv6 - RFC2461 - - Sending Router Advertisements and processing Router Solicitation MUST - be supported. - -10. Network Management - - Network Management MAY be supported by IPv6 nodes. However, for IPv6 - - - -Loughney (editor) February 16, 2004 [Page 12] - - - - - -Internet-Draft - - - nodes that are embedded devices, network management may be the only - possibility to control these nodes. - -10.1 Management Information Base Modules (MIBs) - - The following two MIBs SHOULD be supported by nodes that support an - SNMP agent. - -10.1.1 IP Forwarding Table MIB - - IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes - that support an SNMP agent. - -10.1.2 Management Information Base for the Internet Protocol (IP) - - IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an - SNMP agent. - -11. Security Considerations - - This draft does not affect the security of the Internet, but - implementations of IPv6 are expected to support a minimum set of - security features to ensure security on the Internet. "IP Security - Document Roadmap" [RFC-2411] is important for everyone to read. - - The security considerations in RFC2460 describe the following: - - The security features of IPv6 are described in the Security - Architecture for the Internet Protocol [RFC-2401]. - -12. References - -12.1 Normative - - [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- - tion Requirements For ESP And AH", draft-ietf-ipsec- - esp-ah-algorithms-01.txt, January 2004. - - [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the - Internet Key Exchange Version 2", draft-ietf-ipsec- - ikev2-algorithms-04.txt, Work in Progress. - - [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 - Service", draft- ietf-dhc-dhcpv6-stateless-00.txt, - Work in Progress. - - [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support - in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in - - - -Loughney (editor) February 16, 2004 [Page 13] - - - - - -Internet-Draft - - - progress. - - [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec - to Protect Mobile IPv6 Signaling between Mobile Nodes - and Home Agents", draft-ietf- mobileip-mipv6-ha- - ipsec-06.txt, Work in Progress. - - [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version - 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in - Progress. - - [RFC-1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU - Discovery for IP version 6", RFC 1981, August 1996. - - [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table - MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in - Progress. - - [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the - Internet Protocol (IP)", draft-ietf-ipv6-rfc2011- - update-07.txt, Work in progress. - - [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: - Keyed-Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for - the Internet Protocol", RFC 2401, November 1998. - - [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication - Header", RFC 2402, November 1998. - - [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within - ESP and AH", RFC 2403, November 1998. - - [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 - within ESP and AH", RFC 2404, November 1998. - - [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher - Algorithm With Explicit IV", RFC 2405, November 1998. - - [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security - - - -Loughney (editor) February 16, 2004 [Page 14] - - - - - -Internet-Draft - - - Protocol (ESP)", RFC 2406, November 1998. - - [RFC-2407] Piper, D., "The Internet IP Security Domain of - Interpretation for ISAKMP", RFC 2407, November 1998. - - [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, - J., "Internet Security Association and Key Management - Protocol (ISAKMP)", RFC 2408, November 1998. - - [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key - Exchange (IKE)", RFC 2409, November 1998. - - [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm - and Its Use With IPsec", RFC 2410, November 1998. - - [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- - sion 6 (IPv6) Specification", RFC 2460, December 1998. - - [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor - Discovery for IP Version 6 (IPv6)", RFC 2461, December - 1998. - - [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address - Autoconfiguration", RFC 2462. - - [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- - tocol Version 6 (IPv6)", RFC 2463, December 1998. - - [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC - 2472, December 1998. - - [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling - in IPv6 Specification", RFC 2473, December 1998. Xxx - add - - [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast - Listener Discovery (MLD) for IPv6", RFC 2710, October - 1999. - - [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert - Option", RFC 2711, October 1999. - - - - -Loughney (editor) February 16, 2004 [Page 15] - - - - - -Internet-Draft - - - [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC - 3041, January 2001. - - [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August - 2001. - - [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol - for IPv6 (DHCPv6)", RFC 3315, July 2003. - - [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver- - sion 6 (IPv6) Addresses in the Domain Name System - (DNS)", RFC 3363, August 2002. - - [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC - 3484, February 2003. - - [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing - Architecture", RFC 3513, April 2003. - - [RFC-3590] Haberman, B., "Source Address Selection for the Multi- - cast Listener Discovery (MLD) Protocol", RFC 3590, - September 2003. - - [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP - version 6", RFC 3596, October 2003. - - [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use - with IPsec", RFC 3602, September 2003. - -12.2 Non-Normative - - [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", - draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in - Progress. - - [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of - DES-like cryptosystems", Journal of Cryptology Vol 4, Jan - 1991. - - [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. - - [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without - Strong Integrity", Proceedings of the 32nd IETF, Danvers, - MA, April 1995. - - [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser- - vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in - - - -Loughney (editor) February 16, 2004 [Page 16] - - - - - -Internet-Draft - - - Progress. - - [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "DNS Security Introduction and Requirements" draft- - ietf-dnsext-dnssec-intro- 06.txt, Work in Progress. - - [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro- - gress. - - [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "Protocol Modifications for the DNS Security Exten- - sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work - in Progress. - - [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- - col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress. - - [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home - Address Options", draft-savola-ipv6-rh-ha-security- - 03.txt, Work in Progress, March 2002. - - [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- - rity Threats and Counter-Measures; In Proceedings "Sympo- - sium on Network and Distributed System Security", Febru- - ary 1995, pp.2-16. - - [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, - August 1980. - - [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- - ties", RFC 1034, November 1987. - - [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, - May 1997. - - [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and - S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC - 2205, September 1997. - - [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet - Networks", RFC 2462, December 1998. - - [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over - ATM Networks", RFC 2492, January 1999. - - [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 - - - -Loughney (editor) February 16, 2004 [Page 17] - - - - - -Internet-Draft - - - Jumbograms", RFC 2675, August 1999. - - [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal - IPv6 Addresses in URL's", RFC 2732, December 1999. - - [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, - "Textual Conventions for Internet Network Addresses", RFC - 2851, June 2000. - - [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 2893, August 2000. - - [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific - Multicast (SSM)", RFC 3569, July 2003. - - [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", - draft-ietf- ssm-arch-03.txt, Work in Progress. - -13. Authors and Acknowledgements - - This document was written by the IPv6 Node Requirements design team: - - Jari Arkko - [jari.arkko@ericsson.com] - - Marc Blanchet - [marc.blanchet@viagenie.qc.ca] - - Samita Chakrabarti - [samita.chakrabarti@eng.sun.com] - - Alain Durand - [alain.durand@sun.com] - - Gerard Gastaud - [gerard.gastaud@alcatel.fr] - - Jun-ichiro itojun Hagino - [itojun@iijlab.net] - - Atsushi Inoue - [inoue@isl.rdc.toshiba.co.jp] - - Masahiro Ishiyama - [masahiro@isl.rdc.toshiba.co.jp] - - John Loughney - [john.loughney@nokia.com] - - - -Loughney (editor) February 16, 2004 [Page 18] - - - - - -Internet-Draft - - - Rajiv Raghunarayan - [raraghun@cisco.com] - - Shoichi Sakane - [shouichi.sakane@jp.yokogawa.com] - - Dave Thaler - [dthaler@windows.microsoft.com] - - Juha Wiljakka - [juha.wiljakka@Nokia.com] - - The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- - penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, - Juha Ollila and Pekka Savola for their comments. - -14. Editor's Contact Information - - Comments or questions regarding this document should be sent to the - IPv6 Working Group mailing list (ipv6@ietf.org) or to: - - John Loughney - Nokia Research Center - Itamerenkatu 11-13 - 00180 Helsinki - Finland - - Phone: +358 50 483 6242 - Email: John.Loughney@Nokia.com - -Notices - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to per- - tain to the implementation or use of the technology described in this - document or the extent to which any license under such rights might - or might not be available; neither does it represent that it has made - any effort to identify any such rights. Information on the IETF's - procedures with respect to rights in standards-track and standards- - related documentation can be found in BCP-11. Copies of claims of - rights made available for publication and any assurances of licenses - to be made available, or the result of an attempt made to obtain a - general license or permission for the use of such proprietary rights - by implementors or users of this specification can be obtained from - the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - - - -Loughney (editor) February 16, 2004 [Page 19] - - - - - -Internet-Draft - - - rights, which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Loughney (editor) February 16, 2004 [Page 20] - - diff --git a/doc/draft/draft-ietf-secsh-dns-05.txt b/doc/draft/draft-ietf-secsh-dns-05.txt deleted file mode 100644 index a272d81b..00000000 --- a/doc/draft/draft-ietf-secsh-dns-05.txt +++ /dev/null @@ -1,614 +0,0 @@ -Secure Shell Working Group J. Schlyter -Internet-Draft OpenSSH -Expires: March 5, 2004 W. Griffin - SPARTA - September 5, 2003 - - - Using DNS to Securely Publish SSH Key Fingerprints - draft-ietf-secsh-dns-05.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on March 5, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document describes a method to verify SSH host keys using - DNSSEC. The document defines a new DNS resource record that contains - a standard SSH key fingerprint. - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 1] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 - 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 - 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 - 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 - 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5 - 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 - 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 - 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 - Normative References . . . . . . . . . . . . . . . . . . . . 8 - Informational References . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - Intellectual Property and Copyright Statements . . . . . . . 10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 2] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -1. Introduction - - The SSH [6] protocol provides secure remote login and other secure - network services over an insecure network. The security of the - connection relies on the server authenticating itself to the client - as well as the user authenticating itself to the server. - - If a connection is established to a server whose public key is not - already known to the client, a fingerprint of the key is presented to - the user for verification. If the user decides that the fingerprint - is correct and accepts the key, the key is saved locally and used for - verification for all following connections. While some - security-conscious users verify the fingerprint out-of-band before - accepting the key, many users blindly accept the presented key. - - The method described here can provide out-of-band verification by - looking up a fingerprint of the server public key in the DNS [1][2] - and using DNSSEC [5] to verify the lookup. - - In order to distribute the fingerprint using DNS, this document - defines a new DNS resource record, "SSHFP", to carry the fingerprint. - - Basic understanding of the DNS system [1][2] and the DNS security - extensions [5] is assumed by this document. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [3]. - -2. SSH Host Key Verification - -2.1 Method - - Upon connection to a SSH server, the SSH client MAY look up the SSHFP - resource record(s) for the host it is connecting to. If the - algorithm and fingerprint of the key received from the SSH server - match the algorithm and fingerprint of one of the SSHFP resource - record(s) returned from DNS, the client MAY accept the identity of - the server. - -2.2 Implementation Notes - - Client implementors SHOULD provide a configurable policy used to - select the order of methods used to verify a host key. This document - defines one method: Fingerprint storage in DNS. Another method - defined in the SSH Architecture [6] uses local files to store keys - for comparison. Other methods that could be defined in the future - might include storing fingerprints in LDAP or other databases. A - - - -Schlyter & Griffin Expires March 5, 2004 [Page 3] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - configurable policy will allow administrators to determine which - methods they want to use and in what order the methods should be - prioritized. This will allow administrators to determine how much - trust they want to place in the different methods. - - One specific scenario for having a configurable policy is where - clients do not use fully qualified host names to connect to servers. - In this scenario, the implementation SHOULD verify the host key - against a local database before verifying the key via the fingerprint - returned from DNS. This would help prevent an attacker from injecting - a DNS search path into the local resolver and forcing the client to - connect to a different host. - -2.3 Fingerprint Matching - - The public key and the SSHFP resource record are matched together by - comparing algorithm number and fingerprint. - - The public key algorithm and the SSHFP algorithm number MUST - match. - - A message digest of the public key, using the message digest - algorithm specified in the SSHFP fingerprint type, MUST match the - SSHFP fingerprint. - - -2.4 Authentication - - A public key verified using this method MUST NOT be trusted if the - SSHFP resource record (RR) used for verification was not - authenticated by a trusted SIG RR. - - Clients that do validate the DNSSEC signatures themselves SHOULD use - standard DNSSEC validation procedures. - - Clients that do not validate the DNSSEC signatures themselves MUST - use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8], - between themselves and the entity performing the signature - validation. - -3. The SSHFP Resource Record - - The SSHFP resource record (RR) is used to store a fingerprint of a - SSH public host key that is associated with a Domain Name System - (DNS) name. - - The RR type code for the SSHFP RR is TBA. - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 4] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -3.1 The SSHFP RDATA Format - - The RDATA for a SSHFP RR consists of an algorithm number, fingerprint - type and the fingerprint of the public host key. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | fp type | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / - / / - / fingerprint / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 Algorithm Number Specification - - This algorithm number octet describes the algorithm of the public - key. The following values are assigned: - - Value Algorithm name - ----- -------------- - 0 reserved - 1 RSA - 2 DSS - - Reserving other types requires IETF consensus [4]. - -3.1.2 Fingerprint Type Specification - - The fingerprint type octet describes the message-digest algorithm - used to calculate the fingerprint of the public key. The following - values are assigned: - - Value Fingerprint type - ----- ---------------- - 0 reserved - 1 SHA-1 - - Reserving other types requires IETF consensus [4]. - - For interoperability reasons, as few fingerprint types as possible - should be reserved. The only reason to reserve additional types is - to increase security. - -3.1.3 Fingerprint - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 5] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - The fingerprint is calculated over the public key blob as described - in [7]. - - The message-digest algorithm is presumed to produce an opaque octet - string output which is placed as-is in the RDATA fingerprint field. - -3.2 Presentation Format of the SSHFP RR - - The RDATA of the presentation format of the SSHFP resource record - consists of two numbers (algorithm and fingerprint type) followed by - the fingerprint itself presented in hex, e.g: - - host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 - - The use of mnemonics instead of numbers is not allowed. - -4. Security Considerations - - Currently, the amount of trust a user can realistically place in a - server key is proportional to the amount of attention paid to - verifying that the public key presented actually corresponds to the - private key of the server. If a user accepts a key without verifying - the fingerprint with something learned through a secured channel, the - connection is vulnerable to a man-in-the-middle attack. - - The overall security of using SSHFP for SSH host key verification is - dependent on the security policies of the SSH host administrator and - DNS zone administrator (in transferring the fingerprint), detailed - aspects of how verification is done in the SSH implementation, and in - the client's diligence in accessing the DNS in a secure manner. - - One such aspect is in which order fingerprints are looked up (e.g. - first checking local file and then SSHFP). We note that in addition - to protecting the first-time transfer of host keys, SSHFP can - optionally be used for stronger host key protection. - - If SSHFP is checked first, new SSH host keys may be distributed by - replacing the corresponding SSHFP in DNS. - - If SSH host key verification can be configured to require SSHFP, - SSH host key revocation can be implemented by removing the - corresponding SSHFP from DNS. - - As stated in Section 2.2, we recommend that SSH implementors provide - a policy mechanism to control the order of methods used for host key - verification. One specific scenario for having a configurable policy - is where clients use unqualified host names to connect to servers. In - this case, we recommend that SSH implementations check the host key - - - -Schlyter & Griffin Expires March 5, 2004 [Page 6] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - against a local database before verifying the key via the fingerprint - returned from DNS. This would help prevent an attacker from injecting - a DNS search path into the local resolver and forcing the client to - connect to a different host. - - A different approach to solve the DNS search path issue would be for - clients to use a trusted DNS search path, i.e., one not acquired - through DHCP or other autoconfiguration mechanisms. Since there is no - way with current DNS lookup APIs to tell whether a search path is - from a trusted source, the entire client system would need to be - configured with this trusted DNS search path. - - Another dependency is on the implementation of DNSSEC itself. As - stated in Section 2.4, we mandate the use of secure methods for - lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This - is especially important if SSHFP is to be used as a basis for host - key rollover and/or revocation, as described above. - - Since DNSSEC only protects the integrity of the host key fingerprint - after it is signed by the DNS zone administrator, the fingerprint - must be transferred securely from the SSH host administrator to the - DNS zone administrator. This could be done manually between the - administrators or automatically using secure DNS dynamic update [11] - between the SSH server and the nameserver. We note that this is no - different from other key enrollment situations, e.g. a client sending - a certificate request to a certificate authority for signing. - -5. IANA Considerations - - IANA needs to allocate a RR type code for SSHFP from the standard RR - type space (type 44 requested). - - IANA needs to open a new registry for the SSHFP RR type for public - key algorithms. Defined types are: - - 0 is reserved - 1 is RSA - 2 is DSA - - Adding new reservations requires IETF consensus [4]. - - IANA needs to open a new registry for the SSHFP RR type for - fingerprint types. Defined types are: - - 0 is reserved - 1 is SHA-1 - - Adding new reservations requires IETF consensus [4]. - - - -Schlyter & Griffin Expires March 5, 2004 [Page 7] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [5] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. - Lehtinen, "SSH Protocol Architecture", - draft-ietf-secsh-architecture-14 (work in progress), July 2003. - - [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. - Lehtinen, "SSH Transport Layer Protocol", - draft-ietf-secsh-transport-16 (work in progress), July 2003. - -Informational References - - [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document - Roadmap", RFC 2411, November 1998. - - [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [10] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 8] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Authors' Addresses - - Jakob Schlyter - OpenSSH - 812 23rd Avenue SE - Calgary, Alberta T2G 1N8 - Canada - - EMail: jakob@openssh.com - URI: http://www.openssh.com/ - - - Wesley Griffin - SPARTA - 7075 Samuel Morse Drive - Columbia, MD 21046 - USA - - EMail: wgriffin@sparta.com - URI: http://www.sparta.com/ - -Appendix A. Acknowledgements - - The authors gratefully acknowledge, in no particular order, the - contributions of the following persons: - - Martin Fredriksson - - Olafur Gudmundsson - - Edward Lewis - - Bill Sommerfeld - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 9] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Schlyter & Griffin Expires March 5, 2004 [Page 10] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 11] - diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt deleted file mode 100644 index 3578d2a1..00000000 --- a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt +++ /dev/null @@ -1,519 +0,0 @@ - -Internet Draft Johan Ihren -draft-ihren-dnsext-threshold-validation-00.txt Autonomica -February 2003 -Expires in six months - - - Threshold Validation: - - A Mechanism for Improved Trust and Redundancy for DNSSEC Keys - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - -Abstract - - This memo documents a proposal for a different method of validation - for DNSSEC aware resolvers. The key change is that by changing from - a model of one Key Signing Key, KSK, at a time to multiple KSKs it - will be possible to increase the aggregated trust in the signed - keys by leveraging from the trust associated with the different - signees. - - By having multiple keys to chose from validating resolvers get the - opportunity to use local policy to reflect actual trust in - different keys. For instance, it is possible to trust a single, - particular key ultimately, while requiring multiple valid - signatures by less trusted keys for validation to succeed. - Furthermore, with multiple KSKs there are additional redundancy - benefits available since it is possible to roll over different KSKs - at different times which may make rollover scenarios easier to - manage. - -Contents - - 1. Terminology - 2. Introduction and Background - - 3. Trust in DNSSEC Keys - 3.1. Key Management, Split Keys and Trust Models - 3.2. Trust Expansion: Authentication versus Authorization - - 4. Proposed Semantics for Signing the KEY Resource Record - Set - 4.1. Packet Size Considerations - - 5. Proposed Use of Multiple "Trusted Keys" in a Validating - Resolver - 5.1. Not All Possible KSKs Need to Be Trusted - 5.2. Possible to do Threshold Validation - 5.3. Not All Trusted Keys Will Be Available - - 6. Additional Benefits from Having Multiple KSKs - 6.1. More Robust Key Rollovers - 6.2. Evaluation of Multiple Key Distribution Mechanisms - - 7. Security Considerations - 8. IANA Considerations. - 9. References - 9.1. Normative. - 9.2. Informative. - 10. Acknowledgments. - 11. Authors' Address - - -1. Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in - RFC 2119. - - The term "zone" refers to the unit of administrative control in the - Domain Name System. "Name server" denotes a DNS name server that is - authoritative (i.e. knows all there is to know) for a DNS zone, - typically the root zone. A "resolver", is a DNS "client", i.e. an - entity that sends DNS queries to authoritative nameservers and - interpret the results. A "validating resolver" is a resolver that - attempts to perform DNSSEC validation on data it retrieves by doing - DNS lookups. - - -2. Introduction and Background - - From a protocol perspective there is no real difference between - different keys in DNSSEC. They are all just keys. However, in - actual use there is lots of difference. First and foremost, most - DNSSEC keys have in-band verification. I.e. the keys are signed by - some other key, and this other key is in its turn also signed by - yet another key. This way a "chain of trust" is created. Such - chains have to end in what is referred to as a "trusted key" for - validation of DNS lookups to be possible. - - A "trusted key" is a the public part of a key that the resolver - acquired by some other means than by looking it up in DNS. The - trusted key has to be explicitly configured. - - A node in the DNS hierarchy that issues such out-of-band "trusted - keys" is called a "security apex" and the trusted key for that apex - is the ultimate source of trust for all DNS lookups within that - entire subtree. - - DNSSEC is designed to be able to work with more than on security - apex. These apexes will all share the problem of how to distribute - their "trusted keys" in a way that provides validating resolvers - confidence in the distributed keys. - - Maximizing that confidence is crucial to the usefulness of DNSSEC - and this document tries to address this issue. - - -3. Trust in DNSSEC Keys - - In the end the trust that a validating resolver will be able to put - in a key that it cannot validate within DNSSEC will have to be a - function of - - * trust in the key issuer, aka the KSK holder - - * trust in the distribution method - - * trust in extra, out-of-band verification - - The KSK holder needs to be trusted not to accidentally lose private - keys in public places. Furthermore it needs to be trusted to - perform correct identification of the ZSK holders in case they are - separate from the KSK holder itself. - - The distribution mechanism can be more or less tamper-proof. If the - key holder publishes the public key, or perhaps just a secure - fingerprint of the key in a major newspaper it may be rather - difficult to tamper with. A key acquired that way may be easier to - trust than if it had just been downloaded from a web page. - - Out-of-band verification can for instance be the key being signed - by a certificate issued by a known Certificate Authority that the - resolver has reason to trust. - -3.1. Simplicity vs Trust - - The fewer keys that are in use the simpler the key management - becomes. Therefore increasing the number of keys should only be - considered when the complexity is not the major concern. A perfect - example of this is the distinction between so called Key Signing - Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds - overall complexity but simplifies real life operations and was an - overall gain since operational simplification was considered to be - a more crucial issue than the added complexity. - - In the case of a security apex there are additional issues to - consider, among them - - * maximizing trust in the KSK received out-of-band - - * authenticating the legitimacy of the ZSKs used - - In some cases this will be easy, since the same entity will manage - both ZSKs and KSKs (i.e. it will authenticate itself, somewhat - similar to a self-signed certificate). In some environments it will - be possible to get the trusted key installed in the resolver end by - decree (this would seem to be a likely method within corporate and - government environments). - - In other cases, however, this will possibly not be sufficient. In - the case of the root zone this is obvious, but there may well be - other cases. - -3.2. Expanding the "Trust Base" - - For a security apex where the ZSKs and KSK are not held by the same - entity the KSK will effectively authenticate the identity of - whoever does real operational zone signing. The amount of trust - that the data signed by a ZSK will get is directly dependent on - whether the end resolver trusts the KSK or not, since the resolver - has no OOB access to the public part of the ZSKs (for practical - reasons). - - Since the KSK holder is distinct from the ZSK holder the obvious - question is whether it would then be possible to further improve - the situation by using multiple KSK holders and thereby expanding - the trust base to the union of that available to each individual - KSK holder. "Trust base" is an invented term intended to signify - the aggregate of Internet resolvers that will eventually choose to - trust a key issued by a particular KSK holder. - - A crucial issue when considering trust expansion through addition - of multiple KSK holders is that the KSK holders are only used to - authenticate the ZSKs used for signing the zone. I.e. the function - performed by the KSK is basically: - - "This is indeed the official ZSK holder for this zone, - I've verified this fact to the best of my abilitites." - - Which can be thought of as similar to the service of a public - notary. I.e. the point with adding more KSK holders is to improve - the public trust in data signed by the ZSK holders by improving the - strength of available authentication. - - Therefore adding more KSK holders, each with their own trust base, - is by definition a good thing. More authentication is not - controversial. On the contrary, when it comes to authentication, - the more the merrier. - - -4. Proposed Semantics for Signing the KEY Resource Record Set - - In DNSSEC according to RFC2535 all KEY Resource Records are used to - sign all authoritative data in the zone, including the KEY RRset - itself, since RFC2535 makes no distinction between Key Signing - Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS] - it is possible to change this to the KEY RRset being signed with - all KSKs and ZSKs but the rest of the zone only being signed by the - ZSKs. - - This proposal changes this one step further, by recommending that - the KEY RRset is only signed by the Key Signing Keys, KSK, and - explicitly not by the Zone Signing Keys, ZSK. The reason for this - is to maximize the amount of space in the DNS response packet that - is available for additional KSKs and signatures thereof. The rest - of the authoritative zone contents are as previously signed by only - the ZSKs. - -4.1. Packet Size Considerations - - The reason for the change is to keep down the size of the aggregate - of KEY RRset plus SIG(KEY) that resolvers will need to acquire to - perform validation of data below a security apex. For DNSSEC data - to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be - set, and therefore the allowed packet size can be assumed to be at - least the EDNS0 minimum of 4000 bytes. - - When querying for KEY + SIG(KEY) for "." (the case that is assumed - to be most crucial) the size of the response packet after the - change to only sign the KEY RR with the KSKs break down into a - rather large space of possibilities. Here are a few examples for - the possible alternatives for different numbers of KSKs and ZSKs - for some different key lengths (all RSA keys, with a public - exponent that is < 254). This is all based upon the size of the - response for the particular example of querying for - - ". KEY IN" - - with a response of entire KEY + SIG(KEY) with the authority and - additional sections empty: - - ZSK/768 and KSK/1024 (real small) - Max 12 KSK + 3 ZSK at 3975 - 10 KSK + 8 ZSK at 3934 - 8 KSK + 13 ZSK at 3893 - - ZSK/768 + KSK/1280 - MAX 10 KSK + 2 ZSK at 3913 - 8 KSK + 9 ZSK at 3970 - 6 KSK + 15 ZSK at 3914 - - ZSK/768 + KSK/1536 - MAX 8 KSK + 4 ZSK at 3917 - 7 KSK + 8 ZSK at 3938 - 6 KSK + 12 ZSK at 3959 - - ZSK/768 + KSK/2048 - MAX 6 KSK + 5 ZSK at 3936 - 5 KSK + 10 ZSK at 3942 - - ZSK/1024 + KSK/1024 - MAX 12 KSK + 2 ZSK at 3943 - 11 KSK + 4 ZSK at 3930 - 10 KSK + 6 ZSK at 3917 - 8 KSK + 10 ZSK at 3891 - - ZSK/1024 + KSK/1536 - MAX 8 KSK + 3 ZSK at 3900 - 7 KSK + 6 ZSK at 3904 - 6 KSK + 9 ZSK at 3908 - - ZSK/1024 + KSK/2048 - MAX 6 KSK + 4 ZSK at 3951 - 5 KSK + 8 ZSK at 3972 - 4 KSK + 12 ZSK at 3993 - - Note that these are just examples and this document is not making - any recommendations on suitable choices of either key lengths nor - number of different keys employed at a security apex. - - This document does however, based upon the above figures, make the - recommendation that at a security apex that expects to distribute - "trusted keys" the KEY RRset should only be signed with the KSKs - and not with the ZSKs to keep the size of the response packets - down. - - -5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver - - In DNSSEC according to RFC2535[RFC2535] validation is the process - of tracing a chain of signatures (and keys) upwards through the DNS - hierarchy until a "trusted key" is reached. If there is a known - trusted key present at a security apex above the starting point - validation becomes an exercise with a binary outcome: either the - validation succeeds or it fails. No intermediate states are - possible. - - With multiple "trusted keys" (i.e. the KEY RRset for the security - apex signed by multiple KSKs) this changes into a more complicated - space of alternatives. From the perspective of complexity that may - be regarded as a change for the worse. However, from a perspective - of maximizing available trust the multiple KSKs add value to the - system. - -5.1. Possible to do Threshold Validation - - With multiple KSKs a new option that opens for the security - concious resolver is to not trust a key individually. Instead the - resolver may decide to require the validated signatures to exceed a - threshold. For instance, given M trusted keys it is possible for - the resolver to require N-of-M signatures to treat the data as - validated. - - I.e. with the following pseudo-configuration in a validating - resolver - - security-apex "." IN { - keys { ksk-1 .... ; - ksk-2 .... ; - ksk-3 .... ; - ksk-4 .... ; - ksk-5 .... ; - }; - validation { - # Note that ksk-4 is not present below - keys { ksk-1; ksk-2; ksk-3; ksk-5; }; - # 3 signatures needed with 4 possible keys, aka 75% - needed-signatures 3; - }; - }; - - we configure five trusted keys for the root zone, but require two - valid signatures for the top-most KEY for validation to - succeed. I.e. threshold validation does not force multiple - signatures on the entire signature chain, only on the top-most - signature, closest to the security apex for which the resolver has - trusted keys. - -5.2. Not All Trusted Keys Will Be Available - - With multiple KSKs held and managed by separate entities the end - resolvers will not always manage to get access to all possible - trusted keys. In the case of just a single KSK this would be fatal - to validation and necessary to avoid at whatever cost. But with - several fully trusted keys available the resolver can decide to - trust several of them individually. An example based upon more - pseudo-configuration: - - security-apex "." IN { - keys { ksk-1 .... ; - ksk-2 .... ; - ksk-3 .... ; - ksk-4 .... ; - ksk-5 .... ; - }; - validation { - # Only these two keys are trusted independently - keys { ksk-1; ksk-4; }; - # With these keys a single signature is sufficient - needed-signatures 1; - }; - }; - - Here we have the same five keys and instruct the validating - resolver to fully trust data that ends up with just one signature - from by a fully trusted key. - - The typical case where this will be useful is for the case where - there is a risk of the resolver not catching a rollover event by - one of the KSKs. By doing rollovers of different KSKs with - different schedules it is possible for a resolver to "survive" - missing a rollover without validation breaking. This improves - overall robustness from a management point of view. - -5.3. Not All Possible KSKs Need to Be Trusted - - With just one key available it simply has to be trusted, since that - is the only option available. With multiple KSKs the validating - resolver immediately get the option of implementing a local policy - of only trusting some of the possible keys. - - This local policy can be implemented either by simply not - configuring keys that are not trusted or, possibly, configure them - but specify to the resolver that certain keys are not to be - ultimately trusted alone. - - -6. Additional Benefits from Having Multiple KSKs - -6.1. More Robust Key Rollovers - - With only one KSK the rollover operation will be a delicate - operation since the new trusted key needs to reach every validating - resolver before the old key is retired. For this reason it is - expected that long periods of overlap will be needed. - - With multiple KSKs this changes into a system where different - "series" of KSKs can have different rollover schedules, thereby - changing from one "big" rollover to several "smaller" rollovers. - - If the resolver trusts several of the available keys individually - then even a failure to track a certain rollover operation within - the overlap period will not be fatal to validation since the other - available trusted keys will be sufficient. - -6.2. Evaluation of Multiple Key Distribution Mechanisms - - Distribution of the trusted keys for the DNS root zone is - recognized to be a difficult problem that ... - - With only one trusted key, from one single "source" to distribute - it will be difficult to evaluate what distribution mechanism works - best. With multiple KSKs, held by separate entitites it will be - possible to measure how large fraction of the resolver population - that is trusting what subsets of KSKs. - - -7. Security Considerations - - From a systems perspective the simplest design is arguably the - best, i.e. one single holder of both KSK and ZSKs. However, if that - is not possible in all cases a more complex scheme is needed where - additional trust is injected by using multiple KSK holders, each - contributing trust, then there are only two alternatives - available. The first is so called "split keys", where a single key - is split up among KSK holders, each contributing trust. The second - is the multiple KSK design outlined in this proposal. - - Both these alternatives provide for threshold mechanisms. However - split keys makes the threshold integral to the key generating - mechanism (i.e. it will be a property of the keys how many - signatures are needed). In the case of multiple KSKs the threshold - validation is not a property of the keys but rather local policy in - the validating resolver. A benefit from this is that it is possible - for different resolvers to use different trust policies. Some may - configure threshold validation requiring multiple signatures and - specific keys (optimizing for security) while others may choose to - accept a single signature from a larger set of keys (optimizing for - redundancy). Since the security requirements are different it would - seem to be a good idea to make this choice local policy rather than - global policy. - - Furthermore, a clear issue for validating resolvers will be how to - ensure that they track all rollover events for keys they - trust. Even with operlap during the rollover (which is clearly - needed) there is still a need to be exceedingly careful not to miss - any rollovers (or fail to acquire a new key) since without this - single key validation will fail. With multiple KSKs this operation - becomes more robust, since different KSKs may roll at different - times according to different rollover schedules and losing one key, - for whatever reason, will not be crucial unless the resolver - intentionally chooses to be completely dependent on that exact key. - -8. IANA Considerations. - - NONE. - - -9. References - -9.1. Normative. - - [RFC2535] Domain Name System Security Extensions. D. Eastlake. - March 1999. - - [RFC3090] DNS Security Extension Clarification on Zone Status. - E. Lewis. March 2001. - - -9.2. Informative. - - [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System - (DNS). D. Eastlake 3rd. May 2001. - - [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. - December 2001. - - [DS] Delegation Signer Resource Record. - O. Gudmundsson. October 2002. Work In Progress. - -10. Acknowledgments. - - Bill Manning came up with the original idea of moving complexity - from the signing side down to the resolver in the form of threshold - validation. I've also had much appreciated help from (in no - particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and - Olaf Kolkman. - - -11. Authors' Address -Johan Ihren -Autonomica AB -Bellmansgatan 30 -SE-118 47 Stockholm, Sweden -johani@autonomica.se diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt deleted file mode 100644 index f9eaf268..00000000 --- a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt +++ /dev/null @@ -1,1830 +0,0 @@ - - - - INTERNET-DRAFT S. Daniel Park - Expires: October 2003 Syam Madanapalli - File: SAMSUNG Electronics - draft-park-ipv6-extensions-dns-pnp-00.txt April 2003 - - - - - IPv6 Extensions for DNS Plug and Play - - - - Status of This Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - - Abstract - - This document proposes automatic configuration of domain name (FQDN) - for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as - a part of IPv6 plug and play feature. 6DNAC allows the automatic - registration of domain name and corresponding IPv6 Addresses with - the DNS server. In order to provide 6DNAC function, Neighbor Discovery - Protocol [2461] will be used. Moreover, 6DNAC does not require any - changes to the existing DNS system. - - - Table of Contents - - 1. Introduction ............................................. 3 - 2. Terminology .............................................. 3 - 3. 6DNAC Design Principles .................................. 4 - 4. 6DNAC Overview ........................................... 4 - 5. 6DNAC Requirements ....................................... 5 - 5.1. 6DANR Client Requirements ................................ 5 - 5.2. 6DNAC Server Requirements ................................ 6 - -Park & Madanapalli Expires October 2003 [Page 1] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 6. 6DNAC Messages and Option Formats ........................ 6 - 6.1. Router Advertisement (RA) Message Format ................. 6 - 6.2. Neighbor Solicitation (NS) Message Format ................ 7 - 6.3. Neighbor Advertisement (NA) Message Format ............... 8 - 6.4. Option Formats ........................................... 8 - 6.4.1. DNS Zone Suffix Information Option Format ................ 8 - 6.4.2. Domain Name (FQDN) Option Format ......................... 9 - 6.4.3. Router Alert Option for 6DNAC ............................ 10 - 7. 6DNAC Operation .......................................... 10 - 7.1. 6DNAC Network Topology ................................... 11 - 7.2. 6DNAC Operational Scenarios .............................. 12 - 7.2.1. Domain Name Registration-Success Case .................... 12 - 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14 - 7.2.3. Domain Name Registration-Defend Case ..................... 16 - 7.2.4. Domain Name Registration in Retry Mode ................... 19 - 7.2.5. Domain Name Registration when DAD Fails .................. 20 - 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22 - 7.3.1. Sending Router Advertisement Messages .................... 22 - 7.3.2. Processing Router Advertisement Messages ................. 22 - 7.3.3. FQDN Lifetime expiry ..................................... 23 - 7.3.4. Host Naming Algorithm .................................... 23 - 7.4. Duplicate Domain Name Detection .......................... 23 - 7.4.1. DAD with All Nodes Multicast Address ..................... 24 - 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24 - 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24 - 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25 - 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25 - 7.4.1.5. Pros and Cons ............................................ 25 - 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25 - 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25 - 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26 - 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26 - 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26 - 7.4.2.5. Pros and Cons ............................................ 26 - 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26 - 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26 - 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26 - 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27 - 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27 - 7.4.3.5. Pros and Cons ............................................ 27 - 7.4.4. Retry Mode for Re-registering Domain Name ................ 27 - 7.5. Domain Name Registration ................................. 27 - 8. Security Consideration ................................... 27 - 9. IANA Consideration ....................................... 28 - 10. Acknowledgement .......................................... 28 - 11. Intellectual Property .................................... 28 - 12. Copyright ................................................ 28 - 13. References ............................................... 29 - 14. Author's Addresses ....................................... 30 - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 2] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 1. Introduction - - Today, most networks use DNS[1034][1035] for convenience. In case of - IPv6, DNS is more important element because of IPv6 long addresses - which are difficult to remember. In addition, small networks like home - networks using IPv6, should be able to make network easily without - manual configuration. Also, these small networks may not have DHCP - Server, DNS Server etc. that are used to configure the network. This - document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure - for generating and registering the Domain Name and IPv6 addresses with - the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are - required to implement lightweight functions specified in this document. - 6DNAC can be applied to all defined IPv6 unicast addresses except Link - local IPv6 addresses, viz: Site-local and Global addresses. - - 6DNAC uses Neighbor Discovery Protocol [2461] with new additions - (defined in section 6) and DAD procedures for generating and - registering the Domain Name with the DNS server automatically. - - - 2. Terminology - - 6DNAC - IPv6 Domain Name Auto Configuration. It can provide - IPv6 hosts with Domain Name Generation and - Registration automatically. - - 6DNAC Client - An IPv6 node that can generate its own unique Domain - Name. Section 3 identifies the new requirements that - 6DNAC places on an IPv6 node to be a 6DNAC node. - - 6DNAC Server - An IPv6 node that can collect and registrate Domain - Name and IPv6 addresses automatically. 6DNAC server - uses the information from the DAD operation messages - with newly defined options for the registration of the - Domain Name and IPv6 Addresses. Section 3 identifies - the new requirements that 6DNAC places on an IPv6 - node to be a 6DNAC server. Also 6DNAC server can have - various other functions depending on network - environment and the network operator. For instance - 6DNAC Server can acts as a Gateway as well Home Server - in Home Networks. - - DAD - Duplicate Address Detection (is defined [2461]) - - DFQDND - Duplicate Domain Name Detection - - FQDN - Fully Qualified Domain Name - FQDN and Domain Name are - used interchangeably in this document. - - NA - Neighbor Advertisement message (is defined [2461]) - - NS - Neighbor Solicitation message (is defined [2461]) - - RA - Router Advertisement message (is defined [2461]) - - SLAAC - Stateless Address Autoconfiguration [2462]. - -Park & Madanapalli Expires October 2003 [Page 3] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 3. 6DNAC Design Principles - - This section discusses the design principles of 6DNAC mechanism. - - 1. The new procedures for plug and play DNS should not cause changes - to existing DNS system. 6DNAC requires lightweight functions to be - implemented only at the client side of the DNS system, and uses the - existing DDNS UPDATE [2136] to communicate with DNS Servers. - - 2. Introducing a new protocol will always introduce new problems. - 6DNAC uses the existing protocols NDP [2461] with minor extensions - for generating and registering the domain name automatically - without defining a new protocol - - 3. Reusing proven and well understood design principles/patterns - will always yield a robust system. 6DNAC is based on IPv6 Address - Auotoconfiguration principle, where routers advertise the prefix - and host adds the interface ID to the prefix and forms the IPv6 - address. Domain Name (FQDN) also contains two parts: host name - and DNS zone suffix. Routers can advertise the DNS zone suffix - on a particular link in Router Advertisements (RA Messages) and - hosts can prefix their preferred host name to the DNS zone suffix - and form the fully qualified domain name. Also the detection of - duplicate domain name is similar to Duplicate Address Detection - (DAD) and can be part of DAD operation itself. - - - 4. 6DNAC Overview - - 6DNAC proposes minor extensions to NDP [2461] for automatic generation - and registration of domain name with the DNS server. It introduces two - new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone - Suffix option is carried in Router Advertisement (RA) messages for - notifying IPv6 nodes about the valid DNS Zone Suffix on the link and - FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement - (NA) messages to detect duplicate domain name. 6DNAC consists of two - components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the - domain name based on DNS Zone Suffix using Host Naming Algorithm (see - section 7.3.1) and 6DNAC Server collects and registers the DNS - information with the DNS Server on behalf of 6DNAC Clients. - - The automatic configuration of domain name using 6DNAC consists of - three parts. - - - DNS Zone Suffix Discovery and FQDN Construction: - - IPv6 Nodes collect DNS Zone Suffix information from Router - Advertisements and constructs FQDN by prefixing host name to the - DNS Zone Suffix. The IPv6 Nodes are required to implement Host - Naming Algorithm for generating host part of the FQDN in the - absence of administrator. - - Generation of node's FQDN within the node itself has advantages. Nodes - can provide forward and reverse name lookups independent of the DNS - System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain - Name is some thing that is owned by the node. - -Park & Madanapalli Expires October 2003 [Page 4] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - Duplicate Domain Name Detection - - All nodes are expected to go for DAD for all new IPv6 unicast - addresses, regardless of whether they are obtained through - stateful, stateless or manual configuration. 6DNAC uses the DAD - messages with new option for carrying the Domain Name along with - the new IPv6 Address. 6DNAC Server captures this information and - updates DNS Server provided that the IPv6 Address and its domain - name are not duplicate. If the domain name is already in use, - the 6DNAC server replies to the sender with FQDN Option in NA - message indicating that the domain name is duplicate. Then the - node is expected to generate another domain name using host - naming algorithm and go for DAD. This time the DAD is only for - duplicate domain name detection (DFQDND). In order to avoid - confusion with the normal NDP processing, the target address - field of the NS message must carry the unspecified address - in retry mode. This can be repeated depending on number of - retries defined by the administrator in the host naming algorithm. - - - - Domain Name Registration - - 6DNAC Server detects the DNS information (IPv6 Address and - corresponding FQDN) from DAD/DFQDND messages and updates DNS - Server using existing protocol DDNS UPDATE [2136] provided that - the IPv6 Address and its domain name are not duplicate. - - If an IPv6 Address is duplicate, the IPv6 node cannot perform - stateless address autoconfiguration repeatedly. Unlike IPv6 stateless - address autoconfiguration, 6DNAC allows the automatic configuration of - domain name repeatedly if the domain name is duplicate depending on - number of retries defined by the administrator in the host naming - algorithm. - - - 5. 6DNAC Requirements - - Depending on the 6DNAC functionality, the IPv6 nodes implement, they - are called either 6DNAC Clients or 6DNAC Servers. The following - sections lists the requirements that the 6DNAC Client and 6DNAC server - must support. - - - 5.1. 6DANC Client Requirements - - - 6DNAC Client must recognize and process the following NDP - extensions - - - DNS Zone Suffix option in RA messages for generating its - domain name (FQDN). - - - Domain Name option in NS and NA messages for detecting - the duplicate domain name - - - - -Park & Madanapalli Expires October 2003 [Page 5] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - It must generate its domain name (FQDN) based on the DNS - suffix that it got from the router advertisement. And it must - have a host naming algorithm for generating the host part of - the FQDN. - - - If NA message is received with unspecified target address and - FQDN option, then the node must treat that the domain is - duplicate. - - - 5.2. 6DNAC Server Requirements - - - 6DNAC Server must recognize and process the following NDP - extensions - - - If the 6DNAC Server is a router on the link, then it - must advertise DNS Zone Suffix option in RA messages - for hosts to generate their domain name (FQDN). - - - FQDN option in NS messages for detecting new DNS - information for of nodes on the link for which it - must update the AAAA RR and PTR RR in DNS Server. - - - FQDN option in NA messages for notifying duplicate - domain name with unspecified target address. - - - 6DNAC server must update the DNS Server (both AAAA RR and - PTR RR) dynamically using DDNS UPDATE [2136]. - - - 6DNAC server must cache this (newly detected) FQDN, Link - Layer Address, and IPv6 Address information, so that it can - decide whether it really needs to update DNS Server or not, - to avoid redundant updates. This information will also be - used for notifying the duplicate domain name. - - - 6. 6DNAC Messages and Option Formats - - In order to achieve the plug and play DNS, 6DNAC proposes new - extensions to the NDP [2461]. This section specifies the new - additions to NDP messages and formats of new options. - - - 6.1. Router Advertisement (RA) Message Format - - Routers send out Router Advertisement (RA) message periodically, or - in response to a Router Solicitation. 6DNAC does not modify the format - of the RA message, but proposes new option (DNS Zone Suffix Information) - to be carried in RA messages. - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 6] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Cur Hop Limit |M|O| Reserved | Router Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reachable Time | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Retrans Timer | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | DNS Zone Suffix Information | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - <Figure: 1 RA message> - - - - 6.2. Neighbor Solicitation (NS) Message Format - - 6DNAC does not modify the format of the Neighbor Solicitation (NS) - message, but proposes new option (FQDN Option) to be carried in NS - messages. When a node is going for DAD, the node must include FQDN - option in NS message to participate in plug and play DNS. If the - node is going for Explicit Detection of Duplicate Domain Name, the - node must use FQDN option in NS message and unspecified address in - the target address field. - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | Domain Name | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - <Figure: 2 NS message> - -Park & Madanapalli Expires October 2003 [Page 7] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 6.3. Neighbor Advertisement (NA) Message Format - - 6DNAC does not modify the format of the Neighbor Advertisement (NA) - message, but proposes new option (FQDN Option) to be carried in NA - messages. 6DNAC Server sends NA message with FQDN option to 6DNAC - Client that is performing duplicate domain name detection in case - the domain name found to be duplicate. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |R|S|O| Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | FQDN Option | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - <Figure: 3 NA message> - - - 6.4 Option Formats - - 6.4.1. DNS Zone Suffix Information Option Format - - IPv6 nodes require DNS Zone Suffix for constructing their FQDN. - 6DNAC introduces new option for routers to advertise the DNS Zone - Suffix Information for IPv6 nodes on the link. The suffix information - should be configured into routers manually. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Valid Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - / DNS Zone Suffix / - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - <Figure: 4 DNS Zone Suffix Information> - -Park & Madanapalli Expires October 2003 [Page 8] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - Type [TBD] - - Length 8-bit unsigned integer. The length of the option - (including the type and length fields) in units of - 8 octets. - - Reserved This field is unused. It must be initialized to zero - by the sender and must be ignored by the receiver. - - Valid Life Time 32-bit signed integer. The maximum time, in - seconds, over which this suffix is valid. Nodes - should treat this as the life time for their domain - name. Nodes should contact the source of this - information before expiry of this time interval. - A value of all one bits (0xFFFFFFFF) represents - infinity. - - DNS Zone Suffix The suffix part of the FQDN. The data in the DNS - Zone Suffix field should be encoded according to - DNS encoding rules specified in [1035]. - - - - 6.4.2. Domain Name (FQDN) Option Format - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Valid Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + FQDN Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - / Domain Name / - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - <Figure: 5 FQDN Information> - - Type [TBD] - - Length 8-bit unsigned integer. The length of the option - (including the type and length fields) in units - of 8 octets. It must be greater than 3. - - - -Park & Madanapalli Expires October 2003 [Page 9] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - Reserved This field is unused. It must be initialized to - zero by the sender and must be ignored by the - receiver. - - Valid Life Time 32-bit signed integer. The maximum time, in - seconds, over which this domain name is valid - 6DNAC should deregister this domain name at - the expiry of this interval. 6DNAC clients - should send updates by the expiry of this - interval. A value of all one bits (0xFFFFFFFF) - represents infinity. - - FQDN Target Address The Address for which the FQDN maps to. It - should be same as Target Address field of the - NS message in case of DAD & duplicate FQDN are - running in parallel. - - Domain Name The domain name (FQDN) of the node. The data in - the domain name should be encoded according to - DNS encoding rules specified in [1035]. - - - 6.4.3. Router Alert Option for 6DNAC - - Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop - Header for using in NDP messages. The presence of this option in NS - message informs the router that this NS message is carrying Domain - Name information and must be processed by the 6DNAC Server on the router. - 6DNAC Clients can use this option for sending DAD packets instead - of addressing the DAD packets to the all-nodes multicast address - when 6DNAC Server is implemented on router. - - The Router Alert option has the following format: - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Length = 2 - - Values are registered and maintained by the IANA. For 6DNAC, the - value has to be assigned by IANA. - - Further information about this option can be obtained from - IPv6 Router Alert Option [2711]. - - - 7. 6DNAC Operation - - 6DNAC provides mechanisms for automatic generation of domain name - and registering it with the DNS Server for IPv6 nodes. 6DNAC consists - of two components: 6DNAC Client and 6DNAC Server. All nodes that want - to participate in plug and play DNS are required to implement 6DNAC - Client functionality, and one of the IPv6 nodes is required to - implement 6DNAC Server functionality. The IPv6 node that implements - the 6DNAC Server functionality must know the location of the DNS - Server and must be a trusted node to send DDNS UPDATE [2136] messages. - -Park & Madanapalli Expires October 2003 [Page 10] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 7.1. 6DNAC Network Topology - - This section identifies the possible locations for the 6DNAC Server. - Note that, all nodes are required to implement 6DNAC Client - functionality for constructing the domain name from the DNS Zone - Suffix Information advertised by the router. Figure 6 illustrates - IPv6 host (H4) implementing 6DNAC Server functionality. In this case - H4 can serve only one link (that it belongs to) for automatic - registration of domain name. H4 must observe the DAD packets on the - link to detect the DNS information, this requires all nodes on the - link must belong to same solicited node multicast address. In general, - this may not be the case. So the node that is going for DAD must use - all nodes multicast address for DAD packets, so that the 6DNAC Server - (H4) can observe the DAD packets, detects IPv6 address and - corresponding domain name, checks if this domain name is duplicate - and finally registers the domain name with the DNS Server. - - - 6DNAC Server - +---+ +---+ +----------+ - | H1| | H4|<--- DDNS UPDATE --->|DNS Server| - +-+-+ +-+-+ +----+-----+ - | | +----+ +---/ - | | | | / - ---+-----+-----------+-----+-----------+ R1 +-----+ - | | | | - | | +----+ - +-+-+ +-+-+ - | H2| | H3| - +---+ +---+ - - - H1, H2, H3 - 6DNAC Clients - H4 - 6DNAC Server - R1 - Router - - - <Figure: 6 Example of 6DNAC Topology> - - - Figure 7 shows the 6DNAC Server implemented on a router R1. In this - case a single 6DNAC server can serve multiple links for automatic - configuration of the domain name. This topology also has flexibility - of using DAD packets with Router Alert option instead of sending DAD - packets to all nodes multicast address. The routers are required to - process all the packets with Router Alert option as per [2711]. - - In case of Home Networks, R1 is will acts as a Home Gateway (CPE) - connected to ISP. R1 delegates the prefix from the ISP edge router. - After delegating the prefix the CPE can advertise the DNS Zone suffix - along with the prefix information to the nodes on the links to which - the router is connected to. Note that the R1 must be configured with - the DNS Zone suffix Information manually. - - - - -Park & Madanapalli Expires October 2003 [Page 11] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---+ +---+ - | H3+ | H4| - +-+-+ +-+-+ - | | - | LINK2 | - +---+ ---+--------+--+-- +----------+ - | H1| | |DNS Server| - +-+-+ | +----+-----+ - | +--+-+ -------/ - | LINK 1 | | / - ---+-----+------------------+ R1 +---------+ - | | | DDNS UPDATE - | +----+ - +-+-+ 6DNAC Server - | H2| - +---+ - - - H1, H2 - 6DNAC Clients on Link1 - H3, H4 - 6DNAC Clients on Link2 - R1 - Router with 6DNAC Server, serving both Link1 and Link2 - - - <Figure: 7 Example of 6DNAC Server serving multiple links> - - - 7.2. 6DNAC Operational Scenarios - - This section provides message sequence charts for various 6DNAC - operational scenarios assuming that the 6DNAC Server is implemented - on a router. All the scenarios assume that the normal boot up time - stateless address autoconfiguration of Link Local address derived - from the Interface Identifier has been completed successfully. And - it is also assumed that the router is already configured with the - DNS Zone Suffix Information. - - - Legend: - - 6DNAC-A, B, C : 6DNAC Clients - 6DNAC-S : 6DNAC Server/Router - DAD : Duplicate Address Detection - DFQDND : Duplicate Domain Name Detection - DNS-S : DNS Server - - - 7.2.1. Domain Name Registration-Successful Case - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. It is Assumed that the - DupAddrDetectTransmits is set to 1. - - - - -Park & Madanapalli Expires October 2003 [Page 12] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - | RA with | | - | DNS Suffix Opt | | - |<---------------| | - | #1 | | - |---+ | | - Construct |#2 | | - FQDN | | | - |<--+ | | -DAD/DFQDND Starts | | - | | | - | | | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #3 | | - | | | - | |------+ | - | Create FQDN | #4 | - | <FQDN,C> | | - | |<-----+ | - | | | - | | Register FQDN | - | |--------------->| - | | #5 | - | #6 | | - |--------+ | | - No Response | | | - DFQDND-Success | | | - |<-------+ | | - | | | - | | | - v V v - - - <Figure: 8 Domain Name Generation and Registration> - - - #1. 6DNAC Server (Router) sends out router advertisement with DNS - Suffix information along with other parameters as specified in - NDP [2461]. - - #2. 6DNAC Client processes the router advertisement and constructs - the FQDN by prefixing hostname to the DNS Zone Suffix. It also - constructs IPv6 address from the autoconfiguration prefix - information option. - - #3. 6DNAC Client starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor - Solicitation message with FQDN option. - - Note that the DAD packets must be addressed to all nodes multicast - address if Router Alert option is not used. - -Park & Madanapalli Expires October 2003 [Page 13] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #4. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client as part of duplicate FQDN detection procedure and - creates a FQDN entry in its FQDN Cache (assuming that there is no - entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client. - - #5. 6DNAC Server then registers FQDN and corresponding IPv6 address - through the existing protocol DDNS UPDATE. - - #6. 6DNAC Client times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name. - - Note that, Stateless Address Autoconfiguration DAD procedure is not - depicted in the following message sequence chart, which simultaneously - happens along with duplicate FQDN detection. - - - 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. The node is configured with - DupAddrDetectTransmits = 2 for reliability in delivering DAD messages. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 14] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - | RA with | | - | DNS Suffix Opt | | - |<---------------| | - | #1 | | - |---+ | | - Construct |#2 | | - FQDN | | | - |<--+ | | -DAD/DFQDND Starts | | - | | | - | | | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #3 | | - | | | - | |------+ | - | Create FQDN | #4 | - | <FQDN,C> | | - | |<-----+ | - | | | - | | Register FQDN | - | |--------------->| - | | #5 | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #6 | | - | | | - | Lookup FQDN | - | Entry exists | - | |------+ | - | Ignore | #7 | - | |<-----+ | - | #8 | | - |--------+ | | - No Response | | | - DFQDND-Success | | | - |<-------+ | | - | | | - | | | - v V v - - - - <Figure: 9 Verification of duplicated Domain Name> - - - Steps from #1 to #5 are same as that of scenario.7.2.1. - - #6. 6DNAC Client sends out second Neighbor Solicitation message with - FQDN option as part of duplicate FQDN detection. - -Park & Madanapalli Expires October 2003 [Page 15] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #7. 6DNAC Server receives and observes that the FQDN Cache exactly - matches with that of the NS information and ignores the NS message. - - #8. 6DNAC Client times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name.. - - - 7.2.3. Domain Name Registration-Defend Case - - This scenario starts when two 6DNAC Client receive RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and both the nodes want configure their IPv6 - address (Global or Site Local) and domain name. In this scenario both - the nodes want to have same domain name. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 16] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - - +---------+ +---------+ +---------+ +---------+ - | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | - +----+----+ +----+----+ +----+----+ +----+----+ - | | | | - | RA with | RA with | | - | DNS Suffix Opt | DNS Suffix Opt | | - |<---------------|--------------->| | - | #1 | #1 | | - |---+ | |---+ | - Construct | #2 | Construct | #2 | - FQDN | | FQDN | | - |<--+ | |<--+ | - DAD/DFQDND Starts | DAD/DFQDND Starts | - | | <DELAYED> | - | | | | - | NS with | | | - | FQDN Opt | | | - |--------------->| | | - | #3 | | | - | No Entry | | - | |------+ | | - | Create FQDN | #4 | | - | <FQDN,A> | | | - | |<-----+ | | - | | | | - | | Register FQDN #5 | - | |-------------------------------->| - | | | | - | | NS with | | - | | FQDN Opt | | - | |<---------------| | - | | #6 | | - | |------+ | | - | FQDN is in use| | | - | Defend DFQDND| #7 | | - | |<-----+ | | - | | | | - | | NA with | | - | | D-flag Set | | - | |--------------->| | - | | #8 | | - |------+ | |---+ | - No Response | #9 | Enter | #10 | - DFQDND Success| | Retry Mode| | - |<-----+ | |<--+ | - | | | | - v v v v - - - <Figure: 10 Multiple Hosts Requesting Same Domain Name> - - - - - -Park & Madanapalli Expires October 2003 [Page 17] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #1. 6DNAC Server (Router) sends out router advertisement with DNS - Suffix information. - - #2. 6DNAC Clients A&B process the router advertisement and construct - their FQDN by prefixing hostname to the DNS Zone Suffix. They - also construct IPv6 address from the autoconfiguration prefix - information option. - - When each host is trying to go for DAD, all hosts must have - random delay to avoid the traffic congestion according to [2461]. - So here it is assumed that 6DNAC Client-A starts DAD first and - 6DNAC Client-B starts DAD later. - - #3. 6DNAC Client-A starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor - Solicitation message with FQDN option. - - #4. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client-A as part of duplicate FQDN detection procedure and - creates a FQDN entry in its FQDN Cache (assuming that there is no - entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A. - - #5. 6DNAC Server then registers FQDN and corresponding IPv6 address - through the existing protocol DDNS UPDATE. - - #6. 6DNAC Client-B starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor Solicitation - message with FQDN option. - - #7. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client-B as part of duplicate FQDN detection procedure and - finds that the domain name is already in use by the 6DNAC Client-A. - Hence, concludes to defend the duplicate FQDN detection of 6DNAC - Client-B. - - #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN - option to 6DNAC Client-B to defend its duplicate FQDN detection. - - #9. 6DNAC Client-A times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name. - - #10. 6DNAC Client-B observes that there is a NA with FQDN option - indicating that the domain name is duplicate and enters Retry - Mode. In retry mode, 6DNAC Client constructs another FQDN based - on Host Naming Algorithm. The number of retries is defined by the - administrator and must be a configurable value. - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 18] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 7.2.4. Domain Name Registration in Retry Mode - - Pre-Conditions: - - 1. Duplicate Address Detection has succeeded - 2. Duplicate FQDN Detection FAILED - 3. FQDN is the first FQDN one constructed and FAILED - 4. FQDN2 is the second FQDN to be constructed - 5. The Neighbor Solicitation in the 'Retry Mode' - carries unspecified address in its target field (NS*). - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - |--------+ | | - Construct | #1 | | - new FQDN2 | | | - |<-------+ | | - | | | - DFQDND Restarts | | - | | | - | | | - | NS* With | | - | FQDN Opt | | - |--------------->| | - | #2 | | - | | | - | No Entry | - | |------+ | - | Create FQDN | #3 | - | <FQDN2,C> | | - | |<-----+ | - | | | - | | Register FQDN2 | - | |--------------->| - | | #4 | - | | | - |--------+ | | - No Response | #5 | | - DFQDND-Success | | | - |<-------+ | | - | | | - v V v - - - <Figure: 11 Regeneration of Domain Name> - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 19] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm, - the DNS Zone Suffix, and it is FQDN2. - #2. It then starts Duplicate Detection only for Domain Name. 6DNAC - Client sends out NS with FQDN option and unspecified target - address. - - #3. 6DNAC Server processes the Retry Mode NS message and finds that - the FQDN2 is not in use and creates Cache entry as <FQDN2, C>. - - #4. It then starts registration procedures with the DNS Server. - - #5. Meanwhile, 6DNAC Client timesout and observes that there is no - defending NA for its DFQDND NS sent out and successfully - configures its domain name. - - - 7.2.5. Domain Name Registration when DAD Fails - - Duplicate domain name detection and subsequent registration starts - if and only if the DAD for IPv6 address succeeds. If the DAD for - IPv6 address fails then no actions are taken for domain name. When - DAD fails for stateless address autoconfiguration, then the domain - configuration starts only when the address has been configured using - Stateful Address Configuration methods and the node is going on DAD - for this address. - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 20] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ +---------+ - | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | - +----+----+ +----+----+ +----+----+ +----+----+ - | | | | - | | | | - | RA with | | | - | DNS Suffix Opt | | | - |<---------------| | | - | #1 | | | - |-----+ | | | - Construct | | | | - FQDN& | #2 | | | - IPv6 Addr | | | | - |<----+ | | | - DAD/DFQDND Starts | | | - | | | | - | | | | - | NS with | | | - | FQDN Opt | | | - |--------------->+--------------->| | - | #3 | #3 | | - | No Entry | | - | |------+ | | - | Create FQDN | | | - | <FQDN,A> | #4 | | - | |<-----+ | | - | | | | - | | |------+ | - | | My IPv6 Addr| #5 | - | | |<-----+ | - | | Defend DAD | | - | | with NA | | - |<---------------+<---------------| | - | #6 | #6 | | - | Entry | | - | |------+ | | - | Delete FQDN | #7 | | - | |<-----+ | | - | | | | - |----+ | | | - DAD Failed | #8 | | | - Stop DFQDND | | | | - |<---+ | | | - | | | | - v v v v - - <Figure: 12 DAD failure> - - #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A. - - #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and - FQDN as per Host Naming Algorithm. - - #3. It then starts Duplicate address & FQDN Detection, for the newly - constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS - with FQDN option. - -Park & Madanapalli Expires October 2003 [Page 21] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #4. 6DNAC Server processes the DAD/DFQDND NS message and finds - that there is no entry for the FQDN in its cache. And, - creates Cache entry as <FQDN, A> and starts a Registration - timer with RegistrationWaitTime seconds. - - #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is - in its unicast address list. - - #6. It then starts defending DAD by sending NA to all-nodes multicast. - - #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A. - And, deletes its FQDN Cache entry <FQDN,A>. - - #8. 6DNAC Client gets defending DAD-NA and desists from DAD. - And also, stops Duplicate FQDN Detection as well. - At this point the address must be configured using stateful - methods and the domain name registration starts with the DAD - for the newly constructed IPv6 address. - - 7.3. DNS Zone Suffix Discovery and FQDN Construction - - 7.3.1. Sending Router Advertisement Messages - - Routers send out Router Advertisement message periodically, - or in response to a Router Solicitation. Router should include - the DNS Zone Suffix Option in their advertisements. If the DNS - Zone Suffix changes (similar to Site Renumbering), then it should - advertise the Old Zone Suffix with zero Valid Lifetime and New - Zone Suffix with proper non-zero Valid Lifetime. In any other - case, a router should not send this option twice in a single - router advertisement. - - 7.3.2. Processing Router Advertisement Messages - - For each DNS Zone Suffix Option in Router Advertisement, - - a. 6DNAC node stores the Zone Suffix information in its local - database. Also, constructs FQDN as per Host Naming Algorithm. - - b. If the node has not configured FQDN yet, - - 1. If the node is going to perform DAD for either Site local or - Global Address, then it should include FQDN option to perform - Duplicate FQDN Detection in parallel with DAD. - - 2. If the node has already got either Site local or Global - address, then it should send out NS with FQDN option and - unspecified target address to perform Duplicate FQDN - Detection. - - c. If the node has already configured FQDN, and if the - advertisement carries two DNS Zone Suffix Options, - First DNS Zone Suffix should match with the configured FQDN - Suffix and its Valid Lifetime must be zero. Second DNS Zone - - - -Park & Madanapalli Expires October 2003 [Page 22] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - Suffix should have non-zero Valid Lifetime. In this case, the - node constructs new FQDN based on the new DNS Zone Suffix (from - second DNS Zone Suffix option), and perform Duplicate FQDN - Detection with unspecified target address. Also, it should - overwrite the old FQDN with the newly constructed FQDN. - - - 7.3.3. FQDN Lifetime expiry - - 6DNAC Server: - It should delete the FQDN cache entry and should de-register from - the DNS Server. - - 6DNAC Client: - It should send update to 6DNAC Server by restarting the Duplicate - FQDN Detection. - - 7.3.4. Host Naming Algorithm - - A node constructs FQDN by combining DNS Zone Suffix and the hostname - as depicted in the following diagram. - - +------------------+----------------------------------+ - | Host Name | Advertised Suffix | - +------------------+----------------------------------+ - - <Figure 13: Fully Qualified Domain Name format> - - A node can choose Host Name using any of the following methods: - - a. String form of random number generated from the Interface - Identifier. - - b. List of configured Host Names provided by the administrator. - - - The number of retries must be specified in this algorithm in - case of domain name duplication. - - - 7.4. Duplicate Domain Name Detection - - The procedure for detecting duplicated FQDNs uses Neighbor - Solicitation and Advertisement messages as described below. - - If a duplicate FQDN is detected during the procedure, the - FQDN cannot be assigned to the node. - - An FQDN on which the DFQDND Procedure is applied is said - to be tentative until the procedure has completed successfully. - A tentative FQDN is not considered "assigned to the node" in the - traditional sense. That is, the node must accept Neighbor - Advertisement message containing the tentative FQDN in the FQDN - Option. - - -Park & Madanapalli Expires October 2003 [Page 23] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - It should also be noted that DFQDN must be performed prior to - registering with DNS Server to prevent multiple nodes from using - the same FQDN simultaneously. All the Duplicate Address Detection - Neighbor Solicitation messages must carry Source Link Layer Address - Option as specified in NDP [2461]. - - The detection of duplicate FQDN can be achieved through one of the - following three types of procedures. - - 1. DAD with All Nodes Multicast Address - 2. DAD with Router Alert Option for 6DNAC. - 3. Explicit Detection of Duplicate Domain Name - - Even though three solutions are listed, authors prefer only one - procedure to be followed in future based on further analysis and - comments received from others. - - 7.4.1. DAD with All Nodes Multicast Address - - 7.4.1.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate Address Detection SLAAC [2462] with the following - extra information and modifications: - - a. Include FQDN Option in the DAD Neighbor Solicitation Message - b. Destination Address is set to All Nodes Multicast Address - - There may be a case where DAD has succeeded but DFQDND is in Retry - Mode. In such case, the Neighbor Solicitation must carry unspecified - address in the ICMP target address field and new domain name in FQDN - option to re-try the registration of the domain name. - - 7.4.1.2. Processing Neighbor Solicitation Messages - - 6DNAC Clients must ignore the FQDN option found in any of the - neighbor solicitation messages. - - 6DNAC Server processes FQDN Option found in the Duplicate Address - Detection Neighbor Solicitation Messages as described below: - - Lookup FQDN Cache for the domain name in FQDN Option. - - If the entry exists and - i. Link Layer Address matches with SLLA option, this is the case, - where node has changed its IPv6 address or updating the valid - life time. 6DNAC Server updates its cache and also updates DNS - Server using DDNS-UPDATE. If there is no change in IPv6 address - or life time then no updates are sent to the DNS server. - - ii. Link Layer Address differs with SLLA option, defend the duplicate - FQDN Detection by sending Neighbor Advertisement Message as - described in $7.4.1.3$. - - - -Park & Madanapalli Expires October 2003 [Page 24] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - else, - Lookup FQDN Cache for the Link Layer Address in SLLA Option. - - If the entry exists, update the FQDN Cache and update DNS Server - using DDNS-UPDATE. This is the case, where node has changed its - domain name (similar to Site Re-numbering). - - If then entry does not exists, then it means that this is the new - registration. It must create a cache entry and start Registration - - timer with RegistrationWaitTime. At the expiry of the Registration - timer, it should update DNS Server with DDNS-UPDATE. - - 7.4.1.3. Sending Neighbor Advertisement Messages - - 6DNAC Server sends Neighbor Advertisement Messages as part - of Duplicate Address Detection SLAAC [2462] with the FQDN Option - in Neighbor Advertisement message to defend duplicate FQDN - detection. - - There may be the case where defending of duplicate address detection - is not required but defending of FQDN is required. In such instance, - the defending Neighbor Advertisement must carry FQDN and unspecified - address in the ICMP target address field. - - 7.4.1.4. Processing Neighbor Advertisement Messages - - 6DNAC Server must ignore the any FQDN option found any of - the neighbor advertisement messages. If the Neighbor Advertisement - is a DAD defending, then it must delete its FQDN Cache entry created - on the reception of DAD Neighbor Solicitation message. - - When 6DNAC Clients gets the duplicate address detection neighbor - advertisement messages with FQDN option set it means that its - duplicate FQDN detection failed and enters Retry Mode. - - 7.4.1.5. Pros and Cons - - The advantage of this procedure is that it does not need any - extension header options to be included. The disadvantage of this - procedure is that, it needs change in the existing DAD procedure. - The change is only that the DAD neighbor solicitations are to be - addressed to all nodes multicast address instead of solicited - node multicast address. The another disadvantage is that, it needs - the existence of Duplicate Address Detection Procedure to - perform duplicate FQDN detection. - - 7.4.2. DAD with Router Alert Option for 6DNAC - - 7.4.2.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate Address Detection SLAAC [2462] with the following - extra information: - - -Park & Madanapalli Expires October 2003 [Page 25] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - a. Include Hop-by-Hop extension Header with Router Alert Option - for 6DNAC as described in IPv6 Router Alert Option[2711]. - - b. Include FQDN Option in the DAD Neighbor Solicitation Message - - 7.4.2.2. Processing Neighbor Solicitation Messages - - This is same as described in $7.4.1.2$. - - 7.4.2.3. Sending Neighbor Advertisement Messages - - This is same as described in $7.4.1.3$. - - 7.4.2.4. Processing Neighbor Advertisement Messages - - This is same as described in $7.4.1.4$. - - 7.4.2.5. Pros and Cons - - The advantage of this procedure is that it does not disturb - the existing implementation and their way of processing the - packets. The disadvantage is that, it needs the existence - of Duplicate Address Detection Procedure to perform duplicate - FQDN detection. Another disadvantage is that this procedure - requires 6DNAC Server functionality to be implemented on Router. - However, in this case 6DNAC Server can serve multiple links. - - 7.4.3. Explicit Detection of Duplicate Domain Name - - In this procedure Duplicate FQDN Detection starts after completion - of successful Site local or Global Address configuration. - - 7.4.3.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate FQDN Detection with the following information: - - a. Include FQDN Option in the Neighbor Solicitation Message - - b. Destination Address is set to All Nodes Multicast Address - or uses Router Alert Option for 6DNAC, when 6DNAC Server is - implemented on router. - - c. Target Address is set to Unspecified Address - - d. Other fields are set as per DAD SLAAC [2462]. - - 7.4.3.2. Processing Neighbor Solicitation Messages - - This is same as described in $7.4.1.2$. - - - - - - -Park & Madanapalli Expires October 2003 [Page 26] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - 7.4.3.3. Sending Neighbor Advertisement Messages - - This is same as described in $7.4.1.3$. - - 7.4.3.4. Processing Neighbor Advertisement Messages - - This is same as described in $7.4.1.4$. - - 7.4.3.5. Pros and Cons - - The advantage of this procedure is that it does not need the - existing duplicate address detection procedure. This is introduced - as the DAD procedure is found to be redundant in when IPv6 addresses - are constructed from the interface ID [DIID]. - - Note that, if 6DNAC Clients know the address of 6DNAC Server then - they can directly send DFQDND-NS to 6DNAC Server. - - 7.4.4. Retry Mode for Re-registering Domain Name - - In retry mode, nodes construct new FQDN as per Host Naming Algorithm. - Then they restart Duplicate FQDN Detection as described in $7.4.3$. - - - 7.5. Domain Name Registration - - 6DNAC Server must be an authenticated to update the DNS Server. - 6DNAC Server must also be configured with the DNS Server - information. - - 6DNAC Server detects the DNS information (IPv6 Address and - corresponding FQDN) from DAD/DFQDND messages and caches the - information. It also have an associated Registration Timer with - RegistrationWaitTime to wait for the successful completion of - DFQDND and update DNS Server using existing protocol DDNS UPDATE - [2136]. - - - 8. Security Consideration - - If someone wants to hijack correct Domain Name registration, they - could send a NS message with incorrect or same Domain Name to the - 6DNAC server repeatedly and server would start the Domain Name - registration through above mechanism, which is a security hole. - As described in [2461], a host can check validity of NDP messages. - If the NDP message include an IP Authentication Header, the message - authenticates correctly. For DNS UPDATE processing, secure DNS - Dynamic Update is described in [3007]. - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 27] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - 9. IANA Consideration - - Values in the Router Alert Option are registered and maintained by - IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is - required to assign the Type values for DNS Zone Suffix Information - option and FADN option. - - - 10. Acknowledgement - - Special thanks are due to Badrinarayana N.S. and Christian Huitema for - many helpful suggestions and revisions. - - - 11. Intellectual Property - - The following notice is copied from RFC 2026 [Bradner, 1996], - Section 10.4, and describes the position of the IETF concerning - intellectual property claims made against this document. - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use other technology described in - - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances - of licenses to be made available, or the result of an attempt made - to obtain a general license or permission for the use of such - proprietary rights by implementers or users of this specification - can be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - 12. Copyright - - The following copyright notice is copied from RFC 2026 [Bradner, - 1996], Section 10.4, and describes the applicable copyright for this - document. - - Copyright (C) The Internet Society July 12, 2001. All Rights - Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - -Park & Madanapalli Expires October 2003 [Page 28] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - 13. References - - [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [2460] Deering, S. abd R. Hinden, "Internet Protocol, - Version 6 (IPv6) Specification", RFC 2460, - December 1998. - - [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor - Discovery for IP version 6(IPv6)", RFC 2461, December - 1998. - - [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto- - Configuration", RFC 2462, December 1998. - - [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option", - RFC 2711, October 1999. - - [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND - FACILITIES", RFC 1034, November 1987. - - [1035] P. Mockapetris, "Domain Names - Implementation and - Specification" RFC 1035, November 1987. - - [2136] P. Vixie et al., "Dynamic Updates in the Domain Name - System (DNS UPDATE)", RFC2136, April 1997. - - [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - -Park & Madanapalli Expires October 2003 [Page 29] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - [DIID] yokohama-dad-vs-diid.pdf - at http://playground.sun.com/ipng/presentations/July2002/ - - [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf- - dnsop-ipv6-dns-issues-00.txt, work in progress. - - [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix - delegation", draft-ietf-ipv6-prefix-delegation- - requirement-01.txt, work in progress. - - [Autoreg] H. Kitamura, "Domain Name Auto-Registration for - Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name- - auto-reg-00.txt, work in progress. - - [NIQ] Matt Crawford, "IPv6 Node Information Queries", <draft- - ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress. - - - 14. Author's Addresses - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics, KOREA - Phone: +82-31-200-3728 - Email:soohong.park@samsung.com - - Syam Madanapalli - Network Systems Division, SAMSUNG India Software Operations, INDIA - Phone: +91-80-5550555 - Email:syam@samsung.com - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 30] diff --git a/doc/misc/options b/doc/misc/options index 3cf58ca8..bc28ace7 100644 --- a/doc/misc/options +++ b/doc/misc/options @@ -78,6 +78,7 @@ options { bindkeys-file <quoted_string>; blackhole { <address_match_element>; ... }; cache-file <quoted_string>; + check-dup-records ( fail | warn | ignore ); check-integrity <boolean>; check-mx ( fail | warn | ignore ); check-mx-cname ( fail | warn | ignore ); @@ -98,11 +99,12 @@ options { directory <quoted_string>; disable-algorithms <string> { <string>; ... }; disable-empty-zone <string>; - dnskey-ksk-only <boolean>; dnssec-accept-expired <boolean>; + dnssec-dnskey-kskonly <boolean>; dnssec-enable <boolean>; dnssec-lookaside <string> trust-anchor <string>; dnssec-must-be-secure <string> <boolean>; + dnssec-secure-to-insecure <boolean>; dnssec-validation <boolean>; dual-stack-servers [ port <integer> ] { ( <quoted_string> [ port <integer> ] | <ipv4_address> [ port <integer> ] | @@ -182,7 +184,6 @@ options { root-delegation-only [ exclude { <quoted_string>; ... } ]; rrset-order { [ class <string> ] [ type <string> ] [ name <quoted_string> ] <string> <string>; ... }; - secure-to-insecure <boolean>; serial-queries <integer>; // obsolete serial-query-rate <integer>; server-id ( <quoted_string> | none |; @@ -275,6 +276,7 @@ view <string> <optional_class> { attach-cache <string>; auth-nxdomain <boolean>; // default changed cache-file <quoted_string>; + check-dup-records ( fail | warn | ignore ); check-integrity <boolean>; check-mx ( fail | warn | ignore ); check-mx-cname ( fail | warn | ignore ); @@ -295,11 +297,12 @@ view <string> <optional_class> { dlz <string> { database <string>; }; - dnskey-ksk-only <boolean>; dnssec-accept-expired <boolean>; + dnssec-dnskey-kskonly <boolean>; dnssec-enable <boolean>; dnssec-lookaside <string> trust-anchor <string>; dnssec-must-be-secure <string> <boolean>; + dnssec-secure-to-insecure <boolean>; dnssec-validation <boolean>; dual-stack-servers [ port <integer> ] { ( <quoted_string> [ port <integer> ] | <ipv4_address> [ port <integer> ] | @@ -364,7 +367,6 @@ view <string> <optional_class> { root-delegation-only [ exclude { <quoted_string>; ... } ]; rrset-order { [ class <string> ] [ type <string> ] [ name <quoted_string> ] <string> <string>; ... }; - secure-to-insecure <boolean>; server <netprefix> { bogus <boolean>; edns <boolean>; @@ -419,6 +421,7 @@ view <string> <optional_class> { alt-transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; auto-dnssec ( allow | maintain | create | off ); + check-dup-records ( fail | warn | ignore ); check-integrity <boolean>; check-mx ( fail | warn | ignore ); check-mx-cname ( fail | warn | ignore ); @@ -429,7 +432,8 @@ view <string> <optional_class> { database <string>; delegation-only <boolean>; dialup <dialuptype>; - dnskey-ksk-only <boolean>; + dnssec-dnskey-kskonly <boolean>; + dnssec-secure-to-insecure <boolean>; file <quoted_string>; forward ( first | only ); forwarders [ port <integer> ] { ( <ipv4_address> | @@ -465,7 +469,6 @@ view <string> <optional_class> { nsec3-test-zone <boolean>; // test only pubkey <integer> <integer> <integer> <quoted_string>; // obsolete - secure-to-insecure <boolean>; sig-signing-nodes <integer>; sig-signing-signatures <integer>; sig-signing-type <integer>; @@ -503,6 +506,7 @@ zone <string> <optional_class> { alt-transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; auto-dnssec ( allow | maintain | create | off ); + check-dup-records ( fail | warn | ignore ); check-integrity <boolean>; check-mx ( fail | warn | ignore ); check-mx-cname ( fail | warn | ignore ); @@ -513,7 +517,8 @@ zone <string> <optional_class> { database <string>; delegation-only <boolean>; dialup <dialuptype>; - dnskey-ksk-only <boolean>; + dnssec-dnskey-kskonly <boolean>; + dnssec-secure-to-insecure <boolean>; file <quoted_string>; forward ( first | only ); forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) @@ -546,7 +551,6 @@ zone <string> <optional_class> { notify-to-soa <boolean>; nsec3-test-zone <boolean>; // test only pubkey <integer> <integer> <integer> <quoted_string>; // obsolete - secure-to-insecure <boolean>; sig-signing-nodes <integer>; sig-signing-signatures <integer>; sig-signing-type <integer>; |