Supabase project hostname returns NXDOMAIN

[kucicakuca266-tech]

Hello,

I have a Supabase project called "Domaće i Ručno" with project ref:

lowajnbdzsxvqxnjtoq

The project hostname:

https://lowajnbdzsxvqxnjtoq.supabase.co

does not resolve publicly.

Google Public DNS returns:

Status: 3 (NXDOMAIN)

I have tested this outside of my website as well, so this does not appear to be a frontend or JavaScript issue.

My Supabase support ticket is:

SU-495921

The support ticket was submitted because the project API hostname is unreachable, but I have not received a technical response yet.

Could someone please check the DNS provisioning for this project hostname and advise how it can be restored?

Thank you.

[jovanovic-djo]

Ćao, seems like lowajnbdzsxvqxnjtoq.supabase.co does return NXDOMAIN from Google DNS. But the ref you posted is 19 characters, and Supabase project refs are 20 lowercase letters. For example, mhgnxlrqbpbamdlzkvzv.supabase.co resolves normally.

So a character may have been lost when the ref was copied. Could you:

1. Open Dashboard -> Project Settings -> Data API and copy the Project URL exactly as shown.
2. Compare it with content in your app's env (SUPABASE_URL / NEXT_PUBLIC_SUPABASE_URL etc.). If your app has the 19-character version, that's the cause.
3. Test the copied URL directly: nslookup .supabase.co 8.8.8.8

If the correct 20-character hostname also returns NXDOMAIN, it's a provisioning or project-state problem on Supabase's side. Add the full ref to your ticket SU-495921 so they can check it.

I hope this helps.

[kucicakuca266-tech]

Thank you for checking this.

I verified the API URL directly in my Supabase Dashboard → Data API.

The dashboard itself shows:

https://lowajnbdzsxvqxnjtoq.supabase.co/rest/v1/

So the hostname is exactly the one I reported; it was not copied incorrectly from my application.

Google Public DNS still returns NXDOMAIN for this exact hostname.

Could you please advise what could cause the Supabase Dashboard itself to show a hostname that does not resolve publicly?

Support ticket: SU-495921

[jovanovic-djo]

Not quite sure, but my assumption is that dashboard just builds the address from your project ID. It doesn't check if that address actually works. The DNS record is created separately by Supabase when the project is set up, so the dashboard can show an address that doesn't exist on the internet.

Most likely the project is paused, or something failed when it was created (your 19-character ID points to this). Only Supabase can fix the missing record, so reply to your ticket SU-495921 and ask them to check and recreate the DNS record. If you need it working fast and the project has little data, creating a new project is the quickest fix.

By the way, I am not Supabase support, you should definitely reply to them on your ticket.

[HIRATRA]

One additional thing I'd check before assuming this is a DNS provisioning issue is whether the NXDOMAIN is consistent across authoritative and recursive resolvers.

Since NXDOMAIN is different from a timeout or SERVFAIL, it would be useful to verify the exact hostname and query path:

dig +short lowajnbdzsxvqxnjtoq.supabase.co
dig +trace lowajnbdzsxvqxnjtoq.supabase.co
dig @1.1.1.1 lowajnbdzsxvqxnjtoq.supabase.co
dig @8.8.8.8 lowajnbdzsxvqxnjtoq.supabase.co

If the hostname is confirmed to be the exact Project URL from the dashboard and multiple public resolvers consistently return NXDOMAIN, dig +trace can help distinguish a resolver/cache issue from the record genuinely not existing in the authoritative DNS chain.

I'd also check whether the project itself is in a transitional state (recently created, restored, renamed, paused/unpaused, or otherwise undergoing provisioning), because the API hostname is infrastructure-level and a healthy dashboard state doesn't necessarily prove that the DNS record has already propagated.

So I'd frame the diagnosis as:

1. Verify the canonical Project URL from the Dashboard.
2. Query multiple recursive resolvers.
3. Use dig +trace to check the authoritative path.
4. If the canonical hostname still returns NXDOMAIN consistently, attach those DNS results to SU-495921 so Supabase can check the project's DNS provisioning rather than spending time debugging the application.

The key signal here is that a reproducible NXDOMAIN at the canonical hostname points to a different layer than a frontend/API connectivity issue.

[russfranky]

Same signature as a provisioning problem. Google Public DNS returns NXDOMAIN too, so this is not your cache and not your frontend.

Check two things. Project paused? Free plans pause after inactivity. Billing clean?

If both are fine, the DNS record for lowajnbdzsxvqxnjtoq was never re-registered at Supabase's gateway. Your ticket SU-495921 is the right channel. Reply to it with the nslookup output and the project ref. Ask them to confirm the record exists and re-register it if not.