Skip to content

Restore DNS policy parity under WireGuard - #738

Merged
kasnder merged 2 commits into
masterfrom
codex/fix-wireguard-dns-parity
Aug 20, 2026
Merged

Restore DNS policy parity under WireGuard#738
kasnder merged 2 commits into
masterfrom
codex/fix-wireguard-dns-parity

Conversation

@kasnder

@kasnder kasnder commented Aug 20, 2026

Copy link
Copy Markdown
Member

Summary

  • pause Secure DNS whenever a valid enabled WireGuard configuration owns DNS, including profiles without a DNS = line, so the UI no longer claims that an inert DoH proxy is active and the app does not send DoH outside the tunnel
  • apply the native DNS response policy to decrypted WireGuard replies: record A/AAAA mappings first, then blank SVCB/HTTPS or explicitly blocked-domain answers
  • rewrite IPv4/IPv6 UDP responses with corrected lengths and checksums; gate DNS-over-TCP rewriting on known sequence/frame boundaries and preserve stream lengths
  • expose the existing domain-policy and blocked-RCODE hooks through the WireGuard callback boundary

Verification

  • cargo test: 30 passed
  • :app:testGithubDebugUnitTest: 219 passed, 0 failures
  • assembleGithubDebug: passed, including native C and Rust for all four Android ABIs
  • Pixel 8, GitHub debug installed with adb install -r: existing WireGuard profile with no DNS = line stayed connected
  • live HTTPS-record query through WireGuard returned NXDOMAIN with zero answers after Rust rewriting
  • temporarily enabling Secure DNS produced Secure DNS proxy disabled while WireGuard egress is active; the original disabled preference and active VPN were restored afterward

Known limit

DNS-over-TCP responses split across segments are recorded but deliberately left unchanged. Rewriting those safely requires buffering plus TCP sequence translation; continuation segments cannot be treated as fresh DNS frames.

Closes #734
Closes #736

kasnder and others added 2 commits August 20, 2026 11:52
A computed checksum of zero is mapped to 0xffff only for UDP, where zero
means "no checksum" (RFC 768). TCP has no such convention, so encoding a
zero there corrupted the rewritten segment; because every retransmission
is rewritten identically, the receiver would have dropped each copy and
the DNS-over-TCP lookup would hang instead of failing fast.

Also drop the per-segment clone of the reassembly buffer: the residual
frame can be up to 64 KiB, so cloning it for every arriving segment made
frame detection quadratic in the size of a TCP response.
@kasnder
kasnder marked this pull request as ready for review August 20, 2026 10:18
@kasnder
kasnder merged commit bb1de9d into master Aug 20, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants