Whisper · Docs
Standards

DNSSEC

Every answer Whisper serves is signed, chains to a single trust anchor at the IANA root, and can be verified by anyone with dig — no account, no API key, no reason to believe us.

Why this page exists

Plain DNS has no integrity check. A resolver on a coffee-shop network, a poisoned cache, a malicious upstream, or an attacker on-path can hand your agent a forged AAAA record and there is nothing in the UDP packet that says "this is fake." Your agent connects to the wrong address, TLS may or may not save you depending on whether it validates hostnames properly, and by the time anything looks wrong the damage is done. For a fleet of autonomous agents resolving hundreds of names a minute with no human watching the screen, "trust whatever came back on port 53" is not a security posture — it is an open door.

DNSSEC closes that door with math, not policy. Every RRset Whisper serves — forward AAAA, reverse PTR, TLSA for DANE, TXT for the transparency ledger's keys — carries a signature that chains, zone by zone, up to the same root the entire internet already trusts. You don't have to trust Whisper. You have to trust the same one root key your resolver already ships with.

The chain, from the wire up

DNSSEC (RFC 4033, 4034, 4035) adds four record types and one flag bit to plain DNS:

Record Purpose
DNSKEY The zone's public key(s) — a Zone Signing Key (ZSK) and, in a split scheme, a Key Signing Key (KSK)
RRSIG A signature over an RRset, produced with the zone's private key
DS Delegation Signer — a hash of the child zone's KSK, published in the parent
NSEC / NSEC3 Authenticated denial — proves a name does not exist, signed like any other RRset
AD bit Set by a validating resolver (not the authoritative server) once it has walked the chain and every signature checks out

The chain for an agent's forward name — structured <agent-id>.<tenant>.agents.whisper.online, e.g. ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online — walks like this:

  1. The root zone (.) is signed; its trust anchor (the KSK's hash) is the one thing every validator is preconfigured with — a single anchor, not one per registrar or provider (RFC 4033 §2).
  2. Root holds a DS record for online. (or the relevant TLD), which is a hash of online.'s KSK.
  3. online. holds a DS for whisper.online., hashing its KSK.
  4. whisper.online. — the zone this server is authoritative for — signs the AAAA/PTR/TLSA/TXT RRsets it serves for every agent, live, on every answer.

Each hop is "does the hash in the parent's DS match the child's DNSKEY, and does the child's signature over the DNSKEY RRset verify with that key." Break any link and validation fails closed — the resolver returns SERVFAIL, not a downgraded plain answer. That fail-closed behavior is the entire point: an attacker who can spoof UDP packets cannot also forge a signature they don't hold the private key for.

Algorithm 13 — ECDSA P-256

Whisper signs with DNSSEC algorithm number 13: ECDSA using curve P-256 with SHA-256 (RFC 6605 defines the algorithm; the IANA registry assigns it number 13). Whisper runs a single Combined Signing Key (CSK, RFC 6781 §3.2.1) rather than a split ZSK/KSK pair — so a dig whisper.online DNSKEY returns exactly one 257 3 13 key that both signs the zone's RRsets and is the one the parent's DS attests. One key, one algorithm, one thing to reason about — the leaner design is also the more auditable one. Compared to the older RSA/SHA-256 (algorithm 8) still common on legacy zones, ECDSA-P256 signatures are roughly a quarter the size — around 64 bytes versus 256+ for a comparable-strength RSA signature — which matters when every DNS answer over UDP has to fit under the path MTU without fragmenting. Smaller signatures mean smaller RRSIG records, smaller DNSKEY responses, and a lower chance of ever needing to fall back to TCP for a signed answer.

NSEC3 — proving a name doesn't exist

The harder half of DNSSEC isn't proving a record exists — it's proving one doesn't, without letting an attacker enumerate every name in the zone by walking the negative-answer chain (the original NSEC design leaks the full sorted zone contents to anyone who asks). RFC 5155 fixes this with NSEC3: instead of listing the next actual name in the zone, it lists the hash of the next name, salted and iterated with SHA-1. A resolver can still prove "nothing sorts between these two hashes, so your query name doesn't exist" — but can't reverse the hash to recover the zone's real name list. Whisper's dynamic zones (both the delegated forward zones and the 2a04:2a01::/32 reverse tree) use NSEC3 for exactly this reason: the zone contains real agent identities, and an enumerable NSEC chain would hand an attacker a directory of every agent ever provisioned.

Verify it yourself — stock tools

No Whisper software required. Any DNSSEC-aware resolver already validates this; you're just asking it to show its work.

# 1. Ask a validating resolver and look for the AD (Authenticated Data) bit
dig @1.1.1.1 ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online AAAA +dnssec
# ... flags: qr rd ra ad;  <-- "ad" means Cloudflare's resolver validated the chain itself

# 2. Pull the actual signature and key records straight from Whisper's authoritative server
dig @ns1.whisper.online whisper.online DNSKEY +multi
dig @ns1.whisper.online ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online AAAA +dnssec +multi
# RRSIG AAAA 13 5 60 ... <alg 13 = ECDSA P-256, per RFC 6605>

# 3. Walk the chain of trust from the root down, entirely offline of Whisper's opinion
delv @1.1.1.1 ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online AAAA
# ; fully validated

# 4. TLSA under DNSSEC — the DANE pin for the agent's TLS leaf (see /docs/dane)
dig +short TLSA _443._tcp.ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online +dnssec
# 3 1 1 9EC1EF18...422BB47D   <-- 3=DANE-EE, 1=SubjectPublicKeyInfo, 1=SHA-256

delv (part of BIND, RFC 4035-aware) is the reference validator: it re-derives the chain itself rather than trusting a resolver's AD bit, which is the right level of paranoia for anything scripted. kdig (Knot DNS's client) is a good second opinion with cleaner DNSSEC-specific output:

