Launch: Pointing Your Domain - 'A' vs 'CNAME' Record

When you are launching a Website, API, or other service, this usually involves a key step of getting the customer to point their domain(s) of choice to the server hosting your service. There are two ways to do this (A record or CNAME record) and its important to understand the difference.

A Record

The A record points a name to a specific IP. For example, if you want the name www.agilitycms.com to point to the server 185.31.17.133 you will configure:

www.agilitycms.com.     A        185.31.17.133

 CNAME Record

The CNAME record points a name to another name, instead of an IP. The CNAME source represents an alias for the target name and inherits its entire resolution chain.

www.agilitycms.com.      CNAME   agilitycms.azurewebsites.net.

In this example, the domain agilitycms.azurewebsites.net is actually controlled by Microsoft Azure which happens to be the cloud service provider.

The Problem: A Record

With cloud services growing exponentially in popularity (and for good reason), sometimes a static IP Address isn't always static for the service. For example, in Azure App Service while each Service Plan has a static IP it is not always guaranteed. If you were to move an Azure App Service to another region, delete it and recreate it, or change the service tier to "Free" it is entirely likely the IP Address would change. 

Having a service that is not resolving due to an IP address being changed is not a fun place to be in. Your pretty much left to the mercy of contacting your customer and getting them to urgently update their DNS settings while their service remains offline. Not fun.

The Solution: CNAME Record

If your customer had setup a CNAME record for their domain to point to their provided cloud service domain, then you can lift and shift your resources in the cloud without having any customer intervention. This is powerful. Take the following scenarios into consideration:

1. Your beloved cloud provider is having a nasty outage in one of their data centers. Your service is offline. You can move your app to another data center entirely (assuming your provider keeps your service domain the same). This is actually fairly trivial to do, and you could do this all without having any customer intervention. They will love you for finding a way to keep their site up while everyone else is still down.
2. Your customer's website is located in a specific region and they've requested you move them to another region (i.e. US vs Canada, or East US vs West US). Or, for internal management you'd like to move them to another region or server. Again, no need to get them to update their DNS, just lift and shift the resource.

When to Use an A Record

If you are creating a record for root domain name such as agilitycms.com then unfortunately you won't be able to take advantage of a CNAME and will need to use an A record pointed to the domain. However, you could still have a CNAME for www.agilitycms.com to agilitycms.com domain (which has it's own A record).

I'm finding it harder and harder to find any other reasons why you'd ever use an 'A Record' again. In this constant evolving landscape, it's the way to go.