How NS1 ensures seamless DNS migrations

Migrating a mission-critical system like authoritative DNS is always going to involve some amount of risk. Whenever you’re flipping a switch from one infrastructure provider to another, the possibility of downtime is always lurking in the background.

Unfortunately, many network admins use this risk potential as a reason to continue using an authoritative DNS service that no longer adds business value. That fear of the unknown often seems worse than enduring the day-to-day indignities of the DNS platforms they currently use.

This is why IBM NS1 Connect pays so much attention to the customer migration process. We pride ourselves on our DNS expertise and our hands-on approach to customer service. Over time, we’ve developed a tried and true migration process that enables a seamless changeover without downtime.

We also use the onboarding process to optimize your authoritative DNS, so you hit the ground running. We want your business to feel comfortable enough with NS1 Connect functionality to drive the results you’re looking for: better network performance, improved reliability and reduced cost of delivery.

It’s worth mentioning that we use this process for complete changeovers and in situations where NS1 is added as a second provider. Confirming the proper division of labor as well as the validity of failover mechanisms is an important consideration when you’re using more than one authoritative DNS provider. That’s why we treat it like a de facto migration.

The NS1 migration process

Customers often ask us how long their migration will take. They want to dig into the details of how we’re going to make the transition seamless. Our primary goal is to do no harm, but close behind that we want to make the change as quick and easy as possible.

We’ve broken up our authoritative DNS migration process into six distinct stages. The timing of these stages vary quite a bit, depending on the scale and complexity of a customer’s DNS architecture and business requirements. We’ve done “emergency” migrations in as little as a day, but generally, we prefer a few weeks to allow customers time to test various functions as thoroughly as they’d like.

Step one: Kickoff and discovery

In this stage, we meet with your DNS team and scope out the migration project. We’ll ask about your business requirements and how you measure success. We’ll also map out your DNS infrastructure and ask about any business-specific quirks or custom configurations. By the end of this phase, we should be aligned on what you want to achieve and how we’ll get you there.

Step two: Build out the basics

Once the scoping part is complete, we usually progress straight to the build phase. Working closely with your team, we create your DNS records and zone files. If you’ve got existing DNS zones that you’d like to replicate, we export your zone files to NS1. If you’re adding NS1 as a secondary provider, we’ll connect it to your primary server and configure handoffs accordingly. We also walk through the NS1 Connect API and start building connections to automation platforms (like Terraform or Ansible) that you may be using. By the end of this phase, you should have the basic outlines of your DNS architecture up and running.

Step three: Advanced configuration

In this phase, we expand on the baseline from phase two by optimizing your DNS configurations. Looking at the performance metrics for your application or business, we work with your team to set up traffic steering logic, build out automated functionality, add resilience and put together frameworks for monitoring. At the end of this phase, you should have a finely tuned DNS infrastructure that fits your performance and resilience requirements.

Step four: Consistency check

In this phase, we test your configurations for accuracy and reliability. We also use this phase to update the NS1 system as needed to ensure it covers 100% of the original configuration. This step makes sure that we don’t miss anything, including updates that weren’t made in Phase 2 that may need replication. We use analytics tools to make sure that the DNS answers you’re providing are the right ones. We also double check the performance of the system using real data to ensure that it meets the expectations set out at the beginning of the project. At the end of this phase, you should have a fully configured DNS architecture that’s ready to deploy.

Step five: Migration

Now comes the fun part—turning it on! In this phase, we start gradually moving traffic onto NS1 systems, monitoring performance as we go along. It starts off small to minimize risk and ensure that any impact isn’t felt across the enterprise. Usually, we prioritize certain parts of your application workloads with reduced impact. Then gradually, we start to cut over larger portions of the enterprise until you’re fully up and running on NS1.

Step six: Optimization

The job of fine tuning a network never truly ends. You learn a lot in the onboarding and migration steps, but over time your metrics for success often change. Applications come and applications go. With every change, your DNS will have to adapt. That’s why we stay in touch long after a migration is over. We want to make sure that the authoritative DNS we build for you meets your long-term needs.

Taking the first step

Migrating your authoritative DNS doesn’t have to be difficult. The risk is manageable. It doesn’t have to consume a lot of time or resources. The result—an authoritative DNS that meets your business needs and delivers great user experiences—is clearly worth it.

The key is to have someone who’s been there before, who knows what to look for. That’s where NS1’s DNS experts add concrete value. We’ve migrated hundreds of customers—large and small, complex and straightforward, from every other authoritative DNS solution on the market. That’s why our customers love us. We focus on what we know best—the DNS infrastructure your business relies on every day.

It doesn’t matter how antiquated, proprietary, or complex your authoritative DNS setup is today. We work just as well with customers who have self-hosted with BIND for decades as with customers who use cloud providers for their DNS. With all the customers we’ve migrated, not much will truly surprise us at this point.

Source: ibm.com