Verisign

rseethiraju@verisign.com

Verisign

sthakar@verisign.com

Verisign

kshyamsunder@verisign.com

Verisign

eosterweil@verisign.com

The agentic AI ecosystem includes many different technologies and operations. One important aspect is the ability to establish connections between AI agents. In single-platform approaches, the processes and metadata with which AI agents discover, locate, and connect to each other are typically managed by their common platform. This document describes an inter-domain mechanism to enable AI agents to locate and connect to each other using necessary metadata and secure DNS associations, in a similar fashion to the way that DNS-Based Authentication of Named Entities (DANE), RFC6698, does for Transport Layer Security. This is accomplished through two new Resource Record (RR) types: AIDISCA and AIINDEX.

Artificial Intelligence (AI) agent-based systems provide automated functionality across distributed environments. In these systems, AI agents discover and interact with other AI agents. These AI agents are reachable through network endpoints and their services are advertised as capabilities. Stable navigation and inter-domain connectivity is, and will continue to be, a fundamental need for the agentic AI ecosystem. Even as this agentic AI space continues to evolve, AI agents will continue to need to communicate with each other, discover data, process data, and perform actions. While inter-agent connections will vary in form and function, there is a finite set of metadata needed to establish connectivity. Agentic AI began in single-platform (intra-domain) environments, and must now be extended to the Internet's inter-domain space. In single platform environments, AI agents discover each other by using functionality built into their platform. Specifically, AI agents use names to identify themselves and each other. This document describes a name-based inter-domain mechanism to enable AI agents to locate and connect to each other using the Domain Name System (DNS) to advertise, name, and lookup AI agent names. This document defines an approach for AI agent discovery referred to as DNS-Based Agent Naming (DAN). DAN allows AI agents to be given DNS domain names as inter-domain names, and to advertise the necessary and sufficient set of metadata needed to locate services and connect securely. DAN is built on two new DNS Resource Record types (RRtypes). The first is a DNS-based Authentication of Named Entities (DANE)-like AI agent association record called AIDISCA. This RR associates a set of necessary metadata elements to an AI agent's domain name, which is sufficient to facilitate a secure connection to that AI agent. The second RR is the AIINDEX RR, which enables advertisement of a DNS zone's available AI agents. This document does not define semantic search, ranking, policy evaluation, or how to select AI agents; those functions are expected to be defined and performed separately. 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.

AI Agent (or Agent): An AI-based entity capable of performing actions or providing functionality through interaction with other AI agents. Capability: A function or operation provided by an AI agent that can be invoked by another AI agent. Service Endpoint: A network location at which an AI agent can be reached for interaction. AI Agent Metadata: Structured information describing an AI Agent publication, including capabilities, supported protocols, service endpoints, and cryptographic associations. The domain name at which the metadata is published provides the authoritative publication point under which that metadata is controlled. AI Agent Publication: The association of AI agent metadata with a domain name through DNS records.

To enable inter-domain AI agents to locate and connect to each other, DAN first creates a secure DNS-based discovery framework for AI agents. Then, a canonical set of necessary metadata is defined that is sufficient for securely associating AI agents' names with their identified endpoints. This approach defines a new AIDISCA record that uses DANE semantics directly, so that any existing trust or recognition that is already associated with the DNS zone containing an AIDISCA record can be transitively associated with a named AI agent. This record atomically associates capabilities, AI agent protocol, and an X.509 certificate to an AI agent, based on name resolution. In addition, this approach defines a mechanism to perform secure DNS-based discoverability of available AI agents on a per-zone basis, via its AIINDEX record.

AI agents determine which other AI agents to connect to with an understanding of what capabilities are available after connection. Therefore, to avoid promiscuous communication and opportunistic capability discovery, it is necessary for connecting AI agents to know capabilities of remote AI agents in advance of choosing to connect to them. Endpoint discovery is therefore outside the scope of the runtime interaction protocols themselves and relies on registries/catalogs, well-known URLs, or other ecosystem-specific discovery mechanisms. AI agent communication protocols can be logically separated into two architectural phases: endpoint discovery and runtime interaction. In the Model Context Protocol (MCP) model , for example, an AI agent first discovers and connects to an MCP endpoint. The MCP server then exposes tools, resources, prompts, and protocol interaction details through subsequent MCP network transactions and exchanges. Similarly, in the Agent to Agent (A2A) model , an AI agent first discovers an A2A endpoint and retrieves the Agent Card. The Agent Card and subsequent protocol interaction then expose skills/capabilities, workflows, authentication requirements, modalities, and interaction patterns. In both models, detailed runtime semantics are obtained after protocol initiation and are not required for initial endpoint discovery. AIDISCA standardizes only the interoperable discovery/bootstrap primitives required for protocol initiation: protocol identifier, coarse-grained capability, service endpoint, and certificate-bound identity verification. This architectural separation allows the DNS layer to remain focused on discovery, reachability, and trust bootstrapping, while protocol-specific interaction semantics remain within the protocol runtime layer itself.

