Kloxo, secundary domain name server solution

Follow this (not my instructions) (from http://project.lxcenter.org/issues/969)

Secondary DNS
The previous tutorial described a DNS server on the same machine as the web server using a single IP address. That works just fine if all you are doing is hosting simple websites. In that case, a good argument can be made that if the web server goes down for some reason (along with the DNS server, most likely), that a secondary DNS server can’t help visitors get to your website because the web server is down anyway. And all of that is true.
Where it makes a difference is when you have clients who are counting on email that is handled by your server. So if you have a business that is hosting its email with you and both your server and DNS are down, mail will be immediately returned to senders as a bad email domain. That’s obviously not good for business. But if you had a secondary DNS server running someplace the sender’s email server will hold the email message until your email server comes back up, then try sending again.
So if your business reaches a point where you believe that a secondary DNS server is necessary, you need to consider a solution. If you only have a limited number of domains then you might consider a free service to host your secondary DNS. You might consider BuddyNS.com for that. It’s very good service, and you can host an unlimited number of DNS zones (domains) with them, but you will have to enter new domains manually.
If you are going to be running a hosting business where a lot of domains are likely to be created or deleted, particularly if you are going to have resellers who will be creating domains that you aren’t even aware of, then you need to find a more automated solution. To that end, I am going to provide an automated method of making the slave DNS server aware of new or deleted domains.
It’s important to understand that while BIND comes with the capability to automatically update zones, it does not have the capability to know when new zones are added in the master DNS server. The first part of this tutorial will be to take care of that by transferring a zone list to the slave server.
These steps are done in the Master DNS server
The first thing that needs to be done is to create a zone listing file in the master DNS server machine that can be used as a .conf file by BIND in the slave DNS server. However, we’ll use the file extension .txt in this script, since Apache is funny about transferring .conf files.
You will need to determine where the active .conf file is on the master DNS server. The BIND default location is /etc/named.conf, but I use the Kloxo control panel so my conf file happens to be:
Also you need to decide where your zone files should be in the slave machine. In my case I wanted the files to be in the following directory.
Note that I used “dallas” in the path, since my master DNS server VPS happens to be in Dallas. That not only leaves room for future server locations, but also keeps files orderly. With my master DNS server in Dallas and my slave DNS server in Denver, I keep things straight by referencing those locations. For that
reason, I’ll called the script we are going to create updatedenver. So you should use a text editor to create a file in /var/named/ called updatedenver, then paste the following code into it.
for domain in `grep ^zone /var/named/chroot/etc/kloxo.named.conf |grep "type master" |/bin/awk '{print $2}' |/bin/awk -F\" '{print $2}'`
/usr/bin/printf "zone \"${domain}\" { type slave; file \"/var/named/chroot/var/named/slaves/dallas/named/${domain}\"; masters {; }; };\n"
done > /home/admin/entomy.com/dns/updatedenver.txt
In the first line of code (the “for” statement), the only thing you need to change is the path to your named.conf file. In this case it will be the path to the kloxo.named.conf.
In the “printf” statement, change the path to where you want to zone files to be put. Change the IP address ( to the IP address of your master server. When this conf file is eventually applied in the slave DNS server, BIND will create empty zone files in the slave server according to where you specify in this statement.
In the last line (i.e., the“done” statement) enter the path to a web accessible location to deposit the output file of this script, usually someplace in /var/www… or someplace in /home/…
Once you are finished editing the file, save it. I called my script updatedenver and put it in the /var/named/ directory, which will work fine.
Now login to SSH as root and enter the following command to make sure that the web accessible script is writable. You will edit the path to the web accessible location of your choice.
# mkdir /home/admin/entomy.com/dns/
# chown 755 /home/admin/entomy.com/dns/
Now test run the script.
# sh /var/named/updatedenver
Check the output of the script buy navigating to the web accessible directory and opening the output file with a text editor. Mine is located at.
You should see a line in that file for each existing zone, specifying the path location for the zone file in the slave DNS machine.
Once you get the script running properly, you should create a cron job to run the script at regular intervals. In this case, we’ll run it once per hour so there will always be a fresh listing of your zones available to the slave DNS server to fetch. Using webmin, click the System icon at the top and click the Scheduled Cron Jobs icon. Click the “Create a new scheduled cron job” link. Fill it out like this:
That concludes the Master DNS server configuration, at least as far as updating zone names is concerned.
These steps are done in the Slave DNS server
The objective of this section is to configure the slave DNS server to fetch a zone information file from the master DNS server, place the file in a location that is accessible to BIND, and then apply those zones to BIND by restarting the application. To do that you need to create a script.
Create a text file and paste the following code into it:
wget http://entomy.com/dns/updatedenver.txt -O /var/named/chroot/var/named/slaves/dallas.conf
/etc/init.d/named restart
The wget statement fetches the file from the master DNS server, and then saves it as a file called dallas.conf in the specified location. You will need to edit the URL of the text file location to the actual web accessible location you put it in on the master DNS server. Likewise, edit the name and location of the .conf file to your liking. When done, save the file. I called the file getdallas, since my master DNS server is in Dallas, and saved it in the var/named/chroot/var/named/slaves/ directory, the same location as I put the .conf file.
Now open your named.conf file (normally found in /etc) and place this statement at the end of the file.
include "/var/named/chroot/var/named/slaves/dallas.conf";
You will need to edit the path and file name to match the location of the .conf file you specified in the script. Save the file. Also not that if BIND is running “chrooted” (as it is under Kloxo) that the path will be shortened to make the command look like this.
include "/var/named/slaves/dallas.conf";
Now login to SSH as root and create the .conf file so it can be written to by your script, editing for the proper path and file name, of course.
# touch /var/named/chroot/var/named/slaves/dallas.conf
Create the directory for the zone files to be created in, make the directory writable, and then restart BIND.
# mkdir /var/named/chroot/var/named/slaves/dallas/
# mkdir /var/named/chroot/var/named/slaves/dallas/named/
# chown 777 /var/named/chroot/var/named/slaves/dallas/
# chown named:named /var/named/chroot/var/named/slaves/dallas/
# chown 777 /var/named/chroot/var/named/slaves/dallas/named/
# chown named:named /var/named/chroot/var/named/slaves/dallas/named/ # /etc/rc.d/init.d/named restart
Of course, all of the above can be done a lot quicker & easier using the webmin file manager, but it works fine from the command prompt.
With those tasks done, test run the script from the command prompt.
With any luck, your output will look like this.
You can see from the output that the file was fetched, saved in the proper location, then named was restarted successfully.
Once you have the script running the way you want it to, create a cron job to run the script soon after the script on the master DNS server runs. Scheduling the scripts to run once or twice an hour is normally sufficient for redundant DNS.
Note that the zone files that were created from these scripts will be empty files. These scripts are only intended to make the slave DNS server aware of changes in the master DNS server zone listing. You will need to configure another solution to fetch the zone file contents, such as AXFR, rsync, or scp. However, it’s important to note that any zone files that existed in the slave DNS server before the script was run that already contained zone details will not be overwritten.
Enviar um comentário

Mensagens populares deste blogue

Categorias de Artigos

List all recepients in all Distribution Lists in Office365 / Exchange in powershell