Authoritative DNS
Which zones Whisper answers for, what signs them, and how a name under your own apex joins them.
On this page (5)
Authoritative DNS Documentation
An identity is only checkable because something authoritative answers for it. Whisper runs that half itself: the forward zone the identity names live in, the reverse tree that covers its address space, and any apex a customer delegates.
What is published, and when
Minting an identity writes a set of records in one step, so there is never a window where half the proof exists:
| Record | Where | What it carries |
|---|---|---|
AAAA | the identity's canonical name | the address |
PTR | the reverse tree under ip6.arpa | the canonical name |
CNAME | the friendly name you chose | the canonical name |
TLSA | _443._tcp.<fqdn> | a pin on the identity's own key |
The forward and reverse halves are separate delegations that are populated independently, which is what makes a mismatch between them a signal rather than a shrug. How the name is derived from the address is on The Address as Identity, and the pin is on Keys, Signing and Encryption.
Everything is signed
Every zone is DNSSEC-signed with ECDSA P-256, using a single combined signing key per zone, and the zones that change constantly use NSEC3. That is what lets a stranger validate an answer from the IANA root down without asking Whisper for anything:
delv -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478
dig +dnssec AAAA ae3b051ff3bf7f478.t<tenant>.agents.whisper.online
The AD bit on those answers is the point of the exercise. A verifier that skips it is
trusting the transport instead of the signature, which is the failure mode
Verify an Identity is written to avoid.
Where the signing keys live
Two things are signed with keys that DNS itself publishes rather than with the zone key: the
identity documents an agent serves, and the transparency log's checkpoints. Their public
halves are TXT records under whisper.online, at _whisper-identity and _whisper-ledger,
so a verifier fetches the key the same way it fetches everything else. The log is described
in The Transparency Log.
Under your own name
You can have identities answered for under your own apex instead of Whisper's. You delegate the apex and publish the delegation signer record that the submit step hands you, and the observed signed delegation is itself the authorization, so there is no text record to place and no challenge to poll. The record set covers the nameservers, the delegation signer (algorithm 13 with a SHA-256 digest, and a SHA-384 digest offered as well), the two child-side records that let the key rotate, and a certificate authority authorization pair. Removing the nameserver and delegation signer records withdraws it again.
Agents minted under a delegated apex get the same record set as any other identity, signed with a key that belongs to that zone alone. The steps are on Bring Your Own Domain.
Reading the zone as a client
Nothing here needs an account. The resolver side, where answers are filtered rather than served, is a different job with a different contract: How Resolution Works.