More on BIND 9.1, Views, and Zone Transfers

[Alain Fontaine (Post master, UCL)]

I am still struggling with that question. I am submitting the
description of an hypothetical network, which I have tried to make
as simple as possible, in order to illustrate the question as I see it.

IP-wise:
--------

A range of public (routable) IP addresses is available. Besides that, in
order to save those precious routable addresses, all the machines that do
not need Internet access have private IP addresses. Inside the network,
those addresses are routed normally, so that communication happens
transparently between both kind of addresses.

DNS-wise:
---------

A domain name (example.org) has been requested, and a delegation exists
from the tld servers to the servers ns1.xyz.example.org (primary), and
ns2.xyz.example.org (secondary). There is also a delegation for the
reverse zone for the public IP network, but the details will not be
described here. Both servers are on public IP addresses ; this is
mandatory, since both are known in the parent zone.

All machines having public addresses have names in example.org.
Given the delegation, those name are visible from the Internet, using
either server.

In order to facilitate the operations between the machines on public
addresses, and those on private addresses, it is wanted to associate
domain names with the second category. Of course, the informations
about that second category must not be visible from the Internet, since
giving out private addresses outside of their scope would be erroneous.

Setting up the primary server ns1.xyz.example.org:
--------------------------------------------------

Access-list internal-clients lists the public and private address ranges
of our example network. There are two versions of the master zone file,
one with only the names associated with public adresses, and one with names
associated with both public and private adresses.

view "internal" {
	match-clients { internal-clients; };
	recursion yes;
	zone "." {
		type hint;
		file "named.root";
	};

	zone "localhost" {
		type master;
		file "zone.localhost";
	};

	zone "example.org" {
		type master;
		file "zone.org.example.$int";
		notify yes;
		allow-transfer { "address of ns2"; };
	};

};

view "external" {
	match-clients { any; };
	recursion no;
	zone "." {
		type hint;
		file "named.root";
	};

	zone "localhost" {
		type master;
		file "zone.localhost";
		allow-query { none; };
	};

	zone "example.org" {
		type master;
		file "zone.org.example.$ext";
		notify yes;
		allow-transfer { "address of ns2"; };
	};
};

No problem yet, this works as expected.

Setting up the secondary server ns2.xyz.example.org:
----------------------------------------------------

No name service without at least a second server... The secondary server
will receive queries from both the internal clients, and from the internet.
So it has to use views, too.

view "internal" {
	match-clients { internal-clients; };
	recursion yes;
	zone "." {
		type hint;
		file "named.root";
	};

	zone "localhost" {
		type master;
		file "zone.localhost";
	};

	zone "example.org" {
		type slave;
		file "slave.int/org.example";
		masters { "address of ns1"; };
	};
};

view "external" {
	match-clients { any; };
	recursion no;
	zone "." {
		type hint;
		file "named.root";
	};

	zone "localhost" {
		type master;
		file "zone.localhost";
		allow-query { none; };
	};

	zone "example.org" {
		type slave;
		file "slave.ext/org.example";
		masters { "address of ns1"; };
	};
};

The secondary will indeed select the correct view depending on the
client. But there is a problem when getting the zone from the
primary: since ns2 is an 'internal-client', il will always get the
internal version of the zone from the master. As a result, the
information in both views will be identical, and private data will
leak to external clients.

Question:
---------

How can we make this setup to work correctly ?


                                                    /AF