web-dev-qa-db-fra.com

CNAME doit-il être utilisé pour les sous-domaines?

Je gère plusieurs sites Web qui ont actuellement la configuration DNS suivante:

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

Est-ce une utilisation appropriée des enregistrements CNAME? J'ai regardé en ligne et je n'ai pas trouvé de réponse claire. Certaines personnes affirment que les enregistrements CNAME sont mauvais (ils ne savent pas pourquoi, cependant) et proposent la configuration suivante:

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

Laquelle de celles-ci est la meilleure approche (et pourquoi)?

Remarque: Les sous-domaines ne nécessitent pas leurs propres enregistrements MX, ce n'est donc pas un problème ici.

domain-name-systemcname-record
85
Joseph Sturtevant

Oui, c'est une utilisation appropriée des CNAME. Dans les discussions auxquelles j'ai participé, les arguments ont tendance à ressembler à ceci:

Contre les CNAME:

  • Il y a une (petite) pénalité de performance, car les caches DNS en aval doivent effectuer 2 recherches DNS, une pour le CNAME et une pour l'enregistrement A vers lequel le CNAME pointe.
  • Des arguments vagues et faux au sujet des CNAME ayant moins de problèmes d'autorité ou de compatibilité.

En faveur des CNAME:

  • Ils fournissent une abstraction nette entre le matériel (serveurs physiques) et les services.
  • Ils simplifient la gestion DNS - lorsqu'un serveur se déplace, vous n'avez besoin de modifier qu'un seul enregistrement.

Après avoir essayé deux méthodes différentes pour le faire, j'ai maintenant un style préféré personnel. C'est:

  • Un enregistrement A pour chaque serveur physique; avec un assez faible TTL (peut-être 30 minutes); donner au serveur un nom convivial .
  • Un CNAME pour chaque service; avec un haut TTL (peut-être 24 heures); pointant vers les noms de serveur ci-dessus.
  • Comme seule exception aux règles ci-dessus, la racine du domaine est un enregistrement A, pointant vers le serveur Web/l'équilibreur de charge Web. (Le @ doit être un enregistrement A.)

Je trouve que cette configuration fonctionne bien. Il maintient les recherches DNS supplémentaires pour le CNAMES vers le bas; et si un serveur tombe en panne, je peux toujours changer le DNS public assez rapidement.

Voici un exemple (improvisé) dans la syntaxe BIND:

;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
87
Jesper M

Oui, c'est approprié.

Mes meilleures pratiques, que de nombreuses personnes partagent, consistent à créer un enregistrement 1 A pour chaque IP de serveur; et utiliser CNAMES pour autre chose.

Un exemple courant serait:

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
13
Chris S