Discover and publish AI agents via DNS using SVCB records (RFC 9460)
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
DNS-based Agent Identification and Discovery
Reference implementation for IETF draft-mozleywilliams-dnsop-dnsaid-02.
DNS-AID enables AI agents to discover each other via DNS, using the internet's existing naming infrastructure instead of centralized registries or hardcoded URLs.
The DNS-AID specification is being developed within the IETF: https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/.
This repository provides a reference implementation.
This project does not define the specification. The IETF draft is authoritative.
This project focuses on implementation, tooling, and ecosystem activities.
Changes to protocol behavior should be discussed within the IETF.
New to DNS-AID? Start with the Getting Started Guide for install, first agent publication, and backend setup.
DNS-AID is a substrate. The library in this repository is sufficient on its own β it publishes and resolves agent records against any DNS provider, with no dependency on a particular directory, indexer, or telemetry backend.
When a search, indexing, or telemetry layer is useful, the SDK can point at any HTTP endpoint that implements the documented interfaces. Operators are encouraged to run their own β the indexer is a thin layer over the same DNS records this library publishes and discovers, and the SDK telemetry sink is configurable via DNS_AID_SDK_HTTP_PUSH_URL (off by default). Independent directory implementations exist across the ecosystem; DNS-AID is designed to remain interoperable with any of them rather than canonicalize a single one.
For backend-specific extras (route53, cloudflare, ns1, cloud_dns, infoblox, akamai-edgedns, ddns), see the Getting Started Guide.
When the caller does not yet know which domain hosts the agent it wants, the SDK can query any directory backend that implements the search endpoint. The directory layer is opt-in convenience; the DNS substrate remains the authoritative trust gate.
After the directory returns candidates, re-resolve each one through Path A and validate signatures / DNSSEC before invoking. This is the substrate-as-authority pattern: the directory provides ranking and discovery convenience, but never sits in the trust path between the caller and the agent.
The SDK exposes additional filter parameters (capabilities, min_security_score, verified_only, etc.) for directories that compute and return those signals; see API Reference for the full surface. The semantics of those values are defined by whichever directory the caller has chosen β DNS-AID does not centralize them.
OpenTelemetry (v0.23.0+): install dns-aid[otel] and set
otel_enabled=True (or DNS_AID_SDK_OTEL_ENABLED=true) to emit spans +
metrics per invoke and propagate W3C trace context to downstream agents.
See docs/integrations/opentelemetry.md.
For advanced usage (connection reuse, OpenTelemetry export, pluggable telemetry sink):
If an external aggregator publishes community-wide rankings over HTTP, the SDK can fetch them via client.fetch_rankings(...); the endpoint is configured by the caller, not by the library.
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/dns-aid)<a href="https://allmcps.com/mcp/dns-aid"><img src="https://allmcps.com/api/badge/dns-aid?style=directory" alt="Dns Aid on AllMCPs" /></a>