Hi,
for a large number of zones, it is very uncomfortable to specify
provide-xfr/request-xfr/notify/allow-notify settings individually for
every zone. I would like to add these options to the server section of
the config. Such global ACL settings would then be appended to the ACLs
of every zone.
Example:
server:
provide-xfr: 10.1.2.3 NOKEY
provide-xfr: 10.1.2.4 NOKEY
....
zone:
name: "domain1.com"
zone:
name: "domain2.com"
provide-xfr: 10.6.6.6 NOKEY
...would be equivalent to:
zone:
name: "domain1.com"
provide-xfr: 10.1.2.3 NOKEY
provide-xfr: 10.1.2.4 NOKEY
zone:
name: "domain1.com"
provide-xfr: 10.6.6.6 NOKEY
provide-xfr: 10.1.2.3 NOKEY
provide-xfr: 10.1.2.4 NOKEY
I already have a sketch of the patch, but I want to ask two questions first:
(a) Are you (NSD maintainers and users) interested in this patch? I hope
so 
(b) There are two ways it can be implemented. I can either make private
copies of the global ACL entries for every zone, or share the global ACL
entries across all zones. I prefer the second way but my question to NSD
maintainers is: is it safe/reasonable to share the acl_options_t objects
across multiple ACLs? ACL objects are organized in single-linked lists,
so it is very easy to append a shared list to the end of them. But it
requires the lists to be accessed in a read-only manner everywhere!! Is
that true? I've found no code that writes to the ACLs yet but I can be
wrong.
I welcome any comments.
Martin
a message of 56 lines which said:
I already have a sketch of the patch, but I want to ask two questions first:
A warning: I feel the need, too but, before asking for a change in nsd
(which is supposed to be a small and lean server), I suggest to
consider producing the nsd.conf automatically from a program, either a
PPR script or a preprocessor like cpp or m4, thus freeing nsd from
this task.
Stephane Bortzmeyer wrote:
a message of 56 lines which said:
I already have a sketch of the patch, but I want to ask two questions first:
A warning: I feel the need, too but, before asking for a change in nsd
(which is supposed to be a small and lean server), I suggest to
consider producing the nsd.conf automatically from a program, either a
PPR script or a preprocessor like cpp or m4, thus freeing nsd from
this task.
Stephane, we generate the config automatically, as everybody who has
more than twenty zones But the config looks ... ehm ... quite ugly.
My natural feeling is that if something must be repeated 65k+ times,
something is wrong. Or at least it deserves few minutes of thinking
about pros and cons... The solution seems quite simple and
straightforward to me, but NSD maintainers will have the final word.
Martin
Hello,
attached I send a patch that adds support for global zone options. With
this patch, all zone options can also be specified globally in "server"
section of nsd.conf. These zone options are then automatically applied
to every zone. For value-like options (allow-xfr-fallback,
notify-retry), the global setting can be overridden in a "zone" section.
ACL-like global settings are simply added to the end of lists specified
in "zone" sections.
We use the patch on our production servers more than two months without
any problems. However, we use only few options and I'm too busy to
prepare test environments for all other possible cases. So, most of the
patch was tested only by inspecting "nsd-checkconf -v".
Pros:
- cleaner configuration for uniform setups with thousands of zones
- faster parsing of (smaller) nsd.conf, more than 70% in our case
Cons:
- goes against "No end-user friendliness" non-requirement of NSD 
Any comments (and testers) are welcomed.
Best regards,
Martin
(attachments)
default-zone-options.patch (9.81 KB)