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've been bending the _de_facto_ rules in these regards (e.g.
> > "section agnosticism" or whatever you call it)
>
> How is it possible for people to be so fundamentally confused about such
> a simple issue?
>
> RFC 1034 says that the AXFR server sends ``messages'' that ``carry'' all
> the records. This is ambiguous: does ``carry'' refer to all sections of
> the message, or is it restricted to the answer section?

You're only reinforcing the need for a Clarify draft.

> I decided to take the safest possible interpretation:
>
>    * My AXFR _server_ puts all records in the answer section, just in
>      case some clients look only at the answer section.
>
>    * My AXFR _client_ reads all sections, just in case some servers use
>      other sections.

Okay, Dan, I appreciate now that you were just trying to be cautious in your
client. But the threat that you protected against never actually
materialized, and at the same time the mechanism you used to protect against
it appears to have made 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.

No-one blames you for having less-than-perfect foresight. But when the
DNS world changes, sometimes old assumptions are invalidated and code which
is based on those assumptions needs to change or become
non-standards-compliant. The proposed AXFR Clarify draft, inasmuch as it
seeks to accommodate relatively recent developments like EDNS0 and TSIG, not
to mention future extensions, with its "must ignore" provisions, seems to be
incompatible with the behavior of your AXFR client. Something has to give
here. The question is: is your codebase the "immovable object" which
prevents AXFR from being clarified in this way, or is AXFR Clarify the
"irresistible force" which requires you to change your code in order to
maintain standards-compliance? As inconvenient as it may be for you and the
users of your DNS package, I think the rough concensus here is for the
latter. The alternative is for AXFR to remain under-specified
*indefinitely*, thus leading to more interoperability problems in future
implementations. Let's move forward here.


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