I have for some time wanted to try something along these lines myself to aid with the monotony of DNS administration. The idea I was going to use for storing the information from which the config files were built was to use MySQL, since PHP and MySQL work very well together.
Information could be updated in the database and the config files and zone files could be rebuilt from the new information.
Just an idea after seeing your survery!
All the best,
Steve Abraham.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The thought of using MySQL did indeed cross my mind. But there are a couple of issues to consider.
I wanted a lightweight implentation fully in PHP, not using any outside resources.
Also, I tried another package, called oDns http://sourceforge.net/projects/odns/. With the provided example pages, I could not generate a consistent dns config, and therefore decided to write my own.
Here are some issues AGAINST using MySQL:
1) You will be dependent upon MySQL and the php class to generate your config files. Say goodbye to editing anything by hand.
2) Some DNS servers have to be lightweight, running Apache/w PHP is bad enough. Apache/w PHP and MySQL would kill some dns boxes. Like my Multia with a 200meg hd drive. :-)
3) Any kind of connectivity problems, accidental deletion of mysql socket file, or some such, and your configs are fubar.
On the other hand, if you handle a HUGE amount of dns data, you'll need a HUGE amount of ram and processing power to use PHP Bind. Since PHP Bind parses named.conf and the domain.db file at LEAST once per run that would be slow and time consuming. For systems like that, we may move to MySQL, or at least offer it as a config option. Perhaps later on we will branch off this project. But for now, I'd like to keep it simple, reliable, and working.
Generally, PHP Bind 8 is excellent for an Intranet dns system, or even a small ISP. Anything larger would become too much for PHP Bind to deal with.
Thanks!
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using any SQL has pros/cons, but so does parsing the bind files. SQL would make it easier to integrate into web apps (eg, control panels for web hosting customers).
I'm going to give phpbind a whirl (need a few more boxen though <g>)...looks cool. Personally though, I am probably going to tweak it to have bind run on some rogue port (just as a test dns server), run queries against it (to make sure it's kosher), and then use ssh/rsync to move files over to the production nameservers (as well as use ssh to sighup named).
marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Grab the version from CVS it has a few more bug fixes/enhancements.
Another reason for not using SQL:
The current implementation doesn't utilize all of Bind's features. Therefore, using SQL you'd lose data (converting from named.conf to sql).
The cool thing with this, is that when it comes across data it doesn't understand (like slave zones for now, or text fields, configuration, etc). It just gobbles it up, and spits it back out.
So you need to start off with a pre-exiting ready configured named.conf, then if you want reverse zones, just use a package like mkrdns (search for that in freshmeat.net).
slave zones are ignored (but re-generated) for now. I've been using the CVS version in production now and it's pretty spiffy. I've got over 100 domains I'm administering with it..
koguma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK,
Client registers 15,000+ domains
(Rather them than me)
They come to me to set up a web-server.
Primary DNS will be hosted on the same server.
(Secondary DNS is unknown at this time)
They need to be able to add Domains via a web form.
They also need to be able to upload comma-sepperated file for my PHP code to parse to add batches of domains.
The DNS server merely has to point all web traffic at itself. Point ALL MX records to a third parties server. And point all mail.<domain> subdomains to the third parties web server.
My intention:
To use MySQL to store the domains and either get bind to use MySQL or wright scripts to generate zone files from the MySQL database.
With this number of domains, is this a sensible approach and will phpbind8 handle this sort of stuff?
I figure with htis number of domains, which ever code ends upo being used is going to be prety well production tested ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm basically using it for exactly that. Granted, I haven't had that kind of volume, and if you HAVE that kind of volume you'd better use sql. BUT, for light weight (I have about 200 hosted domains) it works great. You don't need sql to have webforms, that's what the api does for you. You just query the api and you get back domain info, or named.conf info.
Also, there's a gz packege for compressed html output, might be a good idea to implement if trying to view 15,000+ domains... :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have for some time wanted to try something along these lines myself to aid with the monotony of DNS administration. The idea I was going to use for storing the information from which the config files were built was to use MySQL, since PHP and MySQL work very well together.
Information could be updated in the database and the config files and zone files could be rebuilt from the new information.
Just an idea after seeing your survery!
All the best,
Steve Abraham.
The thought of using MySQL did indeed cross my mind. But there are a couple of issues to consider.
I wanted a lightweight implentation fully in PHP, not using any outside resources.
Also, I tried another package, called oDns http://sourceforge.net/projects/odns/. With the provided example pages, I could not generate a consistent dns config, and therefore decided to write my own.
Here are some issues AGAINST using MySQL:
1) You will be dependent upon MySQL and the php class to generate your config files. Say goodbye to editing anything by hand.
2) Some DNS servers have to be lightweight, running Apache/w PHP is bad enough. Apache/w PHP and MySQL would kill some dns boxes. Like my Multia with a 200meg hd drive. :-)
3) Any kind of connectivity problems, accidental deletion of mysql socket file, or some such, and your configs are fubar.
On the other hand, if you handle a HUGE amount of dns data, you'll need a HUGE amount of ram and processing power to use PHP Bind. Since PHP Bind parses named.conf and the domain.db file at LEAST once per run that would be slow and time consuming. For systems like that, we may move to MySQL, or at least offer it as a config option. Perhaps later on we will branch off this project. But for now, I'd like to keep it simple, reliable, and working.
Generally, PHP Bind 8 is excellent for an Intranet dns system, or even a small ISP. Anything larger would become too much for PHP Bind to deal with.
Thanks!
Alex
Using any SQL has pros/cons, but so does parsing the bind files. SQL would make it easier to integrate into web apps (eg, control panels for web hosting customers).
I'm going to give phpbind a whirl (need a few more boxen though <g>)...looks cool. Personally though, I am probably going to tweak it to have bind run on some rogue port (just as a test dns server), run queries against it (to make sure it's kosher), and then use ssh/rsync to move files over to the production nameservers (as well as use ssh to sighup named).
marco
Grab the version from CVS it has a few more bug fixes/enhancements.
Another reason for not using SQL:
The current implementation doesn't utilize all of Bind's features. Therefore, using SQL you'd lose data (converting from named.conf to sql).
The cool thing with this, is that when it comes across data it doesn't understand (like slave zones for now, or text fields, configuration, etc). It just gobbles it up, and spits it back out.
So you need to start off with a pre-exiting ready configured named.conf, then if you want reverse zones, just use a package like mkrdns (search for that in freshmeat.net).
slave zones are ignored (but re-generated) for now. I've been using the CVS version in production now and it's pretty spiffy. I've got over 100 domains I'm administering with it..
koguma
OK,
Client registers 15,000+ domains
(Rather them than me)
They come to me to set up a web-server.
Primary DNS will be hosted on the same server.
(Secondary DNS is unknown at this time)
They need to be able to add Domains via a web form.
They also need to be able to upload comma-sepperated file for my PHP code to parse to add batches of domains.
The DNS server merely has to point all web traffic at itself. Point ALL MX records to a third parties server. And point all mail.<domain> subdomains to the third parties web server.
My intention:
To use MySQL to store the domains and either get bind to use MySQL or wright scripts to generate zone files from the MySQL database.
With this number of domains, is this a sensible approach and will phpbind8 handle this sort of stuff?
I figure with htis number of domains, which ever code ends upo being used is going to be prety well production tested ;)
I'm basically using it for exactly that. Granted, I haven't had that kind of volume, and if you HAVE that kind of volume you'd better use sql. BUT, for light weight (I have about 200 hosted domains) it works great. You don't need sql to have webforms, that's what the api does for you. You just query the api and you get back domain info, or named.conf info.
Also, there's a gz packege for compressed html output, might be a good idea to implement if trying to view 15,000+ domains... :-)