Comprendre les enregistrements DNS : essentiels et pièges

La majorité des pannes attribuées à un « serveur hors ligne » relèvent en réalité du DNS. Le serveur fonctionne, le site est intact, mais un enregistrement texte pointe vers la mauvaise adresse — ou un ancien enregistrement persiste dans les caches DNS.

Le DNS est également la couche la moins surveillée d'un site web. Personne ne s'y intéresse tant que tout fonctionne, et lorsqu'un incident survient, la modification incriminée remonte souvent à plusieurs semaines.

Voici le rôle exact de chaque type d'enregistrement et les erreurs de configuration les plus courantes.

A et AAAA — la localisation du site

L'enregistrement A associe un nom d'hôte à une adresse IPv4. L'enregistrement AAAA l'associe à une adresse IPv6.

example.com.      A      203.0.113.10
example.com.      AAAA   2001:db8::1
www.example.com.  A      203.0.113.10

Si ces entrées sont erronées ou absentes, le reste de la configuration est inopérant.

L'erreur classique : publier un enregistrement A pour example.com mais oublier www.example.com (ou inversement). Une moitié des utilisateurs tapera l'autre variante et fera face à une page inaccessible. Vous ne le remarquerez pas si vous utilisez toujours le même format d'URL.

Concernant l'IPv6 : sur plusieurs marchés, une part majeure du trafic mobile transite exclusivement en IPv6 et ne rejoint les sites IPv4 qu'au prix d'une passerelle de conversion (NAT64), ajoutant de la latence à chaque connexion. Si votre hébergeur gère l'IPv6, renseigner les enregistrements AAAA est gratuit et supprime cette étape intermédiaire.

MX — la réception des e-mails

example.com.  MX  10 mx1.provider.com.
example.com.  MX  20 mx2.provider.com.

Ces enregistrements listent les serveurs de messagerie qui réceptionnent les e-mails de votre domaine. Le numéro de priorité le plus bas est prioritaire ; les numéros supérieurs servent de serveurs de secours (fallback).

Deux confusions fréquentes :

Le MX contrôle exclusivement la réception des e-mails. Si vos messages sortants finissent dans les courriers indésirables, le MX n'est pas en cause : ce sont les protocoles SPF, DKIM et DMARC qu'il faut auditer, et ceux-ci sont déclarés dans des enregistrements TXT.

Un enregistrement MX doit impérativement pointer vers un nom d'hôte (FQDN), jamais vers une adresse IP. Une entrée MX 10 203.0.113.5 est invalide et de nombreux serveurs SMTP refuseront de distribuer les e-mails destinés à un tel domaine.

NS — les serveurs faisant autorité

example.com.  NS  ns1.provider.com.
example.com.  NS  ns2.provider.com.

Ce sont les serveurs de noms faisant autorité pour votre zone. Ils doivent obligatoirement concorder avec la délégation configurée chez votre bureau d'enregistrement (registrar) — les enregistrements NS au sein de la zone et la délégation chez le registrar sont deux éléments distincts pouvant être désynchronisés.

Le piège lors d'une migration : vous changez d'hébergeur, mettez à jour votre zone DNS chez le nouveau prestataire, et le site fonctionne chez vous mais pas chez vos clients. La raison : la délégation chez le registrar pointe toujours vers les anciens serveurs NS. Une partie du web interroge donc toujours l'ancienne infrastructure.

Définissez systématiquement au moins deux serveurs NS. Un serveur unique constitue un point de défaillance critique pour l'ensemble de vos services, y compris la messagerie.

TXT — le couteau suisse

Enregistrements de texte libre, aujourd'hui indispensables pour de multiples usages :

• SPF — liste les serveurs autorisés à émettre des e-mails en votre nom : v=spf1 include:_spf.google.com ~all
• DMARC — définit la politique de traitement des e-mails non authentifiés, sur _dmarc.example.com
• DKIM — publie la clé publique de signature cryptographique, sur selector._domainkey.example.com
• Vérification de domaine — pour Google Search Console, Microsoft 365, Atlassian et d'autres plateformes SaaS

Deux règles critiques :

