Consider the option "transfers-in".
Look at the output of:
rndc status
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.
Richard
On 3/15/2011 6:29 PM, Mark Andrews wrote:
In message<ilo4hp$s5g$1...@dough.gmane.org>, Bernhard Schmidt writes:
Hi,
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
transfers.
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.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
