Faut-il utiliser le CNAME pour les sous-domaines ?

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

Contre les CNAME :

• Il y a une (petite) pénalité de performance, car les caches DNS en aval doivent effectuer deux recherches DNS, une pour le CNAME et une pour l'enregistrement A vers lequel le CNAME pointe.
• Des arguments vagues et bidons sur le fait que les CNAME ont moins d'"autorité" ou des problèmes de compatibilité.

En faveur des CNAMEs :

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

Après avoir essayé plusieurs façons différentes pour faire cela, j'ai maintenant un style personnel préféré. Il s'agit de :

• Un enregistrement A pour chaque serveur physique, avec un TTL assez bas (peut-être 30 minutes), ce qui donne au serveur un nom d'utilisateur et un mot de passe. nom convivial .
• Un CNAME pour chaque service, avec un TTL élevé (peut-être 24 heures), pointant vers les noms des serveurs ci-dessus.
• 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. Elle permet de limiter les consultations DNS supplémentaires pour les CNAMES et, si un serveur tombe en panne, je peux toujours modifier les DNS publics 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