Subject: Re: update timing

From: [email-masked]
Date: Sun, 23 Feb 2003 12:00:25 +1100

> [email-masked] writes:
> > So now you want to update the contents of the parent zone
> > without a changing the serial.
> 
> I said nothing of the sort.
> 
> The entire theme of this discussion is that _you_ are causing problems
> by leaving a serial number alone when you should be updating it. Because
> of your configuration error, a slave fails to realize that it needs to
> do an AXFR.

	In every case I've presented the PRIMARY changed the serial when
	the parent zone was updated.   This is correct adminstrative
	procedure.
 
> _I_ am saying that those serial numbers have to be changed at certain
> times. My position is supported by both RFC 1034 (which imposes even
> more stringent constraints---so stringent that you're trying to change
> them) and the reality of what actually works with the installed base.

	There is no requirement to change the contents of a secondary
	zone in RFC 1034.  It's all in your imagination.
 
> (The ``I'll update serial numbers too early if I feel like it, and it's
> inexcusable for software to fail to correct my mistake'' religion made
> a brief appearance in this discussion, and was quickly shredded. It's
> obvious that some constraints are required.)

	It's your I'll change the contents of a secondary zone that
	is causing all the problems.
 
> It is, of course, acceptable for serial numbers to be changed at other
> times too. Extra AXFRs will not cause the world to collapse.
> 
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> --
> 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/>
--
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: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2003 02:29:32 -0000

[email-masked] writes:
> the parent zone was updated.   This is correct adminstrative procedure.

No. Your procedure is insufficient, incomplete, and incorrect.

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.

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?

Anyway, you've admitted that your procedure (1) violates RFC 1034 and
(2) gives wrong answers with most of the installed base. So you don't
have a leg to stand on when you call it ``correct.''