ietf
[Top] [All Lists]

Re: your ongoing diatribe

2003-02-24 15:24:39
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



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