Should CNAME Be Used For Subdomains?

Solution 1:

Yes, that's an appropriate use of CNAMEs. In the discussions I've been part of, the arguments tend to go like this:

Against CNAMEs:

• There is a (tiny) performance penalty, as the downstream DNS caches need to perform 2 DNS lookups, one for the CNAME and one for the A-Record the CNAME points to.
• Vague, bogus arguments about CNAMEs having less "authority" or compatibility issues.

In favor of CNAMEs:

• They provide a clean abstraction between hardware (physical servers) and services.
• They simplify DNS management -- when a server moves, you only need to change one record.

After trying a couple of different ways to do this, I now have a personal favorite style. It is:

• One A Record for each physical server; with a fairly low TTL (perhaps 30 minutes); giving the server a human-friendly name.
• One CNAME for each service; with a high TTL (perhaps 24 hours); pointing to the above server names.
• As the sole exeption to the rules above, the domain root is an A-Record, pointing to the webserver / web load balancer. (The @ is required to be an A-record.)

I find that this setup works well. It keeps extra DNS lookups for the CNAMES down; and if a server crashes I can still change public DNS around fairly fast.

Here's a (improvised) example in BIND syntax:

;name     ttl   class rr     value 
server01  30m   IN    A      192.168.0.3
server02  30m   IN    A      192.168.0.4

webmail   24h   IN    CNAME  server01
extranet  24h   IN    CNAME  server02
ftp       24h   IN    CNAME  server02

Solution 2:

Yes it's appropriate.

My Best Practices, which many people share, are to create 1 A record for each server IP; and use CNAMES for anything else.

A common example would be:

server1.example.com.      IN A      192.168.0.1
server2.example.com.      IN A      192.168.5.2
www                       IN CNAME  server1
ftp                       IN CNAME  server1
beta                      IN CNAME  server2