eah, just make sure you use BIND 9.3.0 or later with this setup. As my
recent findings indicate, earlier versions of BIND appear to have a bug
wherein they can occasionally "poison" their own caches with NS records
from the forwarders' responses (which point to external, possibly
inaccessible nameservers), in the case where you have a CNAME record in
an "external-only" zone, pointing to a name in a "schizophrenic" (used
on both the inside and outside) stub zone. E.g. if
www.example-external.com is a CNAME record pointing to
www.example-schizo.com, and example-external.com is "external-only" (and
thus resolved from the inside only via forwarding), and
example-schizo.com is defined as "type stub" (i.e. used on both the
inside and outside), and the nameserver happens to have no NS records
for example-schizo.com at some particular point in time, then a query
for www.example-external.com will cause the cache to get polluted with
the *external* version of the example-schizo.com NS records reported by
the forwarder, which may break the zone temporarily (until the bogus NS
records time out). BIND 9.3.0 appears to fix this problem, although I
can't find any specific mention of the bug or the fix in the CHANGES file.
Of course, if for some reason one cannot use 9.3.0 or above, a
reasonable workaround -- providing one does not mind the wasteful
zone-transfer traffic -- is to define the zones as "type slave" instead
of "type stub". I suspect most of us who have been bitten by this bug --
all 3 of us :-) -- have probably just changed the stub definitions to
slave definitions to work around the problem, and that's probably why it
was never reported clearly as a bug to ISC...
P.S. Although I've touched on it above, nothing in my "skeletal example"
below supports the actual *hosting* of DNS data to the Internet. If you
wanted to include that, I'd probably divide the config up into 3
different views: 1) a "resolve_internal" view, which would be limited to
clients in your internal address range, and allow them to resolve names
within your internal-root-bounded namespace, 2) a "resolve_external"
view, which would be limited to your proxy and perhaps a handful of
other devices in your BGN (Border Gateway Network) and allow them to
resolve Internet names and internal names under certain enumerated
domains, and 3) a "hosting" view for serving DNS data to the Internet,
which would be open to everyone, but would have recursion turned off, so
no miscreant could use it to resolve names that weren't actually hosted
authoritatively from that view. Really, though, from a security
standpoint -- if nothing else -- at that point you should be considering
splitting up the various nameserver functions among multiple boxes...
Vincent Blondel wrote: