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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20040827/56352d4e/attachment.htm>
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