Bobcares

Configure DNS Master Slave replication in PowerDNS | How to

by | Oct 30, 2021

Configure DNS Master Slave replication in PowerDNS like a pro with help from our skilled Support Team.

 

At Bobcares, we offer solutions to every query that comes our way as a part of our much sought after Server Management Service

 

Let’s take a look at how our proficient Support Techs configured the DNS Master Slave replication for one of our clients recently.

How to configure DNS Master Slave replication in PowerDNS

In order to configure the DNS Master-Slave replication in PowerDNS, we need to install and configure PowerDNS as a part of the prerequisites. After that, we will make the changes mentioned in this article in the pdns.conf file. Before we proceed, keep the following assumptions in mind:

  • ns1 – master – 192.168.250.52
  • ns2 – slave – 192.168.250.152
  • ns3 – slave – 192.168.250.252

DNS Master Slave replication: Master Configuration

Here, we define two options, namely allow-axfr-ips and master here. allow-axfr-ips option informs PowerDNS about endpoints that can initiate as well as receive zone transfers.

For instance, here ns2.example.com runs on 192.168.250.152 and ns3.example.com runs on 192.168.250.252. In other words, these IPs are cleared for zone transfers.

We can also define complete ranges like 192.168.250.0/25. However, our Support Engineers prefer to keep restrict zone transfers to the minimum.

cp -pv /etc/powerdns/pdns.conf /etc/powerdns/pdns.conf-bkp22;
vim /etc/powerdns/pdns.conf
allow-axfr-ips=192.168.250.152,192.168.250.252

Next, we will set the master parameter to “yes” as seen below:

master=yes

After these changes, we will restart PowerDNS with this command:

systemctl restart pdns

DNS Master Slave replication: Slave Configuration

On slave servers, we will set slave to yes in pdns.conf. This informs PowerDNS this is a slave server. Furthermore, we can also keep the slave server up to date with its master with the slave-cycle-interval option without waiting for the NOTIFY command as seen below:

cp -pv /etc/powerdns/pdns.conf /etc/powerdns/pdns.conf-bkp23;
vim /etc/powerdns/pdns.conf
slave=yes
slave-cycle-interval=60

 

Next, we will add the master server to the backend config as well. The data includes the following three values:

  1. IP address of DNS server, 192.168.250.52 in this scenario
  2. FQDN of slave server
  3. Role to be assigned, admin role in this scenario

Our Support Engineers would like to remind you that each slave will have its own FQDN.

 

Hence, on NS2:

mysql
use pdns;
insert into pdns.supermasters values ('192.168.250.52', 'ns2.example.com', 'admin');

 

Similarly on NS3:

mysql
use pdns;
insert into pdns.supermasters values ('192.168.250.52', 'ns3.example.com', 'admin');

 

Then, we will restart PowerDNS with this command

systemctl restart pdns

 

Testing the replication

After adding a new zone to the master server, we will run the following code if nothing happens:

root@master:~# pdnsutil create-zone replicateme.dev
Creating empty zone 'replicateme.dev'

 

In case the domain does not show up on the slave, we will run this code:

root@slave:~# pdns_control list-zones | grep replicateme

 

Moreover, since the zone does not have NS entries yet, the next step is to NS entries for NS1 and NS2 with the following command:

pdnsutil add-record replicateme.dev @ NS ns1.example.com;

pdnsutil add-record replicateme.dev @ NS ns2.example.com;

 

For instance:

root@master:~# pdnsutil add-record replicateme.dev @ NS ns1.example.com
New rrset:
replicateme.dev. IN NS 3600 ns1.example.com

root@master:~# pdnsutil add-record replicateme.dev @ NS ns2.example.com
New rrset:
replicateme.dev. IN NS 3600 ns1.example.com
replicateme.dev. IN NS 3600 ns2.example.com

 

After that, we will increase the zone’s serial and then use notify command:

pdnsutil increase-serial replicateme.dev;

pdns_control notify replicateme.dev;

 

For instance:

root@master:~# pdnsutil increase-serial replicateme.dev
SOA serial for zone replicateme.dev set to 2019040101

root@master:~# pdns_control notify replicateme.dev
Added to queue

 

This results in the following log entries on the slave server:

Apr  3 11:00:10 slave pdns_server[19627]: Received NOTIFY for replicateme.dev from 192.168.250.52 for which we are not authoritative
Apr  3 11:00:10 slave pdns_server[19627]: Created new slave zone 'replicateme.dev' from supermaster 192.168.250.52
Apr  3 11:00:10 slave pdns_server[19627]: 1 slave domain needs checking, 0 queued for AXFR
Apr  3 11:00:10 slave pdns_server[19627]: Received serial number updates for 1 zone, had 0 timeouts
Apr  3 11:00:10 slave pdns_server[19627]: Domain 'replicateme.dev' is stale, master serial 2019040101, our serial 0
Apr  3 11:00:10 slave pdns_server[19627]: Initiating transfer of 'replicateme.dev' from remote '192.168.250.52'
Apr  3 11:00:10 slave pdns_server[19627]: Starting AXFR of 'replicateme.dev' from remote 192.168.250.52:52
Apr  3 11:00:10 slave pdns_server[19627]: AXFR started for 'replicateme.dev'
Apr  3 11:00:10 slave pdns_server[19627]: AXFR of 'replicateme.dev' from remote 192.168.250.52:52 done
Apr  3 11:00:10 slave pdns_server[19627]: Backend transaction started for 'replicateme.dev' storage
Apr  3 11:00:10 slave pdns_server[19627]: AXFR done for 'replicateme.dev', zone committed with serial number 2019040101

 

Furthermore, this causes the domain to show up on the slave and we can query it as seen below:

pdns_control list-zones | grep replicateme;

dig -t NS replicateme.dev @localhost +short;

 

For instance:

root@slave:~# pdns_control list-zones | grep replicateme
replicateme.dev.

root@slave:~# dig -t NS replicateme.dev @localhost +short
ns1.example.com.
ns2.example.com.

 

Ultimately, the master config in the /etc/powerdns/pdns.conf file will look like this:

allow-axfr-ips=135.181.95.52
allow-dnsupdate-from=127.0.0.0/8,::1
allow-notify-from=0.0.0.0/0,::/0
api=yes
api-key=oL7TzKcAGGgmkdkb
default-soa-content=pdns1.maxihoster.com. sysadmin.maxihoster.com. 2021101402 21600 3600 1209600 21600
disable-axfr=no
disable-syslog=no
include-dir=/etc/powerdns/pdns.d
launch=
log-dns-queries=yes
log-timestamp=yes
loglevel=5
master=yes
primary=yes
query-logging=yes

 

Moreover, the slave config in the /etc/powerdns/pdns.conf file will be similar to this:

api=yes
api-key=lgAw2d170Y4mzyQw
disable-syslog=no
include-dir=/etc/powerdns/pdns.d
launch=
local-address=0.0.0.0, ::
local-port=52
log-dns-queries=yes
log-timestamp=yes
query-logging=yes
slave=yes
slave-cycle-interval=60
superslave=yes

[Need further assistance? We are just a click away.]

Conclusion

In brief, the Support Engineers demonstrated how to configure DNS Master Slave replication in PowerDNS with ease.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Never again lose customers to poor
server speed! Let us help you.

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF