Vérificateur de propagation DNS

Qu'est-ce que la propagation DNS

Ce vérificateur de propagation DNS répond à la question qui te ronge après chaque changement de record : est-ce passé partout, ou seulement sur ta machine ? La "propagation", c'est juste le décalage entre le moment où tu publies une modification DNS et le moment où le reste d'internet le remarque vraiment. Et voilà le truc que personne ne te prévient : à la seconde où ton nameserver autoritaire commence à servir une nouvelle IP, un nouveau record MX ou TXT, presque personne ne l'interroge directement. Les navigateurs et les serveurs mail parlent à des recursive resolvers à la place. Ces resolvers gardent ce qu'ils ont récupéré la dernière fois aussi longtemps que le TTL du record le leur dit. Tant que cette copie en cache n'a pas expiré, tu reçois la réponse périmée. Sans exception. Donc la propagation n'est pas un interrupteur qui bascule. C'est un balayage lent, rythmé par le TTL de chaque record, par les particularités du resolver, et par ce que le réseau décide de faire ce jour-là entre lui et ton nameserver.

Du coup, je pointe trois points d'observation distincts vers le même nom et je mets leurs réponses côte à côte. Deux sont les géants sur lesquels tu t'appuies presque certainement déjà (Google Public DNS, Cloudflare 1.1.1.1), interrogés directement depuis ton navigateur. Le troisième est notre propre resolver serveur, qui glisse un angle européen (OVH) sans que tu quittes la page. Le même record partout, avec des décomptes de TTL qui s'alignent à peu près ? Ton changement est sorti proprement. Un resolver qui crache encore l'ancienne valeur, ou des TTL éparpillés dans tous les sens ? Eh oui, ça mijote encore.

Comment fonctionne un vérificateur de propagation DNS

Sous le capot ? Pas compliqué. La page construit une requête par resolver, les envoie toutes ensemble, et recolle les réponses dans un seul tableau. Google et Cloudflare reçoivent chacun un appel DNS-over-HTTPS (DoH) vers leur endpoint JSON public. Le point d'observation PeopleAreGeek passe par notre REST API, qui se contente de lancer une simple recursive lookup sur la box OVH et de renvoyer le résultat. Les trois reviennent dans la même forme (liste de records, TTL, status code du genre NOERROR ou NXDOMAIN ou SERVFAIL), donc les comparer est trivial. Échantillonner une poignée de resolvers d'un coup te donne une lecture correcte de la façon dont l'internet plus large résout le nom à cet instant précis. Et tu évites d'installer dig ou de te connecter en SSH à un tas de machines pour l'obtenir.

1. Validation de l'entrée. Je nettoie le domaine, je retire le scheme ou le path que tu aurais collé par erreur, puis je remets en ordre le record type pour que les lookups ne s'étouffent pas dessus.
2. Envoi des requêtes DoH vers Google Public DNS et Cloudflare 1.1.1.1, plus une recursive query côté serveur via la REST API PeopleAreGeek.
3. Parsing des réponses. J'extrais les records de réponse, le TTL, le status, et toute chaîne CNAME suivie en chemin.
4. Regroupement des réponses uniques entre les resolvers, pour que tu voies d'un coup d'oeil ce que chacun sert. Et, tout aussi parlant, ce qu'il ne sert pas.
5. Scoring de cohérence. Tout le monde d'accord sur le même jeu de records, ça veut dire que tu es propagé. Une minorité encore coincée sur l'ancienne valeur, c'est que c'est en plein déploiement. Un resolver qui échoue carrément ou qui revient vide ? Ça pointe en général vers quelque chose de cassé en amont, pas juste vers de la lenteur.

Cas d'usage courants d'un vérificateur de propagation DNS

• Juste après avoir modifié un record chez le registrar. Tu viens de basculer un record A vers une nouvelle IP. Maintenant tu veux savoir combien de resolvers sont déjà dessus avant d'aller annoncer à qui que ce soit que la migration est terminée. C'est de loin la raison pour laquelle je l'ouvre le plus souvent.
• En plein milieu d'une migration d'hébergement. Tu pointes un domaine vers un nouveau serveur et, pendant des heures, tu vas recevoir aussi bien l'ancienne que la nouvelle valeur selon à qui tu demandes. La vue Comparaison montre à peu près quelle proportion du pool a basculé. C'est là-dessus que je m'appuie pour décider qu'il est enfin sûr de tuer l'ancienne box.
• Quand tu traques un rapport "ça marche sur ma machine". Un collègue voit le nouveau site, un autre atterrit encore sur l'ancien. Neuf fois sur dix, son resolver est juste resté planté sur un cache périmé, et un petit run ici identifie exactement quel resolver public traîne la patte.
• Email qui part en vrille. Un nouveau record MX, SPF ou DMARC ne fait rien tant que le resolver du serveur mail destinataire ne l'a pas réellement récupéré. Aligner les réponses TXT et MX entre resolvers est un moyen rapide d'écarter un DNS périmé comme cause des mails qui rebondissent ou qui finissent en quarantaine.
• Validation de certificat SSL qui ne passe pas. Les challenges DNS-01 pour Let's Encrypt et les autres flux ACME ont besoin d'un record TXT frais, et quand la validation échoue en boucle, c'est vraiment dur de savoir si tu as mal saisi le record ou s'il n'a simplement pas encore propagé. Comparer les resolvers règle ça en quelques secondes, en général.
• Audits de subdomain takeover. Quand un CNAME pointe vers un service tiers, vérifier la chaîne CNAME sur plusieurs resolvers peut attraper une délégation pendante : déjà disparue du serveur autoritaire, mais encore en cache et exploitable ailleurs.
• Évaluer un domaine douteux. Des réponses qui divergent énormément entre resolvers peuvent évoquer du fast-flux DNS ou un détournement géo-ciblé. Un signal parmi d'autres. Pas une preuve. Mais ça ne coûte rien à récupérer, alors je le récupère.

