Linux Exercise 9 - DNS Replication

🧪 Exercise: Setting Up DNS Replication with a Secondary DNS Server

Introduction

In the previous lab, you configured a primary DNS server using BIND 9 to provide name resolution in your internal network.

But what happens if your DNS server goes down?
Without DNS, clients can’t reach services by name, even if the services themselves are still running.

DNS replication solves this by introducing a secondary (slave) DNS server. The secondary automatically synchronizes zone data from the primary. If the primary fails, the secondary can continue answering queries — ensuring name resolution still works.

By the end of this exercise, you will:

Understand the role of a secondary DNS server
Configure zone transfers between primary and secondary servers
Test DNS failover scenarios
Secure the replication with DNSSEC
Understand how DHCP configuration fits into this setup

1. Understanding DNS Replication

Primary vs Secondary DNS

Primary (master) DNS server:
- Holds the original zone files.
- Is authoritative for the zone.
- Allows zone transfers to secondaries.
Secondary (slave) DNS server:
- Doesn’t have editable zone files.
- Periodically or on notification copies the zone data from the primary.
- Answers queries just like the primary.

🔸 Important: Secondary servers are read-only. All changes happen on the primary and are replicated.

Why Replication Matters

High availability – If the primary goes offline, clients still get DNS responses.
Load sharing – Multiple DNS servers can handle more clients.
Resilience – Network issues or maintenance on one server won’t break the whole DNS service.

Scenarios to Consider

Scenario	What happens
Primary online, secondary online	Both respond to queries. Typically clients use the primary first.
Primary offline, secondary online	Secondary continues to serve queries with the last zone data.
Both offline	DNS fails.
Zone updated on primary	Secondary gets notified and pulls new zone data.
Secondary can’t reach primary for long	Secondary eventually expires the zone data and stops serving it (based on SOA expire timer).

2. DHCP and DNS Replication

If you have DHCP configured, you can provide multiple DNS server IPs to clients:

option domain-name-servers 192.168.56.10, 192.168.56.11;

The first IP (primary) is used first.
If it fails, clients automatically fall back to the secondary.

🔐 Note: DHCP does not handle replication itself. It only informs clients which DNS servers to use.
Zone replication happens directly between DNS servers.

3. Preparing the Secondary Server

You should have:

Primary DNS server: 192.168.56.10 (ns1.mynetwork.local)
Secondary DNS server: 192.168.56.11 (ns2.mynetwork.local)

3.1. Install BIND9 on the secondary

sudo apt update
sudo apt install bind9 bind9-utils -y

Enable and start the service:

sudo systemctl enable bind9
sudo systemctl start bind9

4. Configuring the Primary Server for Zone Transfers

4.1. Update zone definitions on the primary:

sudo nano /etc/bind/named.conf.local

Modify your existing zones:

zone "mynetwork.local" {
    type master;
    file "/etc/bind/db.mynetwork.local";
    allow-transfer { 192.168.56.11; };
    also-notify { 192.168.56.11; };
};

zone "56.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.168.56";
    allow-transfer { 192.168.56.11; };
    also-notify { 192.168.56.11; };
};

allow-transfer → authorizes the secondary server to pull zone data.
also-notify → immediately notifies the secondary of changes.

Restart BIND on the primary:

sudo systemctl restart bind9

Check for errors:

sudo named-checkconf

5. Configuring the Secondary Server

5.1. Define the zones as slave zones

On the secondary server:

sudo nano /etc/bind/named.conf.local

Add:

zone "mynetwork.local" {
    type slave;
    file "/var/cache/bind/db.mynetwork.local";
    masters { 192.168.56.10; };
};

zone "56.168.192.in-addr.arpa" {
    type slave;
    file "/var/cache/bind/db.192.168.56";
    masters { 192.168.56.10; };
};

type slave → this server mirrors the zone.
file → where it stores the copied zone data.
masters → IP of the primary server.

Restart BIND on the secondary:

sudo systemctl restart bind9

