split-DNS: adepartment.adomain.com (was: <empty subject>)

[Mathias Körber]

> Part of a department "adepartment" in our domain adomain.com is
> protected by a firewall. The DNS for adomain.com including
> adepartment.adomain.com is not maintained by us. The hosts behind the
> firewall are not listed in the public dns.

SO you would not even need to touch this part.

>=20
> So we would like to set up a DNS-server (internal DNS) behind our
> firewall. Our wishes for a setup are as follows:
>=20
> 1. Hosts protected by the firewall should be able to resolve other =
hosts
> behind the firewall as well as all other hosts in
> adepartment.adomain.com
> 2. This should be possible without having to include all of the data =
for
> adepartment.adomain.com in our internal DNS-server.
> 3. We would like to achieve this without having to give up our flat
> namespace for adepartment.adomain.com, i.e. not introducing =
subdomains.

>=20
> So the setup should be as follows:
>=20
> The internal DNS should:
> 1. Try to resolve queries for adepartment.adomain.com or forward them =
to
> the public DNS in case the name cannot be resolved. Regulary the DNS
> returns a NOERROR at this point.
> 2. Forward all other requests (i.e. not including
> adepartment.adomain.com) to the public DNS.
>=20
> If I understood P. Albitz' and C. Liu's "DNS and Bind" correctly this
> could be realised using "views" in the upcoming Bind 9.x release.=20

yes.

>=20
> Can anybody give me a hint to solve this problem with standard Bind =
8.x
> ?

Up front: I think you want to have some internal nameserver first
query for hosts in an inside copy of the zone, and if it does not find =
them
there query the outside copy of the same zone. This is not possible, as
the internal nameserver would reply with an NXDOMAIN if it cannot find
 host in the internal copy. Similarly, a nameserver cannot currently be
configured to try another nameserver for the same zone if it received an
NXDOMAIN reply from the first.
You will have to end up making setting up your internal nameserver with
*all* the resource records, including the outside information, so the =
internal
server can resolve that immediately, and only fwd queries for any other =
domain
that adepartment.adomain.com to the outside.



1. You define two copies of the adepartment.adomain.com zone:
	complete:	contains *all* records, those of the internal
			hosts *and* the external hosts. (ie every time
			the external zone changes you'd have to
			edit your copy too, to obtain their changes).
			This *could* be done by
				- obtaining zonetransfer permissions for
				  that zone to some maintenance host,
				- using cron (or similar) to AXFR a copy of
				  the zone (like every morning)
				- munging this data into your internal
				  zone. Note: potential for
				  name conflicts if the outside domain=20
				  manager uses names you already used etc.

	restricted:	contains only the external hosts (this already exists
			as you describe)

You'd set up an internal nameserver which is authoritative for the =
*complete* copy of
'adepartment.adomain.com'.

The internal nameservers would be configured to forward
all queries to some nameservers outside the firewall
(need not be the external auth nameservers!).

Your internal clients use the internal nameserver as resolving =
nameservers (resolv.conf etc).
The internal nameserver (being auth. for the compete copy) will simply =
resolve *all*
queries for data in adepartment.adomain.com, and fwd everything else to =
the outside.


Outside, delegation of your adepartment.adomain.com subdomain goes to =
your external
nameservers as usual, so any nameserver outside the firewall can resolve =
anything
that is in the restricted copy of the zone.

Outside clients use whatever outside nameserver they use and follow the =
proper delegation
to the restricted copy of your zone served by the outside nameservers.

If I didn't overlook anything here, this is a standard split-DNS =
problem, nothing
exceptionally fancy here.