The Domain Set Discovery Protocol (domain-set)
draft-barrett-dnsop-domain-set-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Thomas Barrett , Chris Schaub , Andrew Barrett , Paweł Kowalik | ||
| Last updated | 2026-08-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-barrett-dnsop-domain-set-00
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 <label>.<tld> as a member of the
set, without requiring a per-domain record at that name.
* MUST still apply the mutual attestation rule of Section 3.2 to
each named member outside the TLD: a link between the TLD and
example.com is CONFIRMED only if example.com reciprocates.
* MUST reject a "scope=subtree" record published at a name that is
not a top-level domain.
A reciprocating member identifies the TLD by its bare label:
_domain-set.example.com. IN TXT
"v=domainset1; primary=example.com;
members=example,example.co.uk"
Consumers MUST accept a bare TLD label as a valid member identifier
when, and only when, the referenced TLD publishes a conforming
"scope=subtree" record.
Publishing a "scope=subtree" record does not imply any evaluation of
the operator's eligibility to operate that TLD (Section 8). This
protocol does not validate whether a TLD in fact restricts
registration to its operator; consumers MAY use independent knowledge
of that fact, in the same manner they rely on the Public Suffix List
(Section 4.1).
A "scope=subtree" record MUST NOT be published for a TLD that accepts
registrations from unaffiliated third parties. Consumers
encountering a "scope=subtree" record at a TLD known to be open or
shared SHOULD record a validation warning and SHOULD NOT expand the
set.
This mechanism is named for the general case of a subtree controlled
by a single operator, not for top-level domains specifically, but
conforming use is restricted to top-level domains: a TLD's registry
agreement is currently the only point in the namespace where a
Barrett, et al. Expires 21 February 2027 [Page 11]
Internet-Draft domain-set August 2026
consumer can generally confirm single-operator control from outside
the DNS. A future revision MAY extend "scope=subtree" to other node
classes once a comparable means of confirming that precondition
exists.
4.3. Domain Set Manifest
A Domain Set Manifest is a JSON [RFC8259] document containing the
authoritative structured representation of a domain set. When a
record references a manifest via the "uri" field, the manifest
supplies the set's membership and primary designation; the DNS
record's role is discovery and authorization of the manifest
location.
The manifest MUST be retrieved over HTTPS. Media type: application/
json. Example:
{
"version": "domainset1",
"primary": "examplebank.com",
"members": [
"examplebank.com",
"examplebank.bank",
"example.org",
{"domain": "examplebank.net", "rel": "defensive"}
],
"entity": {},
"verified": "2026-08-05T00:00:00Z"
}
The RECOMMENDED manifest location is the well-known path (registered
in Section 12.2):
https://<domain>/.well-known/domain-set
The path deliberately omits a ".json" suffix so that future revisions
can employ HTTP content negotiation without changing the discovery
URI. Publishers MAY use any HTTPS URI; the well-known path is a
convention, not a requirement, since the authorizing pointer is the
DNS record itself (Section 4.4).
A manifest contains the following members:
version REQUIRED. "domainset1".
members REQUIRED. Array of member domains, with the semantics
Barrett, et al. Expires 21 February 2027 [Page 12]
Internet-Draft domain-set August 2026
of the "members" field of Section 5.1, except that the
manifest's members array SHOULD include every member of the
set, including domains whose records reference this
manifest. Each array entry is either a plain domain
string, or an object of the form {"domain": <domain>,
"rel": <rel-value>} carrying the relation type of
Section 5.1 for that member. Consumers MUST accept both
forms; a plain string entry carries no relation type and
MUST be treated as "operating" for validation purposes, per
Section 5.1.
primary OPTIONAL. As in Section 5.1. A manifest MUST identify
at most one primary domain.
verified OPTIONAL. As in Section 5.1.
entity OPTIONAL. An open extension point. The "entity"
object MAY contain arbitrary issuer-defined metadata
describing the organization, project, service, person,
namespace, or other entity associated with the domain set:
display names, descriptions, web sites, contact
information, public identifiers, logos, trust statements,
verification evidence, or links to external resources.
This document defines no members of the "entity" object and
does not constrain its contents. Consumers MUST ignore
unknown members of the "entity" object. Entity metadata
MUST NOT affect the validation procedure of Section 6.
Unknown top-level manifest members MUST be ignored to permit
extension.
4.4. Manifest Hosting and Consistency
A manifest MAY be hosted by the primary domain, by any member of the
set, or by an independent third-party service. Authority is
established by publication of the corresponding "_domain-set" TXT
record(s), not by the hostname serving the manifest: the DNS record
authorizes the manifest location, and HTTPS authenticates its
retrieval (Section 10).
Hosting location does, however, determine whether the link can be
authenticated at all. When the referencing record is retrieved from
an unsigned zone, the "uri" pointer itself is unauthenticated, and a
certificate valid for a third-party host authenticates only that
host, not the publisher. A manifest therefore satisfies the
authentication requirement of Section 6.2 only when the referencing
Barrett, et al. Expires 21 February 2027 [Page 13]
Internet-Draft domain-set August 2026
record was DNSSEC-validated or the manifest is hosted at the
publishing member's own registrable domain. Publishers who have not
signed their zone MUST host the manifest at their own domain for that
direction of a link to be CONFIRMED.
Multiple participating domains MAY reference the same manifest URI.
Consumers MAY treat shared manifest references as a consistency
signal, but the mutual-attestation rule of Section 3.2 remains the
sole basis for confirming links: a shared manifest does not
substitute for each member's own DNS record.
A consumer that retrieves a manifest MUST verify that the queried
domain appears in the manifest's "members" array; a manifest that
omits the domain whose record referenced it is inconsistent, and the
record MUST be treated as absent.
5. Record Syntax
5.1. Fields
v REQUIRED. Version tag. This document defines "domainset1".
Records with unrecognized versions MUST be ignored.
members CONDITIONAL. Comma-separated list of registrable
domains (A-labels for IDNs) that this publisher attests
are operated by the same organization. The publishing
domain itself MUST NOT appear in its own members list.
Exactly one of "members" or "uri" MUST appear.
uri CONDITIONAL. An HTTPS URI [RFC3986] referencing the
set's Domain Set Manifest (Section 4.3), from which
consumers obtain the membership. Exactly one of
"members" or "uri" MUST appear.
primary OPTIONAL. A single registrable domain designated as
the set's canonical presence. MAY be the publishing
domain itself.
scope OPTIONAL. Declares the breadth of the record. The
only value defined by this document is "subtree", valid
only in records published at a top-level domain, with
the semantics of Section 4.2. Absent this field, a
record speaks only for the publishing domain.
rel OPTIONAL. Characterizes the role of the publishing
Barrett, et al. Expires 21 February 2027 [Page 14]
Internet-Draft domain-set August 2026
domain within the set, as the publisher uses it. Values
are recorded in the "Domain Set Relation Types" registry
(Section 12.4). This document registers the following
initial values:
primary the set's canonical public presence
operating actively serves content or services
redirect resolves and redirects to another member
defensive held to prevent third-party registration;
not in active use
reserved held for future or internal use
Values not found in the registry MUST be treated as
"operating" for validation purposes and surfaced
unchanged to consumers; implementations validate against
this rule, not the registry's contents. A relation type
describes the publisher's use of a name, not an
assessment of it (Section 8).
verified OPTIONAL. Timestamp [RFC3339] recording when the
publisher last reviewed and confirmed the domain set.
This is a freshness indicator, not an expiration date.
See Section 6.3.
contact OPTIONAL. A URI (typically "mailto:" or "https:")
identifying an operational point of contact for the
publisher's domain-set records, in the manner of the SOA
RNAME field and the Contact field of [RFC9116].
Publishers SHOULD use role-based rather than personal
addresses (Section 11).
Unknown fields MUST be ignored to permit extension.
5.2. ABNF
Formal syntax in ABNF [RFC5234] (informative in this revision; to be
completed):
Barrett, et al. Expires 21 February 2027 [Page 15]
Internet-Draft domain-set August 2026
record = "v=domainset1" *( ";" [FWS] field )
field = members-f / uri-f / primary-f / scope-f /
rel-f / verified-f / contact-f / ext-f
; exactly one of members-f / uri-f per record
members-f = "members=" member *( "," member )
member = domain / tld-label
uri-f = "uri=" https-URI ; [RFC3986]
primary-f = "primary=" domain
scope-f = "scope=" "subtree"
rel-f = "rel=" rel-value
rel-value = 1*32(ALPHA / DIGIT / "-")
; registered values: Section 12.4
verified-f = "verified=" date-time ; [RFC3339]
contact-f = "contact=" URI ; [RFC3986]
ext-f = ext-name "=" ext-value
5.3. Examples
Minimal record (member of a two-domain set):
_domain-set.examplebank.bank. IN TXT
"v=domainset1; primary=examplebank.com;
members=examplebank.com"
Subtree-scoped record (single-organization TLD):
_domain-set.example. IN TXT
"v=domainset1; scope=subtree; primary=example.com;
members=example.com,example.co.uk"
Record referencing a manifest:
_domain-set.example.org. IN TXT
"v=domainset1;
uri=https://example.org/.well-known/domain-set"
Record with a verified timestamp:
_domain-set.example.org. IN TXT
"v=domainset1; primary=examplebank.com;
members=examplebank.com,examplebank.bank;
verified=2026-08-05T00:00:00Z"
6. Validation Procedure
Barrett, et al. Expires 21 February 2027 [Page 16]
Internet-Draft domain-set August 2026
6.1. Link Validation
For every comparison of domain names in this document, names MUST
first be canonicalized: converted to lowercase, represented as
A-labels, and stripped of any trailing root separator ("."). Both
directions of a link MUST be evaluated using the same registrable-
domain boundary determination (Section 4.1).
To validate a claimed link between A and B, a consumer:
1. Retrieves A's domain-set record (Section 4). If the record
contains a "uri" field, retrieves the referenced manifest
(Section 4.3), verifies that A appears in the manifest's members
array, and obtains A's membership from the manifest; otherwise
obtains it from the inline "members" field. Confirms B appears
in that membership.
2. Performs the same procedure for B's record and confirms A appears
in B's membership.
3. If both succeed and both directions satisfy the authentication
requirement of Section 6.2, the link A<->B is CONFIRMED. If only
one direction exists, or authentication fails in either
direction, the link is ASSERTED (where mutuality nonetheless
holds) and MUST NOT be presented as establishing common
operation.
A record whose referenced manifest cannot be retrieved, is malformed,
or omits the referencing domain MUST be treated as absent for the
purposes of this procedure.
Where A is a name under a TLD publishing a conforming "scope=subtree"
record (Section 4.2), step 1 is satisfied by that apex record; step 2
is unchanged, and the bare TLD label is the identifier B must name.
The effective domain set containing A is the transitive closure of
confirmed links reachable from A. Closure computation MUST employ
cycle detection, visiting each member at most once, and consumers
MUST bound the resources spent per validation: this document
RECOMMENDS a default limit of 64 members per closure and 10
retrievals (DNS lookups plus manifest fetches) per link. A closure
truncated at a limit is reported as truncated, with a validation
warning; truncation does not invalidate the links already confirmed.
Consumers SHOULD record validation warnings for: disagreement on the
primary domain, asserted-only links, aged "verified" timestamps
within the closure (Section 6.3), and manifest inconsistencies
(Section 4.4).
Barrett, et al. Expires 21 February 2027 [Page 17]
Internet-Draft domain-set August 2026
6.2. Authentication
Every direction of a link MUST be retrieved over an authenticated
channel. A record satisfies this when retrieved from a DNSSEC-signed
zone with a validated chain of trust [RFC4033], or when the
referenced manifest is retrieved over HTTPS with a certificate valid
for the publishing domain and hosted at the publishing member's own
registrable domain (or a subdomain of it). A manifest hosted
elsewhere authenticates only its own host, not the publisher: if the
record naming it was not itself DNSSEC-validated, that direction does
not meet this requirement regardless of the manifest's certificate.
The two mechanisms MAY be mixed across the two directions of a link.
A record retrieved from an unsigned zone over unauthenticated DNS, or
a manifest that fails the authentication test above, MUST NOT
establish a CONFIRMED link. Consumers MAY retain such a record as an
unauthenticated observation for diagnostic purposes and MUST NOT
present it as establishing common operation.
DNSSEC signatures are independently verifiable by any party; HTTPS
establishes trust only for the party that performed the retrieval. A
consumer republishing a link established through a manifest MUST NOT
represent it as independently verifiable. Publishers for whom
downstream verification matters SHOULD sign their zones. This
document does not require every publisher to deploy DNSSEC; the HTTPS
path is a fully equal alternative.
This requirement excludes a domain with an unsigned zone that
publishes inline "members" without a manifest hosted at its own
domain: such a domain cannot reach CONFIRMED status. This targets
the dangling-attestation risk discussed in Section 10.3.
Authentication is independent of the ASSERTED/CONFIRMED mutuality
test of Section 3.2: CONFIRMED requires both mutuality and
authentication, in both directions.
6.3. Freshness
Mutual attestations rot: organizations divest brands, let defensive
names lapse, and forget records. Therefore:
Barrett, et al. Expires 21 February 2027 [Page 18]
Internet-Draft domain-set August 2026
* Publishers SHOULD include a "verified" timestamp recording when
they last reviewed and confirmed the set, and SHOULD refresh it at
least annually and upon any change-of-control event of
Section 6.4. The annual cadence is a floor, chosen to coincide
with the registration renewal cycle, when membership changes are
most likely to occur; operators of high-value sets MAY adopt a
shorter cadence.
* The "verified" timestamp is a freshness indicator, not an
expiration date. Consumers MAY use its age as an input to
confidence or presentation decisions, and MAY surface an aged
timestamp as a validation warning, but MUST NOT invalidate an
otherwise valid domain set solely because its "verified" timestamp
is old or absent. The timestamp is self-asserted and
unverifiable: any party controlling the record can refresh it
without performing a review. It MUST NOT be an input to the link
validation of Section 6.1, whose security rests on mutual
attestation alone.
* Consumers SHOULD re-validate confirmed links at least every 30
days and MUST NOT serve cached confirmations older than 90 days
without revalidation.
* A domain whose registration has lapsed and been re-registered may
retain stale inbound attestations from former set members. The
mutual-attestation rule limits the damage (the new registrant
cannot force reciprocation from members it does not control).
Consumers with access to registration data SHOULD consume change-
of-control signals as follows, in decreasing order of strength:
1. Creation date. A change in the domain's creation date, as
reported in registration data (the RDAP "registration" event),
means the prior registry object was deleted and the name re-
registered. Renewal and restoration never alter the creation
date, so this signal cannot misfire on a late renewal.
Consumers SHOULD invalidate cached links involving the domain
and revalidate from live records.
Barrett, et al. Expires 21 February 2027 [Page 19]
Internet-Draft domain-set August 2026
2. Lapse indicators. Registry grace statuses observed on a
member (auto-renew period, redemption period, pending restore
[RFC3915]), or an expiration event earlier than the
observation time, indicate that the registration lapsed before
renewal. Control may have changed without deletion: expiry-
stream auctions convey lapsed names to new operators by
renewal, preserving the creation date, so this is the only
registration-data trace of that acquisition path. Because
late renewal by the same operator is also common, consumers
SHOULD record this as a validation warning and SHOULD trigger
prompt revalidation, rather than invalidating automatically.
3. Transfer indicators. A registration-data transfer event or a
change of sponsoring registrar SHOULD likewise be recorded as
a validation warning.
A change of control that surfaces no registration-data signal at
all -- for example, a sale effected within a single registrar
without lapse -- is not detectable by consumers; the publisher
duties of Section 6.4 are the control for that case.
Publishers SHOULD additionally notify an index (Section 9.2) when a
record is first published and whenever its membership materially
changes.
6.4. Revocation and Change of Control
Removal of a record is revocation. A publisher withdraws its
attestations by deleting its "_domain-set" record (or, for a single
member, by removing that member from its membership). A consumer
that observes, on revalidation, that a previously retrieved record is
absent or no longer names a counterpart MUST cease treating the
affected links as CONFIRMED. There is no grace period for
presentation: a revoked link MAY be retained internally as history,
but MUST NOT be presented as a current confirmed link. The
revalidation limits of Section 6.3 bound how long a revocation can
remain unobserved; publishers wanting prompt effect SHOULD resubmit
the affected domains to indexes (Section 9.2), which triggers
immediate revalidation.
Attestations are made by the party operating a domain, and do not
survive that party. When control of a member changes -- through
sale, transfer, divestiture, or lapse and re-registration -- the
prior operator's outbound attestations and the counterparts' inbound
attestations both refer to an organization that no longer operates
the name. Therefore:
Barrett, et al. Expires 21 February 2027 [Page 20]
Internet-Draft domain-set August 2026
* A publisher MUST promptly remove from its membership any domain it
has divested or allowed to lapse; a stale entry is a standing
offer of confirmation to the name's next operator (Section 10).
* A publisher transferring a domain away SHOULD delete its "_domain-
set" record before or at transfer, and remove the departing domain
from the records of remaining members.
* A publisher acquiring a domain SHOULD review and remove or reissue
any inherited "_domain-set" record before relying on it, and
SHOULD refresh the "verified" timestamp only after that review.
* Consumers with access to registration data SHOULD apply the graded
change-of-control signals of Section 6.3: invalidation on a
creation-date change, and validation warnings on lapse or transfer
indicators.
Counterpart members cannot observe a transfer directly; their
protection is the annual review cadence of Section 6.3 and the stale-
attestation guidance of Section 10.
7. Consumer Behavior
Consumers presenting domain-set data to end users or downstream
systems:
* MUST distinguish confirmed links from asserted claims.
* SHOULD present whether a link satisfies the authentication
requirement of Section 6.2 where the consuming context involves
security decisions.
* MUST NOT present set membership as implying eligibility,
licensure, endorsement, safety, or reputation (Section 8).
* MUST NOT represent a confirmed link, or a relation type
(Section 5.1), as a trust, safety, or reputation signal, whether
to end users or to downstream automated consumers.
* SHOULD attribute the data as published by the domain operators
themselves, i.e., first-party assertion, not third-party
verification.
Barrett, et al. Expires 21 February 2027 [Page 21]
Internet-Draft domain-set August 2026
8. Relationship to Eligibility Verification
Some top-level domains impose eligibility verification at
registration: examples include charter verification, professional
licensure, or accreditation screening. A domain-set record makes no
claim about any such verification. The protocol answers "operated by
the same organization?" -- it cannot answer "is that organization a
licensed bank?"
The two layers compose naturally: a consumer may combine a confirmed
link between a verified-namespace domain and a legacy domain with
knowledge of the namespace's registration policy to conclude that the
legacy domain is operated by an organization that passed the
namespace's verification. Registries, registrars, and third-party
indexes MAY provide that policy layer; this protocol deliberately
does not.
A consumer MUST NOT conclude from a confirmed link that the linked
domain is safe, that content served there is authorized, or that the
organization is trustworthy -- only that it satisfied the namespace's
registration policy at the time of registration. Consumers that
summarize this data for downstream systems, including natural-
language generators, SHOULD carry that scoping forward rather than
collapsing a link into a single confidence measure.
9. Domain-Set Indexes
Domain-set records are self-published and validated pairwise; nothing
in this protocol requires an aggregator. In practice, many consumers
will prefer to query an index rather than perform live DNS retrieval
and closure computation. This section defines an OPTIONAL index role
so that discovery can be event-driven rather than dependent on
continuous crawling of the namespace.
9.1. The Index Role
A domain-set index is any party that accepts submissions of domain
names, retrieves and validates the corresponding records under
Sections 4 through 6, and republishes the results. The role is
deliberately generic: any number of indexes may operate concurrently,
none is canonical, and this document establishes no admission,
accreditation, or coordination among them. The design follows the
precedent of Certificate Transparency logs [RFC9162]: the
specification defines the role, and operation is open to any party.
Barrett, et al. Expires 21 February 2027 [Page 22]
Internet-Draft domain-set August 2026
An index is a consumer in the sense of Section 7 and is subject to
all requirements of that section, in particular the distinction
between confirmed and asserted links and the prohibition on
presenting membership as eligibility or endorsement.
9.2. Submission
An index accepting submissions exposes an endpoint at:
https://<index>/.well-known/domain-set-submit
A submission is an HTTP POST whose body is a JSON object with a
single member:
{ "domain": "examplebank.com" }
The submitted value names one registrable domain (or, for subtree-
scoped records, one TLD label). The submission deliberately carries
no other data: no set membership, no contact information, and no
registration or authentication requirement. The submission is a
pointer, not an assertion; the authoritative description of the set
is whatever the named domain itself publishes under Section 4.
Submissions naming domains the submitter does not operate are
permitted; the mutual-attestation rule of Section 3.2 makes third-
party submission harmless.
Publishers SHOULD submit their domain to at least one index when a
record is first published and whenever its membership materially
changes. Because a record participates in discovery only after an
index learns of it, the incentive to submit rests with the publisher;
indexes are not expected to crawl for unsubmitted records, though
they MAY discover records by any other means.
9.3. Index Behavior
On receiving a submission, an index:
1. Retrieves the named domain's record (Section 4). If none exists,
the submission is discarded.
2. Validates links to listed members under Section 6, retrieving
each member's record to test reciprocation.
3. Records the outcome (confirmed, asserted, warnings,
authentication status) together with a retrieval timestamp.
Indexes MUST expose the retrieval timestamp alongside any republished
result, SHOULD expose the record's "verified" timestamp where
present, and are bound by the revalidation limits of Section 6.3 for
Barrett, et al. Expires 21 February 2027 [Page 23]
Internet-Draft domain-set August 2026
any result they continue to serve. A record that has changed in the
DNS but has not been resubmitted may be served stale within those
limits; the notification duty of Section 9.2 places responsibility
for promptness on the publisher.
Submissions naming different members of the same set MUST be treated
idempotently: they update the same computed set rather than creating
duplicates.
10. Security Considerations
10.1. Unilateral Insertion
The primary abuse case is a hostile domain claiming membership in a
victim's set. Mutual attestation (Section 3.2) is the structural
defense: the claim remains ASSERTED and MUST NOT be surfaced as
common operation. Consumer implementations that skip the reciprocity
check reintroduce the entire vulnerability; Section 7's requirements
are therefore normative, not advisory.
10.2. Compromise of One Member
An attacker controlling one member's DNS (or web server, for the
well-known mechanism) can add reciprocal records linking the victim
set to attacker domains. Mitigations: the revalidation cadence of
Section 6.3 bounds the exposure window; publishers SHOULD monitor
their own records; DNSSEC signing raises the cost of off-path
attacks; and consumers SHOULD treat sudden set-membership growth as
anomalous.
10.3. Dangling Outbound Attestations
A stale entry in a "members" list is not merely clutter; it is a
standing offer of confirmation. If a member domain lapses and is re-
registered by an attacker while other members still name it, the
attacker controls the reciprocating side: publishing a record naming
the remaining members yields links that are CONFIRMED under
Section 3.2, attaching an attacker-operated domain to a legitimate
set. This is the protocol's most consequential maintenance failure,
and it is created entirely by the victim's own stale data.
Mitigations: the prompt-removal requirement of Section 6.4 is the
primary control; the annual "verified" review of Section 6.3 exists
chiefly to catch this case; consumers SHOULD treat a creation-date
change on a member as invalidating cached links, SHOULD treat lapse
indicators as a warning (an expiry-stream auction conveys control of
a lapsed name without altering its creation date), and SHOULD weight
recently re-registered or recently lapsed members with suspicion even
when links validate; and indexes SHOULD flag confirmed links in which
Barrett, et al. Expires 21 February 2027 [Page 24]
Internet-Draft domain-set August 2026
one side's zone or registration is materially newer than the
counterpart's attestation.
10.4. Resource Consumption
Validation is recursive by nature: records reference manifests, and
closures traverse members that each require further retrievals.
Maliciously constructed sets (long member chains, mutually
referencing records, oversized manifests) could otherwise draw a
naive consumer into unbounded work, in the manner of the processing-
limit failures that motivated the lookup limits of [RFC7208]. The
cycle-detection and resource-limit requirements of Section 6.1 are
mandatory for this reason, and consumers SHOULD additionally cap
manifest sizes and retrieval timeouts.
10.5. Subtree-Scoped Records
A "scope=subtree" record expands set membership to an entire zone, so
its misuse has correspondingly broad effect. Two constraints bound
the risk: the record can only be placed by the party operating the
TLD's zone, and links to members outside the TLD still require
reciprocation. The principal residual risk is a shared or open TLD
publishing "scope=subtree", which would sweep unaffiliated
registrants into a set; Section 4.2 requires consumers to reject
expansion in that case. Consumers SHOULD maintain independent
knowledge of which TLDs are single-organization rather than relying
on the record's own assertion.
10.6. Homograph and Look-Alike Domains
Nothing in this protocol prevents an attacker from building a valid
domain set among attacker-controlled look-alike domains. A confirmed
set of malicious domains is still malicious. Consumers MUST NOT
treat set validity as a reputation signal in itself.
10.7. Manifest Retrieval
The DNS record authorizes the manifest location; HTTPS authenticates
its retrieval. An attacker who can serve content at the manifest URI
but cannot modify the publisher's DNS cannot forge authorization, but
can alter the membership the manifest reports. Three constraints
bound this: the manifest MUST be served over HTTPS with a valid
certificate for its host; a manifest omitting the referencing domain
is rejected (Section 4.4); and links to members added by a
compromised manifest still require reciprocal records under
Section 3.2, which the attacker does not control. Publishers using
third-party manifest hosting SHOULD monitor the served content, and
SHOULD prefer hosts they operate. DNSSEC, where deployed, protects
Barrett, et al. Expires 21 February 2027 [Page 25]
Internet-Draft domain-set August 2026
the authorizing pointer itself.
10.8. Subdomain Confusion
Restricting publication to the registrable domain (Section 4.1)
prevents hosting customers on shared platforms from publishing
records that appear to speak for the platform's domain.
10.9. Submission Endpoint Abuse
The submission endpoint of Section 9.2 causes an index to issue DNS
and HTTPS retrievals toward arbitrary domains, and is therefore a
reflection and amplification primitive if left unconstrained.
Indexes MUST rate-limit submissions per submitting source and per
target domain, SHOULD apply backoff to repeated submissions naming
domains that publish no record, and SHOULD bound the closure walk of
Section 9.3 by the membership the retrieved records themselves
declare. Because submissions are unauthenticated, an index MUST NOT
interpret the act of submission as evidence of anything about the
submitter or the named domain.
11. Privacy Considerations
Domain-set records are public by design and reveal organizational
relationships between domains, some of which an organization may have
preferred to keep unlinked (e.g., a defensive registration of a
controversial brand). Publication is voluntary and per- domain;
operators control exposure by choosing what to attest. Records
identify organizations by domains. The OPTIONAL "contact" field
(Section 5.1) is the only field intended to carry an address;
publishers SHOULD populate it with role-based rather than personal
addresses, and MUST NOT place personal data in any other field,
including extension fields. Because domain-set records are public,
an address placed in the "contact" field must be assumed to be
harvested; the field exists so that operational contact can be
published deliberately, in the manner of [RFC9116], rather than
scraped from incidental sources. Submission to an index
(Section 9.2) discloses no information beyond the domain name
submitted.
12. IANA Considerations
12.1. Underscored Node Name
IANA is requested to add the following entry to the "Underscored and
Globally Scoped DNS Node Names" registry [RFC8552]:
Barrett, et al. Expires 21 February 2027 [Page 26]
Internet-Draft domain-set August 2026
RR Type: TXT
_NODE NAME: _domain-set
Reference: [this document]
12.2. Well-Known URI
IANA is requested to register "domain-set" in the "Well-Known URIs"
registry [RFC8615]:
URI Suffix: domain-set
Change Controller: IETF
Reference: [this document]
The suffix omits a format extension so that future revisions of this
specification can employ HTTP content negotiation at the same URI.
12.3. Well-Known URI for Index Submission
IANA is requested to register "domain-set-submit" in the "Well-Known
URIs" registry [RFC8615]:
URI Suffix: domain-set-submit
Change Controller: IETF
Reference: [this document]
12.4. Domain Set Relation Types
IANA is requested to create a new registry titled "Domain Set
Relation Types." New assignments are made under the Expert Review
policy [RFC8126]. Registrations consist of a value (an ASCII token
matching the "rel-value" ABNF production of Section 5.2), a short
description of the publisher role it denotes, and a reference.
Designated experts should confirm that a proposed value denotes how a
publisher uses a name, rather than a judgment about the name's
safety, reputation, or eligibility (Section 8), before approving it.
The registry is initially populated as follows:
Barrett, et al. Expires 21 February 2027 [Page 27]
Internet-Draft domain-set August 2026
+===========+=====================================+=================+
| Value | Description | Reference |
+===========+=====================================+=================+
| primary | the set's canonical public presence | [this |
| | | document] |
+-----------+-------------------------------------+-----------------+
| operating | actively serves content or services | [this |
| | | document] |
+-----------+-------------------------------------+-----------------+
| redirect | resolves and redirects to another | [this |
| | member | document] |
+-----------+-------------------------------------+-----------------+
| defensive | held to prevent third-party | [this |
| | registration; not in active use | document] |
+-----------+-------------------------------------+-----------------+
| reserved | held for future or internal use | [this |
| | | document] |
+-----------+-------------------------------------+-----------------+
Table 1
13. References
13.1. Normative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987,
<https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
Barrett, et al. Expires 21 February 2027 [Page 28]
Internet-Draft domain-set August 2026
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
13.2. Informative References
[I-D.ietf-dconn-domainconnect]
Kowalik, P., Blinn, A., Kolker, J., and S. Kerola, "Domain
Connect Protocol - DNS provisioning between Services and
DNS Providers", Work in Progress, Internet-Draft, draft-
ietf-dconn-domainconnect,
<https://datatracker.ietf.org/doc/html/draft-ietf-dconn-
domainconnect>.
[I-D.ietf-dnsop-domain-verification-techniques]
Sahib, S. K., Huque, S., Wouters, P., and E. Nygren,
"Domain Control Validation using DNS", Work in Progress,
Internet-Draft, draft-ietf-dnsop-domain-verification-
techniques, <https://datatracker.ietf.org/doc/html/draft-
ietf-dnsop-domain-verification-techniques>.
Barrett, et al. Expires 21 February 2027 [Page 29]
Internet-Draft domain-set August 2026
[I-D.ietf-dnsop-integration]
Sheth, S., Kaizer, A., Newbold, B., and N. Johnson,
"Integration of DNS Domain Names into Application
Environments: Motivations and Considerations", Work in
Progress, Internet-Draft, draft-ietf-dnsop-integration,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
integration>.
[I-D.ietf-regext-epp-same-entity]
Galvin, J., "Same Entity Set Support for the Extensible
Provisioning Protocol (EPP)", Work in Progress, Internet-
Draft, draft-ietf-regext-epp-same-entity,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
epp-same-entity>.
[PSL] Mozilla Foundation, "Public Suffix List",
<https://publicsuffix.org/>.
[RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
the Extensible Provisioning Protocol (EPP)", RFC 3915,
September 2004, <https://www.rfc-editor.org/info/rfc3915>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9116] Foudil, E. and Y. Shafranovich, "A File Format to Aid in
Security Vulnerability Disclosure", RFC 9116, April 2022,
<https://www.rfc-editor.org/info/rfc9116>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, December 2021,
<https://www.rfc-editor.org/info/rfc9162>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
Barrett, et al. Expires 21 February 2027 [Page 30]
Internet-Draft domain-set August 2026
[RWS] W3C WICG / Google Privacy Sandbox, "Related Website Sets",
<https://github.com/WICG/first-party-sets>.
Appendix A. Worked Example
Snug Harbor Bank (fictional) operates snugharbor.bank in a verified
namespace, snugharborbank.com as its primary website, and three
additional names. Each domain publishes:
_domain-set.snugharborbank.com. IN TXT
"v=domainset1; primary=snugharborbank.com;
members=snugharbor.bank,snugharborbank.net,
snugharborbank.org,shbmortgage.com;
verified=2026-08-05T00:00:00Z"
_domain-set.snugharbor.bank. IN TXT
"v=domainset1; primary=snugharborbank.com;
members=snugharborbank.com; verified=2026-08-05T00:00:00Z"
(Similar records at the remaining members.)
Equivalently, the primary could reference a manifest:
_domain-set.snugharborbank.com. IN TXT
"v=domainset1;
uri=https://snugharborbank.com/.well-known/domain-set"
with the manifest carrying the membership and any issuer-defined
entity metadata:
{
"version": "domainset1",
"primary": "snugharborbank.com",
"members": [
"snugharborbank.com",
"snugharbor.bank",
"snugharborbank.net",
"snugharborbank.org",
"shbmortgage.com"
],
"entity": {
"name": "Snug Harbor Bank"
},
"verified": "2026-08-05T00:00:00Z"
}
Barrett, et al. Expires 21 February 2027 [Page 31]
Internet-Draft domain-set August 2026
A consumer asked "is snugharborbank.com the same institution as
snugharbor.bank?" validates both directions, finds the link
CONFIRMED, confirms both directions are authenticated under
Section 6.2 (both zones are DNSSEC-signed), and can additionally
observe -- from outside this protocol -- that .bank registration
requires charter verification, composing a strong answer from first-
party data.
A phishing domain snugharb0r-secure.com publishing
"members=snugharborbank.com" achieves nothing: no member
reciprocates, the link remains ASSERTED, and conforming consumers
never present it.
Appendix B. Worked Example: Single-Organization TLD
A manufacturer operates the TLD .example, restricted by its registry
agreement to the operator and its affiliates, alongside a legacy
portfolio. The TLD publishes one record:
_domain-set.example. IN TXT
"v=domainset1; scope=subtree; primary=example.com;
members=example.com,example.co.uk,example-group.net;
verified=2026-08-05T00:00:00Z"
Each legacy domain reciprocates, naming the TLD by its bare label:
_domain-set.example.com. IN TXT
"v=domainset1; primary=example.com;
members=example,example.co.uk,example-group.net;
verified=2026-08-05T00:00:00Z"
A consumer asked whether support.example and example.com are the same
organization finds the apex record covering support.example without a
per-name lookup, confirms reciprocation from example.com, and reports
the link CONFIRMED. No records were published at individual names in
the .example zone.
Appendix C. Future Extensions (Informative)
This appendix is informative. It records extensions and applications
of this protocol that the authors anticipate, in sufficient detail
that a person skilled in the art could implement them. Nothing here
is normative, and future companion documents may specify these
mechanisms differently. The appendix exists so that the design space
around this protocol is documented in the open literature as of this
document's publication date.
Barrett, et al. Expires 21 February 2027 [Page 32]
Internet-Draft domain-set August 2026
C.1. Platform Identifiers
A domain set could be extended to associate platform-scoped
identifiers -- accounts on social media or messaging platforms --
with the organization the set describes. Identifiers would be
carried in the manifest (for example within the "entity" object, or a
dedicated "identifiers" array pairing a platform label with an
account identifier). Because most platforms cannot publish
reciprocal DNS records, such identifiers would carry a per-identifier
corroboration state rather than participating in mutual attestation:
"attested" where only the set publisher states the association, and
"corroborated" where an independent check closes the loop.
Corroboration mechanisms include: for the AT Protocol, resolving the
"_atproto" TXT record of a claimed handle and matching the resulting
DID against the account identifier stated in the manifest; for
platforms supporting profile link verification, confirming a rel="me"
or equivalent verified backlink from the platform profile to a member
domain; and, as a weakest form, confirming that the platform
profile's stated web address is a member of the set. Consumers would
surface corroboration state exactly as Section 6.2 surfaces
authentication status. Note that identifiers which are themselves
domain names -- such as AT Protocol handles hosted at a member domain
-- require no extension at all: they participate in the base protocol
as ordinary members.
C.2. Corroboration Against Authoritative Registers
The "entity" object could carry references to entries in
authoritative external registers: legal entity identifiers (LEI),
banking charter or license records maintained by financial
regulators, professional licensure databases, or registry-operator
eligibility rosters. An implementation would record, per reference:
the register, the identifier within it, the retrieval or verification
date, and the party that performed the check. Consumers or indexes
could then corroborate the set's claimed organizational identity
against the register, composing with (not altering) the validation of
Section 6, in the layered manner described in Section 8.
C.3. Delegated and Registry Attestation
A registry operator, registrar, or DNS provider could publish or co-
publish "_domain-set" records on behalf of registrants it serves: at
registration time via an EPP extension carrying the membership;
continuously, by provisioning and refreshing records under registrant
authorization; or via Domain Connect templates
[I-D.ietf-dconn-domainconnect] enabling one-click publication. A
delegated record could carry an extension field identifying the
provisioning party, allowing consumers to distinguish operator-
Barrett, et al. Expires 21 February 2027 [Page 33]
Internet-Draft domain-set August 2026
published from provider-published records without changing
validation.
C.4. Assurance Tiering
Consumers and indexes could derive a graded assurance level for a set
or link from observable inputs: DNSSEC presence on each side
(Section 6.2), the age and refresh recency of "verified" timestamps,
the age of the links themselves, the number and strength of
corroborations under C.1 and C.2, and the stability of membership
over time. Tier definitions could themselves be published machine-
readably so that independent consumers compute comparable levels.
C.5. Index Federation and Lifecycle Behavior
Indexes (Section 9) could adopt common lifecycle conventions:
freezing a set's published state when revalidation begins to fail,
displaying the last successful retrieval time during the frozen
interval, and aging the entry out after a defined window; reconciling
submissions naming different members of one set; and exchanging
submissions or computed results with other indexes (gossip),
following the multi-log model of Certificate Transparency [RFC9162].
C.6. Consumption by Automated Agents
Computed set data could be exposed to automated consumers --
including AI systems and agent frameworks -- through structured query
endpoints or agent tool-calling protocols, returning the effective
set, per-link confirmation status, authentication status,
corroboration states, and freshness metadata for a queried domain.
An agent deciding whether two names represent the same organization
would weight confirmed, authenticated, corroborated links above any
inference from content similarity, and would decline to infer
relationships that the protocol data does not support.
C.7. Hierarchical and Transitive Sets
A set could reference another set -- a parent organization naming the
sets of its subsidiaries -- via a manifest member carrying the
referenced set's primary domain. Such references would be subject to
the same mutuality rule at the set level (each set's manifest names
the other), with explicit scoping of what the relationship asserts
(common ownership rather than common operation) and loop detection
during closure computation.
Barrett, et al. Expires 21 February 2027 [Page 34]
Internet-Draft domain-set August 2026
C.8. Integrity and Transparency Mechanisms
The manifest could be signed (for example as a JWS) by a key
published in or referenced from the DNS record; the DNS record could
carry a digest of the manifest content in an extension field (for
example "hash="), making substitution at the manifest host detectable
without DNSSEC; and set changes could be recorded in an append-only,
publicly auditable transparency log analogous to Certificate
Transparency [RFC9162], enabling detection of retroactive alteration
and providing an audit trail of membership over time.
C.9. Abuse Monitoring and Notification
An index or monitoring service could detect unreciprocated records
naming a given domain -- the ASSERTED-only claims of Section 3.2 --
and notify the named domain's operator via the "contact" URI of its
own record, enabling the operator to discover impersonation attempts,
look-alike registrations claiming affiliation, and stale
attestations, and to feed established takedown or dispute processes.
C.10. Privacy-Preserving Membership
An organization wanting verifiability without public enumeration
could publish hashed member identifiers (salted digests of member
domains) in place of cleartext membership, disclosing the preimages
selectively to chosen consumers, who then validate reciprocation in
the normal way. This trades open discoverability for confidentiality
and would be signaled by a distinct field so that ordinary consumers
skip such records cleanly.
Acknowledgments
This document draws on the deployment philosophy of security.txt
[RFC9116] and on operational experience indexing verified domain
namespaces.
Authors' Addresses
Thomas Barrett
EnCirca, Inc.
Woburn, MA
United States of America
Email: tbarrett@encirca.com
Barrett, et al. Expires 21 February 2027 [Page 35]
Internet-Draft domain-set August 2026
Chris Schaub
EnCirca, Inc.
Woburn, MA
United States of America
Email: cschaub@encirca.com
Andrew Barrett
EnCirca, Inc.
Woburn, MA
United States of America
Email: andrew@encirca.com
P Kowalik
DENIC eG
Frankfurt am Main
Germany
Email: pawel.kowalik@denic.de
Barrett, et al. Expires 21 February 2027 [Page 36]