Dns Leak is possible with bypass DoH endpoints from Apps Script tunnel

[w0l4i]

how about dns leak ?
if this bool set to true req ip comes from iran and can make it dns leak with iran flag
it's ok to be optional but this is the issue that i wanted to present
#439
the local dns module + dns caching + parallel dns over proxy outband is a must we need with this setting even plain text dns is almost secure and fast

[dazzling-no-more]

This is correct, but even with good internet outside of Iran, the full mode was not usable at all. It took forever to open anything for me.

[therealaleph]

@w0l4i — yes, this is a valid concern and the framing in the PR description undersold it. Let me think through it carefully because it shapes a few v1.8.x roadmap items.

Confirming the leak surface:

When tunnel_doh: false (default) and the user is in Full mode (Iran VPS as exit), DoH lookups go:

client → mhrv-rs SOCKS5 → matched DoH host → bypass → plain TCP/443 from client's network →
  e.g. 1.1.1.1:443 (Cloudflare DoH) → query+answer

That direct leg from the client's network exposes:

• Source IP — client's ISP-assigned IP (Iranian ISP for the bulk of users), visible to the DoH provider in their connection logs and to any on-path DPI as the destination IP of an outbound flow
• TCP destination — the DoH endpoint IP, visible to the client's ISP via packet headers (DoH answer/query content is encrypted, but "client X talking to Cloudflare DoH" is itself a signal)
• TLS SNI — chrome.cloudflare-dns.com etc. cleartext on the wire, even with ECH the SNI is often visible. ISP DPI sees: "Iranian residential IP made TLS handshake to known DoH provider, then a few hundred ms later loaded site Y from its IP"

So the DNS leak is real on three axes:

1. DoH provider sees Iran origin — privacy leak to the DoH provider. Marginal since most users already use the same DoH provider with their browser, but the flag-of-Iranian-IP hits the provider's logs even when the user thought they were proxied
2. ISP sees DoH destination — DPI signature for "this user uses encrypted DNS" + can correlate the timing with subsequent flows
3. No latency-distribution defense — query timing differs from typical home-network DoH if the user's mhrv-rs causes bursty patterns

The PR's framing was wrong. "DoH is already encrypted; only marginal property is hiding fact-of-DoH from local network" — but in the Iran threat model, "fact-of-DoH" + IP + correlation IS the leak. ECH isn't yet universally deployed, and even if it were, the IP-to-IP signature is enough for traffic-correlation analysis.

Mitigation paths, ordered by tradeoff:

Path A: Flip default to tunnel_doh: true

Pros: matches the privacy-first default the user expects. Closes the leak surface for v1.8.4+ users who never read the changelog.

Cons: pays the ~2s UrlFetchApp roundtrip per DNS lookup. Page load time visibly worse. DNS amplification risk (browser fires 50+ DNS lookups during a page load, all serial through Apps Script).

Path B: Local DNS module + caching (your suggestion)

Implement a small DNS resolver inside mhrv-rs that:

• Caches answers with TTL
• Resolves over tunnel_doh: true path (through Apps Script tunnel) when entry is missing
• Routes the cached answer back to the client without re-fetching

This is what masterking32's Python relay does — DNS lookups go through the relay, but cache hits avoid the roundtrip. Browser's hot pages effectively pay the tunnel cost only on first lookup. Subsequent lookups are local.

Pros: privacy + reasonable performance after warm-up. No leak since all DNS goes through the tunnel.

Cons: implementation complexity (TTL handling, negative caching, parallel resolution under cache miss). Estimated 2-3 weeks of focused work.

Path C: Per-deployment "outbound DNS" via tunnel-node

In Full mode, send DNS queries through the tunnel-node container's outbound resolver instead of through Apps Script. The VPS resolves; client gets the answer. Bypasses the Apps Script latency for DNS specifically.

Pros: privacy in Full mode + low latency. tunnel-node has resolver capacity.

Cons: only works in Full mode (apps_script-mode users still need path A or B). Adds a tunnel-node responsibility.

Path D: Plain DNS with allowlist for Iran-friendly resolvers

