DNS setup¶
One TXT record turns your server from "some host on the internet" into a verifiable sender. Publishing it is the single most important post-install step.
What the record is¶
At boot, the server generates (or loads) its root key and prints the record to publish:
docker compose logs api
You are looking for a line naming _revoked.<your-domain> with a value like
v=revoked1; k=sha256/1421ab…64 hex characters…
That hex string is the SHA-256 fingerprint of your server's root public key. Publishing it under a name only you control is what lets any client on any server verify the chain: DNS names the key → the key signed the identity → the identity signed the request. A phisher can claim your domain in a request; they cannot publish records in your DNS zone.
Publishing it¶
The record goes at _revoked. prepended to your exact DOMAIN. If
DOMAIN=api.example.com, the record is _revoked.api.example.com.
Most registrars auto-append the zone, so in the host field you type the part without the zone:
| DOMAIN | Record name | Host field at the registrar |
|---|---|---|
example.com |
_revoked.example.com |
_revoked |
api.example.com |
_revoked.api.example.com |
_revoked.api |
In Namecheap: Advanced DNS → Add new record → TXT Record, host as above,
value the full v=revoked1; k=sha256/… string, TTL automatic.
Verifying it took¶
DNS changes are not instant — a few minutes is normal, and your registrar's own dashboard can lag behind what it has actually published. Check from the outside:
dig TXT _revoked.api.example.com +short
You should see the v=revoked1; k=sha256/… value quoted back. The app checks
the same thing end-to-end: Settings → Developer → Domain verification runs
the full chain against public DNS-over-HTTPS resolvers and tells you exactly
which step failed if one did.
Until it resolves¶
The server works without the record — but every identity it issues shows as unverified, in red, on any client that checks. That is deliberate: a client that cannot verify says so rather than trusting silently. Publish the record and the same identities verify with no further action.
If the key ever changes¶
The fingerprint is derived from server_root.pem in the pb_data volume. A
fresh volume means a fresh key, which means the published record no longer
matches and every previously issued identity stops verifying — this is why
backups matter more than anything else on the machine. Restoring
the volume restores the fingerprint; only then does the old record become
valid again.