I was surprised that a
dig
www.unicode.org a
was coming back with a SERVFAIL. I have bind running on the same server, so
I thought it just had a hiccup. Just to be sure I haven't fat-fingered
anything and accidentally set dns lookups to go to another dns server on the
network, I did an explicit "dig @127.0.0.1", and that worked. Must be it,
right? I looked at /etc/resolv.conf and found out that the default server is
127.0.0.53, and then remembered in F33 it was decided to have systemd stick
its nose into another place it didn't belong in the first place.
So, systemd's resolver was broken, for some reason, with no indication why
or how. Nothing was logged anywhere, as I far as I could see. Typical. As I
was researching for the proper way to get rid of yet another pile of systemd
junk, I got to the point of finding out about "resolvectl dns" which proudly
reported the server's IP address as the only DNS server it knows about, then
resolution via 127.0.0.53 started working again. And again, without any
explanation.
Reading the amusing list of buzzwords in "man resolvectl", like "server
feature probing logic" it is unclear why any of that crap is needed. If the
whole purpose of this whole house of cards is to have a proxy that silently
redirect DNS lookups to whatever DNS server is configured via the currently
active connection, I can see the value in that but I do not see what's to be
gained by a fragile "server feature probing logic" that, apparently,
sometimes decides that the DNS server on the same host doesn't really exist,
and decides to reject all requests, on its own initiative, with SERVFAILs.
And provide no useful logging, whatsoever. 'journalctl -u systemd-resolved'
has no explanation, of any kind, whatsoever.
DNS resolution is a critical function. systemd-resolved failed it,
miserably. And without having even the courage to provide any kind of a
useful logging that can be used to file a bug report.