Various topics on which the systemd people have worked in the last year or so.
systemd has moved from the freedesktop infrastructure to github. And it has paid off, there are more contributors, and they started to use the CI infrastructure. But there are also problems, like the workflows are just weird.
All bigger distros except Gentoo have adopted systemd as the default init system. So, is systemd boring now? Are the controversial discussions done? In a way, indeed, systemd is no longer radical and to a large extent it’s maintenance.
networkd has replaced NetworkManager in a few distros, Fedora and Ubuntu cloud. They are working on an interactive interface in networkd so it can really replace network-manager.
nspawn, the minimal container implementation, is used as the base for CoreOS rkt.
Some auxiliary components, are used by other packages, e.g. sd-dhcp is used by NetworkManager.
systemd is very much based on control groups to manage processes. The problem with CG is that it no only does resource management, but also organises processes in a hierarchy. The unified control group hierarchy simplifies this. However, if other applications are also using control groups, this change will break things (e.g. it breaks Docker at the moment). Features introduced with this: PID conrollers, i.e. limiting the number of processes that can be created; safe delegation of control to another process without breaking systemd.
systemd-resolved is a new component that does DNS resolution. Traditionally this is handled by the resolver in libc that will talk directly to the network. It would be better to instead talk to a single process on the host, because:
- you can do caching;
- you can add LLMNR (Microsoft’s link-local resolver);
- you can add DNSSEC support;
- you can add mDNS support.
DNSSEC adds authentication to DNS, not confidentiality (people can still see that you did that lookup). It works with a chain of trust, matching the registrar hierarchy.. It also allows to embed additional information, like TLS certificates, PGP fingerprints, … Although it started to be deployed in 2010 and most TLDs support it, only 2% of the most popular websites currently use it. Google’s 188.8.131.52 will validate DNSSEC, but of course there is no authentication between you and 184.108.40.206. At the client side, DNSSEC is non-existent. No OS implements it. Why? Because it is very hard to get right, and it makes things slower. Web browsers don’t like it (google it to find out why). Also it’s nasty to set up on the DNS server side, you have to constantly keep it updated. And the specs are simply not very good. And also, it doesn’t enable anything that wasn’t possible before (using TLS for example). For IPv6 there are stronger reasons, but who uses IPv6?
So, why should we support it? Because it is there and it does increase security (second shell against TLS failures).
Problems with DNSSEC: Private DNS zones (e.g. ess-mail.com) – they will NOT be authenticated by the TLD. Workaround: still allow it if the TLD doesn’t exist. Crappy implementations in routers and ISPs that don’t implement DNSSEC correctly. Captive portals often work by faking DNS. As long as you’re in the discovery fake and the captive portals intercepts traffic, DNSSEC should be disabled.
systemd-resolved’s approach: downgrade to non-validating whenever validating is not possible (unless configured differently). This of course opens it to downgrade vulnerability. But at least the information whether it was authenticated or not is propagated to clients, so they can react to it appropriately. In particular, any extra information (SSH fingerprint, TLS certificate) should be ignored in that case. This is the only practical way to use DNSSEC at all.