Signed path attestation

DNSSEC proves the answer is authentic. It does not prove that your query reached the genuine authority, over a clean path, unmodified. This does.

The gap

A validating resolver can tell you a record is signed and unaltered. It cannot tell you whether a forwarder sat invisibly in the middle of your path, whether your query left the network you think it did, or whether the answer you received is the one the authority actually sent. Those are questions about the path, and nothing in DNS answers them.

How it works

You mint a fresh random 128-bit nonce and put it in the name you look up.
The query travels your real resolution path to our authoritative server.
The server answers with an attestation signed with Ed25519, covering your nonce, the exact name asked, the transport used, and the IP your resolver actually arrived from.
You verify the signature against a published key. Offline. No trust required.

Because the nonce is fresh and unpredictable, a replayed or pre-computed answer cannot satisfy it. Because the signature covers the exact name, an answer cannot be swapped for a different one. Because only the authority holds the private key, nothing else can produce a valid attestation.

What is in an attestation

// 112 bytes on the wire: 48-byte payload + 64-byte signature version 1 byte wire format key id 4 bytes which server signed it timestamp 4 bytes replay window name hash 16 bytes binds the exact name you asked for transport 1 byte Do53, DoT or DoH flags 2 bytes DNSSEC OK, EDNS, cookies, ECS, 0x20, qname minimisation ecs 4 bytes client-subnet lengths only, never an address egress 16 bytes the resolver exit the authority actually saw

The signature is domain separated, so an attestation can never be lifted and replayed in another context. The whole answer fits in a single unfragmented UDP packet.

The egress is the load-bearing field. It is what unmasks a hidden forwarder, shows your ISP's real DNS exit, and reveals when the resolver you configured is not the one doing the resolving.

Verdicts

Verdict	Meaning
PROVEN	Valid signature over your fresh nonce and the exact name. The path reached the genuine authority and the answer was unmodified in flight.
SUSPECT	Signed, but bound to a different name than the one you asked for. Possible answer substitution.
FAIL	No valid signature. Spoofed, tampered with, or the wrong key.
INFERRED	Evidence, not proof. Comparisons and absences live here and never get promoted.

The distinction is deliberate and strict. An absent attestation is never treated as a failed path, and a comparison is never treated as a proof. An adversary can deny proof; they can never fabricate it.

Honest limits

A matching egress never proves your path is clean. A transparent interceptor that re-forwards your query can produce a matching exit. Only a mismatch is evidence, and it is evidence, not proof.
This proves the path to our authority for our name. It says nothing about any other zone.
A missing measurement means we did not see it, nothing more.
Delivery is best effort by design and never blocks or slows a DNS answer.

Quorum

One source gives you no truth. Two that disagree cannot tell you which one is lying. Three is quorum, and it is the same reason you do not run two NTP servers. Our notaries continuously prove the path to each other, so a break localises to a path rather than leaving you with a shrug.

Standards it leans on

RFC 8032 Ed25519 · RFC 1035 DNS · RFC 4033-4035 DNSSEC · RFC 6891 EDNS(0) · RFC 7873 DNS cookies · RFC 9156 qname minimisation · RFC 7766 DNS over TCP · RFC 8484 DoH · RFC 7858 DoT · RFC 8914 extended errors · RFC 2182 nameserver diversity

Run one yourself

Anyone can measure their own path and check our signature. Serve on the jury.