As reasoned justification for constructing the RRtypes in this document, two general approaches to associating metadata with AI agent names are considered from first principles: 1) the set of metadata could be separated into multiple records, or 2) be bundled together atomically. In the case of 1), the set of necessary metadata is separated into either multiple records or requires multiple (separate) lookups if embedded metadata only links to external sources. In these cases, clients will require multiple network transactions to perform lookups/resolution of the entire set of necessary metadata. This will incur additional transaction time, and if some network transactions are unsuccessful, clients may only gain a partial set of necessary metadata. In addition to overhead, this creates a more complex requirement on the protocol to be able to address partial sets of metadata. Alternately, approach 2) prescribes retrieving metadata from a single record. This reduces the potential for inconsistencies that may arise when information is obtained from multiple independent sources. AIDISCA records provide an atomic representation of all AI agent metadata necessary to establish connectivity. A general evaluation framework for agentic AI naming and discovery is proposed and illustrated in . This consideration of first principles and the substance of the evaluation framework serves as justification for the approach in this document, which reduces the locations and variability of protocols required for AI agent operators to get the necessary and sufficient metadata in establishing connectivity to one location with the AIDISCA resource record.

The AIDISCA resource record encodes the complete set of necessary structured metadata that is sufficient for locating and communicating with an AI agent. The record format is based on the TLSA record defined in , and extends it to include additional fields required to describe agent-specific metadata.

The RDATA for the AIDISCA record consists of a sequence of fields describing the AI agent protocol, capabilities, and service endpoint certificate association, and optional extensions. The Extensions field provides an extensibility mechanism for optional metadata associated with an AI agent publication. Extensions are not required for interaction establishment and MUST NOT alter the semantics of the core AIDISCA fields.

AIDISCA RDATA Wire Format

The AI Agent Proto field identifies the protocol used to interact with the one instance of an AI agent that is referenced by a particular AIDISCA record. This field is a one-octet value referencing an IANA registry of AI agent communication protocols, defined below in . Each AIDISCA record describes the protocol for interacting with a single AI agent over a specific protocol. Multiple records may be published at the same domain name to enable connectivity over separate AI agent protocols.

The Cert Usage, Selector, Matching Type, and Certificate Association Data fields are defined in and are used without modification. The Cert Assoc Data Length field is a 16-bit unsigned integer in network byte order. It specifies the length, in octets, of the Certificate Association Data field. These fields specify certificate or public-key material associated with the Service Endpoint and enable endpoint verification using DNS-published associations. The Certificate Association Data binds the Service Endpoint to a certificate or public key. The processing procedures and rule MUST follow those specified in for the Selector, Matching, Usage, and Certificate Association Data fields of the TLSA record.

The Capabilities Length field is a 16-bit unsigned integer in network byte order. It specifies the length, in octets, of the Capabilities field.

The Capabilities field contains a UTF-8 encoded, comma-separated list of capability identifiers supported by the AI agent. Each identifier represents a function or operation that the AI agent can perform. Because AI agents use free text for processing, capabilities are not well suited to being derived from IANA registries. Capability identifiers are agent-defined and are not interpreted by DNS. The semantics of Capability identifiers MAY be interpreted within the context of the Agent protocol identified by the Agent Proto field, but this specification does not define or constrain capability vocabularies.

The Service Endpoint Length field is a 16-bit unsigned integer in network byte order. It specifies the length, in octets, of the Service Endpoint field.

The Service Endpoint field contains a UTF-8 encoded string representing a Uniform Resource Identifier at which the AI agent is reachable, and is the endpoint used to interact with the AI agent. The endpoint is not required to reside within the same domain name or domain boundary as the AIDISCA record. The endpoint can be verified against the certificate association defined in the record.

