CNAME RRs incur performance overheads. The most common DNS query is for an A RR, or an AAAA RR if IPv6 - the end system needs an address which is only defined with these RR types. In the above example if a query for the address of www.example.com is received, two look-up operations are performed on the master or slave server. The first finds www.example.com which finds a CNAME RR. This is followed by a query for server1.example.com to obtain the IP, that is, the CNAME chain is followed to attempt to resolve the request for an IP address. On low volume DNS servers the additional resources used are not significant but on high volume servers the additional load can become non-trivial. The user must make a choice to balance what many see as the convenience of using CNAME RRs against the possible performances degradation involved.

CNAME RRs cannot have any other RRs with the same name, for example, a TXT - well that was true until DNSSEC came along and in this case RRSIG, NSEC and certain KEY RRs can now occupy the same name.

While use of CNAME RRs with NS and MX records is widely implemented and generates a working configuration it is theoretically not permitted (RFC 1034 section 3.6.2) since it can result in lost names. The fragment below illustrates a widely used but technically invalid configuration.

In the above configuration when a query is issued for the A RR of mail.example.com the result will return both the mail.example.com CNAME RR and the server1.example.com A RR. When the A RR is used the name associated with the CNAME can be lost, that is, there is a valid MX record referencing the host mail.example.com and an A RR referencing server1.example.com but nothing joins the two records. The fragment below, by re-ordering the RRs, will achieve the same result and allow a valid mapping of the MX name to the A RR name.

For many users the above feels uncomfortable because the real host name is server1.example.com not mail.example.com. Bear in mind that the DNS system simply maps a name used externally to an IP address - irrespective of the host's name in its local configuration file or whatever it answers to a hostname command.

You can map CNAME records to another CNAME record but this is considered bad practice since queries will follow the CNAME chain and look for the A record which uses more DNS resources. CNAME loops can also inadvertently result from such a procedure.

You can redefine a single IP to have multiple names using standard A records which is functionally the same as a CNAME for entries within a zone.

Examples & Variations

; zone file fragment for example.com
joe IN A 192.168.254.3
www IN CNAME joe ;canonical name is joe.example.com.
www IN CNAME joe.example.com. ; exactly the same as above
ftp IN CNAME www.example.com. ; bad practice
; better practice to achieve same result as ftp CNAME above
; by re-defining the same physical host with 2 A records
ftp IN A 192.168.254.3
; next line redirects bill.example.com to fred.another.com
bill IN CNAME fred.another.com.
; this is theoretically invalid - but widely implemented
IN MX 10 mail.example.com.
...
mail IN CNAME joe.example.com.
; classic www.example.com and example.com access
; resolves example.com to an IP
IN A 192.168.254.8
www IN CNAME example.com.
; could also be defined as
IN A 192.168.254.8
www IN A 192.168.254.8

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.