Que faire si le site ne s'ouvre plus après le changement de DNS
Que faire si le site ne s'ouvre plus après le changement de DNS
Le changement de DNS est une chose sournoise. Le site semble déjà être traduit, mais dans le navigateur, c'est vide, une erreur ou une ancienne adresse. Et ensuite, la panique commence : l'hébergement est blâmé en premier, puis le registraire, puis soi-même.
Il ne s'agit pas de bruit, mais de vérification étape par étape. Souvent, le problème réside dans un enregistrement, un NS ou dans le cache du fournisseur, et non dans le site lui-même. Si vous devez comprendre que faire si le site ne s'ouvre plus après un changement de DNS, commencez par le fait : qu'est-ce qui a été changé et à quel moment cela a été fait.
Vérifier si le problème est vraiment lié au DNS
D'abord, séparez l'effet DNS de tout le reste. Si le site s'ouvrait avant le changement de DNS et a cessé de fonctionner après 5 minutes, ce n'est pas encore une preuve. La coïncidence temporelle est trompeuse.
Regardez comment le site se comporte avec différents symptômes : ne s'ouvre pas du tout, redirige vers un autre domaine, affiche une erreur SSL ou tourne simplement en chargement. Ce sont déjà 4 scénarios différents, et chacun a sa propre source. Parfois, le problème ressemble à un DNS, alors qu'en réalité, la redirection vers https est cassée ou le certificat a expiré.
Il existe un test simple : essayez d'ouvrir le site par son IP direct, si vous le connaissez, ou par un autre canal de communication où l'ancienne adresse est déjà enregistrée. Si le serveur répond par IP, mais pas par domaine, le DNS est effectivement sur la liste des suspects. S'il ne répond à rien, alors ce n'est plus une question de DNS, mais de serveur, d'hôte virtuel ou de la plateforme elle-même.
Vérifiez également les facteurs externes. Par exemple, si le site a récemment changé de SSL ou de redirections, le navigateur peut afficher une erreur complètement différente de celle que vous attendez. Il est utile de se concentrer non pas sur des suppositions, mais sur le message exact. Un texte d'erreur peut parfois faire économiser 30 minutes de recherches inutiles.
Faire correspondre le nouveau DNS avec ce qui doit s'ouvrir
Après avoir changé les DNS, ouvrez la liste des enregistrements et comparez-la avec ce qui doit réellement être ouvert. Pour la racine du domaine, on vérifie généralement l'enregistrement A, pour l'IPv6 — AAAA, pour le sous-domaine, un CNAME est souvent nécessaire. Une erreur d'une lettre transforme un site normal en impasse.
Il faut regarder non seulement le domaine lui-même, mais aussi le sous-domaine. Par exemple, www peut pointer vers un hôte, tandis que sans www — vers un autre. Et si l'un des points pointe vers un ancien serveur, les utilisateurs verront des résultats différents selon la façon dont ils saisissent l'adresse.
Cela aide bien à la vérification avec le plan de migration. Si vous avez transféré le site, le nouveau DNS doit pointer vers l'adresse où le site est déjà en ligne, et non vers une plateforme de test vide. L'erreur ici est souvent simple : l'enregistrement a été créé, mais la cible est restée ancienne.
Si vous devez vérifier la liaison plus en profondeur, comparez les valeurs actuelles avec ce qui devrait être selon la tâche. Trois choses sont importantes ici : le nom de l'enregistrement, le type d'enregistrement et l'adresse de destination. Un symbole en trop dans le CNAME ou un IP d'un réseau étranger — et le site cesse de s'ouvrir uniquement pour une partie des requêtes.
Vérifiez si le passage à un nouveau fournisseur DNS est cassé
Lorsque le domaine est transféré à un nouveau fournisseur DNS, il faut s'assurer que la délégation a été entièrement effectuée. Le domaine doit avoir les bons NS, et la zone doit être réellement gérée par le nouveau serveur. Sinon, tout semble beau dans le panneau, mais sur Internet, l'ancienne configuration est toujours active.
Vérifiez si les NS du registraire correspondent à ce que vous avez inscrit chez le nouveau fournisseur. S'il reste une ancienne adresse, le domaine peut se comporter de manière imprévisible. Cela est particulièrement visible lorsque l'enregistrement a été modifié la nuit, et que le matin le site est déjà « parfois accessible, parfois non ».
Une autre piège fréquent est que la zone est créée, mais inactive. Un nouveau fournisseur DNS peut accepter le domaine dans le panneau, mais ne pas servir les enregistrements. Dans ce cas, vous voyez les paramètres, mais le monde extérieur ne les voit pas. Pas agréable, n'est-ce pas ?
Une bonne façon de vérifier est de regarder la réponse à la requête NS provenant de plusieurs sources. Si une partie des réponses va vers l'ancien fournisseur, la transition n'est pas terminée. Et ici, il ne s'agit pas d'une seule capture d'écran, mais de 2 à 3 vérifications indépendantes.
Prendre en compte le retard de mise à jour dans le monde et chez les utilisateurs
Après le changement de DNS, certaines personnes verront la nouvelle adresse, tandis que d'autres verront l'ancienne. C'est normal. Le fournisseur, le routeur et l'appareil ont un cache, et il ne se réinitialise pas à votre demande.
Le retard de mise à jour dans le monde peut varier, donc ne tirez pas de conclusions à partir d'un seul téléphone ou d'un seul bureau. Vérifiez le site via Internet domestique, réseau mobile et au moins un outil externe. Lorsque différents points montrent des résultats différents, c'est presque toujours un effet de cache, et non un problème du site.
Si le domaine a récemment fonctionné avec d'anciennes configurations, certains résolveurs s'en souviendront encore. Dans ce cas, un utilisateur voit le nouveau serveur, un autre voit l'ancien, et un troisième reçoit une erreur en raison d'incohérences dans les enregistrements. Ce comportement est particulièrement visible lors du changement d'enregistrement A vers un autre hôte.
Ici, une simple discipline aide : ne changez pas le DNS d'un côté à l'autre 5 fois de suite. Chaque nouvelle modification perturbe davantage le tableau, et ensuite personne ne comprend quelle entrée est la dernière. Mieux vaut fixer un changement et attendre que de naviguer entre trois options.
Vérifier le conflit entre IPv4 et IPv6
Parfois, l'enregistrement A est déjà correct, tandis que AAAA pointe vers nulle part. Pour certains appareils, ce n'est pas un détail, mais un véritable signal d'arrêt. Les navigateurs modernes et les réseaux aiment IPv6, et s'il est cassé, le site peut sembler inaccessible même avec un IPv4 fonctionnel.
Vérifiez les deux enregistrements séparément. Si le domaine doit fonctionner uniquement sur IPv4, il vaut mieux ne pas laisser AAAA par accident. Une adresse IPv6 vide ou ancienne crée souvent une image étrange : le site s'ouvre sur un Internet, mais pas sur un autre.
Il arrive que ce soit l'inverse. L'IPv6 est déjà activé, mais l'enregistrement A pointe vers l'ancien serveur. Dans ce cas, certains utilisateurs se connectent sans problème, tandis que d'autres rencontrent un timeout. Extérieurement, cela ressemble à un chaos, mais la raison est généralement la même : deux enregistrements regardent dans des directions différentes.
Si vous avez accès aux paramètres DNS, comparez les deux adresses avec l'adresse de l'espace de travail. Il n'est pas nécessaire de deviner ici. Deux chiffres sont nécessaires : IPv4 et IPv6. Et les deux doivent mener là où le site répond réellement.
S'assurer que le site répond à l'adresse de destination
Même un DNS parfait ne sauvera pas si le serveur de l'autre côté reste silencieux. Après avoir changé l'enregistrement, il faut vérifier si l'hôte est vivant, si le serveur web est en ligne et si le lien avec le bon domaine n'est pas perdu. Parfois, le site reste immobile, mais l'hôte virtuel est configuré avec un ancien nom.
S'il y a plusieurs sites sur le serveur, le bon hôte virtuel résout tout. La même IP peut servir 10 domaines, et sans un lien précis, le serveur renverra le mauvais projet ou une erreur. Cela est particulièrement visible après le transfert vers une nouvelle plateforme, lorsque la configuration semble avoir été copiée, mais que le nom de domaine a été oublié.
Vérifiez également la réponse du serveur : 200, 301, 302, 404 ou 500. Ces codes en disent plus que n'importe quel chat avec le support. Si l'adresse de destination renvoie un 404, cela signifie que le DNS a déjà atteint, mais que le site sur l'hôte ne correspond pas aux attentes.
Parfois, il est utile d'ouvrir non pas la page d'accueil, mais un chemin spécifique, par exemple /login ou /admin. Cela permet de voir si le site fonctionne dans son ensemble ou seulement la page d'accueil. Lorsqu'il s'agit de migration, une petite vérification est préférable à une grande assurance « ça semble s'ouvrir ».
À propos, si vous avez besoin d'une pause divertissante entre les vérifications, vous pouvez jeter un œil blagues sur les étudiants. Blagues gratuites. Courtes — cela prend 1 à 2 minutes, pas plus. Parfois, une telle pause aide à ne pas confondre l'ancien serveur avec le nouveau.
Vérifiez HTTPS et le certificat après le changement d'enregistrement
Le DNS peut déjà pointer vers le bon hôte, mais le navigateur se plaint toujours de HTTPS. Dans ce cas, le problème vient du certificat, de HSTS ou de la redirection. C'est une histoire très courante après un transfert vers une nouvelle IP.
Vérifiez si le certificat a été émis pour ce domaine et sous-domaine. Si la nouvelle adresse mène à un serveur où le certificat est délivré à un autre nom, le navigateur ne laissera pas l'utilisateur aller plus loin. Ni le cache ni le redémarrage ne seront utiles ici.
HSTS ajoute de la rigidité. Si le site fonctionnait auparavant en HTTPS et qu'une règle est ancrée dans le navigateur, essayer de l'ouvrir avec une ancienne configuration ou une configuration incorrecte entraînera un blocage immédiat. Ce n'est pas un bug du navigateur, mais sa mémoire, et elle persiste plus longtemps que souhaité.
Encore un petit détail : la redirection de http vers https. Si elle pointe vers un ancien domaine, le nouveau DNS semble correct, mais le site ne va toujours pas là où il faut. Vérifiez l'adresse finale après la redirection, et pas seulement le point de départ.
Si après toutes les étapes, il est encore flou de savoir si le site est accessible par d'autres, il est judicieux de vérifier la question avec le matériel comment vérifier un site pour fraude. Parfois, les gens prennent une erreur de certificat pour une tentative de substitution, alors qu'il ne s'agit que d'un décalage entre les enregistrements et le domaine.
Préparer ce qu'il faut transmettre au support d'hébergement ou DNS
Lorsque vos vérifications sont terminées, rassemblez un court paquet pour le support. Vous avez besoin du domaine, des nouveaux NS, de l'heure exacte du changement, d'une capture d'écran de l'erreur et d'une liste de ce qui a déjà été vérifié. Ce sont 5 points, et ils font gagner plus de temps qu'un long e-mail « rien ne fonctionne chez nous ».
N'oubliez pas d'indiquer de quel appareil et de quel réseau le problème est visible. Pour le support, ce n'est pas une formalité, mais un détail utile : un même domaine peut s'ouvrir depuis un réseau mobile et échouer depuis un réseau domestique. Il est également utile de joindre les enregistrements A, AAAA et CNAME actuels, s'ils ont changé.
Si vous avez changé de fournisseur DNS, indiquez qui avait le domaine auparavant et qui l'a maintenant. Parfois, l'aide dépend du fait que la zone soit déjà déléguée, mais que l'ancien serveur continue de répondre dans certaines résolutions. Plus vous décrivez précisément le parcours, moins il y aura de cercles dans la réponse.
Il est de bon ton de fournir immédiatement le résultat de la vérification provenant de 2 à 3 sources, et non d'une seule capture d'écran du navigateur. Il est plus facile pour le support de voir où se situe le problème : dans la zone, chez le registraire ou sur le serveur. Moins il y a de suppositions, plus il est rapide de trouver le goulet d'étranglement.
Si vous souhaitez un peu décharger votre esprit après la routine technique, vous pouvez vous distraire avec les expériences les plus cruelles des psychologues — le sujet n'est pas simple, mais il aide à dissiper l'impression qu'un seul DNS cassé maintient le monde en place. Ensuite, revenez aux journaux et aux enregistrements NS.
Que vérifier d'autre si le problème persiste
Si le site ne s'ouvre que pour une partie des utilisateurs, ne regardez pas un seul facteur, mais une combinaison de 3 éléments : DNS, cache et serveur. Lorsque les trois sont en désaccord, les symptômes changent chaque heure. C'est justement le cas où un même domaine se comporte différemment le matin et le soir.
Parfois, il est utile de vérifier via un service externe de résolution et de faire un test séparé dans le navigateur sans données enregistrées. Pas parce que c'est de la magie, mais parce que vous séparez l'image locale de l'image globale. Si ça ne va pas localement, mais que ça va à l'extérieur, le problème est plus proche de l'appareil ou du fournisseur.
Si après le transfert vous avez également modifié la structure du site, n'oubliez pas les anciens liens. L'utilisateur peut atterrir sur une page inexistante et conclure que le domaine est complètement cassé. En pratique, seul 1 chemin sur 20 se casse.
Et oui, parfois il est utile de voir le problème comme une chaîne. Le DNS mène au serveur, le serveur renvoie le site, le certificat confirme le domaine, et le navigateur décide d'accepter l'utilisateur ou non. Si l'un des 4 éléments est manquant, le site ne s'ouvre plus comme il se doit.
Lorsque tout est vérifié et que l'accès saute toujours, notez les 2 dernières modifications et ne faites pas de nouvelles jusqu'à la réponse du support. Sinon, vous vous empêchez de voir où la chaîne s'est interrompue.
