Summary
The ans-verify CLI verifies ANS TL receipts and Merkle proofs correctly for ANS-registered agents. Today's agent-to-agent interoperability testing revealed two gaps worth tracking:
1. No general agent verification for non-ANS agents
The current ans-verify tool requires an agentId and queries the TL. It cannot verify an agent that is discoverable via DNS-AID SVCB and has a reachable signed agent card but is not registered in ANS.
In practice, legitimate agents from other ecosystems (Infoblox DDI agent, for example) are discoverable via DNS-AID SVCB at the owner FQDN, have signed agent cards with jku, and enforce proper OAuth2 auth — but return no ANS TL proof. A caller interoperating with these agents needs a verification path that reports DNS state, SVCB records, DNSSEC, and card reachability independently of ANS registration.
Proposed: extend ans-verify (or add an ans-verify agent <fqdn> subcommand) that:
- Queries
_ans TXT (ANS discovery record)
- Queries SVCB at the bare FQDN (DNS-AID)
- Fetches the agent card, trying the SVCB TargetName when the owner name has no A record
- If an ANS
agentId is found, runs the existing TL proof check
- Reports
ans_verified (TL proof valid) and reachable (card fetched) as distinct outputs
2. Terminology: verified vs ans_verified
The current tool exits 0 for "verified." For interoperability, the distinction matters:
ans_verified=true — the ANS TL Merkle proof is valid. Requires ANS registration.reachable=true — the agent card was fetched and the agent is contactable. Does not require ANS registration.
An agent can be reachable=true, ans_verified=false (DNS-AID discoverable, not in ANS) or ans_verified=true, reachable=false (TL proof valid but endpoint currently down). Both states are meaningful and different.
Suggesting the output schema use these two fields rather than a single verified boolean.
Reference
Encountered while testing against Infoblox ddi-agent.ai.infoblox.com (DNS-AID SVCB, OAuth2 auth, signed card with jku). The SVCB for that agent points to a different TargetName (ddi-agent-edge.ai.infoblox.com) with no A record at the owner FQDN — a pattern the current tool cannot follow.
Summary
The
ans-verifyCLI verifies ANS TL receipts and Merkle proofs correctly for ANS-registered agents. Today's agent-to-agent interoperability testing revealed two gaps worth tracking:1. No general agent verification for non-ANS agents
The current
ans-verifytool requires anagentIdand queries the TL. It cannot verify an agent that is discoverable via DNS-AID SVCB and has a reachable signed agent card but is not registered in ANS.In practice, legitimate agents from other ecosystems (Infoblox DDI agent, for example) are discoverable via DNS-AID SVCB at the owner FQDN, have signed agent cards with
jku, and enforce proper OAuth2 auth — but return no ANS TL proof. A caller interoperating with these agents needs a verification path that reports DNS state, SVCB records, DNSSEC, and card reachability independently of ANS registration.Proposed: extend
ans-verify(or add anans-verify agent <fqdn>subcommand) that:_ansTXT (ANS discovery record)agentIdis found, runs the existing TL proof checkans_verified(TL proof valid) andreachable(card fetched) as distinct outputs2. Terminology:
verifiedvsans_verifiedThe current tool exits 0 for "verified." For interoperability, the distinction matters:
ans_verified=true— the ANS TL Merkle proof is valid. Requires ANS registration.reachable=true— the agent card was fetched and the agent is contactable. Does not require ANS registration.An agent can be
reachable=true, ans_verified=false(DNS-AID discoverable, not in ANS) orans_verified=true, reachable=false(TL proof valid but endpoint currently down). Both states are meaningful and different.Suggesting the output schema use these two fields rather than a single
verifiedboolean.Reference
Encountered while testing against Infoblox
ddi-agent.ai.infoblox.com(DNS-AID SVCB, OAuth2 auth, signed card withjku). The SVCB for that agent points to a different TargetName (ddi-agent-edge.ai.infoblox.com) with no A record at the owner FQDN — a pattern the current tool cannot follow.