mysqlBind Tutorial

Supports BIND 9 and 8. This brief tutorial is meant for experienced DNS/Bind administrators. It does not have much help* on using the technical but intuitive MySQL database web interface to the zone data that is mysqlBind.cgi.

mysqlBind servers use the Bind name daemon named 8.3.1+ and now named 9.x.x series with a few static configuration files, most notably /usr/local/mysqlbind/named.conf, but in general files generated from the mysql mysqlbind database on the central administrative mysql server (usually where the mysqlBind.cgi is running.) These files are located in the /usr/local/mysqlbind/named.d tree. Multiple master and slave mysqlBind managed Bind/DNS servers connect (by crontab) to the mysql server to update their zone information. The mysql database server is (or clustered mysql "replication" servers are) managed by this application, which should be running on a Mod_SSL Apache server with SSLVerifyClient require option enabled . Another option is to allow cgi dir access only to intranet IP's. These IP's should be non routable private LAN IP's (Ex. and carefully firewalled. The SSL model with an SSL Certificate Authority -for the issuance of personal certificates- is recommended for all but the smallest ISP's.

RFC-2317 Wizard added (Release 1.7)

CNAME use fixed.

"dig" used instead of deprecated nslookup.

Master DNS Servers
One or more master DNS servers get their zone db files and named.conf include files via crontab job queue processing. This is supplied by command line operation of the mysqlBind.cgi. Please note that a given DNS server can be a master for some zones and a slave for others. Usually a server is only a master or only a slave for all zones.

Slave DNS Servers
One or more slave DNS servers get their named.conf include files that define their slave zones from the mysqlbind database via crontab operation of the slave servers mysqlBind.cgi executable. Do not confuse this mysqlBind operation with the subsequent automated primary/master to slave zone transfers that are an integral part of the DNS system. Simply put, the slave zones get the zone info from the master server via DNS protocols but they need to know what zones to request transfers for. This is automated by the mysqBind Bind/DNS management system. This system supports mixed Bind 9 masters and Bind 8 slave servers. With Bind 9 advance setup you don't need the jobqueue processing for the slaves. But you need plenty of experience to setup Bind 9 that way and cryptographic security keys and whatnot. Large ISP's should use BIND 9 to the fullest. But for most of us a simple BIND 9 setup works fine.

Client Authentication and Permission Scheme
Users login via a cookie login mechanism and their encrypted password is stored as a cookie (again, it is important that the web server be SSL if not on a secure intranet since the login and password would be sent clear text.) The encrypted password and user permission level is stored in tAuthorize, along with the customer ID (uClient) that indexes into the tClient table. This means that you should make sure that no one can get into your mysql server from the outside! The permission level controls access to mysqlBind functions and the customer ID to row level operations on table data. This allows for customer reseller control over Bind/DNS information as well as multilevel access to mission critical DNS administration. Arpa zones and their resource records are always readable by all.

Advantages of using mysqlBind: Organization, Redundancy, Backup, and MySQL
mysqlBind helps you organize vast quantities of DNS information. All your DNS data is organized in the same way avoiding the common unix admin "I do it this way with tcl and perl scripts..." problem. This admin approach is not very good (or wise) for enterprise organization and will also avoid staffing and growth problems. Keeping things homogeneous and well organized also is great for small DNS operations where the "by-hand" admin may make mission critical mistakes (the "whoops..." factor.)

All your mission critical data is not only saved as standard Bind files but also stored on the very robust and reliable MySQL "server." This "server" can actually be a MySQL replication cluster for enterprise level DNS systems. Many system administrators are well versed in MySQL operation and even junior level admins can write simple SQL code to handle even complex enterprise wide DNS accounting and management reports and develop SQL scripts for automated zone modification. Since mysqlBind is open source, any competent C programmer can add important enterprise customizations to this software. Apart from your server backup very easy mysqldump backups can be done on multiple remote hosts (see INSTALL for example.)

Brief Installation Overview
Once mysqlBind.cgi is built (with make and make install) and running on your apache server you then must initialize the application by creating MySQL database tables and preloading some default data.

Run from the linux command line of the server: Important make sure -before running Initialize- that mysql server owner usually mysql can get to the .txt files in the mysqlBind/data directory. If you encounter a problem you need to via mysql drop the mysqlbind database and run Initialize again. Remember to edit local.h to setup for BIND 9 operation! You can also find named.conf files for recursive and non recursive BIND 9 operation in mysqlBind/setup9 dir. You should always get the latest root.cache file if needed every so often. BIND 9: You may also have to edit named.conf and /etc/rndc.conf and/or /etc/rndc.key. See the named.conf file itself and the INSTALL file for more info.

