How India Blocks Telegram: A Technical Deep Dive into DNS, SNI, and ISP-Level Censorship

On Tuesday, 16 June 2026, millions of Indians opened Telegram to a spinning connection icon that never resolved. The government had ordered the platform blocked until Monday, 23 June — a window timed squarely around the NEET 2026 re-examination on 21 June, after paper-leak and cheating rackets were found organising on Telegram channels. The order originated from the Ministry of Education's National Testing Agency and was enforced under the IT Act's blocking powers, invoked in the interest of India's "sovereignty and integrity."

The government called it a "last resort" after content-takedown requests failed. Telegram's founder Pavel Durov pushed back:

The leaks just moved to other apps. Blocking punishes 150M+ ordinary Telegram users in India, not the insiders who leaked the exam materials.

He has a point — and the reason he has a point is entirely technical. To understand why a national block is simultaneously disruptive and leaky, you need to understand what "blocking an app" actually means on the wire. Let's go under the hood.

First, the legal machinery

Before a single packet is dropped, there's paperwork. India blocks online resources primarily through two levers in the Information Technology Act, 2000:

Section 69A + the Blocking Rules, 2009 — the Ministry of Electronics and IT (MeitY) issues a confidential blocking order on grounds of national security, public order, or sovereignty. This is the "hard" route, and it's almost certainly what was used here.
Section 79(3)(b) — intermediary-liability notices that ask platforms/ISPs to disable specific content.

The order itself doesn't block anything. It's a legal instruction sent to licensed Internet Service Providers — Jio, Airtel, Vi, BSNL, ACT and the rest. Their licensing agreements compel compliance. Crucially, the rules don't mandate how an ISP must block. Each provider picks its own mechanism. That single detail is why a site can be dead on Jio but reachable on Airtel, and why your friend across town has a different experience than you. India doesn't have one censorship system — it has dozens, one per ISP, loosely coordinated.

What "blocking" actually targets: the request lifecycle

When your phone connects to web.telegram.org, four distinct things happen in sequence. Each is a checkpoint a censor can attack:

                                                        CENSORSHIP CHECKPOINT
1. DNS    "what's the IP for web.telegram.org?"  ─────▶  [1] DNS tampering
          ◀── 149.154.167.99

2. TCP    SYN ──▶ 149.154.167.99:443             ─────▶  [2] IP / null-route blocking

3. TLS    ClientHello { SNI: web.telegram.org }  ─────▶  [3] SNI filtering (DPI)

4. DATA   ◀── encrypted application traffic ──▶  ─────▶  [4] protocol/DPI fingerprinting

A website is "blocked" by breaking any one of these steps. The catch: each checkpoint is cheaper or more precise than the last, and each is defeated by a different countermeasure. Here's how Indian ISPs actually use them.

Checkpoint 1 — DNS tampering (the cheap, common one)

The Domain Name System turns web.telegram.org into an IP address. By default your DNS queries go, in plaintext over UDP port 53, to your ISP's resolver — which the ISP fully controls. The most common block in India is simply lying at this step:

# Honest answer from an open resolver
$ dig +short web.telegram.org @1.1.1.1
149.154.167.99

# Same query through a censoring ISP resolver
$ dig +short web.telegram.org @<isp-resolver>
10.10.34.36      # a "block page" sinkhole — or NXDOMAIN, or 127.0.0.1

The ISP returns a forged answer: either NXDOMAIN ("no such domain"), a loopback address, or the IP of a server that shows a "This site has been blocked as per orders…" page. This is called DNS poisoning / tampering. It's popular because it's nearly free — no expensive hardware, no inspection of traffic, just a config entry on the resolver.

It's also the weakest block, because it only works as long as you use the ISP's resolver and an unencrypted channel.

Checkpoint 2 — IP and null-route blocking

If DNS isn't enough (say you're using a different resolver), the ISP can block the destination IP itself. At the BGP/routing layer they install a null route — packets to Telegram's IPs are silently dropped or sent to nowhere. The connection just times out.

This is blunter and more expensive in collateral damage: modern services sit behind shared cloud IPs and CDNs, so null-routing one IP can take down unrelated services that share it. This blunt instrument is exactly what made Telegram so hard to block elsewhere (more below).

Checkpoint 3 — SNI filtering (the modern workhorse)

Here's the subtle one. Even over HTTPS, the very first message of a TLS handshake — the ClientHello — historically carries the destination hostname in plaintext, in a field called SNI (Server Name Indication). SNI exists so one IP can host many TLS sites. But it also hands a censor the domain name on a silver platter, before encryption begins:

