One modern approach to web development is to build your applications by leveraging a platform as a service (PaaS) like Heroku, or AWS Elastic Beanstalk. Services like these (also called Cloud Application Platforms) allow developers to focus more on the application and less on infrastructure by offering convenient ways to scale the app and configure resources. Beyond scaling and configuration, these platforms also perform regular maintenance on servers and apply security updates. All these things are helpful, but it means your application runs on servers that exist in an amorphous, virtual space. There is no reliable way to associate your application with a specific server at a specific IP address. This has pretty obvious implications for DNS records.
Why not just use a CNAME?
A-Records, which are used for associating a domain with a server, don’t cut it for the type of service described above. Imagine attempting to associate a domain name with an unstable server IP address. While it could work, you’d have to be very vigilant. You would always have to watch for changes from the PaaS that could affect the server and be ready to update the DNS record at a moment’s notice.
To avoid that, Cloud Application Platforms typically recommend that you create CNAME-Record instead. CNAMEs are most commonly used to create subdomains but they are also great for abstracting away the volatility of IP addresses. While A-Records map a domain to an IP address, CNAME-Records map a domain to a target domain.
CNAME app.example.com encircled-magnolia-9265.herokudns.com.
Consider the record above. A DNS lookup for app.example.com will tell the DNS Client to check encircled-magnolia-9265.herokudns.com. This will return A-Records containing the IP address of the server currently running the application. A browser, with the correct IP address, can now access the server and the site works!
But… even CNAME doesn’t completely work.
The DNS specification doesn’t allow a CNAME-Record at a zone apex(root) like example.com for instance. The example above only works because the mapped domain, app.example.com, is a subdomain. A CNAME-Record at zone apex, like example.com, would have serious implications for other records that also use the zone apex. Examples of other records that commonly use the zone apex include SOA, MX (mail exchange), and NS records, all of which would experience DNS resolution failures.
“Operationally a CNAME record effectively rewrites all other DNS records for that owner name (on the left-hand side) – for all record types – to the target name.”
DNS records get messy.
As a result, DNS host providers got crafty and things have become a little messy. Enter ALIAS, ANAME, and CNAME flattening. All 3 of which are non-standard DNS features that allow for mapping the zone apex to another domain. Fortunately, while named differently, their behavior is almost identical: when a DNS query is received for the mapped record, the DNS host follows the redirect and generates an A or AAAA-Record to send in the response. This provides the client with the IP address needed to make their requests.
Unfortunately, until there is an established standard, the correct record type for your application depends on the DNS host you use. For example, DNSimple uses ALIAS, easyDNS uses ANAME, and Cloudflare uses CNAME flattening. There’s no guarantee that your DNS hosting provider has implemented any of these non-standard records in which case, it may be necessary to switch providers.