Whisper · Docs
Standards

Bring your own domain

Your agents under your own apex. The delegation is the onboarding, and the delegation is the proof.

Delegation is the proof

Give your agents an identity under your own domain, not ours. You keep the name at your registrar; Whisper runs the authoritative DNS for it, signs it, and mints per-agent identities like a1b2c3d4e5f60718.yourdomain.com that resolve to routable /128 addresses and carry their own DANE-pinned keys.

There is no TXT challenge and no verification token to paste. Pointing your NS records at ns1.whisper.online and ns2.whisper.online and publishing our DS at your registrar is implicit enough: only the domain's holder can change the delegation at the parent, so a signed delegation observed live in the public DNS is the authorization. That observation is the one check in the whole system that fails closed; everything else fails open.

Everything your agents get afterwards (address, reverse DNS, key pin, RDAP object, transparency receipt) is verifiable by any third party with stock tools and no Whisper API key. So start with the proof.

Verify it yourself

Once your domain is verified, everything below is keyless and third-party checkable, no account required. Substitute your own domain and agent name; the outputs show the shape you will see. The values here are illustrative.

The delegation and its DNSSEC chain:

dig +short NS yourdomain.com
#   ns1.whisper.online.
#   ns2.whisper.online.

dig +short DS yourdomain.com @1.1.1.1
#   12345 13 2 EBD7EB8EA3A206F167A2FA023B36DADAD8117C1AC060790974268D5831B3110C

dig +short DNSKEY yourdomain.com @1.1.1.1
#   257 3 13 mDg4c1B2eXaMPLekeYbYtEsGoHeReNoTaReAlKeYjUsTiLLuStRaTiVeExAmPLev4==

# a validator that owes us nothing walks the chain from the IANA root down to your TLD:
delv @1.1.1.1 yourdomain.com NS
#   ; fully validated
#   yourdomain.com.  300  IN  NS  ns1.whisper.online.
#   yourdomain.com.  300  IN  NS  ns2.whisper.online.

The DS key tag (12345) matches the DNSKEY the servers answer with, the algorithm is 13 (ECDSA P-256 SHA-256), and delv prints "fully validated" because the parent's DS, our DNSKEY, and every signature agree. The record set for this domain also carries a SHA-384 digest, 12345 13 4 0A1B2C3D4E5F60718293A4B5C6D7E8F90A1B2C3D4E5F60718293A4B5C6D7E8F90A1B2C3D4E5F60718293A4B5C6D7E8F9, for registrars that accept digest type 4; your TLD's parent registry publishes the SHA-256 one.

A minted identity under the apex:

FQDN=a1b2c3d4e5f60718.yourdomain.com
ADDR=2a04:2a01:1a2b:3c4d:5e6f:7081:92a3:b4c5

dig +short AAAA "$FQDN"
#   2a04:2a01:1a2b:3c4d:5e6f:7081:92a3:b4c5

delv @1.1.1.1 "$FQDN" AAAA
#   ; fully validated

dig +short -x "$ADDR"
#   a1b2c3d4e5f60718.yourdomain.com.

dig +short TLSA "_443._tcp.$FQDN"
#   3 1 1 1F2E3D4C5B6A79808F1E2D3C4B5A69788796A5B4C3D2E1F009182736455463728

curl -s https://rdap.whisper.online/ip/"$ADDR" | jq '{handle, objectClassName, status}'
#   { "handle": "a1b2c3d4e5f60718", "objectClassName": "ip network", "status": ["active"] }

Forward and reverse match. The DANE-EE pin (3 1 1) chains to the public root through the domain's own published DS, not through a CA. The /128 is a first-class RDAP object; its registrant is the domain itself (under your own apex there is nothing left to hide), while a registrant on the shared agents.whisper.online plane is an opaque tenant handle t<sha256>. A raw account identifier never appears in either. The mint is also logged in the append-only transparency log.

What the observer checks

Once your NS and DS are live at the registrar there is nothing more to do. We poll the public DNS from multiple vantage points and require all four of these to hold, agreeing across every answering vantage:

  1. Your parent's DS RRset contains a digest matching the key we hold for your domain.
  2. Every delegation NS points at ns1.whisper.online and ns2.whisper.online.
  3. The DNSSEC chain validates: independent public resolvers (Cloudflare, Google, Quad9, over v6 and v4) return validated answers, and our own servers serve a live DNSKEY whose digest matches the DS.
  4. The NS set and DS set are identical across every vantage. A split answer never wins on majority; it fails.

Only when all four hold does the domain verify and attach to your account; every identity you mint from then on lands under your apex. A timeout or a SERVFAIL is treated as inconclusive, never as proof of absence, so a transient blip never triggers a false revocation. A daily continuity sweep re-checks verified domains; only a definitive chain break (NS moved away, DS removed, a re-key) revokes.

One key, two servers, one DS

The per-domain signing key is a single ECDSA P-256 CSK, algorithm 13, derived deterministically. Both authoritative servers compute a byte-identical key on their own, so they answer identically from the first second, and no private key ever crosses the wire. Re-provisioning a domain reproduces the same key, which is why the DS is stable enough to print on this page: the yourdomain.com digest above does not churn.

The record set

Two record types are load-bearing: NS and DS. Our nameserver names are out of bailiwick, so no glue is needed.

; the delegation
yourdomain.com.   NS   ns1.whisper.online.
yourdomain.com.   NS   ns2.whisper.online.

; the delegation signer, both digest types (SHA-1 is never used)
yourdomain.com.   DS   <keytag> 13 2 <SHA-256 digest>
yourdomain.com.   DS   <keytag> 13 4 <SHA-384 digest>

For registrars that scan and auto-adopt child records (RFC 7344), the zone also serves matching CDS and CDNSKEY at the apex, plus CAA 0 issue ";". The CAA denies every public CA on purpose: the live trust model for a BYOD identity is DANE-EE, pinned by your own DNSSEC chain, not WebPKI. A public-CA opt-in is roadmap; see below.

What each agent gets

With the domain verified, minting is unchanged; the identity simply lands under your name. Each agent under your apex carries the same surface as one under agents.whisper.online:

Names already minted under agents.whisper.online keep resolving; the two planes coexist.

Getting onboarded

Self-serve provisioning through the public control plane is rolling out. The domain verbs (assess, submit, status, list under whisper.agents({op:'domain'})) are built and running on the authoritative fleet, but the public endpoint does not accept op:'domain' yet, so you cannot reach them with your API key today.

To bring a domain now, email hostmaster@whisper.online with your apex; you get back the exact NS and DS set to publish, and the observer does the rest.

The verification half needs no onboarding, no key, and no account: everything under Verify it yourself works against any verified domain.

Withdrawing

To take the domain back, remove the NS and DS at your registrar (auto-scanning registrars can use the RFC 8078 delete sentinels the zone serves). The daily sweep observes the definitive break and revokes cleanly: the zone is withdrawn and the domain detaches from your account.

Live vs roadmap

Live and keyless today: the delegated, DNSSEC-signed zone on both nameservers; deterministic per-domain keys and a stable DS; apex-direct names (a<hex>.yourdomain.com); routable /128 identities with matching reverse DNS; DANE-EE TLSA pins; RDAP and WHOIS; transparency-log inclusion. All of it demonstrated above on yourdomain.com.

Rolling out: op:'domain' on the public control plane (self-serve assess, submit, status, list). Until it lands, onboarding is by email.

Roadmap, not live: browser-trusted (WebPKI) certificates under a BYOD domain via ACME. Today the live certificate trust for BYOD identities is DANE-EE only.

Next