DNS has been quietly evolving for forty years. In 1986, MX records taught the internet where to deliver email. In 2000, SRV records enabled service discovery for VoIP, instant messaging, and directory services. In 2023, SVCB records (RFC 9460) optimized how browsers find and connect to HTTPS services.
Now, in 2026, DNS is taking its next step: becoming the discovery layer for AI agents.
The DNS-AID specification (DNS-based Agent Identification and Discovery), currently being developed within the IETF, proposes using DNS as the standard mechanism for AI agents to publish themselves and discover each other. Instead of centralized registries, hardcoded URLs, or proprietary directories, agents advertise their capabilities, endpoints, and authentication requirements through DNS records that any resolver on the internet can query.
The reference implementation, developed by Infoblox and hosted under the Linux Foundation, already supports publishing, discovery, verification, and invocation across multiple DNS providers including Route 53, Cloudflare, NS1, Google Cloud DNS, and BIND via RFC 2136.
This is a significant development for anyone who manages DNS infrastructure. If DNS-AID gains adoption, the DNS records you monitor today gain an entirely new category of entries, and the security implications of DNS misconfiguration, hijacking, and neglect become substantially more severe.
How DNS Became a Service Discovery Protocol
To understand why DNS-AID makes sense, it helps to see the pattern that's been repeating for four decades.
DNS was originally built to translate domain names to IP addresses. Then people realized that the same distributed, cached, hierarchical system could answer broader questions: not just "where is this server?" but "where should I send email for this domain?" (MX records), "what services does this domain offer?" (SRV records), "who is authorized to send email for this domain?" (SPF via TXT records), and "which certificate authorities can issue certificates for this domain?" (CAA records).
Each of these extensions followed the same logic: DNS is already universally deployed, universally queried, and universally cached. Rather than building a new discovery mechanism from scratch, use the one that already exists everywhere.
DNS-AID follows this exact pattern for the AI agent era. The question it answers is: "What AI agents does this domain offer, and how do I connect to them?"
How DNS-AID Works
DNS-AID uses SVCB records (RFC 9460) to advertise AI agents. An organization that wants to publish an agent adds records to their DNS zone under a standardized naming convention:
_chat._mcp._agents.example.com. 3600 IN SVCB 1 chat.example.com. alpn="mcp" port=443
_chat._mcp._agents.example.com. 3600 IN TXT "capabilities=chat,assistant" "version=1.0.0"Breaking this down:
-
_chat— The agent name -
_mcp— The protocol (MCP, A2A, HTTPS, etc.) -
_agents— The DNS-AID namespace -
example.com— The domain that owns the agent - SVCB record — Points to the agent's endpoint with transport metadata
- TXT record — Describes the agent's capabilities and version
An index record at _index._agents.example.com lists all agents published on the domain, enabling a single DNS query to discover every agent an organization offers:
_index._agents.example.com. TXT "agents=chat:mcp,billing:a2a,support:https"The Discovery Flow
When an AI agent (or orchestrator like LangGraph or CrewAI) wants to find agents at a domain:
- Query the index record to see what agents exist
- Query individual SVCB records for endpoint details (host, port, protocol)
- Query TXT records for capabilities and version information
- Optionally fetch a metadata document at
/.well-known/agent.jsonfor richer details (auth requirements, action semantics, lifecycle status) - Validate the entire chain via DNSSEC to confirm the records are authentic
- Connect to the agent endpoint
The entire process uses standard DNS queries. No proprietary APIs, no centralized registries, no vendor lock-in. Any DNS resolver on the planet can serve these records.
Trust Through DNSSEC
DNS-AID's trust model is built on DNSSEC. When an agent discovers another agent via DNS, DNSSEC validation confirms that the records haven't been tampered with and actually were published by the domain owner. The specification also supports DANE/TLSA for TLS certificate verification and includes a security scoring system that evaluates DNSSEC status, TLSA presence, and endpoint health.
This is a fundamentally different trust model than centralized registries. Instead of trusting a registry operator to vet agents, you trust DNS and DNSSEC, the same infrastructure that already secures your email (DMARC), your certificates (CAA), and your web traffic (HTTPS).
Why This Matters
The AI agent ecosystem is exploding. Google's A2A (Agent-to-Agent) protocol, Anthropic's MCP (Model Context Protocol), Microsoft's AutoGen, LangChain's LangGraph, and dozens of other frameworks are creating a world where AI agents need to find and communicate with each other at scale.
Right now, agent discovery is mostly manual: developers hardcode agent URLs, configure MCP servers in JSON files, or register agents in proprietary directories. This doesn't scale. When every enterprise has dozens of agents, spanning internal tools, customer-facing services, partner integrations, and third-party SaaS, there needs to be a standard, decentralized discovery mechanism.
DNS-AID's argument is that this mechanism already exists. It's called DNS. And the argument is compelling for several reasons:
Decentralization. No single entity controls DNS. There's no registry that can go down, get compromised, or decide to gatekeep which agents are listed. Every organization controls their own DNS zone, publishes their own agent records, and maintains their own authority.
Universal infrastructure. Every device on the internet already has a DNS resolver. Every organization already has DNS infrastructure. There's no new protocol to deploy, no new service to run, no new dependency to manage.
Operational familiarity. IT teams already manage DNS records. Adding SVCB records for agents follows the same operational model as adding MX records for email or CAA records for certificates. The tools, processes, and monitoring already exist.
Built-in security. DNSSEC provides cryptographic verification out of the box. Unlike centralized registries where you trust the operator's vetting process, DNSSEC lets you verify agent records directly against the domain's signing keys.
The Risks: New Attack Surface, Familiar Vulnerabilities
Every benefit of using DNS for agent discovery comes with a corresponding risk, because DNS inherits all the vulnerabilities that have plagued it for decades, now applied to a much higher-stakes domain.
DNS Hijacking Becomes Agent Hijacking
When an attacker compromises a domain's DNS, they can redirect web traffic and intercept email. With DNS-AID, they can also redirect AI agent traffic. An attacker who modifies SVCB records can point your agent's endpoint to their infrastructure, intercepting every request from every agent and orchestrator that discovers your services via DNS.
This is particularly dangerous because AI agent interactions often carry sensitive data: financial transactions, customer information, internal business logic, API credentials. Agent hijacking isn't just a redirection; it's a data exfiltration channel and a potential supply chain compromise.
Dangling DNS Becomes Agent Takeover
Dangling DNS records, where CNAME or A records point to decommissioned cloud services, are already one of the most exploited attack surfaces on the internet. DNS-AID adds a new dimension: dangling agent records. When an organization decommissions an AI agent but forgets to remove the SVCB and TXT records, an attacker can claim the endpoint and serve a malicious agent under the organization's domain.
The consequences are worse than traditional subdomain takeover. A taken-over subdomain typically serves phishing pages. A taken-over agent endpoint actively processes requests from other AI systems, with the trust and permissions that the legitimate agent had. If other agents in a multi-agent workflow discover and invoke the compromised agent based on its DNS records, the attacker is inside the workflow.
DNSSEC Dependency
DNS-AID's trust model relies heavily on DNSSEC. Without DNSSEC, there's no cryptographic guarantee that agent records are authentic. An attacker who can poison a resolver's cache can inject fake agent records that pass all non-DNSSEC checks.
The problem: global DNSSEC adoption is still low. As of 2026, only a fraction of domains have DNSSEC properly deployed and maintained. The .de TLD outage in May 2026, which we covered in a previous article, demonstrated that even well-managed DNSSEC deployments can fail catastrophically during routine key rollovers. Organizations adopting DNS-AID without robust DNSSEC are building on a trust foundation that doesn't exist.
Public Capability Exposure
DNS records are public. Anyone can query them. When an organization publishes agent capabilities in TXT records (capabilities=payment-processing,fraud-detection,customer-data-access), they're telling the world exactly what their internal AI can do. This is valuable intelligence for attackers planning targeted attacks, competitors performing reconnaissance, and threat actors identifying high-value targets.
Operational Complexity
Most organizations already struggle with basic DNS hygiene: stale records, inconsistent TTLs, missing SPF records, forgotten subdomains. Adding SVCB records, capability TXT records, index records, and capability documents for every AI agent significantly increases the management burden. Without automated monitoring, the gap between what's published in DNS and what's actually running in production will grow quickly.
How DNS Assistant Fits Into This Future
If DNS becomes the discovery layer for AI agents, then DNS monitoring becomes AI agent security monitoring. Every capability that DNS Assistant provides today maps directly to a DNS-AID security requirement:
SVCB Record Monitoring
DNS Assistant already monitors all record types across your domains, including SVCB. As organizations publish agent records, DNS Assistant will detect changes to agent endpoints, protocol configurations, and service parameters. An unauthorized SVCB modification, whether from a compromised DNS provider account, a registrar-level attack, or an internal misconfiguration, triggers an immediate alert.
TXT Record Change Detection
Agent capabilities, versions, and index records are stored in TXT records. DNS Assistant monitors TXT records and alerts on any change. If an attacker modifies your agent's capability list, downgrades a version, or adds a rogue agent to your index record, your team knows immediately.
Dangling DNS Detection
DNS Assistant checks for dangling records across 22+ cloud provider fingerprints. As agent endpoints move to cloud infrastructure, the same dangling DNS risks that affect web subdomains will affect agent endpoints. An abandoned SVCB record pointing to a decommissioned cloud service is an agent takeover waiting to happen. DNS Assistant catches these before attackers do.
DNSSEC Validation
Since DNS-AID's trust model depends on DNSSEC, maintaining a valid DNSSEC chain becomes a security requirement, not just a best practice. DNS Assistant validates the full DNSSEC chain of trust for monitored domains, checking signature validity, expiration windows, and chain integrity. If your DNSSEC breaks, your agent trust breaks, and DNS Assistant alerts you before that happens.
WHOIS and Registration Monitoring
Domain control is the root of DNS-AID security. If an attacker gains control of your domain registration (through expiration, transfer, or registrar compromise), they control your agent DNS records. DNS Assistant monitors WHOIS data for registration changes, expiration risks, and unauthorized transfers.
Multi-Channel Alerting
DNS changes in an agent ecosystem need to reach security teams fast. DNS Assistant delivers alerts via email, Slack, Microsoft Teams, webhooks, and SMS, ensuring your team can respond to unauthorized agent record changes within minutes, not hours.
What Organizations Should Do Now
DNS-AID is still an IETF draft, not a ratified standard. Adoption is early. But the trajectory is clear: DNS is becoming more important, not less, as AI agents proliferate. Here's how to prepare:
1. Get Your DNS House in Order
Before you can secure agent records, you need to secure your existing DNS. Audit your records, eliminate dangling entries, enforce DNSSEC, and establish monitoring baselines. Run a Free Domain Risk Report to see where you stand on DNS health, email authentication, and TLS configuration.
2. Deploy and Maintain DNSSEC
If DNS-AID's trust model depends on DNSSEC, and it does, then DNSSEC deployment is a prerequisite for secure agent discovery. This means not just enabling DNSSEC but actively monitoring it: signature expiration, key rollovers, and chain-of-trust integrity. DNS Assistant provides automated DNSSEC validation for exactly this purpose.
3. Monitor All Record Types
DNS-AID uses SVCB, TXT, and potentially TLSA records for agent metadata. Most organizations only monitor A and MX records today. Expanding monitoring to cover all record types ensures you'll catch changes to agent records as soon as they exist. DNS Assistant monitors A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV, and more, providing comprehensive coverage.
4. Build DNS Cleanup Into Your Decommissioning Process
This is critical today for dangling DNS prevention, and it becomes even more critical in a DNS-AID world. Every agent decommission must include DNS record cleanup. Every cloud service teardown must remove the corresponding DNS entries. This should be a mandatory checklist item, not an afterthought.
5. Track the Specification
The DNS-AID specification is being developed openly at the IETF. Track the IETF draft and the reference implementation to understand what's coming and how it will affect your DNS infrastructure.
The Bigger Picture
DNS-AID represents a philosophical bet: that the decentralized, battle-tested infrastructure we've been building for forty years is the right foundation for AI agent discovery. It's the same bet that was made for email (MX records), for VoIP (SRV records), for certificate issuance (CAA records), and for email authentication (SPF/DKIM/DMARC in TXT records). Every time, DNS proved to be the right choice because it was already everywhere.
But every time DNS took on a new responsibility, the security stakes increased. MX records made DNS hijacking an email interception attack. SPF records made DNS misconfiguration an email deliverability issue. CAA records made DNS compromise a certificate issuance risk. DNS-AID would make DNS the trust foundation for AI-to-AI communication, the highest-stakes role DNS has ever been asked to play.
The organizations that will navigate this transition successfully are the ones that treat DNS as the critical security infrastructure it is: monitored continuously, changes detected in real time, DNSSEC validated, and every record type tracked across the entire domain portfolio.
That's what DNS Assistant is built to do.
Start with a free scan: Use the DNS lookup tool to check your current DNS records, or run a Free Domain Risk Report for a comprehensive view of your DNS health. For continuous monitoring with real-time alerting, sign up at dnsassistant.com.
Top comments (0)