Subject: Re: update timing

From: [email-masked]
Date: Sun, 23 Feb 2003 16:07:48 +1100

> [email-masked] writes:
> > In every case I've presented the PRIMARY changed the serial when
> > the parent zone was updated.   This is correct adminstrative procedure.
> 
> No. Your procedure is insufficient, incomplete, and incorrect.

	Changing the serial number when they data in a zone changes is
	correct procedure.

	THAT IS ALL THAT IS REQUIRED WITH NON BROKEN SERVERS.  THAT IS
	ALL THAT IS REQUIRED BY RFC 1034.

	Waiting for data to propogate is a WORKAROUND.

> You're arguing that, because you did _something_ right, your entire
> procedure is correct. The premise is okay, but the logic is idiotic.
> 
> Here's an extreme example to demonstrate the flaw in the logic. Suppose
> you _never_ update the data in the child servers. Then the old data will
> persist, producing a long-lasting inconsistency, quite similar to the
> inconsistencies in your BIND 8 examples and in my BIND 9 example.

	If you never update the child then it is an *administrative*
	error.

> You can scream ``I updated the parent data and serial number'' all you
> want. But the problem isn't what you _did_; the problem is what you
> _failed_ to do. Now do you understand the flaw in your argument?
 
	The size of the installed base has absolutely nothing to do
	which what is right or wrong.
	
	If 90% of installed bridges had construction/design flaws what
	would you do.

	A.  Continue to used that the existing construction/design method.
	B.  Stop using the existing construction/design method.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Len Budney <[email-masked]>
Date: Sun, 23 Feb 2003 00:33:58 -0500 (EST)

> If 90% of installed bridges had construction/design flaws what

Redesign and rebuild the bridges, of course. But I wouldn't claim it was
"routine maintenance" and "design clarification", for starters. I'd call
it what it was.

--Len.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2003 09:15:13 -0000

[email-masked] 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.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago