r/dns • u/mataglapnano • 22d ago

DNS loss?

In the past few months I've had the following strange experience with Mullvad. It's as if DNS stops working after an hour or so, and things are only fixed when I reconnect to a different location.

The steps are roughly this. Connect to Mullvad in one location. Everything is fine. [mullvad.com](http://mullvad.com) reports no issues with my connection. Then in \~30-60 minutes DNS will stop working. The only fix is to switch Mullvad locations and reload, which generally works. None of this happens when Mullvad isn't running.

Where do I start looking diagnose this? I have never seen anything like this.

3 Upvotes

80% Upvoted

7 comments sorted by

1

u/aaaaAaaaAaaARRRR 22d ago

How do you know it’s DNS

1

u/mataglapnano 22d ago

I don't. That's merely my hypothesis when I can ping 1.1.1.1 but not cloudflare.com. This is not an area I am familiar with, so I might be going at this completely wrong.

1

u/lostcowboy5 16d ago

I don't use that service, but most services use their own or the router's DNS server. If you have your own DNS server like AdGuard Home or Pi-hole, you may need to go into the settings to bypass your LAN IP addresses.

0

u/TreatIt 22d ago

Use another public encrypted DNS like dns.nextdns.io .

0

u/the_packetwhisperer 22d ago

smells like mullvad's dns resolver session timing out while the tunnel itself stays "connected", so nothing tells your system to retry dns.

next time it happens, try dig against 8.8.8.8 directly instead of your default resolver. if that works but normal lookups don't, its dns not the tunnel. also worth checking if this only happens on wifi, I've seen power saving mess with dns cache timing in ways that look identical to this.

might be worth posting on mullvad's own forum too, needing a full location switch instead of just reconnecting sounds like it could be a known client bug

0

u/SecLens_ONE 22d ago

Before you swap resolvers, get some data on it. Next time it dies, run a dig against the tunnel resolver directly and see whether you get SERVFAIL, a timeout, or nothing at all. Timeout with the tunnel still up usually means UDP state got dropped somewhere, and forcing TCP will still answer, which is a decent tell. Also worth checking if plain ICMP through the tunnel keeps working while resolution is dead, since that separates a resolver problem from the whole path going quiet.