This has always worked until a few a days ago. I sometimes check my network at ipleak . net and I noticed that after the last or the previous system update it seems the resolv.conf file is ignored (it isn’t read).
the output of ``pacman -Qs resolv’’ is the following:
It is not clear to me why you want to restrict the name servers your VPN providers DNS.
This may be due to you not being on the VPN providers network - but I don’t know with if their servers are publicly available.
Some DNS servers only respond if you are connected to the network and you seem to be using VPN. The dns resolver daemon will query the servers listed in resolv.conf until a working answer is retrieved. The answering name server is then used for subsequent queries.
If you want to manually control your resolv.conf - you should remove the resolvconf package.
sudo pacman -R resolvconf
Anonymous (no logging) DNS services exist and are freely accessible to anyone. E.g. uncensoreddns.org which I use as fallback for my local name server (using root servers thus bypassing my ISP).
Maybe it is only the web browser - which may indicate the browser is using the vendor DNS - an annoying method - but more common - the argument is - it prevents a bad UX when the browser don’t load the page.
You could just set up Mullvad’s DNS as your primary DNS servers.
Mullvad’s public, non-logging DNS server IP: 193.138.218.74 before establishing a tunnel,
10.64.0.1 if you use Wireguard or 10.8.0.1 if you use OpenVPN for use when connected.
These servers are accessible only when you’ve established a tunnel.
Believe this is done by the default config scripts even if you don’t use the GUI, when configuring the routing.
Just try connecting and check your DNS after establishing a tunnel using your NS lookup tool of choice.
Being inside the VPN (hence encrypted) and non-logging, I’d say that covers your back.
NOTE FOR FIREFOX USERS:
If you use Firefox, also make sure Firefox Options > General > Network settings > Settings -> Enable DNS over HTTPS is DISABLED to avoid DNS requests getting leaked to Cloudflare.
Mullvads VPN servers will even hijack any attempt to use the non-tunneled DNS resolver and route it to the inside of the VPN, which is pretty neat when using the default / custom via their config generator configuration scripts for Wireguard or the GUI client.
Thank you, I disabled “dns over https” and now it works. When I’m using a VPN, I noticed that even if “dns over https” is enabled, it is being used those (DNS servers) of the VPN.
I don’t know all publicly available DNS - but usually - the VPN provider’s DNS is only accessible inside the provider’s network (my use of the term fence*).
There are several Modes to DoH for Firefox
in about:config the network.trr.mode has following
0 - Default value in standard Firefox installations (currently is 5, which means DoH is disabled)
1 - DoH is enabled, but Firefox picks if it uses DoH or regular DNS based on which returns faster query responses
2 - DoH is enabled, and regular DNS works as a backup
3 - DoH is enabled, and regular DNS is disabled
5 - DoH is disabled
Mullvads VPN servers will hijack any attempt to use the non-tunneled DNS resolver and route it to the one inside the VPN, unless you disable it in the VPN configuration files.
Also, the public DNS is non-logging and only used to resolve names until a tunnel is established.
Best bet is to not tinker to much with DoH and other half finished standards, as it is superfluous when using the method I described in the original answer.
Use this link to check for leaks: mullvad[dot]net/en/check
(can’t post links or pictures )
You should see all but the first green on an open, non-tunneled connection
and all green lights if connected.
As @freed00m mentioned, the about:config -> network.trr.mode = 5 is probably not a bad idea to add to the mix, as Firefox will try to use Cloudflare if it is enabled, though I believe this will also get routed to Mullvad’s internal VPN servers by default while connected, but not when surfin the open seas.
To get rid of the WebRTC leaks, add media.peerconnection.enabled = false as well.
As I don’t use IPv6, I also add: network.dns.disableIPv6 = true and network.notify.IPv6 = false