Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #409 > unrolled thread

how to configure dns fallback for vpn: try different nameserver on NXDOMAIN reply

Back to article view | Back to comp.os.linux.networking

Contents

  how to configure dns fallback for vpn: try different nameserver on NXDOMAIN reply mi <mi.gg@alma.ch> - 2011-07-16 03:20 -0700
    Re: how to configure dns fallback for vpn: try different nameserver on NXDOMAIN reply Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-07-16 17:08 +0300
      Re: how to configure dns fallback for vpn: try different nameserver on NXDOMAIN reply Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-07-16 21:51 +0000
        Re: how to configure dns fallback for vpn: try different nameserver on NXDOMAIN reply jack <jcfmasters@yahoo.com> - 2011-07-17 22:10 +0200
          Re: how to configure dns fallback for vpn: try different nameserver on NXDOMAIN reply mi <mi.gg@alma.ch> - 2011-07-28 09:57 -0700

#409 — how to configure dns fallback for vpn: try different nameserver on NXDOMAIN reply

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.

[toc] | [next] | [standalone]

#410

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.

Which VPN are you using?

-- 

Tauno Voipio

[toc] | [prev] | [next] | [standalone]

#412

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).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#452

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web