Re: RFC 2119 section 6

[Kevin Darcy <[e-mail]>]

D. J. Bernstein wrote:

> Kevin Darcy writes:
> > TSIG and EDNS0 are already with us, and as far as I know it is legal
> > for either or both to be transmitted in an AXFR response
>
> Only by bilateral agreement.

We've already stipulated that AXFR servers shouldn't be sending zone data
outside of the Answer Section, so this whole issue is moot if every server
could be trusted to do The Right Thing all of the time. But if we want AXFR
clients to be robust and deal reasonably with a server that does The Wrong
Thing, however, then we have to deal with unagreed-upon OPT or TSIG records
as well as non-Answer-Section zone data. The clarify draft says "ignore the
RRs". You seem to be challenging that and saying instead "no, treat them as
zone data". Which means if you get a wayward OPT or TSIG record, your
client presumably will mistake that for zone data, whereas most other
clients will just ignore them if they don't recognize them or there is no
bilateral agreement to use them. This is an interoperability problem. The
same records are being treated differently depending on the idiosyncrasy of
the implementor. This is _exactly_ the kind of thing that a clarify draft
is meant to clear up. And when a protocol is clarified, it's certainly not
unusual for software which made the "wrong" assumption (even if it didn't
seem "wrong" at the time, because the specification was unclear) to have to
change to conform to the clarified standard.

> > are you seriously suggesting that we already need 2 new port
> > assignments, with more to be obtained as new extensions are adopted?
>
> Of course not. You could easily squeeze the entire OSI protocol suite
> into a protocol running on a single TCP port.
>
> You have to be careful, however, if you want to use port 25, or port 80,
> or port 53. You have to maintain compatibility with the installed base.
> That's why protocol designers often use new ports.

Or they use otherwise-unused sections of a response...

> Terrified of new ports? Fine. Use a new EXFR query type. This is not
> rocket science.

Oh, great. So now we're defining new query types for every extension,
whether it functionally needs it or not. Or, should I say, every
*combination* of extensions (one for TSIG only, one for EDNS0 only, one for
EDNS0+TSIG, etc.)? We'll chew up the QTYPE range pretty quickly that way...

> > you have IMO fallen far short of demonstrating that
> > "section-agnosticism" has any practical value
>
> I have thousands of sites whose adminitsrators don't want to be forced
> to upgrade their working DNS software. If you don't think compatibility
> has ``practical value,'' you're an idiot.

And if you think protocol-implementing software can be immutable, even in
the face of protocol clarifications and extensions, then you're... well...
I've sworn off name-calling so I'll abstain. Suffice it to say, speaking as
an administrator, I view claims about "software that will never need to be
upgraded" with about as much skepticism as claims about perpetual-motion
machines.


- Kevin





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