NEnembal·Mar 11, 2026
The layered architecture argument is right. Discovery, identity, and authorization should be separate concerns. AgentDNS tries to be all three plus billing and proxying, and that's how you get a single point of failure that controls everything.
We've been building the "narrowly scoped discovery" piece this review recommends. Agent Identity & Discovery (AID) [1] is a DNS TXT record at `_agent.<domain>` — endpoint, protocol, auth hint, optional Ed25519 public key. No registry, no proxy, no billing. Add one DNS record and any AID client finds your agent.
Works with MCP, A2A, OpenAPI, gRPC, GraphQL, WebSocket, local agents (Docker, npx, pip). SDKs in TS, Go, Python, Rust, .NET, Java. The discovery lookup is a single DNS query.
The optional PKA (Public Key Attestation) uses RFC 9421 HTTP Message Signatures with Ed25519 for endpoint proof. It s
Read the rest
its underneath SPIFFE and OAuth rather than replacing them. We wrote up the cross-boundary auth problem and the remaining gaps [2].
One thing the review misses: the .agent TLD. The .agent Community [3] (3,000+ members, 700+ companies) is going through ICANN's Community Priority Evaluation in the 2026 round to get `.agent` under community governance instead of corporate control. AID works on any domain today, but a community-governed TLD for agents is worth knowing about if you care about who controls the naming layer. Spec is at v1.2 [4].
Your conclusion — "define minimum interoperable layers and connect them with verifiable trust" — that's what we're after. DNS is the minimum viable trust anchor that already runs everywhere.
If any of this is interesting, you can join the community at agentcommunity.org.
[1] https://aid.agentcommunity.org
[2] https://blog.agentcommunity.org/external_identity_anchor
[3] https://agentcommunity.org/about
[4] https://aid.agentcommunity.org/docs/specification
[5] https://github.com/andre-git/agent-internet-rfcs/issues/1