Agent Naming and Discovery Guide: ANS, DNS-AID, DAWN

Before one agent can authenticate another it has to find it, and whoever controls that lookup controls which agent you end up trusting. Agents today are found through Agent Card files at well-known URLs, hand-maintained configuration and vendor marketplaces. A wave of proposals now aims to make agents discoverable at internet scale: the Agent Name Service (ANS), DNS-based agent discovery (DNS-AID), the IETF Discovery of Agents, Workloads, and Named entities (DAWN) working group, the NANDA Index and the AGTP protocol draft. This guide explains what each proposes, the attacks that target naming and discovery, and the checks a client should perform before trusting a lookup result. It is for architects and security engineers who publish agents or let their agents call external ones, and it complements our AI agent registry guide, which covers the internal inventory side.

Key takeaways

Nothing here is a standard yet. As of 11 November 2026, ANS, DNS-AID, AGTP and NANDA are individual drafts or research papers, and the DAWN working group's protocol milestone is December 2027. Build on the stable pieces underneath: DNS, DNSSEC, TLS, DANE and signed metadata.
Discovery is not trust. The DNS-AID draft says records must be treated as a verifiable transport for metadata, with trust decided out of band. A correct lookup tells you who published a record, not whether the agent is safe.
The domain is the anchor. Most proposals tie an agent name to a domain the publisher controls, so registrar security, DNSSEC and domain lifecycle become agent security controls.
Bind every hop. A sound client checks that the name, the DNS record, the TLS certificate and the fetched Agent Card all describe the same agent, using digests and pinned keys where available.
Metadata is untrusted input. Descriptions and skills fetched during discovery can carry prompt injection; parse them as data and never feed raw text into an agent's instructions.

Why agent naming is a security problem

Human-facing services rely on people to recognise a brand or a URL. Agents resolve names and select peers automatically, often from capability descriptions, and act within seconds. That changes the threat model in three ways:

Selection by description: an agent choosing "a travel booking agent" from an index can be steered by whichever entry describes itself most attractively, which is the agent version of search poisoning.
No human check: look-alike names that a person might spot are accepted by software unless the client verifies identity cryptographically.
Short decision loops: a poisoned lookup leads straight to delegation of a task, data or credentials, with no review step.

Today most organisations rely on the A2A Agent Card at https://{server_domain}/.well-known/agent-card.json, discovered because someone configured the domain. That works for known partners but provides no way to find an unknown agent, check that a card has not been replaced, or know whether an agent has been retired. The proposals below try to fill those gaps. See the A2A Protocol Security Guide for Agent Card signing.

The main proposals compared

Statuses below were checked on the IETF Datatracker and arXiv on 11 November 2026. Individual drafts have no formal IETF standing and change between revisions: avoid hard dependencies on draft details.

Proposal	Status (11 Nov 2026)	Naming model	Trust anchor	Notable security features
ANS v2 (draft-narajala-courtney-ansv2)	Individual draft -02, 26 Oct 2026, Independent Submission, Informational; replaces draft-narajala-ans-00	`ans://v{version}.{agentHost}`, a versioned name under a domain the registrant controls	Domain control, Web PKI, a Registration Authority and an append-only Transparency Log	Certificate fingerprints sealed in the log; lifecycle states; optional DANE; mTLS or DPoP proof of possession
DNS-AID (draft-mozleywilliams-dawn-dnsaid)	Individual draft -00, 2 Nov 2026, header Standards Track; replaces the earlier dnsop draft	SVCB records at the agent's DNS name, plus an organisation index at `_index._agents.{domain}`	DNS and DNSSEC, with DANE TLSA optional	Descriptor digest, `mandatory=` downgrade protection, strict TLS posture option
IETF DAWN working group	Chartered, active, Internet Area; protocol specification milestone 31 December 2027	To be defined; charter names DNS and mDNS as foundations	Out of scope beyond secure content exchange	Charter limits work to finding public details, not search or ranking
NANDA Index and AgentFacts	Research paper and work-in-progress design from Project NANDA (MIT and others)	Agent ID resolved to a small signed AgentAddr record pointing to AgentFacts	Index signatures and W3C Verifiable Credentials from approved issuers	Short TTLs, credential status revocation, a privacy path that avoids contacting the agent's domain
AGTP (draft-hood-independent-agtp)	Individual draft -10, 30 Oct 2026, Independent Submission, Informational	`agtp://` URI scheme; Agent-ID is a hash of a registrar-signed genesis record	Registrar-signed identity, TLS 1.3, signed requests	Discovery itself deferred to companion documents

