On Jul 17, 10:10*pm, jack <jcfmast...@yahoo.com> wrote:
> 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
Thank you very much for the suggestion with DNS forwarding and
detailed explanations. Sounds indeed like the solution I was looking
for.
In the meantime, I had found an alternative solution by installing
dsnmasq (
http://en.wikipedia.org/wiki/Dnsmasq). It can be configured
to use different name servers for different domains, with lines like
server=/localdomain.lan/192.168.44.1
server=/remotedomain.lan/192.168.81.2
Even though it is mainly designed for home networks, it worked for my
purpose. As far as I understand, it is doing about the same thing than
what you suggest, by taking over DNS on the local machine and doing
the forwarding itself.
Thanks for the help.
mi
Similar Threads
Linear Mode
