'succesful' nsupdate of remote server not persistent across nameserver restart?

Warren Kumari warren at kumari.net
Tue Apr 26 19:22:58 UTC 2016

On Mon, Apr 25, 2016 at 2:34 PM Matthew Pounsett <matt at conundrum.com> wrote:

> On Monday, 25 April 2016, <jasonsu at mail-central.com> wrote:
>> On Mon, Apr 25, 2016, at 10:58 AM, Matthew Pounsett wrote:
>> > It's not clear to me why one would want to destroy/rebuild the chroot
>> every
>> > time you restart the process.
>> Well, here
>> (1) Because I inherited it this way, and
>> (2) The notes' quoted examples did that too, and
>> (3) I'd not yet gotten any/good advice NOT to (security?)
> Unless you have a clear reason to do it (perhaps there's some security
> consideration I haven't thought of) it seems to me it's unnecessary
> complexity that would lead to problems just like this.
I think that some of the justifications for doing something like this is
similar to some of the justifications for running things in a container --
if an attacker does manage to break out of the process they will have a
much harder time persisting. Also, if I do something stupid I can just
restart the chroot / container and all of my stupid gets overwritten with a
known good version...

Not suggesting that chroot with something that overwrites all my changes is
a good idea, just explaining a justification I've heard a number of times...


> TBH, I'm not even sure whether "these days", chroot is still recommended.
>> Apparmor or Docker instead? Is privsep taken care of in current bind so we
>> don't have to worry about it anymore (e.g., the openntpd vs ntpd case)?
>> I'm not clear on it.
> Although BIND 9 has never had a remote code execution exploit that I'm
> aware of, it's still advisable to run it in a chroot environment.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160426/c540fb9f/attachment.html>

More information about the bind-users mailing list