Michał Kępień
dfdd3a8a2f
Every DocBook source document can be namespaced (DocBook 5) or
non-namespaced (DocBook 4). The set of XSL stylesheets used for
producing an output document can also be namespaced or non-namespaced.
Namespaced source documents should be used with namespaced stylesheets
and non-namespaced source documents should be used with non-namespaced
stylesheets. However, both stylesheet flavors contain processing rules
which allow them to be used interchangeably for any type of source
document.
Unfortunately, these processing rules became broken in version 1.79.1 of
the stylesheets, which means that non-namespaced source documents can no
longer be correctly transformed into man pages using namespaced
stylesheets and vice versa. This problem was fixed upstream [1], but no
released version of the XSL stylesheets contains that fix yet.
Back in 2016, this problem was reported as RT #43831 and allegedly fixed
in commit 1b8ce3b330. However, that fix
only helped for the non-namespaced version of the stylesheets - while
also breaking man page generation for the namespaced flavor.
Since using namespaced DocBook sources is the current best practice
(DocBook 5), make BIND DocBook sources namespaced again. When using
version 1.79.1 or 1.79.2 of the XSL stylesheets, care must be taken to
ensure namespaced stylesheets are used for generating BIND
documentation.
[1] https://github.com/docbook/xslt10-stylesheets/issues/109
95 lines
4.7 KiB
XML
95 lines
4.7 KiB
XML
<!--
|
|
- Copyright (C) Internet Systems Consortium, Inc. ("ISC")
|
|
-
|
|
- This Source Code Form is subject to the terms of the Mozilla Public
|
|
- License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
- file, you can obtain one at https://mozilla.org/MPL/2.0/.
|
|
-
|
|
- See the COPYRIGHT file distributed with this work for additional
|
|
- information regarding copyright ownership.
|
|
-->
|
|
|
|
<!-- Converted by db4-upgrade version 1.0 -->
|
|
<section xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="rfc5011.support"><info><title>Dynamic Trust Anchor Management</title></info>
|
|
|
|
<para>
|
|
BIND is able to maintain DNSSEC trust anchors using RFC 5011 key
|
|
management. This feature allows <command>named</command> to keep track
|
|
of changes to critical DNSSEC keys without any need for the operator to
|
|
make changes to configuration files.
|
|
</para>
|
|
|
|
<section><info><title>Validating Resolver</title></info>
|
|
|
|
<!-- TODO: command tag is overloaded for configuration and executables -->
|
|
<para>To configure a validating resolver to use RFC 5011 to
|
|
maintain a trust anchor, configure the trust anchor using a
|
|
<command>managed-keys</command> statement. Information about
|
|
this can be found in
|
|
<xref linkend="managed-keys"/>.</para>
|
|
<!-- TODO: managed-keys examples
|
|
also in DNSSEC section above here in ARM -->
|
|
</section>
|
|
<section><info><title>Authoritative Server</title></info>
|
|
|
|
<para>To set up an authoritative zone for RFC 5011 trust anchor
|
|
maintenance, generate two (or more) key signing keys (KSKs) for
|
|
the zone. Sign the zone with one of them; this is the "active"
|
|
KSK. All KSKs which do not sign the zone are "stand-by"
|
|
keys.</para>
|
|
<para>Any validating resolver which is configured to use the
|
|
active KSK as an RFC 5011-managed trust anchor takes note
|
|
of the stand-by KSKs in the zone's DNSKEY RRset, and stores them
|
|
for future reference. The resolver rechecks the zone
|
|
periodically; after 30 days, if the new key is still there,
|
|
the key is accepted by the resolver as a valid trust
|
|
anchor for the zone. Anytime after this 30-day acceptance
|
|
timer has completed, the active KSK can be revoked, and the
|
|
zone can be "rolled over" to the newly accepted key.</para>
|
|
<para>The easiest way to place a stand-by key in a zone is to
|
|
use the "smart signing" features of
|
|
<command>dnssec-keygen</command> and
|
|
<command>dnssec-signzone</command>. If a key exists with a publication
|
|
date in the past, but an activation date which is unset or in
|
|
the future, <command>dnssec-signzone -S</command> includes the DNSKEY
|
|
record in the zone but does not sign with it:</para>
|
|
<screen>
|
|
$ <userinput>dnssec-keygen -K keys -f KSK -P now -A now+2y example.net</userinput>
|
|
$ <userinput>dnssec-signzone -S -K keys example.net</userinput>
|
|
</screen>
|
|
<para>To revoke a key, use the command
|
|
<command>dnssec-revoke</command>. This adds the
|
|
REVOKED bit to the key flags and regenerates the
|
|
<filename>K*.key</filename> and
|
|
<filename>K*.private</filename> files.</para>
|
|
<para>After revoking the active key, the zone must be signed
|
|
with both the revoked KSK and the new active KSK. Smart
|
|
signing takes care of this automatically.</para>
|
|
<para>Once a key has been revoked and used to sign the DNSKEY
|
|
RRset in which it appears, that key is never again
|
|
accepted as a valid trust anchor by the resolver. However,
|
|
validation can proceed using the new active key, which was
|
|
accepted by the resolver when it was a stand-by key.</para>
|
|
<para>See RFC 5011 for more details on key rollover
|
|
scenarios.</para>
|
|
<para>When a key has been revoked, its key ID changes,
|
|
increasing by 128 and wrapping around at 65535. So, for
|
|
example, the key "<filename>Kexample.com.+005+10000</filename>" becomes
|
|
"<filename>Kexample.com.+005+10128</filename>".</para>
|
|
<para>If two keys have IDs exactly 128 apart and one is
|
|
revoked, the two key IDs will collide, causing several
|
|
problems. To prevent this,
|
|
<command>dnssec-keygen</command> does not generate a new key if
|
|
another key which may collide is present. This checking
|
|
only occurs if the new keys are written to the same directory
|
|
that holds all other keys in use for that zone.</para>
|
|
<para>Older versions of BIND 9 did not have this protection.
|
|
Exercise caution if using key revocation on keys that were
|
|
generated by previous releases, or if using keys stored in
|
|
multiple directories or on multiple machines.</para>
|
|
<para>It is expected that a future release of BIND 9 will
|
|
address this problem in a different way, by storing revoked
|
|
keys with their original unrevoked key IDs.</para>
|
|
</section>
|
|
</section>
|