kdig +dnssec @ns1.whisper.online ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online AAAA
kdig +dnssec +multi @ns1.whisper.online whisper.online DS       # the DS Whisper's parent must publish

Verify it with Whisper

The whisper CLI wraps the same chain walk into one command, and — critically — it's the mechanism the trustless verification path is built on: a peer proves your agent is real by validating DNSSEC and DANE itself, never by asking Whisper's API to vouch for it.

# CLI — re-derives the DNSSEC + DANE chain locally, prints the verdict
whisper verify --trustless ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online

# keyless HTTP verdict, same underlying chain check, JSON for scripting
curl -s https://rdap.whisper.online/verify-identity/ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online | jq .
# {"is_whisper_agent": true, "fqdn": "ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online",
#  "dane_ok": true, "jws_ok": true,
#  "evidence": {"address": "2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478", "forward_aaaa": "...", "ptr": "..."}}

# the control-plane verb, for a tenant checking its own fleet
CALL whisper.agents({op:'identity', args:{agent:'my-agent'}})

Every one of these is keyless — no API key required to verify an agent's identity (RULE-of-thumb: verification is a public good; only provisioning and egress need a key). See whisper create for provisioning and DANE for what the TLSA record itself protects once DNSSEC has proven it's genuine.

What "signed" actually buys you

DNSSEC alone doesn't encrypt anything and doesn't stop a man-in-the-middle from reading your query on the wire (that's DoH/DoT's job) — it stops an attacker, on-path or off, from making a resolver believe a forged answer. Combined with DANE's TLSA pinning (RFC 6698) — which is itself only trustworthy because the TLSA record is DNSSEC-signed — the pair gives you certificate validation with zero certificate authority in the loop: the DNS chain from the IANA root to whisper.online is the entire trust path, an open, auditable, thirty-year-old standard rather than a proprietary API you're asked to take on faith.

Next

← How DNS worksDANE & TLSA →