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

Reply via email to