Enable systemd hardening options for named

[Ludovic Gasc]

2018-01-16 11:58 GMT+01:00 Reindl Harald <h.reindl at thelounge.net>:

>
>
> Am 16.01.2018 um 11:46 schrieb Tony Finch:
>
>> Robert Edmonds <edmonds at mycre.ws> wrote:
>>
>>>
>>> I would guess that retaining CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE
>>> during the process runtime permits open-ended reloading of the config at
>>> runtime (e.g., binding to a new IP address on port 53 without needing to
>>> restart the daemon).
>>>
>>
>> BIND since 9.10 listens on the routing socket so it can spot network
>> interfaces coming and going automatically, without needing an explicit
>> `rndc reconfig` or `rndc scan`. This works very nicely with `keepalived` -
>> I use it for failover in my production resolver cluster.
>>
>
Good to know, thanks for the information.


> (I avoid systemd: journald makes it so difficult to get logs out that I
>> get angry every time I encounter it, and systemd has a habit of believing
>> that a service is working when it isn't. I've had enough pain in test
>> environments that I don't want to use it in production.)
>>
>
> well, complete infrastructure running from 2011 until now with systemd


The goal of my e-mail wasn't to have a debate about the interest of systemd
:-)

Personally, we use systemd+journald on production since 2015. Even if the
beginning was complicated, the time we needed to learn and especially about
performances issues in journald, since we use systemd backports on Debian,
it's OK now. And we have upgraded to Debian stretch, nothing special to do
anymore.

However, it's technically possible to replace most systemd features by
several other technologies, and certainly with more options.
Nevertheless, from my past experience with other solutions, systemd is good
enough for most use cases.

While nobody forbids me to use systemd features, it's OK for me that other
people use other technologies ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180116/ded95dfa/attachment-0001.html>