DNS for Disaster Recovery Site Failover, Explained

As a Disaster Recovery as a Service (DRaaS) provider, our solutions engineering team is fielded with a lot of questions concerning the mechanics of the failover process. One of the most popular: How are my customers and my data redirected to SingleHop’s hosted environment in a DR scenario? The short answer: We redirect traffic to a failover site using a standard DNS method.

For the (slightly) longer version, let’s dive into the process, as well as some of the terminology you’ll encounter along the way. 

How to Use DNS for Site Redirection

SingleHop provides fixed public IP addresses at the DR site. Since these addresses are known, it’s fairly easy to predetermine how they will be used at time of disaster (ATOD) or at time of test (ATOT). To understand how the redirect works, keep in mind the function of two important DNS record types:   

A Record

A Records are the most commonly used type of DNS record. It simply points a domain or subdomain name to an IP address.


A CNAME (or canonical name) is an alias record. This is used to point to a particular A Record.

Since the IP addresses are known and fixed for the production and DR sites, A Records can be created for each site; we then can use CNAME to direct to the active record.

Determining the Time to Live

Time to live dictates how long it takes for your DNS information to be refreshed. In a DR scenario, the time to live (TTL) for the CNAME should be fairly short so that it isn’t cached by a browsing computer for too long a period. If an event occurs, you want browsing computers to be redirected quickly and not have to wait for their cached DNS records to expire. The minimum TTL is one second, but this puts increased demand on your DNS server or DNS service provider. Some DNS providers’ plans limit the number of DNS queries per second (QPS), so lowering the TTL might require that you also adjust to a higher-priced plan.

We typically recommend setting TTL to match or be shorter than your recovery time objective (RTO). You will also want to check with your DNS registrar to find out how long they update their zones. For example, VeriSign refreshes zones every three minutes, which would fit very well for this.

Let’s walk through an example of how the redirect will work given the following information:

  •        DNS domain of paulp.com
  •        Production site with an IP of
  •        DR site with an IP of
  •        RTO of 1 hour (60 minutes)


I’ll first create an A Record for the production site with a TTL of 60:


A BIND zone file (a text file describing your DNS zones)  for paulp.com might look like this:  

To test this, I can ping prod.paulp.com.

I can then create an A Record for the DR site:


A BIND zone file for the DR site might look like this:

If I have an active server at the DR site, this is easy to test without interrupting production. I simply ping dr.paulp.com.

Now I can use a CNAME record to point to www.paulp.com to the production site during normal operations. A BIND zone file for this record would like:

If disaster strikes, I can change my CNAME record to point www.paulp.com to the DR site.

And here’s the edited zone file:

Note that for web servers running name-based virtual hosts, the host header in this case is still www, so the web server will detect it as such and still direct it to the proper content.

Overall, DNS redirection is a quick and simple way of redirecting traffic from one site to another during a DR scenario. The process  does not require a large amount of automation or technical knowledge and can be done by most end users.

If you’re in the early stages of crafting your Disaster Recovery plan and don’t know where to start, we can help. Check out our free Business Impact Analysis template here and don’t forget to explore our Standby and Active DRaaS plans over at our main site.   

Wishing you an incident-free day.

explore dr
Read Also:
SingleHop at VeeamOn 2018 World Backup Day 2018: The Best Advice and Resources for Protecting Your Business’s Critical Data Disaster Recovery is the Perfect Entry Point to the Cloud. Here’s Why.
Paul Painter, Director of Solutions Architecture
Paul Painter
Director of Solutions Architecture

Paul Painter is SingleHop's Director of Solution Architecture and is responsible for Presales engineering support to SingleHop's sales teams. Paul has been in IT since 1984 working for companies such as Mellon Bank and Allied...READ MORE

Free shipping site of all wholesale bike jerseys products,more items bigger discount,hurry to collect discount hockey jerseys

Wishing you an incident-free day.

free draas consultation
Recent Tweets

Ready to Transform Your IT Strategy?

From groundbreaking server management software and automation platforms to custom, flexible managed infrastructure solutions, we win customers because we put customers’ unique needs at the center of every solution.

"I feel the customer service is light years better at SingleHop than with my previous provider. I love that I can call the 24 hour support line when things are simply easier to explain on the telephone than in a support ticket. "

Jane, SingleHop Customer

"Wonderful service. We really appreciate your willingness to work with us to help our business succeed. "

Aviva, SingleHop Customer

"As always I can depend on SingleHop Tech Support team for an assist whenever we need them. They’ve exceeded our expectations each and every time for the last 7 years. "

Rodney, SingleHop Customer

"Excellent! Hardware and software are important in this environment but what is truly outstanding is the tech support that comes with it!"

Kenneth, SingleHop Customer

"[The] completed task has made a serious difference in the server’s performance. Thanks for digging deeper. The efforts/findings were so worth the time taken, in my eyes!"

Michael, SingleHop Customer

"The crew is indeed outstanding. Everyone is involved with your case; they respond promptly and accurately.
They are always correct and incredibly fast."

Juliana, SingleHop Customer