Un seul enregistrement SPF par domaine. Déclarer deux entrées TXT commençant par v=spf1 génère une erreur permanente et invalide les deux règles. Cela survient souvent lors de l'intégration d'un nouvel outil d'e-mailing créant son propre enregistrement au lieu de modifier l'existant. Fusionnez-les impérativement.

L'accumulation des entrées TXT. La plupart des domaines accumulent des enregistrements de validation d'outils abandonnés depuis des années. Bien qu'inoffensifs, ils surchargent la zone DNS et masquent les erreurs comme les doublons SPF. Effectuez un audit annuel.

CAA — l'autorisation des autorités de certification

Le type d'enregistrement le plus sous-estimé et pourtant indispensable pour la sécurité.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef "mailto:security@example.com"

Le CAA (Certification Authority Authorization) déclare quelles autorités sont autorisées à délivrer des certificats SSL/TLS pour votre domaine. Sans lui, n'importe quelle autorité publique peut émettre un certificat. Avec lui, seules celles que vous désignez y sont habilitées.

Les autorités de certification ont l'obligation légale de vérifier cet enregistrement avant émission. C'est une protection majeure contre l'usurpation de certificats, configurable en deux minutes.

Deux points de vigilance : déclarez toutes les autorités réellement utilisées — y compris celles déléguées à votre CDN ou hébergeur — et utilisez issuewild ";" pour interdire les certificats wildcard si vous ne les utilisez pas.

SOA — les métadonnées de zone

Un seul par zone, géré automatiquement la plupart du temps. La donnée essentielle à connaître est le numéro de série (serial number) : il s'incrémente à chaque modification de la zone. Lors d'une migration, si le numéro de série n'a pas changé, vos modifications n'ont pas été publiées. Cette vérification rapide évite bien des confusions.

TTL : la clé d'une migration sans interruption

Chaque enregistrement possède une durée de vie TTL (Time To Live) — le nombre de secondes pendant lesquelles les résolveurs DNS peuvent conserver l'information en cache.

Un enregistrement avec un TTL de 24 heures peut nécessiter une journée entière pour se propager à l'échelle mondiale. Il est impossible d'accélérer ce délai a posteriori. Une fois la réponse mise en cache, elle sera servie jusqu'à expiration du TTL.

La méthode pour une bascule immédiate :

1. 48 heures avant la migration, réduisez le TTL des enregistrements cibles à 300 secondes (5 minutes).
2. Attendez l'expiration de l'ancien TTL pour que tous les résolveurs adoptent la nouvelle durée courte.
3. Effectuez le changement d'IP ou de serveur. La propagation prend désormais 5 minutes maximum.
4. Le lendemain, remontez le TTL à 3600 secondes ou plus.

L'étape 4 est essentielle : un TTL trop court en continu multiplie les requêtes DNS et ralentit légèrement le premier temps de connexion des utilisateurs.

Pourquoi les outils affichent des résultats divergents

Parce qu'ils interrogent des résolveurs DNS différents, disposant de caches rafraîchis à des moments distincts.

Immédiatement après une modification, cette divergence est normale et se résorbe à l'expiration des TTL. Si elle persiste au-delà du TTL, deux jeux de serveurs de noms sont probablement actifs simultanément suite à une migration incomplète.

Vous pouvez inspecter l'ensemble des enregistrements et leurs TTL grâce à notre outil d'analyse DNS gratuit. Il interroge directement les serveurs depuis votre navigateur pour afficher l'état réel de résolution.

Checklist d'une migration DNS réussie

1. Exporter l'intégralité de la zone DNS existante avant toute manipulation.
2. Réduire les TTL à 300 s, 48 heures à l'avance.
3. Configurer l'ensemble de la zone chez le nouvel hébergeur avant de modifier la délégation.
4. Mettre à jour les serveurs de noms (NS) chez le registrar.
5. Vérifier la bonne résolution des enregistrements A, AAAA, MX, TXT et CAA chez le nouveau prestataire.
6. Tester l'envoi et la réception d'e-mails.
7. Conserver l'ancienne zone DNS active pendant une semaine pour répondre aux résolveurs ayant un cache persistant.
8. Remonter les TTL aux valeurs standards une fois le trafic stabilisé.

L'étape 7 est fréquemment oubliée, expliquant pourquoi une migration semble réussir le premier jour avant de provoquer des rejets d'e-mails le troisième.