Add a section about Denial of Existence

Move bits from the "DNSSEC, Dynamic Zones, and Automatic Signing"
about denial of existence to a separate section below the "Key and
Signing Policy" section.

Add a brief introduction about denial of existence to this section.
This commit is contained in:
Matthijs Mekking 2022-05-11 12:09:43 +02:00
parent 34dea43f9c
commit 71490a5a2d

View file

@ -132,6 +132,50 @@ The :ref:`dnssec_advanced_discussions` in the DNSSEC Guide discusses the
various policy settings and may help you determining which values you should
use.
.. _dnssec_denial_of_existence:
Denial of Existence
^^^^^^^^^^^^^^^^^^^
To prove that some data does not exist in the zone, ``NSEC`` records are added
to the zone for each domain name. This record contains a list that tells
which record types are present at that name, so that if a query comes in for
a type that is not in the list, the requestor can proof its non-existence.
The ``NSEC`` record also contains a next owner name, proving that all names
between the owner name and next owner name do not exist.
The ``NSEC`` method allows for trivial zone walking, where one would query
for the apex ``NSEC`` record and then queries the ``NSEC`` of each next owner
name to learn about all names that exist in a certain zone. While this may not
be a problem for most, you can mitigate against this by using ``NSEC3``, hashed
denial of existence (defined in :rfc:`5155`). This uses one-way hashes to
obfuscate the next owner names.
With ``NSEC3`` you can also opt-out insecure delegations from denial of
existence, which may be useful for parent zones with a lot of insecure child
zones.
To enable ``NSEC3``, add an ``nsec3param`` option to your DNSSEC Policy:
::
dnssec-policy "nsec3" {
nsec3param iterations 5 optout yes salt-length 8;
};
..
The ``nsec3`` policy above creates ``NSEC3`` records using the SHA-1 hash
algorithm, using 5 iterations and a salt that is 8 characters long. It also
skips insecure delegations.
The ``NSEC3`` chain is generated and the ``NSEC3PARAM`` record is added before
the existing ``NSEC`` chain (if any) is destroyed.
You can also switch back to ``NSEC`` by removing the ``nsec3param`` option.
In this case, the ``NSEC`` chain is generated before the ``NSEC3`` chain
is removed.
.. _dnssec_tools:
DNSSEC Tools