[DNSOP] Best Practices for Persistent References in DNS

"Sheth, Swapneel" <ssheth@Verisign.com> Wed, 23 April 2025 15:20 UTC

Return-Path: <ssheth@verisign.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 8E61F201003E for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 08:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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_MED=-2.3, 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=verisign.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 TEj0afvRXTwD for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 08:19:59 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) by mail2.ietf.org (Postfix) with ESMTP id 85E9B2010021 for <dnsop@ietf.org>; Wed, 23 Apr 2025 08:19:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8521; q=dns/txt; s=VRSN; t=1745421599; h=from:to:subject:date:message-id:mime-version; bh=ECzRSQtvLCDX26Hus22u0BsvkAEwDl/mOsutSeWW8Do=; b=pDlJGbk6MagIghwQeUfyY9SbImklvsQ8XEo879i3g2mStfaO/U5VagGi EsXXrcKeSOVS08WSOYEHEw2v+p+jP9v1W2rnwh2DKOj8vyRGa0iPz77tC SBMeEk+cFIOc7wM+ZhtYBIGTB4746Gb1fCOFTgeZwgwVA3umMeyeYp7/s akKSuZy0m75MunWNBf4QHdeFBzvfLY/EUwKxxnU7+RVHNI16Ud8PUEIOe 0h9H/WqkYvRFRZcw66SS8uTMgM59B7CUN/fDKa5AinexhLNSzSGLBJbiJ Tf+g85NZfkPUU7Gt2J2zObVDn7G3i/jOdimYntC1mKQA/79B7CeUvSpQq Q==;
X-CSE-ConnectionGUID: PqxGSEOWS8e1NryXNVcRTQ==
X-CSE-MsgGUID: oe/oZtFkQQSktPmitkCAUw==
X-URL-LookUp-ScanningError: 1
X-ThreatScanner-Verdict: Negative
IronPort-Data: A9a23:n+53c6oZkgztq0fE+qLYT5+bpHJeBmKrZRIvgKrLsJaIsI4StFGz/ xJOGSnaY6zbJjuqJcY2M9718ldF4MGLn5ImCldcGRtFVHdLrMeDHYuCRqubFyjOIsSTEBxqt ptCM9Kbd5lrESWG/Ez3Y+mx8SFwiK2CS+v3VuKcZH0tGVY9F3sq0B5uwLdl0oRh2oTkU1jRt I6aT6H3MUe93z9/O34V7KTEsBBkp6u3ozIXuFUieOpG1LP7vyB94MU3efHrdxMUO7V8HvKmX 7SEi7ay5Xuf8xYiC9ioiKq9eUoPGhQ7l+Gz4ka6IJNO/iV/jiwuzr5pc70EakYSjD6Sh5Z9y dpMvpGqVUEiOaiUtadF2fGQQiFiIbUUv7TOKnWl99eCykTbb3uqyPJrS0QuPoxf9ud4AGpD7 +ATcisNZwqOi/mzwbe2QeAqjd4/dPzWVL/zwUqMsQzkJfY6XYjYEeKN+sBHmjsxicFFEOzCI cEebH1EVC+YyfTkxxRPonuVfI+UagLEn0plRCi9+Oxui1X7zBBtyKO/d53KZcPMScRan02Vv H6A9GP8RQsCPZmCwGLtzp7XvQO4oM+BcN9UTdWF3v52nEWIlCtUFwIJE1e6rviyh1SiHdlYL gsO4iNrsKFq3iSXoqLGs2qFTASs41hFM+dtLtDWyD1h64LYuVzFWDkPE28RN4J47JI6Szchi wWEzornCGA/vOSZFi7EpuafoA3pNHlOJwfuR8OmoSgtuIC//d5p3nojav45TcZZW/WsQWmYL wii9XZ43/NLy5ZWi81XxHif6xq0vJ/FUwUp0QveW2Oh/2tRaZWsD2CSwQGzAc1ocsDAEzFtg FBew5LDtLxUVsnU/MCwaL5l8I+Btq7t3AL03AYH86kJr1yF53OldIZM1zByTG8BGtoEYzLgf HjIsgpX4pJJVFPyBUOgS9vsYyiC5fGI+eXNDpg4XPIXCnRCXFbvEBVVWKKl9zuFfH4EyvhjZ MjBIa5AOl5BYUhv5GLeq+41j+d3lnhmrY/ZbciTIx+PidJyaJMJIFus3ZTngu0Rtcu5TAvpH 9l3D9Ka5C5yd9LFMiSO15QCHXY0JkIHPMWjwyBXXrbrzgtOMlsHUsD37IN5Isp7lKNPjqHB8 jejQFRejlH4gBUrKy3TMjY6N+ipBMsk6y5rVcAvFQ/AN3wLep2v4bsfX4U6Z7g89eNli/VzS pHpfu3cWakSG2iXoVzxa7H6octlRgiFhju3BCm5WD0+Y51LbjHWr4qMkgzHsXNm4jCMncc4u Lq4/gLWXZRFQB5tZPs6c9ql1VXoon4QiLorGlDWOJ9WeV6p+o8sITb317kpOdoKbx7Ew1N2y jqrPPvRnsGVy6ddzTUDrfrsQ1uBewemIndnIg==
IronPort-HdrOrdr: A9a23:q5NKN60ssapUcsKhfTOGAgqjBIskLtp133Aq2lEZdPUMSL36qy ncpoV46faUskd2ZJhOo7G90cW7K080lqQFmLX5X43DYOCOggLBR72KhrGP/9SUIUPDH5lmup uIHZISNDS6NykesS+z2njdLz8P+qjhzJyV
X-Talos-CUID: 9a23:B047/mGC7YiwdnfoqmJf7V47Ie0CTUaNwS72OV6IL1hicoGsHAo=
X-Talos-MUID: 9a23:az5iNA8uubC/Z8yKYdvFaDGQf8BlpKOcFG4OqKw9uNW8MC1sOBy0sSviFw==
X-IronPort-AV: E=Sophos;i="6.15,233,1739836800"; d="p7s'346?scan'346,208,346";a="43559482"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Wed, 23 Apr 2025 11:19:58 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2507.044; Wed, 23 Apr 2025 11:19:58 -0400
From: "Sheth, Swapneel" <ssheth@Verisign.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: Best Practices for Persistent References in DNS
Thread-Index: AQHbtGMsHkkaIc7DDkeHiFcDVYnOvQ==
Date: Wed, 23 Apr 2025 15:19:58 +0000
Message-ID: <4E29922E-A2B0-4FB8-B933-4A8C234DAB01@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3828251998_3276812404"
MIME-Version: 1.0
Message-ID-Hash: 2VL5ITIZEPW7ELPSBHTUDQHXOKD4FWF2
X-Message-ID-Hash: 2VL5ITIZEPW7ELPSBHTUDQHXOKD4FWF2
X-MailFrom: ssheth@verisign.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: [DNSOP] Best Practices for Persistent References in DNS
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pb5YxkXgGscXhGp90tXw7MerfQk>
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>

Greetings DNSOP,
 
We have recently published draft-sheth-identifiers-dns (1) that proposes some best practices for Application Service Providers who provide associations between a global DNS domain name and use case specific references.  The best practices use DNSSEC to provide a globally consistent, cryptographically verifiable association.  While nonce-based domain control validation (DCV) has been used for similar purposes, it may not be practical when the association is persistent and where multiple relying parties want to confirm the association independently as this would require a nonce for each relying party which may become impractical for a user to maintain.
 
Examples of persistent, multiple perspective use cases include the CAA record used by Certificate Authorities, the proposals to use DNS to identify digital wallets, and the use of domain names as social media handles.  In each use case, more than one party uses the same DNS data and should come to the same conclusion, e.g., in CAA if the Certificate Authority is authorized (or not) to issue a certificate for a domain name.
 
This draft differs from the current DCV BCP draft (2) in the persistence of the DNS record(s), the presence of multiple relying parties, and the requirement of DNSSEC.  Our perspective is that these differences are substantive enough to merit separate drafts but are open to further discussion.
 
Thanks,
Swapneel

(1) - https://datatracker.ietf.org/doc/draft-sheth-identifiers-dns/
(2) - https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/