Re: axfr-clarify breaking RFC 1034

[Mark.Andrews@isc.org]

> Here's a chart summarizing the situation:
> 
>    Timing of         |Useful in|RFC 1034 |BIND 8 |BIND 9 |tinydns
>    data change       |practice |compliant|support|support|support
>    ------------------+---------+---------+-------+-------+-------
>    Synchronized      |Yes      |Yes      |No     |No     |Yes
>    Semi-synchronized |Yes      |No       |Yes    |Yes    |Yes
>    Unsynchronized    |No       |No       |No     |Yes    |No

	This is not a accurate summary.
 
> The BIND company observes that
> 
>    * synchronized changes are hard to do with BIND, even though they're
>      required by RFC 1034; and

	RFC 1034 requires the *administators* to keep the glue in sync.

Section 4.2.2. Administrative considerations

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.

	This is a administrative action.

	If you can automate administrative actions well and good.  Using
	a single file for all your PRIMARY zones is actually a useful
	way to partially achieve this.  It will keep all PRIMARY zones
	on the server in sync.

	If you wish you can copy the contents of a SECONDARY into a 
	PRIMARY provided you also change the SERIAL of the PRIMARY to
	reflect the change.  I wouldn't encorage this as a default
	action however.

	However changing the contents of SECONDARY zones is not allowed.
	That action needs to be performed through the PRIMARY server for
	the zone.  UPDATE could be used to facilitate this.  Again I would
	not encourage this as a default action.

	A server ceases to be a SECONDARY if it changes the zones contents.

>    * unsynchronized changes can fail miserably with BIND 8 et al., which
>      account for the majority of DNS servers.

	Which is why we fixed our server.
 
> The obvious solution is semi-synchronized changes, which work with the
> entire installed base. I wouldn't object to modifying RFC 1034 to allow
> semi-synchronized changes.

	You have to be kidding.  Even if we were to go down that
	path (which I don't believe we should) it still leaves
	servers with the underlying problem in that they are not
	serving the zone contents as entered.
 
> (To repeat the relevant definitions: A synchronized change happens at
> the same time in all the parent servers and all the child servers. A
> semi-synchronized change happens in the parent zone---specifically, the
> parent serial is changed---after it happens in all the child servers.)
> 
> I certainly _do_ object to allowing unsynchronized changes. They don't
> work correctly with the installed base, and they have no advantages over
> semi-synchronized changes. It's insane to demand massive redeployment of
> DNS servers for the sake of a useless protocol modification.

	Nobody is demanding a massive redeployment.  None of the changes
	require a massive redeployment.
 
	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org