[bind10-dev] Datasource API

[JINMEI Tatuya / 神明達哉]

At Thu, 07 Jan 2010 10:46:48 +0100,
Jelte Jansen <jelte at isc.org> wrote:

> > Anyway, aside from efficiency, another thing to consider is how to
> > ensure the "real" RRset and its RRSIG belong to the "same version".

[...]

> hmm, good point. Would there be anything else that we need to keep track
> of within one set of operations? (then including the 'version at time of
> start' could perhaps be encapsulated in a context pattern)

I have no other particular things in my mind ('version' can be a very
broad notion, where everything necessary fits:-)

> > Now, this is another consideration point of how intelligent the
> > low-level methods should be, that is, whether or not the method
> > considers the trust level in an add operation or whether it's caller's
> > responsibility.
> 
> let's keep it in mind; i would suggest that that is something the
> lowlevel functions should not have to do, so a flag or specific
> functions would be appropriate

I tend to agree (see also below), but then I guess "a flag" wouldn't
be appropriate (not at least in the sense I referred to it) because it
would be an argument to a low-level method.

> > A related random idea: if we provide generic primitives of something like
> > findPreviousName(), we might even be able to hide the NSEC related
> > details from the low-level API implementations.  Further, we could
> > also extend the notion of "RRtype" so that an extended version
> > encapsulates both the "real" type and covered type (the latter is
> > meaningful only for RRSIG).
> > 
> 
> thanks, good points, something like that would be very useful (and
> probably necessary)

On thinking about it more, I now more inclined to the idea of making
the lowest level interface as much independent from DNS as possible.

Ideally, the low level API considers a data source a very simple
database where keys are a pair of "name + (extended) type (+ perhaps
class)" and values are some opaque data.  name/type/class could be
represented as some trivial type of data, such as a (C-style) string
or integers.  Then we'll only need to provide some basic manipulation
methods:

value = datasrc.find(key);
value = datasrc.add(key, value); // this 'add' is a 'replace'
value = datasrc.delete(key);

and matching keys is a straightforward exact match.  These are
backend-specific, of course.

We then build a middle layer where all DNS related specifics (but
independent from backend details) exist.  Its findRRset() method will
be more intelligent for search based on the DNS protocol.  For
example, to find the longest match, it would do:

for (i = 0; i < qname.getLabel(); i++) {
  result = lowlevel_datasrc.find(qname.split(i, qname.getLabel()),
                                 i == 0 ? qtype : NS, class);
  if (result == success)
    break;
  if (i == 0 && lowlevel_datasrc.find(qname.split(i, qname.getLabel()),
                                      "any", class) == success) {
    // no error, no data case.  handle it accordingly.
  }
}
// if the search succeeds, if we have either an exact match for the
// qname+qtype or the deepest zone cut with the corresponding NS RR


I showed DNSSEC related lookup could be implemented using the naive
low level primitives in the previous message.

Other trickier part, such as wildcard matching or how to order the low
level data in the DNSSEC ordering, may be more...tricky, but if we
can separate the lowest level and the middle layer at this level of
abstraction, I think it will be a cleaner in the design, and have some
practical benefits:
- we don't have to write relatively complicated DNS logic multiple
  times
- (as a corollary) the lowest level implementation can be very simple,
  mainly just concentrating on portability issues for the trivial
  tasks.
- (as a corollary) it will be easier to support more data source
  backends.

---
JINMEI, Tatuya