]> Infoblox, Inc.

jmozley@infoblox.com

Infoblox, Inc.

nic@infoblox.com

Unaffiliated

sarikaya@ieee.org

Deutsche Telekom

roland.schott@telekom.de

Amazon

jdamick@amazon.com

GoDaddy

scourtney@godaddy.com

ops dnsop DNS AI Service Discovery agent-to-agent agent2agent DAWN This document specifies DNS for AI Discovery (DNS-AID), a method for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them. It defines three discovery use cases, ordered by increasing latency and computational cost. In the known-agent case, the requestor knows both the agent and its domain, and a single DNS query returns connectivity information and key metadata. In the known-organization case, the requestor knows the domain but not which agent provides a required capability, and queries a well-known organizational index to get connectivity information to enable a capability search of a catalog, agent registry or database. In the known-capability case, the requestor knows only the required capability and must rely on an external directory or search service. This document addresses the known-agent and known-organization cases. The known-capability case is out of scope, but search and cataloging services can be built from the organizational index defined here. Once a client has learned an organization’s agents, later interactions can use the known-agent case, relying on a minimal, cacheable record set that each organization controls. DNS-AID uses Service Binding (SVCB) records, optionally with DNS-Based Service Discovery (DNS-SD) labels, DNSSEC, and DANE TLSA records. This gives agents direct connections that no third party mediates and works the same way on public and private networks. No new resource record types, opcodes, or response codes are introduced. 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 This document standardizes an approach for publishing AI agents in the DNS so that other agents can discover them. Discovery can be initiated based on one of three use cases, where they are ranked in ascending order of latency and computational power required to complete: Known Agent - The requestor knows both the agent and its origin domain, and a single DNS query provides connectivity information and key metadata (see ) Known Organisation - The requestor knows the domain but not which agent provides a required capability, and an organization-level index returns connectivity information to a catalog, agent registry or database from which one can be selected (see ) Known Capability - The requestor knows the required capability, but not the agent or domain, or knows neither, in which case it must rely on an external directory or search service (see ) Of the above discovery use cases, (1) and (2) are addressed by this document. The third use case can be derived from (2) based on a well-known entry point to an organization's index of agents, such that any organization could build a search service based on this information. In the event the capability is unknown, external search is likely used anyway, which is treated like (3).

Design DNS-AID is designed so that, once a client has learned an organization's agent capabilities, subsequent queries can use the first use case. The intention is to provide a minimum DNS record set, that is cacheable or even learnable as an agentic skill, with each organization able to control the advertisement of its own agents. This also provides consumers of agent services with a direct connection method for agentic workloads not mediated by a third party. Organizations can use the same approach within internal networks, providing consistency across public and private networks. The mechanism uses SVCB and DNS-SD to include connectivity and metadata within a single DNS record, and optionally utilizes DANE TLSA records to support efficiently establishing encrypted communication. A deployment using the DNS-AID approach uses the following: Service Binding (SVCB) records for the agent endpoint and protocol TLSA records MAY be used for the agent's TLS identity The records SHOULD be DNSSEC-signed for data origin authentication and data integrity, if TLSA records are used they MUST be signed DNS-Based Service Discovery (DNS-SD) MAY be used for compatibility with existing service-discovery tooling Several extensions - agent-to-zone control proofs, query-time policy signaling, and cross-domain search - are being explored in parallel and are summarized under . Section defines TXT records as the fallback where SVCB, or the SvcParamKeys below, cannot be published or served.

Determinism DNS discovery is deterministic and cacheable: a given query against a given zone returns the same SVCB and TLSA RRsets, signed and time-bounded, until the publisher rotates them. The downstream agent's decisions over the discovered metadata are not deterministic. Implementations and reviewers SHOULD treat DNS-AID as providing a verifiable transport for agent metadata, not as a guarantee that an agent will behave predictably given that metadata.

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.

agent

A program that exchanges structured messages with other programs (other agents, services, or human-facing applications), typically over an HTTP transport.

agent record

The SVCB record set published at an agent's primary owner name, together with any AliasMode records that redirect to it.

agent protocol

The application-layer protocol an agent speaks once a TLS connection has been established (for example, the Model Context Protocol or Agent-to-Agent). Carried in the proto SvcParamKey.

