[Resolvconf-devel] Bug#612351: resolvconf: move VPN interfaces to the end of interface-order

[Bob Proulx]

Andrew Pimlott wrote:
> Currently, tun* is ahead of eth* in /etc/resolvconf/interface-order.  I
> think that putting the VPN interfaces at the end may be a better
> default.

Neither the current nor the proposed solution is without problems.
But I disagree with your suggestion and so wanted to log a dissenting
opinion into the discussion.  However some type of improvement to the
situation would be welcome if we can figure out a good way to do it.

Before I say too much let me note that I am most familiar with the
Lenny version of resolvconf.  I need to become more familiar with the
Squeeze version and what I say may be stale.  Sorry.

> I suggest this because, in typical use, most resolver requests are for
> the public internet and can be handled by the "standard" resolver, which
> is usually faster and more reliable than the resolver on the VPN
> (typically running on a crappy VPN gateway and managed by an overworked,
> underfunded, or incompetent corporate IT department).

In the typical case where I see VPNs configured it is to access hosts
behind a firewall.  Because if the hosts were immediately available
then there wouldn't be a need for the vpn.  In that case the names of
those hosts are not publicly known.  Using the public dns fails in
that case.  The private dns is required in order to get the private IP
addresses of them.  Therefore in this typical case the tun* dns
nameservers are needed to be used instead of the public dns
nameservers.  But unfortunately it isn't that simple.

There is a critical difference in operation depending upon whether the
host has a local caching nameserver configured or not.  If not then
/etc/resolv.conf will list nameservers and the first one listed will
be used for queries.  Only after a timeout will a process fallback to
a subsequently listed nameserver.  Otherwise the first one listed will
receive all queries.  Not having one is simpler but it is also slower
and the failure mode is unpleasantly slow as it falls back.

But in this case having tun* ordered first makes things work normally
with the least thinking.  Reversing this would completely break the
simple configuration.  This is why I am the dissenting voice against
the proposed change.  (But wait, there is more.)

If there is a local caching nameserver configured (my preferred
configuration) then things are completely different.  And this is
where resolvconf is really useful, gluing everything together.  In
that case the local nameserver in /etc/resolv.conf is the localhost.
There is only the one and all queries go there.  In that case the list
of available nameservers will be put into the (let's assume bind9 for
sake of simplifying the discussion) /var/run/bind/named.options file.
In that case the local bind nameserver will load balance queries among
the pool of available servers.  That creates a problem.

In the case of the local nameserver upstream queries will load
balance.  (This is somewhat dependent upon daemon versions since in
the past there have been code changes there.  The load balancing isn't
simple either.  It is version dependent.  Sigh.)  This means that
randomly you will be able to resolve private addresses (hits private
nameserver) and randomly you will not (hits public nameserver).  For
things to work we want all queries to go to the private vpn
nameserver.

To handle this case and after some discussion with the maintainer I
modified the scripts locally to *replace* (replace, not reorder) the
public dns nameservers with the private vpn tun nameservers.  With
this modification the local caching nameserver load balances among the
private vpn tunnel nameservers.  And when the tunnel is down
resolvconf restores the public nameserver list.

This works extremely well.  So well that I am thinking of filing a
wishlist asking for this configuration to be made the default.  :-)

> Of course, this is just my use case, and you may have more information
> about other use cases where this thange would break things.  Just
> offering it as an idea.

And so I jumped in.  :-)

There is definitely some room for some type of improvement.  And I
don't think there will be a one size solution that will fit everyone.
But something that can be more adaptive would be welcomed.  But let's
not simple reverse the order or it would definitely break the simple
case.

Bob