Commit e1ba21bd authored by Evan Hunt's avatar Evan Hunt
Browse files

[master] fix managed-keys doc

4525.	[doc]		Fixed outdated documentation on managed-keys.
			[RT #43810]
parent df372d96
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]
......
......@@ -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>
 
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment