The Domain Set Discovery Protocol (domain-set)

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 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.¶

• 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 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.¶

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.¶

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.¶

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.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.¶

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.¶

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 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¶

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 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.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 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):¶

   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.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).¶

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:¶

• 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.¶

  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:¶

• 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.¶

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.¶

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 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.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 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 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.¶

12.1. Underscored Node Name

IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]:¶

   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:¶

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-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.¶

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.¶