DNS A record ALIASES, and ANAME record differences

Question

We have a number of groups of servers on AWS that use trios of servers to serve out sites. Each server, or set of servers is within a different availability region, one of which is a redirection server while the other two are the primary servers accessed behind an elastic load balancer. We finally have one client on board for using Route53 and was looking up some details of pointing zone apex domains at elastic load balances. Most DNS providers which support this seem to refer to this as DNS aliases of A records. Some sites however seem to refer to a similar record called an ANAME record. This is not the typical CNAME, or the atypical DNAME record. Most of these sites also refer back to DNSMadeEasy simpleDNS which uses it.

So what is the difference between Route53 (or elsewhere's) A record ALIASes and ANAME records? Is there one? Does either of these have, or are included in an IEFT RFC implementation document or are aliased records all implemented within the provider they are use on?

[edit]: incorrect DNS provider listed for ANAME usage

Solution 1

It looks like ANAME is just a standard-sounding name made up by DNS Made Easy to describe a service offering of theirs that is extremely similar to what a Route 53 Alias does.

I described the differences betweeen an Alias and a CNAME recently on Stack Overflow, but to summarize here:

A DNS server provisioned with a CNAME for a given host hands out a referral indicating the canonical name of the host being looked up, often requiring a second query by the origin resolver to look up that alternate name; an Alias (and from the looks of it, an ANAME) uses internal information the DNS server knows about the "true" destination to simply respond directly to the request, without the need for a second lookup and without any visibility of the intermediate information in the DNS protocol exchanges.

What an Alias provides, in addition to this, is the ability to use information that Route 53 has in its possession about currently valid IP addresses for S3 website endpoints, ELB, and Cloudfront, to respond to A-record queries with authoritative information that is accurate in near real time, which, if you are using those services, is not something any other provider will have at their disposal; of course, the opposite is also true, a Route 53 Alias can't be used to find and return information that isn't intrinsically available to Route 53. You can't just use "any" target for an alias -- only the endpoints of the three services I mentioned above, or other records in the same hosted zone within Route 53.

In this sense, an ANAME and an Alias are not equivalent, depending on what service is providing the back-end... unless the ANAME is pointing (internally) to information that is static.

An ANAME record on another DNS host's service would not be able to provide the same capabilities as Route 53 if the destination is S3, ELB, or CloudFront, in the same way that an Alias on Route 53 would not be able to return answers pointing to another CDN provider's edge locations using internally-available information, because the information isn't internally available to the provider's infrastructure. Otherwise the functionality seems largely the same.

Solution 2

Starting right here in the FAQ, it explains that an alias record is a Route53 specific pointer, similar to a CNAME record, but not visible to a resolver.

Comments

[Andrew B]

ALIAS and ANAME "records" are not incorporated by any RFC.

[plaisthos]

This should be updated to indicate ANAME records are in an IETF work group draft: datatracker.ietf.org/doc/draft-ietf-dnsop-aname

[dcmbrown]

That is pretty much what I expected. While testing this set up in only a simple record format, it appears to work roughly like a round-robin DNS A record, with local DNS caching the record until it expires, and then more often than not switching over to the opposite record.

[Fabien Snauwaert]

Just a quick note that, to date, Route 53 still does not support apex domain CNAME nor any alternative.

[Michael - sqlbot]

@FabienSnauwaert that is not accurate. Route 53 supports A-Record Aliases at the apex, which can reflect the value of an S3, CloudFront, ELB/ALB, or Elastic Beanstalk endpoint. Route 53 doesn't support a CNAME at the apex of a zone, and likely never will, because that is not a valid configuration.

[Fabien Snauwaert]

Thanks for the clarification, Michael, I appreciate it. I was trying to refer to what's called ALIAS at DNSimple, ANAME at DNS Made Easy, ANAME at easyDNS, ALIAS at PointDNS and CNAME (a misnommer) at CloudFlare and lets point say mydomain.com (www-less) to another domain (e.g.: myapp.herokuapp.com). As far as I can tell Route 53 offers no such option at this time. (EDIT: I discussed this here about another hosting company.)

[Erik Aronesty]

The lack of a CNAME at the root of a domain was an oversight in the original RFC that should have been corrected a long time ago. Clearly, a CNAME at the root should be for all record request EXCEPT an SOA, rather than making it an error, since that's completely unambiguous and works fine... even with legacy caching servers (try it... hack up a DNS server and serve a CNAME from the root... it will resolve, and get cached correctly!).

[Michael - sqlbot]

@ErikAronesty it's really not completely unambiguous. Hack the DNS server and then try to send email to the domain. Who's the mail exchanger? If you're going to make an exception for SOA, you need an exception for MX, TXT, NS, ... since CNAME means this hostname is an alias for another, this implies that those records should be looked up for the other hostname and this would not typically make sense, particularly for web hosting.

[plaisthos]

Now that ANAME records are being pursued as IETF Drafts, any change to this? datatracker.ietf.org/doc/draft-ietf-dnsop-aname