Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #274004 > unrolled thread

DNS on minimal new installation

Back to article view | Back to linux.debian.user

Contents

  DNS on minimal new installation Chris Green <cl@isbd.net> - 2024-10-24 21:20 +0200
    Re: DNS on minimal new installation Greg Wooledge <greg@wooledge.org> - 2024-10-24 21:40 +0200
      Re: DNS on minimal new installation Chris Green <cl@isbd.net> - 2024-10-24 23:00 +0200
    Re: DNS on minimal new installation Joe <joe@jretrading.com> - 2024-10-24 22:30 +0200
      Re: DNS on minimal new installation Greg Wooledge <greg@wooledge.org> - 2024-10-24 22:40 +0200
        Re: DNS on minimal new installation <tomas@tuxteam.de> - 2024-10-25 07:20 +0200
          Re: DNS on minimal new installation Chris Green <cl@isbd.net> - 2024-10-25 09:30 +0200
            Re: DNS on minimal new installation Joe <joe@jretrading.com> - 2024-10-25 10:40 +0200
              Re: DNS on minimal new installation <tomas@tuxteam.de> - 2024-10-25 11:40 +0200
        Re: DNS on minimal new installation Chris Green <cl@isbd.net> - 2024-10-25 09:20 +0200
        Re: DNS on minimal new installation Joe <joe@jretrading.com> - 2024-10-25 10:40 +0200
          Re: DNS on minimal new installation Greg Wooledge <greg@wooledge.org> - 2024-10-25 13:40 +0200
            Re: DNS on minimal new installation eben@gmx.us - 2024-10-25 17:50 +0200

#274004 — DNS on minimal new installation

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?

-- 
Chris Green

[toc] | [next] | [standalone]

#274007

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.

[toc] | [prev] | [next] | [standalone]

#274017

Greg Wooledge <greg@wooledge.org> wrote:
> 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.

Ah, thank you, that link to the wiki tells me what I need to know.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#274012

On Thu, 24 Oct 2024 20:16:30 +0100
Chris Green <cl@isbd.net> wrote:

> 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?
> 

I would not expect a DNS server as part of a minimal installation, the
default assumption will be to pick up the network DNS server and gateway
from DHCP, and in many networks they will be the same device anyway.

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.

I'm just setting up a Raspberry Pi headless server, and it does run
bind9, but before I had installed that I had set things up in the way
described. Does dnsmasq not have a forwarders configuration? I've never
used it, but I would have thought it did, as it doesn't use root hints.
If so, that's the right place to put the nameserver(s) it will relay
queries to.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#274013

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.

[toc] | [prev] | [next] | [standalone]

#274026

[Multipart message — attachments visible in raw view] — view raw

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.

Cheers
-- 
t 

[toc] | [prev] | [next] | [standalone]

#274029

tomas@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
·

[toc] | [prev] | [next] | [standalone]

#274031

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. 

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#274034

[Multipart message — attachments visible in raw view] — view raw

On Fri, Oct 25, 2024 at 09:36:20AM +0100, Joe wrote:
> 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. 

That's one of the first things we teach the poor folks using Windows in
our net: "ipconfig /flushdns".

Followed by a hint that we, non-Windows folks don't need it :-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274028

Greg Wooledge <greg@wooledge.org> 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.

Yes, OP here, that would seem to be what creates /etc/resolv.conf in
my case, a minimal install with the only addition being ssh.  It's
perfectly OK for my backup system, it won't be doing many DNS queries
and not having a DNS cache really won't matter at all.  The extra
simplicity is a bonus.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#274032

On Thu, 24 Oct 2024 16:31:18 -0400
Greg Wooledge <greg@wooledge.org> 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 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 did go on to say that if an onboard caching server is used, the right
place for the authoritative server is in the cache server forwarders
configuration, and resolv.conf should then show localhost.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#274035

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.

[toc] | [prev] | [next] | [standalone]

#274042

On 10/25/24 07:35, Greg Wooledge wrote:
> 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.

On my LAN (i.e. in my house) pretty much everything gets a particular
address assigned by DHCP, so I can easily identify it and address it in a
firewall if need be.

--
"It can be shown that for any nutty theory, beyond-the-fringe political
  view or strange religion there exists a proponent on the Net. The proof
  is left as an exercise for your kill-file." -- Bertil Jonell

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web