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. 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. 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. 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.. 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.. 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, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . 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, . [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, . [DomainConnect] Kowalik, A., "Domain Connect Protocol", Work in Progress, Internet-Draft, draft-kowalik-domainconnect-00, October 2024, . [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, . [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, . [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, DOI 10.17487/RFC4255, January 2006, . [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, . [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, . 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, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [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, . [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, . 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]