On Tue, Mar 24, 2015 at 3:27 PM, Jan Včelák <jan.vce...@nic.cz> wrote:
> 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. > > 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. > 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
