Seamless DNS migration: Your how-to guide

One of the first things you do when you move to a new house is to update your mailing address with the postal service. This update isn’t necessarily complicated, but it is essential: otherwise, important mail might be sent to your old address, and neither you nor the sender would know that the mail wasn’t delivered.

DNS migration is similar. If not done properly, your website could become inaccessible to users, email could fail and cause communications issues with clients, integrations could break and more. Essentially, customers might be unable to reach your business at the correct address, which can lead to a host of negative outcomes.

The domain name system (DNS) is like a phonebook or directory for the internet. It enables a user to navigate to a website by using an easy-to-remember domain name, such as IBM.com, instead of string of numbers (in this case, 184.85.75.7).

But DNS involves much more than a simple translation, and the quality of service from a managed DNS provider can impact performance, reliability, latency, security, privacy and more. When a provider’s DNS service isn’t meeting expectations or needs, businesses might seek a new provider. When they do, they will need to plan a DNS migration.

DNS migration, in which an organization transfers a domain’s DNS records and settings from one provider to another, does not have to be the arduous endeavor it’s often made out to be. However, it does have its risks, and potential headaches if not executed properly. Errors in DNS migration can result in server downtime, network vulnerabilities and more. Here’s how to help ensure that doesn’t happen.

You can read more about the DNS lookup process here.

The simple answer is that not all DNS providers offer the same services, or quality of services. Performance is a key feature, but it is not the only concern.

For example, a DNS provider might also provide security features to prevent DNS spoofing and block access to known or suspected malicious domains. Monitoring and logging capabilities also vary from provider to provider. Some DNS providers offer load balancing for failover, in which multiple redundant web servers handle DNS queries to avoid overloading any one server, or a global content delivery network (CDN) that helps cache content closer to users. Of course, cost might also be a factor in a decision to change DNS providers.

Business leaders must choose the service that best fits their business needs. Those needs often evolve, and DNS requirements might evolve in kind. When a current DNS provider’s services no longer satisfy a business’s needs, business leaders might consider migrating their DNS records and management to a new provider.

Generally speaking, there's a major reason many businesses procrastinate in doing so: a feeling that migration is too daunting and that any change will lead to downtime. It’s a legitimate concern, but one that can be mitigated through careful planning and execution.

The first step in a DNS migration is to specify the reason (or reasons) for the migration. What benefits is the business seeking that it doesn’t currently have? What issues does the business need to resolve? For example, if an enterprise uses a small internet service provider’s (ISP) DNS, they might find that resolution times are reaching into the triple-digit milliseconds. In that case, improving speed might be a priority.

Once the business has identified reasons for migrating, IT teams can compare different services to find the right blend of features, service and cost. Different providers offer different specifics for onboarding a migration, but there are some general guidelines to follow.

Once the migration team has selected a provider, they needs to gather all records and related information from the previous DNS provider. These records might include the following:

These records provide a direct translation from domain name to IP address. A records are for IPv4 addresses, and AAAA records are for IPv6 addresses. IPv6 is becoming more common; it offers a much greater number of unique IP addresses and includes some rudimentary security and speed-increasing features.

Canonical name records, or CNAME records, direct an alias domain to a canonical domain. This means that this type of record is used to link subdomains to domain A or AAAA records.

Delegation name records, or DNAME records, are used to redirect multiple subdomains with one record and point them to another domain.

Certificate authority authorization records, or CAA records, allow domain owners to specify which certificate authorities (CAs) can issue certificates for their domain. A CA is an organization that validates the identity of websites and connects them to cryptographic keys by issuing digital certificates.

Text, or TXT records, store textual information related to domains and subdomains. Text records enable the storage of sender policy framework (SPF) records and email verification records. DKIM and DMARC records, which are stored in TXT records, help email servers confirm that a message is coming from a reliable source.

Start of authority, or SOA records, store important administrative information about a domain. This information can include the domain administrator’s email address, information on domain updates and when a server should refresh its information.

