Our content sync pipeline broke on Monday morning. No error in the code. No failed migration. No expired API key. Just silence — requests to our Supabase project (hfyczaxyaafgxntbodpy) hanging indefinitely, then timing out. The blog you are reading right now, the projects page, the team section — all of it pulls from Supabase at request time via SSR. All of it went dark for anyone on an Indian ISP.

It took us about twenty minutes to figure out what had happened, and when we did, it was infuriating. India's largest internet service providers — Jio, Airtel, ACT Fibernet — had started DNS-poisoning every *.supabase.co domain, quietly redirecting resolution to a sinkhole IP. No announcement. No official order made public. No explanation. Just a developer platform serving millions of Indian engineers, silently erased from the DNS.

This is not an outage report. This is a critique. Because what happened this week is not a technical failure — it is an institutional one, and every developer in India should be paying attention.

DNS resolution being intercepted and redirected DNS queries for supabase.co domains being silently redirected to ISP-controlled sinkhole IPs across Indian networks

What Exactly Happened

Starting approximately February 24, 2026, developers across India began reporting that Supabase services were unreachable. The pattern was immediately recognizable to anyone who has dealt with Indian ISP blocking before: DNS resolution was being intercepted.

Here is what a normal DNS resolution for a Supabase endpoint looks like:

$ dig hfyczaxyaafgxntbodpy.supabase.co

;; ANSWER SECTION:
hfyczaxyaafgxntbodpy.supabase.co. 300 IN CNAME  kong-supabase-aws.supabase.co.
kong-supabase-aws.supabase.co.    60  IN A      13.233.x.x

And here is what developers on Jio, Airtel, and ACT Fibernet started seeing:

$ nslookup hfyczaxyaafgxntbodpy.supabase.co
Server:   198.18.0.1
Address:  198.18.0.1#53

Non-authoritative answer:
Name:     hfyczaxyaafgxntbodpy.supabase.co
Address:  49.44.192.x

That 49.44.x.x address is not a Supabase server. It is a Jio-owned IP — a DNS sinkhole. Every query to any *.supabase.co subdomain was being resolved to this address, which either returns nothing or serves a block page. The ISPs were not filtering at the IP level or doing deep packet inspection. They were poisoning DNS responses at the resolver level, the cheapest and most blunt instrument available.

You can verify this yourself if you are on an affected ISP:

# Using your ISP's default DNS (poisoned)
$ nslookup supabase.co
# Returns sinkhole IP (49.44.x.x range)

# Using Cloudflare DNS (clean)
$ nslookup supabase.co 1.1.1.1
# Returns actual AWS IP

# Full dig comparison
$ dig @1.1.1.1 supabase.co +short
# Real IP
$ dig @198.18.0.1 supabase.co +short
# Sinkhole IP

This is textbook DNS poisoning. The ISP's recursive resolver intercepts the query for *.supabase.co, ignores the authoritative nameserver response, and injects a forged answer pointing to their own infrastructure. Your application thinks it is connecting to Supabase. It is actually connecting to nowhere.

The Scale of the Damage

Let me be concrete about what this breaks. Supabase is not a niche tool. It is the open-source Firebase alternative used by hundreds of thousands of projects worldwide. In India specifically, Supabase has seen massive adoption among startups, indie developers, student projects, and agencies — including us.

Here is what stopped working the moment DNS was poisoned:

Service Impact Severity
Supabase Dashboard Completely inaccessible — cannot manage projects, view data, or edit configs Critical
Database connections (REST API) All client-side queries fail — apps return empty states or crash Critical
Authentication (GoTrue) Sign-up, login, OAuth flows all timeout — users locked out of apps Critical
Edge Functions All serverless function invocations fail Critical
Realtime (WebSocket) Live subscriptions drop, collaborative features break High
Storage API Image uploads, file downloads fail High
Supabase CLI Local development commands that phone home fail Medium
Documentation site docs.supabase.com unaffected (different domain), but supabase.com partially affected Low

For CODERCOPS specifically, the impact was immediate and comprehensive. Our architecture is simple: content is authored as MDX and Markdown files in a Git repository, synced to Supabase via a GitHub Actions pipeline, and served to the website via SSR queries at request time. Every page load on our site makes at least one query to hfyczaxyaafgxntbodpy.supabase.co. When that domain resolves to a sinkhole, nothing renders.

Our sync pipeline (sync-to-supabase.js) runs in GitHub Actions, which uses GitHub's own DNS resolvers — so the sync itself was unaffected. But every developer on our team working from India could not access the Supabase dashboard to verify data, debug queries, or manage the project. And any visitor to our site on an Indian ISP saw failures.

If your production application uses Supabase and serves Indian users, your app is likely broken right now for anyone on Jio, Airtel, or ACT Fibernet who has not manually changed their DNS settings. This is not a Supabase problem. This is an ISP-level DNS override affecting your end users.

Who Ordered This and Why

This is where the story goes from frustrating to infuriating. As of the time of writing, there is no public explanation for why Supabase was blocked.

Multiple reports — from Medianama, CyberKendra, and OfficeChai — indicate that ISPs are acting on a "ministry order," presumably from MeitY (Ministry of Electronics and Information Technology). But no official communication has been published. No gazette notification. No press release. No entry in any public blocking list.

Supabase's official account on X (formerly Twitter) confirmed the block, posted workarounds, and directly tagged Union Minister Ashwini Vaishnaw asking for clarification. As of February 28, there has been no public response from the minister or from MeitY.

The GitHub community has been tracking this in issue #43142, which has become a clearinghouse for affected developers sharing diagnostic data, workarounds, and frustration. The thread is hundreds of comments deep and growing.

Let me be direct about what is happening here: a government ministry has apparently ordered the blocking of a developer infrastructure platform used by millions of engineers, and has not offered a single word of public justification. The ISPs have complied silently. And the developers whose livelihoods depend on this infrastructure are left to figure it out themselves.

The Technical Absurdity

I want to dwell on how technically absurd this blocking mechanism is, because it reveals how little thought went into it.

DNS poisoning blocks everything on a domain. Supabase uses *.supabase.co as its multi-tenant namespace. Every single Supabase project — hundreds of thousands of them — shares this domain pattern. There is no way to block one specific project or one specific piece of content using DNS poisoning of *.supabase.co. You block all of them or none of them.

This means the block is indiscriminate by design. It does not target specific content. It does not target specific users. It simply removes an entire cloud platform from the Indian internet. Student projects, startup MVPs, enterprise applications, open-source tools, educational platforms — all of them collateral damage.

Network infrastructure cables and connections The infrastructure that connects millions of Indian developers to cloud services — disrupted by a single DNS override

Compare this to how content moderation actually works on platforms that deal with illegal content: you issue takedown notices for specific URLs, you work with the platform to remove specific items, you use targeted legal processes. You do not nuke an entire cloud provider's DNS because something somewhere on it offended someone.

It is the equivalent of shutting down all of AWS because one S3 bucket hosted objectionable content. Except even that analogy is too generous, because at least AWS has public-facing consumer content. Supabase is almost entirely a backend-as-a-service — it hosts databases, authentication endpoints, and serverless functions. The content it serves is API responses, not web pages. The idea that DNS-level blocking is an appropriate response to anything on Supabase reveals a fundamental misunderstanding of what the platform even is.

The Affected ISPs

Here is what we have confirmed based on community reports and our own testing:

ISP Block Method Confirmed Workaround
Jio (Fiber + Mobile) DNS poisoning to 49.44.x.x sinkhole Yes Switch DNS to 1.1.1.1 or 8.8.8.8
Airtel (Broadband + Mobile) DNS poisoning Yes Switch DNS or use VPN
ACT Fibernet DNS poisoning Yes Switch DNS or use VPN
BSNL Reports inconsistent — some regions affected Partial Switch DNS
Vi (Vodafone Idea) Some reports of blocking Unconfirmed Switch DNS
Excitel Not confirmed blocked Unknown N/A
Local cable ISPs Varies by region Mixed Switch DNS

The common thread: every major ISP that typically complies with DoT/MeitY blocking orders has implemented this. Smaller ISPs and those in certain regions may not have complied yet — enforcement of these orders is notoriously inconsistent.

What You Can Do Right Now

If you are a developer in India affected by this, here are your immediate options, ranked by ease of implementation:

1. Change Your DNS Resolver (Fastest Fix)

This is the simplest workaround because the block is DNS-level only. Switch your system or router DNS to any of these:

Provider Primary DNS Secondary DNS DoH Support Notes
Cloudflare 1.1.1.1 1.0.0.1 Yes Fastest resolution, privacy-focused
Google 8.8.8.8 8.8.4.4 Yes Most widely used alternative
Quad9 9.9.9.9 149.112.112.112 Yes Malware filtering included
OpenDNS 208.67.222.222 208.67.220.220 Yes Cisco-owned, content filtering options

On macOS:

# Temporary (reverts on reboot)
sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1

# Verify
scutil --dns | head -20

On Linux:

# Edit resolv.conf (temporary)
sudo sh -c 'echo "nameserver 1.1.1.1" > /etc/resolv.conf'
sudo sh -c 'echo "nameserver 1.0.0.1" >> /etc/resolv.conf'

# Or use systemd-resolved (persistent)
sudo mkdir -p /etc/systemd/resolved.conf.d/
sudo tee /etc/systemd/resolved.conf.d/dns.conf <<EOF
[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4
EOF
sudo systemctl restart systemd-resolved

On Windows (PowerShell as Administrator):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")
If you change DNS on your development machine, remember that your end users on Indian ISPs will still be affected unless they also change their DNS. This workaround fixes your development workflow but does not fix your production application for Indian users on default ISP DNS.

2. Use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT)

Standard DNS queries are unencrypted UDP packets that ISPs can intercept and modify. DNS-over-HTTPS encrypts the query, making it impossible for the ISP to poison the response.

Most modern browsers support DoH natively:

  • Firefox: Settings > Privacy & Security > Enable DNS over HTTPS > Select Cloudflare
  • Chrome: Settings > Privacy and Security > Use Secure DNS > Select a provider
  • Edge: Settings > Privacy > Use Secure DNS

For system-wide DoH on macOS, you can use cloudflared as a local DNS proxy:

brew install cloudflare/cloudflare/cloudflared

# Run as DNS proxy
sudo cloudflared proxy-dns --port 53 --upstream https://1.1.1.1/dns-query

# Then set your DNS to 127.0.0.1

3. Use Cloudflare WARP (VPN)

Cloudflare's WARP app (available on all platforms) routes your traffic through Cloudflare's network, bypassing ISP DNS entirely. The free tier is sufficient for development work.

# Install on macOS
brew install cloudflare-warp

# Or download from https://1.1.1.1

4. Custom Domains with Proxying (Production Fix)

For production applications, the real fix is to stop relying on *.supabase.co domains that your Indian users must resolve. Set up a custom domain that proxies to your Supabase project:

# Nginx reverse proxy example
server {
    listen 443 ssl;
    server_name api.yourdomain.com;

    location / {
        proxy_pass https://hfyczaxyaafgxntbodpy.supabase.co;
        proxy_set_header Host hfyczaxyaafgxntbodpy.supabase.co;
        proxy_ssl_server_name on;
        resolver 1.1.1.1;
    }
}
Supabase has a custom domains feature on their Pro plan and above. If you are running a production application with Indian users, this is now a necessity rather than a nice-to-have. A custom domain means your users never need to resolve *.supabase.co directly.

This is the approach we are evaluating at CODERCOPS. Our Vercel deployment already runs outside India, so the SSR queries from our server to Supabase are unaffected. But any client-side Supabase calls (like our page view counter hitting /api/views/[slug]) would fail for users on affected ISPs if those calls resolved through poisoned DNS. A custom domain on our own infrastructure eliminates this dependency entirely.

