IETF Logo Mail Archive

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

Joe Abley <jabley@strandkip.nl> Tue, 17 June 2025 16:52 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 EF40B360C80F for <dnsop@mail2.ietf.org>; Tue, 17 Jun 2025 09:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_BLOCKED=0.001, 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 QBCGNDD1FZKM for <dnsop@mail2.ietf.org>; Tue, 17 Jun 2025 09:52:04 -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 3E516360C80A for <dnsop@ietf.org>; Tue, 17 Jun 2025 09:52:03 -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 4bMCZp6rp1z1Ht3; Tue, 17 Jun 2025 16:52:02 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4bMCZp4qVzz8x; Tue, 17 Jun 2025 16:52:02 +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=rhuw5fDL; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=soverin1; t=1750179122; 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=r0pkrK4gndXdu4IzDHcgvQdBlqFqYBA+RZALaojY6z8=; b=rhuw5fDLnMrU6nEN3e4F3zPRomREf83lf/toGqddQVM4+zu1iTOi8p/kCyREik6EsaYSdc uB8W1qz4rg6TsrDgcF5s64mg68DHeI8k75w/XciIXDGw/0lym1b37729WmZVhOCtPzibpZ CekeKOLBAsZ96U7Zbqcf/zNO7qnBAkHC6bSlDDGSBfOYJ8SYS10/BuuqhP3nJP27ERmssl Vznis29NUV4JyyyaflSPrpL+4ZJm5MjyI5jeFf/GXRTxj5HgYJCTc1UtoryPOLa45rv6WE phhyGMaDRCreVLBUVtK24K5aKBuM/6a24jAbwDrKCa4bzDIZeVcjglgmuF11lQ==
X-CM-Analysis: v=2.4 cv=UsCZN/wB c=1 sm=1 tr=0 ts=68519d32 a=Xe3T0Gaq1rth7aCrjvjMsw==:617 a=tNF5heSCPcKR_L7q:21 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=mDhKZzf2AAAA:8 a=YGlwHqqn_Krr_MdMcP8A:9 a=CjuIK1q_8ugA:10 a=CdbHPLkhJ6Q0XNsaeua2:22 a=ADiJHLWpjGBBXEl7-v_j:22
X-CM-Envelope: MS4xfLDxqAHPiuy9F1o5gl/xpfjAH/SwgqZ8GYGFV2Ex40pvvJpPaZcCZb8kRv8CvGllDN4KCf+BZYLz/ONHF74UEOvp6wYzjdewD689FKOONNXUCLXWPPfG k0mZVJ0uvgdq95uOvNiYit8EJGDCQ9MaxwAJpD7TixIMrH5yzmrDY22/W7h+rnooRbw31FZinEv/HI005AEBIJ8GoKi4PO9cBGBaCl4Mywg+IOqyKZ3ciolo XkZECmpRl7oX7Q+WMqObWeVCtpNPzRYhiFro/Wyb1do=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
From: Joe Abley <jabley@strandkip.nl>
In-Reply-To: <86992F96-FC07-4F86-89C8-C6C6183EA484@fugue.com>
Date: Tue, 17 Jun 2025 18:51:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <09B4AA94-A98A-43FC-8CB6-2132296FD915@strandkip.nl>
References: <761F6D32-25FE-4742-9682-819A338C8EC9@strandkip.nl> <86992F96-FC07-4F86-89C8-C6C6183EA484@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Spampanel-Class: ham
Message-ID-Hash: HO34B556MJPIX366RCTJVSRLMU6CBNOB
X-Message-ID-Hash: HO34B556MJPIX366RCTJVSRLMU6CBNOB
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/DaR69zhlmpxdrf_d20cMMiv8-ko>
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 Ted,

On 17 Jun 2025, at 18:45, Ted Lemon <mellon@fugue.com> wrote:

> This looks good.

Glad you like it!

> we'll do some A/AAAA queries to root, but presumably these will be negative cached so it won't be a huge load?

Both certainly seem possible. This is the Wes-science placeholder that I alluded to, earlier. I don't actually know what he has found, yet, since I had to get on a plane.

> If this really is better, then we should consider also updating RFC6303, RFC8375 and RFC9665, and also adding a similar delegation for .local. RFC6762 doesn't address this at all.

As currently written, this would not be applicable to .LOCAL or .ALT or .ONION or anything that acts as an anchor for non-DNS resolution protocols.

The thinking here was that (a) the resolution switch in those examples happens in or very close to the application, so there are other ways for applications to know those names exist and (b) those names really shouldn't exist in the DNS as well as those other name resolution protocols, kind of by definition, and introducing that kind of ambiguity would be a bit of a regression.

Quite possibly we have missed some potential benefit, though.


Joe

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