diff --git a/doc/arm/dnssec.inc.rst b/doc/arm/dnssec.inc.rst index eb61a24f7b..b0f7dee3e8 100644 --- a/doc/arm/dnssec.inc.rst +++ b/doc/arm/dnssec.inc.rst @@ -156,8 +156,51 @@ Also: For more information about KASP configuration see :ref:`dnssec_policy_grammar`. -The :ref:`dnssec_advanced_discussions` in the DNSSEC Guide discusses the -various policy settings and may help you determining values for your special needs. +The :ref:`dnssec_advanced_discussions` section in the DNSSEC Guide discusses the +various policy settings and may be useful for determining values for specific +needs. + +Key Rollover +============ + +When using a ``dnssec-policy``, a key lifetime can be set to trigger +key rollovers. ZSK rollovers are fully automatic, but for KSK and CSK rollovers +a DS record needs to be submitted to the parent. See +:ref:`secure_delegation` for possible ways to do so. + +Once the DS is in the parent (and the DS of the predecessor key is withdrawn), +BIND needs to be told that this event has happened. This can be done automatically +by configuring parental agents: + +.. code-block:: none + :emphasize-lines: 5 + + zone "dnssec.example" { + type primary; + file "dnssec.example.db"; + dnssec-policy default; + parental-agents { 192.0.2.1; }; + }; + +Here one server, ``192.0.2.1``, is configured for BIND to send DS queries to, +to check the DS RRset for ``dnssec-example`` during key rollovers. This needs +to be a trusted server, because BIND does not validate the response. + +If setting up a parental agent is undesirable, it is also possible to tell BIND that the +DS is published in the parent with: +:option:`rndc dnssec -checkds -key 12345 published dnssec.example. `. +and the DS for the predecessor key has been removed with: +:option:`rndc dnssec -checkds -key 54321 withdrawn dnssec.example. `. +where 12345 and 54321 are the key tags of the successor and predecessor key, +respectively. + +To roll a key sooner than scheduled, or to roll a key that +has an unlimited lifetime, use: +:option:`rndc dnssec -rollover -key 12345 dnssec.example. `. + +To revert a signed zone back to an insecure zone, change +the zone configuration to use the built-in "insecure" policy. Detailed +instructions are described in :ref:`revert_to_unsigned`. .. _dnssec_dynamic_zones: diff --git a/doc/dnssec-guide/recipes.rst b/doc/dnssec-guide/recipes.rst index 8b30598035..ac66ca9497 100644 --- a/doc/dnssec-guide/recipes.rst +++ b/doc/dnssec-guide/recipes.rst @@ -986,12 +986,40 @@ Reverting to Unsigned This recipe describes how to revert from a signed zone (DNSSEC) back to an unsigned (DNS) zone. -Whether the world thinks your zone is signed is determined by the -presence of DS records hosted by your parent zone; if there are no DS records, -the world sees your zone as unsigned. So reverting to unsigned is as -easy as removing all DS records from the parent zone. +Here is what :iscman:`named.conf` looks like when it is signed: -Below is an example showing how to remove DS records using the +.. code-block:: none + :emphasize-lines: 4 + + zone "example.com" IN { + type primary; + file "db/example.com.db"; + dnssec-policy "default"; + }; + +To indicate the reversion to unsigned, change the ``dnssec-policy`` line: + +.. code-block:: none + :emphasize-lines: 4 + + zone "example.com" IN { + type primary; + file "db/example.com.db"; + dnssec-policy "insecure"; + }; + +Then use :option:`rndc reload` to reload the zone. + +The "insecure" policy is a built-in policy (like "default"). It makes sure +the zone is still DNSSEC-maintained, to allow for a graceful transition to +unsigned. It also publishes the CDS and CDNSKEY DELETE records automatically +at the appropriate time. + +If the parent zone allows management of DS records via CDS/CDNSKEY, as described in +:rfc:`8078`, the DS record should be removed from the parent automatically. + +Otherwise, DS records can be removed via the registrar. Below is an example +showing how to remove DS records using the `GoDaddy `__ web-based interface: 1. After logging in, click the green "Launch" button next to the domain @@ -1036,58 +1064,17 @@ Below is an example showing how to remove DS records using the Revert to Unsigned Step #4 -If your parent allows managing DS record via CDS/CDNSKEY, as described in -:rfc:`5155`, you could add CDS/CDNSKEY DELETE records in your zone to signal -that the corresponding DS records from the parent zone needs to be removed. -If it is unclear which format the parent zone is expecting, you should publish -both CDS and CDNSKEY DELETE records. - -To be on the safe side, wait a while before actually deleting -all signed data from your zone, just in case some validating resolvers -have cached information. After you are certain that all cached -information has expired (usually this means one TTL interval has passed), -you may reconfigure your zone. - -Here is what :iscman:`named.conf` looks like when it is signed: - -:: - - zone "example.com" IN { - type primary; - file "db/example.com.db"; - allow-transfer { any; }; - dnssec-policy "default"; - }; - -Change your ``dnssec-policy`` line to indicate you want to revert to unsigned: - -:: - - zone "example.com" IN { - type primary; - file "db/example.com.db"; - allow-transfer { any; }; - dnssec-policy "insecure"; - }; - -Then use :option:`rndc reload` to reload the zone. - -The "insecure" policy is a built-in policy (like "default"). It will make sure -the zone is still DNSSEC maintained, to allow for a graceful transition to -unsigned. It also publishes the CDS and CDNSKEY DELETE records for you when -the time is right. - When the DS records have been removed from the parent zone, use :option:`rndc dnssec -checkds -key id withdrawn example.com ` to tell :iscman:`named` that the DS is removed, and the remaining DNSSEC records will be removed in a timely -manner. Or if you have parental agents configured, the DNSSEC records will be +manner. Or, if parental agents are configured, the DNSSEC records will be automatically removed after BIND has seen that the parental agents no longer -serves the DS RRset for this zone. +serve the DS RRset for this zone. -After a while, your zone is reverted back to the traditional, insecure DNS -format. You can verify by checking that all DNSKEY and RRSIG records have been +After a while, the zone is reverted back to the traditional, insecure DNS +format. This can be verified by checking that all DNSKEY and RRSIG records have been removed from the zone. -You can then remove the ``dnssec-policy`` line from your :iscman:`named.conf` and -reload the zone. The zone will now no longer be subject to any DNSSEC +The ``dnssec-policy`` line can then be removed from :iscman:`named.conf` and +the zone reloaded. The zone will no longer be subject to any DNSSEC maintenance.