[bind10-dev] ddns

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

Here's some random thinking aloud to kickstart the ddns implementation
discussion.

- - the one thing i gathered from early discussions with users is that
they would want the option not to run any ddns code at all if they do
not use it, so it would make sense to me to make a separately running
module for handling ddns packets.
- - I think we should pass off DDNS messages from auth to ddns
module similarly to how we do it for xfrin
- - Naturally it should only work on zones for which we are master, and
the datasource should be writable
- - Also naturally, we will need ACL checks done here
- - The module should handle the updates, and form (one or more) DDNS
commands into a form so that ixfr-out would still work (see adddiff
docs)
- - I think we could quite easily support multiple updates
rolled into one change (by waiting for a bit for additional update
commands before committing), but it does depend on how good
transactions work on the backend (idling around if you have one giant
lock on the db does not seem like a good idea).
- - I think the biggest difference between ixfr and ddns is that we have
prerequisites. So we need to make sure our finder can retrieve all
necessary information.
- - Another difference is that, unless updated by the ddns command, we
need to increase the serial, and we can choose several approaches for
that. This is something i think should be completely done by the ddns
module (and not the datasource).

So an initial task breakdown could be:
1) Create a module that handles ddns packets, with skeleton functions
for 2, 3, and 4, and which initially responds with either NOTIMPL or
REFUSED
(the rest will certainly depend on 1)
2) Add ACL checking
3) Implement prerequisite checking (this can probably be
broken down into several smaller ones)
4) Assuming that the prerequisites are checked, take the update part
and feed it in the correct form to the datasource.
5) We can probably initially get away with doing 4 without any
consistency checks, but we should really do those as well. This would,
I think, depend on 4 being done though (or it should be done in 4).


And.... go!

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

iEUEARECAAYFAk7PyP0ACgkQ4nZCKsdOncWD8QCXcFNqewMU+XDooiSvSVQaiPX5
fwCg3Qk2N+PQD26oqw+oxv5QKxVkJOY=
=taRP
-----END PGP SIGNATURE-----