Skip to content

Allow patterns with a catalog-producer-zone option to be included from zone clauses in the config file #451

@gjherbiet

Description

@gjherbiet

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions