Technical reasons behind the ALIAS record

Every once in a while I come across threads or discussions describing unexpected issues with the CNAME record, generally originated from pointing a domain APEX to Heroku or another service. The root of these issues inevitably leads to the reason why two years ago we created the ALIAS record.

I recently noticed, despite documentation for the ALIAS record in our support site and that our posting several articles on the topic, we've never explained why you need to use the ALIAS record in some cases.

In this article I will try to explain the technical reason behind the ALIAS record and important limitations of the CNAME record you need to know. I'll try to avoid non-essential DNS details that may prevent less technical readers from closing this page right now.

The A and CNAME records

The A and CNAME records are the two common ways to map an host name (name hereafter) to one or more IP address. Before going ahead, it's important that you really understand the differences between these two records. Please take a minute to read the support article, if you're not familiar with them.

The limitations of the CNAME record

This section is the essence of the entire article. The CNAME record, other than being required to point to a name instead of an IP, has another important limitation: a CNAME record is not allowed to coexist with any other data.

In other words, if blog.dnsimple.com is a CNAME for example.com, you can't have any other records attached to blog.dnsimple.com, for example no MX records (which means no emails @blog.dnsimple.com), no TXT records and, even more importantly, no NS records.

This explains why you cannot use a CNAME for aliasing your root domain (apex domain) to another name. Let's take the dnsimple.com root domain. You expect at least one NS record associated to the name, one SOA record, one or more MX records (we want to use @dnsimple.com emails!) and possibly some TXT records used by third parties such as the Google Webmaster Tools.

    dnsimple.com.   SOA	ns1.dnsimple.com. admin.dnsimple.com. ...
    dnsimple.com.	NS	ns1.dnsimple.com.
    dnsimple.com.	NS	ns2.dnsimple.com.
    dnsimple.com.	NS	ns3.dnsimple.com.
    dnsimple.com.	NS	ns4.dnsimple.com.
    dnsimple.com.	MX	1 mail.dnsimple.com.

There are cases where this limitation is perfectly fine. The most notable the www name, universally recognized as the alternate address for your root domain. It's very common to configure the www record as a CNAME for the root domain (zone apex). The benefit is that, if you change the IP address of your site, you will only have to update one record, instead of two (or more).

  www.dnsimple.com. CNAME dnsimple.com.

Here the limitations of the CNAME record are irrelevant. In fact, we don't need to have @www.dnsimple.com email addresses and we hardly need to attach other DNS records to this name.

Mixing CNAME with other records

But what does it happen if you create additional DNS records in combination with a CNAME for a specific name? It depends.

In most common name server software and libraries, only the CNAME will be returned for a DNS query to the name. All the other records will be silently ignored. No error messages, no warning. This is why we occasionally get clients confused because they used a CNAME for their blog, but they are not able to add the Google Verification token to it.

Here comes the ALIAS record

At this point, I hope it's clear why it's not possible (practically speaking) to use a CNAME for aliasing the root domain (zone apex) to another name.

Here comes the ALIAS record. We created the ALIAS record with two goals in mind:

1. Make it possible to alias the root domain to another service
2. Make it possible to use an alias system that can coexist with other data

These are, in fact, the two common cases why you want to use the ALIAS record.

It makes very simple to alias your root domain to another name. In most cases you can simply replace the CNAME with a standard A record as long as the target name resolves to a single IP, but distributed architectures such as Heroku or GitHub Pages resolve with a pool of IP addresses and aliasing is the most effective way to setup your DNS records.

Likewise, there are situations where you want to use record aliasing, but you can't use a CNAME because you need other records for the same name. This is again a perfect case for the ALIAS record.

Externally, the ALIAS record behaves like an A record returning one or more A records matching the alias target. Because the A record doesn't have the limitation described before for the CNAME record, likewise the ALIAS record doesn't inherit them.

I hope this article put some light on the topic. If you have any questions, feel free to contact us.

Happy ALIASing!

Share on Twitter and Facebook

Simone Carletti

Italian software developer, a PADI scuba instructor and a former professional sommelier. I make awesome code and troll Anthony for fun and profit.