ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Remove auto-dnssec from documentation

Browse Source 
Update the ARM and DNSSEC guide, removing references to 'auto-dnssec',
replacing them with 'dnssec-policy' if needed.

The section "Alternative Ways" of signing has to be refactored, since
we now only focus on one alternative way, that is manual signing.
This commit is contained in:
Matthijs Mekking
2023-07-04 17:08:21 +02:00
parent 71af4f4e0b
commit 10bb8f92a1
6 changed files with 176 additions and 400 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/arm/dnssec.inc.rst
View File

@@ -228,7 +228,7 @@ There are several tools available to manually sign a zone.
To set up a DNSSEC secure zone manually, a series of steps
must be followed. Please see chapter
:ref:`advanced_discussions_manual_key_management_and_signing` in the
:ref:`advanced_discussions_manual_signing` in the
:doc:`dnssec-guide` for more information.
Monitoring with Private Type Records

51
doc/arm/reference.rst
View File

@@ -1766,13 +1766,14 @@ default is used.
:tags: dnssec
:short: Sets the frequency of automatic checks of the DNSSEC key repository.
When a zone is configured with ``auto-dnssec maintain;``, its key
repository must be checked periodically to see if any new keys have
been added or any existing keys' timing metadata has been updated
(see :ref:`man_dnssec-keygen` and :ref:`man_dnssec-settime`).
The :any:`dnssec-loadkeys-interval` option
sets the frequency of automatic repository checks, in minutes. The
default is ``60`` (1 hour), the minimum is ``1`` (1 minute), and
When a zone is configured with ``dnssec-policy;``, its key
repository must be checked periodically to see if the next step of a key
rollover is due. The :any:`dnssec-loadkeys-interval` option
sets the default interval of key repository checks, in minutes, in case
the next key event cannot be calculated (for example because a DS record
needs to be published).
The default is ``60`` (1 hour), the minimum is ``1`` (1 minute), and
the maximum is ``1440`` (24 hours); any higher value is silently
reduced.
@@ -2520,39 +2521,6 @@ Boolean Options
log when the serial number on the primary is less than what :iscman:`named`
currently has. The default is ``no``.
.. namedconf:statement:: auto-dnssec
:tags: dnssec
:short: Permits varying levels of automatic DNSSEC key management.
Zones configured for dynamic DNS may use this option to allow varying
levels of automatic DNSSEC key management. There are three possible
settings:
``auto-dnssec allow;`` permits keys to be updated and the zone fully
re-signed whenever the user issues the command :option:`rndc sign zonename <rndc sign>`.
``auto-dnssec maintain;`` includes the above, but also
automatically adjusts the zone's DNSSEC keys on a schedule, according
to the keys' timing metadata (see :ref:`man_dnssec-keygen` and
:ref:`man_dnssec-settime`). The command :option:`rndc sign zonename <rndc sign>`
causes :iscman:`named` to load keys from the key repository and sign the
zone with all keys that are active. :option:`rndc loadkeys zonename <rndc loadkeys>`
causes :iscman:`named` to load keys from the key repository and schedule
key maintenance events to occur in the future, but it does not sign
the full zone immediately. Note: once keys have been loaded for a
zone the first time, the repository is searched for changes
periodically, regardless of whether :option:`rndc loadkeys` is used. The
recheck interval is defined by :any:`dnssec-loadkeys-interval`.
``auto-dnssec off;`` does not allow for DNSSEC key management.
This is the default setting.
This option may only be activated at the zone level; if configured
at the view or options level, it must be set to ``off``.
The DNSSEC records are written to the zone's filename set in :any:`file`,
unless :any:`inline-signing` is enabled.
.. namedconf:statement:: dnssec-validation
:tags: dnssec
:short: Enables DNSSEC validation in :iscman:`named`.
@@ -7160,9 +7128,6 @@ Zone Options
:any:`key-directory`
See the description of :any:`key-directory` in :namedconf:ref:`options`.
:any:`auto-dnssec`
See the description of :any:`auto-dnssec` in :namedconf:ref:`options`.
:any:`serial-update-method`
See the description of :any:`serial-update-method` in :namedconf:ref:`options`.

10
doc/design/cds-child
View File

