API

[katzeprior]

Would love to be able to control zones like you can in via some sort of (rest) api, nsd-control already does this via an undocumented "protocol". Powerdns has this build in and someone made powerdns-admin which is a powerful tool. If NSD gets a feature where I can edit the zones via a custom documented protocol or a restful API via http requests I would love to build a control dashboard around it to make it easier for people to have a master-slave setup and change dns records via an API, would also make it possible for wildcard certs via lets-encrypt.

afaik: bind9 achieves this by having the zones in a database so a third party can change the records in the database.

its bedtime so I hope this issue is readable

[katzeprior]

Maybe a better question is, what is the best way to make NSD add zones and records from my own program

[k0ekk0ek]

Hi @katzeprior, sorry, I meant to get back to you. Sounds like a nice project!

Can't speak for other maintainers, but I feel/think providing a REST api is out-of-scope for NSD and nsd-control is the preferred way(?) I think it'll provide everything you need too, but definitely let me know what I can do to assist.

Personally, I think storing zone files in a certain directory and make that writable for your program is easiest. A zone file is really just a text representation of DNS data and is standardized. Depending on your programming language, zone file parsers may be readily available. Logic for checking zone consistency in your webapplication can perhaps be copied from PowerDNS-Admin(?)

What you can then do is:

Initial addition:

1. \<web interface> takes the zone.
2. store in the file specific to that zone. e.g. example.zone.
3. call "nsd-control " to add it to nsd.

Modification:

1. \<web interface> reads data from zone file.
2. \<web interface> takes changes for the zone.
3. store the updated zone in the zone file on disk.
4. call "nsd-control reload " to make NSD reload the file from disk.

Changes should be propagated through notify and (A|I)XFR, but you may choose to add functionality to your program to trigger an (A|I)XFR after a successful reload, "nsd-control -s \<secondary> transfer \<zone>" should help you out there.

Of course, you'd need to take precautions so no partial zone files are written (store in example.zone.\<something> and then rename?) and no unauthorized parties can write to that directory, but that's no different from ensuring nobody can write to your SQL database(?) You probably need to ensure changes are serialized too, maybe using a lock-file per zone(?)

That's some of my initial thoughts. Hope it helps.

[katzeprior]

Hi @katzeprior, sorry, I meant to get back to you. Sounds like a nice project!

Can't speak for other maintainers, but I feel/think providing a REST api is out-of-scope for NSD and nsd-control is the preferred way(?) I think it'll provide everything you need too, but definitely let me know what I can do to assist.

Yup, a REST api would be cool but not needed and as you pointed out nsd-control (while super confusing to me, so need to do more playing around) can be used by a third party to implement a third party REST api.

Personally, I think storing zone files in a certain directory and make that writable for your program is easiest. A zone file is really just a text representation of DNS data and is standardized. Depending on your programming language, zone file parsers may be readily available. Logic for checking zone consistency in your webapplication can perhaps be copied from PowerDNS-Admin(?)

What you can then do is:

Initial addition:

1. <web interface> takes the zone.

2. store in the file specific to that zone. e.g. example.zone.

3. call "nsd-control  " to add it to nsd.

Modification:

1. <web interface> reads data from zone file.

2. <web interface> takes changes for the zone.

3. store the updated zone in the zone file on disk.

4. call "nsd-control reload " to make NSD reload the file from disk.

Thanks, always nice to have someone brainstorm with you as I don't have friends that can help with this part of the project. Mostly had a hard time with the updating/adding a zone file logic/theory behind NSD.

Changes should be propagated through notify and (A|I)XFR, but you may choose to add functionality to your program to trigger an (A|I)XFR after a successful reload, "nsd-control -s transfer " should help you out there.

Of course, you'd need to take precautions so no partial zone files are written (store in example.zone. and then rename?) and no unauthorized parties can write to that directory, but that's no different from ensuring nobody can write to your SQL database(?) You probably need to ensure changes are serialized too, maybe using a lock-file per zone(?)

That's some of my initial thoughts. Hope it helps.

You're initial thoughts helped a lot and will help me find the best solution and will update you (idk where the best place would be to do that) on the progress <3 Thanks for being an amazing dutch non profit.

[k0ekk0ek]

Closing this issue as the question has been answered.