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:
- Your parent's
DSRRset contains a digest matching the key we hold for your domain. - Every delegation
NSpoints atns1.whisper.onlineandns2.whisper.online. - The DNSSEC chain validates: independent public resolvers (Cloudflare, Google, Quad9, over v6 and v4) return validated answers, and our own servers serve a live
DNSKEYwhose digest matches theDS. - The
NSset andDSset 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:
- a routable
AAAA/128from2a04:2a01::/32(announced by AS219419), - a reverse
PTRback to the same name, so forward and reverse match, - a per-agent DANE-EE
TLSA(3 1 1) at_443._tcp.<name>, chaining through your own publishedDS, - an RDAP object and WHOIS record for the
/128, - inclusion in the transparency log,
- and the rest of the standard identity surface.
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
- DANE & TLSA is the key pin your own
DSanchors - RDAP is the registry object behind every
/128 - Verify an agent walks the full keyless proof set