Re: [dnsext] RETRY and EXPIRE clarification

[Chris Thompson <[e-mail]>]

On Oct 5 2011, Edward Lewis wrote:

>At 10:18 +0200 10/5/11, Lubos Slovak wrote:
[..anip..]
>>1) Should the RETRY interval start when the REFRESH event occurred (this
>>is a bit more deterministic) or when it is clear that the transfer failed,
>>i.e. on timeout or error during transfer (this is maybe closer to the
>>definition of RETRY in RFC 1035, part 3.3.13)?
>
>Doesn't really matter, I mean, how long does it take to fail a 
>transfer?  Let's say it's 90 seconds - if the retry is 43200 (12 
>hours), whether you try 1/2 a day later or 1/2 day plus 90 seconds 
>later isn't going to change things.  It looks cooler in the logs if 
>the retries happen at the stroke of 1/2 day intervals, but it doesn't 
>matter in the long run.

That is in any case the sort of thing that leads to different processes
getting into lock step and generating load spikes. It is better to
dither the intervals a bit, as NIND has done for, lo, these many years:

 432.   [func]          Added refresh/retry jitter.  The actual refresh/
                        retry time is now a random value between 75% and
                        100% of the configured value.

[That was already in BIND 9.1, at least.]

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [e-mail]    New Museums Site, Cambridge CB2 3QH,
Phone: [phone]       United Kingdom.