Struggling with a DNS slave that won’t sync after a migration? This guide details the common causes (like journal file conflicts) and provides three field-tested solutions to get your zones transferring again.

DNS Slave Not Syncing After a Migration? Let’s Fix It.

I remember it vividly. It was 2 AM, during a “low-impact” maintenance window. The task was simple: migrate a secondary DNS server, `dns-slave-02`, to a new VM with a new IP. We powered down the old one, spun up the new one, copied over the BIND configs, updated the master’s `named.conf` with the new slave IP, and hit `rndc reload`. We waited. And waited. Nothing. The slave logs were eerily silent, and the master showed no attempts to initiate a zone transfer. What should have been a 15-minute job turned into a two-hour-long head-scratcher. That night taught me a valuable lesson about the hidden “state” of DNS that can turn a simple migration into a nightmare.

So, What’s Actually Going On? The “Why” Behind the Silence

When you’re in a panic, it’s easy to start shotgun-debugging—checking firewalls, ACLs, and app armor profiles. But 9 times out of 10, the problem is much simpler and lies with the zone’s serial number and the slave’s journal file.

Here’s the workflow in a nutshell:

• Your master DNS server has a zone file with a Serial Number in its SOA record (e.g., 2024052101).
• The slave server periodically checks in with the master and asks, “Hey, what’s your serial number for `example.com`?”
• If the master’s serial is higher than the slave’s, the slave requests a zone transfer (AXFR/IXFR).

The problem arises when you migrate. If you copied the old zone files and their corresponding journal files (.jnl) to the new slave, the new server wakes up with an existing state. It might believe its serial number is already current, or even newer than the master’s, especially if something went wrong during the copy. The slave sees no reason to request an update, and you get silence.

The Fixes: From a Quick Nudge to a Full Reset

Alright, enough theory. You’re here because your DNS is broken and your boss is asking for an ETA. Let’s get this fixed. Here are three ways to solve this, from the least invasive to the most aggressive.

Solution 1: The “By the Book” Fix (The Serial Bump)

This is the cleanest and most professional way to handle it. You’re not touching the slave at all; you’re simply telling the master, “Hey, there’s a new version,” which forces all slaves to re-evaluate and sync.

Steps:

1. SSH into your master DNS server (e.g., `dns-master-01`).
2. Edit the zone file that isn’t transferring. I’ll use `our-app.internal` as an example.

sudo vim /var/named/zones/db.our-app.internal

3. Find the SOA record at the top of the file. You’ll see the serial number, usually in a YYYYMMDDNN format.

; Original SOA Record
@       IN      SOA     dns-master-01.example.com. hostmaster.example.com. (
                        2024052101      ; Serial
                        3600            ; Refresh
                        ...

4. Simply increment the serial number by one.

; Updated SOA Record
@       IN      SOA     dns-master-01.example.com. hostmaster.example.com. (
                        2024052102      ; Serial - I incremented this!
                        3600            ; Refresh
                        ...

5. Save the file and tell BIND to reload its configuration and zones.

sudo rndc reload

6. Now, on your slave server, tail the logs. You should see the transfer happen almost immediately.

tail -f /var/log/messages | grep named

Pro Tip: Using the `YYYYMMDDNN` format for serials is a lifesaver. `YYYYMMDD` is the date, and `NN` is a two-digit counter for changes made on that day (00, 01, 02…). It makes auditing changes so much easier than just incrementing a random integer.

Solution 2: The “Nuke and Pave” Option (The Clean Slate)

Sometimes the serial bump doesn’t work, or the slave’s state is so corrupted that it’s easier to just start fresh. This method involves deleting the slave’s copy of the zone file, forcing it to realize it has nothing and needs to perform a full transfer (AXFR).

Steps:

1. SSH into your problematic slave DNS server (e.g., `dns-slave-01`).
2. Stop the BIND/named service. Don’t skip this step!

sudo systemctl stop named

3. Navigate to the directory where BIND stores its slave zone files. This path is defined in your `named.conf` options. It’s often `/var/named/slaves` or `/var/named/data/`.

cd /var/named/slaves/

4. Delete (or better yet, move) the problematic zone file and its journal file. The .jnl file is the real troublemaker here.

# Backup first, just in case!
sudo mv db.our-app.internal db.our-app.internal.bak

# Now delete the journal file. This is the critical part.
sudo rm db.our-app.internal.jnl

5. Restart the BIND service.

sudo systemctl start named

6. Check your logs. The slave will start up, see it’s configured to serve `our-app.internal` but has no local file, and immediately request a full download from the master.

Warning: This is a destructive action. While it’s safe for a slave (since the master is the source of truth), always be 100% sure you are on the correct server before running `rm`. Deleting a zone on the master is a very, very bad day.

Solution 3: The “Get It Done Now” Fix (The Rsync Shuffle)

Let’s be honest. Sometimes it’s 3 AM, the change window is closing, and you just need the server to work. This is the “hacky but effective” approach. We’re going to manually copy the zone file from the master to the slave, bypassing the transfer mechanism entirely to get the slave into a known-good state.

Steps:

1. SSH into your slave DNS server and stop BIND.

sudo systemctl stop named

2. From the slave server, use `scp` or `rsync` to pull the zone file directly from the master. I prefer `rsync`.

# Syntax: rsync [user]@[master_host]:[source_path] [destination_path]
sudo rsync -avz root@dns-master-01:/var/named/zones/db.our-app.internal /var/named/slaves/

3. Fix the ownership and permissions on the newly copied file. It needs to be owned by the user that BIND runs as (usually `named` or `bind`).

sudo chown named:named /var/named/slaves/db.our-app.internal

4. Start BIND back up.

sudo systemctl start named

Now, the slave has an identical copy of the master’s zone file. While this gets you online immediately, it doesn’t fix the underlying sync issue. You should still follow up with a serial bump (Solution 1) to ensure future automatic transfers work as expected.

In the end, that 2 AM incident was solved with Solution 2. We nuked the old journal file, and everything snapped into place. It’s a humbling reminder that even in complex systems, the fix is often about finding and resetting a tiny piece of forgotten state.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions