By geoff_t on

I'm creating a module to handle dynamic dns and bind administrative functions and I thought I'd put this out there in the hope that someone may have some ideas of the hurdles I'm going to come across. Here's a bit about the poject:

The goals are:
1) DNS Update Gateway Operation:
Allows the server running drupal to act as a gateway to update someones dns records using dynamic updates. The dns server is not neccessarily the drupal server but it could be.

2) Zone Administration:
Web interface to add and remove resource records from a zone. An administrative backend to allow modifications to all zones handled by the server and a user's front end to allow self serve to a user's own dns zone.

Appeal of drupal for this project:
User database and security system is already done and the separation of back-end and front-end functionality is useful also.

It seems like a relatively small project but no doubt it will be 3 times more consuming than I expect depending on how many features end up being implemented. My current ddns solution is in perl so to get things rolling the functions to add, remove and update dns records will just call the relative perl script but I have a view to using the pear Net::DNS to keep it all php so I'm allowing for this.

Some issues I see:
The module would add some tables to drupal and I'm not sure at this point how to make it work with the data abstraction layer. Are there docs about this somewhere - I have looked, there's so many (which is what I like about drupal coincidentally) a point in the right direction would really be appreciated.

Keeping the resource records up to date can be done using the dynamic updates but creating new zones will require write acces s to the conf file but I think this will be fine with a bit of a permissions checking script at install time for the module.

Let me know what do you think of this idea.

⋅ Categories: Drupal 4.7.x

Comments

Samat Jain’s picture

Samat Jain commented

This is an extremely weird module to have for Drupal, though I have to agree Drupal's user and ACL system are nothing short of excellent.
__
Personal home page | Rhombic Networks: Drupal-friendly web hosting

pkej’s picture

pkej commented

A search on DNS on freshmeat.net reveals a long list of DNS tools, many webbased. Why not integrate one of these into drupal?

At least they would have code to start with, so that you don't have to code everything from scratch.

Paul K Egell-Johnsen

Paul K Egell-Johnsen

geoff_t’s picture

geoff_t commented

heheh, my reason for it was to make my current setup easier. Thanks for that, looks like there's a few around that already do what I'm after :)

my apologies

pkej’s picture

pkej commented

I think a DNS module would be great for organic groups/civiccrm, for example assigning MX records to subdomains, etc.

So it is a good idea, and a useful one. And it would be nice to have integrated; the integration would be faster though if one used existing code.

Good to hear you found something which could work for you at once.

Paul K Egell-Johnsen

Paul K Egell-Johnsen

cmsn00b’s picture

cmsn00b commented

geoff_t,

I really liked the idea of what you have outlined above.

It was not too long ago I too was thinking along these lines for finding a way around the tedious task of having to manually fiddle around with my zonefiles.

I am still working on finding my way around with all things Drupal, but would like to know how things are evolving with this interesting project.

You mentioned you found something along the lines of what you were after. Care to elaborate?

Thanks in advance for your input

sean
cmsn00b

jamesJonas’s picture

jamesJonas commented

Bind + DLZ
I have been looking into this issue and thought your idea was great. I would integrate this into DLZ (http://bind-dlz.sourceforge.net/) which is going to the Bind Core as of 9.4 (just released but not on many distros). This means you would need to figure out functionality you wish to expose. The tables and the interface into bind have already been defined for Postgres (http://bind-dlz.sourceforge.net/postgresql_driver.html) and MySQL (http://bind-dlz.sourceforge.net/mysql_driver.html) (ldap is also possible and will tend to be faster since bind data is hierarchical.)

Here are the example for mysql tables:
(http://bind-dlz.sourceforge.net/mysql_example.html).

Here is a sample php frontend:
ANT
http://antdns.sourceforge.net/index.php
"Ant provides a minimalistic management interface for the database backend of Bind-DLZ. Currently Ant only supports PostgreSQL. However, the combination of pear MDB2 and a bit of oop should enable you to easily support any other db."

James

FatAtlas.com - US Atlas - 2 million places - Drupal Rocks ( :

you_know_who’s picture

you_know_who commented

First of all, allow me to put in my 2-bits and suggest that you should never let anyone change your motivation when people ask "what for or why". Personally, it irritates me when people question people's motivation because they don't perceive things as the person that might be writing the code. Don't be discouraged because people might say "well we already have a tool like that." Your tool might just end up being better than the rest and might benefit the drupal community even more.

The reason I am posting, is because I have been doing a lot of hobby work with bind-dlz, bind-sdb, and I have been a long-time bind user, and a long-time user of other isc products for some time. Recently, I have been searching for a decent front-end, for bind-dlz, whether it be a web or php frontend, or even a binary or GUI framework that would allow adjustment to the database VIA a graphical means.

A google search with the terms "bind dlz front end" (without the quotes) produced this page as the fifth link from the top. Before these, include ANT, which was previously mentioned, The "ajaxsified" dnsEditor by Lokkju, where it says "In Lokkju we trust" but I think there is some code missing from Lokkju's SVN trunk because I cannot get the ajax pieces to work. Other links before this one are irrelevant.

Sure people say - use ant, but there are limits and many adjustments are needed to make it work with mysql + using a "non-ant" schema.

So, based on the google search, and what I have tested and found, the bottom line is this: There really doesn't seem to be a good GUI alternative for BIND, comparing it to competitive commercial alternatives. Traditional BIND, using flat files, requires a restart if zone files are manually modified. The SQL database is a great alternative for this. Many commercial implementations utilize a database back-end, so no restarts are necessary, and then provide some nifty front-end that allows simple adjustment for the resource records. Here again, I know that anything can be done on the command line - whether it be the nsupdate for the flat files scheme, or SQL insert statements for the BIND-DLZ and SDB implementations, and that's great for me, but what about those folks that aren't so proficient on the command line? Those folks will stick with the commercial alternatives because they can operate them with a fancy GUI. The only thing I did find that suffices (and I mean, it suffices) is phpmyadmin, which accompanies many other potential side effects for just wanting to manage a single dns table.

So here are my suggestions for your project (if you're still thinking about doing something).

1. Keep the database pieces scalable, and simple. Use a single dns_records table for the database. Make certain that there is the availability for the drupal user of the module, to decide whether or not a separate table could be used (outside of the drupal database), or inside the drupal database if the user prefers. Make sure it works with mysql since that's what drupal works with in the first place.

2. The schema that JasonJonas mentioned is a great starting point. The one I am using right now is the one from the Lokkju's dnsEditor, and it's almost the same except for incrementing record ID's (which could be easily adjusted for another schema such as the one that JasonJonas mentioned in his reference). Here again, make certain that the user has a choice as to whether or not the table can be a part of, or separate from, the main drupal database. It's probably a good idea to provide for the availability of a separate authentication option (allowing the bind mysql user account to be used for the updates/selects and so on, instead of the drupal db user account).

3. Why not keep an option to allow for bind-sdb schemas? Or some other scalability that would allow the user to adjust and make their own row/columns for the database? Depending on the user's named.conf file, there could be any number of different rows, tables, and different combinations. Perhaps there's a way to allow the user to move the various columns around, but still requiring that all required columns are kept (e.g. the data column must be kept for all record types, a ttl value must also be there, and so on and so on etc.).

4. Keep djbdns on the horizon for your project if it matures. This "sleeping giant" DNS implementation looks like the BIND killer waiting to happen, and your application should include the ability to scale and use it later on, albeit provided that djbdns properly uses the same idea as the DLZ implementation, with the idea of storing resource records, domains, and zones in a mysql table.

Thanks again for your efforts!