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.
pgpwCu9K32Hxr.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
