[bind10-dev] zonemgr / notify out questions

[Jerry Scharf]

Jeremy,

Re: 19

jitter is a server operation detail rather than a protocol issue.

It is there to ease the following problem: someone updates a whole bunch 
of zones that each have a bunch of slaves. Without jitter, every refresh 
cycle from then on, at the refresh expire time all of the slaves will 
ask the master for an XFR of every zone at exactly the same time. You 
get a huge spike in the load on the master processing all the transfer 
requests.

With jitter, this gets spread out and the master doesn't fall over. It's 
one of those operational details that was hard earned learning. So it 
belongs there at some point and is necessary to call it production 
level, but a server can ship without it and still be useful. Almost any 
implementation that meets the general goal is fine. I would guess that 
25% range spread (refresh/4) was chosen at a dart board one day. :)

hope that helps,
jerry S


On 09/13/2010 11:10 AM, Jeremy C. Reed wrote:
> On Sun, 12 Sep 2010, Jerry wrote:
>
>    
>>>>> 17)  zonemgr expired a zone where the serial was not increased. This
>>>>>            
>> may
>>      
>>>>> be same problem as above #15.
>>>>>
>>>>> [b10-zonemgr] Zone (foo., IN) is expired.
>>>>>            
>>>>
>>>>   I can't understand this question, when zone expires, will its serial be
>>>> changed?
>>>>          
>>      
>>> Serial not changed. The question is: why does it output that the zone is
>>> expired?  Why does it think it is expired?
>>>        
>> When zone refresh timer finds a zone's master servers can't be reached for
>> "expire" time
>> (now - last_refresh_time>=  expire time), the zone will become expired.
>> But if zonemgr receives notify-in messages for a expired zone, it will still
>> try to connect
>> to the zone's master servers and do refresh again.
>>      
> It seems broken to me.
>
> See trunk/src/bin/zonemgr/zonemgr.py.in _zone_is_expired
>
> Is the test backwards?
>
>           if (ZONE_EXPIRED == self._get_zone_state(zone_name_class) or
>              zone_last_refresh_time + zone_expired_time<= self._get_current_time
>
>              return True
>
> If the previous time plus the SOA expire is less than current time, then
> it should return False.
>
> And is that misnamed? "last_refresh" as expired is not based on a single
> last refresh only.
>
> Also for some zones I get repeated "expired" logging  for the same zone
> -- even when no notify is sent to it to restart this counter.
>
> And it does a AXFR-in even if the SOA serial doesn't increase. For
> example, my zone has a SOA refresh of 10. Approximately every ten
> seconds, it will do a new AXFR transfer. This keeps repeating even
> though the master's serial for that zone never changes. This stops doing
> the zone transfers once it reaches the SOA expired (and says zone "is
> expired.") -- but that doesn't match up either since it is around 104
> seconds where my expire is 45 seconds.
>
>
> 19) Is random Refresh jitter defined in any specification? I see it uses
> between (zone_refresh_time - ((1 * zone_refresh_time) / 4)) and
> zone_refresh_time.
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev
>