Domain Affiliation Confirmation (DAC)
draft-manelidis-dnsop-domain-affiliation-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dimitri Manelidis , Fabio Ramos | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-manelidis-dnsop-domain-affiliation-01
Network Working Group D. Manelidis
Internet-Draft
Intended status: Standards Track F. Ramos
Expires: 4 May 2027 31 October 2026
Domain Affiliation Confirmation (DAC)
draft-manelidis-dnsop-domain-affiliation-01
Abstract
Security systems assess domain names one at a time. A new domain of
an established organization therefore starts with no reputation, and
a legitimate domain that resembles another organization's name can be
reported as an impersonation. This document defines Domain
Affiliation Confirmation (DAC), by which the operator of one domain,
the confirming domain, confirms that another domain, the affiliated
domain, is operated by it or under its authority. The two domains
need not be related in the DNS hierarchy. The affiliated domain
publishes a DNS record naming the confirming domain and a random
token; the confirming domain confirms that token, in the DNS or over
HTTPS, by naming the affiliated domain. Verification takes at most
three DNS queries and one HTTPS request. The confirming domain
publishes no list of its domains, and an affiliation is ended by
deleting one record. The document also states what a confirmation
means to relying parties such as takedown services and reputation
systems.
About This Document
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Domain Name System
Operations (DNSOP) Working Group mailing list (dnsop@ietf.org). A
reference implementation with test vectors accompanies this draft
(Section 15).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Manelidis & Ramos Expires 4 May 2027 [Page 1]
Internet-Draft Domain Affiliation Confirmation October 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. This Document . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Relationship to Other Work . . . . . . . . . . . . . . . 7
1.6. Requirements Language . . . . . . . . . . . . . . . . . . 8
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
4. Records . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Common Syntax . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Claim Record . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Scope of an Affiliation . . . . . . . . . . . . . . . . . 11
4.4. Marker Record . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Confirmation Record (DNS Channel) . . . . . . . . . . . . 13
4.6. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Publishing an Affiliation . . . . . . . . . . . . . . . . . . 15
5.1. Creating an Affiliation . . . . . . . . . . . . . . . . . 15
5.2. Ending an Affiliation . . . . . . . . . . . . . . . . . . 16
5.3. Moving an Affiliated Domain to Another Confirming
Domain . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Organizations with Several Levels . . . . . . . . . . . . 17
6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Inputs and Outputs . . . . . . . . . . . . . . . . . . . 17
6.2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 17
Manelidis & Ramos Expires 4 May 2027 [Page 2]
Internet-Draft Domain Affiliation Confirmation October 2026
6.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. DNS Errors . . . . . . . . . . . . . . . . . . . . . . . 20
6.5. Authenticated Results . . . . . . . . . . . . . . . . . . 20
6.6. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. HTTPS Channel . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Fetching . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Meaning of a Confirmation . . . . . . . . . . . . . . . . . . 23
8.1. What a Confirmation States . . . . . . . . . . . . . . . 23
8.2. What a Confirmation Does Not State . . . . . . . . . . . 24
8.3. Considerations for Relying Parties . . . . . . . . . . . 24
9. Reuse of Registrant Verification . . . . . . . . . . . . . . 25
10. Failure Reports . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. When Reports Are Sent . . . . . . . . . . . . . . . . . 26
10.2. Report Format . . . . . . . . . . . . . . . . . . . . . 27
10.3. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 27
10.4. Handling Reports . . . . . . . . . . . . . . . . . . . . 28
11. Operational Considerations . . . . . . . . . . . . . . . . . 28
11.1. Automation and Inventory . . . . . . . . . . . . . . . . 28
11.2. TTLs, Signatures, and Revocation Time . . . . . . . . . 28
11.3. Staged Deployment . . . . . . . . . . . . . . . . . . . 29
11.4. Choosing and Changing Channels . . . . . . . . . . . . . 29
11.5. Load and Scale . . . . . . . . . . . . . . . . . . . . . 29
11.6. DNS Configuration . . . . . . . . . . . . . . . . . . . 29
11.7. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 30
12.2. Fabricated Claims . . . . . . . . . . . . . . . . . . . 30
12.3. Copied Claims and Token Disclosure . . . . . . . . . . . 31
12.4. Stale Confirmations . . . . . . . . . . . . . . . . . . 31
12.5. Forged DNS Responses . . . . . . . . . . . . . . . . . . 31
12.6. Replay of Deleted Records . . . . . . . . . . . . . . . 32
12.7. Wildcards, Aliases, and Delegation . . . . . . . . . . . 32
12.8. Compromise of the Confirming Domain . . . . . . . . . . 33
12.9. HTTPS Resources Created by Others . . . . . . . . . . . 33
12.10. Use of Affiliations to Deflect Takedowns . . . . . . . . 33
12.11. Inducing Adverse Results . . . . . . . . . . . . . . . . 34
12.12. Resource Consumption . . . . . . . . . . . . . . . . . . 34
12.13. Subtree Confirmations . . . . . . . . . . . . . . . . . 34
12.14. Failure Reports . . . . . . . . . . . . . . . . . . . . 35
12.15. Expiry Dates . . . . . . . . . . . . . . . . . . . . . . 35
12.16. Confusable Names . . . . . . . . . . . . . . . . . . . . 35
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14.1. Underscored and Globally Scoped DNS Node Name . . . . . 36
14.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 37
14.3. Domain Affiliation Confirmation Registry Group . . . . . 37
14.3.1. DAC Tags . . . . . . . . . . . . . . . . . . . . . . 37
Manelidis & Ramos Expires 4 May 2027 [Page 3]
Internet-Draft Domain Affiliation Confirmation October 2026
14.3.2. DAC Confirmation Channels . . . . . . . . . . . . . 38
14.3.3. DAC Report Reasons . . . . . . . . . . . . . . . . . 39
14.3.4. DAC Relationship Values . . . . . . . . . . . . . . 39
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 40
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
16.1. Normative References . . . . . . . . . . . . . . . . . . 41
16.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 47
A.1. Why TXT Records . . . . . . . . . . . . . . . . . . . . . 48
A.2. Why Not a List of Domains . . . . . . . . . . . . . . . . 48
A.3. Why Not Signatures . . . . . . . . . . . . . . . . . . . 48
A.4. Why the Procedure Does Not Use the Public Suffix List . . 49
A.5. Why Affiliation Is Not Transitive Across Organizations . 49
A.6. Why One Confirming Domain per Affiliated Domain . . . . . 49
A.7. Why Authentication Is Reported Rather Than Required . . . 49
A.8. Why Confirmations Are Not Bound to Registration Data . . 50
A.9. Why the Relationship Is Optional . . . . . . . . . . . . 50
A.10. Why No Aggregators . . . . . . . . . . . . . . . . . . . 51
A.11. Why the Meaning of a Confirmation Is Defined . . . . . . 51
Appendix B. Complete Example . . . . . . . . . . . . . . . . . . 51
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 52
Appendix D. Changes since -00 . . . . . . . . . . . . . . . . . 57
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction
1.1. Problem Statement
Mail filters, browser warning systems, secure web gateways, and
brand-protection services evaluate domain names individually. Two
consequences follow for organizations that operate more than one
domain.
New domains start without reputation. When an organization launches
a product or service under a new domain name, that name is treated
as unknown, and often as suspicious, because nothing tells the
evaluating system that it is operated by the same organization as
an established domain.
Legitimate look-alikes are reported as impersonations.
Brand-protection services search for newly registered names that
resemble their clients' names. A legitimate domain of one
organization can resemble the name of an unrelated organization.
The service has no standard way to learn that the domain is
operated by an established organization and may ask the domain's
registrar or hosting provider to suspend it. Erroneous takedown
requests can disable an entire legitimate domain [ITCHIO].
Manelidis & Ramos Expires 4 May 2027 [Page 4]
Internet-Draft Domain Affiliation Confirmation October 2026
Both problems would be reduced if an evaluating system could ask a
precise question and get an answer from the party able to give it:
"Does the operator of this established domain confirm that it
operates this other domain?" No deployed mechanism answers it.
Registration data [RFC9083] is frequently redacted and was not
designed to express relationships between domains, and certificates
bind keys to names, not names to each other.
An organization's internal records and policies do not answer the
question either. They tell the organization which domains it
operates, but a takedown service, a mail filter, or a reputation
system that encounters one of those domains has no access to them and
no means of checking them. The answer has to be published where any
such party can retrieve it, and it has to come from the operator of
the established domain.
The same question arises when software agents act for an organization
under domain names of their own. A party that receives a request
from an agent's domain, which may be new and have no reputation, may
want to know which established domain stands behind it.
1.2. This Document
This document defines Domain Affiliation Confirmation (DAC). The
domain to be affiliated (the affiliated domain) publishes a DNS
record that names the established domain (the confirming domain) and
carries a random token. The confirming domain confirms the
affiliation by publishing, under a name derived from that token, a
record that names the affiliated domain. A verifier reads the
affiliated domain's record, reads the confirming domain's
confirmation, and checks that the confirmation names the affiliated
domain it started from.
"Confirming domain" and "affiliated domain" name roles in this
protocol only. They imply no hierarchy or delegation in the DNS.
The two domains can be at the same level, under different top-level
domains, or in different scripts, and either can be the older one.
Publishing an affiliation requires no action by a registry or
registrar.
The document also states what a confirmation means (Section 8): the
confirming operator indicates that it operates the affiliated domain
or authorizes its operation, and that reports of abuse concerning the
affiliated domain may be directed to it. A relationship that relying
parties are not meant to act on would leave the problems above
unsolved (Appendix A.11).
Manelidis & Ramos Expires 4 May 2027 [Page 5]
Internet-Draft Domain Affiliation Confirmation October 2026
DAC is intended for systems that evaluate domains without a person in
the loop, such as takedown services, reputation systems, mail
filters, and registries. Such systems already examine a domain at a
defined time, for example when a report about it is received, when it
is first observed, or when it is scored, and they perform the
verification at that time. DAC does not require that affiliations be
shown to users.
1.3. Design Goals
1. Only the confirming domain can create an affiliation. A claim
the confirming domain has not confirmed has no effect, and a
confirmation for one affiliated domain cannot be reused for
another.
2. The confirming domain publishes nothing from which its affiliated
domains can be listed. Each affiliated domain's claim is public,
so affiliated domains can be found by examining domains
individually, as with any public DNS data.
3. An affiliation is ended by deleting one record at the confirming
domain, without any change at the affiliated domain. The change
takes effect within cache and DNSSEC signature lifetimes
(Section 12.6).
4. No new key material. The protocol relies on the confirming
domain's existing control of its DNS zone or, optionally, its web
origin.
5. Bounded cost. Verification takes at most three TXT queries, plus
one HTTPS request and its address resolution when the confirming
domain uses that channel or its marker is not validated as
secure, with no recursion and no searching.
6. Deployable with existing tools. Records are TXT records at
underscored names [RFC8552].
7. The verification procedure does not consult a list of public
suffixes. Every confirmation requires a record that only the
confirming operator can publish.
1.4. Non-Goals
DAC does not establish the identity, legitimacy, or licensing of the
confirming operator. It conveys a statement by whoever operates the
confirming domain; whether that party deserves trust is for each
relying party to decide (Section 8).
Manelidis & Ramos Expires 4 May 2027 [Page 6]
Internet-Draft Domain Affiliation Confirmation October 2026
DAC does not express relationships between independent organizations,
such as partnerships or service providers (Appendix A.5).
DAC does not define where administrative boundaries in the DNS lie.
Relying parties may still need such information to decide which names
to evaluate.
DAC does not detect impersonation. A domain that impersonates an
organization can publish a claim naming that organization's domain,
but the claim is not confirmed (Section 12.2), and the organization
can learn of it through failure reports (Section 10). A domain that
publishes no claim, or whose claim is not confirmed, is not thereby
shown to be an impersonation (Section 8.3).
DAC does not establish which legal entity operates a domain. A
confirmation can state whether the two domains are operated by the
same legal entity (Section 4.5), but that statement is made by the
confirming operator and is not verified by DAC.
1.5. Relationship to Other Work
[I-D.ietf-dnsop-domain-verification-techniques] describes how a
service verifies that a user controls a domain. DAC follows its
practices for TXT records at underscored names and for tokens, but
records a standing relationship between two domains rather than
proving control of one domain to one service.
[I-D.ietf-regext-epp-same-entity] lets registries and registrars keep
a set of names that a registry policy treats as related, such as
variants of an internationalized name, with one registrant. DAC
depends on no registry policy and is published by the domains'
operators. A registry or registrar can, however, use DAC results
when it registers a domain or reuses an earlier verification of a
registrant (Section 9).
Related Domains By DNS [I-D.brotman-rdbd] lets a domain declare or
disavow a relationship with another domain, using new resource record
types and optional signatures. It signals that some relationship
exists without defining its meaning. DAC uses TXT records, requires
a record by each of the two domains, defines what a confirmation
states (Section 8), and uses no key material (Appendix A.3).
The DBOUND work [I-D.tjw-dbound2-problem-statement] addresses
administrative boundaries in the DNS, such as where one
organization's names end and another's begin below a common suffix.
DAC does not define such boundaries (Section 1.4); it relates two
domains that may be anywhere in the DNS.
Manelidis & Ramos Expires 4 May 2027 [Page 7]
Internet-Draft Domain Affiliation Confirmation October 2026
Related Website Sets [RWS] let a group of web sites declare that they
belonged together, through a file at each site and a centrally
reviewed list, so that a browser could apply its privacy rules to the
group. DAC involves no central list, is not specific to the web, and
is intended for systems that assess abuse.
[I-D.ihsanullah-dnsid] binds the domain name of a software agent to
an accountable entity identified by a domain under that entity's
control. DAC is not specific to agents and expresses a relationship
between any two domains (Section 1.2).
[I-D.mozleywilliams-dnsop-dnsaid] describes how an organization
publishes its software agents in the DNS under a domain. When the
agents are published under a domain of their own, DAC relates that
domain to the organization's established domain.
[I-D.barrett-dnsop-domain-set] lets the domains operated by one
organization attest to each other by listing other members, in the
DNS or in a file over HTTPS; in DAC, the confirming domain publishes
nothing from which its affiliated domains can be listed
(Appendix A.2).
1.6. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
DNS terms are used as defined in [RFC9499]. This document also uses
the following terms.
Affiliated domain: The domain name whose affiliation is declared or
verified.
Confirming domain: The domain name that the affiliated domain names
as its confirming domain.
Confirming operator: The party that controls the content of the
confirming domain's DNS zone or, for confirmations over HTTPS, of
the confirming domain's HTTPS origin.
Claim: The TXT record published by the affiliated domain
(Section 4.2).
Manelidis & Ramos Expires 4 May 2027 [Page 8]
Internet-Draft Domain Affiliation Confirmation October 2026
Marker: The TXT record by which a confirming domain indicates that
it participates and selects a confirmation channel (Section 4.4).
Confirmation: The record by which the confirming domain confirms one
claim, published in the DNS (Section 4.5) or over HTTPS
(Section 7).
Token: A random value, unique to one affiliated domain, that links a
claim to its confirmation (Section 4.6).
Verifier: A party that carries out the procedure in Section 6.
Relying party: A party that makes decisions using verification
results, such as a takedown service, a mail filter, or a
reputation system.
In examples, "bank.example" is the confirming domain and
"embank.example" is the affiliated domain [RFC2606]. The token used
in examples, "mfrggzdfmztwq2lknnwg23tpobyxe43u", is illustrative and
not random.
3. Protocol Overview
An affiliation consists of three records. The claim is published by
the affiliated domain; the marker and the confirmation are published
by the confirming domain.
Affiliated: embank.example Confirming: bank.example
+-------------------------------+ +--------------------------------+
| _affiliation.embank.example. | | _affiliation.bank.example. |
| TXT "v=DAC1; | | TXT "v=DAC1" (marker) |
| p=bank.example; | | |
| t=<token>" (claim) | | <token>._affiliation. |
+-------------------------------+ | bank.example. |
| TXT "v=DAC1; |
| d=embank.example" |
| (confirmation) |
+--------------------------------+
Verifier:
1. TXT _affiliation.embank.example -> p=bank.example, t=<token>
2. TXT _affiliation.bank.example -> marker, channel "dns"
3. TXT <token>._affiliation.bank.example
-> d=embank.example
4. d= equals the affiliated domain -> result "confirmed"
Figure 1: Records and Verification Steps
Manelidis & Ramos Expires 4 May 2027 [Page 9]
Internet-Draft Domain Affiliation Confirmation October 2026
A claim copied to another domain fails because the confirmation names
the original affiliated domain. Confirmation names cannot be found
without the corresponding claims, because they contain the token.
The marker prevents a wildcard elsewhere in the confirming domain's
zone from answering for confirmation names (Section 12.7) and tells
the verifier which channel the confirming domain uses.
4. Records
4.1. Common Syntax
The three records share one tag-list syntax: a version tag followed
by zero or more tags, separated by semicolons. The ABNF [RFC5234]
below uses case-sensitive strings [RFC7405]; WSP, ALPHA, and DIGIT
are the core rules of [RFC5234].
<CODE BEGINS> file "dac.abnf"
record = *WSP v-tag *( *WSP ";" *WSP tag ) [ *WSP ";" ] *WSP
v-tag = %s"v" *WSP "=" *WSP %s"DAC1"
tag = tag-name *WSP "=" *WSP tag-value
tag-name = ALPHA *( ALPHA / DIGIT / "_" )
tag-value = 1*tval-char
tval-char = %x21-3A / %x3C-7E ; VCHAR except ";"
p-value = domain ; claim: confirming domain
t-value = 26*52b32-char ; claim: token
c-value = 1*tval-char ; marker: channel
m-value = 1*tval-char ; marker: mode
r-value = 1*tval-char ; marker: abuse contact URI
d-value = domain ; confirmation: affiliated
s-value = 1*tval-char ; confirmation: scope
rel-value = 1*tval-char ; confirmation: relationship
x-value = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; confirmation: expiry
f-value = 1*tval-char ; marker: report URI
domain = label *( "." label )
label = ld-char [ *61ldh-char ld-char ]
ld-char = %x61-7A / DIGIT ; lowercase letters and digits
ldh-char = ld-char / "-"
b32-char = %x61-7A / %x32-37 ; RFC 4648 base32, lowercase
<CODE ENDS>
A TXT record is a DAC record if its text, after any leading spaces or
tabs, begins with "v", optional whitespace, "=", optional whitespace,
and "DAC1", followed by whitespace, ";", or the end of the text.
Other TXT records are ignored, so DAC records can share a name with
other TXT records. A DAC record is well-formed if it matches the
"record" rule, contains no tag name more than once, and the value of
Manelidis & Ramos Expires 4 May 2027 [Page 10]
Internet-Draft Domain Affiliation Confirmation October 2026
every tag defined in this document matches the rule given for it,
with an "x" value that is also a valid calendar date. A DAC record
that is not well-formed is malformed.
* Tag names are case-sensitive. Verifiers MUST ignore tags they do
not recognize. New tags are registered as described in
Section 14.3.1; adding a tag does not change the version.
* A TXT record consisting of several character-strings is
interpreted as their concatenation without separators, as in
Section 3.3 of [RFC7208]. Publishers SHOULD keep each record
within a single character-string of at most 255 octets.
* Domain names in records are in canonical form: A-labels [RFC5890]
in lowercase, without a trailing dot, at most 253 octets long,
with a last label that is not entirely numeric. A label with
hyphens in both the third and fourth positions MUST be a valid
A-label. The "domain" rule expresses the character-level
constraints; a name violating the others is malformed. Verifiers
do not repair names.
4.2. Claim Record
An affiliated domain declares its confirming domain with one TXT
record at the name formed by prepending the label "_affiliation" to
the affiliated domain:
_affiliation.embank.example. 3600 IN TXT
"v=DAC1; p=bank.example; t=mfrggzdfmztwq2lknnwg23tpobyxe43u"
p (required): The confirming domain, matching the "p-value" rule.
t (required): The token, matching the "t-value" rule (Section 4.6).
An affiliated domain has at most one confirming domain and MUST NOT
publish more than one DAC record at its "_affiliation" name; a domain
that is also a confirming domain includes its marker tags in the same
record (Section 4.4). The confirming domain MUST NOT be the
affiliated domain itself. The claim name MAY be a CNAME, for example
when the affiliated domain's records are managed by the confirming
operator.
4.3. Scope of an Affiliation
A claim is published at, and an affiliation is verified for, one
domain name. Organizations typically publish claims at their
registrable domains, such as "embank.example", not at every host
name.
Manelidis & Ramos Expires 4 May 2027 [Page 11]
Internet-Draft Domain Affiliation Confirmation October 2026
A relying party assessing a name below such a domain, for example
"marketing.embank.example", determines the domain it regards as
responsible for that name, as it already does when attributing
reputation, and verifies that domain. Claims are not published at
names like "marketing.embank.example" for this purpose.
By default, a confirmation states nothing about names below the
affiliated domain, and relying parties apply their usual practice to
them. A confirming domain that operates, or authorizes the operation
of, every name below the affiliated domain states this by including
the "s" tag with the value "subtree" in the confirmation
(Section 4.5). The confirmation then also covers every name below
the affiliated domain. A confirming domain MUST NOT include it when
names below the affiliated domain are operated by parties not acting
under the confirming domain's authority, such as customers of a
hosting or platform service (Section 12.13).
If a name below an affiliated domain with a subtree confirmation
publishes its own claim, that claim governs the name and the names
below it.
4.4. Marker Record
A confirming domain that confirms affiliations publishes exactly one
DAC record at the name formed by prepending "_affiliation" to the
confirming domain. A domain that is both an affiliated domain and a
confirming domain publishes a single record there containing both the
claim tags and the marker tags.
A confirming domain whose zone is not signed and that publishes its
confirmations only over HTTPS can omit the marker, because verifiers
then consult its HTTPS resources (step 5 of Section 6.2). It still
needs the marker to convey its mode and abuse contact.
_affiliation.bank.example. 3600 IN TXT
"v=DAC1; r=mailto:abuse@bank.example"
c (optional): The confirmation channel. This document defines
"dns", the default (Section 4.5), and "https" (Section 7). Other
values are registered as described in Section 14.3.2. With
"https", DNS confirmation records are not consulted.
r (optional): A URI [RFC3986] for reports of abuse concerning the
confirming domain's affiliated domains, with scheme "mailto"
[RFC6068] or "https". Semicolons and whitespace in the URI are
percent-encoded. Verifiers ignore an "r" tag with any other
scheme.
Manelidis & Ramos Expires 4 May 2027 [Page 12]
Internet-Draft Domain Affiliation Confirmation October 2026
m (optional): The mode: "enforce", the default, or "test". In
"test" mode the confirming domain is deploying the protocol and
asks that its confirmations not be acted on (Section 11.3).
Verifiers treat any value other than "enforce" as "test".
f (optional): A URI to which verifiers may send reports of claims
naming this confirming domain that were not confirmed
(Section 10). It is either "https://" followed by a host and an
optional path, without userinfo, port, query, or fragment, or
"mailto:" followed by exactly one address, without header fields.
The host, or the domain of the address, is in canonical form
(Section 4.1) and is the confirming domain or a name below it.
Verifiers ignore an "f" tag that does not meet these conditions.
The marker MUST be a TXT record owned by the "_affiliation" name
itself, not data reached through a CNAME or DNAME record. The marker
makes "_affiliation" an existing node in the confirming domain's
zone, so that a wildcard higher in the zone cannot answer for names
below it (Section 12.7). The "_affiliation" name MAY be delegated as
a separate zone, in which case that zone's operator publishes the
marker and confirmations. A DNAME record [RFC6672] at that name
redirects the queries for confirmations to another zone and has the
same effect as delegating them.
4.5. Confirmation Record (DNS Channel)
For each confirmed affiliated domain, a confirming domain using the
DNS channel publishes one TXT record at the name formed by prepending
the affiliated domain's token to the confirming domain's
"_affiliation" name:
mfrggzdfmztwq2lknnwg23tpobyxe43u._affiliation.bank.example.
3600 IN TXT "v=DAC1; d=embank.example"
d (required): The affiliated domain, matching the "d-value" rule.
s (optional): The scope. The value "subtree" states that the
confirmation also covers every name below the affiliated domain
(Section 4.3). Verifiers ignore any other value; other scopes
would be defined with a new tag.
rel (optional): The relationship between the operators of the two
domains, matching the "rel-value" rule. The value "same-entity"
states that the affiliated domain is operated by the legal entity
that operates the confirming domain. The value "third-party"
states that it is operated by another party acting under the
confirming operator's authority, such as another legal entity of
the same group or a contractor. Other values are registered as
Manelidis & Ramos Expires 4 May 2027 [Page 13]
Internet-Draft Domain Affiliation Confirmation October 2026
described in Section 14.3.4. Without "rel", or with a value the
verifier does not recognize, the confirmation does not state which
of these applies. Confirming operators SHOULD include "rel".
x (optional): The last day of validity, as a full-date in UTC
[RFC3339], matching the "x-value" rule. The confirmation applies
until the end of that day, 23:59:59 UTC, and not afterwards.
Without "x", the confirmation applies until it is removed.
An expiry date suits domains used for a limited time, such as
campaign sites. It also limits the consequences of a confirmation
that is not removed when the affiliated domain's registration lapses
and the domain is registered by someone else (Section 12.4). For
this reason, confirming operators SHOULD include "x" and SHOULD set
it no later than the expiry date of the affiliated domain's
registration. A confirming operator extends a confirmation by
replacing the record with one carrying a later date.
A tool that publishes confirmations (Section 11.1) can obtain the
expiry and creation dates of the affiliated domain's registration
through the Registration Data Access Protocol (RDAP) [RFC9082]
[RFC9083] [RFC9224], or have them entered by the operator where RDAP
does not provide them. Such a tool extends "x" only when the
registration has been renewed, that is, when the expiry date has
moved forward, the creation date is unchanged, and no transfer of the
registration has been recorded since the previous check. A recorded
transfer can mean a sale; the tool then does not extend the
confirmation and alerts the operator. Many registries move the
expiry date forward automatically when it is reached, before the
registrant has paid, and delete the domain later if no payment
follows. The tool therefore ends the confirmation, and alerts the
operator, when the registration data shows the domain as deleted or
scheduled for deletion, for example through the RDAP statuses
"redemption period" and "pending delete" [RFC8056], or when the
creation date has changed, which indicates that the domain was
deleted and registered again, possibly by someone else.
An expiry date tied to the registration does not end a confirmation
when the affiliated domain is sold without a recorded transfer, when
the registrant's account at its registrar is taken over, or when the
domain is moved to another DNS operator. In these cases the
confirming operator has to remove the confirmation (Section 5.2).
Verifiers cannot determine whether a confirming operator follows the
practice above.
Manelidis & Ramos Expires 4 May 2027 [Page 14]
Internet-Draft Domain Affiliation Confirmation October 2026
A confirmation name MUST NOT hold more than one DAC record. It MAY
be a CNAME, for example to a name hosted by a DNS provider. The
confirming domain MUST NOT publish wildcard records at or below its
"_affiliation" name.
4.6. Tokens
A token links one claim to one confirmation. It makes confirmation
names unpredictable, so that a confirming domain's confirmations
cannot be found by guessing names, whether by online queries or, for
DNSSEC-signed zones using NSEC3, by offline guessing of hashed names.
A token is not a secret: it is published in the claim and appears in
queries. The protocol's resistance to forged affiliations does not
depend on tokens being unknown (Section 12.3).
* A token MUST contain at least 128 bits, and SHOULD contain 160
bits, from a cryptographically secure random source [RFC4086]. At
128 bits, guessing a confirmation name is infeasible and
collisions between tokens are negligible.
* A token is encoded in base32 (Section 6 of [RFC4648]) with
lowercase letters and without padding, giving 26 to 52 characters;
a 160-bit token is 32 characters, well within the 63-octet limit
on a DNS label [RFC1035]. Case-sensitive encodings such as base64
cannot be used, because DNS name matching ignores case [RFC4343]
and some resolvers alter the case of query names.
* Tokens are opaque; verifiers do not decode them. A confirming
domain MUST use a different token for each affiliated domain and
SHOULD use a new token when re-establishing an affiliation that
was previously ended.
5. Publishing an Affiliation
5.1. Creating an Affiliation
1. The confirming operator publishes the marker, once, before its
first affiliation.
2. The confirming operator generates a token for the affiliated
domain and publishes the confirmation (Section 4.5 or Section 7).
3. The operator of the affiliated domain publishes the claim. When
the confirming domain and the affiliated domain are operated by
the same organization, one tool performs all of these steps
(Section 11.1).
Manelidis & Ramos Expires 4 May 2027 [Page 15]
Internet-Draft Domain Affiliation Confirmation October 2026
Publishing the confirmation first lets the affiliation verify as soon
as the claim is visible.
5.2. Ending an Affiliation
The confirming operator ends an affiliation by removing the
confirmation; no change at the affiliated domain is needed. A
confirming operator MUST remove the confirmation for an affiliated
domain that it no longer operates or authorizes, including when the
affiliated domain is transferred, sold, or allowed to expire, except
as described in Section 5.3. A claim left in the affiliated domain's
zone, or copied there by a later registrant, has no effect once the
confirmation is gone.
A confirming domain that withdraws from the protocol removes its
marker and any confirmations it serves over HTTPS, which ends all of
its affiliations.
5.3. Moving an Affiliated Domain to Another Confirming Domain
When an affiliated domain moves from one confirming domain to
another, for example after an acquisition, the operators proceed in
this order so that the affiliated domain remains confirmed
throughout:
1. The new confirming domain publishes its marker, if it has none,
and a confirmation for the affiliated domain under a new token.
2. The affiliated domain replaces its claim with one naming the new
confirming domain and the new token.
3. After verifying that the affiliated domain's claim names the new
confirming domain, and after the TTL of the old claim has passed
(86400 seconds if the old confirming domain does not know it),
the old confirming domain removes its confirmation.
If the affiliated domain leaves both organizations, for example
because it is sold, the confirming domain removes its confirmation no
later than the transfer (Section 5.2), and the new operator of the
affiliated domain replaces or removes the claim.
Manelidis & Ramos Expires 4 May 2027 [Page 16]
Internet-Draft Domain Affiliation Confirmation October 2026
5.4. Organizations with Several Levels
A confirming domain can itself be the affiliated domain of another
affiliation, for example when a subsidiary's primary domain is
affiliated with its group's primary domain. Each affiliation is
confirmed separately and means only what Section 8 states about that
pair: a confirmation of a confirming domain by its own confirming
domain says nothing about the affiliated domains of the former.
Verifiers MAY repeat the procedure with the confirming domain as the
affiliated domain. A verifier that does so MUST NOT follow more than
two levels beyond the first confirming domain and MUST stop if a
domain repeats.
6. Verification
6.1. Inputs and Outputs
The input is an affiliated domain in canonical form (Section 4.1).
Verifiers that accept names containing non-ASCII characters convert
them to A-labels as specified in [RFC5891]; the processing of [UTS46]
with non-transitional processing is a common way of doing so. A name
that cannot be converted yields "permerror".
The output is a result (Section 6.3) and, when available, the
confirming domain, the channel, whether the result is authenticated
(Section 6.5), whether the confirmation covers names below the
affiliated domain (Section 4.3), the relationship stated by the
confirmation (Section 4.5), the confirming domain's mode and abuse
contact, and the time for which the result may be reused
(Section 6.6).
6.2. Procedure
Verifiers MUST use a DNS interface that exposes the answer section of
responses, so that CNAME [RFC1034] and DNAME [RFC6672] records in an
answer can be detected. In the steps below, "no record" means that
the query returned NXDOMAIN, or NOERROR with no DAC record; this
includes a name that exists only as an empty non-terminal. NXDOMAIN
and NOERROR without data are treated alike because servers differ in
which they return. Other DNS outcomes are handled as described in
Section 6.4.
1. Query TXT at "_affiliation." followed by the affiliated domain.
* No record: the result is "none".
* More than one DAC record, or a malformed one: "permerror".
Manelidis & Ramos Expires 4 May 2027 [Page 17]
Internet-Draft Domain Affiliation Confirmation October 2026
* Neither a "p" nor a "t" tag: the record is only a marker, and
the result is "none".
* Only one of "p" and "t", or "p" equal to the affiliated
domain: "permerror".
2. Query TXT at "_affiliation." followed by the confirming domain.
Any "p" and "t" tags in the marker belong to the confirming
domain's own claim and are ignored here. Apply the following
checks in order.
a. The answer contains a CNAME or DNAME record: "permerror".
b. No record: "not-confirmed".
c. More than one DAC record, or a malformed one: "permerror".
d. A "c" value not supported by the verifier: "not-confirmed".
3. If the channel is "dns", query TXT at the token, followed by
"._affiliation.", followed by the confirming domain.
* No record: "not-confirmed".
* More than one DAC record, or a malformed one: "permerror".
If the channel is "https", obtain the confirmation as described
in Section 7.
4. Examine the confirmation's "d" tag.
* Missing: "permerror".
* Not equal to the affiliated domain: "not-confirmed".
* Equal to the affiliated domain, but the confirmation has an
"x" tag and the time of verification is after the end of that
day: "not-confirmed".
* Otherwise: "confirmed". If the confirmation has "s=subtree",
the verifier reports that the result covers names below the
affiliated domain. If it has "rel" with the value "same-
entity" or "third-party", the verifier reports that value.
5. Step 5 applies when step 1 yielded a claim, the query in step 2
returned NOERROR or NXDOMAIN and that answer was not validated as
secure (Section 6.5), the HTTPS channel was not used in step 3,
and steps 2 to 4 did not yield "confirmed". A verifier that
Manelidis & Ramos Expires 4 May 2027 [Page 18]
Internet-Draft Domain Affiliation Confirmation October 2026
supports the HTTPS channel MUST then obtain the confirmation as
described in Section 7 and examine it as in step 4, whatever the
marker contains and also when there is no marker. If this yields
"confirmed", that is the result, with channel "https".
Otherwise, the result of steps 2 to 4 stands; if the HTTPS
request failed with a temporary error, that result is not reused
(Section 6.6).
Step 5 lets a confirming domain whose zone is not signed with DNSSEC
obtain authenticated results (Section 6.5) by publishing its
confirmations over HTTPS, without the marker deciding whether its
HTTPS origin is consulted. For a confirming domain whose zone is
signed, a verifier that validates DNSSEC obtains a secure answer in
step 2 or, for a forged or otherwise bogus answer, "temperror"
(Section 6.4), so step 5 does not apply and the marker alone selects
the channel. A verifier that does not validate DNSSEC treats every
answer as not validated as secure.
When the result is obtained in step 5, the mode and the abuse contact
are taken from the marker if step 2 obtained a well-formed marker
that was not reached through a CNAME or DNAME record; otherwise the
mode is "enforce" and there is no abuse contact.
Domain names are compared as octet strings in canonical form. The
procedure does not query any other names, follow references found in
record content, or consult a list of public suffixes. It makes at
most one HTTPS request.
6.3. Results
confirmed: The confirming domain confirms the affiliated domain.
not-confirmed: The affiliated domain claims a confirming domain, and
the verifier did not obtain a confirmation. This covers a
confirming domain that does not participate, an ended affiliation,
a copied or fabricated claim, and a channel the verifier does not
support.
none: The affiliated domain makes no claim.
temperror: A temporary failure prevented a result; the verifier can
retry later.
permerror: A record is malformed or the configuration is invalid;
the result will not change until a record is corrected.
Only "confirmed" establishes an affiliation.
Manelidis & Ramos Expires 4 May 2027 [Page 19]
Internet-Draft Domain Affiliation Confirmation October 2026
6.4. DNS Errors
Any response code other than NOERROR and NXDOMAIN, a timeout, or a
truncated response that cannot be retried over TCP yields
"temperror". A response that fails DNSSEC validation ("bogus"
[RFC4035]) also yields "temperror" and MUST NOT contribute to a
"confirmed" result. Verifiers MUST support DNS over TCP.
6.5. Authenticated Results
Verifiers report whether a result is authenticated, and how, as one
of the following values:
dnssec: No HTTPS response was used, and all DNS answers used were
validated as secure [RFC4035], either by the verifier or by a
validating resolver reached over a trusted path.
dnssec+webpki: The marker selected the HTTPS channel, an HTTPS
response was obtained, and the claim and the marker were validated
as secure.
webpki: The result is "confirmed", the confirmation was obtained
over HTTPS, and the claim or the marker was not validated as
secure, or there was no marker.
A result to which none of these applies is not authenticated. A
"temperror" result is never authenticated.
Over HTTPS, the Web PKI authenticates the confirmation itself.
Because a "confirmed" result requires a confirmation that names the
affiliated domain, a forged marker can at most cause the verifier to
fetch a confirmation that the confirming operator published. This
depends on the confirming operator controlling every resource under
"/.well-known/affiliation/" on its origin (Section 7.1). "webpki"
does not authenticate the claim: an attacker able to forge the claim
can make a domain appear to claim a confirming domain that the
attacker operates (Section 12.11). "dnssec+webpki" also
authenticates the claim.
The abuse contact is taken from the marker and is authenticated only
when the marker is.
Manelidis & Ramos Expires 4 May 2027 [Page 20]
Internet-Draft Domain Affiliation Confirmation October 2026
6.6. Caching
A verifier MAY reuse a result for the smallest of: the TTLs [RFC2181]
of the DNS answers used, where the TTL of a negative answer is
determined as in [RFC2308]; the freshness lifetime of the HTTPS
response (Section 7.2); the time remaining until a confirmation's
expiry; and 86400 seconds. A result for which the HTTPS request of
step 5 failed with a temporary error is not reused.
After "temperror", verifiers retry with increasing intervals and
SHOULD NOT retry more often than once a minute. Resolvers that serve
stale data [RFC8767] can extend the time for which an ended
affiliation still verifies.
7. HTTPS Channel
A confirming domain can publish its confirmations as HTTPS resources
instead of DNS records, which suits operators that manage such data
through a web application rather than their DNS provider, and lets a
confirming domain whose zone is not signed obtain authenticated
results (Section 6.5). A confirming domain selects this channel with
"c=https" in its marker. For a confirming domain whose marker is not
validated as secure, verifiers that support the HTTPS channel also
consult the HTTPS resource when the DNS channel does not yield
"confirmed" (step 5 of Section 6.2), so such a domain can use this
channel without a marker; a marker with "c=https" still saves
verifiers DNS queries and conveys the mode and abuse contact. The
claim remains a DNS record.
7.1. Resource
The confirmation for a token is the resource identified by:
https://<confirming domain>/.well-known/affiliation/<token>
A confirmed token is served with status code 200 and media type
"text/plain". The content is one DAC confirmation record, with the
same syntax as in the DNS, optionally followed by a single CRLF or
LF:
Manelidis & Ramos Expires 4 May 2027 [Page 21]
Internet-Draft Domain Affiliation Confirmation October 2026
Request:
GET https://bank.example/.well-known/affiliation/
mfrggzdfmztwq2lknnwg23tpobyxe43u
Accept: text/plain
Response:
200 OK
Content-Type: text/plain
Cache-Control: max-age=3600
v=DAC1; d=embank.example
A token that is not confirmed is answered with 404 (Not Found) or 410
(Gone).
Verifiers consult this resource also for confirming domains that have
not selected the HTTPS channel (step 5 of Section 6.2). A confirming
operator MUST NOT allow other parties to create or alter resources at
or below "/.well-known/affiliation/" on its origin [RFC8615], for
example through shared hosting or an upload feature. The same
applies in practice to the operator of any domain whose zone is not
signed, since a claim can name any domain; Section 12.9 discusses the
risk.
7.2. Fetching
A verifier fetching a confirmation:
* MUST use the "https" scheme on port 443, with the confirming
domain as the host, and MUST validate the server's certificate for
that name [RFC9110] [RFC9525];
* MUST NOT follow redirects;
* MUST NOT connect to addresses that the IANA special-purpose
address registries [RFC6890] mark as not globally reachable, and
MUST connect to the address it checked;
* MUST NOT send cookies or other credentials; and
* MUST read no more than 1024 octets of content and SHOULD limit the
request to 10 seconds.
Responses are handled as follows:
Manelidis & Ramos Expires 4 May 2027 [Page 22]
Internet-Draft Domain Affiliation Confirmation October 2026
* 200 with media type "text/plain" (parameters are ignored) and
content that is exactly one DAC record: the record is the
confirmation, examined as in step 4 of Section 6.2. A malformed
record, other content, another media type, or more than 1024
octets yields "permerror".
* 404 or 410: "not-confirmed".
* 5xx, a connection failure, a timeout, or a TLS failure:
"temperror".
* Any other status code, including 3xx, or a confirming domain that
has no globally reachable address: "permerror".
The freshness lifetime of a response is zero if it carries Cache-
Control no-store or no-cache, is otherwise taken from a max-age
directive if present, and is otherwise 3600 seconds.
8. Meaning of a Confirmation
This section states what a "confirmed" result means, so that relying
parties can use it consistently. It does not prescribe relying-party
policy.
8.1. What a Confirmation States
A "confirmed" result means that, at the time of verification, the
confirming operator had published a statement that:
1. the affiliated domain is operated by the confirming operator or
by a party acting under its authority; and
2. reports of abuse concerning the affiliated domain may be directed
to the confirming operator, at the contact in the marker or by
its usual means.
With "s=subtree", both statements also apply to every name below the
affiliated domain. With "rel=same-entity", the confirming operator
also states that the affiliated domain is operated by the same legal
entity; with "rel=third-party", that it is operated by another party
acting under its authority.
The second element distinguishes an affiliation from a mere
association: a confirming domain that confirms an affiliated domain
is the expected recipient of complaints about it. The statement is
made by whoever controls the confirming domain's DNS zone or, when
the confirmation was obtained over HTTPS, its HTTPS origin.
Manelidis & Ramos Expires 4 May 2027 [Page 23]
Internet-Draft Domain Affiliation Confirmation October 2026
8.2. What a Confirmation Does Not State
A confirmation says nothing about the trustworthiness, identity, or
licensing of the confirming operator, or about the content served by
the affiliated domain. A confirmation from a confirming domain
registered yesterday is as valid as one from a long-established
organization. A confirmation therefore conveys at most the standing
that a relying party already attributes to the confirming domain. In
particular, look-alike domains that confirm one another gain nothing:
each confirmation conveys at most the standing of its own confirming
domain, and a look-alike confirming domain has none of the standing
of the name it resembles (Section 12.16).
A "rel" value is a statement by the confirming operator, not a
verified fact. DAC does not establish which legal entity operates
either domain.
8.3. Considerations for Relying Parties
* Takedown decisions. When a domain resembling a protected name is
confirmed as affiliated with a confirming domain that the relying
party already regards as legitimate, the resemblance is unlikely
to be an impersonation of the confirming domain's own name, and a
conflict with another organization's name is a dispute between
organizations. Relying parties can direct such reports to the
confirming domain's abuse contact or to the dispute processes for
name conflicts. A confirmation alone does not justify delaying
action on abuse that has been observed (Section 12.10).
* Reputation. A relying party may extend to a confirmed affiliated
domain some or all of the reputation it attributes to the
confirming domain. Attributing more standing to the affiliated
domain than to the confirming domain is inconsistent with the
meaning above, and taking abuse observed on a confirmed affiliated
domain into account when assessing the confirming domain gives
confirming operators a reason to confirm only domains they
control. A reputation system may use a confirmation as the
starting standing of a new affiliated domain, replaced by the
domain's own record as it accumulates one.
* Relationship. A relying party that treats domains differently
depending on whether they are operated by the same legal entity,
such as a registry reusing an earlier verification (Section 9),
can use the "rel" value. A confirmation without "rel" does not
indicate either relationship.
Manelidis & Ramos Expires 4 May 2027 [Page 24]
Internet-Draft Domain Affiliation Confirmation October 2026
* Testing mode. Confirmations from a confirming domain in "test"
mode are intended for reporting to the confirming domain, not for
decisions.
* Other results. "none", "not-confirmed", "temperror", and
"permerror" are not, by themselves, evidence that a domain is
malicious. Most domains publish no claim. A claim that a well-
known confirming domain does not confirm may be an attempt to
borrow its standing, but it may also result from misconfiguration
or from records an attacker caused to appear in a victim's zone
(Section 12.11).
* Assurance. Relying parties taking consequential actions can
consider whether a result was authenticated (Section 6.5) and, for
unauthenticated results, the measures in Section 12.5.
9. Reuse of Registrant Verification
A domain registry or registrar that has verified the legal entity
behind a domain, for example under a policy requiring verification of
registrants, may rely on that verification when the same organization
registers or operates another domain. DAC results can support such
reuse within the limits below. This section does not change the
procedure in Section 6.
A confirmation is a statement by the confirming operator (Section 8),
and the reuse also relies on the earlier verification of the
confirming domain's registrant. Registries and registrars reusing
verification SHOULD require an authenticated result (Section 6.5) and
verify at the time of reuse.
Delegated DNS administration:
DAC conveys the statement of whoever controls the confirming
domain's DNS zone or HTTPS origin, which can be a DNS provider, an
agency, or another company of the group rather than the verified
registrant. The registry therefore checks separately, from its
own records or from registration data, that the confirming domain
is registered to the entity it verified. A confirmation does not
show this.
Legal entities of one group:
Reusing the verification of one legal entity for a domain is
appropriate only if the same legal entity operates that domain. A
registry reusing such verification requires "rel=same-entity"
(Section 4.5). With "rel=third-party", or without "rel", the
operator of the affiliated domain is verified on its own. The
"rel" value is the confirming operator's statement and is not
verified by DAC.
Manelidis & Ramos Expires 4 May 2027 [Page 25]
Internet-Draft Domain Affiliation Confirmation October 2026
Changes of control:
A verification reflects the situation at one time. The registry
verifies the affiliation when it reuses the verification and does
not reuse it if either domain's registrant has changed since the
verification. Expiry dates tied to the registration (Section 4.5)
limit how long a forgotten confirmation remains effective.
Domains not yet registered:
A domain that is not yet registered cannot publish a claim. The
confirming operator can instead publish a confirmation for that
domain before it is registered, and the registrant gives the
registry the confirming domain and the token. The registry
performs steps 2 to 5 of Section 6.2 with that confirming domain
and token, as if they had been read from a claim, and checks that
the confirmation names the domain being registered. After
registration, the registrant publishes the claim with the same
token, and the affiliation verifies normally. If the domain is
registered by another party, the confirming operator removes the
confirmation (Section 5.2).
10. Failure Reports
A confirming domain can ask verifiers to report claims that name it
but are not confirmed, for example by a domain that copied a claim or
fabricated one. Such reports let the confirming domain learn about
attempts to borrow its standing, and about confirmations that have
expired or been removed by mistake. Sending reports is optional for
verifiers.
10.1. When Reports Are Sent
A verifier MAY send a report when it obtained the confirming domain's
marker, the marker carries an "f" tag, and the result is "not-
confirmed" or "permerror" for a reason arising after step 2 of
Section 6.2, that is, a missing, mismatched, expired, or malformed
confirmation, or a confirmation that could not be obtained over
HTTPS. Reports are not sent for "temperror" or for an unsupported
channel, nor when step 5 of Section 6.2 yields "confirmed". Reports
are particularly useful while a confirming domain is in "test" mode,
and verifiers may send them then.
A verifier MUST NOT send a report to an "f" URI that does not meet
the conditions in Section 4.4; in particular, reports go only to the
confirming domain or names below it, which prevents a marker from
directing reports at third parties. A confirming domain that wants
reports processed by a provider points a name below its domain, or
its mail routing, at that provider. Because an attacker can create
any number of affiliated domains, a verifier MUST send at most one
Manelidis & Ramos Expires 4 May 2027 [Page 26]
Internet-Draft Domain Affiliation Confirmation October 2026
message per report destination in 24 hours, combining reports into
it, and SHOULD limit the number of reports per message, for example
to 1000.
10.2. Report Format
A report is a JSON [RFC8259] array of objects, each with the
following members:
version: The string "DAC1".
observed: The time of verification, as an RFC 3339 date-time
[RFC3339] in UTC.
child: The affiliated domain, in canonical form.
parent: The confirming domain, in canonical form.
result: "not-confirmed" or "permerror".
reason: One of the values in the "DAC Report Reasons" registry
(Section 14.3.3).
reporter (optional): A domain name identifying the organization
sending the report.
[
{
"version": "DAC1",
"observed": "2026-10-22T09:30:00Z",
"child": "embank-login.example",
"parent": "bank.example",
"result": "not-confirmed",
"reason": "different-child",
"reporter": "filter.example"
}
]
Receivers ignore members and reason values they do not recognize.
10.3. Delivery
For an "https" URI, the verifier sends the report in an HTTP POST
request with media type "application/json", subject to the same
restrictions as in Section 7.2, except that the content may be up to
65536 octets. For a "mailto" URI, the verifier sends an email
message with the subject "DAC report for" followed by the confirming
domain, whose body, or one of whose body parts, is the report with
Manelidis & Ramos Expires 4 May 2027 [Page 27]
Internet-Draft Domain Affiliation Confirmation October 2026
media type "application/json". Verifiers SHOULD send report email
from a domain that authenticates its mail, so that receivers can
filter it. Failure to deliver a report is not retried more than
once.
10.4. Handling Reports
Reports are unauthenticated assertions by whoever sent them. A
confirming domain treats a report as a prompt to verify the named
affiliated domain itself, not as evidence, and rate-limits what it
accepts. Reports are not a substitute for the monitoring described
in Section 11.7.
11. Operational Considerations
11.1. Automation and Inventory
Apart from the expiry date, the records contain no dates. An
organization with many domains maintains the records with a tool that
generates tokens, writes records through its DNS providers'
interfaces, and updates expiry dates when the affiliated domains'
registrations are renewed (Section 4.5).
Affiliations go stale when domains change hands. The most reliable
control is to derive confirmations from the organization's registrar
accounts or domain inventory, so that a confirmation is removed when
its domain leaves the inventory. Registrars and DNS providers can
offer this as a service.
11.2. TTLs, Signatures, and Revocation Time
The time for an ended affiliation to stop verifying is normally
bounded by the TTL of the confirmation (or the freshness lifetime of
the HTTPS confirmation) and by the 86400-second limit in Section 6.6;
serve-stale resolvers and replay can extend it (Section 6.6,
Section 12.6). A TTL of 3600 seconds is a reasonable default. For
signed zones, the validity period of signatures over confirmation
records also bounds how long a deleted confirmation can be replayed
(Section 12.6); confirming domains wanting prompt revocation keep it
short for names below "_affiliation". The negative-caching TTL of
the confirming domain's zone affects how soon a new confirmation
becomes visible.
Manelidis & Ramos Expires 4 May 2027 [Page 28]
Internet-Draft Domain Affiliation Confirmation October 2026
11.3. Staged Deployment
A confirming domain can publish its marker with "m=test", create
confirmations, and check results before changing the marker to
"enforce". Relying parties can likewise verify in a reporting-only
mode before acting on results.
11.4. Choosing and Changing Channels
The DNS channel needs only DNS records and benefits from DNSSEC. The
HTTPS channel suits confirming domains that prefer to manage
confirmations in a web application; it requires that the confirming
domain itself serve HTTPS on port 443 without redirecting, which many
organizations' apex domains do not do by default. A confirming
domain that changes channel publishes confirmations in the new
channel before changing the marker and removes the old ones after the
marker's TTL has passed.
The primary zones of many large organizations are not signed. Such a
confirming domain obtains authenticated results ("webpki") by
publishing its confirmations over HTTPS, either with "c=https" in its
marker or without a marker (step 5 of Section 6.2). With an unsigned
marker selecting the DNS channel and DNS confirmations, results are
not authenticated.
Confirmations may be hosted by a DNS provider through CNAME records
or by delegating the "_affiliation" name; the provider can then
create and remove confirmations (Section 12.7).
11.5. Load and Scale
Verification costs at most three TXT queries and one HTTPS request.
Markers are shared by all affiliated domains of a confirming domain
and are cached accordingly. Most domains publish no claim, and for
them the cost is one query. A confirming domain using the HTTPS
channel receives a request for each verification of a claim naming it
that is not answered from a cache, and a confirming domain whose
marker is not validated as secure receives one for each such
verification not confirmed in the DNS; such confirming domains SHOULD
serve confirmations from infrastructure able to handle that load and
SHOULD set a Cache-Control max-age, also on 404 responses.
11.6. DNS Configuration
Manelidis & Ramos Expires 4 May 2027 [Page 29]
Internet-Draft Domain Affiliation Confirmation October 2026
* Confirming domains SHOULD sign their zones with DNSSEC so that
verifiers can obtain authenticated results. A signed confirming
domain's zone SHOULD use NSEC3 [RFC5155] with the parameters in
[RFC9276], compact denial of existence [RFC9824], or minimally
covering NSEC records [RFC4470], and SHOULD NOT use NSEC records
that allow the zone to be walked (Section 13).
* Confirming domains SHOULD restrict zone transfers to their own
secondary servers [RFC5936] [RFC9103].
* Confirming domains and affiliated domains MUST NOT publish
wildcard records at or below their "_affiliation" names, and
SHOULD NOT publish wildcard CNAME records that cover those names.
11.7. Monitoring
Confirming operators can check newly observed domains, for example
from Certificate Transparency logs, for claims naming their domain.
A claim carrying a token the confirming domain did not issue
indicates a domain attempting to borrow its standing; a claim for a
domain no longer in the confirming domain's inventory indicates a
confirmation that should already have been removed.
12. Security Considerations
12.1. Threat Model
The attacker wants a domain it controls to verify as affiliated with
a confirming domain it does not control, to prevent a legitimate
affiliation from verifying, to use an affiliation to delay action
against abuse, or to learn a confirming domain's affiliated domains.
The attacker can register domains, publish records in zones it
controls, place content on web hosting it has access to, observe
public DNS data, and in some cases forge or replay DNS responses on
the path to a verifier. Compromise of the confirming domain's DNS
zone or web origin is discussed in Section 12.8.
12.2. Fabricated Claims
Anyone can publish a claim naming any confirming domain. The claim
is confirmed only if a record exists under the confirming domain's
"_affiliation" node, or at the confirming domain's HTTPS origin, that
names the claiming domain. Absent forged responses (Section 12.5),
only the confirming operator, or a party able to create resources on
its HTTPS origin (Section 12.9), can create such a record.
Manelidis & Ramos Expires 4 May 2027 [Page 30]
Internet-Draft Domain Affiliation Confirmation October 2026
A fabricated claim therefore does not make an impersonating domain
appear affiliated with the organization it imitates. If the
organization's marker carries an "f" tag, verifiers can report the
claim to it with the reason "unconfirmed-token" (Section 10).
12.3. Copied Claims and Token Disclosure
Claims and tokens are public. An attacker that copies a legitimate
claim to its own domain obtains a confirmation naming the legitimate
affiliated domain, and the result is "not-confirmed". The binding
between token and affiliated domain is in the confirming domain's
confirmation, which the attacker cannot alter.
12.4. Stale Confirmations
If a confirming domain fails to remove the confirmation of an
affiliated domain that has changed hands, the new registrant of the
affiliated domain inherits the affiliation. This is the most likely
failure in practice. The requirement in Section 5.2, inventory-
driven automation (Section 11.1), and monitoring (Section 11.7)
address it. An expiry date tied to the registration (Section 4.5),
maintained by a tool that ends the confirmation when the domain is
deleted, limits the time a lapsed registration stays confirmed, but
does not help when the domain is sold before then. Relying parties
with access to registration data [RFC9083] [RFC9224] can treat a
confirmation with caution when the affiliated domain's registration
changed after the confirmation was first observed.
Likewise, if a confirming domain expires and is registered by someone
else, the new registrant can confirm arbitrary domains. Relying
parties that attribute standing to a confirming domain based on its
history can reassess a confirming domain whose registration has
changed rather than carrying standing across the change.
12.5. Forged DNS Responses
An attacker able to forge DNS responses to a verifier, for example
through cache poisoning [RFC5452] or by hijacking routes to
authoritative servers, can produce any result for unsigned zones.
For the DNS channel, the forgery has to cover the confirming domain's
records; forging the claim alone cannot produce "confirmed".
Forging the marker of an unsigned zone, or the marker of any zone
toward a verifier that does not validate DNSSEC, can switch the
channel or change the mode, for example by removing "m=test".
Switching to the DNS channel helps the attacker only together with
forged confirmation records, and the result is then not
authenticated. Switching to the HTTPS channel, or removing the
Manelidis & Ramos Expires 4 May 2027 [Page 31]
Internet-Draft Domain Affiliation Confirmation October 2026
marker, causes the verifier to fetch the confirmation from the
confirming domain's HTTPS origin, where the Web PKI protects against
forged DNS answers: the result is "confirmed" only if that origin
serves a confirmation naming the affiliated domain. This is why the
fixed HTTPS resource is consulted for unsigned zones whatever the
marker says (step 5 of Section 6.2), and why no party other than the
confirming operator may create resources under it (Section 7.1).
Results authenticated with DNSSEC or the Web PKI are not affected by
forged DNS responses for the records they authenticate (Section 6.5).
Relying parties taking consequential actions on unauthenticated
results can perform the queries from several network locations and
require the answers to agree, as certification authorities are
required to do for domain validation [CABF-BR].
12.6. Replay of Deleted Records
An attacker on the path to a verifier can replay a confirmation that
the confirming domain has deleted. For unsigned zones, any response
can be forged anyway. For signed zones, a replayed RRset validates
until its signatures expire, which can be weeks. Confirming domains
that want deletion to take effect promptly against such attackers use
short signature validity periods for names below "_affiliation"
(Section 11.2). A confirmation with an expiry date cannot be
replayed to effect beyond that date.
12.7. Wildcards, Aliases, and Delegation
If a confirming domain's zone contained a wildcard such as
"*.bank.example" and no "_affiliation" node existed, queries for
confirmation names would be answered from the wildcard [RFC4592]. If
that wildcard were a CNAME into a zone operated by a third party,
such as a hosting platform, a tenant of that platform might be able
to publish a TXT record there confirming a domain of its choosing.
The marker prevents this: since its owner name exists, a wildcard
above it cannot match names below it, and verifiers reject a marker
reached through a CNAME or DNAME record. An empty non-terminal at
"_affiliation" also blocks the wildcard, and the result is "not-
confirmed" unless a confirmation is obtained over HTTPS in step 5 of
Section 6.2.
Confirmation names may be CNAMEs, and the "_affiliation" name may be
delegated or carry a DNAME record. The operator of the target or
delegated zone can then create and remove confirmations. Confirming
domains delegate in this way only to parties they would trust to
publish confirmations on their behalf.
Manelidis & Ramos Expires 4 May 2027 [Page 32]
Internet-Draft Domain Affiliation Confirmation October 2026
12.8. Compromise of the Confirming Domain
An attacker controlling the confirming domain's DNS zone can confirm
any domain; it can also redirect the confirming domain itself, so DAC
does not add to the consequences of that compromise. An attacker
controlling only the confirming domain's web origin, or able to
create resources under "/.well-known/affiliation/" on it, can confirm
domains through the HTTPS channel when the confirming domain's marker
selects that channel or is not validated as secure (Section 6.2). A
confirming domain whose zone is signed and whose marker selects the
DNS channel is not exposed in this way to verifiers that validate
DNSSEC. Verifiers report the channel used, and relying parties
concerned about web compromise can give less weight to confirmations
obtained over HTTPS. A confirming domain can detect confirmations it
did not create by comparing them with its inventory, and recovers by
deleting them.
12.9. HTTPS Resources Created by Others
Verifiers consult "/.well-known/affiliation/" on the HTTPS origin of
any confirming domain whose marker is not validated as secure (step 5
of Section 6.2). A party able to create resources there can
therefore confirm domains in that domain's name, whether or not its
operator takes part in DAC. Examples are web hosting shared by
several customers, upload features that store files at paths the
uploader chooses, and content delivery configurations that pass
unknown paths to a customer's server. Other uses of fixed paths on
an origin, such as the "http-01" challenge of ACME [RFC8555], carry
the same exposure. Confirming operators MUST NOT allow it
(Section 7.1). Operators of other origins that let others create
resources at arbitrary paths can avoid it by signing their zones or
by answering every request under "/.well-known/affiliation/" with 404
(Not Found). Relying parties concerned about this risk can give less
weight to "webpki" results for confirming domains whose web content
is not under their operator's sole control.
12.10. Use of Affiliations to Deflect Takedowns
An attacker that controls a confirming domain to which relying
parties attribute standing, for example an expired domain re-
registered for its history or a compromised DNS account, can confirm
look-alike domains used for phishing. Takedown requests may then be
directed to an abuse contact that the attacker controls. Relying
parties should not let a confirmation alone delay action against
abuse they have observed, and can reassess confirming domains whose
registration has changed (Section 12.4) or whose set of confirmed
domains grows unexpectedly.
Manelidis & Ramos Expires 4 May 2027 [Page 33]
Internet-Draft Domain Affiliation Confirmation October 2026
12.11. Inducing Adverse Results
An attacker able to place a TXT record at "_affiliation" under a
victim's domain, for example through a dangling or wildcard CNAME in
the victim's zone pointing to a platform the attacker uses, controls
the victim's claim. It can make the victim appear to claim a
confirming domain that does not confirm it, which is one reason why
results other than "confirmed" are not by themselves evidence of
malice (Section 8.3). It can also name a confirming domain the
attacker operates and confirm the claim there, making the victim
appear affiliated with the attacker and directing abuse reports about
the victim to the attacker's contact. Affiliated domains therefore
MUST NOT publish wildcards covering their "_affiliation" name
(Section 11.6) and SHOULD make their claim name a CNAME only to names
they or their confirming operator control.
12.12. Resource Consumption
Verification is bounded at three TXT queries and one HTTPS request
with its address resolution, with no recursion and no references in
record content, avoiding the lookup-limit problems experienced with
[RFC7208]; following several levels (Section 5.4) is bounded at nine
queries and three HTTPS requests.
An attacker can publish claims with random tokens naming a
participating confirming domain, so that each verification causes a
query for a new name at the confirming domain's authoritative
servers, or a request to its HTTPS origin. Claims naming a
confirming domain whose marker is not validated as secure cause an
HTTPS request even if that domain does not participate (step 5 of
Section 6.2); verifiers cache the response, including 404 responses,
for its freshness lifetime. Aggressive use of DNSSEC-validated
caches [RFC8198] can absorb such queries only where denial of
existence covers ranges of names; the configurations recommended in
Section 11.6 to prevent zone walking, and unsigned zones, give up
that protection, so confirming domains using them depend on verifiers
limiting their query rates. Verifiers that accept names to verify
from untrusted sources SHOULD rate-limit the queries and requests
they send for each confirming domain.
12.13. Subtree Confirmations
A subtree confirmation extends the confirming domain's statement to
names that the confirming domain does not list individually. If
anyone other than the confirming domain's organization can create
names below the affiliated domain, for example because the affiliated
domain offers subdomains to customers or has a delegation or wildcard
record pointing to a third party, those parties' names would appear
Manelidis & Ramos Expires 4 May 2027 [Page 34]
Internet-Draft Domain Affiliation Confirmation October 2026
affiliated with the confirming domain. A subtree confirmation is
also not evidence about the content of any particular name below the
affiliated domain; abuse observed there is handled as in
Section 12.10. This is why confirming domains include "s=subtree"
only for affiliated domains whose entire namespace they control
(Section 4.3). A dangling record below the affiliated domain, such
as a CNAME to a deprovisioned cloud resource, has the same effect if
taken over, so confirming domains using subtree confirmations keep
the affiliated domain's zone free of such records.
12.14. Failure Reports
An attacker can publish many claims naming a confirming domain so
that verifiers send reports to it; the per-destination limit in
Section 10.1 and rate limiting at the confirming domain bound the
effect. Restricting report destinations to the confirming domain's
own names prevents markers from being used to direct reports at third
parties. A forged marker can direct reports from a verifier to a
name chosen by the attacker only within the same limits as other
forged responses (Section 12.5). Reports are never evidence that a
domain is malicious (Section 10.4).
12.15. Expiry Dates
Expiry dates are evaluated against the verifier's clock. An expiry
date limits how long a forgotten confirmation remains effective but
does not replace removing confirmations (Section 5.2).
12.16. Confusable Names
An attacker can create its own confirming domain and affiliated
domains with names resembling a legitimate organization's, and
confirm them, including in a chain in which each look-alike confirms
the next. Their affiliations verify, but convey only the standing of
the attacker's confirming domains, which is none of the standing of
the names they resemble (Section 8.2). The legitimate organization
is not involved and receives no reports about them. User interfaces
that display affiliations SHOULD display names in a form that makes
confusable characters evident [UTS39].
13. Privacy Considerations
A claim publicly discloses that the affiliated domain declares an
affiliation with the confirming domain; this disclosure is the
purpose of the claim. The confirming domain publishes no list of its
domains: a query at the confirming domain reveals nothing about which
affiliated domains exist, and confirmations can be located only from
the corresponding claims. A third party can still find affiliated
Manelidis & Ramos Expires 4 May 2027 [Page 35]
Internet-Draft Domain Affiliation Confirmation October 2026
domains by examining domains one by one, for example those listed in
Certificate Transparency logs or zone files, so organizations should
assume that every domain publishing a claim is discoverable. Domains
that publish no claim, such as names held defensively or not yet
launched, are not revealed.
This property depends on confirmation names not being enumerable.
Zone transfers and DNSSEC denial of existence using NSEC records can
reveal them; NSEC3 hashes of names containing random tokens of 128
bits or more cannot feasibly be reversed. Section 11.6 gives
recommendations.
Queries reveal to resolver operators, and to passive DNS collections,
which domains a verifier is evaluating. QNAME minimisation [RFC9156]
reduces exposure of full names to servers higher in the DNS tree. An
HTTPS request, including one made in step 5 of Section 6.2 to a
confirming domain that does not participate, reveals to the
confirming domain's web servers that one of its affiliated domains,
or a domain claiming it, is being evaluated, and reveals the token.
Failure reports disclose to the confirming domain which of the
verifier's evaluations involved claims naming the confirming domain.
Verifiers that do not wish to disclose this do not send reports, and
the reports contain no information about why an evaluation took
place.
The abuse contact in the marker is published, and confirming domains
SHOULD use role addresses. Publishers SHOULD NOT include personal
data in records.
14. IANA Considerations
14.1. Underscored and Globally Scoped DNS Node Name
IANA is requested to add the following entry to the "Underscored and
Globally Scoped DNS Node Names" registry [RFC8552]:
+=========+==============+===========+
| RR Type | _NODE NAME | Reference |
+=========+==============+===========+
| TXT | _affiliation | RFC XXXX |
+---------+--------------+-----------+
Table 1: Underscored Node Name
Manelidis & Ramos Expires 4 May 2027 [Page 36]
Internet-Draft Domain Affiliation Confirmation October 2026
14.2. Well-Known URI
IANA is requested to register the following in the "Well-Known URIs"
registry [RFC8615]:
URI Suffix: affiliation
Change Controller: IETF
Specification Document: RFC XXXX, Section 7
Status: permanent
Related Information: None
14.3. Domain Affiliation Confirmation Registry Group
IANA is requested to create a registry group titled "Domain
Affiliation Confirmation (DAC)" containing the four registries below.
Registrations in all four are made under the Specification Required
policy [RFC8126].
14.3.1. DAC Tags
Each entry contains a tag name matching the "tag-name" rule, the
record in which it appears (claim, marker, or confirmation; a tag may
appear in more than one), a short description, and a reference. The
designated expert checks that the tag is clearly defined and that
verifiers that ignore it remain interoperable. The initial contents
are:
Manelidis & Ramos Expires 4 May 2027 [Page 37]
Internet-Draft Domain Affiliation Confirmation October 2026
+=====+=============================+===================+===========+
| Tag | Record | Description | Reference |
+=====+=============================+===================+===========+
| v | claim, marker, confirmation | version | RFC XXXX |
+-----+-----------------------------+-------------------+-----------+
| p | claim | confirming | RFC XXXX |
| | | domain | |
+-----+-----------------------------+-------------------+-----------+
| t | claim | token | RFC XXXX |
+-----+-----------------------------+-------------------+-----------+
| c | marker | confirmation | RFC XXXX |
| | | channel | |
+-----+-----------------------------+-------------------+-----------+
| r | marker | abuse | RFC XXXX |
| | | contact URI | |
+-----+-----------------------------+-------------------+-----------+
| m | marker | mode | RFC XXXX |
+-----+-----------------------------+-------------------+-----------+
| d | confirmation | affiliated | RFC XXXX |
| | | domain | |
+-----+-----------------------------+-------------------+-----------+
| s | confirmation | scope | RFC XXXX |
+-----+-----------------------------+-------------------+-----------+
| x | confirmation | expiry date | RFC XXXX |
+-----+-----------------------------+-------------------+-----------+
| rel | confirmation | relationship | RFC XXXX |
+-----+-----------------------------+-------------------+-----------+
| f | marker | failure | RFC XXXX |
| | | report URI | |
+-----+-----------------------------+-------------------+-----------+
Table 2: Initial DAC Tags
14.3.2. DAC Confirmation Channels
Each entry contains a channel name consisting of lowercase letters,
digits, and hyphens, a short description, and a reference. The
designated expert checks that the specification states how a
confirmation is obtained, which outcomes map to which results, and
the security properties of the channel. The initial contents are:
Manelidis & Ramos Expires 4 May 2027 [Page 38]
Internet-Draft Domain Affiliation Confirmation October 2026
+=========+=================================+===========+
| Channel | Description | Reference |
+=========+=================================+===========+
| dns | TXT record under the confirming | RFC XXXX |
| | domain's "_affiliation" name | |
+---------+---------------------------------+-----------+
| https | Resource under "/.well-known/ | RFC XXXX |
| | affiliation/" | |
+---------+---------------------------------+-----------+
Table 3: Initial DAC Confirmation Channels
14.3.3. DAC Report Reasons
Each entry contains a reason value consisting of lowercase letters,
digits, and hyphens, a short description, and a reference. The
designated expert checks that the reason describes a distinct outcome
of the procedure in Section 6.2 or of a channel. The initial
contents are:
+========================+========================+===========+
| Reason | Description | Reference |
+========================+========================+===========+
| unconfirmed-token | No confirmation exists | RFC XXXX |
| | for the claim's token | |
+------------------------+------------------------+-----------+
| different-child | The confirmation names | RFC XXXX |
| | another domain | |
+------------------------+------------------------+-----------+
| expired | The confirmation's | RFC XXXX |
| | expiry date has passed | |
+------------------------+------------------------+-----------+
| malformed-confirmation | The confirmation is | RFC XXXX |
| | malformed, not unique, | |
| | or cannot be obtained | |
+------------------------+------------------------+-----------+
Table 4: Initial DAC Report Reasons
14.3.4. DAC Relationship Values
Each entry contains a value of the "rel" tag consisting of lowercase
letters, digits, and hyphens, a short description, and a reference.
The designated expert checks that the value states a relationship
between the operators of the two domains that is distinct from those
already registered. The initial contents are:
Manelidis & Ramos Expires 4 May 2027 [Page 39]
Internet-Draft Domain Affiliation Confirmation October 2026
+=============+=====================================+===========+
| Value | Description | Reference |
+=============+=====================================+===========+
| same-entity | Operated by the legal entity that | RFC XXXX |
| | operates the confirming domain | |
+-------------+-------------------------------------+-----------+
| third-party | Operated by another party under the | RFC XXXX |
| | confirming operator's authority | |
+-------------+-------------------------------------+-----------+
Table 5: Initial DAC Relationship Values
15. Implementation Status
This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Organization: The first author.
Implementation: "dac", a library and command-line tool in Go:
https://github.com/tastypepperoni/dac.
Description: A verifier implementing Section 6 and Section 7 with
its own DNS client, including step 5 of Section 6.2 and the check
of a domain before it is registered (Section 9); failure reporting
(Section 10); a publisher that maintains an inventory of
affiliations, generates claims, markers and confirmations with
"rel" values, and keeps expiry dates no later than the
registration expiry using RDAP or dates entered by the operator
Manelidis & Ramos Expires 4 May 2027 [Page 40]
Internet-Draft Domain Affiliation Confirmation October 2026
(Section 4.5); a server for the HTTPS channel; checks of published
records; and a test DNS server. All test vectors of Appendix C
are automated tests, and every record example in this document is
checked against the ABNF in Section 4.1.
Level of maturity: Prototype; not yet deployed.
Coverage: All of the protocol.
Licensing: BSD 3-Clause.
Contact: The first author.
16. References
16.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
Manelidis & Ramos Expires 4 May 2027 [Page 41]
Internet-Draft Domain Affiliation Confirmation October 2026
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<https://www.rfc-editor.org/info/rfc6068>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
Manelidis & Ramos Expires 4 May 2027 [Page 42]
Internet-Draft Domain Affiliation Confirmation October 2026
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
16.2. Informative References
Manelidis & Ramos Expires 4 May 2027 [Page 43]
Internet-Draft Domain Affiliation Confirmation October 2026
[CABF-BR] CA/Browser Forum, "Baseline Requirements for the Issuance
and Management of Publicly-Trusted TLS Server
Certificates", <https://cabforum.org/working-
groups/server/baseline-requirements/requirements/>.
[I-D.barrett-dnsop-domain-set]
Barrett, T., Schaub, C., Barrett, A., and P. Kowalik, "The
Domain Set Discovery Protocol (domain-set)", Work in
Progress, Internet-Draft, draft-barrett-dnsop-domain-set-
00, 20 August 2026,
<https://datatracker.ietf.org/doc/html/draft-barrett-
dnsop-domain-set-00>.
[I-D.brotman-rdbd]
Brotman, A. and S. Farrell, "Related Domains By DNS", Work
in Progress, Internet-Draft, draft-brotman-rdbd-03, 18
September 2019, <https://datatracker.ietf.org/doc/html/
draft-brotman-rdbd-03>.
[I-D.ietf-dnsop-domain-verification-techniques]
Sahib, S., Huque, S., Wouters, P., and E. Nygren, "Domain
Control Validation using DNS", Work in Progress, Internet-
Draft, draft-ietf-dnsop-domain-verification-techniques-13,
22 June 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-dnsop-domain-verification-techniques-13>.
[I-D.ietf-regext-epp-same-entity]
Galvin, J. and M. Bauland, "Same Entity Set Support for
the Extensible Provisioning Protocol (EPP)", Work in
Progress, Internet-Draft, draft-ietf-regext-epp-same-
entity-01, 13 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
epp-same-entity-01>.
[I-D.ihsanullah-dnsid]
Ihsanullah, N., "DNS-Anchored Durable Identity for AI
Agents (DNSid)", Work in Progress, Internet-Draft, draft-
ihsanullah-dnsid-01, 29 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ihsanullah-
dnsid-01>.
[I-D.mozleywilliams-dnsop-dnsaid]
Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J.
Damick, "DNS for AI Discovery", Work in Progress,
Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27
May 2026, <https://datatracker.ietf.org/doc/html/draft-
mozleywilliams-dnsop-dnsaid-02>.
Manelidis & Ramos Expires 4 May 2027 [Page 44]
Internet-Draft Domain Affiliation Confirmation October 2026
[I-D.tjw-dbound2-problem-statement]
Wicinski, T., Ed., "Domain Boundaries 2.0 Problem
Statement", Work in Progress, Internet-Draft, draft-tjw-
dbound2-problem-statement-00, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-tjw-dbound2-
problem-statement-00>.
[ITCHIO] Video Games Chronicle, "Funko and BrandShield say it
wasn't their fault itch.io was taken offline, site creator
says otherwise", December 2024,
<https://videogameschronicle.com/news/funko-and-
brandshield-say-it-wasnt-their-fault-itch-io-was-taken-
offline-site-creator-says-otherwise>.
[PSL] Mozilla Foundation, "Public Suffix List",
<https://publicsuffix.org/>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<https://www.rfc-editor.org/info/rfc2606>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343,
DOI 10.17487/RFC4343, January 2006,
<https://www.rfc-editor.org/info/rfc4343>.
[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
and DNSSEC On-line Signing", RFC 4470,
DOI 10.17487/RFC4470, April 2006,
<https://www.rfc-editor.org/info/rfc4470>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452,
DOI 10.17487/RFC5452, January 2009,
<https://www.rfc-editor.org/info/rfc5452>.
Manelidis & Ramos Expires 4 May 2027 [Page 45]
Internet-Draft Domain Affiliation Confirmation October 2026
[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch,
Ed., "Design Choices When Expanding the DNS", RFC 5507,
DOI 10.17487/RFC5507, April 2009,
<https://www.rfc-editor.org/info/rfc5507>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework
(SPF) and Sender ID Experiments", RFC 6686,
DOI 10.17487/RFC6686, July 2012,
<https://www.rfc-editor.org/info/rfc6686>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8056] Gould, J., "Extensible Provisioning Protocol (EPP) and
Registration Data Access Protocol (RDAP) Status Mapping",
RFC 8056, DOI 10.17487/RFC8056, January 2017,
<https://www.rfc-editor.org/info/rfc8056>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8767] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
to Improve DNS Resiliency", RFC 8767,
DOI 10.17487/RFC8767, March 2020,
<https://www.rfc-editor.org/info/rfc8767>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
Manelidis & Ramos Expires 4 May 2027 [Page 46]
Internet-Draft Domain Affiliation Confirmation October 2026
[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
Mankin, "DNS Zone Transfer over TLS", RFC 9103,
DOI 10.17487/RFC9103, August 2021,
<https://www.rfc-editor.org/info/rfc9103>.
[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
Name Minimisation to Improve Privacy", RFC 9156,
DOI 10.17487/RFC9156, November 2021,
<https://www.rfc-editor.org/info/rfc9156>.
[RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
[RFC9276] Hardaker, W. and V. Dukhovni, "Guidance for NSEC3
Parameter Settings", BCP 236, RFC 9276,
DOI 10.17487/RFC9276, August 2022,
<https://www.rfc-editor.org/info/rfc9276>.
[RFC9824] Huque, S., Elmerot, C., and O. Gudmundsson, "Compact
Denial of Existence in DNSSEC", RFC 9824,
DOI 10.17487/RFC9824, September 2025,
<https://www.rfc-editor.org/info/rfc9824>.
[RFC9989] Herr, T., Ed. and J. Levine, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC)",
RFC 9989, DOI 10.17487/RFC9989, May 2026,
<https://www.rfc-editor.org/info/rfc9989>.
[RWS] Web Platform Incubator Community Group, "Related Website
Sets", <https://github.com/WICG/first-party-sets>.
[UTS39] Davis, M. and M. Suignard, "Unicode Security Mechanisms",
Unicode Technical Standard #39,
<https://www.unicode.org/reports/tr39/>.
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", Unicode Technical Standard #46,
<https://www.unicode.org/reports/tr46/>.
Appendix A. Design Rationale
Manelidis & Ramos Expires 4 May 2027 [Page 47]
Internet-Draft Domain Affiliation Confirmation October 2026
A.1. Why TXT Records
[RFC5507] discourages overloading TXT records, mainly because
unrelated uses collide at the same owner name. DAC uses a dedicated
underscored name [RFC8552] and a version tag, which avoid that
collision. A dedicated resource record type would remove the need
for version-tag parsing, and authoritative servers handle unknown
types [RFC3597]. TXT was chosen because DNS provisioning interfaces
used by domain operators support it universally, and because
experience with the dedicated SPF type [RFC6686], which [RFC7208]
removed, showed the deployment cost of requiring one. The data model
is simple enough that a dedicated type could be added later without
changing it.
Verifiers query TXT records only at fixed names under the two domains
concerned, formed with "_affiliation" and, for confirmations, a
token. No name is found by walking up or across the DNS tree, so the
difficulties of discovering policy at arbitrary points in the tree do
not arise.
A.2. Why Not a List of Domains
If the confirming domain published a list of its domains, a single
query at the confirming domain would disclose the organization's
entire portfolio at once, including domains not otherwise easy to
find, which is a ready-made target list for attackers and can reveal
products before launch. Every new domain would require editing a
shared record, and the list would be bounded by record size or moved
to a separate document fetched over HTTPS, adding a dependency.
Hashing list entries does not help, because domain names are
guessable. Confirmations per affiliated domain reveal nothing at the
confirming domain and are each located only from a claim.
A.3. Why Not Signatures
A confirming domain could publish a public key and sign each
affiliated domain's name, with the signature published by the
affiliated domain, so that the confirming domain's zone would not
change per affiliated domain. Signatures remain valid after an
affiliated domain changes hands, however, so they need expiry dates,
periodic re-signing of every affiliated domain, revocation lists for
urgent cases, and procedures for key rotation and compromise. DAC
instead relies on the confirming domain's existing control of its DNS
zone or web origin, at the cost of one record per affiliated domain
at the confirming domain.
Manelidis & Ramos Expires 4 May 2027 [Page 48]
Internet-Draft Domain Affiliation Confirmation October 2026
A.4. Why the Procedure Does Not Use the Public Suffix List
Mechanisms that infer relationships between names depend on the
Public Suffix List [PSL], a community-maintained list without a
standard update model; [RFC9989] replaced its use in DMARC for this
reason. DAC infers nothing: each confirmation requires a record that
only the confirming operator can publish. A claim naming a public
suffix as its confirming domain is confirmed only if that suffix's
operator confirms it. Relying parties may still use boundary
information to decide which names to evaluate and how to attribute
standing.
A.5. Why Affiliation Is Not Transitive Across Organizations
A mechanism in which organizations vouch for one another, with
vouching that propagates, lets an attacker gain standing by
compromising or paying any participant, dilutes the meaning of each
step, and makes revocation depend on parties who may not know about
the chain. DAC expresses only that one operator operates or
authorizes a domain. The protocol cannot tell whether two levels
belong to the same organization, which is why a confirmation says
nothing about the confirmed domain's own affiliated domains
(Section 5.4).
A.6. Why One Confirming Domain per Affiliated Domain
In designs where every member of a group lists, and must be confirmed
by, every other member, each new domain requires changes at every
member, and a verifier must compute the group as the closure of
pairwise links, at a cost that grows with the size of the group and
has to be capped by arbitrary limits. DAC relates each affiliated
domain to exactly one confirming domain, so adding a domain changes
two records and verification has a fixed cost. Organizations with
several levels are handled one affiliation at a time (Section 5.4).
A.7. Why Authentication Is Reported Rather Than Required
Requiring DNSSEC or an HTTPS origin on both sides of every
relationship would exclude most domains, including names held
defensively that serve no content, and would make the mechanism
unusable for most of the organizations it is meant to help. DAC
instead reports whether each result is authenticated (Section 6.5),
so that relying parties can require authentication where their
decisions warrant it.
The primary zones of many large organizations are not signed, so
DNSSEC alone would leave most confirming domains without
authenticated results. The Web PKI authenticates a confirmation
Manelidis & Ramos Expires 4 May 2027 [Page 49]
Internet-Draft Domain Affiliation Confirmation October 2026
obtained over HTTPS whatever selected the channel, because a
"confirmed" result requires a confirmation that names the affiliated
domain. What an attacker could still forge is the decision whether
to consult the HTTPS origin. The procedure therefore consults the
fixed HTTPS resource whenever the marker is not validated as secure
and the DNS channel does not yield "confirmed" (Section 6.2), so that
a forged or removed marker cannot hide an HTTPS confirmation or
select a resource the confirming operator does not control
(Section 7.1). Toward verifiers that validate DNSSEC, a signed
confirming domain keeps full control of the channel through its
marker.
A.8. Why Confirmations Are Not Bound to Registration Data
A confirmation could carry data identifying the affiliated domain's
registration or DNS configuration, such as a digest of its DNSSEC key
or its name servers, so that it stops verifying when that data
changes. Such data changes for many reasons other than a change of
hands, such as key rollovers and changes of DNS provider, and is
often shared by unrelated domains, such as the name servers of a
registrar or DNS provider. Each such change would end affiliations
that should continue, while a new registrant using the same provider
could keep them. DAC instead recommends an expiry date tied to the
registration, extended only on renewal (Section 4.5), and relies on
the confirming operator to remove confirmations when a domain changes
hands (Section 5.2).
A profile for a specific use, such as DNSSEC-signed domains operated
for software agents, may add a binding to the affiliated domain's
key, as a tag registered as described in Section 14.3.1.
A.9. Why the Relationship Is Optional
Most relying parties need only the statement that the confirming
operator operates or authorizes the affiliated domain (Section 8).
Some, such as registries reusing a verification of a legal entity
(Section 9), need to know whether the same legal entity operates both
domains. The "rel" tag lets the confirming operator state this
without changing the meaning of confirmations that omit it, so
confirmations published without it remain valid, and verifiers that
do not recognize it ignore it.
Manelidis & Ramos Expires 4 May 2027 [Page 50]
Internet-Draft Domain Affiliation Confirmation October 2026
A.10. Why No Aggregators
DAC needs no index, registry of relationships, or submission service.
Every verifier obtains results directly from the domains concerned,
so there is no additional party to operate, trust, or keep current,
and no endpoint that can be used to make a service send traffic to
arbitrary domains. Claims can still cause verifiers to send queries
and HTTPS requests to the domains they name (Section 12.12).
Aggregators can be built on DAC, but nothing depends on them.
A.11. Why the Meaning of a Confirmation Is Defined
A mechanism that declares a relationship between domains, but whose
specification forbids relying parties to draw conclusions from it,
gives those parties nothing to act on, and the problems in
Section 1.1 remain. DAC addresses a specific operational problem
with intended consumers, takedown services and reputation systems,
and states what a confirmation means (Section 8), including where
reports of abuse are to be sent. It also bounds that meaning: a
confirmation conveys no more standing than the confirming domain
already has (Section 8.2). The authors invite operators of such
services to comment on whether the stated meaning meets their needs.
Appendix B. Complete Example
The operator of bank.example launches embank.example and uses the DNS
channel.
; In the bank.example zone (once):
_affiliation.bank.example. 3600 IN TXT
"v=DAC1; r=mailto:abuse@bank.example"
; In the bank.example zone (per affiliated domain):
mfrggzdfmztwq2lknnwg23tpobyxe43u._affiliation.bank.example.
3600 IN TXT "v=DAC1; d=embank.example"
; In the embank.example zone:
_affiliation.embank.example. 3600 IN TXT
"v=DAC1; p=bank.example; t=mfrggzdfmztwq2lknnwg23tpobyxe43u"
A verifier evaluating embank.example:
1. queries TXT at _affiliation.embank.example and obtains confirming
domain "bank.example" and the token;
2. queries TXT at _affiliation.bank.example and obtains the marker:
channel "dns", mode "enforce", contact
"mailto:abuse@bank.example";
Manelidis & Ramos Expires 4 May 2027 [Page 51]
Internet-Draft Domain Affiliation Confirmation October 2026
3. queries TXT at
mfrggzdfmztwq2lknnwg23tpobyxe43u._affiliation.bank.example and
obtains "d=embank.example", which equals the affiliated domain.
The result is "confirmed", reusable for 3600 seconds, and
authenticated ("dnssec") if all three answers validate as secure. If
embank.example is operated by the same legal entity as bank.example,
the confirmation can state this as "v=DAC1; d=embank.example;
rel=same-entity".
If the bank.example zone is not signed, its operator can instead
serve the confirmation at https://bank.example/.well-known/
affiliation/ followed by the token (Section 7). A verifier that
finds no confirmation in the DNS then fetches that resource, and the
result is "confirmed" over HTTPS, authenticated as "webpki".
A mail filter assessing "statements.embank.example" verifies
"embank.example", the domain it already treats as responsible for
that name. Because the confirmation above has no "s" tag, the result
states nothing about "statements.embank.example" itself. If
bank.example operates every name under embank.example, it publishes
the confirmation as "v=DAC1; d=embank.example; s=subtree", and the
result covers "statements.embank.example" too.
An attacker registers embank-login.example and publishes a copy of
the claim. Step 3 returns "d=embank.example", which differs from
"embank-login.example", so the result is "not-confirmed". When the
operator of bank.example sells embank.example, it deletes the
confirmation; from then on, embank.example yields "not-confirmed"
whatever its new operator publishes.
Appendix C. Test Vectors
Each vector describes a change to the data of Appendix B and the
expected result for the affiliated domain "embank.example" (in vector
6, "embank-login.example"). T is the example token. Unless a vector
says otherwise, no answer validates as secure, and requests for
resources under "/.well-known/affiliation/" at bank.example yield
404, so step 5 of Section 6.2 does not change the result of vectors 1
to 60. "Unauthenticated" means a "confirmed" result that is not
authenticated (Section 6.5). The reference implementation
(Section 15) runs these vectors as tests.
Manelidis & Ramos Expires 4 May 2027 [Page 52]
Internet-Draft Domain Affiliation Confirmation October 2026
+==+==============================================+===============+
|# | Change from the example |Result |
+==+==============================================+===============+
|1 | None |confirmed |
+--+----------------------------------------------+---------------+
|2 | No claim at the affiliated domain |none |
+--+----------------------------------------------+---------------+
|3 | Affiliated domain has only "v=spf1 -all" |none |
+--+----------------------------------------------+---------------+
|4 | Affiliated domain has "v=DAC10; |none |
| | p=bank.example; t=T" | |
+--+----------------------------------------------+---------------+
|5 | No marker at the confirming domain |not-confirmed |
+--+----------------------------------------------+---------------+
|6 | Affiliated domain is embank-login.example |not-confirmed |
| | with a copy of the claim | |
+--+----------------------------------------------+---------------+
|7 | Claim carries a token the confirming domain |not-confirmed |
| | never issued | |
+--+----------------------------------------------+---------------+
|8 | Confirmation deleted |not-confirmed |
+--+----------------------------------------------+---------------+
|9 | Marker name is an empty non-terminal |not-confirmed |
| | (NOERROR, no data) | |
+--+----------------------------------------------+---------------+
|10| Marker answer contains a CNAME |permerror |
+--+----------------------------------------------+---------------+
|11| Marker answer contains a CNAME and no TXT |permerror |
| | data | |
+--+----------------------------------------------+---------------+
|12| Claim answer contains a CNAME |confirmed |
+--+----------------------------------------------+---------------+
|13| Confirmation answer contains a CNAME |confirmed |
+--+----------------------------------------------+---------------+
|14| Two DAC records at the claim name |permerror |
+--+----------------------------------------------+---------------+
|15| Two DAC records at the confirmation name |permerror |
+--+----------------------------------------------+---------------+
|16| Confirmation repeats the "d" tag |permerror |
+--+----------------------------------------------+---------------+
|17| Confirmation has no "d" tag |permerror |
+--+----------------------------------------------+---------------+
|18| Token in uppercase |permerror |
+--+----------------------------------------------+---------------+
|19| Token of 8 characters |permerror |
+--+----------------------------------------------+---------------+
|20| Token of 26 characters, confirmed under that |confirmed |
| | token | |
Manelidis & Ramos Expires 4 May 2027 [Page 53]
Internet-Draft Domain Affiliation Confirmation October 2026
+--+----------------------------------------------+---------------+
|21| Claim has "p=Bank.Example." |permerror |
+--+----------------------------------------------+---------------+
|22| Claim has an additional tag "z=future" |confirmed |
+--+----------------------------------------------+---------------+
|23| Claim repeats the "p" tag |permerror |
+--+----------------------------------------------+---------------+
|24| Claim names embank.example as its confirming |permerror |
| | domain | |
+--+----------------------------------------------+---------------+
|25| Confirming domain is the single-label name |confirmed |
| | "bank" | |
+--+----------------------------------------------+---------------+
|26| Claim has "p=192.0.2.1" |permerror |
+--+----------------------------------------------+---------------+
|27| Marker has "m=test" |confirmed, mode|
| | |test |
+--+----------------------------------------------+---------------+
|28| Marker has "m=other" |confirmed, mode|
| | |test |
+--+----------------------------------------------+---------------+
|29| Confirmation has "s=subtree" |confirmed, |
| | |covers names |
| | |below |
+--+----------------------------------------------+---------------+
|30| Confirmation has "s=other" |confirmed, |
| | |affiliated |
| | |domain only |
+--+----------------------------------------------+---------------+
|31| Confirmation has "x=2099-12-31" |confirmed |
+--+----------------------------------------------+---------------+
|32| Confirmation has "x=2020-01-01" |not-confirmed |
| | |(report reason |
| | |"expired") |
+--+----------------------------------------------+---------------+
|33| Confirmation has "x=2027-02-30" |permerror |
+--+----------------------------------------------+---------------+
|34| Confirmation has an "x" value equal to the |confirmed |
| | current UTC date | |
+--+----------------------------------------------+---------------+
|35| Confirmation has "s=subtree; x=2099-12-31" |confirmed, |
| | |covers names |
| | |below |
+--+----------------------------------------------+---------------+
|36| Marker has "f=mailto:dac- |not-confirmed; |
| | reports@bank.example"; claim carries a token |report with |
| | the confirming domain never issued |reason |
| | |"unconfirmed- |
Manelidis & Ramos Expires 4 May 2027 [Page 54]
Internet-Draft Domain Affiliation Confirmation October 2026
| | |token" to that |
| | |address |
+--+----------------------------------------------+---------------+
|37| Marker has "f=mailto:reports@other.example"; |not-confirmed; |
| | claim carries a token the confirming domain |no report |
| | never issued | |
+--+----------------------------------------------+---------------+
|38| Marker has |no reports (tag|
| | "f=mailto:r@bank.example?cc=x@other.example" |ignored) |
+--+----------------------------------------------+---------------+
|39| Marker has "f=https://user@bank.example/r" |no reports (tag|
| | or "f=https://bank.example:8443/r" |ignored) |
+--+----------------------------------------------+---------------+
|40| Marker has "f=https://reports.bank.example/ |not-confirmed; |
| | dac"; "c=https" and the resource returns 404 |report reason |
| | |"unconfirmed- |
| | |token" |
+--+----------------------------------------------+---------------+
|41| Confirmation repeats the "d" tag, marker has |permerror; |
| | a valid "f" |report reason |
| | |"malformed- |
| | |confirmation" |
+--+----------------------------------------------+---------------+
|42| Affiliated domain record has only marker |none |
| | tags ("v=DAC1; | |
| | r=mailto:abuse@embank.example") | |
+--+----------------------------------------------+---------------+
|43| Affiliated domain record has claim and |confirmed |
| | marker tags; its own affiliated domains |(both) |
| | verify against it | |
+--+----------------------------------------------+---------------+
|44| Claim has "p=bank.example" but no "t" |permerror |
+--+----------------------------------------------+---------------+
|45| Marker has "r=ftp://x.example" |confirmed, no |
| | |contact |
+--+----------------------------------------------+---------------+
|46| Marker has "c=future" or "c=HTTPS" |not-confirmed |
+--+----------------------------------------------+---------------+
|47| SERVFAIL, timeout, or DNSSEC bogus at any of |temperror |
| | the three names | |
+--+----------------------------------------------+---------------+
|48| Confirmation name returns NOERROR without |not-confirmed |
| | data | |
+--+----------------------------------------------+---------------+
|49| "c=https"; 200, "text/plain", "v=DAC1; |confirmed |
| | d=embank.example" | |
+--+----------------------------------------------+---------------+
|50| "c=https"; 200, "text/plain; charset=utf-8", |confirmed |
Manelidis & Ramos Expires 4 May 2027 [Page 55]
Internet-Draft Domain Affiliation Confirmation October 2026
| | "v=DAC1; d=embank.example" | |
+--+----------------------------------------------+---------------+
|51| "c=https"; 200, "text/plain", "Cache- |confirmed, not |
| | Control: no-store", "v=DAC1; |reusable |
| | d=embank.example" | |
+--+----------------------------------------------+---------------+
|52| "c=https"; 404 |not-confirmed |
+--+----------------------------------------------+---------------+
|53| "c=https"; 301 |permerror |
+--+----------------------------------------------+---------------+
|54| "c=https"; 200 with "text/html" |permerror |
+--+----------------------------------------------+---------------+
|55| "c=https"; content longer than 1024 octets |permerror |
+--+----------------------------------------------+---------------+
|56| "c=https"; content is two records |permerror |
+--+----------------------------------------------+---------------+
|57| "c=https"; malformed record |permerror |
+--+----------------------------------------------+---------------+
|58| "c=https"; 503 or connection failure |temperror |
+--+----------------------------------------------+---------------+
|59| "c=https"; confirming domain has no globally |permerror |
| | reachable address | |
+--+----------------------------------------------+---------------+
|60| "c=https"; no resource, but a DNS |not-confirmed |
| | confirmation exists | |
+--+----------------------------------------------+---------------+
|61| Confirmation has "rel=same-entity" |confirmed, |
| | |relationship |
| | |same-entity |
+--+----------------------------------------------+---------------+
|62| Confirmation has "rel=third-party" |confirmed, |
| | |relationship |
| | |third-party |
+--+----------------------------------------------+---------------+
|63| Confirmation has "rel=other" |confirmed, no |
| | |relationship |
+--+----------------------------------------------+---------------+
|64| No marker; resource returns "v=DAC1; |confirmed over |
| | d=embank.example" |HTTPS, "webpki"|
+--+----------------------------------------------+---------------+
|65| Confirmation deleted; resource returns |confirmed over |
| | "v=DAC1; d=embank.example" |HTTPS, "webpki"|
+--+----------------------------------------------+---------------+
|66| As vector 65, but the marker validates as |not-confirmed |
| | secure | |
+--+----------------------------------------------+---------------+
|67| As vector 49, stating the authentication |confirmed over |
| | |HTTPS, "webpki"|
Manelidis & Ramos Expires 4 May 2027 [Page 56]
Internet-Draft Domain Affiliation Confirmation October 2026
+--+----------------------------------------------+---------------+
|68| As vector 67, but the claim and the marker |confirmed over |
| | validate as secure |HTTPS, |
| | |"dnssec+webpki"|
+--+----------------------------------------------+---------------+
|69| All three answers validate as secure |confirmed, |
| | |"dnssec" |
+--+----------------------------------------------+---------------+
|70| No marker; resource returns 404 |not-confirmed |
+--+----------------------------------------------+---------------+
|71| Marker answer contains a CNAME; resource |confirmed over |
| | returns "v=DAC1; d=embank.example" |HTTPS, "webpki"|
+--+----------------------------------------------+---------------+
|72| Marker has "c=future"; resource returns |confirmed over |
| | "v=DAC1; d=embank.example" |HTTPS, "webpki"|
+--+----------------------------------------------+---------------+
|73| Resource returns "v=DAC1; d=other.example" |confirmed over |
| | |DNS, |
| | |unauthenticated|
+--+----------------------------------------------+---------------+
|74| No marker; resource returns "v=DAC1; |not-confirmed |
| | d=embank.example; x=2020-01-01" | |
+--+----------------------------------------------+---------------+
Table 6: Test Vectors
Appendix D. Changes since -00
This section is to be removed before publishing as an RFC.
* Renamed the roles "parent" and "child" to "confirming domain" and
"affiliated domain" and stated that they imply no hierarchy in the
DNS. Tag names and report member names are unchanged.
* Added the "rel" tag to confirmations, with the values "same-
entity" and "third-party", and the "DAC Relationship Values"
registry.
* Added step 5 to the verification procedure: when the marker is not
validated as secure and the DNS channel does not yield
"confirmed", verifiers fetch the HTTPS resource, taking the mode
and abuse contact from the marker if there is one. Added the
"webpki" authentication value, required that only the confirming
operator create resources under "/.well-known/affiliation/", added
a security consideration on such resources created by others, and
updated the operational, security, and privacy considerations
accordingly.
Manelidis & Ramos Expires 4 May 2027 [Page 57]
Internet-Draft Domain Affiliation Confirmation October 2026
* Recommended an expiry date no later than the affiliated domain's
registration expiry, extended only on renewal, and stated the
limits of this practice.
* Added a section on reuse of registrant verification by registries
and registrars, including verification before a domain is
registered. Later sections are renumbered.
* Added rationale on why confirmations are not bound to registration
data, noting that a profile may add such a binding, and on why the
relationship is optional. Added a note that a reputation system
may use a confirmation as the starting standing of a new
affiliated domain.
* Added text on why organizations' internal policies do not solve
the problem, on software agents, on which systems verify and when,
on impersonation, and on why TXT records at fixed underscored
names are used.
* Added references to related work: Related Domains By DNS, DBOUND,
Related Website Sets, DNSid, DNS-AID, and domain-set.
* Added test vectors 61 to 74, and updated the implementation
status.
* Added Fabio Ramos as an author.
Acknowledgments
This document builds on the practices collected in
[I-D.ietf-dnsop-domain-verification-techniques] and on operational
experience with SPF, DMARC, MTA-STS, and ACME.
The authors thank John Klensin, John Levine, and Andrew Sullivan for
their comments on the DNSOP mailing list.
Authors' Addresses
Dimitri Manelidis
Email: tastypepperoni@gmail.com
Fabio Ramos
Email: fabio@martian.pink
Manelidis & Ramos Expires 4 May 2027 [Page 58]