Tim via users writes:
Ed Greshko: >> When I tested reverting to the previous behavior I simply started >> with an empty /etc/resolv.conf. >> No symlink. No selinux troubles. Everything just worked.Sam Varshavchik: > Well, then how do the apps that need to talk to the DNS server find > it? Maybe something in the glibc resolver knows to look in the > alternate locations if /etc/resolv.conf is empty. Didn't he then go on to say that it was populated? (Letting the system create that configuration file.) Surely his subsequent tests were after that stage.
Didn't see that until later.Networkmanager must be checking if /etc/resolv.conf is a symbolic link and only updating its own private resolver configs, otherwise it'll update them and /etc/resolv.conf
Wonder how long this behavior will last.
In the olden days I remember that kind of thing being a continual showstopper for a variety of things. Linux seemed to expect a continual and static internet connection and didn't handle dial-up (where you may not be connected most of the day, and your IP was dynamic). NTP, for instance, would try to start (and fail) if you weren't on-line, and never recover. I had to add a NTPd restart script to my connection script. Heck, even doing a graphical login to your computer could be painful if you didn't have an assigned IP.
I remember those days and I've done some of these things myself, back then.In general, I would agree that having a transparent DNS proxy on localhost that simply forwards queries to the DNS-server-du-jour is a solid idea. Actually, it's a pretty clever hack.
Except that, unsurprisingly, systemd keeps trying to find every possible way to mess it up. It completely fell apart on my server with a bind running on the same machine; systemd somehow found a way to frak it up and have its port 53 proxy start spewing SERVFAILs, for random domains, repeatedly to every client. But sending the same DNS query to bind's port 53 worked as usual. And this wasn't the case of it just sending a TEMPFAIL, or two, or three, but then getting its brains back together and resuming its proxying, quietly. I've tried, over the course of several minutes to see if its brain damage went away. It didn't, it just kept returning SERVFAILs to every query, meanwhile bind, on the same server, was like: "WHASSSUPPPPP!!!!"
And this happened several times, over the course of a week, it wasn't just a one-time fluke.
I defy anyone to come up with a logical explanation why systemd-resolved couldn't find bind running on the same machine, and for it to keel over. Not when the real server it always should be talking to is bind on the same machine. Then we have the other reports, with it going nuts with VPN connections, and spewing tons of garbage into syslog …oops, not syslog, journalctl.
And then, after reading all those assurances how easy it is turn off this "feature" simply by repointing the /etc/resolv.conf symbolic link (or removing it) – only to discover that its tentacles still slither in, via nsswitch.conf?
And then I also read all that jazz about some kind of a overengineered feature-discovery thing it does, for some unclear reason. I'd love to be educated with an explanation of what is that supposed to accomplish. But until then, I just don't trust it. You know, I would've kept quiet and minded my own business, accepting the fact that it's simply a matter of turning off the service, and repointing the symlink. Ok, that sucks but it's not a big deal, not the end of the world, I'll deal with it. But then, discovering this back-door invasion via nsswitch.conf – that ticked me off, somehow.
Oh, and about those NTP restart things we were reminiscing about? That was a long time ago. The forward march of progress carries on. Everything seems to be working just fine now, in that area. My laptop keeps connecting and disconnecting from my wifi, as I put it to sleep, and wake up, all the time. chronie seems to be doing its job, keeping its clock in sync. So, I don't really see what this house of cards is giving me, except a headache.
pgprVYETpBJ8K.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