Check:

sudo named-checkconf
sudo systemctl status bind9

6. Testing Replication

6.1. Verify zone files on secondary

ls /var/cache/bind/

You should see:

db.mynetwork.local
db.192.168.56

6.2. Test resolution from the client

On the client VM, set the secondary as DNS:

dig @192.168.56.11 www.mynetwork.local

Expected: same result as querying the primary.

6.3. Simulate primary failure

Stop BIND on the primary:

sudo systemctl stop bind9

Test again from client:

dig @192.168.56.11 www.mynetwork.local

✅ The secondary should still resolve the names.

7. Securing the Zone Transfer with TSIG

By default, zone transfers are not encrypted but can be authenticated with TSIG (Transaction SIGnatures).

7.1. Generate a TSIG key on the primary

cd /etc/bind
sudo dnssec-keygen -a HMAC-SHA256 -b 256 -n HOST zonetransfer-key

Display the key:

cat Kzonetransfer-key.+*.key

Copy the secret part after IN KEY ....

7.2. Add the key to both servers

Primary (/etc/bind/named.conf.local):

key "zonetransfer-key" {
    algorithm hmac-sha256;
    secret "YOUR_KEY_HERE";
};

zone "mynetwork.local" {
    type master;
    file "/etc/bind/db.mynetwork.local";
    allow-transfer { key zonetransfer-key; 192.168.56.11; };
    also-notify { 192.168.56.11; };
};

zone "56.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.168.56";
    allow-transfer { key zonetransfer-key; 192.168.56.11; };
    also-notify { 192.168.56.11; };
};

Secondary (/etc/bind/named.conf.local):

key "zonetransfer-key" {
    algorithm hmac-sha256;
    secret "YOUR_KEY_HERE";
};

server 192.168.56.10 {
    keys { zonetransfer-key; };
};

zone "mynetwork.local" {
    type slave;
    file "/var/cache/bind/db.mynetwork.local";
    masters { 192.168.56.10 key zonetransfer-key; };
};

zone "56.168.192.in-addr.arpa" {
    type slave;
    file "/var/cache/bind/db.192.168.56";
    masters { 192.168.56.10 key zonetransfer-key; };
};

Restart BIND on both:

sudo systemctl restart bind9

Check logs:

sudo journalctl -u bind9

8. Securing the Zone Itself with DNSSEC

TSIG secures the transfer, not the data itself.
To protect against DNS spoofing, enable DNSSEC signing on the zone.

8.0. Research

Before you start setting up your security measures, do a little research and try to answer what DNS spoofing actually is, how this attack is possible without proper protection and why DNSSEC protects you against it.

8.1. Generate DNSSEC keys on the primary

cd /etc/bind
sudo dnssec-keygen -a RSASHA256 -b 2048 -n ZONE mynetwork.local
sudo dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE mynetwork.local

8.2. Sign the zone

sudo dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16)   -N increment -o mynetwork.local -t /etc/bind/db.mynetwork.local

This produces a signed zone file:

/etc/bind/db.mynetwork.local.signed

8.3. Use the signed file in the config

sudo nano /etc/bind/named.conf.local

zone "mynetwork.local" {
    type master;
    file "/etc/bind/db.mynetwork.local.signed";
    allow-transfer { key zonetransfer-key; 192.168.56.11; };
    also-notify { 192.168.56.11; };
    auto-dnssec maintain;
    inline-signing yes;
};

Restart BIND:

sudo systemctl restart bind9

DNSSEC data will also be transferred to the secondary.

9. Testing DNSSEC

From the client:

dig @192.168.56.10 www.mynetwork.local +dnssec

Look for the ad (authenticated data) flag in the response.

✅ Summary

You have:

Set up a secondary DNS server for redundancy.
Configured zone transfers and notifications.
Integrated with DHCP by adding multiple DNS IPs.
Secured zone transfers using TSIG.
Enabled DNSSEC to protect against spoofing.

Your network is now much more resilient and secure.