multi-master-dnsThe purpose of this article is to demonstrate how multi-master DNS is configured and supported in VitalQIP 7.x for static DNS environments. A multi-master DNS configuration using BIND DNS software is defined as having two different name servers configured as master for the same zone.  In this article we configure two name servers and to be master name servers for a static zone called Our zone has dynamic DNS updates disabled and is statically managed.  Essentially, our two name servers become identical peer name servers or do they?!

First, we should ask the question -- why would someone want to create a pair of master name servers for the same zone?

Traditional BIND DNS configurations consisted of a single master name server, with multiple slaves that would pull zone transfers from the master. Under the traditional model, the single master can be considered a single point of failure. So, adding a pair of identically configured masters for a zone can add resiliency. Slaves now have the ability to perform zone transfers from either of the two masters.

What are some of the pitfalls to using multi-master DNS?

The most significant caveat to this design is that both masters MUST now be kept in sync and have identical data. Today's IPAM products will take care of that since the data is stored in a common database repository. Data is generated from the same source to these different name server targets. This ensures that we get identical data right? Well, sort of. Let's dig in and we'll explain.

Our environment for this article is:

  • VitalQIP 7.2
  • Solaris 10
  • Oracle 10g

In VitalQIP 7.2 multi-master DNS servers can be configured using a collection of CLIs, the Windows and/or UNIX thick client GUI, as well as, the new Web UI. Our high-level steps for accomplishing this are as follows:

  1. Create a static zone called (i.e. dynamic updates are disabled 'allow-update none;')
  2. Create
  3. Create
  4. Associate both name servers ns1 and ns2 as master or primary name servers to

We are not going to go into all the details of creating domains, and servers, as that is beyond the scope of this article. We will however, discuss required configuration parameters when defining the name servers. These parameters will have a direct bearing on the way that multi-master DNS behaves using the VitalQIP product.

There are two (2) very important server parameters that MUST be set correctly for multi-master support to function:

ParametersValue TypeOptionsUsage
Disable DNS communication (dynamic updates / SOA queries) from QIP Boolean True or False When set to True, the VitalQIP client does not attempt to send dynamic DNS updates to the DNS server or query for serial numbers on DNS generation. Also, the qip-genddnsconfs command does not include this server in the ddns.conf file that it generates for the DNS Update Service.
DNS Serial Number Query Type on Generation Text None, All Primaries, Target Only This parameter determines which servers are queried to determine the serial number of a zone. These values can be used:
  • None - does not do SOA queries during the push. Useful if there are no secondary name servers defined.
  • All Primaries - queries all primary servers for the SOA serial number. Required if there are secondary name servers that point to more than one primary server.
  • Target Only - queries only the DNS server that is being pushed to. Useful for organizations whose secondary servers point to only one primary name server.

Our configuration requires the following options be set for AND

  • "Disable DNS communication (dynamic updates / SOA queries) from QIP" = "False"
  • "DNS Serial Number Query Type on Generation" = "All Primaries"

What's next?

Assuming that the zone and servers are properly configured and the zone has data, it's time to perform a DNS generation. VitalQIP will generate a serial number of 1 if the zone is new. Otherwise, if the zone existed before, it will query all master name servers for the highest Serial number, and add two (2) to it. Let's assume for the purposes of this article that is brand new, and we push to It's serial number should be 1. Now lets perform a DNS generation to our second master, Done. Hey wait a minute! The serial number for on is 3 which is two higher than the serial number on

Upon close examination, the data is identical, but the serial numbers are off by two (2). Since we now have two masters for the same zone, it's assumed that we want to keep them in lock-step. We create a simply cron job to call a push script that looks like this:

# source VitalQIP env variables!
if [ -f /export/opt/qip/etc/shrc ]
    . /export/opt/qip/etc/shrc

$QIPHOME/usr/bin/qip-dnsupdate -n
$QIPHOME/usr/bin/qip-dnsupdate -n

Our cron job should keep them in sync shouldn't it?

The answer is sort of. The zone contents and RRs of will be almost completely identical. The ONLY thing that won't be identical is the Serial Number values in the SOA record on each server for

Why are the serial numbers not identical?

If we manually hard-code the Serial Number to 100 for on both and we can get them into sync. We do this by stopping named, and manually editing the files. When we start the name service on both ns1 and ns2, they load with a serial number of 100. Great, we have them in sync. Suppose at 12:00 midnight our DNS push script runs. This script pushes to both ns1 and ns2.

What is the result of our cron job to perform the DNS generation?

When the script executes the first call to qip-dnsupdate to, VitalQIP will query the BOTH ns1 and ns2 for their Serial Numbers for the zone Both return 100. VitalQIP will generate the files for with the serial number for set to 100 + 2 or 102. When the second call to qip-dnsupdate to occurs, VitalQIP will again query BOTH ns1 and ns2 for their serial numbers for the zone The server will return 102, and will return 100 for respectively. VitalQIP will take the higher of the two, 102 and set the serial number for on ns2 to 102 + 2 or 104. At this point, they have identical data, except that ns2 has a higher serial number than ns1. Below is a table that summarizes what serial numbers would result for if we executed our script four times.

Push Serial Serial #
0 100 100
1 102 104
2 106 108
3 110 112
4 114 116

What is the net effect?

Assuming we successfully push to both, the data is the same in all regards with the exception of the Serial Numbers. Slave name servers for that were configured to point to our multi-master configuration will have the following in their named.conf configuration:

zone "" {
    type slave;
    masters {;; };
    file "sec_qip/";

The exepected behavior is for both masters to have identical zone data and serial numbers for and the slaves would query each of the two masters, and have a 50-50 chance from which server they would initiate the transfer from. In our case, however, the slaves would likely initiate their zone transfers from since it's serial number is always higher by two (2) as shown in the figure below.


One possible way to enforce a better distribution of zone transfers between the masters would be to change our DNS generation script to using some form of RAND() function that randomly selects which of the two servers will be generated first and which second. This would more evenly distribute from which master the slaves would initiate zone transfers from.


Alcatel-Lucent VitalQIP DNS/DHCP & IP Management Software | Release 7.2 User's Guide 4-44 and 4-45