A DNS leak happens when a system using a VPN connection makes a DNS query using the local Internet Service Provider's DNS servers instead of passing the DNS request through the VPN tunnel to the VPN provider's DNS server (or to any other DNS server of your choice).
If you just drop the outgoing DNS requests on your non-VPN network interfaces, your network access using hostnames may become inconveniently slow (as the necessary DNS queries before each new connection will have to time out before an alternative DNS server, hopefully configured by the VPN, is tried) or effectively stop completely (if your local DNS resolver has not received new DNS servers from the VPN client, and only keeps on retrying the ISP's servers you have blocked).
Instead of just trying to "block the leaks", you should find out why the VPN provider's DNS servers are not getting configured for exclusive use when your VPN connection is activated.
You should first verify that when a VPN connection is activated, the settings referring to your ISP's DNS servers get replaced by other DNS servers configured by the VPN client.
In order to know where you should be looking, first run
grep hosts /etc/nsswitch.conf and look at the output. It will be of the format:
hosts: <some keywords>
This defines the mechanisms used for resolving hostnames.
In place of
<some keywords>, there should be at least
files (referring to
/etc/hosts) and either
resolve. There may be other keywords.
dns means the standard glibc DNS resolver library, that will look for configuration in
/etc/resolv.conf. On Debian-related systems (including *Ubuntu, Mint and the like), this configuration file is often managed by the
resolvconf tool instead of applying changes to
/etc/resolv.conf directly. The
resolvconf tool keeps track of the DNS settings associated with each network interface, both to generate the overall
/etc/resolv.conf according to configurable network interface priorities, and to ensure that appropriate DNS settings are restored when a network interface is shut down.
If your system uses
man 5 interface-order and then check
/etc/resolvconf/interface-order configuration file to verify that your VPN interface will be prioritized higher than the physical interface on top of which the VPN connection runs.
resolve means that a new
systemd-resolved is used; run
resolvectl status to see its configuration. This usually means that
/etc/resolv.conf will only have a
nameserver 127.0.0.53 line in it, redirecting any DNS queries done using the old glibc resolver back into
If a VPN client is unaware of the existence of either the
resolvconf tool or the
systemd-resolved mechanism when either or both of them is used, the result will be a mess. Unfortunately, you'll need to verify that your openvpn service will fully integrate with these tools if they're used on your system.
It is also possible that the
NetworkManager daemon is used for overall control of the network interfaces. This daemon may use
systemd-resolved, or just update
/etc/resolv.conf directly if those other components aren't in use on your system.
Without knowing the name and version of your Linux distribution and your current configuration, it will be hard to give any more advice.
If you want a better answer, please edit your question to include as much of the following information as you can:
- Name and version of your Linux distribution?
- NetworkManager or not?
- what does the
hosts: line in your
- is your OpenVPN service integrated with
resolvconf, or will it edit