setenv ISMROOT <path to where mysqlBind resides> (tcsh example: setenv ISMROOT
/home/joe. Bash: export ISMROOT=/home/joe )
chown mysql $ISMROOT/mysqlBind/data
chmod o+x $ISMROOT
mysqlBind.cgi Initialize <mysql root passwd>

Back to your browser. You must now edit the name server group in the tNameServer table. The cList should be edited and the first line should contain the master NS fully qualified domain name (FQDN) with a capitalized MASTER with a single space. Then subsequent lines should specify all the SLAVE name servers that will be used ex. MASTER SLAVE
... SLAVE 
The cLabel should be a helpful group name like "ns1/". Next you need to add the NS zone (or zones if you prefer.) Ex. and finally a .arpa zone that has PTR resource records for all the NS specified in your NS group. Failure to do this means your NS will not even startup in Bind 8 series named daemons!, apart from the obvious non RFC compliance. Add the arpa zone by doing a [Modify] operation and selecting the checkbox: RevDNS[x], then finally [Confirm Modify].

After Bind 8.3.1+ or Bind 9 is installed on your server, run from the linux command line: (Bind 9 requires you edit local.h and make clean and then make install)

mysqlBind.cgi installbind <name server ip>.
This installs the needed Bind configuration files. If you will be running the server as nobody (recommended for security.) You need to set user/group ownership and permissions accordingly. If the Apache server is running as www or nobody you also must change permissions for /var/run/ndc-mysqlbind (also see crontab implications below.)

You should now proceed to start your name server. First modify named.conf for any local requirements. Then start the server. Ex:

/usr/sbin/named -u nobody -g nobody -c /usr/local/mysqlbind/named.conf
Proceed to check the system out. With dig/nslookup and ndc as well as looking directly at /var/log/named-mysqlbind.log. Ex.

Bind 8

/usr/sbin/ndc -c /var/run/ndc-mysqlbind status
/usr/sbin/ndc -c /var/run/ndc-mysqlbind reload

Bind 9

/usr/sbin/rndc status
/usr/sbin/rndc reload

Finally you need to setup the crontab job queue processing which is explained below. With Bind 9 youcan setup automated creation of new slave zones but it is an advanced topic. The default Bind 9 install will be enough for 90% of DNS server providers out there.

Repeat the above for the slave servers. With the caveat that the slave name servers need not have an apache server, since only crontab operation of the mysqlBind.cgi is required.

Setup and use the supplied nph-dnstest.cgi copy it to your cgi-bin dir and edit to taste.

Shell and Job Queue Crontab Operation
From the shell:
mysqlBind.cgi --help
Typical root crontab entry for a master name server. Note that depending on the way you setup your /usr/local/mysqlbind/named.d file permissions and the Apache server user you will have to run mysqlBind.cgi as the correct user (both crontab and shell.)
*/15 * * * * /cgi-bin/mysqlBind.cgi ProcessJobQueue >/dev/null 2>&1
*/15 * * * * /cgi-bin/mysqlBind.cgi ProcessExtJobQueue >/dev/null 2>&1
Slave mysqlBind servers (usually just running mysqlBind.cgi from crontab, no need for apache admin server -webconsole httpd daemon). For job queue processing, on non MySQL server local machines, you need to change local.h. And recompile with make clean, and then make install. These are the important lines of the local.h file changed fro a remote mySQL server:
#define DBIP
#define DBNAME "openispbind"
#define DBLOGIN "openispbind"
#define DBPASSWD "sj378fjd"

You will also have to grant permission to the slave server to connect to the master server MySQL database. This is done by using the command line mysql program on the master server as mysql user root and issueing an SQL statement like:

mysql>GRANT ALL ON mysqlbind.* TO openispbind@ IDENTIFIED BY 'sj378fjd';

For getting external jobs from mysqlISP or mysqlApache setup these configuration values in tConfiguration:

Note that these tConfiguration records come preloaded with full comments. Comments are good!

Depending on your ISP DNS management workload the processing batch period should be adjusted. With more operators and more DNS operations the period should be longer. The jobqueue processing uses the new Bind scheduling of zone reloads and low impact reconfig ndc commands to keep your name servers running well even under heavy loads. The jobqueue processing also uses simple heuristics to keep the reconfig and reload commands to the bare minimum. This section of mysqlBind is always being improved upon so it is recommended that you routinely check for updates if your run a large DNS server farm or have very heavy loads.

