Evenementdomein toont na een DNS-wijziging een parkeerpagina: vind de verkeerde koppeling

Leg vast wat bezoekers echt zien

Download het reparatieblad voor parkeerpagina’s (Markdown, Engels)

Open de exacte URL, inclusief www of subdomein, op een telefoon en via een tweede netwerk. Noteer tijdstip, eind-URL na omleidingen, paginatitel, aanbieder en screenshot. Controleer hoofddomein en www apart. Houd een goedgekeurde evenement- of ticketlink beschikbaar tijdens het onderzoek.

De pagina kan van de registrar, DNS-dienst of host komen. Een scherm “site klaar” kan betekenen dat verkeer de juiste host maar niet het juiste project bereikt. Het screenshot bewijst het symptoom, niet de oorzaak. Noteer de laatste goedgekeurde wijziging en de eigenaar van elk account.

Bepaal welke DNS-zone gezaghebbend is

Vergelijk de nameservers bij de registrar met die van de bedoelde zone. Komen ze niet overeen, dan regelen wijzigingen in die zone het publieke antwoord niet. Zoek bij dubbele zones eerst de gedelegeerde zone. Nameservers aanpassen zonder de hele zone te controleren kan andere diensten, zoals e-mail, verstoren.[1]

Bewaar het autoritatieve antwoord voor de getroffen hostnaam. Eén cacheantwoord laat niet zien wat iedereen krijgt. Vergelijk na een recente wijziging verschillende netwerken met tijdstippen voordat je oude cache aanwijst.

Vergelijk het DNS-doel met de hostinginstructies

Vergelijk het zichtbare DNS-antwoord van type A, AAAA of CNAME met de domeininstructies van de huidige host. Gebruikt de DNS-provider ALIAS of flattening in het dashboard, controleer dan ook die instelling; ALIAS is geen afzonderlijk DNS-antwoordtype. Type en doel hangen af van provider en hostnaam. Kopieer geen algemeen IP-adres uit een handleiding. Zoek oude parkeerrecords, onverwachte wildcards en doelen van de vorige host.[2][4][5]

Komt het antwoord al overeen, dan is DNS niet vanzelf de enige oorzaak. Maak onderscheid tussen hoofddomein, www of beide. Laat één onderbouwde wijziging goedkeuren en bewaar vorige waarde en terugweg. Raak ongerelateerde mail- en verificatierecords niet aan.

Controleer de domeintoewijzing bij de host

Controleer in het hostingdashboard of precies deze hostnaam is gekoppeld aan de gepubliceerde evenementsite en of vereiste verificatie klaar is. Vercel en Netlify beschrijven die koppeling afzonderlijk van DNS-records. Volg de status en instructies van de werkelijk gebruikte aanbieder.[2][3]

Controleer of de publieke versie en niet een concept of oud evenement moet antwoorden. Bij een conflict met een ander project of account leg je het bericht voor aan de eigenaar; forceer geen overdracht zonder bevestigd doel.

Test de bezoekersroute opnieuw

Open na de goedgekeurde reparatie de exacte HTTPS-URL in een nieuwe browser en op een ander netwerk. Test hoofddomein, www, evenementpagina, datum, locatie en ticketlink afzonderlijk. Ziet één netwerk nog de oude pagina, vergelijk dan DNS-antwoord en eerdere TTL; een nieuwe TTL verkort een al opgeslagen antwoord niet.[1]

Leg hostnaam, verkeerde pagina, DNS-doel, sitetoewijzing, eigenaar, tijd en resultaat vast. Trek de tijdelijke route pas in na controle van de gepubliceerde pagina. Staat het evenement op Boletolibre.com, test dan de evenement- en ticketbestemming apart.