Also see thread starting at:
http://darkwing.uoregon.edu/~llynch/dnsop/msg03465.html
Ed responded to Olaf:
> >>
> >> # roll: At the rollover stage (SOA serial 2) DNSKEY 11 is used to sign
> >> # the data in the zone exclusively (i.e. all the signatures from
> >> # DNSKEY 10 are removed from the zone). DNSKEY 10 remains published
> >> # in the key set. This way data that was loaded into caches from
> >> # version 1 of the zone can still be verified with key sets fetched
> >> # from version 2 of the zone.
> >> # The minimum time that the key set including DNSKEY 10 is to be
> >> # published is the time that it takes for zone data from the
> >> # previous version of the zone to expire from old caches i.e. the
> >> # time it takes for this zone to propagate to all authoritative
> >> # servers plus the Maximum Zone TTL value of any of the data in the
> >> # previous version of the zone.
> >>
> >> Not the maximum TTL, but the TTL of the key set.
> >
> >
> >You want data that is still cached and signed with signature 10 (as in
> >version SOA1 of the key) to expire before you remove key10 from
> >SOA2. That timing is set by the TTL of the zone data not the DNSKEY.
>
> And also the REFRESH time in the SOA. "Pulling" a record from the
> master won't pull it from a slave that isn't going to come back for
> REFRESH seconds. It's like REFRESH + TTL at least. Even if you use
> NOTIFY - recall that notifies are on UDP, hence not-guaranteed.
>
But that REFRESH allready is incorporated into: "i.e. the time it
takes for this zone to propagate to all authoritative server"
What might be confusing is that in the ascii art we use the SOA as an
indication for what version the zone is at and as an indication of
what signature is used.
> I also thought about this (the advantages of taking a real long time
> to reply, I suppose). DNS allows a server to act as master and
> slave, so it's possible that the first round of slaves wait REFRESH
> seconds to get an updated zone from the master, and then their slaves
> REFRESH seconds after that. "Regional masters" is one label I have
> heard for this practice. In the extreme, it's conceivable that the
> true time for a zone's propagation to all authoritative servers is
> unbounded.
>
> The text here ought to be general by saying that the admin should
> allow for the maximum propagation delay to all authoritative servers
> plus the TTL. Usually the propagation delay is small with NOTIFY,
> may be REFRESH seconds for one layer of master server-slave server,
> may be 2*REFRESH for slave servers that rely on other slave servers
> for zone updates. Further chaining of slave servers increases the
> potential delay, for this and other timing reasons, chaining of
> servers ought to be kept to a minimum.
>
> >> (This could be more
> >> complicated as there would have been a TTL of one week yesterday, then
> >> shortened to an hour today.)
> >
> >Agreed... but I think mentioning this would complicate rather than
> >clarify.
> >
> >You could actually also mention that one could take the 'maximum'
> >SIGNATURE expiration time of the data at the roll to determine when
> >the post-roll should occur. Caches should throw out the data when that
> >expiration time occurred. Since that provides you with an absolute time
> >to do the rollover that may actually be a good recommendation to give
> >too. (also see 4035 section 4.3 "The resolver SHOULD discard the
> >entire atomic entry when any of the RRs contained in it expire").
> >
> >Any opinion from the working group?
>
> I should draw some ascii art of the timeline. I'll do that after
> sending this message and see what happens.
>
Is your suggestion to add a general paragraph about propagation delay
to all authoritative servers? Would that be appropriate as appendix?
I will need text though.
-- Olaf
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
