0

There are two ways to ways to tell bind9 which zones to load: list them in named.conf (or the files included from it), and manage them with rndc addzone, rndc delzone etc.

If I want to move from the first option to the second, is there any way to do that without any downtime?

If I remove a zone from named.conf, I have to reload the config before I can run rndc addzone <zone>; but that way the zone is gone between the reload and the rnd rndc addzone command.

(Which wouldn't be too bad for one zone, but I want to migrate several thousand zones).

I use bind9 version 9.11.5, if that matters.

moritz
  • 151
  • 1
  • 5
  • 1
    Shouldn't your secondary nameserver be able to keep up the service for the zone while you swap it on the primary? Thus, no downtime. – Tilman Schmidt Mar 07 '21 at 15:14

1 Answers1

1

I don't know that there is any tooling provided for this, but my suggestion for an approach would be:

  • Decide what is actually acceptable (I'm going to go with what was suggested by "which wouldn't be too bad for one zone", that minimal downtime might be ok rather than a strict "no downtime" requirement)
  • Clone the environment so that you can test this particular migration scenario
  • Write a script that enumerates the zone names and the bodies of the zone definitions from a config (the two main things that you will want to feed to rndc addzone)
  • Run it, and make sure it works. I suppose the state you need to be in is: named running, old zone definitions not loaded but available in a file for your script (easy if those are isolated to some specific include file(s))
  • Determine if it's quick enough to be acceptable in terms of downtime. If not, consider an approach of doing it "TV chef-style", having the resulting output already prepared and then just doing an "Indiana Jones-style" swap between old files and new files during downtime.
Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90