The Extensions Length field is a 16-bit unsigned integer in network byte order. It specifies the length, in octets, of the Extensions field. When the Extensions Length field is zero, the Extensions field is absent.

The Extensions field is optional. When present, the Extensions field consists of one or more code/length/value extension elements encoded using the same format as EDNS(0) options defined in . Extension Code values are assigned through the IANA registry defined in . Extensions MAY be used to publish optional metadata associated with an AI agent publication. This document defines an Agent Card extension code in the IANA registry described in . Such extensions are optional and are not required to establish the initial interaction with the Service Endpoint. Clients that receive extensions MUST ignore any entries for which they do not recognize the meaning of the code. If the Extensions field contains malformed extension data, including an extension length that exceeds the remaining Extensions field length or a truncated extension element, the Extensions field MUST be treated as invalid and ignored.

The following example illustrates the presentation format of an AIDISCA record. In presentation format, the Capabilities and Service Endpoint fields are represented as quoted character strings in DNS master file format. UTF-8 encoded content and URI characters are encoded directly within the quoted strings. Any required escaping MUST follow the DNS master-file quoting and escaping conventions defined in , Section 5.1. The Service Endpoint field follows the URI representation conventions used by the URI Resource Record defined in . In wire format, the Capabilities Length and Service Endpoint Length fields are derived from the lengths, in octets, of the corresponding UTF-8 encoded character strings. The Certificate Association Data field is represented in presentation format as hexadecimal data, following the TLSA presentation format defined in . The optional Extensions field, if present, is represented as one or more quoted escaped octet strings containing the complete encoded extension element sequence. The use of the "_agents" label in this example illustrates a recommended naming convention for publishing AIDISCA records. Implementations SHOULD publish AIDSCA records beneath a dedicated “_agents” label to support predictable discovery and operational consistency. Other naming conventions MAY be used where deployment requirements differ.

The AIINDEX resource record provides a mechanism for enumerating domain names at which AIDISCA records are published. This enables domain-scoped enumeration of AI agent publication points. This record allows zone administrators to choose which, if any, of the AI agents in their zone(s) they want to advertise as available. This can be a subset of those AI agents with AIDISCA records in a zone. AIINDEX enables scalable discovery and indexing of published AI agent metadata without requiring DNS crawling or zone enumeration. AIINDEX records SHOULD be published at the apex of the zone in which AI agent publication names are advertised. This aids discoverability, so that querying clients are able to locate AIINDEX records at a well known position in a zone's namespace (though zone administrators are able to place AIINDEX records at non-normative locations as well).

The RDATA for the AIINDEX record consists of an AI Agent Name List Length field, an Extensions Length field, a sequence of one or more domain names encoded in DNS wire format as described in , and an optional Extensions field. The sequence of domain names occupies the number of octets specified by the AI Agent Name List Length field. Individual domain names are parsed sequentially until the length is exhausted. The Extensions field, if present, follows the AI Agent Domain Name List field.

AIINDEX RDATA Wire Format

The AI Agent Domain Name List Length field is a 16-bit unsigned integer in network byte order. It specifies the length, in octets, of the AI Agent Domain Name List field.

The AI Agent Domain Name List field contains a variable-length sequence of domain names. Each domain name identifies a location where AIDISCA record is published. Each domain name is encoded using the DNS name representation defined in . DNS name compression MUST NOT be used within the AI Agent Domain Name List field.

The Extensions Length field is a 16-bit unsigned integer in network byte order. It specifies the length, in octets, of the Extensions field. When the Extensions Length field is zero, the Extensions field is absent.

The Extensions field is optional. When present, the values in the Extensions field are encoded as a sequence of code/length/value elements, as described in for EDNS(0) options. Extension Code values are assigned through the IANA registry defined in . Clients that receive extensions MUST ignore any entries for which they do not recognize the meaning of the code. If the Extension field contains malformed extension data, including an extension length that exceeds the remaining Extensions field length or a truncated extension element, the Extensions field MUST be treated as invalid and ignored.

The following example illustrates the presentation format of an AIINDEX record published at the apex of a zone. In presentation format, each AI agent publication name is represented as a domain name in DNS master file format. The optional Extensions field, if present, is represented as one or more quoted escaped octet strings containing the complete code/length/value extension sequence. The use of the "_agents" label in the referenced AIDISCA records of this example illustrates a recommended naming convention for publishing AIDISCA records.

