]> Infoblox, Inc.

jmozley@infoblox.com

Infoblox, Inc.

nic@infoblox.com

Unaffiliated

sarikaya@ieee.org

Deutsche Telekom

roland.schott@telekom.de

ops dnsop DNS AI Service Discovery agent-to-agent agent2agent This document specifies a method for utilizing the Domain Name System (DNS) to facilitate scalable and interoperable discovery between AI agents. The proposed mechanism, referred to as DNS AI agent Discovery (DNS-AID), defines a structured DNS namespace and record usage model to support metadata exchange and capability advertisement. This will allow organisations to publish information about their AI agents on the Internet or internal networks using a well-known label within the organisation’s own DNS namespace. This document does not define how the published agent information is accessed or the exact structure of that information. Instead, it specifies a mechanism for indicating which access protocol should be used and what format the agent information will be provided in. This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction DNS-AID introduces a leaf zone convention (e.g., _agents.example.com) containing Service Binding (SVCB) records (e.g., chat._agents.example.com) that encode application-specific metadata. These records enable agents to retrieve operational parameters prior to initiating a session, supporting both targeted lookups and capability-based discovery. The approach leverages existing DNS protocols and records, including DNS Service Discovery (DNS-SD), DNSSEC, and DANE, to provide integrity, authenticity, and automation without requiring human intervention. Lastly, the draft for Domain Control Validation (DCV) proposes a best current practice to prove an agent is authorized to act on behalf of a domain. This mechanism provides the bootstrap for discovering an organization's agents. An organization can publish it's own registry of agents and their capabilities at a well-known entry point in the DNS hierarchy. It is also possible to provide names for commonly used agents, so that any registry does not need to be queried and the returned capabilities processed (e.g. on a model card or other schema) and then the name of this resolved. It is expected that other drafts will develop the content of any registry, such as refining the model card concept to a more structure schema, and the protocol used to interact with the registry. It is more performant and deterministic to receive the details of the IP, protocols and port from an SVCB record than it is to determine this from a model card. It also mitigates against the vulnerability of parsing this information from a model card. For example, a company may only have a few external agents available for use, and if the IETF standardizes 'types' of AI agents, then perhaps _chat._agents.example.com or _img2txt._agents.example.com etc are all different SVCB records. On the other hand a company may provide an index of all agents via a well know entry point in the DNS hierarchy e.g. _index._agents.example.com. The DNS-AID model is designed for incremental and non-disruptive deployment within existing DNS infrastructure. It introduces no new DNS message formats, opcodes, response codes, or resource record types. Instead, it defines a structured namespace convention and usage profile for existing record types... primarily SVCB, TXT, and TLSA all within designated leaf zones (e.g., _a2a._agents.example.com). Organizations may adopt DNS-AID by publishing agent metadata under delegated subdomains, leveraging DNSSEC for integrity and authenticity, and optionally implementing Domain Control Validation (DCV) to signal delegated authority. These zones may be exposed selectively via split-horizon DNS or different zones, enabling differentiated discovery views for internal and external agents. No changes are required to recursive or authoritative DNS server implementations beyond standard support for DNSSEC and SVCB. This model supports opt-in adoption, allowing agent operators to publish discovery metadata without coordination with external registries or protocol maintainers. It is compatible with existing DNS tooling, including zone provisioning systems, monitoring platforms, and resolver configurations. DNS-AID is therefore suitable for deployment across enterprise, cloud, and federated environments, and may coexist with other discovery mechanisms without conflict.

Conventions and Definitions 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.

DNS Mechanisms for Agent Discovery AI agents that need to be discovered are currently being developed to support tasks such as travel planning, etc. See .

