Re: TKEY compatibility problems

[Robert Elz <[e-mail]>]

    Date:        Tue, 17 Jul 2001 13:19:34 -0700
    From:        "D. J. Bernstein" <[e-mail]>
    Message-ID:  <[e-mail]>

  | Could you possibly explain just what it would hurt for the BIND company
  | to alter _their_ implementation to handle data in other sections?

If that was the right thing to do (if there was some advantage to be
gained by doing that), then it wouldn't hurt at all, and I would be
requesting that exactly that happen.

Just now, I can't think of any possible benefit that would gain though,
if data in an AXFR is supposed to be treated just line the data in the
answer section, then it might as well get put in the answer section.
After all, there's nothing to be gained by putting it elsewhere.

The only point for having multiple sections in answers is so the RRs
in those sections can be treated differently, otherwise the different
sections wouldn't exist at all.

  | After all, I might want to deploy an optional AXFR extension that---
  | without wasting space---communicates a few extra bits of information by
  | putting records into AU or AR instead of AN. This extension would be
  | incompatible with current versions of BIND, so BIND has to be fixed!

Yes, if there's any benefit to be gained by that extension, so that it
would ever get general agreement, that would be true.   So, if you can
explain to me just how anyone would ever benefit by deliberately splitting
data that is to be treated just the same over multiple sections, then
perhaps you would get me (and perhaps even someone else) to agree with
you.

On the other hand, it is easy to see how if there was ever some data that
should not be treated the same could easily be marked as different by putting
it in a different section - provided that servers don't go treating the
different sections as if they were equivalent.

  | Now, I realize that there are a million BIND hosts out there, including
  | tens of thousands running ancient versions of BIND, but, gee, surely
  | they'll all upgrade before I deploy my incompatible extension. If they
  | don't, we'll use BIND's ``remote root upgrade'' feature!

Yes, they probably would, if there were to be a reason to do this,
remaining compatible with ancient BIND into the distant future isn't
something to worry about.  Retaining compatability with ancient djbdns
is even less to worry about.

  | Whaddya mean, optional extensions have no right to break compatibility?

I don't mean that, never did.   For sure, the compatability of any
extension needs to be carefully considered to see how well it will
actually work - that's just the same as evaluating whether the rest
of the proposal will actually work.   There's no point defining something
that won't work in practice, no matter what the reason.   But if it
will work, and is generally agreed to be required, then breaking old
stuff can be OK - it's all part of the trade offs to be considered.

  | Maybe you're not swayed by practical compatibility concerns. Well, how
  | about the spirit of RFC 1034? The RFC says that zone transfer messages
  | carry all the zone records. It _doesn't_ say that the records are in the
  | answer section. Obviously clients are meant to read all the sections!

The conclusion does not follow.   More accurate would be "Obviously
clients get the AXFR answer from the answer section, we don't need to
actually say that".

Note that you deliberately avoided answering the question I asked.
>From that I assume that there is no rational reason at all why you
can't change your implementation to only look in the answer section.

Given this, and the notice that you have been given that one day perhaps
an AXFR extension may be created which requires servers to treat the
different sections in an AXFR message differently (and one might assume,
allows servers that don't understand the new stuff to simply ignore it,
by ignoring that section and all its data), then if that ever happens,
and the users of your server all come complaining that they're being forced
to upgrade, and they don't want to (or can't, if your server is no longer
being maintained then) - we'll all just refer them to you, and tell them
that you knew all about this years ago (from that time in the future) and
deliberately decided then to screw them.

kre




to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.