Re: update timing errors

[Paul Vixie <paul@vix.com>]

ok mark, that's it.  no more replies are warranted.  if mr. bernstein
still misunderstands zone coherency, then someone who doesn't work for
ISC will have to take a turn trying to educate him.  we're done. --paul

ps. great answer btw.

re:

> X-Original-To: vixie@vix.com
> To: "D. J. Bernstein" <djb@cr.yp.to>
> Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org
> From: Mark.Andrews@isc.org
> Subject: Re: update timing errors 
> Date: Mon, 24 Feb 2003 08:28:07 +1100
> Sender: owner-namedroppers@ops.ietf.org
> 
> 
> > Mark.Andrews@isc.org writes:
> > > If you never update the child then it is an *administrative* error.
> > 
> > Changing the serial number too early is also an administrative error.
> > Here's a summary of our three examples of administrative errors:
> > 
> >    1. Failing to update the parent serial number after updating the glue
> >       in all the child servers. As you keep pointing out, this error can
> >       cause problems with BIND 8: the data will be inconsistent until
> >       the serial number is updated.
> > 
> >    2. Failing to update the parent serial number after updating the glue
> >       in the parent master. This error can cause problems with BIND 9
> >       (and BIND 8, of course): the data will be inconsistent until the
> >       serial number is updated.
> > 
> >    3. Failing to update the data in the child master. This error can
> >       cause problems with BIND 9 (and BIND 8, of course): the data will
> >       be inconsistent until the child data is updated (and the serial
> >       numbers handled properly).
> > 
> > In every case, the administrator is violating RFC 1034 (as you have
> > admitted), and is creating a configuration that does not work properly
> > with most DNS software deployed in the real world.
> > 
> > You persist in drawing a completely unjustified line between the first
> > error and the other two errors. You claim that allowable administrative
> > action is defined by BIND 9---never mind what RFC 1034 says, and never
> > mind the rest of the installed base. You cycle endlessly between ``BIND
> > 9 is doing the Right Thing'' and ``BIND 9 handles that situation'' and
> > ``that situation is not actually an error,'' attempting to defend each
> > part of the BIND 9 religion by showing how it fits with the other parts.
> > The circularity is pathetic.
> > 
> > In situations where there's a difference between the software and the
> > spec---for example, actions that are prohibited by RFC 1034 even though
> > they work in the real world, or vice versa---one can reasonably discuss
> > whether the actions should be considered errors. But the above actions
> > do _not_ work and are _not_ allowed by the spec. If you want to support
> > them in BIND 9, fine, but you have no basis for demanding that the rest
> > of us support them too.
> 
> 	Changing the content of SECONDARY zones is outside of the
> 	actions specified by RFC 1034.  In fact RFC 1034 demands a
> 	"accurate" copy.  You can't have a "accurate" copy if it
> 	has been changed.
> 
> 	There are no timing issues if you have a "accurate" copy.
> 
> 	There is no such thing as changing the serial "too early".
> 
> 	It is the errors in BIND 4, BIND 8 and tinydns that introduce
> 	timing constraints that are not part of RFC 1034 and only
> 	affect servers that are serving both parent and child zones.
> 
> 	We have heard from at least three other independent developers
> 	that they preserve / preserved the copy of the child zone
> 	based on RFC 1034 requirement.
> 
> 	Maintaining consistancy between parent and child zones is
> 	a administrative responsability.  Even with automated
> 	assistance the changes are required to be applied to the
> 	PRIMARY not to the SECONDARY.  BIND 4, BIND 8 and tinydns
> 	violate the maintance model as a result of applying changes
> 	in the incorrect place directly leading to the situation where
> 	all the PRIMARY copies of the zones have the correct information
> 	but some of the SECONDARY "copies" don't.
> 
> 	There is no technical reason not to preserve the contents of
> 	the SECONDARY copies of the zone unaltered.  There are no
> 	negative effects from doing this.  There definitely are negative
> 	effects caused by changing the contents of SECONDARY copies.
> 
> 	All your complaints are based on your interpretation of RFC
> 	1034.  Your interpretation introduces timing issues which
> 	even your own software cannot meet without violating the
> 	requirement to change the serial number when you change the
> 	zone contents.
> 
> 	In addition to the pure AXFR issues.  IXFR depends upon the
> 	contents of the zone not being changed unilaterally on the
> 	SECONDARY.  Failure to preserve the contents will result
> 	in deltas not applying that should.  This should result in
> 	fallback to AXFR to get a upto date copy of the zone.  This
> 	will result in a AXFR style IXFR to done stream servers.
> 
> 	Mark
> 
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>