pith. sign in

arxiv: 2606.02314 · v1 · pith:DUZ7SD7Hnew · submitted 2026-06-01 · 💻 cs.NI

Discovering Agents for Discovery: The Case for DNS

Ramachandra Rao Seethiraju , Sameer Thakar , Karthik Shyamsunder , Eric Osterweil This is my paper

Pith reviewed 2026-06-28 12:12 UTC · model grok-4.3

classification 💻 cs.NI
keywords AI agent discoveryDNSservice discoveryagent metadatainternet infrastructuretrust metadata
0
0 comments X

The pith

DNS can encode the metadata needed to discover AI agents within a single UDP transaction.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper sets out to show that the Domain Name System already provides a workable foundation for AI agents to locate one another, exchange trust information, and connect across platforms. It identifies three evaluation criteria for any discovery solution—navigational completeness of the metadata, lookup complexity, and transaction performance—and tests the first of these against real service-endpoint data. Measurements from 119,757 endpoints demonstrate that the required records remain small enough to travel in one DNS UDP message. Because DNS is already globally deployed and returns results in milliseconds, the authors conclude it can support agent discovery at Internet scale without new infrastructure. If this holds, agents could authenticate and authorize interactions using existing DNS mechanisms rather than building separate registries.

Core claim

DNS is well-suited for AI agent discovery because the size and amount of data necessary are well within the range of a single DNS UDP transaction, whose latency can be on the order of milliseconds.

What carries the argument

Standard DNS records used to store and retrieve metadata elements such as trust for AI agent discovery.

If this is right

  • Agents could locate and authenticate one another across organizational boundaries using existing DNS infrastructure.
  • Discovery queries could complete with the same low latency already observed for ordinary DNS lookups.
  • No new global registries or protocols would be required to achieve navigational completeness for agent metadata.
  • Existing DNS security extensions could directly support integrity and authorization checks for agents.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Organizations could register agents the same way they register services today, inheriting DNS operational practices.
  • Dynamic updates to agent metadata could occur through standard DNS update mechanisms without custom tooling.
  • The approach would allow agent discovery to inherit the global reach and caching behavior already built into DNS resolvers.

Load-bearing premise

The basic semantics and metadata elements required for AI agent discovery can be adequately encoded and retrieved using standard DNS records and protocols without changes to the protocol or new infrastructure.

What would settle it

A measurement showing that the metadata needed for a representative AI agent exceeds the payload limit of one DNS UDP packet.

Figures

Figures reproduced from arXiv: 2606.02314 by Eric Osterweil, Karthik Shyamsunder, Ramachandra Rao Seethiraju, Sameer Thakar.

