DNS migration:  Moving from homegrown BIND DNS to the BlueCat Adaptive DNS solution

In two recent posts, we talked about the operational downsides of homegrown BIND DNS infrastructures, and how it can stand in the way of digital transformation.  “That’s all very good,” you might be thinking.  “But migrating away from BIND is just as difficult to manage, if not more so.”

It’s no secret that Domain Name System (DNS) migrations entail a lot of inherent DNS outage risk.  From over twenty years’ experience with a large range of customers, we know that IT shops which are stuck on BIND get especially nervous.  That’s because they’ve seen firsthand just how complex managing decentralized BIND DNS becomes as the enterprise expands, network technologies evolve, and new integrations are required. One misplaced semicolon in the DNS code, one misdirected link, or an IP address conflict can bring down applications, critical servers, or even the whole network for days.

BIND involves a lot of customization in the form of patches, configurations, and integrations. In a migration scenario, you’re going to want to retain all of that functionality.  That can mean reconstructing several years’ worth of scripts and converting them to a new platform – an extremely painful and time-consuming task.

That’s why so many BIND users we meet end up in a ball on the floor whenever the possibility of a migration or network expansion comes up.  It just seems like such an impossible thing to do, and something that would take up so much time.  The result:  network teams feel stuck.  The existing DNS clearly isn’t working, but getting up and running with an alternative almost sounds worse.

The BIND-BlueCat migration process

Knowing all of this, BlueCat developed a tried and true process for migrating our customers from their decentralized BIND DNS infrastructure into a flexible, scalable, Adaptive DNS solution.

Unlike some other DDI vendors, we don’t just “lift and shift” your data from one system to another.  We take the time to understand your operational needs, your business goals, and the system itself before we do anything.  Here’s a quick overview of our process, from start to cutover.

Step #1:  Understand goals and requirements

The first thing we do is to sit down with the network team and talk about the BIND migration in context.  We ask about where the network is today, where the team wants it to be at the time of cutover, and where the network should several years down the road.

We talk through all of the upcoming initiatives on the company’s roadmap – is there a plan for cloud DNS in the works?  Is automation in the cards?  What do the future demands on DDI services look like?

Since DNS touches so much of any network, we also look at the integration landscape.  We find out which tools the organization is using for network management, security, and other functions which may call on DNS resources or require DNS data.

If necessary, we bring in other stakeholders from the organization to talk about how they use DNS in their lines of work.  DevOps teams, virtualization teams, the security people – everyone in IT has a stake in DNS at some level, and we look to understand their motivations and needs.

Step #2:  Understand the current DNS infrastructure

Next, we review the architecture as it stands.  Our DNS experts basically become a member of the network team – it’s their job to understand the tangle of BIND as it exists, so they can figure out which essential pieces need to stay, and which parts might need to change.

We pay particular attention to the custom patches, tools, and configurations which BIND administrators have built up over the years.  There’s a lot of functionality built into these pieces, and we take the time to review the code and talk to “Mister DNS” or whoever it was who constructed the architecture to function as it does.

In this stage, we usually ask for a copy of your BIND data so we can start the assessment process.  This usually prompts another round of questions as we look at the intent behind the code.

Step #3:  Cleanse and prepare the data

This is a crucial step which other DDI vendors usually skip.  By definition, if you’re switching to a new DDI platform there are things about your existing set-up that you’d like to change.  When those changes happen, data like IP addresses and DNS server records can become obsolete or stale, bogging down the system in the long term.

BlueCat uses a special tool, developed in-house, which cleanses DNS records, zone files, resource records, and other data in preparation for a DNS migration.  Once the data is run through this tool, we go over it with the network team to show the before and after picture.  This ensures that any data we mark for deletion or change is approved before the migration begins.

Step #4:  Consider automation

One of the main benefits of BlueCat Adaptive DNS is its strong support for DNS automation.  Before we migrate data and processes over from BIND, we will go through any operational efficiencies we can add through our Intelligent Automation functionality.

Our BlueCat Labs repository on GitHub has plenty of examples of automation scripts which commonly replace BIND configurations.  If there’s a custom script which needs to be created prior to the cutover, the BlueCat team would usually create the requirements and code it in Python (or show you how to do it) during this stage.

Step #5:  Migration plan overview

Once we’ve reviewed objectives, combed through the data, and built any automation scripts, the BlueCat team will then roll out a formal migration plan.  We sit down with the network team and go over this plan in great detail, making sure that we haven’t left anything to chance.

We also – and this is often the tough part – socialize the migration plan with other stakeholders in the organization.  This ensures that nobody gets “migration panic”, everyone knows what’s coming, and nothing earth-shattering is planned to occur during the same change window.

Once everyone agrees, we schedule the cutover period and begin the actual migration process.

Step #6:  Installation and testing

The actual installation usually begins with standing up physical and/or virtual instances of our DNS, DHCP, and IPAM services, all of which seamlessly integrate and centralize management and provide the baseline for our Intelligent Security and Intelligent Automation solution.

We’ll start in your development lab.  Given the critical nature of DNS, it’s super important to make sure that everything is working properly before the final cutover occurs.

This is usually when we introduce customers to the BlueCat support team as well.  This ensures a smooth handoff after migration in case any issues arise, and starts a relationship which makes it easy to reach out when help is needed.

Step #7:  Cutover and handover

The big day has finally arrived!  Or rather, several big days.

We prefer to stagger cutovers just as a final failsafe.  Since most organizations we work with have DNS zones specific to certain geographies or business functions, it usually works out that the change would happen gradually at any rate.  When we start migrating zones and regions, we tend to start with the smaller ones first, and then work our way up to the larger sections of the network.  During the process, we keep a close eye on how the system is functioning to ensure that all the assumptions we made in the planning and testing process actually come to fruition.

Once the cutover is complete, we formally turn your shiny new DDI system over to you.  If any DNS training is needed, we’ll handle that before the handover occurs, making sure everyone is up to speed.  From this point on, the sky’s the limit!

Learn more about BlueCat’s DDI solution and our DNS experts who make it all come to life.