Fake TLD inside a VPN and forwarding
Kevin Darcy
kcd at daimlerchrysler.com
Fri Jun 24 23:45:47 UTC 2005
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
More information about the bind-users
mailing list