How To Configure DNS Replication on a Slave PowerDNS Server on Ubuntu 14.04

Introduction

In this tutorial we will learn how to set up PowerDNS in a master/slave configuration with automatic replication from the master DNS server to the slave. This tutorial is the second tutorial in our PowerDNS series for Ubuntu.

A master/slave configuration provides additional reliability. If one of your PowerDNS servers goes down, you will have a secondary server to handle the requests.

We recommend provisioning these servers in seperate data centers. If they are in two physical locations, then even a data center outage would not affect your DNS service.

By the end of this tutorial we will have two functional PowerDNS servers using master/slave replication.

Prerequisites

Please complete these requirements:

• Two 512 MB Droplets or larger with Ubuntu 14.04 64-bit. 512 MB should be plenty to run a PowerDNS server with a moderate number of zones/records
• A sudo user
• How To Install and Configure PowerDNS with a MariaDB Backend on Ubuntu 14.04 (details in Step 1)
• Glue records and nameserver settings for domains configured at your registrar

In our previous tutorial, we pointed three subdomains to a single PowerDNS server. We will now be using one of these subdomains to point at our slave server. In our examples our master server IP will be 111.111.111.111, and our slave server IP will be 222.222.222.222.

You will need to update the glue records with your provider accordingly. Please use the information below as a guide. See the previous PowerDNS tutorial for more information on configuring your DNS records.

• hostmaster.example-dns.com 111.111.111.111 (Master Server)
• ns1.example-dns.com 111.111.111.111 (Master Server)
• ns2.example-dns.com 222.222.222.222 (Slave Server)

Note that you should set up both glue records and SOA records at your registrar for the domain used for the nameservers themselves. On the other hand, you need only SOA records for other domains whose zone files you want to host on your custom nameservers.

Step 1 — Install PowerDNS on Both Servers

First, we need to have two functional PowerDNS servers. One server will become our master server, while the second one will become our slave server.

If you haven’t done so already, please follow the previous tutorial, How To Install and Configure PowerDNS with a MariaDB Backend on Ubuntu 14.04.

You should follow the complete tutorial on your master server.

You can follow just Steps 1-7 on your slave server, since we don’t need Poweradmin on the secondary server.

When you have two functional PowerDNS servers, with at least one of them running Poweradmin, you can proceed to the next step.

Step 2 — Configure Master Server (ns1.example-dns.com)

We are now ready to configure our master PowerDNS server.

This should be the server that has Poweradmin installed, and will be considered your primary DNS server. If you have Poweradmin installed on both servers, you may use either one. If you’re following this example, this should be ns1.example-dns.com.

Back up the original configuration file.

cd /etc/powerdns
sudo mv pdns.conf pdns.conf.orig

Create our new configuration file.

sudo nano pdns.conf

The details below are for a standard master server configuration with a single slave server. We will enter the slave server IP address, allowing it to communicate with this master server. Remember to substitute your own slave server IP address below.

Note: /32 is a single IP subnet, and required for this configuration.

allow-recursion=0.0.0.0/0
allow-axfr-ips=222.222.222.222/32
config-dir=/etc/powerdns
daemon=yes
disable-axfr=no
guardian=yes
local-address=0.0.0.0
local-port=53
log-dns-details=on
log-failed-updates=on
loglevel=3
module-dir=/usr/lib/powerdns
master=yes
slave=no
setgid=pdns
setuid=pdns
socket-dir=/var/run
version-string=powerdns
include-dir=/etc/powerdns/pdns.d

Restart the PowerDNS service for changes to take effect.

sudo service pdns restart

Step 3 — Configure Slave Server (ns2.example-dns.com)

Now we are ready to configure our slave server. This server will replicate DNS zones from the master server we just configured. If you’re following along with the example, this should be ns2.example-dns.com.

Back up the original configuration file.

cd /etc/powerdns
sudo mv pdns.conf pdns.conf.orig

Create the new configuration file.

sudo nano pdns.conf

The details below are for a standard slave server configuration with a 60-second refresh interval. You can copy the configuration exactly.

allow-recursion=0.0.0.0/0
config-dir=/etc/powerdns
daemon=yes
disable-axfr=yes
guardian=yes
local-address=0.0.0.0
local-port=53
log-dns-details=on
log-failed-updates=on
loglevel=3
module-dir=/usr/lib/powerdns
master=no
slave=yes
slave-cycle-interval=60
setgid=pdns
setuid=pdns
socket-dir=/var/run
version-string=powerdns
include-dir=/etc/powerdns/pdns.d

