Late last year we introduced the ALIAS virtual record type at DNSimple. Since then we've had numerous people ask us how we implemented the functionality. While we are always making incremental changes, here is an overview of how it works:
When one of our authoritative name servers receives a request for an A record, CNAME record or the ANY type and there is a corresponding name with an ALIAS record, our name server will attempt to resolve the name found in the content part of the ALIAS record. For example, if the ALIAS points to proxy.herokuapp.com, then our authoritative server will resolve the name proxy.herokuapp.com and return its associated A records. If the name is a CNAME
argon-stack-1879049447.us-east-1.elb.amazonaws.com record then our authoritative name servers will resolve the CNAME down to its A records. Ultimately we will always return A records in place of an A record, or a negative response if we cannot resolve the name.
Our authoritative name servers query local resolvers and will respect the TTL of the resulting records that it found. Thus if our authoritative name server resolves an ALIAS to an A record with a TTL of 60 seconds, we can cache the result for up to 60 seconds, reducing the response times for returning a successful result. We also return the currently cached TTL from the resolver, which will always be less-than or equal to the TTL specified on the original A record.
One of the biggest challenges is that resolvers may set their internal timeouts quite low, expecting a very fast response from authoritative name servers. Normally this is not a problem since the overhead of resolving the ALIAS name to its A records is usually fairly low. This is not always the case though, which is why we've spent time tweaking our own internal timeouts to improve the likelihood that we can return a result in a reasonable amount of time. It's not perfect but we've got some more ideas on how to improve this even more.
Another challenge is that ALIAS records are currently not portable. There's not much we can do about that at the moment, but in the future we plan on working with the DNS community to prepare an RFC that defines how the ALIAS record should behave. We believe that virtual records are an important part of DNS and thus an official RFC would be a useful addition to the existing DNS RFCs.
Ultimately our goal is to continue advancing the state of art for DNS and domains. We have more coming down the pipe and as always welcome ideas and feedback from you to help improve DNSimple and DNS in general.
I break things so Simone continues to have plenty to do. I occasionally have useful ideas, like building a domain and DNS provider that doesn't suck.
Configure DNSimple as your secondary DNS provider to improve your domain's availability and redundancy with AXFR zone transfers.
Get a free limited-edition t-shirt featuring the characters of howdns.works and howhttps.works with any new yearly subscription to DNSimple.