I suspect the big part is putting "DNSStubListener=no" into the [Resolve] section of /etc/systemd/resolved.conf if you want to have something else listening on port 53.
Yeah, but if you regress to 'legacy DNS' by removing systemd-resolved then there's no good way to do per-interface DNS (~client-split DNS), or (optionally) validate DNSSEC, or do DoH/DoT; and then nothing respawns and logs consistently-timestamped process events of substitute network service processes.
FWIU, per-user DNS configs are still elusive. Per-user DNS would make it easier to use family-safe DNS (that redirects to family-safe e.g. SafeSearch domains) by default; some forums are essential for system administration.
Since nothing in the real world is or ever will be DNSSEC signed anyways, it's not that much of a loss. Meanwhile, the most important DoH user --- your browser --- has DoH baked in and doesn't need systemd-resolved's help.
Package managers don't rely on DNSSEC for package security (it would be deeply problematic if they did). But you can also just go look and see that, for instance, Ubuntu.com isn't signed, nor are most of the Pacman mirrors for Arch, nor is alpinelinux.org, &c. DNSSEC is simply not a factor in package management security.
People have weird ideas about how this stuff works.
Unfortunately all packages aren't necessarily signed either; "Which package managers require packages to be cryptographically signed?" is similar to "Which DNS clients can operate DNS resolvers that require DNSSEC signatures on DNS records to validate against the distributed trust anchors?".
FWIW, `delv pkg.mirror.server.org` is how you can check DNSSEC:
man systemd-resolved # nmcli
man delv
man dnssec-trust-anchors.d
delv pkg.mirror.server.org
The TUF Overview explains some of the risks of asset signature systems; key compromise, there's one key for everything that we all share and can't log the revocation of in a CT (Certificate Transparency) log distributed like a DLT,
https://theupdateframework.io/overview/
> Proposed is an extension to PEP 458 that adds support for end-to-end signing and the maximum security model. End-to-end signing allows both PyPI and developers to sign for the distributions that are downloaded by clients. The minimum security model proposed by PEP 458 supports continuous delivery of distributions (because they are signed by online keys), but that model does not protect distributions in the event that PyPI is compromised. In the minimum security model, attackers who have compromised the signing keys stored on PyPI Infrastructure may sign for malicious distributions. The maximum security model, described in this PEP, retains the benefits of PEP 458 (e.g., immediate availability of distributions that are uploaded to PyPI), but additionally ensures that end-users are not at risk of installing forged software if PyPI is compromised.
One W3C Linked Data way to handle https://schema.org/SoftwareApplication ( https://codemeta.github.io/user-guide/ ) cryptographic signatures of a JSON-LD manifest with per-file and whole package hashes would be with e.g. W3C ld-signatures/ld-proofs and W3C DID (Decentralized Identifiers) or x.509 certs in a CT log.
Author here. I can’t believe I didn’t cover that as I spent ages fighting with it before writing this.
Writing those posts was incredibly cathartic, but I still left stuff out because I couldn’t get to the bottom of it. I do recall that configuring systemd resolved and finding useful docs for it was a nightmare.
Also predates netplan. NetworkManager (another redhat tool to makes things "simpler", like systemd) is mentioned in part 3.
I've used Debian based distributions for 20 years with nothing more than ifupdown, resolvconf, and occasionally dnsmasq, but no distro for old men and all that.
Stuff like systemd (and systemd-resolved) are wonderful innovation and that m god they're the de-facto standard on most desktops.
And by the way, the joy of systemd-resolved is in complex stuff that become surprisingly easy.
Example: split-horizon DNS. You're connected to a VPN network but you're only routing some subnets through that, not everything. Thus, you have to have DNS that query some DNS server inside the VPN for a set of domains, but keep using the usual DNS servers for everything else.
It's surprisingly easy with systemd-resolved, but I'm not aware of any feasibility without a DNS server running on the local machine (albeit in resolver mode). Which usually would be dnsmasq, but at that point you might as well run systemd-resolved.
> Example: split-horizon DNS. You're connected to a VPN network but you're only routing some subnets through that, not everything. Thus, you have to have DNS that query some DNS server inside the VPN for a set of domains, but keep using the usual DNS servers for everything else.
Why. I want to route 10.0.0.0/8 via a VPN, I don't know if "flargle.bazonga.com" resolves to 10.0.0.1 or 99.99.99.99 until I do the lookup.
If bazonga.com is domain only accessible through the VPN then you most likely always want to look up flargle.bazonga.com through the VPN name servers. On the internet you'll get NXDOMAIN.
However, this could be solved by setting the name servers always to the VPN name servers and make them recursive. But then, what if those name servers don't have internet access?
I might, but that's not at all how my networks work.
Indeed even the corporate business network (which I rarely ever touch) doesn't do that any more - some internal looking DNS resolve to public IPs, some external looking DNS resolve to rfc1918s, some are overwritten if you're on the network or not, and vpns are now based around zscaler which doesn't even allow access via IP address, not entirely sure how it works but DNS resolves everything to 100.64.x.x or similar (cg nat I believe) - not sure how it routes web traffic to the right server, but as I say I very rarely use it (I don't think I've used it since covid started)
If I were setting up a corporate laptop, I would likely set all dns, and possibly all traffic, routing via the vpn for security/compliance/monitoring purposes. What benefit does resolvd give me?
I use Arch on my laptop. I love the flexibility of NetworkManager and I use a variety of DNS sources including a local unbound and a /etc/hosts file. I have a wired ethernet profile called RFC1918 with a lot of addresses on it that covers pretty much all router, firewall and switch defaults. It crucially has the check box for "Use only for connections..." in the routes section. That means that the default gateway stays on the wifi and/or VPN. I have several other profiles to deal with various combinations of requirements.
Recently I modelled a data centre on my home network to get a Fortigate cluster up and running as though it was in place. It's WAN was behind a VLAN on my home pfSense, so it had it's "real" external IPs running fine and then I put VMs in at various places to test out routing and policy before deployment.
DNS is simply (lol) a name to address mechanism and there is no need to get too het up about it. I simply make whatever view of the world I need to exist at the time I'm doing a job. I do this for IPv4 and 6.
It can get a bit challenging WFH. I have a site to site IPSEC VPN to the office and also a OpenVPN dial up VPN connection available. Customer sites are generally setup to allow access from certain IPs and I have to make sure I appear to be the right address. Even more fun is had with the quite large collection of sites with a subnet range of 192.168.{0|1}.0/24. Those I generally wholesale NAT and then for the really dumb devices at the other end or those with a broken routing table, NAT outbound on LAN.
I use networkmanager on my laptop. 99%+ of my linux machines are not laptops so I don't need network manager on them.
I use dnsmasq on two servers, which has a few local dns entries in its host (either to block lookups for some sites like dailymail.co.uk, or to have an entry for "nas" pointing to 192.168.0.51) and upstreams the rest of the queries. I don't need a forwarder on the other machines on the network, they are told by dhcp to use those two servers when they are on my network, when they're on another network dhcp tells them to use something else.
I run syslog on a few servers listening to an anycast device, and syslog fires text to the local machine and that anycast IP.
Had a problem last night with a systemd-resolvd server, I'd added an entry to DNS, and it wasn't working. Of course that's because the entry hadn't migrated from the main dns server to the backup one (the cronjob runs every 20 minutes as it has done for over a decade), and systemd decided to use the backup server (which is very rarely used). That costs me time.
If I want fancy DNS resolving paths, I can choose to install a fancy forwarder.
(For WFH I do have a router I can plug my laptop and other devices like a pi into and everything is forwarded through work, including routes to 0.0.0.0/0. No natting involved. When I bring my VPN up on the road, everything is routed via the VPN (other than the vpn end point obviously). I wouldn't bridge my network normally, why would I bridge it with a VPN?)
I did the same for years, with the addition of wireless tools when I switched to using laptops. With Buster and the additional networking features of systemd (and iwd for wifi), I was able to replace the whole stack with just 2-3 things. Much simpler in design and easier to setup and use.
99% of my machines (everything apart from one laptop) has no wifi. Systemd is constantly
Now of course I can return to basics and learn everything again from scratch. The problem with that approach is distros like Ubuntu frequently drop in new features which last 5 years, and then they're gone as they're no longer sexy. This reduces the payoff of learning something new, may as well just continue to fight.
I probably won't use ubuntu on servers going forward as they broke the installer for 20.04 (they got rid of the nice simple debian-installer, which just needed a new kernel/initrd and a preseed tweak every 2 years) and replaced it with some live cd monstrosity. Managed to avoid netplan on 18.04. It's a pain, as it means spending mental effort to make changes to something that just works, and the whole reason I use linux is because it has "just worked" for 2 decades.
It seems all these recent changes are aimed at people who want their linux machine to operate just like an OSX laptop.
Without wifi it isn't very compelling vs. the good old /etc/network/interfaces setup, it's hard to get simpler than that. I still use that on my servers as well.
I use Debian myself and know that they don't change tech lightly and will keep supporting Systemd for the foreseeable future. So that part isn't a concern for me. Can't help with the Ubuntu installer, I only ever used it for cloud deployments with cloudinit.
Systemd is a mixed bag but overall I've been happy with it. I have been using it since Jesse and have never had any issues with it and definitely prefer it over sysv-init (which I always hated, every other init system is an improvement over it IMO... so low bar I guess).
You can use autoinstall instead of d-i - I vastly prefer it over the arcane d-i configurations. d-i is one of those things which you get working and never touch again in case you break it.
I've used d-i with ubuntu since 6.10 and it just works.
Never managed to find a base pxe boot for autoinstall, but it's just one of the many straws
As I say, just one of the many reasons I'm trying to leave the tech industry, just like the unix greybeards were annoyed by young upstart linux people in the late 90s, these things are cyclical.
Edit: Well, and also browsers doing DNS over https. It's pretty confusing these days to know which path your app took to resolve a name.