Secondary refresh tuning

[Kevin Darcy]

Don Stokes wrote:

>I have a server, running BIND 8, that operates as a secondary to about
>2300 zones, at a wide variety of primary addresses and administrators. 
>The server is updated automatically from a provider's database, and
>inevitably a number -- about 400 -- of the primaries out there are not
>reachable or defunct.  Some of them have never been able to transfer
>zones. 
>
>Of course if I could positively identify which ones were genuinely dead
>vs the ones that might come back one day, I wouldn't be writing this..
>
>The problem I had been having with these is that the server always had
>named-xfer processes running, trying to talk to primaries that weren't
>ever going to answer.  These clogged things up enough that legitimate
>zone transfers were taking hours to be performed.
>
>I solved this by writing a wrapper to named-xfer that maintained a
>database of results and timestamps; if an axfr is queried before a
>"hold" period has expired, the last result is just returned and
>named-xfer doesn't run.  The hold period is a sliding arrangement, so
>that the first time a zone is unreachable, it is set to 15 minutes, and
>gets longer the longer the zone can't transfer, up to a maximum
>(currently 6 hours).  That way defunct zones only attempt AXFRs
>occasionally, while functioning zones are transferred within seconds
>rather than hours as before.
>
>I'm looking at upgrading to BIND 9, which of course does not have a
>separate named-xfer.  BIND 9 does have minimum and maximum refresh/retry
>periods, which would help.  But I'm not really sure what the effect of
>hundreds of defunct zones would be on BIND 9.
>
>Would 400 or so defunct primaries stop an active zone being updated
>immediately if a notify for it was received?
>
Well, BIND 9 is good at multi-tasking/multi-threading. Whether 400 
outstanding zone-transfer requests (actually, it's unlikely that they'd 
all be outstanding at the same time) would busy out the server is going 
to be highly dependent on what operating system you use, what the 
machine capacity is, and how you have configured the resource limits.

If NOTIFY-based auto-slaving were to ever become a reality, the simple 
solution to your problem would be to delete the slave zone definitions 
for "dead" zones; as soon as one of these zones is resurrected, you'll 
get a NOTIFY and automatically reconfigure yourself as a slave again.

                                                                        
                                                - Kevin

P.S. Speaking of which... Mark, are you ignoring my autoslaving-related 
messages, or am I just using the wrong email address for you?

>  
>