Connect with us

Hi, what are you looking for?

SecurityWeekSecurityWeek

Network Security

DNS Migration: How To Minimize Problems When Switching DNS Providers

DNS Migration – Strategies for Changing DNS Providers Without Disruption

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.

Advertisement. Scroll to continue reading.

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.)

Written By

Click to comment

Trending

Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest threats, trends, and technology, along with insightful columns from industry experts.

Join the session as we discuss the challenges and best practices for cybersecurity leaders managing cloud identities.

Register

SecurityWeek’s Ransomware Resilience and Recovery Summit helps businesses to plan, prepare, and recover from a ransomware incident.

Register

Expert Insights

Related Content

Identity & Access

Zero trust is not a replacement for identity and access management (IAM), but is the extension of IAM principles from people to everyone and...

Cybersecurity Funding

Network security provider Corsa Security last week announced that it has raised $10 million from Roadmap Capital. To date, the company has raised $50...

Network Security

Attack surface management is nothing short of a complete methodology for providing effective cybersecurity. It doesn’t seek to protect everything, but concentrates on areas...

Application Security

Virtualization technology giant VMware on Tuesday shipped urgent updates to fix a trio of security problems in multiple software products, including a virtual machine...

Identity & Access

Hackers rarely hack in anymore. They log in using stolen, weak, default, or otherwise compromised credentials. That’s why it’s so critical to break the...

Application Security

Fortinet on Monday issued an emergency patch to cover a severe vulnerability in its FortiOS SSL-VPN product, warning that hackers have already exploited the...

Cyberwarfare

Websites of German airports, administration bodies and banks were hit by DDoS attacks attributed to Russian hacker group Killnet

Network Security

A zero-day vulnerability named HTTP/2 Rapid Reset has been exploited to launch some of the largest DDoS attacks in history.