Endpoint

DNS and your domain

Every host and agent on your fleet already carries a real, routable identity in the public DNS. Bring your own domain and that identity lives under your own name instead of ours, with DNSSEC signed for you.

Your fleet is already in the DNS

Nothing here is new plumbing. The /128 identity every host and agent already holds is a public DNS name today, under agents.whisper.online: reverse DNS resolves it, DNSSEC signs it, a DANE-EE record pins its key, and RDAP carries the registration. A stranger checks all four with dig, delv and curl; our API is never in the trust decision. Bring-your-own-domain does not change any of that mechanism, it changes whose name it runs under.

Bring the identity under your own name

Point your domain's NS records at ns1.whisper.online and ns2.whisper.online, publish the DS we hand back at your registrar, and every identity minted after that lands under your apex instead of the shared plane: a{hex}.{your-domain} rather than a1b2c3d4e5f60718.t<hash>.agents.whisper.online. The delegation itself is the proof; there is no separate token to paste. Whisper computes a deterministic per-domain signing key and serves your zone signed on both nameservers from the first second, so your team never runs its own DNSSEC key rollover. DANE-EE is the trust default (no public CA in the path); a WebPKI leaf is an additive opt-in, not a replacement for the DANE anchor.

This page is the EDR-fleet angle. For the full delegation walk (the exact records, the four checks the observer requires, withdrawing a domain, the live-versus-roadmap line), see Bring your own domain on the main site, alongside the protocol references it draws on: DNS, DNSSEC, DANE & TLSA and RDAP.

Verify it with the CLI you already installed

The same whisper binary the sensor ships with carries the bring-your-own-domain trust chain as a subcommand, keyless, no account needed. whisper domain verify runs the identical check the console runs: DANE-EE, DNSSEC and the signed identity document, for any name under a Whisper-anchored domain, yours or the shared plane. Run here against a live identity on the shared plane, the same call resolves against a name under your own apex once it verifies:

$ whisper domain verify ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online
FIELD                VALUE
agent                yes
fqdn                 ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online
operator             tdc38e7c55bad3306a92b830f9bb1e4f9
dane_ok              yes
jws_ok               yes
dane_tlsa_sha256     9ec1ef18a1f15e5480a0fc3c8d6e9690b2ccf1a7fa7146201940f28c422bb47d
served_leaf_matches  yes
whisper: ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online is a verified Whisper agent (DANE-anchored)

The operator field is the registrant. On the shared plane it is an opaque tenant handle; under your own apex it is your domain, so the registrant a third party sees on an RDAP lookup is you, not a hash.

Why it matters for an EDR fleet

Attribution reads as your own naming. The reverse-DNS name your SIEM logs, the RDAP registrant your abuse desk sees, and the name printed in the console all become {host}.{your-domain} instead of a shared, tenant-hashed name. Nothing about the sensor or the graph changes; only whose name carries the record.
The DNS collector already ties a lookup to a process. The on-host DNS attribution tap joins every resolved name to the process that asked for it (see Telemetry collectors); once your own identities carry your own naming, that trail reads in terms your analysts already recognize.
No DNSSEC operations burden. The signing key, the rollover, and serving the zone on two active nameservers are ours to run. Your team's only touchpoint is the NS and DS at the registrar, the same two records that let you take the domain back at any time.

The console

Once a domain is delegated, the console's Domains section is where you manage it day to day: the records that live under your apex, and the DNSSEC state of the zone we sign for you. It is the same fleet you already govern from the console for identity, policy and containment, with your own domain now part of that surface.

Getting a domain onboarded

Submitting and checking a domain are key-gated, the control-plane half of the same two-tier command; run whisper login first. The failure mode on a missing or rejected key is a clean, specific error, never an opaque one:

$ whisper domain list
whisper: your key was not accepted - run: whisper login

$ whisper domain submit {your-domain} --json

submit takes the apex. There is no flag to add: a browser-trusted (WebPKI) leaf is not offered for a domain you bring yet, and --webpki refuses with that explanation rather than accepting a request nothing would act on. DANE-EE is the trust anchor either way. status <apex> reads the onboarding and trust state back, and list shows every domain on your account. See Bring your own domain for what the console and the control plane return once a domain is live.

← The /128 identity Calm footprint & SLA →