Sign in
P-12ProposedTier 0 operations, Gelhaus Solutions (Tier 0)

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.

1

Scope

1.1
Bindingp12-c1

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.

2

Change freezes

2.1
Enforced settingp12-c2Not enforced yet

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.

2.2
Bindingp12-c3

An emergency change during a freeze needs a written reason, is published like a veto, and is reviewed within 7 days.

3

Incidents and alerts

3.1
Bindingp12-c4

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.

3.2
Bindingp12-c5

Every alert links to a runbook, every runbook is exercised at least once a year, and there is no alert without one.

3.3
Bindingp12-c6

Status is published on Kener Improved at a status subdomain, fed by the prober and the incident tooling, and hosted outside vps1.

4

Backups

4.1
Bindingp12-c7

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.

5

Software and releases

5.1
Bindingp12-c8

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.

5.2
Bindingp12-c9

Every release artefact ships with a CycloneDX SBOM, and a release with a known exploitable critical vulnerability is blocked.

5.3
Bindingp12-c10

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.

5.4
Bindingp12-c11

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.

5.5
Bindingp12-c12

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.

6

Rate limits

6.1
Bindingp12-c13

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.

6.2
Enforced settingp12-c14

One address tries to sign in at most 30 per 15 minutesfloor.

6.3
Enforced settingp12-c15

One address signs up at most 10 per hourfloor.

6.4
Enforced settingp12-c16

One address asks for a password reset at most 10 per hourfloor, and one account at most 3 per hourfloor.

6.5
Enforced settingp12-c17

One address asks for a new verification mail at most 10 per hourfloor, and one account at most 3 per hourfloor.

6.6
Enforced settingp12-c18

One address uses links from mail at most 30 per 15 minutesfloor.

6.7
Enforced settingp12-c19

One address presents refused API keys at most 30 per 15 minutesfloor.

6.8
Enforced settingp12-c20

One account issues invitations at most 10 per hourfloor, and one address checks invitation codes at most 30 per 15 minutesfloor.

6.9
Enforced settingp12-c21

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.