diff --git a/doc/arm/dnssec.inc.rst b/doc/arm/dnssec.inc.rst index e2ca6ed0dd..397c9d0ab7 100644 --- a/doc/arm/dnssec.inc.rst +++ b/doc/arm/dnssec.inc.rst @@ -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 +`. -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 +`, 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." diff --git a/doc/arm/reference.rst b/doc/arm/reference.rst index fc31137c4e..68710a1bff 100644 --- a/doc/arm/reference.rst +++ b/doc/arm/reference.rst @@ -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