Before You Start

Placement

Cascade is what is known as a “hidden signer”. It is meant to run as a dedicated server with restricted access that takes local zones or zones received from an upstream primary nameserver, signs those zones and makes the results available to downstream, Internet facing secondary nameservers.

Warning

Do not run Cascade as an Internet facing service, as it is designed to answer a limited subset of the DNS protocol that a full authoritative nameserver must support.

One possible authoritative server that could be used up and downstream of Cascade is NSD, but any solution can be used provided that it supports transferring zones via XFR zone transfers to and from Cascade.

Intended Audience

Cascade is currently targeted for use by TLD operators, but will evolve over time to cater to other audiences. As a successor to OpenDNSSEC, Cascade is clearly intended to offer continuity and a migration path for current users, but Cascade will also offer superior performance, flexibility and user experience.

Important

Cascade does not require the use of a Hardware Security Module (HSM). It can make use of on-disk key files and, if desired, use PKCS#11 and KMIP compatible HSMs.

The Moving Parts

Cascade consists of three main components and an optional fourth:

  • The cascaded daemon for receiving zone data, signing it, and serving the signed result. It supports Review Hooks during the processing pipeline, allowing you to use your preferred solutions to automate verification of the unsigned and signed zone, before publishing it.

  • The cascade command line interface (CLI) for controlling and interacting with the cascaded daemon.

  • A tool called dnst keyset, which is responsible for the key management of Cascade, including automation of key rolls. It is invoked as needed by the cascaded daemon.

  • The optional cascade-hsm-bridge daemon, which is only required when using a PKCS#11 compatible HSM.

Supported Inputs/Outputs

Cascade supports:

  • Receiving zone data via AXFR or IXFR zone transfers, or from on-disk files.

  • Publishing data via AXFR.

Publishing data via IXFR is coming soon. On-disk files, while not supported directly, could be achieved by XFR of the signed zone to an on-disk file.

Important

Fully automatic key rolls are enabled by default. For this to work, Cascade requires access to all nameservers of the zone and the parent zone. If this is not available, make sure to disable automatic key rolls.

System Requirements

Cascade is able to run with fairly limited CPU and memory. Exact figures are not yet available, but in principle more CPU cores allow for more parallel operations and more memory makes it possible to load and sign larger zones.

Hint

During testing, Cascade currently uses using about 30GiB of RAM when signing a 1GiB zone file with about 25 million resource records and adding roughly 10 million records while signing.

Right now, signing speed is not likely to be a bottleneck for most use cases, but there are many speed improvements in the pipeline, especially when using an HSM.

Cascade can currently be used by operators with at most a few small to medium size zones. As development progresses, it will also support operators with very large zones or operators with many zones.

Cascade is not yet intended for operation as a clustered deployment.