Architecture

The Pipeline

The Cascade pipeline runs as a single binary and no additional database software is required. Zone changes cascade through several stages, letting you review and approve at each step:

Schematic view of of the Cascade pipeline

A schematic view of of the Cascade pipeline with the verification stages.

Flexible Signing

Cascade does not require a Hardware security module (HSM) to operate. Cascade is able to use OpenSSL and ring software cryptography to generate signing keys and to cryptographically sign DNS RRset data, storing the generated keys in on-disk files.

For operators wishing to use an HSM, Cascade can connect directly to KMIP compatible HSMs, or to PKCS#11 compatible HSMs via our cascade-hsm-bridge daemon, which is installed automatically as part of our Cascade packages.

Hint

Separating the main Cascade and cascade-hsm-bridge daemons avoids running untrusted third-party code inside the main Cascade process. This eliminates a source of potential instability and unpredictable behaviour, as well as limiting resource usage.

Bespoke Zone Verification

Using Review Hooks, Cascade supports optional verification of your zone data at two critical stages: verification of the unsigned zone, and verification of the signed zone. In both cases verification consists of executing an operator supplied script or application which can verify the zone using whatever mechanisms are required to satisfy your policy.

Verification of the zone can be done by retrieving it using the zone transfer protocol from dedicated “review” nameservers within Cascade, either verifying the zone directly or writing the zone to disk for verification by tools that only support working with files.

On completion of the verification process, approval or rejection is signalled back to Cascade via the script exit code.

Rejecting a zone “soft” halts the Cascade pipeline for the zone, preventing it from cascading further down the pipeline, but allowing a newer version of the zone to be completely processed (unless that too should fail verification).

Serious errors in the pipeline may result in a “hard” halt for the pipeline of a zone, preventing any further processing of that zone for the current and future versions until an operator manually resumes the pipeline.

Managing State

Cascade stores its state in on-disk files in JSON format, by default at various locations under a single parent directory. No additional database software is required. As such, state is human-readable and easily backed up. Note however, that state files are not intended to be modified by the user.

Some configuration is done via the Cascade command line interface (CLI), such as adding zones and HSMs. Other configuration is done by editing policy and application configuration files and instructing the Cascade daemon via the CLI to reload them.

The Cascade daemon updates its on-disk state files periodically, and when signalled to stop, reloading them on next start.

As Cascade outsources PKCS#11 support to cascade-hsm-bridge, it does not require access to related configuration files or other vendor specific module dependencies.

Robustness

Cascade is written in the Rust programming language making it significantly less likely to crash or suffer from memory safety issues, and at the same time making it easier to leverage the higher core count of modern computers via Rust’s “fearless concurrency” when needed.