Differences between the A,
CNAME, ALIAS and URL records
A, CNAME, ALIAS and URL
records are all possible solutions to point a host name (name hereafter) to
your website.
However, they have some small differences that affect how the client
will reach your site.
Before going further into
the details, it’s important to know that A and CNAME records are standard DNS
records, whilst ALIAS and URL records are custom DNS records. Both are translated internally into A records to ensure
compatibility with the DNS protocol.
Here’s the main differences:
The A record maps a name to
one or more IP addresses, when the IP are known and stable.
The CNAME record maps a name
to another name. It should only be used when there are no other records on that
name.
The ALIAS record maps a name
to another name, but in turns it can coexist with other records on that name. The URL record redirects the
name to the target name using the HTTP 301 status code.
Some important rules to keep
in mind:
The A, CNAME, ALIAS records
causes a name to resolve to an IP. Vice-versa, the URLrecord redirects the name
to a destination. The URL record is simple and effective way to apply a
redirect for a name to another name, for example to redirect www.example.com to
example.com.
The A name must resolve to
an IP, the CNAME and ALIAS record must point to a name.
Which one to use
Understanding the difference
between the A name and the CNAME records will help you to decide.
The general rule is:
use an A record if you
manage what IP addresses are assigned to a particular machine or if the IP are
fixed (this is the most common case)
use a CNAME record if you
want to alias a name to another name, and you don’t need other records (such as
MX records for emails) for the same name
use an ALIAS record if you
are trying to alias the root domain (apex zone) or if you need other records
for the same name
use the URL record if you
want the name to redirect (change address) instead of resolving to a
destination.
You should never use a CNAME
record for your root domain name (i.e. example.com).
The A and CNAME records are
the two common ways to map a 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. I’ll keep it simple.
The A record points a name
to a specific IP. For example, if you want the name blog.dnsimple.com to point
to the server 185.31.17.133 you will configure:
blog.dnsimple.com. A
185.31.17.133
The CNAME record points a
name to another name, instead of an IP. The CNAME source represents an alias
for the target name and inherits its entire resolution chain.
Let’s take our blog as
example:
blog.dnsimple.com. CNAME
aetrion.github.io.
aetrion.github.io. CNAME
github.map.fastly.net.
github.map.fastly.net. A
185.31.17.133
We use GitHub Pages and we
set blog.dnsimple.com as a CNAME of aetrion.github.io, which in turns is itself
a CNAME of github.map.fastly.net, which is an A record pointing to
185.31.17.133. In short terms, this means that blog.dnsimple.com resolves to
185.31.17.133.
To summarize, an A record
points a name to an IP. CNAME record can point a name to another CNAME or an A
record.
The chief difference between
a CNAME record and an ALIAS record is not in the result—both point to another
DNS record—but in how they resolve the target DNS record when queried. As a result of this difference, one is safe
to use at the zone apex (e.g., naked domain, such as example.com) and the other
is not.
Let’s start with the CNAME
record type. It simply points a DNS
name, like www.example.com, at another DNS name, like lb.example.net. This introduces a performance penalty, since
at least one additional DNS lookup must be performed to resolve the target
(lb.example.net). In the case of neither
record ever having been queried before by your recursive resolver, it’s even
more expensive time-wise, as the full DNS hierarchy must be traversed for both
records:
You as the DNS client (or
stub resolver) query your recursive resolver for www.example.com.
Your recursive resolver
queries the root name server for www.example.com
The root name server refers
your recursive resolver to the .com Top-Level Domain (TLD) authoritative
server.
Your recursive resolver
queries the .com TLD authoritative server for www.example.com.
The .com TLD authoritative
server refers your recursive server to the authoritative servers for
example.com.
Your recursive resolver
queries the authoritative servers for www.example.com, and receives
lb.example.net as the answer.
Your recursive resolver
caches the answer, and returns it to you.
You now issue a second query
to your recursive resolver for lb.example.net.
Your recursive resolver
queries the root name server for lb.example.net.
The root name server refers
your recursive resolver to the .net Top-Level Domain (TLD) authoritative
server.
Your recursive resolver
queries the .net TLD authoritative server for lb.example.net.
The .net TLD authoritative
server refers your recursive server to the authoritative servers for example.net.
Your recursive resolver
queries the authoritative servers for lb.example.net, and receives an IP
address as the answer.
Your recursive resolver
caches the answer, and returns it to you.
Each of these steps consumes
at least several milliseconds, often more, depending on network
conditions. This can add up to a
considerable amount of time that you spend waiting for the final, actionable
answer of an IP address.
In the case of an ALIAS
record, all of the same actions are taken as with the CNAME, except the
authoritative server for example.com performs steps six through thirteen for
you, and returns the final answer of an IP address.
This offers two advantages
and one significant drawback:
Advantages
Faster final answer
resolution speed. In most cases, the authoritative servers for example.com are
more powerful and have faster Internet connectivity than your own computer and
connection. They can therefore traverse
the DNS hierarchy and retrieve the final answer much faster than you can.
Answer looks like an A
record. Since an ALIAS record returns the final answer consisting of one or
more IP addresses, it can be used anywhere an A record can be used—including
the zone apex. This makes it more flexible than a CNAME, which cannot be used
at the zone apex.
Disadvantages
Geotargeting information is
lost. Since it is the authoritative server for example.com that is issuing the
queries for lb.example.net, then any intelligent routing functionality on the
lb.example.net record will act upon the location of the authoritative server,
not on your location. The EDNS0 edns-client-subnet option does not apply here.
This means that you may be potentially mis-routed: for example, if you are in
New York, and the authoritative server for example.com is in California, then
lb.example.com will believe you to be in California and will return an answer
that is distinctly sub-optimal for you in New York.
One important thing to note
is that NS1 collapses CNAME records provided they all fall within the NS1
system, i.e., NS1’s nameservers are authoritative for both the CNAME and the
target record. Collapsing simply means that the NS1 nameserver will return the
full chain of records, from CNAME to final answer, in a single response. This eliminates all the additional lookup
steps, and allows you to use CNAME records, even in a nested configuration,
without any performance penalty.
And even better, NS1
supports a unique record type called a Linked Record. This is basically a
symbolic link within DNS that acts as an ALIAS record might, except with
sub-microsecond resolution speed. To use
a Linked Record, simply create the target record as you usually would (it can
be of any type) and then create a second record to point to it, and select the
Linked Record option. Note that Linked
Records can cross domain (zone) boundaries and even account boundaries within
NS1, and offer a powerful way to organize and optimize your DNS record
structure.