On 8 Oct 2012, at 11:46, Scott Armitage <[email protected]> wrote: > > Surely you would just do a KSK rollover using the DS record from the new > vendor. Then there is no need to transfer the key. For parents which don't > support multiple KSKs this could be tricky, timing your RRSIG TTLs. > However, for parents which support multiple KSKs there should be no problem.
Yes, but you also have to do a ZSK rollover at the same time. At the point when you change the NS records from the old to the new provider, you have to ensure that all validators will be able to validate signatures from the old and new versions of the zone using the old or new versions of the DNSKEY RRset. They have to be able to do this in both directions because of what might or might not be cached. That means both DNSKEY RRsets have to have both the old and the new ZSK. And both DNSKEY RRsets have to be signed by a key whose hash appears in the DS RRset. So the process is: (1) Import unsigned version of zone to new provider who signs it with new keys. Add DS RR for new KSK. Copy ZSK DNSKEY RRs from old to new and vice versa. (2) Wait for old DS and DNSKEY RRs to expire. Then change NS RRsets from old to new providers. (3) Wait for old NS and old zone RRsets to expire. Then decommission old provider and delete old DS and DNSKEY RRs. In order for a provider to support this process, whether on the winning or the losing side, it needs to allow you to import DNSKEY records with no corresponding private key, and to point NS records at third parties. (Though you might be able to get away without the latter.) Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/
