mirror of
https://github.com/isc-projects/bind9.git
synced 2026-04-15 22:09:31 -04:00
Update NSEC3 guidance to match draft-ietf-dnsop-nsec3-guidance-10
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance-10 is on it's way to become RFC, so let's update our recommendations in the docs to be in line with it.
This commit is contained in:
Petr Špaček
parent
529a7c0c1a
commit
2ee3f4e6c8
12 changed files with 236 additions and 199 deletions
|
|
@ -43,7 +43,7 @@ Options
|
|||
This option uses an NSEC3-capable algorithm to generate a DNSSEC key. If this
|
||||
option is used with an algorithm that has both NSEC and NSEC3
|
||||
versions, then the NSEC3 version is selected; for example,
|
||||
``dnssec-keygen -3a RSASHA1`` specifies the NSEC3RSASHA1 algorithm.
|
||||
``dnssec-keygen -3 -a RSASHA1`` specifies the NSEC3RSASHA1 algorithm.
|
||||
|
||||
.. option:: -a algorithm
|
||||
|
||||
|
|
|
|||
|
|
@ -362,16 +362,25 @@ Options
|
|||
(-) can be used to indicate that no salt is to be used when
|
||||
generating the NSEC3 chain.
|
||||
|
||||
.. note::
|
||||
``-3 -`` is the recommended configuration. Adding salt provides no practical benefits.
|
||||
|
||||
.. option:: -H iterations
|
||||
|
||||
This option indicates that, when generating an NSEC3 chain, BIND 9 should use this many iterations. The default
|
||||
is 0.
|
||||
|
||||
.. warning::
|
||||
Values greater than 0 cause interoperability issues and also increase the risk of CPU-exhausting DoS attacks.
|
||||
|
||||
.. option:: -A
|
||||
|
||||
This option indicates that, when generating an NSEC3 chain, BIND 9 should set the OPTOUT flag on all NSEC3
|
||||
records and should not generate NSEC3 records for insecure delegations.
|
||||
|
||||
.. warning::
|
||||
Do not use this option unless all its implications are fully understood. This option is intended only for extremely large zones (comparable to ``com.``) with sparse secure delegations.
|
||||
|
||||
.. option:: -AA
|
||||
|
||||
This option turns the OPTOUT flag off for
|
||||
|
|
|
|||
|
|
@ -523,15 +523,17 @@ Currently supported commands are:
|
|||
depending on whether the opt-out bit in the NSEC3
|
||||
chain should be set. ``iterations`` defines the number of additional times to apply
|
||||
the algorithm when generating an NSEC3 hash. The ``salt`` is a string
|
||||
of data expressed in hexadecimal, a hyphen (`-') if no salt is to be
|
||||
of data expressed in hexadecimal, a hyphen (``-``) if no salt is to be
|
||||
used, or the keyword ``auto``, which causes :iscman:`named` to generate a
|
||||
random 64-bit salt.
|
||||
|
||||
So, for example, to create an NSEC3 chain using the SHA-1 hash
|
||||
algorithm, no opt-out flag, 10 iterations, and a salt value of
|
||||
"FFFF", use: ``rndc signing -nsec3param 1 0 10 FFFF zone``. To set
|
||||
the opt-out flag, 15 iterations, and no salt, use:
|
||||
``rndc signing -nsec3param 1 1 15 - zone``.
|
||||
The only recommended configuration is ``rndc signing -nsec3param 1 0 0 - zone``,
|
||||
i.e. no salt, no additional iterations, no opt-out.
|
||||
|
||||
.. warning::
|
||||
Do not use extra iterations, salt, or opt-out unless all their implications
|
||||
are fully understood. A higher number of iterations causes interoperability
|
||||
problems and opens servers to CPU-exhausting DoS attacks.
|
||||
|
||||
``rndc signing -nsec3param none`` removes an existing NSEC3 chain and
|
||||
replaces it with NSEC.
|
||||
|
|
|
|||
|
|
@ -284,8 +284,9 @@ not completely signed until :iscman:`named` has had time to "walk" the zone
|
|||
and generate the NSEC and RRSIG records. The NSEC record at the apex
|
||||
is added last, to signal that there is a complete NSEC chain.
|
||||
|
||||
To sign using NSEC3 instead of NSEC, add an
|
||||
NSEC3PARAM record to the initial update request. The OPTOUT bit in the NSEC3
|
||||
To sign using :ref:`NSEC3 <advanced_discussions_nsec3>` instead of :ref:`NSEC
|
||||
<advanced_discussions_nsec>`, add an NSEC3PARAM record to the initial update
|
||||
request. The :term:`OPTOUT <opt-out>` bit in the NSEC3
|
||||
chain can be set in the flags field of the
|
||||
NSEC3PARAM record.
|
||||
|
||||
|
|
|
|||
|
|
@ -5385,11 +5385,17 @@ The following options can be specified in a ``dnssec-policy`` statement:
|
|||
|
||||
nsec3param iterations 0 optout no salt-length 0;
|
||||
|
||||
The default is to use NSEC. The ``iterations``, ``optout`` and
|
||||
The default is to use :ref:`NSEC`. The ``iterations``, ``optout``, and
|
||||
``salt-length`` parts are optional, but if not set, the values in
|
||||
the example above are the default NSEC3 parameters. Note that you don't
|
||||
specify a specific salt string, :iscman:`named` will create a salt for you
|
||||
of the provided salt length.
|
||||
the example above are the default :ref:`NSEC3` parameters. Note that the
|
||||
specific salt string is not specified by the user; :iscman:`named` creates a salt
|
||||
of the indicated length.
|
||||
|
||||
.. warning::
|
||||
Do not use extra :term:`iterations`, :term:`salt`, and
|
||||
:term:`opt-out` unless their implications are fully understood.
|
||||
A higher number of iterations causes interoperability problems and opens
|
||||
servers to CPU-exhausting DoS attacks.
|
||||
|
||||
``zone-propagation-delay``
|
||||
This is the expected propagation delay from the time when a zone is
|
||||
|
|
|
|||
|
|
@ -101,6 +101,7 @@ To solve this problem, two different solutions were created. We will
|
|||
look at the first one, NSEC, next.
|
||||
|
||||
.. _advanced_discussions_nsec:
|
||||
.. _NSEC:
|
||||
|
||||
NSEC
|
||||
^^^^
|
||||
|
|
@ -124,7 +125,7 @@ So we end up with four NSEC records:
|
|||
|
||||
::
|
||||
|
||||
example.com. 300 IN NSEC alice.example.com. A RRSIG NSEC
|
||||
example.com. 300 IN NSEC alice.example.com. A RRSIG NSEC
|
||||
alice.example.com. 300 IN NSEC edward.example.com. A RRSIG NSEC
|
||||
edward.example.com. 300 IN NSEC susan.example.com. A RRSIG NSEC
|
||||
susan.example.com. 300 IN NSEC example.com. A RRSIG NSEC
|
||||
|
|
@ -168,13 +169,15 @@ phone book: if you don't want a name to be known publicly, don't put it
|
|||
in DNS! Consider using DNS views (split DNS) and only display your
|
||||
sensitive names to a select audience.
|
||||
|
||||
The second drawback of NSEC is actually increased operational
|
||||
overhead: there is no opt-out mechanism for insecure child zones. This generally
|
||||
is a problem for parent-zone operators dealing with a lot of insecure
|
||||
child zones, such as ``.com``. To learn more about opt-out, please see
|
||||
:ref:`advanced_discussions_nsec3_optout`.
|
||||
The second potential drawback of NSEC is a bigger zone file and memory consumption;
|
||||
there is no opt-out mechanism for insecure child zones, so each name
|
||||
in the zone will get an additional NSEC record and a RRSIG record to go with
|
||||
it. In practice this is a problem only for parent-zone operators dealing with
|
||||
mostly insecure child zones, such as ``com.``. To learn more about opt-out,
|
||||
please see :ref:`advanced_discussions_nsec3_optout`.
|
||||
|
||||
.. _advanced_discussions_nsec3:
|
||||
.. _nsec3:
|
||||
|
||||
NSEC3
|
||||
^^^^^
|
||||
|
|
@ -204,7 +207,7 @@ back into the ribeye steak: that's what we call a one-way hash.
|
|||
|
||||
NSEC3 basically runs the names through a one-way hash before giving them
|
||||
out, so the recipients can verify the non-existence without any
|
||||
knowledge of the actual names.
|
||||
knowledge of the other names in the zone.
|
||||
|
||||
So let's tell our little story for the third time, this
|
||||
time with NSEC3. In this version, our intern is not given a list of actual
|
||||
|
|
@ -228,99 +231,129 @@ ease of display):
|
|||
|
||||
::
|
||||
|
||||
FSK5....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF JKMA... A RRSIG
|
||||
JKMA....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF NTQ0... A RRSIG
|
||||
NTQ0....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF FSK5... A RRSIG
|
||||
FSK5....example.com. 300 IN NSEC3 1 0 0 - JKMA... A RRSIG
|
||||
JKMA....example.com. 300 IN NSEC3 1 0 0 - NTQ0... A RRSIG
|
||||
NTQ0....example.com. 300 IN NSEC3 1 0 0 - FSK5... A RRSIG
|
||||
|
||||
.. note::
|
||||
|
||||
Just because we employed one-way hash functions does not mean there is
|
||||
no way for a determined individual to figure out our zone data.
|
||||
Someone could still gather all of our NSEC3 records and hashed
|
||||
names and perform an offline brute-force attack by trying all
|
||||
possible combinations to figure out what the original name is. In our
|
||||
meat-grinder analogy, this would be like someone
|
||||
buying all available cuts of meat and grinding them up at home using
|
||||
the same model of meat grinder, and comparing the output with the meat
|
||||
you gave him. It is expensive and time-consuming (especially with
|
||||
real meat), but like everything else in cryptography, if someone has
|
||||
enough resources and time, nothing is truly private forever. If you
|
||||
are concerned about someone performing this type of attack on your
|
||||
zone data, read more about adding salt as described in
|
||||
:ref:`advanced_discussions_nsec3_salt`.
|
||||
|
||||
Most names published in the DNS are rarely secret or unpredictable. They are
|
||||
published to be memorable, used and consumed by humans. They are often recorded
|
||||
in many other network logs such as email logs, certificate transparency logs,
|
||||
web page links, intrusion detection systems, malware scanners, email archives,
|
||||
etc. Many times a simple dictionary of commonly used domain-name prefixes
|
||||
(www, mail, imap, login, database, etc.) can be used to quickly reveal a large
|
||||
number of labels within a zone. Additionally, if an adversary really wants to
|
||||
expend significant CPU resources to mount an offline dictionary attack on a
|
||||
zone's NSEC3 chain, they will likely be able to find most of the "guessable"
|
||||
names despite any level of hashing.
|
||||
|
||||
Also, it is still possible to gather all of our NSEC3 records and hashed
|
||||
names and perform an offline brute-force attack by trying all
|
||||
possible combinations to figure out what the original name is. In our
|
||||
meat-grinder analogy, this would be like someone
|
||||
buying all available cuts of meat and grinding them up at home using
|
||||
the same model of meat grinder, and comparing the output with the meat
|
||||
you gave him. It is expensive and time-consuming (especially with
|
||||
real meat), but like everything else in cryptography, if someone has
|
||||
enough resources and time, nothing is truly private forever. If you
|
||||
are concerned about someone performing this type of attack on your
|
||||
zone data, use some of the special techniques described in :rfc:`4470`.
|
||||
|
||||
.. _advanced_discussions_nsec3param:
|
||||
|
||||
NSEC3PARAM
|
||||
++++++++++
|
||||
|
||||
The above NSEC3 examples used four parameters: 1, 0, 10, and
|
||||
1234567890ABCDEF. 1 represents the algorithm, 0 represents the opt-out
|
||||
flag, 10 represents the number of iterations, and 1234567890ABCDEF is the
|
||||
.. warning::
|
||||
Before we dive into the details of NSEC3 parametrization, please note:
|
||||
the defaults should not be changed without a strong justification and a full
|
||||
understanding of the potential impact.
|
||||
|
||||
The above NSEC3 examples used four parameters: 1, 0, 0, and
|
||||
zero-length salt. 1 represents the algorithm, 0 represents the opt-out
|
||||
flag, 0 represents the number of additional iterations, and - is the
|
||||
salt. Let's look at how each one can be configured:
|
||||
|
||||
- *Algorithm*: The only currently defined value is 1 for SHA-1, so there
|
||||
is no configuration field for it.
|
||||
.. glossary::
|
||||
|
||||
- *Opt-out*: Set this to 1 for NSEC3 opt-out, which we
|
||||
discuss in :ref:`advanced_discussions_nsec3_optout`.
|
||||
Algorithm
|
||||
NSEC3 Hashing Algorithm
|
||||
The only currently defined value is 1 for SHA-1, so there
|
||||
is no configuration field for it.
|
||||
|
||||
- *Iterations*: Iterations defines the number of additional times to
|
||||
apply the algorithm when generating an NSEC3 hash. More iterations
|
||||
yield more secure results, but consume more resources for both
|
||||
authoritative servers and validating resolvers. The considerations
|
||||
here are similar to those seen in :ref:`key_sizes`, of
|
||||
security versus resources.
|
||||
Opt-out
|
||||
Setting this bit to 1 enables NSEC3 opt-out, which is
|
||||
discussed in :ref:`advanced_discussions_nsec3_optout`.
|
||||
|
||||
- *Salt*: The salt cannot be configured explicitly, but you can provide
|
||||
a salt length and :iscman:`named` generates a random salt of the given length.
|
||||
We learn more about salt in :ref:`advanced_discussions_nsec3_salt`.
|
||||
Iterations
|
||||
Iterations defines the number of _additional_ times to
|
||||
apply the algorithm when generating an NSEC3 hash. More iterations
|
||||
consume more resources for both authoritative servers and validating
|
||||
resolvers. The considerations here are similar to those seen in
|
||||
:ref:`key_sizes`, of security versus resources.
|
||||
|
||||
If you want to use these NSEC3 parameters for a zone, you can add the
|
||||
following configuration to your ``dnssec-policy``. For example, to create an
|
||||
NSEC3 chain using the SHA-1 hash algorithm, with no opt-out flag,
|
||||
5 iterations, and a salt that is 8 characters long, use:
|
||||
.. warning::
|
||||
Do not use values higher than zero. A value of zero provides one round
|
||||
of SHA-1 hashing and protects from non-determined attackers.
|
||||
|
||||
::
|
||||
A greater number of additional iterations causes interoperability problems
|
||||
and opens servers to CPU-exhausting DoS attacks, while providing
|
||||
only doubtful security benefits.
|
||||
|
||||
dnssec-policy "nsec3" {
|
||||
...
|
||||
nsec3param iterations 5 optout no salt-length 8;
|
||||
};
|
||||
|
||||
To set the opt-out flag, 15 iterations, and no salt, use:
|
||||
|
||||
::
|
||||
|
||||
dnssec-policy "nsec3" {
|
||||
...
|
||||
nsec3param iterations 15 optout yes salt-length 0;
|
||||
};
|
||||
Salt
|
||||
A salt value, which can be combined with an FQDN to influence the
|
||||
resulting hash. Salt is discussed in more detail in
|
||||
:ref:`advanced_discussions_nsec3_salt`.
|
||||
|
||||
.. _advanced_discussions_nsec3_optout:
|
||||
|
||||
NSEC3 Opt-Out
|
||||
+++++++++++++
|
||||
|
||||
One of the advantages of NSEC3 over NSEC is the ability for a parent zone
|
||||
to publish less information about its child or delegated zones. Why
|
||||
would you ever want to do that? If a significant number of your
|
||||
delegations are not yet DNSSEC-aware, meaning they are still insecure or
|
||||
unsigned, generating DNSSEC-records for their NS and glue records is not
|
||||
a good use of your precious name server resources.
|
||||
First things first: For most DNS administrators who do not manage a huge number
|
||||
of insecure delegations, the NSEC3 opt-out featuere is not relevant.
|
||||
|
||||
Opt-out allows for blocks of unsigned delegations to be covered by a single NSEC3
|
||||
record. In other words, use of the opt-out allows large registries to only sign as
|
||||
many NSEC3 records as there are signed DS or other RRsets in the zone; with
|
||||
opt-out, unsigned delegations do not require additional NSEC3 records. This
|
||||
sacrifices the tamper-resistance proof of non-existence offered by NSEC3 in
|
||||
order to reduce memory and CPU overheads, and decreases the effectiveness of the cache
|
||||
(:rfc:`8198`).
|
||||
|
||||
Why would that ever be desirable? If a significant number of delegations
|
||||
are not yet securely delegated, meaning they lack DS records and are still
|
||||
insecure or unsigned, generating DNSSEC records for all their NS records
|
||||
might consume lots of memory and is not strictly required by the child zones.
|
||||
|
||||
This resource-saving typically makes a difference only for *huge* zones like ``com.``.
|
||||
Imagine that you are the operator of busy top-level domains such as ``com.``,
|
||||
with millions of insecure delegated domain names.
|
||||
As of mid-2022, around 3% of all ``com.`` zones are signed. Basically,
|
||||
without opt-out, with 1,000,000 delegations, only 30,000 of which are secure, you
|
||||
still have to generate NSEC RRsets for the other 970,000 delegations; with
|
||||
NSEC3 opt-out, you will have saved yourself 970,000 sets of records.
|
||||
|
||||
In contrast, for a small zone the difference is operationally negligible
|
||||
and the drawbacks outweigh the benefits.
|
||||
|
||||
If NSEC3 opt-out is truly essential for a zone, the following
|
||||
configuration can be added to ``dnssec-policy``; for example, to create an
|
||||
NSEC3 chain using the SHA-1 hash algorithm, with the opt-out flag,
|
||||
no additional iterations, and no extra salt, use:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
dnssec-policy "nsec3" {
|
||||
...
|
||||
nsec3param iterations 0 optout yes salt-length 0;
|
||||
};
|
||||
|
||||
The resources may not seem like a lot, but imagine that you are the
|
||||
operator of busy top-level domains such as ``.com`` or ``.net``, with
|
||||
millions of insecure delegated domain names: it quickly
|
||||
adds up. As of mid-2020, less than 1.5% of all ``.com`` zones are
|
||||
signed. Basically, without opt-out, with 1,000,000 delegations,
|
||||
only 5 of which are secure, you still have to generate NSEC RRsets for
|
||||
the other 999,995 delegations; with NSEC3 opt-out, you will have saved
|
||||
yourself 999,995 sets of records.
|
||||
|
||||
For most DNS administrators who do not manage a large number of
|
||||
delegations, the decision whether to use NSEC3 opt-out is
|
||||
probably not relevant.
|
||||
|
||||
To learn more about how to configure NSEC3 opt-out, please see
|
||||
:ref:`recipes_nsec3_optout`.
|
||||
|
|
@ -330,50 +363,35 @@ To learn more about how to configure NSEC3 opt-out, please see
|
|||
NSEC3 Salt
|
||||
++++++++++
|
||||
|
||||
As described in :ref:`advanced_discussions_nsec3`, while NSEC3
|
||||
does not put your zone data in plain public display, it is still not
|
||||
difficult for an attacker to collect all the hashed names and perform
|
||||
an offline attack. All that is required is running through all the
|
||||
combinations to construct a database of plaintext names to hashed names,
|
||||
also known as a "rainbow table."
|
||||
.. warning::
|
||||
Contrary to popular belief, adding salt provides little value.
|
||||
Each DNS zone is always uniquely salted using the zone name. **Operators should
|
||||
use a zero-length salt value.**
|
||||
|
||||
There is one more feature NSEC3 gives us to provide additional
|
||||
protection: salt. Basically, salt gives us the ability to introduce further
|
||||
randomness into the hashed results. Whenever the salt is changed, any
|
||||
pre-computed rainbow table is rendered useless, and a new rainbow table
|
||||
must be re-computed. If the salt is changed periodically, it
|
||||
becomes difficult to construct a useful rainbow table, and thus difficult to
|
||||
walk the DNS zone data programmatically. How often you want to change
|
||||
your NSEC3 salt is up to you.
|
||||
|
||||
To learn more about the steps to take to change NSEC3, please see
|
||||
:ref:`recipes_nsec3_salt`.
|
||||
The properties of this extra salt are complicated and beyond scope of this
|
||||
document. For detailed description why the salt in the context of DNSSEC
|
||||
provides little value please see `IETF draft ietf-dnsop-nsec3-guidance version
|
||||
10 section 2.4
|
||||
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance-10#section-2.4>`__.
|
||||
|
||||
.. _advanced_discussions_nsec_or_nsec3:
|
||||
|
||||
NSEC or NSEC3?
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
So which one should you choose: NSEC or NSEC3? There is not a
|
||||
single right answer here that fits everyone; it comes down to your
|
||||
network's needs or requirements.
|
||||
So which is better: NSEC or NSEC3? There is no single right
|
||||
answer here that fits everyone; it comes down to a given network's needs or
|
||||
requirements.
|
||||
|
||||
If you prefer not to make your zone easily enumerable, implementing
|
||||
NSEC3 paired with a periodically changed salt provides a certain
|
||||
level of privacy protection. However, someone could still randomly guess
|
||||
the names in your zone (such as "ftp" or "www"), as in the traditional
|
||||
insecure DNS.
|
||||
In most cases, NSEC is a good choice for zone administrators. It
|
||||
relieves the authoritative servers and resolver of the additional cryptographic
|
||||
operations that NSEC3 requires, and NSEC is comparatively easier to
|
||||
troubleshoot than NSEC3.
|
||||
|
||||
If you have many delegations and need to be able to opt-out to save
|
||||
resources, NSEC3 is for you.
|
||||
|
||||
In other situations, NSEC is typically a good choice for most zone
|
||||
administrators, as it relieves the authoritative servers of the
|
||||
additional cryptographic operations that NSEC3 requires, and NSEC is
|
||||
comparatively easier to troubleshoot than NSEC3.
|
||||
|
||||
NSEC3 in conjunction with ``dnssec-policy`` is supported in BIND
|
||||
as of version 9.16.9.
|
||||
NSEC3 comes with many drawbacks and should be implemented only if zone
|
||||
enumeration prevention is really needed, or when opt-out provides a
|
||||
significant reduction in memory and CPU overheads (in other words, with a
|
||||
huge zone with mostly insecure delegations).
|
||||
|
||||
.. _advanced_discussions_key_generation:
|
||||
|
||||
|
|
@ -1049,7 +1067,7 @@ Below are a few challenges and disadvantages that DNSSEC faces.
|
|||
actually signed. What this means is, even if your company's zone is
|
||||
signed today, fewer than 30% of the Internet's servers are taking
|
||||
advantage of this extra security. It gets worse: with less than 1.5%
|
||||
of the ``.com`` domains signed, even if your DNSSEC validation is enabled today,
|
||||
of the ``com.`` domains signed, even if your DNSSEC validation is enabled today,
|
||||
it's not likely to buy you or your users a whole lot more protection
|
||||
until these popular domain names decide to sign their zones.
|
||||
|
||||
|
|
|
|||
|
|
@ -795,13 +795,12 @@ according to the steps described in
|
|||
|
||||
To enable NSEC3, update your ``dnssec-policy`` and add the desired NSEC3
|
||||
parameters. The example below enables NSEC3 for zones with the ``standard``
|
||||
DNSSEC policy, using 10 iterations, no opt-out, and a random string that is
|
||||
16 characters long:
|
||||
DNSSEC policy, using 0 additional iterations, no opt-out, and a zero-length salt:
|
||||
|
||||
::
|
||||
|
||||
dnssec-policy "standard" {
|
||||
nsec3param iterations 10 optout no salt-length 16;
|
||||
nsec3param iterations 0 optout no salt-length 0;
|
||||
};
|
||||
|
||||
Then reconfigure the server with :iscman:`rndc`. You can tell that it worked if you
|
||||
|
|
@ -810,7 +809,7 @@ see the following debug log messages:
|
|||
::
|
||||
|
||||
Oct 21 13:47:21 received control channel command 'reconfig'
|
||||
Oct 21 13:47:21 zone example.com/IN (signed): zone_addnsec3chain(1,CREATE,10,1234567890ABCDEF)
|
||||
Oct 21 13:47:21 zone example.com/IN (signed): zone_addnsec3chain(1,CREATE,0,-)
|
||||
|
||||
You can also verify that it worked by querying for a name that you know
|
||||
does not exist, and checking for the presence of the NSEC3 record.
|
||||
|
|
@ -821,15 +820,15 @@ For example:
|
|||
$ dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline
|
||||
|
||||
...
|
||||
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF (
|
||||
5A03TL362CS8VSIH69CVA4MJIKRHFQH3.example.com. 300 IN NSEC3 1 0 0 - (
|
||||
TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
|
||||
NS SOA RRSIG DNSKEY NSEC3PARAM )
|
||||
...
|
||||
|
||||
Our example used four parameters: 1, 0, 10, and 1234567890ABCDEF, in
|
||||
Our example used four parameters: 1, 0, 0, and -, in
|
||||
order. 1 represents the algorithm, 0 represents the
|
||||
opt-out flag, 10 represents the number of iterations, and
|
||||
1234567890ABCDEF is the salt. To learn more about each of these
|
||||
opt-out flag, 0 represents the number of additional iterations, and
|
||||
- denotes no salt is used. To learn more about each of these
|
||||
parameters, please see :ref:`advanced_discussions_nsec3param`.
|
||||
|
||||
.. _recipes_nsec3_to_nsec:
|
||||
|
|
@ -844,7 +843,7 @@ server. You can tell that it worked if you see these messages in the log:
|
|||
::
|
||||
|
||||
named[14093]: received control channel command 'reconfig'
|
||||
named[14093]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)
|
||||
named[14093]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,0,-)
|
||||
|
||||
You can also query for a name that you know does not exist,
|
||||
and you should no longer see any traces of NSEC3 records.
|
||||
|
|
@ -859,45 +858,6 @@ and you should no longer see any traces of NSEC3 records.
|
|||
ns1.example.com. 300 IN NSEC web.example.com. A RRSIG NSEC
|
||||
...
|
||||
|
||||
.. _recipes_nsec3_salt:
|
||||
|
||||
Changing the NSEC3 Salt
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In :ref:`advanced_discussions_nsec3_salt`, we discuss the
|
||||
reasons why you may want to change your salt periodically for better
|
||||
privacy. In this recipe, we look at what command to execute to
|
||||
actually change the salt, and how to verify that it has been changed.
|
||||
|
||||
The ``dnssec-policy`` currently has no easy way to re-salt using the
|
||||
same salt length, so to change your NSEC3 salt you need to change the
|
||||
``salt-length`` value and reconfigure your server. You should see
|
||||
the following messages in the log, assuming your old salt was
|
||||
"1234567890ABCDEF" and :iscman:`named` created "FEDCBA09" (salt length 8)
|
||||
as the new salt:
|
||||
|
||||
::
|
||||
|
||||
named[15848]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)
|
||||
named[15848]: zone example.com/IN: zone_addnsec3chain(1,CREATE|OPTOUT,10,FEDCBA0987654321)
|
||||
|
||||
To verify that it worked, you can query the name server (192.168.1.13 in our
|
||||
example) for a name that you know does not exist, and check the NSEC3 record
|
||||
returned:
|
||||
|
||||
::
|
||||
|
||||
$ dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline
|
||||
|
||||
...
|
||||
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN NSEC3 1 0 10 FEDCBA09 (
|
||||
TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
|
||||
NS SOA RRSIG DNSKEY NSEC3PARAM )
|
||||
...
|
||||
|
||||
If you want to use the same salt length, you can repeat the above steps and
|
||||
go back to your original length value.
|
||||
|
||||
.. _recipes_nsec3_optout:
|
||||
|
||||
NSEC3 Opt-Out
|
||||
|
|
@ -909,6 +869,15 @@ the results of each action. As discussed in
|
|||
that can help conserve resources on parent zones with many
|
||||
delegations that have not yet been signed.
|
||||
|
||||
.. warning::
|
||||
NSEC3 Opt-Out feature brings benefit only to _extremely_ large zones with lots
|
||||
of insecure delegations. It's use is counterproductive in all other cases as
|
||||
it decreases tamper-resistance of the zone and also decreases efficiency of
|
||||
resolver cache (see :rfc:`8198`).
|
||||
|
||||
In other words, don't enable Opt-Out unless you are serving an equivalent of
|
||||
``com.`` zone.
|
||||
|
||||
Because the NSEC3PARAM record does not keep track of whether opt-out is used,
|
||||
it is hard to check whether changes need to be made to the NSEC3 chain if the flag
|
||||
is changed. Similar to changing the NSEC3 salt, your best option is to change
|
||||
|
|
@ -944,25 +913,25 @@ Before enabling NSEC3 opt-out, the zone ``example.com`` contains ten
|
|||
NSEC3 records; below is the list with the plain text name before the actual
|
||||
NSEC3 record:
|
||||
|
||||
- *aaa.example.com*: 9NE0VJGTRTMJOS171EC3EDL6I6GT4P1Q.example.com.
|
||||
- *aaa.example.com*: IFA1I3IE7EKCTPHM6R58URO3Q846I52M.example.com
|
||||
|
||||
- *bbb.example.com*: AESO0NT3N44OOSDQS3PSL0HACHUE1O0U.example.com.
|
||||
- *bbb.example.com*: ROJUF3VJSJO6LQ2LC1DNSJ5GBAUJPVHE.example.com
|
||||
|
||||
- *ccc.example.com*: SF3J3VR29LDDO3ONT1PM6HAPHV372F37.example.com.
|
||||
- *ccc.example.com*: 0VPUT696LUVDPDS5NIHSHBH9KLV20V5K.example.com
|
||||
|
||||
- *ddd.example.com*: TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER.example.com.
|
||||
- *ddd.example.com*: UHPBD5U4HRGB84MLC2NQOVEFNAKJU0CA.example.com
|
||||
|
||||
- *eee.example.com*: L16L08NEH48IFQIEIPS1HNRMQ523MJ8G.example.com.
|
||||
- *eee.example.com*: NF7I61FA4C2UEKPMEDSOC25FE0UJIMKT.example.com
|
||||
|
||||
- *ftp.example.com*: JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
|
||||
- *ftp.example.com*: 8P15KCUAT1RHCSDN46HBQVPI5T532IN1.example.com
|
||||
|
||||
- *ns1.example.com*: FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
|
||||
- *ns1.example.com*: GUFVRA2SFIO8RSFP7UO41E8AD1KR41FH.example.com
|
||||
|
||||
- *web.example.com*: D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
|
||||
- *web.example.com*: CVQ4LA4ALPQIAO2H3N2RB6IR8UHM91E7.example.com
|
||||
|
||||
- *www.example.com*: NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
|
||||
- *www.example.com*: MIFDNDT3NFF3OD53O7TLA1HRFF95JKUK.example.com
|
||||
|
||||
- *example.com*: TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.
|
||||
- *example.com*: ONIB9MGUB9H0RML3CDF5BGRJ59DKJHVK.example.com
|
||||
|
||||
We can enable NSEC3 opt-out with the following configuration, changing
|
||||
the ``optout`` configuration value from ``no`` to ``yes``:
|
||||
|
|
@ -970,31 +939,31 @@ the ``optout`` configuration value from ``no`` to ``yes``:
|
|||
::
|
||||
|
||||
dnssec-policy "standard" {
|
||||
nsec3param iterations 10 optout yes salt-length 16;
|
||||
nsec3param iterations 0 optout yes salt-length 0;
|
||||
};
|
||||
|
||||
After NSEC3 opt-out is enabled, the number of NSEC3 records is reduced.
|
||||
Notice that the unsigned delegations ``aaa``, ``ccc``, ``ddd``, and
|
||||
``eee`` no longer have corresponding NSEC3 records.
|
||||
|
||||
- *bbb.example.com*: AESO0NT3N44OOSDQS3PSL0HACHUE1O0U.example.com.
|
||||
- *bbb.example.com*: ROJUF3VJSJO6LQ2LC1DNSJ5GBAUJPVHE.example.com
|
||||
|
||||
- *ftp.example.com*: JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
|
||||
- *ftp.example.com*: 8P15KCUAT1RHCSDN46HBQVPI5T532IN1.example.com
|
||||
|
||||
- *ns1.example.com*: FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
|
||||
- *ns1.example.com*: GUFVRA2SFIO8RSFP7UO41E8AD1KR41FH.example.com
|
||||
|
||||
- *web.example.com*: D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
|
||||
- *web.example.com*: CVQ4LA4ALPQIAO2H3N2RB6IR8UHM91E7.example.com
|
||||
|
||||
- *www.example.com*: NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
|
||||
- *www.example.com*: MIFDNDT3NFF3OD53O7TLA1HRFF95JKUK.example.com
|
||||
|
||||
- *example.com*: TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.
|
||||
- *example.com*: ONIB9MGUB9H0RML3CDF5BGRJ59DKJHVK.example.com
|
||||
|
||||
To undo NSEC3 opt-out, change the configuration again:
|
||||
|
||||
::
|
||||
|
||||
dnssec-policy "standard" {
|
||||
nsec3param iterations 10 optout no salt-length 16;
|
||||
nsec3param iterations 0 optout no salt-length 0;
|
||||
};
|
||||
|
||||
.. note::
|
||||
|
|
@ -1006,8 +975,8 @@ To undo NSEC3 opt-out, change the configuration again:
|
|||
|
||||
::
|
||||
|
||||
# nsec3hash 1234567890ABCDEF 1 10 www.example.com.
|
||||
NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ (salt=1234567890ABCDEF, hash=1, iterations=10)
|
||||
# nsec3hash - 1 0 www.example.com.
|
||||
MIFDNDT3NFF3OD53O7TLA1HRFF95JKUK (salt=-, hash=1, iterations=0)
|
||||
|
||||
.. _revert_to_unsigned:
|
||||
|
||||
|
|
|
|||
|
|
@ -583,5 +583,7 @@ would execute a command like this:
|
|||
$ nsec3hash 1234567890ABCEDF 1 10 www.example.com
|
||||
RN7I9ME6E1I6BDKIP91B9TCE4FHJ7LKF (salt=1234567890ABCEDF, hash=1, iterations=10)
|
||||
|
||||
Zero-length salt can be specified as ``-``.
|
||||
|
||||
While it is unlikely you would construct a rainbow table of your own
|
||||
zone data, this tool may be useful when troubleshooting NSEC3 problems.
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ generated.
|
|||
This option uses an NSEC3\-capable algorithm to generate a DNSSEC key. If this
|
||||
option is used with an algorithm that has both NSEC and NSEC3
|
||||
versions, then the NSEC3 version is selected; for example,
|
||||
\fBdnssec\-keygen \-3a RSASHA1\fP specifies the NSEC3RSASHA1 algorithm.
|
||||
\fBdnssec\-keygen \-3 \-a RSASHA1\fP specifies the NSEC3RSASHA1 algorithm.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
|
|
|||
|
|
@ -408,18 +408,39 @@ KSK\-flagged keys to sign all records, not just the DNSKEY RRset.
|
|||
This option generates an NSEC3 chain with the given hex\-encoded salt. A dash
|
||||
(\-) can be used to indicate that no salt is to be used when
|
||||
generating the NSEC3 chain.
|
||||
.sp
|
||||
\fBNOTE:\fP
|
||||
.INDENT 7.0
|
||||
.INDENT 3.5
|
||||
\fB\-3 \-\fP is the recommended configuration. Adding salt provides no practical benefits.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-H iterations
|
||||
This option indicates that, when generating an NSEC3 chain, BIND 9 should use this many iterations. The default
|
||||
is 0.
|
||||
.sp
|
||||
\fBWARNING:\fP
|
||||
.INDENT 7.0
|
||||
.INDENT 3.5
|
||||
Values greater than 0 cause interoperability issues and also increase the risk of CPU\-exhausting DoS attacks.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-A
|
||||
This option indicates that, when generating an NSEC3 chain, BIND 9 should set the OPTOUT flag on all NSEC3
|
||||
records and should not generate NSEC3 records for insecure delegations.
|
||||
.sp
|
||||
\fBWARNING:\fP
|
||||
.INDENT 7.0
|
||||
.INDENT 3.5
|
||||
Do not use this option unless all its implications are fully understood. This option is intended only for extremely large zones (comparable to \fBcom.\fP) with sparse secure delegations.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
|
|
|||
|
|
@ -567,15 +567,21 @@ representing SHA\-1. The \fBflags\fP may be set to \fB0\fP or \fB1\fP,
|
|||
depending on whether the opt\-out bit in the NSEC3
|
||||
chain should be set. \fBiterations\fP defines the number of additional times to apply
|
||||
the algorithm when generating an NSEC3 hash. The \fBsalt\fP is a string
|
||||
of data expressed in hexadecimal, a hyphen (\fI\-\(aq) if no salt is to be
|
||||
used, or the keyword \(ga\(gaauto\(ga\fP, which causes \fI\%named\fP to generate a
|
||||
of data expressed in hexadecimal, a hyphen (\fB\-\fP) if no salt is to be
|
||||
used, or the keyword \fBauto\fP, which causes \fI\%named\fP to generate a
|
||||
random 64\-bit salt.
|
||||
.sp
|
||||
So, for example, to create an NSEC3 chain using the SHA\-1 hash
|
||||
algorithm, no opt\-out flag, 10 iterations, and a salt value of
|
||||
"FFFF", use: \fBrndc signing \-nsec3param 1 0 10 FFFF zone\fP\&. To set
|
||||
the opt\-out flag, 15 iterations, and no salt, use:
|
||||
\fBrndc signing \-nsec3param 1 1 15 \- zone\fP\&.
|
||||
The only recommended configuration is \fBrndc signing \-nsec3param 1 0 0 \- zone\fP,
|
||||
i.e. no salt, no additional iterations, no opt\-out.
|
||||
.sp
|
||||
\fBWARNING:\fP
|
||||
.INDENT 7.0
|
||||
.INDENT 3.5
|
||||
Do not use extra iterations, salt, or opt\-out unless all their implications
|
||||
are fully understood. A higher number of iterations causes interoperability
|
||||
problems and opens servers to CPU\-exhausting DoS attacks.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.sp
|
||||
\fBrndc signing \-nsec3param none\fP removes an existing NSEC3 chain and
|
||||
replaces it with NSEC.
|
||||
|
|
|
|||
|
|
@ -35,9 +35,12 @@ Removed Features
|
|||
Feature Changes
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
- :option:The `dnssec-signzone -H` default value has been changed to 0 additional
|
||||
- The :option:`dnssec-signzone -H` default value has been changed to 0 additional
|
||||
NSEC3 iterations. This change aligns the :iscman:`dnssec-signzone` default with
|
||||
the default used by the :ref:`dnssec-policy <dnssec_policy_grammar>` feature.
|
||||
At the same time, documentation about NSEC3 has been aligned with
|
||||
`Best Current Practice
|
||||
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance-10>`__.
|
||||
:gl:`#3395`
|
||||
|
||||
Bug Fixes
|
||||
|
|
|
|||
Loading…
Reference in a new issue