TSIG support

[bal-e]

While Cascade was initially intended to support TSIG from the get-go, this feature got lost during the alpha development process. A lot of the infrastructure necessary for it is already in the codebase, it just has to be tied back together. A major concern is going to be the zone loader -- with the current architecture, it's hard to going to be difficult to integrate the new TSIG key store with it. We may have to wait until a new zone loader (#15) is available. TSIG also concerns outgoing zone transfers, for which some form of access control policy needs to be designed.

[Philip-NLnetLabs]

Note that keyset also need TSIG support (for key roll automation). It is best if keyset can access the TSIG secret store in Cascade to avoid duplicating secrets.

[bal-e]

I agree, but that's going to be tricky to implement. The ideal case would be that keyset becomes a library and can directly access Cascade's in-memory TSIG key store. For now, the key manager could verify that the TSIG key store has been synchronized to disk before invoking keyset.

[ximon18]

Currently existing TSIG support in main:

• TSIG key specification as JSON support exists in main (see https://github.com/NLnetLabs/cascade/blob/main/src/tsig/mod.rs).
• main.rs loads the store from the configured tsig-store-path resulting in an in-memory mapping of TSIG key names to key algorithm and key data bytes.
• src/loader/server.rs configures the transport to use a given TSIG key when doing AXFR/IXFR, and the key name to use is taken from zone state.
• src/center contains an old_tsig_key_store member field which uses a TSIG key store based on domain types, and this key store is made available in src/units/zone_server.rs to XfrMiddlewareSvc and TsigMiddlewareSvc.

What is missing regarding TSIG support in main:

• There is no way to specify which TSIG key should be used for a given upstream zone source. The key name to use is part of the zone source BUT crates/api/src/lib.rs defines impl From<&str> for ZoneSource which sets tsig_key: None and the CLI help string for zone add documents help "--source " as "The zone source can be an IP address (with or without port, defaults to port 53) or a file path", i.e. no mention of a TSIG key.
• There is no way to add a key to the key store, e.g. no way to specify it via policy or config nor a CLI command, nor is a sample empty file with commented out sample values for example written to tsig-store-path so the user can't manually construct it, and old_tsig_key_store is never populated, src/main.rs sets it to Default::default() and it is not interacted with anywhere after this point of initial creation.
• There is no way to specify which key from old_tsig_key_store, were it to be populated, should be used with downstream secondary XFR clients. The closest we have is server.outbound.send-notify-to in etc/policy.template.toml.
• Any desired support for / integration with dnst keyset to tell it which TSIG key name relates to a given zone.
• Any desired support for / integration with dnst keyset to allow it to access the TSIG key algorithm and key data bytes from Cascade.

[ximon18]

Regarding #301 (comment) and keyset becoming a library, current planning is for TSIG support to be added for Cascade 0.1.0-rc1 but creation of a dnst keyset library is not expected to be available at that time, thus any work done for 0.1.0-rc1 should use dnst keyset as is today, a separate binary invoked by Cascade as needed.

[Philip-NLnetLabs]

Keyset has an issue for adding TSIG support: NLnetLabs/dnst#156

[ximon18]

PR #529 removes the old TSIG key store.

TSIG key persistence in-memory and on-disk are already in main. Things still missing include (assuming a particular design):

• cascade CLI subcommands to manage TSIG keys.
• Extensions to policy file format to support specifying which TSIG keys to use similar to NSD.
  • notify: <ip-address> <key-name | NOKEY>: We already have server.outbound.send-notify-to = ["IP[:PORT]", ...] but this lacks a means of specifying the optional TSIG key to use per destination. Actually the current impl uses DeserializeFromStr to convert "IP:[PORT]" to SimpleNameserverCommsSpec but both NameserverCommsSpec and ComplexNameserverCommsSpec support Deserialize. If these CommsSpec enum variant inner types were extended with tsig_key: Option<String> a user could use rich TOML syntax, instead of a string, to supply the TSIG key name. We could even extend the FromStr impl to support the NSD string format.
  • provide-xfr: <ip-spec> <key-name | NOKEY | BLOCKED> [tls-auth-name]: We lack an equivalent policy element for this. We could add a server.outbound.allow-xfr-to policy element with the same value format as send-notify-to.
  • allow-notify: <ip-spec> <key-name | NOKEY | BLOCKED>: We lack an equivalent policy element for this. We could add a server.inbound section in policy with an allow-notify-from policy element with the same value format as send-notify-to.
  • request-xfr: [AXFR|UDP] <ip-address> <key-name | NOKEY> [tls-auth-name]: We lack an equivalent policy element for this. We could add a server.inbound section in policy with an request-xfr-from policy element with the same value format as send-notify-to.

We also need a way to tell dnst keyset which TSIG keys to use and where to find the secrets. We could add:

• dnst keyset set tsig-store-path <path> to specify the TSIG secret storage location and pass it the Cacsade tsig-store-path value.
• dnst keyset set publication-ns <xxx> where xxx would tell dnst keyset where it can XFR the signed zone from and optionally which TSIG key to use when doing XFR. @Philip-NLnetLabs has a preference for a single string format that encodes all of the information needed to XFR with a single nameserver (IP/hostname, port, TSIG key name, and later possibly TLS related configuration too) without any whitespace (so not the NSD string format), of which multiple may need to be provided. *1

dnst keyset uses the given nameservers to XFR the signed zone. If none are provided then as now dnst keyset would fall back to querying the nameserver at the zone SOA mname, without TSIG.

Internally:

• In the zone server code the domain crate TSIG middleware would need to take a new type that implements the KeyStore trait and provides the necessary key information by querying the TSIG key store in Center.
• Center has a LoaderState per Zone which can identify the TSIG key to use, but no equivalent state exists for saying which TSIG key should be required to be used by a downstream nameserver that sends an XFR request to Cascade.
• http_server::get_zone_status() hard-codes the TSIG key name it reports to None, if the TSIG key name should be reported via cascade zone status this would need wiring up with the actual TSIG key name.
• Center::add_zone() ignores the given TSIG key name, it would need to use it.

*1: @Philip-NLnetLabs suggested that it might also be possible to instruct dnst keyset to query the Cascade publication server for the signed zone if no other XFR nameserver is provided, but this would prevent dnst keyset from falling back to the SOA mname. It may also be desirable to have an explicit key_manager.nameservers section or similar which configures dnst keyset explicitly with nameservers to try XFR with and optional TSIG keys to use.