DNSSEC and keys

This policy sets how the root and every TLD zone Gelhaus Solutions signs are keyed, signed, published and rolled. A self-hosted TLD keeps its keys under controls no weaker than these.

Every DNSSEC key uses algorithm 13fixed, ECDSA P-256 with SHA-256, and every DS record we publish uses digest type 2fixed, SHA-256. SHA-1 is used nowhere.

An algorithm rollover is rehearsed every year on the local stack, so that moving to a post-quantum algorithm later is routine.

Every key has exactly one role and its own key in Vault: the root KSK and ZSK, each TLD's KSK and ZSK, the CA roots and issuing CAs, the anchor bundle key, the release key, the log checkpoint key, TSIG keys and the mirror enrolment CA.

Every signing key is a non-exportable Vault Transit key with plaintext backup disabled, and every signature is made inside Vault. There is no fallback to a local key.

Rule keys.in_vault. Limits: A non-negotiable, which no scope, motion or emergency reaches.

Vault is reachable only from named hosts over WireGuard, keeps two audit devices, binds every credential to network addresses, and holds no standing root token.

A signer refuses to sign when its clock is not synchronised by NTS or is off by more than 1 secondfixed.

The root KSK is offline. It is held in a separate ceremony Vault that stays sealed outside ceremonies and opens only with 3 of 5 key shares, each held by a different person in a tamper-evident bag at a separate site. The online signer never holds it.

Offline keys, namely the root KSK, the CA roots and the anchor bundle key, are generated and used only in scripted ceremonies with at least two witnesses, published scripts, a recording or signed notes, and minutes entered in the transparency log.

Signatures are valid for 30 daysfixed, with jitter. A zone is re-signed when fewer than 21 daysfixed remain, the publishing gate refuses a zone with fewer than 20 daysfixed, and alarms fire at 17 daysfixed and at 14 daysfixed remaining.

Every zone we publish carries a SHA-384 ZONEMD record. Two independent validators check each zone before it is published; a zone that fails either is not published, and the version already serving stays. Mirrors reject any copy whose ZONEMD or DNSSEC chain fails.

Rule zone.integrity.

The root uses NSEC. A TLD uses NSECfloor unless its own policy chooses NSEC3, with the parameters RFC 9276 recommends.

ZSKs roll by pre-publication every 180 daysfloor. TLD KSKs roll every 12 monthsfloor by double-DS. The root KSK rolls every 2 yearsfixed under the timers of RFC 5011, the first time within 12 months of launch.

An emergency rollover is rehearsed every year for every key role. A rollover runs under a validation watch, can be paused, and blocks non-emergency root changes while it runs.

A registrant's DS record is accepted for algorithms 8, 13, 14, 15 and 16 and digest types 2 and 4, and is published only where the child zone's keys match it, since a DS record that matches no key makes the name fail validation for everyone.

Rule ds.preflight.

Every trust anchor, the root KSK's DS and DNSKEY and the CA roots, is published through at least 3 independent channelsfixed: HTTPS at cdr.gplatform.org, the transparency log and signed release packages. A change is announced through all of them at least 30 daysfixed ahead.

While the root anchor is a test anchor, it may be replaced at shorter notice than 8.1 sets. Every replacement is still announced through every channel and recorded in the transparency log.