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
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.
Facebook
Twitter
