Sorry, you can't have a CNAME on the root domain - Porkbun refuses CNAME for Zeabur apex domain

Not specified by the original author.

TL;DR

Switched the record type to ALIAS like Porkbun suggested, but the root domain still would not resolve properly while subdomains worked fine. Porkbun's ALIAS record is the equivalent for apex domains, but you need to make sure it actually resolves to the right target.

Steps

1. Tried pointing my root domain at Zeabur in Porkbun and got refused with an error saying a CNAME on the root domain violates RFC and will break things. Switched the record type to ALIAS like Porkbun suggested, but the root domain still would not resolve properly while subdomains worked fine. The maintainer pointed out that apex CNAMEs are not allowed by DNS rules and suggested flattening the CNAME by digging the A records of Zeabur's target and putting those A records on the apex directly.
2. You cannot put a CNAME on an apex/root domain, that is an actual RFC restriction, not a Porkbun quirk. Porkbun's ALIAS record is the equivalent for apex domains, but you need to make sure it actually resolves to the right target. The maintainer suggested flattening the CNAME yourself: run dig against Zeabur's CNAME target to get its A records, then put those A records directly on your root domain. One more thing from the thread: in the end the reporter's issue turned out to be plain Porkbun DNS propagation delay, so if you just changed records, wait a bit and recheck before assuming something is broken.

When to use

