mirror of
https://github.com/isc-projects/bind9.git
synced 2026-05-28 04:34:54 -04:00
Rewrite DNSSEC Validation subchapter in the ARM
Mostly deduplicating and linking information across the ARM.
Generally people should not touch it unless they what they are doing, so
let's try to discourage them a bit.
(cherry picked from commit bffa3063f0)
This commit is contained in:
Petr Špaček
Matthijs Mekking
parent
c6a82e0ff1
commit
1d07cf4883
2 changed files with 45 additions and 94 deletions
|
|
@ -470,113 +470,62 @@ a given case zone. Generally the options are, from most- to least-recommended:
|
|||
DNSSEC Validation
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
To enable :iscman:`named` to validate answers received from other servers, the
|
||||
``dnssec-validation`` option must be set to either ``yes`` or ``auto``.
|
||||
The BIND resolver validates answers from authoritative servers by default. This
|
||||
behavior is controlled by the configuration statement :ref:`dnssec-validation
|
||||
<dnssec-validation-option>`.
|
||||
|
||||
When ``dnssec-validation`` is set to ``auto``, a trust anchor for the
|
||||
DNS root zone is automatically used. This trust anchor is provided
|
||||
as part of BIND and is kept up to date using :rfc:`5011` key management.
|
||||
By default a trust anchor for the DNS root zone is used.
|
||||
This trust anchor is provided as part of BIND and is kept up-to-date using
|
||||
:ref:`rfc5011.support`.
|
||||
|
||||
When ``dnssec-validation`` is set to ``yes``, DNSSEC validation
|
||||
only occurs if at least one trust anchor has been explicitly configured
|
||||
in :iscman:`named.conf`, using a ``trust-anchors`` statement (or the
|
||||
``managed-keys`` and ``trusted-keys`` statements, both deprecated).
|
||||
.. note::
|
||||
DNSSEC validation works "out of the box" and does not require
|
||||
additional configuration. Additional configuration options are intended only
|
||||
for special cases.
|
||||
|
||||
When ``dnssec-validation`` is set to ``no``, DNSSEC validation does not
|
||||
occur.
|
||||
To validate answers, the resolver needs at least one trusted starting point,
|
||||
a "trust anchor." Essentially, trust anchors are copies of ``DNSKEY`` RRs for
|
||||
zones that are used to form the first link in the cryptographic chain of trust.
|
||||
Alternative trust anchors can be specified using :ref:`trust_anchors`, but
|
||||
this setup is very unusual and is recommended only for expert use.
|
||||
For more information, see :ref:`trust_anchors_description` in the
|
||||
:doc:`dnssec-guide`.
|
||||
|
||||
The default is ``auto`` unless BIND is built with
|
||||
``configure --disable-auto-validation``, in which case the default is
|
||||
``yes``.
|
||||
|
||||
The keys specified in ``trust-anchors`` are copies of ``DNSKEY`` RRs for zones
|
||||
that are used to form the first link in the cryptographic chain of trust. Keys
|
||||
configured with the keyword ``static-key`` or ``static-ds`` are loaded directly
|
||||
into the table of trust anchors, and can only be changed by altering the
|
||||
configuration. Keys configured with ``initial-key`` or ``initial-ds`` are used
|
||||
to initialize :rfc:`5011` trust anchor maintenance, and are kept up-to-date
|
||||
automatically after the first time :iscman:`named` runs.
|
||||
|
||||
``trust-anchors`` is described in more detail later in this document.
|
||||
|
||||
BIND 9 does not verify signatures on load, so zone keys
|
||||
The BIND authoritative server does not verify signatures on load, so zone keys
|
||||
for authoritative zones do not need to be specified in the configuration
|
||||
file.
|
||||
|
||||
After DNSSEC is established, a typical DNSSEC configuration looks
|
||||
something like the following. It has one or more public keys for the
|
||||
root, which allows answers from outside the organization to be validated.
|
||||
It also has several keys for parts of the namespace that the
|
||||
organization controls. These are here to ensure that :iscman:`named` is immune
|
||||
to compromised security in the DNSSEC components of parent zones.
|
||||
Validation Failures
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
::
|
||||
|
||||
trust-anchors {
|
||||
/* Root Key */
|
||||
"." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
|
||||
JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
|
||||
aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
|
||||
4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
|
||||
hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
|
||||
5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
|
||||
g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
|
||||
66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
|
||||
97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
|
||||
dgxbcDTClU0CRBdiieyLMNzXG3";
|
||||
/* Key for our organization's forward zone */
|
||||
example.com. static-ds 54135 5 2 "8EF922C97F1D07B23134440F19682E7519ADDAE180E20B1B1EC52E7F58B2831D"
|
||||
|
||||
/* Key for our reverse zone. */
|
||||
2.0.192.IN-ADDRPA.NET. static-key 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc
|
||||
xOdNax071L18QqZnQQQAVVr+i
|
||||
LhGTnNGp3HoWQLUIzKrJVZ3zg
|
||||
gy3WwNT6kZo6c0tszYqbtvchm
|
||||
gQC8CzKojM/W16i6MG/eafGU3
|
||||
siaOdS0yOI6BgPsw+YZdzlYMa
|
||||
IJGf4M4dyoKIhzdZyQ2bYQrjy
|
||||
Q4LB0lC7aOnsMyYKHHYeRvPxj
|
||||
IQXmdqgOJGq+vsevG06zW+1xg
|
||||
YJh9rCIfnm1GX/KMgxLPG2vXT
|
||||
D/RnLX+D3T3UL7HJYHJhAZD5L
|
||||
59VvjSPsZJHeDCUyWYrvPZesZ
|
||||
DIRvhDD52SKvbheeTJUm6Ehkz
|
||||
ytNN2SN96QRk8j/iI8ib";
|
||||
};
|
||||
|
||||
options {
|
||||
...
|
||||
dnssec-validation yes;
|
||||
};
|
||||
|
||||
..
|
||||
|
||||
.. note::
|
||||
|
||||
None of the keys listed in this example are valid. In particular, the
|
||||
root key is not valid.
|
||||
|
||||
When DNSSEC validation is enabled and properly configured, the resolver
|
||||
rejects any answers from signed, secure zones which fail to
|
||||
validate, and returns SERVFAIL to the client.
|
||||
When DNSSEC validation is configured, the resolver rejects any answers from
|
||||
signed, secure zones which fail to validate, and returns SERVFAIL to the
|
||||
client.
|
||||
|
||||
Responses may fail to validate for any of several reasons, including
|
||||
missing, expired, or invalid signatures; a key which does not match the
|
||||
DS RRset in the parent zone; or an insecure response from a zone which,
|
||||
according to its parent, should have been secure.
|
||||
|
||||
.. note::
|
||||
For more information see :ref:`dnssec_troubleshooting`.
|
||||
|
||||
When the validator receives a response from an unsigned zone that has
|
||||
a signed parent, it must confirm with the parent that the zone was
|
||||
intentionally left unsigned. It does this by verifying, via signed
|
||||
and validated NSEC/NSEC3 records, that the parent zone contains no DS
|
||||
records for the child.
|
||||
Coexistence With Unsigned (Insecure) Zones
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If the validator *can* prove that the zone is insecure, then the
|
||||
response is accepted. However, if it cannot, the validator must assume an
|
||||
insecure response to be a forgery; it rejects the response and logs
|
||||
an error.
|
||||
Zones not protected by DNSSEC are called "insecure," and these zones seamlessly
|
||||
coexist with signed zones.
|
||||
|
||||
The logged error reads "insecurity proof failed" and "got insecure
|
||||
response; parent indicates it should be secure."
|
||||
When the validator receives a response from an unsigned zone that has
|
||||
a signed parent, it must confirm with the parent that the zone was
|
||||
intentionally left unsigned. It does this by verifying, via signed
|
||||
and validated :ref:`NSEC/NSEC3 records
|
||||
<advanced_discussions_proof_of_nonexistence>`, that the parent zone contains no
|
||||
DS records for the child.
|
||||
|
||||
If the validator *can* prove that the zone is insecure, then the
|
||||
response is accepted. However, if it cannot, the validator must assume an
|
||||
insecure response to be a forgery; it rejects the response and logs
|
||||
an error.
|
||||
|
||||
The logged error reads "insecurity proof failed" and "got insecure
|
||||
response; parent indicates it should be secure."
|
||||
|
|
|
|||
|
|
@ -2114,7 +2114,9 @@ Boolean Options
|
|||
This option enables DNSSEC validation in :iscman:`named`.
|
||||
|
||||
If set to ``auto``, DNSSEC validation is enabled and a default trust
|
||||
anchor for the DNS root zone is used.
|
||||
anchor for the DNS root zone is used. This trust anchor is provided
|
||||
as part of BIND and is kept up-to-date using :ref:`rfc5011.support` key
|
||||
management.
|
||||
|
||||
If set to ``yes``, DNSSEC validation is enabled, but a trust anchor must be
|
||||
manually configured using a ``trust-anchors`` statement (or the
|
||||
|
|
|
|||
Loading…
Reference in a new issue