Indian ISPs use heterogeneous and overlapping censorship mechanisms with no single technique common across all providers: DNS tampering (ACT, Airtel, BSNL, MTNL), HTTP header filtering (all six ISPs), and SNI inspection (Jio only). Individual ISPs such as ACT simultaneously apply DNS-only blocking to 233 sites, HTTP-only to 1,873 sites, and both to 1,615 sites.

A proposed HTTP censorship detection algorithm combining status-code comparison, response-length Z-score, HTML TF-vector cosine similarity, and redirect-hostname matching achieves F1 scores of 0.83 (censored) and 0.77 (uncensored), outperforming OONI (0.80 / 0.70), length-difference methods (0.70 / 0.66), and HTML-similarity methods (0.52 / 0.34) on a manually annotated set of 3,000 responses across six Indian ISPs.

§4.3, Table 1 evaluation

All detected HTTP censorship events in BSNL and MTNL are attributable to infrastructure shared with or operated by Airtel and ACT, demonstrating that upstream ISP filtering creates collateral censorship visible to downstream networks. Isolated cross-ISP leakage was also observed: Vodafone's censorship notice appeared in 2 Jio tests, and Airtel's appeared in 2 Vodafone tests.

§5.1.3 evaluation

Across six ISPs covering 98.82% of Indian internet subscribers, only 1,115 out of 4,033 tested blocked websites (27.64%) are blocked by all six ISPs simultaneously. ACT blocks 3,721 websites while Airtel blocks only 1,892, and 215 websites are blocked by exactly one ISP with no apparent legal basis.

§5.2, Table 3 evaluation

Jio, India's largest ISP serving 49.7% of internet users, employs SNI inspection to block 2,951 out of 3,340 websites it censors — the first documented use of SNI-based blocking in India. No other of the six tested ISPs uses this technique.

§5.1.4 evaluation

GFWeb tested 1.02 billion domains against the GFW over 20 months and discovered 943,000 pay-level domains blocked by HTTP filters and 55,000 by HTTPS filters — the largest GFW blocklist dataset ever published. The HTTP-to-HTTPS ratio (17:1) confirms that the GFW's HTTPS keyword-based and SNI-based blocking covers far fewer domains than its HTTP host-header blocking, likely because HTTPS blocks carry higher collateral-damage risk.

2024-hoang-gfweb Abstract, §5.1 dpidns-poisoningip-blockingkeyword-filteringsni-blocking

Article 19 documents that Iran's National Information Network (NIN / SHOMA) was designed with explicit reference to China's Great Firewall as a model, with institutional mirroring: Iran's Supreme Council of Cyberspace parallels China's Cyberspace Administration of China, and both governments share a "cyber sovereignty" doctrine used to justify domestic content controls and cross-border technology transfer. The report frames Iran's filtering infrastructure as deliberately architected to replicate GFW capabilities, not as an independently developed system.

2026-article19-tightening-the-net §2, §3 dpisni-blockingdns-poisoningip-blockingbgp-hijackthrottling

Both Firefox and Chromium leak cleartext DNS before establishing encrypted DNS connections: they first send an unencrypted UDP DNS query to resolve the DoH server's domain (e.g., doh.opendns.com). An in-path censor can intercept and poison this initial query, making encrypted DNS in browsers completely ineffective without additional circumvention of the resolver-lookup step. Additionally, Chromium always includes the SNI extension in the encrypted DNS TLS handshake (e.g., "doh.opendns.com"), leaking the resolver identity even after the initial lookup. No resolver requires SNI to be present for certificate validation when the resolver's IP certificate is configured.

2026-lange-towards §2.4, §7, §10 dns-poisoningsni-blocking

DNS censorship of encrypted protocols is inconsistent in both China and Iran. In China, Yandex resolvers are censored only when the SNI extension is present; omitting SNI bypasses censorship for these resolvers. In Iran, DoH requires SNI omission for Quad9, Google, Adguard, CleanBrowsing, and NextDNS resolvers, but works with SNI for Yandex and Cisco resolvers. These inconsistencies suggest resolvers have been accidentally missed by censors, highlighting the value of automated tools that trial all resolver-mode combinations rather than hard-coding a single strategy. The support evaluation found 47 resolvers supporting DoH, 16 supporting DoH3, and only 8 supporting DoQ out of ~65 tested.

2026-lange-towards §6.2, Table 2 dns-poisoningsni-blockingip-blocking

DPYProxy-DNS tested 8 circumvention modes against DNS censorship from vantage points in Iran (AS201295, Mashhad) and China (AS4837, China Unicom). In Iran, DoQ was entirely uncensored even with the SNI extension present; DoH3 worked for all Cloudflare and NextDNS resolvers. Iran's censor operates in-path (not on-path like the GFW), making the "Last Response" mode (wait 3s for the last UDP reply) ineffective in Iran but highly effective in China. Auto-mode averaged 12.32s (median 8.28s) in Iran and 13.78s (median 12.90s) in China to discover a working combination.

2026-lange-towards §6.2, §6.3 dns-poisoningsni-blockingip-blocking

All major browsers (Firefox, Chromium) issue an unencrypted DNS-over-UDP query to resolve their configured DoH resolver's domain before initiating any encrypted DNS session. In Iran, nearly all tested DoH resolver domains are directly censored at the DNS layer (returning block-page IPs), which renders browser-native encrypted DNS ineffective regardless of whether the underlying encrypted protocol would otherwise succeed. Additionally, browsers always include the SNI extension in TLS handshakes with DNS resolvers even though no tested resolver requires it.

2026-niere-dpyproxy-dns §7 dns-poisoningsni-blocking