Entry Updated: July 2nd, 2012
How familiar are you with DNS? Wikipedia states:
The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. A Domain Name Service resolves queries for these names into IP addresses for the purpose of locating computer services and devices worldwide. By providing a worldwide, distributed keyword-based redirection service, the Domain Name System is an essential component of the functionality of the Internet.
In simple terms, it is the address book system of the internet, converting human-friendly addresses (such as andrewallen.co.uk) in to computer-friendly IP addresses.
Ok, so you knew that much already. How familiar are you with DNS resource records?
A Resource Record (RR) is the basic data element in the domain name system. Each record has a type (A, MX, etc.), an expiration time limit, a class, and some type-specific data. Resource records of the same type define a resource record set (RRset). The order of resource records in a set, returned by a resolver to an application, is undefined, but often servers implement round-robin ordering to achieve Global Server Load Balancing. DNSSEC, however, works on complete resource record sets in a canonical order.
When dealing with a web site, there are two particular types of resource record that people mostly care about – the A record, which translates a hostname to an IP address, and the CNAME record, which allows you to alias one hostname to another.
How about the ANAME record? Ever heard of that before? Nope, neither did I until today.
For an increasing number of years, I’ve chosen to host all my domain zone files with DNS Made Easy – not only are they cost effective, but they guarantee 100% uptime across their geographically distributed IP Anycast network. When I moved my blog across to Amazon S3 / Amazon CloudFront from Posterous, I did do some research into whether I should also migrate to Amazon Route 53, Amazon’s own DNS service, however I found many comments showing people were actually seeing DNS Made Easy outperform all other similar service offerings, including Route 53.
Not only that, DNS Made Easy offer a number of other services, which simply isn’t offered anywhere else, and one such unique service announced today is the ANAME resource record type.
What is an ANAME record?
“DNS Made Easy are the first provider in the world to revolutionize the way DNS zones can be configured using the ANAME record”
Their words, not mine, however:
CNAME records cannot be created for the apex, or root record, of a domain. This is invalid based on DNS RFC’s, yet required in certain configurations.
CNAME records must be unique based on DNS RFC’s. Administrators can not create any other record type with the same name as a CNAME record or use multiple records in a round robin configuration. This is also required in certain configurations.
CNAME record resolution is slower based on the fact that they require a double lookup. Once to find the CNAME record itself, and a second to find the referred IP address.
What are the advantages?
When an ANAME record is created, DNS Made Easy internally monitored the fully qualified domain name (FQDN) of the IP address. We then create the associated A records that point to the IP address of the FQDN. When the IP address changes, the A records are updated immediately across all DNS Made Easy name servers.
ANAME records can be used as the root record for a domain as the resulting records created are A records which bypasses the limitation of allowing the alias at the root record.
Multiple ANAME records can be configured with the same name and all additional IP’s will be added in a round robin configuration in DNS Made Easy.
ANAME record speed up DNS performance as the correct IP address is returned on the first lookup rather than requiring multiple queries. Faster DNS lookups result in fast website load times which improves SEO.
Just this evening I switched over a number of CNAME entries on andrewallen.co.uk, which currently reference Amazon S3 and CloudFront hostnames, over to ANAME records instead. When you now carry out a DNS lookup against http://www.andrewallen.co.uk, you’ll now see that instead of a CNAME redirection to an Amazon CloudFront hostname, A records of the resolved IP address for the CloudFront hostname are returned instead.
This means your client machine has had to carry out one less DNS lookup in order to resolve my site, so basically speeding up the whole process of viewing the site. In the world of user experience, response times are everything – that’s what Jakob Neilsen’s research shows anyway…
Update: July 2nd, 2012
Following a question posted in the comments by iwod, I developed a few further questions in my head about the service.
Depending on the type of DNS Made Easy account you purchase, you’ll be allocated a finite number of DNS queries that can be made against your zones – in my case, I have the business account and so allowed 10 millon queries per month, totalled across all my managed zones. I wondered, due to the nature of how ANAME records work, if this would impact the monthly query amount allocated to my account, as I have no control over how often the referenced hostname is checked? I can only control the TTL on my resource records, i.e. the resulting A records that are returned to lookups against my zone.
A reply back to this post from Richard at DNS Made Easy confirmed that…
“… ANAME records would not impact your monthly query count anymore than a CNAME would. In fact if you are creating a ANAME to another domain within DNS Made Easy it would actually save queries since there is no longer the requirement to do a double lookup.”
“There will be a minimal amount of checks against your domain if your target to your ANAME record is within DNS Made Easy, but nothing that should exceed a few thousand queries per month. This will generally save users on queries as well though since it would involve a double-lookup normally.”
The other query I had was around the use of ANAME records against my assigned Amazon CloudFront domain name. Once you’ve created a distribution within Amazon CloudFront, assigned the origins and setup the CNAME entries you want recognised against the distribution, you’ll then be assigned a unique domain name – you can then create a CNAME resource record against this within your own DNS zone.
As briefly mentioned, I have setup two CNAME resource records in my DNS Made Easy account:
static.andrewallen.co.uk, which references my website enabled Amazon S3 bucket (static.andrewallen.co.uk.s3-website-eu-west-1.amazonaws.com)
http://www.andrewallen.co.uk, which references my Amazon CloudFront domain name (d2pmvviymfwb5p.cloudfront.net)
When DNS Made Easy launched their ANAME resource records last week, I replaced both the above CNAME records with ANAME records instead – once updated, I could see that A record responses were now being returned, but I’ve now just noticed an unintended side effect.
I originally decided to use Amazon CloudFront because it can deliver my entire website, including dynamic, static and streaming content using a global network of edge locations – requests for content are automatically routed to the nearest edge location, so content is delivered with the best possible performance.
Because I have now switched to using ANAME records, when my referenced Amazon CloudFront domain name (d2pmvviymfwb5p.cloudfront.net) is resolved to an IP address by DNS Made Easy, the request is directed to the nearest edge location to the requester, i.e. nearest to the DNS Made Easy servers. The response is then stored to use for lookups against my zone, which won’t necessarily be the optimal location for everyone else – so in effect, all requests against my website are being directed to the same edge location, regardless of the requesters location, removing the effect and benefits of using Amazon CloudFront.
By carrying out a traceroute from my location in the UK, I am routed 17 hops to http://www.andrewallen.co.uk, with 100ms latency to the final hop, compared to 13 hops to d2pmvviymfwb5p.cloudfront.net, with 21ms latency to the final hop.
I’ve checked my AWS Usage Reports which also confirms the same – all traffic since the DNS update has been served out of the same region.
The end result appears that configuring ANAME records against a CDN provider such as Amazon CloudFront is not recommended, due to it not taking into consideration the latency based routing used to connect you to the nearest edge location. There are still benefits for using ANAME records against all other addresses not distributed through a content delivery network, such as a website enabled Amazon S3 bucket, as it will remove the extra lookup, as designed.
If ANAME records are to be useful alongside Amazon CloudFront, DNS Made Easy would have to recognise the various edge locations within Amazon’s Global Infrastructure, and adapt automatically on how those results are then returned.
For my own site, I’ve swapped the ANAME entry referencing my Amazon CloudFront domain name back to a CNAME resource record (www.andrewallen.co.uk), since overall lower latency is more important than the initial DNS lookup, but I have left in place the ANAME directly referencing my Amazon S3 bucket (static.andrewallen.co.uk).