How DNS-based discovery works

DNS-AID reuses the Service Binding record type (SVCB, RFC 9460) and defines no new record types. An agent publishes an SVCB record at its own name carrying connection details (alpn, port, address hints) and agent keys such as proto (for example mcp or a2a), well-known or path to the card, and desc-ref with desc-ref-digest, a SHA-256 digest of the descriptor. A client that knows the agent name must try that lookup first; a client that knows only the organisation queries _index._agents.{domain} and fetches the index over HTTPS. Capability search is out of scope. SVCB records should be DNSSEC-signed, TLSA records must be if used, and consumers should refuse records that fail validation. The draft offers three TLS postures: permissive (use TLSA if present, else Web PKI), preferred (the same but log when TLSA is missing) and strict (refuse without matching TLSA).

How ANS v2 adds a transparency layer

ANS v2 publishes SVCB records in the same DNS-AID style but adds a Registration Authority that checks domain control with an ACME-style DNS-01 or HTTP-01 challenge, and a Transparency Log that records signed lifecycle events such as AGENT_REGISTERED and AGENT_REVOKED. A required _ans-badge TXT record points to the log entry. Verifiers check the log entry, the Web PKI chain, optional TLSA, the inclusion proof, and that live DNS and certificates match the sealed values. An optional Identity Certificate from the authority's private CA carries the full ANS name for client authentication.

Attacks on naming and discovery

Attack	How it works	Main defence	Mapping
Look-alike names	An agent registered under a similar domain, name or skill set is selected instead of the real one	Allow-lists of verified identities; never select by description alone	T1583.001, AML.T0074
DNS spoofing or cache poisoning	Forged answers send the client to an attacker endpoint	DNSSEC validation; DANE in strict posture; encrypted DNS to a validating resolver	T1557
Registrar or DNS account takeover	The attacker edits the real zone, so records and new certificates look legitimate	Registrar MFA and lock; transparency log and certificate monitoring	T1584.002
Expired or transferred domains	A lapsed domain still trusted by clients is re-registered; ANS v2 notes a former holder's registrations stay active until revoked	Domain lifecycle monitoring; revoke registrations on transfer	T1583.001
Card or descriptor substitution	The record is genuine but the card fetched from it has been replaced	Digest in the signed record; signed Agent Cards	AML.T0074
Metadata prompt injection	Descriptions or skills carry instructions to the client's model	Parse to schema; keep metadata out of instruction context	AML.T0051.001
Version rollback	The client is steered to an older, deprecated agent version	Pin versions; refuse deprecated and revoked states	T1557
Enumeration and traffic analysis	Indexes reveal internal agents; lookups reveal who is using which agent	Publish only public agents; DoT or DoH; no EDNS Client Subnet	None specific

The ForcedLeak Salesforce Agentforce incident shows the domain lifecycle risk in practice: an expired domain still trusted by the platform was bought for about five dollars and used to exfiltrate data. See the Authoritative DNS and Registrar Account Security Guide.

Lookup trust: what a client should verify

Resolve with validation: use a DNSSEC-validating resolver over DoT or DoH and treat bogus or unverifiable answers as failures, not as a reason to fall back.
Check the anchor: confirm the agent's domain or registered identity is on your allow-list or verified through your registry, not merely well described.
Bind TLS to the record: where TLSA exists, require it to match; for high-risk agents use the strict posture and refuse connections without DANE.
Check transparency and status: where an ANS-style log exists, verify the inclusion proof and that the registration is ACTIVE, not DEPRECATED or REVOKED.
Verify the card: compare the fetched card or descriptor with the published digest and verify its signature before reading any field.
Authenticate the agent itself: discovery finds an endpoint; the agent must still prove possession of its key through mTLS, DPoP or the scheme its card declares. See the Agent-to-Agent Authentication Guide.
Cache with limits: honour TTLs, re-verify on expiry and re-check status before high-impact tasks.

Publishing your own agents safely

Publish deliberately: list only agents meant for external callers in any public index; keep internal agents in internal DNS views or your private registry.
Sign the zone: enable DNSSEC on zones that carry agent records and publish TLSA for agent endpoints. See the DNSSEC Deployment Guide.
Bind the card: publish a digest of the Agent Card or descriptor in the record and sign the card itself.
Keep secrets out of metadata: no internal hostnames, tokens or debug endpoints in cards, descriptors or TXT records.
Retire cleanly: remove records, revoke registrations and certificates when an agent is retired or a domain is transferred, and keep the domain registered until clients stop calling it.
Identity per agent: give each published agent its own key pair and certificate, rotated on a schedule, so one compromise does not expose every agent on the domain.

