]>

tastypepperoni@gmail.com

fabio@martian.pink

Operations and Management Network Working Group DNS affiliation phishing takedown reputation TXT 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 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 ().

Introduction

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 .

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

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

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 ().
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 .
7. The verification procedure does not consult a list of public suffixes. Every confirmation requires a record that only the confirming operator can publish.

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 (). DAC does not express relationships between independent organizations, such as partnerships or service providers (). 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 (), and the organization can learn of it through failure reports (). A domain that publishes no claim, or whose claim is not confirmed, is not thereby shown to be an impersonation (). 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 (), but that statement is made by the confirming operator and is not verified by DAC.

Relationship to Other Work 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. 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 (). Related Domains By DNS 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 (), and uses no key material (). The DBOUND work 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 (); it relates two domains that may be anywhere in the DNS. Related Website Sets 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. 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 (). 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. 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 ().

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

Terminology DNS terms are used as defined in . 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 ().

Marker:

The TXT record by which a confirming domain indicates that it participates and selects a confirmation channel ().

Confirmation:

The record by which the confirming domain confirms one claim, published in the DNS () or over HTTPS ().

Token:

A random value, unique to one affiliated domain, that links a claim to its confirmation ().

Verifier:

A party that carries out the procedure in .

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 . The token used in examples, "mfrggzdfmztwq2lknnwg23tpobyxe43u", is illustrative and not random.

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.

Records and Verification Steps " (claim) | | ._affiliation. | +-------------------------------+ | bank.example. | | TXT "v=DAC1; | | d=embank.example" | | (confirmation) | +--------------------------------+ Verifier: 1. TXT _affiliation.embank.example -> p=bank.example, t= 2. TXT _affiliation.bank.example -> marker, channel "dns" 3. TXT ._affiliation.bank.example -> d=embank.example 4. d= equals the affiliated domain -> result "confirmed" ]]>

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 () and tells the verifier which channel the confirming domain uses.

Records

Common Syntax The three records share one tag-list syntax: a version tag followed by zero or more tags, separated by semicolons. The ABNF below uses case-sensitive strings ; WSP, ALPHA, and DIGIT are the core rules of . 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 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 ; 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 . 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 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.

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:

p (required):

The confirming domain, matching the "p-value" rule.

t (required):

The token, matching the "t-value" rule ().

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

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

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 ). It still needs the marker to convey its mode and abuse contact.

c (optional):

The confirmation channel. This document defines "dns", the default (), and "https" (). Other values are registered as described in . With "https", DNS confirmation records are not consulted.

r (optional):

A URI for reports of abuse concerning the confirming domain's affiliated domains, with scheme "mailto" or "https". Semicolons and whitespace in the URI are percent-encoded. Verifiers ignore an "r" tag with any other scheme.

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 (). 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 (). 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 () 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 (). 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 at that name redirects the queries for confirmations to another zone and has the same effect as delegating them.

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:

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 (). 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 described in . 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 , 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 (). 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 () can obtain the expiry and creation dates of the affiliated domain's registration through the Registration Data Access Protocol (RDAP) , 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" , 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 (). Verifiers cannot determine whether a confirming operator follows the practice above. 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.

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

• A token MUST contain at least 128 bits, and SHOULD contain 160 bits, from a cryptographically secure random source . At 128 bits, guessing a confirmation name is infeasible and collisions between tokens are negligible.
• A token is encoded in base32 () 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 . Case-sensitive encodings such as base64 cannot be used, because DNS name matching ignores case 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.

Publishing an Affiliation

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

Publishing the confirmation first lets the affiliation verify as soon as the claim is visible.

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

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 (), and the new operator of the affiliated domain replaces or removes the claim.

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

Verification

Inputs and Outputs The input is an affiliated domain in canonical form (). Verifiers that accept names containing non-ASCII characters convert them to A-labels as specified in ; the processing of with non-transitional processing is a common way of doing so. A name that cannot be converted yields "permerror". The output is a result () and, when available, the confirming domain, the channel, whether the result is authenticated (), whether the confirmation covers names below the affiliated domain (), the relationship stated by the confirmation (), the confirming domain's mode and abuse contact, and the time for which the result may be reused ().

