isitdns? is it DNS?
DNS for AI

When an agent asks DNS where another agent lives, prove the answer is real.

AI agents are starting to discover each other through DNS. That makes the discovery path a target: whoever sits on it can point an agent at an impostor and nothing in ordinary DNS will tell the agent it was lied to. isitdns gives DNS an alibi — cryptographic proof that the query reached the genuine authority and the answer came back untouched. When something goes wrong, you can prove it was not DNS.

run a probe read the protocol

The gap DNSSEC leaves open

DNSSEC proves the record is authentic, if the client validates. It says nothing about whether this query reached a real authority, whether the answer was modified in flight, or whether a transparent forwarder is quietly logging every lookup. Those are questions about the path. Automated agents are the least likely to validate and the most valuable to intercept, so the path is exactly where the risk moved.

So how can you tell?

That is the whole question. Everyone says "it's DNS." Almost no one can actually tell — prove the query reached the real authority and came back untouched. Until now the honest answer was a shrug. Here is how you tell:

The agent asks for a name it has never used and never will, carrying a fresh random nonce, under a zone the authority synthesizes per query. No cache, forwarder, or interceptor can precompute the answer, so the query has to reach a genuine authority to be answered at all. The authority signs the nonce, the exact name, and the resolver exit it actually saw:

# one query, asked over plain DNS, DoT, or DoH dig TXT x<nonce>.t.probe.isitdns.net # the answer is a signature you verify offline — no CA, no trust in this page verdict: PROVEN — reached the genuine authority, unmodified in flight egress: the resolver exit the authority actually saw

A PROVEN receipt is DNS's alibi: the path held. A mismatch names the culprit on the path. Absence is never promoted to proof — the discipline is the product.

Don't believe us. Monitor us yourself.

Every verdict on this site is checkable math, not our word. You verify the signature offline, against a key published where no certificate authority sits in the path. If we lied, the signature would fail in your hands, not ours.

So point it at any DNS — your own, your provider's, ours. isitdns is an independent external witness: when a vendor says "your DNS is fine," you no longer have to take their word for it. Turn up a witness outside their network and watch the path yourself. Inside a grid, pull your busiest domains straight from reporting and monitor those exact services from the outside in — the view the vendor's own dashboard cannot give you, because it is graded by someone who is not the vendor.

Built for the agent era

Proves the discovery path

As agent-to-agent discovery moves into DNS, isitdns is the layer that proves the discovered record reached the agent from the real authority, untampered.

Offline-verifiable

An agent verifies an Ed25519 signature with a pre-published key. No certificate authority in the path, no dependence on the agent doing DNSSEC validation.

Keyless probe, anywhere

A small agent runs on a laptop, a branch box, a build runner. It measures and relays; it holds no key, so it can never forge a verdict. Safe to hand to anyone.

Off the CDN edge

The authorities sit off any single cloud edge, so they can actively test nameservers and paths an edge-only checker physically cannot reach.

Prove it in three steps

  1. Ask the canary for a fresh nonce through the path you want to test — plain DNS, DoT, or DoH.
  2. Get back a signed receipt: the nonce, the exact name, and the resolver exit the authority saw.
  3. Verify the signature offline against the published key. It holds, or it does not. No trust required.
Honest limits, up front. This proves the path for one name to one zone at one moment. A matching egress never proves a clean path — only a mismatch is evidence. It is not confidentiality, and it makes no claim about other domains. Say these first; the honesty is what makes the proof believable.

Standards it leans on

RFC 8032 Ed25519 · RFC 1035 DNS · RFC 4033-4035 DNSSEC · RFC 4035 §5.2 insecure delegation · RFC 6891 EDNS(0) · RFC 7873 / 9018 DNS cookies · RFC 9156 qname minimisation · RFC 8484 DoH · RFC 7858 DoT · RFC 8914 extended errors

run a probe read the protocol