Supabase project hostname returns NXDOMAIN despite Healthy status

[omwish]

Hello Supabase community,

I'm experiencing a DNS resolution issue with my Supabase project.

Project details

• Project name: kegiatan-warga-rt05-rw04
• Project reference: wzurrkuoldqrnskqzdnf
• Region: ap-northeast-1 (Tokyo)
• Plan: Free
• Support ticket: SU-506919

The Supabase dashboard shows the project status as Healthy, but the project hostname does not resolve.

Project URL:
https://wzurrkuoldqrnskqzdnf.supabase.co

DNS test results

• Local DNS: NXDOMAIN
• Cloudflare DNS (1.1.1.1): NXDOMAIN
• Google DNS (8.8.8.8): NXDOMAIN
• Authoritative nameserver (christina.ns.cloudflare.com): NXDOMAIN

The database hostname db.wzurrkuoldqrnskqzdnf.supabase.co also returned NXDOMAIN.

My Python application cannot connect to the Supabase API because the hostname does not resolve.

I have submitted a support request through the Supabase dashboard under ticket SU-506919 and received the automated acknowledgement.

Could anyone advise whether this may be a project DNS provisioning issue and suggest safe next steps?

I want to preserve the existing project, database structure, and data. I have not deleted or recreated the project.

Thank you for your help.

[GaryAustin1]

Have you tried project restart from General Settings?
Otherwise file as support ticket.

[mgkvibez]

Hit this on a restore recently — the dashboard saying Healthy and DNS saying NXDOMAIN is almost always propagation, not a broken project. What I run, in order:

1. Ask the authoritative servers directly, so your resolver's cache can't lie to you:

dig wzurrkuoldqrnskqzdnf.supabase.co @8.8.8.8 +short
dig wzurrkuoldqrnskqzdnf.supabase.co @1.1.1.1 +short

If some resolvers answer and others NXDOMAIN, it's propagation — and your ticket is the right lever, since only Supabase can push the zone.

2. Project restart (General Settings) — for a restored project this genuinely re-registers the DNS records; it's not just a placebo step. Wait 5-10 minutes after, then re-run the dig.

3. Check from a different network/region — a VPS or phone hotspot answers differently than your campus/ISP resolver, which tells you whether the problem follows the network (stale NXDOMAIN caching upstream, try dig with a different resolver) or the project (all resolvers agree → ticket).

4. If every resolver NXDOMAINs for more than an hour post-restart, it's a zone issue on Supabase's side — nothing client-side will fix it, and SU-506919 is the fastest path. Reply on the ticket with your dig output from multiple resolvers; that's the exact evidence support needs to escalate.

For the free-tier restore path specifically: restored projects get fresh DNS records and the registration occasionally lands after the status flips to Healthy — the gap you're seeing is that gap.

[omwish]

Thank you for the suggestions.

I have already queried the authoritative nameserver christina.ns.cloudflare.com, as well as Cloudflare DNS (1.1.1.1) and Google DNS (8.8.8.8). All return NXDOMAIN for my project hostname.

The dashboard still shows the project as Healthy.

Before restarting the project, could you clarify whether a normal project restart is likely to help when the authoritative DNS server itself returns NXDOMAIN? I want to avoid unnecessary downtime if this requires DNS provisioning repair on Supabase's side.

My support ticket is SU-506919.

Thank you.

[mgkvibez]

Good instinct to push on this — and you're right to be skeptical. Here's the honest breakdown:

If christina.ns.cloudflare.com (authoritative for the supabase.co zone) returns NXDOMAIN, that rules out propagation and caching entirely. An authoritative answer is the source of truth: the record for your project doesn't exist in the zone right now. No resolver-side trick will change that.

So does a restart still help? Actually yes, sometimes: a project restart triggers the control plane to re-provision the project's DNS records, and for restored projects specifically there are confirmed cases where NXDOMAIN resolved after a restart — the record simply had failed to register on restore, and re-registering fixed it.

On the downtime concern: there's no availability left to protect. NXDOMAIN means the project is already unreachable for every client — a restart can only improve the situation, not degrade it.

So the sequence I'd run:

1. Restart once, wait ~10-15 min, then re-run:
   dig wzurrkuoldqrnskqzdnf.supabase.co @christina.ns.cloudflare.com +short

2. If it still NXDOMAINs after that, it's definitively DNS provisioning on Supabase's side — nothing client-side remains, and only support can inject the record into the zone.

For SU-506919: reply with your dig output against the authoritative NS specifically. That single output proves the record is absent at the zone level, which is the exact evidence needed to route it to the right team instead of getting generic "check your DNS" replies.

One more thing worth adding to the ticket: there have been several independent NXDOMAIN-after-restore reports for ap-northeast-1 free-tier projects in the last day or two, all with Healthy dashboards even mine also. If there's a provisioning issue on restored projects in that region, the volume of reports will help support see the pattern faster.