Figure 1
Figure 1. Figure 1: Left: endpoint length ECDF. Middle: MCP tool namespace footprint ECDF. Right: 90 [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
read the original abstract

As Artificial Intelligence (AI) agents enter their next stage of being deployed ubiquitously throughout the Internet, their discoverability will become a central challenge. The information AI agents need to discover one another, how they will locate it, how to facilitate authentication, integrity, and authorization, how to connect across different platforms, and how to scale across organizational boundaries form a set of unanswered challenges that deployment success will prompt. These are challenges for which one of the Internet's most venerable, solid, and ubiquitous infrastructures is ideally suited: The Domain Name System (DNS). Such a rich, already ubiquitous, and programmatically flexible foundation is an ideal option for discovery of AI agents. In this work, we propose an illustration and rationale for the basic semantics that discovery for AI agents will require. We argue that three key evaluation criteria will become paramount: navigational completeness (the extent to which the necessary metadata, with elements like trust, is included in a discovery solution), lookup complexity, and transaction performance (e.g., latency, speed, or recency). Using data about 119,757 real-world service endpoints and multiple agent tooling ecosystems, we empirically evaluate the first of these considerations to illustrate the appropriateness of using DNS for AI agent discovery. Our results show the size and amount of data necessary are well within the range of a single DNS UDP transaction, whose latency can be on the order of milliseconds. Our evaluations illustrate a promising path toward enabling AI agent discoverability at the Internet's scale, and thereby accelerating secure, stable, and resilient AI agent deployments.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 0 minor

Summary. The paper proposes DNS as an infrastructure for AI agent discovery, outlining required semantics including authentication, integrity, authorization, and cross-platform connectivity. It identifies three evaluation criteria (navigational completeness, lookup complexity, transaction performance) and empirically assesses navigational completeness using aggregate metadata sizes from 119,757 real-world service endpoints across agent tooling ecosystems, concluding that the data fits within a single DNS UDP transaction (millisecond latency).

Significance. If the central claim holds, the work identifies a practical path for scalable AI agent discoverability using existing, ubiquitous infrastructure without new protocols. The large-scale empirical dataset drawn from real service endpoints is a concrete strength that grounds the size-feasibility argument.

major comments (1)
  1. [Abstract and evaluation section] Abstract and evaluation section: navigational completeness is defined to encompass metadata elements such as trust, authentication, and authorization, yet the reported evaluation only measures aggregate data sizes from the 119,757 endpoints against UDP limits. No concrete encoding, RR-type mapping (e.g., TXT/SRV), or validation is shown for trust or authorization semantics using standard DNS records without extensions; size compatibility alone therefore does not establish the claimed navigational completeness.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback, which helps clarify the scope of our evaluation. The comment correctly identifies that our empirical analysis focuses on aggregate metadata sizes rather than explicit record encodings.

read point-by-point responses

  1. Referee: [Abstract and evaluation section] Abstract and evaluation section: navigational completeness is defined to encompass metadata elements such as trust, authentication, and authorization, yet the reported evaluation only measures aggregate data sizes from the 119,757 endpoints against UDP limits. No concrete encoding, RR-type mapping (e.g., TXT/SRV), or validation is shown for trust or authorization semantics using standard DNS records without extensions; size compatibility alone therefore does not establish the claimed navigational completeness.

    Authors: We agree that navigational completeness, as defined, requires not only sufficient capacity for metadata including trust elements but also feasible encoding within standard DNS. The manuscript's evaluation demonstrates that real-world aggregate sizes from 119,757 endpoints fit within a single UDP transaction, establishing a necessary precondition for including such metadata. However, it does not provide concrete RR-type mappings or example encodings for authentication/authorization semantics. This reflects the paper's focus on initial size-based feasibility using empirical data rather than a full protocol specification. We will revise the evaluation section to include illustrative mappings (e.g., using TXT records for metadata and discussing trust via existing DNSSEC or SRV extensions where applicable) to more directly connect the size results to navigational completeness. revision: yes

Circularity Check

0 steps flagged

No circularity; evaluation uses independent external service endpoint data

full rationale

The paper proposes DNS-based discovery for AI agents and evaluates navigational completeness via aggregate size measurements drawn from 119757 real-world service endpoints. This constitutes an external empirical check against UDP transaction limits rather than any fitted parameter, self-defined quantity, or derivation that reduces a claimed result to its own inputs by construction. No equations, uniqueness theorems, or ansatzes are invoked that loop back to the paper's own definitions or prior self-citations as load-bearing support. The central size result therefore stands as an independent observation on external data.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the domain assumption that standard DNS can encode and serve the required discovery metadata without modification.

axioms (1)
  • domain assumption Standard DNS records and protocols are sufficient to encode and retrieve AI agent discovery metadata including trust elements
    Invoked in the proposal of basic semantics and the evaluation of navigational completeness using existing DNS capabilities.

pith-pipeline@v0.9.1-grok · 5819 in / 1174 out tokens · 25315 ms · 2026-06-28T12:12:13.329345+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

31 extracted references · 5 canonical work pages

  1. [1]

    API Index

    APIs.guru. API Index. https://api.apis.guru/v2/list.json : Accessed: May 2026

    2026

  2. [2]

    OpenAPI Directory

    APIs.guru. OpenAPI Directory. https://github.com/APIs-guru/openapi-directory : Accessed: May 2026

    2026

  3. [3]

    IP Fragmentation Considered Fragile

    Ron Bonica, Fred Baker, Geoff Huston, Bob Hinden, Ole Trøan, and Fernando Gont. IP Fragmentation Considered Fragile. RFC 8900, September 2020

    2020

  4. [4]

    Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity

    Scott Courtney, Vineeth Sai Narajala, Ken Huang, Idan Habler, and Akram Sheriff. Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity. Internet-Draft draft-narajala-courtney-ansv2-01, Internet Engineering Task Force, April 2026. https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/01/ : Accessed: May 2026

    2026

  5. [5]

    Agentdns: A root domain naming system for llm agents,

    Enfang Cui, Yujun Cheng, Rui She, Dan Liu, Zhiyuan Liang, Minxin Guo, Tianzheng Li, Qian Wei, Wenjuan Xing, and Zhijie Zhong. AgentDNS: A Root Domain Naming System for LLM Agents, 2025. https://arxiv.org/abs/2505.22368 : Accessed: May 2026

    work page arXiv 2025

  6. [6]

    Joao Luis Silva Damas, Michael Graff, and Paul A. Vixie. Extension Mechanisms for DNS (EDNS(0)). RFC 6891, April 2013

    2013

  7. [7]

    DNS Transport over TCP - Implementation Requirements

    John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin, and Duane Wessels. DNS Transport over TCP - Implementation Requirements. RFC 7766, March 2016

    2016

  8. [8]

    The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance

    Viktor Dukhovni and Wes Hardaker. The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance. RFC 7671, October 2015

    2015

  9. [9]

    Kazunori Fujiwara and Paul A. Vixie. IP Fragmentation Avoidance in DNS over UDP. RFC 9715, January 2025

    2025

  10. [10]

    Post-Quantum Signatures in DNSSEC via Request-Based Fragmentation, 2022

    Jason Goertzen and Douglas Stebila. Post-Quantum Signatures in DNSSEC via Request-Based Fragmentation, 2022. https://arxiv.org/abs/2211.14196

    work page arXiv 2022

  11. [11]

    Google public experiment results, 2020

    Google Public DNS. Google public experiment results, 2020. https://github.com/dns- violations/dnsflagday/issues/139#issuecomment-673489183 : Accessed: May 2026

    2020

  12. [12]

    agent: Headless domains for agentic applications, 2025

    Headless Domains. .agent: Headless domains for agentic applications, 2025. https://headlessdomains.com/agent : Accessed: May 2026

    2025

  13. [13]

    Hoffman and Jakob Schlyter

    Paul E. Hoffman and Jakob Schlyter. The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. RFC 6698, August 2012. 5

    2012

  14. [14]

    Hoffman and Wouter Wijngaards

    Paul E. Hoffman and Wouter Wijngaards. Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC. RFC 6605, April 2012

    2012

  15. [15]

    Discussion of Discovery of Agents, Workloads, and Named entities (DAWN)

    IETF DAWN Mailing List. Discussion of Discovery of Agents, Workloads, and Named entities (DAWN). IETF Mail Archive. https://mailarchive.ietf.org/arch/browse/dawn/

  16. [16]

    DNS Delegation (deleg) Working Group

    IETF DELEG Working Group. DNS Delegation (deleg) Working Group. IETF Datatracker. https://datatracker.ietf.org/group/deleg/about/

  17. [17]

    DNS-Anchored Durable Identity for AI Agents (DNSid)

    Naveed Ihsanullah. DNS-Anchored Durable Identity for AI Agents (DNSid). Internet-Draft draft-ihsanullah-dnsid-00, Internet Engineering Task Force, April 2026. Work in Progress

    2026

  18. [18]

    Paul Mockapetris and Kevin J. Dunlap. Development of the Domain Name System. In Symposium proceedings on Communications architectures and protocols (SIGCOMM), pages 123–133, 1988

    1988

  19. [19]

    DNS for AI Discovery

    Jim Mozley, Nic Williams, Behcet Sarikaya, and Roland Schott. DNS for AI Discovery. Internet-Draft draft-mozleywilliams-dnsop-dnsaid-01, Internet Engineering Task Force, March

  20. [20]

    https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/01/

  21. [21]

    The AGNTCY Agent Directory Service: Architecture and Implementation, 2025

    Luca Muscariello, Vijoy Pandey, and Ramiz Polic. The AGNTCY Agent Directory Service: Architecture and Implementation, 2025. https://arxiv.org/abs/2509.18787 : Accessed: May 2026

    work page arXiv 2025

  22. [22]

    A Cybersecurity Terminarch: Use It Before We Lose It.IEEE Security & Privacy, 18(4):67–70, 2020

    Eric Osterweil. A Cybersecurity Terminarch: Use It Before We Lose It.IEEE Security & Privacy, 18(4):67–70, 2020

    2020

  23. [23]

    Deploying and Monitoring DNS Security (DNSSEC)

    Eric Osterweil, Dan Massey, and Lixia Zhang. Deploying and Monitoring DNS Security (DNSSEC). In2009 Annual Computer Security Applications Conference (ACSAC), pages 429–438. IEEE, 2009

    2009

  24. [24]

    Beyond dns: Unlocking the internet of ai agents via the nanda index and verified agentfacts,

    Ramesh Raskar, Pradyumna Chari, John Zinky, et al. Beyond DNS: Unlocking the Internet of AI Agents via the NANDA Index and Verified AgentFacts, 2025. https://arxiv.org/abs/2507.14263 : Accessed: May 2026

    work page arXiv 2025

  25. [25]

    DNS Security Introduction and Requirements

    Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. DNS Security Introduction and Requirements. RFC 4033, March 2005

    2005

  26. [26]

    Protocol Modifications for the DNS Security Extensions

    Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. Protocol Modifications for the DNS Security Extensions. RFC 4035, March 2005

    2005

  27. [27]

    Resource Records for the DNS Security Extensions

    Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. Resource Records for the DNS Security Extensions. RFC 4034, March 2005

    2005

  28. [28]

    Schwartz, Mike Bishop, and Erik Nygren

    Benjamin M. Schwartz, Mike Bishop, and Erik Nygren. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). RFC 9460, November 2023

    2023

  29. [29]

    Strengthening Security with DNSSEC Algorithm Update, 2023

    Verisign. Strengthening Security with DNSSEC Algorithm Update, 2023. https://blog.verisign.com/security/dnssec-algorithm-update/ : Accessed: May 2026

    2023

  30. [30]

    Algorithm Implementation Requirements and Usage Guidance for DNSSEC

    Paul Wouters and Ondˇrej Surý. Algorithm Implementation Requirements and Usage Guidance for DNSSEC. RFC 8624, June 2019

    2019

  31. [31]

    MCPZoo: A Large-Scale Dataset of Runnable Model Context Protocol Servers for AI Agent, 2025

    Mengying Wu, Pei Chen, Geng Hong, Baichao An, Jinsong Chen, Binwang Wan, Xudong Pan, Jiarun Dai, and Min Yang. MCPZoo: A Large-Scale Dataset of Runnable Model Context Protocol Servers for AI Agent, 2025. https://arxiv.org/abs/2512.15144 : Accessed: May 2026. 6

    work page arXiv 2025