Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!news-out.readnews.com!transit3.readnews.com!s09-10.readnews.com!not-for-mail From: jack Subject: Re: how to configure dns fallback for vpn: try different nameserver on NXDOMAIN reply Date: Sun, 17 Jul 2011 22:10:24 +0200 User-Agent: Pot/0.14.2.93 (As She Poured The Soup) Newsgroups: comp.os.linux.networking References: <26a68960-11e8-436e-88cd-f9278346803a@w24g2000yqw.googlegroups.com> X-OS: may the source be with you MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: Lines: 67 NNTP-Posting-Host: bef336ba.usenet-news.net X-Trace: DXC=U[QgJ\7hh\[5JFSHmejT8_^oXGM_6\KVPmX0AG3X_jU_bf4VGD9d]2Ve5lD:F8V9X_\9G0dcfIZ\Pf\W48kQY`QViO1`aQOOJa^P:gO=OmHnHW[ok:lH_cGTR X-Complaints-To: abuse@usenet-news.net Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.networking:414 On Sat, 16 Jul 2011 21:51:38 +0000, Jorgen Grahn wrote: > On Sat, 2011-07-16, Tauno Voipio wrote: >> On 16.7.11 1:20 , mi wrote: >>> When I connect through VPN to a remote lan, I can resolve remote hosts >>> through DNS, but I cannot resolve local hosts anymore. >>> >>> When the VPN connection is established, my /etc/resolv.conf is updated >>> so that my first nameserver is the one on the remote lan. That is >>> fine, and allows me to resolve host.remote.lan, and also public >>> Internet hosts. >>> >>> However, I now cannot resolve host.local.lan, because ns.remote.lan >>> knows nothing about the local.lan zone. The answer it gives (NXDOMAIN) >>> makes my resolver give up. >>> >>> What can I do so that my resolver tries ns.local.lan after receiving a >>> "NXDOMAIN" reply from ns.remote.lan. >>> >> >> VPN is a very generic term: there are plenty of different >> ways to achieve a Virtual Private Network, and at least >> as many different programs to achieve it. > > That's true, but surely his/her problem is pretty clearly stated as it > is, and independent of the VPN technology? > > "mi" is on two different networks, there's a separate DNS for each of > them, and they are not aware of each other (and rightly so). I'm not > sure if there's a good solution for that (but I have never really > thought about it before). One way we have found to get around this is by running a local nameserver, and adding a forwarding zone just for the network on the other side of the tunnel. Let's say our local domain is example.com, and we have a VPN link into somewhere that has a nameserver on 10.123.10.10, which knows about machineXYZ.cust.local and friends. The /etc/resolv.conf points to our local nameserver, which handles generic internet (with a options { forwarders some-public-servers; }, and is authoritative for the example.com zone. Then add a zone like zone "cust.local" IN { type forward; forwarders { 10.123.10.10; }; }; to this. Now requests for 'machineXYZ.cust.local' will be handled by 10.134.10.10. Add a 'search example.com, cust.local' to /etc/resolv.conf, and most things will work as expected. A few things to be aware of: you need to prevent whatever sets up the VPN tunnel from messing with /etc/resolv.conf. Also, if the VPN tunnel is down, the local nameserver will still try to contact 10.123.10.10, and name resolution for local zones is slow. All this can be fixed with a bunch of scripts on tunnel up/down, how exactly depends on what VPN client is used, if the nameserver on the other side is always on the same address, and if the local nameserver runs on the same machine as the VPN client. If there are duplicate host names (both example.com and cust.local have a machinePQR), just asking for 'machinePQR' will resolve to the local one. To get the one on the other side of the VPN tunnel we need to use the full 'machinePQR.cust.local'). j