It works fine though. The /etc/resolv.conf is:-
domain zbmc.eu
search zbmc.eu
nameserver 192.168.1.1
which simply means all DNS gets passed to my LAN's DNS server. Is that
what one gets on a minimal installation, no explicit DNS server or
resolv management? I'm very happy with this, it's very simple and the
backup system isn't going to make a lot of DNS queries such that it
needs a DNS cache. Have I understood this OK?
I have just installed Debian Bookworm on my backup server which is a
Fujitsu Esprimo Q556 with an 8TB external USB drive for backup. I was previously running xubuntu there.
It has all gone very straightforwrdly, the actual installation only
took half an hour or so and configuring things not much more. I've
already run a backup from one of my smaller systems and it ran fine.
On xubuntu I have made a habit of removing systemd-resolved.service
and installing dnsmasq. (I know they're not quite the same thing, but
the result works OK)
Thus dnsmasq provides a local caching DNS service and it passes DNS
queries that it can't answer on to my main LAN DNS server. It uses
the file /run/NetworkManager/no-stub-resolv.conf to tell it where
the upstream DNS server is.
However my backup system is headless so doesn't have Network Manager installed. (No desktop installed, just basic utilities and ssh)
It doesn't appear to have systemd-resolved.service installed either.
It works fine though. The /etc/resolv.conf is:-
domain zbmc.eu
search zbmc.eu
nameserver 192.168.1.1
which simply means all DNS gets passed to my LAN's DNS server. Is that
what one gets on a minimal installation, no explicit DNS server or
resolv management? I'm very happy with this, it's very simple and the
backup system isn't going to make a lot of DNS queries such that it
needs a DNS cache. Have I understood this OK?
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.
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.
On Thu, Oct 24, 2024 at 20:16:30 +0100, Chris Green wrote:
It works fine though. The /etc/resolv.conf is:-
domain zbmc.eu
search zbmc.eu
nameserver 192.168.1.1
which simply means all DNS gets passed to my LAN's DNS server. Is that
what one gets on a minimal installation, no explicit DNS server or
resolv management? I'm very happy with this, it's very simple and the backup system isn't going to make a lot of DNS queries such that it
needs a DNS cache. Have I understood this OK?
In a typical installation, on a typical network, you will get your DNS configuration via DHCP, from whatever is acting as your network's DHCP server. In your case, I'm guessing it's a router.
Check the /etc/network/interfaces file and see if you have your interface configured for dhcp. I'm guessing you do.
With DNS configuration being provided by DHCP, any changes you make to
the /etc/resolv.conf file will be overwritten every time the DHCP client daemon renews its DHCP lease. This will usually happen once or twice
per day.
If you'd like to set up a local caching DNS nameserver, then you'll need
to work out a way to change your resolv.conf file without your changes
being overwritten. There are many different approaches to this.
See <https://wiki.debian.org/resolv.conf> to see some ways of doing it.
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.
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.
[-- 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.
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, 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.
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.
On Fri, 25 Oct 2024 08:03:43 +0100
Chris Green <cl@isbd.net> wrote:
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.
I don't know if it's significant, but that's how Microsoft domain DNS
works, meaning that unless multiple DNS servers replicate. a short loss
of connection cuts the clients off from Active Directory, rather more serious.
I was assuming someone setting up a server of some kind would not be
running a DHCP client, which of course can be done with a reservation,
but it's another potential point of failure that a fixed address configuration doesn't have.
On Fri, Oct 25, 2024 at 09:33:24 +0100, Joe wrote:
I was assuming someone setting up a server of some kind would not be
running a DHCP client, which of course can be done with a reservation,
but it's another potential point of failure that a fixed address
configuration doesn't have.
I've seen it done both ways. In a lot of environments, even server IP addresses are assigned by DHCP (with a reservation so that the same
address is issued every time). This gives the benefit of central
address management.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 168:46:42 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,551 |