capability descriptor

A machine-readable document describing the operations, inputs, and outputs an agent exposes. The descriptor itself is fetched out of band; DNS-AID carries its URI and a SHA-256 digest of its canonical form.

organization index

The list of agents an organization chooses to advertise as discoverable, published at _index._agents.<domain>.

primary owner

The fully-qualified domain name at which an agent's normative SVCB ServiceMode record is published.

Discovery Use Cases This section of the document provides details of the three generic use cases, including DNS record usage.

Known Agent This section covers the use case where a requestor knows both the agent and its origin domain. A single SVCB record type query for agent-name.example.com returns IP addresses, transport, agent protocol, and descriptor metadata. A TLSA record type query authenticates the TLS endpoint, although implementations may use other mechanisms. This is the form publishers SHOULD support and the form requestors MUST try first. The SVCB record of an agent provides connectivity and service parameters to a discovering agent. These are summarized below: Parameter Meaning Reference TargetName Target of the SVCB record, which can be the same as the agent domain name or a different FQDN Note 1 ipv4hint TargetName IPv4 addressing Note 1 ipv6hint TargetName IPv6 addressing Note 1 alpn A transport protocol suite used by the target (e.g. alpn=h2,h3) Note 1 proto The agent protocol (e.g. mcp, a2a) Note 2 proto-ver The agent protocol version (e.g. 1.0, 2025-11-25) Note 2 well-known The .well-known suffix(es) Note 3 path Endpoint path Note 2 desc-ref Descriptor reference Note 2 desc-ref-digest Descriptor reference digest Note 2 Notes: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) Common Agent DNS Discovery Parameters An SVCB Service Parameter for Well-Known URI Paths Operators MAY publish the same agent under an _agents.example.com inventory leaf (for organizations that prefer a single containing prefix for their agents) or under a canonical DNS-SD label (so off-the-shelf DNS-SD clients can enumerate). In these cases SVCB AliasMode MUST be used to point at the primary owner. Not all parameters are needed in all cases, for instance a record for an agent protocol with a specification including a single fixed .well-known suffix as a description of version and capability (e.g. an agent card) may only need alpn and proto. Where an agent supports multiple protocols, or a single protocol has custom protocol bindings to support different transport mechanisms or communication patterns, then additional parameters will signal this to a discovering agent and prevent the need for probing for capability. Examples of these records are shown below in and their usage in :

) # An MCP server, path specified for the discovering agent ticket-server.example.com. 3600 IN SVCB 1 . ( alpn="h2,h3" port=443 ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 proto=mcp path=/api/agent ) # Agent agent-name where the TargetName is a hosted service agent-name.example.com. 3600 IN SVCB 1 resource.service-provider.example ( ... ) ]]>

| | | | | | | | | 2. Iterative Queries | | | | retrieve SVCB RRset | | | |<--------------------->| | | | | | | 3. Response to agent | | | | (validated + cached) | | | | Response includes: | | | | - TargetName | | | | - ALPN protocol suite | | | | - Port number | | | | - IPv4/IPv6 hints | | | | - DNSSEC signatures | | | | - Capabilities | | | |<-----------------------| | | | | | | | 4. TLSA Query | | | | (Recursive) | | | |----------------------->| | | | | | | | | 5. Iterative Queries | | | | retrieve TLSA RRset | | | |<--------------------->| | | | | | | 6. TLSA Response | | | | (validated+cached) | | | |<-----------------------| | | | | | | | 7. Agent validates | | | | certificate | | | | | | | | 8. Agent communication | | | | begins using service | | | | binding parameters | | | |--------------------------------------------------------------->| | | | | ]]>

Agents Supporting Multiple Protocols n agent that supports more than one agent-layer protocol publishes one SVCB record per protocol. Each record carries proto with a single protocol value and alpn with the HTTP transport versions. A client processes the RRset and selects the record matching the protocol it wants. Each agent protocol MUST be a separate record in the RRset:

Multiple agent protocols MUST NOT be combined in a single proto value:

An agent hosted at a service provider uses a distinct TargetName for each protocol endpoint:

