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