Re: [dd] [Ext] starting charter text for the DELEG BOF discussion

Dave Lawrence <tale@dd.org> Wed, 20 March 2024 08:00 UTC

Return-Path: <tale@dd.org>
X-Original-To: dd@ietfa.amsl.com
Delivered-To: dd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A80DC151992 for <dd@ietfa.amsl.com>; Wed, 20 Mar 2024 01:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDQ28nVaWWAO for <dd@ietfa.amsl.com>; Wed, 20 Mar 2024 01:00:02 -0700 (PDT)
Received: from fluff.twonth.com (fluff.twonth.com [45.79.143.238]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A9FC15109C for <dd@ietf.org>; Wed, 20 Mar 2024 01:00:02 -0700 (PDT)
Received: from gro.dd.org (c-76-23-204-191.hsd1.vt.comcast.net [76.23.204.191]) by fluff.twonth.com (Postfix) with ESMTPS id 45F4F1FCCB for <dd@ietf.org>; Wed, 20 Mar 2024 08:00:01 +0000 (UTC)
Received: by gro.dd.org (Postfix, from userid 102) id E114E1897B0; Wed, 20 Mar 2024 04:00:00 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <26106.38784.897736.471320@gro.dd.org>
Date: Wed, 20 Mar 2024 04:00:00 -0400
From: Dave Lawrence <tale@dd.org>
To: dd@ietf.org
In-Reply-To: <352DA8F3-FAFB-45F7-9C07-6CBB0143240D@gmail.com>
References: <yblbk7wl65k.fsf@wx.hardakers.net> <D3E1CFCD-D078-42AB-9049-08BE5D7968FF@icann.org> <20240319.192031.779472543197418519.he@uninett.no> <26106.33066.79339.949428@gro.dd.org> <CAKr6gn2MksS4rcWUeO8ey+edcic6PqpreFOfRoEDsAOi98N3WQ@mail.gmail.com> <352DA8F3-FAFB-45F7-9C07-6CBB0143240D@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/VgpYGpl7HG5pOOz95dKdeUuh7eM>
Subject: Re: [dd] [Ext] starting charter text for the DELEG BOF discussion
X-BeenThere: dd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Delegation <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>, <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>, <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 08:00:04 -0000

Geoff Huston writes:
> I'm curious - why should a DELEG-like delegation referral point to
> precisely the same nameserver names as NS records? (if that is what
> you are saying here) What consideration motivates such a constraint? 

One of the open issues for the DELEG RR folks is what to say about
using NS records if you understand DELEG.  

One possibility is recommending "do not fall back to NS" in the
presence of a signed delegation.  I'm not making any assertions about
which way I think it should be, just observing one reason it might be
desirable.

Imagine:

example.com NS ns1.example.net
example.com DELEG 1 ns1.example.net alpn=do53
example.com DELEG 1 ns1.example.net alpn=dot
example.com DELEG 1 ns1.example.net alpn=doq
example.com RRSIG DELEG ...

Now if a DELEG-aware hardened resolver didn't talk dot or doq, and
also didn't want to fall back to unsigned NS, it would want that do53
record even though it is essentially what's in the NS.