Correct, applied your fixed text to the work in progress document. Best regards, Matthijs
On 09/18/2012 01:25 PM, Tony Finch wrote: > Section 4.1.2, explanatory text: > > initial: Initial version of the zone. The parental DS points to > DNSKEY_K_1. Before the rollover starts, the child will have to > verify what the TTL is of the DS RR that points to DNSKEY_K_1 -- > it is needed during the rollover and we refer to the value as > TTL_DS. > > new DNSKEY: During the "new DNSKEY" phase, the zone administrator > generates a second KSK, DNSKEY_K_2. The key is provided to the > parent, and the child will have to wait until a new DS RR has been > generated that points to DNSKEY_K_2. After that DS RR has been > published on all servers authoritative for the parent's zone, the > zone administrator has to wait at least TTL_DS to make sure that > the old DS RR has expired from caches. > > DS change: The parent replaces DS_K_1 with DS_K_2. > > This is missing a necessary wait: the old DNSKEY RRset must expire from > caches before the parent to replaces the DS RR. > > Fixed text: > > new DNSKEY: During the "new DNSKEY" phase, the zone administrator > generates a second KSK, DNSKEY_K_2, introduces it into the key > set, and signs the new key set with both the old and new KSKs. > The minimum duration of this phase is the time it takes for > the data to propagate to the authoritative servers, plus TTL value > of the key set. > > DS change: The new key is provided to the parent. The child will > have to wait until the parent replaces DS_K_1 with DS_K_2. After > the new DS RR has been published on all servers authoritative for > the parent's zone, the zone administrator has to wait at least > TTL_DS to make sure that the old DS RR has expired from caches. > > Tony. >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