Interaction with AI agent metadata is performed using DNS resolution. DNS provides an authoritative mechanism for retrieving both the set of AI agent publication names under a domain and the metadata describing each AI agent. A client that seeks AI agents published under a domain retrieves the AIINDEX record for that domain. The AIINDEX record contains a list of domain names identifying locations at which AIDISCA records are published. DNS messages returned to clients that contain AIDISCA and/or AIINDEX records MUST pass DNSSEC validation. Clients MUST treat AIDISCA and AIINDEX records that fail DNSSEC validation as invalid and MUST NOT use the associated metadata for discovery or interaction establishment. Each domain name contained in the AIINDEX record identifies a distinct publication point for AI agent metadata. A client can retrieve the AIDISCA record at one or more of these domain names in order to obtain structured metadata describing an individual AI agent. When a domain name corresponding to an AI agent is already known, the retrieval process can begin directly with the AIDISCA record for that name, without requiring an AIINDEX lookup. An AIDISCA record provides the information required to securely connect and interact with an AI agent, including the interaction protocol, capabilities, service endpoint, and certificate association data. The Service Endpoint identifies the network location used for interaction with the AI agent. The Certificate Association Data binds that endpoint to a certificate or public key using the certificate association semantics defined in . During interaction establishment, the endpoint presents a certificate as part of the underlying transport protocol. The certificate presented by the endpoint can be compared with the certificate association data obtained from DNS to confirm that the endpoint is consistent with the certificate association published under the domain name. The retrieval model separates discovery of AI agent names from retrieval of AI agent metadata. AIINDEX provides a domain-scoped discovery mechanism, while AIDISCA provides the metadata required to describe and interact with an individual AI agent publication. This document defines DNS-based mechanisms for publishing and discovering AI agent metadata using the AIINDEX and AIDISCA records. Functions such as indexing, aggregation, ranking, filtering, and selection of AI agents are outside the scope of this document and may be performed by systems external to DNS. DNS serves solely as the authoritative publication and retrieval mechanism for the metadata upon which such systems may operate. The client processing model consists of three logically distinct phases: optional discovery of AI agent publication names, retrieval of AI agent metadata, and runtime interaction establishment.

When the publication name of an AI agent is not already known, a client MAY retrieve the AIINDEX record associated with a domain. When doing so, the client MUST validate the response using DNSSEC in order to obtain one or more AI agent publication names. AIINDEX records that fail DNSSEC validation MUST be treated as invalid and MUST NOT be used for AI agent discovery.

A client retrieves the AIDISCA record associated with an AI agent publication name and MUST validate the response using DNSSEC. Retrieval of the AIDISCA record provides all the metadata necessary to establish interaction with the AI agent. AIDISCA records that fail DNSSEC validation MUST be treated as invalid and MUST NOT be used for interaction establishment.

After retrieving the AIDISCA record, the client MAY establish interaction with the service endpoint. During interaction establishment, the presented certificate is compared with the certificate association data obtained from the AIDISCA record and MUST conform to validation procedures specified in for the specified endpoint, to verify consistency with the published association.

Goal: clients want to resolve and connect to AI agents... One alternative approach to creating a single DANE-like record like AIDISCA is to use existing service records, like SVCB , or TXT records. The inherent flexibility in such an approach presents an appealing target for flexible specification. This, however, should be counterbalanced by two considerations: 1) can all relevant metadata values be encoded in such a record, or will they need to reference external or separate data records or sources? Also, 2) will the specification of externalities from 1) require additional resolution or network transactions? Other alternatives may combine DNS-based AI agent lookups and connectivity with additional resolution of necessary metadata from other forms of registries. In such approaches, important considerations for clients are additional latency of queries to the separate registry, a separate reliability profile of the external registry, and the additional complexity incurred by clients when there are partial states (such as if some of the transactions are successful but others are not).

The AIDISCA record includes variable-length fields such as Capabilities, Service Endpoint, and Certificate Association Data. Because these fields contribute to the overall size of DNS responses, consideration of the potential for exceeding Path Maximum Transmission Unit (PMTU) limits is important. An empirical analysis of service endpoint characteristics (such as described in ) provides measurement-based evaluation of the feasibility of encoding the necessary and sufficient set of metadata for the establishment of AI agent connectivity, as encoded in a single AIDISCA record. These results indicate that the necessary and sufficient metadata set fit in less than half the PMTU threshold suggested by . These results indicate that service endpoint and capability metadata can be represented within practical DNS response size ranges under the most common deployment conditions (90th percentile). In the statistically unlikely event that a message must be truncated, DNS implementations will fall back to standard DNS mechanisms for handling larger responses, TCP . Operators may consider the impact of field sizes and record density when publishing AIDISCA records, particularly in environments where response size or network constraints are a consideration.

