-
-
Notifications
You must be signed in to change notification settings - Fork 115
Description
When NSD is used as a distribution server, it may act as both a secondary server (receiving zones listed in a consumer catalog zone from an upstream server) and a primary server (transferring zone listed in a producer catalog zone to a downstream server), i.e.
XFR XFR
upstream -----> distribution -----> downstream
This could be theoretically achieved with the following configuration:
pattern:
name: "distribution"
catalog-producer-zone: "downstream-catalog.invalid"
# Allow notify and request XFR to upstream server
allow-notify: ...
request-xfr: ...
# Notify and provide XFR to downstream server
notify: ...
provide-xfr: ...
zone:
name: "upstream-catalog.invalid"
catalog: consumer
catalog-member-pattern: "distribution"
allow-query: BLOCKED
# Allow notify and request XFR to upstream server
allow-notify: ...
request-xfr: ...
zone:
name: "downstream-catalog.invalid"
catalog: "producer"
allow-query: BLOCKED
# Notify and provide XFR to downstream server
notify: ...
provide-xfr: ...Unfortunately, this configuration leads to the following error:
error: patterns with an catalog-producer-zone option are to be used with "nsd-control addzone" only and cannot be included from zone clauses in the config file
In scenarios where the "distribution" pattern only contains zones from the upstream server, this can be worked around by allowing transfer of "upstream-catalog.invalid" to the downstream server and also using this zone as a catalog consumer there.
However, the distribution server may as well be a primary for a static set of zones (or receive them from an alternative upstream), eg:
pattern:
name: "distribution"
catalog-producer-zone: "downstream-catalog.invalid"
# Notify and provide XFR to downstream server
notify: ...
provide-xfr: ...
pattern: "primary"
include-pattern: "distribution"
zonefile: %s
pattern: "upstream"
include-pattern: "distribution"
# Allow notify and request XFR to upstream server
allow-notify: ...
request-xfr: ...
pattern: "alternative-upstream"
include-pattern: "distribution"
# Allow notify and request XFR to alternative upstream server
allow-notify: ...
request-xfr: ...
zone:
name: "upstream-catalog.invalid"
catalog: consumer
catalog-member-pattern: "upstream"
allow-query: BLOCKED
# Allow notify and request XFR to upstream server
allow-notify: ...
request-xfr: ...
zone:
name: "downstream-catalog.invalid"
catalog: "producer"
allow-query: BLOCKED
# Notify and provide XFR to downstream server
notify: ...
provide-xfr: ...
zone:
name: "example.com"
include-pattern: "primary"
zone:
name: "example.net"
include-pattern: "alternative-upstream"This use case would require to remove zones declarations for example.com and example.net from the configuration file (as for all zones with the "primary" and "alternative-upstream" patterns) and to execute, after each restart of NSD:
nsd-control addzone example.com primary
nsd-control addzone example.net alternative-upstream
which is inelegant and not very practical as it defeats the purpose of configuration files.