Dear Ross,
You're absolutely right, and thanks for the pointer to DNS-AID — I hadn't
seen that draft before. The SVCB-first approach is clearly the better
design for this use case. A few reasons why I'm convinced, beyond your
(correct) point about TXT overloading:
1. Single-query resolution
ADP v1.0 requires TXT (_agent.{domain}) + SRV (_agent._tcp.{domain}) =
minimum two DNS queries before you know where to connect. DNS-AID's SVCB
approach packs target, port, IP hints, ALPN, capability digest, and
well-known URI into one RRset. That's a real latency win for agent-to-agent
discovery where every round trip matters.
2. ALPN is a first-class citizen in SVCB
Agent protocols (MCP, A2A, whatever emerges) map naturally to ALPN IDs. ADP
currently has no standard way to signal which wire protocol an agent speaks
— you have to fetch the well-known JSON to find out. SVCB's alpn parameter
solves this inline, and DNS-AID even separates it further with the bap
(Bulk Agent Protocol) SvcParamKey so policy engines can match on agent
protocol without parsing transport protocols.
3. The TXT proliferation problem is real
TXT has been abused for decades: SPF (now largely replaced by SPF RR type
99), DKIM, DMARC, ACME challenges, domain verification tokens, MTA-STS, and
now agent discovery. Large TXT RRsets cause UDP truncation → TCP fallback →
increased latency. This isn't hypothetical — it's a documented operational
pain point. Adding agent discovery metadata to TXT just compounds the
problem.
4. DNS-AID already defines the SvcParamKeys we need
The draft registers bap, cap, cap-sha256, and well-known as SVCB service
parameters. These map almost 1:1 to the fields ADP currently stuffs into
TXT key=value pairs, just in a properly typed and extensible format.
The one defensible reason for TXT in ADP was ubiquity, but I think that
argument is weakening. SVCB/HTTPS record support has grown significantly
since RFC 9460 — it's required for ECH, and major DNS providers
(Cloudflare, AWS Route53, Google Cloud DNS) all support it now.
What I'm proposing for ADP v1.1:
Layer 1 (DNS) becomes:
Primary: SVCB query at agent-name.example.com
→ target, port, ipv4hint/ipv6hint, alpn, bap,
cap, cap-sha256, well-known
Fallback: TXT _agent.{domain} + SRV _agent._tcp.{domain}
(for environments where SVCB isn't available)
Security: TLSA for DANE-style TLS authentication (if DNSSEC)
This aligns ADP with DNS-AID on the critical path while keeping TXT as a
documented fallback — exactly what Section 4 of the draft suggests.
Aligning with an IETF draft-in-progress is better than creating a parallel
approach that diverges on record type selection.
Want me to draft the v1.1 revision of the spec? The key structural change
is swapping Layer 1 from TXT+SRV to SVCB-first, and the rest of the
protocol (well-known JSON schema, AGP wire protocol, security model) stays
largely intact.
Ross Gibson <[email protected]> 于 2026年6月11日周四 上午3:18写道：
> The use of the SVCB record, which better fits service discovery, as the
> primary mechanism makes more sense to me. An SVCB-first approach is what
> is proposed by DNS-AID (
> https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/
> ), which takes advantage of where the protocol is today. Why create yet
> another use case for TXT records, which have already been put in to use for
> a multitude of different purposes, when there are better-suited options
> available?
>
>
>
> Thanks,
> Ross
>
> On Wed, Jun 10, 2026 at 12:37 PM Bin Lian <[email protected]> wrote:
>
>> Hi all,
>> We've submitted draft-pro-adp-agent-discovery-00, which defines a
>> lightweight three-layer discovery protocol for AI Agents using DNS
>> TXT/SRV records (Section 4), Well-Known URIs (Section 5), and
>> WebSocket endpoints (Section 6).
>> The key idea: domain names as decentralized Agent identities, with
>> public key fingerprint bound in DNS for first-meeting trust.
>> We'd appreciate feedback on the DNS record usage and the security
>> model.
>> Link: https://datatracker.ietf.org/doc/draft-pro-adp-agent-discovery/
>> Repo: https://github.com/harrylian8766/adp-protocol
>> _______________________________________________
>> DNSOP mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
