backend abstraction layer

NSD
1

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?
  2. this region business is confusing - what are they exactly? pointers so i can rtfm/rtfs are welcome.
  3. what would make the most sense in terms of abstracting the logic out of the current parser?
  4. does this stand a chance of being accepted (after appropriate testing and ifdef’ed of course)?

i’m going to do a bit more source reading and will, provided i don’t get flamed to heck and back for even thinking of implementing such heresy, post a summary of how i plan to implement it so folk with more clue can point out any (inevitable) problems.

cheers,
paul

2

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/&gt;\) and Cyclone (<URL:http://www.eecs.harvard.edu/~greg/cyclone/&gt;, 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

3

erik,

4

Paul G wrote:

this is a little less robust than i'd like. while i'm a big fan of "The Unix
Way", shellscripts that take 5 minutes to write and save hours of c coding
etc, i'd rather have something closer inegrated in a production environment.
with that said, i might well end up doing this because i'm lazy.

Another advantage of the "generate a .zone file from the database" approach is that it is easy to use with any other nameserver, because they all(?) support .zone files.

right. adding an is_dynamic flag to a per zone structure and implementing
atomic updates thtough ipc would work for this, simplistically speaking,
yes?

I'm not sure if I completely understand you here. But I suppose if you used such a flag and reimplemented/modified the functions specified in namedb.h you'd be able to get most of NSD to work with another backend.

But the API specified in namedb.h might not be a very good "fit" for a dynamic SQL based backend.

understood. my concern is my ability to maintain a patch that would be as
intrusive as this one if it does not get accepted into the main codebase. i
am still on the fence as to whether i'm going to be doing this and i am
definitely seriously considering the simpler, more hackish solution as well.

It is hard to predict the amount of modifications necessary for your requirements. If the changes are limited to some internal API changes that do not complicate the rest of NSD but make implementing dynamic backends easier those changes will be accepted.

But support for any kind of specific dynamic or SQL backend will most likely have to remain a separate patch or plugin.

Erik

5

Erik Rozendaal wrote:

But support for any kind of specific dynamic or SQL backend will most likely have to remain a separate patch or plugin.

Actually, to clarify a bit, dynamic backends will have to remain separate. See the requirements (#9) and especially the non-requirements (#4) in the REQUIREMENTS file.

So to reiterate, if some internal changes are needed to make it easier for you to implement whatever you need and those changes do not complicate NSD the changes can be included. But anything beyond that will have to remain as a separate patch/plugin/project.

Erik

6

erik,