bind secure architecture.

bind secure architecture.

Post by Vincent Bl » Sat, 20 Aug 2005 16:39:57


We are currently using Bind on one FreeBSD 4.10 server. This server is directly used by internal users and internet clients.

We decided recently to set up a real DMZ in our IT architecture. This is now done and we are already using an http proxy. Time is now
to consider a complete new architecture for our Bind server.

So I looked on the net for a complete secure and split ( internal , external ) architecture and have found that we coud mix next
features :

- internal root
- split architecture could be done by the "VIEW" feature in BIND 9.x

With such an architecture, we could complete configure all internal servers and subdomains for internal services and set up another
configuration ( usual www, smtp, dns ) for specific external services.
This configuration also involves that the internal root server has to forward the request on the net ( via our dmz gateway BIND Server
) for all domains we are not serving as SOA ( example ).

... and this is my specific problem, I don't immagine how I can configure this.

So can somebody explain me how I can do it and/or eventually give me an example of configuration ???


bind secure architecture.

Post by Kevin Darc » Sun, 21 Aug 2005 09:52:45

No, don't try to mix root server with forwarding. Configure an
"external" view on your internal nameserver, that forwards to the dmz
gateway BIND server. Have the web proxy's address be the only thing that
matches that view. If your web proxy is going to be handling internal as
well as external HTTP requests, then you may have to define the apex of
each domain you use internally as a "type stub". Optionally, if these
zones have any subzones, add a "forwarders { };" to inhibit the
forwarding of queries for any of their subzones. Basically, you're
"overriding" forwarding selectively for those parts of the namespace, in
this "external" view, and forcing the queries to be resolved internally.

Skeletal example:

view "external" {
match-clients { web.proxy.add.ress; };
forwarders { x.x.x.x; };
forward only;

zone "" {
type stub;
file "external/";
masters { y.y.y.y; }; /* my address */
forwarders { };

view "internal" {
match-clients { any; };

zone "." {
type master;
file "internal/root";

zone "" {
type master;
file "internal/";

- Kevin


bind secure architecture.

Post by Vincent Bl » Mon, 22 Aug 2005 17:19:16

many thanks, I will try this as soon as possible.

bind secure architecture.

Post by Kevin Darc » Wed, 24 Aug 2005 10:54:08

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 is a CNAME record pointing to, and is "external-only" (and
thus resolved from the inside only via forwarding), and is defined as "type stub" (i.e. used on both the
inside and outside), and the nameserver happens to have no NS records
for at some particular point in time, then a query
for will cause the cache to get polluted with
the *external* version of the 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...

- Kevin

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: