feature: keeping system DNS unchanged or use custom DNS

[codl]

hi, I have a local DNS resolver for caching reasons and I want to keep using it when I enable mullvad, but the daemon changes resolv.conf without asking and even monitors it and reverts it every time it is changed. I couldn't find a way to disable this

could an option be added to disable this behaviour?

[Mikaela]

This started affecting me yesterday as my Debian Testing's glibc updated to 2.31-1 which disables passing AD flag to software unless /etc/resolv.conf includes options trust-ad which generally should only happen when there is a local DNSSEC validating resolver running so now I don't get automatic validation of SSHFP records.

I would like the ability to trust systemd-resolved and a DoT server instead of Mullvad's in general also. I think the best case would be if Mullvad had public DoT server accessible also without Mullvad being enabled, so I could use the same configuration regardless of whether I had Mullvad enabled at that moment.

[lonecone]

I love Mullvad. The fact that I can get a VPN service without it storing any identifying information is amazing.

However, blocking ads and tracking urls is more important for security and privacy than using a VPN. So without this feature I'm going to have to stop using Mullvad and move to another service which supports both :(

[erehwonstudios]

+1 : much love to all of you at mullvad, i've been a supporter from the beginning, but allowing us (if not you) to implement DNS filtering is a must. i have devices across every platform and, yes, i have the technical skills to jury rig a solution for some of them but, frankly, i just don't have the time. please, consider a priv DNS option (covered with security warnings and disclaimers), i'm about to drop money on a competitor that i'd much rather give to you.

[atmosblack]

I couldn't have said it better than the last 2 comments. Mullvad is my all-time favorite VPN, but I'd like to use Adguard Home as DNS server on my VPS to block ads etc on all my devices. Setting my own custom DNS has absolute priority for me. Since this thread is going on for years, I'm for sure not the only user wanting this feature.

[p1r473]

This alone is why I am leaving Mullvad. Also- the Windows app requires the DNS Caching service to be enabled. It's almost like the Mullvad guys don't know about DNS stuff....

[tndv]

It is a shame, I'm very happy with literally everything else this VPN has to offer.

[faern]

We know this is a highly requested feature. This is currently blocked on having the infrastructure support not hijacking all sent DNS. After that is done, we can allow the app to set a custom DNS.

[jamesmacwhite]

I guess because it is a common feature seen across a lot of VPN providers that is why there is a fair bit of noise around it, but can't argue with careful and calculated implementation, given DNS leaks are a big problem and very easy to do, which I guess it the main concern here to protect the innocent!

[RandomUserName22]

We know this is a highly requested feature. This is currently blocked on having the infrastructure support not hijacking all sent DNS. After that is done, we can allow the app to set a custom DNS.

Why cannot the app be allowed to use ports 1400/1401?

[faern]

That would be a very messy solution. It would make the custom DNS feature entangled in unrelated things, such as the relay selection parameter algorithm. And it would not work for users who need to use specific ports to escape their network anyway. So instead we wait until the infrastructure team allows enabling and disabling DNS hijacking per connection. It will take a bit longer, but the end result will be so much smoother and cleaner for users.

[itsmekevin212124]

I want to pile on a bit here as well.

Resetting the resolv.conf file basically breaks DNS for anyone who needs anything custom with DNS (kinda what it does), so anything with Pi-hole, OpenNic, NameCoin, private network DNS, some corporate networks, ect. simply don't work with the current Mullvad app. Although it may seem like a good security feature this app also breaks workflow for many users.

Just wanted to point that out for anybody who mat be wondering why the ability to use custom DNS is important. :P

---

Edit: I did also want to say, this might be a good feature to put under the "advanced" section.

[dhaavi]

I just investigated why the Mullvad App could not connect when the Portmaster Application Firewall is running. It turns out that the Mullvad App requires the Windows DNS Client (the dnscache service) to be running, which the Portmaster disables to gain its required system integration.

I would be great to not have the Mullvad App depend on this service, so that all Portmaster users can also use Mullvad.

I can confirm that Mullvad works perfectly if I use the OpenVPN profiles. As Portmaster uses encrypted DNS, there is no DNS interception possible on the VPN server - I understand that this is something that is going on from one of the comments. Although I'd like to understand why this is done.

[faern]

We very carefully filter DNS requests in the client app and hijack them on the servers for privacy reasons. DNS is giving away basically all details about what you do online. So having a VPN tunnel without properly handled DNS is kind of as pointless as not having a VPN tunnel at all, from a privacy perspective.

Maybe the users of certain other third party software are safe without us handling DNS. But in a default installation they are not, so we must take matters into our own hands to guarantee privacy.

All of this was designed before encrypted DNS was a thing. The encrypted DNS "revolution" really cause problems for privacy concious VPN users. They don't need it. The best they can do (in a Mullvad setup at least) is to ask the VPN server inside the tunnel anyway. Modulo ad blocking or other special handling of requests of course. I'm not talking about that here. The app makes sure that all DNS requests go encrypted in the tunnel.

The server side hijacking specifically is designed for users not using our app, but using vanilla OpenVPN or WireGuard. Since their devices might send DNS requests far and wide, we intercept them and make sure they don't leave the server. That way their privacy is kept a bit more intact. But we are working on making this optional. So people can disable this hijacking for their connections. When this is available the app will do it automatically and handle DNS privacy on the client side, allowing a custom DNS to be used if desired.

[dhaavi]

Thanks for the detailed explanation. It is true that DNS is quite tricky when it comes to privacy. Encrypted DNS without a VPN provides a decent amount of security, but not all that much privacy.

Intercepting stray DNS queries is actually a very nice protection against misconfiguration. 👌 Haven't seen this in a VPN before. This adds great value to non-technical users and is vital in bringing more privacy to everyone. In fact, the Portmaster does the same, but locally.

Looking forward to more compatibility when this feature launches!

[atmosblack]

I guess what some consider a bug, for others can be a feature. ;) I was fighting with DNS/VPN settings on iOS over the past days. While on Android it simply works to have an encrypted DNS parallel to a VPN, on iOS the VPN always overwrites and wins over the encrypted native DNS. The only possibility was to connect via IKEv2, have Adguard Pro in split tunnel mode and use my NextDNS settings there to be able to run both DNS & VPN at the same time. It doesn't work with Wireguard (or OpenVPN) unfortunately. Very few VPN clients have a custom DNS option (IVPN, PIA), but then you still have to manually register your IP in nextDNS everytime, which is annoying. That's just iOS though...

What makes it even more annoying is that Mullvad hasn't even managed to give their users a custom DNS option that works on all platforms! So you don't get to the even more advanced challenges with Mullvad.

Until they manage that, I'll stay with PIA - knowing very well, that it's located in the US and has not the best leadership out there, but from a technical perspective it's still the best option if you are an advanced user.

[faern]

Mullvad App requires the Windows DNS Client (the dnscache service) to be running, which the Portmaster disables to gain its required system integration.

This is interesting. We don't directly depend on dnscache. But I assume you are referring to our use of netsh to set DNS servers on the virtual interface then? I guess that command requires dnscache to be running to actually work.

[kayg04]

but then you still have to manually register your IP in nextDNS

I wish they supported ipv6 addresses. As you said, with ipv4, you'd have to register with another service for dynamic DNS. All of that is very inconvenient.

What makes it even more annoying is that Mullvad hasn't even managed to give their users a custom DNS option

If you're on Windows, I currently have a hack running that works. Use YogaDNS to configure NextDNS and have it running alongside the Mullvad app. This leads to your system using NextDNS + Mullvad's DNS (below is a result of both of them connected simultaneously). All the blocked stuff seems to respond correctly.

[dhaavi]

... use of netsh to set DNS servers on the virtual interface then? I guess that command requires dnscache to be running to actually work.

Yes, that is also how I understood it. netsh reported that the service was not running.

[RandomUserName22]

Any ETA on custom dns? I may have to abandon Mullvad until this feature is available.

[arik-gamerlink]

Am I incorrect to assume that this PR addresses this? At least on Android.

[kayg04]

I realize that isn't exactly a fix but if you use the Private DNS feature in settings on Android along with the Mullvad app to connect to the VPN, everything works as intended.

07-Oct-2020 04:15:12 arik-gamerlink notifications@github.com:

Am I incorrect to assume that this PR[https://github.com/mullvad/mullvadvpn-app/pull/2096] addresses this? At least on Android.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub[https://github.com/mullvad/mullvadvpn-app/issues/473#issuecomment-704592115], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AHH6GP7BLYQDTIGXPMUGLP3SJOMXNANCNFSM4FXG7VTQ]. [https://github.com/notifications/beacon/AHH6GP3FDTNJBSCFNBGGMYTSJOMXNA5CNFSM4FXG7VT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFH7TR4Y.gif]

[HK53]

Yesterday I installed NextDNS. It seemed to work alright, but after sleepmode of my laptop Mullvad did not connect because it could not set de DNS. So I am in the ranks.

I found a work around. I stopped NextDNS in the terminal, then reconnected Mullvad with success, and restarted NextDNS. A little bit of a hassle, but it works. No problem to do this for a short while.

Today I installed the recent 2020.8-Beta2 and there is an option to add a custom VPN, but it needs a local ip address.

Am I correct that this custom VPN is (or will become) a solution to the conflict with NextDNS? If so, is there a local ip address to direct DNS queries to NextDNS? And will the NextDNS deamon use the Mullvad tunnel?

[cwmke]

Yesterday I installed NextDNS. It seemed to work alright, but after sleepmode of my laptop Mullvad did not connect because it could not set de DNS. So I am in the ranks.

I found a work around. I stopped NextDNS in the terminal, then reconnected Mullvad with success, and restarted NextDNS. A little bit of a hassle, but it works. No problem to do this for a short while.

Today I installed the recent 2020.8-Beta2 and there is an option to add a custom VPN, but it needs a local ip address.

Am I correct that this custom VPN is (or will become) a solution to the conflict with NextDNS? If so, is there a local ip address to direct DNS queries to NextDNS? And will the NextDNS deamon use the Mullvad tunnel?

For NextDNS I believe you would use 127.0.0.1 as the custom option.

[HK53]

thank you, @cwmke !

I already tried 127.0.0.1 (a wild guess), but Mullvad immediatly blocked, saying 'cannot set dns'.

My problem is also that I have no idea how all these network component relate to each other (native Linux/Ubuntu, with KDE Gui on top, Mullvad, NextDNS)...

regards, H

[pinkisemils]

I installed the NextDNS client on debian-testing with our client 2020.8-beta2 and tested it out via their test server. It works just fine as long as you add 127.0.0.1 to the custom DNS servers. It might help to disable systemd-resolved as it's listening on port 53, the same port NextDNS's client wants to use -

sudo systemctl stop systemd-resolved

This should work, and if it doesn't, I suggest you send us a problem report through the app and mention this issue. It's hard to decipher what's going on without seeing our daemon's logs.

If you're using NextDNS to use DoH or DoT, you could also just use [systemd-resolved] - go to the setup page of your nextdns account to get the config file for you. Then, enable, run the following commands as root:

systemctl enable systemd-resolved
systemctl start systemd-resolved
rm /etc/resolv.conf && ln -s /var/run/systemd/resolved/resolv.conf /etc/stub-resolv.conf

[HK53]

Thank you @pinkisemils !

I tried "sudo systemctl stop systemd-resolved". That does not help. After entering 127.0.0.1 as custom DNS Mullvad blocks. After stopping NextDNS Mullvad agrees to reconnect. After Start NextDNS it stays connected.

Your followup advice is very condensed... I needed to read it several times.

I installed NextDNS already with sh -c "$(curl -sL https://nextdns.io/install)", that was their recommended install.

test.nextdns.io says 'status ok' and 'protocol DOH'.

I copied from my.nextdsn.io/setup the lines under "systemd-resolved" into /etc/systemd/resolved.conf.

I do not know what you mean by 'enable'. I assumed stop and start ... Mullvad? NextDNS? I did both.

I exucuted the three commands you mentioned with sudo. the 'ln -s ..." needed an extra sudo...

Now, after all this done, I still have the problem that Mullvad blocks after resume from sleep. And still the work around of temporarily stopping NextDNS helps.

Please note, my problem is not that NextDNS is not working. My problem is that Mullvad blocks after sleep.

Now what shall I do, or what needs to be done? For me the situation is equal to not using a custom DNS. Should I perform any command to return something to previous setup?

Thanks for your help.

[pinkisemils]

With the systemd-resovled use, I meant to only use systemd-resolved without the NextDNS client. You'd still be using their service, just without their client. So, firstly you'd have to remove or disable the NextDNS client, and then re-enable systemd-resolved.

Regardless, would you mind posting the contents of your /etc/resolv.conf when the daemon fails to apply DNS? Feel free to censor any addresses, just want to see the options used there.

[HK53]

thank you again, @pinkisemils

somehow I managed to get Mullvad and NextDNS living peacefully together, even after resuming from system sleep...

I tried to enable systemd-resolved with NextDNS uninstalled, but that resulted in not being able to load any new webpages at all (no DNS?)

I re-installed NextDNS => new webpages again (relief)

Then, onetime, at resume from system sleep, Mullvad kicked out NextDNS... I noticed this because of a status change on my.nextdns.io. The roles were changed?

Anyhow, at this moment, both Mullvad and NextDNS just continue after resume from system sleep. So my initial problem for posting seems to have been solved.

I would like to understand better what has happened...

Question: do I need to clear config slack w.r.t. systemd-resolved ?

Question: tcpdump does not show any DNS traffic on port 53. Might that mean only now systemd-resolved is effectively stopped? (trying to figure out how this all relates)

Question: are you still interested in some information?

[pinkisemils]

One reason why DNS didn't work via systemd-resolved might be because you didn't link it's resolv.conf to /etc/resolv.conf via ln -s /var/run/systemd/resolv/resolv.conf /etc/resolv.conf. But you don't have to worry about that.

Question: do I need to clear config slack w.r.t. systemd-resolved ?

You can remove the config changes you made if you're not going to use it just for clarity.

Question: tcpdump does not show any DNS traffic on port 53. Might that mean only now systemd-resolved is effectively stopped? (trying to figure out how this all relates)

If you've successfully enabled NextDNS client, it will probably use DoH or DoT, which use different ports.

Question: are you still interested in some information?

I'd be very interested in your /etc/resolv.conf if our app still fails to set DNS.

[HK53]

@pinkisemils everyting is ok now. Many thanks for you assistance!

[HoboDev]

I'm trying the new beta for Linux. Unfortunately I can not start the gui because my Krunner is broken and I don't know how to start it from command line. But when I set a custom dns via cli It overrides the mullvad dns. Is there any options to use it side by side? (Currently I use a script which sets custom-dns to off gets the dns from resolv.conf and sets new custom-dns with both the custom dns and the mullvad dns)

Two things come to my mind: It would be nice to have an option for getting the nameserver without script hackery. Also a hook for a script that runs after connecting.

[faern]

I'm trying the new beta for Linux. Unfortunately I can not start the gui because my Krunner is broken and I don't know how to start it from command line.

The GUI start script is at /opt/Mullvad\ VPN/mullvad-vpn, so you can just run that.

@HoboDev What's your use case for this? That's not what custom DNS was designed for. Custom DNS is for when you don't want to use our DNS resolver in the tunnel. Because you have a special DNS that does ad blocking or where you have some special local subdomains or something. So yes, it switches between the Mullvad one or your custom one on purpose.

If you are fine with having our DNS resolver in the list of resolvers, then why not only having our resolver? Our resolver should work fine, so you don't need to add a second one for redundancy.

[Mattrazol]

Is this feature going to be released for android as well?

[faern]

Yes. Custom DNS will be on Android and desktop.

[Mattrazol]

@faern When will that be available? And if for example I have a Pi-Hole and I set it as my primary DNS will I be able to leave the local IP address of my Pi-Hole as primary and have the secondary handled by the app itself so when I'm not connected to my WiFi network it will fallback on the Mullvad one? I hope that this will makes sense..

[faern]

I don't have an ETA for the next app release. It depends on how well development and internal testing goes. Probably within a few weeks.

No it's not really designed to have a fallback. You either configure it to have a custom DNS or you let it manage DNS internally automatically. Not both. The app can't determine if your pi-hole is available or not in any good way.

[Mattrazol]

@faern what about querying the first and if it doesn't find the domain or it fails than fallback on the secondary (if set) and in case if is not set use the default one from Mullvad?

[p1r473]

+1 here, cant use Mulvad while using Pihole

Are you using wireguard with mullvad @p1r473 ? I think there may be a way to get to use both

I cant connect to Mullvad while Pihole enabled. I got an error about DNS System Preference couldn't be changed.

Support said I am required to use the Windows DNS Caching service, which I don't want, else I need to use OpenVPN Sad, because I wanted to use the Mullvad windows app and not have to use DNS Caching service.

[vr]

what about the "leave my dns unchanged" option ? my /etc/resolv.conf has immutable flag as purpose and i don't want any application to touch it, having to remove that to set again 127.0.0.1 as custom dns is not enough for me.

[sylv-io]

Is there a way to use systemd-resolved stub listener on 127.0.0.53 ? I would like to be able to resolve hosts on my private network, using a custom dns server.

[faern]

:tada: Yesterday we released app version 2021.1 for Windows, macOS and Linux. That version supports custom (local) DNS :tada:

https://mullvad.net/en/blog/2021/2/11/long-awaited-feature-introduced-desktop-app-20211/

This means that you can now go to Settings -> Advanced and set up custom DNS resolver IPs. However, since our VPN servers still hijack all DNS requests going through them only local resolvers are possible. This means you can use ~127.0.0.53 for a resolver running on your system~ (<- this is not supported) or use something like 10.0.0.1 for your router or something.

The same functionality will come for Android in the next release. We have no ETA for when that is. But expect it in a few weeks maybe.

That means most of the functionality in this feature request has now been implemented. I hope it will work well for all of you!

[fooness]

Slightly off-topic, but also somewhat related: Might there be any problems when using Mullvad’s DNS server (IP via: https://mullvad.net/en/help/dns-leaks/) as the upstream DNS of my raspberry pi (with pihole) to prevent DNS leaks? Are there more/alternate Mullvad DNS server IPs in case of downtime or lots of traffic?

[faern]

If you just use our public DNS server as your DNS resolver and don't have a VPN tunnel or anything, then your ISP or anyone else between you and our server will see your requests. Normal DNS is not encrypted. And if you do have a VPN tunnel on the other hand it's a different deal.

We have also just now released our own DoH and DoT solutions (still in beta). You can try that out if you are interested: https://mullvad.net/en/help/dns-over-https-and-dns-over-tls/

For other inquiries about DNS and usage of our infrastructure please contact support@mullvad.net instead as this is not app related.

[TheOriginalCoda]

I have lost hours pissing about with DNS today - when my server is connected to Mullvad all DNS lookups fail. I cant run incoming connections to my public IP either when mullvad is running, all attempts at setting up port forwarding on my account page fail whether using wireguard or openvn - this all works when mullvad is disconnected! Not only that but often a 'mullvad status' request says 'connection blocked... too many clients' which is bananas, and searching for help on the web is fruitless - it finally brought me here to find out that I cant use my local DNS I have set up already, and the new custom-dns settings in the linux client do not work. I've cancelled my recurring payment and will look for something else. Its a shame, I've been happy for years with mullvad but havent tried anything 'outside of the box' until now.

[faern]

@TheOriginalCoda You can set a custom DNS is the app. I'm not sure what part of it / why it does not work for you. However, if the local resolver is on localhost you would need some extra firewall trickery to allow it to reach the internet, since our app would be blocking anything from going outside the tunnel. And any DNS inside the tunnel is currently captured by our relay servers. You can't for example reach 1.1.1.1 inside the tunnel, because the relay would hijack the request. This latter problem is something outside of the control of the app. But the restriction will be lifted very soon. Then custom DNS can go through the tunnel!

As for incoming connections. Yes, our app blocks that as by design. When enabled nothing outside the tunnel is allowed. However, you can manually add firewall rules with higher priority than the rules our app add, and then allow whatever it is you want to allow there. See this comment for some inspiration: https://github.com/mullvad/mullvadvpn-app/issues/2097#issuecomment-799485645

[p1r473]

Can you please make this not require dnscache Windows service?

[dhaavi]

I'm not part of Mullvad, but wanted to add my .2c:

At some point with Windows 10 the dnscache Windows service became a required service. This is very poorly documented. A hint for this is that you cannot turn it off anymore via the service manager, but have to manually edit the registry.

The dependance on dnscache goes so far that even Powershell commands require it to be running and just silently fail if it's not. We ourselves built a firewall that required it to be turned off, which created huge problems. For example, Docker for Windows won't run with the new backend anymore.

My .2c as a developer from another project: It just does not make sense anymore to turn off dnscache. I feel that at this point, turning it off can be seen as a modified operating system.

[p1r473]

I personally dislike dnscache as I run my own DSN server, and during a troubleshooting or whitelisting issue, I have to disable the dnscache so I am getting proper nslookups, unhindered by the cache

[dhaavi]

In that case I would recommend to leave dnscache enabled and use the amazing tool dig. Here is an install guide. This bypasses the Windows dnscache and does lookups directly.

Just be careful when using it while having Mullvad enabled, as - afaik - they catch astray dns queries and redirect them to themselves.

[p1r473]

Thanks, good idea.!