Catalog zones

Since version 4.9.0, NSD has support for Catalog zones version “2” as specified in RFC 9432. NSD can be a producer of catalog zones as well as a catalog zone consumer, but it is limited to process only a single consumer zone.

Setting up NSD as a catalog consumer

NSD will process a zone as a catalog consumer zone if the zone has the catalog: consumer option set. An example catalog consumer configuration could look like this:

pattern:
        name: "member-zone-config"
        request-xfr: 198.51.100.1 NOKEY
        allow-notify: 198.51.100.1 NOKEY

key:
        name: tsig-key.name
        algorithm: hmac-sha256
        secret: "SXMgdGhpcyBhIHNlY3JldCBvciBqdXN0IHRleHQ/Pz8="

tls-auth:
        name: primary.example
        auth-domain-name: primary.example

zone:
        name: "catalog1.invalid"
        catalog: consumer
        catalog-member-pattern: "member-zone-config"

        request-xfr: 192.0.2.1@853 tsig-key.name primary.example
        allow-notify: 192.0.2.1 tsig-key.name

        allow-query: BLOCKED

The consumer zone catalog1.invalid is configured in the example as a secondary zone. It transfers the catalog from the primary at 192.0.2.1. The transfer is mutually authenticated using TSIG.

The content of catalog zones are only relevant for the name servers handling those zones. They contain a list of zones that are served from the name servers and it is likely undesirable to expose that content. We have protected the zone against queries from third-parties by setting the allow-query: BLOCKED option. The transfer is protected against on-path eavesdroppers by doing it over authenticated TLS.

Note

Using privacy preserving option is RECOMMENDED for catalog zones (See RFC 9432 Sections 6 and 7).

Note

Catalog consumer zones do not need to be secondary, they may also process just zone files.

NSD supports the group property. Member zones from the catalog will be added with the pattern given by the group property of that member. If a member does not have a group property or its value is invalid or doesn’t match a pattern, the pattern given by the catalog-member-pattern: option will be used.

Using nsd-control to get catalog zone status

The status of catalog zones and catalog member zones can be consulted with nsd-control zonestatus.

$ nsd-control zonestatus

zone:   catalog1.invalid
        catalog: consumer (serial: 1708341939, # members: 2)
        state: ok
        served-serial: "1708341939 since 2024-02-19T15:19:44"
        commit-serial: "1708341939 since 2024-02-19T15:19:44"
        wait: "3461 sec between attempts"

zone:   example.net
        pattern: member-zone-config
        catalog-member-id: a5b75379.zones.catalog1.invalid.
        state: ok
        served-serial: "2024013019 since 2024-02-19T14:25:43"
        commit-serial: "2024013019 since 2024-02-19T14:25:43"
        wait: "7195 sec between attempts"

zone:   example.org
        pattern: group1
        catalog-member-id: 96143f7d.zones.catalog1.invalid.
        state: ok
        served-serial: "2024013016 since 2024-02-19T14:18:10"
        commit-serial: "2024013016 since 2024-02-19T14:18:10"
        wait: "6544 sec between attempts"

The first zone: entry in the example output above shows the status our configured consumer zone catalog1.invalid. Besides its role (consumer or producer) it show the last SOA serial number that was successfully processed, and the number of member zones that were added by processing the consumer zone.

Note

If the catalog zone has become invalid and isn’t processed anymore, nsd-control zonestatus will show the reason why.

nsd-control zonestatus will also show the catalog-member-id of catalog member zones. In the example output of nsd-control zonestatus above we can see that example.net and example.org are member zones from catalog1.invalid. Apparently the example.net member did not have a valid group property, because it has been added with the default catalog-member-pattern: member-zone-config.

Setting up NSD as a catalog producer

A catalog producer zone can be configured in NSD by setting the catalog: producer option. Unlike consumer zones, multiple producer zones may be configured. NSD creates the content of producer zones and therefore producer zones cannot be configured as secondary zones. Likewise, zonefile: options are only used to write the zone, never to read it.

An example catalog producer configuration could look like this:

server:
        interface: 192.0.2.1@853
        tls-port: 853
        tls-service-key: "primary.example.key.pem"
        tls-service-pem: "primary.example.cert.pem"

pattern:
        name: "group0"
        catalog-producer-zone: "catalog1.invalid"

pattern:
        name: "group1"
        catalog-producer-zone: "catalog1.invalid"

key:
        name: tsig-key.name
        algorithm: hmac-sha256
        secret: "SXMgdGhpcyBhIHNlY3JldCBvciBqdXN0IHRleHQ/Pz8="

zone:
        name: "catalog1.invalid"
        catalog: producer

        store-ixfr: yes
        provide-xfr: 203.0.113.1@853 tsig-key.name
        notify: 203.0.113.1 tsig-key.name

        allow-query: BLOCKED

The producer zone is configured as a primary and allows (in our example) transfer of the zone over TLS only. Also, just like with the consumer zone configuration example above, queries to this zone are BLOCKED to comply with RECOMMENDED privacy and security considerations. We also recommend - for primary zones in general - to serve incremental transfers (configured with store-ixfr: yes).

Zones can be added as member zones, by adding them to NSD with nsd-control addzone with a pattern that has the name of the producer zone as value of a catalog-producer-zone: option. In the example configuration above, patterns "group0" and "group1" both have that option.

Here is an example on how to do that:

$ nsd-control addzone example.net group0
ok
$ nsd-control addzone example.org group1
ok

Like with consumer zones and consumer member zones, nsd-control zonestatus can be used to check on the status of catalog producer zones and its members:

$ nsd-control zonestatus

zone:   catalog1.invalid
        catalog: producer (serial: 1708341939, # members: 2)
        state: primary

zone:   example.net
        pattern: group0
        catalog-member-id: a5b75379.zones.catalog1.invalid.
        state: primary

zone:   example.org
        pattern: group1
        catalog-member-id: 96143f7d.zones.catalog1.invalid.
        state: primary

Like with other zones added with nsd-control addzone, the member zones are persistently added to the zone list file (see the zonelistfile: configure option). The content of the catalog producer zone is not persistent and will be reconstructed from the member zone entries in the zone list file.

$ cat /var/db/nsd/zone.list
# NSD zone list
# name pattern
cat example.net group0 a5b75379
cat example.org group1 96143f7d