DNS Crash Course, Part 3: CNAME Records

Quick note: It's been a while since I've written a new post for my DNS Crash Course series. Life gets in the way and things get re-prioritized. Nevertheless, here is the third installment of this series, this time on CNAME records.

CNAME records can be useful, depending on what you need to accomplish with DNS. The "C" in CNAME stands for canonical, which means "accepted as being accurate and authoritative".

The term implies that the CNAME record is not the primary record for the domain (that would be the A Record), but in fact defers to an A record for a hostname as the source of truth. Hence, doing a lookup on an alias domain (always a subdomain) is called a canonical lookup because it's looking for the authoritative record for the subdomain. Take my own example of:

autodiscover.classicyuppie.com.    300 IN  CNAME   mail909.itekmail.com.  

Here, the autodiscover entry for my email configuration can be looked up at autodiscover.classicyuppie.com. That hostname exists in DNS, and will redirect all queries to mail909.itekmail.com. That defines the roll of a CNAME record in a nutshell. It's job is to direct traffic to another hostname that has an finite endpoint, provided the endpoint hostname has a corresponding A record in their DNS zone.

CNAME records come with some pre-existing rules to ensure they work correctly.

  • CNAME records must always point to another hostname, not an IP address. Otherwise you're effectively setting up an A record.

  • The hostname you're defining in a CNAME record must not have another DNS entry. To use the example above, I would not be able to have autodiscover.classicyuppie.com already exist with an A record (pointing to an IP address), or an MX record (to receive email). The CNAME record has a specific purpose that cannot be confused with another record type.

  • You cannot have a DNS zone file contain only a CNAME record. The minimum requirement for a DNS zone file is an A record.

  • It is not recommended to use CNAME records to transact email between servers as this can cause mail to be dropped if the record breaks behind the scenes.

  • Care must be taken to not form an infinite loop redirect, as it's entirely possible within DNS to create the following record:

foo.example.com.  CNAME  bar.example.com.  
bar.example.com.  CNAME  foo.example.com.  

This will cause a redirect loop that will result in a timeout message being displayed in the browser.


There are only two viable reasons you should need to set up a CNAME record. The first is for the purpose of redirecting a subdomain to an alternate resource. You'd do this to give a finite endpoint an easier way to be referenced with a casual hostname, like with the example of an email autodiscover record. Which is easier for you to remember - autodiscover.example.com or mail.someserver.com/autodiscover/autodiscover.xml?

The second reason to use a CNAME record is to prove ownership of a root domain, sometimes called a second-level domain, like example.com. To prove domain ownership, a service provider like a web host might ask you to create a CNAME record and point the target to a specific hostname they control (i.e., 89yk4e.yourisp.com). The idea behind this is that if you can modify your domain's DNS records, you must be the rightful owner of the domain in question, and this is proven after the DNS record you add has had time to propagate, and the service provider completes the validation check successfully.

A word on CNAME redirects to alternate domains

I've been told in the past that it's useful for redirecting popular misspellings of domain names like "Gooogle.com", however, if you perform a DNS query on that domain, you'll find that it's actually redirecting based on an A record, not a CNAME record.

;Gooogle.com.            IN  CNAME

Gooogle.com.        60  IN  SOA ns3.google.com. dns-admin.google.com. 115138126 900 900 1800 60  

Since dig returns an start of authority (SOA) record in the example above, that indicates the name server does not have a CNAME record on file to be returned in the query. Performing the same lookup for an A record returns:

;Gooogle.com.            IN  A

Gooogle.com.        300 IN  A  

If you put gooogle.com in your browser, it will redirect to https://www.google.com/?gws_rd=ssl, indicating that the redirect is happening on the server itself. DNS was never intended to handle redirects of domains, and traffic switching of this type is more efficiently handled with Apache's mod_rewrite or http_rewrite_module in NGINX. The more onus you put on DNS to do the dirty work, the less efficient your zone file becomes.

I've seen domain owners (and I've been guilty of this myself), of setting up redirects like:

mail.somedomain.com CNAME outlook.com  

This is great and will actually work, until the domain owner decides to block incoming CNAME redirects. This will cause your rule to break, because in setting it up, you've chosen to link to a resource you don't control (in the example above, outlook.com).

A lesser understood side-effect of using CNAME redirects is that you could experience an invalid NXDOMAIN response through hijacked DNS, if the record is not set up with care. This can be done either by ISPs or by registrars themselves. You'd essentially be hijacking your own domain.

Another limitation of CNAME redirects is that it will almost always cause SSL/TLS certificate errors in-browser. Say you want to set up a redirect over HTTPS. When the domain attempts to redirect in the browser, it will cause a certificate mismatch error to result, alerting the user that the certificate for the first domain doesn't match the second domain.

Don't be that guy (or gal) who causes unnecessary confusion for your users and site visitors. Set your CNAME records up properly, use them for their intended purpose, and you'll be just fine.

My next post in the DNS Crash Course series will be on TXT records. Until then, you can recap with my previous posts covering A, AAAA, and PTR records, and MX records.