Report

7 min read MahsaNet Team

Irancell (MTN) DNS behavior with sanctioned domains

Analysis of MTN Irancell's DNS behavior, revealing systematic DNS spoofing for sanctioned services leading to traffic routing through Hetzner, Azerbaijan and Cloudflare WARP, bypassing geo-blocks.

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.

    [MTN1] ⮞ nslookup www.chatgpt.com
    
    Name:      www.chatgpt.com
    Address 1: 159.69.82.202 static.202.82.69.159.clients.your-server.de
    Address 2: 2a01:4f9:c012:564e::1

    As you can see, resolving the domain without a custom DNS will return Hetzner IP addresses.

    When running curl:

    [MTN1] ⮞ curl https://www.chatgpt.com/cdn-cgi/trace
    fl=533f216
    h=www.chatgpt.com
    ip=2a01:4f8:1c1e:6f71::f:3cc
    visit_scheme=https
    uag=curl/8.4.0
    colo=CDG
    sliver=none
    http=http/1.1
    loc=DE
    tls=TLSv1.3
    sni=plaintext
    warp=off
    gateway=off
    rbi=off
    kex=X25519

    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.

    [MTN1] ⮞ nslookup www.chatgpt.com 8.8.8.8
    Server:    8.8.8.8
    Address 1: 8.8.8.8 dns.google
    
    Name:      www.chatgpt.com
    Address 1: 104.18.32.47
    Address 2: 172.64.155.209

    As you can see, resolving the domain with a custom DNS will return the actual Cloudflare CDN IP.

    When running curl:

    [MTN1] ⮞ curl https://www.chatgpt.com/cdn-cgi/trace
    h=www.chatgpt.com
    ip=31.171.100.104
    visit_scheme=https
    uag=curl/8.4.0
    colo=ARN
    sliver=none
    http=http/1.1
    loc=AZ
    tls=TLSv1.3
    sni=plaintext
    warp=off
    gateway=off
    rbi=off
    kex=X25519

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

In conclusion, for the chatgpt.com domain:

DNS resolver Resolved IP Cloudflare observed IP WARP
MTN default DNS Hetzner IPv4 Hetzner IPv6 off
Custom DNS Cloudflare CDN edge Delta Telecom IPv4 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.

[MTN1] ⮞ curl https://cloudflare.com/cdn-cgi/trace --resolve cloudflare.com:443:188.245.228.253

curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

We can see the status for other domains:

URL DNS resolver Resolved IPs Resolved IP ASN / location Cloudflare observed IP Observed IP ASN / location WARP
www.chatgpt.com Not set (MTN default) 88.99.172.132 Hetzner (AS24940) / DE 2a01:4f8:c013:8d84::7:cfca Hetzner (AS24940) / DE off
www.chatgpt.com 8.8.8.8 (or any) 104.18.32.47, 172.64.155.209 Cloudflare CDN (AS13335) / DE 31.171.100.104 Delta Telecom (AS29049) / AZ off
www.epicgames.com Not set (MTN default) 91.107.238.86 Hetzner (AS24940) / DE 104.28.222.14 Cloudflare WARP (AS13335) / DE on
www.epicgames.com 8.8.8.8 (or any) 104.18.20.94, 104.18.21.94 Cloudflare CDN (AS13335) / DE 185.200.233.50 Gulf Bridge (AS200612) / QA off
www.gitlab.com Not set (MTN default) 172.65.251.78 Cloudflare CDN (AS13335) / DE 31.171.101.146 Delta Telecom (AS29049) / AZ off
www.gitlab.com 8.8.8.8 (or any) 172.65.251.78 Cloudflare CDN (AS13335) / DE 31.171.100.50 Delta Telecom (AS29049) / AZ off
www.okta.com Not set (MTN default) 188.245.228.253 Hetzner (AS24940) / DE 104.28.207.215 Cloudflare WARP (AS13335) / DE on
www.okta.com 8.8.8.8 (or any) 104.18.212.105, 104.18.211.105 Cloudflare CDN (AS13335) / DE 31.171.100.45 Delta Telecom (AS29049) / AZ off

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.