vincent.blon...@ing.be wrote:
hello,
little question .. maybe some of you already get this kind of set-up ?
we get in our belgian division some dns resolvers configured to use our
internal dns root servers. Most of the internal dns system but not all
is under the tld intranet. and 10.in-addr.arpa. this is working fine and
nothing special with this.
next to these servers we also get some dns resolvers in gateway area for
giving dns access to our servers hosted in dmz area. so these are
completely two different systems but that technically can speak with
each other.
now my question is .. we should open the internet dns resolution into
the trusted lan. I already tried some different set-up including global
forwarders but nothing found simply till now. problem with global
forwarders is that we only get the choice between "first" and "only" but
not "last".
I should find a solution configuring simply the way to first have a look
at the dns inside and if nothing found forwarding the request to the dmz
servers.
No, that's not the way recursive-resolver failover works. Failover only
occurs if there is no response. But "name does not exist" (NXDOMAIN) is
a perfectly valid and common response, so no failover will occur in that
case.
Since BIND doesn't have a "failover on NXDOMAIN" mechanism, you need to
deal with the fact that you are *not* going to be able to use your
internal-root zone in the nameserver, or in the view, which resolves
Internet names for your "trusted LAN". There is no practical way to mix
the use of an internal root zone, with resolvability of Internet names.
The way I use now in my lab is simply configuring a view in lan and dmz
area, both of them configured with our internal db.root file, stopping
most of the queries on internal dns resolvers with zone "intranet" {type
stub; masters {1.2.3.4;};forwarders{};}; so all my internal queries are
not forwaded to the dmz and finally configuring the dmz area to send
"com" "net" .... to the internet but as I said it this is sure not the
right way to do it.
Have your "trusted LAN" use the DMZ servers for resolution, and then
explicitly define "intranet" and "10.in-addr.arpa" on those servers, and
in that view, as, respectively, either a) type "slave" or "stub", with a
"forwarders { };" definition, or b) type "forward", pointing to internal
servers, "forward only". If you have descendant zones of "intranet"
and/or "10.in-addr.arpa", then you should probably define them here as
well, also with a "forwarders { };" if they are of type "slave" or
"stub". This allows the DMZ servers to use global forwarding without
interfering with the trusted-LAN's ability to resolve
"intranet"/"10.in-addr.arpa" names. If your DMZ servers can talk to
Internet nameservers directly, another option would be to not use
forwarding at all for Internet names. In that case, the "forwarders {
};" for "intranet"/"10.in-addr.arpa" (and any/all descendant zones)
would be unnecessary, even if those zones are defined as "slave" or "stub".
Also add explicit definitions for the other parts of your internal
namespace, unless you're serving a secure *subset* of that namespace to
the Internet. If you're serving a subset of the zone, we'd need to talk
about "split DNS", but you haven't so far indicated that this is a
challenge you're facing.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