The Broader Pattern: India and Developer Tools

This is not the first time India has blocked or disrupted access to developer infrastructure. And that pattern is what makes this particularly alarming.

GitHub faced intermittent blocking and slowdowns in India in previous years, reportedly related to specific repositories hosting content the government objected to. The difference was that GitHub, being Microsoft-owned and enormously visible, attracted enough attention that the issues were resolved relatively quickly.

Supabase is smaller, more specialized, and less visible to non-developers. That makes it an easier target and a harder case to resolve through public pressure alone.

The fundamental problem is that Indian internet blocking operates through opaque administrative orders with no meaningful transparency or appeals process. The IT Act gives the government broad powers to order blocking, and ISPs comply without question. There is no public registry of blocked sites. There is no requirement to notify the blocked service. There is no formal process for challenging a block.

For developer tools and cloud infrastructure, this model is catastrophically inappropriate. When you block a consumer website, users cannot access that website. When you block a cloud platform, you break every application built on that platform. The blast radius is orders of magnitude larger, and the collateral damage falls on people and businesses that have nothing to do with whatever triggered the block.

Consider what a startup founder in Bangalore experiences when this happens: their production application breaks, their users cannot log in, their data is inaccessible, their development workflow is disrupted — and they have absolutely no information about why, how long it will last, or what they can do about it through official channels. The only recourse is technical workarounds that their end users may not know how to implement.

This is not governance. This is infrastructure sabotage by administrative fiat.

What Needs to Change

The developer community in India needs to push for three things:

1. Transparency in blocking orders. Every blocking order should be published with a specific legal justification. "Ministry order" is not an explanation. Developers and businesses have a right to know why their infrastructure is being disrupted.

2. Proportionality in enforcement. DNS-level blocking of an entire cloud platform is never proportionate. If there is specific content on Supabase that violates Indian law, the appropriate response is a targeted takedown request to Supabase, not a nuclear option that breaks hundreds of thousands of unrelated projects.

3. An appeals and review process. There must be a mechanism for affected services and developers to challenge blocking orders, present evidence, and get timely resolution. The current system — where a platform is blocked and must tweet at a government minister hoping for a response — is not a system at all.

If you are building a production application in India, you need to treat ISP-level blocking as a realistic infrastructure risk. Design your architecture to minimize single-provider DNS dependencies. Use custom domains. Implement fallback mechanisms. This is not paranoia — it is the reality of building on the Indian internet in 2026.

What CODERCOPS Is Doing

We are not going to pretend this is fine. Here is what we are doing in response:

First, our immediate fix was straightforward. Our Vercel deployment handles SSR from Vercel's edge network, which resolves DNS through its own infrastructure — not through Indian ISPs. So server-side rendering continued to work. For our development team, we switched to Cloudflare DNS across all machines within the first hour.

Second, we are evaluating Supabase's custom domains feature to ensure that even client-side calls from Indian users never touch *.supabase.co directly.

Third, we are documenting this incident thoroughly — which is what this post is. Because the next time a developer platform gets silently blocked in India, the community needs a record of what happened, what the impact was, and what the workarounds are.

We chose Supabase deliberately. It is open-source, well-engineered, and has an excellent developer experience. We are not reconsidering that choice because of this block — the problem is not Supabase. The problem is an opaque regulatory system that treats developer infrastructure as collateral damage in content enforcement actions that it will not even explain publicly.

The Bottom Line

Four days after the block began, we still have no official explanation. Millions of developers are affected. Production applications are broken. The Supabase team has been responsive and helpful — posting workarounds, engaging with the community, reaching out to government officials. The Indian government has said nothing.

This is what happens when internet governance operates without transparency, proportionality, or accountability. Developer tools are infrastructure. Blocking them is not content moderation — it is economic disruption. And doing it silently, without explanation, without a process for resolution, is indefensible.

If you are a developer affected by this, change your DNS, set up custom domains, and make noise. File reports with TRAI. Contact your representatives. Post about it. The only thing worse than this block is accepting it in silence.

Useful links:

Comments