Known Organization This section covers the use case where a requestor knows the organizational domain, but not which agent provides a required capability. This is likely to be an agent searching for a capability from an organizational database such as , or other agent directory. An SVCB record type query for _index._agents.example.com returns a pointer to an organization-specific registry of all agents, which is out of the scope of this draft. The requestor uses the data returned to select an agent and cache the selection so that the process in can be used for subsequent interaction. The data provided at _index._agents.{domain}, protocols and schemas are out of scope for DNS-AID. The TargetName MUST be used and MUST not contain underscores as used in DNS-SD labels, as public x.509 certificates will be used in communications with the index. Following the _index._agents.example.com SVCB record query, agents will use the TargetName for any TLSA record query. The labels _index._agents have been chosen as DNS-SD labels with the intent of registering them with IANA, as it is not possible to register a generic name such as agent-index. An index record SHOULD carry the parameters a client needs to reach and cache the index such as alpn and ipv4hint for connectivity information. Then parameters as applicable to the catalog, agent registry or database implementation such as well-known or path for the HTTP endpoint, desc-ref for the descriptor of the service, and proto where the index is itself served over an agent protocol. Examples of these records are shown below in :

| | | | | | | | | 2. Iterative Queries | | | | retrieve SVCB RRset | | | |<--------------------->| | | | | | | 3. Response to agent | | | | (cached+validated) | | | | Response includes: | | | | - TargetName | | | | - ALPN protocol | | | | - Port number | | | | - IPv4/IPv6 hints | | | | - DNSSEC signatures | | | | - Descriptor reference | | | |<-----------------------| | | | | | | | 4. TLSA Query for | | | | TargetName. | | | |----------------------->| | | | | | | | | 5. Iterative Queries | | | | retrieve TLSA RRset | | | |<--------------------->| | | | | | | 6. TLSA Response | | | | (validated+cached) | | | |<-----------------------| | | | | | | | 7. Agent validates | | | | certificate | | | | | | | | 8. Agent-to-agent | | | | communication | | | | Agent retrieves | | | | index via e.g. via | | | | https, a2a, etc. | | | |--------------------------------------------------------------->| | | | | | 9. Agent makes | | | | semantic search | | | | selection based on | | | | index data, caching | | | | agent details e.g. | | | | name, descriptor, etc. | | | | | | | | 10. Query for target | | | | agent SVCB RRset | | | |----------------------->| | | | | | | | | 10. Iterative queries | | | | retrieve SVCB RRset | | | |<--------------------->| | | | | | | 11. Response to agent | | | | as in step 3. | | | |<-----------------------| | | | | | | | 12. Cert. validation | | | | as in steps 3. to 7. | | | | | | | | 13. Agent communication| | | | begins using service | | | | binding parameters | | | |--------------------------------------------------------------->| | | | | ]]>

Known Capability This section covers the use case where the requestor knows the required capability, but not the organization or agent. This is a search based process and is out of the scope for DNS-AID. Directory services that aggregate records across organizations could be derived from by querying _index._agents.{domain} and using that data for a search service.

Use of TXT Records as a Fallback From SVCB Records SVCB is the primary record type for DNS-AID, as it is designed for service discovery . TXT records are the fallback where a DNS management portal, service, or server cannot publish SVCB records or serve the SvcParamKeys defined here; DNS server software supports TXT almost universally. Until IANA assigns code points, private-use SvcParamKey numbers may also differ between implementations, so TXT at the same owner name is the interoperability fallback for the parameters themselves. A TXT fallback record sits at the same owner name as the SVCB record it stands in for and uses the same key names, as key=value strings, so a client needs one vocabulary for both, for example "proto=a2a", "well-known=agent-card.json". A TXT record has no TargetName or SvcPriority, so it cannot point at an endpoint in a different domain, such as a service provider, nor order alternatives; where those are needed, SVCB is required. One option that can be considered as this draft is developed is to used an SVCB record in conjunction with a TXT record, with the same owner, to provide support for the additional parameters that will be registered with IANA, until these are incorporated into DNS server implementations. This would have the advantage of bringing SVCB into use as the standard for AI agents and organizational catalogs, so there is no upgrade or migration from TXT records needed, rather there would be a gradual reduction in TXT records for additional parameters and then deprecation.