Limites et notes de confidentialité

Soyons clairs sur ce que cet outil ne fera pas. Trois points d'observation te donnent un instantané solide. Mais trois sur des milliers ? C'est un échantillon, pas un recensement. La plupart des FAI grand public font tourner leurs propres resolvers, et pas mal de réseaux d'entreprise font du split-horizon DNS qui sert des IPs internes pour exactement le même nom. Donc quand quelqu'un rapporte un souci depuis un réseau comme ça, le maximum que cet outil peut honnêtement te dire, c'est "le côté public a l'air OK". Le dernier kilomètre nécessite encore une requête lancée depuis l'intérieur de leur réseau. Autre piège bon à connaître : le TTL que chaque resolver affiche est celui qu'il sert en ce moment, pas forcément celui que tu as réglé sur le serveur autoritaire. Le caching et les chaînes de forwarding grignotent ce chiffre au fur et à mesure du trajet. Et quelques-uns des gros resolvers publics (Quad9, OpenDNS, AdGuard, NextDNS), je n'arrive tout simplement pas encore à les atteindre depuis le navigateur, parce que leurs endpoints DoH ne renvoient pas les en-têtes CORS que les navigateurs exigent. Je les ferai passer par un proxy côté serveur dans une prochaine version.

Côté confidentialité : le domaine que tu interroges part vers les endpoints DoH de Google et de Cloudflare, plus notre propre serveur pour la troisième lecture. Google et Cloudflare appliquent chacun leur propre politique de confidentialité sur le trafic resolver. Ça, c'est leur affaire. Notre resolver serveur ne logge pas ce que tu interroges. Tout est calculé dans ton navigateur, puis effacé à la seconde où tu fermes ou rafraîchis la page.

Questions fréquentes

Combien de temps prend la propagation DNS en général ?

Honnêtement ? Tout dépend du TTL de l'ancien record. La plupart des fournisseurs modernes font tourner un TTL situé entre cinq minutes et une heure, donc en pratique tu es généralement visible mondialement en quelques heures. Les pénibles, ce sont les vieux records encore figés sur un TTL de vingt-quatre heures. Ceux-là peuvent traîner une journée entière. Mon astuce, et elle ne me lâche presque jamais : baisse le TTL quelques heures avant tout changement que tu as prévu, et l'ensemble se boucle bien plus vite.

Quelle est la différence entre un DNS autoritaire et un DNS récursif ?

Vois le serveur autoritaire comme l'unique source de vérité pour ton domaine. C'est là que vivent les vrais records. Les recursive resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) sont les intermédiaires auxquels tes navigateurs et tes serveurs mail parlent réellement, et ils mettent en cache à fond. Ta modification atteint le serveur autoritaire tout de suite. Mais ces caches récursifs ne vont pas se donner la peine d'aller chercher la copie fraîche tant que leur TTL n'est pas à sec. Ce trou, posé entre les deux, c'est toute la raison pour laquelle la propagation paraît si lente.

Pourquoi des resolvers différents renvoient-ils parfois des adresses IP différentes pour le même nom ?

En général une parmi quelques causes, et elles sont vraiment faciles à confondre. Le plus souvent, c'est de la simple propagation encore en vol après une modification récente. Parfois c'est l'EDNS Client Subnet qui fait son truc sur du DNS géo-routé, où le côté autoritaire donne à Google une IP différente selon l'endroit où se trouve physiquement le resolver qui demande. Et parfois ? Totalement normal. Les CDN en anycast et en load-balancing te donneront volontiers n'importe laquelle de plusieurs IPs équivalentes, donc des réponses différentes ne veulent pas dire qu'un truc est cassé.

Cet outil interroge-t-il le resolver de mon FAI ?

Non, il ne le fait pas. La comparaison tourne sur Google Public DNS, Cloudflare 1.1.1.1 et le resolver serveur PeopleAreGeek. Le resolver de ton FAI n'entre jamais dans le tableau. Tu veux voir aussi ce que le tien sert ? Lance dig +short example.com depuis un terminal et pose ça à côté de ce que cette page t'affiche. Ce côte à côte, c'est exactement comme ça que j'attrape un FAI qui traîne discrètement derrière tout le monde.

Pourquoi un resolver renvoie-t-il SERVFAIL ou aucune réponse ?

Ces deux-là embrouillent les gens en permanence, alors voilà comment je les lis. SERVFAIL veut généralement dire que le resolver a bien atteint ton serveur autoritaire mais que la réponse est revenue malformée, ou que la validation DNSSEC a explosé en chemin. Un NOERROR sans rien dedans ? Le nom existe, juste pas ce record type. NXDOMAIN, c'est le verdict plus sévère : le nom lui-même n'existe pas du tout. Quand tu as besoin d'être absolument sûr de lequel tu as sous les yeux, l'onglet Raw JSON détaille le status code exact de chaque resolver.

Puis-je m'y fier pour des décisions de mise en production ?

Pour la plupart des sites grand public et des applis SaaS, je pencherais pour oui. Si les trois points d'observation montrent le nouveau record, tu es propagé sur les deux plus gros resolvers publics plus une lecture serveur européenne, et ça couvre l'essentiel du trafic réel. Mais si ton audience se trouve derrière des réseaux d'entreprise qui font du DNS privé strict, ou si tu as vraiment besoin d'une vue multi-région profonde, ne mise surtout pas le go-live là-dessus seul. Je suis peut-être trop prudent ici, mais lance au moins une requête depuis l'intérieur de ce réseau d'abord. Et ensuite, tranche.