To protect against clients being manipulated into interacting with unintended endpoints or processing and interpreting incorrect AI agent metadata, DNSSEC MUST be used for origin authentication and integrity protections. Responses containing AIDISCA and/or AIINDEX records that fail DNSSEC validation MUST be treated as invalid and MUST NOT be used for discovery or interaction establishment. DNSSEC validation protects AIDISCA and/or AIINDEX records against modification, injection, or suppression by an attacker.

The AIDISCA record includes certificate association data that adheres to the TLSA record format and clients MUST follow the same processing rules for the Usage, Association, Matching, and Certificate Association Data fields in AIDISCA as are defined for those fields in (DANE). This association binds the Service Endpoint to a certificate or public key using DNS. This ensures that the communications to the AI agent endpoint are authorized by the AIDISCA domain name, and communications can be authenticated and encrypted by the authorized certificate's key pair.

The Service Endpoint specified in an AIDISCA record is not required to have any discernable relationship with the AIDISCA record itself (e.g., does not need to be within the same domain name, under the same DNS TLD, in bailiwick, etc.). The endpoint can reference a service hosted under a different domain name. DNSSEC MAY be deployed for that endpoint's domain name, but is not mandated by this protocol.

Fields such as Service Endpoint and Capabilities are interpreted by clients and may influence connection behavior. These values are obtained from DNS and should be treated as externally supplied input. Implementations may apply validation and parsing appropriate to the underlying protocols and data formats in use. Ultimately, the accuracy and freshness of published metadata remain the responsibility of the domain owner or operator.

Publishing AI agent metadata in DNS makes this information publicly accessible. This may reveal details about available AI agents, capabilities, and service endpoints associated with a domain. Deployment choices SHOULD consider whether specific metadata elements are appropriate for publication in DNS, depending on the intended level of visibility.

IANA is requested to assign two new DNS Resource Record (RR) TYPE codes from the "Resource Record (RR) TYPEs" registry:

• AIDISCA
• AIINDEX

IANA is requested to create a new registry titled "AI Agent Protocol Values". This registry defines values for the AI Agent Proto field in the AIDISCA record. Each value identifies a protocol used to communicate with an AI agent. Each AIDISCA record specifies a single protocol. Multiple records may be published at the same domain name to represent support for multiple protocols. Initial values are:

Value	Description
0	Reserved
1	Model Context Protocol (MCP)
2	Agent-to-Agent Protocol (A2A)
3-244	Unassigned
245-255	Reserved for Private Use

New assignments are to be made via Specification Required as defined in .

IANA is requested to create a new registry titled "AI Agent DNS Extension Codes". This registry defines Extension Code values used in the Extensions fields of AIDISCA and AIINDEX records. Extension Code values identify the semantics and format of the corresponding Extension Data field. Initial values are:

Value	Description
0	Reserved
1	Agent Card
2-64999	Unassigned
65000-65535	Reserved for Private Use

New assignments are to be made via Specification Required as defined in .

Normative References Informative References Model Context Protocol A2A Project

This appendix provides non-normative operational guidance for deployment and management of AIDISCA and AIINDEX records.

Operators are responsible for maintaining the accuracy and freshness of published AI agent metadata. AI agent endpoints, capabilities, certificate associations, and optional extension data can change over time and SHOULD remain consistent with the deployed agent service. Operators SHOULD select TTL values appropriate for the expected rate of change of published AI agent metadata. Metadata that changes frequently SHOULD NOT be published with long TTL values.

AIINDEX records advertise AI agent publication names intended to be discoverable under a domain. Operators MAY publish only a subset of available AIDISCA records in the AIINDEX record. For example, to control the discoveryability of some AI agents through selective advertisement of AIDISCA records. Operators SHOULD consider the operational impact of large AIINDEX records, particularly when publishing large numbers of AI agent publication names.

A domain name MAY publish multiple AIDISCA records for the same AI agent. This would be approrpriate when an AI agent is reachable using mulitple communication protocols, such as MCP and A2A. In these cases, a separate AIDISCA record for each protocol is appropriate. Related AIDISCA records SHOULD NOT contain conflicting or stale metadata.