Bug#612351: resolvconf: move VPN interfaces to the end of interface-order
Package: resolvconf Version: 1.48 Severity: wishlist 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. By VPN interfaces I mean the interfaces that are typically used to reach VPNs or other special networks--probably tun* and tap*--as opposed to the public internet, usually reached by eth*, etc. 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). Also, in bug 460200, the VPN crashed without running resolvconf -d, resulting delays attempting to reach the VPN's nameservers. This is probably a bug in vpnc, but bugs happen, and if the default is to use the standard resolver first, the bug is not as painful. 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. Andrew -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages resolvconf depends on: ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip resolvconf recommends no packages. resolvconf suggests no packages. -- Configuration Files: /etc/resolvconf/resolv.conf.d/base [Errno 2] No such file or directory: u'/etc/resolvconf/resolv.conf.d/base' -- debconf information: resolvconf/bad-pppoeconf-hook: * resolvconf/downup-interfaces: * resolvconf/link-tail-to-original: false resolvconf/bad-pppconfig-hook: resolvconf/linkify-resolvconf: true resolvconf/disable-bad-hooks: true resolvconf/bad-xisp-hook: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612351: resolvconf: move VPN interfaces to the end of interface-order
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org