Hello to all,
I changed my /etc/resolv.conf file (and his attribute by ``sudo chattr +i /etc/resolv.conf’’) with the following code:
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:
Minimal mDNS resolver library
resolv.conf management framework (resolvconf)
Resolve abstract dependencies into concrete ones
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).
The provider also offers encrypted DNS using pgp.
If OP has
+i set on /etc/resolv.conf, programs that set resolv.conf shouldn’t matter…even systemd-resolved leaves it alone in this case.
For me…Unbound FTW.
I know - the file is locked - but it doesn’t matter if the name servers are not responding - e.g. if they are fenced withing the VPN provider network.
Some old fashioned network trouble shooting may be necessary - to find which name server is actually responding - and why
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: 184.108.40.206 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.
I’m not using a VPN. I removed “openresolv” package but doesn’t work. When I connect by a VPN, his DNS is used (I checked it).
A week ago, that code was:
> # sudo chattr +i /etc/resolv.conf
> # sudo systemctl restart network-online.target
> # https://www.privacytools.io/providers/dns/
> # https://wiki.lelux.fi/dns/resolvers/
> # https://en.wikipedia.org/wiki/Public_recursive_name_server#List_of_public_DNS_service_operators
> options timeout:1
> options attempts:1
> options rotate
> options single-request
> # mullvad
> nameserver 220.127.116.11
> # nordvpn
> #nameserver 18.104.22.168
> #nameserver 22.214.171.124
> # nic.cz/odvr
> nameserver 126.96.36.199
> nameserver 188.8.131.52
> # dns.watch
> #nameserver 184.108.40.206
> #nameserver 220.127.116.11
> # adguard, no filtering
> #nameserver 18.104.22.168
> #nameserver 22.214.171.124
> # dismail.de, filtering
> #nameserver 126.96.36.199
> #nameserver 188.8.131.52
> # adguard, filtering
> #nameserver 184.108.40.206
> #nameserver 220.127.116.11
> # blahdns, filtering
> #nameserver 18.104.22.168
> #nameserver 22.214.171.124
> #nameserver 126.96.36.199
> # dnswarden, the first filtering
> #nameserver 188.8.131.52
> #nameserver 184.108.40.206
> # securedns
> #nameserver 220.127.116.11
> # snopyta
> #nameserver 18.104.22.168
> # nixnet
> #nameserver 22.214.171.124
> # Cisco Umbrella (formerly OpenDNS)
> #nameserver 126.96.36.199
> #nameserver 188.8.131.52
That DNS servers are freely provided by the VPN companies.
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 was suspecting that - hence my comment
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
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.