On 24.3.2015 20:08, Bob Harold wrote: > > On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák wrote: > > On 23.3.2015 18:26, Bob Harold wrote: > > I think we might need to allow for more than one NSEC5 key and chain, > > during a transition. Otherwise it might be impossible to later create a > > reasonable transition process. This might require us to tag the NSEC5 > > records with an id, so that the chains and matching keys can be > > distinguished. Better to do this now than to try to retrofit later. > > Please, can you clarify which transition process do you mean? > > Transitioning from one NSEC5 key to another. I think the process would > need to be: > - add new NSEC5 key RR, but not used yet. Also add new private to all > authoritative servers. > - wait for new key to reach everywhere (propagation + ttl) > - change all NSEC5 records in the zone. > - wait for new records to reach everywhere
I don't think we need to wait till updated NSEC5 records get everywhere. Also with NSEC3, the two servers can answer from different NSEC3 chains as far as the chains are signed correctly. The server must switch to a new private key at the moment, when it gets an updated NSEC5 chains and drops the old one. Right, that's one of the things which should be clarified. > - remove old NSEC5 key record. Also remove old private key from all > authoritative servers. > But for the servers and public to know which key to use, there will need > to be some id that matches NSEC5 records to the matching NSEC5 key. > That requires changing the format of the NSEC5 records, so it cannot be > done later. You should never get a zone with NSEC5 records mixed from two different chains. The change of the NSEC5 chain must be atomic. That is required by the draft. What is missing in the draft is, how to determine a correct NSEC5 private key to use to compute the NSEC5 proofs. What comes to my mind is that when the zone is loaded (or the chain is updated), the server could just compute the NSEC5 hash of the zone apex and determine, which key is in use. That could work even without the id. But this is definitely a good point. I will think about it. Thank you. Jan _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
