{"slug":"dns-aid-goes-vendor-neutral-linux-foundation-takes-over-agent-discovery","citations":[{"url":"https://www.linuxfoundation.org/press/linux-foundation-announces-dns-aid-project-to-advance-decentralized-ai-agent-discovery","committed_hash":"sha256:3834ad9857e601e32ee69eb1130cc1b9a94dd04f2393d736ac6e55bb0c179a09","committed_hash_short":"sha256:3834ad98…0c179a09","mime_type":"text/html","committed_at":"2026-09-01T14:00:26.846449+00:00","content_snapshot":"\n \n \n Linux Foundation Announces DNS-AID Project to Advance Decentralized AI Agent Discovery\n \n\n \n \n \n \n \n\n \n\n \n \n\n\n\n\n\n\n\n\n\n\n\n \n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n \n \n \n \n \n \n \n\n\n\n\n\n \n
\n
\n\n
\n \n \n
\n
\n \n

Open Source Summit Europe • 7-9 OCT 2026 • REGISTER NOW

\n
\n \n
\n \n \n \n \n \n
\n
\n \n
\n \n \n \n \n \n \n \n
\n

\n Search\n

\n
\n
\n \n \n \n \n \n \n
\n
\n
    \n
    \n \n \n
    \n
    \n
    \n \n \n
    \n
    \n
    \n \n
    \n
    \n
    \n \n
    \n
    \n
    \n \n Join\n \n
    \n
    \n
    \n \n
    \n
    \n \n
    \n \n\n
    \n \n\n
    \n
    \n \n \n
    \n
    \n \n 6 MIN READ\n \n

    Linux Foundation Announces DNS-AID Project to Advance Decentralized AI Agent Discovery

    \n
    The Linux Foundation | 27 May 2026
    \n
    \n\n \n
    \n \n \n \n \n \n \n
    \n \n \n
    \n
    \n

    \"Press

    \n\n

    New project enables open, secure, decentralized connectivity for the emerging agentic web

    \n

    Summary

    \n
      \n
    • The Linux Foundation announced the launch of the DNS-AID project, a new open source project designed to enable secure, decentralized discovery and communication between AI agents using the internet’s existing DNS infrastructure and open standards.
      • \n
    • Initially developed by Infoblox, DNS-AID provides a vendor-neutral framework for publishing, discovering, and verifying AI agents and Model Context Protocol (MCP) servers without relying on centralized registries or hardcoded integrations.
      • \n
    • The Linux Foundation and initial project members – including Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Infoblox, Internet Systems Consortium, and WWT – will support the long-term growth of open, interoperable infrastructure for the emerging agentic web.
      • \n
    \n

    SAN FRANCISCO, May 27, 2026 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced the launch of the DNS-AID project, an open source project enabling AI agents to discover and communicate with one another in a standard way. By leveraging the internet’s existing Domain Name System (DNS) infrastructure, DNS-AID provides a robust, decentralized alternative to the centralized registries and hardcoded URLs currently limiting AI interoperability.

    \n

    As the AI ecosystem expands, the ability for autonomous agents to locate and verify each other across disparate platforms has become a critical bottleneck. The DNS-AID project, initially developed by Infoblox, enables agents and Model Context Protocol (MCP) servers to use DNS as a global, vendor-neutral directory. This approach ensures that agent discovery remains scalable, secure, and compatible with the foundational protocols of the internet.

    \n

    “AI agents are quickly becoming the connective tissue of the modern internet, but without secure, open discovery infrastructure, that connectivity becomes a liability,” said Jim Zemlin, CEO at the Linux Foundation. “DNS-AID helps anchor agent discovery in the DNS infrastructure the internet already trusts. The Linux Foundation provides the neutral home where this work can grow with the open governance, community collaboration, and long-term stability the emerging agentic web requires.”

    \n

    The DNS-AID project provides a reference implementation including a Python SDK, a command-line interface (CLI), and an MCP server, allowing developers to integrate agent discovery into their existing workflows immediately. Because the protocol is implementation-agnostic, it functions across any DNS provider, ensuring that organizations maintain control over their agent infrastructure without relying on proprietary, centralized services.

    \n

    “Current approaches to agent connectivity are fragmented and often rely on fragile, hardcoded configurations,” said Igor Racic and Ingmar Van Glabbeek, project maintainers for DNS-AID. “With DNS-AID, we are moving toward a 'web-native' model for AI. By utilizing the existing DNS hierarchy, we enable developers to publish and discover agents with the same reliability and ubiquity that we’ve used to navigate the internet for decades. We look forward to building this community under the Linux Foundation to ensure the protocol evolves to meet the needs of the global AI developer community.”

    \n

    Under Linux Foundation governance, DNS-AID will remain vendor neutral, fostering transparent, community-driven growth, ensuring accessibility, and supporting sustainability.

    \n

    The project is now open for contributions and community participation. To review the documentation, explore the reference implementation, and join the conversation, visit: https://github.com/dns-aid.

    \n

    Supporting Quotes

    \n

    “The Internet already solved the discovery problem decades ago with DNS – it's fast, it scales globally, and every network on earth understands it. By extending this proven architecture to the agentic web, DNS-AID provides the foundational routing layer that autonomous systems need to operate safely and efficiently. Cloudflare has always championed an open, interoperable Internet, and we are excited to support this project as it builds a decentralized future where AI scale isn't bottlenecked by centralized chokepoints.”
    – Dane Knecht, Chief Technology Officer, Cloudflare

    \n

    “The Domain Name System has proven its resiliency and scalability across every major technological disruption and innovation. As AI ecosystems continue to evolve, domains, the DNS, and their associated security protocols will become a foundational trust layer for AI, ML, and LLM-driven systems, enabling agent identity, routing, security, and policy enforcement. Through the monitoring and enforcement of daily domain name behaviors across the internet, we have seen firsthand the emerging threat vectors targeting enterprises globally. Initiatives like DNS-AID are critical to ensuring that the domain and DNS ecosystem, and the internet’s trusted infrastructure, evolve securely alongside the rise of AI-powered communication.”

    \n

    – Ihab Shraim, Chief Technology, Product and AI Officer, CSC

    \n

    “As AI agents become a foundational part of how enterprises interact across digital ecosystems, open and neutral discovery mechanisms will be critical. DNS-AID represents a promising step toward standardizing how agents are discovered and trusted across hybrid and multicloud environments. At Equinix, we see this as complementary to enabling secure, high-performance interconnection across a globally distributed infrastructure.”
    – Kaladhar Voruganti, Vice President and Senior Technologist, Equinix

    \n

    \"The agentic internet is going to be built on the same DNS and public-CA infrastructure that carried the human web for 30 years, and that works because no single operator owns it. DNS-AID gives agent discovery a neutral DNS-layer protocol any resolver can implement. The Agent Name Service open standard then adds a layer of verification and identification any agent can use. Both standards compose with whatever sits above them at the application layer. DNS-AID and Agent Name Service at the Linux Foundation are part of a broader move toward open, interoperable building blocks for the evolving internet. The standards that succeed at internet scale are the open ones, well operated.\"

    \n

    – Scott Courtney, Vice President, Engineering, GoDaddy

    \n

    “The threat of shadow AI always lurks in the deployment of agentic AI agents. It seems to me that the business community and cybersecurity teams need a common interface/protocol that can be used at the time of agent deployment. With DNS-AID, end-users use a common convention (DNS) and an open standard to create scale for the proliferation of AI agents that will only grow exponentially.”

    \n

    – Chris Kissel, Research Vice President, IDC Security & Trust Team

    \n

    “For forty years, DNS has quietly operated as the internet’s largest distributed trust graph. Every name resolution is, in effect, a trust signal. The agentic Internet inherits that graph the moment we extend DNS to agents, which is exactly what DNS-AID does. The DNS-AID architecture enables further fine-grained trust bootstrapping by linking to AI-native artifacts like AgentCards as well as third-party verifiable attestations about the agent and the human or enterprise behind it.”

    \n

    – Ken Adler, Technical Fellow, AgenticIAM, Indeed

    \n

    “DNS is already running everywhere agents will run. It's the only discovery system on the internet that is universally deployed, universally interoperable, and proven at planetary scale. DNS-AID extends what DNS has always done to AI agents that will increasingly act on our behalf. By standardizing how agents are published, discovered, and verified in DNS, it gives every operator, registrar, and platform one shared way to participate.”

    \n

    – Wei Chen, Chief Legal Officer and Executive Vice President, Regulatory Strategy, Infoblox

    \n

    “This is exactly the kind of application that the DNS Service Binding (SVCB) and HTTPS records were designed for. By publishing metadata about available agents and their capabilities, the DNS-AID can provide a quick and efficient process for discovering resources on the Internet.”

    \n

    – Victoria Risk, BIND 9 Product Manager, Internet Systems Consortium

    \n

    \"Agent-to-agent communication is the next frontier of AI attack surface, and it's exactly the kind of challenge our ARMOR framework was built to address. DNS-AID gives enterprises an open, standards-based way to handle agent discovery and identity – a foundational control that maps directly to ARMOR's infrastructure security and secure AI operations domains. We've been telling clients there's no AI without ARMOR; open protocols like DNS-AID are what make that principle operational at internet scale.\"

    \n

    – Chris Konrad, Vice President, Global Cyber, WWT

    \n

     

    \n

    Media Contact

    \n

    pr@linuxfoundation.org

    \n

     

    \n
    \n \n \n
    \n
    \n
    \n \n \n \n \n
    \n
    \n
    \n

    \n About The Linux Foundation\n

    \n

    The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, OpenChain, OpenSSF, OpenStack, PyTorch, RISC-V, SPDX, Zephyr, and more. The Linux Foundation is focused on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

    \n

    For a list of trademarks of The Linux Foundation, please see its trademark usage page: linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

    \n
    \n \n
    \n \n \n \n \n \n \n \n \n
    \n \n\n \n
    \n
    \n\n
    \n
    \n\n
    \n
    \n
    \n\n
    \n\n \n \n
    \n\n\n
    \n \n
    \n
    \n \n

    Stay Connected with the Linux Foundation

    \n \n
    \n

    \n\n
    \n\n\n\n\n\n\n\n\n\n    \n
    \n
    \n
    \n \n
    \n
    \n \n\n \n \n\n\n\n\n\n\n\n\n\n \n \n\n\n\n \n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    \n \n \n\n\n \n \n\n","snapshot_chars":94832,"live_check":"changed"},{"url":"https://www.theregister.com/ai-ml/2026/05/28/ai-agents-get-their-own-phone-directory-built-atop-dns/5247539","committed_hash":"sha256:e35e765ae82079d75f6033b096ce159f8d14d97e2b341cb82efd13099a03f3e4","committed_hash_short":"sha256:e35e765a…9a03f3e4","mime_type":"text/html","committed_at":"2026-09-01T14:00:28.051606+00:00","content_snapshot":"\n\n\n \n \n \n \n \n AI agents get their own phone directory built atop DNS\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n \n\n \n\n\n\n\n\n \n \n \n \n \n \n \n \n \n \n\n \n \n \n \n \n\n\n\n\n \n\n \n\n \n \n \n \n\n \n\n\n\n \n \n \n\n \n Jump to main content\n\n
    \n
    \n
    \n
    \n \n \n \n
    \n
    \n\n
    \n \n \n \n
    \n\n
    \n\n\n\n\t\t\n\n\n\t\n\n\n\n\t\t\n\n\n\t\n\n\n
    \n
    \n\n
    \n\n
    \n\n
    \n \n \n \n
    \n\n \n
    \n\n \n\n\n\n\n\n\n\n\n\n\t\n\n\n
    \n
    \n
    \n\n\n\n\n\t\n\n\n
    \n\n
    \n\n\n \n
    \n\n \n\n \n \n\n\n
    \n
    \n
    \n\n REG AD\n
    \n \n
    \n\n
    \n
    \n
    \n\n
    \n\n
    \n\n\n\n
    \n\n \n\n\n\n

    AI + ML

    \n\n\n
    \n
    \n
    \n\n\n\n\n\n

    AI agents get their own phone directory built atop DNS

    \n

    DNS-AID, under the auspices of the Linux Foundation, promises easier agent discovery

    \n\n\n
    \n \n\n
    \n
    \n \n
    \n \n
    \n Thomas Claburn\n \n Thomas\n Claburn\n \n\n Senior reporter\n
    \n
    \n
    \n\n \n
    \n\n\n \n
    \n \n Published\n \n \n
    \n\n\n
    \n \n \n \n \n \n \n
    \n\n\n\n
    \n\n
    \n\n\n \n\n \n \n\n\n \n\n
    \n \n \n\n

    In the future, AI agents will be able to find one another using the Domain Name System (DNS), instead of crawling about and probing ports or checking configured resources.

    That future begins now with DNS for AI Discovery (DNS-AID), an open source project intended to facilitate agent-to-agent discovery using existing internet infrastructure. The system has been built atop DNS to avoid the creation of yet another registry that has the potential to become a competitive chokepoint.

    \"Current approaches to agent connectivity are fragmented and often rely on fragile, hardcoded configurations,” said Ingmar Van Glabbeek, project maintainer for DNS-AID, in a statement. \"With DNS-AID, we are moving toward a 'web-native' model for AI. By utilizing the existing DNS hierarchy, we enable developers to publish and discover agents with the same reliability and ubiquity that we’ve used to navigate the internet for decades.\"

    \n\n REG AD\n
    \n \n
    \n

    DNS already provides various capabilities beyond domain name resolution. For example, websites expose their DMARC, SPF, and DKIM records via DNS TXT entries. And more recently, Service Binding (SVCB) and HTTPS RR (HTTPS Resource Records) were adopted to make it easier for clients to discover services and associated parameters.

    \n\n REG AD\n
    \n \n
    \n

    DNS-AID utilizes SVCB (with TXT as a fallback) and optionally DNS Security Extensions (DNSSEC) and DNS-Based Authentication of Named Entities (DANE) TLSA records. These provide agents with a way to connect without a mediating entity, additional infrastructure, or a preferred protocol. DNS-AID supports MCP, A2A, HTTPS, and anything addressable via SVCB and ALPN. 

    \n \n
    \n

    MORE CONTEXT

    \n \n
    \n
    \n

    The system allows agents to be searched by name, by function, and by domain.

    The Linux Foundation promises vendor-neutral governance for the project, which was initially developed by Infoblox.

    \"The Internet already solved the discovery problem decades ago with DNS – it's fast, it scales globally, and every network on earth understands it,\" said Dane Knecht, CTO of Cloudflare, in a statement. \"By extending this proven architecture to the agentic web, DNS-AID provides the foundational routing layer that autonomous systems need to operate safely and efficiently.\"

    There are various ways to get started, the simplest of which is to install dns-aid and then issue the command dns-aid init. There is already a Python SDK, and presumably it won't be long before other languages have a reference implementation.

    The setup process involves publishing an SVCB record for your agent to your site's DNS zone and signing the zone with DNSSEC as a verification of provenance. Thereafter, attempts to resolve the agent record _{agent-name}._{protocol}._agents.{your-domain} will return the relevant details, which can then be verified via DNSSEC, optional JWS signatures, and DANE policy before agents connect to one another.

    Several DNS providers currently offer DNS-AID support, including AWS Route 53, Azure DNS, Cloudflare, Google Cloud DNS, Infoblox NIOS and UDDI, NS1, and any standards-compliant DNS service (RFC 2136 DDNS). Developers experimenting locally have the option to use a Docker BIND9 playground.

    Global consultancy McKinsey argues that agent-to-agent commerce could be meaningful someday, calling it a \"projected $3 trillion to $5 trillion economic opportunity.\" We note that McKinsey's 1980s prediction about the size of the mobile phone market in 2000 was off by about 100x. ®

    \n\n \n\n \n
    \n\n\n \n\n\n
    \n \n cloudflare\n ai agents\n ai + ml\n ai\n linux foundation\n domain name system\n dns-aid\n \n \n
    \n\n\n
    \n
    \n \n \n \n \n \n \n
    \n
    \n\n
    \n \n
    \n
    \n
    \n\t
    \n\n REG AD\n
    \n \n
    \n
    \n
    \n\t\n\n
    \n \n
    \n \n
    \n\t
    \n \n
    \n\n \n\n \n\n
    \n\n \n \n
    \n
    \n
    \n
    \n\t
    \n\t\n\n\n
    \n
    \n\t\n\n\n
    \n
    \n\n\n\n\n\n
    \n
    \n\t\n\n
    \n \n
    \n

    AI

    \n \n
    \n
    \n\n\n\n
    \n \n
    \n

    Infosec

    \n \n
    \n
    \n\n\n\n
    \n \n
    \n

    FOSS

    \n \n
    \n
    \n\n
    \n\n
    \n
    \n\n
    \n
    \n\n
    \n
    \n \n \n
    \n\n \n\n\n \n \n\n \n\n\n\n\n\n\n\n \n\n\n\n \n \n \n\n","snapshot_chars":165149,"live_check":"changed"},{"url":"https://www.ietf.org/archive/id/draft-mozleywilliams-dnsop-dnsaid-01.html","committed_hash":"sha256:aafe477b014c49433d76ab60b159959e3949058beda33c3dfb249f096789bb78","committed_hash_short":"sha256:aafe477b…6789bb78","mime_type":"text/html","committed_at":"2026-09-01T14:00:28.121043+00:00","content_snapshot":"\n\n\n\n\n\nDNS for AI Discovery\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    Internet-DraftDNS-AIDMarch 2026
    Mozley, et al.Expires 3 September 2026[Page]
    \n
    \n
    \n
    \n
    Workgroup:
    \n
    dnsop
    \n
    Internet-Draft:
    \n
    draft-mozleywilliams-dnsop-dnsaid-01
    \n
    Published:
    \n
    \n\n
    \n
    Intended Status:
    \n
    Standards Track
    \n
    Expires:
    \n
    \n
    Authors:
    \n
    \n
    \n
    J. Mozley
    \n
    Infoblox, Inc.
    \n
    \n
    \n
    N. Williams
    \n
    Infoblox, Inc.
    \n
    \n
    \n
    B. Sarikaya
    \n
    Unaffiliated
    \n
    \n
    \n
    R. Schott
    \n
    Deutsche Telekom
    \n
    \n
    \n
    \n
    \n

    DNS for AI Discovery

    \n
    \n

    Abstract

    \n

    This document specifies a method for utilizing the Domain Name System (DNS) to facilitate scalable and interoperable discovery between AI agents. The proposed mechanism, referred to as \"DNS AI agent Discovery (DNS-AID)\", defines a structured DNS namespace and record usage model to support metadata exchange and capability advertisement.

    \n

    This will allow organisations to publish information about their AI agents on the Internet or internal networks using a well-known label within the organisation's own DNS namespace. This document does not define how the published agent information is accessed or the exact structure of that information. Instead, it specifies a mechanism for indicating which access protocol should be used and what format the agent information will be provided in.

    \n

    This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values.

    \n
    \n
    \n

    \nAbout This Document\n

    \n

    This note is to be removed before publishing as an RFC.

    \n

    \n The latest revision of this draft can be found at https://example.com/LATEST.\n Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/.

    \n

    \n Discussion of this document takes place on the\n WG Working Group mailing list (mailto:WG@example.com),\n which is archived at https://example.com/WG.

    \n

    Source for this draft and an issue tracker can be found at\n https://github.com/USER/REPO.

    \n
    \n
    \n
    \n

    \nStatus of This Memo\n

    \n

    \n This Internet-Draft is submitted in full conformance with the\n provisions of BCP 78 and BCP 79.

    \n

    \n Internet-Drafts are working documents of the Internet Engineering Task\n Force (IETF). Note that other groups may also distribute working\n documents as Internet-Drafts. The list of current Internet-Drafts is\n at https://datatracker.ietf.org/drafts/current/.

    \n

    \n Internet-Drafts are draft documents valid for a maximum of six months\n and may be updated, replaced, or obsoleted by other documents at any\n time. It is inappropriate to use Internet-Drafts as reference\n material or to cite them other than as \"work in progress.\"

    \n

    \n This Internet-Draft will expire on 3 September 2026.

    \n
    \n
    \n
    \n
    \n \n

    \n Copyright (c) 2026 IETF Trust and the persons identified as the\n document authors. All rights reserved.

    \n

    \n This document is subject to BCP 78 and the IETF Trust's Legal\n Provisions Relating to IETF Documents\n (https://trustee.ietf.org/license-info) in effect on the date of\n publication of this document. Please review these documents\n carefully, as they describe your rights and restrictions with\n respect to this document. Code Components extracted from this\n document must include Revised BSD License text as described in\n Section 4.e of the Trust Legal Provisions and are provided without\n warranty as described in the Revised BSD License.

    \n
    \n
    \n
    \n
    \n ▲

    \nTable of Contents\n

    \n\n
    \n
    \n
    \n
    \n

    \n1. Introduction\n

    \n

    This document describes DNS for AI Agent Discovery (DNS-AID), a mechanism that enables agents to retrieve operational parameters prior to initiating a session. DNS-AID introduces a leaf zone convention (e.g., _agents.example.com) containing Service Binding (SVCB) records (e.g., chat._agents.example.com) that encode application-specific metadata. It is these records that enable agents to retrieve operational parameters prior to initiating a session, supporting both targeted lookups and capability-based discovery.

    \n

    The approach leverages existing DNS protocols and records, including DNS Service Discovery (DNS-SD), DNSSEC, and DANE, to provide integrity, authenticity, and automation without requiring human intervention and without requiring modification of the basic principles of DNS. Lastly DNS-AID leverages Domain Control Validation (DCV) described as a best current practice to prove an agent is authorized to act on behalf of a domain in [I-D.draft-ietf-dnsop-domain-verification-techniques].

    \n

    DNS-AID provides the bootstrap for discovering an organization's agents. An organization can publish it's own registry of agents and their capabilities at a well-known entry point in the DNS hierarchy. It is also possible to provide names for commonly used agents, so that no registry needs to be queried and the returned capabilities processed (e.g., on a model card or other schema) before the name of can be resolved. It is expected that other documents will develop the content of any registry, such as refining the model card concept to a more structure schema, and will specify the protocol used to interact with the registry. It is more performant and deterministic to receive the details of the IP, protocols and port from an SVCB record than it is to determine this from a model card. It also mitigates against the vulnerability of parsing this information from a model card.

    \n

    For example, a company may only have a few external agents available for use, and if the IETF standardizes 'types' of AI agents, then perhaps _chat._agents.example.com or _img2txt._agents.example.com etc are all different SVCB records. On the other hand a company may provide an index of all agents via a well know entry point in the DNS hierarchy e.g. _index._agents.example.com.

    \n

    For example, a company might have only a few external agents available for use, and if the 'types' of AI agent are standardized, then (for example) _chat._agents.example.com and _img2txt._agents.example.com would use different SVCB records. On the other hand, a company may provide an index of all agents via a well-known entry point in the DNS hierarchy, e.g., _index._agents.example.com.

    \n

    The DNS-AID model is designed for incremental and non-disruptive deployment within existing DNS infrastructure. It introduces no new DNS message formats, opcodes, response codes, or resource record types. Instead, it defines a structured namespace convention and usage profile for existing record types (primarily SVCB, TXT, and TLSA) all within designated leaf zones (e.g., _a2a._agents.example.com).

    \n

    Organizations may adopt DNS-AID by publishing agent metadata under delegated subdomains, leveraging DNSSEC for integrity and authenticity, and optionally implementing Domain Control Validation (DCV) to signal delegated authority. These zones may be exposed selectively via split-horizon DNS or different zones, enabling differentiated discovery views for internal and external agents. No changes are required to recursive or authoritative DNS server implementations beyond standard support for DNSSEC and SVCB.

    \n

    This model supports opt-in adoption, allowing agent operators to publish discovery metadata without coordination with external registries or protocol maintainers. It is compatible with existing DNS tooling, including zone provisioning systems, monitoring platforms, and resolver configurations. DNS-AID is therefore suitable for deployment across enterprise, cloud, and federated environments, and may coexist with other discovery mechanisms without conflict.

    \n
    \n
    \n
    \n
    \n

    \n2. Conventions and Definitions\n

    \n

    The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\",\n\"MAY\", and \"OPTIONAL\" in this document are to be interpreted as\ndescribed in BCP 14 [RFC2119] [RFC8174] when, and only when, they\nappear in all capitals, as shown here.

    \n
    \n
    \n
    \n
    \n

    \n3. DNS Mechanisms for Agent Discovery\n

    \n

    AI agents that need to be discovered are currently being developed to support tasks such as travel planning, etc. See Figure 1.

    \n
    \n
    \n
    \n
    \n\n \n \n \n \n \n \n \n \n \n Agent\n Capabilities\n DISCOVERY\n APPLICATION\n -\n SVCB\n (INDEX)\n -\n TRAVEL\n IP\n -\n COST\n PROTOCOL\n -\n ATTESTATIONS\n PORT\n TRAINING\n DATA\n CERTIFICATIONS\n -WELL\n KNOWN\n AGENTS\n ACCEPTABLE\n USE\n SVCB\n RRs\n -\n TO\n BE\n SPECIFIED...\n This\n draft\n Other\n drafts\n \n \n
    \n
    \n
    Figure 1:\nAI Agent Capabilities\n
    \n
    \n
    \n
    \n

    \n3.1. Use of Service Binding Records in Discovery\n

    \n

    Agents will use SVCB records as defined in [RFC9460] to discover other agent endpoints under structured leaf zones (e.g., _chat._agents.example.com). These records allow querying agents to retrieve operational parameters prior to initiating a session, including supported protocols, privacy features (e.g., Encrypted Client Hello via ECH), and failover configurations.

    \n

    Agents may advertise support for QUIC, HTTP/3, or agent-to-agent protocols via ALPN declarations. Operators may specify alternate endpoints or migrate services across domains without relying on CNAME indirection, improving performance and reducing DNS resolution complexity.

    \n

    When paired with attribute leaf zones and custom SVCB parameters, this mechanism enables fine-grained discovery of agent capabilities. For instance, an agent querying _a2a._agents.example.com may receive an SVCB record indicating supported modalities (e.g., chat, image-to-text), expected input formats, and cost-related metadata (e.g., token pricing). This structured discovery model supports deterministic, cacheable, and semantically rich interactions between agents.

    \n

    SVCB records can indicate the protocol used to communicate with a given agent as in Figure 2:

    \n
    \n
    \n
    \n
    \n\n \n _index._agents.example.com.\n 3600\n IN\n SVCB\n 1\n ai-index-svc.example.com.\n (\n alpn=\"a2a\"\n port=443\n ipv4hint=192.0.2.1\n ipv6hint=2001:db8::1\n )\n \n \n
    \n
    \n
    Figure 2:\nSVCB Record Example\n
    \n
    \n
    \n
    \n
    \n
    \n

    \n3.2. DNS-Based Service Discovery\n

    \n

    DNS-SD as defined in [RFC6763], extends the capabilities of the Domain Name System to support service-type-based discovery. Unlike previous DNS resolution, which requires prior knowledge of a specific hostname, DNS-SD enables clients to discover services based on their functional type (e.g., _http._tcp, _printer._udp) within a given domain.

    \n

    DNS-SD provides a mechanism for AI agents to discover other agents or services based on declared capabilities rather than explicit names. For example, an agent may issue a query for _data-cleaner._a2a._agents.example.com to locate services capable of performing data sanitization tasks. This type-based discovery model supports dynamic ecosystems where agent roles and capabilities may evolve over time.

    \n

    DNS-SD operates over both multicast DNS (mDNS) and unicast DNS, allowing for flexible deployment in local networks and globally scoped domains. In enterprise or cloud environments, unicast DNS-SD enables structured and policy-compliant discovery across organizational boundaries. When combined with SVCB records, DNS-SD allows agents to retrieve detailed service metadata, including transport preferences, protocol support, and operational parameters.

    \n

    This model supports federated agent architectures, where multiple agents may advertise similar capabilities under different domains. By leveraging DNS-SD, agents can perform capability-based queries and receive a list of candidate services, each accompanied by structured metadata for evaluation and selection.

    \n

    DNS-SD also supports extensibility through TXT records and custom service naming conventions, enabling organizations to encode additional attributes relevant to agent interaction (e.g., supported data formats, authentication requirements, or cost models). A TXT record with the same name as the SVCB record could be used to provide additional meta-data. These features make DNS-SD a suitable foundation for scalable, interoperable, and semantically rich agent discovery workflows.

    \n

    An index of agents by type of service can be provided via DNS-SD as a well known entry point to a more complete capability description via a common schema, e.g., _index._agents.example.com. This may be used in addition to or instead of querying for specific agent services such as _data-cleaner._a2a._agents.example.com. Querying specific services will shortcut communication compared to querying an index.

    \n
    \n
    \n
    \n
    \n

    \n3.3. Domain Control Validation\n

    \n

    DCV refers to the process by which an entity demonstrates authoritative control over a DNS domain. As described in [I-D.draft-ietf-dnsop-domain-verification-techniques], DNS-based DCV typically involves the placement of a DNS record, most commonly a TXT record, containing a challenge token or assertion at a designated location within the domain. This record is then queried by an Application Service Provider (ASP) to confirm control.

    \n

    Authorization should not solely exist solely within the discovery phase, however there may be use cases in which agents acting on behalf of domains, prior to application handshake, can prove they are acting on behalf of a domain (organization). This may be a preferable mechanism, especially for ephemeral agents, to prove they act on behalf of a domain, rather than manage many temporary security mechanisms across multiple information security pillars (firewalls, certs, etc.).

    \n

    In the context of DNS-AID, DCV provides a mechanism for agents to assert delegated authority on behalf of a domain. For example, an organization may publish a TXT record under a structured leaf zone (e.g., _agent-roles._a2a._agents.example.com) containing metadata such as:

    \n

    ai-role=data-cleaner; crm=dummyorg; access=readonly

    \n

    This record signals that a specific agent is authorized to perform scoped operations under the domain's authority. When protected by DNSSEC [RFC9364], such assertions become cryptographically verifiable, mitigating risks of spoofing or unauthorized delegation.

    \n

    DCV within DNS-AID supports both ephemeral and persistent validation models. Ephemeral validation may be used for short-lived agent credentials or session-based delegation, while persistent records enable long-term authorization signaling. TTL and expiration considerations, as discussed in the draft, are critical to ensuring that validation records do not persist beyond their intended scope.

    \n

    Furthermore, DNS-AID encourages the use of application-specific naming conventions and token formats to avoid service confusion and collision. Validation records should be scoped to the intended service and include unguessable tokens or structured metadata to prevent unauthorized reuse across federated agent ecosystems.

    \n
    \n
    \n
    \n
    \n
    \n
    \n

    \n4. Architecture\n

    \n

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

    \n
    \n
    \n

    \n4.1. Example Communication\n

    \n

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

    \n
    \n
    \n
    \n
    \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n DNS\n SVCB\n Query\n _a2a._agents.example\n com\n AI\n Agent\n Resolver\n Auth\n DNS\n (ORG1)\n (ORG1)\n (ORG2)\n _a2a._agents.org2.com.\n 3600\n IN\n SVCB\n 1\n ai-index-svc.org2.com.\n (\n alpn=\"a2a\"\n port=443\n ipv4hint=192.0.2.1\n ipv6hint=2001:db8::1\n )\n \n \n
    \n
    \n
    Figure 3:\nAgent ORG1 Querying Org2\n
    \n
    \n
    \n
    \n
    \n
    \n

    \n4.2. Example Record\n

    \n
    \n
    \n
    \n
    \n\n \n _a2a._agents.org2.com.\n 3600\n IN\n SVCB\n 1\n ai-index-svc.org2.com.\n (\n alpn=\"a2a\"\n port=443\n ipv4hint=192.0.2.1\n ipv6hint=2001:db8::1\n )\n \n \n
    \n
    \n
    Figure 4:\nExample SVCB Resource Record\n
    \n
    \n
      \n
    • \n

      _a2a._agents.example.com.: The service name, following the SVCB naming convention (_service._agents.example.com).

      \n
      • \n
    • \n

      3600: TTL (Time to Live) in seconds.

      \n
      • \n
    • \n

      IN SVCB: The record type.

      \n
      • \n
    • \n

      1: SVCB priority. 0 is for alias mode; 1+ is for service mode.

      \n
      • \n
    • \n

      ai-index-svc.org2.com.: The target name of the service.

      \n
      • \n
    • \n

      alpn=\"a2a\": Specifies the ALPN protocol identifier. This is where your custom protocol is declared.

      \n
      • \n
    • \n

      port=443: The port on which the service is available.

      \n
      • \n
    • \n

      ipv4hint and ipv6hint: Optional hints for clients to connect directly.

      \n
      • \n
    \n
    \n
    \n
    \n
    \n

    \n4.3. Example Use Cases\n

    \n
      \n
    1. \n

      A user instructs their internal agent to \"clean up DummyCorp contacts based on this email.\" The agent must discover DummyCorp's authorized agents, validate its own delegation to act on behalf of the enterprise, and initiate a secure session. DNS-AID enables this by publishing agent endpoints and roles under DNS zones controlled by each organization.

      \n
      2. \n
    2. \n

      A research consortium deploys agents across multiple institutions. Each institution publishes its agents under its own domain (e.g., _a2a._agents.universityA.example.edu), allowing collaborators to discover services based on capability (e.g., _data-annotator._a2a.universityB.example.edu) while respecting institutional boundaries and trust models.

      \n
      3. \n
    3. \n

      A SaaS provider hosts agents for multiple customers. Each customer's agents are published under tenant-specific zones (e.g., customer1._agents.saas.com), enabling scoped discovery and policy enforcement. DNS-AID supports this model through hierarchical zone delegation and metadata-rich SVCB records.

      \n
      4. \n
    4. \n

      Lightweight agents deployed on mobile or edge devices require low-latency, cacheable discovery mechanisms. The DNS distributed architecture and support for SVCB hints (e.g., IP addresses, preferred protocols) enable efficient resolution and connection bootstrapping in constrained environments.

      \n
      5. \n
    5. \n

      In regulated industries, agents must operate within jurisdictional boundaries and maintain audit trails of interactions. DNS supports geographic scoping via ccTLDs and split-horizon configurations, while query logging and DNSSEC provide observability and integrity guarantees.

      \n
      6. \n
    \n
    \n
    \n
    \n
    \n

    \n4.4. Zone and Other Requirements\n

    \n
    \n
    \n

    \n4.4.1. Delegation and Chain of Trust\n

    \n

    A public authoritative zone used for the purposes of agent discovery MUST use DNSSEC [RFC4033]. The zone MUST establish a complete chain of trust to a publicly recognized trust anchor. AI agents MUST use validating resolvers, or have the capability to validate records.

    \n

    All DNS-AID-specific discovery records (e.g. SVCB/HTTPS [RFC9460], TXT/URI [RFC7553] used for capability descriptors, and any DNS-AID-defined RRTypes) MUST be signed and published in the DNS-AID External Zone. Where DNS-AID endpoints rely on TLS, publication of DANE TLSA records MAY be used to bind endpoint certificates to DNSSEC-validated names [RFC6698][RFC7671]. Resolver behavior consuming DNS-AID data MUST treat DNSSEC-bogus responses as failures and MUST NOT act on unsigned or invalidly signed discovery data.

    \n
    \n
    \n
    \n
    \n

    \n4.4.2. Performance Optimization(s)\n

    \n

    Each agent service endpoint that is specifically published as a DNS record SHOULD be an SVCB record in ServiceMode (or HTTPS RR for HTTPS endpoints) to convey connection parameters and capability locators with a single lookup [RFC9460]. SVCB \"address hints\" (ipv4hint, ipv6hint) SHOULD be used to reduce A/AAAA follow-up queries; resolvers MAY still validate final addresses via canonical resolution. Where human-friendly names are required, SVCB AliasMode (priority 0) MAY be used to map from a stable alias name to a canonical name.

    \n

    Authoritative servers MUST support EDNS(0) [RFC6891] and TCP fallback [RFC7766]. Operators SHOULD target response sizes that avoid IP fragmentation on common paths (e.g., <= 1232 bytes on IPv6), preferring compression and layered indirection over oversized RRsets. TTLs MUST be chosen to reflect the volatility of capability data; index/indirection records may use longer TTLs than frequently changing endpoint or capability descriptors. Negative caching MUST conform to [RFC2308].

    \n

    A representative naming pattern is shown below; the exact label order is deployment-specific, but the leaf per service, per agent rule applies:

    \n
    \n
    \n; Hashed, per-agent, per-service leaf\na4k2f9._mcp._agents.example.org.  600 IN SVCB 1 svc-a4k2f9.example.org.\n    alpn=\"map,h2,h3\" port=443 ipv6hint=2001:db8::5 ipv4hint=192.0.2.5\n\n; Optional alias for a friendlier owner name\nbilling._mcp._agents.example.org. 300 IN SVCB 0 a4k2f9._mcp._agents.example.org.\n
    \n
    \n
    \n
    \n
    \n
    \n

    \n4.4.3. Customization(s)\n

    \n

    DNS-AID deployments MAY define additional SVCB parameters (SvcParamKeys) to convey agent-specific capability metadata, provided that interoperability safeguards in [RFC9460] are observed. During experimentation, unregistered keys MUST use the numeric keyNNNNN presentation form, and any client behavior that depends on them MUST be gated via the mandatory SvcParam to ensure downgrade safety.

    \n

    This specification defines the following provisional SvcParamKeys for DNS-AID (names are illustrative; production deployments MUST register through IANA per [RFC9460] or use keyNNNNN until standardized):

    \n

    The following are example use cases for additional params:

    \n
      \n
    • \n

      cap - a capability descriptor locator or inline identifier (e.g., a URN or compact JSON-Ref) that identifies the agent's advertised capability schema/version.

      \n
      • \n
    • \n

      cap-sha256 - a base64url-encoded SHA-256 digest of the canonical capability descriptor to support integrity checks and cache revalidation.

      \n
      • \n
    • \n

      policy - a URI or URN identifying a policy bundle applicable to this agent (e.g., jurisdiction, data handling class) for client-side selection.

      \n
      • \n
    • \n

      realm - an opaque token for multi-tenant scoping or authz realm selection during protocol bootstrapping.

      \n
      • \n
    \n

    Clients that require any of these parameters MUST verify their presence via the mandatory key; otherwise, the SVCB record MUST be ignored. Example:

    \n
    \n
    \nSingle-RRTYPE publication with custom params (experimental keys shown)\na4k2f9._mcp._agents.example.org. 600 IN SVCB 1 svc-a4k2f9.example.org.\n    alpn=\"h2\" port=443 ipv4hint=192.0.2.5\n    mandatory=alpn,port,key65001,key65002,key65010\n    key65001=\"cap=urn:cap:example:mcp:invoice.v1\"\n    key65002=\"cap-sha256=yvZ0n7q8bE2gYkz8m1j1s0yQG0mC2F6qj3b9pVb6Gk0\"\n    key65010=\"bap=a2a/1,mcp/1\"\n
    \n
    \n

    Where endpoints are HTTPS, the HTTPS RR variant SHOULD be used to co-locate transport parameters such as ECH with capability metadata; otherwise, generic SVCB MAY be used. Future standardization SHOULD define the exact syntax (e.g., ABNF) and registry policy for these keys, including error handling for malformed or conflicting parameters. Until registration is complete, deployments MUST treat unknown keyNNNNN parameters as opaque and MUST NOT infer semantics without out-of-band agreement.

    \n
    \n
    \n
    \n
    \n
    \n
    \n
    \n
    \n

    \n5. Implementation Guidance\n

    \n
    \n
    \n

    \n5.1. Discovery Usage Examples\n

    \n
    \n
    \n

    \n5.1.1. Discovery Status 1 (Known Service and Domain)\n

    \n

    Query foobar._mcp._agents.example.com Figure 5:

    \n

    In this scenario, the AI Agent Client knows both the service type (mcp) and the\nauthoritative domain (example.com) and performs a direct SVCB query.

    \n
    \n
    \n
    \n
    \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n AI\n Agent\n Client\n wants\n to\n discover:\n foobar._mcp._agents.example.com\n (mcp\n =\n service,\n foobar\n =\n agent/capability,\n example.com\n =\n trusted\n domain)\n Agent\n Client\n Resolver\n /\n Cache\n Root/TLD/Auth\n DNS\n 1.\n SVCB\n Query\n (Recursive)\n 2.\n Query\n Root\n 3.\n Referral\n to\n .com\n NS\n 4.\n Query\n .com\n TLD\n 5.\n Referral\n to\n auth\n NS\n 6.\n Query\n Auth\n NS\n for\n foobar._mcp._agents\n 7.\n SVCB\n RRSet\n Response\n (DNSSEC-signed)\n 8.\n SVCB\n Response\n (cached\n +\n validated)\n Response\n includes:\n -\n Service\n target\n -\n ALPN\n protocol(s)\n -\n Port\n number\n -\n IPv4/IPv6\n hints\n -\n DNSSEC\n signatures\n -\n Capabilities\n (cost,\n modalities,\n etc)\n 9.\n A2A,\n MCP,\n etc.\n (Agent-to-Agent\n communication\n begins)\n \n \n
    \n
    \n
    Figure 5:\nDiscovery Status 1: SVCB Query with Full Chain Traversal\n
    \n
    \n
    \n
    \n
    \n
    \n

    \n5.1.2. Discovery Status 2 (Known Service OR Domain, Trusted)\n

    \n

    Query of the known organisation's index if service is unknown Figure 6:

    \n

    In this scenario, the Agent Client knows the trusted domain (example.com) but the\nspecific agent service type is unknown. The client queries a well-known index entry\npoint to discover available agent capabilities. The index query is not DNS.

    \n
    \n
    \n
    \n
    \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n AI\n Agent\n Client\n knows:\n example.com\n is\n trusted\n wants\n to\n discover:\n available\n agents\n and\n services\n queries:\n _index._agents.example.com\n (well-known\n entry\n point)\n Agent\n Client\n Resolver\n /\n Cache\n Root/TLD/Auth\n DNS\n 1.\n SVCB\n Query\n _index._agents\n (Recursive)\n 2.\n Query\n Root\n 3.\n Referral\n to\n .com\n NS\n 4.\n Query\n .com\n TLD\n 5.\n Referral\n to\n auth\n NS\n 6.\n Query\n Auth\n NS\n for\n _index._agents\n 7.\n Index\n DNS\n Response\n (SVCB\n RRSet\n or\n CNAME/AliasMode)\n 8.\n Index\n Agent\n Response\n (cached\n +\n validated)\n Response\n includes:\n -\n List\n of\n agent\n types\n (mcp,\n a2a,\n etc.)\n -\n Service\n endpoints\n -\n Capability\n metadata\n -\n DNSSEC\n signatures\n 9.\n Parse\n index,\n select\n desired\n agent\n type\n (e.g.,\n mcp)\n 10.\n Query\n specific\n agent\n service\n foobar._mcp._aiag...\n 11.\n Return\n service\n details\n 12.\n A2A,\n MCP,\n etc.\n (Agent-to-Agent\n communication\n begins)\n \n \n
    \n
    \n
    Figure 6:\nDiscovery Status 2: Index-Based Discovery with Service Selection\n
    \n
    \n
    \n
    \n
    \n
    \n

    \n5.1.3. Discovery Status 3 (Multi-Domain Query for Known Service)\n

    \n

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

    \n
    \n
    \n
    \n
    \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n AI\n Agent\n Client\n knows:\n img2txt\n is\n a\n well-known\n agent\n type\n knows:\n org1.com\n and\n org2.com\n are\n trusted\n domains\n wants\n to\n discover:\n which\n orgs\n have\n img2txt\n agents\n available\n Agent\n Client\n Resolver\n /\n Cache\n Root/TLD/Auth\n DNS\n (ORG1\n and\n ORG2)\n 1.\n SVCB\n Query\n img2txt._a2a._agents\n .org1.com\n (Recursive)\n 2.\n Resolve\n .org1\n chain\n 3.\n Auth.\n DNS\n org1\n returns\n service\n info\n 4.\n Response\n (org1)\n (cached\n +\n validated)\n 5.\n SVCB\n Query\n img2txt._a2a._agents\n .org2.com\n 6.\n Resolve\n .org2\n chain\n 7.\n Auth.\n DNS\n org2\n returns\n service\n info\n 8.\n Response\n (org2)\n (cached\n +\n validated)\n 9.\n Client\n evaluates:\n -\n Service\n capabilities\n from\n both\n responses\n -\n Trust\n levels\n (DNSSEC)\n -\n Cost,\n latency,\n etc.\n 10.\n Select\n endpoint\n &\n A2A/protocol\n with\n chosen\n provider\n (Agent-to-Agent\n communication\n begins)\n \n \n
    \n
    \n
    Figure 7:\nDiscovery Status 3: Parallel Multi-Domain Service Discovery\n
    \n
    \n
    \n
    \n
    \n
    \n

    \n5.1.4. Discovery Status 4 (Untrusted Domain / Consolidated Registry)\n

    \n

    Query a consolidated (reputable) registry (not DNS) when neither domain nor comprehensive service list is known:

    \n
    \n
    \n
    \n
    \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n AI\n Agent\n Client\n knows:\n a\n trusted\n registry\n (e.g.,\n registry.ai-trust-community.org)\n wants\n to\n discover:\n all\n viable\n img2txt\n agents\n available\n (any\n org)\n scenario:\n agent\n choice\n driven\n by\n capability,\n not\n domain\n affinity\n Agent\n Client\n Resolver\n /\n Cache\n Registry\n /\n Auth\n DNS\n 1.\n SVCB\n Query\n _index._agents\n .registry.ai-trust...\n (Recursive)\n 2.\n Resolve\n registry\n domain\n chain\n 3.\n Return\n registry\n index/catalog\n SVCB\n 4.\n Registry\n Index\n (HTTP,\n JSON,\n etc)\n 5.\n Registry\n Response\n Response\n contains:\n -\n Ref\n list:\n img2txt\n agents\n from\n multiple\n trusted\n orgs\n -\n Domains\n +\n endpoints\n -\n Aggregate\n ratings,\n SLA\n info,\n cost\n -\n DNSSEC\n provenance\n -\n Capabilities\n (cost,\n modalities,\n etc)\n 6.\n Client\n evaluates\n registry\n results\n (may\n include\n one\n or\n more\n followup\n queries\n per\n Discovery\n Status\n 1\n for\n additional\n detail)\n 7.\n Query\n chosen\n agent's\n auth\n DNS\n for\n final\n details\n 8.\n A2A/protocol\n with\n registry-selected\n endpoint\n (Agent-to-Agent\n communication\n begins)\n \n \n
    \n
    \n
    Figure 8:\nDiscovery Status 4: Registry-Based Discovery Across Multiple Providers\n
    \n
    \n
    \n
    \n\n
    \n
    \n
    \n
    \n

    \n5.2. AI Providers\n

    \n
    \n
    \n

    \n5.2.1. Publishing Schema\n

    \n

    Publishers SHOULD expose per-service discovery records using SVCB (or HTTPS for HTTP origins) at stable, well-scoped owner names (e.g., agent-id._mcp._agents.example.org.). SVCB ServiceMode conveys connection parameters and capability locators in a single round trip; AliasMode MAY be used to map a friendly name to a hashed leaf for sharding without duplicating RRSets. Initial connection parameter keys (alpn, port, address hints) and the mandatory key MUST be honored by clients. [RFC9460]

    \n

    Minimal example:

    \n
    \n
    \n; ServiceMode SVCB for an MCP-capable agent\na4k2f9._mcp._agents.example.org.  600 IN SVCB 1 svc-a4k2f9.example.net.\n    alpn=\"h2,h3\" port=443 ipv6hint=2001:db8::5 ipv4hint=192.0.2.5\n    mandatory=alpn,port\n
    \n
    \n

    SVCB/HTTPS semantics and SvcParam processing MUST follow [RFC9460] to ensure interop and correct fallback.

    \n
    \n
    \n
    \n
    \n

    \n5.2.2. TTLs, Update Agility\n

    \n

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

    \n
    \n
    \n
    \n
    \n

    \n5.2.3. Example DNS-AID Zonefile\n

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

    \n5.2.4. How to use this zonefile\n

    \n
      \n
    • \n

      Adjust TTLs for agility vs. cache efficiency. Use longer TTLs on indirection (aliases), shorter TTLs on volatile leaves and DCV. This aligns with DNS caching behavior and negative caching rules [RFC2308].

      \n
      • \n
    • \n

      Follow SVCB/HTTPS semantics. Clients must honor SvcPriority, AliasMode (priority 0), and ServiceMode parameters, including mandatory, alpn, port, and address hints per [RFC9460].

      \n
      • \n
    • \n

      DCV token flow. Issue a time-bounded token at _agents-challenge.domain and require DNSSEC-validated retrieval (pattern analogous to ACME's DNS-01 in [RFC8555]). Remove on success.

      \n
      • \n
    • \n

      Bind transport to DNS with DANE (optional). If your relying parties validate DNSSEC, publish TLSA to bind the endpoint's cert/key, using the operational guidance in [RFC7671] (TLSA record format in [RFC6698]).

      \n
      • \n
    • \n

      Sign the zone. This file is pre-signing. Sign with DNSSEC (DNSKEY/DS/RRSIG, etc.) before deployment; validators must treat unsigned/bogus discovery data as a failure (per your earlier spec). See DNSSEC core specs [RFC4033], [RFC4034], [RFC4035] and operational guidance.

      \n
      • \n
    \n
    \n
    \n
    \n
    \n
    \n
    \n

    \n5.3. Why these records\n

    \n
      \n
    • \n

      SVCB/HTTPS concentrate connection metadata and allow aliasing at apex and service labels, reducing round trips and enabling policy-gated parameters via mandatory.

      \n
      • \n
    • \n

      Per-service, per-agent leaves avoid oversized RRsets and allow parallel administration/sharding while keeping alias names stable. This follows performance guidance in SVCB and your DNS-AID perf section.

      \n
      • \n
    • \n

      DCV via TXT mirrors a well-understood, automated control-proof pattern [RFC8555] that fits DNS-AID authorization workflows.

      \n
      • \n
    • \n

      DANE TLSA optionally removes reliance on external PKI anchors for endpoint auth where DNSSEC is deployed [RFC6698], with deployment rules in [RFC7671].

      \n
      • \n
    \n
    \n
    \n
    \n
    \n
    \n
    \n

    \n6. Future Work & Unaddressed Portions\n

    \n

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

    \n
    \n
    \n
    \n
    \n

    \n7. Security Considerations\n

    \n

    DNSSEC and other security considerations apply. More work is needed to expand on this.

    \n
    \n
    \n
    \n
    \n

    \n8. Operational Considerations\n

    \n

    Work is needed to expand on operational considerations.

    \n
    \n
    \n
    \n
    \n

    \n9. IANA Considerations\n

    \n

    IANA maintains a registry of \"Underscored and Globally Scoped DNS Node Names\" per [RFC8552]. IANA is is requested to register an underscored attribute leaf for AI agents. _agent is suggested.

    \n

    IANA maintains a registry of \"DNS SVCB Service Parameter Keys (SvcParamKeys)\" per [RFC9460]. IANA is requested to designate custom key-value pairs for SVCB parameters to facilitate agent-to-agent application discovery and cost optimization. The following parameters are requested:

    \n

    Name | Meaning\n-----------+---------------------------------------------------------\ncap | capability descriptor locator or inline identifier\n | (e.g., a URN or compact JSON-Ref)\ncap-sha256 | capability base64url-encoded SHA-256 digest of the\n | canonical capability descriptor\npolicy | URI or URN identifying a policy bundle applicable to an\n | agent\nrealm | opaque token for multi-tenant scoping or authz realm\n | selection during protocol bootstrapping

    \n
    \n
    \n
    \n
    \n

    \n10. References\n

    \n
    \n
    \n

    \n10.1. Normative References\n

    \n
    \n
    [RFC2119]
    \n
    \nBradner, S., \"Key words for use in RFCs to Indicate Requirement Levels\", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
    \n
    \n
    [RFC2308]
    \n
    \nAndrews, M., \"Negative Caching of DNS Queries (DNS NCACHE)\", RFC 2308, DOI 10.17487/RFC2308, , <https://www.rfc-editor.org/rfc/rfc2308>.
    \n
    \n
    [RFC4033]
    \n
    \nArends, R., Austein, R., Larson, M., Massey, D., and S. Rose, \"DNS Security Introduction and Requirements\", RFC 4033, DOI 10.17487/RFC4033, , <https://www.rfc-editor.org/rfc/rfc4033>.
    \n
    \n
    [RFC6891]
    \n
    \nDamas, J., Graff, M., and P. Vixie, \"Extension Mechanisms for DNS (EDNS(0))\", STD 75, RFC 6891, DOI 10.17487/RFC6891, , <https://www.rfc-editor.org/rfc/rfc6891>.
    \n
    \n
    [RFC7766]
    \n
    \nDickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, \"DNS Transport over TCP - Implementation Requirements\", RFC 7766, DOI 10.17487/RFC7766, , <https://www.rfc-editor.org/rfc/rfc7766>.
    \n
    \n
    [RFC8174]
    \n
    \nLeiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
    \n
    \n
    [RFC9460]
    \n
    \nSchwartz, 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, , <https://www.rfc-editor.org/rfc/rfc9460>.
    \n
    \n
    \n
    \n
    \n
    \n
    \n

    \n10.2. Informative References\n

    \n
    \n
    [I-D.draft-ietf-dnsop-domain-verification-techniques]
    \n
    \nSahib, S. K., Huque, S., Wouters, P., Nygren, E., and T. Wicinski, \"Domain Control Validation using DNS\", Work in Progress, Internet-Draft, draft-ietf-dnsop-domain-verification-techniques-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-11>.
    \n
    \n
    [RFC4034]
    \n
    \nArends, R., Austein, R., Larson, M., Massey, D., and S. Rose, \"Resource Records for the DNS Security Extensions\", RFC 4034, DOI 10.17487/RFC4034, , <https://www.rfc-editor.org/rfc/rfc4034>.
    \n
    \n
    [RFC4035]
    \n
    \nArends, R., Austein, R., Larson, M., Massey, D., and S. Rose, \"Protocol Modifications for the DNS Security Extensions\", RFC 4035, DOI 10.17487/RFC4035, , <https://www.rfc-editor.org/rfc/rfc4035>.
    \n
    \n
    [RFC6698]
    \n
    \nHoffman, P. and J. Schlyter, \"The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA\", RFC 6698, DOI 10.17487/RFC6698, , <https://www.rfc-editor.org/rfc/rfc6698>.
    \n
    \n
    [RFC6763]
    \n
    \nCheshire, S. and M. Krochmal, \"DNS-Based Service Discovery\", RFC 6763, DOI 10.17487/RFC6763, , <https://www.rfc-editor.org/rfc/rfc6763>.
    \n
    \n
    [RFC7553]
    \n
    \nFaltstrom, P. and O. Kolkman, \"The Uniform Resource Identifier (URI) DNS Resource Record\", RFC 7553, DOI 10.17487/RFC7553, , <https://www.rfc-editor.org/rfc/rfc7553>.
    \n
    \n
    [RFC7671]
    \n
    \nDukhovni, V. and W. Hardaker, \"The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance\", RFC 7671, DOI 10.17487/RFC7671, , <https://www.rfc-editor.org/rfc/rfc7671>.
    \n
    \n
    [RFC8552]
    \n
    \nCrocker, D., \"Scoped Interpretation of DNS Resource Records through \"Underscored\" Naming of Attribute Leaves\", BCP 222, RFC 8552, DOI 10.17487/RFC8552, , <https://www.rfc-editor.org/rfc/rfc8552>.
    \n
    \n
    [RFC8555]
    \n
    \nBarnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, \"Automatic Certificate Management Environment (ACME)\", RFC 8555, DOI 10.17487/RFC8555, , <https://www.rfc-editor.org/rfc/rfc8555>.
    \n
    \n
    [RFC9364]
    \n
    \nHoffman, P., \"DNS Security Extensions (DNSSEC)\", BCP 237, RFC 9364, DOI 10.17487/RFC9364, , <https://www.rfc-editor.org/rfc/rfc9364>.
    \n
    \n
    \n
    \n
    \n
    \n
    \n
    \n
    \n

    \nAcknowledgments\n

    \n

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

    \n
    \n
    \n
    \n
    \n

    \nAuthors' Addresses\n

    \n
    \n
    Jim Mozley
    \n
    Infoblox, Inc.
    \n
    \nEmail:\njmozley@infoblox.com\n
    \n
    \n
    \n
    Nic Williams
    \n
    Infoblox, Inc.
    \n
    \nEmail:\nnic@infoblox.com\n
    \n
    \n
    \n
    Behcet Sarikaya
    \n
    Unaffiliated
    \n
    \nEmail:\nsarikaya@ieee.org\n
    \n
    \n
    \n
    Roland Schott
    \n
    Deutsche Telekom
    \n
    \nEmail:\nroland.schott@telekom.de\n
    \n
    \n
    \n
    \n\n\n\n","snapshot_chars":156015,"live_check":"changed"}]}