1.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") 2.. 3.. SPDX-License-Identifier: MPL-2.0 4.. 5.. This Source Code Form is subject to the terms of the Mozilla Public 6.. License, v. 2.0. If a copy of the MPL was not distributed with this 7.. file, you can obtain one at https://mozilla.org/MPL/2.0/. 8.. 9.. See the COPYRIGHT file distributed with this work for additional 10.. information regarding copyright ownership. 11 12.. _rfc5011.support: 13 14Dynamic Trust Anchor Management 15~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16 17BIND is able to maintain DNSSEC trust anchors using :rfc:`5011` key 18management. This feature allows :iscman:`named` to keep track of changes to 19critical DNSSEC keys without any need for the operator to make changes 20to configuration files. 21 22Validating Resolver 23^^^^^^^^^^^^^^^^^^^ 24 25To configure a validating resolver to use :rfc:`5011` to maintain a trust 26anchor, configure the trust anchor using a :any:`trust-anchors` statement and 27the ``initial-key`` keyword. Information about this can be found in 28the :any:`trust-anchors` statement description. 29 30Authoritative Server 31^^^^^^^^^^^^^^^^^^^^ 32 33To set up an authoritative zone for :rfc:`5011` trust anchor maintenance, 34generate two (or more) key signing keys (KSKs) for the zone. Sign the 35zone with one of them; this is the "active" KSK. All KSKs which do not 36sign the zone are "stand-by" keys. 37 38Any validating resolver which is configured to use the active KSK as an 39:rfc:`5011`-managed trust anchor takes note of the stand-by KSKs in the 40zone's DNSKEY RRset, and stores them for future reference. The resolver 41rechecks the zone periodically; after 30 days, if the new key is 42still there, the key is accepted by the resolver as a valid 43trust anchor for the zone. Anytime after this 30-day acceptance timer 44has completed, the active KSK can be revoked, and the zone can be 45"rolled over" to the newly accepted key. 46 47The easiest way to place a stand-by key in a zone is to use the "smart 48signing" features of :iscman:`dnssec-keygen` and :iscman:`dnssec-signzone`. If a key 49exists with a publication date in the past, but an activation date which is 50unset or in the future, :option:`dnssec-signzone -S` includes the 51DNSKEY record in the zone but does not sign with it: 52 53:: 54 55 $ dnssec-keygen -K keys -f KSK -P now -A now+2y example.net 56 $ dnssec-signzone -S -K keys example.net 57 58To revoke a key, use the command :iscman:`dnssec-revoke`. This 59adds the REVOKED bit to the key flags and regenerates the ``K*.key`` 60and ``K*.private`` files. 61 62After revoking the active key, the zone must be signed with both the 63revoked KSK and the new active KSK. Smart signing takes care of this 64automatically. 65 66Once a key has been revoked and used to sign the DNSKEY RRset in which 67it appears, that key is never again accepted as a valid trust 68anchor by the resolver. However, validation can proceed using the new 69active key, which was accepted by the resolver when it was a 70stand-by key. 71 72See :rfc:`5011` for more details on key rollover scenarios. 73 74When a key has been revoked, its key ID changes, increasing by 128 and 75wrapping around at 65535. So, for example, the key 76"``Kexample.com.+005+10000``" becomes "``Kexample.com.+005+10128``". 77 78If two keys have IDs exactly 128 apart and one is revoked, the two 79key IDs will collide, causing several problems. To prevent this, 80:iscman:`dnssec-keygen` does not generate a new key if another key 81which may collide is present. This checking only occurs if the new keys are 82written to the same directory that holds all other keys in use for that 83zone. 84 85Older versions of BIND 9 did not have this protection. Exercise caution 86if using key revocation on keys that were generated by previous 87releases, or if using keys stored in multiple directories or on multiple 88machines. 89 90It is expected that a future release of BIND 9 will address this problem 91in a different way, by storing revoked keys with their original 92unrevoked key IDs. 93