Best Practices for Authoritative Servers
Kevin Darcy
kcd at chrysler.com
Fri Feb 1 17:48:58 UTC 2008
Niall O'Reilly wrote:
> [ My MUA insists on normalizing timestamps to my timezone. I'm sorry. ]
>
> On 1 Feb 2008, at 02:02, Mark Andrews wrote:
>> If you have a loop in the axfr transfer graph all the slaves
>> in that loop will converge to serving the same zone content
>> (good) but will also keep resetting the refresh (with refresh
>> not retry which is bad) and expiry timers (extremely bad).
>>
>
> On 1 Feb 2008, at 02:41, Kevin Darcy wrote:
>
>> It's a shame BIND doesn't have any way of differentiating between "peer"
>> masters and "upstream" masters, so that the resetting behavior can be
>> controlled.
>
> It's not the only software not to have a DWIM mode, and with
> good reason. Somewhere, there has to be a responsible person
> in charge. Identifying which elements of a configuration
> correspond, in the mind of that person, to a particular
> purpose, is not something which software can reliably do.
Perhaps I wasn't clear. I wasn't talking about DWIM, I was talking about
a way within named.conf to *explicitly* tell named which of the masters
are "peers" versus which of them are truly "upstream". "Serial number
ok" responses from "upstream" masters would reset the timers are per
usual, but wouldn't reset the timers when received from "peer" masters,
whose only purpose is to ensure that the latest version of the zone gets
out everywhere. Thus, if the only good refreshes come from "peer"
masters, eventually the zone will expire.
Example config:
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; };
peer-masters { aaa.aaa.aaa.aaa; bbb.bbb.bbb.bbb; };
>
> As Mark explains (see above), "peer" masters are an "extremely
> bad" idea. They give the opportunity of robustly perpetuating
> incorrect state, while making it more difficult to notice
> that something is wrong, since nothing appears broken from
> outside the circle of peers.
In the absence of such a BIND configuration feature, one is limited to
scanning the logs for messages of the type
17-Jan-2008 17:55:13.439 zone xxx.xxx.com/IN: refresh: retry limit
for master xxx.xxx.xxx.xxx#53 exceeded (source 0.0.0.0#0)
which is probably something good admins should be doing anyway, unless
you want zone expiration to be the *first* indication that something is
wrong with your replication.
- Kevin
More information about the bind-users
mailing list