Possible DNS interception on ISP network

[AlienSarlak]

I’m experiencing what appears to be DNS interception on an ISP network in Iran.

A newly configured domain initially works normally for about a day. Then it suddenly stops working, and public DNS resolvers begin returning the same incorrect private IP instead of the real VPS IP.

Authoritative DNS → <PUBLIC_VPS_IP>

8.8.8.8 → 10.10.34.35
1.1.1.1 → 10.10.34.35
9.9.9.9 → 10.10.34.35

Directly querying the authoritative nameserver still returns the correct public IP, and the VPS itself remains reachable by IP.

Interestingly, this also happens with newly created subdomains: they start resolving to 10.10.34.35.

This makes me suspect that the domain is initially unknown to the filtering system, but after approximately one day it is detected and DNS responses are subsequently rewritten to a private sinkhole IP.

I also tried DNS-over-HTTPS, but connections to dns.google:443 timed out.

Has anyone observed similar behavior, and is this consistent with DNS interception/censorship that dynamically discovers and blocks new domains?

I appreciate any help.

[YCistak]

Yes, this is textbook transparent DNS interception, and the sinkhole address gives it away.

10.10.34.35 is not a random private IP. 10.10.34.34/.35/.36 are the well-known addresses Iranian ISPs return for filtered domains — they're the block-page hosts. Getting that back from 8.8.8.8, 1.1.1.1 and 9.9.9.9 simultaneously doesn't mean three independent resolvers agree; it means none of your queries ever reached them.

What's actually happening

Plain DNS is UDP/53 in cleartext. A middlebox on the path doesn't need to be your resolver — it watches for UDP/53, and when it sees a query for a filtered name it injects a forged response. The forged packet arrives before the real one from Google/Cloudflare, your resolver library takes the first answer, and the genuine response is discarded as a duplicate. That's why:

• Every public resolver returns the same wrong answer. They're all being spoofed by the same box.
• Querying the authoritative nameserver directly still works. That query goes to a host the filter doesn't have on its list yet, or on a path the middlebox isn't inspecting.
• The VPS stays reachable by IP. Only the name is poisoned, not the route.

The one-day delay you noticed is the interesting part and it matches what these systems do: the filter learns domains from passive observation. Your new domain is invisible until traffic to it appears, gets classified, and is added to the list. New subdomains getting sinkholed immediately afterwards means the rule landed on the parent zone as a wildcard, not on the individual name.

Why DoH to dns.google:443 timed out

This is a second, separate block, and it tells you something useful. DoH runs over normal TLS, so the DNS payload is encrypted — but the SNI in the ClientHello is not. The middlebox reads dns.google in cleartext, and drops or resets the connection before the handshake completes. Your DoH request never gets far enough to be encrypted usefully.

So: DNS interception at the resolution layer, SNI filtering at the transport layer. Two mechanisms, and fixing only one leaves you blocked.

What actually works

• Resolve through the tunnel, not beside it. Configure Xray's built-in DNS with a DoH server and — this is the part people skip — make sure that DNS traffic is routed through an outbound that isn't freedom. If your resolver query leaves the machine in cleartext or with a readable SNI, you've solved nothing.
• Address the DoH endpoint by IP. https://8.8.8.8/dns-query instead of https://dns.google/dns-query removes the hostname the filter is matching on. Note that many stacks will still send an SNI; where you can, disable it or set it to something unfiltered.
• Stop relying on the domain. If the name is sinkholed, connect to the VPS by IP and put the domain only where it's needed for TLS. With REALITY you're borrowing someone else's certificate and SNI anyway, so your own domain never has to appear on the wire.
• Watch for the domain being burned, not just blocked. Once a name has been classified, rotating to a new one buys you roughly the same day you already measured. Design for that instead of fighting it.

One diagnostic worth running

Send the same query to a resolver on a non-standard port — for example a DoT/DoH endpoint, or your own recursive resolver listening on 5353. If port 5353 returns the correct IP while port 53 returns 10.10.34.35, the interception is port-based and you've confirmed the mechanism in a single test. It's a five-second check that saves a lot of guessing.

[AlienSarlak]

Thanks a lot! I really appreciate your help.

[shakibamoshiri]

Your main domain has already been flagged, then adding subDomain is flagged too.

[AlienSarlak]

I already checked that, and unfortunately, it is the case.