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

[Ken Shaffer]

On 12/14/18, Rick Moen <rick at linuxmafia.com> wrote:
...
> What does the 'hosts' line in /etc/nsswitch.conf say?  There's some
> chance that the rather awful 'mdns' (Zeroconf) stuff is screwing up.
> Ideally, it says 'hosts: files dns' rather than 'hosts: files
> mdns4_minimal [NOTFOUND=return] dns'.

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


> Also, what does /etc/host.conf say?  Ideally, it says:On 12/15/18, Rick Moen <rick at linuxmafia.com> wrote:
> multi on
> order hosts,bind

My lines are reversed, but otherwise, the same.

> FYI, that description cannot possibly be of use to aspiring helpers
> because you are not being specific.  _Take contemporaneous notes._  Post
> details from those notes, when asking for help.



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.

...
> 'nslookup', but there are _lots_ of different ways to use it.  Did you
> take care to specify a particular DNS nameserver to query?  If not, do
> you even know which nameserver got used?
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

> And, just a note about that and the advantage of keeping accurate notes,
> There is no such thing as 'systemd-resolve'.  There _is_ an (optional)
> systemd 'service' called systemd-resolved, which is a buggy and
> much-mocked DNS caching service for the systemd suite that also gets its
> tentacles into lots of other things including system file
> /etc/resolv.conf.  It's unclear to me what you mean when you speak of
> there being nothing odd when you 'run' it.  It's a daemon.

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.
By nothing odd, I mean it did the expected name to ip resolution.

> Basically, you just followed the advice of _somebody_ commenting
> somewhere on the Web, without really understanding what's going on.
> wish you luck with that, I really do, but you may regret that approach
> when various things go haywire.
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.


On 12/15/18, Rick Moen <rick at linuxmafia.com> wrote:
> Quoting Ken Shaffer (kenshaffer80 at gmail.com):
>
>> Looks like I missed the forum discussion of the comcast/systemd-resolve
>> problem:
>> https://ubuntuforums.org/showthread.php?t=2406399
>
> Short version (https://moss.sh/name-resolution-issue-systemd-resolved/):
> One of the innumerble ways systemd-resolved sucks rocks is in failing to
> follow DNS standards, such as DNSSEC's RRSIG digital signatures.
>
> (From above link:)
>
> # host -t RRSIG keyserver.ubuntu.com 127.0.0.53
> Using domain server:
> Name: 127.0.0.53
> Address: 127.0.0.53#53
> Aliases:
> Host keyserver.ubuntu.com not found: 1(FORMERR)
> #
>
> You'd probably have seen entries about the DNS resolution error pointing
> the finger directly at systemd-resolved if it had occurred to you to
> look in /var/log/syslog -- but it didn't, right?

The one systemd-resolved error was not very illuminating, but a clue
-- running at a reduced function level UDP.
...
systemd-resolved[864]: Server returned error NXDOMAIN, mitigating
potential DNS violation DVE-2018-0001, retrying transaction with
reduced feature level UDP.
...

Nota bene:  When Unix
> processes have problems, they very often mutter about that into log files.
> Log files are your friend.  Get to know them.  Many mysterious goings-on
> will become much less so.
>
> And, Ken, are you going to be implementing daft solutions from
> nobody-in-particular on ubuntuforums.org?  Like hardwiring an IP address
> instead of 'pop3.comcast.net' to compensate for systemd-resolved's
> inability to correctly handle DNSSEC?  Or migrating everything from a
> POP3 account to an IMAP account?

Nope, none of that would be interesting to me.
I got three things from the forum discussion (yeah there were a lot of
horrible suggestions):
1) I'm not the only one experiencing this problem.
2)Bug 1805027-"systemd-resolved can't resolve Comcast mail server addresses"
 on which I added myself to the "Does this affect me?" list.
3)Bug 1804487-"systemd-resolved has issues when the answer is over 512
bytes with EDNS disabled"
 which might the be underlying issue, but I'll need further checking
to confirm. The answer to the problem of "How can one name resolution
fail?" is that
the output is too big for the "reduced feature level UDP." in use, so
a time dependency
too, until the reduced level resets.
>
> See, that's the problem with following advice off ubuntuforums.org.
> It's the blind leading the blind.
>
> How about considering -- oh, just spitballing, here -- disabling
> systemd-resolved, seeing that it's bugware 'n' all?  Like, addressing
> the source of the error, rather than just limping around it?
>
Getting rid of systemd-resolved DNS handling is what I accomplished by
changing the one /etc/resolv.conf link to a working (previous?)
version of the link target.
No third party DNS programs needed, my wi-fi hardware work just fine.
No editing system files, things worked for 8 months, no random changes
need apply.
No turning off systemd-resolved services -- "Do one job well" is not
the systemd philosophy, and I'm not willing to check code for anything
else it may be providing.  Who knows what other program(s) may be
checking for a running systemd-resolved, and doing their own (DNS,...)
workaround if it's not -- you could be in a maze of twisty little
passages before you know it.

Minimal system change back to a previously working version -- works for me.
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/<br>
> Related Information <br>
> http://www.shallowsky.com/blog/<br>
> http://explainshell.com/ <br>
>