[bind10-dev] Datasource API

[Jelte Jansen]

On 01/07/2010 12:30 AM, JINMEI Tatuya / 神明達哉 wrote:
> 
> And another example is a query for type "ANY".
> 
> Basically, the proposed plan seems to make sense to me, that is, we
> provide low-level primitive without much intelligence about DNS
> specific transactions like above, because we'll be able to support
> more variants of backend.  But at the same time, if the middle or
> upper layer to support these advanced stuff is too complicated or very
> inefficient, that wouldn't be a good architecture.
> 
> Right now I don't have a clear image about the best balance on this
> point.  So, let's begin with what we've come up with so far, keeping
> in our mind these corner cases.
> 

well said :)

> 
>>> - interface to handle SIGs: should we separate this from getRRset()?
>>>   FYI, BIND9 uses a unified "find" interface to get both the answer
>>>   and its SIG by a single lookup.  If my memory is correct NSD does
>>>   the same thing.
>>
>> yep, and probably everything efficient should, but that's the reason i
>> was thinking of lowlevel and highlevel functions, where if they are
>> encapsulated in one class, the efficient end-result would have those
>> high-level ones take quite a lot of shortcuts. Though i'm open to
>> suggestions or loud no-shouting :)
> 
> I'm not sure what you mean by "the efficient end-result would..."
> 

i'm predicting that in some implementation classes, the high-level
function are overwritten and no longer necessarily use the low-level
ones (but rather some convenient shortcuts that depend on the data
structures used).

> Anyway, aside from efficiency, another thing to consider is how to
> ensure the "real" RRset and its RRSIG belong to the "same version".
> 
> With this method signature, 
> 
>     virtual result getRRSigs(RRsetPtr target, const RRsetPtr rrset);
> 
> it would be impossible unless "rrset" holds the version information.
> But, since RRset{,Ptr} is designed to be a generic "RRset" class,
> independent from how they are used, it wouldn't be the case.
> 
> One possibility is to add an explicit method to retrieve the "current
> version"
> 
>     virtual const DataSourceVersion& getVersion();
> 
> and pass it to findRRset() and its friends:
> 
> version = datasrc.getVersion();
> datasrc.findRRset(version, target, Name("www.example.com"), IN, A);
> dtasrc.getRRSigs(version, sgitarget, target);
> 
> Of course, if we can ensure that the sequence of findRRset() and
> getRRsigs() calls is atomic, we could omit the "version" information.
> But I'm afraid it's too optimistic even if we don't support multi
> threads.
> 

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)

> 
> FYI, BIND9 separates "replace" and "merge" by a flag argument to
> dns_db_addrdataset(): if we set the DNS_DBADD_MERGE flag, the added
> records will be merged into (any) existing RRset.  Otherwise the new
> data will replace existing one, unless the latter has higher (RFC2181)
> trust level.
> 
> 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

>>>
>>> - about the high level method (getData()): I'm afraid this will make
>>>   the class too monolithic.  maybe we can begin with a non member
>>>   function only using other low-level public methods.
>>
>> well see my second and fifth answer (on intelligence and efficiency),
>> i'm certainly not set in stone on the current approach (nor for other
>> choices made so far)
> 
> I don't have a strong suggestion right now.  I'll think about it more.
> 
> BTW, I'm not sure the getNSECs()' signature makes sense:
> 
>     virtual result getNSECs(RRsetPtr target, const RRsetPtr rrset);
> 
> what's the "rrset" argument in this context?  For example, if the
> corresponding findRRset() resulted in name_not_found, I'd not expect
> an RRset object to be returned.
> 

you are right

> 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)

Jelte