Integrating with NSD

Name Server Daemon (NSD) by NLnet Labs is an authoritative DNS name server.

—https://nsd.docs.nlnetlabs.nl/

Using NSD as a primary to Cascade

To use NSD as an upstream name server of Cascade you must add a zone to NSD that refers to Cascade as a secondary name server. If enabled in NSD, NSD will send an RFC 1996 DNS NOTIFY message to Cascade notifying it when changes to the zone occur.

The NOTIFY message will trigger Cascade to perform an AXFR transfer to fetch the full zone content from NSD, or, if already fetched and IXFR is enabled in NSD, an IXFR transfer will be performed to fetch just the incremental changes since the last fetch.

If NOTIFY is NOT enabled in NSD, Cascade will monitor NSD for a newer version of the zone by periodically sending SOA queries according to the number of seconds defined by the REFRESH field of the zone apex SOA record.

Optionally NSD and Cascade can be configured with the same TSIG key to authenticate the NOTIFY and XFR messages.

The NSD settings relevant here are:

For example the following NSD configuration file fragment adds an example.com zone to NSD that is to be served as input to a Cascade daemon running on host 192.168.0.2 listening on the default port 4542:

zone:
  name: example.com
  zonefile: /etc/nsd/example.com.zone
  notify: 192.168.0.2@4542 NOKEY
  provide-xfr: 192.168.0.2 NOKEY
  store-ixfr: yes
  create-ixfr: yes

A TSIG key can be used to authenticate the NOTIFY and XFR communications. For example:

key:
  name: "sec1_key"
  algorithm: hmac-sha256
  secret: "..."

zone:
   name: example.com
   zonefile: /etc/nsd/example.com.zone
   notify: 192.168.0.2@4542 sec1_key
   provide-xfr: 192.168.0.2 sec1_key
   store-ixfr: yes
   create-ixfr: yes

See https://nsd.docs.nlnetlabs.nl/en/latest/running/using-tsig.html for more information.

Tip

Remember to reload the NSD configuration or restart NSD so that changes to the configuration take effect.

To add the TSIG key to Cascade use cascade tsig add.

First create a file containing only the TSIG key. In this case the nsd file format is used.

key:
  name: "sec1_key"
  algorithm: hmac-sha256
  secret: "..."

Then pass the filename to the cascade tsig add command. See the commands documentation for all available formats, nsd is the default format.

$ cascade tsig add tsig-key.yaml

To use the new TSIG key it must be specified when adding a zone to Cascade. Assuming that NSD is running on host 192.168.0.1 on port 53, the following command instructs Cascade to add the example.com zone sourced from the NSD server using the sec1_key TSIG key to authenticate with NSD:

$ cascade zone add --source "192.168.0.1^sec1_key" --policy default example.com

Using NSD as a secondary to Cascade

The NSD settings relevant here are:

To allow NSD to receive and respond to NOTIFY messages from Cascade, and to instruct NSD to fetch zone updates via zone transfer from Cascade, these settings need to be added to the zone configuration.

For example the following configures NSD for an upstream Cascade server running at 192.168.0.2 listening on the default port 4542:

zone:
  name: example.com
  allow-notify: 192.168.0.2
  request-xfr: 192.168.0.2@4542

To authenticate zone transfer related messages using TSIG you must first have added the key to both Cascade and NSD using the same cascade tsig add command and key: block as shown above.

To instruct Cascade to use TSIG when communicating with a downstream nameserver such as NSD you must set the required policy settings and reload the policy. The relevant policy settings in Cascade are:

server.outbound.send-notify-to
server.outbound.provide-xfr-to

Integrating with NSD

Suggested reading

Using NSD as a primary to Cascade

Using NSD as a secondary to Cascade