backend abstraction layer

[Erik Rozendaal]

Paul G wrote:
> folks,
>  
> 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.

Erik