Récords DNS pour les développeurs — A, CNAME, MX, TXT et le TTL qui vous ont fait attendre 48 heures

Vous avez acheté un domaine, l'avez pointé vers une destination, et vous regardez maintenant un navigateur qui affiche encore le site ancien. Ou vous avez mal configuré vos enregistrements MX et vous avez découvert que les courriels commencent à rebondir. Le DNS est l'un de ces éléments que les développeurs ignorent la plupart du temps jusqu'à ce qu'il les pique — et quand il le fait, le cycle de retour est lent et douloureux.

Ce n'est pas un tutoriel pour les personnes qui n'ont jamais entendu parler du DNS. C'est une référence pour les développeurs qui connaissent ce qu'est un domaine, mais qui se tournent vers Stack Overflow chaque fois qu'ils ont besoin d'ajouter un type d'enregistrement qu'ils n'ont pas touché depuis six mois.

Comment fonctionne réellement le DNS (version de 30 secondes)

Lorsqu'un navigateur résout example.com, il demande à un résolveur récursif (généralement votre fournisseur d'Internet ou 8.8.8.8). Le résolveur vérifie son cache. Si une correspondance est trouvée, il retourne la réponse enregistrée. Si non, il parcourt l'arbre DNS — serveurs racine → serveurs de domaine TLD (.com) → le serveur autoritaire de votre domaine — et enregistre le résultat pendant la durée indiquée par le TTL.

Chaque enregistrement DNS a un type, un nom, une valeur et un TTL. C'est tout. La complexité vient de savoir quel type fait quoi et où les enregistrements interagissent de manière non évidente.

Les types d'enregistrements que vous utiliserez effectivement

Enregistrement A — adresse IP pour un nom d'hôte

Associe un nom d'hôte à une adresse IPv4. C'est le type d'enregistrement le plus fréquemment utilisé.

example.com.     300   IN  A   93.184.216.34
www.example.com. 300   IN  A   93.184.216.34

Le piège : vous pouvez avoir plusieurs enregistrements A pour le même nom d'hôte. Le DNS retourne tous les enregistrements, et le client choisit un d'entre eux (généralement en rotation). C'est une configuration simple de charge équilibrée — mais si l'un de ces IPs tombe en panne, le DNS n'a pas de vérifications de santé. Il continuera à servir l'IP défaillante jusqu'à l'expiration du TTL, puis vous devrez le supprimer manuellement.

Pour l'IPv6, l'équivalent est un enregistrement AAAA. Même concept, adresse de 128 bits au lieu de 32 bits.

Enregistrement CNAME — alias vers un autre nom d'hôte

Pointe un nom d'hôte vers un autre nom d'hôte (pas une adresse IP). Le résolveur suit la chaîne jusqu'à ce qu'il atteigne un enregistrement A.

www.example.com.    300  IN  CNAME  example.com.
blog.example.com.   300  IN  CNAME  mysite.netlify.app.

CNAME vs A — quand utiliser lequel : Si vous pointez vers un service qui vous donne un nom d'hôte (Netlify, Vercel, GitHub Pages, Heroku, la plupart des CDNs), utilisez un CNAME. Si vous avez une adresse IP statique, utilisez un enregistrement A. C'est simple.

Règle difficile : vous ne pouvez pas mettre un CNAME sur l'apex de votre zone (le domaine pur — example.com, et non pas www.example.com). L'RFC 1034 l'interdit car l'apex doit contenir des enregistrements SOA et NS, et un CNAME au même nom créerait un conflit. Quand Netlify ou Vercel vous disent d'ajouter un CNAME pour votre domaine racine, ce qu'ils veulent vraiment dire, c'est d'utiliser leur fournisseur de DNS qui supporte des enregistrements ANAME ou ALIAS — une extension propriétaire qui se comporte comme un CNAME mais qui résout directement vers des enregistrements A au niveau de la zone.

Également : ne jamais pointer un CNAME vers un CNAME si vous pouvez le éviter. Techniquement légal, mais chaque étape dans la chaîne représente une requête DNS supplémentaire. Plus important, si le CNAME intermédiaire tombe en panne, votre enregistrement tombe aussi.

Enregistrement MX — routage des courriels

Indique aux serveurs de courriels où livrer les courriels pour votre domaine. Les enregistrements MX ont un numéro de priorité — un numéro plus bas = priorité plus élevée.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

Si mail1 est indisponible, les serveurs d'envoi essayeront mail2. C'est un retour de secours correct, pas un équilibrage de charge — vous ne divisez pas le trafic, vous spécifiez un ordre de préférence.

L'erreur que les développeurs commettent : pointer un MX vers une adresse IP ou un CNAME. Les valeurs MX doivent pointer vers des enregistrements A (noms d'hôte), pas vers des adresses IP ou des CNAMEs. Certains fournisseurs de DNS vous permettent d'enregistrer cette configuration incorrecte sans avertissement, et alors vos courriels échouent silencieusement.

Si vous configurez Google Workspace ou Microsoft 365, ils vous fourniront un ensemble d'enregistrements MX. N'ajustez pas les numéros de priorité en pensant être intelligent — le logiciel de routage des courriels dépend de leur exactitude.

Enregistrement TXT — texte arbitraire, principalement pour la vérification et l'authentification des courriels

Les enregistrements TXT contiennent des chaînes de texte libres. En pratique, ils sont utilisés pour trois choses :

