[DNSOP] Re: on the more general problem of delegating to other namespaces in the DNS

Joe Abley <jabley@strandkip.nl> Tue, 24 June 2025 11:39 UTC

Return-Path: <jabley@strandkip.nl>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id F088438B5307 for <dnsop@mail2.ietf.org>; Tue, 24 Jun 2025 04:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
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 Z4eYkHs6NDLS for <dnsop@mail2.ietf.org>; Tue, 24 Jun 2025 04:39:58 -0700 (PDT)
Received: from dane.soverin.net (dane.soverin.net [185.233.34.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 CB4A338B52F5 for <dnsop@ietf.org>; Tue, 24 Jun 2025 04:39:58 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4bRNKT5bQQz125W; Tue, 24 Jun 2025 11:39:57 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4bRNKT3JWtzKy; Tue, 24 Jun 2025 11:39:57 +0000 (UTC)
Authentication-Results: smtp.soverin.net; dkim=pass (2048-bit key; unprotected) header.d=strandkip.nl header.i=@strandkip.nl header.a=rsa-sha256 header.s=soverin1 header.b=toLn0lDU; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=soverin1; t=1750765197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fGHHjq1WG19hoGdZAMobIMKW0qSd21Zs7tjUfA7SRcM=; b=toLn0lDUoRFVhjfL3n/NSpX7R+iBa/1WLp18Pb89zq5ni1A0pC50kIl57aJ6PHmHmjkXrD FaUWCcP8YdrMVMUAyCJU3zt4ZLpE3Q4X0jkSnVM9g/btlToFBTuY0YJku/alPW8O4c57jp 4YkCJ+dED23eNRBLFdD2yAyI5o5UPqDcvPdj2Gjl3akumazPZDZMOS+CNo9Xd4CPsMIBky 2NvRE6Je2Vglys5qw+3D1idCPNdfryXM7Km1vrQRbqdykFGv7IHMhjt7gdrPB3/g8N2wel uJQG11Qb5cntJdHabbEiPNmv7d7/x3x1VYu+O4tCMDAzmGuqQaGI2T1PdCwPqA==
X-CM-Envelope: MS4xfGg5ic7AzBrOPmijvgR+bzXXaB/SjsV3qJM12XgZC72eHCxxaLROTQNXPRgRHCDPvzLaTAD4Q9CsKOYoDGgh0O3zScobS913mf8CIGwzrNOz8326QCHJ KNJuCDD7OjNl8vEBhgVEZZsDBi+iCWm3ldfekWBBlDVXL7ZcOZwO1s1PbE1XTmdQlS2sYkRkKvZ/GMOr+q9rlalfk/lJetLzrKfsHZftET4SkcbOpp49DpWw oroRqXHK1DQO3bUvmgQG5t7QgrskNbkcaIpm5MQu4/w=
X-CM-Analysis: v=2.4 cv=d/oPyQjE c=1 sm=1 tr=0 ts=685a8e8d a=aIy6+7DDbEjOfFlTtMGZlw==:617 a=tNF5heSCPcKR_L7q:21 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=pafVdeRGAAAA:8 a=dsvDBlWmmUmu3waXRlsA:9 a=QEXdDO2ut3YA:10 a=3hrdv27JUtpGZagksXwW:22 a=ADiJHLWpjGBBXEl7-v_j:22
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
From: Joe Abley <jabley@strandkip.nl>
In-Reply-To: <35BF9B4D-175B-4442-B379-3B4D9D6FDA2F@depht.com>
Date: Tue, 24 Jun 2025 13:39:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C48B1F8A-808C-4EFA-A126-793DCFAD9241@strandkip.nl>
References: <33857674-E1AC-48E7-A4E5-B6953535A86F@depht.com> <D60A06A4-DC62-49A6-9351-BB7EE6323D05@strandkip.nl> <35BF9B4D-175B-4442-B379-3B4D9D6FDA2F@depht.com>
To: Andrew McConachie <andrew@depht.com>
X-Spampanel-Class: ham
Message-ID-Hash: 6P5MS77ICZPOWIEA4U4OEPYBWH2EL32R
X-Message-ID-Hash: 6P5MS77ICZPOWIEA4U4OEPYBWH2EL32R
X-MailFrom: jabley@strandkip.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: on the more general problem of delegating to other namespaces in the DNS
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DMMI-BwrvV60OuWfKSJZUfdv_Qo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Hi Andrew!

On 24 Jun 2025, at 12:20, Andrew McConachie <andrew@depht.com> wrote:

> But a device can also not cache an answer if the name is not present in the parent zone.

Ah, so this is not actually true. A device can cache a negative response from the parent zone, see RFC 2308.

> Adding a zone cut to nowhere doesn’t stop a device from caching some RRSet.

It stops a device from caching the non-existence of a name, because a referral response is a signal that the name exists (unlike a NODATA response or an NXDOMAIN response, with or without DNSSEC).

> Regarding the DNSSEC trust chain, it’s broken with both a zone cut to nowhere and a non-existent name.

In some cases, the point is to break the chain of trust. An insecure delegation to nowhere is thought by some to be useful in the case of .INTERNAL, for example, so that there is no signed proof of non-existence of the INTERNAL domain possible from a root server that might contradict the existence of the INTERNAL domain in a private namespace.

In other cases, the opportunity is to preserve a chain of trust. A secure delegation to nowhere for INTERNAL.COMPANY.EXAMPLE zone might be installed in the global-scope COMPANY.EXAMPLE zone; the DS RRSet installed in public might match the KSKs used to sign the DNSKEY RRSet at the INTERNAL.COMPANY.EXAMPLE zone which is visible in a private network. This might allow devices to be able to get secure responses from internal-network nameservers without needing keys to be distributed through mobile device management systems.

> I guess the point this draft makes is that a signed lame delegation is better than a signed proof of non-existence. Either way the private resolver or private authoritative will have to ‘fake’ some DNSSEC data, because there can never be a ‘real’ signed DS RR in the parent zone.

See above for a real-world example of when such a secure delegation to nowhere might be useful.

> I’m still left with the question of: Why is a (signed/unsigned) lame-delegation better than (signed/unsigned) non-existence?


Because non-existence is a cacheable signal and unreachable is not.


Joe