There's this adage about consuming whatever newspaper reporting, everything seems fine and dandy, until one day they report on something in your field. Say, chemistry, and you're a chemist, and... it's all wrong. Even the basics.
My field is networking, roughly from Ethernet physicals to TCP/UDP.
systemd has no f*cking clue what they're doing on networking. You need to not use systemd-resolved, and not use systemd-networkd or systemd-timesyncd either.
I really hope they are service manager people and know how to write a service manager, and I have no counterindications on that. But don't let them touch your networking, aside from service-managing on that.
(My recommendation for DNS - on servers - would be to install unbound locally and use that. It's not great for clients since it doesn't deal well with frequently changing network connectivity, or rather, it does, but only if you restart it on network attachment change, which implies flushing all cached data.)
> systemd has no f*cking clue what they're doing on networking. You need to not use systemd-resolved, and not use systemd-networkd or systemd-timesyncd either.
Can you give some more details, or do you have some examples of where systemd is bad here? Because I'm quite happy with systemd-resolved and systemd-networkd, but I admittedly know hardly anything about networking.
> [...] But don't let them touch your networking, aside from service-managing on that.
What do you recommend as an alternative then? systemd-resolved and systemd-timesyncd are easy to replace, since there is lots of good DNS/NTP software available, but systemd-networkd seems trickier: I don't like NetworkManager, I'd rather not write a bunch of ad-hoc shell scripts, and I'm not aware of any other alternatives.
> There's this adage about consuming whatever newspaper reporting, everything seems fine and dandy, until one day they report on something in your field. Say, chemistry, and you're a chemist, and... it's all wrong. Even the basics.
Gell-Mann amnesia effect: https://en.wiktionary.org/wiki/Gell-Mann_Amnesia_effect
> systemd has no fcking clue what they're doing on networking. You need to not use systemd-resolved, and not use systemd-networkd or systemd-timesyncd either.
I'm not sure how to reconcile that with enjoying each of those:
systemd-resolved is the default on many distributions, and does DNS-over-TLS stub resolution for me. What do you suggest as an alternative that handles changing network connectivity, and DoT?
* systemd-networkd is very well documented/organised. I find it pretty useful on servers.
* systemd-timesyncd doesn't seem to cause issues for me. It being an SNTP client (rather than NTP) seems appropriate for distributions. I would like to move to NTS or Roughtime at some point.
> My recommendation for DNS - on servers - would be to install unbound locally and use that
And now your developers are running around and cursing you because nothing works anymore.
Because Docker silently retargets the interna Docker resolver to 8.8.8.8 if it sees 127.0.0.1 as a resolver address on the host.
Because people who wrote Docker have no fucking clue how the system works.
NB: see https://news.ycombinator.com/item?id=47441785 to solve the Docker issue with a local resolver.
> It's not great for clients since it doesn't deal well with frequently changing network connectivity
This is is something Linux specific I guess, I run Unbound locally on my Windows laptops for years and never had a problem which would require the Unbound restart.
> which implies flushing all cached data
It doesn't really matters in 2026. Just look in your cache and note the default TTLs for like 90% of records.
> My recommendation for DNS - on servers - would be to install unbound locally and use that.
At least on Ubuntu 26.04, you can't easily bind Unbound on a WireGuard interface because of services dependency order, so the Unbound service errors during system boot because the WireGuard interface doesn't exist yet. And IIRC neither `ip-transparent` nor `interface-automatic` fixed it.
On Alpine Linux all this just works.