• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

How To: Full Automation for your Slave DNS zone file

P

philb@

Guest
Tired of manually creating, pruning, copying and restarting named on your secondary DNS when you add a new domain or delete one on your Plesk machine?

Me too.

I'm going to start with the assumption that you have a working slave that you would like to automate. If you don't, we can go into that in another How To.

Here's a couple of shell scripts, the first goes on the master machine in the /root folder, the second one goes on the slave machine in the /root folder. If you'd like these in /usr/local/sbin, that's fine. Just put them where you want them and then modify the cron job to match whatever path you like.

Be safe. Make a copy of your existing named.conf on both ends. Something like

cp /etc/named.conf /etc/named.conf.working

So if it all goes to hell in a handbasket, you can put them back to where you started.

On the Zone Master machine (your main Plesk box):

The following process grabs your /etc/named.conf file and parses out all the domain names and then uses them to synthesize the slave zone file. Replace nn.nn.nn.nn with your master IP address. Replace YourWebSite.com with any web site name that lives on the master machine.

/root/generate.slave.zones.sh
Code:
#!/bin/sh
#
for domain in `/bin/grep ^zone /etc/named.conf | grep -v '"."' | grep -vi in-addr | /bin/awk '{print $2}'| /bin/awk -F\" '{print $2}'`

do
        /usr/bin/printf "zone \"${domain}\" {\n\ttype slave;\n\tfile \"slaves/${domain}.db\";\n\tmasters { nn.nn.nn.nn; };\n};\n"
done > /var/www/vhosts/YourWebSite.com/httpdocs/named.conf.slave.zones

Since cron (root) created it, by default it will be owned by root.root and you'll need to fix that to make it world readable. Go to the target directory and use chown to make it owned like the other files in that httpdocs directory.

cd /var/www/vhosts/YourWebSite.com/httpdocs

chown user.group named.conf.slave.zones

Then make it readable with

chmod 744 named.conf.slave.zones

You should only have to do the chown/chmod process once unless you delete it.

The Zone Master runs this on a cron job that looks like:

0,15,30,45 * * * * /root/generate.slave.zones.sh


This generates a new named.conf.slave.zones file every 15 minutes. Adjust to your own happiness. It doesn't have much load so we might was well reduce latency.


On the Slave DNS machine:

This shell script fetches the file created in the previous step and brings it to your slave DNS host. If the fetch is successful, it moves it to it's working directory and tells named to restart.

And a one time step before all that will work, you need to modify your /etc/named.conf file to remove all your previous manually (and lovingly) entered slave zones and put an include directive in place to point named.conf to the new slave zone file.

/root/fetch.slave.zones.sh
Code:
#!/bin/bash
#

DIRECTORY=/etc/named.slave.fetch

if [ ! -d "$DIRECTORY" ]; then
    mkdir $DIRECTORY
fi
cd $DIRECTORY

rm -f $DIRECTORY/named.conf.slave.zones*

/usr/bin/wget [url]http://YourWebSite.com/named.conf.slave.zones[/url]
if [ $? -eq 0 ]
then
        /bin/cp -u named.conf.slave.zones ..
        /sbin/service named reload
else
        echo "Slave zone file download failed."
fi

The DNS Slave machine runs this with the following cron

5,20,35,50 * * * * /root/fetch.slave.zones.sh


You'll need to modify /etc/named.conf file to pick up the new file named /etc/named.conf.slave.zones.

So edit your /etc/named.conf and remove all your slave zones and put this link in place:

include "/etc/named.conf.slave.zones";

Then you'll need for the new slave zone file to be readable by named.

chgrp named /etc/named.conf.slave.zones
chmod 740 /etc/named.conf.slave.zones

Once both ends are up and running, you should find your zone db files in a directory named slaves. It will move depending on if you are running named in a jail, but on my machine the slave zone db's are in:

/var/named/slaves

Of course, there's a LOT of ways that are more secure to move the file between the machines such as scp with a key in place, ipsec tunnels, secure ftp, etc. I'm a fan of KISS so I kept it simple.

Let me know if you have questions.
 
Last edited by a moderator:
Hello,

First of all thats for the tutorial. Very very usefull.

I have one question. What happens if you manage more than one plesk machine and wants to use a secondary DNS server for all the machines?

Regards
 
You can implement the script on as many machines as you like.

Plesk Servers

On the Plesk servers, you'll have to set up the data creation step on each one. Modify those so each creates a uniquely named file instaed of the generic name. Instead of:

/var/www/vhosts/YourWebSite.com/httpdocs/named.conf.slave.zones

, you'd create as the last line in the script:

/var/www/vhosts/YourWebSite.com/httpdocs/named.conf.firstpleskserver.com.slave.zones

Of course, substitute your server name for firstpleskserver.com so it makes sense to you when you look at the script later.

Secondary DNS:

Then create copies of the pull script that runs on the secondary DNS server under different names and set a cron to run each one.

So instead of

fetch.slave.zones.sh

you'd have multiple of them like

fetch.slave.firstpleskserver.com.zones.sh
fetch.slave.secondpleskserver.com.zones.sh

with the internals pointed to the correct plesk server and the correct file name.

Then you'll need a new include line in named.conf to pick up each new file you add.

There's no reason to believe that all this would not work on creating a secondary for any bind dns server, since all named.conf files look pretty much the same regardless of how they got created.
 
Last edited by a moderator:
Back
Top