ANAME or ALIAS DNS Records are now supported
Now you can create a CNAME at the apex!
We’ve avoided it for a long time because being RFC compliant is important to us. But due to overwhelming demand driven by clouds and CDNs (and ultimately, customers!), we finally released our ANAME record type.
ANAME?
ANAME stands for Alias Name and is very similar to a CNAME, or canonical name. CNAMEs allow you to take any host and “point it to” another FQDN. For example, your AWS load balancer might want you to point your “www” record over to d3d4tu57145qya.cloudfront.net. No problem, that’s easy to do.
But when they ask you to do the same for the apex/root of your domain, you’re stuck! CNAME records don’t support an apex or root record, and A records require an IP address. So what are you to do?
Some folks will resolve d3d4tu57145qya.cloudfront.net to determine what IP address(es) are being given out and create the corresponding A records to handle it. And while that often works, it doesn’t work for very long. One of the reasons organizations like AWS use these DNS names is so they can rotate IP addresses on a regular basis. They do this for a variety of reasons, but we won’t get into that here, because we disagree with a few of them.
Enter ANAME to the rescue
The ANAME record type does exactly what we’ve alluded to. It allows you to create a root/apex entry (in our case, that’s a host of @) and direct it to a FQDN, exactly like a CNAME. This record type will allow you to create that special record that all those clouds want you to do. And, much like a CNAME record, when you query it, it gives out an IP based on the “Points To” value.
How does it work?
Our implementation mimics CNAME records closely, except it uses a pre-fetch or “flattening” method. Our system constantly checks the “Points to” value to keep the IP addresses for your ANAME record up-to-date. A CNAME will only fetch the IP address when queried, but that can add some lookup latency. With this approach, an ANAME is just as fast as a regular A record.
AAAANAME
Whether the “Points to” value of your ANAME resolves to an IPv4, IPv6 or one or multiple IP addresses, we’ve got it covered. Our implementation will ensure that every IP is used. And, with IPv6 support, the ANAME is technically also an AAAANAME too, but a record type like that seems silly, so we just cover it all under one umbrella.
Why didn’t you do this before?
This is a fair question we receive often. Our DNS platform has always been strictly RFC compliant. Following the letter of the law is important to us, but if all the cloud providers are breaking the rules, then I suppose it’s only fair that we finally bend them a little too. And honestly, our customers keep asking. This implementation is RFC compliant in the sense that it takes the ANAME record type that the DNS industry created and flattens it to create actual, compliant A and AAAA records.
Are there any downsides to the ANAME?
There are only a couple of potential downsides to this concept. First, if your provider changes the IP addresses behind the “Points to” FQDN more frequently than once per minute, we may not be up-to-date. But we rarely encounter this problem.
For example, if you use a service like AWS CloudFront, the 4 IPs they give out are dynamic, but they change so infrequently that it’s easy for us to stay up-to-date. In fact, we specifically tested with CloudFront and it was very easy for us to stay up-to-date. Furthermore, when they do swap out the IPs, the old ones remain in service for a short period of time while they are phased out, so there is no negative impact because by the time they are fully phased out, we haven’t given them out for a while.
The second drawback is potentially how we designed the back-end resolution mechanism. We check for IP addresses based on the US-East region. If your “Points to” FQDN gives out different IPs based on where you query it around the world, then there may be some added latency as a result. But for most customers, this isn’t an issue since the vast majority redirect to another record anyway, like www.
In the future, if demand dictates, we’ll implement a more global approach and update our design to look up FQDN values globally so every POP can give out A and AAAA records unique to that region, if the cloud provider stipulates that. So if that’s important to you, just let us know. The more customers that ask, the sooner we’ll develop it!