• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 385
  • Last Modified:

Multi BIND DNS server merge

I have been charged with the process of merging two separate sets of dns servers into one (each with a primary and secondary server). We have our primary and secondary bind dns server running BIND 9.2.1 on say and

The second set of dns servers are running BIND 9.2.4 on and

While we will eventually update all the domains on the second set of servers to list the nameservers of the first set of dns servers I would like to merge the second onto the first as soon as possible.

My question is, can I simply setup a second NIC that would run on the 10.10.10.x network and then add the second servers domains to the named.conf file of the first server?

Is there a better/easier solution?

Thank you in advance.
  • 2
  • 2
2 Solutions
GCaronAuthor Commented:
Would this be possible?

If the second set of dns servers are ns1.seconddns.com and ns2.seconddns.com and they resolve to and respectively and the first set of dns servers are ns1.firstdns.com and ns2.firstdns.com which resolve to and respectively. Could I simply update the associated ip addresses of ns1.seconddns.com and ns2.seconddns.com to point to and after adding the zones to the first servers?

Thanks again on any insight you can provide.

If you add the zones on the second pair of servers to the master of the first pair, as slaves, let them do a zone transfer, then change their status to masters and slave it to the other server that's the transfer done. You would be advised in advance of the change to lower the TTL of your dns results to say 300 seconds, so that once you change the NS records, stale results won't be floating around everywhere looking for the old servers.
There are a few important details left out of your question :

Are these internal or public servers ?
Are all clients able to reach both the 192.168.168.n and 10.10.10.n networks ?
Do you have a specific arrangement of servers in mind as a target ? (eg, do you want to end up with 4 servers all the same, just servers, or ...)

alextoft has already provided a basic mechanism to transfer zones.

Your secondary question : "Could I simply update the associated ip addresses of ns1.seconddns.com and ns2.seconddns.com to point to and after adding the zones to the first servers?" provides more hints, and the answer to that is Yes, you can do that. It might be better though to actually change the nameservers to ns1.firstdns.com and ns2.firstdns.com because this will make zone file management easier in the long term.

I'll assume that your end-plan is to have just 2 servers servicing all your clients for all the zones ...
First thing is, which 2 servers ? If you use and then these are (according to your example addresses) in the same subnet. You might consider keeping or  if it is on a separate network for better resilience - that is a separate issue, it doesn't have much effect on the process. Also, as an aside, if you have (for example) somedomain.com and somotherdomain.net, I would suggest using something like ns0.somedomain.com and ns1.somotherdomain.net as your nameservers - I recall a while ago when there was a problem with the .co.uk servers and all the isps that just had nsx.isp.co.uk as nameservers just vanished from the net, it's rare but s**t happens.

First thing is to get all the zones available on the servers you want. You already have a config file listing the zones (on the existing slave server), copy and paste the zone definitions into the configs for the other servers - don't forget that you may have to alter access controls if you restrict zone transfers etc.

Once the zones have transferred, you can go to the registrar(s) and change the nameserver settings.

Now, on the server you want to be master, promote all the slave zones to master, and demote the same zones to slave on the other server(s). Change ns records to match what you set at the registrar - eg if you choose to use ns1.firstdns.com and ns2.firstdns.com then these must be the servers listed both in the zone files and at the registrar.

Keep the old servers around and active for a while, that way there will be no problems caused by clients using cached information and querying servers which are no longer there. This should be for a minimum of the TTL value of the ns records - but I would give it several weeks longer if you can as I've seen clients accessing a server well after the dns should have timed out.

Once you have changed any systems which directly refer to the retiring server, you can shut them down (or disable DNS on them).

You will find http://dnsreport.com/ invaluable for testing !
GCaronAuthor Commented:
Hi FurnessSupport,

All the servers in question are on public ip, I was just using private ip addresses for the example. We have three primary servers on two separate networks for resilience. My end game is that I want to remove the seconddns.com servers completely.

From the two responses I believe my best course of action would be to setup the seconddns.com domains as slaves on my firstdns.com servers to zone transfer all the files then convert them to master (on the master) etc. I will then update the ip address of ns1.seconddns.com and ns2.seconddns.com to match ns1.firstdns.com and ns2.firstdns.com, leaving the old servers up for several weeks to handle cached information. Once that has been done I can, at my leisure, update the listed nameservers at each of the domains from seconddns.com to use the firstdns.com nameservers.

Does this sound about right?

Yes, that's about right. When you are tidying up the nameserver entries, just make sure that you keep the settings at the registry and the ns records in your zones in sync. There's be short periods when they won't agree, but it won't matter as long as they point to the same addresses.

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now