[DNSOP] Re: Advice sought: DNS record type for FedCM well-known file delegation

John Levine <johnl@ietf.email> Wed, 08 April 2026 19:49 UTC

Return-Path: <johnl@iecc.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 6AD9AD84CBC2 for <dnsop@mail2.ietf.org>; Wed, 8 Apr 2026 12:49:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775677740; bh=pm2eZQlFV36s5aK+ww6z6y+ioN7RLUlVcXbD8d//6cI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=qDbwKHN3os7hOwFqAM6LXHr6aI6u3TPjjlCW1Rkh+fLpuD8W+w+f4RCGFS/462Qnw Dch7H9XWHqRW0VQOlSZopdqJmpvP7iPhysAqtfJzrJ5PHZ4SXToHk+3Zqzq3HxsauM gE4J5KARBJX1ABrZUNA9k67GDevAZ7aVLaMAXbtM=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 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, FROM_FMBLA_NEWDOM28=0.799, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b="Ls8/0Qx6"; dkim=pass (2048-bit key) header.d=ietf.email header.b="PFsansRH"
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 n940yyzxKFPW for <dnsop@mail2.ietf.org>; Wed, 8 Apr 2026 12:49:00 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 589C7D84C0C7 for <dnsop@ietf.org>; Wed, 8 Apr 2026 12:42:40 -0700 (PDT)
Received: (qmail 15787 invoked from network); 8 Apr 2026 19:42:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding:cleverness; s=3da969d6afaa.k2604; t=1775677344; x=1776022944; bh=pm2eZQlFV36s5aK+ww6z6y+ioN7RLUlVcXbD8d//6cI=; b=Ls8/0Qx61x/BjrTiMTV7SZo7txI+2pTZajtayJ1aRC1LhACN5WBmxpa4CQPfQXoinxZq+dNeaOz6lMU4eLOYhSz09DehPpg0tfuO8GTibJPpAsaPcQ1voP297wlMVDQC5b4TLa1FdbuAzv1OdTCX6nb3TFJMTwWjc3ux9PYX/Ni650tBhClH0H3sjYKgMk7mpS3IAwmLqPLGraybRS7t9naPh4CYO18L4cuhrGaKWABnUTDaG48MQauc0fekVQ01kfgxefsejx1OhuQjepqnYfv4Orw3P4DlS0FsEEQb4707EGws8MGAiokeM6nqTdMzhHk+y8lT+3jkj7wlzA8ZDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=ietf.email; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding:cleverness; s=3da969d6afaa.k2604; bh=pm2eZQlFV36s5aK+ww6z6y+ioN7RLUlVcXbD8d//6cI=; b=PFsansRHEsFutoCvZfU+bOPCIflpVO8QkEOqcpMtDKQzniKvBdK+IbqoIR/8BgTOeaBr6a4RpVfB76Th+sNdIm3dmYyxOB8UmYvyi/vL3Qj0CwwR0fwFu2ldsVS009sDKl7ov16IW9lyzhYXrf8TMWvjaG98Th8YTqmnULKS10gD2RByu1d/WOQAniM9EYFDCB4BHTeiEil9n5zqKfWHtoFvEKkAWxPRoZVD6EorNRAMwBDGMpZkc2YSr7MGcwX4dBvMohaHTXFN8iSA01Hq1Qu9wWu20veYqcVVHbLgEWrYo+HguacskXLKKVPjnz3PsNGLHBu9WDro3e10GJ0dlA==
Received: from ary.local ([IPv6:2001:470:1f07:1126:0:78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126:0:78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA CHACHA20-POLY1305 AEAD) via TCP6; 08 Apr 2026 19:42:34 -0000
Received: by ary.local (Postfix, from userid 501) id 903C51017746D; Wed, 8 Apr 2026 15:42:33 -0400 (EDT)
Date: Wed, 08 Apr 2026 15:42:33 -0400
Message-Id: <20260408194233.903C51017746D@ary.local>
From: John Levine <johnl@ietf.email>
To: dnsop@ietf.org
In-Reply-To: <PH0PR00MB287470B5624C4161156CB2E6D35DA@PH0PR00MB2874.namprd00.prod.outlook.com>
Organization: Taughannock Networks
References: <PH0PR00MB287470B5624C4161156CB2E6D35DA@PH0PR00MB2874.namprd00.prod.outlook.com>
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Message-ID-Hash: ORVL2K4Y2MW3XIRZVPWIKW52PZVNVQVA
X-Message-ID-Hash: ORVL2K4Y2MW3XIRZVPWIKW52PZVNVQVA
X-MailFrom: johnl@iecc.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: wibartle@microsoft.com
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Advice sought: DNS record type for FedCM well-known file delegation
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Llj3XM9cg-SPz31r3jE20P5hDtI>
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>

Keeping in mind that I am unpersuaded there is anything for DNSOP to do here.

It appears that Will Bartlett  <wibartle@microsoft.com> said:
>  1.
>Is SVCB appropriate here? We're not doing service binding in the traditional sense (ALPN negotiation, ECH, etc.) — we'd either be
>using TargetName purely for delegation (Option B) or embedding application-layer metadata in custom SvcParams (Option A). Is this a
>reasonable use of SVCB, or a misuse of the record type?

Given that this problem is basically due to the limited capabilities of people running corporate web servers,
it would not be a good idea to assume their DNS department can handle SVCB.

>TXT vs SVCB pragmatics. TXT at an underscore-prefixed name (à la DMARC _dmarc, MTA-STS _mta-sts) is universally supported by
>registrars today. SVCB support is still limited. Given that a goal is broad deployability (including small organizations managing
>DNS through commodity registrars), does the group have a view on whether new protocols should prefer SVCB over TXT for simple
>delegation, or is TXT still the practical choice?

An underscore prefixed TXT record is probably the least bad option here.

>  3.
>Naming convention. Is _web-identity.<domain> an appropriate underscore name? Any conflicts or conventions we should be aware of?
>Should we register in the Underscored and Globally Scoped DNS Node Names registry (RFC 8552)?

It takes five minutes and costs nothing once you have a reference you can point to, so sure.

>  4.
>Embedding data in DNS vs delegation. Option A puts application data (URL paths) directly in DNS records, avoiding an HTTP fetch. Is
>there precedent or guidance for/against this pattern? We're aware of the 65535-byte practical limit on DNS responses, but the data
>here is small (two short paths).

My inclination would be just to put the hostname into the record so you don't have to worry about encoding the funky
characters that might be in a URL.  You need a fixed known prefix on the record contents so lookups don't get confused
by domains that wildcard everything, e.g.

_web-identity.examp1e.com TXT "webident;idp.example.com"

R's,
John

PS:
>  *   Spec: https://fedidcg.github.io/FedCM/

404 when I try to look at it