Document the trade-off + offer dns_resolver: "shecan" / "403" (Iran-blessed public resolvers that don't expose user data to foreign DoH providers). Plain DNS is fast + no foreign-IP leak.

Pros: low latency. Iran-compatible.

Cons: still leaks DNS query content to ISP. Doesn't generalize to non-Iran users.

My take, given the threat model:

For the default, I think we should flip to path B implementation as soon as feasible, with an interim hybrid:

• v1.8.5 (in 1-2 days): document the leak surface in bypass_doh_hosts doc comment + README. Keep default tunnel_doh: false but make the trade-off explicit.
• v1.8.6 / v1.8.7 (1-2 weeks): implement basic in-memory DNS cache + inline resolver via tunnel path. Default to caching enabled.
• v1.8.x (3-4 weeks): full DoH-over-tunnel with parallel-on-miss + DNSSEC validation. Default flips to tunnel_doh: true once the cache makes it performant.

For users today who are privacy-conscious in Iran, the immediate workaround is tunnel_doh: true in config.json. They pay the latency, but the leak closes. We document this.

Adding "DNS leak surface in DoH bypass mode" as v1.8.x roadmap item with priority bump alongside your earlier suggestions on the per-deployment quota tracking.

On your "local dns module + dns caching + parallel dns over proxy outbound" suggestion:

Yes, this is exactly the right architecture. DNS-over-tunnel as default with cache, parallel resolution on cache miss, DNSSEC validation if available. masterking32's Python implementation is one reference; we'd want a Rust-native version using hickory-resolver (which is in the v1.8.x roadmap already for #377 anyway — this just bumps its priority and merges scope).

On "even plain text dns is almost secure and fast":

For non-Iran threat models, agreed. For Iran specifically, plain DNS has a different leak (the resolver and ISP see queries), but if the resolver is shecan or 403 (Iranian DNSes that don't relay queries to foreign ad-tech), and the ISP already has the destination IP from subsequent flows, the marginal leak is small. So plain DNS to Iranian resolver + Iran threat model + cached-mostly = often the best practical defense even for Iran users.

Worth offering as a dns_resolver: "shecan" config option alongside the DoH bypass.

Will track in v1.8.x roadmap. Filing this issue as the canonical reference for the DNS-leak / DNS-architecture redesign work. Tagging you for review when the design issue is filed (~1 week).

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[w0l4i]

@w0l4i — yes, this is a valid concern and the framing in the PR description undersold it. Let me think through it carefully because it shapes a few v1.8.x roadmap items.

Confirming the leak surface:

When tunnel_doh: false (default) and the user is in Full mode (Iran VPS as exit), DoH lookups go:

client → mhrv-rs SOCKS5 → matched DoH host → bypass → plain TCP/443 from client's network →
  e.g. 1.1.1.1:443 (Cloudflare DoH) → query+answer

That direct leg from the client's network exposes:

• Source IP — client's ISP-assigned IP (Iranian ISP for the bulk of users), visible to the DoH provider in their connection logs and to any on-path DPI as the destination IP of an outbound flow
• TCP destination — the DoH endpoint IP, visible to the client's ISP via packet headers (DoH answer/query content is encrypted, but "client X talking to Cloudflare DoH" is itself a signal)
• TLS SNI — chrome.cloudflare-dns.com etc. cleartext on the wire, even with ECH the SNI is often visible. ISP DPI sees: "Iranian residential IP made TLS handshake to known DoH provider, then a few hundred ms later loaded site Y from its IP"

So the DNS leak is real on three axes:

1. DoH provider sees Iran origin — privacy leak to the DoH provider. Marginal since most users already use the same DoH provider with their browser, but the flag-of-Iranian-IP hits the provider's logs even when the user thought they were proxied
2. ISP sees DoH destination — DPI signature for "this user uses encrypted DNS" + can correlate the timing with subsequent flows
3. No latency-distribution defense — query timing differs from typical home-network DoH if the user's mhrv-rs causes bursty patterns

The PR's framing was wrong. "DoH is already encrypted; only marginal property is hiding fact-of-DoH from local network" — but in the Iran threat model, "fact-of-DoH" + IP + correlation IS the leak. ECH isn't yet universally deployed, and even if it were, the IP-to-IP signature is enough for traffic-correlation analysis.

Mitigation paths, ordered by tradeoff:

Path A: Flip default to tunnel_doh: true

Pros: matches the privacy-first default the user expects. Closes the leak surface for v1.8.4+ users who never read the changelog.

Cons: pays the ~2s UrlFetchApp roundtrip per DNS lookup. Page load time visibly worse. DNS amplification risk (browser fires 50+ DNS lookups during a page load, all serial through Apps Script).

Path B: Local DNS module + caching (your suggestion)

Implement a small DNS resolver inside mhrv-rs that:

• Caches answers with TTL
• Resolves over tunnel_doh: true path (through Apps Script tunnel) when entry is missing
• Routes the cached answer back to the client without re-fetching

This is what masterking32's Python relay does — DNS lookups go through the relay, but cache hits avoid the roundtrip. Browser's hot pages effectively pay the tunnel cost only on first lookup. Subsequent lookups are local.

Pros: privacy + reasonable performance after warm-up. No leak since all DNS goes through the tunnel.

Cons: implementation complexity (TTL handling, negative caching, parallel resolution under cache miss). Estimated 2-3 weeks of focused work.

Path C: Per-deployment "outbound DNS" via tunnel-node

In Full mode, send DNS queries through the tunnel-node container's outbound resolver instead of through Apps Script. The VPS resolves; client gets the answer. Bypasses the Apps Script latency for DNS specifically.

Pros: privacy in Full mode + low latency. tunnel-node has resolver capacity.

Cons: only works in Full mode (apps_script-mode users still need path A or B). Adds a tunnel-node responsibility.

Path D: Plain DNS with allowlist for Iran-friendly resolvers

Document the trade-off + offer dns_resolver: "shecan" / "403" (Iran-blessed public resolvers that don't expose user data to foreign DoH providers). Plain DNS is fast + no foreign-IP leak.

Pros: low latency. Iran-compatible.

Cons: still leaks DNS query content to ISP. Doesn't generalize to non-Iran users.

My take, given the threat model:

For the default, I think we should flip to path B implementation as soon as feasible, with an interim hybrid:

• v1.8.5 (in 1-2 days): document the leak surface in bypass_doh_hosts doc comment + README. Keep default tunnel_doh: false but make the trade-off explicit.
• v1.8.6 / v1.8.7 (1-2 weeks): implement basic in-memory DNS cache + inline resolver via tunnel path. Default to caching enabled.
• v1.8.x (3-4 weeks): full DoH-over-tunnel with parallel-on-miss + DNSSEC validation. Default flips to tunnel_doh: true once the cache makes it performant.

For users today who are privacy-conscious in Iran, the immediate workaround is tunnel_doh: true in config.json. They pay the latency, but the leak closes. We document this.

Adding "DNS leak surface in DoH bypass mode" as v1.8.x roadmap item with priority bump alongside your earlier suggestions on the per-deployment quota tracking.

On your "local dns module + dns caching + parallel dns over proxy outbound" suggestion:

Yes, this is exactly the right architecture. DNS-over-tunnel as default with cache, parallel resolution on cache miss, DNSSEC validation if available. masterking32's Python implementation is one reference; we'd want a Rust-native version using hickory-resolver (which is in the v1.8.x roadmap already for #377 anyway — this just bumps its priority and merges scope).

On "even plain text dns is almost secure and fast":

For non-Iran threat models, agreed. For Iran specifically, plain DNS has a different leak (the resolver and ISP see queries), but if the resolver is shecan or 403 (Iranian DNSes that don't relay queries to foreign ad-tech), and the ISP already has the destination IP from subsequent flows, the marginal leak is small. So plain DNS to Iranian resolver + Iran threat model + cached-mostly = often the best practical defense even for Iran users.

Worth offering as a dns_resolver: "shecan" config option alongside the DoH bypass.

Will track in v1.8.x roadmap. Filing this issue as the canonical reference for the DNS-leak / DNS-architecture redesign work. Tagging you for review when the design issue is filed (~1 week).

[reply via Anthropic Claude | reviewed by @therealaleph]

shecan and other iranian dns providers are indeed perform dns hijacking and dns poisoning
i propose that plain text dns : 53 > proxy outband and caching system and parallel dns dispatching on client side
dns query > mhrv-rs cleint > gas > tunnel node
this is the pure way to stay intact by those issue's

[therealaleph]

@w0l4i — you're right and I was wrong on Shecan / 403. Walking back the bad recommendation:

Confirming: Shecan (shecan.ir / 178.22.122.100) and 403.online (10.202.10.102) are documented to perform:

• DNS hijacking — return their own A records for certain domains (Twitter, Facebook, etc.) routing to their owned servers (which then fail or serve their own captive portal)
• DNS poisoning — for blocked domains, return NXDOMAIN or invalid records instead of the real address
• Selective answer modification — even for sites they "support", they sometimes modify TTLs or return different IPs to specific clients

So suggesting dns_resolver: "shecan" as a viable Iranian-friendly resolver was wrong. They're effectively another middlebox censor + tracker, not a privacy-preserving alternative to foreign DoH.

The correct architecture is what you proposed:

Client DNS query (UDP/TCP :53)
  → mhrv-rs (intercept all DNS)
  → cache lookup (hit → return immediately)
  → cache miss → query through Apps Script tunnel via UrlFetchApp.fetch() to authoritative resolver (or DoH endpoint)
  → in Full mode: tunnel-node container resolves directly via OS resolver / configured upstream
  → answer cached + returned to client

Where I went wrong in the v1.8.x roadmap framing:

The "DNS-over-tunnel as default with cache" was right. The hybrid mention of plain Iranian DNS was wrong. There's no "low-latency Iranian-friendly resolver" path — Iranian resolvers are themselves part of the censorship apparatus. Every DNS query needs to go through the tunnel (Apps Script in apps_script mode, tunnel-node in Full mode), full stop.

Updated v1.8.x DNS architecture plan:

1. Phase 1 (v1.8.5, 1-2 days): doc-only update. Make bypass_doh_hosts doc comment explicitly call out the IP-leak surface for Iran-threat-model users. Update README. Don't change defaults yet.

2. Phase 2 (v1.8.6/7, ~1-2 weeks): in-process DNS resolver in mhrv-rs:

   • Hijack all :53 outbound from client (or run as a SOCKS5 UDP-associate target — UDP is tricky here but DNS-over-TCP works)
   • Route queries through UrlFetchApp.fetch() to a public DoH endpoint (Cloudflare 1.1.1.1 / Quad9 9.9.9.9) wrapped in JSON-over-POST so it fits the Apps Script protocol
   • In-memory LRU cache with respect for the response's TTL (down-cap to 5 min for safety against poisoned upstream)
   • Negative cache for NXDOMAIN responses (1 min default, overridable)
   • Parallel resolution on cache miss: fire to 3 different DoH endpoints, return the first valid response (defeats individual upstream-resolver censorship)

3. Phase 3 (v1.8.x, ~3-4 weeks): full integration:

   • Default flips to tunnel_doh: true (DoH bypass becomes opt-in for users who explicitly want the latency advantage)
   • DNSSEC validation when upstream provides it
   • In Full mode, tunnel-node has its own resolver (faster path: skip Apps Script for the DNS lookup once tunnel-node is reachable)

Implementation notes for Phase 2:

The Rust ecosystem has hickory-resolver (formerly trust-dns). It supports DoH out of the box, has a clean async API, and we can wrap its outbound transport layer to route through UrlFetchApp.fetch() instead of a raw socket. Estimated 2-3 weeks of focused work for the basic version.

The harder piece is UDP DNS handling (most clients query UDP first, fall back to TCP only on truncation). mhrv-rs's SOCKS5 already supports UDP-associate; we'd intercept queries to *.53/udp and route them through the same path as TCP. Or simpler: only hijack TCP DNS + force clients to TCP via SOCKS5 (some clients do this naturally; others need a hint).

On parallel dispatch defeating censorship:

Excellent point. If we query Cloudflare DoH + Quad9 DoH + AdGuard DoH in parallel, even if Iran's upstream-MITM has corrupted one of them, the other two return real answers and we return whichever first valid response arrives. Effectively impossible for any single upstream to lie about a domain since at least two would have to coordinate.

Filing this issue (#449) as the canonical reference for the DNS-architecture redesign work. Will tag you on the design issue when filed (~3-5 days). The RFC-style design doc will incorporate your suggestions on plain-DNS-over-tunnel + parallel dispatch + caching as the foundation.

Thanks for pushing back on the bad recommendation. The Iranian-resolver framing was a thinko on my part — Iranian DNS providers fundamentally cannot be trusted as privacy-preserving alternatives because they're operating under the same censorship regime that necessitates mhrv-rs in the first place.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}