backend abstraction layer
erik at NLnetLabs.nl
Wed Sep 1 09:08:36 UTC 2004
Paul G wrote:
> i'm considering writing a backend abstraction layer and a sql (mysql or
> sql-lite) backend implementation. this is something i personally would
> like to see implemented given what i'd like to use nsd for. in that
> vein, i have a few (stupid?) questions:
> 1. does anyone have any input/tips/pointers on getting this done?
`First, why not use a DNS server that already supports SQL backends? I
know PowerDNS does and there might be others. NSD really isn't designed
with an abstracted back-end in mind.
But do you want NSD to dynamically query a sql database or just want
zonec to be able to compile from a sql database? In the latter case the
easiest solution is to generate standard .zone files from your SQL
database and pipe them into zonec. This is basically the "Unix"
approach (lots of small tools that do a single thing).
In the former case there will be a couple of big issues that you will
have to resolve. NSD makes the assumption that the database is fixed
while NSD is running. This is probably not true with a backend
abstraction layer or a sql database backend.
Furthermore there is currently very little abstraction between accessing
the zone data and responding to the query. So splitting these out would
be the first step...
> 2. this region business is confusing - what are they exactly? pointers
> so i can rtfm/rtfs are welcome.
Regions are used to group related resource allocations together (mainly
memory using region_alloc). All these resources can then be released
simultaneously using a region_free_all or region_destroy. This
simplifies resource management because we do not have to keep track of
each individual resource. But it also means resources can no longer be
individually released, which would probably be nice with a dynamic back-end.
Regions were inspired by MLton (<URL:http://www.mlton.org/>) and Cyclone
(<URL:http://www.eecs.harvard.edu/~greg/cyclone/>, but the page isn't
currently working for me). They are also related to memory allocation
pools and mark-release allocators.
> 3. what would make the most sense in terms of abstracting the logic out
> of the current parser?
If you just want to modify the parser the simpler solution is to
generate .zone files from your database and pipe them into zonec.
> 4. does this stand a chance of being accepted (after appropriate testing
> and ifdef'ed of course)?
NSD really isn't meant as a server with lots of support for various
back-ends and configurations. The focus is on an RFC compliant
authorative nameserver. Since there are currently no RFCs defining DNS
data in a SQL database format integrating various ways to access DNS
data into DNS will be a tough sell.
More information about the nsd-users