Re: in support of axfr-clarify

[Kevin Darcy <kcd@daimlerchrysler.com>]

"D. J. Bernstein" wrote:

> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  your subscription address is
>   54830374684695-namedroppers@sublist.cr.yp.to, please post from it or
>   fix subscription your subscription address! ]
>
> Kevin Darcy writes:
> > You're only reinforcing the need for a Clarify draft.
>
> I've been saying for years that the DNS specifications are horribly
> inadequate. I thought axfr-clarify sounded like a great idea until I
> read the document and discovered twelve problems. Two of those problems
> have now been fixed; ten more to go.
>
> > an implicit assumption -- that non-Answer sections of an AXFR response
> > would never be used productively -- which turned out to be false
> > because of things like EDNS0 and TSIG.
>
> These issues have been discussed before. First, contrary to your claim,
> there is no evidence of an actual problem. Second, and more importantly,
> if an optional protocol extension fails to ensure compatibility with the
> previous protocol, that is entirely the extension's fault.

Well, no, not really. My understanding is that any protocol extension may
alter the base protocol as long as the extension itself is on Standards
Track. In this case, it's rather a moot point anyway, since AXFR was
underspecified originally (we all agreed on that, right?), so it's not clear
whether TSIG, EDNS0, etc. actually broke anything vis-a-vis their potential
applicability to AXFR transactions. You can't "break" something that wasn't
specified in the first place.

> As I wrote when we last discussed this in July 2001, after you asked why
> I wasn't changing my code:
>
>    The benefits are nonexistent. The harms include encouraging further
>    disregard for compatibility. What stops incompetent implementors from
>    demanding another code change every week? Ignore AXFR AR, discard
>    TKEY, ignore types 128-255, recognize IXFR, ignore MS garbage. This
>    is not a sane way to handle optional protocol extensions.
>
> Is compatibility such a difficult concept to grasp?

Just because you don't find any use for TSIG, EDNS0,  doesn't mean that
other people don't. Yes, I find compatibility-as-a-concept easy to grasp,
but what I fail to understand is why you think *your* compatibility trumps
everyone else's. I want to (and do) use TSIG-signed zone transfers. Do you
think this is or should be a "proprietary" mechanism? As your code stands
today, would it break your AXFR client to receive one? axfr-clarify confers
the blessing of IETF standards on TSIG-signed zone transfers, among other
extensions, while at the same time ensuring that implementations which don't
understand or don't support these extensions aren't hurt if some day they
receive one. And the only cost we (collectively) pay for these benefits is
that *one* implementation (yours) has to make a relatively small code change
that didn't demonstrably help anyone in the first place.


- Kevin



--
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/>