to...@tuxteam.de wrote: > [-- text/plain, size 1.2K, charset utf-8, 34 lines, encoding quoted-printable > --] > > On Thu, Oct 24, 2024 at 04:31:18PM -0400, Greg Wooledge wrote: > > On Thu, Oct 24, 2024 at 21:24:17 +0100, Joe wrote: > > > In an installation not using a DHCP client, you would be expected to > > > make your own DNS and gateway arrangements along with the IP address. > > > > OK. I'm guessing that's not relevant here, though. > > > > > If > > > you're not running Network Manager nor a resolver application, nothing > > > will touch /etc/resolv.conf, so the nameserver would normally go there, > > > as you have done. > > > > That part's incorrect. The thing that usually modifies resolv.conf in > > most setups is in fact the DHCP client daemon. That will happen even > > if Network Manager is not in use. > > I think there is some confusion in this thread between "resolver" and > "DNS server". Your base installation always has a resolver, typically > part of your libc. This one is the piece responsible for looking up > host names (and typically configured via /etc/resolv.conf); it may > do some caching. > Yes, OP here again, that's why I said in my original post "(I know they're not quite the same thing, but the result works OK)" I think (on Ubuntu it did anyway) that systemd-resolved.service provides a DNS caching service. The trouble is that it does it wrong (in many people's opinion), if the 'first' DNS server fails to give an answer it tries the 'second' (correct enough) but it then sticks to using the 'second'. If your local LAN DNS fails (even momentarily) then it never gets used again and you lose LAN DNS. This has been argued over endlessly with the systemd developers.
> The DNS servers are the things queried by the resolver (among others, > like /etc/hosts). > > A caching resolver overlaps in function somewhat with a local DNS server, > perhaps thus the confusion. > > And then there are browsers doing DoH. Pure evil, if you ask me. > Yes, I quite agree! :-) -- Chris Green ยท
