The CNAME record

This record type was introduced in the original DNS specifications (RFC 1034 and 1035) in 1987. CNAME records have not changed much since then, but CNAME remains a powerful and useful tool in any DNS toolbox.

The CNAME record has only one data field besides the usual DNS TTL field: the canonical name. The canonical name can be thought of as the target of the CNAME record. Whenever a client performs a DNS lookup for the owner name of the CNAME record, they will receive the canonical name. All DNS clients will then proceed with DNS lookup of the canonical name and add that result to the set of DNS records returned to the application.

CNAME is universally supported. Full CNAME support is required in the implementation of all DNS clients and servers.

You can look up the CNAME record for a DNS zone with our CNAME checker.

CNAME from www to the zone root

A common use of the CNAME record is to allow the “www” name in a zone to resolve to the same records as the name of the DNS zone itself. Let’s look at an example of this using the zone for ohmcar.org (a fictional electric vehicle company).

ohmcar.org. 3600 SOA ns1.ohmcar.org. ( ... )

ohmcar.org. 3600 A 10.0.0.1
ohmcar.org. 3600 A 10.0.0.2
ohmcar.org. 3600 A 10.0.0.3

www.ohmcar.org. 3600 CNAME ohmcar.org.

In this example, we have the SOA record and three IPv4 address records (type A) at the DNS zone root. There would be other records in the zone, such as NS, but they are omitted for brevity. The web presence for ohmcar.org is hosted on these three IP addresses for redundancy.

It is typical also for www.ohmcar.org to resolve in the DNS to these same three IP addresses. This allows visitors to the website to use ohmcar.org and www.ohmcar.org interchangeably in their web browser.

To make both ohmcar.org and www.ohmcar.org resolve to the same address records, the DNS administrator could copy the three type A records, so they exist at both names, but data duplication is always awkward and potentially dangerous. If a change is made in one record set but not the other, then clients may experience odd results or failures.

This sort of data copying gets complicated quickly. There may be more than three type A records, and also AAAA records may exist for IPv6. Additionally, there may be many names in a zone using canonical names, and so a lot of data will often need to be manually kept in sync.

So, instead a CNAME record should be added at www.ohmcar.org with the canonical name, or target, of ohmcar.org. Now, any change made to the address records at ohmcar.org will automatically also apply to resolution of www.ohmcar.org. This is very convenient and powerful, and it removes the possibility of errors in copied data.

Hosting multiple DNS names on the same web server

It is also common to use the same canonical name multiple times in a zone.

In the example below, portal.ohmcar.org and customerservice.ohmcar.org both resolve to the name of a backend server, which has multiple address records for redundancy. If any of the address records for the server are changed, portal.ohmcar.org and customerservice.ohmcar.org will automatically resolve to the new addresses through their respective CNAME records.

A zone could contain dozens or even thousands of similar CNAME records to map many DNS names to a single server or endpoint.

server.ohmcar.org. 3600 A 10.0.0.10
server.ohmcar.org. 3600 A 10.0.0.11
server.ohmcar.org. 3600 AAAA 2000::1
server.ohmcar.org. 3600 AAAA 2000::2

portal.ohmcar.org. 3600 CNAME server.ohmcar.org.

customerservice.ohmcar.org. 3600 CNAME server.ohmcar.org.

CNAMEs across zone boundaries

CNAMEs are not restricted to operating within a single zone. The canonical name, or target, of a CNAME record can reside in any zone in the DNS.

For example, an organization might contract out server functionality to some third party and redirect traffic from “www” in their zone to their contractor’s server host name in an entirely different zone. Note that this would have ramifications for the SSL certificates if used for HTTPS.

CNAME restrictions

There are some restrictions on the usage of CNAME records. The first is the most critical: because of the way DNS clients are expected to follow CNAME records, no other DNS record may exist at the owner name of a CNAME record. The only exception is for DNSSEC records such as NSEC and RRSIG.

Because of this rule, a CNAME may never exist at the zone root because other records (SOA and NS, and others) always exist there. Platform specific features, like CNAME flattening and alias records, can help work around this issue, as we’ll see later on.

This rule also applies to a CNAME record itself. There may only be exactly one CNAME record for any name in the DNS. RFC 2181 does an excellent job of specifying the restrictions on CNAME and clarifying a number of other aspects of the DNS. If you are interested in DNS technical details, then RFC 2181 is well worth a read!

Below are three different examples of illegal CNAME records. None of these patterns may appear in the DNS.

; Illegal CNAME at the zone root
example.org. 3600 SOA ns1.example.org. ...
example.org. 3600 CNAME server1.example.org.

; Two CNAME records at the same owner name — also illegal
alias1.example.org. 3600 CNAME server1.example.org.
alias1.example.org. 3600 CNAME server2.example.org.

; Illegal CNAME at the same name as an MX record
mail.example.org. 3600 MX 10 mailserver.example.org.
mail.example.org. 3600 CNAME mailserver.example.org.

Another restriction is that the canonical name, or the CNAME target, must be a DNS host name. This is because the DNS must be independent of the transport layer. The example below would not function properly since DNS clients would assume that 1.2.3.4 is a literal DNS host name and not an IP address:

