Project domain not resolving via DNS anywhere (kcscvxljtuvvmnfwapj.supabase.co)

[yun2419]

My project's domain is not resolving via DNS from any location or DNS server.

Project Reference: kcscvxljtuvvmnfwapj
Project Name: 잡스플랜
Region: ap-northeast-1 (Tokyo)
Plan: Free

Issue:
The domain kcscvxljtuvvmnfwapj.supabase.co fails to resolve, both from the local ISP DNS and from Google's public DNS (8.8.8.8). Browser requests fail with DNS_PROBE_FINISHED_NXDOMAIN.

Steps taken:

• Confirmed project status shows "Healthy" in the dashboard
• Ran nslookup kcscvxljtuvvmnfwapj.supabase.co (default DNS) → Non-existent domain
• Ran nslookup kcscvxljtuvvmnfwapj.supabase.co 8.8.8.8 → Non-existent domain
• Confirmed dashboard itself (supabase.com/dashboard) loads fine, but project request success rate shows 0%
• Tried pausing and resuming the project — issue persists after resume
• Tested from multiple devices/networks — same result on all

This has been an ongoing issue for about two weeks now, across two different machines. A support ticket was submitted previously (Ticket ID: SU-432504) but only received an automated response directing to supabase.help.

Any guidance on how to get the DNS record re-provisioned would be greatly appreciated.

[puneet26082006]

One detail worth checking: the project reference in your post, kcscvxljtuvvmnfwapj, has 19 characters. Supabase documents project references as 20-character identifiers, so there may be a missing character in the hostname.

Could you copy the full Project URL directly from your project’s Connect dialog and compare it with the URL configured in your application? Then run nslookup using that exact hostname, without https:// or any path.

Relevant documentation:

• Project reference format : https://supabase.com/docs/guides/graphql#project-reference-project_ref
• Where to get your Project URL : https://supabase.com/docs/guides/api/creating-routes#api-url-and-keys

If you shortened the reference only for this discussion, this might not explain the issue. If the exact hostname copied from the dashboard still returns NXDOMAIN on both resolvers, add the hostname, lookup output, and timestamps to your existing support ticket so Supabase can investigate the DNS configuration.

The length mismatch is worth ruling out before assuming the DNS record needs to be re-provisioned.

[Drako01]

Based on what you've tested, this looks more like a project-hostname DNS provisioning issue than a local DNS configuration problem.

The key observation is that the project shows Healthy, but its hostname returns NXDOMAIN from multiple independent resolvers.

I'd verify one additional layer before escalating.

1. Confirm the exact project hostname.

Copy the Project URL directly from the Supabase dashboard under API settings.

Make sure the hostname matches the active project reference.

2. Query multiple DNS resolvers.

For example:

dig kcscvxljtuvvmnfwapj.supabase.co A @1.1.1.1
dig kcscvxljtuvvmnfwapj.supabase.co A @8.8.8.8
dig kcscvxljtuvvmnfwapj.supabase.co AAAA @1.1.1.1

Then inspect the DNS delegation path:

dig +trace kcscvxljtuvvmnfwapj.supabase.co

If the authoritative DNS servers also return NXDOMAIN, repeatedly clearing local DNS caches won't resolve the underlying issue.

3. Distinguish compute health from hostname availability.

A healthy database instance does not necessarily prove that the project's public API hostname was provisioned correctly.

Those are separate infrastructure concerns.

4. Escalate with reproducible evidence.

Since you've already opened support ticket SU-432504, I'd update it with:

• Project reference and region.
• Exact DNS hostname.
• Timestamp and resolver used for each test.
• Authoritative DNS response.
• Confirmation that pause/resume did not resolve the problem.

Ask support to verify the DNS/API gateway provisioning for that specific project.

I would avoid trying to create custom DNS records for the provider-managed supabase.co domain or relying on a hardcoded IP address.

If the authoritative record is missing, the actual fix requires action on the managed infrastructure.

The most useful remaining diagnostic is the authoritative DNS result, because it determines whether this is propagation/caching or a missing record at the source.