ANAME or ALIAS DNS Records

ANAME DNS Records, Also Called an ALIAS or CNAME (Virtual) Are Necessary

Recently, we had an issue with one of our client's hosting providers.  They are hosted on Network Solutions, which has been a major DNS provider since the early days of the internet.

The problem is that we use cloud servers for scalability.  Many cloud servers are configured such that an ANAME or ALIAS is required for the DNS to work properly.

To understand the problem, we need to define a few things.

Some Background Definitions About DNS

DNS - Domain Name System

Everything on the internet has an IP Address.  When we access a website, or even when an API for an APP accesses back-end services which make it work, they ultimately route to an IP Address.  IP addresses are numbers separated by dots, like 127.23.24.222. If it is a V6 address then it looks like this: 2345:0425:2CA1:0000:0000:0567:5673:23b5

Imagine putting that on your business card.  Checkout my website at 2345:0425:2CA1:0000:0000:0567:5673:23b5.

or emailing me at james@2345:0425:2CA1:0000:0000:0567:5673:23b5.

The domain name system solves this problem by resolving a more easily understood and remembered word like ibcscorp.com to an IP address.

It used to be that straight forward.

I may have had a machine under my desk with an IP address 32.132.222.111 and a DNS A record which pointed to it like this:

ibcscorp.com : 33.132.222.111

www.ibcscorp.com:33.132.222.111

Then whenever someone put in that domain name, they would be routed to the machine under my desk which, if it had a web server on it, would deliver a website.

This is great, but, it isn't so great because it implies that the machine at 33.132.222.111 is always on and working. 

Today that would be an unacceptable solution because we expect applications and things on the internet to be up 24X7 always, even when they are being updated.

So, the simple DNS A record doesn't work well for our modern day needs.

It gets more complicated with distributed cloud based applications and applications which are distributed over a content delivery network.

Domain Name Server - DNS Server

As explained above the Domain Name System (DNS) provides mapping from common names called domain names, which are easier for us to remember to IP addresses which are not easy to remember.

Domain name servers provide this mapping.  While there are only 13 root domain servers, there are many domain servers which provide domain name lookup services as can be seen here:

https://dnschecker.org/#A/ibcscorp.com

If there was only one, then we could update the IP address in real time when we were swapping out or upgrading a machine or if a machine failed, but, as the IP address may take 72 hours to update, this isn't a good solution.

CNAME Record

A CNAME record is a canonical name record.  It is used to alias one domain name to another, so we might map a subdomain to another using a CNAME record.  It can be used in lieu of an A record. 

This would allow us to point our domain to a cloud provider or content delivery network which has its own host name which we may not control. This network may represent any number of servers in any kind of routing network keeping our site up and running 24X7 with extremely high availability and access speed.  

However, CNAME records do not allow the root domain (DNZ zone apex), so ibcscorp.com could not be a CNAME.

ALIAS or ANAME

Unlike the CNAME record An ALIAS or ANAME record does support the root domain.  This makes it so that iBCScorp.com as well as www.ibcscorp.com can be pointed to a CDN (Content Delivery Network) which would provide quick access and robustness to the website.

Most applications we build, including applications built on PrimeAgile require an ANAME or Alias record to ensure high availability and performance.

Canonical URL

A canonical URL is the most representative form of a page or URL.  It us necessary to prevent duplicates in search results.  Typically, we use www. as the canonical URL for a website, for example, www.ibcscorp.com.  Other subdomains may also be used for other applications, API's, or to provide other functionalities.

Typically, we redirect the root domain to www. for web traffic, so we would route ibcscorp.com to www.ibcscorp.com, which is our canonical URL.

So you might ask, why does it matter anyway since we always use Canonical URL's when we publish a website?

It matters because we want to prevent in all cases non-routability of the root domain should it be entered into a web browser.  WWW is the standard prefix for a website, like ftp. might be the standard prefix of an ftp server, but it is not always typed in by the user as redirects are the standard practice to make it easier for the user to get to www.yourwebsite.net.

Possible Solutions

301 Redirect

One possible solution is to setup a 301 redirect on a web server which routs the root domain to the www. domain. In this case, Network Solutions will do this for $2 to $3 per month. 

However, we find that to be a smelly solution as it requires routing to the wrong server in order for the re-route to take place.

Thus, we suggest using a different DNS service provider.

Migrate the Zone File

Our feeling is that, in the end, if the DNS provider does not support ANAME/ALIAS, we should migrate the zone file to another provider which does support it.  Some providers that provide this include:

  • ANAME at Amazon Route 53 
  • ALIAS at DNSimple
  • ANAME at DNS Made Easy
  • ANAME at easyDNS
  • CNAME (virtual) at CloudFlare

If you are using a Content Delivery Network (CDN) like CloudFront and want your root domain to route, then this is required.

It is important to note that we typically route the root domain to www., so a 301 permanent redirect is going to be in place routing the root domain to www. anyway.