[bind10-dev] Data source development

[Jelte Jansen]

On 12/30/2009 08:13 PM, Michael Graff wrote:
> Shane has asked if we could have this done by the end of the next
> bind-10 meeting summit in January.
> 
> I believe the only hard part right now that I need to solve is simple:
> Do we use a "compiled" format (where something, either the system or the
>  admin, compiles a zone into an sqlite3 or bdb format) or do we accept
> text directly and have an in memory system?
> 

imo, either is fine right now (the other one should be the first next
thing anyway)

i think there's a more important decision; where exactly does the
'smartness' live, above or below the data source API? (this choice is
already implied in your list, separated by the 'if we can't do sigs+' line)

If it is below the API, when you ask it for an RRset, it will also look
up related signatures, and very probably also have a convenient way to
formulate full denial proofs, and probably much more, so the only thing
there is to do by the calling layer is mold it into an answer packet
(and since it is already mostly in wireformat, that would mostly mean
deciding on what goes in and do compression, tsig, etc.).

This is very probably the best design in terms of efficiency for lookups
(since a lot of the smartness can be done in one go), but will mean that
we might need to redo a lot of that logic per data source type (it will
probably also not be most efficient for updates, but lookups should
occur a lot more often ;) ).

I think we should first make a list of things we'll want to know from
the data source (which'll end up as functions and return types/classes),
before we make a data model (whether that be classes for in-memory or
tables for an RDBMS)

Jelte

> I'd be tempted to do this, as I think it could be pounded out fast by
> anyone who knows C++ well (which is not yet me...)
> 
>     A tool that takes a flat text file and compiles into SQLite3
> 
>     A tool that does the reverse.
> 
>     DDNS updates go into the sqlite3 database.
> 
>     The database stores a simple wire format (or other fast-to-re-render
>     format) of an RRSET.  It has signatures on those records and returns
>     them both at once.
> 
>     If we can't do sigs + data trick as above, then rrsigs are just
>     records and we'll seek and filter when we render.
> 
>     A simple cache that sits between data sources and the server
>     logic.  Perhaps this cache may be per-data source (with a shared
>     maximum size) or perhaps it will be BEFORE any data sources.  I
>     sort of prefer the former, as I think it's a cleaner approach.
> 
>     When we do REAL caching for a resolver, that is not the same as
>     the hot-spot cache described above.
> 
> Remember that whatever we do here is not going to be set in stone; we
> can always add to the API, remove from it, etc. as we wish.  We can
> either version the API and eventually remove older ones, or do something
> better like providing default, working-but-not-extremely-efficient
> versions for missing functionality.
> 
> --Michael
> 
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev