MCI (AS197207, Iran) intercepts cleartext DNS and returns the bogon address 10.10.34.36 for dns.adguard.com A queries regardless of which upstream resolver is used (system, 8.8.8.8, or 9.9.9.9), and intercepted queries never reached a researcher-controlled DNS-over-UDP server. This bogon falls in the same /24 documented in prior Iranian censorship research. Additionally, SNI blocking for dns.adguard.com was confirmed independently on both port 853 (DoT) and port 443 (DoH).

In AS45090 (China), the Cloudflare CDN IP 104.16.248.249 succeeds 100% of the time with SNI 'cloudflare-dns.com' but triggers TLS handshake resets 93% of the time with SNI 'mozilla.cloudflare-dns.com'. Follow-up measurements using those same SNIs against unrelated HTTPS servers (example.org, hbl.fi) reproduced the same resets, confirming that the GFW performs SNI-keyed TLS blocking independent of the destination IP.

§V-E, Table VI detection

Dominant failure modes differ systematically by country: China (AS45090) shows connect timeouts in 75% of DoT failures (IP-level blocking); Kazakhstan (AS48716) shows post-TLS-handshake timeouts in 72% of DoT failures (likely ACK or segment discard after handshake); Iran (AS197207) shows TLS handshake timeouts in 80% of DoT failures. Packet capture analysis confirmed that timeouts during and after the TLS handshake correspond to unacknowledged TCP segments, not connection resets.

§V-F, §V-G, Table VIII evaluation

In AS197207 (Iran, MCI), approximately 50% of DoT endpoints failed consistently — the only case across all tested ASN/protocol combinations where failure exceeded 20%. In Kazakhstan (AS48716) and China (AS45090), more than 80% of DoT and DoH endpoints were always reachable.

§V-F, Table VII evaluation

In AS197207 (Iran), Google's DoT endpoint 8.8.4.4:853 is blocked 100% of the time while 8.8.8.8:853 is always accessible, regardless of SNI value. TLSv1.3 handshake analysis (hiding server certificates) confirmed no SNI correlation, establishing that Google's DoT blocking depends solely on the destination IP endpoint.

§V-I, Table X detection

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

DPYProxy-DNS's automated probe-and-select mode identified a working DNS circumvention in an average of 13.78 seconds (median 12.90s) in China and 12.32 seconds (median 8.28s) in Iran across 100 runs each; best-case startup was 0.32s (China) and 0.47s (Iran) when the first-tried combination succeeded, while worst-case exceeded 30.72s in China and 58.16s in Iran due to the slow Last Response mode (3s fixed wait per attempt) being selected early in the randomized probe order.

2026-niere-dpyproxy-dns §6.3 dns-poisoningsni-blockingip-blocking