Re: TKEY compatibility problems

[Robert Elz <[e-mail]>]

    Date:        Wed, 18 Jul 2001 18:59:41 -0700
    From:        "D. J. Bernstein" <[e-mail]>
    Message-ID:  <[e-mail]>

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

ANY lookups not directed at an auth server for the zone containing the RR
are close to a waste of time, as all they ever return is what the server
queried happens to have in its cache at the time (unless, sometimes, that
was nothing, and the server queried finds the auth server and does an
ANY query of that).   A query of an AUTH server won't return a TKEY
in the answer section.

But should a client for some odd reason decide that an ANY query of a cache
actually makes sense, then ...

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

"chokes" in any reasonable implementation will be "ignores the record".
In practice, those applications that do do ANY queries, are looking for
a couple of particular record types (they'd often rather be sending a
query for A AAAA A6 MX and CNAME but can't currently do that in one
message) anything else returned (NS, SOA, RP, LOC, HINFO, WKS, ...) just
gets ignored anyway - it is kind of hard to see why TKEY is going to
be treated differently.

  | or it could
  | prevent #5 by requiring that TKEY clients ignore unexpected TKEY
  | records,

Yes, the TKEY spec probably should do that, but that it doesn't doesn't
make it fatally flawed, just not as complete as it could be - something
to fix when it is revised.

  | Writing specs does not solve interoperability problems. _Deploying code_
  | can solve interoperability problems. Deployment is, however, expensive.

Yes, which is why it is good if everyone can agree on what the deployed
code should do to void the problem before anyone starts deploying anything.
Otherwise the attempts to solve the problems can just cause other problems.
That is, writing the specs is a useful first step.

  | Why should my users suffer this cost?

We're not back at this again are we?  I thought this had already been
made clear ... no-one is asking your users to do anything.  We're
suggesting that you should change your implementation and then make
that available to your users if they want it.   You can even delay
making the changed version available until there are other updates to
the code for other reasons if you like (no need to actually go do the
work of making a distribution just for this).   Just make the change
in your master sources (it doesn't even need any real doc, since it
is changing nothing anyone will ever notice) and then let natural
selection play its part.

You have yet to explain what is difficult/hard/impossible/unreasonable
about that.   I seem to recall that people who have seen your code have
even demonstrated the change that needs to be made...

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

No.   As I said, the server will often be authoritative for the A record
involved (not always, but often), and so the A record didn't come from
glue in the server's data.   But the resolver that receives the reply has
no way to know that - all it sees is an A record that isn't from the same
zone as the answer.   That's glue.   There's no way at all for the resolver
to know whether the server was authoritative or not.

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

No question but what started out as clarifications also grew some new
specifications (as I recall it, 2181 even makes that clear, despite the
title still saying clarifications).

So?

Call this part "corrections" if you like.

  | Your sarcastic comments about my deliberate violation of RFC 2181
  | [...] sound rather stupid in light of the
  | fact that BIND 9 also deliberately violates RFC 2181.

No, it isn't that your server violates 2181 that I commented on.
Nor do I care much whether BIND9 does (nor whether the two of them
ignore the same part).   When 2181 gets considered for elevation to DS
it will get reviewed, and any parts of it that are generally considered
to be wrong will either get deleted, or corrected.   That's a normal
part of our iterative standards development process.

What was ludicrous in your statement was the suggestion that the deployed
base that you created by deliberately ignoring 2181 was, in itself,
a reason for 2181 to be changed.

This seems to be based on your flawed assumption that all the IETF does is
document that which exists in the wild.   That's not true - what we do
is document what should exist out there, as best we can judge it.  That is
heavily influenced by what actually is out there of course - on the
assumption that we wouldn't be shipping stuff if we didn't believe it was
the right thing - but not always.

eg: back in the distant past, old BINDs implemented the SOA.serial
field as a (perhaps signed, I forget) integer, with a range from 0
to 2^32-1 (or -2^31 .. 2^31-1 if it was signed).   Upon reaching the
max value it simply stopped.   And the 0 was "magic" (may still be
in BIND8, though I hope that is fixed in BIND9).   Back then, BIND
was essentially the whole deployed base.   According to your theory
on what the IETF should do, it should have simply documented the
serial number as a simple bounded integer value, to match what was
actually deployed.   But that would have been stupid - not a rational
definition of the field, instead, the (almost) whole deployed base
was simply made to fix the bug, and now we have serial numbers
everywhere that actually work the way they were designed to work.

kre



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