Project DNS record missing — zhcfpwkwbwarlzgqcsua (ap-southeast-1) — NXDOMAIN, production impact imminent

[PengendaliDivisiInfra]

🚨 Production-Impacting: Project DNS Record Missing

Project ref: zhcfpwkwbwarlzgqcsua
Region: ap-southeast-1 (Singapore)
Ticket ID: SU-511489 (submitted via dashboard support)
Account email: engineringf@gmail.com

---

Issue

Authoritative NS for supabase.co returns NXDOMAIN for this project's subdomain. Production may become unavailable when Cloudflare Workers DNS cache expires.

DNS Evidence

Resolver	Result
Cloudflare DoH (1.1.1.1)	❌ Status 3 (NXDOMAIN), SOA from christina.ns.cloudflare.com
Google DoH (8.8.8.8)	❌ Same NXDOMAIN
whatsmydns.net (global)	❌ ALL nodes fail
Base domain supabase.co	✅ RESOLVES (76.76.21.21)
Pooler aws-0-ap-southeast-1.pooler.supabase.com	✅ RESOLVES
Wildcard *.supabase.co	❌ NXDOMAIN (no wildcard)
Dashboard project status	✅ Healthy

Impact

Cloudflare Workers production (promanage-next.engineringf.workers.dev) still works via cached DNS, but cache will expire soon → full outage imminent.

Estimated downtime window: < 24 hours.

Ask

1. Verify A/CNAME record for zhcfpwkwbwarlzgqcsua.supabase.co in authoritative zone
2. Restore record if missing
3. Provide ETA for fix
4. Interim: provide target IP so we can add temporary hosts entry to keep production alive

Environment

• Supabase project ref: zhcfpwkwbwarlzgqcsua
• Client SDK: @supabase/supabase-js@2.117.2
• Region: ap-southeast-1
• Existing ticket: SU-511489

Any Supabase engineer able to check internal DNS zone for this project? 🙏

[DYNOSuprovo]

Immediate Cause & DNS Verification

Confirmed from external resolvers: zhcfpwkwbwarlzgqcsua.supabase.co returns NXDOMAIN (RCODE 3) directly from the authoritative nameservers (christina.ns.cloudflare.com / dane.ns.cloudflare.com).

This is a known control-plane reconciliation desync that has affected several projects recently (#51655, #51752, #51815, #51816, #51848). While your underlying database, Kong API gateway, and containers remain Healthy on AWS ap-southeast-1, the asynchronous DNS provisioning worker failed to publish or re-verify the authoritative CNAME/A record in the supabase.co zone.

---

Step 1: Immediate Self-Service Fix (Forces Control-Plane DNS Re-registration)

You do not have to wait for ticket response to restore the DNS record. In several identical incidents over the past few days, the following sequence successfully restored the DNS record in under 2 minutes:

1. In the Supabase Dashboard, go to Project Settings → General → Infrastructure.
2. Click Pause Project.
3. Wait ~60 seconds until the project status transitions to Paused.
4. Click Resume Project.

Why this works: The Resume orchestration workflow tears down and re-executes the complete provisioning sequence, triggering the authoritative DNS registration hook against Cloudflare/Route 53. Once resumed, the authoritative record for zhcfpwkwbwarlzgqcsua.supabase.co is re-announced within 60–90 seconds.

Note: If you are on Pro and cannot afford a 60-second maintenance pause, triggering a momentary compute resize (e.g. Micro → Small or vice versa) under Compute Add-ons forces the exact same reconciliation event without stopping the project.

---

Step 2: Emergency Workaround for Cloudflare Workers (promanage-next)

Before your Cloudflare Workers DNS cache expires:

1. Database Traffic (Direct / Prisma / Drizzle / pg):
   Do not connect via db.zhcfpwkwbwarlzgqcsua.supabase.co. Instead, switch your database connection string to the shared regional Supavisor pooler:

   • Host: aws-0-ap-southeast-1.pooler.supabase.com
   • Port: 6543 (Transaction mode) or 5432 (Session mode)
   • User: postgres.zhcfpwkwbwarlzgqcsua
   • Password: [YOUR-DB-PASSWORD]
     This hostname is active and resolving (52.77.146.31), fully bypassing the project-specific DNS.

2. Custom Domain Alternative (API / Auth / PostgREST):
   If your project is on the Pro tier, you can configure a Custom Domain (e.g., api.yourdomain.com) under Project Settings → Custom Domains. This assigns a dedicated CNAME under your own DNS provider and bypasses the *.supabase.co zone entirely.

---

Step 3: Ticket Escalation Reference

If the Pause & Resume cycle is blocked by organizational policy, reply to your open ticket SU-511489 and link discussions #51655, #51752, #51815, and #51848. Supabase support agents have an internal re-sync utility to republish authoritative DNS records for specific project refs on-demand.

---

If the Pause & Resume re-sync successfully restores your project's DNS record, please consider marking this response as the accepted answer! 🚀

[kevinjosh10]

Hi @community! For urgent project DNS outages where <project-ref>.supabase.co returns NXDOMAIN in production:

---

Immediate Production Fallback (Bypass Project DNS)

You can restore database connectivity immediately by switching your application connections to the regional connection pooler, which does not rely on the individual project DNS record:

• Hostname: aws-0-ap-southeast-1.pooler.supabase.com
• Port: 6543 (Transaction) or 5432 (Session)
• User: postgres.zhcfpwkwbwarlzgqcsua
• Password: [your-database-password]

---

DNS Escalation

Submit an urgent ticket via Supabase Dashboard → Support and select Production Outage. Include:

• Project Reference: zhcfpwkwbwarlzgqcsua
• Region: Singapore (ap-southeast-1)
• Authoritative DNS query result showing NXDOMAIN from AWS Route53.
  Supabase support can trigger an automated Route53 zone re-sync to publish the missing A/AAAA records.