dynamic update nad easier config

Tue Nov 28 11:23:10 UTC 2006

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 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.

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 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.
> 

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFbBwdkDLqNwOhpPgRAuOfAJ9fmKg7t5heaoGqYASkavMxuGf+dACfdgf4
39svmycEG8EM7/FZdGvB5MQ=
=7TMu
-----END PGP SIGNATURE-----