[bind10-dev] writable datasources 2/3; Ideas and open issues

Jelte Jansen jelte at isc.org
Mon May 10 08:43:09 UTC 2010


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


For writable data sources, I think we should use a similar approach we
have right now; a set of mandatory-to-implement lowlevel primitives, a
set of high-level functions with a default implementation (that uses the
low-level functions), and if needed, a set of functions in between
(which are actually also 'high-level', just contain a bit more
intelligence that the low-level functions.

While most functions will have the option to return 'not implemented',
we probably still need some structure to advertise possibilities, though
at this point, apart from whether data can be written at all i'm not
sure what we need here (we will probably need something about concurrent
write access, though how exactly is one of the open issues, and I
haven't a specific proposal yet).

So for the low-level; we need at least these functions
- - add/delete records
- - check if a zone exists/get the currently stored serial
- - some form of write-lock and transaction (start, commit, rollback)
handling
  (these could simply be wrappers if the backend has these features, I think
  we should think about having some defaults or examples for these
though, for
  backends that do not have direct support)
- - check for existence/nonexistence of specific rrs within a zone

I'm not entirely sure yet how 'smart' add and delete need to be (since
our base 'unit' is the RRset, the current addRRset would add the
contents of the given RRset to any RRset that already exists, but we
could make these really dumb and provide a smarter add() function that
fetches any existing rrset first, adds to it, then deletes the old one
and stores the new. For instance. This would make full loads for
loadzone and axfr quite a lot more efficient, and you could error on
duplicates).

High-level functions:

- - Replace all rrsets for a given zone (load/axfr)
- - Delete and add a set of records (ixfr)
- - Do Dynamic update

And we might also need some different functions;
- - A way to select a datasource where a new zone should be stored?
- - A 'smart' add function? (add if rdatalen>0, delete if rdatalen==0)
- - Sanity check? (there are a few that add() and delete() could
potentially do, but not all of them; we probably need two forms of
sanity checks; one automatic for invariants that can never be broken
(e.g. multiple CNAME records for instance, always delete existing one
first), and one that is actively called after a set of operations for
invariants that can be temporarily broken in the course of one update
(e.g. delete/add SOA records). I'm also wondering if we would have use
for add/delete without checking at all.

Currently, most functions, like the read functions, return Result. I
think we'll need to have some more return values for writing. If so,
we'll need to either expand the Result enum, or add a second one,
WriteResult. My preference is for the latter.


To be continued.

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

iEYEARECAAYFAkvnxx0ACgkQ4nZCKsdOncV8TwCgu5Crzm6CKsWtmA907otkANqI
gVAAnjc2InfQTTRvw+2dnUL0EVcOJtOa
=HSM3
-----END PGP SIGNATURE-----



More information about the bind10-dev mailing list