{
 "acronym": "DAN",
 "adoption": {
  "by": null,
  "level": "unmeasured",
  "probe_run": null
 },
 "aliases": [
  "AIDISCA/AIINDEX",
  "draft-seethiraju-dawn-dan"
 ],
 "analog": "DNS-based Authentication of Named Entities (DANE) for TLS certificates, applied to agent discovery instead of TLS",
 "collisions": [
  "DNS-AID (unrelated IETF dnsop draft, SVCB-based, Infoblox/Deutsche Telekom/Amazon/GoDaddy)",
  "AID (agentcommunity.org, TXT-based, unrelated authorship)",
  "ANS/Agent Name Service v2 (dual-certificate + SCITT transparency log, unrelated authorship)",
  "DAN also collides with the unrelated 'Do Anything Now' AI jailbreak prompt meme"
 ],
 "discovery": {
  "mechanism": "Two new DNS Resource Record types resolved directly (no well-known HTTP path). AIINDEX, published at a zone's _agents label, enumerates the AI agent publication names available in that zone. AIDISCA, published at each agent's own name, atomically carries protocol identifier, coarse-grained capabilities, service endpoint, and a DANE-style embedded certificate association — no separate TLSA lookup is needed.",
  "path": "_agents.<domain> (AIINDEX, TYPE65502); <agent-name>._agents.<domain> (AIDISCA, TYPE65501)"
 },
 "dispute": {
  "claims": [
   "DAN: two new RR types AIDISCA/AIINDEX, DANE-style cert embedded in-record, Verisign individual submission",
   "DNS-AID: SVCB records at agent + _index._agents labels, IETF dnsop draft, Infoblox/Deutsche Telekom/Amazon/GoDaddy",
   "AID: single TXT record at _agent.<domain>, agentcommunity.org, community-governed"
  ],
  "summary": "DAN is the third independent IETF-adjacent proposal to bind AI-agent discovery metadata to DNS, alongside DNS-AID (draft-mozleywilliams-dnsop-dnsaid, SVCB records, Infoblox/Deutsche Telekom/Amazon/GoDaddy) and AID (agentcommunity.org, TXT records). Unlike both, DAN does not reuse an existing RR type (SVCB or TXT): it defines two brand-new RR types (AIDISCA, AIINDEX) that must be published in RFC3597 generic form until IANA assigns mnemonics, and it embeds the certificate association directly inside AIDISCA rather than pointing to a separate DANE TLSA record. No evidence was found in this pass that Verisign's draft references, cites, or coordinates with the DNS-AID or AID authors, or vice versa; all three compete to answer the same 'discover' question with incompatible DNS shapes."
 },
 "evidence": [
  {
   "claim": "draft-seethiraju-dawn-dan-00 (5 June 2026, Verisign authors Seethiraju/Thakar/Shyamsunder/Osterweil, Intended status Standards Track, individual IETF submission with no working-group sponsorship, IESG state 'I-D Exists') defines the AIDISCA and AIINDEX DNS RR types, their RDATA formats, a client processing model, and IANA considerations for a new 'AI Agent Proto' registry and 'AI Agent DNS Extension Code' registry.",
   "date": "2026-06-05",
   "label": "VERIFIED",
   "url": "https://datatracker.ietf.org/doc/draft-seethiraju-dawn-dan/"
  },
  {
   "claim": "The verisign/dan GitHub repository is an open-source proof-of-concept reference implementation providing dan-gen.py (generates AIDISCA/AIINDEX records in RFC3597 presentation format from MCP endpoint or A2A agent-card metadata plus a certificate file) and dan-discover.py (resolves and human-readably prints published AIDISCA/AIINDEX records); as of the last commit (18 Jul 2026) it has 0 stars/0 forks and demonstrates only example domains (namestudioapi.com, colinmcnamara.com), not confirmed production deployments.",
   "date": "2026-07-18",
   "label": "VERIFIED",
   "url": "https://github.com/verisign/dan"
  },
  {
   "claim": "Verisign's own blog post (1 Sep 2026, co-authored by all four draft authors) announces the DAN Internet-Draft, frames it as extending DANE semantics to AI agent discovery, and states Verisign has published a royalty-free public IPR license to support standardization; it does not claim any third-party adoption.",
   "date": "2026-09-01",
   "label": "VERIFIED",
   "url": "https://blog.verisign.com/security/proposed-dns-record-types-ai-agent-discovery/"
  }
 ],
 "form": "dns-record",
 "governance": "IETF Independent Submission (individual draft; not sponsored by a chartered working group; 'dawn' in the draft filename is a keyword, not a working-group name)",
 "group": null,
 "history": [
  {
   "date": "2026-09-07",
   "note": "created as a new discover-step record; verified against draft-seethiraju-dawn-dan-00 (datatracker.ietf.org), the verisign/dan proof-of-concept repository, and Verisign's 2026-09-01 blog announcement"
  }
 ],
 "id": "dan",
 "implementation": "prototype",
 "last_verified": "2026-09-07",
 "name": "DNS-Based Agent Naming",
 "native_status": "Active Internet-Draft (individual, -00), Intended status: Standards Track; IESG state 'I-D Exists'; expires 7 December 2026",
 "origin": {
  "date": "2026-06-05",
  "org": "Ramachandra Rao Seethiraju, Sameer Thakar, Karthik Shyamsunder, Eric Osterweil (Verisign) — IETF Independent Submission"
 },
 "part_of": null,
 "parties": [
  "agent-agent",
  "agent-registry"
 ],
 "phase": "draft",
 "probe": {
  "method": "DNS query",
  "on_absent": "No AIINDEX/AIDISCA records resolve at this zone; the domain does not publish DAN-discoverable agents. Because the two RR types are not yet IANA-assigned to stable mnemonics, records are typically published and queried in RFC3597 generic form (TYPE65501/TYPE65502); most public DNS resolvers, zone editors, and tooling do not recognize AIDISCA/AIINDEX by name yet.",
  "parse": "AIINDEX RDATA contains an AI Agent Domain Name List (each entry a domain name under the zone); AIDISCA RDATA contains AI Agent Proto (1=MCP, 2=A2A), Capabilities (comma-separated string), Service Endpoint (URL), and Certificate Association Data (DANE-style usage/selector/matching-type + hash), plus an optional Extensions field (e.g. an A2A Agent Card URL)",
  "path": "QNAME=_agents.{origin} QTYPE=TYPE65502 (AIINDEX) to enumerate published agents; then QNAME=<name>._agents.{origin} QTYPE=TYPE65501 (AIDISCA) for each listed name"
 },
 "question": "Given a domain, which AI agents does it publish, and how can I locate and cryptographically bind to their service endpoint using DNS alone?",
 "scope": "general",
 "spec_url": "https://datatracker.ietf.org/doc/draft-seethiraju-dawn-dan/",
 "step": "discover",
 "summary_md": "DNS-Based Agent Naming (DAN) is an IETF Internet-Draft from Verisign that proposes two brand-new DNS Resource Record types — AIDISCA and AIINDEX — so that an AI agent's discovery metadata can be published and resolved directly through DNS, the way DANE (RFC 6698) binds TLS certificates to domain names [1]. AIINDEX, published at a zone's `_agents` label, lists the AI agent publication names available under that zone; AIDISCA, published at each such agent name, atomically carries the protocol identifier (MCP or A2A), a coarse capabilities string, the service endpoint URL, and a DANE-style embedded certificate association, all in one record [1].\n\nIt solves the same problem DNS-AID and AID solve — given a domain, find and cryptographically bind to the agents it publishes — but takes a different technical path: rather than reusing SVCB (DNS-AID) or TXT (AID), it mints two entirely new RRtypes and folds the certificate binding into the discovery record itself instead of a separate TLSA lookup, on the theory that this minimizes DNS round-trips [3]. It does not define semantic search, ranking, policy evaluation, or agent selection — the draft states these are explicitly out of scope — and it does not yet have IANA-assigned RRtype mnemonics, so records must currently be published in RFC3597 generic form (TYPE65501/TYPE65502) using ordinary DNS zone tooling [1].\n\nCurrent state as of 2026-09-07: a single version, draft-seethiraju-dawn-dan-00, dated 5 June 2026, submitted as an individual (non-working-group) Internet-Draft with Intended status Standards Track; IESG state is 'I-D Exists' with no telechat scheduled and no responsible Area Director assigned, meaning it has not been adopted by any IETF working group [1]. Verisign published the draft alongside a supporting arXiv paper and, on 1 September 2026, a blog post announcing a royalty-free public IPR license intended to support eventual standardization [3].\n\nWho implements it: only Verisign itself, via the open-source `verisign/dan` proof-of-concept repository, which provides `dan-gen` (generates AIDISCA/AIINDEX records from MCP endpoint or A2A agent-card metadata) and `dan-discover` (resolves and prints them). The repo's examples use illustrative domains rather than confirmed production deployments, and the repository shows no external stars, forks, or contributors as of its last commit (18 July 2026) [2].\n\nDisputed or unknown: DAN, DNS-AID, and AID are three separately authored, technically incompatible DNS-based discovery mechanisms competing to answer the same question, and no evidence was found that any of the three coordinates with or references the others. Whether DAN will be adopted by an IETF working group, merge with a competing draft, or remain an individual submission is unresolved. No third-party adopter, registrar, or DNS host has been found announcing support for DAN specifically (contrast with DNS-AID, which Infoblox and GoDaddy have publicly named).",
 "track": "ietf",
 "version": {
  "date": "2026-06-05",
  "label": "draft-seethiraju-dawn-dan-00, 5 June 2026 (single published version; no -01 as of 2026-09-07)"
 }
}