Future Work and Experimental Mechanisms This section collects mechanisms that have been prototyped against the DNS-AID record set but that are not yet ready for normative specification in this document. Implementations MAY experiment with them; future revisions or separate documents are expected to standardize the ones that prove out. The headings below replace the briefer "Future Work & Unaddressed Portions" section in earlier revisions and consolidate the open questions raised there.

Agent Protocol and Version The proto parameter signals the agent-layer protocol for this SVCB record (e.g. proto=a2a, proto=mcp). The companion proto-ver parameter carries the version of that protocol in the protocol's own syntax (e.g. proto-ver=1.0 with proto=a2a, proto-ver=2025-11-25 with proto=mcp). proto-ver is a selection hint only; the protocol's own negotiation settles compatibility. Whether version signalling in DNS provides useful signal or adds only RDATA bloat remains under evaluation pending interoperability testing.

Domain Control Validation DNS-AID anticipates that agents and directories will sometimes need to prove that the publisher of an agent record controls the DNS zone in which it is published. The procedure in is one candidate mechanism: the challenger issues a short-lived token that the claimant publishes at _agents-challenge.{domain} as TXT, and the challenger reads it back over a DNSSEC-validated path. A binding parameter such as bnd-req=svc:<agent>@<issuer> can scope a token to a specific agent leaf and issuer to prevent cross-challenger reuse. A representative TXT record body and ABNF:

Open questions that should be answered before this is made normative: how a verifier scopes the number of records consulted for one verification, how expiry semantics interact with DNSSEC validity windows, and whether DCV results should be cached past their expiry. Consideration will also need to be given to the risk of this being used as an attack vector.

SVCB Indicating TLSA Support An SvcParamKey in the agent SVCB record could be used to indicate TLSA support for the agent. As the SVCB query is the first one queried this might improve efficiency. Although the discovering agent may simply send both an SVCB and TLSA query simultaneously and infer support from the query responses, indicating the presence of a TLSA record would be more deterministic.

EDNS(0) Discovery Hints A separate experimental mechanism allows a requestor to attach selector and metering hints to a DNS-AID query as an EDNS(0) option . Substrate selectors (realm, transport, jurisdiction, minimum trust level) can influence the returned RRset and participate in cache keys; metering hints (intent class, freshness budget, parallelism) are advisory and do not fragment caches. A reference implementation and wire format are tracked in dns-aid-core (see docs/experimental/edns-signaling.md and the accompanying ABNF). No IANA option-code reservation is requested in this revision; the option uses the private-use code range.

Consolidated Registry and Cross-Domain Search DNSAID-01 left open how a consolidated registry would operate -- whether it would scrape DNS-AID records published by individual organizations, or require attestation and verification from each publisher. The same question covers cross-domain search, i.e. locating agents whose origin domain the requestor does not know. This document treats both as upper-layer work; see for one complementary proposal.

Operator and Service Metadata SvcParamKeys Additional policy and realm SvcParamKeys are reserved for operator-controlled and service-controlled metadata that does not affect basic discovery: multi-tenant scoping, jurisdictional and compliance hints, and commercial signaling such as cost-per-unit-of-input, unit-of-input definitions, billing tiers, or rate-limit hints. The exact syntax of these payloads, the registry policy for any sub-keys that emerge, and the interaction between these parameters and the trust profile described in the Security Considerations section are open questions. Implementations are encouraged to experiment with concrete payloads in the private-use space and to report back so that a future revision can specify a common subset.

Connection Extensions as SvcParamKeys Using connect-class and connect-meta provides a mechanism to signal which transport models to use, and with which pieces of metadata. Class may indicate fields like direct for hostname+port semantics and lattice for integration with a vendor tools and services. Test implementations can use the Private Use parameter range and be moved to registered SvcParamKeys if they have wide spread applicability.

Zero Trust Extension SvcParamKeys Adding a capability like enroll-uri may be relevant for mediated zero-trust overlay connections where a caller/service must first complete enrollment/authentication prior to invocation of any skills. This can be added via an SvcParamKey.

JSON-Encoded Organization Index The TXT record-based form of _index._agents.{domain} may be suitable for small organizations and could be machine-parseable. A JSON-bodied variant, among others, has been discussed for larger inventories where TXT record chunking and multi-record assembly becomes complex and more subject to error. The encoding, signing, and validity-window rules for such a variant are open questions deferred to a future revision. It is anticipated that other standards will address organizational agent registries and the protocols to access them..

