]> git.ipfire.org Git - thirdparty/bind9.git/commitdiff
[master] fix managed-keys doc
authorEvan Hunt <each@isc.org>
Mon, 5 Dec 2016 04:22:20 +0000 (20:22 -0800)
committerEvan Hunt <each@isc.org>
Mon, 5 Dec 2016 04:22:20 +0000 (20:22 -0800)
4525. [doc] Fixed outdated documentation on managed-keys.
[RT #43810]

CHANGES
doc/arm/Bv9ARM-book.xml

diff --git a/CHANGES b/CHANGES
index f5711e346094744bc5c3ede8219a325434d370d1..73a5a28c82a00a349e28d10d00ac94ca8eabed0e 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,6 @@
+4525.  [doc]           Fixed outdated documentation on managed-keys.
+                       [RT #43810]
+
 4524.  [bug]           The net zero test was broken causing IPv4 servers
                        with addresses ending in .0 to be rejected. [RT #43776]
 
index debef67cc51a1340be649412809e9b064dbc43bd..f9d6b6f17be550b51452da69bb43c982684553ac 100644 (file)
@@ -11436,9 +11436,9 @@ example.com                 CNAME   rpz-tcp-only.
            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.
+           key specified in the <command>managed-keys</command>
+           statement is not used to validate answers; it has been
+           superseded by the key or keys stored in the managed keys database.
          </para>
          <para>
            The next time <command>named</command> runs after a name
@@ -11449,25 +11449,31 @@ example.com                 CNAME   rpz-tcp-only.
            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.
+           In the current implementation, the managed keys database
+           is stored as a master-format zone file.
          </para>
          <para>
-           In the current implementation, the managed keys database is
-           stored as a master-format zone file called
-           <filename>managed-keys.bind</filename>.  When the key database
-           is changed, the zone is updated.  As with any other dynamic
-           zone, changes will be written into a journal file,
-           <filename>managed-keys.bind.jnl</filename>.  They are committed
-           to the master file as soon as possible afterward; in the case
-           of the managed key database, this will usually occur within 30
+           On servers which do not use views, this file is named
+           <filename>managed-keys.bind</filename>.  When views are in
+           use, there will be a separate managed keys database for each
+           view; the filename will be the view name (or, if a view name
+           contains characters which would make it illegal as a filename,
+           a hash of the view name), followed by
+           the suffix <filename>.mkeys</filename>.
+         </para>
+         <para>
+           When the key database is changed, the zone is updated.
+           As with any other dynamic zone, changes will be written
+           into a journal file, e.g.,
+           <filename>managed-keys.bind.jnl</filename> or
+           <filename>internal.mkeys.jnl</filename>.
+           Changes are committed to the master file as soon as
+           possible afterward; this will usually occur within 30
            seconds.  So, whenever <command>named</command> is using
-           automatic key maintenance, those two files can be expected to
-           exist in the working directory.  (For this reason among others,
-           the working directory should be always be writable by
-           <command>named</command>.)
+           automatic key maintenance, the zone file and journal file
+           can be expected to exist in the working directory.
+           (For this reason among others, the working directory
+           should be always be writable by <command>named</command>.)
          </para>
          <para>
            If the <command>dnssec-validation</command> option is
@@ -11477,9 +11483,11 @@ example.com                 CNAME   rpz-tcp-only.
            option is set to <userinput>auto</userinput>,
            <command>named</command> will automatically initialize
            a managed key for the zone <literal>dlv.isc.org</literal>.
-           In both cases, 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>.
+           (Note: The ISC DLV service is expected to cease operation by
+           the end of 2017.) In both cases, 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>
        </section>