Problem with Secondary systems with many zones

[Barry Margolin]

In article <coopvu$1c9q$1 at sf1.isc.org>, list3 at wwwcrazy.com wrote:

> Quoting phn at icke-reklam.ipsec.nu:
> 
> > You don't seem to run bind-9.3, you should upgrade.
> 
> You are correct, these are bind.9.2.4  but I don't believe 9.3 will fix this
> (have tried 9.3 already).
> It does not appear that this was ever listed as a bug even so I'm shocked 
> that
> no one else has found this problem.
> 
> The thing that I do not care about 9.3 is that the host program does multiple
> lookups when you try to do a simple A record query.
> It breaks all of our scripts.
> 
> >
> > bind-9 has a statement "transfers-per-ns" which according to the "ARM-book" 
> > :
> > transfers-per-ns
> >
> We are already doing that.  We have:
>         transfers-per-ns 100;
> 
> 
> The problem is not really with the transfers.  It is that Bind seems to not 
> make
> the SOA queries if the zone file already exist (when there are thousands of
> zones).  And it seems like it just gets congested and doesn't get anything
> accomplished (dynamic updates, SOA queries, etc).

I remember seeing a similar problem with an 8.3 server when I worked at 
Genuity, maybe 9.x has a similar problem.

We had one customer with lots of zones (they owned a class B network and 
had a separate reverse zone for each /24 block), and they had their 
Refresh times set to 24 hours.  I had a script that scanned our slave 
zone files, looking for ones whose modification times were older than 
their refresh times.  Any time we restarted our slave server, a bunch of 
these zones (as well as other zones with long refresh times) always 
showed up in the report a few hours later.  It appears that the refresh 
timer restarted for all zones at named startup time, rather than using 
the files' timestamps as the basis.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***