You should also sync your servers to a single clock with ntpdate on a daily basis.

*Expanded tResource and Webconsole Interface in General Operation Notes


Click on tResource (t is for table Resource and tResource is the actual mySQL table. uSomething is an unsigned value or an index into another table if you see text!).
Click on [Modify] ([This is a button]).
Click on [Delegation Wizard].
Select the name server group, the IP start number of the CIDR block you are delegating to the name server group members above, specify the CIDR value (very briefly, just a short hand way of saying how many IPs). And then click on [Create Delegation]. If all values make sense, then all the RFC required zone entries will be created for you saving lots and lots of typing and typo related bugs. Note that you can add more wizard generated entries that even overlap (for now, good idea?) The [Delete Delegation] button removes all the RR entries that were added even previously by this method unless the comment field is changed somehow (mysql batch job?)
In general every field and button should have the yellow 'tool tip' pop-up (you may have to move mouse over the field with care to get it to re-appear. These should explain the purpose and the range of input where applicable.


The CNAME resource record (RR) is now much less restricted which is nice but can also allow you to break things. Basically you can use "dotless" or "dotted" terminated entries on both sides, the main difference is that "dotless" entries on the right side of the CNAME refer to the current zone. To CNAME to an external reference you must end the FQDN (Fully Qualified Domain Name. Ex. with a period or as we say dot (.) at the end.

Root/Admin/Reseller/Customer (uPermLevel) Overview

When you initially install mysqlBind you have to login to the browser based interface (after doing the shell command line operations) and setup your intial dns and mail server information and zones. Please note that you can have -if you want, against RFC guidelines of course- only a single name server -or dns server- in your tNameServer, that would be a MASTER name server, but I digress...), You can see the level of the user in the top black bar by the IP from where you are using the browser interface cgi from.
As Root -or John IspOwner- (you can create as many root level users as you need. And you should for security get rid of the default Root entry and change the password of course) you should be able to see and do almost everything.
If you create a tClient admin level user, then they will also be able to see and do most everything but delete things that the root level user created.
If you create a tClient reseller level user (has to be done by root or admin level user), then they should be only be able to see and do most everything that has to do with their own records and their customer level users.
If a customer level user is created (can be done by root or admin level user for a reseller or usually directly by a reseller) then they will be able (if authorized of course, this goes for all the above also) to only see, add, mod or delete their own zones and zone resource records, including the PTR records in .arpa zones.
More about .arpa zones and the multi level browser interface: Basically, we have tried to prevent resellers and end customers the possibility of finding out what other resellers and end users are using the system. This, while still allowing them to take care of their own .arpa entries.
Final words on admins, resellers and end user customers: Make sure you only authorize people that really need and understand how to use the system. They can shoot themselves in the proverbial foot quite easily, but they should not be able to hurt others or the name server system in general.

Reverse DNS or .arpa Zones Overview

Any authorized user can automatically add .arpa zones with the correct PTR records.
Only root level users can create the zones directly, fix inter customer conflicts or delete them.
How-to add a rev dns entry for a zone: Just [Modify] the zone and check the RevDNS box right under the [Confirm Modify] button.
If another customer did this for their domain already then it will not add another PTR record (this avoids usually bad round robin PTR record effect.) If you think you need it contact the admin person to resolve the dispute.
You can also add reverse dns PTR records for tResource entries, if it makes sense (we may have missed some, so let us know!) This is done is a similar way as above when creating the resource record entry. A good example would be an A record entry for a mail server on an IP that is only used for that, or mainly for that service.
Closing note: Remember that if your upstream has not delegated the resolution of the .arpa zone in question, for the world at large none of your .arpa zones will work. You can find out more with "whois -h a.b.c.d" where a.b.c.d is the IP number in question. Also "dig ns" (note the c.b.a pattern and you may wish to try just b.a...) should provide valuable information. Example below that shows that quiknet2/ are the name servers for the .arpa zone shown below:
[xyz@camelot xyz]$ dig ns

; DiG 9.2.1 ns
;; global options:  printcmd
;; Got answer:
;; HEADER opcode: QUERY, status: NOERROR, id: 33952
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;       IN      NS

;; ANSWER SECTION: 86400  IN      NS 86400  IN      NS

;; ADDITIONAL SECTION:   85192   IN      A

;; Query time: 44 msec
;; WHEN: Tue Feb 10 09:09:43 2004
;; MSG SIZE  rcvd: 114
$Id: tutorial.html 2 2005-11-13 01:21:34Z ggw $