Network Working Group R. Seethiraju Internet-Draft S. Thakar Intended status: Standards Track K. Shyamsunder Expires: 7 December 2026 E. Osterweil Verisign 5 June 2026 DNS-Based Agent Naming (DAN): AIDISCA and AIINDEX Resource Records for AI Agent Discovery draft-seethiraju-dawn-dan-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Seethiraju, et al. Expires 7 December 2026 [Page 1] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Necessary and Sufficient Metadata . . . . . . . . . . . . 5 1.4. Consistency of Metadata . . . . . . . . . . . . . . . . . 5 2. The AIDISCA Resource Record . . . . . . . . . . . . . . . . . 6 2.1. AIDISCA RDATA Format . . . . . . . . . . . . . . . . . . 6 2.2. Field Descriptions . . . . . . . . . . . . . . . . . . . 7 2.2.1. AI Agent Proto . . . . . . . . . . . . . . . . . . . 7 2.2.2. Certificate Association Fields . . . . . . . . . . . 7 2.2.3. Capabilities Length . . . . . . . . . . . . . . . . . 8 2.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 8 2.2.5. Service Endpoint Length . . . . . . . . . . . . . . . 8 2.2.6. Service Endpoint . . . . . . . . . . . . . . . . . . 8 2.2.7. Extensions Length . . . . . . . . . . . . . . . . . . 9 2.2.8. Extensions . . . . . . . . . . . . . . . . . . . . . 9 2.3. Presentation Format . . . . . . . . . . . . . . . . . . . 9 3. The AIINDEX Resource Record . . . . . . . . . . . . . . . . . 10 3.1. AIINDEX RDATA Format . . . . . . . . . . . . . . . . . . 11 3.2. Field Descriptions . . . . . . . . . . . . . . . . . . . 11 3.2.1. AI Agent Domain Name List Length . . . . . . . . . . 11 3.2.2. AI Agent Domain Name List . . . . . . . . . . . . . . 11 3.2.3. Extensions Length . . . . . . . . . . . . . . . . . . 12 3.2.4. Extensions . . . . . . . . . . . . . . . . . . . . . 12 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 12 4. Client Processing Model . . . . . . . . . . . . . . . . . . . 13 4.1. Optional Discovery . . . . . . . . . . . . . . . . . . . 14 4.2. Metadata Retrieval . . . . . . . . . . . . . . . . . . . 14 4.3. Runtime Interaction . . . . . . . . . . . . . . . . . . . 14 5. Alternative Considerations . . . . . . . . . . . . . . . . . 14 6. Response Size Considerations . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.1. Integrity and Authenticity . . . . . . . . . . . . . . . 16 7.2. Certificate Association and Endpoint Authentication . . . 16 7.3. Endpoint Verification Scope . . . . . . . . . . . . . . . 16 7.4. Input Handling . . . . . . . . . . . . . . . . . . . . . 16 7.5. Privacy Considerations . . . . . . . . . . . . . . . . . 17 Seethiraju, et al. Expires 7 December 2026 [Page 2] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8.1. DNS Resource Record Types . . . . . . . . . . . . . . . . 17 8.2. AI Agent Proto Registry . . . . . . . . . . . . . . . . . 17 8.3. AI Agent DNS Extension Code Registry . . . . . . . . . . 18 9. Normative References . . . . . . . . . . . . . . . . . . . . 19 10. Informative References . . . . . . . . . . . . . . . . . . . 19 Appendix A. Operational Considerations . . . . . . . . . . . . . 20 A.1. AI Agent Metadata Management . . . . . . . . . . . . . . 20 A.2. AIINDEX Publication . . . . . . . . . . . . . . . . . . . 20 A.3. Multiple AIDISCA Records . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction 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) [RFC1035] 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 [RFC6698] (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. Seethiraju, et al. Expires 7 December 2026 [Page 3] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.1. Terminology 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. 1.2. Approach 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. Seethiraju, et al. Expires 7 December 2026 [Page 4] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 1.3. Necessary and Sufficient Metadata 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 [MCP], 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 [A2A], 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. 1.4. Consistency of Metadata 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 Seethiraju, et al. Expires 7 December 2026 [Page 5] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 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 [AGENT_METADATA_SIZE_ANALYSIS]. 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. 2. 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 [RFC6698], and extends it to include additional fields required to describe agent-specific metadata. 2.1. AIDISCA RDATA Format 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. Seethiraju, et al. Expires 7 December 2026 [Page 6] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AI Agent Proto| Cert Usage | Selector | Matching Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capabilities Length | Service Endpoint Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Assoc Data Length | Extensions Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / Capabilities (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Service Endpoint (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Certificate Association Data (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Extensions (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: AIDISCA RDATA Wire Format 2.2. Field Descriptions 2.2.1. AI Agent Proto 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 Section 8. 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. 2.2.2. Certificate Association Fields The Cert Usage, Selector, Matching Type, and Certificate Association Data fields are defined in [RFC6698] and are used without modification. Seethiraju, et al. Expires 7 December 2026 [Page 7] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 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 [RFC6698] for the Selector, Matching, Usage, and Certificate Association Data fields of the TLSA record. 2.2.3. Capabilities Length The Capabilities Length field is a 16-bit unsigned integer in network byte order. It specifies the length, in octets, of the Capabilities field. 2.2.4. Capabilities 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. 2.2.5. Service Endpoint Length 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. 2.2.6. Service Endpoint 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. Seethiraju, et al. Expires 7 December 2026 [Page 8] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 2.2.7. Extensions Length 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. 2.2.8. Extensions 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 [RFC6891]. Extension Code values are assigned through the IANA registry defined in Section 8. 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 Section 8. 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. 2.3. Presentation Format 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 [RFC1035], Section 5.1. Seethiraju, et al. Expires 7 December 2026 [Page 9] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 The Service Endpoint field follows the URI representation conventions used by the URI Resource Record defined in [RFC7553]. 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 [RFC6698]. 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. booking._agents.example.com. 60 IN AIDISCA ( 1 3 1 1 "hotel-booking,itinerary" "https://example.com/agent" 12AB34CD56EF78AA90BB12CC... "\000\001\000\030https://example.com/agent-card" ) Figure 2 3. The AIINDEX Resource Record 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). Seethiraju, et al. Expires 7 December 2026 [Page 10] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 3.1. AIINDEX RDATA Format 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 [RFC1035], 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. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AI Agent Name List Length | Extensions Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / AI Agent Domain Name List (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Extensions (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: AIINDEX RDATA Wire Format 3.2. Field Descriptions 3.2.1. AI Agent Domain Name List Length 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. 3.2.2. AI Agent Domain Name List 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 [RFC1035]. DNS name compression MUST NOT be used within the AI Agent Domain Name List field. Seethiraju, et al. Expires 7 December 2026 [Page 11] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 3.2.3. Extensions Length 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. 3.2.4. Extensions 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 [RFC6891] for EDNS(0) options. Extension Code values are assigned through the IANA registry defined in Section 8. 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. 3.3. Presentation Format 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. example.com. 60 IN AIINDEX ( booking._agents.example.com. search._agents.example.com. ) Figure 4 Seethiraju, et al. Expires 7 December 2026 [Page 12] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 4. Client Processing Model 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 [RFC6698]. 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. Seethiraju, et al. Expires 7 December 2026 [Page 13] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 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. 4.1. Optional Discovery 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. 4.2. Metadata Retrieval 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. 4.3. Runtime Interaction 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 [RFC6698] for the specified endpoint, to verify consistency with the published association. 5. Alternative Considerations Goal: clients want to resolve and connect to AI agents... Seethiraju, et al. Expires 7 December 2026 [Page 14] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 One alternative approach to creating a single DANE-like record like AIDISCA is to use existing service records, like SVCB [RFC9460], 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). 6. Response Size Considerations 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 [AGENT_METADATA_SIZE_ANALYSIS]) 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 [DNS_FLAG_DAY]. 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 [RFC7766]. 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. Seethiraju, et al. Expires 7 December 2026 [Page 15] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 7. Security Considerations 7.1. Integrity and Authenticity 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. 7.2. Certificate Association and Endpoint Authentication 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 [RFC6698] (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. 7.3. Endpoint Verification Scope 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. 7.4. Input Handling 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. Seethiraju, et al. Expires 7 December 2026 [Page 16] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 7.5. Privacy Considerations 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. 8. IANA Considerations 8.1. DNS Resource Record Types IANA is requested to assign two new DNS Resource Record (RR) TYPE codes from the "Resource Record (RR) TYPEs" registry: * AIDISCA * AIINDEX 8.2. AI Agent Proto Registry 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: Seethiraju, et al. Expires 7 December 2026 [Page 17] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 +=========+===============================+ | Value | Description | +=========+===============================+ | 0 | Reserved | +---------+-------------------------------+ | 1 | Model Context Protocol (MCP) | +---------+-------------------------------+ | 2 | Agent-to-Agent Protocol (A2A) | +---------+-------------------------------+ | 3-244 | Unassigned | +---------+-------------------------------+ | 245-255 | Reserved for Private Use | +---------+-------------------------------+ Table 1 New assignments are to be made via Specification Required as defined in [RFC8126]. 8.3. AI Agent DNS Extension Code Registry 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 | +-------------+--------------------------+ Table 2 New assignments are to be made via Specification Required as defined in [RFC8126]. Seethiraju, et al. Expires 7 December 2026 [Page 18] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 9. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10. Informative References Seethiraju, et al. Expires 7 December 2026 [Page 19] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 [AGENT_METADATA_SIZE_ANALYSIS] Seethiraju, R., Thakar, S., Shyamsunder, K., and E. Osterweil, "Discovering Agents for Discovery: The Case for DNS", 2026, . [DNS_FLAG_DAY] Surý, O., "DNS Flag Day 2020", 2019, . [MCP] Model Context Protocol, "Model Context Protocol Specification", 2025, . [A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification", 2026, . Appendix A. Operational Considerations This appendix provides non-normative operational guidance for deployment and management of AIDISCA and AIINDEX records. A.1. AI Agent Metadata Management 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. A.2. AIINDEX Publication 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. Seethiraju, et al. Expires 7 December 2026 [Page 20] Internet-Draft AIDISCA/AIINDEX DNS Records June 2026 A.3. Multiple AIDISCA Records 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. Authors' Addresses Ramachandra Rao Seethiraju Verisign Email: rseethiraju@verisign.com Sameer Thakar Verisign Email: sthakar@verisign.com Karthik Shyamsunder Verisign Email: kshyamsunder@verisign.com Eric Osterweil Verisign Email: eosterweil@verisign.com Seethiraju, et al. Expires 7 December 2026 [Page 21]