2

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?

Rob Reagan
  • 7,313
  • 3
  • 20
  • 49

3 Answers3

2

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.

Y.B.
  • 3,526
  • 14
  • 24
  • 2
    You can't "point an A record at Traffic Manager" since TM works at the DNS level. The requests do not go through TM, so there is no relevant IP address you could use. Only CNAME records with subdomains can be used with it due to that. – juunas Jan 03 '18 at 18:26
  • @juunas Right, thank you for the correction on ATM. Do you think IP re-assignment will work with ASE? – Y.B. Jan 04 '18 at 11:04
  • 1
    Hmm, well whether the apps are in a "public" service plan or a dedicated one like in ASE would not really make a difference. The IP address is pointing to a load balancer in the data center anyway. So if individual servers fail it won't affect anything (well okay maybe some requests will fail). The scenario where OP would have to point the A record to another IP address would be one where the entire data center goes down. Or if they wanted the user to hit a closer instance, they need anycast. – juunas Jan 04 '18 at 11:08
  • Your answer with ATM and CloudFlare is absolutely correct. I understand there is no control over Web App IP address in a "public" service and if the datacenter goes down the new instance of Web App would have a new IP. ASE being deployed in virtual network should (probably?) allow this trick with IP re-assignment. – Y.B. Jan 04 '18 at 11:44
2

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

juunas
  • 54,244
  • 13
  • 113
  • 149
  • Thanks for the CloudFlare suggestion. I'll do a bit of research to better understand their available tools and how they can fit into our high availability strategy. – Rob Reagan Jan 03 '18 at 21:26
  • Why [DNS is a poor choice for simulating failover](https://serverfault.com/a/6742). More on [Azure Load Balancer](https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-introduction) – Y.B. Jan 04 '18 at 10:48
1

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

Jonathan
  • 185
  • 1
  • 4