• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

How To: Full Automation for your Slave DNS zone file

P

philb@

Guest
I haven't tested it because I don't have a Plesk 10.x installation, but there's no reason to think this would not work for any version of Plesk since we're talking about bind here:

http://forum.parallels.com/showthread.php?t=258488

I know this question has been asked many times before and there are expensive solutions that do it.

Keep the money in your pocket!
 
philb@, this is an interesting post indeed. Having master DNS servers operated by Plesk in sync with the slaves is extremely useful. In our company I am, in fact, managing something similar. Our environment is, however, relatively complex and the managed DNS solution has been designed and developed with the following in mind:
- one master DNS server should be able to keep multiple slaves in sync;
- one slave DNS server should be able to store zones from multiple masters;
- when migrating clients from one Plesk server to another the slaves should be automatically updated as part of the process with the new master DNS servers, or else the slaves will reject the notifies.
To achieve all the above we had to shift the paradigm and have the Plesk servers "pushing" the changes to the slave DNS servers instead of acting as passive entities. We are actively using Plesk's event manager to trigger specific actions on events like domain added, domain deleted, domain updated and so on. Plesk will run a script taking the domain name and the action as argument and construct a GET http request sent to one of the slave DNS servers that is used as single-point-of-failu^H^H^H^management :D interface. There, the domain data is processed, stored in a database and other scripts are updating named configuration for all the slave servers.
I had to deal with several corner cases (for example missed notifies due to a race condition was one of the biggest problem) but now the setup is pretty solid, has decent logging / reporting facilities and is relatively ease to manage when / if manual action is still needed.
Another idea would be to have this master(s)<->slave(s) setup working with slave DNS servers other than Bind. Having already a database backend makes the task easier to approach and the existing code can be easily extended to support, say, PowerDNS.
 
Last edited:
Back
Top