Promote slave DNS server

[Leroy Tennison]

If there is already an ISC document I didn't find it, please provide the URL. I just added a slave of a master for disaster recovery and now need to know how to promote it should the master be offline too long. What I have found so far is:

1. For the zone definitions in /etc/named.conf (or equivalent):
(a) Change the “type” statements from ”slave” to “master” and remove the “masters” statement.
(b) Add “allow-update” and “allow-transfer” statements as appropriate.
(c) Possibly add “also-notify” statements as appropriate.
2. Add key definitions if needed
3. If “masterfile-format text” wasn't used in named.conf.local convert the zone files to text using named-compilezone including the -j parameter.
4. If the server's name is different than the former master then the SOA record for each (to be ) master zone must be updated. Since rndc
freeze/thaw doesn't work on slave zones the server probably needs to be shut down.
5. Change the MNAME to the new server name

Anything I've missed? Thanks for your help. I also have a question about DNS and keepalived but I'll make that another post.


Join us
at the 2018 Momentum User Conference!
Register
here
Leroy Tennison
Network Information/Cyber Security Specialist
E: ***@datavoiceint.com
2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com
TThis message has been sent on behalf
of a company that is part of the Harris Operating Group of
Constellation Software Inc. These companies are listed
here
.
If you prefer not to be contacted by Harris
Operating Group
please notify us
.
This message is intended exclusively for the
individual or entity to which it is addressed. This communication
may contain information that is proprietary, privileged or
confidential or otherwise legally exempt from disclosure. If you are
not the named addressee, you are not authorized to read, print,
retain, copy or disseminate this message or any part of it. If you
have received this message in error, please notify the sender
immediately by e-mail and delete all copies of the
message.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.

[Grant Taylor via bind-users]

Post by Leroy Tennison
If there is already an ISC document I didn't find it, please provide
the URL.

I'm not aware of any such best practices type document. I too would be
interested in reading it is it exists.

Post by Leroy Tennison
I just added a slave of a master for disaster recovery and now need to
know how to promote it should the master be offline too long.

The first thing I would do is make sure the expiry timer is sufficiently
high. I'd likely go with something between multiple days and a month.

Post by Leroy Tennison
(a) Change the “type” statements from ”slave” to “master”
and remove the “masters” statement. (b) Add “allow-update”
and “allow-transfer” statements as appropriate. (c) Possibly add
“also-notify” statements as appropriate. 2. Add key definitions
if needed

I took a slightly different approach to this the last time I had this
problem.

I created an intermediary file that was a list of the zones that I
needed to be able to quickly switch between master and slave. Then I
used that file as data for a script (really different m4 macros) to
create the proper configurations (at the same time) for both master and
slave operating modes. Each configuration was (effectively) stored in
their own file; /etc/named/zones.master.conf and
/etc/named/zones.slave.conf. Then I would dynamically update a sym-link
to point to the operating mode of the server.

Master:
/etc/named/zones.conf -> /etc/named/zones.master.conf

Slave:
/etc/named/zones.conf -> /etc/named/zones.slave.conf

My main named.conf file would then simply include the
/etc/named/zones.conf file.

Post by Leroy Tennison
3. If “masterfile-format text” wasn't used in named.conf.local convert
the zone files to text using named-compilezone including the -j parameter.

I prefer to keep my zones in text format. But I thought that the same
binary file format could be used for master and slave zones. - I could
be wrong about this.

Post by Leroy Tennison
4. If the server's name is different than the former master then the
SOA record for each (to be ) master zone must be updated.

IMHO the MNAME does not need to be changed. (More details below.)

Post by Leroy Tennison
Since rndc freeze/thaw doesn't work on slave zones the server probably
needs to be shut down.

You are going to need to reconfigure all the zones that you want to
change role. IMHO the easiest way to do that is to shut down BIND,
change the config file (read: change where the /etc/named/zones.conf
file points to) and restart BIND.

It may be possible to dynamically reconfigure BIND but I've never gone
there as I found the method I'm describing to work satisfactorily well.

Post by Leroy Tennison
5. Change the MNAME to the new server name

I decided to go a different route with this.

I created a (bogus) record / hostname that was used specifically for the
MNAME parameter of the SOA record. I.e. soa.example.com

I then created (and properly delegated) the soa.example.com zone in the
parent zone, example.com. Then I would have different local versions of
the soa.example.com zone on each DNS server.

That way, the parent zone would say that the MNAME was soa.example.com,
which each local server would resolve from it's local specific version
of the zone to itself.

Post by Leroy Tennison
Anything I've missed? Thanks for your help. I also have a question
about DNS and keepalived but I'll make that another post.

I don't know that it applies to your example, but you may need to also
allow dynamic updates on the new master. This should be doable, but may
be an added complication that you need to overcome.

The only other problem that I've seen people run into is what I call the
"return to home problem". How do you gracefully make the transition
back the other way? Especially if you have any updates that originated
on the slave->master that need to be propagated back to the original master.