IETF Logo Mail Archive

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

Joe Abley <jabley@strandkip.nl> Tue, 17 June 2025 15:44 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 81BCC3601061 for <dnsop@mail2.ietf.org>; Tue, 17 Jun 2025 08:44:58 -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 REwCKVuxzla6 for <dnsop@mail2.ietf.org>; Tue, 17 Jun 2025 08:44:57 -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 AE055360105C for <dnsop@ietf.org>; Tue, 17 Jun 2025 08:44:57 -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 4bMB5N2Wtnz1GGM for <dnsop@ietf.org>; Tue, 17 Jun 2025 15:44:56 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4bMB5N0RDdz8x for <dnsop@ietf.org>; Tue, 17 Jun 2025 15:44:56 +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=RYvWsbLi; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=soverin1; t=1750175096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=aCXT5/5oavpAJE8+NFeKtOQk+Eqrc18RBhhuBm18u6s=; b=RYvWsbLiC9S5xUjv0uikaZ5sKURJgoN0DAMyIqFxKo/TT5NG91IR7AfEuA9fD5CIFkDjG0 RfLmEFzPaU4AGgwkT/zO8LW9NwhzxuRvW9slmzA82fLClMIDHDULtbyn5CECehQ4wHz6IO SX6GH+h7bdETfNUWB2BAX7Maj6nNFO7tii0hON7GFz6jygvFnmVnBYYOpBvwM0mJVNSXAb 8VpBKo2OADcY6XwFRY8TiFIDyAIERXK0KvjY0A0TK1K9F+/EZ+H5WIFUpc3E5StmxMu++f uKlCePik9TwEUFcBB2/ziQJBuBRYP50X3QMG+q/5BNGwps0zUZOwSSZrK/IHFQ==
X-CM-Envelope: MS4xfGkvPZsA8ppPXBEHWAX1tpRPjlXQz4fyCvAcRPf6flFI55lLUVG8RtO284i736UX65IA14bFKShhHIhvq7CtUI7hRZ4GqakjnKrEm7pdDJJE8MzW1VWz EnzbzUaPIvXWLeS/M9NnTMmEQHuQ0TkLAYg4NvvFCFdaMxPEH0rUXVoxfDRctuiXeQdAqfAd9dFx1kSTChOgqIEMdhCgmGTBc6FP1ctuAGZ4yR7DKOzao1nq UZu+GheRhySjqkva325Ifg==
X-CM-Analysis: v=2.4 cv=I7afRMgg c=1 sm=1 tr=0 ts=68518d78 a=Xe3T0Gaq1rth7aCrjvjMsw==:617 a=tNF5heSCPcKR_L7q:21 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=48vgC7mUAAAA:8 a=oKdGJXzqHsz2PILLIDsA:9 a=CjuIK1q_8ugA:10 a=UEHgTPegLARCV9VKrYbE:22 a=ADiJHLWpjGBBXEl7-v_j:22
From: Joe Abley <jabley@strandkip.nl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Message-Id: <761F6D32-25FE-4742-9682-819A338C8EC9@strandkip.nl>
Date: Tue, 17 Jun 2025 17:44:45 +0200
To: dnsop <dnsop@ietf.org>
X-Spampanel-Class: ham
Message-ID-Hash: UUS5X6B6FPG5GR4CBLMT4VEX24WM2HSY
X-Message-ID-Hash: UUS5X6B6FPG5GR4CBLMT4VEX24WM2HSY
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] 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/IMORyOrKIGVz5dPrVL04SgJf-EU>
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 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>


Joe

v2.35.0 | Report a Bug | By Email | System Status