[bind10-dev] Data source API

[Michael Graff]

Here's some quick thoughts on how I'd like to approach the data source
API in the short and near term.

Initially, it will be very simple and may only allow for very simple,
low-level functions:
    Look up data based on (name, type)
    Update data
Step two will be:
    Return associated data (like CNAME targets, DNSSEC records, etc)

I envision a 3-layer approach eventually:  the application should have
to do very little "grunt work".  The database layer itself will do most
of the hard stuff, since the closer we put things like searching to the
data itself, the faster and more efficient I think it will be.  A middle
layer will be in place to implement searching and other things that a
specific layer may not implement.

Initially this will be a very shallow design, with the application doing
more than it should.  This middle layer should grow out of refactoring
work as we add more than one data source, and find that we are doing
common tasks which can move up from the low level, and as we write more
applications/tools which use the data sources, and functionality moves
from the apps into this middle layer.

Short-term design would:

  (1)  Work on the RRSet level, not on the record level.
  (2)  Be fast for single-name/type lookups.
  (3)  May be a read-from-disk, in memory database, and updates will
       go to disk periodically.
  (4)  Perhaps going straight to sqlite is just better.  It's really
       fast, and can be used entirely in-memory.

The important thing here is I don't want to do what BIND 9 did, if we
can avoid it -- we are not database experts, so using pre-written data
structure libraries is likely better for us initially than rolling our
own.  I hope it is better for the long term too.

(1) is hopefully handled mostly by Jinmei's DNS library.
(2) should be pretty easy for simple lookups.  We may initially do more
than one lookup as we search up the tree to find negative answers, etc.
It will also have to do more lookups to find associated data.  I see no
reason RRSIGs cannot live with the data it signs, however.
(3) may not be the most efficient in rev 1.0, but should be iterated
over to improve speed.  One advantage we have over BIND 9 is that we are
designing a system where most of the DNS protocols are well defined,
while BIND 9 grew DNSSEC three times, LRU caching, efficient expiry,
etc.

--Michael