Procedure Verifiers MUST use a DNS interface that exposes the answer section of responses, so that CNAME and DNAME 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 .

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".
   • 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.
   1. The answer contains a CNAME or DNAME record: "permerror".
   2. No record: "not-confirmed".
   3. More than one DAC record, or a malformed one: "permerror".
   4. 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 .
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 (), the HTTPS channel was not used in step 3, and steps 2 to 4 did not yield "confirmed". A verifier that supports the HTTPS channel MUST then obtain the confirmation as described in 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 ().

Step 5 lets a confirming domain whose zone is not signed with DNSSEC obtain authenticated results () 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" (), 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.

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.

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" ) also yields "temperror" and MUST NOT contribute to a "confirmed" result. Verifiers MUST support DNS over TCP.

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 , 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 (). "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 (). "dnssec+webpki" also authenticates the claim. The abuse contact is taken from the marker and is authenticated only when the marker is.

Caching A verifier MAY reuse a result for the smallest of: the TTLs of the DNS answers used, where the TTL of a negative answer is determined as in ; the freshness lifetime of the HTTPS response (); 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 can extend the time for which an ended affiliation still verifies.

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

Resource The confirmation for a token is the resource identified by: /.well-known/affiliation/ ]]> 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: 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 ). A confirming operator MUST NOT allow other parties to create or alter resources at or below "/.well-known/affiliation/" on its origin , 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; discusses the risk.

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 ;
• MUST NOT follow redirects;
• MUST NOT connect to addresses that the IANA special-purpose address registries 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:

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

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.

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.

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 (). A "rel" value is a statement by the confirming operator, not a verified fact. DAC does not establish which legal entity operates either domain.

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 ().
• 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 (), can use the "rel" value. A confirmation without "rel" does not indicate either relationship.
• 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 ().
• Assurance. Relying parties taking consequential actions can consider whether a result was authenticated () and, for unauthenticated results, the measures in .

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 . A confirmation is a statement by the confirming operator (), 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 () 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" (). 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.

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

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.

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 , 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 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 ; 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 message per report destination in 24 hours, combining reports into it, and SHOULD limit the number of reports per message, for example to 1000.

Report Format A report is a JSON array of objects, each with the following members:

version:

The string "DAC1".

observed:

The time of verification, as an RFC 3339 date-time 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 ().

reporter (optional):

A domain name identifying the organization sending the report.

Receivers ignore members and reason values they do not recognize.

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

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 .

Operational Considerations

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

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 ; serve-stale resolvers and replay can extend it (, ). 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 (); 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.

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.

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

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.

DNS Configuration

• Confirming domains SHOULD sign their zones with DNSSEC so that verifiers can obtain authenticated results. A signed confirming domain's zone SHOULD use NSEC3 with the parameters in , compact denial of existence , or minimally covering NSEC records , and SHOULD NOT use NSEC records that allow the zone to be walked ().
• Confirming domains SHOULD restrict zone transfers to their own secondary servers .
• 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.

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.

Security Considerations

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 .

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 (), only the confirming operator, or a party able to create resources on its HTTPS origin (), can create such a record. 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" ().

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.

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 , inventory-driven automation (), and monitoring () address it. An expiry date tied to the registration (), 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 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.

Forged DNS Responses An attacker able to forge DNS responses to a verifier, for example through cache poisoning 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 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 ), and why no party other than the confirming operator may create resources under it (). Results authenticated with DNSSEC or the Web PKI are not affected by forged DNS responses for the records they authenticate (). 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 .

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" (). A confirmation with an expiry date cannot be replayed to effect beyond that date.

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

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

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 ). 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 , carry the same exposure. Confirming operators MUST NOT allow it (). 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.

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 () or whose set of confirmed domains grows unexpectedly.

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 (). 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 () and SHOULD make their claim name a CNAME only to names they or their confirming operator control.

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 ; following several levels () 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 ); verifiers cache the response, including 404 responses, for its freshness lifetime. Aggressive use of DNSSEC-validated caches can absorb such queries only where denial of existence covers ranges of names; the configurations recommended in 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.

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 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 . This is why confirming domains include "s=subtree" only for affiliated domains whose entire namespace they control (). 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.

