chroot-ed bind 9 (was: Users Want *Seamless* Solutions, Not Patchwork)

[Kevin Darcy]

My opinion is that Dynamic Update-enabled masters don't belong on the public
Internet. If you want to maintain your Internet domains via Dynamic Update,
then put your master on the inside and replicate out to the
publically-accessible slaves, i.e. the so-called "hidden
master" configuration. Even if some or all of the updates originate from the
public Internet (crypto-authenticated, presumably), the slaves can be
configured to forward those updates back to the hidden master.


- Kevin

Donald Nash wrote:

> In article <9jsjlq$dp8 at pub3.rc.vix.com>,
>  Brad Knowles <brad.knowles at skynet.be> wrote:
>
> >       You must have a hard time running secondary nameservers that are
> >never able to write file versions of the zones that they transfer.
>
> I forgot to mention that this was for a strictly primary nameserver
> without any dynamic zones.  For a secondary nameserver, I'd put the
> secondary zone files on their own separate partition to which BIND would
> have write access.  In this case, cleaning up after a compromised BIND
> would consist of installing a fixed BIND and deleting all the secondary
> zone files.  Since they're just copies, it doesn't matter if they get
> trashed since they can be restored from the primary nameserver.
>
> Dynamic zones present a bigger problem since the primary nameserver must
> have write access to the master copy.  We're not doing that yet, so I
> haven't given it any thought.