I l@ve RuBoard Previous Section Next Section

5.25 Promoting a Slave Name Server to the Primary Master

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.

    I l@ve RuBoard Previous Section Next Section