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.
DNS standards say you can't have a CNAME at the domain Apex, you need an A record.
Some providers will let you do this against standards. CloudFlare does this in a tricky way, it appears to let you create a CNAME at the domain apex but does it in a way that's standards compliant using a proxy system - Michael explains it well below.
The best option is to use AWS Route53 and alias records. Route53 takes over the job of providing DNS for the domain, you no longer need your previous DNS provider.
Best Answer
A engineer on the Route 53 team informed me that creating the proprietary alias can be created in the Route 53 Console (the GUI).
Here are the steps.
DNS Name: new-balancer-751654286.us-east-1.elb.amazonaws.com (A Record)
ipv6.new-balancer-751654286.us-east-1.elb.amazonaws.com (AAAA Record)
dualstack.new-balancer-751654286.us-east-1.elb.amazonaws.com (A or AAAA Record)
Note: Because the set of IP addresses associated with a LoadBalancer can change over time, you should never create an “A” record with any specific IP address. If you want to use a friendly DNS name for your LoadBalancer instead of the name generated by the Elastic Load Balancing service, you should create a CNAME record for the LoadBalancer DNS name, or use Amazon Route 53 to create a hosted zone. For more information, see the Using Domain Names With Elastic Load Balancing at http://docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/using-domain-names-with-elb.html.
Status: 0 of 0 instances in service
Port Configuration: 80 (HTTP) forwarding to 80 (HTTP)
Stickiness: Disabled(edit)
Availability Zones: us-east-1b
Source Security Group: amazon-elb-sg
Owner Alias: amazon-elb
Hosted Zone ID: Z3DZXD0Q79N41H