[bind10-dev] Data source development

[Danny Mayer]

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?
> 
> 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.

A couple of comments on this.

A) It seems to me that there are two parts of the data that needs to be
managed: 1) the zone data, by which I mean AAAA, NS, MX, etc. records,
and 2) domain data by which I mean data about the domain such as the all
of the DNSSEC records.  Keeping these separate architecturally would
help with simplifying making changes and additions to either one or the
other. This would also allow you to deal with issues like the putative
BNAME discussion currently going on in namedroppers, though I agree with
Michael and said so there that it is more a matter or better tools and
servers than yet another DNS type. Hopefully you are using design
patterns to implement all this.

B) Will this scale? For example will loading of the .com. domain load
quickly and be responsive?

Danny