代理標準與基礎設施
DNS-AID Builds an Agent Discovery Layer with SVCB and DNSSEC, Freeing MCP and A2A Endpoints from Centralized Directories
DNS-AID has launched a public website and an Apache 2.0-licensed reference implementation that let organizations publish agent endpoints, protocols, and capability documents as existing DNS records. The approach can use DNSSEC to authenticate the publisher’s domain, but it still cannot prove that an agent itself is secure, that its capability claims are accurate, or that it should be authorized.
DNS-AID aims to address a layer of the agent interoperability stack that has yet to be standardized: how one agent can find an MCP, A2A, or HTTPS endpoint provided by another organization without knowing about a central registry service. Its naming format places the agent and protocol in `_<agent>._<protocol>._agents.<domain>`, then uses SVCB records defined by RFC 9460 to publish the hostname, port, and protocol information. Additional metadata—including capability document URLs, hashes, policies, versions, and tenant scopes—can be placed in custom parameters. DNS providers that do not support custom SVCB parameters can fall back to TXT records.
The design’s main advantage is that it reuses the existing control plane. Enterprises can publish agents under their own domains, use split-horizon DNS to expose different lists to internal and external users, and use DNSSEC to prove that records have not been tampered with. TLSA/DANE can also link service certificates back to the DNS chain of trust. DNS queries already benefit from caching and globally distributed resolution, eliminating the need to entrust agent names, endpoints, or organizational identities to a single platform. The specification itself is protocol-agnostic, and SVCB’s `alpn` parameter can identify MCP, A2A, or future protocols.
The public Python toolkit includes a CLI, SDK, and MCP server, with support for Route 53, Cloudflare, Infoblox, and RFC 2136 Dynamic DNS. It can also maintain an `_index._agents` index, retrieve capability documents, invoke discovered agents, and emit OpenTelemetry spans. Short-lived credentials can be obtained dynamically through a callback before each invocation, avoiding the inclusion of long-lived bearer tokens in discovery data.
However, DNSSEC can only confirm that “this domain published this record.” It cannot verify an agent’s actual capabilities, model quality, runtime integrity, or authorization scope. Capability-based search may still require an additional directory, while TTL caching can delay revocation. More importantly, the current document is an individually submitted IETF Internet-Draft and explicitly does not constitute IETF endorsement; the reference implementation is also small in scope. Engineering teams should next watch whether the naming format, custom SVCB parameters, revocation semantics, and other agent-directory approaches converge before deciding whether to deploy DNS-AID in production.