anchor, configure the trust anchor using a "managed-keys" statement
instead of a "trusted-keys" statement.
-The syntax for "managed-keys" is identical to that for "trusted-keys".
-However, whereas a trusted key is trusted permanently until it is removed
-from named.conf, a managed key is only trusted for as long as it takes to
-initialize RFC5011 key maintenance.
-
-When named loads for the first time with a managed key configured, it
-will fetch the DNSKEY RRset directly from the zone apex and check its
-signature against the key specified in the "managed-keys" statement.
-If it is validly signed, then the DNSKEY RRset is used as the basis for a
-new managed keys database.
-
-From that point on, when named loads, it will see the "managed-keys"
-statement, check to make sure RFC5011 key maintenance has already been
-initialized for the specified zone, and if so, it will simply move on.
+A "managed-keys" statement contains a list of keys to be maintained,
+with information on how they are to be initialized the first time. The
+only initialization method supported in BIND 9.7.0 is "initial-key".
+This means the "managed-keys" statement itself will contain a copy of
+the initializing key. In future releases, keys may be initialized by
+other methods, removing the need to incorporate a copy of an intializing
+key in named.conf.
+
+Example:
+
+managed-keys {
+ sample.domain. initial-key 257 3 5 "BEAAAAPHMu ...";
+};
+
+At first glance this is very similar to a "trusted-keys" statement,
+differing only in the presence of the second field, "initial-key".
+However, whereas a trusted key is trusted permanently until it is
+removed from named.conf, this key would only be trusted once, for
+as long as it takes to initialize RFC5011 key maintenance.
+
+The first time named runs with a managed key configured in named.conf,
+it fetches the DNSKEY RRset directly from the zone apex, and validates
+it using the key specified in the "managed-keys" statement, as above.
+If the DNSKEY RRset is validly signed, then it is used as the basis for
+a new managed keys database.
+
+From that point on, whenever named loads, it sees the "managed-keys"
+statement, checks to make sure RFC5011 key maintenance has already been
+initialized for the specified zone, and if so, it simply moves on.
No action will be taken unless a key is *removed* from the "managed-keys"
statement--in which case that zone is removed from the managed keys
database as well, and RFC5011 key maintenance will no longer be used.
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- File: $Id: Bv9ARM-book.xml,v 1.425 2009/08/25 02:56:03 marka Exp $ -->
+<!-- File: $Id: Bv9ARM-book.xml,v 1.426 2009/09/01 07:14:25 each Exp $ -->
<book xmlns:xi="http://www.w3.org/2001/XInclude">
<title>BIND 9 Administrator Reference Manual</title>
<command>dnssec-validation</command> options must both be
set to yes (the default setting in <acronym>BIND</acronym> 9.5
and later), and at least one trust anchor must be configured
- with a <command>trusted-keys</command> statement in
+ with a <command>trusted-keys</command> or
+ <command>managed-keys</command> statement in
<filename>named.conf</filename>.
</para>
</para>
<para>
- <command>trusted-keys</command> are described in more detail
+ <command>managed-keys</command> are trusted keys which are
+ automatically kept up to date via RFC 5011 trust anchor
+ maintenance.
+ </para>
+
+ <para>
+ <command>trusted-keys</command> and
+ <command>managed-keys</command> are described in more detail
later in this document.
</para>
more public keys for the root. This allows answers from
outside the organization to be validated. It will also
have several keys for parts of the namespace the organization
- controls. These are here to ensure that <command>named</command> is immune
- to compromises in the DNSSEC components of the security
- of parent zones.
+ controls. These are here to ensure that <command>named</command>
+ is immune to compromises in the DNSSEC components of the security
+ of parent zones.
</para>
<programlisting>
-trusted-keys {
-
+managed-keys {
/* Root Key */
-"." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
- JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
- aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
- 4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
- hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
- 5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
- g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
- 66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
- 97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
- dgxbcDTClU0CRBdiieyLMNzXG3";
-
-/* Key for our organization's forward zone */
-example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
- 5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
- GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
- 4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
- kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O
- g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
- TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
- FxmAVZP20igTixin/1LcrgX/KMEGd/biuv
- F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
- /oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o
- 1OTQ09A0=";
-
-/* Key for our reverse zone. */
-2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc
- xOdNax071L18QqZnQQQAVVr+i
- LhGTnNGp3HoWQLUIzKrJVZ3zg
- gy3WwNT6kZo6c0tszYqbtvchm
- gQC8CzKojM/W16i6MG/eafGU3
- siaOdS0yOI6BgPsw+YZdzlYMa
- IJGf4M4dyoKIhzdZyQ2bYQrjy
- Q4LB0lC7aOnsMyYKHHYeRvPxj
- IQXmdqgOJGq+vsevG06zW+1xg
- YJh9rCIfnm1GX/KMgxLPG2vXT
- D/RnLX+D3T3UL7HJYHJhAZD5L
- 59VvjSPsZJHeDCUyWYrvPZesZ
- DIRvhDD52SKvbheeTJUm6Ehkz
- ytNN2SN96QRk8j/iI8ib";
+ "." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
+ JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
+ aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
+ 4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
+ hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
+ 5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
+ g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
+ 66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
+ 97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
+ dgxbcDTClU0CRBdiieyLMNzXG3";
+};
+
+trusted-keys {
+ /* Key for our organization's forward zone */
+ example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
+ 5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
+ GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
+ 4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
+ kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O
+ g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
+ TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
+ FxmAVZP20igTixin/1LcrgX/KMEGd/biuv
+ F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
+ /oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o
+ 1OTQ09A0=";
+
+ /* Key for our reverse zone. */
+ 2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc
+ xOdNax071L18QqZnQQQAVVr+i
+ LhGTnNGp3HoWQLUIzKrJVZ3zg
+ gy3WwNT6kZo6c0tszYqbtvchm
+ gQC8CzKojM/W16i6MG/eafGU3
+ siaOdS0yOI6BgPsw+YZdzlYMa
+ IJGf4M4dyoKIhzdZyQ2bYQrjy
+ Q4LB0lC7aOnsMyYKHHYeRvPxj
+ IQXmdqgOJGq+vsevG06zW+1xg
+ YJh9rCIfnm1GX/KMgxLPG2vXT
+ D/RnLX+D3T3UL7HJYHJhAZD5L
+ 59VvjSPsZJHeDCUyWYrvPZesZ
+ DIRvhDD52SKvbheeTJUm6Ehkz
+ ytNN2SN96QRk8j/iI8ib";
};
options {
</para>
</entry>
</row>
+ <row rowsep="0">
+ <entry colname="1">
+ <para><command>managed-keys</command></para>
+ </entry>
+ <entry colname="2">
+ <para>
+ lists DNSSEC keys to be kept up to date
+ using RFC 5011 trust anchor maintenance.
+ </para>
+ </entry>
+ </row>
<row rowsep="0">
<entry colname="1">
<para><command>view</command></para>
they are secure. If <userinput>no</userinput>, then normal
DNSSEC validation applies allowing for insecure answers to
be accepted. The specified domain must be under a
- <command>trusted-key</command> or
+ <command>trusted-keys</command> or
+ <command>managed-keys</command> statement, or
<command>dnssec-lookaside</command> must be active.
</para>
</listitem>
level are inherited by all views, but keys defined in a view
are only used within that view.
</para>
+ </sect2>
+
+ <sect2>
+ <title><command>managed-keys</command> Statement Grammar</title>
+
+<programlisting><command>managed-keys</command> {
+ <replaceable>string</replaceable> initial-key <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ;
+ <optional> <replaceable>string</replaceable> initial-key <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; <optional>...</optional></optional>
+};
+</programlisting>
+
+ </sect2>
+ <sect2>
+ <title><command>managed-keys</command> Statement Definition
+ and Usage</title>
+ <para>
+ The <command>managed-keys</command> statement, like
+ <command>trusted-keys</command>, defines DNSSEC
+ security roots. The difference is that
+ <command>managed-keys</command> can be kept up to date
+ automatically, without intervention from the resolver
+ operator.
+ </para>
+ <para>
+ Suppose, for example, that a zone's key-signing
+ key was compromised, and the zone owner had to revoke and
+ replace the key. A resolver which had the old key in a
+ <command>trusted-keys</command> statement would be
+ unable to validate this zone any longer; it would
+ reply with a SERVFAIL response code. This would
+ continue until the resolver operator had updated the
+ <command>trusted-keys</command> statement with the new key.
+ </para>
+ <para>
+ If, however, the zone were listed in a
+ <command>managed-keys</command> statement instead, then the
+ zone owner could add a "stand-by" key to the zone in advance.
+ <command>named</command> would store the stand-by key, and
+ when the original key was revoked, <command>named</command>
+ would be able to transition smoothly to the new key. It would
+ also recognize that the old key had been revoked, and cease
+ using that key to validate answers, minimizing the damage that
+ the compromised key could do.
+ </para>
+ <para>
+ A <command>managed-keys</command> statement contains a list of
+ the keys to be managed, along with information about how the
+ keys are to be initialized for the first time. The only
+ initialization method currently supported (as of
+ <acronym>BIND</acronym> 9.7.0) is <literal>initial-key</literal>.
+ This means the <command>managed-keys</command> statement must
+ contain a copy of the initializing key. (Future releases may
+ allow keys to be initialized by other methods, eliminating this
+ requirement.)
+ </para>
+ <para>
+ Consequently, a <command>managed-keys</command> statement
+ appears similar to a <command>trusted-keys</command>, differing
+ in the presence of the second field, containing the keyword
+ <literal>initial-key</literal>. The difference is, whereas the
+ keys listed in a <command>trusted-keys</command> continue to be
+ trusted until they are removed from
+ <filename>named.conf</filename>, an initializing key listed
+ in a <command>managed-keys</command> statement is only trusted
+ <emphasis>once</emphasis>: for as long as it takes to load the
+ managed key database and start the RFC 5011 key maintenance
+ process.
+ </para>
+ <para>
+ The first time <command>named</command> runs with a managed key
+ configured in <filename>named.conf</filename>, it fetches the
+ DNSKEY RRset directly from the zone apex, and validates it
+ using the key specified in the <command>managed-keys</command>
+ statement. If the DNSKEY RRset is validly signed, then it is
+ used as the basis for a new managed keys database.
+ </para>
+ <para>
+ From that point on, whenever <command>named</command> runs, it
+ sees the <command>managed-keys</command> statement, checks to
+ make sure RFC 5011 key maintenance has already been initialized
+ for the specified domain, and if so, it simply moves on. The
+ key specified in the <command>managed-keys</command> is not
+ used to validate answers; it has been superseded by the key or
+ keys stored in the managed keys database.
+ </para>
+ <para>
+ The first name <command>named</command> runs after a name
+ has been <emphasis>removed</emphasis> from the
+ <command>managed-keys<command> statement, the corresponding
+ zone will be removed from the managed keys database,
+ and RFC 5011 key maintenance will no longer be used for that
+ domain.
+ </para>
+ <para>
+ <command>named</command> only maintains a single managed keys
+ database; consequently, unlike <command>trusted-keys</command>,
+ <command>managed-keys</command> may only be set at the top
+ level of <filename>named.conf</filename>, not within a view.
+ </para>
<para>
- In addition to keys specified in
- <command>trusted-keys</command> statements, if the
- <command>dnssec-lookaside</command> option is set to "auto",
- named will also load a built-in trusted key for dlv.isc.org.
+ If the <command>dnssec-lookaside</command> option is set to
+ "auto", <command>named</command> will automatically initialize
+ a managed key for the zone <literal>dlv.isc.org</literal>. The
+ key that is used to initialize the key maintenance process is
+ built into <command>named</command>, and can be overridden
+ from <command>bindkeys-file</command>.
</para>
</sect2>
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: namedconf.c,v 1.103 2009/07/29 17:52:00 each Exp $ */
+/* $Id: namedconf.c,v 1.104 2009/09/01 07:14:26 each Exp $ */
/*! \file */
/*%
- * A dnssec key, as used in the "trusted-keys" or "managed-keys" statement.
+ * A dnssec key, as used in the "trusted-keys" statement.
*/
static cfg_tuplefielddef_t dnsseckey_fields[] = {
{ "name", &cfg_type_astring, 0 },
&cfg_rep_tuple, dnsseckey_fields
};
+/*%
+ * A managed key initialization specifier, as used in the
+ * "managed-keys" statement.
+ */
+static cfg_tuplefielddef_t managedkey_fields[] = {
+ { "name", &cfg_type_astring, 0 },
+ { "init", &cfg_type_ustring, 0 }, /* must be literal "initial-key" */
+ { "flags", &cfg_type_uint32, 0 },
+ { "protocol", &cfg_type_uint32, 0 },
+ { "algorithm", &cfg_type_uint32, 0 },
+ { "key", &cfg_type_qstring, 0 },
+ { NULL, NULL, 0 }
+};
+static cfg_type_t cfg_type_managedkey = {
+ "managedkey", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple,
+ &cfg_rep_tuple, managedkey_fields
+};
+
static keyword_type_t wild_class_kw = { "class", &cfg_type_ustring };
static cfg_type_t cfg_type_optional_wild_class = {
cfg_doc_bracketed_list, &cfg_rep_list, &cfg_type_astring
};
-/*% A list of dnssec keys, as in "trusted-keys" and "managed-keys" stanzas */
+/*% A list of dnssec keys, as in "trusted-keys" */
static cfg_type_t cfg_type_dnsseckeys = {
"dnsseckeys", cfg_parse_bracketed_list, cfg_print_bracketed_list,
cfg_doc_bracketed_list, &cfg_rep_list, &cfg_type_dnsseckey
};
+/*%
+ * A list of managed key entries, as in "trusted-keys". Currently
+ * (9.7.0) this has a format similar to dnssec keys, except the keyname
+ * is followed by the keyword "initial-key". In future releases, this
+ * keyword may take other values indicating different methods for the
+ * key to be initialized.
+ */
+
+static cfg_type_t cfg_type_managedkeys = {
+ "managedkeys", cfg_parse_bracketed_list, cfg_print_bracketed_list,
+ cfg_doc_bracketed_list, &cfg_rep_list, &cfg_type_managedkey
+};
+
static const char *forwardtype_enums[] = { "first", "only", NULL };
static cfg_type_t cfg_type_forwardtype = {
"forwardtype", cfg_parse_enum, cfg_print_ustring, cfg_doc_enum, &cfg_rep_string,
{ "dlz", &cfg_type_dynamically_loadable_zones, 0 },
{ "server", &cfg_type_server, CFG_CLAUSEFLAG_MULTI },
{ "trusted-keys", &cfg_type_dnsseckeys, CFG_CLAUSEFLAG_MULTI },
- { "managed-keys", &cfg_type_dnsseckeys, CFG_CLAUSEFLAG_MULTI },
+ { "managed-keys", &cfg_type_managedkeys, CFG_CLAUSEFLAG_MULTI },
{ NULL, NULL, 0 }
};
static cfg_clausedef_t
bindkeys_clauses[] = {
{ "trusted-keys", &cfg_type_dnsseckeys, CFG_CLAUSEFLAG_MULTI },
- { "managed-keys", &cfg_type_dnsseckeys, CFG_CLAUSEFLAG_MULTI },
+ { "managed-keys", &cfg_type_managedkeys, CFG_CLAUSEFLAG_MULTI },
{ NULL, NULL, 0 }
};
projects / thirdparty / bind9.git / commitdiff
