Root operations
- Version
- v1
- In force since
- Not yet
- Next review
- At adoption
- Snapshot
- None yet
- Adopted by
- Proposed for founding adoption
- Signature
- At adoption
- Log entry
- Not appended yet
- Binding text
- English
Proposed, not in force
Open for comment until 28 October 2026, 00:00 UTC. Nothing here binds anyone until it is adopted.
Scope
This policy sets how Tier 0 runs the root and the platform day to day. Every global policy bounds it, and it may only tighten them.
Change freezes
Non-emergency root changes are blocked while a key rollover runs, for 72 hoursfixed around a key ceremony, during a declared incident and in announced freeze windows.
An emergency change during a freeze needs a written reason, is published like a veto, and is reviewed within 7 days.
Incidents and alerts
Incidents run with four severity levels and a named incident lead. For the two highest levels, a status update is posted within 15 minutes. A postmortem is published within 14 days, and regulators are told where the legal assessment requires it.
Every alert links to a runbook, every runbook is exercised at least once a year, and there is no alert without one.
Status is published on Kener Improved at a status subdomain, fed by the prober and the incident tooling, and hosted outside vps1.
Backups
The Postgres write-ahead log is archived continuously, encrypted base backups go nightly to two places outside vps1, and Vault is snapshotted daily. Restores are tested monthly, and a full rebuild of vps1 is rehearsed twice a year with the recovery point and time measured.
Software and releases
Go binaries and container images build reproducibly, with pinned toolchains, trimmed paths, SOURCE_DATE_EPOCH and locked dependencies, and a second build on another machine must match before a release.
Every release artefact ships with a CycloneDX SBOM, and a release with a known exploitable critical vulnerability is blocked.
Every release artefact, image and package is signed with a release key held in Vault, with checksums and verification steps published. Agents and clients verify the signature before any self-update.
Dependencies are pinned exactly, and each new one is justified, its licence included. A new upstream version waits 7 days unless it fixes a security issue. Our own code is written only in Go and TypeScript.
A STRIDE threat model is written and reviewed before any feature that touches keys, zones, sign-in, registrant data or the mirror agent is built, and every parser of untrusted input is fuzzed.
Rate limits
The api counts attempts in fixed windows, per address by its keyed hash or per account, and refuses the rest with 429 until the window ends. A key that works is never slowed down.
One address tries to sign in at most 30 per 15 minutesfloor.
One address signs up at most 10 per hourfloor.
One address asks for a password reset at most 10 per hourfloor, and one account at most 3 per hourfloor.
One address asks for a new verification mail at most 10 per hourfloor, and one account at most 3 per hourfloor.
One address uses links from mail at most 30 per 15 minutesfloor.
One address presents refused API keys at most 30 per 15 minutesfloor.
One account issues invitations at most 10 per hourfloor, and one address checks invitation codes at most 30 per 15 minutesfloor.
One address searches for available names at most 60 per minutefloor, and one account checks a zone's nameservers at most 30 per 15 minutesfloor.