Zones not getting transferred after a restart
rtom at cv.net
Thu Jun 2 08:05:38 UTC 2011
Consider the option "transfers-in".
Look at the output of:
If you notice that the "soa queries in progress" number is high in
proportion to the number of slave zones maintained by the server, you
should increase the transfers-in number (the default is 10 as I
recall). That means that your server is limiting itself to only 10
simultaneous zone retrievals from the masters of the zones. I didn't
get the response I liked in my particular case until I tweaked the
number to about 70% of the "soa queries in progress" number.
As with tweaking any parameter on a heavily used system, you might want
to look at the typical system vital statistics after tweaking the value
and looking at how any of those things (cpu, mem, disk i/o, network i/o,
general load, etc) may now be trending differently after a day/week.
On 3/15/2011 6:29 PM, Mark Andrews wrote:
> In message<ilo4hp$s5g$1 at dough.gmane.org>, Bernhard Schmidt writes:
>> we have an internal distribution point running BIND 9.5.0-P2 (SLES 11.1
>> distribution package). It slaves about 1800 zones from a commercial DNS
>> management software running on 127.0.0.1:8054 and distributes them
>> towards our servers.
>> Whenever we restart BIND on that system, the 1800 zones are loaded
>> within two seconds (1800 loaded serial xxxxx entries, running), but it
>> takes up to 30 minutes (26 minutes the last time) where it does not do
>> any AXFR upstream and logs
>> 15-Mar-2011 09:36:47.334 zone kongress.xxx.de/IN: notify from
>> 127.0.0.1#8054: refresh in progress, refresh check queued
>> on every notify it receives. I cannot really see SOA queries upstream
>> either. When that time has passed by it catches up with the zone
>> Other than having "edns no" and "request-ixfr no" set for the upstream
>> server (due to bugs in this field) the configuration is pretty standard.
>> I'm not really opposed to updating the BIND to a newer version, but
>> given I'd have to go away from the distribution package where I feel
>> fine using it (firewalled system, only reachable by our other servers)
>> I'd rather know for sure that this problem is solved. I see similar
>> issues on our frontend servers running 9.7.3.
>> Can anyone explain how I can speedup this progress?
> Disable notify for the zones. Increase soa-query-rate. It also applies
> to notifies.
>> Also I'd like to disable/tune down the
>> 15-Mar-2011 08:25:36.828 zone xxx.in-addr.arpa/IN: refresh:
>> skipping zone transfer as master 127.0.0.1#8054 (source 0.0.0
>> .0#0) is unreachable (cached)
>> thing. Good idea, but stopping all zone transfers for 10 minutes from
>> the only master just because it was unreachable for a few seconds is a
>> bad idea.
> Adjust lame-ttl.
>> I have searched for a named.conf knob and have failed to find any.
>> Closest I have found is serial-query-rate, which is not set in our
>> environment and should default to 20.
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.
More information about the bind-users