# Passing the DNS-AID check with an SVCB record, and the two records I rejected

> The DNS-AID check fails Infoblox, Cloudflare and the scanner's own site. What the draft specifies, the one SVCB record I published, and the two I rejected.

Source: https://visibleorigin.com/dns-aid-svcb-record/
Published: 2026-08-31

---

The public scanner at [isitagentready.com](https://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.org` and `dnsaid.org`
- `a2aprotocol.ai`
- `agenticresourcediscovery.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=443
```

SVCB 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 signature
```

The `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: h2
```

Advertising `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](https://visibleorigin.com/services/).

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.