83

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.

  • 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? – the0ther 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 4 '18 at 19:37
83

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
  • 1
    Thank you, finally a reasonable opinion on CNAMEs thats laid out clearly and concisely. – Tyler Aug 12 '12 at 4: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
  • 2
    @Marco Demaio: About the "domain root A-Record": A second level domain like company.comis a zone apex. It needs a SOA record. Thus it must be an A Record and not a CNAME -- see serverfault.com/questions/170194/… – Jesper Mortensen Feb 21 '13 at 21:01
  • 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
12

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
  • 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, MXrecords must not be CNAMEs, see serverfault.com/a/232243/2874 It probably works fine in practice -- but still, better not to do so. – Jesper Mortensen 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 0: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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.