Use of Service Binding Records in Discovery Agents will use SVCB records as defined in to discover other agent endpoints under structured leaf zones (e.g., _chat._agents.example.com). These records allow querying agents to retrieve operational parameters prior to initiating a session, including supported protocols, privacy features (e.g., Encrypted Client Hello via ECH), and failover configurations. Agents may advertise support for QUIC, HTTP/3, or agent-to-agent protocols via ALPN declarations. Operators may specify alternate endpoints or migrate services across domains without relying on CNAME indirection, improving performance and reducing DNS resolution complexity. When paired with attribute leaf zones and custom SVCB parameters, this mechanism enables fine-grained discovery of agent capabilities. For instance, an agent querying _a2a._agents.example.com may receive an SVCB record indicating supported modalities (e.g., chat, image-to-text), expected input formats, and cost-related metadata (e.g., token pricing). This structured discovery model supports deterministic, cacheable, and semantically rich interactions between agents. SVCB records can indicate the protocol used to communicate with a given agent as in :

DNS-Based Service Discovery DNS-SD as defined in , extends the capabilities of the Domain Name System to support service-type-based discovery. Unlike traditional DNS resolution, which requires prior knowledge of a specific hostname, DNS-SD enables clients to discover services based on their functional type (e.g., _http._tcp, _printer._udp) within a given domain. DNS-SD provides a mechanism for AI agents to discover other agents or services based on declared capabilities rather than explicit names. For example, an agent may issue a query for _data-cleaner._a2a._agents.example.com to locate services capable of performing data sanitization tasks. This type-based discovery model supports dynamic ecosystems where agent roles and capabilities may evolve over time. DNS-SD operates over both multicast DNS (mDNS) and unicast DNS, allowing for flexible deployment in local networks and globally scoped domains. In enterprise or cloud environments, unicast DNS-SD enables structured and policy-compliant discovery across organizational boundaries. When combined with SVCB records, DNS-SD allows agents to retrieve detailed service metadata, including transport preferences, protocol support, and operational parameters. This model supports federated agent architectures, where multiple agents may advertise similar capabilities under different domains. By leveraging DNS-SD, agents can perform capability-based queries and receive a list of candidate services, each accompanied by structured metadata for evaluation and selection. DNS-SD also supports extensibility through TXT records and custom service naming conventions, enabling organizations to encode additional attributes relevant to agent interaction (e.g., supported data formats, authentication requirements, or cost models). A TXT record with the same name as the SVCB record could be used to provide additional meta-data. These features make DNS-SD a suitable foundation for scalable, interoperable, and semantically rich agent discovery workflows. An index of agents type service can be provided via DNS-SD as a well known entry point to a more complete capability description via a common schema e.g. _index._agents.example.com. This may be used in addition to or instead of querying for specific agent services such as _data-cleaner._a2a._agents.example.com. Querying specific services will shortcut communication vs. querying an index derived from something like organisation's agent registry.

Domain Control Validation DCV refers to the process by which an entity demonstrates authoritative control over a DNS domain. As described in , DNS-based DCV typically involves the placement of a DNS record, most commonly a TXT record, containing a challenge token or assertion at a designated location within the domain. This record is then queried by an Application Service Provider (ASP) to confirm control. The authors do not intend for authorization to exist solely within this phase of the discovery process, however there may be use cases in which agents acting on behalf of domains, prior to application handshake, can prove they are acting on behalf of a domain (organization). This may be a preferable mechanism, especially for ephemeral agents, to prove they act on behalf of a domain, rather than manage many temporary security mechanisms across multiple information security pillars (firewalls, certs, etc.). In the context of DNS-AID, DCV provides a mechanism for agents to assert delegated authority on behalf of a domain. For example, an organization may publish a TXT record under a structured leaf zone (e.g., _agent-roles._a2a._agents.example.com) containing metadata such as: ai-role=data-cleaner; crm=salesforce; access=readonly This record signals that a specific agent is authorized to perform scoped operations under the domain's authority. When protected by DNSSEC, such assertions become cryptographically verifiable, mitigating risks of spoofing or unauthorized delegation. DCV within DNS-AID supports both ephemeral and persistent validation models. Ephemeral validation may be used for short-lived agent credentials or session-based delegation, while persistent records enable long-term authorization signaling. TTL and expiration considerations, as discussed in the draft, are critical to ensuring that validation records do not persist beyond their intended scope. Furthermore, DNS-AID encourages the use of application-specific naming conventions and token formats to avoid service confusion and collision. Validation records should be scoped to the intended service and include unguessable tokens or structured metadata to prevent unauthorized reuse across federated agent ecosystems.

