DNS Server migration from HP-UX to RHEL

[Arunabha Banerjee]

Dear Expert,

I want to migrate DNS server from HP-UX (11..11) to RHEL (7.3). I don't want to change any configuration in the target environment, i.e. on HP-UX (because of server uptime [more than 3 years] and complexity). I want to set up a secondary/slave DNS server in the target environment i.e. on RHEL and replicate the configuration. During cutover, I will change target DNS server (RHEL) role from secondary/slave to primary, and if it fails I will immediately bring up the primary (HP-UX) server. I just wanted to know the best practice, steps, and feasibility to do the same without any changes in the source environment (HP-UX).

Thanks in advance.

Arunabha

[Matti_Kurkela]

Which version of BIND the old server is running?

At cutover time, are you planning to give the IP address of the old server to the new server? Or is the new server going to keep its current IP address through the cutover?

There is at least one change you must do to the current server in every case: you must configure it to allow zone transfers to the new server. If the new server is going to get the old server's IP address at cutover, this is probably best achieved by adding an allow-transfer clause to the configuration of the old server (if it's a reasonably modern BIND 9.x; for older servers it might be different).

But if the new server is going to keep its current IP address through the cutover, you'd better add the new server into the NS records of your zones. In this case, you should also contact the administrator of the higher-level domain(s), to update your zones' delegation and glue records accordingly at cutover time.

[Arunabha Banerjee]

BIND Version 9.3.2 - Old Server (HP-UX 11.11)
BIND Version 9.9 - Target Server (RHEL 7.3)

As you have mentioned during cutover time we are planning to give the IP address and hostname of the old server to the new server.

During lab test (primary DNS and slave DNS both on RHEL 7.3 and BIND version is 9.9) I have found without adding "allow-transfer" entry in the Primary DNS "named.conf" we are able to transfer zone from primary to slave DNS server. I believe "allow-transfer" is not mandatory for zone transfer from primary to slave, default it is allowed. So once zone transfer is complete I will make changes in "named.conf" in the target to make it primary.

From:

zone "lab.com" {
          type slave;
          file "lab.fwd.zone";
          masters { 192.168.0.201; };
};
zone "0.168.192.in-addr.arpa" {
          type slave;
          file "lab.rev.zone";
          masters { 192.168.0.201; };
};

To

zone "lab.com" {
          type master;
          file "lab.fwd.zone";
};
zone "0.168.192.in-addr.arpa" {
          type master;
          file "lab.rev.zone";
};

Once the changes have been made we will stop named service in the old primary (HP-UX) and then give the old hostname and IP address to the new primary (RHEL) and restart named service.

Let me know if you agree with this plan.

[Matti_Kurkela]

As far as transferring the zone data is concerned, your plan will work. However, there may be consequences to people trying to resolve your zone out there in the internet.

You said:

I believe "allow-transfer" is not mandatory for zone transfer from primary to slave, default it is allowed.

That's true... but how exactly does the primary server know that a particular DNS server is a valid slave for it?

The answer is: by the NS records of the zone. And those NS records also have another effect: they will announce the existence of the new slave to the worldwide internet, if your zone is public.

So, after one TTL cycle after adding the slave, pretty much every resolving DNS server out in the internet that needs to resolve names from your zone will definitely see the new NS record, and will cache it. From that point on, as long as they have the new NS record cached, they will have an 1/(number of NS records in your zone) probability of sending their queries about your zone to the new slave.

If the new slave is not publicly reachable (it's set up for the migration only, after all), for the observer outside your environment, it will look like your zone's DNS server is slow or has some problems, as some DNS requests will get sent to the unreachable slave first, before they time out and get re-sent to another authoritative server.

Of course, caching at the resolver server level will minimize this problem, but it is not ideal.

Once you do the cutover and move the new server to the IP address the old server had, at that point you should also remove the slave NS records created for the migration. But that change, too, will take one TTL cycle to fully propagate to the worldwide internet. Only after that time has passed, you can be sure that the world will no longer try to send requests for your zone's data to the slave server you've just removed. Before that, you'll have a period of time during which your DNS may again seem somewhat flakey when viewed from the internet.

The allow-transfer configuration keyword allows setting up unannounced slave servers, or "stealth-slaves": just instead of adding a NS record for the new slave, add an allow-transfer setting to the primary server's configuration. To make sure that the unannounced slave gets any zone updates as quickly as possible, you might want to use the also-notify keyword too. On the slave server, there is no difference in set-up between a regular slave and a stealth-slave.

The end result of the stealth-slave procedure is that you can have a slave DNS server for your zone(s) without having to announce its existence to the public, and thus not having anyone send any queries to the new slave server. This is ideal for migration procedures like the one you're planning.