Firewall, split dns and the forwarders directive

Ted_Rule at flextech.co.uk Ted_Rule at flextech.co.uk
Thu Jul 22 18:00:22 UTC 1999



The sneaky use of the forwarders directive in this way  is an enhancement of a
feature which
used to be available via the so-called "noforwarders" patch for bind 4.9.x, This
patch was sadly
never rewritten for bind 8, as it was always intended ( so I understand ) to
incorporate its
functionality in to bind 8's forward zones.

bind 8 introduced the forward zones, but left out one crucial trick which has
now been fixed in bind 8.2.1

You may well find that including a forwarders directive in a master zone is not
listed as a valid
configuration in the named.conf syntax listed on www.isc.org. This is probably
only because they've
not had the chance to update the Documentation on the website to reflect the
change in syntax - it is now
possible to include forwarders directives in all types of zones.

The forwarders setting for a zone determines which set of forwarders are chosen
to look via should
the query fail on "this" server. Hence the split DNS setup for which Cricket has
shown this section

zone "movie.edu" {
    type master;
    file "db.movie.edu";
    forwarders {};
};

actually hinges on the interaction of two forwarders settings - one in the
global options settings, and the
one shown above for the "top-level-internal" zone.

When a query is made to the server for a name which is not currently in the
cache, or which is not in a
pre-loaded zone ( either from a file or a slave-zone-transfer ) , the server
searches all the zones listed
in the configuration for the nearest match to the name, and chooses the
forwarders list from that zone.
If no match is found, it uses the forwarders list from the global options.

It then prefixes this list to the list of nearest NS records it has found for
the query in the cache.

It then queries the list in order, starting with the forwarders.

If the "null-forwarders-in-a-master-zone-Split-DNS" trick is employed, then any
time a query is made
to the server for a name in a subzone of the top-level-internal zone, the server
will prefix a null list of
forwarders to the list of NS records. As a result, the server will query forward
to one of the internal
servers which  are listed as NS records for the subzone and never use the usual
forwarders; which
usually points to a firewall host.

Before bind8.2.1, the only way to achieve the same effect was to list ALL the
internal subzones as
forward type zones with null forwarders lists. Now, with 8.2.1, it is possible
to do it with a single extra
forwarders directive in the top-level master zone on the top-level server.

The compliment to this on all the other internal subzone masters within the
splitDNS tree is that they
really need to have a minimum configuration of

zone "movie.edu" {
    type stub;
    file "stub.movie.edu";
    masters { <ip-address-of-movie.edu-,master zone server > };
    forwarders {};
};

such that at boot time they pick up the NS records for the internal movie.edu
domain, as well as
disabling forwarding for subzones of that domain. Elsewise, the top-level server
knows how to
interrogate all subzones on the internal subzone servers, but the internal
subzone servers don't
necessarily know how to find the NS records for other subzones for which they
are not personally
authoratitive.

And why would you want to bother? Well, I believe its really down to the
possibilities for delegating
responsiblity for the maintenance of internal subzones to different departments
in a large multi-domain
enterprise, AND providing resilience against the loss of firewall DNS services.

Before the advent of all these forwarding tricks, one virtually had to make
every internal server
authoratitive for every internal zone and subzone, which was an administrative
headache.
Without this in place, queries for names in a subzone to a server which was not
authoratitive for the
subzone would have to "route" via the main forwarder - i.e. usually the
firewall.

Now , with this available, all internal servers automatically learn,  by normal
DNS caching,
the whereabouts of all internal subzone NS records , and because
forwarding is effectively disabled for the internal subzones, will "route"
queries to the best possible
server for each query rather than via the firewall. Hence killing the firewall
will lead to loss of internet
DNS connectivity, but not necessarily to loss of internal
inter-subzone-DNS-connectivity.

Does that help to explain the issues?



Ted Rule,
Flextech Television






A.Pirard at ulg.ac.be (André Pirard) on 22/07/99 11:40:28

To:   comp-protocols-dns-bind at uunet.uu.net
cc:    (bcc: Ted Rule/160GPS/Flextech/UK)

Subject:  Re: Firewall, split dns and the forwarders directive




"Cricket Liu" <cricket at acmebw.com> wrote:
>zone "movie.edu" {
>    type master;
>    file "db.movie.edu";
>    forwarders {};
>};

I'm not sure I understand what this does.
Syntaxically, "forwarders" is not listed as an option for a master
zone in the documentation I read on www.isc.org.
Semantically, requests for data in authoritative zones are not
"forward"ed, so, what can be the effect of overriding the
"forwarders"' list for one?

Best regards,

Andr‚.







*****************************************************************
This E-mail message, (including any attachments), is intended
only for the person or entity to which it is addressed,
and may contain confidential information.

If you are not the intended recipient, any review, retransmission,
disclosure, copying, modification or other use of this E-mail message
or attachments is strictly forbidden.

If you have received this E-mail message in error, please contact the
author and delete the message and any attachments from your computer.

You are also advised that the views and opinions expressed in this E-mail
message and any attachments are the author's own, and may not reflect the
views and opinions of FLEXTECH Television.
*****************************************************************



More information about the bind-users mailing list