Irancell (MTN) DNS behavior with sanctioned domains

Recent network observations from MTN Irancell (Iran's major mobile operator) indicate that multiple high-profile, sanction-restricted domains are accessible without VPNs. These domains include:

• chatgpt.com
• openai.com
• gitlab.com
• okta.com
• epicgames.com

Under normal circumstances, these domains should resolve to Cloudflare CDN IP addresses, which remains true when using non-default DNS resolvers. However, when connected to Irancell and utilizing their DNS servers, these domains are subject to DNS response spoofing. This technique resolves them to illegitimate servers/IPs hosted on the Hetzner network. Furthermore, some spoofed domains not only connect to these illegitimate IPs but are also tunneled through a Cloudflare WARP tunnel, further obscuring the Hetzner IP from Cloudflare's CDN.

When using non-default DNS servers, the originating IP observed by the Cloudflare CDN does not belong to MTN but rather to Delta Telecom, a network based in Azerbaijan.

To facilitate this redirection, MTN Irancell appears to employ an SNIProxy or a transparent proxy. This allows intercepted HTTPS traffic—identified by SNI in the TLS handshake—to be forwarded to the intended destination or further manipulated, all while maintaining a seamless connection from the client's perspective.

The domains discussed here are those that have been identified so far, but it is likely that MTN employs similar techniques for many other Cloudflare CDN domains as well.

Process Diagnostic

Take chatgpt for an example:

When accessing https://www.chatgpt.com/cdn-cgi/trace using an MTN Irancell residential internet, the following behaviors are consistently observed:

• If no custom DNS is set, the DNS resolver always returns a Hetzner IPv4+IPv6 address for chatgpt.com, and Cloudflare also sees a Hetzner IPv6 as the client IP—even when the device is configured for IPv4 only. Occasionally, the Hetzner IP may be in Finland or Germany. As you can see, resolving the domain without a custom DNS will return Hetzner IP addresses.

  When running curl: Here, cloudflare will only and always see Hetzner IPv6.

• If any custom DNS is set (regardless of provider), the DNS response is a standard Cloudflare CDN IP, and Cloudflare sees the connection as coming from Delta Telecom (Azerbaijan) IPv4. As you can see, resolving the domain with a custom DNS will return the actual Cloudflare CDN IP.

  When running curl: In this scenario, Cloudflare consistently observes the connection as originating from an Azerbaijan (DeltaTelecom) IP address.

• In conclusion: (for chatgpt.com domain)

  • MTN Default DNS:
    • Resolved IP: Hetzner IPv4
    • Cloudflare Observed IP: Hetzner IPv6
    • WARP Status: off
  • Custom DNS:
    • Resolved IP: Cloudflare CDN Edge
    • Cloudflare Observed IP: Delta Telecom IPv4
    • WARP Status: off

Traceroute tests to these Hetzner IPs confirm that these addresses are legitimately announced and not hijacked.

Domains such as cloudflare.com did not resolve to Hetzner IPs, and while attempting to force a connection to cloudflare.com through the Hetzner server, the connection was terminated, indicating a presence of a whitelist system on the SNI proxy.

We can see the status for other domains:

Notably, when resolving www.epicgames.com and www.okta.com via the default MTN DNS server, it returns an Hetzner IP address but shows WARP as on when accessing https://epicgames.com/cdn-cgi/trace. This suggests a different routing behavior compared to other domains, where clients initially connect to the Hetzner IP but their connection is subsequently routed over a Cloudflare WARP tunnel configured on the Hetzner server.

Overall, while the routing and DNS manipulation are evident, the exact mechanisms and policies remain opaque, and there is no clear visibility into the full extent of the infrastructure or logic behind these behaviors.

Conclusion

MTN Irancell demonstrates a pattern of DNS response spoofing and infrastructure-level routing manipulation for domains under international sanctions. The use of techniques such as WARP tunneling and selective whitelisting enables access to certain services in ways that are not transparent to end users or the broader internet community. Whether these behaviors are the result of misconfiguration or deliberate policy is unclear, and the lack of visibility into the underlying mechanisms raises important questions about accountability and intent.