1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

How To: Full Automation for your Slave DNS zone file

Discussion in 'Plesk 10.x for Linux Issues, Fixes, How-To' started by philb@, Mar 31, 2012.

  1. philb@

    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:


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

    Keep the money in your pocket!
  2. burnleyvic

    burnleyvic Regular Pleskian

    Nov 9, 2011
    Likes Received:
    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: Apr 1, 2012