Return-Path: 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 AB2C3CB73A86; Mon, 16 Mar 2026 10:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=meta.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 1jGmMmsdeedd; Mon, 16 Mar 2026 10:08:46 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 B8EEFCB73A7F; Mon, 16 Mar 2026 10:08:43 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62GF9v9n008093; Mon, 16 Mar 2026 10:08:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=s2048-2025-q2; bh=3L2F++lABuw+i2ZkvlG4 eSQAi1SHwPYNflb7heRQ4zw=; b=i2WERWKgrVFuvzceViZ2ubarnn5pRwbOxLes gk/3G9cP2aWV6BniLClD4lMCMDDjiAJVWlJ+7Nz2A9B0xuHY5m+TVjuhOT0kZEiJ xPeNRIYBfiPFSvlYlgy/t63A3+Mf8n0epKJtdNmYfDNV+7z/7CofopUelKJarJ/L OymSPpfdNTvlq86gqOtej7ZWeoBB+x4UK+U5Aq8R/aP7ii7ugEjE9oDRS/v+u6uw 2OJGi8J6sMvMhK8nGluVMDM5rXcX8roIbLXaZHX5V74XKJBqUXBtQZrOlS6uXxWM G8TIuweFhjYq/R0Vj2rSVGUQyiRbS3osHakVri1zXU0QERotjg== Received: from ph8pr06cu001.outbound.protection.outlook.com (mail-westus3azon11012020.outbound.protection.outlook.com [40.107.209.20]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 4cxeg3f01u-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 16 Mar 2026 10:08:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DoVIapM9rIYuBp8K18IYz2AEUorJR1tQsN6js4lTOFYZoqpDiPAqvge7YWE3fNg0iNdMpeQygYEcSNaBb4aVsimo2WEdwaRYQOeTeWJL6jYOwhrhqlEDUph/DEX9CZtTRZi8s45mIHUCXWoKvc7/+UFBts1C81U6FxUtLcqzsccGwCGrM+jW+bQ0SPdxoqm6WAzZZKrbWj2ANiCEOOLKyIp2MBJg4QBP97wtXFDNlDaknwNdRmy3Bo37LuOx1sFQwn/HHVfeNHWg27IJ+IMRxJsJzPpPQiGEGlMVI5sPLvdTwFAmdz8spIR+mu3R+5Z+ZGAF0xMgfSTerM35PnIXZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BTzhe6oRdlwn0tXf1uCuk3yX5nsZbMsfshk6WN9wRPI=; b=hzK5zr7X1fQHRp8gFR9P98WU/rLqXS0GNl6rPB/HWhGy62tXje4xn3by9XnaleMqT/GOZlW4r7rnvC0ntbMgCkgu5Xv/j13ofo9szrHeZtdLbpIjMJ6lWYBxLPhD8gPz8NuJkBfOtV7ZHQkPAFecHVTzPQP6D7f1ZzxopBvVbyyiNEzLQzI0tzLw1IMnTIX1HsH4mUrcvTaGRUu+xntb/TY1j5BGDDX7O/6N7qreRE48+9Nl06uzTEBIgqECpH9SjlavHwThK0+SHOGjghOH3mmkBiRBwqg5UmK2lJqDk0+ZcInHIoOGH7EdhEko3pPvxExoAZapW3RyjVKRhHmBPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=meta.com; dmarc=pass action=none header.from=meta.com; dkim=pass header.d=meta.com; arc=none Received: from SN6PR15MB2382.namprd15.prod.outlook.com (2603:10b6:805:24::14) by SJ4PPF8013D9261.namprd15.prod.outlook.com (2603:10b6:a0f:fc02::8b0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.4; Mon, 16 Mar 2026 17:08:40 +0000 Received: from SN6PR15MB2382.namprd15.prod.outlook.com ([fe80::ed5b:196f:fa33:b90b]) by SN6PR15MB2382.namprd15.prod.outlook.com ([fe80::ed5b:196f:fa33:b90b%6]) with mapi id 15.20.9723.000; Mon, 16 Mar 2026 17:08:38 +0000 From: Ben Schwartz To: "i-d-announce@ietf.org" , "dnsop@ietf.org" Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-12.txt Thread-Index: AQHcqpLGW9e+GLt1jEOYAFazG1k78LWxWnKI Date: Mon, 16 Mar 2026 17:08:38 +0000 Message-ID: References: <177248995865.3621643.4690295346192711627@dt-datatracker-6ff7c68975-7k42g> In-Reply-To: <177248995865.3621643.4690295346192711627@dt-datatracker-6ff7c68975-7k42g> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SN6PR15MB2382:EE_|SJ4PPF8013D9261:EE_ x-ms-office365-filtering-correlation-id: 7b2453ed-6a15-45a8-3a16-08de837eaa80 x-fb-source: Internal x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|10070799003|4022899009|366016|376014|1800799024|38070700021|13003099007|8096899003|56012099003|18002099003|22082099003; x-microsoft-antispam-message-info: OBmSfc90ODqDLQMieNt1yVpcdP/fLA2IDVsKZukFn6goHSv503x37h5i+0hrVN3Gtc8KKgkmTwjoE+QKvk5UczFkNkbhJOnaSVrhJboWzr+Md453nmcufr1JYWlo/ilh8xc6uWWfNNDuAcYSTfB4tvRFMGQDp/ODRjM6J7llTjD3L3RMCw406Z1zNW9PdH/qpCPev5ILsLw+xb5kdk95DjUGvo2O+Ujb075BrJIVCRw8n9BfQG41/JIFS1d9wVtvGwapF6/WbmW/xH6v8MavS32HfNRYUxN+JcO55H1ATBijUP3UxYAJxsNVUgeAQTVQ5UW9m4Dbn/sFaimkGZqSfW4RHHzM0gyinOgAXspAF4hMuU4IOAB51m/kj4B9JFSXWkGKbmT3krE+zs9Mtyr58CwJ4FZU9uWDq7u38gGLaeyKvMTMYCdPafV4omN82EDB89KNO5W3yTuQT9TYsNU7mMthgFVz/h9owNYHw52vIyf7B+xHfzUlsyewUxMYX+TFHMWqRQXeunnt3kwdyEOheJ38t4bvPnLlxOHqepCF5Wpw7C6U11cqVWvS3ckbLZ+sSbc4+OmpuZpOyEKR9SeVAv+KzjUlTalZcescD+PwtCIuFq6YgU7yLju67RPGgkp4D9IHogCyGlD7vqlIBnGJMORdTR/B5klyMU7XwpqWvfE9jcTLKAN5+aboTHbGd0f2HRbuwQsEw3UlOZpKg2iqaL1Fe8VvC26dZr6x4ZPXOwxWBQx84+KgYalrji4TEu0I/XSR5/DJ/XhhosYP7G+49hhih5Svw7Utt9A3OpnEJN0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN6PR15MB2382.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(4022899009)(366016)(376014)(1800799024)(38070700021)(13003099007)(8096899003)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?dXnodiZU+k+lBoQk9XaL9CTGE78mhrGEnc6jgL7zu47KLWMg6YrjX/pF5pcG?= =?us-ascii?Q?tLAqVX0OJTN7+1wVJiaQ6vagqneLScZ3Mk97rehEKyqRNoI4eVEKriLIXeGk?= =?us-ascii?Q?ewBPII+sTEGFvuV+evVPqi0DLiJVsaIWIZUjwIwcbvR7B/qr/rRRTKKjFXZ9?= =?us-ascii?Q?EN1lX33zkGmTOMXNWNEBJcUjy1zkFPL7zhW4kAebEjmgoozkXomAGB4efJjG?= =?us-ascii?Q?JgtsY0ZqSQGcKWsCVtBJget+9kpLK7u4rpLeyB5v0uvwZP9fnGU67pACcO4O?= =?us-ascii?Q?FoS9d8I9NUUkLeXXGqV4QaO/8R09mM/Go3AmTdanOrHlHmnbXpHHGmmd84+i?= =?us-ascii?Q?L2ty35JJqHkmCgSFP5VrAKsOG7y8oVXT1s2DZ6v1DbFnYkOe+TgsVLknc3Oy?= =?us-ascii?Q?X7AbQl0fyuEJg46JSllDBCgNQDmcTi0+xScABu6me4o6pknfjDy+0M5R2APi?= =?us-ascii?Q?RAEqcMvj9mTKw0OO0Q+UgcQEUdm9+hAFIdsHUUP3zltX/rR9izrCLLs94uHG?= =?us-ascii?Q?AZAhIx676evF/gdGxm/avQw8jrTK9hzRot4YYelw+evniIAAY26/K6v9aMeB?= =?us-ascii?Q?gcNMlP9Hg4sWteeF7wibp58OZo1PxFM9V280Ws7N9SQLxs6NzkCUKez5a8mM?= =?us-ascii?Q?PJMZjj80xZwu9yRBp6JhW0MmfS9R4JhcIhYZDFWpsqDJBv6UPDPYeCT4DFnG?= =?us-ascii?Q?pAYqosTrW4E2zKMxbJK5CRGKfsi6E4pcy2HCfv4OltrMMEu1h1mN0GrkGszQ?= =?us-ascii?Q?0UfME1b5JHC0klL6bFCZCS9HGGhWTZ0ClGE5Xfd9JR441kd+45wnfady7NT/?= =?us-ascii?Q?6dRF9yqvsHqytog9kMgkAjNLX4d9/0g2w7m0nNJ/rh1XZQ8gMbVzQuRZ9GKL?= =?us-ascii?Q?7ZWn6UrfDHvAZ2KLMUYHB265s9RzbdfAN6SzxVs58TFJyLqcEzFGXL04i2gd?= =?us-ascii?Q?Jw075/WNC5qzXr0bS1KneVgLWq6vkzJwx4eFBPRLMfu3iYfkeTVMTqZS1cOW?= =?us-ascii?Q?UPFR2H3GbTyT2v2EI8h+2zLq5+Z9FIlsw84J0clAzRu/qN6vDIKesXnLDSp1?= =?us-ascii?Q?Nm7pOGl6eEnnLEAXMvXGZHP5Wm9LeANHJVw3ALqsBGjbwctDrH2sZgtE0xFl?= =?us-ascii?Q?NcUUbDuNSOj3jwqI9Z9JMvVbLqdr+WXSJJ5oCgKs8RqDR2S1YuwMYLK9EDZd?= =?us-ascii?Q?hjxq2hvpuRADi4cCOnBW/OMNdKnetZ82i+4mdPUl7v2EuVV+Rhhx1eTkbRAu?= =?us-ascii?Q?aEllaQWekHr7IyFRJhyenTkjGvXQ+CGQUDxxLuA7POlq/cRWsdwwhvCkEYJu?= =?us-ascii?Q?nriMY/jJyOR1ihl4418ju+aQQLG/gyYwwx+Cs5vaTSvscIle4qCurPjyfOBp?= =?us-ascii?Q?EgO96oUXxK8ZOQmrpG7+v6bYjO9HZFZOB1r3wn4KAeDGh+2XdpmCkcgUA6rL?= =?us-ascii?Q?7SeKsPmI30OauIdnSsjgMPsHRp+WEyWnUB2aZz+dYkcw9Wpmybw0dquPLwv4?= =?us-ascii?Q?fldEKIyg2Cl+1WyYbcRekXnZ7qUItDTWeyYBjlaXKSRHh21EnKCIkZN1v307?= =?us-ascii?Q?f84iP+Wpu5PIsC6lBe40sXU6TgrcXCplFpednGunP4IilYwItAuA8IhA7ZFK?= =?us-ascii?Q?Gjw61CDQKUK0xsJTLswZVQtb9XTaZZj3wldH7Fsqk/5cfaFBtMOvBIZMevRJ?= =?us-ascii?Q?ZglqDGX07nWmISpBXk0w9izNWfbkohwEVO2O29yY1sJNbZNNQi0+wcBkB1iq?= =?us-ascii?Q?K9fduNAqjO/LIRAj2yoYFrCxS0Dw1Pc/jas3Ix/y9jAXbkN0MjGR?= Content-Type: multipart/alternative; boundary="_000_SN6PR15MB238260B5E3477E2412698C33B340ASN6PR15MB2382namp_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: Ljqf++5HfhFPekDfUkG1PSiREdsDkPndea61OlZDANFtHM7thHNtrVozdl5/gP2BYoTtv3JUWNAyav+i3v1lon+cqkI7ANLjTdZiGq6j/91U3XLaRTY4c412Pfeo9bOCBil4WWB7p/MaMd+zybGryMl3q+dQIxGXJ99ZtT1jG8IQlN76CbGSnRP5OksZxjVQL1DnbDjlG3N57tQTXcxp+1UzZYX3uLb77aRwYNFj/nkb0vCMxzUsm+5Uoryyd2z+xFLt/q6kP2tYSPI5sziZNeLTleYpehGRqAPx0fncujnX/BGEamalWX9v+/MUomwYe0ZIEA0PoYTlvy1PW4I2kg== X-OriginatorOrg: meta.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR15MB2382.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b2453ed-6a15-45a8-3a16-08de837eaa80 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2026 17:08:38.2788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xJ7hK8PWtSLLKBF8GhU1qGCawIf6hRj7ZJA2sXVlyBsndePXNphde7F1iYMtnmWg X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ4PPF8013D9261 X-Proofpoint-GUID: uCCHQ6iiHhTrgj_XCYyYgA-A5Coi-L-k X-Authority-Analysis: v=2.4 cv=GOgF0+NK c=1 sm=1 tr=0 ts=69b8391b cx=c_pps a=0GA36Cgflur6eTh9hrVzog==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=Yq5XynenixoA:10 a=VkNPw1HP01LnGYTKEx00:22 a=7x6HtfJdh03M6CCDgxCd:22 a=xtH7KyWI9dI7BmFOsl-x:22 a=48vgC7mUAAAA:8 a=EZrXN75DOwGzt0QpSO4A:9 a=CjuIK1q_8ugA:10 a=bk4LzNUkyO0lvNFP:21 a=frz4AuCg-hUA:10 a=_W_S_7VecoQA:10 X-Proofpoint-ORIG-GUID: uCCHQ6iiHhTrgj_XCYyYgA-A5Coi-L-k X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzE2MDEzMyBTYWx0ZWRfXz+brszaOP9Tt ZTD8GFYqVhx28Zy0Co3UT1yHY8CV8ttlYrOrKZt9mpFuvWUiXy+A94ZVybEi1bC0tPNNby8MBMC ogH1E8mjO3g3FHgZAQ72lZR0OJWlajJGNVl9L28UvlvXBkJRqIXdMdCPOLj8MOC/B9cudVsBlQd gmlrHDm/KdSiiXdrG68loaUOKxawwEX2U0xh1jlG8ZBD6EPbNDwtKPfmZLQzl7Zb1zGpJOctVT7 HLKKLyfI5uuoEQnFaHLKMx0Z6lWWgJXesbtOk0BQ/RZn44x6tgOfOcLvVnKhDBGqlwOb3RlQ5Op TiuOppfXay93JnqtVilIdOL2hO0qrpdr+Q21+F7ZyAx0dXmsQjzKEDPLJ/6h4CJ2X2ruAt+1GQp z+x8fwQVUSJg3Xt9rUk59dYdHyQAYMgYV/0mJ1v4ijbxBY0xb8x+2wM7YZgyXAuf8ytvbVCWgXt 6YBlESo3VNy1bR/HA5w== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-16_04,2026-03-16_04,2025-10-01_01 Message-ID-Hash: MINXHFGISX3IJF4RFT7W7UTT42QM5ET7 X-Message-ID-Hash: MINXHFGISX3IJF4RFT7W7UTT42QM5ET7 X-MailFrom: prvs=15355bdc25=bemasc@meta.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 X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_I-D_Action=3A_draft-ietf-dnsop-domain-verificati?= =?utf-8?q?on-techniques-12=2Etxt?= List-Id: IETF DNSOP WG mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_SN6PR15MB238260B5E3477E2412698C33B340ASN6PR15MB2382namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review: Section 1: > In practice, DNS-based methods take the form of the Application Service P= rovider generating a Unique Token and asking the requester to create a DNS = record containing this Unique Token and placing it at a location within the= domain that the Application Service Provider can query for. This sentence now seems to be in tension with the existence of draft-ietf-a= cme-dns-persist. Perhaps it could be fixed by adding the word "often" or r= eplacing the word "token". (Also, run-on sentence.) I continue to see major issues with this draft, somewhat related to that se= ntence: 1. While this is certainly a current practice, I don't believe that it is a= very good one. - A point-in-time validation that someone controls the content of a TXT rec= ord is not a logical basis on which to take any persistent action, and most= actions of interest are persistent. - Opaque tokens make the function of each record difficult to determine. I= n practice, this contributes to zone cruft, in which unneeded records are n= ot removed because their purpose is unknown. 2. The draft makes numerous, sometimes conflicting assumptions without clea= rly stating them. - It seems to assume that each domain-associated permission has some kind o= f revalidation timescale that is known to all participants. (Otherwise, ho= w would I know how long I have to wait after acquiring a new domain name be= fore I can be sure that it is safe to use?) - It seems to assume that anyone with the ability to populate a TXT record = on _$SPECIAL.$FOO can also modify any records on $FOO. Sometimes, it also = assumes that this power extends to all other names below $FOO (for wildcard= s), perhaps because of the assumed ability to populate NS records? - It assumes that this party is the "owner", and is authorized to make use = of this domain name outside of the DNS in unspecified other ways. (But it = also assumes that there is a distinction between this "owner" and the "owne= r" of the zone. In general, individual DNS names are not described as havi= ng "owners", and the draft does not define "owner".) - It assumes that anyone who allows a third party to choose names within th= eir zone either (a) has registered in the PSL or (b) prohibits the third pa= rty from choosing underscore-prefixed names. (Zone owners are not currentl= y subject to any normative obligation to comply with either assumption, and= the draft does not add one.) - It assumes that the zone administrator intrinsically knows why the record= is in place, but doesn't intrinsically know how long it is needed. These assumptions may be reasonable, but that doesn't mean they go without = saying. 3. It imagines that the acquirer of a domain might leave records from the p= revious owner in place, even when the purpose of those records is not known= to the new owner ("accidental persistence"). This would be wildly insecur= e for most DNS record types, including ACME dns-persist-01. In my view, in= cluding unauthorized records from someone else amounts to giving them contr= ol of the domain. This problem is exacerbated by the use of opaque tokens. I see real value from this draft for "harm reduction". Right now, many dom= ains are building up absurdly huge TXT RRSets at the zone apex, full of rec= ords that probably could be deleted but no one knows for sure. Moving thes= e to unique underscore domains and adding "expiry" tags is a clear improvem= ent. Including plenty of entropy is probably good too. But in my view, th= is whole practice is built on very fuzzy security aims and unstated assumpt= ions about conventional zone management practices and service account situa= tions. The actual "best practice", in my view, looks like dns-persist-01, CAA, SPF= , or TLSA: a persistent record that clearly authorizes designated parties t= o take particular actions in the name of this domain. DCV is only the "bes= t practice" when the confidentiality loss of exposing these authorization d= etails outweighs the benefits of clarity and auditability. "Ephemeral" DCV= is perhaps justifiable as a form of "proof of work", but it is hard to ima= gine a use case where the "point in time" validation semantic is desired. This draft's version of DCV is certainly a "better practice" than many curr= ent deployments of DCV, and I support publication on that basis. For this = draft, I would like to see: 1. A disclaimer limiting the scope of applicability, distinguishing "anti-a= buse" measures from formal "security" elements. (In ACME, it is the CAA re= cord, not the DNS challenge, that establishes formal security!) 2. A collection of all the draft's assumptions about zone management and ow= nership in one section. (Note that the draft expects that all zones comply= with these assumptions, even zones that are not making use of this specifi= cation!) 3. Exclusion of "accidental persistence" from the threat model, since any s= uch zone is hopelessly compromised anyway. --Ben Schwartz ________________________________ From: internet-drafts@ietf.org Sent: Monday, March 2, 2026 5:19 PM To: i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-technique= s-12.txt Internet-Draft draft-ietf-dnsop-domain-verification-techniques-12.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Domain Control Validation using DNS Authors: Shivan Sahib Shumon Huque Paul Wouters Erik Nygren Tim Wicinski Name: draft-ietf-dnsop-domain-verification-techniques-12.txt Pages: 23 Dates: 2026-03-02 Abstract: Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. The IETF datatracker status page for this Internet-Draft is: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dns= op-domain-verification-techniques/__;!!Bt8RZUm9aw!8p43GN4-R7EjNLCrk-sXFashK= hTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixXyVmjyQA6i3LA$ There is also an HTML version available at: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dnso= p-domain-verification-techniques-12.html__;!!Bt8RZUm9aw!8p43GN4-R7EjNLCrk-s= XFashKhTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixXyVmjy5LqDrIg$ A diff from the previous version is available at: https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=3Ddra= ft-ietf-dnsop-domain-verification-techniques-12__;!!Bt8RZUm9aw!8p43GN4-R7Ej= NLCrk-sXFashKhTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixXyVmjyQD0wTUQ$ Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-leave@ietf.org --_000_SN6PR15MB238260B5E3477E2412698C33B340ASN6PR15MB2382namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Review:

Section 1:

> In practice, DNS-based methods take the form of the Application Servic= e Provider generating a Unique Token and asking the requester to create a D= NS record containing this Unique Token and placing it at a location within = the domain that the Application Service Provider can query for.

This sentence now seems to be in tension with the existence of draft-i= etf-acme-dns-persist.  Perhaps it could be fixed by adding the word &q= uot;often" or replacing the word "token".

(Also, run-on sentence.)

I continue to see major issues with this draft, somewhat related to that se= ntence:

1. While this is certainly a current practice, I don't believe that it is a= very good one.
- A point-in-time validation that someone controls the content of a TXT rec= ord is not a logical basis on which to take any persistent action, and= most actions of interest are persistent.
- Opaque tokens make the function of each record difficult to determine.&nb= sp; In practice, this contributes to zone cruft, in which unneeded records = are not removed because their purpose is unknown.

2. The draft makes numerous, sometimes conflicting assumptions without clea= rly stating them.
- It seems to assume that each domain-associated permission has some kind o= f revalidation timescale that is known to all participants.  (Otherwis= e, how would I know how long I have to wait after acquiring a new domain na= me before I can be sure that it is safe to use?)
- It seems to assume that anyone with the ability to populate a TXT record = on _$SPECIAL.$FOO can also modify any records on $FOO.  Sometimes, it = also assumes that this power extends to all other names below $FOO (for wil= dcards), perhaps because of the assumed ability to populate NS records?
- It assumes that this party is the "owner", and is authorized to= make use of this domain name outside of the DNS in unspecified other ways.=   (But it also assumes that there is a distinction between this "= owner" and the "owner" of the zone.  In general, indivi= dual DNS names are not described as having "owners", and the draft do= es not define "owner".)
- It assumes that anyone who allows a third party to choose names within th= eir zone either (a) has registered in the PSL or (b) prohibits the third pa= rty from choosing underscore-prefixed names.  (Zone owners are not cur= rently subject to any normative obligation to comply with either assumption, and the draft does not add one.)
- It assumes that the zone administrator intrinsically knows why the record= is in place, but doesn't intrinsically know how long it is needed.

These assumptions may be reasonable, but that doesn't mean they go without = saying.

3. It imagines that the acquirer of a domain might leave records from the p= revious owner in place, even when the purpose of those records is not known= to the new owner ("accidental persistence").  This would be= wildly insecure for most DNS record types, including ACME dns-persist-01.  In my view, including unauthorized records from= someone else amounts to giving them control of the domain.  This problem is exacerbated b= y the use of opaque tokens.

I see real value from this draft for "harm reduction". = Right now, many domains are building up absurdly huge TXT RRSets at t= he zone apex, full of records that probably could be deleted but no one kno= ws for sure.  Moving these to unique underscore domains and adding "expiry" tags is a clear improvement.  Including ple= nty of entropy is probably good too.  But in my view, this whole pract= ice is built on very fuzzy security aims and unstated assumptions about con= ventional zone management practices and service account situations.

The actual "best practice", in my view, looks like dns-persist-01= , CAA, SPF, or TLSA: a persistent record that clearly authorizes designated= parties to take particular actions in the name of this domain.  DCV i= s only the "best practice" when the confidentiality loss of exposing these authorization details outweighs the benefits of cla= rity and auditability.  "Ephemeral" DCV is perhaps justifiab= le as a form of "proof of work", but it is hard to imagine a use = case where the "point in time" validation semantic is desired.

This draft's version of DCV is certainly a "better practice" than= many current deployments of DCV, and I support publication on that basis.&= nbsp; For this draft, I would like to see:
1. A disclaimer limiting the scope of applicability, distinguishing "a= nti-abuse" measures from formal "security" elements.  (= In ACME, it is the CAA record, not the DNS challenge, that establishes form= al security!)
2. A collection of all the draft's assumptions about zone management and ow= nership in one section.  (Note that the draft expects that all zones comply with these assumptions, even zones that are no= t making use of this specification!)
3. Exclusion of "accidental persistence" from the threat model, s= ince any such zone is hopelessly compromised anyway.

--Ben Schwartz
From: internet-drafts@ietf.= org <internet-drafts@ietf.org>
Sent: Monday, March 2, 2026 5:19 PM
To: i-d-announce@ietf.org <i-d-announce@ietf.org>
Cc: dnsop@ietf.org <dnsop@ietf.org>
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-te= chniques-12.txt
 


Internet-Draft draft-ietf-dnsop-domain-verification-techniques-12.txt is no= w
available. It is a work item of the Domain Name System Operations (DNSOP) W= G
of the IETF.

   Title:   Domain Control Validation using DNS
   Authors: Shivan Sahib
            Shumon H= uque
            Paul Wou= ters
            Erik Nyg= ren
            Tim Wici= nski
   Name:    draft-ietf-dnsop-domain-verification-t= echniques-12.txt
   Pages:   23
   Dates:   2026-03-02

Abstract:

   Many application services on the Internet need to verify owner= ship or
   control of a domain in the Domain Name System (DNS).  The= general
   term for this process is "Domain Control Validation"= , and can be done
   using a variety of methods such as email, HTTP/HTTPS, or the D= NS
   itself.  This document focuses only on DNS-based methods,= which
   typically involve the Application Service Provider requesting = a DNS
   record with a specific format and content to be visible in the= domain
   to be verified.  There is wide variation in the details o= f these
   methods today.  This document provides some best practice= s to avoid
   known problems.

The IETF datatracker status page for this Internet-Draft is:
= https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dns= op-domain-verification-techniques/__;!!Bt8RZUm9aw!8p43GN4-R7EjNLCrk-sXFashK= hTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixXyVmjyQA6i3LA$

There is also an HTML version available at:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-iet= f-dnsop-domain-verification-techniques-12.html__;!!Bt8RZUm9aw!8p43GN4-R7EjN= LCrk-sXFashKhTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixXyVmjy5LqDrIg$<= /a>

A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddi= ff?url2=3Ddraft-ietf-dnsop-domain-verification-techniques-12__;!!Bt8RZUm9aw= !8p43GN4-R7EjNLCrk-sXFashKhTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixX= yVmjyQD0wTUQ$

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-leave@ietf.org
--_000_SN6PR15MB238260B5E3477E2412698C33B340ASN6PR15MB2382namp_--