Irancell (MTN): Impact of DNS Resolution Paths on Blocked Domains

Introduction

Recent network observations on MTN Irancell (a major Iranian mobile operator) highlight a significant and evolving pattern of internet censorship. While standard DNS queries (DNS-over-UDP) for blocked domains consistently undergo manipulation, the use of alternative DNS transport protocols—specifically DNS-over-TCP (DoTCP), DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ)—presents a more complex landscape.

Previously, most popular and personal DoT, DoH, DoQ, and DoTCP DNS servers were blocked. This situation has changed; blocking efforts have become more granular, targeting the DoH, DoT, and DoQ protocols on well-known public DNS services, while their DoTCP services often remain functional. Concurrently, private servers using clean, non-blocked IP addresses are unaffected. This has opened a viable path for bypassing DNS manipulation on Irancell's network. By utilizing personal DoTCP, DoT, DoH, and DoQ servers with clean, non-blocked IP addresses, or popular DoTCP servers, it is often possible to retrieve the actual IP addresses for blocked domains and circumvent DNS-based filtering.

More strikingly, subsequent direct HTTPS/TLS connections to these real IP addresses, for what are typically blocked domains (via SNI or DNS), are mostly successful. This indicates that MTN Irancell's SNI-based Deep Packet Inspection (DPI) or similar TLS-layer filtering mechanisms are not being applied. This report details these observations, including results from a custom testing tool, and discusses their potential implications.

Background: Standard Iranian ISP Intervention Layers

Typically, Iranian ISPs implement a multi-layered approach to manage and restrict access to online content:

• DNS Filtering/Manipulation: Intercepting and altering responses to DNS queries to prevent users from resolving the correct IP addresses of targeted domains. Usually returning 10.10.34.X for blocked domains.
• IP Address Denylisting (IP Blocking): Maintaining lists of IP addresses or entire ranges that are blocked at the network level.
• SNI-based Filtering / TLS-level DPI: Inspecting the SNI field of the ClientHello message in the TLS handshake to identify and block connections to specific HTTPS-enabled domains.

The observations on Irancell suggest that while DNS Filtering is still in place, it only applies to DNS-over-UDP and not DNS-over-TCP, and SNI-based blocking is entirely disabled. This suggests that perhaps censorship on the TCP transport protocol (and other encrypted transports to personal DNS servers) is currently inactive. For end-users on Irancell, this means that by simply circumventing DNS censorship, traditionally blocked websites can be accessed without a VPN.

Detailed Observations on Irancell

Part 1: Bypassing DNS Filtering with Alternative DNS Transports

Consistent behavior has been observed across different DNS transport protocols:

• Default DNS (DoU):

  • When using Irancell's default DNS resolvers, queries for domains known to be filtered on the network typically resolve to an internal IP address (10.10.34.X), effectively blocking access at the DNS level.

  

• Alternative DNS Transports (DoTCP, DoH, DoT, DoQ):

  • In contrast, when DNS queries for the same filtered domains are performed using DoTCP, DoT, DoH, or DoQ (on any ports) to capable public resolvers, the DNS responses consistently provide the authentic, publicly routable IP addresses for these domains.
  • This indicates that Irancell's DNS filtering system is effectively circumvented when these alternative, often encrypted, DNS transport protocols are utilized.

  

Part 2: Testing the SNI DPI effectiveness in TLS handshakes

To further analyze the TLS handshake behavior and the effectiveness of potential DPI for SNI, we utilized our custom testing tool named "heybabe" (details of which will be announced soon). "heybabe" allows us to initiate various types of TLS handshakes (including standard Golang TLS 1.3 and TLS 1.3 with uTLS client profiles such as 'Chrome' browser) using a target identifier. For the specific test illustrated below, the domain www.youtube.com was used.

The interpretation is that success=true from "heybabe" indicates a successful TLS handshake, suggesting SNI DPI for that test is ineffective. success=false (or connection failure to a known good IP) would suggest blocking.

