Guide
CNAME, MX et TXT : les cas qui cassent
Ces trois types sont simples chacun seul. Ils cassent quand on les empile sur le même nom, ou quand le texte dit le contraire de l’adresse.
Le CNAME occupe tout le nom
Un CNAME veut dire : « ce nom est un alias, va voir l’autre ». La règle qui en découle est stricte. S’il y a un CNAME, il ne doit pas y avoir d’autre enregistrement sur ce même nom, à l’exception de signatures DNSSEC. Pas de A à côté, pas de MX, pas de TXT, pas de NS. Le 23 octobre 2026, www.wikipedia.org ne publiait qu’un CNAME vers dyna.wikimedia.org. Les adresses sont sur la cible, pas sur le nom alias. www.iana.org suivait le même modèle vers www.iana.org.cdn.cloudflare.net, dont les A étaient 104.18.24.232 et 104.18.25.232.
Poser un CNAME sur le sommet de la zone (exemple.fr nu, sans www) entre en collision avec le SOA et les NS, qui doivent vivre à ce nom. Beaucoup de plateformes veulent pourtant un CNAME au sommet pour pointer vers leur CDN. Le DNS classique ne le permet pas. Les contournements (ALIAS, ANAME, CNAME flattening) sont des fonctions de l’hébergeur DNS : il publie des A qu’il recalcule, tout en vous montrant un alias dans l’interface. Ce n’est pas un type standard. Si vous migrez la zone vers un serveur qui n’a pas cette fonction, l’alias du sommet disparaît ou devient un CNAME illégal que certains résolveurs rejettent.
Une chaîne de CNAME doit rester courte et se terminer. Un alias vers un alias vers un nom sans adresse donne un site injoignable avec un statut NOERROR : le DNS a répondu, mais il n’y a pas d’adresse utilisable. Une boucle (A alias de B, B alias de A) se termine par un échec après la limite du résolveur. On teste le nom exact demandé par le navigateur, pas seulement le sommet.
MX : la cible, la préférence, le nul
La cible d’un MX est un nom d’hôte qui doit avoir un A ou un AAAA. Elle ne doit pas être un CNAME. Cette contrainte évite des chaînes supplémentaires au moment où un serveur de messagerie décide où livrer. Si l’interface vous propose « pointez le MX vers le www », et que www est un CNAME vers un hébergeur, la configuration est fragile même si un test rapide semble marcher. On crée un nom dédié, par exemple mail.exemple.fr, avec un A, et le MX pointe vers ce nom.
La préférence est un entier. Le plus petit nombre est essayé en premier. Deux MX de préférence 10, comme ceux de wikipedia.org le 23 octobre 2026 (mx-in1001.wikimedia.org et mx-in2001.wikimedia.org), se partagent le courrier. Un MX de préférence 20 ne sert que si les précédents sont injoignables. Un unique MX vers une seule adresse est un point de panne : ce n’est pas une erreur DNS, c’est un choix d’exploitation.
Le MX nul est un cas à part, souvent mal lu. example.com publiait, le 23 octobre 2026, 0 . : priorité 0, cible la racine. Cette forme (RFC 7505) veut dire que le domaine ne reçoit pas de courrier. Ce n’est pas « un MX vide à corriger ». Le TXT v=spf1 -all du même domaine va dans le même sens pour l’émission. Remplacer ce MX par l’adresse d’un webmail sans retirer le SPF -all fait accepter la livraison entrante tout en faisant rejeter les réponses. On change les deux, ou on ne change rien.
TXT : plusieurs textes, plusieurs contrats
Le type TXT n’a pas de format unique. SPF commence par v=spf1. DMARC se publie sur _dmarc et commence par v=DMARC1. DKIM se publie sur un nom du genre selecteur._domainkey. Les preuves de propriété sont des chaînes demandées par un service. Le 23 octobre 2026, wikipedia.org cumulait un SPF (v=spf1 include:_cidrs.wikimedia.org ~all), une vérification Google et une vérification Yandex. example.com cumulait v=spf1 -all et une chaîne de vérification. Effacer un TXT parce qu’on ne le « reconnaît » pas retire un contrat encore en cours.
SPF se lit de gauche à droite et se termine par un qualificatif. -all rejette le reste. ~all marque le reste comme douteux. +all autorise tout le monde et annule l’intérêt de l’enregistrement. Il ne doit y avoir qu’un seul SPF par nom. Deux TXT qui commencent tous deux par v=spf1 rendent le résultat imprévisible. On fusionne les mécanismes dans un seul texte, on ne les empile pas.
La longueur compte. Un TXT très long est découpé en segments. Une interface qui tronque sans prévenir casse la signature DKIM ou le SPF au milieu d’un mot. Après chaque modification, on relit la valeur exacte renvoyée par un résolveur, guillemets compris, pas seulement le message « enregistré » de l’interface. L’outil en type TXT sert à cette relecture sur plusieurs résolveurs.
Combinaisons qui se présentent comme un site « en panne »
Le site ne s’affiche plus après une « simple » redirection vers un hébergeur : un CNAME a été posé sur un nom qui avait encore un TXT ou un A, et la zone a été refusée par le serveur autoritatif, ou le CNAME a remplacé le A sans que la cible réponde. On redemande le type A et le type CNAME du nom exact.
Le courrier part dans le vide après un changement de site : les A du www ont été mis à jour, les MX pointaient vers l’ancienne machine, ou les MX pointaient vers un nom dont le A a été supprimé avec « les anciennes adresses ». On redemande le MX, puis le A de la cible, puis le TXT du sommet. Trois questions, pas une.
Le certificat ne se renouvelle plus alors que le site marche : un CAA trop étroit, ou un CNAME qui fait hériter le nom d’une politique CAA inattendue. Le CAA se teste à part. Le guide anatomie d’une zone rappelle la forme des lignes, et le diagnostic distingue un nom absent d’un type absent. Le lexique reprend CNAME, MX, TXT et CAA au format court.