Decision guidance

Known partners only: configure endpoints and pinned keys directly and verify signed Agent Cards. Public discovery adds little and widens the attack surface.
Many partners or customers finding your agents: DNS-based publication on a DNSSEC-signed zone is a low-regret step, since it uses existing infrastructure and can follow DNS-AID as it changes.
Selecting unknown agents: do not let production agents pick peers from an open index without a human-approved allow-list. Treat any public index as a lead, not a trust decision.
Transparency logs and verifiable credentials: worth piloting where regulators or customers need evidence of which agent version was trusted when; expect format changes while drafts move.
Small versus large: small teams should secure their registrar account, sign their zone and pin partner keys. Large organisations should add an internal discovery gateway that performs all verification steps centrally for every agent.

How to implement

Inventory discovery paths: list how each agent finds peers today (configuration, well-known cards, marketplaces, registries) and which domains it trusts.
Harden the anchors: registrar MFA and transfer lock, DNSSEC on agent zones, certificate transparency monitoring for agent hostnames.
Centralise lookup: route agent discovery through one internal resolver or gateway that validates DNSSEC, checks allow-lists and verifies card digests and signatures.
Run in report mode: log verification failures without blocking for two to four weeks to find unsigned zones and partners without digests.
Enforce by tier: block failures for agents that handle sensitive data or act on behalf of users first; keep a per-partner exception list with expiry as the rollback.
Pilot new schemes: publish one public agent with DNS-AID style SVCB records and, if useful, an ANS-style registration, and track draft revisions before expanding.

Detection and measurement

Log every discovery lookup with the name queried, the records returned, the validation result, the certificate fingerprint and the card digest, and alert on changes. Useful signals are DNSSEC validation failures for partner zones, new certificates issued for agent hostnames, card digest mismatches, lookups for names close to trusted ones, and calls to agents not in the registry.

Share of agent zones you publish that are DNSSEC-signed with TLSA records.
Share of partner agents verified by pinned key or signed card before use.
Discovery verification failures per week, split by cause.
Number of agent calls to unregistered or unverified endpoints (target zero for production).
Time from agent retirement to record removal and revocation.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SC-20, SC-21, SC-22	Signed authoritative data, validating resolvers, resilient name services
NIST SP 800-53 Rev. 5	SC-8, SC-17, IA-9	TLS integrity, PKI certificates, service authentication
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory	Inventory of published and consumed agents
NIST CSF 2.0	ID.AM-02, ID.AM-04, PR.AA-03	Inventories of own and supplier services; authenticated services
MITRE ATT&CK v20	T1583.001, T1584.002, T1557, T1036	Look-alike domains, DNS compromise, interception, masquerading
MITRE ATLAS	AML.T0074 Masquerading; AML.T0051.001	Fake agents and injected metadata

Common failure patterns

Trusting a well-known URL because it is HTTPS: TLS proves the domain, not that the card is the one you approved.
Silent fallback: clients that drop to unvalidated DNS or Web PKI when DNSSEC or TLSA fails give attackers an easy downgrade.
Selecting peers from descriptions: letting a model choose an agent from index text invites look-alike and injection attacks.
Forgotten domains: agent domains left to expire while clients still trust them.
Publishing internal agents: an organisation index that lists internal tools hands attackers a map.
Building on draft details: hard-coding draft parameter names that later change, with no plan to update.

Practitioner checklist

List every way your agents discover peers and every domain they trust.
Protect agent domains with registrar MFA, transfer lock and expiry monitoring.
Sign agent zones with DNSSEC and publish TLSA records for agent endpoints.
Resolve agent names through a validating resolver over encrypted DNS and fail closed.
Publish a digest of each Agent Card in signed records and verify digests and signatures before use.
Allow production agents to call only peers in your registry with pinned identities.
Parse discovery metadata as data and keep it out of model instructions.
Remove records and revoke registrations when agents are retired or domains change hands.
Track ANS, DNS-AID, DAWN and AGTP revisions quarterly before adopting draft features.

Agent Naming and Discovery Guide: Securing How Agents Find and Trust Each Other