[bind10-dev] Datasource discussion

[JINMEI Tatuya / 神明達哉]

At Thu, 14 Jan 2010 12:51:28 +0100,
Shane Kerr <shane at isc.org> wrote:

> > The simplest datasource "driver" would be to get RRSets.  We do want an 
> > RRSet to include signatures.  I feel signature records to be attributes 
> > on an RRSet or name, not records themselves.  Signatures are certainly 
> > closely associated with a specific RRSET, and will change if the 
> > contents change.  Making that a requirement of a low-level API just 
> > makes sense, and IMHO greatly simplifies design rather than complicates it.
> > 
> > RRSIG is the only commonly needed "sub-typed" -- why query a low level 
> > API for RRSIG type, and then have to either filter or modify the 
> > standard "name, type" query to also say "oh, for rrsig, you need to 
> > write special code to only return the stuff we really want."
> 
> Okay... presumably we don't intend for the low level API to also return
> NSEC records, right? What about NSEC3?
> 
> You may be right, but I think sticking with very basic primitives for
> the "required" low level is probably best...

I'm afraid requiring the data source sign RRset would require too
much knowledge about DNSSEC specifics (such as name/RR ordering and
canonicalization).

But I think it's a separate issue than whether to include RRSIG as a
"column" of the original RRset or whether to have RRSIG as a separate
"row" and introduce a specific interface to retrieve the intended
RRSIG.

For example, I think we can make it API user's responsibility to
update the sig if the corresponding RRset is to be modified.  The
caller will simply commit the changed RRset and RRSIG as a set into
the data source.  This way, the lowest-level API still doesn't have to
know anything about DNSSEC, while we can retain the model of including
RRSIG within the RRset.

(I didn't (yet) consider NSEC/NSEC3 implications above).

---
JINMEI, Tatuya