Network Working Group T. Barrett Internet-Draft C. Schaub Intended status: Standards Track A. Barrett Expires: 21 February 2027 EnCirca, Inc. P. Kowalik DENIC eG 20 August 2026 The Domain Set Discovery Protocol (domain-set) draft-barrett-dnsop-domain-set-00 Abstract Organizations commonly operate under multiple domain names: a primary website, legacy names, defensive registrations, divisional brands, and names in restricted or verified top-level domains. No standard mechanism exists for a domain owner to declare, in a machine-readable and verifiable way, which domains belong to the same organization. This document defines "domain-set", a protocol by which domain operators publish membership in a set of domains using a DNS TXT record as the discovery mechanism. The record either lists the members directly or references an extensible Domain Set Manifest retrieved over HTTPS. Mutual attestation is the validation requirement: a link between two domains is valid only when both domains independently publish records naming each other. Every direction of a link MUST be retrieved over an authenticated channel, by DNSSEC or by the Web PKI. The protocol enables browsers, security tooling, and AI systems to answer the question "are these two domains operated by the same organization?" from first-party, owner-published data rather than inference. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 February 2027. Barrett, et al. Expires 21 February 2027 [Page 1] Internet-Draft domain-set August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Why DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 1.7. Note to Readers (To Be Removed Before Publication) . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. The Domain Set Model . . . . . . . . . . . . . . . . . . . . 8 3.1. Sets and Members . . . . . . . . . . . . . . . . . . . . 8 3.2. Mutual Attestation . . . . . . . . . . . . . . . . . . . 8 3.3. Primary Domain . . . . . . . . . . . . . . . . . . . . . 9 4. Publication and Discovery . . . . . . . . . . . . . . . . . . 9 4.1. DNS TXT Record . . . . . . . . . . . . . . . . . . . . . 9 4.2. Subtree-Scoped Records . . . . . . . . . . . . . . . . . 10 4.3. Domain Set Manifest . . . . . . . . . . . . . . . . . . . 12 4.4. Manifest Hosting and Consistency . . . . . . . . . . . . 13 5. Record Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 16 6.1. Link Validation . . . . . . . . . . . . . . . . . . . . . 17 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 18 6.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Revocation and Change of Control . . . . . . . . . . . . 20 7. Consumer Behavior . . . . . . . . . . . . . . . . . . . . . . 21 8. Relationship to Eligibility Verification . . . . . . . . . . 22 9. Domain-Set Indexes . . . . . . . . . . . . . . . . . . . . . 22 9.1. The Index Role . . . . . . . . . . . . . . . . . . . . . 22 9.2. Submission . . . . . . . . . . . . . . . . . . . . . . . 23 Barrett, et al. Expires 21 February 2027 [Page 2] Internet-Draft domain-set August 2026 9.3. Index Behavior . . . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10.1. Unilateral Insertion . . . . . . . . . . . . . . . . . . 24 10.2. Compromise of One Member . . . . . . . . . . . . . . . . 24 10.3. Dangling Outbound Attestations . . . . . . . . . . . . . 24 10.4. Resource Consumption . . . . . . . . . . . . . . . . . . 25 10.5. Subtree-Scoped Records . . . . . . . . . . . . . . . . . 25 10.6. Homograph and Look-Alike Domains . . . . . . . . . . . . 25 10.7. Manifest Retrieval . . . . . . . . . . . . . . . . . . . 25 10.8. Subdomain Confusion . . . . . . . . . . . . . . . . . . 26 10.9. Submission Endpoint Abuse . . . . . . . . . . . . . . . 26 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12.1. Underscored Node Name . . . . . . . . . . . . . . . . . 26 12.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 27 12.3. Well-Known URI for Index Submission . . . . . . . . . . 27 12.4. Domain Set Relation Types . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Worked Example . . . . . . . . . . . . . . . . . . . 31 Appendix B. Worked Example: Single-Organization TLD . . . . . . 32 Appendix C. Future Extensions (Informative) . . . . . . . . . . 32 C.1. Platform Identifiers . . . . . . . . . . . . . . . . . . 33 C.2. Corroboration Against Authoritative Registers . . . . . . 33 C.3. Delegated and Registry Attestation . . . . . . . . . . . 33 C.4. Assurance Tiering . . . . . . . . . . . . . . . . . . . . 34 C.5. Index Federation and Lifecycle Behavior . . . . . . . . . 34 C.6. Consumption by Automated Agents . . . . . . . . . . . . . 34 C.7. Hierarchical and Transitive Sets . . . . . . . . . . . . 34 C.8. Integrity and Transparency Mechanisms . . . . . . . . . . 35 C.9. Abuse Monitoring and Notification . . . . . . . . . . . . 35 C.10. Privacy-Preserving Membership . . . . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction 1.1. Motivation A financial institution may operate examplebank.com as its primary website, examplebank.bank in a verified namespace, example.org for a charitable foundation, and several defensive registrations. To a human customer, a security analyst, or an AI system asked "is examplebank.com the same institution as examplebank.bank?", the relationship among these names is not discoverable by any standard means. The ambiguity is actively exploited: phishing campaigns depend on users' inability to distinguish a legitimate alternate Barrett, et al. Expires 21 February 2027 [Page 3] Internet-Draft domain-set August 2026 domain from an imposter. Existing mechanisms address adjacent problems but not this one. Certificates bind a key to a name, not names to each other. WHOIS and RDAP [RFC9083] expose registration metadata that is frequently redacted and never designed as an organizational assertion. Proprietary databases infer domain ownership clusters probabilistically. What is missing is a first-party, owner- published, mutually verifiable declaration that lives where domain authority already lives: in the DNS. This document defines such a mechanism, in the spirit of security.txt [RFC9116]: a deliberately minimal convention that a competent operator can deploy in minutes. The consumers of domain-set data are expected to be programmatic: browsers, security tooling, and increasingly autonomous or LLM-based agents evaluating a claimed relationship between two domains, rather than a human reading DNS or manifest records directly. The protocol is designed for machine consumption first; any human-facing explanation of a confirmed link is synthesized by the consuming system from the underlying data, not read off the record itself. The expected publishers of domain-set data are businesses and other organizations that operate more than one resolving domain -- a primary site alongside legacy, defensive, verified-namespace, or divisional names -- rather than individual registrants or investors holding a single domain for its own sake. 1.2. Design Goals * Deployable in one afternoon with no new infrastructure: a TXT record, optionally with a static manifest file. * Resistant to unilateral false claims: validity requires mutual attestation (Section 3.2). * Authenticated in every direction, by DNSSEC or by the Web PKI (Section 6.2); neither mechanism is required of every publisher, since the two are fully equal alternatives. * Consumable by automated crawlers, security tooling, browsers, and AI systems without registration, permission, or fees. * Neutral as to who consumes or aggregates the data. Barrett, et al. Expires 21 February 2027 [Page 4] Internet-Draft domain-set August 2026 * Discoverable without continuous crawling: publication is accompanied by lightweight notification to one or more OPTIONAL indexes (Section 9). 1.3. Non-Goals This protocol asserts common operation of domains. It does NOT assert the lawfulness, eligibility, licensure, or trustworthiness of the operating organization (see Section 8). It does not replace certificates, RDAP, or registry verification processes, and it does not define a trust hierarchy or any central registry. The indexes of Section 9 are optional aggregators, of which any number may exist; no index is canonical. 1.4. Related Work Several existing efforts are adjacent to this protocol; none addresses its problem. Domain control validation. [I-D.ietf-dnsop-domain-verification-techniques] catalogs best practices for proving control of a single domain via DNS records, typically for one-time bootstrap of a service. This document's TXT record placement follows those practices. Domain-set differs in purpose: it is not a one-time proof of control of one domain, but a standing, mutually maintained assertion of relationship between domains. DNS integrations. [I-D.ietf-dnsop-integration] describes considerations for applications that use domain names as identifiers, including lifecycle awareness, control validation, and completeness across TLDs. Domain-set is designed to satisfy that document's considerations, and its split between DNS discovery and HTTPS manifest retrieval mirrors deployed practice described there, such as bidirectional handle verification in the AT Protocol. Provisioning protocols. The Domain Connect protocol [I-D.ietf-dconn-domainconnect] standardizes how service providers and DNS providers cooperate to set DNS records with user consent. It configures records; it does not define their meaning. The two compose: a Domain Connect template for the "_domain-set" record would allow participating DNS providers to offer one-click publication of the records defined here. Related Website Sets. The Related Website Sets mechanism [RWS] (formerly First-Party Sets) allows an organization to declare related websites for browser storage-access and cookie decisions, validated in part through a well-known resource. It demonstrates demand for Barrett, et al. Expires 21 February 2027 [Page 5] Internet-Draft domain-set August 2026 machine-readable organizational grouping of domains, but differs fundamentally in architecture and scope: membership is admitted through a single canonical list maintained by one browser vendor, subject to numeric limits and purpose-bound to browser privacy behavior. Domain-set requires no central list, no admission process, and no designated consumer: any party may publish, and any party may validate, using the DNS and the WebPKI alone. Certificates and registration data. WebPKI certificates bind keys to names, not names to each other; multi-SAN certificates reflect hosting arrangements rather than organizational assertions. RDAP [RFC9083] exposes registration metadata that is frequently redacted and was never designed as an organizational statement. Neither provides an owner-published relationship declaration. Registry-enforced grouping. Work in the REGEXT working group on same-entity sets [I-D.ietf-regext-epp-same-entity] allows a registry to group domains that must be held by a single registrant, generalizing earlier work on internationalized variants. The mechanisms are complementary and operate at different layers: same- entity sets are provisioned through EPP within a single registry, are enforced by the registry rather than asserted by the registrant, and cover names a registry defines as equivalent, while domain sets are published in the DNS, span registries and top-level domains, are asserted by the operators themselves, and cover distinct names an organization chooses to associate. Registry enforcement carries an advantage this protocol cannot reproduce. Where a registry requires the members of a group to transfer and be deleted together, the group cannot be partially divested, and the dangling attestation described in Section 10 cannot arise. Where such a grouping exists and is exposed by a registry, a consumer MAY treat it as corroborating a link asserted under this document. 1.5. Why DNS An HTTPS-only design, in the manner of [RFC9116], was considered and rejected. Domains relevant to this protocol frequently offer no services -- defensive registrations, brand holdings, retired names -- and have no HTTP endpoint. Publication in the DNS reaches them; the Domain Set Manifest of Section 4.3 remains available for publishers who operate HTTPS. Barrett, et al. Expires 21 February 2027 [Page 6] Internet-Draft domain-set August 2026 1.6. Limitations This protocol reaches only domains that are delegated and resolving. A registration that is not delegated cannot publish a record and cannot participate, regardless of who holds it, and a consumer has no DNS-based means of learning that such a registration exists or to whom it relates. Registration data access [RFC9083] is the only avenue for such names, subject to its own availability and redaction limits. Enumeration of an organization's holdings is therefore outside what this protocol can achieve. A domain-set record or manifest is an assertion by a publisher about names it chooses to disclose, and MUST NOT be read as a complete account of the organization's registrations. 1.7. Note to Readers (To Be Removed Before Publication) [RFC Editor: please remove this section before publication.] This revision is an individual submission seeking review and dispatch guidance. Discussion is directed to the dnsop working group mailing list (dnsop@ietf.org). The authors are aware that this document currently specifies three separable pieces: the DNS record and validation model, the manifest format, and the index role (Section 9). They are presented together so that initial review can evaluate the design as a whole. Should the working group adopt this work, the authors intend to restructure it into a slim base specification (record and mutual validation) with the manifest format and the index role as companion documents. Known open issues deferred to the next revision: completion of the ABNF (Section 5.2); registration of a dedicated media type for the manifest; CNAME handling at the "_domain-set" node; NXDOMAIN/NODATA distinctions and TTL guidance in retrieval, including interaction with aggressive negative caching; and optional mechanisms by which counterpart re-attestation can clear the lapse warnings of Section 6.3. Text contributions on any of these are welcome. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Barrett, et al. Expires 21 February 2027 [Page 7] Internet-Draft domain-set August 2026 DNS terminology in this document follows [RFC9499]. Domain Set: A group of registrable domains declared by their operators to be operated by a single organization. Member: A domain that publishes a domain-set record naming other domains in the set. Primary Domain: The member designated by the set as the organization's canonical web presence. Manifest: A JSON document containing the authoritative structured representation of a domain set, referenced from a member's DNS record (Section 4.3). Link: An edge between two members. A link is "asserted" when one member names the other, and "confirmed" when both do. Publisher: The operator of a member domain who places the record. Consumer: Any party (crawler, browser, security tool, AI system, aggregator) that retrieves and validates domain-set records. 3. The Domain Set Model 3.1. Sets and Members A domain set is not registered anywhere and has no identifier other than its membership. It exists implicitly as the transitive closure of confirmed links (Section 6.1). Each member publishes its own record listing the other members it attests to. A member MAY list a subset of the full set; consumers compute the effective set from pairwise confirmed links. 3.2. Mutual Attestation The central rule of this protocol: A link between domain A and domain B is CONFIRMED if and only if A publishes a record naming B, and B publishes a record naming A. Barrett, et al. Expires 21 February 2027 [Page 8] Internet-Draft domain-set August 2026 One-directional claims are ASSERTED only and MUST NOT be treated by consumers as establishing common operation. This rule is what prevents a malicious registrant of examp1ebank.com from inserting itself into a legitimate institution's set: the legitimate members will never publish a reciprocal record. 3.3. Primary Domain Each member SHOULD designate the set's primary domain via the "primary" field. Consumers SHOULD treat disagreement among members about the primary domain as a validation warning (Section 6.1) but not as invalidating confirmed links. 4. Publication and Discovery 4.1. DNS TXT Record The DNS TXT record [RFC1035] is the discovery mechanism of this protocol. A publisher places a TXT record at the underscored node name "_domain-set" directly under the registrable domain. This document deliberately uses a TXT record at an underscored name [RFC8552] rather than a dedicated RRTYPE: such records can be provisioned today through every registrar and DNS-provider interface without software changes, following the deployment path of SPF [RFC7208] and DKIM [RFC6376]. A dedicated RRTYPE MAY be defined in a future revision without changing the data model. The record takes one of two mutually exclusive forms. Inline membership. Small sets MAY list members directly: _domain-set.examplebank.com. IN TXT "v=domainset1; primary=examplebank.com; members=examplebank.bank,example.org,examplebank.net" Manifest reference. Larger or extensible sets MAY instead reference a Domain Set Manifest (Section 4.3) by URI: _domain-set.examplebank.com. IN TXT "v=domainset1; uri=https://examplebank.com/.well-known/domain-set" Exactly one of "members" or "uri" MUST appear in a record. A record containing both, or neither, is malformed and MUST be ignored. The URI form also avoids the practical length constraints of TXT record values for large sets. Barrett, et al. Expires 21 February 2027 [Page 9] Internet-Draft domain-set August 2026 A TXT RDATA divided into multiple character-strings MUST be interpreted as the concatenation of those strings in order, without separators, in the manner of Section 3.3 of [RFC7208]. Examples in this document may wrap a character-string across lines for readability. A publisher MUST NOT place more than one TXT record at the "_domain- set" node. A consumer observing multiple TXT records at that node MUST treat the publisher's record as absent for the purposes of Section 6 and SHOULD record a validation warning; this mirrors the multiple-record failure semantics of [RFC7208] and prevents an injected second record from silently widening a set. This document defines a single flat set per publishing domain. A domain that participates in more than one organizationally distinct relationship -- for example, both a corporate family and an unrelated joint venture -- names all such members within that one set, distinguished only by relation type (Section 5.1) where that applies. Segmenting a domain's membership into separately scoped groups is not defined by this document. The record MUST be published at the registrable domain, not at arbitrary subdomains. Determining the registrable-domain boundary ("public suffix plus one") is itself a known hard problem in the DNS, and no IETF-standard mechanism exists; in current practice consumers determine it using the Public Suffix List [PSL], a community- maintained resource. Consumers MUST apply the same boundary determination consistently to both directions of a link (Section 6.1). Publication at a subdomain MUST be ignored by consumers. A record published at a public suffix itself MUST be ignored unless it conforms to Section 4.2. Where the zone is signed with DNSSEC [RFC4033], the record inherits origin authentication, satisfying the authentication requirement of Section 6.2. 4.2. Subtree-Scoped Records Some top-level domains are operated by and registrable only to a single organization and its affiliates. Single-organization TLDs are common in the current namespace: several hundred exist, and their registry agreements typically restrict registrations to the registry operator and parties it controls. For such a TLD, per- domain publication under Section 4.1 is redundant: every name in the zone belongs to the same organization by construction, and the zone operator is that organization. Barrett, et al. Expires 21 February 2027 [Page 10] Internet-Draft domain-set August 2026 A TLD operator MAY therefore publish a single record at the TLD apex using the "scope" field: _domain-set.example. IN TXT "v=domainset1; scope=subtree; primary=example.com; members=example.com,example.co.uk,example-group.net" A record with "scope=subtree" asserts that every registrable name under that node is a member of the declared set. Consumers encountering such a record: * MUST treat any name of the form