Editing CNAME record (section)

== Details ==
DNS CNAME records are specified in {{IETF RFC| 1034}} and clarified in Section 10 of {{IETF RFC| 2181}}.

CNAME records are handled specially in the domain name system and have several restrictions on their use. When a [[DNS resolver]] encounters a CNAME record while looking for a regular resource record, it will restart the query using the canonical name instead of the original name. However, if the resolver is specifically told to look for CNAME records, the canonical name (right-hand side) is returned, rather than restarting the query. The canonical name that a CNAME record points to can be anywhere in the DNS, whether local or on a remote server in a different [[DNS zone]].

For example, consider a DNS zone as follows:
{{sxhl|2=zone|
NAME                    TYPE   VALUE
--------------------------------------------------
bar.example.com.        CNAME  foo.example.com.
foo.example.com.        A      192.0.2.23
}}
When an [[A record]] lookup for ''bar.[[example.com]]'' is carried out, the resolver will see a CNAME record and restart the lookup for ''foo.example.com'' and will then return 192.0.2.23.

=== Possible confusion ===
With a CNAME record, one can point a name such as "''bar.example.com''" to "''foo.example.com''". Because of this, during casual discussion, the "''bar.example.com.''" (left-hand) side of a DNS entry can be incorrectly identified as "the CNAME" or "a CNAME". However, this is inaccurate. The canonical (true) name of "''bar.example.com''" is "''foo.example.com''". Because CNAME stands for Canonical Name, the right-hand side is the ''actual'' "CNAME"; on the same side as the address "A".

This confusion is specifically mentioned in RFC 2181, "Clarifications to the DNS Specification". The left-hand label is an alias for the right-hand side (the RDATA portion), which ''is'' (or should be) a canonical name.<ref>{{cite web |url=http://tools.ietf.org/html/rfc2181#section-10.1.1 |title=RFC 2181: Clarifications to the DNS Specification |date=July 1997 |access-date=2011-03-09 |publisher=[[Internet Engineering Task Force|IETF]] }}</ref> In other words, consider the following CNAME record:
{{sxhl|2=zone|bar.example.com.        CNAME  foo.example.com.}}
This may be read as saying that "''bar.example.com''" is an alias for the canonical name (CNAME) "''foo.example.com''". A client will request "''bar.example.com''" and the answer will be "''foo.example.com''".

=== Restrictions ===
{{unordered list
|CNAME records must always be pointed to another domain name, never to an IP address.
|If a CNAME record is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. (RFC 1034 section 3.6.2, RFC 1912 section 2.4) The exception is when [[DNSSEC]] is being used, in which case there can be DNSSEC related records such as RRSIG, NSEC, etc. (RFC 2181 section 10.1)
|CNAME records that point to other CNAME records should be avoided due to their lack of efficiency, but are not an error.<ref name="RFC1034">{{cite web|url=https://tools.ietf.org/html/rfc1034|last=Mockapetris|first=P.|date=November 1987|title=RFC 1034 - Domain names - concepts and facilities|publisher=Internet Engineering Task Force|access-date=15 July 2019}}</ref> It is possible, then, to create unresolvable loops with CNAME records, as in:
{{sxhl|2=zone|foo.example.com.  CNAME  bar.example.com.
bar.example.com.  CNAME  foo.example.com.}}
|A CNAME record cannot be present at the zone apex. RFC 1034 section 4.2.1<ref>{{cite web|url=https://tools.ietf.org/html/rfc1034#section-4.2.1|last=Mockapetris|first=P.|date=November 1987|title=RFC 1034 section 4.2.1|access-date=15 July 2019}}</ref> demands a [[SOA record]] at the zone apex and RFC 1034 section 3.6.2<ref>{{cite web|url=https://tools.ietf.org/html/rfc1034#section-3.6.2|last=Mockapetris|first=P.|date=November 1987|title=RFC 1034 section 3.6.2|access-date=15 July 2019}}</ref> demands that are no other records be present if a CNAME record is present. Therefore a CNAME record cannot appear at the zone apex. 
|{{clarify|date=November 2017|reason=needs an example and a citation; this issue may also be irrelevant for WP.|text=CNAME records that are served by DNAME records may cause recursive loops in older resolvers.}}
|[[MX record|MX]] and [[NS record]]s must never point to a CNAME alias (RFC 2181 section 10.3). So, for example, a zone must '''not''' contain constructs such as:
{{sxhl|2=zone|example.com.      MX     0   foo.example.com.
foo.example.com.  CNAME  host.example.com.
host.example.com. A      192.0.2.1}}
|Domains that are used in the [[SMTP]] MAIL and RCPT commands may not have a CNAME record.<ref name="RFC1123">{{cite web|url=https://tools.ietf.org/html/rfc1123#section-5.2.2|last=Braden|first=R.|date=October 1989|title=RFC1123 - MAIL - SMTP & RFC-822|access-date=23 July 2020}}</ref> In practice this may work, but can have different behavior with different mail servers, and can have undesired effects.<ref name="DJB_CNAME">{{cite web|url=http://cr.yp.to/im/cname.html|title=CNAME records in mail|last=Bernstein|first=D. J.|access-date=3 June 2011}}</ref>}}