Outil gratuit
Quels serveurs de noms répondent pour ce domaine ?
Les serveurs de noms d'un domaine, et surtout la comparaison que personne ne fait à la main : ce que la zone répond, face à ce que le registre a réellement délégué. Sans inscription, sans e-mail à laisser.
Ce sont eux qui décident de tout le reste
Les serveurs de noms d'un domaine sont l'autorité qui répond à toutes les autres questions : où est le site, où va le courrier, quel certificat est validé. Le jour où la liste change ou se trompe, ce n'est pas une page qui casse — c'est le domaine entier qui bascule d'un coup, site et messagerie compris, et en général sans que personne ne l'ait décidé.
Deux sources, et elles ne disent pas toujours la même chose
Le registre du domaine publie une délégation ; les serveurs cités répondent une liste. Les deux devraient coïncider. Quand elles divergent, la résolution devient une loterie : selon le résolveur qu'il utilise, un visiteur atteint l'ancien hébergement ou le nouveau. L'outil interroge les deux sources et affiche l'écart.
La descente
Trois questions posées à trois serveurs différents
Personne ne connaît la réponse en entier. Chacun renvoie vers le suivant, jusqu'au serveur qui fait autorité sur votre domaine. Déroulez la conversation.
Le résolveurQui sait répondre pour www.example.com ?
Serveur racineJe ne connais que les extensions. Pour tout ce qui finit en .com, adressez-vous aux serveurs de .com.
Une réponse qui fait autorité vient du serveur désigné par le registre. Tout ce qui précède n'est qu'un renvoi vers le suivant.
La règle qu'on enfreint le plus
Deux. C'est le minimum, et ce n'est pas un conseil.
2serveurs
Un domaine servi par une seule machine est un domaine à un seul point de panne.
La règle des deux serveurs de noms au minimum est posée depuis les fondations du système (RFC 1034, 1987) et n'a jamais changé. La RFC 2182 va plus loin : elle recommande de les placer sur des réseaux distincts, idéalement chez deux opérateurs, pour que la panne de l'un ne soit pas la panne du domaine — site, courrier et certificats compris.
Lire le résultat
Le tableau donne les serveurs annoncés par la zone elle-même. Les constats en dessous confrontent cette liste à la délégation du registre, puis vérifient que chaque serveur cité mène bien à une adresse.
- Rien à signaler — les deux listes coïncident
- Le registre délègue aux mêmes serveurs que ceux annoncés dans la zone, et chacun résout. C'est l'état normal d'un domaine en bonne santé.
- À surveiller — le registre et la zone divergent
- Les deux listes ne sont pas identiques. Pendant un changement d'hébergeur c'est attendu, le temps que l'ancienne délégation sorte des mémoires. Passé quelques jours, c'est un oubli — et il laisse une partie des visiteurs sur l'ancien site.
- À surveiller — un seul serveur de noms
- Toute la résolution du domaine repose sur une seule machine. La norme en demande deux depuis l'origine : s'il tombe, le site et le courrier disparaissent ensemble, et rien ne prend le relais.
- Problème — un serveur de noms ne résout pas
- Un nom figure dans la liste mais ne mène à aucune adresse. Une requête qui tombe sur lui reste sans réponse, et la résolution devient intermittente — le genre de panne qu'on décrit par « ça marche une fois sur trois ».
- Problème — aucun serveur de noms
- La zone n'en déclare aucun. Plus rien ne peut être résolu pour ce domaine : ni le site, ni le courrier, ni les certificats.
- Problème — le nom n'existe pas
- Aucun serveur de noms ne connaît ce domaine. Il n'est pas enregistré, ou il ne l'est plus, ou sa délégation a été retirée.
- Indéterminé — serveurs internes au domaine
- Les serveurs cités portent un nom situé dans le domaine qu'ils servent. Leur adresse ne peut alors venir que du registre, par un enregistrement dit « glue ». Ce n'est pas un défaut : c'est une dépendance de plus, qu'un résolveur ordinaire ne permet pas de vérifier.
- Indéterminé — pas de réponse à temps
- Le résolveur n'a rien rendu dans le délai imparti. Cela arrive sur une zone lente ou momentanément surchargée.
Les erreurs qu'on voit le plus souvent
Les serveurs ont été changés chez le registrar, la zone n'a pas été recopiée
Ce qui la provoque : on bascule la délégation vers un nouveau fournisseur avant d'y avoir recréé les enregistrements. Le nouveau serveur répond « je ne connais pas », ou sert une zone vide.
Le geste qui corrige : créer la zone complète chez le nouveau fournisseur, la contrôler en l'interrogeant directement, et ne changer la délégation qu'après.
L'ancien fournisseur est resté dans la liste
Ce qui la provoque : on ajoute les deux nouveaux serveurs sans retirer les deux anciens. Les résolveurs interrogent l'un ou l'autre au hasard, et le site répond tantôt en nouvelle version, tantôt en ancienne.
Le geste qui corrige : la délégation doit contenir les serveurs d'UN seul fournisseur. Retirer les anciens le jour de la bascule.
Le domaine était signé, la signature est restée chez le registre
Ce qui la provoque : un domaine protégé par DNSSEC porte chez son registre une empreinte de la clé de sa zone. Si l'on change de fournisseur sans retirer cette empreinte, les résolveurs qui vérifient les signatures ne trouvent plus de correspondance et refusent toute réponse. Le domaine disparaît pour une partie d'internet, pas pour l'autre.
Le geste qui corrige : retirer l'empreinte chez le registrar AVANT de changer la délégation, ou publier chez le nouveau fournisseur une clé correspondante.
La durée de vie n'a pas été abaissée avant le changement
Ce qui la provoque : les serveurs de noms se mettent en mémoire longtemps, souvent un ou deux jours. Tant que l'ancienne réponse court, une partie du monde continue d'interroger l'ancien fournisseur.
Le geste qui corrige : abaisser la durée de vie quelques jours avant la bascule, la remonter une fois le changement visible partout.
Les deux serveurs sont deux noms sur la même machine
Ce qui la provoque : deux noms différents pointant vers la même adresse donnent l'apparence de la redondance sans en avoir aucun des effets. La panne de la machine emporte les deux.
Le geste qui corrige : vérifier que les serveurs annoncés résolvent vers des adresses distinctes. C'est tout l'objet de la règle des deux serveurs.
Qui détient quoi, dans la résolution d'un nom
La plupart des pannes de délégation viennent d'une confusion entre ces cinq éléments. Chacun détient une partie de la réponse, et il ne sert à rien de corriger chez l'un ce qui est publié par l'autre.
| Acteur | Ce qu'il détient | Ce qui s'y corrige |
|---|---|---|
| Le registre | La délégation : la liste officielle des serveurs de noms du domaine, et l'adresse de ceux qui portent un nom interne au domaine. | Le changement de fournisseur DNS, et l'empreinte DNSSEC. Rien d'autre. |
| Le registrar | Rien techniquement : c'est l'intermédiaire par lequel vous demandez au registre de modifier la délégation. | L'interface où l'on saisit les serveurs de noms, le renouvellement, le verrou de transfert. |
| Les serveurs faisant autorité | La zone : tous les enregistrements du domaine — adresses, MX, TXT, alias — et la liste des serveurs de noms telle que la zone la déclare. | Tout le contenu du domaine. C'est là qu'on ajoute un MX ou un TXT. |
| Le résolveur récursif | Rien en propre : il interroge les autres et garde leurs réponses en mémoire le temps annoncé. | Rien. On ne corrige pas un résolveur, on attend que sa mémoire expire. |
| L'enregistrement « glue » | L'adresse d'un serveur de noms dont le nom est situé dans le domaine qu'il sert. | Chez le registre, par le registrar. Sans lui, la résolution tourne en rond. |
La règle des deux serveurs de noms au minimum est posée depuis les fondations du système (RFC 1034), et la recommandation de les placer sur des réseaux distincts par la RFC 2182.
Les réponses d'un serveur de noms, et ce qu'elles veulent dire
Chaque réponse DNS porte un code. Il ne s'affiche nulle part dans un navigateur, mais c'est lui qui distingue « ce nom n'existe pas » de « ce serveur refuse de répondre » — deux pannes que rien ne rapproche.
| Code | Ce que dit le serveur | Ce qu'il faut regarder |
|---|---|---|
| NOERROR | La question a abouti. | Si aucune donnée n'accompagne la réponse, le nom existe mais ne porte pas ce type d'enregistrement. |
| NXDOMAIN | Ce nom n'existe pas. | Faute de frappe, enregistrement supprimé, ou domaine expiré. |
| SERVFAIL | Le serveur n'a pas pu produire de réponse. | La cause la plus fréquente sur un domaine signé : une signature DNSSEC qui ne correspond plus à l'empreinte publiée chez le registre. |
| REFUSED | Le serveur refuse de répondre pour cette zone. | Il ne se considère pas responsable du domaine. La délégation pointe vers un serveur qui n'héberge pas la zone. |
| NOTIMP | Le serveur ne sait pas traiter cette question. | Rare, et sans rapport avec le contenu du domaine. |
| FORMERR | La question était mal formée. | Un problème de l'émetteur ou d'un équipement réseau qui réécrit les paquets, pas de la zone. |
Ces codes sont définis par la norme du DNS (RFC 1035) et complétés depuis. Un même domaine peut rendre NOERROR sur un résolveur et SERVFAIL sur un autre : seuls les résolveurs qui vérifient les signatures voient une erreur DNSSEC.
Questions fréquentes
Qu'est-ce qu'un serveur de noms ?
C'est la machine qui détient la réponse officielle aux questions posées sur un domaine : quelle adresse pour le site, quels serveurs pour le courrier, quels enregistrements de vérification. Changer de serveurs de noms revient à changer d'autorité pour le domaine entier, pas seulement pour le site.
Comment savoir si mes serveurs de noms ont bien changé ?
En comparant deux sources. Le registre publie la délégation officielle ; les serveurs cités répondent leur propre liste. Tant que les deux diffèrent, le changement n'est pas terminé — c'est exactement la comparaison que fait l'outil ci-dessus.
Combien de serveurs de noms faut-il ?
Deux au minimum, et c'est une règle du système depuis son origine, pas une précaution d'administrateur. Deux adresses distinctes, de préférence sur des réseaux différents : une redondance qui repose sur deux noms pointant vers la même machine ne protège de rien.
Combien de temps prend un changement de serveurs de noms ?
Le registre publie la nouvelle délégation en quelques minutes à quelques heures. Ce qui prend du temps, c'est la mémoire des résolveurs du monde entier : ils conservent l'ancienne réponse pendant la durée annoncée, souvent un à deux jours. Pendant cette période, les deux hébergements répondent.
Qu'est-ce qu'un enregistrement « glue » ?
Quand les serveurs de noms d'un domaine portent un nom situé dans ce même domaine, on ne peut pas les résoudre sans déjà savoir les interroger. Le registre publie donc directement leur adresse, à côté de la délégation : c'est le « glue ». Il n'existe pas quand les serveurs appartiennent à un autre domaine.
Mon site ne répond plus depuis le changement, alors que la zone est correcte
Si le domaine était protégé par DNSSEC, l'empreinte de l'ancienne clé est probablement restée chez le registre. Les résolveurs qui vérifient les signatures ne trouvent plus de correspondance et refusent toute réponse, tandis que les autres servent le site normalement. C'est la panne qui touche « une partie des gens seulement ».
Comment voir les serveurs de noms d'un domaine en ligne de commande ?
Sur macOS et Linux, « dig NS example.com +short » rend la liste annoncée par la zone. Sous Windows, « nslookup -type=ns example.com » donne la même chose sans rien installer. Pour voir la délégation publiée par le registre plutôt que la zone, « dig +trace NS example.com » refait tout le chemin depuis la racine.
Peut-on changer de serveurs de noms sans coupure ?
Oui, à condition de recréer la zone complète chez le nouveau fournisseur avant de toucher à la délégation, d'abaisser la durée de vie plusieurs jours à l'avance, et de retirer l'empreinte DNSSEC si le domaine est signé. La coupure ne vient jamais du changement lui-même : elle vient d'un enregistrement oublié dans la nouvelle zone, presque toujours un MX.
Une migration d'hébergeur, heure par heure
Le scénario ci-dessous n'a rien d'exceptionnel : chaque étape est le comportement normal du système, et aucune n'est une panne. Ce qui fait perdre la journée, c'est que les symptômes n'arrivent jamais dans l'ordre des causes.
09 h 00
Les nouveaux serveurs de noms sont saisis chez le registrar
Ce qu'on voitL'interface confirme la modification. Le site répond, le courrier arrive, tout va bien.
Ce qui se passeRien n'a bougé pour personne. Le registre a enregistré la nouvelle délégation, mais chaque résolveur du monde conserve l'ancienne réponse jusqu'à l'expiration du délai qu'elle annonçait — pour une délégation, souvent un à deux jours.
09 h 40
Le site s'affiche en nouvelle version depuis le bureau
Ce qu'on voitOn rafraîchit, la nouvelle page apparaît. La migration est annoncée comme faite.
Ce qui se passeLe résolveur du bureau avait simplement oublié l'ancienne réponse avant les autres. Un collègue sur un autre réseau voit encore l'ancien site, et il le verra peut-être encore demain. Un seul poste ne prouve jamais rien.
11 h 15
Un client répond à un devis, le message n'arrive jamais
Ce qu'on voitAucun avis d'échec, aucune alerte. La boîte est simplement vide, et on met l'après-midi à s'en apercevoir.
Ce qui se passeLes MX n'ont pas été recréés dans la nouvelle zone. Les résolveurs déjà passés au nouveau fournisseur ne trouvent plus de serveur de courrier ; celui de l'expéditeur met le message en file d'attente et se tait. Le silence dure bien plus longtemps que la panne.
14 h 00
Les MX sont recréés en urgence
Ce qu'on voitLe courrier recommence à arriver, souvent par paquets, dans l'heure qui suit.
Ce qui se passePresque rien n'est perdu : un serveur qui n'arrive pas à remettre un message réessaie pendant des jours avant d'abandonner, et la norme lui recommande d'attendre au moins quatre à cinq jours. Ce qui est perdu, c'est la demi-journée pendant laquelle personne n'a reçu de réponse.
Jour 2, 10 h 00
Une partie des visiteurs voit toujours l'ancien site
Ce qu'on voitLe site est en ligne, la zone est juste, et des captures d'écran de l'ancienne version continuent d'arriver.
Ce qui se passeLes serveurs de l'ancien fournisseur sont restés dans la délégation à côté des nouveaux. Les deux répondent, chaque résolveur en choisit un, et son choix tient jusqu'à l'expiration de sa mémoire. Le site répond en deux versions selon l'opérateur du visiteur.
Jour 3
Chez certains, le domaine n'existe plus du tout
Ce qu'on voitNi l'ancien site, ni le nouveau : une erreur de résolution, et seulement pour une partie des gens.
Ce qui se passeLe domaine était signé. L'empreinte de l'ancienne clé est restée publiée chez le registre, et les résolveurs qui vérifient les signatures refusent désormais toute réponse plutôt que d'en servir une qu'ils ne peuvent pas authentifier. Les autres ne voient rien d'anormal — c'est la panne dont on dit qu'elle « ne touche que certaines personnes ».
Aucune de ces six étapes n'est un dysfonctionnement : le DNS fait exactement ce qu'on lui a demandé. Seul l'ordre des gestes change le résultat, et il tient en neuf lignes.
Le délai avant qu'un serveur abandonne la remise d'un message en attente est celui que recommande la RFC 5321, § 4.5.4.1. Les noms employés sont ceux que la RFC 2606 réserve à la documentation.
Changer de serveurs de noms sans couper le courrier
Neuf gestes, trois temps. La moitié du travail se fait avant d'avoir touché à la délégation, et c'est cette moitié-là qu'on saute.
Plusieurs jours avant
Exporter la zone en entier
Chez le fournisseur actuel, récupérer la liste complète : adresses, MX, TXT, alias, sous-domaines oubliés. Ce sont toujours les lignes dont personne ne se souvenait qui cassent.
Abaisser la durée de vie
La ramener à quelques minutes dans l'ancienne zone. Il faut s'y prendre au moins une durée de vie complète à l'avance, sinon l'abaissement lui-même met deux jours à être connu.
Regarder si le domaine est signé
S'il porte une empreinte DNSSEC chez son registre, la retirer et attendre qu'elle ait disparu. Ce point ne se rattrape pas après coup : le domaine devient invisible pour une partie d'internet, et pas pour vous.
Le jour de la bascule
Recréer la zone avant de déléguer
Tout remettre chez le nouveau fournisseur, MX et TXT compris, pendant que personne ne l'interroge encore.
Interroger les nouveaux serveurs directement
Leur poser la question sans passer par la délégation. S'ils répondent déjà la bonne zone, la bascule ne fera que rediriger le trafic vers quelque chose de juste.
Remplacer la délégation, pas la compléter
Retirer les anciens serveurs au moment même où l'on ajoute les nouveaux. Une délégation mixte fait répondre deux zones différentes, au hasard du résolveur.
Les jours suivants
Comparer les deux sources jusqu'à ce qu'elles coïncident
Le registre et la zone doivent annoncer la même liste. Tant que l'outil en haut de cette page affiche un écart, la migration n'est pas terminée.
Remonter la durée de vie
Une fois tout stable, la ramener à sa valeur habituelle : une durée courte laissée en place multiplie les requêtes sans rien apporter.
Ne fermer l'ancien hébergement qu'après
Tant qu'il répond, une erreur reste rattrapable en une minute.
Les quatre gestes qui ne changent rien
Vider le cache du navigateur
Il garde bien quelques minutes de réponses DNS, mais celle qui vous bloque est dans le résolveur de votre opérateur, hors de votre portée.
Demander à l'hébergeur de « forcer la propagation »
Personne ne peut vider la mémoire des résolveurs du monde entier. Seul le délai annoncé avant le changement décide de la durée.
Recharger la page toute la journée depuis le même poste
Votre résolveur a déjà choisi sa réponse et s'y tiendra. Un contrôle qui interroge plusieurs résolveurs dit quelque chose ; votre navigateur, non.
Laisser l'ancien serveur « au cas où »
C'est exactement ce qui produit un site répondant en deux versions selon le visiteur.
Poser les mêmes questions soi-même, en ligne de commande
L'outil en haut de page fait ces requêtes pour vous et compare les deux sources. Si vous préférez les poser vous-même, ou vérifier depuis le réseau d'un client, voici exactement quoi taper.
macOS, Linux
dig NS example.com +shortCe que la zone annonce
À lire : la liste des serveurs de noms telle que le fournisseur DNS actuel la publie. C'est la moitié gauche de la comparaison, celle qui change dès que la nouvelle zone est en place.
macOS, Linux
dig +trace NS example.comCe que le registre a délégué
À lire : la requête repart de la racine et suit le chemin complet. Le bloc qui précède la réponse finale est celui des serveurs de l'extension : c'est la délégation officielle, celle qui doit coïncider avec la précédente. Certains réseaux d'entreprise bloquent ce mode, auquel cas la commande s'arrête à la première ligne.
Windows
nslookup -type=ns example.comLa même question, sans rien installer
À lire : nslookup est présent d'origine sur Windows. Il interroge le résolveur de votre réseau : il montre donc ce que voit votre poste, pas nécessairement ce que voit le reste du monde.
macOS, Linux
dig SOA example.com +shortSavoir si la zone a réellement changé
À lire : le troisième élément de la réponse est le numéro de série de la zone : il augmente à chaque modification publiée. S'il n'a pas bougé après votre saisie, elle n'est pas partie. Le dernier nombre est la durée pendant laquelle une réponse « ce nom n'existe pas » reste en mémoire.
macOS, Linux, Windows
whois example.comLa délégation vue du registre, en texte
À lire : les lignes « Name Server » viennent du registre de l'extension, pas de la zone. Toutes les extensions ne publient pas la même chose, et plusieurs registres limitent le nombre de requêtes par jour et par adresse.
dig est installé d'origine sur macOS et fourni par les paquets bind-utils ou dnsutils sous Linux ; sous Windows, nslookup remplit le même rôle. Les noms employés ici sont ceux que la RFC 2606 réserve à la documentation : remplacez-les par le vôtre.
Ce que ce contrôle ne peut pas voir
Il interroge le DNS depuis un seul endroit du monde, à un seul instant. Connaître ses angles morts évite d'en tirer une conclusion qu'il ne permet pas.
Il regarde depuis un seul réseau
La liste affichée est celle obtenue depuis nos serveurs, maintenant. Un résolveur situé ailleurs peut encore servir une réponse plus ancienne pendant toute la durée de vie annoncée. Un écart entre cette page et ce que vous voyez chez vous n'est donc pas une contradiction : c'est l'état normal d'un changement en cours.
Il ne vérifie pas les signatures
Le contrôle ne dit pas si le domaine est protégé par DNSSEC, ni si l'empreinte publiée chez son registre correspond encore à sa clé. C'est pourtant la cause de la panne la plus déroutante après un changement de fournisseur, celle qui ne touche qu'une partie des visiteurs.
Il ne voit pas le « glue »
Quand les serveurs de noms portent un nom situé dans le domaine qu'ils servent, leur adresse est publiée par le registre et non par la zone. Un résolveur ordinaire ne peut pas la lire : la page signale la situation, elle ne peut pas en vérifier le contenu.
Il n'éprouve pas toute la liste
La résolution de chaque serveur cité est vérifiée pour les quatre premiers. Sur une délégation qui en compte six, les derniers sont affichés sans être mis à l'épreuve.
Il ne dit rien du contenu de la zone
Savoir qui fait autorité ne dit pas si la zone est complète. Une nouvelle délégation peut être parfaitement correcte et pointer vers une zone vide : c'est exactement le scénario de 11 h 15 plus haut.
Il ne remonte pas le temps
Aucun historique : la page donne l'état de l'instant. Pour savoir qu'une délégation a changé pendant la nuit, il faut la regarder tous les jours — c'est le travail d'une surveillance, pas d'un contrôle ponctuel.
Ces limites tiennent à la nature d'un résolveur récursif, décrite par la RFC 1034 : il ne voit que ce que les serveurs interrogés veulent bien lui rendre, et jamais ce que le registre publie à côté de la délégation.
Le vocabulaire
Huit mots pour comprendre qui répond quoi
Ce sont les termes de l'interface de votre registrar, de la réponse de dig, et du tableau ci-dessus.
délégation- La liste officielle des serveurs de noms d'un domaine, tenue par le registre de l'extension.
faisant autorité- Un serveur qui détient la zone elle-même et répond sans passer par aucun cache.
zone- Le contenu du domaine : adresses,
MX,TXT, alias, et la liste des serveurs telle que la zone la publie. glue- L'adresse d'un serveur de noms dont le nom est situé dans le domaine qu'il sert. Sans elle, la résolution tourne en rond.
registre- L'organisme de l'extension (.fr, .com). Il détient la délégation et l'empreinte
DNSSEC, rien d'autre. registrar- L'intermédiaire par lequel vous demandez au registre de modifier la délégation. Techniquement, il ne détient rien.
résolveur récursif- Le serveur qui interroge les autres pour votre machine et garde leurs réponses le temps annoncé.
SERVFAIL- Le serveur n'a pas pu produire de réponse. Sur un domaine signé, le premier suspect est une signature
DNSSECqui ne correspond plus.
Le registrar n'héberge rien. Il transmet.