resolvconf(8) always leaves original DNS server in the list, allowing DNS requests to leak

[Rui Paulo]

On Saturday 18 April 2015 17:18:01 Yuri wrote:
> I am looking at this typical situation: the VPN app creates and sets up
> tap0 interface meant to be the new default route.
> 
> Then it calls this command:
>  > echo "
>  > nameserver <new-DNS-server>
>  > domain
>  > " | resolvconf -a tap0
> 
> Problem:
> 
> /etc/resolv.conf now looks like this:
>  > nameserver <new-DNS-server>
>  > nameserver <old-DNS-server>
> 
> The old DNS server is left at the last position. This means that in
> cases when the new server fails, DNS resolution falls back on the old
> server, therefore allowing DNS requests to leak.
> 
> I looked through the resolvconf man page, and can't find any way that
> application can replace the old DNS server there. It can only add the
> new one for some interface, and in the end remove it. The new server
> "overrides" the old one, but still leaves the old one there. This
> creates the situation when DNS leaks to the old server.
> 
> I would like to suggest the new option:
>  > -x    Make the new DNS server exclusive.
> 
> With this option resolvconf(8) will replace the old server with the new one.

What you want requires scoped routing and scoped DNS, meaning that the network 
stack must have knowledge of what domain names a specific VPN DNS server 
resolves.  The resolv.conf file is completely unsuitable for this purpose.  

The solution you offer is just a hack to avoid the "leak" of DNS domain names 
and doesn't really solve the bigger problem.  What if the VPN DNS server 
doesn't resolve google.com?

-- 
Rui Paulo