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:

$ cascade tsig add --name sec1_key --alg hmac-sha256 --secret "...=="

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.accept-xfr-from`

Integrating with NSD

Suggested reading

Using NSD as a primary to Cascade

Using NSD as a secondary to Cascade