---
title: "Managing Manual Multi-master or multi-primary"
slug: "managing-manual-multi-master"
description: "It is relatively simple to switch a BIND server from secondary to primary in real time. Here's how."
tags: ["promote to master", "standby master", "master - slave", "primary", "secondary"]
updated: 2025-06-03T11:23:21Z
published: 2025-06-03T11:23:21Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing Manual Multi-master or multi-primary

:::(Info) (Primary, secondary, master, slave)
In the context of DNS, **primary** and **master** mean the same thing and **secondary** and **slave** mean the same thing.
In this document we will use the terms **primary** and **secondary**.
:::
Automatic multi-primary is really hard to do; just ask anyone who does database replication. However, manual multi-primary is easier as you have a human in the loop deciding which machine is primary.

In BIND 9, it is relatively simple to switch a server from *secondary* to *primary* in real time, if the secondary stores the zone data in a file. Simply redefine the zone type - change `type secondary;` to `type primary;` - and remove the `primaries` statement. For example:

#### Server with a secondary zone
```
zone "example.com" {
   type secondary;
   file "db.example.com";
   primaries {192.168.1.1;};
};
```
#### Converted to a primary zone
```
zone "example.com" {
   type primary;
   file "db.example.com";
};
```

However, if you have many thousands of zone files in your primary, modifying these zone blocks sequentially and then reloading BIND 9 will take a lot of time.

Switching a server from standby primary to active primary can be a simple as this, if you keep `/etc/named.active.conf` and `/etc/named.standby.conf` preconfigured for the two modes of operation:
```
cp /etc/named.active.conf /etc/named.conf
rndc reload
```

Then returning the active primary to standby:

```
cp /etc/named.standby.conf /etc/named.conf
rndc reload
```
### Example with dynamic update enabled

#### Active
```
zone example.com {
	type primary;
	masterfile-format raw;
	update-policy {};
	...
};
```
#### Standby
```
zone example.com {
	type secondary;
	masterfile-format raw;
	primaries { <other-primary>; <all-the-machines-that-transfer-from-one-of-these-primaries>; };
	update-forward { … };
		...
};
```
If dynamic update has been enabled, then you might use `rsync` or similar to keep `/etc/named.active.conf` and `/etc/named.standby.conf` up-to-date.

When you use all the secondaries as primaries to the standby primary, you have a very low probability of a lost update should the active primary die before the update makes it onto one of the secondaries.  `named` will almost certainly be up-to-date on the standby primary by the time it is promoted to active primary. This can be checked by verifying all the serial numbers for the zones.

You also need to be able to detect whether the second primary is in active or standby mode when you reboot the server. If you can’t determine this, put the server into standby mode using the following commands and cross-checking:

```
zone standby-mode {
   type primary;
   file "active.db";
};

zone standby-mode {
   type primary;
   file "standby.db";
};
```
:::(Internal) (Private notes)
Why is the same primary zone repeated in the example above? I'm not clear what this is trying to show.
:::
If you do not keep secondary zones in files, this solution will not work for you.

#### Why do I need a second primary?

Imagine this scenario: One primary may send a notify packet unsuccessfully with the increment of secondary DNS. You need one group of secondary servers to connect the first primary, and the other group of secondary servers to connect to the second primary. So these two primary zones must be fully consistent.

Or this one: If one primary goes down you need to switch to another primary right away, so the second primary needs to have the same zone and configuration as the first.   

Note that secondaries can be secondaries to multiple primary servers and servers can have multiple roles. One server can fetch one zone from its primary, but be a primary to another server for the same zone.

Multi-primary is an extremely complex topic, so this article cannot possibly answer all questions about it. Please feel free to post other questions on the [bind-users mailing list](https://www.isc.org/bind-users-mailing-list/), or [visit our website](https://www.isc.org/support/) to find out more about our support options.