Architecture DNS’s hierarchical namespace supports multi-tenant and federated discovery models. Organizations may delegate subdomains to tenants (e.g., customer1._agents.vendor.com) or publish agent metadata under federated zones (e.g., region1._a2a.example.org). This enables scoped discovery, policy enforcement, and operational isolation across tenants, departments, or geographic regions. Combined with DNSSEC and access controls, this model supports secure delegation and trust signaling in complex agent ecosystems, including SaaS platforms and cross-organizational collaborations.

Example Communication Agent (org1) wants to find other agents provided by another entity (org2) and discover/verify capabilities :

Example Record

_a2a._agents.example.com.: The service name, following the SVCB naming convention (_service._agents.example.com). 3600: TTL (Time to Live) in seconds. IN SVCB: The record type. 1: SVCB priority. 0 is for alias mode; 1+ is for service mode. ai-index-svc.org2.com.: The target name of the service. alpn="a2a": Specifies the ALPN protocol identifier. This is where your custom protocol is declared. port=443: The port on which the service is available. ipv4hint and ipv6hint: Optional hints for clients to connect directly.

Example Use Cases A user instructs their internal agent to “clean up Salesforce contacts based on this email.” The agent must discover Salesforce’s authorized agents, validate its own delegation to act on behalf of the enterprise, and initiate a secure session. DNS-AID enables this by publishing agent endpoints and roles under DNS zones controlled by each organization. A research consortium deploys agents across multiple institutions. Each institution publishes its agents under its own domain (e.g., _a2a._agents.universityA.edu), allowing collaborators to discover services based on capability (e.g., _data-annotator._a2a.universityB.edu) while respecting institutional boundaries and trust models. A SaaS provider hosts agents for multiple customers. Each customer’s agents are published under tenant-specific zones (e.g., customer1._agents.saas.com), enabling scoped discovery and policy enforcement. DNS-AID supports this model through hierarchical zone delegation and metadata-rich SVCB records. Lightweight agents deployed on mobile or edge devices require low-latency, cacheable discovery mechanisms. DNS’s distributed architecture and support for SVCB hints (e.g., IP addresses, preferred protocols) enable efficient resolution and connection bootstrapping in constrained environments. In regulated industries, agents must operate within jurisdictional boundaries and maintain audit trails of interactions. DNS supports geographic scoping via ccTLDs and split-horizon configurations, while query logging and DNSSEC provide observability and integrity guarantees.

Zone and Other Requirements

Delegation and Chain of Trust A public authoritative zone used for the purposes of agent discovery MUST use DNSSEC . The zone MUST establish a complete chain of trust to a publicly recognized trust anchor. AI agents MUST use validating resolvers, or have the capability to validate records. All DNS-AID‑specific discovery records (e.g. SVCB/HTTPS , TXT/URI used for capability descriptors, and any DNS-AID‑defined RRTypes) MUST be signed and published in the DNS-AID External Zone. Where DNS-AID endpoints rely on TLS, publication of DANE TLSA records SHOULD be used to bind endpoint certificates to DNSSEC‑validated names . Resolver behavior consuming DNS-AID data MUST treat DNSSEC‑bogus responses as failures and MUST NOT act on unsigned or invalidly signed discovery data.

Performance Optimization(s) Each agent service endpoint that is specifically published as a DNS record SHOULD be an SVCB record in ServiceMode (or HTTPS RR for HTTPS endpoints) to convey connection parameters and capability locators with a single lookup . SVCB “address hints” (ipv4hint, ipv6hint) SHOULD be used to reduce A/AAAA follow‑up queries; resolvers MAY still validate final addresses via canonical resolution. Where human‑friendly names are required, SVCB AliasMode (priority 0) MAY be used to map from a stable alias name to a canonical name. Authoritative servers MUST support EDNS(0) and TCP fallback . Operators SHOULD target response sizes that avoid IP fragmentation on common paths (e.g., ≤1232 bytes on IPv6), preferring compression and layered indirection over oversized RRsets. TTLs MUST be chosen to reflect the volatility of capability data; index/indirection records may use longer TTLs than frequently changing endpoint or capability descriptors. Negative caching MUST conform to . When high update rates are expected, IXFR and NOTIFY SHOULD be used to reduce propagation latency. A representative naming pattern is shown below; the exact label order is deployment‑specific, but the leaf per service, per agent rule applies: ``` ; Hashed, per-agent, per-service leaf a4k2f9._mcp._agents.example.org. 600 IN SVCB 1 svc-a4k2f9.example.org. alpn="map,h2,h3" port=443 ipv6hint=2001:db8::5 ipv4hint=192.0.2.5 ; Optional alias for a friendlier owner name billing._mcp._agents.example.org. 300 IN SVCB 0 a4k2f9._mcp._agents.example.org. ```

Customization(s) DNS-AID deployments MAY define additional SVCB parameters (SvcParamKeys) to convey agent‑specific capability metadata, provided that interoperability safeguards in are observed. During experimentation, unregistered keys MUST use the numeric keyNNNNN presentation form, and any client behavior that depends on them MUST be gated via the mandatory SvcParam to ensure downgrade safety. This specification defines the following provisional SvcParamKeys for DNS-AID (names are illustrative; production deployments MUST register through IANA per or use keyNNNNN until standardized): The following are example use cases for additional params: cap — a capability descriptor locator or inline identifier (e.g., a URN or compact JSON‑Ref) that identifies the agent’s advertised capability schema/version. cap-sha256 — a base64url‑encoded SHA‑256 digest of the canonical capability descriptor to support integrity checks and cache revalidation. policy — a URI or URN identifying a policy bundle applicable to this agent (e.g., jurisdiction, data handling class) for client‑side selection. realm — an opaque token for multi‑tenant scoping or authz realm selection during protocol bootstrapping. Clients that require any of these parameters MUST verify their presence via the mandatory key; otherwise, the SVCB record MUST be ignored. Example: Single-RRTYPE publication with custom params (experimental keys shown) a4k2f9._mcp._agents.example.org. 600 IN SVCB 1 svc-a4k2f9.example.org. alpn="h2" port=443 ipv4hint=192.0.2.5 mandatory=alpn,port,key65001,key65002,key65010 key65001="cap=urn:cap:example:mcp:invoice.v1" key65002="cap-sha256=yvZ0n7q8bE2gYkz8m1j1s0yQG0mC2F6qj3b9pVb6Gk0" key65010="bap=a2a/1,mcp/1" Where endpoints are HTTPS, the HTTPS RR variant SHOULD be used to co‑locate transport parameters such as ECH with capability metadata; otherwise, generic SVCB MAY be used. Future standardization SHOULD define the exact syntax (e.g., ABNF) and registry policy for these keys, including error handling for malformed or conflicting parameters. Until registration is complete, deployments MUST treat unknown keyNNNNN parameters as opaque and MUST NOT infer semantics without out‑of‑band agreement.

Implementation Guidance

Discovery Usage Examples

Discovery Status 1 (Known Service and Domain) Query foobar._mcp._agents.example.com : In this scenario, the AI Agent Client knows both the service type (mcp) and the authoritative domain (example.com) and performs a direct SVCB query.

Discovery Status 2 (Known Service OR Domain, Trusted) Query of the known organisation's index if service is unknown : In this scenario, the Agent Client knows the trusted domain (example.com) but the specific agent service type is unknown. The client queries a well-known index entry point to discover available agent capabilities. The index query is not DNS.

