Re: 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



name="named"
rcvar=named_enable

you'ld modify to say instead:

name="named1"
rcvar=named1_enable



named1_enable="YES"
named1_chroot="/var/named1"
named1_pidfile="/var/run/named1/pid"



        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

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: -- modifying all of the other instances of variable name prefixes in the file from named to named1 similarly. Then you'ld put: 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.

signature.asc
Description: OpenPGP digital signature