Best Practices for Authoritative Servers

[Mark Andrews]

> Kevin Darcy wrote:
> >>     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.
> 
> The master is listed in the SOA record. If it's not from there it's not 
> the master.

	Danny, it is more complicated than that.

	Consider the transfer graph:

		B Transfers from A
		C Transfers from B
		C Transfers from D
		D Transfers from B
		D Transfers from C

			A
			|
			V
			B
		       / \
		      V   V
		      C<->D

	C and D are peers, A and B are treated as masters.
	
	Now add in E which transfers from B, C and D.  If C and D are
	treating each other as peers then E can treat B, C and D as
	masters.  If C and D treat each other as masters then E can
	only treat B as a master and need to treat C and D as peers
	even though they don't transfer from E.

	Mark
	
> Danny

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org