I propose the following addition to the Bv9ARM, and request review and comment
by the experts on this list.
----------
4.9.14 DNSKEY Algorithm Rollover
>From time to time new digital signature algorithms with improved security are
>introduced, and it may be desirable for administrators to roll over DNSKEYs to
>a new algorithm, e.g. from RSASHA1 (algorithm 5 or 7) to RSASHA256 (algorithm
>8). The algorithm rollover must be done with care in a stepwise fashion to
>avoid breaking DNSSEC validation.
As with other DNSKEY rollovers (sections 4.9.5 - 4.9.7), when the zone is of
type master, an algorithm rollover can be accomplished using dynamic updates or
automatic key rollovers. For zones of type slave, only automatic key rollovers
are possible, but the dnssec-settime utility can be used to control the timing
of such.
In any case the first step is to put DNSKEYs using the new algorithm in place.
You must generate the K* files for the new algorithm and put them in the zone's
key directory where named can access them. Take care to set appropriate
ownership and permissions on the keys. If the auto-dnssec zone option is set to
maintain, named will automatically sign the zone with the new keys based on
their timing metadata when the dnssec-loadkeys-interval elapses or you issue
the command rndc loadkeys zone. Otherwise for zones of type master, you can use
nsupdate to add the new DNSKEYs to the zone. This will cause named to use them
to sign the zone. For zones of type slave, e.g. on a bump-in-the-wire inline
signing server, nsupdate cannot be used.
Once the zone has been signed by the new DNSKEYs, you must inform the parent
zone and any trust anchor repositories of the new KSKs, e.g. you might place DS
records in the parent zone through your DNS registrar's website.
Before starting to remove the old algorithm from a zone, you must allow the
maximum TTL on its DS records in the parent zone to expire. This will assure
that any subsequent queries will retrieve the new DS records for the new
algorithm. After the TTL has expired, you can remove the DS records for the old
algorithm from the parent zone and any trust anchor repositories. You must then
allow another maximum TTL interval to elapse so that the old DS records
disappear from all resolver caches.
The next step is to remove the DNSKEYs using the old algorithm from your zone.
Again this can be accomplished using nsupdate to delete the old DNSKEYs (master
zones only) or by automatic key rollover when auto-dnssec is set to maintain.
You can cause the automatic key rollover to take place immediately by using the
dnssec-settime utility to adjust the timing metadata on all key files
associated with the old algorithm. There are five cases:
1) For keys with a deletion date in the past, do nothing.
2) For keys currently published but deactivated, set the deletion date to
sometime in the past.
3) For keys currently published and active, set the inactive and deletion dates
to sometime in the past.
4) For keys currently published but not yet active, set the inactive and
deletion dates to sometime in the past.
5) For keys with a publish date in the future, do nothing.
After adjusting the timing metadata, the command rndc loadkeys zone will cause
named to remove the DNSKEYs and RRSIGs for the old algorithm from the zone.
Note also that with the nsupdate method, removing the DNSKEYs also causes named
to remove the associated RRSIGs automatically.
Once you have verified that the old DNSKEYs and RRSIGs have been removed from
the zone, the final step (optional) is to remove the key files for the old
algorithm from the key directory.
----------
Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