Failure Reports An attacker can publish many claims naming a confirming domain so that verifiers send reports to it; the per-destination limit in 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 (). Reports are never evidence that a domain is malicious ().

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

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

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 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. gives recommendations. Queries reveal to resolver operators, and to passive DNS collections, which domains a verifier is evaluating. QNAME minimisation reduces exposure of full names to servers higher in the DNS tree. An HTTPS request, including one made in step 5 of 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.

IANA Considerations

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 : Underscored Node Name

RR Type	_NODE NAME	Reference
TXT	_affiliation	RFC XXXX

Well-Known URI IANA is requested to register the following in the "Well-Known URIs" registry :

URI Suffix:

affiliation

Change Controller:

IETF

Specification Document:

RFC XXXX,

Status:

permanent

Related Information:

None

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 .

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: Initial DAC Tags

Tag	Record	Description	Reference
v	claim, marker, confirmation	version	RFC XXXX
p	claim	confirming domain	RFC XXXX
t	claim	token	RFC XXXX
c	marker	confirmation channel	RFC XXXX
r	marker	abuse contact URI	RFC XXXX
m	marker	mode	RFC XXXX
d	confirmation	affiliated domain	RFC XXXX
s	confirmation	scope	RFC XXXX
x	confirmation	expiry date	RFC XXXX
rel	confirmation	relationship	RFC XXXX
f	marker	failure report URI	RFC XXXX

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: Initial DAC Confirmation Channels

Channel	Description	Reference
dns	TXT record under the confirming domain's "_affiliation" name	RFC XXXX
https	Resource under "/.well-known/affiliation/"	RFC XXXX

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 or of a channel. The initial contents are: Initial DAC Report Reasons

Reason	Description	Reference
unconfirmed-token	No confirmation exists for the claim's token	RFC XXXX
different-child	The confirmation names another domain	RFC XXXX
expired	The confirmation's expiry date has passed	RFC XXXX
malformed-confirmation	The confirmation is malformed, not unique, or cannot be obtained	RFC XXXX

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: Initial DAC Relationship Values

Value	Description	Reference
same-entity	Operated by the legal entity that operates the confirming domain	RFC XXXX
third-party	Operated by another party under the confirming operator's authority	RFC XXXX

Implementation Status 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 . 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 , "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: .

Description:

A verifier implementing and with its own DNS client, including step 5 of and the check of a domain before it is registered (); failure reporting (); 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 (); a server for the HTTPS channel; checks of published records; and a test DNS server. All test vectors of are automated tests, and every record example in this document is checked against the ABNF in .

Level of maturity:

Prototype; not yet deployed.

Coverage:

All of the protocol.

Licensing:

BSD 3-Clause.

Contact:

The first author.

References Normative References Informative References IAB Web Platform Incubator Community Group CA/Browser Forum Mozilla Foundation Video Games Chronicle

Design Rationale

Why TXT Records discourages overloading TXT records, mainly because unrelated uses collide at the same owner name. DAC uses a dedicated underscored name 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 . TXT was chosen because DNS provisioning interfaces used by domain operators support it universally, and because experience with the dedicated SPF type , which 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.

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.

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.

Why the Procedure Does Not Use the Public Suffix List Mechanisms that infer relationships between names depend on the Public Suffix List , a community-maintained list without a standard update model; 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.

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

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

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 (), 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 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" (), so that a forged or removed marker cannot hide an HTTPS confirmation or select a resource the confirming operator does not control (). Toward verifiers that validate DNSSEC, a signed confirming domain keeps full control of the channel through its marker.

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 (), and relies on the confirming operator to remove confirmations when a domain changes hands (). 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 .

