Security Experts:

DNS Migration: How To Minimize Problems When Switching DNS Providers

DNS Migration - Strategies for Changing DNS Providers Without Disruption

Did you know that when you switch from one DNS provider to another, you are arguably at the highest risk to shut your online presence down? As mundane as it sounds, DNS service is one of the fundamental elements to ensuring that your website is live and your emails work. Enterprises are learning that massively redundant, scalable and geographically diverse DNS resolution is both a critical technology function, and a function that is most economically outsourced.

Changing DNS Service ProvidersWith many players in the Managed DNS market, and countless solicitations arriving in your voice mail and inbox, you may arrive at the tipping point where you are ready to switch DNS providers. Switching your DNS provider is not a trivial matter like switching your toner or stationery provider. DNS is the glue holding your Internet presence together, so major changes always need to be carefully considered before they are implemented.

Double Dipping

Think about changing DNS providers much like changing the physical address of a store. Let’s say you're in the business of selling fast food. You can shut down one restaurant, pack everything into a truck and haul it off to your new premises. But while this move is happening, you're not selling any burgers, which means you’re losing revenue. To avoid having your revenue stream interrupted, it's better to open the new restaurant first, and then close the old one. Similarly, to maintain a consistent user experience during a DNS migration, it makes sense to use two providers simultaneously, and only switch the legacy service off when your DNS is fully operational with the new provider.

DNS Caching Matters

At the technical level, migrations can be tricky. Consider DNS caching. Almost every time a DNS answer is sent in response to an Internet user’s request, that information is cached (stored) on a recursive name server somewhere close on the network, such as at the user’s ISP. There are performance, as well as economic, reasons for doing this.

If everything is working as it should, the maximum length of time a record is cached by a recursive server is determined by the “Time to Live” (TTL) setting, which is set by the website owner. For name server records, this can be a long time – hours or even days. You should assume that, for the TTL period, some Internet users around the world will see older, cached data, which points to your old DNS provider.

To avoid loss of service during a migration, timing is critical. First, it’s important to ensure that both old and new providers are serving identical DNS records for your domain, to avoid conflicts arising in caches. Next, when the migration is initiated, both new and old DNS providers need to keep your domain operational for at least the maximum TTL after the new provider's name server resource records (NS RRSet) are submitted as authoritative for your domain. This means you need to make sure that the old provider will not immediately stop providing resolution for your domain after you initiate the switch. Only after you're confident that TTLs have expired — and the old, cached name server data have been deleted worldwide — should you remove your old name servers and turn off your old provider. Seven to ten days is a good rule of thumb.

Care when migrating a DNSSEC signed zone

DNS migration is more complex for DNSSEC signed zones. The DNSSEC standard extends DNS to enable signed domain validation based on a hierarchy of cryptographic keys stored in zones from yours to the DNS root itself. DNSSEC is not yet broadly deployed. Chances are that your organization does not currently use the technology, especially if your only domain is a .com. DNSSEC, however, will soon become widespread. If you're planning to switch DNS providers and also considering implementing DNSSEC, I recommend delaying the DNSSEC roll-out until after you're comfortably installed at your new provider, to reduce the complexity of the migration.

DNSSEC introduces new records that are also cached by recursive servers for performance reasons, such as the public part of the cryptographic key used to sign your domain's data. Keys also need to be periodically rolled over, to mitigate the risk of becoming compromised by attackers. In an earlier column, I discussed strategies for key management that take into account the TTL of DNS data and the problems that can arise due to caching.

If the zone you're planning to migrate is already DNSSEC-signed, note that timing is everything, literally. Signature records have an expiration time embedded in them, which is distinct from the TTL of the record. This means that you must have your old provider continue service for the greater of the maximum TTL or the maximum expiration time of the existing signature records. Otherwise, a loss of service can result. Your providers can discuss options with you in depth, but this is one reason why it is best to implement DNSSEC after changing DNS providers.

Precision, Coordination and Crisp Execution is Key

Although they are complex, DNS transitions are relatively commonplace. To avoid mishaps, you should create a checklist of tasks to perform, combined with a clearly defined and accepted timeline of actions by both your old and your new DNS provider. You need to ensure you have adequate control of your domain name via your registrar or reseller so that you can submit DNS changes and have them propagated in a predictable way on the Internet.

If you follow these steps, you can minimize some of the dangers when migrating DNS providers, and come out on the other side with no downtime and no disruption to your business.

(Disclosure: My employer, Afilias, provides managed DNS services.)

view counter
Ram Mohan is the Executive Vice President and Chief Technology Officer at Afilias, a global provider of Internet infrastructure services including domain name registry and DNS solutions. Ram also serves as the Security & Stability Advisory Committee's liaison to ICANN’s Board of Directors and has helped direct and write numerous policies effecting domain name registration and DNS security.