IETF Draft · Open Source
Publish agents to DNS, discover them like websites, and verify trust with DNSSEC. No centralized registry, just signal.
Install the full SDK in one shot:
pip docker source
pip install "dns-aid[all]"
What DNS-AID gives you, built on the DNS-AID protocol.
Core principle
DNS-AID is a naming convention on top of existing SVCB, TXT, and TLSA records. No new record types, no new servers, no new protocols — just standards from RFC 9460 and RFC 4033.
Security
Cryptographic proof that agent records are authentic and untampered.
Protocols
MCP, A2A, HTTPS, and any future protocol via alpn.
Discovery
Lookup by name, search by capability, or crawl a domain index.
Enterprise
Different agents to internal vs. external. Built-in tenant isolation.
SDK
CLI, Python SDK, MCP server. Eight backends ship in the box.
Performance
DNS caches automatically. No central API. Distributed lookups.
A deterministic, human-readable naming pattern for agent records.
_<agent-name>._<protocol>._agents.<your-domain> Examples: _chatbot._mcp._agents.example.com MCP chatbot _search._a2a._agents.example.com A2A search agent _data-cleaner._a2a._agents.acme.com capability-based _index._agents.example.com full agent index Multi-tenant: _analytics._mcp._agents.customer1.saas.com
Each agent is an SVCB record packed with machine-readable metadata.
alpn Communication protocol (mcp, a2a, h2)
port Service port number
cap Capability document URI
cap-sha256 Integrity hash for tamper detection
bap Bulk protocol version declarations
policy Governance and usage policy URL
realm Tenant or environment scope
ipv4hint Address hint to reduce extra lookups
Four steps from publish to connect.
1
Use the CLI or SDK to create an SVCB record under your domain's _agents zone with endpoint, protocol, and capabilities.
2
Your authoritative DNS signs the records, creating a cryptographic chain of trust from root to your agent.
3
Remote agents query DNS for your SVCB record by name, capability type, or full domain index.
4
The discoverer validates DNSSEC + DANE, then connects directly via the protocol in your SVCB record.
Get up and running with the dns-aid-core Python package.
Install
pip install "dns-aid[all]" # everything pip install "dns-aid[cli]" # CLI only pip install "dns-aid[route53]" # AWS backend pip install "dns-aid[cloudflare]" # Cloudflare backend pip install "dns-aid[nios]" # Infoblox NIOS backend pip install "dns-aid[mcp]" # MCP server
Publish
dns-aid publish \ --name my-chatbot \ --domain example.com \ --protocol mcp \ --endpoint agent.example.com \ --capability chat
Discover
dns-aid discover example.com dns-aid discover example.com --json dns-aid discover example.com --use-http-index
Verify & Diagnose
dns-aid verify _my-chatbot._mcp._agents.example.com dns-aid doctor --domain example.com
Invoke agents
# List tools on an MCP agent dns-aid list-tools https://mcp.example.com/mcp # Call a specific tool dns-aid call https://mcp.example.com/mcp analyze_security \ --arguments '{"domain":"example.com"}' # Send a message to an A2A agent (discover-first) dns-aid message "What is DNS-AID?" \ -d ai.infoblox.com -n security-analyzer
Manage
# Delete an agent from DNS dns-aid delete -n my-chatbot -d example.com -p mcp
Publish
from dns_aid import publish result = await publish( name="my-chatbot", domain="example.com", protocol="mcp", endpoint="agent.example.com", capabilities=["chat", "summarize"], description="General-purpose chat agent", ) print(f"Published: {result.agent.fqdn}") print(f"Records: {result.records_created}")
Discover
import asyncio from dns_aid import discover, verify async def main(): result = await discover("example.com") for agent in result.agents: print(f" {agent.name} — {agent.protocol} @ {agent.endpoint_url}") check = await verify("_my-agent._mcp._agents.example.com") print(f"DNSSEC valid: {check.dnssec_valid}") asyncio.run(main())
Discover-then-Invoke
from dns_aid import discover, invoke async def find_and_call(): result = await discover("partner.com", protocol="mcp") agent = result.agents[0] resp = await invoke(agent, method="tools/list") print(f"Latency: {resp.signal.invocation_latency_ms}ms") print(f"Data: {resp.data}")
Run the MCP Server
# stdio transport (Claude Desktop) dns-aid-mcp --transport stdio # HTTP transport dns-aid-mcp --transport http --port 8000
| Tool | Description |
|---|---|
| publish_agent_to_dns | Publish an agent's endpoint and capabilities |
| discover_agents_via_dns | Find agents on any domain via DNS |
| verify_agent_dns | Verify DNSSEC, DANE, and endpoint for an agent |
| call_agent_tool | Invoke a tool on a discovered MCP agent |
| list_agent_tools | List available tools on a remote MCP agent |
| send_a2a_message | Message a discovered A2A agent |
| diagnose_environment | Check DNS-AID configuration and connectivity |
| delete_agent_from_dns | Remove an agent's DNS records |
| list_published_agents | List agents in your own DNS zone |
| list_agent_index | Read a domain's agent index record |
| sync_agent_index | Rebuild a domain's agent index from live records |
Local Playground — zero credentials needed
git clone https://github.com/infobloxopen/dns-aid-core.git cd dns-aid-core pip install "dns-aid[cli]" docker compose -f tests/integration/bind/docker-compose.yml up -d # Configure .env for local BIND9 (see .env.example) dns-aid publish --name test-agent --domain test.dns-aid.local \ --protocol mcp --endpoint localhost --backend ddns \ --capability chat dns-aid discover test.dns-aid.local
All via standard DNS queries. No special client needed.
Targeted
You know the agent. Query its SVCB record directly for endpoint details.
dig SVCB _chatbot._mcp._agents.example.com
Capability
Find agents by what they do. Query a capability type under the agent zone.
dig SVCB _data-cleaner._a2a._agents.example.com
Index
Fetch a domain's full agent inventory from a well-known index entry point.
dig TXT _index._agents.example.com
Cross-organization agent discovery flow.
ORG 1 (Discovering) ORG 2 (Publishing) +----------------+ +-------------------+ | AI Agent |---- 1. DNS SVCB Query ----------->| Authoritative | | (org1) | _search._a2a._agents.org2.com | DNS Server | | |<--- 2. SVCB Response -------------| (DNSSEC-signed) | +-------+--------+ alpn="a2a" port=443 +-------------------+ | ipv4hint=198.51.100.10 | | 3. DNSSEC + DANE Validation | | 4. Direct A2A / MCP / HTTPS Connection v +----------------+ | AI Agent | Running at 198.51.100.10:443 | (org2) | +----------------+
R53
Amazon Route 53
AWS hosted zones
CF
Cloudflare
Global edge DNS
IB
Infoblox NIOS
Enterprise DDI
UD
Infoblox UDDI
Universal DDI cloud
GC
Google Cloud DNS
GCP managed
NS1
NS1
Managed DNS & traffic steering
RFC
RFC 2136 DDNS
Any standards-compliant DNS
B9
BIND9
Self-hosted & local dev
Discovery gets agents to the right endpoint. Policy helps deployments express who may call, what auth is required, and which runtime checks to apply without turning the homepage into a protocol memo.
Current
The DNS-AID learning materials already describe runtime policy evaluation alongside discovery metadata, auth requirements, and deployment-specific policy bundles such as policy.json.
Layers
Teams can start with caller-side and target-side checks, then add resolver or proxy enforcement only if their DNS or traffic infrastructure supports it.
Extensions
Some deployments may add local request or response inspection for PII, prompt injection, or data handling checks without routing traffic through a central policy service.
Documented policy examples on this site include caller-domain restrictions, required auth types, availability windows, rate limits, DNSSEC-sensitive decisions, and CEL expressions for tighter runtime checks.
You can start with the current runtime policy model and extend into resolver or proxy enforcement later, instead of committing to a heavyweight centralized security architecture on day one.
Real-world agent discovery scenarios.
Enterprise
An internal agent queries DNS to discover a partner's authorized agents, validates delegation, and initiates a secure session automatically.
Academic
Universities publish agents under their own domains. Collaborators discover services by capability while respecting institutional trust boundaries.
SaaS
SaaS providers host agents under tenant-specific zones. DNS zone delegation provides natural isolation and scoped discovery per customer.
Edge
Lightweight agents on constrained devices benefit from DNS's distributed, cacheable architecture with SVCB hints for low-latency bootstrapping.
Built on the internet's battle-tested security infrastructure.
Mandatory for public zones. Cryptographic chain of trust prevents spoofing and tampering.
Binds TLS certificates to DNS records. Endpoint verification without certificate authority trust issues.
Agents prove authorization via DCV TXT records. Scoped, verifiable, and ideal for ephemeral agents.
cap-sha256 hash ensures capability documents haven't been tampered with.
Internal agents stay invisible externally. Different views for different resolver contexts.
TXT records define per-agent roles and permissions scoped to specific services and operations.
No. DNS-AID introduces no new DNS record types, opcodes, or message formats. It's a naming convention on top of existing SVCB, TXT, and TLSA records. Any DNS server supporting DNSSEC and SVCB will work.
DNS-AID is protocol-agnostic. Agents declare protocols in the SVCB alpn field. The SDK supports MCP, A2A, and HTTPS. New protocols work by using new alpn identifiers.
DNS-AID is decentralized. Each organization publishes records under its own domain. No central registry, no vendor lock-in, no single point of failure.
AWS Route 53, Cloudflare, Infoblox NIOS, and RFC 2136. A Docker BIND9 playground is included for local dev. The backend architecture is extensible.
For public agent zones, yes. Without DNSSEC, discovering agents can't verify records are authentic. For private zones, network-level controls may suffice.
The SDK handles this automatically. Custom parameters are gracefully demoted to TXT records with dnsaid_ prefixes. All metadata is preserved losslessly.
Yes. The repo includes a Docker Compose setup with a local BIND9 server at tests/integration/bind/. Run docker compose -f tests/integration/bind/docker-compose.yml up -d and experiment entirely on your local machine using the DDNS backend.
Install the SDK, publish your first agent, and build on the open universal discovery layer for AI.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。