]>

k.s.swaminathan@live.com

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.

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.

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.

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.

Relationship to Existing Standards This specification builds on and is compatible with: , , , , , , , , , and . 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.

Differentiation from Related Work 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. (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 uses DNS to bootstrap API relationships for DNS record provisioning (write path). The DA standardizes how domain information is consumed (read path). 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. 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.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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 record identifying its DA endpoint. Specified in .

Retrieval Layer:

The five namespaces through which consumers request and receive domain information from the DA. Specified in .

Trust Layer:

The mechanisms by which consumers verify the authenticity and integrity of the designation record and DA responses. Specified in .

Architectural Overview The standard comprises three layers. Each layer is independently useful and incrementally deployable. 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.

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.

Layer 1: Designation This section is entirely normative. It specifies the DNS record by which a domain designates its DA endpoint.

Designation Record Format A domain designates its Domain Authority by publishing a DNS TXT record at the following name: ]]> The record format is: 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 () and the path prefix is always /.well-known/da/ (), 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 ). Example: alg=ed25519.
• fp=: Fingerprint of the DA's signing key, for out-of-band verification (see ).

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.

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.

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

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.

Namespace Overview The DA exposes five namespaces under the well-known URI prefix : 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).

Common Response Requirements The following requirements apply to all namespaces.

Response Format All responses MUST be JSON with Content-Type application/json.

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.

Error Responses Error responses MUST use standard HTTP status codes and SHOULD include a JSON body: 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).

CORS Implementations SHOULD include CORS headers for browser-based consumers.

dns-bundle: Atomic Record Bundles

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.

URI Structure 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).

Examples Retrieve the email authentication bundle: Retrieve the certificate bundle for a subdomain:

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

public-key: Public Key Distribution

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

URI Structure The namespace supports three levels of access: 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.

Examples Retrieve the key catalog: Retrieve all TLS keys: Retrieve the TLS certificate for a specific service: Retrieve a DKIM public key by selector:

Catalog Response Format The catalog provides an index of all available keys:

Individual Key Response Format Individual key responses SHOULD use JWK format as the base representation: 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).

host-api: Domain-Defined APIs

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.

URI Structure Where {api-path} is defined by the domain. This specification does not constrain the structure below host-api/.

Examples Service discovery catalog: Capability declaration:

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.

host-auth: Authenticated Access

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.

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

Authentication Mechanisms 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: The discovery endpoint, if implemented, MUST return a JSON object with an auth_methods array listing supported methods:

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.

domain-ownership: Private Domain Control Validation

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

URI Structure Where {verifier-id} is an identifier for the third-party verifier (e.g., a service name or verification request ID).

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

Response Format

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.

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.

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.

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.

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.

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.

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.

Summary of Trust Mechanisms

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

Security Considerations

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.

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 (). Domains that cannot deploy DNSSEC rely on registrar-level protections (registry lock, two-factor authentication on registrar accounts) to protect the designation record.

domain-ownership Token Security The domain-ownership namespace handles sensitive verification tokens. Implementations MUST enforce token expiration (). 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.

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.

public-key Namespace Security The public-key namespace distributes cryptographic material. Implementations SHOULD sign public-key responses () 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.

IANA Considerations

Well-Known URI Registration This document requests registration of the following well-known URI suffix in the "Well-Known URIs" registry :

• URI suffix: da
• Change controller: IETF
• Specification document(s): This document
• Related information: None

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.

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

Additional bundle types may be registered via Specification Required policy .

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

Additional purpose values may be registered via Specification Required policy .

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 .

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. Informative References The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Internet Architecture Board This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. This memo provides information for the Internet community. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK] The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs. This document obsoletes RFC 6844. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.

Adoption Scenarios These scenarios are non-normative. They illustrate how the three layers can be adopted incrementally.

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.

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.

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.