Configuring views

[Kevin Darcy]

Helmut Schneider wrote:

>Hi,
>
>I have two views, "internal" and "external".
>
>Am I right that if one zone (which the NS is authorative for) is listed in 
>"external" and an internal client is querying it, that it can only be 
>resolved by asking another secondary?
>
It depends. The resolver of your "internal" view -- which I'm assuming 
is caching-only -- will follow the same iterative-resolution algorithm 
it uses for everything else. So if it happens to select its own NS for 
resolving the query, it'll send a query to itself. What happens then 
depends on which view is selected by the source IP of that query. If, 
for example, you exclude that local IP from the "internal" view, and the 
"external" view is the default, then the query will be answered from the 
"external" view, which is what you want. The "external" view would see 
the query as just another query, nothing special about it.

You might not want to make such an exclusion, however, without careful 
consideration of how this would affect *all* locally-generated queries. 
If the local IP is listed first in /etc/resolv.conf, for instance, you 
might find that you lose the ability to resolve anything that requires 
recursion (assuming that recursion is turned off for the "external" 
view). You could remedy this by either a) selectively allowing recursion 
for the local IP (warning: as well as potentially duplicating cache 
entries, this methodology would, in the absence of a draconian 
allow-query regime, allow Internet clients to see the cached results of 
your local lookups, since answering from cache doesn't require 
recursion), or b) using 127.0.0.1 instead of the non-loopback address in 
/etc/resolv.conf (ignoring the warnings in the _DNS_and_BIND_ book) and 
routing that to the "internal" view.

If you're multi-homed, then this gets even more complicated -- say hello 
to query-source and/or transfer-source.

Note also that modern versions of BIND have the ability to differentiate 
views based on whether the query is recursive or not 
(match-recursive-only). This opens up even more possibilities -- local 
lookups would be recursive, whereas lookups from the "internal" to the 
"external" view would be non-recursive in the absence of any forwarding 
configuration -- but I am hesitant to recommend anything in this area, 
since I've never actually used match-recursive-only in production.

>If so is there an easy way to have such a zone available for both views 
>(except for setting up the zone at "internal" and "external")?
>
See above.

                                                                         
                                       - Kevin