Re: Accessing internal zones over a VPN

Anthony Chavez wrote:

>Topology:
> ----- ----- ------
>LAN1<->|FW1|<->Internet<->|FW2|<->LAN2<->|DNS1|
> ----- ----- ------
> |
> R1
> |
> v
> ----- ----- ------
> |FW3|<->VPN<->|FW4|<->LAN3<->|DNS2|
> ----- ----- ------
>Notes:
>R1: static route diverting traffic destined for LAN3
>FW1: BIND8.3.6-REL-p1 (slave DNS for LAN1 and LAN2)
>DNS1: BIND8.3.4-REL (master DNS for LAN1 and LAN2)
>DNS2: BIND9.2.3 (master DNS for LAN3---slaves are on the Internet)
>
>All firewalls are fully capable NAT routers/packet filters.
>
>Problem:
>I want to enable a subset of machines in LAN1 to be able to query DNS2
>for LAN3's zone file.
>
>Hypotheses:
>When the subset queries the DNS on FW1, it gets an NS record and an
>associated A record containing the FW4's external IP. It needs to
>somehow get DNS2's IP instead.
>
>FW4 is a NAT router, which means that all queries to DNS2, including
>those inside LAN3, appear to come from FW4. Therefore, FW1 is where the
>configuration must take place.
>
>One possible solution could involve additional static routes and NAT
>routing along the path from LAN1 to FW4's external subnet.
>
Well, it's not going to be pretty however you implement it. What comes
to my mind is to set up the zones of interest as "stub" zones on a
separate nameserver, nameserver instance (running on a different
interface of the same box, using "listen-on") or (if you're willing to
upgrade to BIND 9) a separate "view", which serves only the
client-subset you care about. These "stub" zones would pull their NS/SOA
data from DNS2, and everything else in that nameserver (or nameserver
instance, or "view", depending on how you set it up) would forward to
the regular FW1 nameserver (or nameserver instance or "view") for normal
resolution.

I'm assuming, based on your description of what you're trying to
accomplish, that DNS2 is authoritative for all of the zones you'd be
looking up. If that's the case, then you could probably also accomplish
the same thing with per-domain forwarding ("type forward" zones) instead
of "stub" zones. If DNS2 does not support recursion, however, then you
may get some spurious warning messages in the logs about your forwarder
being non-recursive.

Regardless of whether you choose "type stub" or "type forward" zone
definitions, it should only be necessary to define the apex of each
domain involved here, i.e. only "example.com", not "foo.example.com",
"bar.example.com" and so on. If you go with "type stub", though, make
sure you specify "forwarders { };" in the definition of each apex zone,
otherwise the global forwarding will take over and send queries for
subzones to the wrong place.


- Kevin

>
>Bonus question:
>How can I accomplish the same thing in reverse, i.e., how can I enable a
>subset of machines in LAN3 to be able to query FW1 for LAN1/LAN2's zone
>files?
>
>I've done some research into a solution for this, but so far have come
>up empty. Any suggestions would much be appreciated!
>
>
>