[bind10-dev] Datasource discussion

[Shane Kerr]

On Wed, 2010-01-13 at 16:43 -0600, Michael Graff wrote:
> Shane Kerr wrote:
> 
> > I'd like to push for a "generic", non-optimal implementation of this,
> > and not require that each datasource be forced to implement
> > DNSSEC-optimized lookups. As you say "some datasources may simply not do
> > it", so we need a way to get this data in that case.
> > 
> > My reasoning for this is that there may be people who want to play
> > around with implementing their own data source, but don't know or care
> > about DNSSEC. Or at least who would prefer to get started quickly
> > without implementing a large API on their side.
> 
> This is the intent, and what was discussed.  To put it differently:
> 
> I would like there to be an upper-stack implementation of DNSSEC 
> searching that will do individual calls down the stack as needed, but 
> allow the low-level "driver" like implementation to overwrite this 
> method and make a more efficient one.  I think this is more important to 
> have the ability to do rather than having specific implementations today.
> 
> 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...

--
Shane