Date: Thu, 22 May 2008 06:25:01 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Jonathan Chen <jonc@chen.org.nz> Cc: Steve Bertrand <iaccounts@ibctech.ca>, freebsd-questions@freebsd.org Subject: Re: Multiple instances of BIND at startup Message-ID: <483503AD.60801@infracaninophile.co.uk> In-Reply-To: <20080522035913.GA78449@osiris.chen.org.nz> References: <48345138.8080507@ibctech.ca> <4834599A.1090108@infracaninophile.co.uk> <4834A7B4.9030302@ibctech.ca> <20080521232319.GA57359@osiris.chen.org.nz> <4834B7EE.3000002@ibctech.ca> <20080522020619.GA69543@osiris.chen.org.nz> <4834D891.6050707@ibctech.ca> <20080522035913.GA78449@osiris.chen.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8E947F30733EBB13EBF4DF4E
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Jonathan Chen wrote:
> On Wed, May 21, 2008 at 10:21:05PM -0400, Steve Bertrand wrote:
>=20
> [...]
>> My authoritative name server (service, eventually cluster) will=20
>> eventually house about 500 domains, which I want only recursive DNS=20
>> servers that come from the root .tld down to see (no caching).
>>
>> The caching name server (service, and eventually cluster) will see ten=
s=20
>> of thousands of our clients requests (we are an ISP) to use as their D=
NS=20
>> lookup, which will perform recursive lookups that we are not=20
>> authoritative for.
>>
>> I'm sorry, I don't know how to put it into other words, other than I=20
>> want complete separation from dns authoritative and dns caching servic=
es=20
>> to be disparate.
>=20
> Let's say your authoritative server is listening on IP-A, and your
> caching server is listening on IP-B; both ip-addresses are on the same
> host. We can have a named instance listening on both addresses, with
> multiple views like:
>=20
> /*
> Used by root .tld.
> */
> view "authoritative"
> {
> match-destination
> {
> IP-A;
> };
> recursion no;
>=20
> zone "my.authoritative.org"
> {
> type master;
> ...
> };
> ....
> }
>=20
> /*
> Use by our client requests.
> */
> view "caching"
> {
> match-destination
> {
> IP-B;
> };
> recursion yes;
>=20
> zone "my.authoritative.org"
> {
> type master;
> ...
> };
> ....
> }
>=20
> The "match-destination" inspects the DNS address used by the client to
> query to determine which view to use. Would this suit your purpose?
I believe that the problem is this: even if configured to be an
authoritative server, BIND will respond to a query about zones
outside what it has authoritative data for with data from its cache
if that data is present. As there is only one cache per instance of
BIND, enabling any sort of recursive capability on a server that is
otherwise meant to be entirely authoritative can lead to data leaking
between the authoritative and recursive parts. This opens up the
possibility of tricking a server into caching false data and responding
with it as if it was authoritative.
In answer to the OPs original question -- yes you can start two instances=
of BIND given the obvious requirement that they have distinct network=20
addresses and ports, pid files etc. You just have to copy the startup=20
script to a new name and modify the variable prefix internally -- eg. Th=
is=20
chunk at the beginning of the script:
name=3D"named"
rcvar=3Dnamed_enable
you'ld modify to say instead:
name=3D"named1"
rcvar=3Dnamed1_enable
-- modifying all of the other instances of variable name prefixes in the =
file from named to named1 similarly. Then you'ld put:
named1_enable=3D"YES"
named1_chroot=3D"/var/named1"
named1_pidfile=3D"/var/run/named1/pid"
etc. etc. into /etc/rc.conf. You can put your modified named1.sh rc scri=
pt=20
into /etc/rc.d/ or /usr/local/etc/rc.d/ -- the latter is probably more =
desirable as you won't get prompted to delete the file every time you run=
=20
mergemaster -- and the rcorder stuff will cause it to be started at much =
the same stage in the boot process as the original named.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enig8E947F30733EBB13EBF4DF4E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkg1A7MACgkQ8Mjk52CukIxz4QCdGSaZejcW7t1ME6sbd65Y8Rvn
1CMAn0lkLtKCmaWmWFTxbg+QkKAszIIW
=CTdM
-----END PGP SIGNATURE-----
--------------enig8E947F30733EBB13EBF4DF4E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?483503AD.60801>