Multiple instances of BIND at startup

[Matthew Seaman]

Jonathan Chen wrote:
> On Wed, May 21, 2008 at 10:21:05PM -0400, Steve Bertrand wrote:
> 
> [...]
>> My authoritative name server (service, eventually cluster) will 
>> eventually house about 500 domains, which I want only recursive DNS 
>> servers that come from the root .tld down to see (no caching).
>>
>> The caching name server (service, and eventually cluster) will see tens 
>> of thousands of our clients requests (we are an ISP) to use as their DNS 
>> lookup, which will perform recursive lookups that we are not 
>> authoritative for.
>>
>> I'm sorry, I don't know how to put it into other words, other than I 
>> want complete separation from dns authoritative and dns caching services 
>> to be disparate.
> 
> 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:
> 
> 	/*
> 		Used by root .tld.
> 	 */
>     view "authoritative"
>     {
>         match-destination
>         {
>             IP-A;
>         };
>         recursion no;
> 
>         zone "my.authoritative.org"
>         {
>             type master;
>             ...
>         };
> 		....
>     }
> 
> 	/*
> 		Use by our client requests.
> 	 */
>     view "caching"
>     {
>         match-destination
>         {
>             IP-B;
>         };
>         recursion yes;
> 
>         zone "my.authoritative.org"
>         {
>             type master;
>             ...
>         };
> 		....
>     }
> 
> 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 
addresses and ports, pid files etc.  You just have to copy the startup 
script to a new name and modify the variable prefix internally -- eg.  This 
chunk at the beginning of the script:


name="named"
rcvar=named_enable

you'ld modify to say instead:

name="named1"
rcvar=named1_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="YES"
named1_chroot="/var/named1"
named1_pidfile="/var/run/named1/pid"

etc. etc. into /etc/rc.conf.  You can put your modified named1.sh rc script 
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 
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

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20080522/ed574656/signature.pgp