Test Case: Using Domain www.youtube.com:

• Scenario 1: "heybabe" using system DNS (MTN Default DNS, no IP specified):

  • When initiating a TLS handshake to www.youtube.com relying on MTN's default DNS, the hostname resolves to 10.10.x.x (both IPv4 and IPv6) IP addresses as expected. TLS handshakes to these IPs and SNI have failed, confirming DNS-level blocking.

    • For IPv4:

    

    • For IPv6: Similar failed results (success=false) are observed.

    

• Scenario 2: "heybabe" with pre-resolved authentic IP (bypassing MTN DNS):

  • An authentic IP address for services associated with the hostname www.youtube.com (e.g., 142.250.186.46 for IPv4, and 2a00:1450:4001:803::200e for IPv6) is first obtained using an alternative DNS method (part 1).

  • "Heybabe" then performs TLS handshakes to this authentic IP address using www.youtube.com as the SNI domain.

    • For IPv4: Both standard TLS 1.3 and uTLS Chrome Auto tests return success=true.

    

    • For IPv6: Similar successful results (success=true) are observed.

    

Further testing with "heybabe" using this two-step methodology (alternative DNS followed by direct IP handshake with correct SNI) indicates that this pattern of successful TLS handshakes is not isolated to the www.youtube.com test case. Similar positive outcomes (bypassing both DNS manipulation and SNI-based blocking) were observed for most other commonly blocked domains (e.g., instagram.com and ...) on the Irancell network that are typically subject to such restrictions.

Discussion and Potential Explanations

The consistent success in bypassing DNS filtering via alternative transports, and more critically, the subsequent widespread ineffectiveness of SNI/TLS DPI for direct IP connections to most tested blocked domains, points to several potential characteristics of MTN Irancell's current filtering architecture:

• DNS Filtering Predominantly Targets DoU: Irancell's DNS manipulation system appears heavily focused on standard DNS-over-UDP, leaving other transports (DoTCP, DoH, DoT, DoQ) largely unhindered.
• Systemic or Intentional Ineffectiveness of SNI/TLS DPI for Direct IP Paths: The broad success in establishing TLS connections to authentic IPs (once resolved) for a majority of typically SNI-blocked domains is the key finding. This suggests:
  • Limited Scope of Inspection: The SNI/TLS DPI systems may not be configured to effectively inspect or apply policies to traffic directed to IPs that were not resolved via MTN's own manipulated DNS.
  • Technical Limitations: The DPI infrastructure could have inherent limitations, such as electricity shortages in Iran.
• IP Denylists Not Universally Applied or Easily Bypassed for these Cases: The success implies that the authentic IPs of these many blocked services are not (or cannot all be) on a comprehensively enforced IP blocklist that would override this SNI DPI gap.

This pattern indicates that while Irancell has a functional DNS filtering layer, its SNI in the TLS DPI enforcement layer has been almost entirely disabled.

Conclusion

The observed behavior on the MTN Irancell network reveals the emergence of a distinct two-fold pattern: alternative DNS transport protocols (DNS-over-TCP, DoH, DoT, DoQ) consistently bypass its DNS-level filtering, enabling the resolution of authentic IP addresses for filtered domains. Critically, direct HTTPS/TLS connections to these IPs for a majority of domains typically blocked via SNI/DNS (e.g., services related to youtube.com, instagram.com, and others) also now succeed. This demonstrates a widespread current ineffectiveness or specific non-application of Irancell's SNI-based DPI or similar TLS-layer blocking mechanisms for these particular communication pathways. This was not always the case and seems to be a recent change.

This significant observable gap in enforcement, whether a result of specific architectural decisions, an unaddressed aspect of their policy implementation, or an inherent characteristic of their current traffic management setup, effectively lowers the barrier to accessing a wide range of otherwise restricted content for users of this ISP. Continuous monitoring and further investigation remain crucial to understand the persistence and underlying reasons for this important aspect of MTN Irancell's current internet censorship posture.