ok mark, that's it. no more replies are warranted. if mr. bernstein still misunderstands zone coherency, then someone who doesn't work for ISC will have to take a turn trying to educate him. we're done. --paul ps. great answer btw. re: > X-Original-To: vixie@vix.com > To: "D. J. Bernstein" <djb@cr.yp.to> > Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org > From: Mark.Andrews@isc.org > Subject: Re: update timing errors > Date: Mon, 24 Feb 2003 08:28:07 +1100 > Sender: owner-namedroppers@ops.ietf.org > > > > Mark.Andrews@isc.org 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. > > Changing the content of SECONDARY zones is outside of the > actions specified by RFC 1034. In fact RFC 1034 demands a > "accurate" copy. You can't have a "accurate" copy if it > has been changed. > > There are no timing issues if you have a "accurate" copy. > > There is no such thing as changing the serial "too early". > > It is the errors in BIND 4, BIND 8 and tinydns that introduce > timing constraints that are not part of RFC 1034 and only > affect servers that are serving both parent and child zones. > > We have heard from at least three other independent developers > that they preserve / preserved the copy of the child zone > based on RFC 1034 requirement. > > Maintaining consistancy between parent and child zones is > a administrative responsability. Even with automated > assistance the changes are required to be applied to the > PRIMARY not to the SECONDARY. BIND 4, BIND 8 and tinydns > violate the maintance model as a result of applying changes > in the incorrect place directly leading to the situation where > all the PRIMARY copies of the zones have the correct information > but some of the SECONDARY "copies" don't. > > There is no technical reason not to preserve the contents of > the SECONDARY copies of the zone unaltered. There are no > negative effects from doing this. There definitely are negative > effects caused by changing the contents of SECONDARY copies. > > All your complaints are based on your interpretation of RFC > 1034. Your interpretation introduces timing issues which > even your own software cannot meet without violating the > requirement to change the serial number when you change the > zone contents. > > In addition to the pure AXFR issues. IXFR depends upon the > contents of the zone not being changed unilaterally on the > SECONDARY. Failure to preserve the contents will result > in deltas not applying that should. This should result in > fallback to AXFR to get a upto date copy of the zone. This > will result in a AXFR style IXFR to done stream servers. > > Mark > > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/>