Re: TKEY compatibility problems

["D. J. Bernstein" <[e-mail]>]

Robert Elz writes:
> and assuming that anyone ever actually wants to do a TKEY lookup

Please read more carefully. Here's the failure under discussion,
involving a TKEY server, a non-TKEY cache, and a TKEY client:

   (1) the server sends a spontaneous TKEY---apparently this is not
       prohibited by the TKEY spec;

   (2) the cache saves the TKEY record---this is how caches are supposed
       to behave under RFC 1034/1035/1123, and it's how my cache works,
       and it's how the current BIND cache would behave if it didn't
       know about TKEY;

   (3) the client does a * lookup (_not_ a TKEY lookup!)---this is
       something that MTAs do frequently, working around old BIND bugs;

   (4) the cache returns the TKEY record in AN---this, again, is how the
       current BIND cache would behave if it didn't know about TKEY;

   (5) the client sees the TKEY record and chokes---the TKEY spec does
       not allow TKEY in AN.

The non-TKEY cache is behaving properly here. The inescapable conclusion
is that the TKEY extension is broken. The TKEY specification has to be
fixed. It could prevent #1 by prohibiting spontaneous TKEYs, or it could
prevent #5 by requiring that TKEY clients ignore unexpected TKEY
records, or both.

> That solves the interoperability problem by defining exactly what is correct.

Writing specs does not solve interoperability problems. _Deploying code_
can solve interoperability problems. Deployment is, however, expensive.
Why should my users suffer this cost? Why is the BIND company so
amazingly careless with its protocol extensions?

I've seen a lot of bad protocol design in the IETF, but never before
have I seen such blatant disregard for compatibility.

> But if it will work, and is generally agreed to be required, then
> breaking old stuff can be OK

Nobody claims that TKEY is required; in fact, like TSIG, it seems rather
pointless in a world of IPSEC. Nobody claims that the BIND company's
hypothetical AXFR extensions are required. The cost of deploying these
optional features should be paid by the people who want the features.

> The A records that accompany those MX records are glue.

As I said, that's rarely true. The server almost always has the A record
in its authoritative data, if it has it at all. Perhaps you have
forgotten the definition of glue?

  [ in RFC 1034, RFC 1035, RFC 1123 ]
> there's certainly support for treating the data in the different
> sections differently

Certainly. But there's no support for Vixie's credibility rules, or for
your fraudulently labelled ``clarifications'' in RFC 2181.

RFC 1035 requires that new data be preferred to cached data in one
situation. It never requires that cached data be preferred to new data.
It never requires that additional records be kept out of answers.

Your sarcastic comments about my deliberate violation of RFC 2181 (``I
will do what I like, and everyone else better write/change the specs to
reflect what I have done,'' etc.) sound rather stupid in light of the
fact that BIND 9 also deliberately violates RFC 2181.

---Dan


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