10. Naming issues

This section deals with the issue of what is a valid DNS name, and what is an authoritative or canonical name.

10.1. CNAME resource records

A CNAME RR identifies the canonical name of an alias. The RR owner name is the alias, and the RR RDATA is the canonical name. A CNAME RR must not have any other RRs with the same name (with the exception of SIG, NXT, and KEY RRs, which are used for DNSSEC).

If a CNAME RR is present at a node, no other data must be present at that node. That is, a node with a CNAME RR must not have any other RRs, except for the DNSSEC RRs mentioned above. This is a change from RFC1034, which allowed other RRs at a node with a CNAME RR.

A CNAME RR must not point to itself, directly or indirectly. That is, a CNAME RR must not have an RDATA field that is the same as its owner name, and a CNAME RR must not point to a name that is the target of another CNAME RR that points to it.

10.2. PTR records

PTR records are used to map from an IP address to a name. The owner name of a PTR record is the IP address, in reverse order, with the suffix ".in-addr.arpa" for IPv4, or ".ip6.arpa" for IPv6. The RDATA of a PTR record is the name that is associated with the IP address.

PTR records must not be present at the apex of a zone. That is, a PTR record must not have an owner name that is the same as the zone apex.

PTR records must point to a valid hostname. That is, the RDATA of a PTR record must be a name that is a valid hostname (i.e. it must not be a CNAME or other alias).

10.3. MX and NS records

MX and NS records must not point to an alias. That is, the RDATA of an MX or NS record must be the canonical name of the target host, not a CNAME or other alias. This is a change from RFC1034, which allowed MX and NS records to point to aliases.

If a server receives an MX or NS record that points to an alias, it must follow the alias to find the canonical name, and use that as the target of the MX or NS record. However, the server must not cache the alias, only the canonical name.