ietf
[Top] [All Lists]

Re: update timing errors

2003-02-23 16:06:58
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(_at_)vix(_dot_)com
To: "D. J. Bernstein" <djb(_at_)cr(_dot_)yp(_dot_)to>
Cc: ietf(_at_)ietf(_dot_)org, iesg(_at_)ietf(_dot_)org, 
namedroppers(_at_)ops(_dot_)ietf(_dot_)org
From: Mark(_dot_)Andrews(_at_)isc(_dot_)org
Subject: Re: update timing errors 
Date: Mon, 24 Feb 2003 08:28:07 +1100
Sender: owner-namedroppers(_at_)ops(_dot_)ietf(_dot_)org


Mark(_dot_)Andrews(_at_)isc(_dot_)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(_dot_)Andrews(_at_)isc(_dot_)org

--
to unsubscribe send a message to 
namedroppers-request(_at_)ops(_dot_)ietf(_dot_)org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



<Prev in Thread] Current Thread [Next in Thread>