I manage multiple websites that currently have le suivant 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 approprié use of CNAME records? J'ai looked online et have pas found a clear answer. Some people claim that CNAME records are bad (they are not, cependant, clear on why this is) et propose le suivant 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 le better approach (and why)?
**Note :** The subdomains do pas require leur own MX records, so that is pas an issue here.
Faut-il utiliser des CNAME pour les sous-domaines ?
Re: Faut-il utiliser des CNAME pour les sous-domaines ?
Yes, c'est an approprié use of CNAMEs. In le discussions J'ai been part of, le arguments tend to go like this:
**Against CNAMEs:**
- Il y a a (tiny) performance penalty, as le downstream DNS caches need to perform 2 DNS lookups, one for le CNAME et one for le A-Record le CNAME points to.
- Vague, bogus arguments about CNAMEs having less "authority" ou compatibility issues.
**In favor of CNAMEs:**
- They provide a clean abstraction entre hardware (physical servers) et services.
- They simplify DNS management -- quand a server moves, you seulement need to change one record.
**After trying a couple of différent ways** to do this, I now have a personal favorite style. It is:
- One A Record for chaque physical server; avec a fairly low TTL (perhaps 30 minutes); giving le server a [human-friendly name](http://web.archive.org/web/20110809095548/https://serverfault.com/questions/45734/the-coolest-server-names).
- One CNAME for chaque service; avec a high TTL (perhaps 24 hours); pointing to le ci-dessus server names.
- As le sole exeption to le rules above, le domain root is an A-Record, pointing to le webserver / web load balancer. (The @ is requis to be an A-record.)
I find that this setup works well. It keeps extra DNS lookups for le CNAMES down; et si a server crashes I can encore change public DNS around fairly fast.
**Voici 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
```
**Against CNAMEs:**
- Il y a a (tiny) performance penalty, as le downstream DNS caches need to perform 2 DNS lookups, one for le CNAME et one for le A-Record le CNAME points to.
- Vague, bogus arguments about CNAMEs having less "authority" ou compatibility issues.
**In favor of CNAMEs:**
- They provide a clean abstraction entre hardware (physical servers) et services.
- They simplify DNS management -- quand a server moves, you seulement need to change one record.
**After trying a couple of différent ways** to do this, I now have a personal favorite style. It is:
- One A Record for chaque physical server; avec a fairly low TTL (perhaps 30 minutes); giving le server a [human-friendly name](http://web.archive.org/web/20110809095548/https://serverfault.com/questions/45734/the-coolest-server-names).
- One CNAME for chaque service; avec a high TTL (perhaps 24 hours); pointing to le ci-dessus server names.
- As le sole exeption to le rules above, le domain root is an A-Record, pointing to le webserver / web load balancer. (The @ is requis to be an A-record.)
I find that this setup works well. It keeps extra DNS lookups for le CNAMES down; et si a server crashes I can encore change public DNS around fairly fast.
**Voici 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
```