Several DNS servers: why is it for the hoster and how is it implemented in Parallels Plesk Panel


    Puzzled by receiving feedback and more accurately prioritizing tasks, Plesk developers created an account on UserVoice - . Thus, they organized a place where customers can offer their innovations, write what they don’t like, vote for the functions they need (those that gain the most votes get into development). One of the popular queries we received from our users is “Automate slave DNS support”. This is a fairly old feature request that almost all Plesk server administrators want. To close this question once and for all, we decided to make the corresponding Plesk extension. What were the reasons for doing this? What exactly did we do?

    There are several reasons why a host may require at least two NS servers (or even more):
    • You bought a domain from a registrar. For a domain to be delegated, most registrars (for example, Russian,,, etc.) require that a minimum of a couple of name servers (NS) serve the domain zone;
    • You have several servers with hosting, you have not yet grown up to using products of the level of Parallels Automation or Parallels Plesk Automation , but want to use a single set of NS-servers for all domains hosted by you;
    • You want to have your own NS-servers and not depend on third parties;
    • You want your NS-servers in whois information of your domain. Here, for example, output whois data for the domain:
      Domain Name: PARALLELS.COM
      Whois Server:
      Name Server: NS1.PARALLELS.COM
      Name Server: NS2.PARALLELS.COM
      Name Server: NS3.PARALLELS.COM

    As you can see, there are enough reasons to have your own NS-servers. Typically, to solve these problems, hosters configure a pair of name servers in master-slave mode. At the same time, domain zones are created on both servers, but resource zone records of domain zones are managed only on the wizard. And the secondary (slave) name server downloads the changes automatically from the wizard. Thus, you always have two name servers active with the same set of domain zones and with the same set of resource records.

    Circuit diagram

    The only unpleasant trifle is that you need to create / delete a zone on both servers. This does not happen automatically. Therefore, we create a domain zone on the master. Then we create a domain zone on slave, specifying the address of the master server. That's all, now, adding domain resource records on the wizard, we can be sure that slave will automatically pick them up from there.

    How did we implement this?

    Integrating Parallels Plesk Panel and slave DNS for many years was not a very trivial task. It is understood that the Plesk server acts as a wizard. Plesk implements slave / master modes for a domain zone; there is a global list of IP addresses that can be used to request domain zones. But there is no mechanism for creating new domain zones on the slave server. And will not be. Because the Plesk concept is a panel for automating hosting operations within a single server. If you need integration of several servers, separation by type of service, then Parallels has other products: Parallels Plesk Automation, Parallels Operation Automation, and, ultimately, a large, comprehensive Parallels Automation solution.

    “Well, what's the problem?” You ask. But the fact is that there are a number of Plesk users who do not need the products listed above, they are overqualified to solve their specific problems. And they only need integration with the slave name server.

    To solve this problem, at one time each Plesk administrator wrote his own software solutions. Or bought commercial ones. Or manually performed the operation of creating / deleting domain zones on a slave server.

    It would seem that complicated? Plesk has a local NS server, let it be a master, there is an event system, let's hang the execution of our script on the events “creating a DNS zone” and “deleting a DNS zone”. Everyone will be happy. Unfortunately, there are no such events in Plesk.

    Plesk developers not only develop Plesk, but also themselves constantly use their product. Therefore, we made an extension for Plesk users that allows you to integrate Plesk with an external slave name server on which BIND9 is installed. You can download it for free, without SMS, by the link -

    How it works?

    Plesk uses BIND as the local NS server. He has the ability to remotely control using the standard rndc utility. No one bothers us to install BIND on a remote server and manage it through rndc. Plesk 11.5 introduces the “Custom DNS backend” mechanism. Through it, you can connect a third-party DNS service, for example AWS Route53. Read more about this in the documentation .

    In a nutshell, the meaning of this functionality can be described as the ability to register in Plesk a script that will receive a JSON description of the DNS zone, what you need to do with the zone each time you create / update / delete any active zone in Plesk. That is all we need. When implementing this functionality, it was assumed that you would not install a local BIND with Plesk, but would use an external service. But! Removing a local BIND is not necessary at all. The script can work in parallel with the local DNS service. Our extension uses this idea.

    The extension operation algorithm is as follows:
    1. In the extension settings, register the slave server
    2. The IP address of the slave server is automatically added to the list of those who are allowed to transfer domain zones from the Plesk server
    3. When an active domain zone is created / updated / deleted in Plesk, Plesk creates / modifies / deletes the domain zone in the local DNS service
    4. Next, a script is run that receives the domain name, the command (create / update / delete)
    5. The script runs an rndc command for each connected slave server
    6. Slave servers synchronize domain zones from a Plesk server

    Thus, we got a very simple and very strong scheme for working with slave name servers. All problems associated with the zone file format, connection and restart of the service are the responsibility of the DNS service itself. The administrator needs to configure the slave server only 1 time to work with external Plesk. Now you can go to the registrar and say that the Plesk server and slave server are the NS servers of your domains. And thanks to this, we solved all the tasks listed at the beginning of the post.

    And now a little more detailed, with a lot of technical details.

    Set up a slave name server (using the example of a server with Debian 7):
    1. We put BIND
      apt-get install bind9
    2. Allow the creation of new zones through rndc. In the file /etc/bind/named.conf.options, inside the options {} directive, we write:
      allow-new-zones yes;
    3. We indicate from which IP address control commands can be received, and we tell BIND to listen to all available network interfaces. In the file /etc/bind/named.conf.localwe write:
      controls {
       inet * port 953 allow { ;; };
    4. Be sure to remember the access key, it is located in the file /etc/bind/rndc.key:
      key "rndc-key" {
       algorithm hmac-md5;
       secret "vwOxonI4n4CVRUhKAOAAIA=="; 

    That's all, the setup of the slave name server is done.

    The next step is to go to our Plesk and install the extension (we mentioned above where to download it). On the extension page, add our slave server, indicating its IP and key. The extension will create a configuration file for the rndc utility, in which there will be settings for our slave server. Now Plesk will automatically translate all created, updated, and deleted zones to the slave server automatically by executing the following commands for each configured slave server:
    • Creature
      /usr/sbin/rndc -c slave.config addzone '{ type slave; file "/var/lib/bind/"; masters { ; }; };'

    • Update
      /usr/sbin/rndc -c slave.config refresh

    • Delete
      /usr/sbin/rndc -c slave.config delzone

    Now, when adding domains to Plesk, the DNS zone is automatically created both on the master server and on the slave server.

    By the way, we read comments and answer questions (also on our Parallels Plesk Panel developers tech blog too: ).


    Also popular now: