On Friday, December 08, 2017 06:27:07 AM Michael StJohns wrote: > To try this out, let’s use a ttl of 28 hours and an expiration of 7 days to > get an active refresh as below.
Mike, I very much appreciate the analysis of the text and the proposed method that you've done. I am picking this message as my entry point to this thread even though my comments are also applicable to Message-ID: <6d239b9a-fd1e-46a3- c705-6851dd8ff...@nthpermutation.com>. > Take an activeRefresh of 14 hours (giving a fast retry of 2.8 hours and an > addHoldDown time of 30 days (720 hour). That gives you an > activeRefreshOffset of 6 hours. A perfect resolver will make 51 queries > in 714 hours and the last triggering query at 728 hours. > > Assume a 4% failure rate (to make the math easy) in queries and assume the > first retry always works. Which adds approx two fast retry intervals to the > time making the total time to do 51 queries 719.8 hour for an actual offset > of .2 hours. The next and last query needed to take place to trigger the > trust anchor installation will take place at 733.8 hours. > > The point is that retransmission drift makes the whole concept of > activeRefreshOffset nonsensical in any population of resolvers with any > losses at all. Authors, I suggest and request that you both model and simulate the proposed method, along the lines Mike has done in this thread but with more than one set of parameters and conditions, in order that the second-set-of-eyes can be readily provided by more than one reviewer. This timing based approach to online DNSSEC signing key changes is subtle beyond anybody's expectations, and because it will be used by the root zone, it is vital that we do more than simply whiteboard our proposed methods. -- P. Vixie -- P. Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
