]> EnCirca, Inc.

WoburnMAUnited States of America tbarrett@encirca.com

EnCirca, Inc.

WoburnMAUnited States of America cschaub@encirca.com

EnCirca, Inc.

WoburnMAUnited States of America andrew@encirca.com

DENIC eG

Frankfurt am MainGermany pawel.kowalik@denic.de

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.

Introduction

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

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 ().
• Authenticated in every direction, by DNSSEC or by the Web PKI (); 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 ().

Non-Goals This protocol asserts common operation of domains. It does NOT assert the lawfulness, eligibility, licensure, or trustworthiness of the operating organization (see ). 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 are optional aggregators, of which any number may exist; no index is canonical.

Related Work Several existing efforts are adjacent to this protocol; none addresses its problem. Domain control validation. 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. 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 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 (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 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 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 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.

Why DNS An HTTPS-only design, in the manner of , 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 remains available for publishers who operate HTTPS.

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

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 (); 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 . Text contributions on any of these are welcome.

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 when, and only when, they appear in all capitals, as shown here. DNS terminology in this document follows .

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

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.

The Domain Set Model

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

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.

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 () but not as invalidating confirmed links.

Publication and Discovery

DNS TXT Record The DNS TXT record 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 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 and DKIM . 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 () 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 . 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 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 () 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 , 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 . Where the zone is signed with DNSSEC , the record inherits origin authentication, satisfying the authentication requirement of .

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

Domain Set Manifest A Domain Set Manifest is a JSON 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 ):

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

primary

OPTIONAL. As in . A manifest MUST identify at most one primary domain.

verified OPTIONAL. As in .

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 .

Unknown top-level manifest members MUST be ignored to permit extension.

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

Record Syntax

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 referencing the set's Domain Set Manifest (), 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 . 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 (). 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 ().

  verified

  OPTIONAL. Timestamp recording when the publisher last reviewed and confirmed the domain set. This is a freshness indicator, not an expiration date. See .

  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 . Publishers SHOULD use role-based rather than personal addresses ().

Unknown fields MUST be ignored to permit extension.

ABNF Formal syntax in ABNF (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

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"

Validation Procedure

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 (). To validate a claimed link between A and B, a consumer:

1. Retrieves A's domain-set record (). If the record contains a "uri" field, retrieves the referenced manifest (), 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 , 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 (), 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).

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 , 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 . Authentication is independent of the ASSERTED/CONFIRMED mutuality test of : CONFIRMED requires both mutuality and authentication, in both directions.

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 . 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 , 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 ), 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 are the control for that case.

Publishers SHOULD additionally notify an index () when a record is first published and whenever its membership materially changes.

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 ().
• 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 and the stale-attestation guidance of .

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 where the consuming context involves security decisions.
• MUST NOT present set membership as implying eligibility, licensure, endorsement, safety, or reputation ().
• MUST NOT represent a confirmed link, or a relation type (), 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.

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.

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.

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

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.

Index Behavior On receiving a submission, an index:

1. Retrieves the named domain's record (). If none exists, the submission is discarded.
2. Validates links to listed members under , 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.

Security Considerations

Unilateral Insertion The primary abuse case is a hostile domain claiming membership in a victim's set. Mutual attestation () 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; 's requirements are therefore normative, not advisory.

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

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.

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 . The cycle-detection and resource-limit requirements of are mandatory for this reason, and consumers SHOULD additionally cap manifest sizes and retrieval timeouts.

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.

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.

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 (); and links to members added by a compromised manifest still require reciprocal records under , 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.

Subdomain Confusion Restricting publication to the registrable domain () prevents hosting customers on shared platforms from publishing records that appear to speak for the platform's domain.

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.

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 , rather than scraped from incidental sources. Submission to an index (Section 9.2) discloses no information beyond the domain name submitted.

IANA Considerations

Underscored Node Name IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry : RR Type: TXT _NODE NAME: _domain-set Reference: [this document]

Well-Known URI IANA is requested to register "domain-set" in the "Well-Known URIs" registry : 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.

Well-Known URI for Index Submission IANA is requested to register "domain-set-submit" in the "Well-Known URIs" registry : URI Suffix: domain-set-submit Change Controller: IETF Reference: [this document]

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 . Registrations consist of a value (an ASCII token matching the "rel-value" ABNF production of ), 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 (), before approving it. The registry is initially populated as follows:

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 member	[this document]
defensive	held to prevent third-party registration; not in active use	[this document]
reserved	held for future or internal use	[this document]

References Normative References Informative ReferencesWork in ProgressWork in ProgressWork in ProgressWork in ProgressMozilla FoundationW3C WICG / Google Privacy Sandbox

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" } 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.

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.

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.

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.

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.

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

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.

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 .

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.

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.

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 , enabling detection of retroactive alteration and providing an audit trail of membership over time.

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.

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 and on operational experience indexing verified domain namespaces.