alias1.example.org. 3600 CNAME 1.2.3.4

Also specified by RFC 2181 (in section 10.3), records of types MX and NS are forbidden to use CNAMEs, so the examples below are both illegal. Note that sometimes this rule is broken, but it is not a good idea. Mail and DNS resolution for the domain may not work properly in all scenarios!

; Illegal: the mail server host name cannot resolve to a CNAME
mail.example.org. 3600 MX 10 mailserver.example.org.
mailserver.example.org. 3600 CNAME server.example.org.

; Illegal: the name server host name cannot resolve to a CNAME
ns1.example.org. 3600 NS nameserver.example.org.
nameserver.example.org. 3600 CNAME server.example.org.

CNAMEs and performance

CNAMEs can also be linked together into chains. In the examples above we saw one DNS host name aliased to another using a single CNAME, but the canonical name of the CNAME can itself be a CNAME record, and so on. It is not uncommon to see CNAME chains with 4 or 5 records, all in different zones.

Long CNAME chains are legal and resolvers will attempt to include additional records in responses to minimize performance impact, but in general long CNAME chains are not best practice. Multiple DNS roundtrips may be required, and the complexity of long CNAME chains can make DNS resolution somewhat fragile. Try to limit CNAME chains to 2 or 3 CNAMEs at most.

Some DNS providers such as Cloudflare offer features to help reduce CNAME chains and add other interesting CNAME-related functionality, such as Cloudflare’s CNAME flattening. This feature also allows the user to effectively have CNAME functionality at the root of the zone without breaking any DNS RFCs.

In general, using a relative long TTL for CNAME records is advisable, since the canonical name usually does not change frequently. An hour (3600 seconds) is a reasonable TTL in most cases. DNS resolvers will cache the CNAME record and the address records for the canonical name of the CNAME record independently. It is common to have shorter TTLs on the address records than the CNAME records, since address records are often more dynamic than CNAME records.

Common CNAME pitfalls

One important thing to note is that the CNAME record allows redirection at the DNS level only from one DNS host name to some other DNS host name. A DNS CNAME record cannot contain a URL. It can only contain a DNS host name. The commonly-used HTTP redirect functionality implemented in a web service operates independently of the DNS.

An interesting issue with the CNAME record type is that it is quite easy to create a CNAME loop. This can be accidental, or it might be done maliciously as part of a DDoS attack to try to consume resources on resolvers and create an outage in the DNS. Since DNS resolvers must follow one CNAME to the next, and then to the next, and so on, this creates an infinite loop of CNAMEs that the resolver technically must iterate through.

The DNS administrator of any zone can create a loop with two or more CNAME records, for example:

; CNAME loop with two CNAMEs 1 -> 2 -> 1 -> 2 -> 1, etc.
alias1.example.org. 3600 CNAME alias2.example.org.
alias2.example.org. 3600 CNAME alias1.example.org.

; CNAME loop with three CNAMEs 1 -> 2 -> 3 -> 1, etc.
alias1.example.org. 3600 CNAME alias2.example.org.
alias2.example.org. 3600 CNAME alias3.example.org.
alias3.example.org. 3600 CNAME alias1.example.org.

A more complex version of this involves CNAMEs chained through different zones, which could in theory make DNS resolvers work even harder. CNAME loops, whether accidental or malicious, are well-known in the DNS world. All DNS resolvers have safeguards built in to detect CNAME loops and will reject the requests either by dropping them or by returning a DNS SERVFAIL error when a CNAME loop is detected.

Alternatives to CNAME

The ability to alias one DNS name to another DNS name is extremely useful and powerful. Over time, there have been efforts to improve upon the CNAME record, including:

• DNAME: This is a DNS record type that was created to allow an entire domain to be renamed. It is somewhat similar to CNAME but applies to an entire DNS subtree and was intended for different scenarios. DNAME is not frequently used.
• ANAME: This is a DNS record type that has been proposed but has not become standardized and currently the effort is stalled. It was an attempt to make a more powerful version of CNAME, but unfortunately, it is not feasible to garner universal support for a brand-new DNS record type of this nature. The amount of effort required to update every DNS implementation would be too large.
• Platform specific alias functionality: Some DNS hosting providers such as Route53, NS1, and Azure DNS allow the creation of an “alias record” which is converted into standard DNS records such as type A, AAAA, and CNAME when queried. These “alias records” are not true DNS record types but offer powerful and interesting functionality. Not all DNS providers have a feature of this type: for example, Cloudflare and Google currently do not.

The DNS CNAME record is an all-round powerful DNS tool, enabling redirection in the DNS and eliminating the need for tedious and error-prone duplication of DNS records. Many, perhaps most, DNS zones should have at least one CNAME, to allow www and the zone root to resolve to identical address records.

Finding the CNAME record for a zone

The CNAME record of a dns name can be queried with the dig or nslookup command line tools. To find the CNAME record for www.wikipedia.org, use this command:

dig CNAME www.wikipedia.org

On operating systems that support nslookup, you can use the following:

nslookup -type=cname www.wikipedia.org

You can also check the CNAME record of any domain name in our CNAME lookup tool, or by entering it here: