Event domain shows a parking page after a DNS change: find the wrong handoff

Capture the page that visitors actually receive

Download the parking-page repair worksheet (Markdown, English)

Open the exact public URL, including www or the event subdomain, on a phone and a second network. Note the time, final address after any redirect, page title, host or registrar branding, and a screenshot. Check the root and www names separately; one may work while the other displays a default page. Keep a known working event or ticket URL available in approved attendee communications while the branded domain is being investigated.

A parking page may come from a registrar, DNS service or hosting account. A generic “site ready” screen may mean traffic reached the intended host but the domain is not assigned to the intended site. The screenshot identifies the symptom, not its cause. Record the last approved domain, DNS or hosting change and the owner of each account.

Check which DNS zone is authoritative

Compare the registrar’s current nameservers with the nameservers of the DNS zone that the team meant to publish. If they differ, edits in the intended zone will not control the live answer. If there are duplicate zones, identify the delegated one before editing records. Ask the registrar or DNS owner to confirm the correct delegation; changing nameservers without a complete zone review can disturb other services such as mail.[1]

Record the delegated zone and its current answers for the exact affected hostname. Do not treat a cached answer from one resolver as proof of what every visitor receives. If delegation changed recently, compare an authoritative answer with observations from more than one network and note their timestamps before deciding whether an old cached answer remains.

Compare the live target with the host’s instructions

For each affected hostname, compare the live A, AAAA or CNAME answer with the current host’s domain instructions. If the DNS provider uses an ALIAS or flattened record in its dashboard, inspect that provider-side setting too; ALIAS is not a separate DNS response type. The valid type and target depend on the provider and hostname; do not replace a working record with a generic IP from a tutorial. Check for an old registrar parking record, unintended wildcard or previous-host target. Cloudflare documents unexpected records after wildcard imports.[2][4][5]

If the DNS answer already matches the expected target, stop treating DNS as the only suspect. Note whether the wrong page appears at both apex and www, or only one; that difference narrows the repair. Have the DNS owner approve a single documented correction, including the previous value and a rollback route. Avoid changing unrelated mail or verification records.

Confirm that the host recognizes this domain

In the hosting project or site dashboard, verify that the exact hostname is attached to the intended published event site and has completed the provider’s verification steps. Vercel and Netlify both document domain-to-project or domain-to-site assignment separately from entering DNS records. Use the actual provider’s status and instructions; a correct DNS target alone does not establish which site should answer.[2][3]

Check that the published site itself exists and that its assigned environment is the public one, rather than a draft or previous event. If the host reports a conflict with another project or account, hand that evidence to the host owner. Do not force a transfer or detach a live domain from another project without confirming ownership and the intended replacement.

Retest the attendee journey and close the record

After the approved repair, load the exact HTTPS URL from a fresh browser and another network. Test apex and www, the event page, event date and venue text, and the ticket or registration link as separate checks. If one network still sees the old page, compare its DNS answer and prior TTL with the authoritative answer; AWS notes that a TTL already cached is not shortened by changing it later.[1]

Log the failing hostname, observed default page, authoritative target, host assignment, change owner, change time and final visitor result in the worksheet. Only retire the temporary attendee route after the branded link has been checked on the published page. If the event is listed on Boletolibre.com, verify its event and ticket destination separately from the custom website domain.