Re: DNSSEC architecture vs reality

John C Klensin <john-ietf@jck.com> Tue, 13 April 2021 00:43 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D344B3A18E9 for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 17:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJPhrBKccZpJ for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 17:43:03 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749C63A18E6 for <ietf@ietf.org>; Mon, 12 Apr 2021 17:43:03 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lW78u-0005KY-OR; Mon, 12 Apr 2021 20:43:00 -0400
Date: Mon, 12 Apr 2021 20:42:54 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael Thomas <mike@mtcc.com>, Nico Williams <nico@cryptonector.com>
cc: ietf@ietf.org
Subject: Re: DNSSEC architecture vs reality
Message-ID: <5F7F84363A52E9AB79CBF9B2@PSB>
In-Reply-To: <b0a43f25-c4c2-9f3c-1a42-426a6ef6afa0@mtcc.com>
References: <YHN5ObR0eqea8Mrc@straasha.imrryr.org> <CABrd9SRdw9baHD5-j9nz4Zv5JjfL35TgaTvS787orEyGxZdKzA@mail.gmail.com> <YHOAzeOj1JaGdmsO@straasha.imrryr.org> <5e91c054-5935-df07-e8ba-09cc78f6c950@network-heretics.com> <YHPSP8Kij2K4v7qQ@straasha.imrryr.org> <82c5fcc6-b419-6efb-b682-b5dbb32905e2@network-heretics.com> <585D8590-472B-4CBC-8292-5BE85521DD76@gmail.com> <a6545baf-b15e-3690-d7b5-be33c4078e02@mtcc.com> <20210412221435.GV9612@localhost> <0755b70e-cc8e-3404-73cd-51950b3d7e53@mtcc.com> <20210412222748.GW9612@localhost> <b0a43f25-c4c2-9f3c-1a42-426a6ef6afa0@mtcc.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7iRNS-tqmsIIEoPumb57QC5F85E>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2021 00:43:08 -0000


--On Monday, April 12, 2021 15:43 -0700 Michael Thomas
<mike@mtcc.com> wrote:

> The one thing that bugs me about DANE is its use of a native
> RR type. This is a well trodden argument of doing it proper
> and doing it in a deployable way. We know what happens when
> you do it the "right way" which is usually nothing at all. If
> it started to get popular, we could gin up a TXT record
> alternative though, I suppose. When we were doing DKIM at
> Cisco, our IT folks were incredibly accommodating, but
> implementing a new RR type in their infrastructure would have
> probably been a bridge too far. Heck, I wouldn't be surprised
> if Mark at Y! got told the same thing :)

And I don't want to reopen that argument, but part of it is that
the original plan for TXT RR was essentially as a comment field
that anyone could put anything into that they wanted to convey
to another human.  So, if it is used to express protocol
information, figuring out which protocol and whether the data
field is correct for that protocol is basically a matter for
heuristics, no matter how good one can make them.  If there is a
choice, that is not a really good idea.  Also, it has been years
since I was involved in large-scale DNS operations (and, by
today's standards for "large", I never have been),  but it seems
to me that, if a particular implementation or operational setup
makes it as hard to deal with a new RR type as your comment
above suggests, there is something seriously wrong with that
setup.   And I think the language in 1034/1035 is consistent
with that view.

    john