Re: TKEY compatibility problems

"D. J. Bernstein" <djb@cr.yp.to> Sat, 14 July 2001 05:22 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12414 for <dnsext-archive@lists.ietf.org>; Sat, 14 Jul 2001 01:22:44 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LHAw-0007rZ-00 for namedroppers-data@psg.com; Fri, 13 Jul 2001 21:37:06 -0700
Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15LHAw-0007rT-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 21:37:06 -0700
Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15LHAw-000MFY-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 21:37:06 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: "D. J. Bernstein" <djb@cr.yp.to>
To: namedroppers@ops.ietf.org
Subject: Re: TKEY compatibility problems
References: <E15KpfA-000ISO-00@psg.com> <E15LDdz-0002Xy-00@psg.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15LHAw-0007rZ-00@psg.com>
Date: Fri, 13 Jul 2001 21:37:06 -0700
Content-Transfer-Encoding: 7bit

Suppose I'm a DNS cache with no special knowledge of type TKEY or type
XYZZY. Someone asks me for all nominum.com records of type XYZZY.

One of the nominum.com servers gives me the following response,
including a spontaneously generated TKEY record, which Wellington says
is not prohibited by the TKEY specification:

   query: XYZZY nominum.com
   answer: nominum.com 3600 XYZZY ...
   authority: nominum.com 3600 NS ...
   authority: nominum.com 3600 NS ...
   authority: nominum.com 3600 NS ...
   additional: gns1.nominum.com 3600 A ...
   additional: gns2.nominum.com 3600 A ...
   additional: nominum.com 3600 TKEY ...

All those records are within nominum.com, so I cache all of them.

I do _not_ ignore the two records of unrecognized types. As stated in
RFC 1123, section 6.1.3.5: ``A name server may acquire, via zone
transfer, RRs that the server doesn't know how to convert to printable
format. A resolver can receive similar information as the result of
queries. For proper operation, this data must be preserved.''

I do _not_ ignore the three authority records, and I do _not_ ignore the
three additional records. Wellington's comment ``they're not part of the
zone, as indicated by the fact that they're in the additional section''
is completely out of touch with the existing DNS protocol.

Someone now asks me for all nominum.com records of type *. I am entirely
within my rights to respond with all the cached nominum.com records,
including the TKEY record:

   query: * nominum.com
   answer: nominum.com 3597 NS ...
   answer: nominum.com 3597 NS ...
   answer: nominum.com 3597 NS ...
   answer: nominum.com 3597 TKEY ...
   answer: nominum.com 3597 XYZZY ...

Wellington claims that TKEY-aware clients may barf on this response.

The inescapable conclusion is that the TKEY protocol is broken. It is
incompatible with the existing protocol. It has to be fixed.

How can a broken protocol be used as an argument against the behavior of
my AXFR implementation? I'm indisputably allowed to save records from
the authority section and the additional section when I'm a cache, so
why can't I do the same when I'm an AXFR client?

---Dan

P.S. This particular failure won't actually happen with our current
implementations: my cache will stop its * response after the NS records,
and the nominum.com servers won't spontaneously generate TKEY records in
the first place. But the specifications don't require these protections.

P.P.S. Each of my messages, as sent, contains the following statement in
the header: ``Copyright 2001, D. J. Bernstein. My transmission of this
message to you does not constitute a copyright waiver or any other
limitation of my rights, even if you have told me otherwise.'' This
statement is being discarded somewhere in Randy Bush's mail system.


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.