WhisperDocs
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 ";" denying every public CA by default: the live trust model for a BYOD identity is DANE-EE, pinned by your own DNSSEC chain, not WebPKI. A second, opt-in CAA line authorizing Whisper's own ACME issuance is already part of the record set op:'domain' hands back, and whisper domain submit --webpki is the real command that requests it - but the path targets a staging CA and stays off fleet-wide until a domain explicitly opts in, so DANE-EE is what a BYOD identity actually gets until you've opted in and confirmed a leaf is installed. 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 is live. whisper.agents({op:'domain'}) is on the public control plane today, reachable with your own API key, no allowlisting and no email required:

$ curl -s https://graph.whisper.online/api/query \
  -H "X-API-Key: whisper_live_..." -H 'content-type: application/json' \
  -d '{"query":"CALL whisper.agents({op:\"domain\", action:\"status\", name:\"yourdomain.com\"})"}' | jq .

{
  "op": "domain", "ok": true, "status": 200,
  "result": { "columns": ["kind", "value"], "rows": [
    ["state",  "pending"],
    ["name",   "yourdomain.com"],
    ["record", "yourdomain.com. 60 IN NS ns1.whisper.online."],
    ["record", "yourdomain.com. 60 IN NS ns2.whisper.online."],
    ["record", "yourdomain.com. 60 IN DS 20958 13 2 E04417BDC9318858DD2610DB39B7FEB33F5DDA9C97D2C2DB88B2E057B230A5C5"],
    ["record", "yourdomain.com. 60 IN DS 20958 13 4 C1ED673F5B043D260C20ADEC078E13BCCF98649B68D40C79A17A5D6DE53241CA7A91A3B534FA37CDCA1DB78E21B0FA86"],
    ["record", "yourdomain.com. 60 IN CDS 20958 13 2 E04417BDC9318858DD2610DB39B7FEB33F5DDA9C97D2C2DB88B2E057B230A5C5"],
    ["record", "yourdomain.com. 60 IN CDS 20958 13 4 C1ED673F5B043D260C20ADEC078E13BCCF98649B68D40C79A17A5D6DE53241CA7A91A3B534FA37CDCA1DB78E21B0FA86"],
    ["record", "yourdomain.com. 300 IN CDNSKEY 257 3 13 Ms1BqcUPcmk0yxqsXvd4LceWmSPHoMJSAw+ZERfFkR/SZefysoj9u/8cdzt/WkASJRKIyGGNmnMplKQKuzh4ew=="],
    ["caa",    "yourdomain.com. 3600 IN CAA 0 issue \";\""],
    ["caa",    "yourdomain.com. 3600 IN CAA 0 issue \"whisper.online\""],
    ["note",   "Do NOT add glue (A/AAAA) records for ns1.whisper.online or ns2.whisper.online. They are out-of-bailiwick of your zone, so no glue is needed - your registrar resolves them from whisper.online. Any glue you add can go stale and become a hijack/lameness vector outside our control."],
    ["note",   "Publish the NS and DS records above at your registrar / parent zone. We poll your parent on a schedule; we bring your zone up as soon as we observe your parent delegating it to us, and the domain is authorized on your account automatically once the DS is live too (no further action)."]
  ]}
}

One call hands back everything you need to publish - the exact NS/DS/CDS/CDNSKEY set, both CAA lines (see below), and the two operator notes. As of this writing assess, submit, status, and list all answer with the same record set for a given name - action doesn't yet change the response shape, so treat any of the four as "tell me what to publish and where I stand," not as distinct steps.

There's also a guard on the single-label case: op:'domain' on a bare label like agent1 - not a registrable apex - fails clean instead of trying to onboard it, and points you at the right verb instead:

{"ok": false, "status": 400, "error": {"code": "DOMAIN_NOT_REGISTRABLE",
  "message": "\"agent1\" is a single label, not a registrable domain. ... If you meant to give an agent a Whisper identity, use op:'register' instead."}}

The CLI wraps the same call - verify is keyless, submit/status/list need your key:

whisper domain verify yourdomain.com     # keyless - the DANE-EE + DNSSEC + JWS chain, no account needed
whisper domain submit yourdomain.com     # keyed - submits and returns the record set above
whisper domain status yourdomain.com     # keyed - onboarding + trust state

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.

Live and keyed today: self-serve onboarding through op:'domain' on the public control plane - assess/submit/status/list are all reachable with your own key right now and hand back the exact record set to publish, no email required. (The four verbs currently answer identically for a given name; action doesn't yet change the response shape.)

Not yet: browser-trusted (WebPKI) certificates under a domain you bring. ACME issuance runs today only for apexes we operate, and there is no self-serve opt-in for a BYOD domain, so whisper domain submit --webpki refuses and explains why rather than accepting a request nothing would act on. The second CAA line is published and correct, and the DANE-EE TLSA pin is the trust anchor every BYOD identity gets by default, browser-trusted leaf or not.

Next

← RDAPWHOIS →