GOpenCDR DNSSEC practice statement

About this statement

This is the DNSSEC Practice Statement for the GOpenCDR root zone and for the TLD zones Gelhaus Solutions signs, following the outline of RFC 6841. It states how the keys are held, how zones are signed and published, and what a relying party can check.

GOpenCDR's root is an overlay. It holds only GOpenCDR's TLDs and never replaces the IANA root or its trust anchor: a validating resolver keeps the IANA anchor untouched and adds GOpenCDR's alongside it.

Publication

The trust anchor is published in the format of RFC 9718 through three independent channels: over HTTPS at cdr.gplatform.org, in the public transparency log, and in signed release packages. A change of anchor is announced through all three at least 30 days ahead.

The root trust anchor is published as a test anchor. It may be replaced at shorter notice than 30 days, and every replacement is still announced through all three channels and recorded in the transparency log.

This statement is kept, with every earlier version, in the document archive.

Keys

• Algorithm. Every key uses algorithm 13 (ECDSA P-256 with SHA-256), and every DS record we publish uses digest type 2 (SHA-256). SHA-1 is not used anywhere.
• One role, one key. The root key-signing key (KSK), the root zone-signing key (ZSK), and each TLD's KSK and ZSK are separate keys, each held as its own key in HashiCorp Vault.
• Keys never leave the key store. Every key is non-exportable, with plaintext backup disabled, and every signature is made inside the key store. There is no fallback to a local key.
• The key store runs on our own hardware in Germany and is reachable only over WireGuard from named hosts. It keeps two audit devices, credentials are bound to network addresses, and no standing root token exists.
• The root KSK is offline. It is held in a separate ceremony key store that stays sealed outside key ceremonies and opens only with three of five key shares, each held by a different person and kept in a tamper-evident bag at a separate site. It is used only at ceremonies, to sign the root's DNSKEY sets in advance, and the online signer never holds it.
• Clocks. A signer refuses to sign when its time is not synchronised by NTS or is off by more than one second.

Ceremonies

Offline keys are generated and used only in scripted ceremonies with at least two witnesses. The scripts are published, each ceremony is recorded or documented in signed notes, and its minutes are entered in the transparency log. Non-emergency changes to the root are frozen for 72 hours around a ceremony.

Signing

• Validity. Signatures are valid for 30 days, with jitter. A zone is re-signed when fewer than 21 days remain, and the publishing gate refuses anything with fewer than 20. Alarms fire at 17 and at 14 days, so an outage of about two weeks between the signer and the key store costs nothing in the field.
• Denial of existence. The root uses NSEC. TLDs use NSEC by default, and a TLD may choose NSEC3 with the parameters RFC 9276 recommends.
• Zone integrity. Every zone we publish carries a SHA-384 ZONEMD record, and mirrors reject any copy whose ZONEMD or DNSSEC chain fails.
• Two validators. Two independent validators check every zone before it is published. A zone that fails either is not published, and the version already serving stays in service.

Rollovers

• ZSKs roll by pre-publication every 180 days.
• TLD KSKs roll yearly by double-DS.
• The root KSK rolls every two years under the timers of RFC 5011.
• 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.

Child zones and DS records

A registrant publishes DS records for a signed child zone through the portal or the API. DS records are accepted for algorithms 8, 13, 14, 15 and 16 and digest types 2 and 4. A DS record is published only where the child zone's keys match it, because a DS record that matches no key makes the name fail validation for everyone. Removing a DS record works the same way and takes effect with the next zone version.

Controls around the root

• Four eyes. Every root zone change and every key event needs a second authorised person, who confirms with a hardware-bound passkey at the time of approval. Nobody approves their own change. While only one person holds a root role, that person may approve alone after a 24-hour wait, and every such approval is flagged permanently in the audit record and in the transparency log. That exception ends for good once a second root person exists.
• Delegation order. A TLD reaches the root only after its keys exist, its zone is built and every server that is to serve it answers correctly.
• Records. Every root change and every key event has an audit record and an entry in the public transparency log, whose checkpoints are signed with Ed25519 inside the key store and cosigned by an independent witness.

Compromise and recovery

If a key may be compromised, Tier 0 acts at once under its emergency procedure, which can only suspend or tighten, and rolls the key by the emergency rollover. The event, and what was done about it, is published in the transparency log. How to report a suspected compromise is in the security and disclosure policy.

Review and change

Tier 0 reviews these practices every year. This statement changes only after public comment, and the version in force is the one in the archive with the latest date.

It gives no warranty and creates no service level. Liability is as the general terms of service set it out.