The public scanner at isitagentready.com checks a domain for the discovery surfaces an automated client might look for: llms.txt, an MCP endpoint, OAuth metadata, an A2A agent card. One of its checks is DNS-AID, a DNS record that tells an agent where a domain publishes its agents. On this site it reported fail, so I set out to close it. What follows is what the draft says, the one record I published, and the two I did not.
Who fails the check
First I ran the same scan against the domains you would expect to have solved this already. On August 31, 2026, the check reported fail for all of them:
infoblox.com— two of the draft’s five authors are listed under Infoblox, Inc. on its cover page.cloudflare.com— the scanner is Cloudflare’s. Its own disclaimer reads “Cloudflare assumes no liability for any actions taken or outcomes based on this automated content.”isitagentready.com— that is the scanner’s own site.dns-aid.organddnsaid.orga2aprotocol.aiagenticresourcediscovery.org
One domain in the set passed: turva.dev. I looked at what it publishes, because a single passing example is the only documentation a scanner’s predicate has.
The only domain passing was passing with the wrong record type
turva.dev passed with three HTTPS records (DNS type 65) under underscore-prefixed names: _index._agents, _a2a._agents and _mcp._agents. That is not the record the draft describes, and the substitution is not harmless.
An HTTPS record is a specialization of SVCB whose owner name is the origin being described. RFC 9460 §9.4 is explicit that a client connecting through one sets the TLS SNI and the HTTP :authority to the origin, not to the record’s TargetName. So an HTTPS record at _index._agents.example.com declares an origin whose hostname contains underscores. The draft rules that out and says why — §3.2: “The TargetName MUST be used and MUST not contain underscores as used in DNS-SD labels, as public x.509 certificates will be used in communications with the index.”
In fairness, the check accepts both types: its remediation text says “ServiceMode SVCB/HTTPS records,” and the SVCB record below passed it without objection. But the one domain that had earned a pass had earned it with the shape the draft does not define. Everyone else had published nothing at all.
Reading the draft instead of the scanner
The document is draft-mozleywilliams-dnsop-dnsaid-02, “DNS for AI Discovery,” dated May 27, 2026 and expiring November 28, 2026. It is an individual submission: the dnsop working group has not adopted it. I read the raw text from ietf.org, not a summary. Three things came out of it.
One name in the draft is written out in full. §3.2: “An SVCB record type query for _index._agents.example.com returns a pointer to an organization-specific registry of all agents.” Every other name I had seen suggested — _mcp._agents, <agent>._agents — appears zero times in the draft. They come from the reference implementation, and from the scanner composing a name out of my own TXT record. Inferred names are not specified names, and I was not going to sign one with DNSSEC.
The SvcParams I wanted do not have numbers yet. §7.1 asks IANA to register six keys — cap, cap-sha256, policy, realm, well-known and bap — and says of all of them that “the numeric SvcParamKey values are deferred to IANA assignment.” The three I would have used are cap, well-known and bap. None can be written without inventing a number.
The ALPN token mcp is a placeholder, and the draft says so. §7.3 asks IANA to register mcp and a2a, then states of its own table that “the entries above are placeholders.” mcp is not in the IANA ALPN registry today, and it does not work — see below.
The one record I published
_index._agents.visibleorigin.com. 300 IN SVCB 1 visibleorigin.com. alpn="h3,h2,http/1.1" port=443SVCB is DNS type 64. ServiceMode, priority 1 (RFC 9460 §2.4.1). Explicit TargetName, no underscores, and the certificate served for that name is CN=visibleorigin.com, valid. Check it:
dig +short SVCB _index._agents.visibleorigin.com @1.1.1.1
# 1 visibleorigin.com. alpn="h3,h2,http/1.1" port=443
dig +dnssec SVCB _index._agents.visibleorigin.com @1.1.1.1 | grep -m1 '^;; flags'
# ;; flags: qr rd ra ad; <- 'ad' means the resolver validated the signatureThe alpn list could most easily have been decoration. h2 and http/1.1 I measured with a TLS handshake against the edge. h3 is declared twice on this domain — by the edge, in the alt-svc: h3=":443" header, and by me, in the apex HTTPS record, alpn="h3,h2", signed in this same zone:
dig +short HTTPS visibleorigin.com @1.1.1.1
# 1 . alpn="h3,h2" ipv4hint=... ech=... ipv6hint=...Caveat: the curl on the box I work from has no HTTP/3, so I did not complete a QUIC handshake myself. For h3 I am taking those two declarations at their word — one of them mine — instead of a measurement, and I would rather say so than let you assume I tested it.
The two records I rejected
This half of the work shows up in no checkbox.
A hostname that does not exist
The obvious next record described an agent at audit.visibleorigin.com. That name does not resolve. The trap is that it looks alive: the wildcard certificate covers it, so TLS completes cleanly and the failure surfaces one layer up, in HTTP. Force a connection to the edge for that hostname, then for a name you made up:
IP=$(dig +short A visibleorigin.com @1.1.1.1 | head -1)
curl -s -o /dev/null -w '%{http_code}\n' \
--resolve audit.visibleorigin.com:443:$IP https://audit.visibleorigin.com/
# 530 (body: "error code: 1016")
curl -s -o /dev/null -w '%{http_code}\n' \
--resolve zzz-does-not-exist.visibleorigin.com:443:$IP https://zzz-does-not-exist.visibleorigin.com/
# 530 (body: "error code: 1016")Byte for byte, the real agent name and the invented one produce the same response. The control request matters here, because this zone answers NOERROR with no data for names that do not exist rather than NXDOMAIN — synthesized “black lie” NSEC — so a missing name never announces itself as missing. Query it with +dnssec and the NSEC type bitmap for audit.visibleorigin.com lists RRSIG NSEC TYPE128 and nothing else: no A, no AAAA.
Publishing that record would have meant signing a false statement with DNSSEC, on the site whose entire pitch is that you can check what it says.
An ALPN token the server refuses
The second rejection is alpn="mcp". The draft asks IANA to register the token and calls its own table a placeholder; offer it in the ClientHello and no ALPN is negotiated:
echo | openssl s_client -connect visibleorigin.com:443 -servername visibleorigin.com -alpn mcp 2>/dev/null | grep -i alpn
# No ALPN negotiated
echo | openssl s_client -connect visibleorigin.com:443 -servername visibleorigin.com -alpn h2 2>/dev/null | grep -i alpn
# ALPN protocol: h2Advertising mcp would point a conforming client at a connection this server cannot complete. Leaving it out cost nothing: turva.dev, the only already-passing domain in my set, also publishes a purely transport-level alpn.
What happened when the record went live
The scanner moved dnsAid from fail to pass: serviceRecordCount 0 → 1, dnssecValidated false → true, validServiceMode true, validationIssues empty. My written estimate beforehand was about a 60% chance, and it was not the deciding factor. The stopping rule came first: if the check stayed red, nothing changes — no falling back to _mcp._agents or any other name that exists in no revision of the draft. The record went up because it is true, not because it scores.
Of the nine domains I scanned by hand that day, this is the only one passing with an SVCB record; turva.dev passes with HTTPS. I have not scanned the rest of the internet, so I am not claiming to be first at anything.
What this does not mean
It does not make the site discoverable. The record enables nothing new. It says there is an HTTPS server at visibleorigin.com:443, which the A, AAAA and apex HTTPS records already said. Any sentence of the form “this makes us discoverable to AI agents” has nothing behind it.
It is not “standards compliant.” _agents and _index are not in the IANA underscored node names registry; §7.2 of the draft only requests them. The wording I will keep using: an SVCB record syntactically conformant with RFC 9460, under a name proposed by an active individual Internet-Draft that dnsop has not adopted, whose labels are not yet registered with IANA.
The chain on this domain is not complete, and here is the defect. A TXT record at the same name still reads agents=audit:mcp — announcing an agent called audit whose primary owner is the audit.visibleorigin.com that returns 530 above. That record predates this work. It comes down rather than being made true with a hostname I have no use for, and this paragraph will carry the date it went. Until then the chain has a dangling reference, visible in one query:
dig +short TXT _index._agents.visibleorigin.com @1.1.1.1
# "agents=audit:mcp"That TXT format is not from the draft either. The string agents= appears zero times in the draft text; the encoding it hints at sits in the section titled “Future Work and Experimental Mechanisms,” deferred to a future revision. It comes from the dns-aid-core reference implementation.
The general shape of this
A scoring tool is not a specification. This one is run by a company that fails its own check, scoring domains against a draft whose authors’ employer fails it too, and the only passing domain I could find was passing in a way the draft does not describe. Optimizing against the scanner would have produced two records any stranger with dig and curl could disprove. Reading the primary source produced one that survives those same commands, plus a known defect I would rather write down than leave for you to find.
The transferable part is not the record. It is that a green checkbox and a true statement come apart, and on any site they come apart in the same places: a header set in the CMS that no cache layer ever serves, a rule that returns 403 to a crawler nobody requested the site as. Finding those from outside, on somebody else’s domain, is the work I do for money.
Every command above runs against this domain. If one of them returns something other than what I said it does, that is worth an email.