# Authoritative DNS

> The signed forward and reverse zones behind every Whisper identity, the records written when one is minted, and how a delegated apex joins them.

*Source: https://www.whisper.security/docs/network/authoritative*

---
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](/docs/identity/address), and the pin is on [Keys, Signing and
Encryption](/docs/identity/keys).

## 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](/docs/identity/verify) 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](/docs/identity/transparency).

## 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](/docs/identity/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](/docs/network/resolver/how-it-works).