Security Considerations This section discusses the security properties of DNS-AID itself; the security of the agent protocols in agent-to-agent communication is out of scope. The threat models in (DNSSEC), , Section 10 (SVCB), and (DANE) apply unchanged.

Authenticity, Integrity, and Trust DNS-AID inherits authenticity from DNSSEC: a consumer that follows a validated chain of trust to a signed SVCB and TLSA record set has cryptographic evidence that those records were placed by an entity controlling the zone in which they were signed. DNS-AID does not, and cannot, assert that the agent reached through those records behaves benevolently. Authentic records may point at a malicious or compromised agent, and the descriptor referenced by the well-known or desc-ref parameters may itself contain instructions hostile to a consumer that interprets it (e.g. prompt-injection attacks against language-model agents). Consumers MUST treat the records published in DNS-AID as a verifiable transport for metadata, not as a trust signal in their own right; trust judgments MUST be made out of band by combining DNS-AID records with reputation, attestation, or organizational policy systems.

TLS Endpoint Authentication DNS-AID consumers SHOULD authenticate the TLS endpoint advertised by an SVCB record using DANE TLSA records at the conventional _443._tcp.<owner> name. Three operational postures are common:

permissive (default for general-internet consumers)

TLSA is queried; if a matching record is present and matches the presented certificate, the connection is pinned to it. If no TLSA record is present, the consumer falls back to WebPKI validation.

preferred

As permissive, but the absence of a TLSA record is noted in the consumer's audit log.

strict

A connection is refused unless a TLSA record is present and matches.

This document does not mandate any one posture. Strict-by-default is not appropriate for the general Internet today given current DANE adoption; permissive-with-fallback matches the implementation experience of .

Downgrade Resistance A publisher that requires a consumer to honor a particular SvcParamKey SHOULD list that key in the SVCB mandatory= parameter per , Section 8. A consumer that does not implement a key listed in mandatory= MUST skip the record. This prevents an attacker on the path from substituting an older subset of parameters without breaking discovery for old consumers. Until IANA assigns code points for the keys in this document, implementations may use different private-use numbers for the same key, so listing those keys in mandatory= (for example mandatory=proto) will not work reliably across implementations; TXT at the same owner name () is the interoperability fallback in the meantime.

DNSSEC Dependency and Operational Pitfalls DNS-AID is deployable without DNSSEC, but the authenticity guarantees it offers depend on a validated path from the root to the zone of interest. Consumers SHOULD validate DNSSEC and SHOULD refuse to act on bogus or unverifiable records. Zone operators SHOULD follow the operational guidance in and SHOULD avoid signing algorithms or key sizes that resolvers in the target ecosystem are likely to ignore. The mandatory= mechanism and DNSSEC validation interact: an unsigned record substituted in transit may cause a consumer to fall back to a less safe code path. Consumers MUST NOT relax DNSSEC validation requirements based on the apparent absence of mandatory= keys.

Threat-Model Cross-References The threat catalogs maintained by the OWASP Multi-Agentic System Threat Modeling work cover many agent-layer concerns that DNS-AID does not address directly. The substrate-level threats that DNS-AID does address (transport-identity spoofing, capability poisoning, downgrade) map roughly onto MAESTRO threats T47 / T7.1 / T9 (rogue server, agent impersonation), BV-2 (tool-description poisoning), and T7.6 (transport fallback downgrade). DNS-AID does not address workload-level MAESTRO threats; consumers SHOULD treat DNS-AID as one layer in defense in depth.

Privacy Considerations The names queried during DNS-AID discovery are visible to recursive resolvers and to any on-path observer of unencrypted DNS traffic. Consumers SHOULD use DNS over TLS or DNS over HTTPS where available. EDNS Client Subnet SHOULD NOT be sent on DNS-AID queries that would disclose user-identifying agent names; operators SHOULD set ECS scope to zero where DNS-AID is the only consumer of a zone.

IANA Considerations

DNS Service Parameter Keys SVCB record parameters detailed in this document will be registered via and

