Le domaine de l’événement affiche une page de parking après un changement DNS : trouver la mauvaise liaison

Relever la page réellement vue par le public

Télécharger la fiche de réparation de page de parking (Markdown, en anglais)

Ouvrez l’URL exacte, avec www ou sous-domaine, sur téléphone et depuis un autre réseau. Notez heure, adresse finale, titre, marque du fournisseur et capture. Testez domaine racine et www séparément. Maintenez un lien approuvé vers l’événement ou les billets pendant l’examen.

La page peut provenir du registraire, du DNS ou de l’hébergeur. Une page « site prêt » peut aussi indiquer que le bon hébergeur répond mais pas le bon projet. La capture établit le symptôme, pas sa cause. Consignez la dernière modification approuvée et les responsables des comptes.

Identifier la zone DNS faisant autorité

Comparez les serveurs de noms du registraire à ceux de la zone prévue. S’ils diffèrent, les modifications de cette zone ne pilotent pas la réponse publique. En présence de zones homonymes, trouvez celle qui est déléguée avant toute édition. Changer les serveurs sans contrôler la zone complète peut perturber le courrier.[1]

Conservez la réponse autoritative du nom concerné. Une réponse en cache ne décrit pas tous les visiteurs. Après un changement récent, comparez plusieurs réseaux et horodatages avant d’invoquer un ancien cache.

Comparer la cible aux indications de l’hébergeur

Comparez la réponse DNS A, AAAA ou CNAME du nom concerné avec les instructions de l’hébergeur actuel. Si le fournisseur DNS configure un ALIAS ou un aplatissement dans son tableau de bord, contrôlez aussi ce réglage : ALIAS n’est pas un type de réponse DNS distinct. Type et cible dépendent du fournisseur et du nom; ne copiez pas une adresse IP générique. Repérez un ancien enregistrement de parking, un joker inattendu ou une cible de l’ancien hébergeur.[2][4][5]

Si la cible est correcte, le DNS n’est pas forcément en cause. Distinguez racine, www ou les deux. Faites approuver une seule correction étayée, avec valeur précédente et marche arrière. Ne touchez pas aux entrées de courrier ou de vérification sans rapport.

Vérifier l’affectation du domaine au site

Dans l’espace d’hébergement, vérifiez que le nom exact est associé au site public de l’événement et que la vérification demandée est terminée. Vercel et Netlify documentent cette association séparément des enregistrements DNS. Suivez les indications du fournisseur réellement utilisé.[2][3]

Vérifiez qu’il s’agit de la version publique, et non d’un brouillon ou d’une ancienne édition. Si un autre projet ou compte revendique le domaine, transmettez le conflit au responsable; ne forcez pas un transfert sans destination confirmée.

Recontrôler le parcours des participants

Après la correction approuvée, ouvrez l’URL HTTPS exacte dans un navigateur neuf et sur un autre réseau. Vérifiez séparément racine, www, page, date, lieu et lien billetterie. Si un réseau voit encore l’ancien écran, comparez sa réponse DNS et l’ancien TTL; modifier ce TTL maintenant ne réduit pas un cache déjà rempli.[1]

Notez nom touché, page erronée, cible DNS, affectation du site, responsable, heure et résultat. Retirez le lien provisoire seulement après vérification publique. Si l’événement figure sur Boletolibre.com, testez séparément sa page et son lien de billets.