Action behind firewalls

[lazear@gateway.mitre.org (Walt Lazear)]

I've got several sites, each protected from the Internet by a
dual-homed host-based firewall.  There are two DNS servers, one
on the firewall and one behind the FW.  The FW one serves the
Internet and has only the host's RR, plus a wildcard MX for the
domain behind the FW.

The server behind the FW has the details of the domain.  It
has "forwarders" and "slave" lines in its /etc/named.boot file
that direct it to the FW server for unknown names.  So far,
this is the standard "split DNS" setup for firewalls.  It works
well and often :-)

Now I want to change the scene...I want to interconnect the LANs
behind the firewalls with a "community net".  This means that
any host behind anyone's firewall is directly reachable by any
other host behind the firewalls and that the DNS servers behind
the firewalls are the ones that should be contacted.  The real
question is: How should I force the DNS servers to query each
other, but still use the FW server for unanswered queries?

My first approach was to merely add other domains and servers
in NS RRs in the root.cache file.  While these records showed
up in named's database dump, they were effectively ignored.
Requests still went to the FW server for outside resolution.
Outside names were resolved, but names behind the firewall
were not.

Next, we kept the root.cache as modified and removed the
forwarders and slave lines.  Now, the behavior reversed
itself.  Inside names were resolved, but outside names
did not go to the FW for recursive resolution.

So, I need help!!  How do we get the local DNS server to
go to other servers behind the FW and *still* make recursive
queries to the FW for outside names?  Is there some sort
of intermediary server we need to set up, like a fake root?
I'm trying to stay short of having each DNS server behind
the FW be a secondary for every other domain behind the FW.
WHile I think this will work (each server ends up with a
complete database of every host behind the FW), this does not
scale well to 3-40 sites (i.e., lots of zone transfers and
memory required).

Any help in diagnosing and engineering a solution is greatly
appreciated.

	Walt