From 85be60e3c8e47b9fdfeaa0770f445b206c39bca8 Mon Sep 17 00:00:00 2001 From: Evan Hunt Date: Tue, 1 Sep 2009 07:14:26 +0000 Subject: [PATCH] 2665. [func] Clarify syntax for managed-keys {} statement, add ARM documentation about RFC 5011 support. [RT #19874] --- CHANGES | 3 + README.rfc5011 | 43 +++++--- bin/named/bind.keys.h | 8 ++ bin/named/bindkeys.pl | 16 ++- bin/named/config.c | 8 +- bin/named/server.c | 16 ++- bind.keys | 4 +- doc/arm/Bv9ARM-book.xml | 226 +++++++++++++++++++++++++++++++--------- lib/isccfg/namedconf.c | 41 +++++++- 9 files changed, 282 insertions(+), 83 deletions(-) diff --git a/CHANGES b/CHANGES index b7a42ac474..0bfb605f6f 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +2665. [func] Clarify syntax for managed-keys {} statement, add + ARM documentation about RFC 5011 support. [RT #19874] + 2664. [bug] create_keydata() and minimal_update() in zone.c didn't properly check return values for some functions. [RT #19956] diff --git a/README.rfc5011 b/README.rfc5011 index e8f07d0fed..539d3ba84c 100644 --- a/README.rfc5011 +++ b/README.rfc5011 @@ -48,20 +48,35 @@ To configure a validating resolver to use RFC5011 to maintain a trust 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. diff --git a/bin/named/bind.keys.h b/bin/named/bind.keys.h index 1b287a5184..433173e782 100644 --- a/bin/named/bind.keys.h +++ b/bin/named/bind.keys.h @@ -5,3 +5,11 @@ trusted-keys {\n\ dlv.isc.org. 257 3 5 \"BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh\";\n\ };\n\ " + +#define MANAGED_KEYS "\ +managed-keys {\n\ + # NOTE: This key expires September 2009 \n\ + # Go to https://www.isc.org/solutions/dlv to download a replacement\n\ + dlv.isc.org. initial-key 257 3 5 \"BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh\";\n\ +};\n\ +" diff --git a/bin/named/bindkeys.pl b/bin/named/bindkeys.pl index c68002b900..3ab3ec9818 100755 --- a/bin/named/bindkeys.pl +++ b/bin/named/bindkeys.pl @@ -14,13 +14,12 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: bindkeys.pl,v 1.2 2009/03/04 02:42:30 each Exp $ +# $Id: bindkeys.pl,v 1.3 2009/09/01 07:14:25 each Exp $ use strict; use warnings; -my $lines = '#define TRUSTED_KEYS "\\' . "\n"; - +my $lines; while (<>) { chomp; s/\"/\\\"/g; @@ -28,5 +27,12 @@ while (<>) { $lines .= $_ . "\n"; } -$lines .= '"' . "\n"; -print $lines; +my $mkey = '#define MANAGED_KEYS "\\' . "\n" . $lines . "\"\n"; + +$lines =~ s/managed-keys/trusted-keys/; +$lines =~ s/\s+initial-key//; +my $tkey = '#define TRUSTED_KEYS "\\' . "\n" . $lines . "\"\n"; + +print $tkey; +print "\n"; +print $mkey; diff --git a/bin/named/config.c b/bin/named/config.c index ef64482670..3d72c5573d 100644 --- a/bin/named/config.c +++ b/bin/named/config.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.c,v 1.100 2009/09/01 00:22:25 jinmei Exp $ */ +/* $Id: config.c,v 1.101 2009/09/01 07:14:25 each Exp $ */ /*! \file */ @@ -248,12 +248,12 @@ view \"_meta\" in {\n\ # (used if \"dnssec-lookaside auto;\" is set and\n\ # sysconfdir/bind.keys doesn't exist).\n\ #\n\ -# BEGIN TRUSTED KEYS\n" +# BEGIN MANAGED KEYS\n" /* Imported from bind.keys.h: */ -TRUSTED_KEYS +MANAGED_KEYS -"# END TRUSTED KEYS\n\ +"# END MANAGED KEYS\n\ "; isc_result_t diff --git a/bin/named/server.c b/bin/named/server.c index b4a1a8cf06..dbde146eaa 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.543 2009/09/01 00:22:25 jinmei Exp $ */ +/* $Id: server.c,v 1.544 2009/09/01 07:14:25 each Exp $ */ /*! \file */ @@ -475,6 +475,20 @@ dstkey_fromconfig(const cfg_obj_t *vconfig, const cfg_obj_t *key, keyname = dns_fixedname_name(&fkeyname); keynamestr = cfg_obj_asstring(cfg_tuple_get(key, "name")); + if (managed) { + const char *initmethod; + initmethod = cfg_obj_asstring(cfg_tuple_get(key, "init")); + + if (strcmp(initmethod, "initial-key") != 0) { + cfg_obj_log(key, ns_g_lctx, ISC_LOG_ERROR, + "managed key '%s': " + "invalid initialization method '%s'", + keynamestr, initmethod); + result = ISC_R_FAILURE; + goto cleanup; + } + } + if (vconfig == NULL) viewclass = dns_rdataclass_in; else { diff --git a/bind.keys b/bind.keys index 0f14287da8..a54ad97791 100644 --- a/bind.keys +++ b/bind.keys @@ -1,5 +1,5 @@ -trusted-keys { +managed-keys { # NOTE: This key expires September 2009 # Go to https://www.isc.org/solutions/dlv to download a replacement - dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; + dlv.isc.org. initial-key 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; }; diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 1c94c42435..f4f7785517 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -18,7 +18,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> - + BIND 9 Administrator Reference Manual @@ -2486,7 +2486,8 @@ allow-update { key host1-host2. ;}; dnssec-validation options must both be set to yes (the default setting in BIND 9.5 and later), and at least one trust anchor must be configured - with a trusted-keys statement in + with a trusted-keys or + managed-keys statement in named.conf. @@ -2500,7 +2501,14 @@ allow-update { key host1-host2. ;}; - trusted-keys are described in more detail + managed-keys are trusted keys which are + automatically kept up to date via RFC 5011 trust anchor + maintenance. + + + + trusted-keys and + managed-keys are described in more detail later in this document. @@ -2517,54 +2525,55 @@ allow-update { key host1-host2. ;}; 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 named is immune - to compromises in the DNSSEC components of the security - of parent zones. + controls. These are here to ensure that named + is immune to compromises in the DNSSEC components of the security + of parent zones. -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 { @@ -3494,6 +3503,17 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. + + + managed-keys + + + + lists DNSSEC keys to be kept up to date + using RFC 5011 trust anchor maintenance. + + + view @@ -5495,7 +5515,8 @@ options { they are secure. If no, then normal DNSSEC validation applies allowing for insecure answers to be accepted. The specified domain must be under a - trusted-key or + trusted-keys or + managed-keys statement, or dnssec-lookaside must be active. @@ -9017,11 +9038,112 @@ deny-answer-aliases { "example.net"; }; level are inherited by all views, but keys defined in a view are only used within that view. + + + + <command>managed-keys</command> Statement Grammar + +managed-keys { + string initial-key number number number string ; + string initial-key number number number string ; ... +}; + + + + + <command>managed-keys</command> Statement Definition + and Usage + + The managed-keys statement, like + trusted-keys, defines DNSSEC + security roots. The difference is that + managed-keys can be kept up to date + automatically, without intervention from the resolver + operator. + + + 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 + trusted-keys 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 + trusted-keys statement with the new key. + + + If, however, the zone were listed in a + managed-keys statement instead, then the + zone owner could add a "stand-by" key to the zone in advance. + named would store the stand-by key, and + when the original key was revoked, named + 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. + + + A managed-keys 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 + BIND 9.7.0) is initial-key. + This means the managed-keys statement must + contain a copy of the initializing key. (Future releases may + allow keys to be initialized by other methods, eliminating this + requirement.) + + + Consequently, a managed-keys statement + appears similar to a trusted-keys, differing + in the presence of the second field, containing the keyword + initial-key. The difference is, whereas the + keys listed in a trusted-keys continue to be + trusted until they are removed from + named.conf, an initializing key listed + in a managed-keys statement is only trusted + once: for as long as it takes to load the + managed key database and start the RFC 5011 key maintenance + process. + + + 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. 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 runs, it + sees the managed-keys 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 managed-keys is not + used to validate answers; it has been superseded by the key or + keys stored in the managed keys database. + + + The first name named runs after a name + has been removed from the + managed-keys 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. + + + named only maintains a single managed keys + database; consequently, unlike trusted-keys, + managed-keys may only be set at the top + level of named.conf, not within a view. + - In addition to keys specified in - trusted-keys statements, if the - dnssec-lookaside option is set to "auto", - named will also load a built-in trusted key for dlv.isc.org. + If the dnssec-lookaside option is set to + "auto", named will automatically initialize + a managed key for the zone dlv.isc.org. The + key that is used to initialize the key maintenance process is + built into named, and can be overridden + from bindkeys-file. diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index c8b433099e..aef85edddd 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -15,7 +15,7 @@ * 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 */ @@ -428,7 +428,7 @@ static cfg_type_t cfg_type_category = { /*% - * 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 }, @@ -443,6 +443,24 @@ static cfg_type_t cfg_type_dnsseckey = { &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 = { @@ -530,12 +548,25 @@ static cfg_type_t cfg_type_keylist = { 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, @@ -762,7 +793,7 @@ namedconf_or_view_clauses[] = { { "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 } }; @@ -772,7 +803,7 @@ namedconf_or_view_clauses[] = { 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 } }; -- GitLab