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

Je gère plusieurs sites Web présentant 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 prétendent que les enregistrements CNAME sont mauvais (ils ne savent toutefois pas pourquoi) 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 ces approches est la meilleure (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-system cname-record

— Joseph Sturtevant
source

Je pense que cela devrait être une réponse du wiki. Le DNS est si difficile à obtenir et cette réponse acceptée est-elle toujours valable 6 ans plus tard?

— the0ther

@ the0ther Oui, même aujourd'hui, la réponse validée de Jesper Mortensen est toujours valide (même si l'on peut discuter du nom des éléments ou des valeurs de durée de vie correctes à utiliser, mais ce sont des points distincts de la question de l'utilisation ou non des enregistrements CNAME ). Le DNS étant un ancien protocole, les éléments de base tels que les enregistrements CNAME ne changent pas avec le temps.

— Patrick Mevzek

Réponses:

Oui, c'est une utilisation appropriée des CNAME. Dans les discussions auxquelles j'ai participé, les arguments ont tendance à se présenter comme suit:

Contre les CNAME:

Il y a une (petite) pénalité de performances, car les caches DNS en aval doivent effectuer 2 recherches DNS, une pour le CNAME et une pour l'enregistrement A sur lequel le CNAME pointe.
Arguments vagues et factices selon lesquels les CNAME ont moins de problèmes d'autorité ou de compatibilité.

En faveur des CNAME:

Ils fournissent une abstraction propre entre le matériel (serveurs physiques) et les services.
Ils simplifient la gestion DNS: lorsqu'un serveur est déplacé, il vous suffit de modifier un enregistrement.

Après avoir essayé différentes façons de le faire, j'ai maintenant un style préféré. Il est:

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

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

Voici un exemple (improvisé) de 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

— Jesper Mortensen
source

Merci enfin pour un avis raisonnable sur les CNAME qui sont présentés de manière claire et concise.

— Tyler

@Jesper Mortensen: pourriez-vous s'il vous plaît mettre à jour un peu la réponse avec un petit exemple, en particulier je n'ai pas compris votre troisième point lorsque vous dites: "À la seule exception des règles ci-dessus, la racine du domaine est un A-Record", vous avez déjà a déclaré au 1er point que vous utilisiez un enregistrement A pour chaque serveur de couche physique. (BTW les liens ont disparu)

— Marco Demaio

@Marco Demaio: À propos du "domaine A-Record de domaine": un domaine de second niveau comme company.comun sommet de zone. Il faut un enregistrement SOA. Il doit donc s'agir d'un enregistrement A et non d'un CNAME - voir serverfault.com/questions/170194/…

— Jesper Mortensen le

@ n'est pas obligé d'avoir un enregistrement A; au contraire, un CNAME est interdit.

— Michael Hampton

Je voulais juste ajouter que les CNAME sont particulièrement utiles si votre serveur (s) prend également en charge les adresses IPv6, car vous aurez besoin d'au moins deux entrées par serveur (un enregistrement A et AAAA chacune), utilisez donc un CNAME pour les sous-domaines. dans ce cas, c'est beaucoup, beaucoup plus simple. Si vous utilisez les recommandations de Jesper pour la durée de vie (ou si votre fournisseur DNS a une bonne gestion automatique), il ne devrait pas y avoir de réelle perte de performances.

— Haravikk

Oui c'est approprié.

Mes meilleures pratiques, que beaucoup de gens partagent, sont de créer 1 enregistrement A pour chaque adresse IP de serveur; et utilisez 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

— Chris S
source

Je sais que dans cette question, le courrier n'est pas un problème ici, mais supposons que vous utilisiez aussi le courrier. Comment utiliseriez-vous les enregistrements MX? Merci!

— Marco Demaio

L'enregistrement MX indiquerait également le nom du serveur. IN MX server1et pour plus de commodité, je recommanderais également de configurer imapou popet les smtpCNAME, probablement aussi mail, car de nombreux programmes de messagerie électronique le supposent . Configurer les enregistrements SRV corrects est également une bonne idée, mais comme il s’agit d’une question relativement élémentaire, les enregistrements SRV pourraient être un peu trop difficiles pour une configuration simple.

— Chris S

Un commentaire rapide, les MXenregistrements ne doivent pas être des CNAME, voir serverfault.com/a/232243/2874 Cela fonctionne probablement bien dans la pratique, mais il vaut mieux ne pas le faire.

— Jesper Mortensen

BIND refusera de charger la zone si vous pointez un enregistrement MX ou SRV vers un CNAME ... J'aurais probablement dû préciser que l'enregistrement MX doit pointer sur l'enregistrement A. Je vous remercie.

— Chris S

@ChrisS, que diriez-vous de modifier votre réponse en mentionnant clairement le fait qu'un enregistrement MX ne peut pas pointer vers une entrée CNAME?

— Alexis Wilke