Problem with Secondary systems with many zones
Barry Margolin
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
> 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 ***
More information about the bind-users
mailing list