Every 60 seconds, the slave server will query the master server for zone updates. Typically when a zone is updated, the master server will send a notification to the slave servers assigned to that zone. However, if there is a connection issue during a zone update, this ensures the update will eventually propegate to the slave server when it is online again.

Next we need to tell PowerDNS how to communicate with the master server.

Log in to MariaDB with the PowerDNS username and password you created in the previous tutorial. Our example used powerdns_user.

mysql -u powerdns_user -p

Enter your password at the prompt:

Output
Enter password:

Change to the PowerDNS database you configured in the previous tutorial. Our recommendation was powerdns.

USE powerdns;

Next we will crate a new row in the supermasters table. This row will specify the master server IP address, and the Fully Qualified Domain Name (FQDN) of the slave server we are currently configuring.

insert into supermasters values ('111.111.111.111', 'ns2.example-dns.com', 'admin');

We can now exit the MariaDB shell.

exit;

Restart the PowerDNS service for changes to take effect.

sudo service pdns restart

Step 4 — Test Master/Slave Connection

This step requires ns1.example-dns.com to be pointing to your master server, and ns2.example-dns.com to be pointing to your slave server.

If your glue records, SOA records, and A records haven’t propagated yet, you can add an override to your /etc/hosts file. You will want to do this on both servers.

Open the /etc/hosts using nano.

sudo nano /etc/hosts

Add the entries to your /etc/hosts file.

111.111.111.111 ns1.example-dns.com
222.222.222.222 ns2.example-dns.com

Let’s make sure our two servers can communicate now.

From your master server, ping both hostnames.

ping ns1.example-dns.com

Your result should look like this:

Output
64 bytes from ns1.example-dns.com (111.111.111.111): icmp_seq=1 ttl=64 time=0.061 ms

Ping the slave server:

ping ns2.example-dns.com

Expected result:

Output
64 bytes from ns2.example-dns.com (222.222.222.222): icmp_seq=1 ttl=64 time=48.8 ms

Now, ping both hostnames from your slave server, using the same commands. Once you can ping both servers from both server, continue.

Step 5 — Configure a DNS Zone with Replication

If both servers are communicating properly we are ready to create our first DNS zone with master/slave replication.

Log in to Poweradmin on your master server by visitng http://111.111.111.111/poweradmin/ in your browser.

Log in with the admin credentials you set earlier.

Click the Add master zone link to create a new zone file. You can test this with the original name or a new domain, test.com.

Enter your top-level domain name, and click the Add zone button to create the zone.

Create NS entries for your name servers:

• hostmaster.example-dns.com
• ns1.example-dns.com
• ns2.example-dns.com

Create at least one A record to test replication.

Note: If your Slave Server is not listed as a name server for the zone, it will not replicate the zone.

After a few seconds the new entries should propagate to your slave server.

Test the DNS record saved at ns1.example-dns.com using dig.

dig test.com A @ns1.example-dns.com

It should respond with a result similar to the one below.

Output
root@ns1:/etc/powerdns# dig test.com A @ns1.example-dns.com

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> test.com A @ns1.example-dns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44833
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 2800
;; QUESTION SECTION:
;test.com.                      IN      A

;; ANSWER SECTION:
test.com.               86400   IN      A       104.131.174.138

;; Query time: 2 msec
;; SERVER: 45.55.217.94#53(45.55.217.94)
;; WHEN: Tue Apr 28 18:06:54 EDT 2015
;; MSG SIZE  rcvd: 53

Test the DNS record saved at ns2.example-dns.com using dig.

dig test.com A @ns2.example-dns.com

It should respond with a result similar to the one below.

Output
root@ns1:/etc/powerdns# dig test.com A @ns2.example-dns.com

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> test.com A @ns2.example-dns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11530
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 2800
;; QUESTION SECTION:
;test.com.                      IN      A

;; ANSWER SECTION:
test.com.               86400   IN      A       104.131.174.138

;; Query time: 3 msec
;; SERVER: 45.55.217.132#53(45.55.217.132)
;; WHEN: Tue Apr 28 18:08:06 EDT 2015
;; MSG SIZE  rcvd: 53

Remember that the settings for test.com will only become active after setting your nameservers to ns1.example-dns.com and ns2.example-dns.com at your registrar.

Conclusion

We now have two functional PowerDNS servers using a MariaDB backend in a master/slave configuration.

Any time changes are made to a master zone on the master server, it will notify any slave servers listed with their own NS records.

The slave server will automatically query the Master Server for records that have not been updated recently, ensuring your DNS records stay in sync among your PowerDNS nodes.