Accessing internal zones over a VPN

[Kevin Darcy]

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!
>
>  
>