Relever le nom qui échoue et garder deux témoins
Dans un réseau multisite WordPress autohébergé, le site principal peut fonctionner alors qu’un navigateur ne parvient pas à joindre un sous-site en sous-domaine. Prenez l’adresse exacte dans le lien Visiter de la fiche du site si elle est accessible. Notez le nom d’hôte seul, l’URL complète, le moment du défaut et le message affiché. Demandez si la panne se manifeste depuis un seul poste, depuis le réseau de l’organisation ou depuis plusieurs accès. Ces éléments permettent de comparer les résultats sans dépendre d’un raccourci de navigateur ou d’une adresse reconstruite de mémoire.
Dans cet exercice, le réseau de copie s’appelle reseau.test. Le site principal est accessible sur ce nom, atelier.reseau.test est le témoin fonctionnel, et archives.reseau.test représente le nom à examiner. Un quatrième nom fictif sert uniquement à demander si la zone de recette résout les noms nouveaux de ce niveau. Gardez les trois premières adresses dans votre relevé et interrogez-les dans la même session. Les noms en .test sont réservés à la recette. Utilisez le résolveur de votre environnement isolé pour les exercices DNS.
Une erreur de résolution se produit avant la demande HTTP. Une réponse 404, une redirection vers le site principal ou un écran indiquant que le sous-site est archivé signifie qu’un serveur a répondu. Notez alors le nom et le service qui ont réellement répondu. La réponse peut venir d’un proxy, d’un hébergeur ou de WordPress. Votre première décision porte sur l’étape atteinte, puis sur l’équipe capable de l’examiner.
Préparer la copie et les accès nécessaires
Travaillez sur une copie isolée ou un réseau multisite jetable avec des utilisateurs, pages et médias fictifs. Le serveur doit être accessible uniquement dans la recette. Utilisez une zone DNS de test ou un résolveur de laboratoire pour les noms fictifs. Une entrée dans le fichier hosts peut dépanner un exercice HTTP sur un poste précis. Pour examiner une règle générique, utilisez le résolveur prévu pour le test et évitez les entrées hosts pour les noms mesurés. Une entrée hosts est individuelle et ne démontre aucun fonctionnement DNS.
Identifiez les personnes autorisées à lire ou modifier la zone, la configuration du serveur Web et les fiches des sous-sites. Le super administrateur du réseau peut vérifier la fiche d’un site. Les changements de DNS et de serveur exigent leurs propres accès. Relevez les enregistrements et les réglages initiaux avant une correction et gardez la configuration de la copie hors de la racine Web. Lorsque plusieurs services utilisent le même domaine, relevez aussi les noms explicitement attribués à un autre service pour éviter de modifier leur destination.
Fixez le résultat attendu avant tout changement. Le nom doit se résoudre vers l’entrée Web attendue, la demande avec ce nom doit arriver à la bonne installation, puis WordPress doit servir le sous-site prévu ou appliquer son état volontaire. Choisissez une page ou un titre fictif propre à chaque site pour vérifier ce dernier point. Préservez les paramètres de départ pour pouvoir annuler seulement le changement effectué. Si vous ne disposez que du tableau de bord, préparez des observations et demandez les contrôles externes au mainteneur concerné.
Comparer la résolution des trois noms et interpréter la réponse
Interrogez le même résolveur pour le site principal, le témoin et le nom en panne. Demandez le type A pour IPv4 et, lorsque le service utilise IPv6, le type AAAA. Un alias CNAME peut être normal si sa cible et la chaîne de résolution aboutissent au service prévu. Comparez les destinations à la documentation du serveur ou du proxy. Dans un hébergement derrière un CDN, l’adresse attendue peut être celle du CDN. Plusieurs adresses peuvent aussi être normales si elles appartiennent au service configuré.
NXDOMAIN signifie que le nom demandé est déclaré inexistant par la réponse obtenue. NOERROR sans données du type demandé peut simplement signifier que le nom existe sans enregistrement de ce type. SERVFAIL, refus et délai dépassé restent des diagnostics distincts. Ils peuvent demander de vérifier l’accès au résolveur, la délégation ou la santé de la zone. Une réponse IPv4 correcte ne valide pas le chemin IPv6 si un AAAA erroné est aussi publié. Consignez le statut et les adresses séparément pour pouvoir comparer les deux familles.
La commande ci-dessous utilise PowerShell. Le résolveur 192.0.2.53 est fictif. Remplacez-le par le résolveur autorisé de la zone de test et remplacez les noms par vos témoins de recette. En cas de différence entre deux résolveurs, comparez au serveur autoritatif autorisé ou à la zone elle-même. Le TTL et le cache des réponses négatives peuvent expliquer pourquoi une correction n’est pas visible partout au même moment. Relevez l’heure et le résolveur au lieu d’annoncer un délai fixe.
$dns = "192.0.2.53"
foreach ($nom in "reseau.test", "atelier.reseau.test", "archives.reseau.test") {
Resolve-DnsName -Name $nom -Type A -Server $dns -DnsOnly -NoHostsFile
}Distinguer une entrée absente d’un wildcard absent ou mal dirigé
Comparez le sous-domaine en panne à un nom neuf du même niveau, par exemple sonde-libre.reseau.test. Confirmez d’abord dans votre zone de recette que ce nom n’a pas d’entrée explicite. Si le témoin atelier se résout, mais que le nom en panne et la sonde répondent NXDOMAIN, l’entrée du témoin peut être individuelle et aucune règle générique applicable ne répond à ces deux noms. Vérifiez la zone avant de conclure. La délégation d’un sous-ensemble, un nom déjà présent avec un autre type ou une erreur sur la zone consultée peuvent changer l’interprétation.
Si la sonde se résout vers la bonne entrée et que le nom en panne ne le fait pas, examinez les enregistrements explicites, la délégation et les réponses mises en cache pour ce nom. Une règle générique ne corrige pas une entrée explicite envoyée vers un autre service. La sonde sert à tester le comportement sur un nom libre à ce niveau. Elle ne prouve pas que tous les sous-domaines, ni des noms plus profonds, auront la même réponse. Relevez également la présence d’un enregistrement pour le domaine principal. La règle générique ne fournit pas cet enregistrement.
Choisissez ensuite une correction qui correspond au mode de création des sites. Si les sous-sites sont créés par l’équipe et que les noms sont connus, une entrée par sous-domaine peut suffire. Les créations à la demande nécessitent un routage générique adapté, selon la documentation WordPress. Vérifiez les effets sur les noms réservés à d’autres services avant de proposer un changement partagé. Sur la copie, comparez les réponses avant et après en gardant exactement les mêmes témoins.
Corriger le DNS de recette et vérifier que le changement reste ciblé
Pour un seul nom manquant dans un réseau à création manuelle, préparez l’enregistrement demandé par l’hébergeur pour ce nom dans la zone de recette. Selon le service, il peut s’agir d’une adresse ou d’un alias vers un nom fourni. Comparez d’abord le nom complet que produira l’interface de la zone. Certaines interfaces ajoutent automatiquement le suffixe de la zone. Gardez la destination précédente si une entrée existe, vérifiez le type et renseignez le TTL conformément au plan de l’équipe.
Pour la création à la demande, vérifiez qu’une entrée de type approprié est prévue pour le nom générique au bon niveau, par exemple *.reseau.test dans cet exercice. Prévoyez aussi la prise en charge des noms par le serveur Web et le certificat. Ajoutez l’entrée uniquement dans la zone isolée, puis interrogez un nom neuf et un nom explicite déjà utilisé. Le premier doit rejoindre l’entrée Web attendue. Le second doit conserver le comportement prévu. Consignez toute exception et vérifiez que le domaine principal continue de se résoudre.
Pour le retour arrière, restaurez la valeur précédente de l’entrée modifiée ou retirez l’entrée de recette ajoutée. Contrôlez d’abord l’état de la zone, puis refaites le relevé depuis le même résolveur. Une réponse ancienne peut subsister après l’annulation. Notez cette différence si le serveur de référence et le résolveur n’affichent pas la même chose. Cette procédure ne demande aucune modification des permaliens, de la base WordPress ou de la constante de type de réseau.
- Noter le nom, le type, la destination et le TTL avant de modifier la zone de recette.
- Vérifier le domaine principal, le témoin et le nom corrigé avec le même résolveur.
- Pour une règle générique, ajouter une sonde libre et une exception explicite au relevé.
Vérifier le serveur Web avec le nom prévu
Une résolution correcte permet de joindre une adresse. Pour savoir quel site répond, ouvrez l’URL avec son véritable nom d’hôte. Une requête vers l’IP seule peut atteindre l’hôte virtuel par défaut. Si la page présente le mauvais service, vérifiez avec le mainteneur le proxy, les noms acceptés, l’hôte virtuel et le dossier de l’installation WordPress. Comparez la page du témoin au titre fictif attendu et enregistrez le code HTTP ainsi que la destination des éventuelles redirections.
Sur la copie, il est possible d’imposer temporairement une adresse dans une seule requête curl. Dans l’exemple, 127.0.0.1 est l’adresse de la copie sur le poste. Le serveur écoute sur le port 8080. Le nom présenté à l’application reste atelier.reseau.test et la connexion rejoint directement la copie. Adaptez le port à votre serveur de recette. Cette observation sert à vérifier le chemin Web indépendamment du DNS. Lisez aussi le corps de la réponse, car un code 200 peut correspondre à une page générique.
Si la copie utilise HTTPS, vérifiez avec le nom d’hôte attendu que le certificat présenté le couvre et que sa chaîne est reconnue par votre poste. Pour un certificat générique, contrôlez sa portée exacte et la couverture du nom principal. Un échec TLS peut masquer la page du sous-site même lorsque la résolution est correcte. Conservez l’erreur et confiez la correction à la personne qui gère le certificat. Si la connexion HTTP arrive bien au réseau et que l’accueil ou les articles donnent une 404, poursuivez avec le guide WP-146 indiqué en fin d’article.
curl.exe --noproxy "*" --connect-to atelier.reseau.test:80:127.0.0.1:8080 -i http://atelier.reseau.test/Lire l’état du sous-site dans le bon réseau
En tant que super administrateur de la copie, ouvrez Mes sites, Administration du réseau, puis Sites. Retrouvez la fiche du sous-site et comparez l’identifiant, le domaine et le chemin au relevé initial. Vérifiez le réseau courant lorsque plusieurs installations partagent un serveur. Une fiche peut être absente alors que le DNS répond grâce à la règle générique. Inversement, une fiche active peut être présente alors que son nom n’est pas encore joignable. Le lien Visiter indique l’adresse enregistrée pour le site et doit être comparé à l’adresse réellement ouverte.
Un site archivé, marqué comme indésirable ou désactivé doit être traité avec le responsable qui connaît la décision. Gardez séparés les champs archived, spam et deleted dans le relevé. Le champ deleted peut signaler une désactivation logique dans WordPress. La suppression définitive est une autre opération. N’interprétez pas le champ public comme un test de résolution ou une garantie d’accès au contenu. Comparez la page attendue, le site exact et son état, puis obtenez la validation nécessaire avant toute réactivation.
Pour le mainteneur qui dispose déjà de WP-CLI, la commande suivante lit les fiches de la copie. Adaptez le chemin et l’adresse du réseau. Dans la sortie, une fiche avec l’adresse attendue et les trois indicateurs à zéro fournit un point de départ. Elle ne valide pas le chemin suivi par un navigateur. Si l’adresse est erronée, consignez l’identifiant avant de modifier une fiche sur la copie. Si le réseau vient de changer de modèle d’adressage, passez au parcours WP-150 avant de retoucher les sites un par un.
wp --path="D:/recette/wordpress" --url="http://reseau.test" site list --fields=blog_id,domain,path,archived,spam,deleted --format=tableRejouer trois cas sur une copie fictive
Premier cas. L’atelier répond et le DNS de recette ne connaît ni archives.reseau.test ni le nom de sonde. La fiche Archives peut pourtant exister. Avec une connexion HTTP imposée comme dans le test précédent, une page portant le repère Archives confirme que le serveur et WordPress peuvent servir ce site quand la demande leur parvient. Ajoutez une entrée individuelle dans la zone de recette puis confirmez qu’elle résout Archives et laisse la sonde absente. Vous avez ainsi isolé la résolution du sous-domaine en cause.
Deuxième cas. Une règle générique résout la sonde libre vers le point d’entrée attendu, mais aucune fiche WordPress ne correspond à ce nom. Relevez la réponse réellement obtenue, qui dépend de l’installation et de ses réglages. La résolution d’un nom libre ne crée aucune fiche. Dans ce même test, ajoutez une entrée explicite fictive vers un service différent et comparez son résultat à celui de la sonde. Vous pouvez alors distinguer la règle générique et l’exception enregistrée.
Troisième cas. Archives se résout et le serveur sert le réseau, mais la fiche Archives est archivée. Avec un navigateur déconnecté ou une requête HTTP sans session, relevez le message et comparez-le au résultat d’Atelier. L’état archivé est une décision WordPress, indépendante du DNS. Dans une copie jetable, vous pouvez rejouer la transition puis restituer l’état de départ. Consignez les réponses du DNS, le statut HTTP, l’identifiant du sous-site et l’état affiché. Les résultats sont interprétables même si l’hébergeur présente des pages d’erreur différentes.
- Préparer un témoin actif, un nom sans fiche et un sous-site fictif pouvant être archivé.
- Vérifier séparément la résolution, le serveur rejoint et la fiche WordPress.
- Rétablir la zone de test et l’état des fiches au point de départ.
Clore le diagnostic ou transmettre les observations
Reprenez les mêmes noms, depuis le même résolveur, avec et sans la correction si vous pouvez restaurer la copie sans affecter d’autres essais. Vérifiez l’accueil du site principal, le témoin fonctionnel et la page repère du sous-site concerné. Si vous avez modifié une règle générique, contrôlez aussi une exception explicite et un nom libre. Le résultat est acceptable lorsque chaque observation correspond à l’état décidé et que les témoins restent accessibles. Un état archivé attendu doit rester archivé.
Transmettez le relevé à l’équipe responsable en associant chaque observation à sa couche. Pour le DNS, donnez le nom, le type, le résolveur et le statut. Pour le serveur Web, transmettez le nom présenté, la destination attendue, le code HTTP et l’adresse finale. Pour WordPress, communiquez l’identifiant et l’état de la fiche par le canal prévu. Omettez les secrets, les captures du panneau de gestion et les adresses privées qui ne sont pas nécessaires à la décision.
Lorsque le nom répond correctement et que l’accueil ou les articles restent en erreur, suivez le guide des nouveaux sous-sites en 404. Si plusieurs adresses ont changé de forme au même moment, utilisez le plan de conversion et de retour du réseau. Dans chaque cas, gardez les observations du DNS pour éviter de revenir inutilement à la première étape et choisissez un nouveau témoin adapté à la panne qui reste.
