Dépanner un domaine qui ne se résout pas : transmettre les preuves avant toute modification

Préparez une fiche vierge avant les conclusions

Commencez par un nom d’hôte et une question, pas par tous les services du domaine. Un message de navigateur n’est pas à lui seul une trace de réponse DNS. Si des preuves obtenues dans un cadre autorisé existent, conservez leur contexte ; sinon, demandez-les à l’opérateur responsable. N’ajoutez pas identifiants secrets, données privées de compte ou informations réseau étrangères au dossier partagé.

Cinq lignes de preuves ne sont pas cinq causes présumées

Utilisez « consigné », « en attente » et « non vérifié » comme états des preuves. Consigné signifie qu’une trace existe pour la question indiquée, pas que son interprétation est juste ou que le domaine fonctionne. Une réponse attendue n’est pas un résultat négatif. Réutilisez la fiche pour chaque trace avec son heure et son périmètre.

Transmission vierge : lignes consignées ____ ; en attente ____ ; non vérifiées ____ ; interprétation ouverte ____ ; traces ____ ; prochaine vérification demandée et responsable habilité ____ ; modifications réalisées ____. Gardez le champ vide visible plutôt que d’y inscrire un résultat supposé.

Ne confondez pas les restrictions d’enregistrement

ICANN distingue inactive, sans serveurs de noms associés et sans activité DNS du domaine, de serverHold imposé par le registre et clientHold par le registraire, qui empêchent l’activation DNS. clientTransferProhibited limite, lui, le transfert. Une mention générique « verrouillé » n’explique donc pas à elle seule une panne DNS. Notez code et source exacts ; ne transformez pas toute restriction en hold DNS et ne supposez pas le droit de la retirer.[3]

Le guide de domaine Google présente NXDOMAIN pour un domaine enregistré comme motif de vérifier enregistrement, expiration et holds possibles. Il ne prouve pas que tout NXDOMAIN signifie expiration ou nom disponible. Adressez la question de compte au responsable habilité ou au registraire : le guide public ne prouve ni propriété, ni état réel du compte, ni droit à une modification.[1]

Lisez ensemble question, réponse et renvoi

La RFC 2308, publiée en mars 1998, distingue Name Error/NXDOMAIN de NODATA. NODATA est un pseudo-code déduit de la réponse pour un nom valide dans la QCLASS donnée sans enregistrement du QTYPE demandé. Une chaîne CNAME peut changer le nom finalement résolu. Une réponse vide avec NOERROR n’est pas automatiquement NODATA : réponse, SOA/NS de la section autorité et contexte de renvoi comptent. Consignez-les avant de diagnostiquer le vide. Il s’agit des sections 1 et 2, pas de toutes les implémentations actuelles.[4]

Distinguez NXDOMAIN, SERVFAIL et absence de réponse. Le guide Google traite des vérifications conditionnelles pour ces issues différentes. Une erreur DNS étendue, si fournie, peut ajouter un indice, sans garantie de présence, de texte ou de présentation identique selon le client. Conservez message original et identité du collecteur plutôt que de transformer un indice en cause confirmée.[1]

Orientez délégation et validation sans réduire la sécurité

Google décrit renvois parents, noms des serveurs et glue comme pistes conditionnelles d’investigation de délégation. Un écart ou une trace manquante exige l’interprétation de l’opérateur concerné. Séparez information parente et réponse autoritative ; un résultat de résolveur ne documente intégralement ni l’une ni l’autre. Demandez la question et la source manquantes, pas une modification non approuvée des serveurs de noms.[1]

Le guide évoque aussi des indices de validation DNSSEC, dont des informations DS anciennes après changement de fournisseur. Historique et preuves de validation sont donc pertinents, sans établir la cause du cas. Transmettez ces questions à l’opérateur DNSSEC/domaine habilité. La fiche ne fournit ni procédure ni autorisation pour désactiver la validation, retirer des DS, contourner un échec ou affaiblir la sécurité.[1]

Comparez des observations équivalentes, pas des captures isolées

Le guide Google utilise les comparaisons entre résolveurs récursifs et réponses autoritatives comme éléments conditionnels. Faites correspondre nom d’hôte, contexte CNAME, QTYPE et QCLASS, puis gardez heures, contexte réseau/résolveur et traces complètes. Des résultats différents ouvrent une comparaison à examiner ; ils ne désignent pas seuls la couche fautive. La ligne autoritative non vérifiée le reste même si deux réponses récursives concordent.[1]

La page générale Google évoque des séries SOA différentes et des données autoritatives anciennes après changement de serveurs comme possibilités. Sa mise à jour affichée est le 3 septembre 2024, distincte de la consultation du 14 octobre 2026. N’en faites pas un délai universel de propagation, une recette de purge de cache ou une promesse que l’attente réparera le domaine. Consignez preuve concrète et prochain responsable.[2]

Meadow Lantern Day fictif : trois traces ne ferment pas cinq lignes

Tout est inventé : Meadow Lantern Day, domaine symbolique C, hôte web, statuts, traces et personnes. La scène est datée du 15 octobre 2026 à 09:00, UTC−06:00 : un moment fictif futur par rapport à ce brouillon du 14 octobre, pas une observation réelle. Aucune requête, ouverture de compte ou modification n’a eu lieu. P1 et P2 portent sur le même hôte fictif, QTYPE A et QCLASS IN ; aucun CNAME n’est consigné.

Le registre compte 3 consignés + 1 en attente + 1 non vérifié = 5 lignes. L’accord de P1 et P2 ne remplit ni D ni A. clientHold motive la transmission de la question d’enregistrement, pas chaque étape causale ni un remède garanti. Expiration, disponibilité du domaine et droit de retirer le hold ne sont pas établis.

Transmettez la question ouverte, pas une réussite

La transmission fictive confie l’interprétation du statut au responsable compte/registraire habilité ; la délégation parente reste non vérifiée et la trace autoritative en attente. Deux NXDOMAIN récursifs ne couvrent que la question A/IN indiquée. Demandez les preuves manquantes dans le cadre autorisé et convenez d’une revue. Modifications réalisées : aucune. C’est un exemple inventé, pas un message envoyé au fournisseur.

Dans votre cas réel, joignez fiche exacte, emplacements des traces, décompte des états, historique connu et prochain responsable. Séparez observation et interprétation, permission et possibilité technique. Arrêtez-vous avant diagnostic ou modification non étayés. La fiche remplie ne prouve pas la propriété, ne restaure pas la résolution et ne démontre le fonctionnement ni du site, ni du courriel, ni de TLS.