• Vérification du domaine — Google Search Console, Stripe, GitHub et une centaine d'autres services vous demanderont d'ajouter un enregistrement TXT pour prouver que vous possédez le domaine
• SPF (Framework de politique d'expéditeur) DKIM et DMARC
• DKIM et DMARC — des enregistrements d'authentification des courriels qui empêchent le spoofing

Un enregistrement SPF ressemble à cela :

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Cela signifie : Google et SendGrid sont autorisés à envoyer des courriels pour ce domaine ; tout autre serveur doit être traité avec suspicion (~all = échec doux, -all = échec dur).

Un enregistrement DMARC se trouve à _dmarc.example.com:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

L'élément important : vous ne pouvez avoir qu'un seul enregistrement TXT SPF par domaine. Si vous ajoutez un deuxième (parce qu'un nouveau service vous l'a demandé), les deux enregistrements existent, les serveurs de courriels voient des politiques contradictoires, et l'authentification des courriels s'arrête. Fusionnez-les au lieu de les ajouter : v=spf1 include:_spf.google.com include:sendgrid.net ~all.

Enregistrement NS — délégation des serveurs de noms

Spécifie les serveurs de noms autorisés pour votre domaine. Vous les définissez généralement chez votre fournisseur de domaine, pas directement dans votre zone DNS. Lorsque vous migrez d'un fournisseur de DNS à un autre (par exemple, de la zone de GoDaddy à Cloudflare), vous modifiez les enregistrements NS au niveau du fournisseur de domaine.

La propagation des enregistrements NS est la raison pour laquelle les migrations de domaine sont lentes. Les TTL des enregistrements NS sont souvent de 24 à 48 heures, et les modifications au niveau du fournisseur de domaine ont elles-mêmes un délai de propagation supplémentaire.

TTL — le nombre qui vous a fait attendre 48 heures

Le TTL (Time To Live) est un nombre en secondes. Il indique à des résolveurs en cache combien de temps conserver une réponse avant de la réexaminer. Un TTL de 300 signifie cinq minutes. Un TTL de 172800 signifie 48 heures.

Lorsque vous modifiez un enregistrement DNS, la réponse ancienne est encore en cache partout pendant jusqu'à le TTL ancien. Si votre enregistrement A avait un TTL de 48 heures et que vous venez de changer l'IP, certains utilisateurs vont rencontrer le serveur ancien pendant jusqu'à deux jours — et rien ne peut être fait pour arrêter cela une fois que la modification a été effectuée.

La solution est de baisser le TTL avant de faire la modification. Procédure standard pour les migrations planifiées :

1. Baisser le TTL à 300 (5 minutes) au moins 48 heures avant la migration — vous devez attendre que le TTL ancien expire d'abord
2. Faire la modification DNS
3. Attendre 5 à 10 minutes pour la propagation
4. Rajuster le TTL à une valeur raisonnable (3600 à 86400) une fois que vous avez confirmé que la nouvelle configuration fonctionne

Si vous oubliez l'étape 1 et passez directement à l'étape 2 avec un TTL élevé, vous êtes coincé. Vous pouvez baisser le TTL maintenant, mais cela ne réduit que l'attente pour les résolveurs qui n'ont pas encore enregistré la mise à jour. Tout ce qui a déjà enregistré l'enregistrement doit attendre l'expiration du TTL initial.

Référence rapide

Enregistrement	Pointe vers	Utilisation courante	Piège
UN	Adresse IPv4	Nom d'hôte → adresse serveur	Pas de vérification de santé — les adresses défaillantes restent dans le rotation jusqu'à l'expiration du TTL
AAAA	Adresse IPv6	Nom d'hôte → serveur IPv6	Facile de oublier d'ajouter un enregistrement A pour le support dual-stack
CNAME	Un autre nom d'hôte	Aliases, routage CDN/PaaS	Impossible d'utiliser au niveau de l'apex de la zone ; les MX/NS ne peuvent pas pointer vers un CNAME
MX	Nom d'hôte (enregistrement A)	Routage de livraison des courriels	La valeur doit être un nom d'hôte, pas une adresse IP ; les numéros de priorité sont importants
TXT	Texte libre	SPF, DKIM, DMARC, vérification du domaine	Un seul enregistrement SPF autorisé par domaine — fusionnez, ne rajoutez pas
NS	Nom d'hôte du serveur de noms	Délégation DNS	Les modifications passent par le fournisseur de domaine et se propagent lentement
CAA	Domaine CA	Les CA autorisées à émettre des certificats SSL pour votre domaine	Facile de se bloquer de renouveler les certificats par mauvaise configuration

Les choses qui vous épargneront du temps

Utilisez dig directement, pas un outil web. dig @8.8.8.8 example.com A contourne votre résolveur local et montre exactement ce que voit Google DNS. Ajoutez +short pour seulement la réponse. Ajoutez +trace pour parcourir la chaîne complète de résolution.

# Check what Google sees right now
dig @8.8.8.8 example.com A +short

# Check MX records
dig @8.8.8.8 example.com MX

# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT

# Full resolution trace
dig @8.8.8.8 example.com A +trace

Vérifiez le TTL avant toute migration. Exécutez dig example.com A et regardez le nombre dans la troisième colonne de la section réponse. C'est combien de secondes vous pourriez attendre si vous modifiez l'enregistrement maintenant sans avoir baissé le TTL d'abord.

Les enregistrements proxy de Cloudflare ne montrent pas votre IP réelle. Lorsque vous activez le nuage orange de Cloudflare sur un enregistrement, l'adresse A exposée au monde est celle de Cloudflare, pas la vôtre. C'est généralement ce que vous voulez pour la protection contre les DDoS — mais cela signifie que dig ne montre pas l'IP réelle de votre serveur, et les outils qui sondent directement votre IP ne fonctionnent pas comme prévu.

Vous aimerez peut-être aussi