2
votes

I have a client with the following setup:

  • DNS is NetworkSolutions. Their minimum TTL for a DNS entry is an hour.
  • An Azure Web App hosting a standard MVC site.
  • Azure Traffic Manager set to priority.
  • Our A record points to the Azure Web App's IP address. Our CNAME for www and various other subdomains points to our Traffic Manager endpoint. Our Traffic Manager endpoint then points to [siteName].azurewebsites.net.
  • Our naked domain simply 301 redirects to our www.

My goal is to have a hot standby in another data center that I could failover to quickly if the need arose. With Traffic Manager, I could set the TTL in Traffic Manager for all subdomains to something small, such as a few minutes. If I needed to failover, this is fast.

My question is concerning failing over the A record for the naked domain. At NetworkSolutions, the A record HAS to be an IP address. I have Google'd/Bing'd around and I believe this is true regardless of the DNS provider.

What options are available for quickly failing over the A record to a secondary region and another Web App? As of now, my only idea is to switch to a new authoritative DNS that will let me keep the TTL for the A record smaller than an hour, then dispose of Traffic Manager altogether.

Are there any other more optimal alternatives given our goal of fast failover to a Web App in a different region?

3

3 Answers

2
votes

@Y.B. links to a good answer on Server Fault discussing the fact that DNS does not really work that well for failover. Even if you did set TTL to 5 minutes, there will be many devices which will not respect that.

Traffic Manager is a pretty reliable service as mentioned here. And it won't be affected even if an Azure region goes down.

Your strategy for the A record means search engines won't index the raw domain. So those will still work.

But yeah, DNS is not a failover solution. There's no guarantee how long it takes for changes to DNS records to propagate.

A service like CloudFlare could help you with the load-balancing since they use anycast addresses.

2
votes

DNS is a poor choice for simulating failover

One other option might be to use App Service Environment in regional VNets and Set up IP addressing to connect after failover to a secondary site. Basically, A record still resolve Domain Name to the same IP, but the IP address itself is released at the primary site and assigned to the failover one.

1
votes

I assume your 'A' record is at the zone apex (i.e. mydomain.com rather than something.mydomain.com). If so, you're up against two constraints:

  • The apex of a domain cannot contain a CNAME record (DNS standards forbid it)
  • Traffic Manager only works with CNAMEs

These are incompatible. You're stuck, and need a workaround.

There are some DNS-based traffic management services that support traffic management with A records (AWS Route53 is one, there are many others). These allow traffic management at the zone apex i.e. for mydomain.com. You will need to host your domain with that service, and manage all DNS records for your domain there.

Your options are:

  1. Use a different DNS-based traffic management service instead of Traffic Manager, one that supports traffic management for A records.
  2. Use a non-apex domain e.g. something.mydomain.com only
  3. Create a simple HTTP redirect service to redirect mydomain.com to something.mydomain.com. Use Traffic Manager on the latter. Host the former in more than one region, and create A records at mydomain.com pointing to both (thereby relying on client failover between A records, which should work)
  4. Use an application-level failover service such as App Gateway. Host the App Gateway in more than one region (for high availability) and as with #3 create A records at mydomain.com pointing to both.
  5. Use a non-DNS third-party traffic management solution such as CloudFlare.

You can vote to add support for apex domains in Traffic Manager here: https://feedback.azure.com/forums/217313-networking/suggestions/5485350-support-apex-naked-domains-more-seamlessly