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

Reply via email to