Problem with Secondary systems with many zones

Barry Margolin barmar at
Sat Dec 4 01:16:31 UTC 2004

In article <coopvu$1c9q$1 at>, list3 at wrote:

> Quoting phn at
> > 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
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

More information about the bind-users mailing list