DNS content blockers cause intermittent DNS failures (DNS_PROBE_STARTED)

Is it a bug?

• I know this is an issue with the app, and contacting Mullvad support is not relevant.

I have checked if others have reported this already

• I have checked the issue tracker to see if others have reported similar issues.

Current Behavior

When any DNS content blocker category (ads/trackers/malware/gambling/social media) is enabled, DNS resolution intermittently fails while connected via WireGuard — browsers show DNS_PROBE_STARTED for all sites. Disabling all DNS content blocker categories immediately restores normal DNS resolution, without reconnecting the tunnel.

Expected Behavior

DNS resolution should work reliably with content blockers enabled, same as with them disabled.

Steps to Reproduce

1. Settings → VPN settings → DNS content blockers → enable one or more categories.
2. Connect via WireGuard to any server.
3. Browse the web — DNS resolution starts failing intermittently.
4. Disable all DNS content blocker categories → resolution works normally again immediately.

Failure Logs

[2026-09-10 12:09:54.817] DEBUG mullvad_daemon: New tunnel state: Connected { ... location: Some(GeoIpLocation { country: "Sweden", city: Some("Stockholm"), hostname: Some("se-sto-wg-008") ... }) }
[2026-09-10 12:09:54.817] DEBUG mullvad_daemon: Settings: ..., dns: ads trackers malware gambling social media
[2026-09-10 12:10:03.602]  WARN hickory_net::udp::udp_client_stream: ignoring response from 127.205.225.200:53 because it does not match name_server: 100.64.0.55:53.
[2026-09-10 12:10:40.004]  WARN hickory_net::udp::udp_client_stream: ignoring response from 127.205.225.200:53 because it does not match name_server: 100.64.0.48:53.
[2026-09-10 12:10:40.004]  WARN hickory_net::udp::udp_client_stream: ignoring response from 127.205.225.200:53 because it does not match name_server: 100.64.0.48:53.

Operating system version

macOS 26.5.2 (Darwin 25.5.0, build 25F84)

Mullvad VPN app version

2026.4

Additional Information

The in-tunnel local resolver (127.205.225.200) forwards queries to the content-blocking resolver pool at 100.64.0.0/24 (address selected by which categories are enabled). The Rust DNS client (hickory-dns) strictly validates that a UDP response's source address matches the exact address it queried, and silently drops it otherwise. In this capture, the queried address shifted between two different 100.64.0.x addresses (.55 → .48) while connected to se-sto-wg-008, with no client-side settings change in between — suggesting the resolver behind that address is not consistently reachable/stable (possibly load-balanced), causing dropped/timed-out queries and no fallback. Happy to provide more log excerpts if useful.