As described in RFC 1034, a CNAME record in the DNS identifies the canonical name of an alias. In other words, CNAME records simply point to another domain name that may contain the requested record type. They are often used to simplify system configuration and expedite maintenance.
For example, if you have a particularly complex record configuration or if you need to implement a new service (e.g., a new CDN), you can create a CNAME record that mirrors the configuration of the parent record instead of having to configure both records manually.
CNAME records, however, have limitations. For example, you cannot create a CNAME record at the zone apex and resolution may be slower depending on where the target domain is hosted. To address these limitations, there are two NS1 record types that can be used instead:
-
An ALIAS record provides CNAME-like functionality at the zone apex.
-
A linked record may offer faster resolution than a CNAME when the target record is also hosted on the NS1 platform.
Whether you use a CNAME, ALIAS, or linked record, it’s important to understand the difference between these record types, when to use them, and each of their unique limitations. This article explains the difference between these record types, including the expected behavior and when to use and not to use them.
Below are a few key terms and concepts relevant to understanding different record types:
-
Source: the indirect record or child record (i.e., the CNAME, ALIAS, or linked record)
-
Target: the resulting endpoint or parent record
-
Advanced configuration: an NS1-specific record configuration using filters or metadata
-
Zone apex: the root domain name to which the SOA record refers; the zone with no further hostnames attached (e.g. example.com)
As described in RFC 1034, a CNAME record indicates the canonical name of an alias. CNAME is the most well-known way to “symlink” one DNS record to another. It works by answering queries that ask for the source with a simple referral (by domain name) to the target, which can be anywhere else on the internet. If the target record exists in the same zone, NS1 will automatically add the target answer to the query result, eliminating additional round trips. Otherwise, full CNAME resolution may require the DNS recursive resolver to make additional, subsequent requests.
When queried, a CNAME will always include a CNAME record in the response and, as described, might also include the resolved record pointing to the target — typically, an A or AAAA record. The biggest challenge with CNAME records is that, according to the DNS RFC, they cannot be used at the zone apex level. If you wish to point your zone apex to another record, use an ALIAS record.
|
When to use a CNAME record |
Create a CNAME record to implement simple indirection via referrals. In other words, use a CNAME when you want queries to the current domain name to be answered by records at another domain name. |
|
When not to use a CNAME record |
Do not use CNAME records when:
|
|
Source record type |
CNAME (RFC 1034) |
|
Target record type |
Any (typically A or AAAA) |
|
Query result |
If the CNAME points to a domain name in the same NS1 zone, then the authoritative nameserver will return the target response if the record type exists. For example, if www.example.com has a CNAME record pointing to example.com, an authoritative nameserver will return both the CNAME record and the A record in the same response. This means the resolver does not have to send two DNS queries. |
|
Chaining allowed? |
Yes |
|
Can point to domains outside of NS1? |
Yes |
|
Included in zone transfers? |
Yes, because they are RFC-compliant, CNAME records are included in both incoming and outgoing zone transfers. |
(NS1-specific) ALIAS is a special record type that works like a CNAME record but can be used safely at the zone apex. On the NS1 platform, ALIAS records always resolve to A and AAAA records by running a DNS resolver in each of NS1’s PoPs. Resolution to the target is a completely internal process — DNS recursors making the query will not be able to differentiate between an ALIAS record and an A (or AAAA) record. An ALIAS record will always return one or more A or AAAA records. Since ALIAS is a pseudo-record, the response will never include the ALIAS record itself.
Note
ALIAS records are the only record type that can be added to a secondary zone on the NS1 platform.
Note
During ALIAS record configuration, you have the option to override any address records (A or AAAA) during the lookup process. In most cases, NS1 recommends leaving this option disabled for ALIAS records on primary zones and enabling it for ALIAS records on secondary zones. Refer to this article to learn more about ALIAS record configuration.
|
When to use an ALIAS record |
Use ALIAS records to achieve CNAME-like behavior at the primary or secondary zone apex. |
|
When not to use an ALIAS record |
Do not add an ALIAS record outside of the zone apex. |
|
Source record type |
ALIAS (NS1-specific pseudo record) Note: NS1's ALIAS records are not part of the DNS specification. |
|
Target record type |
A or AAAA (address) record |
|
Query result |
A or AAAA record(s) |
|
Chaining allowed? |
Not recommended |
|
Can point to domains outside of NS1? |
Yes |
|
Included in zone transfers? |
No |
A linked record points to another (target) record hosted elsewhere on the NS1 platform and responds to queries using the same answers and traffic steering configurations applied to the target record. Linked records help avoid the timely and error-prone tasks of manually creating and maintaining identical configurations across multiple records. Additionally, compared to CNAME records, a linked record typically requires one less DNS lookup which can shorten the response time for the requesting resolver or client to receive the final answer.
When queried, the NS1 authoritative server uses the full configuration details specified in the original record (also referred to as the “real” or “target” record) to resolve the query. This includes any advanced configurations like a Filter Chain and any connected data feeds. Any changes made to the original record are automatically reflected in the response when a linked record is queried.
Note
Linked records can point to any target record hosted on the NS1 platform, whether it is in the same zone or not.
For example, a CDN using NS1 DNS services can instruct its customer (who is also using NS1) to use a linked record to point to the customer’s domain at the CDN, instead of a CNAME. This eliminates DNS round trips and (for A or AAAA records) allows direct resolution at the zone apex. A linked record can be any record type (A, MX, CNAME, etc.), but it must be the same type as a target or it will not resolve.
Linked records are specific to NS1, and their resolution is an entirely internal process. During resolution, the full configuration from the target record (including advanced configuration options) is duplicated into the source record such that (other than the name of the record) they resolve identically. DNS recursors making the query cannot differentiate between a linked record and the “real” target to which it points.
Linked records support all NS1 features and capabilities used by the target record — including real-time data feeds.
|
When to use a linked record |
Use linked records to reuse an existing NS1 record as opposed to creating and maintaining a separate one. |
|
When not to use a linked record |
Do not use a linked record if you will need to edit the configuration of one record, but not the other. |
|
Source record type |
You can create a linked record that points to any other record type on the NS1 platform except for URLFWD records. |
|
Target record type |
(same as source) |
|
Query result |
Based on target (In other words, NS1 will defer to the “real” or original record to determine how to answer each query.) |
|
Chaining allowed? |
Yes |
|
Can point to domains outside of NS1? |
No |
|
Included in zone transfers? |
No |
|
Notes |
You can only create a linked record within a primary (or non-secondary) zone. |