Why the Relationship Is Optional Most relying parties need only the statement that the confirming operator operates or authorizes the affiliated domain (). Some, such as registries reusing a verification of a legal entity (), 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.

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 (). Aggregators can be built on DAC, but nothing depends on them.

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 remain. DAC addresses a specific operational problem with intended consumers, takedown services and reputation systems, and states what a confirmation means (), 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 (). The authors invite operators of such services to comment on whether the stated meaning meets their needs.

Complete Example The operator of bank.example launches embank.example and uses the DNS channel. 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";
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 (). 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.

Test Vectors Each vector describes a change to the data of 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 does not change the result of vectors 1 to 60. "Unauthenticated" means a "confirmed" result that is not authenticated (). The reference implementation () runs these vectors as tests. Test Vectors

#	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; p=bank.example; t=T"	none
5	No marker at the confirming domain	not-confirmed
6	Affiliated domain is embank-login.example with a copy of the claim	not-confirmed
7	Claim carries a token the confirming domain never issued	not-confirmed
8	Confirmation deleted	not-confirmed
9	Marker name is an empty non-terminal (NOERROR, no data)	not-confirmed
10	Marker answer contains a CNAME	permerror
11	Marker answer contains a CNAME and no TXT data	permerror
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 token	confirmed
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 domain	permerror
25	Confirming domain is the single-label name "bank"	confirmed
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 current UTC date	confirmed
35	Confirmation has "s=subtree; x=2099-12-31"	confirmed, covers names below
36	Marker has "f=mailto:dac-reports@bank.example"; claim carries a token the confirming domain never issued	not-confirmed; report with reason "unconfirmed-token" to that address
37	Marker has "f=mailto:reports@other.example"; claim carries a token the confirming domain never issued	not-confirmed; no report
38	Marker has "f=mailto:r@bank.example?cc=x@other.example"	no reports (tag ignored)
39	Marker has "f=https://user@bank.example/r" or "f=https://bank.example:8443/r"	no reports (tag ignored)
40	Marker has "f=https://reports.bank.example/dac"; "c=https" and the resource returns 404	not-confirmed; report reason "unconfirmed-token"
41	Confirmation repeats the "d" tag, marker has a valid "f"	permerror; report reason "malformed-confirmation"
42	Affiliated domain record has only marker tags ("v=DAC1; r=mailto:abuse@embank.example")	none
43	Affiliated domain record has claim and marker tags; its own affiliated domains verify against it	confirmed (both)
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 the three names	temperror
48	Confirmation name returns NOERROR without data	not-confirmed
49	"c=https"; 200, "text/plain", "v=DAC1; d=embank.example"	confirmed
50	"c=https"; 200, "text/plain; charset=utf-8", "v=DAC1; d=embank.example"	confirmed
51	"c=https"; 200, "text/plain", "Cache-Control: no-store", "v=DAC1; d=embank.example"	confirmed, not reusable
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 reachable address	permerror
60	"c=https"; no resource, but a DNS confirmation exists	not-confirmed
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; d=embank.example"	confirmed over HTTPS, "webpki"
65	Confirmation deleted; resource returns "v=DAC1; d=embank.example"	confirmed over HTTPS, "webpki"
66	As vector 65, but the marker validates as secure	not-confirmed
67	As vector 49, stating the authentication	confirmed over HTTPS, "webpki"
68	As vector 67, but the claim and the marker validate as secure	confirmed over 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 returns "v=DAC1; d=embank.example"	confirmed over HTTPS, "webpki"
72	Marker has "c=future"; resource returns "v=DAC1; d=embank.example"	confirmed over HTTPS, "webpki"
73	Resource returns "v=DAC1; d=other.example"	confirmed over DNS, unauthenticated
74	No marker; resource returns "v=DAC1; d=embank.example; x=2020-01-01"	not-confirmed

Changes since -00

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