DNS-Based Agent Naming (DAN): AIDISCA and AIINDEX Resource Records for AI Agent Discovery
draft-seethiraju-dawn-dan-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ramachandra Rao Seethiraju , Sameer Thakar , Karthik Shyamsunder , Eric Osterweil | ||
| Last updated | 2026-06-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-seethiraju-dawn-dan-00
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, <https://www.rfc-editor.org/info/rfc1035>.
[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, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[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,
<https://www.rfc-editor.org/info/rfc7766>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[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, <https://www.rfc-editor.org/info/rfc9460>.
[RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource
Identifier (URI) DNS Resource Record", RFC 7553,
DOI 10.17487/RFC7553, June 2015,
<https://www.rfc-editor.org/info/rfc7553>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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, <https://arxiv.org/pdf/2606.02314>.
[DNS_FLAG_DAY]
Surý, O., "DNS Flag Day 2020", 2019,
<https://www.isc.org/blogs/dns-flag-day-2020/>.
[MCP] Model Context Protocol, "Model Context Protocol
Specification", 2025,
<https://modelcontextprotocol.io/specification/latest>.
[A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification",
2026, <https://a2a-protocol.org/latest/specification/>.
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]