Why AID ships on TXT records

People keep asking why AID uses TXT records instead of SVCB. Fair question. I want to give a real answer.

SVCB is the better record type for service discovery. I genuinely think that. We want to use it. But when I looked at the actual DNS provider landscape in early 2026, roughly a third of providers couldn't publish one. Agent adoption is moving way faster than DNS infrastructure upgrades. So we built AID on TXT for v1, designed the spec so it can move to SVCB or SRV in v2, and made the _agent label stable across both.

That's the whole argument. The rest of this post is the evidence.

What AID actually needs from a DNS record

AID's job is small. One record at _agent.<domain> carries a version tag, an endpoint URL, a protocol token, and some optional metadata. Fits in a single TXT record under 255 bytes:

_agent.example.com. 300 IN TXT "v=aid1;p=mcp;u=https://api.example.com/mcp;a=pat"

AID doesn't need ALPN negotiation or ECH key distribution at the discovery layer. It's a pointer. It tells you where the agent lives and what protocol it speaks. After that, the application protocol (MCP, A2A, OpenAPI, whatever else) takes over.

SVCB would give us more structure. Validated parameters instead of semicolon-delimited strings. Native SvcParams extensibility so you can add new fields without touching the format. Cleaner integration with SVCB-aware client stacks. I know. The question was always timing, not merit.

The provider landscape in March 2026

I surveyed 31 DNS providers and registrars: major clouds, CDN DNS, mass-market registrars, regional hosts.

The full-support list is who you'd expect. Cloudflare, AWS Route 53, Google Cloud DNS, Akamai Edge DNS, NS1, DNSimple, Gandi, OVHcloud, Hetzner, others. SVCB works well on all of them.

The no-support list is where it gets awkward. Azure DNS. DigitalOcean. Namecheap. Oracle Cloud DNS. Linode DNS Manager. OpenSRS, the reseller platform behind a bunch of downstream registrars you may not recognize by name but whose customers are very real.

Then there's GoDaddy. Largest registrar in the world, 82+ million domains. They support HTTPS records but only in alias mode, priority locked to 0. ServiceMode parameters, the part that would carry structured discovery data, aren't available.

A developer on DigitalOcean, an enterprise on Azure, a startup that registered through an OpenSRS-powered reseller: none of them can publish an SVCB record from their DNS panel today. These are not edge cases.

Provider-by-provider breakdown

Here's the full picture. "ServiceMode" is what matters for agent discovery — it's the mode that carries structured parameters. AliasMode (priority 0) only does apex CNAME-like redirects and can't carry discovery metadata.

The providers in bold can't publish a ServiceMode SVCB record. Add up the domain counts: GoDaddy (82M), Namecheap (24M), OpenSRS (18M), Squarespace (14M), Hostinger (7M), Network Solutions (6M), Wix (3M). That's over 150 million domains on platforms that can't publish the record.

Now, I'll be the first to say that number is misleading if you take it at face value. Most of those domains are small business sites, parked pages, and personal blogs. They're not going to publish agent discovery records. The companies actually building MCP servers and running agent infrastructure are disproportionately on Cloudflare, Route 53, and Google Cloud DNS — all of which handle SVCB fine. If you weight the numbers by "domains likely to publish an _agent record," SVCB coverage is probably north of 80%. A developer on Namecheap can point nameservers to Cloudflare's free tier in 10 minutes.

So the raw provider gap isn't the whole story. What actually drove the decision was three things: adoption velocity for an early-stage protocol, debugging simplicity, and one enterprise blocker that doesn't have a free-tier workaround.

"Edit a TXT record" is something every developer has done. "Check whether your DNS provider supports SVCB ServiceMode, and if not, migrate nameservers" is a different conversation. For a v1 protocol still proving itself, that friction kills experimentation. And dig TXT _agent.example.com works everywhere — no special tooling, no wondering whether your resolver handles Type 64.

The enterprise blocker is Azure DNS. Microsoft's cloud DNS doesn't support SVCB. If you're running agent infrastructure on Azure — and plenty of enterprises are — you can't publish the record without migrating DNS away from the platform you're running everything else on. That's not a problem you solve with Cloudflare's free tier. That's an architecture constraint.

It goes deeper than Azure's managed DNS service. Windows DNS Server itself — the authoritative server software that enterprises run on-premises — doesn't support SVCB or HTTPS record types either. Simon Painter, a Microsoft MVP, documented this in March 2026: if you're running Windows DNS infrastructure and want to publish SVCB records, the workaround is to stand up a separate BIND instance. That's not a realistic ask for most enterprise DNS teams.

cPanel doesn't support it either

