Subject: Re: update timing

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

> Andrews gives yet another example of a configuration that (1) violates
> the semi-synchronization rule and (2) causes problems.
> 
> The solution, of course, is to follow the semi-synchronization rule:
> update the parent serial number after the child servers have changed.
> 
> [email-masked] writes:
> > Tinydns is incapable of doing this.
> 
> Where do you get these ridiculous ideas?
> 
> With tinydns, you can use manual serial numbers and update them exactly
> as you would with BIND. You can also use automatic serial numbers and
> update them by simply touching the data file. Both ways work.

	So now you want to update the contents of the parent zone
	without a changing the serial.  You want the administators
	to intentionally introduce inconsistanties within the servers
	of a zone to deal with your misguided attempts to remove
	inconsistanties between zones that will be corrected if
	you left them alone.

	Mark
 
> ---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 00:08:19 -0000

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

_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.

(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 is, of course, acceptable for serial numbers to be changed at other
times too. Extra AXFRs will not cause the world to collapse.