Menu
▾
▴
openvpn-users
|
From: Eric S. J. <es...@ha...> - 2009-08-03 03:49:07
|
running open VPN 2.1_RC19 on Windows 7. scanned the archives a bit but didn't see any discussion on this DNS problem. In a nutshell, I want DNS queries to go to a name server across the VPN only if the query can only be served by that name server. For example, if I'm remote, all harvee.org queries go to my name server on the other end of the VPN. All of the queries go to the local name server. I've had this problem on OS X, XP, Vista, Windows 7, and Linux period from some conversation I've seen on the dnsmasq mailing, it's partly a resolver problem. In any case, on Linux or OS X one can abuse DNSmasq to route queries on a per domain basis. Are there any solutions for Windows seven that will let me resolve names on the local network as well as the remote. Was chatting with someone on IRC and it occurred to me that a reasonable solution would be to build a miniature DNS proxy that would query all of the name servers listed in parallel and returned the answer found. If more than one name server returns an answer, then the first one the search order is considered valid. another reasonable solution, like I said is the dnsmasq one where you look at the domain name and route to a remote name server based on the domain name. It's a little harder to set up automatically but it's also interesting as a solution. in any case, I need a solution real soon now for my Windows box. any help would be wonderful. |
|
From: Jan J. K. <ja...@ni...> - 2009-08-03 09:02:44
|
hi Eric, Eric S. Johansson wrote: > running open VPN 2.1_RC19 on Windows 7. > > scanned the archives a bit but didn't see any discussion on this DNS problem. In > a nutshell, I want DNS queries to go to a name server across the VPN only if the > query can only be served by that name server. For example, if I'm remote, all > harvee.org queries go to my name server on the other end of the VPN. All of the > queries go to the local name server. > > I've had this problem on OS X, XP, Vista, Windows 7, and Linux period from some > conversation I've seen on the dnsmasq mailing, it's partly a resolver problem. > In any case, on Linux or OS X one can abuse DNSmasq to route queries on a per > domain basis. Are there any solutions for Windows seven that will let me > resolve names on the local network as well as the remote. > > Was chatting with someone on IRC and it occurred to me that a reasonable > solution would be to build a miniature DNS proxy that would query all of the > name servers listed in parallel and returned the answer found. If more than one > name server returns an answer, then the first one the search order is considered > valid. > > another reasonable solution, like I said is the dnsmasq one where you look at > the domain name and route to a remote name server based on the domain name. > It's a little harder to set up automatically but it's also interesting as a > solution. > > in any case, I need a solution real soon now for my Windows box. any help would > be wonderful. > > I'd say this is largely off-topic for the openvpn forum, as this is about split-horizon DNS on Windows.... typing in split horizon dns windows in google gave me this: http://homepages.tesco.net/J.deBoynePollard/FGA/dns-split-horizon.html Good luck, JJK |
|
From: Eric S. J. <es...@ha...> - 2009-08-03 12:53:23
|
Jan Just Keijser wrote: > hi Eric, >> > I'd say this is largely off-topic for the openvpn forum, as this is > about split-horizon DNS on Windows.... > typing in > split horizon dns windows > in google gave me this: > http://homepages.tesco.net/J.deBoynePollard/FGA/dns-split-horizon.html the split horizon solutions you point me to are great except I can't modify any servers. Thee condition is caused by open VPN end is localized to that one machine. I believe it's also the responsibility of the client to resolve the problem because I can't go around customizing name servers at a dozen or more locations to handle my remote DNS namespace. That would be so wrong on so many levels. If I didn't it clearly before, I'll say it now. I'm not the only one. I've had this problem at every single client site where I have used open VPN in the past eight years. The vast majority of time it didn't show up because end-users were just people working from their home network and therefore the office DNS could provide all of their Internet DNS related needs. I'm finding more and more technically astute people having local networks at home with miniature DNS setups. I find out about it when they call me saying "when open VPN is running, why can't I access any of my machines at home?" now, if you want to say that it's officially not part of open VPN and people with this problem got to suck it up and start typing IP addresses, do so. I'll find another way to cope. It would be helpful to know how you change resolver data and if there's any way I could intercept that action without recompiling my own version of open VPN. --- eric |
|
From: Joseph L. C. <JC...@ac...> - 2009-08-03 13:49:33
|
>If I didn't it clearly before, I'll say it now. I'm not the only one. I've had >this problem at every single client site where I have used open VPN in the past >eight years. The vast majority of time it didn't show up because end-users were >just people working from their home network and therefore the office DNS could >provide all of their Internet DNS related needs. I'm finding more and more >technically astute people having local networks at home with miniature DNS >setups. I find out about it when they call me saying "when open VPN is running, >why can't I access any of my machines at home?" I'm also following this thread with interest as I lurk before my first setup with OpenVPN. In my PIX that I am replacing, it's called Split-DNS and is obviously intrinsic to the function of the VPN. All of my needs revolve around remote users getting RDP access to their wkst's as we don't allow file sharing through the vpn and most of the files they open are prohibitively large files anyway. My users are trained to connect to the FQDN of their dynamically assigned wkst's which makes my administrative job easy. The cisco split-dns has the search domain setup that *.example.com goes across the tunnel. Simple... I hope you figure this out, if so please post back! jlc |
|
From: Les M. <les...@gm...> - 2009-08-03 15:08:33
|
Joseph L. Casale wrote:
>> If I didn't it clearly before, I'll say it now. I'm not the only one. I've had
>> this problem at every single client site where I have used open VPN in the past
>> eight years. The vast majority of time it didn't show up because end-users were
>> just people working from their home network and therefore the office DNS could
>> provide all of their Internet DNS related needs. I'm finding more and more
>> technically astute people having local networks at home with miniature DNS
>> setups. I find out about it when they call me saying "when open VPN is running,
>> why can't I access any of my machines at home?"
>
> I'm also following this thread with interest as I lurk before my first setup with OpenVPN.
> In my PIX that I am replacing, it's called Split-DNS and is obviously intrinsic to the
> function of the VPN. All of my needs revolve around remote users getting RDP access
> to their wkst's as we don't allow file sharing through the vpn and most of the files
> they open are prohibitively large files anyway.
>
> My users are trained to connect to the FQDN of their dynamically assigned wkst's which
> makes my administrative job easy. The cisco split-dns has the search domain setup that
> *.example.com goes across the tunnel. Simple...
This solves the opposite problem by essentially NATting the DNS answers
from the internal server depending on which side you are on. The
problem that needs to be solved is where someone outside has their own
similar private/local DNS that they need to access for their own LAN
functionality while also having VPN access to the other network. In
this case they will have their own DNS server configured that will most
likely see the 'public' view of the other network even though they have
VPN access. If you substitute the other network's DNS server, they will
lose access to their local resources like printers and file services.
> I hope you figure this out, if so please post back!
For a permanent tunnel, a workable approach is to configure the remote
DNS server as a secondary for the zone(s) that need the private view
from the VPN connection, or to use a forwarder for those zones.
However this depends on the remote DNS server having access to the
tunnel which often won't be the case since it is likely to be embedded
in a NAT router or in a DMZ subnet and not running the tunnel. But, I
don't think there is a good solution where the VPN connection is not
permanent and you need to alternate access between (say) a public web
service without VPN and private names in the same domain when the VPN is
up. The simple-minded thing is to put your private addresses in public
DNS so you don't need to worry about the difference between views, but
that's not a good practice security-wise.
--
Les Mikesell
les...@gm...
|
|
From: Joseph L. C. <JC...@ac...> - 2009-08-03 15:32:03
|
>However this depends on the remote DNS server having access to the >tunnel which often won't be the case since it is likely to be embedded >in a NAT router or in a DMZ subnet and not running the tunnel. But, I >don't think there is a good solution where the VPN connection is not >permanent and you need to alternate access between (say) a public web >service without VPN and private names in the same domain when the VPN is >up. In my case the AD dns name is private, example.local where the companies external dns name is example.com. So the clients local dns being provided by either a small router/isp or like my home, a BIND dns server will never answer queries to the invalid domain example.local. I also am pretty sure that the Cisco client did something specific wrt to the dns config that wasn't just as trivial as adding a secondary nameserver: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htspldns.html Thanks for the info! jlc |
|
From: Les M. <les...@gm...> - 2009-08-03 16:21:37
|
Joseph L. Casale wrote: >> However this depends on the remote DNS server having access to the >> tunnel which often won't be the case since it is likely to be embedded >> in a NAT router or in a DMZ subnet and not running the tunnel. But, I >> don't think there is a good solution where the VPN connection is not >> permanent and you need to alternate access between (say) a public web >> service without VPN and private names in the same domain when the VPN is >> up. > > In my case the AD dns name is private, example.local where the companies > external dns name is example.com. So the clients local dns being provided > by either a small router/isp or like my home, a BIND dns server will never > answer queries to the invalid domain example.local. Windows is sort-of a special case anyway since it has its own concept of names besides DNS. You might make most things work for windows applications by setting a a WINS server address on one side of the VPN and DNS on the other. For an unqualified hostname, Windows will try both netbios (through WINS if available, broadcast if not) and DNS with the default domain(s) appended. -- Les Mikesell les...@gm... |
|
From: Jan J. K. <ja...@ni...> - 2009-08-03 21:26:31
|
hi Joseph, Joseph L. Casale wrote: >> However this depends on the remote DNS server having access to the >> tunnel which often won't be the case since it is likely to be embedded >> in a NAT router or in a DMZ subnet and not running the tunnel. But, I >> don't think there is a good solution where the VPN connection is not >> permanent and you need to alternate access between (say) a public web >> service without VPN and private names in the same domain when the VPN is >> up. >> > > In my case the AD dns name is private, example.local where the companies > external dns name is example.com. So the clients local dns being provided > by either a small router/isp or like my home, a BIND dns server will never > answer queries to the invalid domain example.local. > > I also am pretty sure that the Cisco client did something specific wrt to > the dns config that wasn't just as trivial as adding a secondary nameserver: > > http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htspldns.html > The cisco link explains it pretty well, however: the PIX-client (or Cisco IOS box in general) includes a DNS proxying server ; this DNS proxy can talk to multiple DNS servers and can forward the queries to the appropriate server (i.e. local, over VPN link, over external link, etc). LAN clients in figure 1a in the link above don't know or care what kind of box they're talking to: the DNS server runs on the cisco split-horizon-aware box and takes care of the rest. If you were to replace a PIX *client* with an OpenVPN client appliance then you could do exactly the same: install an open soure equivalent of a DNS proxying server, or abuse dnsmasq. The LAN clients would still query the same DNS server and get the appropriate results back. However, what Eric seems to be seeking is a (generic?) solution to have *each* openvpn client use split-DNS: that would require a split-horizon-aware DNS client for each operating system that he runs the openvpn client on. For Linux/*BSD it would certainly be possible. For Windows? that will be a lot harder to find, I'm afraid... cheers, JJK |
|
From: Eric S. J. <es...@ha...> - 2009-08-03 15:36:41
|
Les Mikesell wrote: > But, I > don't think there is a good solution where the VPN connection is not > permanent and you need to alternate access between (say) a public web > service without VPN and private names in the same domain when the VPN is > up. Solution is a simple name lookup proxy. I don't have the hands to write this kind of code anymore but I'm sure there are pieces out there that can be cobbled into shape. The proxy is injected when the VPN comes up and reinjected every time the DHCP client gets renewed. The default name servers taken from the DHCP client. in a very simplified form (and potentially very wrong), the proxy would do something like: Accept a query look up destination name server based on domain name and if domain name not found, yield default name server. proxy query between requester and destination name server. I'll have to check to see if Python has a library for handling this. I might get lucky. > The simple-minded thing is to put your private addresses in public > DNS so you don't need to worry about the difference between views, but > that's not a good practice security-wise. not to mention what happens when you have the same name inside and out so you can access the same resource identically whether you are inside or out. |
|
From: Les M. <les...@gm...> - 2009-08-03 16:00:59
|
Eric S. Johansson wrote:
>
>> But, I don't think there is a good solution where the VPN connection
>> is not permanent and you need to alternate access between (say) a
>> public web service without VPN and private names in the same domain
>> when the VPN is up.
>
>
> Solution is a simple name lookup proxy. I don't have the hands to write
> this kind of code anymore but I'm sure there are pieces out there that
> can be cobbled into shape. The proxy is injected when the VPN comes up
> and reinjected every time the DHCP client gets renewed. The default
> name servers taken from the DHCP client. in a very simplified form (and
> potentially very wrong), the proxy would do something like:
>
> Accept a query
> look up destination name server based on domain name and if domain name
> not found, yield default name server.
> proxy query between requester and destination name server.
>
> I'll have to check to see if Python has a library for handling this. I
> might get lucky.
You can't do this on the remote side since it won't have access to the
original local DNS. So you'd have to supply a proxy that could run on
every OS where openvpn runs and figure out a reasonable address/port for
it - which sounds harder than adjusting the existing server.
>> The simple-minded thing is to put your private addresses in public DNS
>> so you don't need to worry about the difference between views, but
>> that's not a good practice security-wise.
>
> not to mention what happens when you have the same name inside and out
> so you can access the same resource identically whether you are inside
> or out.
If you don't split views, this can't happen. It is a problem if your
NAT device doesn't allow access to the outside address from the inside
interface, though.
--
Les Mikesell
les...@gm...
|
|
From: Eric S. J. <es...@ha...> - 2009-08-03 17:11:48
|
Les Mikesell wrote: > You can't do this on the remote side since it won't have access to the > original local DNS. the client (remote) side has access to the local name server because it exists in the local resolve.conf. This is sufficient information for a default name server address > So you'd have to supply a proxy that could run on > every OS where openvpn runs and figure out a reasonable address/port for > it - which sounds harder than adjusting the existing server. Well, it's actually less difficult when you consider that someone like me use the VPN in a half a dozen locations such as public access points, libraries etc. There I can't modify the name server because it's not my job or responsibility. All I can control is what's local on my system. > If you don't split views, this can't happen. It is a problem if your > NAT device doesn't allow access to the outside address from the inside > interface, though. yes. If an address translation boundary let you use an external address from the inside, then this problem wouldn't exist. But it still wouldn't solve the original problem that I have a half a dozen sites that I use open VPN from connecting to three or four networks and I need private names from both sides. Right now, for me the difficult part is figuring out how to replace the DHC supplied name server information with the private proxy name server information in resolve.conf every time I get a new lease. And also invoking the conversion script on initiation of a VPN. remember, I'm not saying this is open VPNs problem, only that it's configuration revealed a need to think about DNS a different way. Without VPNs, we wouldn't have this problem |
|
From: Les M. <les...@gm...> - 2009-08-03 17:54:40
|
Eric S. Johansson wrote:
>
>> You can't do this on the remote side since it won't have access to the
>> original local DNS.
>
> the client (remote) side has access to the local name server because it
> exists in the local resolve.conf. This is sufficient information for a
> default name server address
>
>> So you'd have to supply a proxy that could run on every OS where
>> openvpn runs and figure out a reasonable address/port for it - which
>> sounds harder than adjusting the existing server.
>
> Well, it's actually less difficult when you consider that someone like
> me use the VPN in a half a dozen locations such as public access points,
> libraries etc. There I can't modify the name server because it's not my
> job or responsibility. All I can control is what's local on my system.
Usually in a public location you don't rely on their local private DNS
at the same time you need access to the tunneled DNS. I thought we were
talking about a connection between LANs, each with their own respective
private DNS names.
In a simple scenario where you only care about one machine you might
manage by fudging things with an /etc/hosts file that you swap in and
out as needed (or leave in if the names are unique). Or on a Windows
box you might hook DNS to one LAN and WINS to the other's server.
>> If you don't split views, this can't happen. It is a problem if your
>> NAT device doesn't allow access to the outside address from the inside
>> interface, though.
>
> yes. If an address translation boundary let you use an external address
> from the inside, then this problem wouldn't exist. But it still
> wouldn't solve the original problem that I have a half a dozen sites
> that I use open VPN from connecting to three or four networks and I need
> private names from both sides.
>
> Right now, for me the difficult part is figuring out how to replace the
> DHC supplied name server information with the private proxy name server
> information in resolve.conf every time I get a new lease. And also
> invoking the conversion script on initiation of a VPN.
>
> remember, I'm not saying this is open VPNs problem, only that it's
> configuration revealed a need to think about DNS a different way.
> Without VPNs, we wouldn't have this problem
It is a natural consequence of private addressing instead of the
expected hierarchical design. VPNs are just a way of working around
some of the issues - but you'd see the same thing if you connected up
with private physical circuits instead of virtual ones.
--
Les Mikesell
les...@gm...
|
|
From: Eric S. J. <es...@ha...> - 2009-08-03 18:06:53
|
Les Mikesell wrote: > Eric S. Johansson wrote: > > Usually in a public location you don't rely on their local private DNS > at the same time you need access to the tunneled DNS. I thought we were > talking about a connection between LANs, each with their own respective > private DNS names. My local public library has printers I accessed by name. Local names in public location. Remember, the unwashed masses are becoming more sophisticated and we are very rapidly. They tell us how the network should work. :-) > > In a simple scenario where you only care about one machine you might > manage by fudging things with an /etc/hosts file that you swap in and > out as needed (or leave in if the names are unique). Or on a Windows > box you might hook DNS to one LAN and WINS to the other's server. that's not really very practical. The stuff should be flip the switch automatic.in fact, I remember a utility called net switcher back in the days of Windows 95 which did just this. It flipped around Windows configurations for networking so you can work in different locations. Cool but crude >> Right now, for me the difficult part is figuring out how to replace >> the DHC supplied name server information with the private proxy name >> server information in resolve.conf every time I get a new lease. And >> also invoking the conversion script on initiation of a VPN. >> >> remember, I'm not saying this is open VPNs problem, only that it's >> configuration revealed a need to think about DNS a different way. >> Without VPNs, we wouldn't have this problem > > It is a natural consequence of private addressing instead of the > expected hierarchical design. VPNs are just a way of working around > some of the issues - but you'd see the same thing if you connected up > with private physical circuits instead of virtual ones. yes but if we had a bunch of physical circuits or static virtual ones, we can solve the problem through negotiation over what's going to go to a name server because to have a VPN up and running between two organization implies a level of trust. An open VPN, there is no trust implied with the local network but still, you may need names or services from that local network and is nothing he can do to the name server on either side to fix this problem. It has to be fixed on the same machine as you run open VPN. Okay, if there's no serious proxy advice forthcoming, I'll just drop this. I will keep telling people there is no solution for split horizon DNS under Windows. |
|
From: Les M. <les...@gm...> - 2009-08-03 19:56:01
|
Eric S. Johansson wrote:
>
>> Usually in a public location you don't rely on their local private DNS
>> at the same time you need access to the tunneled DNS. I thought we
>> were talking about a connection between LANs, each with their own
>> respective private DNS names.
>
> My local public library has printers I accessed by name. Local names in
> public location. Remember, the unwashed masses are becoming more
> sophisticated and we are very rapidly. They tell us how the network
> should work. :-)
Windows netbios names that you can use as a bare hostname or do they
really have a DNS domain?
>> In a simple scenario where you only care about one machine you might
>> manage by fudging things with an /etc/hosts file that you swap in and
>> out as needed (or leave in if the names are unique). Or on a Windows
>> box you might hook DNS to one LAN and WINS to the other's server.
>
> that's not really very practical. The stuff should be flip the switch
> automatic.in fact, I remember a utility called net switcher back in the
> days of Windows 95 which did just this. It flipped around Windows
> configurations for networking so you can work in different locations.
> Cool but crude
How hard to you think it is to rename a couple of files? Make it a
batch command named for the network where it works.
>>> remember, I'm not saying this is open VPNs problem, only that it's
>>> configuration revealed a need to think about DNS a different way.
>>> Without VPNs, we wouldn't have this problem
>>
>> It is a natural consequence of private addressing instead of the
>> expected hierarchical design. VPNs are just a way of working around
>> some of the issues - but you'd see the same thing if you connected up
>> with private physical circuits instead of virtual ones.
>
> yes but if we had a bunch of physical circuits or static virtual ones,
> we can solve the problem through negotiation over what's going to go to
> a name server because to have a VPN up and running between two
> organization implies a level of trust.
The real point is that both IP addressing and DNS naming are supposed to
be under hierarchal control so there are no conflicts. When it's every
LAN for itself you can't expect them to work together sensibly. You are
also fairly likely to run into the case where even if you did connect to
both private DNS servers you'd be likely to get IP addresses in
duplicated subnet ranges and not know where to route them.
> An open VPN, there is no trust
> implied with the local network but still, you may need names or services
> from that local network and is nothing he can do to the name server on
> either side to fix this problem. It has to be fixed on the same machine
> as you run open VPN.
For windows you can try using netbios locally and dns remotely or vice
versa. A hosts file should work for about anything. Not sure what
happens under windows if you have multiple DNS servers configured and
the domain doesn't exist in the first one tried. I'd expect an
authoritative 'does not exist' would just fail without trying other servers.
> Okay, if there's no serious proxy advice forthcoming, I'll just drop
> this. I will keep telling people there is no solution for split horizon
> DNS under Windows.
There's no general answer because you'd need to know the private
domain(s) on each side and how to reach the corresponding nameservers.
--
Les Mikesell
les...@gm...
|
|
From: Eric S. J. <es...@ha...> - 2009-08-03 20:16:21
|
Les Mikesell wrote: > Windows netbios names that you can use as a bare hostname or do they > really have a DNS domain? I've made DNS work without too much trouble > > How hard to you think it is to rename a couple of files? Make it a > batch command named for the network where it works. it's not just a couple files. Its user interface, how I control for the desktop auto edit it, how I maintain it out of way associated with a VPN invocation and make it go away and it's not. How I refresh the contents of these files with the DNS name server? How often do I refresh them especially if DNS is populated by DHCP clients? it's really not a simple problem from this perspective. > The real point is that both IP addressing and DNS naming are supposed to > be under hierarchal control so there are no conflicts. When it's every > LAN for itself you can't expect them to work together sensibly. You are > also fairly likely to run into the case where even if you did connect to > both private DNS servers you'd be likely to get IP addresses in > duplicated subnet ranges and not know where to route them.h and here lies the crux of the conflict. Networks and their namespace are no longer hierarchical. They are graphs. It's the future and nothing is going to change it back. Search order determines which addresses returned and search order should be something the end user can modify on-the-fly either by command or arbitrary name modification. > For windows you can try using netbios locally and dns remotely or vice > versa. A hosts file should work for about anything. Not sure what > happens under windows if you have multiple DNS servers configured and > the domain doesn't exist in the first one tried. I'd expect an > authoritative 'does not exist' would just fail without trying other > servers. That's exactly right. It's the nxdomain that causes the search to stop which is why parallel requests are interesting search strategy for returning first found/highest priority names. > There's no general answer because you'd need to know the private > domain(s) on each side and how to reach the corresponding nameservers. you have the information you need. You just need to be a little more flexible in how to use it. You get the name server information via your open VPN DHCP request. You also have name server information from the equivalent of resolv.conf. When you have all the name servers lined up in the right order, do a parallel search on all name servers listed. If you get more than one result then you return the first in order of listing address. Yes, this is a resolver wrapper and I don't know how to do it but I believe it can be done either internally or externally through a DNS proxy. |
|
From: Les M. <les...@gm...> - 2009-08-03 21:24:38
|
Eric S. Johansson wrote:
>
>> How hard to you think it is to rename a couple of files? Make it a
>> batch command named for the network where it works.
>
> it's not just a couple files. Its user interface, how I control for the
> desktop auto edit it, how I maintain it out of way associated with a VPN
> invocation and make it go away and it's not. How I refresh the contents
> of these files with the DNS name server? How often do I refresh them
> especially if DNS is populated by DHCP clients?
>
> it's really not a simple problem from this perspective.
The problem isn't simple from any perspective. Sticking the answers you
know you need in /etc/hosts is a simple solution that will sometimes work.
>> The real point is that both IP addressing and DNS naming are supposed
>> to be under hierarchal control so there are no conflicts. When it's
>> every LAN for itself you can't expect them to work together sensibly.
>> You are also fairly likely to run into the case where even if you did
>> connect to both private DNS servers you'd be likely to get IP
>> addresses in duplicated subnet ranges and not know where to route them.h
>
> and here lies the crux of the conflict. Networks and their namespace
> are no longer hierarchical. They are graphs. It's the future and
> nothing is going to change it back.
Working, scalable networks are hierarchical. Anarchy sometimes works,
sometimes not - so the future is broken as far as arbitrary and
unplanned connections go. The thing that might change it back is ipv6.
> Search order determines which
> addresses returned and search order should be something the end user can
> modify on-the-fly either by command or arbitrary name modification.
This does not guarantee the desired answer. And when the answer is a
private IP, there is no guarantee that it is not a duplicate when you
are connecting LANs without pre-arrangement.
>> There's no general answer because you'd need to know the private
>> domain(s) on each side and how to reach the corresponding nameservers.
>
> you have the information you need. You just need to be a little more
> flexible in how to use it. You get the name server information via your
> open VPN DHCP request. You also have name server information from the
> equivalent of resolv.conf. When you have all the name servers lined up
> in the right order, do a parallel search on all name servers listed. If
> you get more than one result then you return the first in order of
> listing address.
Zones that have public/private views are fairly likely to have the same
names configured to return different answers - so you are very likely to
get two different answers from your two queries. And there isn't a
'right' order since each server will see the other zone's public view
and you want to slice only the private view from both.
> Yes, this is a resolver wrapper and I don't know how
> to do it but I believe it can be done either internally or externally
> through a DNS proxy.
The steps you propose would sometimes work, but would take a lot of
os-specific work for each platform that doesn't seem likely to happen.
--
Les Mikesell
les...@gm...
|
|
From: Erich T. <eri...@th...> - 2009-08-03 13:08:16
Attachments:
smime.p7s
|
Eric as JJK pointed out this is a bit off topic here, but lets try Eric S. Johansson wrote: In > a nutshell, I want DNS queries to go to a name server across the VPN only if the > query can only be served by that name server. How do you think a resolver should decide that? By consulting an internal list.... bad idea. What else. So you will have to tell your resolver where to go with a query, unfortunately, or rather fortunately, I think, resolvers are quite stupid. They need a server. Servers on the other hand can be taught to do such tasks. If you are connected to a net across a VPN it is a bit like family membership, unless you are a member you do not know what happens inside the family. So it makes sense that your name resolution is part ot the internal view as soon as you have direct access to that internal net. There is nothing wrong using an internal nema server, what can be wrong is that the internal name server would not service everything you want, but that is not a technical problem. Maybe If you detail a bit more, someone may come up with an idea. cheers Erich |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X