Why is systemd-resolved.service disabled on Pi?

I don't know. Why do you want or need it, DNS cache only for the machine running it or for the LAN? I don't know a useful application of the former (but I do precious little with network tech) and the latter seems like something your modem/router already does. Try enabling it?

Well... You might have better luck in the forums on the rpi website about this specific RaspiOS vendor setting.

On my Pi Zero-W it is disabled, but on my desktop (Mint) it is enabled. What this *suggests* to me is that its a disk and ram saving configuration on the Pi. But I can't be authoritative on that.

Do you need to trade a lot of ram and disk for a DNS cache?

I don't want it, I want to run dnsmasq on the Pi and I want to be sure that systed-resolved won't come along and mess things up, if it's

*supposed* to work but doesn't there's a chance that some future update will 'fix' it and it'll start working, which would be a nuisance.

Hmmm, I suspect that knowledge of what "vendor enabled" means is rather arcane systemd knowledge. :-)

Define, a lot? Naively, I would expect a local DNS cache to be tiny. My Win10 PC, used all morning, has 200 entries.

Yes, that's fairly typical I think, most Linux distributions seem to enable it to provide local DNS cacheing. I've had to explicitly disable it on systems where I'm running dnsmasq (which does the same things plus some more). Apart from anything else dnsmasq is *much* easier to configure and has much better support.

No, as I replied to the other comment, I really wish systemd-resolved would go away completely, it's difficult to understand (compared with dnsmasq anyway) and it has some arcane 'oddities' in the way it works. There's a long, ongoing discussion on some Linux distributions about how it handles multiple DNS servers for example.

I just want to be sure that it will *stay* disabled when I update the OS on my Pi systems.

Speed up remote service calls (REST/RPC). Back in the day, I remember we could genuinely speed up apps by avoiding multiple DNS lookups of the same address.

I must admit, I would be a bit pissed off to have to worry about that nowadays.

man systemd.preset

most applications cache lookups themselves

Well its the usual story of systemd replacing something known and perfectly usable with something new unknown and possibly bug ridden.

My strong guess is that the Pi disables it by default.

So you should be able to slam in dnsmasq alongside/over it.

Even if it is enabled

Oh, here you go

"Q:I recently installed dnsmasq to act as DNS Server for my local network. dnsmasq listens on port 53 which is already in use by the local DNS stub listener from systemd-resolved.

Just stopping systemd-resolved and then restart it after dnsmasq is running solves this issue. But it returns after a reboot: systemd-resolved is started with preference and dnsmasq will not start because port 53 is already in use."

"A: As of systemd 232 (released in 2017) you can edit /etc/systemd/resolved.conf and add this line:

DNSStubListener=no

This will switch off binding to port 53.

The option is described in more details in the resolved.conf manpage.

You can find the systemd version your system is running with:

systemctl --version"

My Pi has that file.

I think, this is the page to peruse

Theres enough detail and feedback there to sort you out

... but I bet it could speed up anyispam tools like SpamAssassin quite usefully.

There's also enough detail and different ways to do it to show what a mess this area of configuration has become! :-)

Thanks though, that thread is somewhat enlightening.

Coo, yes, that does explain things somewhat, thank you.

You must live a narrow existence....

"vendor preset: enabled" means that the application developers (systemd in this case) recommend its activation. The distribution maintainers can differ from that recommendation.

OK, thanks, though I have to say calling it vendor preset is pretty silly as it suggests (to me anyway) that it's the suppliers of the system who have decided on that default. It seems the wrong way round to me - vendor means "Mr Raspberry Pi". :-)

Yes, that's what we did.

However, reliable caches are both tricky and remarkably uninteresting in comparison to overall application design. What happens when external events cause a cached item to become invalid?

That's why you would want to delegate caching logic to a well-designed caching service/object. Code that has time invested in handling the logic carefully. Then you can just ask for what you want every time you want it, and it can be delivered reliably and promptly. And we don't have to worry our pretty heads about how it does it.