Underscored DNS Node Names IANA is requested to register the following entries in the "Underscored and Globally Scoped DNS Node Names" registry established by , Section 4. RR Type _NODE NAME Reference SVCB _agents this document SVCB _index this document TXT _agents-challenge this document (experimental; see ) The _agents-challenge registration is requested but tied to an experimental mechanism (see ); a future revision is expected to confirm or relinquish it.

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. 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 the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. 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. Cisco Cisco Infoblox, Inc. Infoblox This document defines parameters for AI agents that would be used in DNS and mDNS discovery processes. It provides a set of common parameters for different DNS records to facilitate agents communicating over application layer protocols such as A2A or MCP. 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 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. 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. Infoblox, Inc. (contribution to Linux Foundation pending) OWASP GenAI Security Project 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. Ericsson This document defines the Agent Directory (AD), a service where agents register their identity, capabilities, and reachable endpoints and where clients discover them by capability. The AD adapts the Constrained RESTful Environments (CoRE) Resource Directory (RFC 9176) from constrained IoT devices to software agents, reusing its registration, lookup, and soft-state lifecycle model. The AD uses HTTP and JSON. MCP and A2A define how agents interact; this document defines how they are found. 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 it 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'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. GoDaddy OWASP DistributedApps.ai OWASP Cisco Systems Autonomous AI agents now invoke one another across organizational boundaries over protocols such as the Model Context Protocol (MCP) and Agent2Agent (A2A). A relying party has no interoperable way to bind a discoverable agent endpoint to the holder of its domain (optionally verified as a legal entity), a specific software release, and an auditable issuance history. This document specifies the architecture of Agent Name Service version 2 (ANS v2), an identity layer, anchored in DNS domains, that binds an agent endpoint to its domain holder, its release, and its history. ANS v2 composes systems the Internet already runs (the DNS with DNSSEC; the Web PKI, with DANE where operators publish it; and an append-only transparency log) and introduces no new root of trust. Every ANS v2 agent carries a versioned name rooted in a DNS domain that the registrant controls. When a registrant registers an agent, the Registration Authority (RA) checks the registrant's control of that domain, can issue an Identity Certificate that binds the versioned name to the agent's key, and submits a signed registration record to a Merkle-tree transparency log. Under the current specifications, a new version is a new registration and a new log entry, so a verifier can pin an agent to a specific release. Any third party can detect a rewritten log by computing, from the log's public tiles, a consistency proof between two of its signed checkpoints. For discovery, ANS v2 adopts the SVCB records and SvcParams of DNS for AI Discovery (DNS-AID) as its default format, and keeps an older TXT-based format only as an opt-in profile. Beyond those discovery records, ANS v2 specifies one DNS record, an "_ans-badge" TXT record that points to the agent's transparency-log entry; the log seals the fingerprint of the agent server's certificate, and operators can add DANE records. With these records, a verifier resolves an agent, authenticates its TLS endpoint, and confirms that the presented name, version, and key match a logged registration. This document also states a threat model covering agent impersonation, DNS spoofing, CA and Registration Authority compromise, version rollback, agent card tampering, and log rewriting, and names what each ANS check does and does not prevent. The reference registry, transparency log, verifier, JSON Schemas, SDKs, and CLI are open source. This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. Cisco Cisco Infoblox, Inc. Infoblox This document defines parameters for AI agents that would be used in DNS and mDNS discovery processes. It provides a set of common parameters for different DNS records to facilitate agents communicating over application layer protocols such as A2A or MCP. Infoblox, Inc. Old Dog Consulting This document defines the "well-known" Service Parameter Key (SvcParamKey) for SVCB and HTTPS resource records. It carries one or more well-known URI suffixes, identifying resources under "/.well- known/" that are available at the service endpoint. It specifies the presentation and wire formats and requests registration of the key with IANA.

Contributors The authors thank the following people for their substantial input to this document: Ralf Weber (Akamai), and John Zinky (Akamai).

Acknowledgments The authors also would like to thank Connor Snitker (GoDaddy), Chungwei Yen (GoDaddy), Patrick Mevzek (GoDaddy), Jim Gilbert (Akamai), Hema Seshadri (Akamai), Aaron Parecki (Okta), Ihab Shraim (CSC), Vincent DAngelo (CSC), and Nick Sullivan for their feedback and discussion.