mixing internal and internet dns namespace

[Kevin Darcy]

vincent.blondel at 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