Skip to content
Network & DNS
Skip navigation

Authoritative DNS

Which zones Whisper answers for, what signs them, and how a name under your own apex joins them.

Published

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:

RecordWhereWhat it carries
AAAAthe identity's canonical namethe address
PTRthe reverse tree under ip6.arpathe canonical name
CNAMEthe friendly name you chosethe 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:

bash
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.