Fake TLD inside a VPN and forwarding

[Kevin Darcy]

Alistair Mackay wrote:

>I have a 4 site VPN and am trying to run an internal DNS heirarchy
>whilst still providing DNS cacheing to the outside world.
>
>It looks like this
>
>TLD of .local
>
>site1 is authoratitive for .local
>
>Each site has a DNS (variously bind 9.2.1 and 9.2.2) server and is
>authoratitive for its own subdomain i.e.
>
>site1.local.
>site2.local.
>site3.local.
>site4.local.
>
>The server for site1.local is also the server for .local
>
>The zone for .local has the appropriate delegation records for each
>site.
>
>So far, in order to be able to lookup host1.site3.local. from
>host1.site2.local. or any such internal query, I've had to set options
>{ forwarders {}} to point at site1's DNS server. This has the drawback
>that a lookup for an external address (like redhat.com) from site2, 3
>or 4 gets forwarded over the VPN to site1 which then resolves the
>external address when I would prefer it to go direct.
>
>Is there a way to configure forwarding such that only queries for hosts
>in the .local domain are forwarded internally whilst all others are
>not.
>
>None of these servers are authoratitive for any real domains, in fact
>they are all behind firewalls from the Internet at large.
>
You could do selective forwarding, e.g.

zone "local" {
    type forward;
    forwarders { x.x.x.x; y.y.y.y; };
    forward only;|
};

Or, maybe you should follow the conventional wisdom of this group and 
avoid forwarding for this internal namespace completely, e.g.

zone "local" {
    type stub;
    file "local";
    masters { x.x.x.x; y.y.y.y; };
    forwarders { };
};

The "forwarders { }" line is only necessary if you're forwarding 
globally (i.e. forwarding defined in the options block). Otherwise, it 
shouldn't be necessary. Its effect is to cancel forwarding for any subzones.

You could always set up the site-specific servers as slaves of the 
"local" zone, of course, or, for that matter, you could make them all 
slaves of each others' site-specific zones. The config for a slave zone 
would look identical to the "stub" example above, except with "type 
slave" instead of "type stub". In addition to the *hard* reasons why you 
might choose one zone type or another, e.g. slaving doesn't work if the 
master won't allow you to zone-transfer, or if you have an idiot 
firewall admin who won't allow 53/TCP connections, forwarding doesn't 
work if your forwarder doesn't allow recursion, but conversely, 
forwarding sometimes gets around network connectivity problems that 
slaving or stub'bing cannot, only slaving gives you full redundancy in 
case of an extended network outage, etc., there are other factors which 
cause you to choose one zone type over another. Slaving might, for 
example, make more sense than forwarding or stub'bing, if you're able to 
IXFR the zone and/or it doesn't change very often and/or, in accordance 
with your customers' requirements, you can tune the REFRESH/NOTIFY 
intervals to not replicate very often (any of which would mean that the 
replication overhead is low) and/or you have a lot of popular entries 
with low TTLs and/or a wide variety of active names in the zone (either 
of which mean that having a local copy of the zone will obviate a 
significant proportion of your network transactions). There are a lot of 
variables in trying to optimize nameserver-to-nameserver traffic, so 
maybe you want to play a little with the various alternatives to see 
what is the best fit for your situation...

                                                                         
                                                   - Kevin