91

I manage multiple websites that currently have the following DNS configuration:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - CNAME    - example.com
beta.example.com - CNAME    - test.example.com
dev.example.com  - CNAME    - test.example.com

Is this an appropriate use of CNAME records? I've looked online and have not found a clear answer. Some people claim that CNAME records are bad (they are not, however, clear on why this is) and propose the following setup:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - A Record - Production Server IP
beta.example.com - A Record - Test Server IP
dev.example.com  - A Record - Test Server IP

Which one of these is the better approach (and why)?

Note: The subdomains do not require their own MX records, so that is not an issue here.

Joseph Sturtevant
  • 1,234
  • 3
  • 15
  • 17
  • 1
    i feel like this should be a wiki answer. DNS is so hard to get right and is this accepted answer still good 6 years later? – Randy L Nov 29 '16 at 20:44
  • 1
    @the0ther Yes, even today the validated answer, from *Jesper Mortensen*, is still valid (even if one could argue about the naming of things or the correct TTL values to use, but these are separate points from the issue of using CNAME records or not). DNS is a 30 old protocol, so basic things like CNAME records do not change over time. – Patrick Mevzek Mar 04 '18 at 19:37

2 Answers2

95

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
Community
  • 1
  • 1
    Thank you, finally a reasonable opinion on CNAMEs thats laid out clearly and concisely. – Tyler Aug 12 '12 at 04:08
  • @Jesper Mortensen: could you please update a bit the answer with a small example, particularly I did not understand your 3rd point when you say "As the sole exeption to the rules above, the domain root is an A-Record," you already said in 1st point that you use one A Record for each physical layer server. (BTW the links has gone) – Marco Demaio Feb 21 '13 at 20:07
  • 3
    @Marco Demaio: About the "domain root A-Record": A second level domain like `company.com`is a zone apex. It needs a SOA record. Thus it must be an A Record and not a CNAME -- see http://serverfault.com/questions/170194/why-cant-a-domains-root-be-a-cname –  Feb 21 '13 at 21:01
  • @Jesper Mortensen: thanks now I undertsood what you meant. FYI I just opened a new question asking about alternative ways alternatives to avoid writing same IP in DNS for mutiple domains: http://serverfault.com/questions/481500/many-domains-sites-hosted-on-same-server-cname-alternatives-to-avoid-writing-sam – Marco Demaio Feb 22 '13 at 13:19
  • 4
    @ is not required to have an A record; rather, a CNAME is prohibited. – Michael Hampton May 11 '13 at 16:00
  • 1
    Just wanted to add that CNAMEs are especially useful if your server(s) support IPv6 addresses as well, as you're going to need at least two entries per server (one A and AAAA record each) so using a CNAME for sub-domains in this case is much, much simpler. If you use Jesper's recommendations for TTL (or your DNS provider has good automatic handling) then there should be no real performance penalty. – Haravikk Jan 20 '16 at 11:49
  • thank you @Haravikk! 6 years later this answer seems to be the right one. i'm about to start a pretty major, and my first, infrastructure build. getting DNS right is so tricky, i think what i learned here will help so much. but i wasn't *quite sure* that it was modern & still correct. – Randy L Nov 29 '16 at 20:46
15

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
Chris S
  • 77,337
  • 11
  • 120
  • 212
  • I know in this question they said mail is not an issue here, but let's suppose that you use also mail how would you go with MX records? Thanks! – Marco Demaio Feb 21 '13 at 19:59
  • 1
    The MX record would point to the server name as well. `IN MX server1` and for convenience I would recommend also setting up `imap` or `pop` and `smtp` CNAMEs, possibly also `mail`, as many e-mail programs guess this. Setting up the correct SRV records is also a good idea, but since this is a relatively basic question SRV records might be a bit much for a simple configuration. – Chris S Feb 21 '13 at 20:07
  • 1
    A quick comment, `MX`records must not be CNAMEs, see http://serverfault.com/a/232243/2874 It probably works fine in practice -- but still, better not to do so. –  Feb 21 '13 at 22:45
  • BIND will refuse to load the zone if you point a MX or SRV record at a CNAME... I probably should have made that clear that the MX record needs to point to the A record. Thank you. – Chris S Feb 22 '13 at 00:40
  • @ChrisS, how about editing your answer and clearly mentioning the fact that an MX record cannot point to a CNAME entry? – Alexis Wilke Aug 30 '16 at 20:55