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.
- Re: RFC 2119 section 6 Alan Barrett
- Re: RFC 2119 section 6 D. J. Bernstein
- Re: RFC 2119 section 6 Brian Wellington
- Re: RFC 2119 section 6 Brian Wellington
- TKEY compatibility problems D. J. Bernstein
- Re: TKEY compatibility problems D. J. Bernstein
- Re: RFC 2119 section 6 Kevin Darcy
- Re: RFC 2119 section 6 Brian Wellington
- Re: TKEY compatibility problems Andreas Gustafsson
- Re: RFC 2119 section 6 D. J. Bernstein
- Re: TKEY compatibility problems D. J. Bernstein
- Re: RFC 2119 section 6 Kevin Darcy
- Re: TKEY compatibility problems Robert Elz
- Re: RFC 2119 section 6 Kevin Darcy
- Re: RFC 2119 section 6 Kevin Darcy
- Re: TKEY compatibility problems Robert Elz
- Re: TKEY compatibility problems Brian Wellington
- Re: TKEY compatibility problems Kevin Darcy
- Re: RFC 2119 section 6 D. J. Bernstein
- Re: TKEY compatibility problems D. J. Bernstein
- Re: TKEY compatibility problems Kevin Darcy
- Re: TKEY compatibility problems D. J. Bernstein
- Re: TKEY compatibility problems D. J. Bernstein
- Re: TKEY compatibility problems D. J. Bernstein
- Re: TKEY compatibility problems Kevin Darcy
- AXFR extensibility Andreas Gustafsson
- Re: RFC 2119 section 6 Robert Elz