Preference of Master Name Servers

[Cathy Almond]

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 mysample.me.uk { type slave; file "m/y/db.mysample.me.uk"; masters {
>> 10.10.100.12; 10.10.101.12; 10.10.102.5; }; };
>> 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 mysample.me.uk/IN: refresh: retry
>> limit for master 10.10.101.12#53 exceeded (source 10.10.100.25#0)
>>
>> 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?

https://kb.isc.org/article/AA-00726/0/Tuning-your-BIND-configuration-effectively-for-zone-transfers-particularly-with-many-frequently-updated-zones.html

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