Domain Authority (DA): A DNS-Designated Service Endpoint for Domain Information
draft-swaminathan-da-00
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) | |
|---|---|---|---|
| Author | Kishore Swaminathan | ||
| Last updated | 2026-06-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-swaminathan-da-00
Network Working Group K. Swaminathan
Internet-Draft 5 June 2026
Intended status: Standards Track
Expires: 7 December 2026
Domain Authority (DA): A DNS-Designated Service Endpoint for Domain
Information
draft-swaminathan-da-00
Abstract
This document specifies a minimal standard by which a domain
designates, via a single DNS record, a Domain Authority (DA) as a
service endpoint accessible at a well-known HTTPS URI. The DA
exposes five namespaces for capabilities beyond what DNS can natively
deliver: atomic record bundles, public key distribution, domain-
defined APIs, authenticated access, and private domain control
verification.
The standard is organized in three layers. The Designation Layer
specifies how a domain publishes a DNS record that points to its DA.
The Retrieval Layer specifies the five namespaces through which
consumers access domain information. The Trust Layer specifies how
consumers establish confidence in the DA and its responses.
The standard preserves full backward compatibility with existing DNS
resolution. It requires no changes to DNS resolvers, no new DNS
record types, and no ecosystem-wide coordination. Any domain can
adopt unilaterally and gain immediate operational benefit.
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/.
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 7 December 2026.
Swaminathan Expires 7 December 2026 [Page 1]
Internet-Draft Domain Authority June 2026
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 and Benefits . . . . . . . . . . . . . . . . . . 4
1.1. Relationship to DNS Evolution . . . . . . . . . . . . . . 5
1.2. Relationship to Existing Standards . . . . . . . . . . . 5
1.3. Differentiation from Related Work . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Layer 1: Designation . . . . . . . . . . . . . . . . . . . . 9
5.1. Designation Record Format . . . . . . . . . . . . . . . . 9
5.2. Record Discovery . . . . . . . . . . . . . . . . . . . . 9
5.3. Subdomain Scope . . . . . . . . . . . . . . . . . . . . . 10
5.4. Why DNS Designation Is Necessary . . . . . . . . . . . . 10
6. Layer 2: Retrieval . . . . . . . . . . . . . . . . . . . . . 10
6.1. Namespace Overview . . . . . . . . . . . . . . . . . . . 11
6.2. Common Response Requirements . . . . . . . . . . . . . . 11
6.2.1. Response Format . . . . . . . . . . . . . . . . . . . 11
6.2.2. HTTP Caching . . . . . . . . . . . . . . . . . . . . 12
6.2.3. Error Responses . . . . . . . . . . . . . . . . . . . 12
6.2.4. CORS . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. dns-bundle: Atomic Record Bundles . . . . . . . . . . . . 12
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 12
6.3.2. URI Structure . . . . . . . . . . . . . . . . . . . . 12
6.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 13
6.3.4. Response Format . . . . . . . . . . . . . . . . . . . 13
6.4. public-key: Public Key Distribution . . . . . . . . . . . 14
6.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 14
6.4.2. URI Structure . . . . . . . . . . . . . . . . . . . . 14
6.4.3. Examples . . . . . . . . . . . . . . . . . . . . . . 15
6.4.4. Catalog Response Format . . . . . . . . . . . . . . . 15
6.4.5. Individual Key Response Format . . . . . . . . . . . 16
6.5. host-api: Domain-Defined APIs . . . . . . . . . . . . . . 17
6.5.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 17
Swaminathan Expires 7 December 2026 [Page 2]
Internet-Draft Domain Authority June 2026
6.5.2. URI Structure . . . . . . . . . . . . . . . . . . . . 17
6.5.3. Examples . . . . . . . . . . . . . . . . . . . . . . 18
6.5.4. Guidance for Implementers . . . . . . . . . . . . . . 18
6.6. host-auth: Authenticated Access . . . . . . . . . . . . . 18
6.6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 18
6.6.2. URI Structure . . . . . . . . . . . . . . . . . . . . 18
6.6.3. Authentication Mechanisms . . . . . . . . . . . . . . 18
6.6.4. Use Cases . . . . . . . . . . . . . . . . . . . . . . 19
6.7. domain-ownership: Private Domain Control Validation . . . 19
6.7.1. Purpose and Architectural Justification . . . . . . . 19
6.7.2. URI Structure . . . . . . . . . . . . . . . . . . . . 20
6.7.3. Workflow . . . . . . . . . . . . . . . . . . . . . . 20
6.7.4. Response Format . . . . . . . . . . . . . . . . . . . 21
6.7.5. Token Lifecycle . . . . . . . . . . . . . . . . . . . 21
7. Layer 3: Trust . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Transport Security . . . . . . . . . . . . . . . . . . . 21
7.2. DNSSEC Anchoring of the Designation Record . . . . . . . 22
7.3. Response Signing . . . . . . . . . . . . . . . . . . . . 22
7.4. Graceful Degradation . . . . . . . . . . . . . . . . . . 23
7.5. Detachment . . . . . . . . . . . . . . . . . . . . . . . 23
7.6. Summary of Trust Mechanisms . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.1. DA as a High-Value Target . . . . . . . . . . . . . . . . 23
8.2. Designation Record Attacks . . . . . . . . . . . . . . . 24
8.3. domain-ownership Token Security . . . . . . . . . . . . . 24
8.4. host-auth Credential Management . . . . . . . . . . . . . 24
8.5. public-key Namespace Security . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Well-Known URI Registration . . . . . . . . . . . . . . . 24
9.2. DA Designation Record . . . . . . . . . . . . . . . . . . 25
9.3. Bundle Type Registry . . . . . . . . . . . . . . . . . . 25
9.4. Key Purpose Registry . . . . . . . . . . . . . . . . . . 25
9.5. DA Namespace Registry . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Adoption Scenarios . . . . . . . . . . . . . . . . . 28
A.1. Minimal Adoption: Domain Ownership Only . . . . . . . . . 28
A.2. Internal Service Discovery . . . . . . . . . . . . . . . 29
A.3. Full Deployment . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
Swaminathan Expires 7 December 2026 [Page 3]
Internet-Draft Domain Authority June 2026
1. Introduction and Benefits
DNS was designed as a static, hierarchical lookup table. Over four
decades it has been pressed into service for policy distribution,
service discovery, certificate management, ownership verification,
and branding -- tasks that exceed its structural capabilities. The
result is TXT record overloading, site-verification litter,
fragmented policy records, and stalled DNSSEC adoption.
This document does not propose to fix DNS. It specifies a minimal
mechanism -- one DNS record and five HTTPS namespaces -- that gives
domains a parallel distribution path alongside DNS for richer,
structured, and authenticated information delivery.
The standard delivers eight concrete benefits:
Backward compatibility. DNS continues to work exactly as it does
today. The DA is a complementary distribution path, not a
replacement. Legacy resolvers are unaffected. Domains continue
to publish DNS records normally; the DA exposes capabilities that
DNS cannot natively deliver.
API-based delivery. Domain information that is awkwardly encoded as
TXT records or spread across multiple DNS lookups can be served as
structured JSON via HTTPS, with metadata that DNS cannot carry
(protocol versions, SLAs, compliance certifications, geographic
availability).
Atomic bundles. Related records that are published and queried
independently in DNS (e.g., SPF, DKIM, DMARC) can be delivered as
a single, validated bundle -- eliminating inconsistencies caused
by partial updates or stale caches.
Size-unconstrained key distribution. DNS has structural size limits
-- UDP responses are practically constrained to ~1,232 bytes, and
even with EDNS0 and TCP fallback, large records cause
fragmentation, truncation, and middlebox failures. Current public
keys already strain these limits; post-quantum public keys
(1,200-2,500 bytes for ML-KEM and ML-DSA) exceed them entirely.
The DA distributes public keys via HTTPS in native formats (JWK,
PEM) with no size constraint, providing a practical path for post-
quantum migration.
Authenticated access. DNS is inherently public. The DA provides a
graduated trust model where public consumers receive baseline
information and authenticated partners, regulators, or federated
domains receive richer metadata or sensitive operational data.
Swaminathan Expires 7 December 2026 [Page 4]
Internet-Draft Domain Authority June 2026
Domain verification cleanup. Third-party site verification today
requires publishing TXT records visible to all resolvers, creating
zone bloat and broadcasting vendor relationships. The DA provides
a private, scoped verification namespace that eliminates both the
litter and the privacy leakage.
Experimentation. The host-api namespace allows domains to deploy new
protocols and information types immediately, without requiring new
DNS record types, resolver support, or ecosystem-wide
coordination. A domain can expose a new capability today and
iterate on its design based on real consumer feedback.
Data-driven standardization. As experimental host-api patterns gain
adoption across domains, they produce concrete evidence -- usage
telemetry, interoperability experience, and implementation
diversity -- that informs future standardization. Patterns that
prove their value become candidates for promotion to named
namespaces in future revisions of this specification, or for
proposal as new DNS record types with real-world deployment data
already in hand.
1.1. Relationship to DNS Evolution
The DA is complementary to proposals for new DNS record types, not
competitive with them. New record types remain the right mechanism
for information that every resolver must process during name
resolution. However, the deployment cycle for a new DNS record type
-- from IETF proposal through resolver implementation, registrar
tooling, and zone file support -- is measured in years to decades.
The DA provides an immediate delivery path: a domain can serve a
proposed record type's information via the DA today, accumulate real
consumer adoption, and provide the IETF with implementation evidence
that strengthens the case for the record type's eventual deployment
in DNS itself. Rather than slowing DNS evolution, the DA accelerates
it by shortening the feedback loop between proposal and operational
experience.
1.2. Relationship to Existing Standards
This specification builds on and is compatible with: [RFC8615],
[RFC4033], [RFC7517], [RFC7489], [RFC7208], [RFC6376], [RFC2782],
[RFC6698], [RFC8659], and [RFC8555].
The DA does not replace or modify any of these standards. It
provides a parallel distribution path that can serve the same
information in richer formats while maintaining full backward
compatibility.
Swaminathan Expires 7 December 2026 [Page 5]
Internet-Draft Domain Authority June 2026
1.3. Differentiation from Related Work
[RFC5507] recommended new DNS record types to address TXT
overloading. Seventeen years later, TXT overloading has accelerated.
This standard takes a complementary approach: a parallel API path
that requires no resolver or registrar changes.
[RFC9460] (SVCB/HTTPS) encodes service connection parameters in DNS
for connection optimization. The DA is complementary: SVCB optimizes
DNS-based connection setup; the DA provides richer service catalogs
and operational metadata via API.
Domain Connect [DomainConnect] uses DNS to bootstrap API
relationships for DNS record provisioning (write path). The DA
standardizes how domain information is consumed (read path).
[DCV] standardizes DNS-based domain control validation. Acknowledges
that DNS-based verification publicly discloses vendor relationships.
The DA's domain-ownership namespace addresses this by moving
verification to a private API path.
[DNSApps] identified fundamental DNS limitations for application use:
no confidentiality, no access control, no complex data. The DA
addresses each via authenticated access, structured APIs, and private
namespaces.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Domain Authority (DA): An HTTPS service endpoint designated by a
domain via a DNS record to serve as an authoritative source of
domain-related information beyond what DNS natively delivers.
DA Designation Record: A DNS TXT record at _da.<domain> that
associates a domain with its Domain Authority, containing a
version identifier and the DA's hostname.
Namespace: A URI path segment under /.well-known/da/ that identifies
a class of DA functionality. This specification defines five
namespaces: dns-bundle, public-key, host-api, host-auth, and
domain-ownership.
Designation Layer: The mechanism by which a domain publishes a DNS
Swaminathan Expires 7 December 2026 [Page 6]
Internet-Draft Domain Authority June 2026
record identifying its DA endpoint. Specified in Section 5.
Retrieval Layer: The five namespaces through which consumers request
and receive domain information from the DA. Specified in
Section 6.
Trust Layer: The mechanisms by which consumers verify the
authenticity and integrity of the designation record and DA
responses. Specified in Section 7.
3. Architectural Overview
The standard comprises three layers. Each layer is independently
useful and incrementally deployable.
+-------------------------------------------------------+
| LAYER 3: TRUST |
| DNSSEC on designation record . Response signatures . |
| Transport security |
+-------------------------------------------------------+
| LAYER 2: RETRIEVAL |
| |
| /.well-known/da/ |
| dns-bundle/ |
| public-key/ |
| host-api/ |
| host-auth/ |
| domain-ownership/ |
+-------------------------------------------------------+
| LAYER 1: DESIGNATION |
| _da.<domain> TXT "v=da1; da=da.example.com" |
+-------------------------------------------------------+
| DNS (unchanged) |
+-------------------------------------------------------+
Layer 1 (Designation) is the foundation. A domain publishes a single
DNS TXT record that names its DA endpoint. This is the only DNS
change required and uses existing record types. Without this record,
consumers have no way to discover the DA.
Layer 2 (Retrieval) defines five namespaces under a well-known URI
prefix. Each namespace provides a distinct structural capability
that DNS cannot natively deliver: atomicity, size-unconstrained key
distribution, extensibility, access control, and privacy. A DA MAY
implement any subset of the five namespaces; each provides standalone
value.
Swaminathan Expires 7 December 2026 [Page 7]
Internet-Draft Domain Authority June 2026
Layer 3 (Trust) defines how consumers verify that the DA endpoint is
authoritative for the domain and how DA responses may be
cryptographically signed.
The layers are additive:
* A domain that publishes only Layer 1 has declared its DA but
serves nothing yet. This is a valid (if pointless) deployment.
* A domain that implements Layers 1 and 2 provides full retrieval
capability. Trust relies on TLS alone.
* A domain that implements all three layers provides DNSSEC-anchored
trust for the designation and optional cryptographic signatures on
responses.
4. Design Goals
G1. No DNS changes required. The standard MUST NOT require new DNS
record types, modified resolver behavior, or changes to
authoritative DNS server software.
G2. Unilateral adoption. Any domain MUST be able to adopt the
standard independently, without requiring action by other domains,
resolvers, or service providers.
G3. Full backward compatibility. Existing DNS resolution MUST
continue to function identically. The DA operates as a
complementary distribution path, not a replacement.
G4. External interfaces only. The standard specifies the DNS
designation mechanism and the namespace structure -- the external
interfaces that consumers interact with. It does not constrain
how a DA is implemented internally. Storage, validation logic,
key management, access control, and operational architecture are
left to implementers. A wide range of implementations are
possible for different kinds and sizes of organizations.
G5. Incremental value. A domain MUST gain operational benefit from
adopting even a single namespace (e.g., domain-ownership alone),
without being required to implement all five namespaces.
G6. Security by design. The standard MUST support, but not mandate,
cryptographic signing of DA responses, authenticated access, and
encrypted transport.
Swaminathan Expires 7 December 2026 [Page 8]
Internet-Draft Domain Authority June 2026
5. Layer 1: Designation
This section is entirely normative. It specifies the DNS record by
which a domain designates its DA endpoint.
5.1. Designation Record Format
A domain designates its Domain Authority by publishing a DNS TXT
record at the following name:
_da.<domain>
The record format is:
_da.example.com. 86400 IN TXT "v=da1; da=da.example.com"
The record MUST contain the following fields:
* v=da1: Version identifier for this specification. Consumers MUST
ignore records with unrecognized version values.
* da=: The hostname of the Domain Authority endpoint. Consumers
construct the endpoint URI by prepending "https://" and appending
the well-known namespace path (e.g., https://da.example.com/.well-
known/da/dns-bundle/email-auth). The scheme is always HTTPS
(Section 7.1) and the path prefix is always /.well-known/da/
(Section 9.1), so the hostname is the only variable. The hostname
SHOULD be a subdomain of the domain itself (e.g., da.example.com)
but MAY be hosted on a different domain (e.g., for managed DA
services).
The record MAY contain the following optional fields:
* alg=: Cryptographic algorithm used for signing DA responses (see
Section 7.3). Example: alg=ed25519.
* fp=: Fingerprint of the DA's signing key, for out-of-band
verification (see Section 7.3).
5.2. Record Discovery
Consumers discover a domain's DA by querying for a TXT record at
_da.<domain>. If no record is found, the domain does not have a
designated DA, and the consumer MUST fall back to standard DNS
resolution.
Swaminathan Expires 7 December 2026 [Page 9]
Internet-Draft Domain Authority June 2026
5.3. Subdomain Scope
A DA designation record at _da.example.com applies only to
example.com. It does not apply to subdomains. A subdomain such as
pay.example.com MAY designate its own DA by publishing a separate
record at _da.pay.example.com.
Consumers MUST NOT assume that a parent domain's DA is authoritative
for its subdomains. A consumer seeking a DA for pay.example.com MUST
query _da.pay.example.com; if no record is found, the subdomain does
not have a DA, regardless of whether the parent domain does.
This scoping enables large organizations to delegate DA operations to
subdivisions or service teams, mirrors the existing DNS delegation
model, and prevents a parent domain's DA from unilaterally asserting
authority over independently operated subdomains.
5.4. Why DNS Designation Is Necessary
A domain could publish /.well-known/da/ endpoints without a DNS
record. The designation record serves two purposes that a bare well-
known URI cannot:
Discovery. The DA endpoint may be hosted on a different domain
(e.g., a managed DA service at da-provider.com). The DNS record
tells consumers where to find it. Without the record, consumers
would need to probe every domain's web server speculatively.
Trust anchoring. When the domain's zone is DNSSEC-signed, the
designation record inherits cryptographic integrity and
authenticity (see Section 7.2). A consumer that validates the
DNSSEC chain can be certain the DA hostname is authoritative for
the domain -- a guarantee that a bare well-known URI, secured only
by TLS, cannot provide.
6. Layer 2: Retrieval
This section is normative. It specifies the five namespaces through
which consumers retrieve domain information from the DA.
This specification defines the external interfaces of each namespace
-- URI structure, request semantics, and response format. It does
not specify how a DA obtains, validates, or stores the information it
serves. Implementations may range from lightweight proxies to
comprehensive domain management platforms.
Swaminathan Expires 7 December 2026 [Page 10]
Internet-Draft Domain Authority June 2026
6.1. Namespace Overview
The DA exposes five namespaces under the well-known URI prefix
[RFC8615]:
/.well-known/da/dns-bundle/
/.well-known/da/public-key/
/.well-known/da/host-api/
/.well-known/da/host-auth/
/.well-known/da/domain-ownership/
Each namespace provides a distinct structural capability that DNS
cannot natively deliver.
+==================+======================+===============+
| Namespace | Capability | Access |
+==================+======================+===============+
| dns-bundle | Atomicity -- related | Public |
| | records as a unit | |
+------------------+----------------------+---------------+
| public-key | Size-unconstrained | Public |
| | key distribution | |
+------------------+----------------------+---------------+
| host-api | Extensibility -- | Public |
| | domain-defined APIs | |
+------------------+----------------------+---------------+
| host-auth | Access control -- | Authenticated |
| | authenticated access | |
+------------------+----------------------+---------------+
| domain-ownership | Privacy -- scoped | Private |
| | verification | |
+------------------+----------------------+---------------+
Table 1
A DA MAY implement any subset of these namespaces. A consumer MUST
NOT assume that all namespaces are available; unsupported namespaces
MUST return HTTP 404 (Not Found).
6.2. Common Response Requirements
The following requirements apply to all namespaces.
6.2.1. Response Format
All responses MUST be JSON with Content-Type application/json.
Swaminathan Expires 7 December 2026 [Page 11]
Internet-Draft Domain Authority June 2026
6.2.2. HTTP Caching
Implementations SHOULD include standard HTTP caching headers.
Implementations SHOULD support conditional requests via ETag and If-
None-Match headers to enable efficient polling for changes.
6.2.3. Error Responses
Error responses MUST use standard HTTP status codes and SHOULD
include a JSON body:
{
"error": "not_found",
"message": "Bundle type 'email-auth' not found",
"status": 404
}
Standard status codes: 400 (malformed request), 401 (authentication
required, host-auth only), 403 (insufficient authorization), 404
(namespace or resource not found), 429 (rate limited), 500 (server
error).
6.2.4. CORS
Implementations SHOULD include CORS headers for browser-based
consumers.
6.3. dns-bundle: Atomic Record Bundles
6.3.1. Purpose
The dns-bundle namespace provides atomic delivery of related DNS
records as a single, coherent bundle. Related records (e.g., SPF,
DKIM, and DMARC) are published and queried independently in DNS, with
no mechanism to ensure mutual consistency at the time of consumption.
A bundle guarantees that all constituent records are delivered as a
unit.
6.3.2. URI Structure
/.well-known/da/dns-bundle/{bundle-type}[/{qualifier}]
This specification defines the following standard bundle types:
* email-auth: SPF, DKIM, and DMARC records as an atomic set.
* service: SRV records with associated TLSA and TXT records for a
named service.
Swaminathan Expires 7 December 2026 [Page 12]
Internet-Draft Domain Authority June 2026
* certificate: TLSA and CAA records for a domain or subdomain.
Implementations MAY define additional bundle types. The qualifier is
an optional path segment for scoping (e.g., /dns-bundle/service/sip
or /dns-bundle/certificate/pay).
6.3.3. Examples
Retrieve the email authentication bundle:
GET https://da.example.com/.well-known/da/dns-bundle/email-auth
Retrieve the certificate bundle for a subdomain:
GET https://da.example.com/.well-known/da/dns-bundle/certificate/pay
6.3.4. Response Format
{
"domain": "example.com",
"bundle_type": "email-auth",
"generated_at": "2025-06-01T12:00:00Z",
"version": 42,
"integrity": "consistent",
"records": {
"spf": {
"record": "v=spf1 ip4:192.0.2.0/24 include:_spf.provider.com -all",
"ttl": 3600
},
"dkim": [
{
"selector": "sel1",
"record": "v=DKIM1; k=rsa; p=MIIBIjANBgkq...",
"ttl": 3600,
"metadata": {
"created": "2025-01-15",
"rotation_due": "2025-07-15"
}
}
],
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
"ttl": 86400
}
},
"signature": "see Layer 3, Response Signing"
}
Swaminathan Expires 7 December 2026 [Page 13]
Internet-Draft Domain Authority June 2026
The version field enables consumers to detect changes via conditional
requests without re-fetching the full bundle.
The integrity field is OPTIONAL. If present, it MUST be one of:
* collected: The bundle aggregates the constituent records without
asserting cross-record consistency. This is a convenience bundle.
* consistent: The DA asserts that the constituent records have been
checked for mutual consistency. This specification does not
define what consistency means or how it is verified; the assertion
is made by the DA implementation.
If the integrity field is absent, consumers SHOULD treat the bundle
as collected.
6.4. public-key: Public Key Distribution
6.4.1. Purpose
The public-key namespace distributes cryptographic public keys and
certificates associated with the domain. DNS has structural size
limits -- UDP responses are practically constrained to ~1,232 bytes,
and large records cause fragmentation, truncation, and middlebox
failures. Current public keys already strain these limits; post-
quantum public keys (1,200-2,500 bytes for ML-KEM and ML-DSA) exceed
them entirely.
The public-key namespace delivers keys via HTTPS in native formats
with no size constraint, providing a practical distribution channel
for current keys and a migration path for post-quantum cryptography.
Unlike DNS record types such as TLSA [RFC6698] and SSHFP [RFC4255],
which encode key material in DNS wire format, this namespace serves
keys in standard cryptographic formats (JWK, PEM) with rich metadata
including algorithm, purpose, expiration, and rotation schedule.
6.4.2. URI Structure
The namespace supports three levels of access:
/.well-known/da/public-key/ (catalog)
/.well-known/da/public-key/{purpose} (keys by type)
/.well-known/da/public-key/{purpose}/{identifier} (specific key)
Where:
* {purpose} identifies the key type (e.g., tls, dkim, smime, pgp).
Swaminathan Expires 7 December 2026 [Page 14]
Internet-Draft Domain Authority June 2026
* {identifier} is purpose-specific: a hostname for TLS, a selector
for DKIM, a local-part for S/MIME.
This specification defines the following standard purpose values:
* tls: TLS certificates and public keys for the domain's services.
* dkim: DKIM public keys, identified by selector.
* smime: S/MIME certificates, identified by local-part.
Implementations MAY define additional purpose values.
6.4.3. Examples
Retrieve the key catalog:
GET https://da.example.com/.well-known/da/public-key/
Retrieve all TLS keys:
GET https://da.example.com/.well-known/da/public-key/tls
Retrieve the TLS certificate for a specific service:
GET https://da.example.com/.well-known/da/public-key/tls/pay.example.com
Retrieve a DKIM public key by selector:
GET https://da.example.com/.well-known/da/public-key/dkim/sel1
6.4.4. Catalog Response Format
The catalog provides an index of all available keys:
Swaminathan Expires 7 December 2026 [Page 15]
Internet-Draft Domain Authority June 2026
{
"domain": "example.com",
"generated_at": "2025-06-01T12:00:00Z",
"keys": [
{
"purpose": "tls",
"identifier": "pay.example.com",
"algorithm": "ecdsa-p256",
"fingerprint_sha256": "b64:abcd1234...",
"expires": "2026-09-01"
},
{
"purpose": "dkim",
"identifier": "sel1",
"algorithm": "rsa-2048",
"fingerprint_sha256": "b64:ef567890...",
"rotation_due": "2026-12-15"
},
{
"purpose": "tls",
"identifier": "mail.example.com",
"algorithm": "ML-KEM-768",
"fingerprint_sha512": "b64:pq789abc...",
"expires": "2027-03-01"
}
],
"signature": "see Layer 3, Response Signing"
}
6.4.5. Individual Key Response Format
Individual key responses SHOULD use JWK format [RFC7517] as the base
representation:
Swaminathan Expires 7 December 2026 [Page 16]
Internet-Draft Domain Authority June 2026
{
"domain": "example.com",
"purpose": "tls",
"identifier": "pay.example.com",
"generated_at": "2025-06-01T12:00:00Z",
"key": {
"kty": "EC",
"crv": "P-256",
"x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
},
"fingerprint_sha256": "b64:abcd1234...",
"expires": "2026-09-01",
"signature": "see Layer 3, Response Signing"
}
For key types not yet registered in the JOSE registry (e.g., post-
quantum algorithms), implementations SHOULD use a kty value of "PQ"
and include an "algorithm" field specifying the algorithm (e.g.,
"algorithm": "ML-KEM-768"). The key material SHOULD be encoded in
the format defined by the algorithm specification, typically
Base64url-encoded raw bytes. Post-quantum keys SHOULD use
fingerprint_sha512 rather than fingerprint_sha256 to provide a
security margin commensurate with the key strength. The DA MAY
additionally serve the key in PEM format via content negotiation
(Accept: application/pem-certificate-chain).
6.5. host-api: Domain-Defined APIs
6.5.1. Purpose
The host-api namespace provides an open-ended extension point for
domain-defined APIs. Domains can expose arbitrary structured
information -- service catalogs, capability declarations, protocol
metadata, operational status -- without requiring new DNS record
types or IETF standardization.
This namespace is intentionally underspecified to enable
experimentation. Domains can deploy new information types via host-
api, gather adoption data, and contribute evidence to future
standardization. As specific patterns gain adoption, they become
candidates for promotion to named namespaces in future revisions.
6.5.2. URI Structure
/.well-known/da/host-api/{api-path}
Swaminathan Expires 7 December 2026 [Page 17]
Internet-Draft Domain Authority June 2026
Where {api-path} is defined by the domain. This specification does
not constrain the structure below host-api/.
6.5.3. Examples
Service discovery catalog:
GET https://da.example.com/.well-known/da/host-api/services
Capability declaration:
GET https://da.example.com/.well-known/da/host-api/capabilities
6.5.4. Guidance for Implementers
Implementations SHOULD use JSON as the default response format,
version APIs via path prefixes (e.g., /host-api/v1/services), and
return HTTP 404 for unrecognized API paths.
6.6. host-auth: Authenticated Access
6.6.1. Purpose
The host-auth namespace provides authenticated access to domain
information not suitable for public distribution. This enables
graduated trust: public consumers receive basic information via DNS
and the public namespaces, while authenticated partners,
administrators, regulators, and federated domains receive richer
metadata or sensitive operational data.
6.6.2. URI Structure
/.well-known/da/host-auth/{resource-path}
All requests to this namespace MUST include authentication
credentials. The DA MUST return HTTP 401 (Unauthorized) for requests
without valid credentials and HTTP 403 (Forbidden) for requests with
valid credentials but insufficient authorization.
6.6.3. Authentication Mechanisms
This specification does not mandate a specific authentication
mechanism. Implementations MAY support:
* Bearer tokens (OAuth 2.0, API keys)
* Mutual TLS (mTLS)
Swaminathan Expires 7 December 2026 [Page 18]
Internet-Draft Domain Authority June 2026
* Domain-issued credentials for DA-to-DA federation
The DA SHOULD advertise supported authentication methods at:
GET https://da.example.com/.well-known/da/host-auth/.discovery
The discovery endpoint, if implemented, MUST return a JSON object
with an auth_methods array listing supported methods:
{
"auth_methods": ["bearer", "mtls"],
"bearer_endpoint": "https://da.example.com/oauth/token"
}
6.6.4. Use Cases
* Partner access: Payment processors retrieving real-time throughput
capacity and SLA metadata.
* Administrative access: Domain operators accessing operational
dashboards.
* Federated access: A subsidiary domain's DA authenticating to a
parent domain's DA for policy synchronization.
* Regulatory access: Compliance systems retrieving audit data and
certification attestations.
6.7. domain-ownership: Private Domain Control Validation
6.7.1. Purpose and Architectural Justification
DNS-based domain control validation places a private, point-to-point
assertion into a public broadcast channel. This is an architectural
mismatch: DNS is designed for public resolution, not private
attestation. Using a public broadcast channel for a point-to-point
proof forces a domain to shout to the entire internet (a TXT record
visible to all resolvers) in order to whisper to one verifier. The
domain-ownership namespace provides the structurally correct
primitive: a scoped, private channel between the domain and a
designated verifier.
The privacy leak is structural, not incidental. Every DCV TXT record
in DNS publicly discloses a vendor relationship. A zone containing
google-site-verification=..., ms=ms12345, and atlassian-domain-
verification=... allows anyone to enumerate the domain's SaaS stack.
This is inherent to using a public resolution system for private
attestation; no improvement to DNS tooling can eliminate it.
Swaminathan Expires 7 December 2026 [Page 19]
Internet-Draft Domain Authority June 2026
[DCV] acknowledges these problems and standardizes DNS-based DCV
practices. That draft distinguishes between two verification modes,
both of which the DA handles more effectively than DNS:
One-off validation. The DCV draft notes that after verification is
complete, there is typically no need for the TXT record to
persist, and recommends its removal. In practice, records
accumulate because operators forget to clean them up, are unsure
which records are still needed, or lack tooling to manage the
lifecycle. The DA solves this structurally: tokens have mandatory
expiration times and SHOULD be automatically retired after
successful verification (Section 6.7.5). Cleanup is built into
the protocol, not left to operator discipline.
Persistent validation. The DCV draft observes that persistent DNS
records are a weak signal of ongoing domain control -- a record
that remains in a zone demonstrates only that no one has removed
it, not that the original owner still controls the domain. The
draft explicitly discourages this practice. The DA provides a
stronger model for continuous verification: the DA is a live,
actively maintained service under the domain operator's control.
A verifier can issue fresh challenges periodically, receive
rotated tokens in response, and be confident that a valid response
reflects current domain control. If the domain changes hands and
the new owner does not control the DA, verification fails -- which
is the correct behavior.
6.7.2. URI Structure
/.well-known/da/domain-ownership/{verifier-id}
Where {verifier-id} is an identifier for the third-party verifier
(e.g., a service name or verification request ID).
6.7.3. Workflow
1. A third-party service requests domain ownership verification from
the domain operator.
2. The domain operator provisions a verification token at the DA
under the domain-ownership namespace, scoped to the requesting
verifier.
3. The third-party service queries the DA to retrieve and validate
the token:
GET https://da.example.com/.well-known/da/domain-ownership/acme-saas
Swaminathan Expires 7 December 2026 [Page 20]
Internet-Draft Domain Authority June 2026
4. The DA returns the verification token if a valid token exists for
the specified verifier. The DA MAY require the verifier to
present a shared secret or API key to retrieve the token.
5. Upon successful verification, the domain operator (or the DA
automatically) retires the token.
6.7.4. Response Format
{
"domain": "example.com",
"verifier": "acme-saas",
"token": "da-verify=a1b2c3d4e5f6",
"issued_at": "2025-06-01T12:00:00Z",
"expires_at": "2025-06-08T12:00:00Z",
"status": "active"
}
6.7.5. Token Lifecycle
* Tokens MUST have an expiration time and SHOULD be automatically
retired after successful verification.
* The DA SHOULD support scoped access so that a verifier can only
retrieve tokens addressed to it, preventing one verifier from
discovering which other verifiers the domain works with.
* The DA SHOULD log all verification queries for audit purposes.
7. Layer 3: Trust
This section specifies how consumers establish confidence in the DA
endpoint and its responses. Layer 3 is OPTIONAL: a DA deployment
that implements only Layers 1 and 2 is valid. Layer 3 adds
cryptographic assurance for deployments that require it.
7.1. Transport Security
All communication with the DA MUST use HTTPS (TLS 1.2 or later, TLS
1.3 RECOMMENDED). The DA's TLS certificate MUST be valid for the
hostname specified in the designation record.
This requirement applies regardless of whether the domain implements
the other Layer 3 mechanisms described below. TLS is the baseline;
DNSSEC and response signing are additive.
Swaminathan Expires 7 December 2026 [Page 21]
Internet-Draft Domain Authority June 2026
7.2. DNSSEC Anchoring of the Designation Record
If the domain's zone is signed with DNSSEC, the DA designation record
SHOULD also be signed. A DNSSEC-validated designation record
provides cryptographic assurance that the DA hostname is
authoritative for the domain.
Consumers that support DNSSEC validation SHOULD verify the
designation record before trusting the DA endpoint. If DNSSEC
validation fails, the consumer MUST treat the designation record as
untrusted and SHOULD fall back to standard DNS resolution.
This mechanism establishes a cryptographic chain from the DNS root to
the DA endpoint: the DNSSEC chain authenticates the designation
record, which names the DA, which is accessed over TLS. Together,
these ensure that the consumer is communicating with the domain's
intended DA.
7.3. Response Signing
A DA MAY sign individual responses to provide cryptographic integrity
and authenticity independent of the transport layer. Signed
responses allow consumers to verify that the data was produced by the
domain's DA, cache and forward responses without loss of
authenticity, and detect tampering by intermediaries.
If the DA supports response signing:
* The alg field in the designation record SHOULD identify the
signing algorithm.
* The fp field in the designation record SHOULD provide the signing
key fingerprint.
* Each signed response MUST include a signature field containing the
signature value.
This specification does not mandate a specific signature format.
Implementations MAY use JWS (RFC 7515), detached CMS signatures, or
other established mechanisms. Future revisions of this specification
may standardize a signature format based on implementation
experience.
Swaminathan Expires 7 December 2026 [Page 22]
Internet-Draft Domain Authority June 2026
7.4. Graceful Degradation
If the DA becomes unavailable, consumers MUST fall back to standard
DNS resolution. The DA is a complementary distribution path; DNS
remains the universal baseline. Domains SHOULD continue to publish
critical records (MX, A, AAAA) in DNS regardless of DA availability.
7.5. Detachment
A domain can disable its DA at any time by removing the designation
record from DNS. Consumers will stop discovering the DA after normal
DNS TTL expiration and negative caching. This provides a recovery
mechanism if the DA is compromised.
7.6. Summary of Trust Mechanisms
+=====================+===========+==========================+
| Mechanism | Status | Depends On |
+=====================+===========+==========================+
| HTTPS/TLS transport | REQUIRED | Layer 1 (valid hostname) |
+---------------------+-----------+--------------------------+
| DNSSEC on | OPTIONAL | Layer 1 + DNSSEC-signed |
| designation record | (SHOULD) | zone |
+---------------------+-----------+--------------------------+
| Response signing | OPTIONAL | Layer 2 (responses to |
| | (MAY) | sign) |
+---------------------+-----------+--------------------------+
| Graceful | REQUIRED | Layer 1 |
| degradation to DNS | | |
+---------------------+-----------+--------------------------+
| Detachment via | REQUIRED | Layer 1 |
| record removal | (support) | |
+---------------------+-----------+--------------------------+
Table 2
8. Security Considerations
8.1. DA as a High-Value Target
Because the DA consolidates domain information behind a single
endpoint, it is a high-value target. Implementations SHOULD employ
rate limiting and DDoS mitigation, access logging and anomaly
detection, key material protection (HSMs or equivalent), and
geographic replication for availability.
Swaminathan Expires 7 December 2026 [Page 23]
Internet-Draft Domain Authority June 2026
8.2. Designation Record Attacks
The DA designation record is the trust anchor for the entire system.
If an attacker can modify this record, they can redirect consumers to
a malicious DA. The primary defense is DNSSEC signing of the
designation record (Section 7.2). Domains that cannot deploy DNSSEC
rely on registrar-level protections (registry lock, two-factor
authentication on registrar accounts) to protect the designation
record.
8.3. domain-ownership Token Security
The domain-ownership namespace handles sensitive verification tokens.
Implementations MUST enforce token expiration (Section 6.7.5).
Implementations SHOULD scope token access to the designated verifier
to prevent enumeration of the domain's vendor relationships.
Implementations SHOULD require verifier authentication (API key,
shared secret) before returning tokens.
8.4. host-auth Credential Management
The host-auth namespace exposes non-public information.
Implementations MUST validate all credentials before serving
authenticated content. Implementations SHOULD support credential
rotation and revocation. Failed authentication attempts SHOULD be
logged and rate-limited.
8.5. public-key Namespace Security
The public-key namespace distributes cryptographic material.
Implementations SHOULD sign public-key responses (Section 7.3) to
prevent substitution attacks. Consumers SHOULD verify response
signatures before trusting served keys, particularly when using
served keys for TLS certificate pinning or DANE-like validation.
9. IANA Considerations
9.1. Well-Known URI Registration
This document requests registration of the following well-known URI
suffix in the "Well-Known URIs" registry [RFC8615]:
* URI suffix: da
* Change controller: IETF
* Specification document(s): This document
Swaminathan Expires 7 December 2026 [Page 24]
Internet-Draft Domain Authority June 2026
* Related information: None
9.2. DA Designation Record
This document defines a TXT record format at _da.<domain>. No new
DNS record type registration is required. Future revisions of this
specification MAY propose a dedicated DNS record type if adoption
warrants simplified parsing.
9.3. Bundle Type Registry
This document establishes a registry of DA bundle types under the
dns-bundle namespace. The initial entries are:
+=============+================================+===============+
| Bundle Type | Description | Specification |
+=============+================================+===============+
| email-auth | SPF + DKIM + DMARC | This document |
+-------------+--------------------------------+---------------+
| service | SRV + TLSA + TXT for a service | This document |
+-------------+--------------------------------+---------------+
| certificate | TLSA + CAA | This document |
+-------------+--------------------------------+---------------+
Table 3
Additional bundle types may be registered via Specification Required
policy [RFC8126].
9.4. Key Purpose Registry
This document establishes a registry of key purpose values under the
public-key namespace. The initial entries are:
+=========+==================================+===============+
| Purpose | Description | Specification |
+=========+==================================+===============+
| tls | TLS certificates and public keys | This document |
+---------+----------------------------------+---------------+
| dkim | DKIM public keys | This document |
+---------+----------------------------------+---------------+
| smime | S/MIME certificates | This document |
+---------+----------------------------------+---------------+
Table 4
Additional purpose values may be registered via Specification
Required policy [RFC8126].
Swaminathan Expires 7 December 2026 [Page 25]
Internet-Draft Domain Authority June 2026
9.5. DA Namespace Registry
This document defines five initial namespaces under the DA well-known
URI. Future specifications MAY register additional namespaces via
Standards Action policy [RFC8126].
+==================+=============================+===============+
| Namespace | Description | Specification |
+==================+=============================+===============+
| dns-bundle | Atomic record bundles | This document |
+------------------+-----------------------------+---------------+
| public-key | Public key distribution | This document |
+------------------+-----------------------------+---------------+
| host-api | Domain-defined APIs | This document |
+------------------+-----------------------------+---------------+
| host-auth | Authenticated access | This document |
+------------------+-----------------------------+---------------+
| domain-ownership | Domain control verification | This document |
+------------------+-----------------------------+---------------+
Table 5
10. References
10.1. Normative References
[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/rfc/rfc2119>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[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/rfc/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/rfc/rfc8174>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
Swaminathan Expires 7 December 2026 [Page 26]
Internet-Draft Domain Authority June 2026
10.2. Informative References
[DCV] Sahib, S. K., Huque, S., Wouters, P., and E. Nygren,
"Domain Control Validation using DNS", Work in Progress,
Internet-Draft, draft-ietf-dnsop-domain-verification-
techniques-12, March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
domain-verification-techniques>.
[DNSApps] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in
the DNS", Work in Progress, Internet-Draft, draft-iab-dns-
applications-07, February 2013,
<https://datatracker.ietf.org/doc/html/draft-iab-dns-
applications-07>.
[DomainConnect]
Kowalik, A., "Domain Connect Protocol", Work in Progress,
Internet-Draft, draft-kowalik-domainconnect-00, October
2024, <https://datatracker.ietf.org/doc/html/draft-
kowalik-domainconnect-00>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/rfc/rfc2782>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
DOI 10.17487/RFC4255, January 2006,
<https://www.rfc-editor.org/rfc/rfc4255>.
[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/rfc/rfc5507>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>.
Swaminathan Expires 7 December 2026 [Page 27]
Internet-Draft Domain Authority June 2026
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/rfc/rfc6698>.
[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/rfc/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/rfc/rfc7489>.
[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/rfc/rfc8555>.
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/rfc/rfc8659>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
Appendix A. Adoption Scenarios
These scenarios are non-normative. They illustrate how the three
layers can be adopted incrementally.
A.1. Minimal Adoption: Domain Ownership Only
A domain deploys Layer 1 and a single namespace (domain-ownership).
Immediate benefit: private domain verification, elimination of TXT
record litter. No other namespace required. Layer 3 is not
implemented; trust relies on TLS alone.
Swaminathan Expires 7 December 2026 [Page 28]
Internet-Draft Domain Authority June 2026
A.2. Internal Service Discovery
A mid-size organization deploys Layer 1 with host-api to publish a
real-time service catalog -- endpoints, health status, protocol
versions, and geographic availability -- for consumption by internal
tooling (deployment dashboards, API gateways, incident response
systems). The organization also deploys host-auth to serve
operational metadata to authenticated internal consumers: compliance
scanners retrieving SOC2 attestations, monitoring systems accessing
SLA parameters, and CI/CD pipelines querying deployment
configurations.
This scenario is particularly effective for ephemeral infrastructure.
Serverless functions, containers, and edge workers have lifespans
measured in seconds to hours -- too short for DNS TTL propagation.
The DA provides a stable, DNS-anchored endpoint whose host-api
content updates instantly as services spin up, scale, migrate, or
shut down. Consumers discover the DA once (via DNS) and query it for
current service state (via HTTPS) without TTL delay.
A.3. Full Deployment
A domain deploys all three layers with all five namespaces -- atomic
bundles, public key distribution, domain-defined APIs, authenticated
partner access, and private domain verification. DNSSEC signing of
the designation record and response signing provide cryptographic
assurance across all namespaces.
Author's Address
Kishore Swaminathan
Email: k.s.swaminathan@live.com
Swaminathan Expires 7 December 2026 [Page 29]