On 15 Jun 2010, at 14:49, Hugo Salgado Hernandez wrote: > I have a comment regarding the KSK rollover with the "Double-DS" method, > section 3.3.2. > > The ICANN draft procedure for submitting DS to the root zone require > that: > "At the time of the trust anchor request, there must be a DNSKEY that > matches the DS record present in the child zone. This will be tested > for the presence of a matching DNSKEY record as part of the > implementation of the record. As with most technical > conformance criteria for the root zone, if a top-level domain > operator has a situation where this is not the case, but this is by > design and can be demonstrated not to affect the stability of the TLD > or the root zone, it is possible to request that the trust anchor be > listed regardless." [1] > > > But in the Double-DS timeline the DS is submitted in Event 2, and the > key "could be" introduced in Event 4. > > I think it is safe to publish the key N even before Event 2 (but not > activate it before Trdy). And like the root procedure, it could > be recommended to do this way for any zone whose parent requires a > published-matching-key along with the DS submission.
The scenario of publishing the KSK in the child zone before publishing the DS record in the parent is what the double-signature KSK method describes, and that would better fit the process outlined above. The KSK rollover methods described in the draft are really extremes: * Double-signature method describes the case where there is only ever a single DS record in the parent zone at a given time; but during the rollover there are two KSK DNSKEY records in the child. * Double-DS method describes the converse, where there is only ever a single KSK DNSKEY record in the child zone at any time but during the rollover there are two DS records in the parents. * Double-RRset describes the rollover that takes the least time. But the penalty for this is that during the rollover the parent must have two DS records and the child two KSK DNSKEY records. Although the timings are conservative - the aim is to ensure that during a rollover it is always possible to retrieve a consistent DS/DNSKEY combination - there is room for flexibility. For example, in a double-RRset KSK rollover, there is a separation between the dead time (event 6) - which is when the old DS/DNSKEY records could be removed and the removal time (event 7) - when they actually are. Theoretically this interval could be zero, but in practice an operator may choose to leave the old DS/DNSKEY pair in their respective zones for an extended period because their signing policy demands a certain degree of key overlap. Stephen _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