There's another layer. Even where the DNS server software handles SVCB fine (BIND and PowerDNS both do), domain owners manage their DNS through control panels. cPanel, the dominant shared hosting panel, doesn't offer SVCB or HTTPS in its zone editor. If you're on shared hosting without root access, you can't publish these records. Period.

RFC 3597 ("unknown record types") theoretically lets you enter arbitrary types. In practice, retail DNS APIs reject them. ClouDNS returns a hard failure. GoDaddy's API doesn't accept it. Namecheap's setHosts has a fixed type allowlist. The theoretical fallback doesn't survive contact with the real world.

Client-side resolution isn't uniform either

Even if you get the record published, client support for Type 64/65 queries is fragmented. Safari on Apple platforms has the most complete implementation. Chromium-based browsers rolled support out gradually since Chrome 96, with behavior varying across releases and platforms. Firefox has been conservative — you shouldn't assume HTTPS-RR-driven upgrades are active for every Firefox user. The RFC 9460 authors themselves acknowledge this, requiring that operators "continue to include address records at the zone apex for legacy clients." If a new standard requires SVCB alongside duplicate fallback records to ensure deliverability, it doubles the administrative burden and increases the likelihood of state sync errors.

Why "just migrate to Cloudflare" isn't an answer

For individual developers, sure. Point your nameservers and move on. But a protocol standard shouldn't assume its users will migrate DNS providers to adopt it. ECH and DDR can deploy incrementally — if your provider doesn't support it, you miss out on a privacy benefit, but nothing breaks. Agent discovery is different. If a domain can't publish the record, it's invisible. The directory has a hole.

I wanted AID to work the day you publish the record, on whatever DNS provider you already use. For v1 of a protocol still earning trust, that matters more than structural elegance.

We planned the SVCB upgrade from the start

I didn't punt on SVCB and hope for the best. The upgrade path has been in the spec since v1.0 (July 2025):

"AID v2 may adopt a more structured DNS record type such as SRV (RFC 2782) or SVCB (RFC 9460) for discovery, depending on registrar support at the time of ratification." -- AID Spec, Section 5

What makes it work is that we separated the label from the record type:

"The _agent DNS label is the stable discovery identifier for AID across all protocol versions." -- AID Spec, Section 5.1

_agent stays. The record type changes. Clients look at v=aid1 to know what format they're parsing. When SVCB coverage is broad enough, AID v2 adopts it, operators keep the same label, and the transition is a record type swap, not a redesign.

What would trigger it:

• GoDaddy and Namecheap ship full ServiceMode SVCB
• Azure DNS, DigitalOcean, and Oracle add support
• cPanel and Plesk put SVCB/HTTPS in their zone editors
• The OpenSRS/reseller stack unblocks the record type

I expect this will happen. SVCB is well-designed and the RFC has been out long enough that providers are slowly adding it. But "slowly adding" and "ready for a global standard to depend on" are different bars, and I don't think it helps anyone to pretend otherwise.

What we're giving up in v1

SVCB would give AID validated, typed parameters instead of semicolon parsing. The SvcParams model means you can add new discovery fields without touching the record format — that's a real advantage over TXT, where you're always one bad parser away from breakage. SVCB also plugs into existing service-binding client code, which would save SDK authors from writing custom parsers.

SRV gives you priority and weight natively, which is a cleaner way to handle multi-endpoint load distribution than one record per domain.

Both are better fits for what AID does than TXT. I'm not pretending otherwise. The tradeoff is deployability now versus structure later, and for a v1 protocol that needs to earn adoption before it can demand infrastructure, I think deployability wins.

Precedent

SPF defined its own dedicated record type (type 99). Adoption was so low that RFC 7208 deprecated it and moved everyone back to TXT. The better record type lost to the one people could actually publish.

DKIM uses TXT. DMARC uses TXT. BIMI uses TXT. MTA-STS uses TXT for the policy record. Not because TXT is ideal for any of these. Because it's the type that works everywhere, and "works everywhere" is table stakes for a standard you want the whole internet to use.

Where AID is different: we wrote the SVCB upgrade path into the spec before shipping v1, instead of hoping the ecosystem would retroactively catch up.

Where this leaves us

I like SVCB. I plan to adopt it. The spec is designed so we can do that without breaking anything when the time comes.

But a discovery standard that a third of domain owners can't deploy isn't a standard. It's a feature for the providers that happen to support it. TXT gets AID into every DNS panel on the internet right now. SVCB gives it better structure when the ecosystem catches up. The _agent label is ready for both.

AID is open source and the spec is frozen at v1.2. Read it, grab an SDK (TypeScript, Python, Go, Rust, .NET, Java), or just go publish an _agent TXT record. 30 seconds, any provider.