Problem with Secondary systems with many zones
barmar at alum.mit.edu
Sat Dec 4 01:16:31 UTC 2004
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
> 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
> 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
*** PLEASE post questions in newsgroups, not directly to me ***
More information about the bind-users