TLS ClientHello (sent in the clear):
  ...
  extension: server_name
    server_name: "web.telegram.org"   ◀── DPI reads this and resets the connection
  ...

ISPs deploy Deep Packet Inspection (DPI) boxes that watch for the SNI extension and, on a match, inject a TCP RST to kill the connection — or just drop the packets. This is precise (it targets one hostname, not a whole IP) and it survives you switching DNS providers, because the hostname leaks in the handshake itself. SNI filtering — increasingly extended to scan QUIC/UDP 443 as well — is now the backbone of serious blocking in India.

Checkpoint 4 — protocol fingerprinting

The deepest checkpoint: ignore names entirely and fingerprint the protocol. DPI can learn the statistical signature of Telegram's MTProto transport and block any flow that looks like it, regardless of IP or domain. This is the most powerful and most expensive option, and it's where the real cat-and-mouse lives.

Why Telegram is especially hard to block

Blocking a single website is easy. Blocking Telegram — an app, not a web page — is a different beast, and Telegram was practically engineered to resist it:

It's not one domain or IP. The apps talk directly to Telegram's data centres over MTProto, across large, rotating ranges of cloud IPs (historically Amazon, Google, etc.). There's no single t.me to poison.
It hops. During Russia's infamous 2018 attempt, Telegram fled across millions of Google/Amazon IP addresses. Russia ended up null-routing huge cloud ranges and breaking unrelated services — and still didn't fully kill Telegram. That episode is the canonical proof that IP blocking against a motivated, cloud-hosted target is a losing game.
Circumvention is built in. Telegram ships MTProto proxies and SOCKS5 support as first-class features. Channels routinely broadcast fresh proxy links; one tap and you're routing around the block.

This is why a national block of Telegram, in practice, is usually a combination — DNS tampering on its web domains, IP-range blocking on its data centres, and DPI/SNI filtering — and why it still tends to leak. It raises the cost of access for ordinary users far more than it stops determined ones. Which is, almost word for word, Durov's complaint.

Can you bypass it from India?

Technically: usually yes, and the right tool depends on which checkpoint your ISP is using. Conceptually, every bypass is the same move — deny the censor visibility into your traffic.

Block mechanism	What defeats it	Why
DNS tampering	Encrypted DNS (DoH / DoT) via `1.1.1.1`, `8.8.8.8`	Your lookups are encrypted and sent past the ISP resolver, so it can't lie or see them
IP / null-route	VPN or proxy	Your real destination is hidden inside a tunnel to the VPN's IP
SNI filtering (DPI)	VPN, or Telegram's built-in MTProto proxy	The hostname never appears in the clear on your ISP's wire
Protocol fingerprinting	Obfuscated transports (obfs4, MTProto-with-obfuscation, Shadowsocks)	Traffic is disguised to look like ordinary TLS/random bytes

A few honest caveats, because the internet is full of half-truths here:

Encrypted DNS alone is often not enough. It beats DNS blocking, but if your ISP is doing SNI filtering or IP blocking, changing your resolver does nothing — the block lives at a different layer. This is the single most common misconception.
A full-tunnel VPN is the most reliable general answer, because it collapses checkpoints 1–3 into a single encrypted tunnel the ISP can't inspect. The cost: the ISP can still see that you're using a VPN and may throttle or block popular VPN endpoints by IP/SNI too — so it becomes its own cat-and-mouse.
ECH / ESNI is not the silver bullet people claim. Encrypted Client Hello hides the SNI, but it was designed for privacy, not censorship circumvention — and it bootstraps off encrypted DNS to fetch its keys. If a censor blocks the encrypted-DNS step, ECH simply doesn't engage. Useful, not magic.
Telegram's own proxies are the path of least resistance for most users: no extra app, baked into the client.

A necessary note: circumventing a lawful blocking order can carry legal and policy consequences, and during a high-stakes window like a national exam the block exists precisely to disrupt coordinated fraud. Understand the mechanics — but understand the context too. This post is about how the technology works, not an endorsement of evading a specific court or government order.

The bigger picture

Strip away the politics and a national app-block is a fascinating systems problem. The censor and the platform are fighting across the OSI stack: poison the names, the user encrypts DNS; block the IPs, the platform hops clouds; filter the SNI, the traffic gets obfuscated. Each layer the censor climbs costs more money, more hardware, and more collateral damage to unrelated services — the deeper the inspection, the broader the blast radius.

That asymmetry is why blunt blocks are simultaneously disruptive and porous: they reliably inconvenience 150 million ordinary users while the motivated minority — exactly the leak insiders the order was meant to stop — slip through a proxy in seconds. The block is real engineering. So is everything that routes around it.