Preference of Master Name Servers

Cathy Almond cathya at
Fri Dec 7 13:34:18 UTC 2012

On 06/12/12 14:12, Matus UHLAR - fantomas wrote:
> On 05.12.12 17:28, David Hall wrote:
>> Question 1:
>> In our secondary / slave name servers we specify the master name
>> servers in
>> the normal manner:
>> zone { type slave; file "m/y/"; masters {
>>;;; }; };
>> What I have found is that the order of the master name servers does not
>> matter and one is used at random. That name server is tried for all
>> AXFR /
>> IXFR attempts until it is unreachable.
>> Is there a way to set a dedicated preference of which name servers to use
>> first?
> No. all masters are treated equally. Do you know a reason why they should
> not? However, if slave received notify from a master, it prefers fetching
> from that master, afaik.
>> Question 2:
>> I am also seeing many entries in our logs that look like:
>> Dec 4 10:28:49 mysys named[28103]: zone refresh: retry
>> limit for master exceeded (source
>> Does this mean that the master name server is unreachable? I have
>> confirmed
>> that it is reachable by UDP and TCP.
>> Or does it mean that we are hitting one of our limits? Our current values
>> are:
>> serial-query-rate 500;
>> transfers-out 300;
>> transfers-in 300;
>> transfers-per-ns 100;
> I would try increasing limits, starting with transfer-in.
> you can check in logs or via netstat (or packet dump), how many transfers
> were executed in parallel (to know which parameter to increase)
>> Question 3:
>> We have over 100,000 domains on the name servers. What we see is that
>> once
>> we start seeing many of these "exceeded" messages in the logs then our
>> "soa
>> queries in progress" will go up significantly and never goes back down.
>> We have to shut down the name server and restart it, and then the "soa
>> queries in progress" goes down to 0 or 1 and he "exceeded" messages go
>> away.
>> Has anyone had a similar problem? If so, how did you resolve this?
> with 100k of zones, you must increase limits. Or, use different technique
> for distributing changes, e.g. NOTIFY and increase the refresh (and retry)
> times to avoid useless timeouts.

Does this KB article help at all?

(It's one you'll need to register to see - but it's otherwise available
to all).

More information about the bind-users mailing list