Subject: your ongoing diatribe

From: "Mike O'Dell" <[email-masked]>
Date: Sun, 23 Feb 2003 20:30:19 -0500

Excuse me, sir, but I've enjoyed quite enough of your behavior

Your lack of genuine operating experience is transparent.  don't quote
	adoption numbers for your software - i'm talking about *you*
	having direct experience running very large name server systems
	with many tens of thousands of zones, both primary and secondary,
	or equivalently, working hand-in-glove with those who have

Your failure (nee unwillingness) to appreciate the large-scale
	consequences of your mathematical fantasy land is simply stunning

The fact the Real World doesn't care about the constraints you've constructed
	to make your world view viable doesn't seem to faze you

In particular, you don't appreciate the necessity of reasonable
	operational behavior in the presence of multiple
	administrative domains which cannot perform with
	perfect coordination

Then you have the audacity to describe those with a deep understanding
	of what it takes to make the Big-I Internet work at very
	large scale as "pathetic".

Frankly, sir, sit down. You have embarrassed yourself in this forum
	quite enough and have impeded the efforts of those working
	mightily to move things along in a constructive manner.

You seem to imagine this is some kind of debating society where you
	gain points by taking yet another turn at the microphone
	when your opponents have been worn down by arguing with a
	refractory surface.

It isn't a debating society, "rough consensus" goes not require unanimity
	and there is serious work to get done, so I ask again,

Sir, please sit down.

	I now return you to the previous screed,
	-mo

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Feb 2003 22:18:18 -0000

Mike O'Dell writes:
> cannot perform with perfect coordination

RFC 1034 requires perfect coordination. However, I've been pointing out
that a much looser glue-update procedure works just fine:

   (1) Change the data in the child zone on the child master.
   (2) Once #1 is done: Change the child serial number.
   (3) Once #2 is done: Copy the new data to all the child slaves, for
       example by waiting for the slaves to pull the data through AXFR.
   (4) Change the data in the parent zone on the parent master.
   (5) Once #3 and #4 are done: Change the parent serial number.
   (6) Once #5 is done: Copy the new data to all the parent slaves, for
       example by waiting for the slaves to pull the data through AXFR.

This guarantees a successful update with all of today's DNS software.
For example, the update will succeed if the child administrator does #1,
#2, #3 and then tells the parent administrator to do #4, #5, #6. Easy!

If you violate the timing constraints---for example, if you change the
parent serial number too early---then the update may fail. For example,
breaking the #3<=#5 rule can cause failures with BIND 8, and breaking
the #4<=#5 rule can cause failures with BIND 8 or BIND 9. Solution:
Don't break the rules!

The BIND company has been drawing a completely unjustified line between
the #3<=#5 rule and the other rules. They're demanding that we go to a
lot of effort to allow #5<#3 because BIND 9 does. How is this supposed
to benefit the administrators?

Even if we started on this massive upgrade, #5<#3 would remain unsafe
for the foreseeable future. Not only is there a huge BIND 8 installed
base, but many OS distributors are deliberately avoiding BIND 9. So
administrators would have to continue following the #3<=#5 rule for
the foreseeable future. The BIND company is simply trying to make extra
work for competing DNS implementations.

There's a long history of the BIND company introducing interoperability
problems: their multiple-answers AXFR format, for example, and their
failure to handle NODATA responses to IXFR. They try to blame the other
side for these failures, even when BIND is clearly violating RFC 1034
(as in the IXFR case) and could easily have avoided the failures (as in
the multiple-answers and IXFR cases). They use these failures to market
the latest version of BIND: if you change to BIND on the other side,
everything will work again! This is reprehensible.

> don't quote adoption numbers for your software

Why not? You talk about ``very large name server systems'' and
``large-scale consequences'' and ``the Real World'' and ``the Big-I
Internet,'' and you expect me not to mention that tinydns is being used
by seven of the largest .com hosting companies on the Internet?

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