Commit 86a3af1c authored by Evan Hunt's avatar Evan Hunt

Various text edits and fixes to the documentation

parent eaff8860
Pipeline #46921 canceled with stages
in 1 minute and 22 seconds
This diff is collapsed.
......@@ -14,84 +14,84 @@
<para>
A "catalog zone" is a special DNS zone that contains a list of
other zones to be served, along with their configuration parameters.
Zones listed in a catalog zone are called "member zones".
When a catalog zone is loaded or transferred to a slave server
which supports this functionality, the slave server will create
Zones listed in a catalog zone are called "member zones."
When a catalog zone is loaded or transferred to a secondary server
which supports this functionality, the secondary server creates
the member zones automatically. When the catalog zone is updated
(for example, to add or delete member zones, or change
their configuration parameters) those changes are immediately put
their configuration parameters), those changes are immediately put
into effect. Because the catalog zone is a normal DNS zone, these
configuration changes can be propagated using the standard AXFR/IXFR
zone transfer mechanism.
</para>
<para>
Catalog zones' format and behavior are specified as an internet draft
for interoperability among DNS implementations. As of this release, the
Catalog zones' format and behavior are specified as an Internet draft
for interoperability among DNS implementations. The
latest revision of the DNS catalog zones draft can be found here:
https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/
https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/.
</para>
<section><info><title>Principle of Operation</title></info>
<para>
Normally, if a zone is to be served by a slave server, the
Normally, if a zone is to be served by a secondary server, the
<filename>named.conf</filename> file on the server must list the
zone, or the zone must be added using <command>rndc addzone</command>.
In environments with a large number of slave servers and/or where
In environments with a large number of secondary servers, and/or where
the zones being served are changing frequently, the overhead involved
in maintaining consistent zone configuration on all the slave
in maintaining consistent zone configuration on all the secondary
servers can be significant.
</para>
<para>
A catalog zone is a way to ease this administrative burden. It is a
DNS zone that lists member zones that should be served by slave servers.
When a slave server receives an update to the catalog zone, it adds,
A catalog zone is a way to ease this administrative burden: it is a
DNS zone that lists member zones that should be served by secondary servers.
When a secondary server receives an update to the catalog zone, it adds,
removes, or reconfigures member zones based on the data received.
</para>
<para>
To use a catalog zone, it must first be set up as a normal zone on
the master and the on slave servers that will be configured to use
To use a catalog zone, it must first be set up as a normal zone on both
the primary and secondary servers that are configured to use
it. It must also be added to a <option>catalog-zones</option> list
in the <option>options</option> or <option>view</option> statement
in <filename>named.conf</filename>. (This is comparable to the way
in <filename>named.conf</filename>. This is comparable to the way
a policy zone is configured as a normal zone and also listed in
a <option>response-policy</option> statement.)
a <option>response-policy</option> statement.
</para>
<para>
To use the catalog zone feature to serve a new member zone:
<itemizedlist>
<listitem>
<para>
Set up the the member zone to be served on the master as normal.
This could be done by editing <filename>named.conf</filename>,
Set up the the member zone to be served on the primary as normal.
This can be done by editing <filename>named.conf</filename>
or by running <command>rndc addzone</command>.
</para>
</listitem>
<listitem>
<para>
Add an entry to the catalog zone for the new member zone.
This could be done by editing the catalog zone's master file
This can be done by editing the catalog zone's zone file
and running <command>rndc reload</command>, or by updating
the zone using <command>nsupdate</command>.
</para>
</listitem>
</itemizedlist>
The change to the catalog zone will be propagated from the master to all
slaves using the normal AXFR/IXFR mechanism. When the slave receives the
update to the catalog zone, it will detect the entry for the new member
zone, create an instance of of that zone on the slave server, and point
The change to the catalog zone is propagated from the primary to all
secondaries using the normal AXFR/IXFR mechanism. When the secondary receives the
update to the catalog zone, it detects the entry for the new member
zone, creates an instance of that zone on the secondary server, and points
that instance to the <option>masters</option> specified in the catalog
zone data. The newly created member zone is a normal slave zone, so
BIND will immediately initiate a transfer of zone contents from the
master. Once complete, the slave will start serving the member zone.
zone data. The newly created member zone is a normal secondary zone, so
BIND immediately initiates a transfer of zone contents from the
primary. Once complete, the secondary starts serving the member zone.
</para>
<para>
Removing a member zone from a slave server requires nothing more than
deleting the member zone's entry in the catalog zone. The change to the
catalog zone is propagated to the slave server using the normal AXFR/IXFR
transfer mechanism. The slave server, on processing the update, will
notice that the member zone has been removed. It will stop serving the
zone and remove it from its list of configured zones. (Removing the
member zone from the master server has to be done in the normal way,
Removing a member zone from a secondary server requires only
deleting the member zone's entry in the catalog zone; the change to the
catalog zone is propagated to the secondary server using the normal AXFR/IXFR
transfer mechanism. The secondary server, on processing the update,
notices that the member zone has been removed, stops serving the
zone, and removes it from its list of configured zones. However, removing the
member zone from the primary server must be done
by editing the configuration file or running
<command>rndc delzone</command>.)
</para>
......@@ -116,31 +116,31 @@ catalog-zones {
This statement specifies that the zone
<literal>catalog.example</literal> is a catalog zone. This zone must be
properly configured in the same view. In most configurations, it would
be a slave zone.
be a secondary zone.
</para>
<para>
The options following the zone name are not required, and may be
specified in any order:
</para>
<para>
The <option>default-masters</option> option defines the default masters
for member zones listed in a catalog zone. This can be overridden by
The <option>default-masters</option> option defines the default primaries
for member zones listed in a catalog zone, and can be overridden by
options within a catalog zone. If no such options are included, then
member zones will transfer their contents from the servers listed in
member zones transfer their contents from the servers listed in
this option.
</para>
<para>
The <option>in-memory</option> option, if set to <literal>yes</literal>,
causes member zones to be stored only in memory. This is functionally
equivalent to configuring a slave zone without a <option>file</option>.
equivalent to configuring a secondary zone without a <option>file</option>
option. The default is <literal>no</literal>; member zones' content
will be stored locally in a file whose name is automatically generated
is stored locally in a file whose name is automatically generated
from the view name, catalog zone name, and member zone name.
</para>
<para>
The <option>zone-directory</option> option causes local copies of
member zones' master files (if <option>in-memory</option> is not set
to <literal>yes</literal>) to be stored in the specified directory.
member zones' zone files to be stored in the specified directory,
if <option>in-memory</option> is not set to <literal>yes</literal>.
The default is to store zone files in the server's working directory.
A non-absolute pathname in <option>zone-directory</option> is
assumed to be relative to the working directory.
......@@ -150,21 +150,21 @@ catalog-zones {
interval between processing of updates to catalog zones, in seconds.
If an update to a catalog zone (for example, via IXFR) happens less
than <option>min-update-interval</option> seconds after the most
recent update, then the changes will not be carried out until this
recent update, the changes are not carried out until this
interval has elapsed. The default is <literal>5</literal> seconds.
</para>
<para>
Catalog zones are defined on a per-view basis. Configuring a non-empty
<option>catalog-zones</option> statement in a view will automatically
turn on <option>allow-new-zones</option> for that view. (Note: this
means <command>rndc addzone</command> and <command>rndc delzone</command>
will also work in any view that supports catalog zones.)
<option>catalog-zones</option> statement in a view automatically
turns on <option>allow-new-zones</option> for that view. This
means that <command>rndc addzone</command> and <command>rndc delzone</command>
also work in any view that supports catalog zones.
</para>
</section>
<section><info><title>Catalog Zone format</title></info>
<section><info><title>Catalog Zone Format</title></info>
<para>
A catalog zone is a regular DNS zone; therefore, it has to have a
A catalog zone is a regular DNS zone; therefore, it must have a
single <literal>SOA</literal> and at least one <literal>NS</literal>
record.
</para>
......@@ -180,14 +180,14 @@ version.catalog.example. IN TXT "1"
</screen>
<para>
Note that this record must have the domain name
version.<replaceable>catalog-zone-name</replaceable>. This illustrates
how the meaning of data stored in a catalog zone is indicated by the
"version.<replaceable>catalog-zone-name</replaceable>".
The data stored in a catalog zone is indicated by the
the domain name label immediately before the catalog zone domain.
</para>
<para>
Catalog zone options can be set either globally for the whole catalog
zone or for a single member zone. Global options override the settings
in the configuration file and member zone options override global
in the configuration file, and member zone options override global
options.
</para>
<para>
......@@ -204,8 +204,8 @@ version.catalog.example. IN TXT "1"
masters.catalog.example. IN A 192.0.2.1
</screen>
<para>
This option defines a master server for the member zones - it
can be either an A or AAAA record. If multiple masters are set the
This option defines a primary server for the member zones, which
can be either an A or AAAA record. If multiple primaries are set, the
order in which they are used is random.
</para>
</listitem>
......@@ -216,7 +216,7 @@ version.catalog.example. IN TXT "1"
label.masters.catalog.example. IN TXT "tsig_key_name"
</screen>
<para>
This option defines a master server for the member zone with a TSIG
This option defines a primary server for the member zone with a TSIG
key set. The TSIG key must be configured in the configuration file.
<option>label</option> can be any valid DNS label.
</para>
......@@ -232,9 +232,9 @@ version.catalog.example. IN TXT "1"
These options are the equivalents of <option>allow-query</option>
and <option>allow-transfer</option> in a zone declaration in the
<filename>named.conf</filename> configuration file. The ACL is
processed in order - if there's no match to any rule the default
policy is to deny access. For the syntax of the APL RR see RFC
3123
processed in order; if there is no match to any rule, the default
policy is to deny access. For the syntax of the APL RR, see RFC
3123.
</para>
</listitem>
</itemizedlist>
......@@ -261,17 +261,17 @@ label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN
allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN APL 1:10.0.0.0/24
</screen>
<para>
As would be expected, options defined for a specific zone override
Options defined for a specific zone override
the global options defined in the catalog zone. These in turn override
the global options defined in the <literal>catalog-zones</literal>
statement in the configuration file.
</para>
<para>
(Note that none of the global records an option will be inherited if
Note that none of the global records for an option are inherited if
any records are defined for that option for the specific zone. For
example, if the zone had a <literal>masters</literal> record of type
A but not AAAA, then it would <emphasis>not</emphasis> inherit the
type AAAA record from the global option.)
A but not AAAA, it would <emphasis>not</emphasis> inherit the
type AAAA record from the global option.
</para>
</section>
</section>
......@@ -13,17 +13,17 @@
<section xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="dlz-info"><info><title>DLZ (Dynamically Loadable Zones)</title></info>
<para>
DLZ (Dynamically Loadable Zones) is an extension to BIND 9 that allows
Dynamically Loadable Zones (DLZ) are an extension to BIND 9 that allows
zone data to be retrieved directly from an external database. There is
no required format or schema. DLZ drivers exist for several different
database backends including PostgreSQL, MySQL, and LDAP and can be
database backends, including PostgreSQL, MySQL, and LDAP, and can be
written for any other.
</para>
<para>
Historically, DLZ drivers had to be statically linked with the <command>named</command>
binary and were turned on via a configure option at compile time (for
example, <userinput>"configure --with-dlz-ldap"</userinput>).
Currently, the drivers provided in the BIND 9 tarball in
example, <userinput>configure --with-dlz-ldap</userinput>).
The drivers provided in the BIND 9 tarball in
<filename>contrib/dlz/drivers</filename> are still linked this
way.
</para>
......@@ -32,21 +32,21 @@
dynamically at runtime, via the DLZ "dlopen" driver, which acts as a
generic wrapper around a shared object implementing the DLZ API. The
"dlopen" driver is linked into <command>named</command> by default, so configure options
are no longer necessary when using these dynamically linkable drivers,
but are still needed for the older drivers in
are no longer necessary when using these dynamically linkable drivers;
they are still needed for the older drivers in
<filename>contrib/dlz/drivers</filename>.
</para>
<para>
When the DLZ module provides data to <command>named</command>, it does so in text format.
The response is converted to DNS wire format by <command>named</command>. This
The DLZ module provides data to <command>named</command> in text format,
which is then converted to DNS wire format by <command>named</command>. This
conversion, and the lack of any internal caching, places significant
limits on the query performance of DLZ modules. Consequently, DLZ is
not recommended for use on high-volume servers. However, it can be
used in a hidden master configuration, with slaves retrieving zone
updates via AXFR. (Note, however, that DLZ has no built-in support for
DNS notify; slaves are not automatically informed of changes to the
zones in the database.)
used in a hidden primary configuration, with secondaries retrieving zone
updates via AXFR. Note, however, that DLZ has no built-in support for
DNS notify; secondary servers are not automatically informed of changes to the
zones in the database.
</para>
<section><info><title>Configuring DLZ</title></info>
......@@ -67,9 +67,9 @@
loaded at runtime by the dlopen DLZ driver. Multiple
<command>dlz</command> statements can be specified; when
answering a query, all DLZ modules with <option>search</option>
set to <literal>yes</literal> will be queried to find out if
they contain an answer for the query name; the best available
answer will be returned to the client.
set to <literal>yes</literal> are queried to see whether
they contain an answer for the query name. The best available
answer is returned to the client.
</para>
<para>
The <option>search</option> option in the above example can be
......@@ -79,11 +79,11 @@
If <option>search</option> is set to <literal>no</literal>, then
this DLZ module is <emphasis>not</emphasis> searched for the best
match when a query is received. Instead, zones in this DLZ must be
separately specified in a zone statement. This allows you to
configure a zone normally using standard zone option semantics,
but specify a different database back-end for storage of the
separately specified in a zone statement. This allows users to
configure a zone normally using standard zone-option semantics,
but specify a different database backend for storage of the
zone's data. For example, to implement NXDOMAIN redirection using
a DLZ module for back-end storage of redirection rules:
a DLZ module for backend storage of redirection rules:
</para>
<screen>
dlz other {
......@@ -100,9 +100,9 @@
<section><info><title>Sample DLZ Driver</title></info>
<para>
For guidance in implementation of DLZ modules, the directory
For guidance in the implementation of DLZ modules, the directory
<filename>contrib/dlz/example</filename> contains a basic
dynamically-linkable DLZ module--i.e., one which can be
dynamically linkable DLZ module - i.e., one which can be
loaded at runtime by the "dlopen" DLZ driver.
The example sets up a single zone, whose name is passed
to the module as an argument in the <command>dlz</command>
......@@ -115,7 +115,7 @@
</screen>
<para>
In the above example, the module is configured to create a zone
"example.nil", which can answer queries and AXFR requests, and
"example.nil", which can answer queries and AXFR requests and
accept DDNS updates. At runtime, prior to any updates, the zone
contains an SOA, NS, and a single A record at the apex:
</para>
......@@ -127,13 +127,13 @@
example.nil. 1800 IN A 10.53.0.1
</screen>
<para>
The sample driver is capable of retrieving information about the
querying client, and altering its response on the basis of this
The sample driver can retrieve information about the
querying client and alter its response on the basis of this
information. To demonstrate this feature, the example driver
responds to queries for "source-addr.<option>zonename</option>&gt;/TXT"
with the source address of the query. Note, however, that this
record will *not* be included in AXFR or ANY responses. Normally,
this feature would be used to alter responses in some other fashion,
record will <emphasis>not</emphasis> be included in AXFR or ANY responses. Normally,
this feature is used to alter responses in some other fashion,
e.g., by providing different address records for a particular name
depending on the network from which the query arrived.
</para>
......@@ -141,7 +141,7 @@
Documentation of the DLZ module API can be found in
<filename>contrib/dlz/example/README</filename>. This directory also
contains the header file <filename>dlz_minimal.h</filename>, which
defines the API and should be included by any dynamically-linkable
defines the API and should be included by any dynamically linkable
DLZ module.
</para>
</section>
......
......@@ -15,15 +15,15 @@
<section><info><title>Converting from insecure to secure</title></info>
</section>
<para>Changing a zone from insecure to secure can be done in two
ways: using a dynamic DNS update, or the
<para>A zone ca be changed from insecure to secure in two
ways: using a dynamic DNS update, or via the
<command>auto-dnssec</command> zone option.</para>
<para>For either method, you need to configure
<command>named</command> so that it can see the
<para>For either method,
<command>named</command> must be configured so that it can see the
<filename>K*</filename> files which contain the public and private
parts of the keys that will be used to sign the zone. These files
will have been generated by
<command>dnssec-keygen</command>. You can do this by placing them
parts of the keys that are used to sign the zone. These files
are generated by
<command>dnssec-keygen</command>, and they should be placed
in the key-directory, as specified in
<filename>named.conf</filename>:</para>
<programlisting>
......@@ -35,11 +35,11 @@
};
</programlisting>
<para>If one KSK and one ZSK DNSKEY key have been generated, this
configuration will cause all records in the zone to be signed
with the ZSK, and the DNSKEY RRset to be signed with the KSK as
well. An NSEC chain will be generated as part of the initial
configuration causes all records in the zone to be signed
with the ZSK, and the DNSKEY RRset to be signed with the KSK.
An NSEC chain is generated as part of the initial
signing process.</para>
<section><info><title>Dynamic DNS update method</title></info>
<section><info><title>Dynamic DNS Update Method</title></info>
</section>
<para>To insert the keys via dynamic update:</para>
......@@ -50,15 +50,15 @@
&gt; update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
&gt; send
</screen>
<para>While the update request will complete almost immediately,
the zone will not be completely signed until
<command>named</command> has had time to walk the zone and
<para>While the update request completes almost immediately,
the zone is not completely signed until
<command>named</command> has had time to "walk" the zone and
generate the NSEC and RRSIG records. The NSEC record at the apex
will be added last, to signal that there is a complete NSEC
is added last, to signal that there is a complete NSEC
chain.</para>
<para>If you wish to sign using NSEC3 instead of NSEC, you should
add an NSEC3PARAM record to the initial update request. If you
wish the NSEC3 chain to have the OPTOUT bit set, set it in the
<para>To sign using NSEC3 instead of NSEC,
add an NSEC3PARAM record to the initial update request.
The OPTOUT bit in the NSEC3 chain can be set in the
flags field of the NSEC3PARAM record.</para>
<screen>
% nsupdate
......@@ -68,15 +68,15 @@
&gt; update add example.net NSEC3PARAM 1 1 100 1234567890
&gt; send
</screen>
<para>Again, this update request will complete almost
immediately; however, the record won't show up until
<para>Again, this update request completes almost
immediately; however, the record does not show up until
<command>named</command> has had a chance to build/remove the
relevant chain. A private type record will be created to record
the state of the operation (see below for more details), and will
be removed once the operation completes.</para>
relevant chain. A private type record is created to record
the state of the operation (see below for more details), and is
removed once the operation completes.</para>
<para>While the initial signing and NSEC/NSEC3 chain generation
is happening, other updates are possible as well.</para>
<section><info><title>Fully automatic zone signing</title></info>
<section><info><title>Fully Automatic Zone Signing</title></info>
</section>
<para>To enable automatic signing, add the
......@@ -89,69 +89,69 @@
<command>auto-dnssec allow</command>,
<command>named</command> can search the key directory for keys
matching the zone, insert them into the zone, and use them to
sign the zone. It will do so only when it receives an
sign the zone. It does so only when it receives an
<command>rndc sign &lt;zonename&gt;</command>.</para>
<para>
<!-- TODO: this is repeated in the ARM -->
<command>auto-dnssec maintain</command> includes the above
functionality, but will also automatically adjust the zone's
DNSKEY records on schedule according to the keys' timing metadata.
functionality, but also automatically adjusts the zone's
DNSKEY records on a schedule according to the keys' timing metadata.
(See <xref linkend="man.dnssec-keygen"/> and
<xref linkend="man.dnssec-settime"/> for more information.)
</para>
<para>
<command>named</command> will periodically search the key directory
for keys matching the zone, and if the keys' metadata indicates
that any change should be made the zone, such as adding, removing,
or revoking a key, then that action will be carried out. By default,
<command>named</command> periodically searches the key directory
for keys matching the zone; if the keys' metadata indicates
that any change should be made to the zone - such as adding, removing,
or revoking a key - then that action is carried out. By default,
the key directory is checked for changes every 60 minutes; this period
can be adjusted with the <option>dnssec-loadkeys-interval</option>, up
can be adjusted with <option>dnssec-loadkeys-interval</option>, up
to a maximum of 24 hours. The <command>rndc loadkeys</command> forces
<command>named</command> to check for key updates immediately.
</para>
<para>
If keys are present in the key directory the first time the zone
is loaded, the zone will be signed immediately, without waiting for an
is loaded, the zone is signed immediately, without waiting for an
<command>rndc sign</command> or <command>rndc loadkeys</command>
command. (Those commands can still be used when there are unscheduled
key changes, however.)
command. Those commands can still be used when there are unscheduled
key changes.
</para>
<para>
When new keys are added to a zone, the TTL is set to match that
of any existing DNSKEY RRset. If there is no existing DNSKEY RRset,
then the TTL will be set to the TTL specified when the key was
the TTL is set to the TTL specified when the key was
created (using the <command>dnssec-keygen -L</command> option), if
any, or to the SOA TTL.
</para>
<para>
If you wish the zone to be signed using NSEC3 instead of NSEC,
To sign the zone using NSEC3 instead of NSEC,
submit an NSEC3PARAM record via dynamic update prior to the
scheduled publication and activation of the keys. If you wish the
NSEC3 chain to have the OPTOUT bit set, set it in the flags field
of the NSEC3PARAM record. The NSEC3PARAM record will not appear in
the zone immediately, but it will be stored for later reference. When
scheduled publication and activation of the keys.
The OPTOUT bit for the NSEC3 chain can be set in the flags field
of the NSEC3PARAM record. The NSEC3PARAM record does not appear in
the zone immediately, but it is stored for later reference. When
the zone is signed and the NSEC3 chain is completed, the NSEC3PARAM
record will appear in the zone.
record appears in the zone.
</para>
<para>Using the
<command>auto-dnssec</command> option requires the zone to be
configured to allow dynamic updates, by adding an
<command>allow-update</command> or
<command>update-policy</command> statement to the zone
configuration. If this has not been done, the configuration will
fail.</para>
<section><info><title>Private-type records</title></info>
configuration. If this has not been done, the configuration
fails.</para>
<section><info><title>Private Type Records</title></info>
</section>
<para>The state of the signing process is signaled by
private-type records (with a default type value of 65534). When
signing is complete, these records will have a nonzero value for
the final octet (for those records which have a nonzero initial
octet).</para>
<para>The private type record format: If the first octet is
non-zero then the record indicates that the zone needs to be
private type records (with a default type value of 65534). When
signing is complete, these records with a non-zero initial octet
have a non-zero value for the final octet.</para>
<para>If the first octet of a private type record is
non-zero, the record indicates either that the zone needs to be
signed with the key matching the record, or that all signatures
that match the record should be removed.</para>
that match the record should be removed. Here are the meanings
of the different values of the first octet:</para>
<para>
<literallayout>
<!-- TODO: how to format this? -->
......@@ -162,13 +162,13 @@
</literallayout>
</para>
<para>Only records flagged as "complete" can be removed via
dynamic update. Attempts to remove other private type records
will be silently ignored.</para>
dynamic update; attempts to remove other private type records
are silently ignored.</para>
<para>If the first octet is zero (this is a reserved algorithm
number that should never appear in a DNSKEY record) then the
record indicates changes to the NSEC3 chains are in progress. The
rest of the record contains an NSEC3PARAM record. The flag field
tells what operation to perform based on the flag bits.</para>
number that should never appear in a DNSKEY record), the
record indicates that changes to the NSEC3 chains are in progress. The
rest of the record contains an NSEC3PARAM record, while the flag field
tells what operation to perform based on the flag bits:</para>
<para>
<literallayout>
<!-- TODO: how to format this? -->
......@@ -178,97 +178,95 @@
0x20 NONSEC
</literallayout>
</para>
<section><info><title>DNSKEY rollovers</title></info>
<section><info><title>DNSKEY Rollovers</title></info>
</section>
<para>As with insecure-to-secure conversions, rolling DNSSEC
keys can be done in two ways: using a dynamic DNS update, or the
<para>As with insecure-to-secure conversions, DNSSEC keyrolls
can be done in two ways: using a dynamic DNS update, or via the
<command>auto-dnssec</command> zone option.</para>
<section><info><title>Dynamic DNS update method</title></info>
<section><info><title>Dynamic DNS Update Method</title></info>
</section>
<para> To perform key rollovers via dynamic update, you need to add
the <filename>K*</filename> files for the new keys so that
<command>named</command> can find them. You can then add the new
DNSKEY RRs via dynamic update.
<command>named</command> will then cause the zone to be signed
with the new keys. When the signing is complete the private type
records will be updated so that the last octet is non
zero.</para>
<para>If this is for a KSK you need to inform the parent and any
trust anchor repositories of the new KSK.</para>
<para>You should then wait for the maximum TTL in the zone before
<para> To perform key rollovers via dynamic update,
the <filename>K*</filename> files for the new keys must be added so that
<command>named</command> can find them. The new
DNSKEY RRs can then be added via dynamic update.
<command>named</command> then causes the zone to be signed
with the new keys; when the signing is complete, the private type
records are updated so that the last octet is non-zero.</para>
<para>If this is for a KSK, the parent and any
trust anchor repositories of the new KSK must be informed.</para>
<para>The maximum TTL in the zone must expire before
removing the old DNSKEY. If it is a KSK that is being updated,
you also need to wait for the DS RRset in the parent to be
updated and its TTL to expire. This ensures that all clients will
be able to verify at least one signature when you remove the old
DNSKEY.</para>
<para>The old DNSKEY can be removed via UPDATE. Take care to
the DS RRset in the parent must also be
updated its TTL allowed to expire. This ensures that all clients
are able to verify at least one signature when the old DNSKEY is removed.</para>
<para>The old DNSKEY can be removed via UPDATE, taking care to
specify the correct key.
<command>named</command> will clean out any signatures generated
<command>named</command> cleans out any signatures generated
by the old key after the update completes.</para>
<section><info><title>Automatic key rollovers</title></info>
<section><info><title>Automatic Key Rollovers</title></info>
</section>
<para>When a new key reaches its activation date (as set by
<command>dnssec-keygen</command> or <command>dnssec-settime</command>),
if the <command>auto-dnssec</command> zone option is set to
<constant>maintain</constant>, <command>named</command> will
automatically carry out the key rollover. If the key's algorithm
has not previously been used to sign the zone, then the zone will
be fully signed as quickly as possible. However, if the new key
is replacing an existing key of the same algorithm, then the
zone will be re-signed incrementally, with signatures from the
old key being replaced with signatures from the new key as their
and if the <command>auto-dnssec</command> zone option is set to
<constant>maintain</constant>, <command>named</command>
automatically carries out the key rollover. If the key's algorithm
has not previously been used to sign the zone, then the zone is
fully signed as quickly as possible. However, if the new key
replaces an existing key of the same algorithm, the
zone is re-signed incrementally, with signatures from the
old key replaced with signatures from the new key as their
signature validity periods expire. By default, this rollover
completes in 30 days, after which it will be safe to remove the
completes in 30 days, after which it is safe to remove the
old key from the DNSKEY RRset.</para>
<section><info><title>NSEC3PARAM rollovers via UPDATE</title></info>
<section><info><title>NSEC3PARAM Rollovers via UPDATE</title></info>
</section>
<para>Add the new NSEC3PARAM record via dynamic update. When the