Discovery Status 3 (Multi-Domain Query for Known Service) Query the same well-known agent name across multiple known domains (potential for this discovery case to be met by the registry described in Discovery Status 4):

Discovery Status 4 (Untrusted Domain / Consolidated Registry) Query a consolidated (reputable) registry (not DNS) when neither domain nor comprehensive service list is known:

Discovery Status 4 (Unknown / Wildcard, or status 2 untrusted?) This case is out of scope.

AI Providers

Publishing Schema Publishers SHOULD expose per‑service discovery records using SVCB (or HTTPS for HTTP origins) at stable, well‑scoped owner names (e.g., agent-id._mcp._agents.example.org.). SVCB ServiceMode conveys connection parameters and capability locators in a single round trip; AliasMode MAY be used to map a friendly name to a hashed leaf for sharding without duplicating RRSets. Initial connection parameter keys (alpn, port, address hints) and the mandatory key MUST be honored by clients. Minimal example: ; ServiceMode SVCB for an MCP-capable agent a4k2f9._mcp._agents.example.org. 600 IN SVCB 1 svc-a4k2f9.example.net. alpn="h2,h3" port=443 ipv6hint=2001:db8::5 ipv4hint=192.0.2.5 mandatory=alpn,port SVCB/HTTPS semantics and SvcParam processing MUST follow to ensure interop and correct fallback.

TTLs, Update Agility Publishers SHOULD assign longer TTLs to relatively static indirection records (aliases, stable service labels) and shorter TTLs to volatile endpoint/capability records to balance cache efficiency with rollout safety. Consumers will apply negative caching per , so publishers SHOULD avoid unnecessary NXDOMAIN flaps during deployments (e.g., prefer blue/green leaves over in‑place deletions).

Example DNS-AID Zonefile ``` $ORIGIN example.org. $TTL 3600 ; ---------------------------------------------------------------------- ; SOA / NS ; ---------------------------------------------------------------------- @ IN SOA ns1.example.org. hostmaster.example.org. ( 2025091901 ; serial (YYYYMMDDnn) 7200 ; refresh 1800 ; retry 1209600 ; expire 3600 ) ; minimum IN NS ns1.example.org. IN NS ns2.example.org. ns1 IN A 192.0.2.53 ns1 IN AAAA 2001:db8::53 ns2 IN A 192.0.2.54 ns2 IN AAAA 2001:db8::54 ; ---------------------------------------------------------------------- ; DNS-AID discovery (MCP example): per-service, per-agent leaf ; - Leaf is a stable mapping from AgentID -> label (e.g. hashed). ; - Use SVCB ServiceMode (priority > 0) to bind connection parameters. ; ---------------------------------------------------------------------- ; AliasMode to keep a friendly name stable even if the leaf changes billing._mcp._agents 300 IN SVCB 0 a4k2f9._mcp._agents.example.org. ; Leaf per agent/service (ServiceMode). Shorter TTL for agility. a4k2f9._mcp._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \ alpn="h2,h3" \ port=443 \ ipv4hint=192.0.2.5 \ ipv6hint=2001:db8::5 \ mandatory=alpn,port ; (Optional) Another service face for the same agent (A2A) a4k2f9._a2a._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \ alpn="h2" port=8443 \ mandatory=alpn,port ; (Optional) HTTPS RR at apex for web-style consumers of DNS-AID metadata @ 900 IN HTTPS 1 web-gw.example.net. \ alpn="h2,h3" port=443 ; ---------------------------------------------------------------------- ; Capability / policy signaling via SVCB custom keys (experimental) ; Use numeric keyNNNNN until you register IANA SvcParamKeys. ; Gate client requirements with "mandatory". ; ---------------------------------------------------------------------- ; Example: reference a capability descriptor and advertise supported app protocols. ; NOTE: Values and key numbers are illustrative. a4k2f9._mcp._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \ alpn="h2,h3" port=443 \ mandatory=alpn,port,key65001,key65010 \ key65001="cap=urn:cap:example:mcp:invoice.v1" \ key65010="bap=a2a/1,mcp/1" ; ---------------------------------------------------------------------- ; Domain Control Validation (DCV) for DNS-AID authorization ; Publish a short-lived token to prove control over example.org. ; Remove after successful validation. Resolver MUST DNSSEC-validate. ; ---------------------------------------------------------------------- _agents-challenge 300 IN TXT "bnd-req=svc:crm-sync@vendor.example;nonce=3Qz6l8pA;exp=2025-09-19T06:00:00Z" ; ---------------------------------------------------------------------- ; Optional DANE TLSA for the service endpoint used above. ; Owner: _<port>._tcp.<endpoint-FQDN> ; Usage 3 (DANE-EE), Selector 1 (SPKI), Match 1 (SHA-256) ; Replace the hash with the actual SPKI hash of the leaf certificate. ; ---------------------------------------------------------------------- _443._tcp.svc-a4k2f9.example.net. 1800 IN TLSA 3 1 1 ( 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789AB ) ; ---------------------------------------------------------------------- ; (Optional) Address records for the service endpoint, if hosted in-zone ; If hosted out-of-zone (example.net), these will live there instead. ; ---------------------------------------------------------------------- svc-a4k2f9 900 IN A 192.0.2.5 svc-a4k2f9 900 IN AAAA 2001:db8::5 web-gw 900 IN A 192.0.2.80 web-gw 900 IN AAAA 2001:db8::80 ```

