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