hi,
is there any plan to include support for dynamic update for zones is
nsd? another nice thing would be if it wouldn't need to config all slave
servers, but by default from the zone file get the NS records and assume
all is slave (if otherwise not stated). this can help to configure
master zones what's more lead to a less error in the config files.
yours.
Farkas Levente wrote:
hi,
is there any plan to include support for dynamic update for zones is
nsd? another nice thing would be if it wouldn't need to config all slave
servers, but by default from the zone file get the NS records and assume
all is slave (if otherwise not stated). this can help to configure
master zones what's more lead to a less error in the config files.
yours.
Hi Farkas,
Dynamic update support in NSD is not planned.
Reading the zone file NS records to get config. This can be a nice idea,
if it is what you need. Of course only for master servers, since a slave
may not have (an up to date) zone file.
Right now NSD does not send NOTIFY or provide AXFR unless you config it
so. This config may not be what people need, their setup may be
different, TSIG usage etc. And it introduces a lot of featurism and
config stuff that is not needed now. (And I personally do not like
making a DNS server dependent on DNS query results to resolve the NS names).
A script that generates nsd.conf using NS records from the zone files
could work better. Much simpler and easier to configure when you run
that script. It keeps the features out of the NSD server, which is good.
I do not plan to write one though, I do not know your setup 
Best regards,
Wouter
Wouter Wijngaards wrote:
Hi Farkas,
Dynamic update support in NSD is not planned.
this has any reason or just a simple not.
Reading the zone file NS records to get config. This can be a nice idea,
if it is what you need. Of course only for master servers, since a slave
may not have (an up to date) zone file.
just for master zones.
Right now NSD does not send NOTIFY or provide AXFR unless you config it
so. This config may not be what people need, their setup may be
different, TSIG usage etc. And it introduces a lot of featurism and
this is a good feature, but IMHO the most common use more then 90% is to
send notify to those slaves which has an NS record in it's zone file.
config stuff that is not needed now. (And I personally do not like
making a DNS server dependent on DNS query results to resolve the NS names).
i can be a preprocessor or build into nsdc.
like something:
zone:
name: "example.com"
zonefile: "example.com.zone"
notify-provide-xfr-ns: yes NOKEY
and in this case while parsing the zone file get the NS record, exclude
the master's and add all others to notify and provide-xfr list with the
given key. this result a much cleaner config and lead to less error eg
one someone modify the master zone file that shouldn't have to modify
the nsd.conf etc.
if i'd like to go further the same theory can be used for slave zones
ie. suppose primary master is in the zones SOA record so it can be get
from there, but this really requires zone lookup etc. which is more then
just zone file parsing. but IMHO also more then 90% of the case use this
setup.
A script that generates nsd.conf using NS records from the zone files
could work better. Much simpler and easier to configure when you run
that script. It keeps the features out of the NSD server, which is good.
I do not plan to write one though, I do not know your setup
nsd put all config data into nsd.db? if yes, then it shouldn't have to
generate new conf, but put these data into nsd.db and imho it's not
setup dependent. or keep slave in memory, then it can be also used and
don't need to generate conf file. or does it read conf each time when it
need to send notify?
just my 2c.
Farkas Levente wrote:
Wouter Wijngaards wrote:
Hi Farkas,
Dynamic update support in NSD is not planned.
this has any reason or just a simple not.
Dynamic update is too complex, especially considering DNSSEC to put into
a light weight authoritative only server. We are considering dynamic
update support using some tool external to NSD (outside the server itself).
Reading the zone file NS records to get config. This can be a nice idea,
if it is what you need. Of course only for master servers, since a slave
may not have (an up to date) zone file.just for master zones.
Yes
Right now NSD does not send NOTIFY or provide AXFR unless you config it
so. This config may not be what people need, their setup may be
different, TSIG usage etc. And it introduces a lot of featurism andthis is a good feature, but IMHO the most common use more then 90% is to
send notify to those slaves which has an NS record in it's zone file.
I do not wish to send NOTIFY to a server that does not expect it. Also I
am not sure 90% of people have such a setup.
config stuff that is not needed now. (And I personally do not like
making a DNS server dependent on DNS query results to resolve the NS names).i can be a preprocessor or build into nsdc.
like something:
zone:
name: "example.com"
zonefile: "example.com.zone"
notify-provide-xfr-ns: yes NOKEY
and in this case while parsing the zone file get the NS record, exclude
the master's and add all others to notify and provide-xfr list with the
given key. this result a much cleaner config and lead to less error eg
one someone modify the master zone file that shouldn't have to modify
the nsd.conf etc.
Yes that could be possible. But it is nasty to get that zone data in
places. It won't get updated when you update the zone NS records for
example. It is the road of creeping featurism to put this inside the
server (and that is explicitly a non-goal for NSD).
That said, a script that reads a nsd.conf.extended file with
notify-provide-xfr-ns: statements and zone files and creates a nsd.conf
with the notify: and provide-xfr: statements you need is clean; outside
of the server and can then be used by (the % of) people that need it.
You would need to run the script before you start nsd. NSD needs to
restart (stop and start again) to re-read the config, and then you can
also re-run the script if your zone is updated.
if i'd like to go further the same theory can be used for slave zones
ie. suppose primary master is in the zones SOA record so it can be get
from there, but this really requires zone lookup etc. which is more then
just zone file parsing. but IMHO also more then 90% of the case use this
setup.
Possible, but same reasoning: a script to process your config file.
Keeps the feature outside the NSD server. That script could become very
popular then, if everyone uses it.
A script that generates nsd.conf using NS records from the zone files
could work better. Much simpler and easier to configure when you run
that script. It keeps the features out of the NSD server, which is good.
I do not plan to write one though, I do not know your setupnsd put all config data into nsd.db? if yes, then it shouldn't have to
generate new conf, but put these data into nsd.db and imho it's not
setup dependent. or keep slave in memory, then it can be also used and
don't need to generate conf file. or does it read conf each time when it
need to send notify?
just my 2c.
No, NSD reads the config file on startup. It is not in the db; but the
db must not contain zones that have no config.
Thanks for your suggestions, I appreciate knowing what troubles users
Best regards,
Wouter
Wouter Wijngaards wrote:
Right now NSD does not send NOTIFY or provide AXFR unless you config it
so. This config may not be what people need, their setup may be
different, TSIG usage etc. And it introduces a lot of featurism andthis is a good feature, but IMHO the most common use more then 90% is to
send notify to those slaves which has an NS record in it's zone file.I do not wish to send NOTIFY to a server that does not expect it. Also I
am not sure 90% of people have such a setup.
do you think this is not the most common way that there is one primary
master and all other NS are slaves and master send notify to all slaves???
Yes that could be possible. But it is nasty to get that zone data in
places. It won't get updated when you update the zone NS records for
example. It is the road of creeping featurism to put this inside the
server (and that is explicitly a non-goal for NSD).
it won't updated in this way either! you should have to recompile your
zone and if the compiler do the NS extraction that it can happened at
the same time. or i don't understand your argument. do nsd periodically
read zone files or?
That said, a script that reads a nsd.conf.extended file with
notify-provide-xfr-ns: statements and zone files and creates a nsd.conf
with the notify: and provide-xfr: statements you need is clean; outside
of the server and can then be used by (the % of) people that need it.You would need to run the script before you start nsd. NSD needs to
restart (stop and start again) to re-read the config, and then you can
also re-run the script if your zone is updated.
the same is true now you need to recompile zone file too what's the
difference nsd don't have to restart just reload.
shouldn't all slaves be warned to receive spurious NOTIFYs per RFC 1996, 4.2?
-Peter
Peter Koch wrote:
send notify to those slaves which has an NS record in it's zone file.
I do not wish to send NOTIFY to a server that does not expect it. Also I
am not sure 90% of people have such a setup.shouldn't all slaves be warned to receive spurious NOTIFYs per RFC 1996, 4.2?
Yes. However, I want to reduce the amount of notifys flying around the
internet. Instead of a default to send out to all those servers, NSD has
the default to remain silent.
NSD implements the rule that it tries to axfr from the master that sent
the notify (if that host is also listed as request-xfr: in config). So
you can send notifies from other slaves, but it is more useful to
receive notifies from the masters.
So; this could be a useful feature.
I would prefer to implement this as config file (macro-style) processing.
The alternative of processing during another step complicates it (I
mean: it requires more code changes to the server, which is
undesirable). If the NS set is updated using a database-reload or
AXFR/IXFR: does this also immediately change the derived config? NSD is
currently not capable of adjusting its config on-the-fly. This is a
security feature, since chroot and username settings are in there.
Changing NSD to change config on the fly would require significant effort.
Preprocessing the config file makes it very clear that no updates are
going to happen later on.
So I am not sure how best to go about this.
Best regards,
Wouter
Hi,
After some discussion here, the conclusion is that notify-from-NS-set is
a hotly wanted feature. I'll get to it and get it working.
I'll get to it after I finish bugfixes for the next release and the
source-address selection feature.
Some technical details on it. To keep the feature out of the server
itself, it will be implemented similar to a patch/script on the config.
Probably when you run zonec. This assumes a slowly changing NS set. To
get NSD to re-read the config file you must restart, not reload, the
daemon.
This means that if you run nsdc patch daily (from a cron job) this will
rerun zonec, and with a restart instead of a reload there, it will
regrab the NS set every day.
Faster changing NS sets would require some level of support inside the
server daemon.
Best regards,
Wouter