[dd] Re: Security Considerations: NS Weaker Than DELEG

Dave Lawrence <tale@dd.org> Thu, 05 March 2026 23:45 UTC

Return-Path: <tale@dd.org>
X-Original-To: dd@mail2.ietf.org
Delivered-To: dd@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3F4EEC545B2C for <dd@mail2.ietf.org>; Thu, 5 Mar 2026 15:45:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yz1t0LijU-ih for <dd@mail2.ietf.org>; Thu, 5 Mar 2026 15:45:06 -0800 (PST)
Received: from mxg.dd.org (rb-sip2-11.greenmountainaccess.net [69.54.28.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A9AC2C545B27 for <dd@ietf.org>; Thu, 5 Mar 2026 15:45:06 -0800 (PST)
Received: by mxg.dd.org (Postfix, from userid 102) id 8F3572339DE; Thu, 05 Mar 2026 18:45:00 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <27050.5500.559578.89159@gro.dd.org>
Date: Thu, 05 Mar 2026 18:45:00 -0500
From: Dave Lawrence <tale@dd.org>
To: dd@ietf.org
In-Reply-To: <B2DE1BC4-6576-403E-AC2D-1DD85203F14B@strandkip.nl>
References: <20260305.165440.316225281820983390.he@uninett.no> <B2DE1BC4-6576-403E-AC2D-1DD85203F14B@strandkip.nl>
Message-ID-Hash: RDK4H46BVKCWDDGPO33XPBIWS4XH5HTL
X-Message-ID-Hash: RDK4H46BVKCWDDGPO33XPBIWS4XH5HTL
X-MailFrom: tale@dd.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [dd] Re: Security Considerations: NS Weaker Than DELEG
List-Id: DNS Delegation <dd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/SGCkLjZ3eYcDjGCZvTvRyUXgz_E>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Owner: <mailto:dd-owner@ietf.org>
List-Post: <mailto:dd@ietf.org>
List-Subscribe: <mailto:dd-join@ietf.org>
List-Unsubscribe: <mailto:dd-leave@ietf.org>

Joe Abley writes:
> Related, in draft-ietf-deleg-requirements we see:
> 
> S5. DELEG should allow for backward compatibility to the
...

We also see:

  "Soft requirements" are those that are desirable, but the absence of
   which does not intrinsically eliminate a design.  These will largely
   be descriptive of the problems that are trying to be addressed with a
   new method, or features that would ease adoption.

The document also doesn't say anywhere that these features have to be
built into the wire protocol itself.

Under the DELEG protocol as currently described, operators are still
free to have local policy that demands that all zones they operate are
reachable via both DELEG and NS, and can derive that capability from
whatever single source of truth they want to use on the backend.
Authoritative server authors are more than welcome to provide such a
feature as a way to ease adoption.

The existing DNS also doesn't demand that all delegations are useful
to all resolvers.

Zone operators who are serving zones that have DELEG-only delegations
are already indicating that they don't care if the zone is unreachable
by some subset of clients, so the legacy resolver fronting a
DELEG-aware resolver scenario, while interesting, is not a problem
that needs solving.