Latest systemd news

[Pete Travis]

On Nov 15, 2014 6:54 AM, "Sam Varshavchik" <mrsam at courier-mta.com> wrote:
>
> Making the rounds of various technical mailing lists yesterday, with a
subject that's typically a variation of "Just for yucks, and giggles" is a
link to a commit to systemd's git, adding DNS caching to systemd; in one,
huge 857 line glop. Here's its entire commit message: "resolved: add DNS
cache".
>
> And, it's beauty to read. Made me teary-eyed to know that systemd will
cache my DNS queries. Not sure why systemd, all of a sudden, needs to make
DNS queries. But if it does, it's going to cache them now! Such a sight to
behold makes my heart skip a beat: now, not just bind, or pretty much every
DNS server that automatically caches DNS for you – but so will systemd!
>
> But, seriously folks, systemd's DNS caching achieves absolutely 100%
nothing. Really. Surprised? Well, you'll be shocked to know that the DNS
server that systemd queries for that DNS RR, such as the stock "bind",
already automatically caches all recursive DNS replies!! systemd's own
caching produces absolutely zero useful results. On the oft chance that it
sends a query for a non-cached RR, the local DNS server will cache the
response, before returning it to systemd, and then use the cached response
for all future queries. That's what DNS servers do: provide caching for
local clients. It's inherent in DNS's design: DNS was explicitly designed
to use aggressive caching, it's an internet-wide, distributed, locally
cached database.
>
> Isn't modern technology amazing?
>
> I'm willing to consider the possibility that I missed something obvious,
some obvious value-added result from caching DNS RRs directly by systemd,
and I'll stick around for someone to enlighten me; or if Occam's razor
applies, and the author of that commit had no idea that bind already
automatically caches DNS responses, and, more importantly, that its caching
algorithms are a result of painful lessons learned from various DNS cache
poisoning attacks, that have circulated around the intertubes, for the last
couple of years.
>
> The only possible use case for this kind of caching approach would be if:
>
> A) You do not have a local DNS server nearby; and you have non-negligible
latencies to whatever DNS server you use.
>
> B) Your queries tend to be for domains that your DNS servers are not
authoritative for, so they'll benefit from local caching.
>
> So, can someone explain to me how likely this is going to be the case in
a typical deployment scenario that systemd is targeted for; in an average
corporate environment where systemd's alleged benefits will supposedly
shine?
>
> I would guess that a typical systemd deployment, in a corporate/business
environment, will certainly have multiple, low-latency DNS servers nearby,
won't that be the case? And, if so, then this is just another potentially
exploitable security hole in systemd, nothing more.
>
> P.S. After I wrote the above, poking around, Google dumped this onto my
screen:
>
> http://seclists.org/oss-sec/2014/q4/592
>
> Mental note to myself: go back and check the timestamp of the systemd git
commit – before, or after, this was disclosed…
>
>
> --

I haven't read into it much yet, but the vast majority of systemd network
functionality is intended almost exclusively to support networking in
systemd-nspawn containers.  The init system's job is to isolate and manage
services; container management is a logical add.

Whatever the intent, I hope that everyone discovers it from reading actual
documentation instead of inflammatory comments on indignant speculation
about the intent behind a one sentence feature description like "
resolved: add DNS cache ".  I'm not necessarily putting you in that box,
Sam, but these discussions tend to feed on themselves and it makes
productive discourse difficult.

--Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20141115/384bf5dd/attachment-0001.html>