@@ -29,10 +29,12 @@ information regarding copyright ownership.
Non-matching CDS and CDNSKEY are removed.
* auto-dnssec maintain should cds and/or cdnskey to zone apex iff the
DNSKEY is published and is signing the DNSKEY RRset. CDS and CDNSKEY
records are only removed if there is a deletion date set (implicit on
matching DNSKEY going inactive / unpublished or explicit).
* dnssec-policy publishes cds and/or cdnskey to zone apex iff the
DNSKEY is published, is signing the DNSKEY RRset, and if it has been
propagated into caches.
CDS and CDNSKEY records are removed if the corresponding DNSKEY has
been removed from zone and caches.
* UPDATE should check that CDS and CDNSKEY match a active DNSKEY that
is signing the DNSKEY RRset and ignore otherwise. This should be

51
doc/dnssec-guide/advanced-discussions.rst
View File

@@ -683,12 +683,10 @@ damage be if a key were compromised without you knowing about it? How
serious would a key roll failure be?
Before going any further, it is worth noting that if you sign your zone
with either of the fully automatic methods (described in ref:`signing_alternative_ways`),
you don't really need to
concern yourself with the details of a key rollover: BIND 9 takes care of
it all for you. If you are doing a manual key roll or are setting up the
keys for a semi-automatic key rollover, you do need to familiarize yourself
with the various steps involved and the timing details.
with :any:`dnssec-policy`, you don't really need to concern yourself with the
details of a key rollover: BIND 9 takes care of it all for you. If you are
doing a manual key roll, you do need to familiarize yourself with the various
steps involved and the timing details.
Rolling a key is not as simple as replacing the DNSKEY statement in the
zone. That is an essential part of it, but timing is everything. For
@@ -884,50 +882,11 @@ roll over DNSKEYs to a new algorithm, e.g., from RSASHA1 (algorithm 5 or
care to avoid breaking DNSSEC validation.
If you are managing DNSSEC by using the :any:`dnssec-policy` configuration,
:iscman:`named` handles the rollover for you. Simply change the algorithm
:iscman:`named` handles these steps for you. Simply change the algorithm
for the relevant keys, and :iscman:`named` uses the new algorithm when the
key is next rolled. It performs a smooth transition to the new
algorithm, ensuring that the zone remains valid throughout rollover.
If you are using other methods to sign the zone, the administrator needs to do
more work. The first step is to put DNSKEYs in place using the new algorithm.
You must generate the ``K*`` files for the new algorithm and put
them in the zone's key directory, where :iscman:`named` can access them. Take
care to set appropriate ownership and permissions on the keys. If the
:any:`auto-dnssec` zone option is set to ``maintain``, :iscman:`named`
automatically signs the zone with the new keys, based on their timing
metadata when the :any:`dnssec-loadkeys-interval` elapses or when you issue the
:option:`rndc loadkeys` command.
Once the zone has been signed by the new DNSKEYs (and you have waited
for at least one TTL period), you must inform the parent zone and any trust
anchor repositories of the new KSKs, e.g., you might place DS records in
the parent zone through your DNS registrar's website.
Before starting to remove the old algorithm from a zone, you must allow
the maximum TTL on its DS records in the parent zone to expire. This
assures that any subsequent queries retrieve the new DS records
for the new algorithm. After the TTL has expired, you can remove the DS
records for the old algorithm from the parent zone and any trust anchor
repositories. You must then allow another maximum TTL interval to elapse
so that the old DS records disappear from all resolver caches.
The next step is to remove the DNSKEYs using the old algorithm from your
zone. Again this can be accomplished using :iscman:`nsupdate` to delete the
old DNSKEYs (for primary zones only) or by automatic key rollover when
:any:`auto-dnssec` is set to ``maintain``. You can cause the automatic key
rollover to take place immediately by using the :iscman:`dnssec-settime`
utility to set the *Delete* date on all keys to any time in the past.
(See the :option:`dnssec-settime -D date/offset <dnssec-settime -D>` option.)
After adjusting the timing metadata, the :option:`rndc loadkeys` command
causes :iscman:`named` to remove the DNSKEYs and RRSIGs for the old algorithm
from the zone.
Once you have verified that the old DNSKEYs and RRSIGs have been removed
from the zone, the final (optional) step is to remove the key files for
the old algorithm from the key directory.
Other Topics
~~~~~~~~~~~~

2
doc/dnssec-guide/recipes.rst
View File

@@ -325,7 +325,7 @@ the new ZSK is in effect:
These are all the manual tasks you need to perform for a ZSK rollover.
If you have followed the configuration examples in this guide of using
:any:`inline-signing` and :any:`auto-dnssec`, everything else is automated for
:any:`inline-signing` and :any:`dnssec-policy`, everything else is automated for
you by BIND.
Day of ZSK Rollover

460
doc/dnssec-guide/signing.rst
View File

@@ -649,13 +649,10 @@ That is quite complex, and it is all handled in BIND 9 with the single
setting up our own DNSSEC policy with customized parameters. However, in many
cases the defaults are adequate.
At the time of this writing (mid-2020), :any:`dnssec-policy` is still a
relatively new feature in BIND. Although it is the preferred
way to run DNSSEC in a zone, it is not yet able to automatically implement
all the features that are available
with a more "hands-on" approach to signing and key maintenance. For this
reason, we cover alternative signing techniques in
:ref:`signing_alternative_ways`.
:any:`dnssec-policy` is the preferred way to run DNSSEC in a zone, but sometimes
a more "hands-on" approach to signing and key maintenance is needed. For this
reason, we cover manual signing techniques in
:ref:`advanced_discussions_manual_signing`.
.. _working_with_parent_zone:
@@ -960,165 +957,71 @@ to tell :iscman:`named` that the DS record has been published.
record it finds by querying our zone really comes from our zone; thus, it
needs to use some other form of secure transfer to obtain the information.
.. _signing_alternative_ways:
.. _advanced_discussions_manual_signing:
Alternate Ways of Signing a Zone
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Manual Signing
~~~~~~~~~~~~~~
Although use of the automatic :any:`dnssec-policy` is the preferred way to sign zones in
BIND, there are occasions where a more manual approach may be
needed, such as when external hardware is used to
generate and sign the zone. :any:`dnssec-policy` does not currently support
the use of external hardware, so if your security policy requires it, you
need to use one of the methods described here.
Manual signing of a zone was the first method of signing introduced into
BIND and offers, as the name suggests, no automation. The user must
handle everything: create the keys, sign the zone file with them, load
the signed zone, periodically re-sign the zone, and manage key rolls,
including interaction with the parent. A user certainly can do all this,
but why not use one of the automated methods?
The idea of DNSSEC was first discussed in the 1990s and has been
extensively developed over the intervening years. BIND has tracked the
development of this technology, often being the first name server
implementation to introduce new features. However, for compatibility reasons, BIND
retained older ways of doing things even when new ways were added. This
particularly applies to signing and maintaining zones, where different
levels of automation are available.
Although use of the automatic :any:`dnssec-policy` is the preferred way to
sign zones in BIND, there are occasions where a manual approach may be needed.
:any:`dnssec-policy` does not currently support the use of external hardware,
so if your security policy requires it, you need to use manual signing.
The following is a list of the available methods of signing in BIND, in the
order that they were introduced - and in order of decreasing
complexity.
BIND 9 ships with several tools that are used in this process, which are
explained in more detail below. In all cases, the ``-h`` option prints a full
list of parameters. Note that the DNSSEC tools require the keyset files to be
in the working directory or the directory specified by the ``-d`` option.
Manual
"Manual" signing was the first method to be introduced into BIND and
its name describes it perfectly: the user needs to do everything. In the
more-automated methods, you load an unsigned zone file into
:iscman:`named`, which takes care of signing it. With manual signing, you
have to provide a signed zone for :iscman:`named` to serve.
In practice, this means creating an unsigned zone file as usual, then
using the BIND-provided tools :iscman:`dnssec-keygen` to create the keys
and :iscman:`dnssec-signzone` to sign the zone. The signed zone is stored
in another file and is the one you tell BIND to load. To
update the zone (for example, to add a resource record), you update the
unsigned zone, re-sign it, and tell :iscman:`named` to load the updated
signed copy. The same goes for refreshing signatures or rolling keys;
the user is responsible for providing the signed zone served by
:iscman:`named`. (In the case of rolling keys, you are also responsible for
ensuring that the keys are added and removed at the correct times.)
Why would you want to sign your zone this way? You probably
wouldn't in the normal course of events, but as there may be
circumstances in which it is required, the scripts have been left in
the BIND distribution.
Semi-Automatic
The first step in DNSSEC automation came with BIND 9.7, when the
:any:`auto-dnssec` option was added. This causes :iscman:`named` to
periodically search the directory holding the key files (see
:ref:`generate_keys` for a description) and to
use the information in them to both add and remove keys and sign the
zone.
Use of :any:`auto-dnssec` alone requires that the zone be dynamic,
something not suitable for a number of situations, so BIND 9.9 added the
:any:`inline-signing` option. With this, :iscman:`named` essentially keeps the
signed and unsigned copies of the zone separate. The signed zone is
created from the unsigned one using the key information; when the
unsigned zone is updated and the zone reloaded, :iscman:`named` detects the
changes and updates the signed copy of the zone.
This mode of signing has been termed "semi-automatic" in this
document because keys still have to be manually created (and deleted
when appropriate). Although not an onerous task, it is still
additional work.
Why would anyone want to use this
method when fully automated ones are available? At the time of
this writing (mid-2020), the fully automatic methods cannot handle all scenarios,
particularly that of having a single key shared among multiple
zones. They also do not handle keys stored in Hardware Security
Modules (HSMs), which are briefly covered in
:ref:`hardware_security_modules`.
Fully Automatic with ``dnssec-keymgr``
The next step in the automation of DNSSEC operations came with BIND
9.11, which introduced the ``dnssec-keymgr`` utility. This is a
separate program and was expected to be run on a regular basis
(probably via ``cron``). It read a DNSSEC policy from its
configuration file and read timing information from the DNSSEC key
files. With this information it created new key files with timing
information in them consistent with the policy. :iscman:`named` was run as
usual, picking up the timing information in the key files to
determine when to add and remove keys, and when to sign with them.
In BIND 9.17.0 and later, this method of handling DNSSEC
policies has been replaced by the :any:`dnssec-policy` statement in the
configuration file.
Fully Automatic with :any:`dnssec-policy`
Introduced a BIND 9.16, :any:`dnssec-policy` replaces ``dnssec-keymgr`` from BIND
9.17 onwards and avoids the need to run a separate program. It also
handles the creation of keys if a zone is added (``dnssec-keymgr``
requires an initial key) and deletes old key files as they are
removed from the zone. This is the method described in
:ref:`easy_start_guide_for_authoritative_servers`.
We now look at some of these methods in more detail. We cover
semi-automatic signing first, as that contains a lot of useful
information about keys and key timings. After that, we
touch on fully automatic signing with :any:`dnssec-policy`. Since this has
already been described in
:ref:`easy_start_guide_for_authoritative_servers`, we will just
mention a few additional points. Finally, we briefly describe manual signing.
.. _semi_automatic_signing:
Semi-Automatic Signing
^^^^^^^^^^^^^^^^^^^^^^
As noted above, the term semi-automatic signing has been used in this
document to indicate the mode of signing enabled by the :any:`auto-dnssec`
and :any:`inline-signing` keywords. :iscman:`named` signs the zone without any
manual intervention, based purely on the timing information in the
DNSSEC key files. The files, however, must be created manually.
By appropriately setting the key parameters and the timing information
in the key files, you can implement any DNSSEC policy you want for your
zones. But why manipulate the key information yourself rather than rely
on :any:`dnssec-policy` to do it for you? The answer
is that semi-automatic signing allows you to do things that, at the time of this writing
(mid-2020), are currently not possible with one of the key managers: for
example, the ability to use an HSM to store keys, or the ability to use
the same key for multiple zones.
To convert a traditional
(insecure) DNS zone to a secure one, we need to create various
additional records (DNSKEY, RRSIG, NSEC/NSEC3) and, as with
To convert a traditional (insecure) DNS zone to a secure one, we need to
create various additional records (DNSKEY, RRSIG, NSEC/NSEC3) and, as with
fully automatic signing, to upload verifiable information (such as a DS
record) to the parent zone to complete the chain of trust.
The first step is to create the keys as described in
:ref:`manual_signing_generate_keys`, then using the BIND-provided tools
:iscman:`dnssec-keygen` to create the keys and
:iscman:`dnssec-signzone` to sign the zone. The signed zone is stored in
another file and is the one you tell BIND to load. To update the zone (for
example, to add a resource record), you update the unsigned zone, re-sign it,
and tell :iscman:`named` to load the updated signed copy. The same goes for
refreshing signatures or rolling keys; the user is responsible for providing
the signed zone served by :iscman:`named`. (In the case of rolling keys, you
are also responsible for ensuring that the keys are added and removed at the
correct times.)
Why would you want to sign your zone this way? You probably wouldn't in the
normal course of events, but as there may be circumstances in which it is
required, the scripts have been left in the BIND distribution.
.. note::
Again, we assume all configuration files, key
files, and zone files are stored in ``/etc/bind``, and most examples
show commands run
as the root user. This may not be ideal, but the point is not
to distract from what is important here: learning how to sign
a zone. There are many best practices for deploying a more secure
BIND installation, with techniques such as jailed process and
restricted user privileges, but those are not covered
in this document. We trust you, a responsible DNS
administrator, to take the necessary precautions to secure your
system.
Again, we assume all configuration files, key files, and zone files are
stored in ``/etc/bind``, and most examples show commands run as the root
user. This may not be ideal, but the point is not to distract from what is
important here: learning how to sign a zone. There are many best practices
for deploying a more secure BIND installation, with techniques such as
jailed process and restricted user privileges, but those are not covered
in this document. We trust you, a responsible DNS administrator, to take
the necessary precautions to secure your system.
For our examples below, we work with the assumption that
there is an existing insecure zone ``example.com`` that we are
converting to a secure version. The secure version uses both a KSK
and a ZSK.
For our examples below, we work with the assumption that there is an
existing insecure zone ``example.com`` that we are converting to a secure
version. The secure version uses both a KSK and a ZSK.
.. _generate_keys:
.. _manual_signing_generate_keys:
Generate Keys
+++++++++++++
^^^^^^^^^^^^^
Everything in DNSSEC centers around keys, so we begin by
generating our own keys.
Everything in DNSSEC centers around keys, so we begin by generating our own
keys.
.. code-block:: console
@@ -1178,15 +1081,23 @@ Alternativelly, the :iscman:`dnssec-keyfromlabel` program is used to get a key
pair from a crypto hardware device and build the key files. Its usage is
similar to :iscman:`dnssec-keygen`.
Setting Key Timing Information
++++++++++++++++++++++++++++++
.. _manual_signing_key_timing_information:
You may remember that in the above description of this method, we said
that time information related to rolling keys is stored in the key
files. This is placed there by :iscman:`dnssec-keygen` when the file is
created, and it can be modified using :iscman:`dnssec-settime`. By default,
only a limited amount of timing information is included in the file, as
illustrated in the examples in the previous section.
Setting Key Timing Information
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Key files contain time information related to rolling keys. This is placed
there by :iscman:`dnssec-keygen` when the file is created, and it can be
modified using :iscman:`dnssec-settime`. By default, only a limited amount of
timing information is included in the file, as illustrated in the examples in
the previous section.
Note that :any:`dnssec-policy` does set key timing information, but it uses its
own state machine to determine what actions to perform.
But when performing manual signing the key parameters and the timing
information in the key files, you can implement any DNSSEC policy you want for
your zones.
All the dates are the same, and are the date and time that
:iscman:`dnssec-keygen` created the key. We can use :iscman:`dnssec-settime` to
@@ -1283,142 +1194,43 @@ This can be summarized as follows:
| | | | from a zone |
+----------+------------------+------------------+------------------+
The publication date is the date the key is introduced into the zone.
Sometime later it is activated and is used to sign resource records.
After a specified period, BIND stops using it to sign records, and at some
other specified later time it is removed from the zone.
The publication date is the date the key should be introduced into the zone.
The activation date can be used to determine when to sign resource records.
With "Inactive" you signal when the signer should stop generating new
signatures with the given key, and the "Delete" metadata specifies when the key
should be removed from the zone.
Finally, we should note that the :iscman:`dnssec-keygen` command supports the
same set of switches so we could have set the dates
when we created the key.
.. _semi_automatic_signing_reconfigure_bind:
.. [#]
The dates can also be modified using an editor, but that is likely to
be more error-prone than using :iscman:`dnssec-settime`.
Reconfiguring BIND
++++++++++++++++++
.. [#]
Only one key file - for either a KSK or ZSK - is needed to signal the
presence of the zone. :iscman:`dnssec-keygen` creates files of both
types as needed.
Having created the keys with the appropriate timing information, the
next step is to turn on DNSSEC signing. Below is a very simple
:iscman:`named.conf`; in our example environment, this file is
``/etc/bind/named.conf``.
.. _manual_signing_the_zone:
::
Signing the Zone
^^^^^^^^^^^^^^^^
options {
directory "/etc/bind";
recursion no;
minimal-responses yes;
};
Now, edit the zone file to make sure the proper DNSKEY entries are included.
The public keys should be inserted into the zone file by including the
``.key`` files using ``$INCLUDE`` statements.
zone "example.com" IN {
type primary;
file "example.com.db";
auto-dnssec maintain;
inline-signing yes;
};
Once the configuration file is updated, tell :iscman:`named` to
reload:
::
# rndc reload
server reload successful
.. _semi_automated_signing_verification:
Verifying That the Zone Is Signed Correctly
+++++++++++++++++++++++++++++++++++++++++++
You should now check that the zone is signed. Follow the steps in
:ref:`signing_verification`.
.. _semi_automatic_signing_upload_ds:
Uploading the DS Record to the Parent
+++++++++++++++++++++++++++++++++++++
As described in :ref:`signing_easy_start_upload_to_parent_zone`, we
must now upload the new information to the parent zone. The format of the
information and how to generate it is described in
:ref:`working_with_parent_zone`, although it is important to remember that you must
use the contents of the KSK file that you generated above as part of the
process.
When the DS record is published in the parent zone, your zone is fully
signed.
Checking That Your Zone Can Be Validated
++++++++++++++++++++++++++++++++++++++++
Finally, follow the steps in :ref:`how_to_test_authoritative_server`
to confirm that a query recognizes the zone as properly signed and
vouched for by the parent zone.
So... What Now?
+++++++++++++++
Once the zone is signed, it must be monitored as described
in :ref:`signing_maintenance_tasks`. However,
as the time approaches for a key roll, you must create the new key. Of
course, it is possible to create keys for the next fifty
years all at once and set the key times appropriately. Whether the
increased risk in having the private key files for future keys available
on disk offsets the overhead of having to remember to create a new key
before a rollover depends on your organization's security policy.
.. _advanced_discussions_automatic_dnssec-policy:
Fully Automatic Signing With :any:`dnssec-policy`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Since BIND 9.16, key management is fully integrated ingo :iscman:`named`.
Managing the signing process and rolling of these keys has been described in
:ref:`easy_start_guide_for_authoritative_servers` and is not
repeated here. A few points are worth noting, though:
- The :any:`dnssec-policy` statement in the :iscman:`named` configuration file
describes all aspects of the DNSSEC policy, including the signing.
- The :any:`dnssec-policy` statement requires to zone to use dynamic DNS,
or that :any:`inline-signing` is enabled.
.. _advanced_discussions_manual_key_management_and_signing:
Manual Signing
^^^^^^^^^^^^^^
Manual signing of a zone was the first method of signing introduced into
BIND and offers, as the name suggests, no automation. The user must
handle everything: create the keys, sign the zone file with them, load
the signed zone, periodically re-sign the zone, and manage key rolls,
including interaction with the parent. A user certainly can do all this,
but why not use one of the automated methods? Nevertheless, it may
be useful for test purposes, so we cover it briefly here.
BIND 9 ships with several tools that are used in
this process, which are explained in more detail below. In all cases,
the ``-h`` option prints a full list of parameters. Note that the DNSSEC
tools require the keyset files to be in the working directory or the
directory specified by the ``-d`` option.
The first step is to create the keys as described in :ref:`generate_keys`.
Then, edit the zone file to make sure the proper DNSKEY entries are included.
The public keys should be inserted into the zone file by
including the ``.key`` files using ``$INCLUDE`` statements.
Finally, use the command :iscman:`dnssec-signzone`.
Any ``keyset`` files corresponding to secure sub-zones should be
present. The zone signer generates ``NSEC``, ``NSEC3``, and ``RRSIG``
records for the zone, as well as ``DS`` for the child zones if
:option:`-g <dnssec-signzone -g>` is specified. If
Use the command :iscman:`dnssec-signzone`. Any ``keyset`` files corresponding
to secure sub-zones should be present. The zone signer generates ``NSEC``,
``NSEC3``, and ``RRSIG`` records for the zone, as well as ``DS`` for the child
zones if :option:`-g <dnssec-signzone -g>` is specified. If
:option:`-g <dnssec-signzone -g>` is not specified, then DS RRsets for the
secure child zones need to be added manually.
By default, all zone keys which have an available private key are used
to generate signatures. The following command signs the zone, assuming
it is in a file called ``zone.child.example``, using manually specified keys:
The following command signs the zone, assuming it is in a file called
``zone.child.example``, using manually specified keys:
.. code-block:: console
@@ -1450,33 +1262,71 @@ and the KSK file name. This also generates a plain-text file
to provide the parent zone administrators with the ``DNSKEY`` records (or their
corresponding ``DS`` records) that are the secure entry point to the zone.
Finally, :iscman:`named.conf` needs to be updated to load the signed version
of the zone, which looks something like this:
By default, all zone keys which have an available private key are used
to generate signatures. You can use the :option:`-S <dnssec-signzone -S>` to
only include keys that have the "Activate" timing metadata in the past and
the "Inactive" timing metadata in the future (or not present).
.. code-block:: none
.. _manual_signing_reloading_zone:
zone "example.com" IN {
type primary;
file "db/example.com.signed.db";
};
Reloading the Zone
^^^^^^^^^^^^^^^^^^
Once the :option:`rndc reconfig` command is issued, BIND serves a signed
zone. The file ``dsset-example.com`` (created by :iscman:`dnssec-signzone`
when it signed the ``example.com`` zone) contains the DS record for the
zone's KSK. You will need to pass that to the administrator of the parent
zone, to be placed in the zone.
Now it is time to inform BIND that a new signed zonefile is available. We can
do this with the :option:`rndc reload example.com <rndc reload>` command.
.. _manual_signing_verification:
Verifying That the Zone Is Signed Correctly
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You should now check that the zone is signed. Follow the steps in
:ref:`signing_verification`.
.. _manual_signing_upload_ds:
Uploading the DS Record to the Parent
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As described in :ref:`signing_easy_start_upload_to_parent_zone`, we must now
upload the new information to the parent zone. The format of the information
and how to generate it is described in :ref:`working_with_parent_zone`,
although it is important to remember that you must use the contents of the
KSK file that you generated above as part of the process.
The file ``dsset-example.com`` (created by :iscman:`dnssec-signzone` when it
signed the ``example.com`` zone) contains the DS record for the zone's KSK.
If not yet done so, you will need to pass that to the administrator of the
parent zone, to be placed in the zone. When the DS record is published in the
parent zone, your zone is fully signed.
.. _manual_signing_validation:
Checking That Your Zone Can Be Validated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Finally, follow the steps in :ref:`how_to_test_authoritative_server`
to confirm that a query recognizes the zone as properly signed and
vouched for by the parent zone.
.. _manual_signing_resigning:
Re-signing the Zone
^^^^^^^^^^^^^^^^^^^
Since this is a manual process, you will need to re-sign periodically,
as well as every time the zone
data changes. You will also need to manually roll the keys by adding and
removing DNSKEY records (and interacting with the parent) at the
appropriate times.
as well as every time the zone data changes. You will also need to manually
roll the keys by adding and removing DNSKEY records (and interacting with the
parent) at the appropriate times.
.. [#]
The dates can also be modified using an editor, but that is likely to
be more error-prone than using :iscman:`dnssec-settime`.
So... What Now?
^^^^^^^^^^^^^^^
.. [#]
Only one key file - for either a KSK or ZSK - is needed to signal the
presence of the zone. :iscman:`dnssec-keygen` creates files of both
types as needed.
Once the zone is signed, it must be monitored as described in
:ref:`signing_maintenance_tasks`. However, as the time approaches for a key
roll, you must create the new key. Of course, it is possible to create keys
for the next fifty years all at once and set the key times appropriately.
Whether the increased risk in having the private key files for future keys
available on disk offsets the overhead of having to remember to create a new
key before a rollover depends on your organization's security policy.