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

Andrew McConachie <andrew@depht.com> Mon, 23 June 2025 09:33 UTC

Return-Path: <andrew@depht.com>
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 7CD173836EEF for <dnsop@mail2.ietf.org>; Mon, 23 Jun 2025 02:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_LOW=-0.7, 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=depht.com
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 Cr8CWILZvnyU for <dnsop@mail2.ietf.org>; Mon, 23 Jun 2025 02:33:37 -0700 (PDT)
Received: from mout-b-110.mailbox.org (mout-b-110.mailbox.org [195.10.208.55]) (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 C33A23836EE8 for <dnsop@ietf.org>; Mon, 23 Jun 2025 02:33:36 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-110.mailbox.org (Postfix) with ESMTPS id 4bQjZ52Lnvz9x59; Mon, 23 Jun 2025 11:33:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=depht.com; s=MBO0001; t=1750671213; 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=VOIgBvPge6e1ov29Fafe8A92BQaWnvuAYV1mhdCsxJ4=; b=ZLkGXepyBH4y4Q4Mb1VuZ15FbQF+5F+iP94GOEoWVw01Kzu5WCx3I1ZgAwqkKuk8whFbGo d+ETSa1g+tPhMArcjrT8zJc7zNagtw3E+Er86ZUVR0miHXae5nBmVQpoQ3s+pn8WZYVpLw MrjVPay7XbAnfRdd0R7ADzjbBCv1aW206G6DzsPfHvyAkVawptKYEDxuWdR8r9epL1hgiN WzWsKzYnuBOXYD4O4o7OBxNj7N4M5SqS54xlm9b2yDa6xGZtvAOQ8CXDv2KctZ98po/jQM iz8/RI2yDHGmOv9Wvq88yLROdqBVtmcx/gDpA9EmPVctwWBEfjuxd+uBMnKdBA==
From: Andrew McConachie <andrew@depht.com>
To: Joe Abley <jabley=40strandkip.nl@dmarc.ietf.org>
Date: Mon, 23 Jun 2025 11:33:16 +0200
Message-ID: <33857674-E1AC-48E7-A4E5-B6953535A86F@depht.com>
In-Reply-To: <761F6D32-25FE-4742-9682-819A338C8EC9@strandkip.nl>
References: <761F6D32-25FE-4742-9682-819A338C8EC9@strandkip.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4bQjZ52Lnvz9x59
Message-ID-Hash: QCOZB7PWUTFFYXCALVVHYZWLERZR3POU
X-Message-ID-Hash: QCOZB7PWUTFFYXCALVVHYZWLERZR3POU
X-MailFrom: andrew@depht.com
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/h4yoOtgkjxBY85Haa6S2D8tC17Y>
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>


On 17 Jun 2025, at 17:44, Joe Abley wrote:

> Hi all,
>
> Warren, Wes and I put our respective heads together in Prague and came 
> up with this:
>
>   https://datatracker.ietf.org/doc/draft-jabley-dnsop-zone-cut-to-nowhere/
>
> This is some general advice for how to delegate a domain to another 
> namespace.
>
> This document proposes a standard mechanism that is potentially 
> applicable, we think, to the .INTERNAL situation that was discussed at 
> some length a while ago (and in a couple of messages today) but also 
> includes other examples of when it could and should not be used.
>
> This document doesn't direct the IANA to do anything, to avoid the 
> policy conversation that implies, but if it achieved consensus it 
> would provide a standard mechanism that IANA could reasonably choose 
> to use.
>
> <clickbait type="wes/science">Wes was still madly typing into a 
> half-closed laptop as I left to board a flight and the document only 
> contains references to his science to follow, not the actual science. 
> If this sounds intriguing, review the document to learn more. 
> </clickbait>
>
> <clickbait type="warren/kittens">There are kittens.</clickbait>
>

I’ve read through the draft as well as the messages on list, but I 
still don’t understand the use case for this draft. Why is creating a 
delegation to nowhere better than doing nothing?

One interpretation of the draft could be that its purpose is to provide 
documentation for human consumption. Is this an intended interpretation? 
Or are zone cuts to nowhere also useful information for machines? If so, 
how SHOULD a resolver on the private side of split-horizon dns behave 
when it encounters a zone cut to nowhere?

Thanks,
Andrew