I'm not quite sure whether this is a problem. If nameserver A cannot resolve a hostname, the system will try nameserver B automagically, then nameserver C until it gets a result. This produces overhead while resolving names, but doesn't break the resolver if there is more than one zone and more than one server. -nik Paul Wouters schrieb: > On Sun, 9 Aug 2009, Trey Nolen wrote: > >> I would like to second this request. I frequently need more than one >> concurrent VPN, and right now I have to do it using virtual machines. > > It's a bit of a hard problem to fix. The way most VPN DNS server swork, > is they assume the VPN supplied DNS server can answer for both the > internal > DNS zones and the external world. So the laptop does not need any > awareness of > where to send which DNS query to. And the /etc/resolv.conf method is > not really suitable for this. > > Now with two VPNs, and two different internal zones, what do you do? If > you would add all VPN supplied nameservers, you will get inconsistent > results. > > And it breaks when you as kfor internal.company1.com at company2.com's > VPN DNS server (you would get the public ansewr, likely an NXDOMAIN). > > The real answer would be a provisioning system where you not only > receive a DNS > server entry, but also a name space for which that server is valid.aBut > I don't think there is any DHCP option for that currently available. > > currently, the best solution would be to preconfigure the two DNS servers > using a local resolving nameserver and specific forwarders, so you say > for > *.company1.com use this DNS, for *.company2.com use that DNS. > > Making unix systems smarter with respect to DNS(SEC) is very much needed > but a work in progress. > > For unbound, this can be dynamically configured using unbound-control. In > fact, if you would apply the nameserver to the given domain name from > DHCP, > you might get close in most cases. > > Paul >
Attachment:
signature.asc
Description: OpenPGP digital signature