On 24.3.2015 21:04, Bob Harold wrote: > > 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. > > That's simpler, and removes the need for the id. > (That's why you are designing this and not me.) Then the process becomes: > - add new private key to all authoritative servers. > - change NSEC5 key and all NSEC5 records in the master zone > - wait for zone to reach all slaves > - each time the NSEC5 key record changes, the servers test to see which > private key it uses. > - remove old private key from all authoritative servers.
I agree. I will update the draft to clarify the replacement of the private key during the rollover process. Thank you, Bob. Jan _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
