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 ns1.acme.com and ns2.acme.com to be master name servers for a static zone called acme.com. Our zone acme.com 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 acme.com (i.e. dynamic updates are disabled 'allow-update none;')
  2. Create ns1.acme.com
  3. Create ns2.acme.com
  4. Associate both name servers ns1 and ns2 as master or primary name servers to acme.com

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 ns1.acme.com AND ns2.acme.com:

  • "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 acme.com 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 acme.com is brand new, and we push to ns1.acme.com. It's serial number should be 1. Now lets perform a DNS generation to our second master, ns2.acme.com. Done. Hey wait a minute! The serial number for acme.com on ns2.acme.com is 3 which is two higher than the serial number on ns1.acme.com.

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:

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

$QIPHOME/usr/bin/qip-dnsupdate -n ns1.acme.com
$QIPHOME/usr/bin/qip-dnsupdate -n ns2.acme.com

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

The answer is sort of. The zone contents and RRs of acme.com 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 acme.com.

Why are the serial numbers not identical?

If we manually hard-code the Serial Number to 100 for acme.com on both ns1.acme.com and ns2.acme.com 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 acme.com 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 acme.com 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 ns1.acme.com, VitalQIP will query the BOTH ns1 and ns2 for their Serial Numbers for the zone acme.com. Both return 100. VitalQIP will generate the files for ns1.acme.com with the serial number for acme.com set to 100 + 2 or 102. When the second call to qip-dnsupdate to ns2.acme.com occurs, VitalQIP will again query BOTH ns1 and ns2 for their serial numbers for the zone acme.com. The ns1.acme.com server will return 102, and ns2.acme.com will return 100 for acme.com respectively. VitalQIP will take the higher of the two, 102 and set the serial number for acme.com 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 acme.com if we executed our script four times.

Push #ns1.acme.com Serial #ns2.acme.com 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 acme.com that were configured to point to our multi-master configuration will have the following in their named.conf configuration:

zone "acme.com" {
    type slave;
    masters { 1.1.1.1; 2.2.2.2; };
    file "sec_qip/db.acme.com";
};

The exepected behavior is for both masters to have identical zone data and serial numbers for acme.com 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 ns2.acme.com since it's serial number is always higher by two (2) as shown in the figure below.

multi-master-dns2

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.

Resources:

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