You are seeing this: Tried pointing my root domain at Zeabur in Porkbun and got refused with an error saying a CNAME on the root domain violates RFC and will break things. Use this skill when you run into "Sorry, you can't have a CNAME on the root domain - Porkbun refuses CNAME for Zeabur apex domain".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Asked in the thread (https://vectle.com/threads/thrpP14lg8kZqHPB9Ky8-bMw): Tried pointing my root domain at Zeabur in Porkbun and got refused with an error saying a CNAME on the root domain violates RFC and will break things. Switched the record type to ALIAS like Porkbun suggested, but the root domain still would not resolve properly while subdomains worked fine. The maintainer pointed out that apex CNAMEs are not allowed by DNS rules and suggested flattening the CNAME by digging the A records of Zeabur's target and putting those A records on the apex directly. The verified answer: You cannot put a CNAME on an apex/root domain, that is an actual RFC restriction, not a Porkbun quirk. Porkbun's ALIAS record is the equivalent for apex domains, but you need to make sure it actually resolves to the right target. The maintainer suggested flattening the CNAME yourself: run dig against Zeabur's CNAME target to get its A records, then put those A records directly on your root domain. One more thing from the thread: in the end the reporter's issue turned out to be plain Porkbun DNS propagation delay, so if you just changed records, wait a bit and recheck before assuming something is broken. Source: https://github.com/zeabur/zeabur/issues/527 Thread: https://vectle.com/threads/thrpP14lg8kZqHPB9Ky8-bMw

Not specified by the original author.

Netlify site down after moving DNS to Cloudflare: 500, blank page and 403 on the custom domain

TL;DR

If the site still loads on its netlify.app subdomain, the deploy is fine and the DNS move broke it. In Cloudflare DNS, point www at the site subdomain with a CNAME and the proxy switched off (DNS only), point the apex (root) domain at Netlify with an A record to 75.2.60.5 or an ALIAS/ANAME, and delete every other A or AAAA record for the same names. Only after DNS resolves cleanly will Netlify provision the HTTPS certificate and the 500, blank page, timeout and 403 errors clear.

Error message

500 Internal Server Error (or a blank page) on the custom domain
403 Forbidden on the custom domain
connection timed out on the custom domain
the same site loads fine at [sitename].netlify.app

Steps

1. Confirm the split first. Open the netlify.app subdomain. Expected: the site loads normally there. Success check: if it fails there too, this skill does not apply, the problem is the deploy, not DNS.
2. Fix the www record in Cloudflare DNS. Set www as a CNAME to the site subdomain, [sitename].netlify.app, and set the proxy status to DNS only (grey cloud). Expected: one www record, unproxied. Success check: a lookup for www returns the Netlify target, not a set of Cloudflare anycast addresses.
3. Fix the apex (root) record. A root domain cannot use a plain CNAME. Either add a single A record for the apex pointing to 75.2.60.5, or use an ALIAS/ANAME record pointing to apex-loadbalancer.netlify.com. Expected: exactly one apex route to Netlify. Success check: a lookup for the bare domain no longer returns the old host or a parked page.
4. Delete conflicting records. Remove every other A and AAAA record for the apex and www names, especially leftover records for the previous host and any duplicate A or AAAA entries the Cloudflare scan imported. Expected: one record per name. Success check: repeated lookups return the same single answer instead of rotating IPs.
5. Leave the proxy off for Netlify records. Cloudflare orange-cloud proxying in front of Netlify commonly produces exactly this mix: 403 on one hostname, timeouts or a 500/blank page on another, and failed certificate checks. Expected: grey cloud on the apex and www records.
6. Wait for propagation, then fix HTTPS last. In Netlify, open Domain management, then HTTPS, verify the DNS check passes, and only then provision or renew the certificate. Expected: the certificate provisions once DNS points at Netlify. Success check: loading the custom domain over HTTPS returns the site with a valid certificate and no 403, 500 or timeout.

When this applies

• The site broke right after DNS moved to Cloudflare (or another external DNS host) and the registrar is elsewhere, for example Hostinger.
• The netlify.app subdomain still works.
• Different hostnames fail differently: apex vs www, 500 on one site, 403 or timeouts on another.

When this does not apply

• The netlify.app subdomain is also down: that is a deploy or Netlify outage problem, not DNS.
• DNS is hosted at Netlify DNS itself: the records are managed for you, so look at the domain assignment instead.
• The domain shows a Netlify 'site not found' page with correct DNS: the domain is probably not added to the site in Domain management.

Variant phrasings

Site works on netlify.app but not on my domain

Same split, same fix: the origin is healthy, so rebuild the apex and www records as in steps 2-4.

403 Forbidden after connecting Cloudflare to Netlify

Almost always the proxy: switch the records to DNS only and remove conflicting A/AAAA entries, then re-check HTTPS.

Apex domain broken but www works (or the reverse)

One of the two records is wrong. www wants the CNAME to the site subdomain; the apex wants the A record to 75.2.60.5 or an ALIAS/ANAME, never a plain CNAME.

Why it happens

Cloudflare's setup scan imports whatever records it finds, including stale A and AAAA records, and defaults records to proxied. Netlify sites are not served from one fixed origin IP per hostname in the way a proxied setup assumes, so visitors land on conflicting endpoints: one request hits Netlify without a matching site or certificate (403, 500, blank page), the next hits a dead imported address (timeout). The netlify.app subdomain bypasses all of it, which is why it keeps working.

Edge cases

• Certificate will not provision: DNS is still returning a proxied or conflicting answer somewhere. Re-check the apex and www lookups before retrying; repeated retries do not fix bad records.
• Only the apex is used, no www: the A-record route alone is enough, but add www with a redirect to the apex in Netlify so both spellings work.
• Migrating from another host the same week: delete that host's records in the same pass. Leaving them in place keeps a share of visitors on the old server and looks like random intermittent downtime.

Provenance

Resolved from the public thread: https://answers.netlify.com/t/all-of-my-websites-are-down/194291

In the Netlify support thread 'All of my websites are down' (answers.netlify.com topic 194291, OP Impakt, Oct 17 2026, 0 replies at scout time): two sites broke immediately after the OP started changing DNS to Cloudflare, while both still worked on their netlify.app subdomains. One returns a 500 error or a blank page, the other first timed out and then returned 403 Forbidden. Domains are registered at Hostinger and use Cloudflare for DNS only. The pattern (healthy origin subdomain, broken custom domain right after a DNS move) points at the DNS records, not the deploys.

Not specified by the original author.

TL;DR

Finish the DNS setup for the Instatus custom domain: publish the exact CNAME record Instatus specifies, wait for propagation checked from an external resolver, and only then mark the page live, because DNS not propagated means the record is missing or still pointing at the old host. Prove it on one test incident before rolling it to the rest of the affected status page, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Instatus custom domain stuck on "DNS not propagated" status page never goes live

Use this when

• You see this exact error or symptom: Instatus custom domain stuck on "DNS not propagated" status page never goes live.
• The failure is in the status page provider named in the title, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one test incident first and capture the evidence before changing anything: check the provider's admin console error and activity log for the page, plus the public page as a logged-out visitor sees it, and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Finish the DNS setup for the Instatus custom domain: publish the exact CNAME record Instatus specifies, wait for propagation checked from an external resolver, and only then mark the page live, because DNS not propagated means the record is missing or still pointing at the old host. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Set an explicit timeout and a visible stuck state for this step, with an alert when it exceeds it, so a hang is reported as a failure instead of silently holding the run. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: repeat the failed action on a test incident or draft and confirm the public page reflects it without notifying subscribers unintentionally. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of the affected status page in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

DNS not propagated fix

The verbatim error or code phrasing for this fault in the status page provider named in the title; the fix is the same one in the steps above.

Instatus custom domain stuck on "DNS not propagated" status page never

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix Instatus custom domain stuck on "DNS not propagated"

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Atlassian Statuspage, Instatus, Better Stack, Cachet, Status.io, Hund, Freshstatus, Statuspal, UptimeRobot, StatusCake, All Quiet, FireHydrant, Squadcast, xMatters, Grafana Incident and PagerDuty as named in the title.

Why it happens

This fault happens because a step waiting on another system has no natural endpoint, so without its own timeout and alerting it holds everything behind it indefinitely. In this case the condition is the one named in the title, in the status page provider named in the title: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tHb6XeZyyltACC6-GVumZQ

Resolved from the public thread: https://vectle.com/posts/pst_tHb6XeZyyltACC6-GVumZQ

Thread query: Instatus custom domain stuck on "DNS not propagated" status page never goes live

TL;DR: Finish the DNS setup for the Instatus custom domain: publish the exact CNAME record Instatus specifies, wait for propagation checked from an external resolver, and only then mark the page live, because DNS not propagated means the record is missing or still pointing at the old host. Prove it on one test incident before rolling it to the rest of the affected status page, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.