Re: BIND 9.2.3, large zone xfer and 100% CPU Utilization

Since the zone transfer under named doesn't seem to work for you, maybe
it is time to consider a different solution. This ***is*** a big zone.

You could periodically download this zone using dig. Have this zone
configured on your server as a master and simply reload it. Named
would not have to perform the zone transfer itself so you shouldn't
have this same downtime problem.

From a strong suggestion made about periodically downloading the root
cache file, I would strongly suggest that you download this zone file
to a separate file. You need to insure that you don't clobber the file
for the running zone while you are downloading the newer zone file.

Bill Larson

On Apr 22, 2004, at 7:55 PM, Mike Diggins wrote:

>
> On Wed, 21 Apr 2004, Alex Rainchik wrote:
>
>> Hello,
>>
>> We are using BIND 9.2.3 on Solaris8, transfering ~45Mb zone from
>> mail-abuse.com
>> every three hours, as they don't support IXFR feature. The issue we
>> have is that
>> at the end of the transfer "named" goes berserk and CPU utlilization
>> goes trough
>> the roof, up to 100% for about 5-10 minutes.
>>
>> During those 5-10 minutes "named" does not respond to any queries,
>> "rdnc status"
>> does not work either. It's the only zone xfer running at that time....
>>
>> Just wondering if it's a bug or a feature?
>
> Alex, I'm also running Bind 9.2.3 on Solaris 8 (Ultra 10) and
> downloading
> the mail abuse zone with exactly the same result. I am also seeking a
> solution! I was going to post this question anyway so I might as well
> ask
> in this same thread.
>
> If I were to compile BIND on a another dual processor system and enable
> multi-threading (I read BIND supports that but I don't really know how
> to
> enable it) can I count on BIND to updates zones (even the BIG mail
> abuse
> zone) AND answer queries at the same time? I can't tolerate the several
> minutes of down time while this zone reloads and management doesn't
> want
> to revert to querying the mail abuse DNS servers directly.
>
> -Mike
>
>