Quelque chose cloche. Le site ne charge pas, les mails reviennent, ou tu as modifié un enregistrement il y a une heure et rien ne bouge. Neuf fois sur dix, la réponse est dans le DNS — il faut juste savoir où regarder.
Le DNS, c'est le carnet d'adresses d'internet : il transforme example.com en une IP à laquelle ton navigateur peut vraiment se connecter. Quand il déraille, tout ce qui vient après semble cassé alors que le serveur va bien. Voyons comment le lire correctement.
Les enregistrements à connaître
Pas besoin de tous les retenir. Voici ceux qui reviennent :
| Enregistrement | Ce qu'il fait | Quand il mord |
|---|---|---|
| A | Associe un nom à une adresse IPv4 | Le site pointe vers le mauvais/ancien serveur |
| AAAA | Pareil, mais IPv6 | Les utilisateurs IPv6 ne t'atteignent pas |
| MX | Où va le courrier du domaine | Les mails reviennent ou disparaissent |
| TXT | Texte libre — SPF, DKIM, vérification | Le mail tombe en spam ; la vérification échoue |
| NS | Quels serveurs de noms font autorité | Tout le domaine résout mal |
| CNAME | Un alias pointant un nom vers un autre | Un sous-domaine ne résout pas |
| SOA | Métadonnées d'administration de la zone | Rarement — mais nomme le NS primaire |
| CAA | Quelles AC peuvent te délivrer des certificats | La délivrance du certificat est refusée |
Notre outil de requête DNS interroge les dix types qu'il prend en charge — A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV et PTR — contre le résolveur de ton choix : Google (8.8.8.8), Cloudflare (1.1.1.1) ou Quad9 (9.9.9.9), et affiche la sortie brute façon dig, TTL conservés. Tu lis exactement ce qu'un sysadmin voit dans un terminal.
Tu repères un enregistrement A qui pointe vers une IP inconnue ? IP WHOIS te dit en quelques secondes à qui elle appartient.
Le TTL : le nombre que tout le monde ignore jusqu'à ce qu'il compte
Chaque enregistrement porte un TTL — time to live, en secondes. C'est la durée pendant laquelle les résolveurs ont le droit de mettre la réponse en cache avant de redemander. Un TTL de 3600, ça veut dire « fais-y confiance pendant une heure ».
Ce seul nombre explique l'essentiel de la panique « ma modif DNS ne marche pas ». Un exemple simple : tu corriges un enregistrement A à 12h00, mais son TTL est de 86400 (une journée entière). Les résolveurs qui ont interrogé ton domaine à 11h30 continuent de renvoyer l'ancienne IP pendant près de 24 heures encore — si bien que pour certains utilisateurs le site ne « déménage » que le lendemain. Rien n'est cassé ; tu leur as simplement dit qu'ils pouvaient mettre cette réponse en cache pendant une journée.
La règle pratique qu'on suit : baisse le TTL un jour avant de prévoir une modification d'enregistrement. Descends-le à 300 secondes, attends que l'ancien TTL élevé expire, puis fais la modification. Le changement se propage alors en minutes au lieu d'un jour. Remonte-le ensuite pour que les résolveurs ne re-sollicitent pas sans cesse tes serveurs de noms.
« Je l'ai changé — pourquoi ce n'est pas en ligne ? »
Parce que le DNS n'a pas de bouton « actualiser ». Il n'y a pas de serveur central vers qui pousser. Ton serveur de noms faisant autorité a la nouvelle valeur instantanément — mais chaque résolveur qui a déjà mis l'ancienne en cache continue de la servir jusqu'à l'expiration de son TTL. Et différents résolveurs, dans différents pays, expirent à des moments différents.
C'est exactement pour ça qu'on a construit le vérificateur de propagation DNS comme on l'a fait. Au lieu d'interroger un seul résolveur et de s'en contenter, il envoie la même requête en parallèle à 15 résolveurs publics répartis dans le monde — Google et Cloudflare aux États-Unis, Quad9 en Suisse, Mullvad en Suède, CZ.NIC en Tchéquie, Alibaba et DNSPod en Chine, et d'autres. Tu vois le nouvel enregistrement s'allumer région par région à mesure que les caches expirent. Quand les 15 sont d'accord, tu es vraiment propagé.
Repère : la « propagation » n'est pas internet qui rame. Ce sont des caches qui respectent le TTL que tu as fixé.
Quand le résolveur lui-même est le problème
Parfois les enregistrements sont corrects partout et le site résout quand même lentement. Ça pointe vers la latence du résolveur, pas vers les valeurs des enregistrements.
Notre outil de temps de réponse DNS mesure exactement ça : il lance dig contre ces mêmes 15 résolveurs, plusieurs fois chacun, et rapporte le minimum, le maximum et le temps de requête moyen par résolveur. Si tes utilisateurs sont en Allemagne et que tes serveurs de noms répondent à Francfort en 8 ms mais à Sydney en 280 ms, c'est un signal réel et mesurable — peut-être l'heure d'un fournisseur DNS anycast.
Qui contrôle la zone : WHOIS et serveurs de noms
Si les enregistrements NS semblent faux, la question devient qui les a posés. Domain WHOIS te donne le bureau d'enregistrement, les dates d'enregistrement et d'expiration, les codes de statut du domaine, si DNSSEC est activé et — surtout — les serveurs de noms que le registre a en fiche.
Une chose à savoir, parce que les outils bon marché se trompent dessus : beaucoup d'extensions récentes comme .tools, .app et .dev ne font tourner aucun serveur WHOIS traditionnel. Interroge-les à l'ancienne, tu n'obtiens rien. Notre requête bascule automatiquement sur RDAP — le remplaçant moderne en JSON — dès qu'elle détecte une réponse WHOIS maigre ou absente, si bien qu'un domaine .tools renvoie le même résultat structuré qu'un .com. On est tombés là-dessus sur notre propre domaine, d'ailleurs. Le correctif est devenu une fonctionnalité.
Si les serveurs de noms chez le registre ne correspondent pas à ce que tu as posé chez ton hébergeur DNS, tu as trouvé ton bug : le domaine pointe complètement ailleurs, et aucune modification d'enregistrement n'aidera tant que la délégation NS n'est pas corrigée.
Une check-list rapide quand le DNS « ne marche pas »
- Cherche l'enregistrement que tu as changé avec l'outil de requête. La nouvelle valeur y est-elle seulement ?
- Vérifie le TTL. Élevé ? Tu attends juste l'expiration du cache.
- Lance une vérif de propagation. Résultats mitigés entre régions = les caches expirent encore ; cohérent partout = c'est en ligne.
- Vérifie les enregistrements NS face à ton hébergeur DNS avec WHOIS. Un écart de délégation est le vrai coupable plus souvent qu'on ne croit.
- Toujours lent ? Mesure le temps de réponse du résolveur avant d'accuser ton appli.
À retenir
La plupart des « pannes » DNS n'en sont pas. Ce sont des TTL qui font exactement ce que tu leur as dit, ou une délégation qui pointe quelque part que tu avais oublié. Lis les enregistrements, respecte le TTL, et vérifie la propagation sur plus d'un résolveur avant de conclure quoi que ce soit. Commence par une requête — la réponse est en général juste là, dans la sortie.
— l'équipe checkbox.tools