[sf-lug] Mail problems (or Firefox, or systemd,...)

[Rick Moen]

Quoting Ken Shaffer (kenshaffer80 at gmail.com):

[nsswitch.conf:]

> You're  right, the msdns is there:
> hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

First, just to reassure you, that is not a problem.  (You needn't be
worried about that.  It appears that through work by you and others, the
source of your problem with resolving Comcast DNS got identified:  a bug
in systemd-resolved.)

Second, if you don't mind, though, I'll take just a moment to explain
nsswitch.conf and that 'hosts' line within it.

nsswitch.conf is a configuration file controlling the name services
functions of the system C library (glibc = the GNU C library).  This is
needed because name information can come from multiple sources, so this
file is where one can specify in what order to consult those sources,
and how.  glibc handles name-resolution of quite a few types of things,
and 'hosts' (names of remote systems) is among them.

In the case of your system, glibc gets instructed to look up the names f
hosts in four places, in order, before giving up and saying no such host
is found:

files:  use the local files, e.g. /etc/hosts.
mdns4_minimal:  use whatever implements multicast DNS (mDNS) protocol 
dns:  use the domain name system
myhostname:  find local hostname from Freedesktop.org service nss-myhostname

The '[NOTFOUND=return]' entry instructs glibc to continue through the
latter entries of that line even if the preceding entry (for mDNS)
returns 'not found'.

The mdns4_minimal line amounts to a directive to ask the Avahi daemon,
written by Freedesktop.org regular and systemd architect Lennart
Poettering, to see if the hostname's in mDNS.  mDNS is a
Microsoft-centric concept where objects have names in a synthetic DNS
domain, '.local'.  https://en.wikipedia.org/wiki/Multicast_DNS  It's
commonly used for autodiscovering networked printers that are configured
to declare their mDNS names continually onto your network, creating a
sort of 'Network Neigbourhood' effect at the cost of junking up your
network with quite a lot of broadcast traffic.  I will stress that you
absolutely do _not_ need it to do DNS.  It's something overlaid on top
of DNS.

The nss-myhostname software is yet another overly complicated solution
to a non-problem by the Freedesktop.org people.  Here's the page where
they justify it;
https://www.freedesktop.org/software/systemd/man/nss-myhostname.html
The justification is, in short, a bunch of nonsense.  The local hostname
has always been perfectly well defined in static file /etc/hostname and
resolved in /etc/hosts.  There's absolutely no need for a dynamic
service to answer that question.  (So, naturally the Freedesktop.org 
coders wrote one.)

Personally, I would immediately strip out the mdns4_minimal and
myhostname items (and the [NOTFOUND=return] glue), as superfluous at
best and potential trouble-makers at worst -- but you certainly don't
need to.


> I agree I need to keep better notes,  My memory is that I confirmed a
> lookup failure with systemd-resolve, but didn't write it down, so when
> it works now, I'm not sure it ever failed.

Understood.  That would be a problem.  ;->  But I'm sure you also get my
point that accurate recountings help others help you.  (Personally, I've
sometimes deferred asking for assistance until I could reproduce the
problem a second time with accurate records.)


> I use nslookup with a name and optional server, So typically four
> times, once with just the name to see the default server (which is in
> the output, so no mystery which one is used), and with the nameservers
> 8.8.8.8, 192.168.1.1, and 127.0.0.53

Thanks for clarifying, and I salute your cautious usage.  A lot of other
people just don't even think about what nameserver the query is going
to, even when that's central to what's being investigted.


> On Ubuntu 18.04  systemd-resolve is a program in /usr/bin.  It's not
> the daemon systemd-resolved. It can do simple name DNS resolution,
> among other things.

OK, I have learned something, so, thank you, Ken.  FWIW, I did try to
Web-search for it, but it's almost impossible to find pages about,
because the search engine assumes you just mistyped systemd-resolved.
By adding quotation marks to my search, I found relevant hits (finally),
such as http://man7.org/linux/man-pages/man1/systemd-resolve.1.html .

Seems IMO weird to bother having such a tool, because AFAIK it does almost
exactly the same thing as just sending a 'dig' or 'nslookup' query to
systemd-resolved's 127.0.0.53 listener -- but there are also a few bells
and whistles.


> That's never a good idea, but I confirmed the fix I came up with as
> one others had used, and while I still don't know for sure what's
> wrong (probably bug 1804487 related), I'm back to a fully functioning
> system.

I would earnestly recommend _not_ following advice from random people on
the Web without being very clear on what you are doing and why.

And, if your altered configuration still routes your DNS queries through
systemd-resolved, then you still have a problem because its handling of
DNSSEC is defective.  (My view is also that it's just a bad piece of
software that doesn't even address a real need, but you be the judge.)