backend abstraction layer

[Paul G]

erik,

----- Original Message ----- 
From: "Erik Rozendaal" <erik at NLnetLabs.nl>
To: "Paul G" <paul at rusko.us>; <nsd-users at NLnetLabs.nl>
Sent: Wednesday, September 01, 2004 5:08 AM
Subject: Re: backend abstraction layer


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

i use powerdns here currently. i am not happy with it. i'd rather patch in a
bit of functionality into a simple, concise and trustworthy codebase than to
try and figure out why i'm seeing mysterious things happen. the other answer
is i like the nsd license better.

> NSD really isn't designed
> with an abstracted back-end in mind.

yes, hence the questions - if it had been straightforward, i would have
built it first and offered it for inclusion later (i'm a spontaneous
codeathon kinda guy).

> But do you want NSD to dynamically query a sql database or just want
> zonec to be able to compile from a sql database?

ideally, i'd like to be able to do both - dynamic queries against a sql
backend as well as doing atomic updates with no service interruption.

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

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.

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

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

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

shouldn't be horribly hard, but needs thought not to overcomplicate things
or add too much overhead.

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

-- snip region explanation --

thanks for the pointers; most of the confusion comes from not dealing with
the whole parsing/lexing business before and confusing the regions into the
picture. i'll be reading up on the idea as it seems interesting and somewhat
related to what i've done on a couple previous occasions (basically creating
a linked list of allocations for each first class citizen).

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

simple is not necessarily better, in my selfish case at least. basically, i
want a solution that behaves well in a distributed environment that is
distinctly different from what most dns operators will be running (ie
servers serving different data for the same zone). simpler systems fail less
and less mysteriously, but for me, the simplest way to use nsd may result in
a more complex solution overall.

> > 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 simplicity of it is what makes it an attractive target for
customization.

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

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.

i also have to thank you for your level headed, informative reply; it is a
breath of fresh air in contrast with my experience with a bunch of other
foss projects, which i won't bother naming here, where questions like this
get flamed like it's marshmallow roasting session at a campfire.

paul