Name server, or NS records, show which DNS server is acting as the authoritative name server for a domain. Authoritative name servers contain the final information about a specific domain and its corresponding IP address. An NS record points to all of the different records your domain holds. Without NS records, users will not be able to access your website.

DNS zones are divisions within a DNS namespace. IBM.com, for example, has a separate DNS zone at research.ibm.com. These subdomains are large enough that they benefit from individual management and monitoring. DNS zone files include most of the aforementioned file types: SOA records, A and AAAA records, and more.

There are other DNS record types as well—read this guide for more information.

Some providers offer automation features that gather, export and import DNS records for you, but it’s often wise to perform a manual backup as well: missing records can result in serious problems. You’ll also want to store a copy of these files somewhere secure.

One potential hiccup in this process could be DNSSEC, or domain name system security extensions. DNSSEC offers a valuable suite of security protections, using signature verification to help ensure accuracy and prevent DNS spoofing and other attacks.

But the DNS migration process can introduce different signing algorithms, breaking the chain and causing outages. There are different solutions for this problem: some providers will offer a DNSSEC-specific migration tool, which maintains that security. For others, it might be necessary to disable DNSSEC before migrating, and then enable it again once migration is completed.

Another recommended practice is to lower time to live (TTL) values. This is the length of time that recursive resolvers—or recursive servers, the first stop in a DNS query—store the IP addresses of recently visited websites in cache. Caching eliminates the need to look up the IP address again, and helps provide faster connections.

If a TTL is set to, say, 24 hours, when a user attempts to visit a site that has migrated its DNS server within that timeframe, their browser will try to go to the old IP address, likely resulting in an error. Setting the TTL to something very low, maybe only a few minutes, can help avoid this issue.

It's a good idea to perform the migration in stages, rather than all at once. Staging allows a migration team to check each feature individually for errors, rather than scrambling to figure out what went wrong throughout the entire operation.

Once the team has exported existing DNS documentation and imported it with the new DNS provider’s service, they should check and verify the documents to ensure nothing was lost along the way. A tool like [dig] can help with verification. [Dig], or domain information groper, is a command-line tool that enables users to check DNS documents, from basic IP address to TXT, SOA and more. Nslookup is another command-line tool, albeit simpler than [dig], returning less detailed results.

Then the team can begin transferring by stages: web hosting, email services, then APIs and other third-party services. It’s a good idea for someone on the team to check and troubleshoot each one as the migration progresses. Configure any advanced settings, such as enabling DNSSEC. Once this is all tested on a test server, the team can proceed with updating information with the registrar.

If the business has a separate domain registrar and DNS provider—perhaps using IBM NS1 Connect for DNS and GoDaddy for domain registry —the team must log in to the domain registration service and update the name server records. If the business uses the same provider for DNS and registry, this can often be done automatically. You do not need to change anything on your web host itself if you aren’t also changing your hosting provider. 

An important factor: do not delete the old DNS quite yet. This is due to DNS propagation. DNS records don’t instantly change throughout the internet; it takes time for the scattered domain servers to search and update their records. The team can check record status periodically with online tools like WhatsMyDNS.net. It generally takes a day or two at most, but during that time, you’ll want both your old and new DNS services to be running while those domain servers update their records. This ensures that users don’t experience outages.

Once propagation is complete, the migration is essentially done. Only some light finishing work remains. This includes:

Restore TTL to normal: Increase the TTL back up to 24 hours or whatever it was before in order to enable caching for users.

Update internal documentation: Make sure that DNS information—account number, billing cycles, that kind of thing—is updated within organizational records to avoid confusion.

Monitor: Review performance and other metrics following the migration. IT teams can review DNS logs for any errors or timeouts, track new response times, set up alerts for any downtime, and periodically check for propagation. Many DNS providers have internal monitoring tools. Third-party tools are also available.

Learn more about managed DNS services here.