So, to continue from my other question....

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

root@raspberrypi:~# systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients


Is this actually as intended by the basic configuration or is there an error somewhere that's causing the systemd-resolved.service to be disabled. It *looks* as if it's meant to be enabled because it says "vendor preset: enabled".

However I can't see anything about 'resolved' in the system logs so maybe it
is explicitly disabled by default and that 'vendor preset' is misleading.

Does anyone here know anything?

--
Chris Green
·
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02-12-2021 11:36, Chris Green wrote:

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

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?

Does anyone here know anything?

Well... You might have better luck in the forums on the rpi website
about this specific RaspiOS vendor setting.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/12/2021 10:36, Chris Green wrote:

So, to continue from my other question....

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

root@raspberrypi:~# systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

Is this actually as intended by the basic configuration or is there an error somewhere that's causing the systemd-resolved.service to be disabled. It *looks* as if it's meant to be enabled because it says "vendor preset: enabled".

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.

However I can't see anything about 'resolved' in the system logs so maybe it is explicitly disabled by default and that 'vendor preset' is misleading.

Does anyone here know anything?

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

--
The biggest threat to humanity comes from socialism, which has utterly
diverted our attention away from what really matters to our existential survival, to indulging in navel gazing and faux moral investigations
into what the world ought to be, whilst we fail utterly to deal with
what it actually is.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/12/2021 11:57, A. Dumas wrote:

On 02-12-2021 11:36, Chris Green wrote:

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

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)

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.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

A. Dumas <alexandre@dumas.fr.invalid> wrote:

On 02-12-2021 11:36, Chris Green wrote:

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

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?

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.

Does anyone here know anything?

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

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

--
Chris Green
·
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 02/12/2021 10:36, Chris Green wrote:

So, to continue from my other question....

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

root@raspberrypi:~# systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled;

vendor preset: enabled)

Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers

https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

Is this actually as intended by the basic configuration or is there an error
somewhere that's causing the systemd-resolved.service to be disabled. It *looks* as if it's meant to be enabled because it says "vendor preset: enabled".

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.

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.

However I can't see anything about 'resolved' in the system logs so maybe it
is explicitly disabled by default and that 'vendor preset' is misleading.

Does anyone here know anything?

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

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.

--
Chris Green
·
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/12/2021 12:36, The Natural Philosopher wrote:

Does anyone here know anything?

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

Define, a lot? Naively, I would expect a local DNS cache to be tiny. My
Win10 PC, used all morning, has 200 entries.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/12/2021 13:03, Pancho wrote:

On 02/12/2021 11:57, A. Dumas wrote:

On 02-12-2021 11:36, Chris Green wrote:

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

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)

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.

most applications cache lookups themselves

--
“But what a weak barrier is truth when it stands in the way of an hypothesis!”

Mary Wollstonecraft

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/12/2021 13:03, Chris Green wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 02/12/2021 10:36, Chris Green wrote:

So, to continue from my other question....

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

root@raspberrypi:~# systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled;

vendor preset: enabled)

Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved >>> https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers

https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients


Is this actually as intended by the basic configuration or is there an error
somewhere that's causing the systemd-resolved.service to be disabled. It >>> *looks* as if it's meant to be enabled because it says "vendor preset: enabled".

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.

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.

However I can't see anything about 'resolved' in the system logs so maybe it
is explicitly disabled by default and that 'vendor preset' is misleading. >>>
Does anyone here know anything?

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

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.

I think, this is the page to peruse

https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq-and-systemd-resolved

Theres enough detail and feedback there to sort you out

--
"Socialist governments traditionally do make a financial mess. They
always run out of other people's money. It's quite a characteristic of them"

Margaret Thatcher

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thu, 02 Dec 2021 10:36:57 +0000, Chris Green wrote:

So, to continue from my other question....

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

root@raspberrypi:~# systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

Is this actually as intended by the basic configuration or is there an error somewhere that's causing the systemd-resolved.service to be disabled. It *looks* as if it's meant to be enabled because it says "vendor preset: enabled".

However I can't see anything about 'resolved' in the system logs so maybe it is explicitly disabled by default and that 'vendor preset' is misleading.

Does anyone here know anything?

man systemd.preset

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/12/2021 13:03, Chris Green wrote:

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.

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.




--
“But what a weak barrier is truth when it stands in the way of an hypothesis!”

Mary Wollstonecraft

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 02/12/2021 13:03, Chris Green wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 02/12/2021 10:36, Chris Green wrote:

So, to continue from my other question....

Why is systemd-resolved.service disabled, at least it's disabled on my >>> Pi systems (some very old ones and an early Pi 4) :-

root@raspberrypi:~# systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; >> vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers

https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients


Is this actually as intended by the basic configuration or is there an error
somewhere that's causing the systemd-resolved.service to be disabled. It >>> *looks* as if it's meant to be enabled because it says "vendor preset: enabled".

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.

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.

However I can't see anything about 'resolved' in the system logs so maybe it
is explicitly disabled by default and that 'vendor preset' is misleading. >>>
Does anyone here know anything?

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

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.

I think, this is the page to peruse

https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq-and-systemd-resolved

Theres enough detail and feedback there to sort you out

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.

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Joe Beanfish <joebeanfish@nospam.duh> wrote:

On Thu, 02 Dec 2021 10:36:57 +0000, Chris Green wrote:

So, to continue from my other question....

Why is systemd-resolved.service disabled, at least it's disabled on my
Pi systems (some very old ones and an early Pi 4) :-

root@raspberrypi:~# systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled;

vendor preset: enabled)

Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers

https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

Is this actually as intended by the basic configuration or is there an error
somewhere that's causing the systemd-resolved.service to be disabled. It *looks* as if it's meant to be enabled because it says "vendor preset: enabled".

However I can't see anything about 'resolved' in the system logs so maybe it
is explicitly disabled by default and that 'vendor preset' is misleading.

Does anyone here know anything?

man systemd.preset

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

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thu, 2 Dec 2021 13:03:40 +0000, Pancho wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/12/2021 12:58, Pancho wrote:

On 02/12/2021 12:36, The Natural Philosopher wrote:

Does anyone here know anything?

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

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

You must live a narrow existence....


--
“Those who can make you believe absurdities, can make you commit atrocities.”

― Voltaire, Questions sur les Miracles à M. Claparede, Professeur de Théologie à Genève, par un Proposant: Ou Extrait de Diverses Lettres de
M. de Voltaire
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2021-12-02, Chris Green <cl@isbd.net> wrote:

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

"vendor preset: enabled" means that the application developers (systemd in
this case) recommend its activation. The distribution maintainers can
differ from that recommendation.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Laurenz Trossel <me@example.invalid> wrote:

On 2021-12-02, Chris Green <cl@isbd.net> wrote:

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

"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". :-)

--
Chris Green
·
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/12/2021 15:44, The Natural Philosopher wrote:

On 02/12/2021 13:03, Pancho wrote:

On 02/12/2021 11:57, A. Dumas wrote:

On 02-12-2021 11:36, Chris Green wrote:

Why is systemd-resolved.service disabled, at least it's disabled on my >>>> Pi systems (some very old ones and an early Pi 4) :-

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)

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.

most applications cache lookups themselves

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.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)