| Internet-Draft | Domain Authority | June 2026 |
| Swaminathan | Expires 7 December 2026 | [Page] |
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.¶
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.¶
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.¶
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:¶
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.¶
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).¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
A DNS TXT record at _da.<domain> that associates a domain with its Domain Authority, containing a version identifier and the DA's hostname.¶
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.¶
The mechanism by which a domain publishes a DNS record identifying its DA endpoint. Specified in Section 5.¶
The five namespaces through which consumers request and receive domain information from the DA. Specified in Section 6.¶
The mechanisms by which consumers verify the authenticity and integrity of the designation record and DA responses. Specified in Section 7.¶
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.¶
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.¶
The standard MUST NOT require new DNS record types, modified resolver behavior, or changes to authoritative DNS server software.¶
Any domain MUST be able to adopt the standard independently, without requiring action by other domains, resolvers, or service providers.¶
Existing DNS resolution MUST continue to function identically. The DA operates as a complementary distribution path, not a replacement.¶
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.¶
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.¶
The standard MUST support, but not mandate, cryptographic signing of DA responses, authenticated access, and encrypted transport.¶
This section is entirely normative. It specifies the DNS record by which a domain designates its DA endpoint.¶
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).¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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 records as a unit | Public |
| public-key | Size-unconstrained key distribution | Public |
| host-api | Extensibility -- domain-defined APIs | Public |
| host-auth | Access control -- authenticated access | Authenticated |
| domain-ownership | Privacy -- scoped verification | Private |
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).¶
The following requirements apply to all namespaces.¶
All responses MUST be JSON with Content-Type application/json.¶
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.¶
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).¶
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.¶
/.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.¶
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).¶
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¶
{
"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"
}
¶
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.¶
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.¶
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).¶
{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.¶
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¶
The catalog provides an index of all available keys:¶
{
"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"
}
¶
Individual key responses SHOULD use JWK format [RFC7517] as the base representation:¶
{
"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).¶
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.¶
/.well-known/da/host-api/{api-path}
¶
Where {api-path} is defined by the domain. This specification does not constrain the structure below host-api/.¶
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¶
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.¶
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.¶
/.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.¶
This specification does not mandate a specific authentication mechanism. Implementations MAY support:¶
Bearer tokens (OAuth 2.0, API keys)¶
Mutual TLS (mTLS)¶
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"
}
¶
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.¶
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.¶
[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:¶
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.¶
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.¶
/.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).¶
A third-party service requests domain ownership verification from the domain operator.¶
The domain operator provisions a verification token at the DA under the domain-ownership namespace, scoped to the requesting verifier.¶
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¶
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.¶
Upon successful verification, the domain operator (or the DA automatically) retires the token.¶
{
"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"
}
¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
| Mechanism | Status | Depends On |
|---|---|---|
| HTTPS/TLS transport | REQUIRED | Layer 1 (valid hostname) |
| DNSSEC on designation record | OPTIONAL (SHOULD) | Layer 1 + DNSSEC-signed zone |
| Response signing | OPTIONAL (MAY) | Layer 2 (responses to sign) |
| Graceful degradation to DNS | REQUIRED | Layer 1 |
| Detachment via record removal | REQUIRED (support) | Layer 1 |
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.¶
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.¶
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.¶
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.¶
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.¶
This document requests registration of the following well-known URI suffix in the "Well-Known URIs" registry [RFC8615]:¶
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.¶
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 |
Additional bundle types may be registered via Specification Required policy [RFC8126].¶
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 |
Additional purpose values may be registered via Specification Required policy [RFC8126].¶
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 |
These scenarios are non-normative. They illustrate how the three layers can be adopted incrementally.¶
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.¶
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 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.¶