Best Practices for Authoritative Servers

[Paul Vixie]

Mark Andrews <Mark_Andrews at isc.org> writes:

> 	Danny, it is more complicated than that.

yea, verily.

> 	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.

this is what made RFC 1996 so hard to write -- even though the protocol
itself is very simple, the language we must use to describe the protocol
agents and roles is like a hairball dipped in honey.  as shown in the
excerpt below, we had to define the roles, knowing that a given server
can assume more than one of those roles at various times, including at
the same time.

===

2. Definitions and Invariants

   2.1. The following definitions are used in this document:

   Slave           an authoritative server which uses zone transfer to
                   retrieve the zone.  All slave servers are named in
                   the NS RRs for the zone.

   Master          any authoritative server configured to be the source
                   of zone transfer for one or more slave servers.

   Primary Master  master server at the root of the zone transfer
                   dependency graph.  The primary master is named in the
                   zone's SOA MNAME field and optionally by an NS RR.
                   There is by definition only one primary master server
                   per zone.

   Stealth         like a slave server except not listed in an NS RR for
                   the zone.  A stealth server, unless explicitly
                   configured to do otherwise, will set the AA bit in
                   responses and be capable of acting as a master.  A
                   stealth server will only be known by other servers if
                   they are given static configuration data indicating
                   its existence.

   Notify Set      set of servers to be notified of changes to some
                   zone.  Default is all servers named in the NS RRset,
                   except for any server also named in the SOA MNAME.
                   Some implementations will permit the name server
                   administrator to override this set or add elements to
                   it (such as, for example, stealth servers).

   2.2. The zone's servers must be organized into a dependency graph
   such that there is a primary master, and all other servers must use
   AXFR or IXFR either from the primary master or from some slave which
   is also a master.  No loops are permitted in the AXFR dependency
   graph.
-- 
Paul Vixie