Outil gratuit
Où en est la propagation DNS de mon domaine ?
Vous avez changé une adresse IP, un MX, un enregistrement TXT, et vous ne savez pas si le changement est passé. Cet outil interroge huit résolveurs publics, puis interroge les serveurs de noms de votre zone, et vous montre qui est encore en retard.
Le mécanisme
Rien ne se propage : des copies expirent
Quand vous modifiez un enregistrement, aucun résolveur n'est prévenu. Chacun garde la copie qu'il a prise jusqu'à ce qu'ELLE expire — et cette copie a commencé à vieillir le jour où il a posé la question, pas le jour de votre changement. Déplacez l'horloge et regardez-les lâcher un par un.
Un résolveur qui avait posé la question juste avant votre modification
sa copie expire dans 1 h203.0.113.10l'ancienne valeurUn résolveur qui l'avait posée à mi-durée
sa copie expire dans 30 min203.0.113.10l'ancienne valeurUn résolveur qui l'avait posée peu avant l'expiration
sa copie expire dans 9 min203.0.113.10l'ancienne valeurUn résolveur à qui personne n'avait encore demandé ce nom
aucune copie à expirer198.51.100.25la nouvelle valeur
À la seconde où vous validez, trois de ces quatre résolveurs servent encore l'ancienne valeur, et vous n'y pouvez rien. Le quatrième n'avait rien en cache : il voit la nouveauté tout de suite.
Une durée de vie est un plafond que chaque cache compte depuis SA propre question (RFC 1035, § 3.2.1). Le « jusqu'à 48 heures » répété par les hébergeurs ne vient d'aucune règle : le pire cas, c'est la durée de vie que vous aviez publiée avant de modifier.
Ce que cet outil mesure, et ce qu'il ne mesure pas
Il interroge huit résolveurs publics par leur adresse, depuis un seul serveur. Il ne sait donc rien de ce que voit quelqu'un à Tokyo. Les outils qui affichent une carte du monde avec des drapeaux interrogent les mêmes adresses que nous : ils ne mesurent pas la géographie, ils mesurent l'état de gros caches. Nous l'affichons pour ce que c'est, et nous ajoutons ce qu'ils omettent — la valeur publiée par les serveurs de la zone, seule référence qui permette de dire si une réponse est la bonne ou l'ancienne.
Surveiller au lieu de recharger
Un jour de migration, on recharge cette page toutes les cinq minutes. C'est normal, et c'est exactement ce qu'un outil ponctuel ne sait pas faire : vous prévenir. DomainVigil relit vos enregistrements en continu et vous écrit quand ils changent — y compris quand ils changent sans vous, parce qu'un prestataire a touché à la zone ou qu'un transfert a remis les anciens serveurs de noms. Le jour de la migration, l'outil suffit. Les trois cent soixante-quatre autres, c'est la surveillance qui compte.
Les durées qui décident
Quarante-huit heures ? Quatre nombres suffisent.
Aucune de ces durées ne se négocie pendant la migration. Trois sont fixées avant, une seule vous appartient le jour même.
172 800s
La délégation d'un .com
Le seul palier qui justifie « jusqu'à 48 heures », et il ne concerne qu'un changement de serveurs de noms. Le registre le fixe, pas vous.
3 600s
La même délégation, en .fr
Quarante-huit fois moins pour le même geste. L'extension du domaine pèse sur l'attente bien plus que l'hébergeur.
300s
À publier la veille
La durée de vie à poser sur l'enregistrement 24 h avant la bascule. Après le changement il est trop tard : les caches tiennent l'ancienne valeur avec l'ancienne durée.
8
Résolveurs interrogés
À chaque contrôle, plus les serveurs de noms de votre zone — les seuls qui fassent autorité, et la référence du tableau.
Les deux premières valeurs sont celles que publient les registres sur la délégation ; la troisième est celle que vous posez dans votre zone ; la dernière est ce que fait ce contrôle.
Idées reçues
Ce qu'on dit d'une propagation, et ce qui se passe vraiment
Les quatre phrases de gauche s'entendent chaque jour. Aucune n'est vraie, et chacune coûte une nuit d'attente.
Ce qu'on croit
Ce qui se passe
« Un changement DNS met 48 heures à se propager. »
Les 48 heures ne concernent que la délégation d'un .com. Un enregistrement A suit la durée de vie que votre zone publie, souvent une heure.
« Il faut attendre que les résolveurs se mettent d'accord entre eux. »
Aucun résolveur ne se concerte. Chacun garde sa copie jusqu'à ce qu'ELLE expire, et son horloge a commencé le jour où il a posé la question.
« Vider mon cache accélère la propagation. »
Vider un cache ne change que la machine où on le vide. Les résolveurs publics gardent la leur, et c'est eux que voient vos visiteurs.
« Mon navigateur montre l'ancien site : le changement n'est pas passé. »
Trois caches s'empilent derrière le résolveur : celui du système, celui du navigateur, et souvent celui d'un réseau de diffusion devant le site.
Lire le tableau
Chaque ligne est un résolveur, et sa puce dit son rapport à la valeur publiée par la zone.
- Identique à la zone
- Ce résolveur sert la valeur que vos serveurs de noms publient. Pour ses utilisateurs, le changement est fait.
- Différent de la zone
- Ce résolveur sert autre chose. Soit son cache n'a pas expiré, soit un réseau de diffusion lui répond une adresse propre à sa région. La colonne « durée de vie » tranche : un nombre qui décroît d'un contrôle à l'autre est un cache qui va expirer.
- Aucun enregistrement de ce type
- Le nom existe mais ne porte pas ce type, ou le résolveur a mémorisé son absence. Après une création, c'est l'état normal pendant la durée du cache négatif de la zone.
- Pas de réponse
- Le résolveur n'a rien renvoyé dans les quatre secondes. Ces services sont partagés et limitent le débit ; l'absence de réponse ne dit rien de votre domaine.
- Durée de vie
- Le temps qu'il reste avant que ce résolveur repose la question. Le DNS ne la publie que pour les enregistrements A et AAAA ; pour les autres types la colonne reste vide, et nous ne l'inventons pas.
- Ce que dit la zone
- Le bloc du haut. Cette valeur vient d'un serveur de noms du domaine, interrogé directement, sans passer par aucun cache. C'est elle qui fait autorité — et sans elle, huit réponses identiques ne prouvent rien.
Les erreurs qui font croire à un problème de propagation
Dans la plupart des cas où « le DNS ne se propage pas », il n'y a rien à propager : l'enregistrement n'a pas été publié là où on le cherche.
Le changement a été fait chez le registrar, mais la zone est servie ailleurs
Ce qui la provoque : Le domaine est enregistré chez un fournisseur et ses serveurs de noms pointent vers un autre. L'interface du registrar affiche alors une zone qui n'est plus lue par personne.
Le geste qui corrige : Interrogez le type NS ci-dessus. Les serveurs qui remontent sont ceux qui font foi : c'est chez eux qu'il faut modifier l'enregistrement, pas chez le registrar.
On attend depuis 48 heures pour un changement d'adresse IP
Ce qui la provoque : Le délai de 48 heures appartient au changement de serveurs de noms d'un .com, pas à un enregistrement A. Ce sont deux durées de vie différentes, fixées par deux acteurs différents.
Le geste qui corrige : Le délai d'un enregistrement est la durée de vie que votre zone publie, souvent une heure. Celui d'une délégation est fixé par le registre : 172 800 secondes pour un .com, 3 600 pour un .fr.
Le navigateur montre encore l'ancien site alors que tous les résolveurs sont à jour
Ce qui la provoque : Trois caches s'empilent derrière le résolveur : celui du système, celui du navigateur, et souvent celui d'un réseau de diffusion devant le site.
Le geste qui corrige : Videz le cache du système (« ipconfig /flushdns » sous Windows, « sudo dscacheutil -flushcache » sous macOS), puis celui du navigateur. Sur Chrome, la page « chrome://net-internals/#dns » porte un bouton pour cela.
On a créé le TXT, et aucun résolveur ne le voit
Ce qui la provoque : Le résolveur avait déjà répondu « ce nom ne porte rien » avant la création, et il garde cette absence en mémoire. C'est le cache négatif, réglé par le dernier champ de l'enregistrement SOA de la zone (RFC 2308).
Le geste qui corrige : Attendez la durée de ce champ. Sur la zone de l'AFNIC il vaut 600 secondes, sur beaucoup de zones hébergées 1 800. Rien ne l'accélère depuis l'extérieur.
Deux résolveurs donnent deux adresses différentes, et ça ne bouge jamais
Ce qui la provoque : Ce n'est pas de la propagation : le domaine est servi par un réseau de diffusion ou une répartition géographique, qui répond une adresse proche de celui qui demande.
Le geste qui corrige : Comparez à la valeur de la zone. Si elle-même varie d'un serveur de noms à l'autre, la configuration est intentionnelle et il n'y a rien à corriger.
Les paliers de propagation, et qui les fixe
« Ça peut prendre jusqu'à 48 heures » est le conseil que donnent tous les hébergeurs. Il est vrai pour un seul de ces paliers. Voici les six, avec ce qui les cause et qui en tient la durée.
| Palier | Durée | Qui la fixe, et ce qui l'accélère |
|---|---|---|
| TTL de l'enregistrement | la valeur publiée, de 60 à 86 400 secondes | Vous, dans votre zone. Abaissez-la à 300 secondes 24 h AVANT une migration : une fois le changement fait, il est trop tard, les caches tiennent l'ancienne valeur avec l'ancienne durée. |
| Cache négatif | le dernier champ du SOA, souvent 600 à 3 600 secondes | Votre zone. Il s'applique à une CRÉATION : le résolveur a mémorisé que le nom ne portait rien. Mesuré le 12/09 : 600 s sur la zone .fr de l'AFNIC, 1 800 s sur une zone hébergée chez Cloudflare. |
| Délégation NS | 172 800 secondes pour un .com, 3 600 pour un .fr | Le registre de l'extension, pas vous. C'est le seul palier qui justifie « jusqu'à 48 heures », et il ne concerne qu'un changement de serveurs de noms. |
| Résolveur du fournisseur d'accès | le TTL, parfois davantage | Votre fournisseur d'accès. Certains allongent la durée de vie des réponses pour économiser du trafic ; c'est chez eux qu'un changement paraît ne jamais passer. |
| Cache du système | jusqu'au redémarrage | Votre machine. « ipconfig /flushdns » sous Windows, « sudo dscacheutil -flushcache » sous macOS, « resolvectl flush-caches » sous Linux. |
| Cache du navigateur | indépendant du système | Chrome et Firefox tiennent leur propre table. Sur Chrome, « chrome://net-internals/#dns » permet de la vider sans fermer le navigateur. |
Le geste qui change tout se fait AVANT la migration, pas après : baisser la durée de vie de l'enregistrement à 300 secondes la veille, la remonter le lendemain. Personne ne le fait, et c'est pour cela que tout le monde attend 48 heures.
Questions fréquentes
Combien de temps prend vraiment la propagation DNS ?
La durée de vie que votre zone publie pour l'enregistrement, et rien de plus, pour un changement d'adresse IP, de MX ou de TXT. Une heure est la valeur la plus répandue. Les 48 heures souvent annoncées concernent le seul changement de serveurs de noms d'un domaine en .com, parce que le registre publie la délégation avec une durée de vie de 172 800 secondes. Un .fr change de serveurs de noms en une heure.
Pourquoi mon site s'affiche chez moi et pas chez mon client ?
Vos deux machines n'interrogent pas le même résolveur. Le vôtre a déjà repris la nouvelle valeur, celui de votre client tient encore l'ancienne jusqu'à expiration de son cache. Le tableau ci-dessus le montre résolveur par résolveur. Si l'écart ne bouge pas après plusieurs contrôles, ce n'est pas un cache : c'est une réponse géographique, ou un enregistrement modifié dans la mauvaise zone.
Peut-on forcer la propagation DNS ?
Non, pas depuis l'extérieur. Un cache appartient à celui qui le tient, et aucun outil ne l'oblige à oublier. Deux choses sont en votre pouvoir : abaisser la durée de vie de l'enregistrement avant le changement, et vider les caches de vos propres machines après. Google et Cloudflare proposent des pages pour purger une entrée de leur cache public, ce qui règle leur cas et celui de personne d'autre.
Pourquoi la colonne « durée de vie » est vide pour un MX ou un TXT ?
Parce que la bibliothèque DNS que nous utilisons ne la rend que pour les enregistrements A et AAAA. Nous préférons une colonne vide à un chiffre inventé. La durée de vie du type que vous consultez se lit dans votre interface de zone, à côté de l'enregistrement.
Mon changement est visible partout, mais l'ancien site s'affiche encore. Pourquoi ?
Le DNS a fini son travail : le problème est ailleurs. Regardez d'abord le cache de votre navigateur et celui de votre système. Puis le réseau de diffusion devant le site, s'il y en a un : Cloudflare, par exemple, garde sa propre copie des pages et il faut la purger séparément. Enfin le serveur lui-même, qui peut servir deux sites selon le nom d'hôte reçu.
Huit résolveurs, est-ce suffisant pour conclure ?
Pour savoir si un changement est passé, oui : ces huit services couvrent une part considérable des requêtes de la planète, et ils ne tiennent pas un cache commun. Pour savoir ce que voit un visiteur précis dans un pays précis, non, et aucun outil public ne le sait — y compris ceux qui affichent une carte.
Le déroulé
Une migration d'hébergeur, heure par heure : ce qu'on voit, ce qui se passe vraiment
Le scénario est toujours le même, et la panique arrive toujours au même endroit. Voici les sept moments d'une bascule ordinaire, avec en face de chacun ce qui se joue réellement dans les caches.
J − 7
Tout le monde est prévenu, sauf les caches
Ce qu'on voit
La date est calée, le nouvel hébergeur confirme, l'équipe bloque le créneau du mardi matin.
Ce qui se passe
L'enregistrement A publie encore une durée de vie de 14 400 secondes. Tant que personne n'y touche, c'est cette valeur-là que chaque résolveur emportera avec sa prochaine copie — et elle vaudra encore quatre heures le jour de la bascule.
J − 1, 9 h
Le seul geste qui raccourcit l'attente
Ce qu'on voit
On passe la durée de vie de 14 400 à 300 secondes dans la zone. « Voilà, maintenant ce sera rapide. »
Ce qui se passe
La nouvelle durée de vie n'est lue que par les résolveurs qui reposent la question. Ceux qui ont copié la veille gardent l'ancienne, entière. Il faut donc abaisser au moins une ancienne durée de vie avant la bascule : ici quatre heures, pas une. Fait la veille, c'est large ; fait le matin même, c'est inutile.
J, 10 h 00
La bascule
Ce qu'on voit
La nouvelle adresse est publiée. Sur le poste de celui qui vient de la saisir, le site répond déjà depuis le nouveau serveur.
Ce qui se passe
Aucun résolveur n'a été prévenu de quoi que ce soit. Le protocole ne le prévoit pas : chacun découvrira le changement quand sa copie expirera, à sa propre heure (RFC 1035, § 3.2.1).
J, 10 h 05
Le premier appel
Ce qu'on voit
« Chez moi, c'est encore l'ancien site. » Deux minutes plus tard, un deuxième appel, avec un écran différent.
Ce qui se passe
Le résolveur du premier a copié à 10 h 02 : sa copie tient jusqu'à 10 h 07. Celui du second avait copié à 9 h 58, sous l'ancienne durée de vie de quatre heures. Les deux ont raison, et rien ne les départage sauf le temps.
J, 10 h 30
Le test qui ne prouve rien
Ce qu'on voit
Un collègue vide son cache, recharge, voit le nouveau site. On en conclut que c'est passé.
Ce qui se passe
On vient de mesurer une machine, pas un réseau. La seule référence est la valeur servie par un serveur de noms de la zone, interrogé sans passer par un cache — c'est le bloc du haut de cette page.
J, 11 h 15
Le site s'affiche, le cadenas manque
Ce qu'on voit
Le nouveau serveur répond bien, mais le navigateur affiche un avertissement de certificat.
Ce qui se passe
Ce n'est plus du DNS. Un certificat se demande une fois que le nom pointe vers le nouveau serveur : l'autorité vérifie soit un fichier servi par ce serveur, soit un enregistrement TXT de la zone. Avant la bascule, cette vérification ne pouvait pas aboutir.
J + 2
On remonte la durée de vie
Ce qu'on voit
Plus personne ne se plaint depuis la veille. La migration est classée.
Ce qui se passe
Laisser 300 secondes en permanence, c'est faire reposer la question quarante-huit fois plus souvent à vos serveurs de noms. On remonte à une heure une fois la bascule confirmée — et on note la date, parce que la prochaine migration commencera par redescendre.
Les durées citées sont celles d'une zone ordinaire ; les vôtres se lisent à côté de chaque enregistrement dans votre interface de zone. Le seul palier hors de votre main est la délégation, tenue par le registre de l'extension.
À 3 h du matin
Le site ne répond plus après la bascule : que regarder, et dans quel ordre
Six situations, et le seul endroit à regarder pour chacune. Le tableau du haut donne la réponse en trois secondes : comparez toujours la ligne « ce que dit la zone » aux lignes des résolveurs.
SiLe bloc du haut n'affiche aucune valeur pour la zone
RegardezLe type NS du domaine, puis l'état de l'hébergeur de la zone.
Parce que Si les serveurs de noms ne répondent plus, plus rien ne peut résoudre le nom une fois les caches expirés. C'est la seule panne de cette liste qui s'aggrave toute seule avec le temps.
SiLa zone répond la nouvelle valeur, les résolveurs l'ancienne
RegardezRien. Il n'y a rien à réparer, il y a à attendre.
Parce que Le changement est publié et correct. Le pire cas restant est la durée de vie qui était publiée avant la modification, pas celle d'aujourd'hui.
SiLa zone répond l'ancienne valeur
RegardezChez qui la zone est réellement servie : le type NS, et l'interface qui porte ces serveurs-là.
Parce que La modification a été faite dans une zone que plus personne ne lit — presque toujours celle du registrar, alors que les serveurs de noms pointent ailleurs.
SiCertains résolveurs répondent « aucun enregistrement », d'autres la bonne valeur
RegardezLa durée du cache négatif de la zone, dernier champ de l'enregistrement SOA.
Parce que Ces résolveurs avaient posé la question avant la création et ont mémorisé l'absence (RFC 2308). Rien ne l'accélère depuis l'extérieur : cette copie-là expire comme les autres.
SiLe domaine nu fonctionne mais pas « www », ou l'inverse
RegardezLa zone, ligne par ligne : ce sont deux noms distincts.
Parce que « www » est un enregistrement à part entière. Rien dans le DNS ne le crée automatiquement à partir du domaine, et beaucoup de migrations n'en recopient qu'un des deux.
SiLe nom résout vers la bonne adresse et le serveur sert encore l'ancien site
RegardezDans cet ordre : le cache du navigateur, celui du système, le réseau de diffusion devant le site, puis la configuration du serveur.
Parce que Le DNS a fini son travail. Trois caches s'empilent derrière lui, et un serveur peut servir deux sites selon le nom d'hôte qu'il reçoit.
À garder sous la main
Les codes de réponse DNS : NOERROR, NXDOMAIN, SERVFAIL, REFUSED
Toute réponse DNS porte un code sur quatre bits. Il se lit dans la ligne « status » de dig, et il dit à lui seul de quel côté chercher.
| Code | Ce qu'il dit | Ce qu'il faut regarder |
|---|---|---|
| NOERROR (0) | La question a abouti. | Attention au piège : un NOERROR peut ne contenir aucune réponse. Le code seul ne suffit pas, il faut compter les enregistrements renvoyés. |
| NOERROR, zéro réponse | Le nom existe, mais il ne porte pas le type demandé. | Ce n'est pas un code à part : c'est l'état que la RFC 2308 appelle NODATA. Après une création, c'est ce que votre zone renvoie tant que l'enregistrement n'est pas publié — et ce que les résolveurs gardent en cache négatif. |
| NXDOMAIN (3) | Le nom n'existe pas. | Et rien en dessous non plus : depuis la RFC 8020, un NXDOMAIN vaut pour tout le sous-arbre. S'il tombe sur un nom que vous venez de créer, c'est le cache négatif de la zone, pas une erreur. |
| SERVFAIL (2) | Le résolveur n'a pas pu produire de réponse. | Premier suspect : une validation DNSSEC en échec — signature expirée, DS qui ne correspond plus à la clé publiée (RFC 4035). Signature qui ne trompe pas : le nom échoue chez les résolveurs qui valident et fonctionne chez ceux qui ne valident pas. |
| REFUSED (5) | Le serveur refuse de répondre, par politique. | Presque toujours : on interroge un serveur qui n'est pas autoritaire pour cette zone et qui n'accepte pas de récursion. Vérifiez à quel serveur la question a été posée avant d'accuser la zone. |
| NOTAUTH (9) | Le serveur interrogé ne fait pas autorité pour cette zone. | Un vestige de l'ancienne délégation, ou un serveur secondaire qui n'a jamais reçu le transfert. Comparez la liste des NS publiée par le registre à celle publiée par la zone. |
| FORMERR (1) | La requête n'a pas été comprise. | Rarement votre zone : plutôt un intermédiaire réseau qui tronque les réponses EDNS. Il se manifeste sur les réponses longues, DNSSEC en tête. |
Codes définis par la RFC 1035, § 4.1.1, et tenus à jour dans le registre « DNS RCODEs » de l'IANA. Depuis la RFC 8914, un résolveur peut joindre à sa réponse une erreur DNS étendue qui précise le motif — par exemple « DNSSEC Bogus » derrière un SERVFAIL. dig l'affiche sous l'intitulé EDE quand elle est présente.
Le geste qui change tout se fait avant la migration, pas après.
Le geste
Changer d'hébergeur sans coupure : le calendrier en trois temps
La quasi-totalité de ce qui peut être fait se fait avant la bascule. Une fois le changement publié, il ne reste qu'à attendre — et à ne pas croire aux gestes qui ne servent à rien.
Avant — la seule fenêtre où l'on agit
- Relever la durée de vie actuelle de chaque enregistrement qui va changer, et la noter pour pouvoir la remettre.
- L'abaisser à 300 secondes au moins une ancienne durée de vie avant la bascule. C'est le geste qui décide de tout le reste.
- Vérifier chez qui la zone est servie, en interrogeant le type NS. C'est là que les modifications comptent, pas forcément chez le registrar.
- Si la migration crée des noms qui n'existaient pas, abaisser aussi le dernier champ du SOA : c'est lui qui fixe la durée du cache négatif.
- Relever les enregistrements qui ne doivent PAS bouger — MX, TXT d'authentification, CAA — et vérifier qu'ils existent à l'identique dans la nouvelle zone avant de déléguer.
Pendant — vérifier la zone, pas son propre écran
- Publier, puis contrôler d'abord la valeur servie par un serveur de noms de la zone. Tant qu'elle est fausse, regarder les résolveurs n'a aucun sens.
- Laisser l'ancien serveur allumé et fonctionnel au moins une ancienne durée de vie. Des visiteurs y arriveront encore, et une page d'erreur y fait plus de dégâts qu'une page un peu datée.
- Pour un changement de serveurs de noms, compter sur la durée de la délégation tenue par le registre, pas sur la vôtre : 172 800 secondes pour un .com, 3 600 pour un .fr.
- Demander le certificat une fois que le nom pointe vers le nouveau serveur, jamais avant : la vérification passe par ce serveur ou par la zone.
Après — refermer proprement
- Remonter la durée de vie à sa valeur d'origine une fois la bascule confirmée, sans quoi vos serveurs de noms encaissent quarante-huit fois plus de requêtes.
- Contrôler les enregistrements qui n'ont pas bougé. Une zone recréée à la main perd en silence ce dont personne ne parle : SPF, DKIM, DMARC, CAA, vérifications de propriété.
- Éteindre l'ancien serveur seulement après, et garder sa sauvegarde. Un retour en arrière consiste à republier l'ancienne adresse — encore faut-il qu'il y ait quelque chose derrière.
Ce qui ne sert à rien
- Vider le cache de votre machine pour accélérer chez les autres : cela ne change que ce que vous voyez, vous.
- Basculer votre poste sur un résolveur public pour « vérifier » : vous mesurez alors ce résolveur-là, et vous perdez la vue de votre fournisseur d'accès.
- Appeler l'hébergeur pour qu'il « force la propagation » : aucun opérateur ne peut vider le cache d'un autre.
- Supprimer puis recréer l'enregistrement : cela ne purge aucun cache, et cela ajoute un cache négatif à attendre.
- Attendre 48 heures par principe : ce délai n'existe que pour un changement de serveurs de noms, et pas dans toutes les extensions.
Le vocabulaire
Huit mots qu'on lit partout sans jamais les voir définis
Ce sont les termes qui apparaissent dans le tableau ci-dessus, dans les réponses de dig, et dans l'interface de votre hébergeur.
TTL- Durée de vie, en secondes. Un plafond que chaque cache compte depuis SA question, jamais depuis votre modification.
SOA- L'enregistrement d'en-tête d'une zone. Son dernier champ fixe la durée du cache négatif.
cache négatif- La mémoire d'une absence : le résolveur a retenu que le nom ne portait rien. C'est lui qu'on attend après une création (RFC 2308).
résolveur- Le serveur qui répond à votre machine. Il interroge la zone une fois, puis sert sa copie à tout le monde.
zone- L'ensemble des enregistrements d'un domaine, tels que les publient ses serveurs de noms.
délégation- Les serveurs de noms que le registre de l'extension désigne comme faisant autorité pour le domaine.
faisant autorité- Une réponse obtenue auprès d'un serveur de la zone, sans passer par aucun cache. C'est la référence du tableau.
NXDOMAIN- Le nom n'existe pas — et rien en dessous non plus, depuis la RFC 8020.
Vingt contrôles, sans inscription
- Générateur d'enregistrement SPF
- Quelle est la réputation de ce domaine ?
- Les en-têtes de sécurité de ce site
- Le bilan complet d'un domaine
- Quand expire ce nom de domaine ?
- Ce certificat SSL est-il valide ?
- Vos e-mails sont-ils authentifiés ?
- Ce domaine est-il sur une liste noire ?
- Quels serveurs reçoivent les e-mails de ce domaine ?
- Quels serveurs de noms répondent pour ce domaine ?
- Quels enregistrements TXT porte ce domaine ?
- Vers quoi pointe cet alias ?