net4people
I(ra)nconsistencies: Novel Insights into Iran's Censorship (FOCI 2025)
For Persian and Iranian Readers 🇮🇷 Attached is the translated version of the paper published by FOCI Community, specifically highlighting the section on Iran’s Censorship – Novel Insights into Inconsistencies.
Additionally, an online workshop will be held on February 20, 2025, covering this topic in depth. This translation is provided for those who are interested but may not be able to attend the event.
For reference, the original paper is also attached.
I(ra)nconsistencies: Novel Insights into IRAN’s Censorship
برای خوانندگان ایرانی و فارسی زبان 🇮🇷
نسخه ترجمه شده به زبان فارسی برگرفته از مقالهای که توسط انجمن FOCI منتشر شده است و بخش ترجمه شده از این مقاله که تمرکز بر روی سانسور در ایران و نگاهی نوین به ناسازگاریها در روشهای فیلترینگ را بررسی و تحلیل میکند.
همچنین یک کنفرانس در این زمینه و زمینههای دیگر که در مقاله اصلی به آنها اشاره شده است در تاریخ ۲۰ فوریه ۲۰۲۵ به صورت آنلاین و کاملاً رایگان برای عموم تهیه دیده شده که در صورت علاقهمندی میتوانید به صورت زنده به این کنفرانس ملحق شوید.
نسخه فارسی
ناسازگاریها – بینشهای جدید درباره سانسور اینترنت در ایران
کارگاه اول Free and Open Communications on the Internet (FOCI) در سال ۲۰۲۵
📅 تاریخ: ۲۰ فوریه ۲۰۲۵ ⏰ ساعت: ۱۷:۰۰ - ۲۱:۳۰ UTC 🌍 محل برگزاری: آنلاین (gather.town) 💰 هزینه: رایگان (ثبتنام الزامی است)
🔗 وبسایت رویداد: foci.community 📝 لینک ثبتنام: ثبتنام در رویداد
📄 مقالات اکنون منتشر شدهاند! اگر میخواهید قبل از رویداد روز پنجشنبه آنها را بررسی کنید، از لینک زیر استفاده کنید: 🔗 مشاهده مقالات FOCI 2025
Special thanks to the FOCI Community. https://github.com/net4people/bbs/issues/450
There is a source code link given in the paper, but as of 62be32a (2025-02-12) it's not populated yet.
https://github.com/UPB-SysSec/IranconsistenciesData
A really interesting detail in Section 3.1 and Appendix C: DNS response injection of valid IP addresses for certain censored domain names, in addition to the already known injection of fake IP addresses in the 10.10.34.0/24 network.
Injected Block Page IPs
While analyzing the DNS responses from our scan, we identified that all responses contain exactly one record in the answers section. The IP address 10.10.34.36 was injected for 41,285 (≈87%) domains and 10.10.34.34 for 6,348 (≈13%).
…
Injected Valid IPs
Next to block page IPs, Iran’s censor injects a DNS response with a static but correct IP for some hostnames. … Iran’s censor intercepts DNS requests with 372 Google-related domains, such as google.com and google.ca, and injects a DNS record with the IP 216.239.38.120—an IP that corresponds to Google. Next to hostnames owned by Google, Iran’s censor exhibits this behavior for 13 other domains, including search engines, foreign secret service websites, and a video game provider. We provide a complete list of injected correct IPs in Appendix C. The correct IP addresses are injected by the same network node as the block page IPs.
We provide two theories on why Iran’s censor directs traffic for affected domains to a static IP address. Firstly, access to the affected domain could potentially be tracked by filtering traffic to the static IP address and would be resilient to changing DNS records. Secondly, resolving domains to a static IP address might allow Iran’s censor to swiftly censor domains by blocking access to the injected static IP address instead of relying on advanced DPI or tracking multiple—potentially cached—IP addresses. While these could explain Iran’s injection of correct IPs, the exact reasoning remains unclear, making it an interesting avenue for future research.
My first guess at the reason for injecting valid IP addresses would be that it's an attempt by the censor to overcome anti-censorship defenses that know to ignore DNS responses with IP addresses in the 10.10.34.0/24 range. Presumably the valid IP addresses are themselves blocked.
@jknockel Outstanding and absolutely invaluable insights regarding Iran's GFW. Many thanks and sincere gratitude to the FOCI Community for providing us with such remarkable and valuable information. 🙏🏽
@wkrp
I found Section 3.2 on HTTP censorship very interesting, particularly the observation that "the lower-case variant gET is not being analyzed and censored, meaning that the censor is case-sensitive for HTTP methods."
We have encountered a few similar anomalies and cases like this (which are better left undiscussed at this point). These findings raise an important question, is this intentional, or is it a flaw in their system that could potentially be exploited to bypass the IRGFW?
We encourage the Iranian community and active users to PRIVATELY share similar findings with FOCI for further investigation and testing.
All defined HTTP methods (e.g., GET, CONNECT)are analyzed and censored by the Iranian censor. Notably, the lower-case variant gET is not being analyzed and censored, meaning that the censor is case-sensitive for HTTP methods. The Iranian censor also ignored all non-standard-compliant values that we tried, such as an empty string, a space, or a censored keyword. We consider this an interesting oversight by the Iranian censor as Harrity et al.
Analyzed Parts of the HTTP Message. The Iranian censor analyzes the Host header and path of HTTP requests but ignores the body. Furthermore, censored domains are only censored in the Host header and censored keywords only in the path. We suspect this is due to performance optimizations, as it is more likely for a censored domain to appear in the Host header and a censored keyword to appear in the path value. This decision by Iran’s censor leads to interesting behavior in combination with different HTTP versions.
The findings in Section 3.3: Correlation of HTTP and DNS Censorship were particularly interesting and insightful. We have long suspected that DNS plays a crucial role in filtering by the IRGFW, even for encrypted connections.
In particular, the statement:
"All HTTP and DNS censorship we encountered in Iran occurred at the same network node. Altering the TTL value of our packets, we deduced that all censorship happened at the last network node in Iran. This hints towards a centralized censorship architecture using border nodes rather than ISP-level censorship."
This discovery provides a clearer understanding of Iran's filtering techniques and reinforces previous observations made by Iranian activist communities. There have been longstanding suspicions that both centralized censorship architecture and ISP-level censorship are in place. These findings further validate those concerns.
I believe the FOCI Community can benefit from Iranian activists' insights and real-world experiences to gain a more comprehensive understanding of Iran’s censorship mechanisms. This knowledge could be invaluable for future testing and research in 2025.
3.3 Correlation of HTTP and DNS Censorship
After analyzing Iran’s HTTP and DNS censorship, we evaluated correlations between injected IPs and HTTP censorship methods. shows a strong correlation between TCP RSTs being used as an HTTP censorship method and the IP 10.10.34.34 being injected on the DNS level. Similarly, most domains that are censored with the IP 10.10.34.36 on the DNS level are censored with a block page.
While we detect a strong correlation between DNS and HTTP censorship, it is incomplete: some domains are censored with a TCP RST via HTTP and 10.10.34.36 via DNS.
All HTTP and DNS censorship we encountered in Iran occurred at the same network node. Altering the TTL value of our packets, we deduced that all censorship happened at the last network node in Iran. This hints towards a centralized censorship architecture using border nodes rather than ISP-level censorship.
This suggests that some parts of Iranian censorship only happen from certain vantage points, and while censorship happens at border nodes, different border nodes might employ different censorship techniques.
@Phoenix-999 Thank you for creating a translation and this thread. That is really awesome and hopefully this helps to make our findings more accessible to everyone. We hope to incorporate this discussion into a future analysis of the Iranian censor.
@wkrp I just pushed all of our promised data to GitHub. The most interesting data there is probably the complete list of domains that map to injected correct IPs. Regarding your possible interpretation: we did not observe any censorship for the correctly injected IPs for the search engines (google, yandex, duckduckgo, bing) . Interestingly, we cannot access the intelligence agency domains over the injected IPs and their accossiated adresses seem to lie in Iran and Sweden:
mi5.gov.uk (Current) 85.233.160.22 AS8622 - TEAM BLUE INTERNET SERVICES UK LIMITED
mi5.gov.uk (Paper) 185.130.45.94 AS210083 - Privex Inc.
mossad.gov.il 87.107.132.83 AS21341 - Soroush Rasanheh Company Ltd
cia.gov 93.115.151.123 AS43754 - Asiatech Data Transmission company
For the additional domains, the behavior has since changed. k.gjacky.com does not seem to face IP adress injection anymore. Otherwise:
lobby.igamecj.com 162.62.115.144 AS132203 - Tencent Building, Kejizhongyi Avenue
lobby.igamecj.com 162.62.116.251 AS132203 - Tencent Building, Kejizhongyi Avenue
still point to the same IP.
My first guess at the reason for injecting valid IP addresses would be that it's an attempt by the censor to overcome anti-censorship defenses that know to ignore DNS responses with IP addresses in the 10.10.34.0/24 range. Presumably the valid IP addresses are themselves blocked.
Iran does all kinds of weird stuff when it comes to dns,their dns poisoning is sometimes so bad that internet is unusable but when i use a dns over https it will be fine again,but as for forging valid dns response,I don't know about all domains but for google.com from a few years ago they started doing some dns poisoning specifcly for google to force safe search on everyone(if use a doh it can be bypassed without problem)
I don't know about all domains but for google.com from a few years ago they started doing some dns poisoning specifcly for google to force safe search on everyone
Ah! Yes! Thank you for reminding me. Injected DNS responses with the IP address of forcesafesearch.google.com to forcibly activate SafeSearch for all users (archive). Google calls it "SafeSearch VIP" (SafeSearch Virtual IP). Now I remember we have talked about this before.
2023-03-28: https://github.com/net4people/bbs/issues/226#issuecomment-1487644887
Here is an example for google.com. I have redacted the transaction ID but it did match the question's transaction ID.
0000 00 2a xx xx 81 a0 00 01 00 01 00 00 00 01 06 67 .*.............g 0010 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 c0 0c 00 01 oogle.com....... 0020 00 01 00 00 01 a2 00 04 d8 ef 26 78 ..........&xI don't know much about DNS over TCP's wire protocol but it looks like it's missing the question class (0x0001 in this case for IN) before starting the answer section and the pointer (0xc00c).
Yes, your analysis is correct. The response is missing the QCLASS field of the Question section. The NAME field of the Answer section is being interpreted as the QCLASS, and then parsing gets desynchronized. The response is malformed in another way: it says ARCOUNT=1 but the Additional section is empty.
But the IP address in the response seems to be a valid one for google.com, 216.239.38.120. Here is a manual dissection:
This is
forcesafesearch.google.comand is not a normal IP address forgoogle.com.It is strange, if this interference is intended for censorship, that it returns what appears to be a good IP address, rather than a 10.10.34.X one.
The censor has the ability to inject any IP address and not just
10.10.34.3x. In this case it is used for forcing safe-search to be enabled for everyone. I don't know if this was previously documented here but it's a well-known thing inside of Iran.
2023-04-04: https://github.com/net4people/bbs/issues/240#issue-1654474426
if you remember its been a while since iran activated "Forced safe search" on google with dns spoofing returning
forcesafesearch.google.comip instead of normalgoogle.com.
And some third-party references:
- 2022-06-30: Iran: Outrage after government puts Google on Safe Search for all Iranians (archive)
- 2022-09-25: "how to turn of safe search in iran ? has been turned on and locked by government for every one" (archive)
- 2023-06-06: Unforce Google SafeSearch (archive)
@FelixLange1998 So at least in the cases of Google and Bing, the fact of injection of valid IP addresses had been known, and there's a reasonable known motive for it (activate a restricted search feature).
That still leaves others from Appendix C unexplained. I'll transcribe the table here:
| Domain Group | Count | IP |
|---|---|---|
| 372 | 216.239.38.120 | |
| Bing | 2 | 204.79.197.220 |
| DuckDuckGo | 2 | 52.250.41.2 |
| Yandex | 1 | 213.180.193.56 |
| CIA | 1 | 93.115.151.123 |
| MI5 | 3 | 185.130.45.94 |
| Mossad | 1 | 87.107.132.83 |
| GJacky | 1 | 10.202.7.212 |
| IGameCJ | 1 | 162.62.115.144 |
| Public IGameCJ | 1 | 162.62.116.251 |
@FelixLange1998 I suppose you and your group's experiments didn't include DNS over TCP. So you may not have had the opportunity to record any malformed DNS responses of the kind documented at https://github.com/net4people/bbs/issues/226#issuecomment-1485829957. But I'm curious whether you saw anything like that.
Safe search…they should better solve this in a political way, like asking Google to do it for Iran. Like Microsoft did for China, locking the safe search to the highest level.
I fell asleep at the event before he finished the presentation. Here is a question left: Did you analyze the injection packets, including the DNS responses and TCP RST? Probably release the tcpdump or pcap files? Because I doubt that they buy such system or middle boxes from Chinese, try looking into the TTL, IPID and DF flag may be interesting.
I read something like GFW probe SaaS one year ago,
China is involved. Connecting to any random port number from the outside world on any server inside of Iran (passing the GFI) is almost always followed by a port probe on that specific port from an IP address belonging to China. https://blog.thc.org/the-iran-firewall-a-preliminary-report
Is it only probes shared?
@firewallPass @wkrp Thank you for your very insightful comments about safe search. That indeed explains the mentioned cases! We will keep this in mind for our future analyses. Maybe we can also figure out the remaining cases in the future and extend our set of websites to maybe even find more of such cases. That would be very interesting.
@wkrp We did not look at DNS over TCP yet and we did not observe any malformed DNS responses so far. We will add DNS over TCP as one of the additional protocols that we plan to analyze in Iran. Thank you!
@UjuiUjuMandan I hope you did not fall asleep because of my talk :) We did not analyze the observed DNS responses and TCP RSTs that deeply so far. We just extracted the IP / observed the presence of a TCP RST packet to get a general overview of censorship in Iran. Looking at the flags more deeply in future evaluations is a good idea. Thank you for your comment!