How to use this zonefile Adjust TTLs for agility vs. cache efficiency. Use longer TTLs on indirection (aliases), shorter TTLs on volatile leaves and DCV. This aligns with DNS caching behavior and negative caching rules . Follow SVCB/HTTPS semantics. Clients must honor SvcPriority, AliasMode (priority 0), and ServiceMode parameters, including mandatory, alpn, port, and address hints per . DCV token flow. Issue a time‑bounded token at _agents-challenge.domain and require DNSSEC‑validated retrieval (pattern analogous to ACME’s DNS‑01 in ). Remove on success. Bind transport to DNS with DANE (optional). If your relying parties validate DNSSEC, publish TLSA to bind the endpoint’s cert/key, using the operational guidance in (TLSA record format in ). Sign the zone. This file is pre‑signing. Sign with DNSSEC (DNSKEY/DS/RRSIG, etc.) before deployment; validators must treat unsigned/bogus discovery data as a failure (per your earlier spec). See DNSSEC core specs , , and operational guidance.

Why these records SVCB/HTTPS concentrate connection metadata and allow aliasing at apex and service labels, reducing round trips and enabling policy‑gated parameters via mandatory. Per‑service, per‑agent leaves avoid oversized RRsets and allow parallel administration/sharding while keeping alias names stable. This follows performance guidance in SVCB and your DNS-AID perf section. DCV via TXT mirrors a well‑understood, automated control‑proof pattern that fits DNS-AID authorization workflows. DANE TLSA optionally removes reliance on external PKI anchors for endpoint auth where DNSSEC is deployed , with deployment rules in .

Future Work & Unaddressed Portions How a consolidated registry would operate? Would it gather and publish information from individual organisations (scraping), would those organisations registery attest to security and be verified?

Security Considerations DNSSEC security considerations apply.

IANA Considerations IANA is requested to register an underscored attribute leaf as part of for agents. IANA is requested to designate custom key-value pairs for SVCB parameters to facilitate agent-to-agent application discovery, potentially for cost optimization (token input counts, costs per token bundle, etc.)

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 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. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. Brave Software Salesforce Aiven Akamai Technologies Cox Communications Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. 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] This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs. 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 clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK] 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. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.

Acknowledgments The authors thank Ben Schwartz and Ross Gibson for their contributions, questions, and comments.