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
» 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 avoir été transféré, mais dans le navigateur, c'est vide, une erreur ou l'ancienne adresse. Et ensuite, la panique commence : on blâme d'abord l'hébergement, 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 seul enregistrement, un seul 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 le changement de DNS, commencez par le fait : qu'avez-vous exactement changé et à quel moment.
Vérifiez si le problème est vraiment lié au DNS
D'abord, séparez l'effet DNS de tout le reste. Si avant le changement de DNS le site s'ouvrait, et qu'après 5 minutes il ne s'ouvre plus, ce n'est pas encore une preuve. La coïncidence temporelle est trompeuse.
Observez 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 problème de 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 l'IP directe, si vous la 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 un problème de DNS, mais de serveur, d'hébergement virtuel ou de la plateforme elle-même.
Associer le nouveau DNS avec ce qui doit être ouvert
Après avoir changé le 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 — l'enregistrement 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 manière dont ils saisissent l'adresse.
La vérification avec le plan de migration est très utile. Si vous avez migré 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 doit ê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 une IP d'un réseau étranger — et le site cesse de s'ouvrir uniquement pour certaines requêtes.
Vérifiez si la transition vers le nouveau fournisseur DNS n'est pas cassée
Lorsque le domaine est transféré vers un nouveau fournisseur DNS, il faut s'assurer que la délégation a été effectuée complètement. Le domaine doit avoir les bons NS, et la zone doit réellement être 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 chez le 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 « s'ouvre ou ne s'ouvre pas ».
Une autre piège courant 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 depuis 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 délai de mise à jour dans le monde et pour 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 délai 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 une trace de cache, et non une panne du site.
Si le domaine a récemment fonctionné avec d'anciens paramètres, certains résolveurs s'en souviendront encore. Alors un utilisateur voit le nouveau serveur, un autre l'ancien, et un troisième reçoit une erreur en raison d'un désaccord entre 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'avant en arrière 5 fois de suite. Chaque nouvelle modification perturbe davantage la situation, et ensuite personne ne comprend quel enregistrement est le dernier. Il vaut mieux fixer un changement et attendre, que de se précipiter entre trois options.
Vérifier le conflit entre IPv4 et IPv6
Parfois, l'enregistrement A est déjà correct, tandis que l'enregistrement AAAA ne pointe 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 accidentellement un enregistrement AAAA. Une adresse IPv6 vide ou ancienne crée souvent une situation étrange : le site s'ouvre depuis un internet, mais pas depuis un autre.
Il arrive que ce soit l'inverse. IPv6 est déjà activé, mais l'enregistrement A pointe vers un ancien serveur. Dans ce cas, certains utilisateurs accèdent sans problème, tandis que d'autres rencontrent un timeout. Extérieurement, cela ressemble à du chaos, mais la raison est généralement la même : les 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. Ici, il n'est pas nécessaire de deviner. Deux chiffres sont nécessaires : IPv4 et IPv6. Et les deux doivent pointer vers l'endroit 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é est silencieux. Après avoir changé l'enregistrement, il faut vérifier si l'hôte est vivant, si le serveur web est actif et si l'association avec le bon domaine n'est pas perdue. Parfois, le site reste en place, 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. Une même IP peut servir 10 domaines, et sans une association précise, le serveur renverra le mauvais projet ou une erreur. Cela est particulièrement visible après un transfert vers un nouvel espace, 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 quelle discussion avec le support. Si une erreur 404 arrive à l'adresse de destination, cela signifie que le DNS a déjà atteint sa destination, 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, un petit contrôle est préférable à un grand « ça a l'air de fonctionner ».
À 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 continue de se plaindre à propos 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 la migration vers une nouvelle IP.
Vérifiez si le certificat a été émis précisément pour ce domaine et sous-domaine. Si la nouvelle adresse pointe vers un serveur où le certificat est délivré à un autre nom, le navigateur ne laissera pas l'utilisateur aller plus loin. Et ici, ni le cache ni le redémarrage ne seront utiles.
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 ou une mauvaise configuration entraînera immédiatement un blocage. Ce n'est pas un bug du navigateur, mais sa mémoire, et elle persiste plus longtemps que souhaité.
Une autre petite chose — 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 devrait. Vérifiez l'adresse finale après la redirection, et pas seulement le point de départ.
Si après toutes les étapes, il n'est toujours pas clair si le site s'ouvre pour les autres, il est utile de vérifier la question avec le matériel. comment vérifier un site pour fraudeParfois, les gens prennent une erreur de certificat pour une tentative de falsification, alors que c'est juste une incohérence entre les enregistrements et le domaine.
Préparez ce que vous devez transmettre au support d'hébergement ou DNS.
Lorsque vos vérifications sont terminées, rassemblez un court paquet pour le support. Vous aurez besoin du domaine, des nouveaux NS, du moment exact 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'une longue lettre « 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 : le même domaine peut s'ouvrir depuis un réseau mobile et tomber depuis un réseau domestique. Il est également utile de joindre les enregistrements A, AAAA et CNAME actuels, s'ils ont été modifiés.
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 a déjà été déléguée, mais l'ancien serveur répond encore dans certaines résolutions. Plus vous décrivez précisément le chemin, moins il y aura de tours dans la réponse.
Il est de bon ton de joindre immédiatement le résultat de la vérification de 2 à 3 sources, et non une seule capture d'écran du navigateur. Il est plus facile pour le support de voir où l'image diverge : dans la zone, chez le registraire ou sur le serveur. Et moins il y a de suppositions, plus vite ils trouvent 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 matériel n'est pas simple, mais il aide à dissiper la sensation qu'un seul DNS cassé maintient le monde en place. Ensuite, revenez aux logs et aux enregistrements NS.
Que vérifier d'autre si le problème est intermittent
Si le site s'ouvre seulement pour une partie des utilisateurs, ne regardez pas un seul facteur, mais une combinaison de 3 choses : DNS, cache et serveur. Quand 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 c'est mauvais localement, mais normal de l'extérieur, le problème est plus proche de l'appareil ou du fournisseur.
Si après le transfert vous avez également changé la structure du site, n'oubliez pas les anciens liens. L'utilisateur peut tomber sur une page inexistante et décider 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 délivre le site, le certificat confirme le domaine, et le navigateur décide de laisser passer l'utilisateur ou non. Si l'un des 4 éléments est manquant, le site ne s'ouvre plus comme il se doit.
Quand tout a été vérifié, mais que l'accès saute toujours, notez les 2 dernières modifications et n'en faites pas de nouvelles jusqu'à la réponse du support. Sinon, vous vous empêchez de voir où la chaîne s'est rompue.
