ENUMPlus has forced me to take a long hard look at DNS and security – with the publicly controlled records and what not – you can imagine what I was up against.  DNS configuration has always been very foggy to me.  Even after reading several books on the subject, I have never really been able to latch on and make it do exactly what I want.

This has all changed now that I have been working under the hood.  Let me take a moment to explain how I went from dreading configuration to not thinking twice.

As always I started with the basics in a safe development environment – Bind9 and vi on a minimal Lenny VM.  I started playing with it locally – setting my desktop resolv.conf to my dev box and modifying one line at a time of example configurations to see what they did and more importantly what they didn’t do.

After about 20 hours of research, probing, testing and … well … smoking – I was ready to start writing the nameserver module for ENUMPlus.  I had a brilliant working model in a few hours – returning NAPTR records and all.  The problem was scalability.  My initial code would curl the web server, writing the NAPTR records to a local file.  I then had a cron job that would cat the SOA, NS, A, MX & CNAME records to a new file – copy the contents of the NAPTR records files created by the web server – then run sed to remove any empty lines and move the file into place (with a reload of course).

It worked like a charm, I mean I was VERY impressed with what I had accomplished, but as always I knew there was a better way.  I started to think how heavy it would be on the host writing out the file, sed, cat, mv blah blah then on top of that reload bind, so I looked for alternative solutions.  After just a few minutes of googling – I ran into PowerDNS, which just happens to support a MySQL backend (the exact same animal running ENUMPlus Web UI).  This was ideal as end users could immediately add their validated records without having to wait for the cron job to advance the SOA serial, write out the new records and reload.  Immediate results are definitely what is going to push ENUMPlus over the top in my opinion.

Anyway we have our hosting in order and are just waiting for DNS to propogate.  We are working on a distributed solution for others to join in the hosting fun (slave boxes for replication and redundancy).  If you own a box and would like to dedicate some cycles – feel free to contact me or come say hi at #pbxinaflash (I live there).

Let’s say you just dumped an entire database and are looking to import it elsewhere, possibly on a new host.  As soon as you install mysql-server on the new box a new password is set for user debian-sys-maint.

# mysqldump –all-databases -u root -p  > dump.sql

Once you import this database on the new host there is a good chance you will not be able to restart mysql as the debian-sys-maint user account passwords will not match.

# mysql -u root -p < dump.sql

So the easiest way to fix this issue is to :

web:~# cat /etc/mysql/debian.cnf 

# Automatically generated for Debian scripts. DO NOT TOUCH!

[client]

host     = localhost

user     = debian-sys-maint

password = PASSWORD

socket   = /var/run/mysqld/mysqld.sock

[mysql_upgrade]

user     = debian-sys-maint

password = PASSWORD

socket   = /var/run/mysqld/mysqld.sock

basedir  = /usr

Open PHPMyAdmin and click Privileges, then click “Edit” on the debian-sys-maint user.  There you can update the password found in the file above (PASSWORD).
Sure hope this helped – I know how much time I have spent in the past looking for an easy solution.