Persistent DNS Resolution Failure (Name or service not known) for New Projects

[linyangqing99]

Bug report

[x] I confirm this is a bug with Supabase, not with my own application.

[x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

<Describe the bug
Creating new projects results in hostnames that cannot be resolved via DNS. Both psql and ping fail with a "Name or service not known" error. This issue has occurred across three separate, newly created projects and persists across different networks.

To Reproduce
Create a new, free-tier project in the Supabase dashboard.

Go to Project Settings -> Database -> Connection string.

Copy the Host parameter.

Attempt to ping the host from a local machine terminal.

See the "Name or service not known" error.

Expected behavior
The ping command should successfully resolve the hostname to an IP address, and the psql connection should be successful.

clean.@cleandeMacBook-Air ~ % dig @1.1.1.1 db.cvvbsmovwrohnpsdolda.supabase.co

; <<>> DiG 9.10.6 <<>> @1.1.1.1 db.cvvbsmovwrohnpsdolda.supabase.co
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
clean.@cleandeMacBook-Air ~ % psql "postgresql://postgres:W5uS20OIhitNd9pL@db.cvvbsmovwrohnpsdolda.supabase.co:5432/postgres"
zsh: command not found: psql
clean.@cleandeMacBook-Air ~ % psql "postgresql://postgres:W5uS20OIhitNd9pL@db.cvvbsmovwrohnpsdolda.supabase.co:5432/postgres"
psql: error: could not translate host name "db.cvvbsmovwrohnpsdolda.supabase.co" to address: nodename nor servname provided, or not known
clean.@cleandeMacBook-Air ~ % dig @1.1.1.1 db.cvvbsmovwrohnpsdolda.supabase.co

; <<>> DiG 9.10.6 <<>> @1.1.1.1 db.cvvbsmovwrohnpsdolda.supabase.co
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
clean.@cleandeMacBook-Air ~ % ping db.cvvbsmovwrohnpsdolda.supabase.co
ping: cannot resolve db.cvvbsmovwrohnpsdolda.supabase.co: Unknown host

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: [e.g. macOS]
• Browser (if applies) [chrome]

[aantti]

Can you try
% dig @1.1.1.1 db.cvvbsmovwrohnpsdolda.supabase.co aaaa ?

Should be along the lines of:

[..]
;; ANSWER SECTION:
db.cvvbsmovwrohnpsdolda.supabase.co. 30	IN AAAA	2600:1f16:1cd0:332d:cab1:cfe6:5031:6d4e
[..]

% telnet -6 2600:1f16:1cd0:332d:cab1:cfe6:5031:6d4e 5432 
Trying 2600:1f16:1cd0:332d:cab1:cfe6:5031:6d4e...
Connected to 2600:1f16:1cd0:332d:cab1:cfe6:5031:6d4e.
Escape character is '^]'.

[linyangqing99]

Thank aantti! I solve it!
need to open the IPV6~

[aantti]

No problem! Yeah, it's IPv6 for the direct connection to the database. Poolers are accessible via IPv4.

[Hallidayo]

Hi, going to move to a discussion for if others have the issue. Thanks @aantti for the fix!

[asadullah009]

This is not actually a DNS bug with Supabase.

The direct database hostname (db.<project>.supabase.co) now resolves primarily to an IPv6 address, not IPv4. If your network/router/ISP/device does not support IPv6, DNS resolution and connections will fail exactly like this. :contentReference[oaicite:0]{index=0}

That is why:

ping db.cvvbsmovwrohnpsdolda.supabase.co

fails with:

Unknown host

and:

psql ...

fails with:

could not translate host name ...

The maintainer’s suggestion confirms this:

dig @1.1.1.1 db.cvvbsmovwrohnpsdolda.supabase.co aaaa

The AAAA query requests the IPv6 record specifically.

The fix is to either:

Enable IPv6 on your network/device/router
Use the Supavisor pooler connection string instead of the direct database connection
Purchase the IPv4 add-on on paid plans

For free-tier projects, the easiest solution is usually using the Session Pooler / Transaction Pooler connection string because those are IPv4-compatible.

So the issue was caused by IPv6 not being enabled locally, not by broken Supabase DNS.

[GitNimay]

Security notice first: Your database password W5uS20OIhitNd9pL is visible in plain text in this report. Go to Project Settings → Database → Reset database password immediately, even if you cannot connect yet.

On the actual bug

The dig timeout against 1.1.1.1 (rather than returning NXDOMAIN) is the key signal here. A timeout means the DNS query never got a response at all, which almost always points to one of two things:

Most likely cause: Project still provisioning

Free-tier Supabase projects can take several minutes to fully provision after creation, and the DNS record for db.<ref>.supabase.co is not created until provisioning completes. If you tried to connect within the first few minutes of creating the project, wait 5 to 10 minutes and try again:

dig db.cvvbsmovwrohnpsdolda.supabase.co

If it returns an A record, provisioning completed and DNS is live. If it still times out or returns NXDOMAIN, the project may have failed to provision correctly.

Second possibility: Free-tier project is paused

Supabase pauses free-tier projects after a period of inactivity. A paused project will not resolve DNS for direct connections. Check your dashboard for a "Restore project" banner and click it if present.

Steps to diagnose right now

Check if the DNS record exists at all without specifying a resolver:

dig db.cvvbsmovwrohnpsdolda.supabase.co +short

Then try with Google's DNS to rule out your ISP:

dig @8.8.8.8 db.cvvbsmovwrohnpsdolda.supabase.co +short

If both return nothing, the project either has not finished provisioning or failed to provision entirely. In that case, delete it, create a new one, wait 10 minutes before attempting any connection, and check the Supabase status page at status.supabase.com for any ongoing provisioning incidents.

If the project dashboard shows it as active and DNS still does not resolve after 15 minutes, this is likely a legitimate provisioning bug and the Supabase team will need your project reference ID to investigate on their end.