[dns-operations] DNS at FOSDEM 2016
edmonds at mycre.ws
Wed Feb 3 21:33:40 UTC 2016
Matthew Pounsett wrote:
> > On Feb 3, 2016, at 15:04 , Evan Hunt <each at isc.org> wrote:
> > On Wed, Feb 03, 2016 at 02:23:19PM -0500, Robert Edmonds wrote:
> >> AFAIK, BIND and Unbound don't really target the use cases they are trying
> >> to address.
> > BIND sort of does with the lightweight resolver daemon (lwresd), but
> > it hasn't gotten any traction to speak of. Dnsmasq definitely does,
> > and supports DNSSEC validation.
Dnsmasq probably fits their requirements more closely than BIND or
Unbound, but it's still a server that you have to talk to via a stub
resolver. In other words, there's still the "last centimeter" of DNSSEC
to secure :-)
> > I have no objection at all to systemd reinventing this particular wheel,
> > though, except "yuck, systemd", and I wish them the very best of luck
> > except bleagh.
> This is my feeling exactly. Concerns I’ve heard about stability and transparency (and therefore ease of troubleshooting) aside, systemd is just reaching into too many parts of the OS. I’m highly supportive of the idea of writing a new validating stub .. but I think it’s folly to link it into the boot/cron system. Same feeling I have with systemd’s integration into /tmp clearing, and a host of other things it shouldn’t be doing directly, or possibly at all.
Other than being part of the same umbrella project, being developed by
the same people, and sharing some utility code (config file parsing,
abstract data type implementations, etc.), I'm not sure if it's accurate
to say that it's linked to the boot/cron system, at least not in the
runtime sense. It certainly doesn't run inside the PID 1 systemd
Is the situation really that different from, say, 4.x BSD? Your init
system, startup scripts, cron daemon, etc. and DNS stub resolver all
came from the same vendor and were integrated into the base OS ;-)
More information about the dns-operations