5.25.1 Problem
You want to "promote" a slave name server to be the primary master name server.
5.25.2 Solution
Change the zone statement for the zones you want the slave to be primary master for from type slave to type master, and delete the masters substatements. For example, this zone statement:
zone "foo.example" { type slave; masters { 192.68.0.1; }; file "bak.foo.example"; };
Becomes this zone statement:
zone "foo.example" { type master; file "bak.foo.example"; };
If you allow dynamic updates to any of the zones, change the MNAME field of those zones' SOA records to the domain name of the new primary and add an allow-update or update-policy substatement. For example:
zone "foo.example" { type master; file "bak.foo.example"; allow-update { 192.168.0.1; }; };
If you restricted zone transfers from the old primary, duplicate the allow-transfer substatement from the old zone statement.
Then reload the name server with rndc reload or ndc reload, as appropriate.
If you followed the instructions in Section 5.24 and set up the slaves to use this name server as their backup master, you're done. If not, you'll need to reconfigure your slaves to use the new primary as their master. Just change the IP address in the masters substatement to the address of the new primary and reload.
5.25.3 Discussion
If you're so inclined, you can rename the zone data file to fit your standard for primary master zones. For example, we might rename bak.foo.example to db.foo.example.
Check the zone statement on the old primary master for other substatements that you might need to duplicate on the new primary master, such as also-notify and check-names.
5.25.4 See Also
Section 5.24 and "Coping with Disaster" in Chapter 8 of DNS and BIND.
Getting Started
Zone Data
BIND Name Server Configuration
Electronic Mail
BIND Name Server Operations
Delegation and Registration
Security
Interoperability and Upgrading
Resolvers and Programming
Logging and Troubleshooting
IPv6