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