New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
DNS Zone Management Script
Anyone know of a PHP or CGI for managing DNS zones?
I'm looking for something that can store information in a db (preferable sqlite, so I don't have to run MySQL, Postgres, etc.) and then generate a bind-format zone file on request.
It shouldn't be 'tied to' or require a particular DNS server. Just a standalone script that stores the data, makes it editable, and generates the zone files when requested.
Anything like that exist, or do I have to invent the wheel? 
Comments
Any chance you're using powerdns?
Everything is at dnsmadeeasy now, and I'm just starting to plan to move DNS in-house. It's early days. I might use powerdns. I might use nsd. Might use something else. Currently looking at options....
PowerDNS can use MySQL for its backend and then you can use something like powerdnsadmin (or maybe it's poweradmin?) which is a pretty straight forward webUI for the whole show
Francisco
I've done some preliminary reading on powerdns/powerdnsadmin and I plan to get a test setup in place soon.
But there's a side of me that wants to run nsd with a custom, lightweight php/sqlite management interface. I installed nsd on a master/slave and wrote part of an interface last night. Someone tell me to stop....
PowerDNS can also use sqlite with some tweaking. Worked wonderfully for me, but then again I've always had a raging hardon for doing things via cli. No clue how easy it would be to tie poweradmin into sqlite <_<
The problem I have with someone else's web interface (for a service like DNS) is that I have to spend time to understand it, and maybe tweak it. Then there's a new version.
In my mind the task is pretty straightforward. Collect data. Store it. If all the required bits are there, write a zone file based on a template. Leave the followup tasks (making changes live on primary & slave servers) to the commandline.
I would love something like this for bind zone files. PowerDNS and PowerAdmin just use too much ram.
Folks, take MaraDNS. Lightweight and easy to work with by using simple shell-scripts. ;-)
It's on the to-look-at list. But I want a web interface
It's not really what you're asking for, but check out https://github.com/tgbit/gitzone -- it's a set of git hooks to handle the bits of zone files which scream out for automation (serial autoincrementing, automatic syntax check before committing), and also integrates zone reloading on your server with git's built-in push/pull network transfer system.
It looks pretty slick, but as an nsd user I haven't tried it yet (I can't imagine it's too hard to adapt to nsd, but it's in perl...). But the git-hook concept is something to think about.
Sticking with plaintext files can have advantages over an SQL database, not least that revision control is so simple with text files, and zone management really should involve revision control. Choosing to go without revision control to facilitate a database-based setup would be a pretty big downside if weighing making your own system.
Period
I looked at it. Can't say I really like the master-slave process. I have no issue with shell scripts, but I find a GUI interface makes 'getting to where you want to be' faster when you have a few hundred domains.
I've spent a bit more time at my web interface. Really, it boils done to something pretty simple when you consider that:
I like PDNSAdmin (http://code.google.com/p/pdnsadministrator/) with PowerDNS.
It was mentioned above... I'm neither discounting it or embracing it at this point
Is there a good reason not to use a unix timestamp as a zone's serial number? Other than the fact that my zones will become invalid when the timestamp rolls over to 11 digits. As that won't happen until Sat, 20 Nov 2286 17:46:40 GMT I won't loose sleep over it.
The popular format YYYYMMDDXX seems to be only a convention, not a standard.
I think SERIAL is defined as a 32-bit UINT, not "10-digits in base10" in RFC1035. So you'll actually hit a wall at 2^32 - 1 seconds past the epoch, which is only just around the corner in 2106
AFAIK all that's important is stay under 32-bits, and only increase the number, never decrease it. Also it wraps around, and I think (2^(32 - 1) - 1) is the biggest increment allowed between expiration periods by RFC1982's explanation of the field's "sequence space arithmetic" before you're actually decreasing the serial. But I haven't really read those RFCs in-depth, and it's a good idea to check at least those two out to see if there's anything there that might cause problems.
The only argument I can think of to keep the YYYYMMDDXX format is that if you're trying to debug something it can really jump out at you when the date is wrong (why is dig showing a serial of 2011120306 on that slave if I just updated the record yesterday...), while you probably wouldn't notice that the serial shouldn't be 1322885296 instead of 1328235296 unless you're specifically looking for it. But that's just a thing that can be a nice help during debugging, not related to any sort of technical requirement.
Appreciated, thanks.