> Instead, we have gnome, NM, systemd-resolved, firefox et all fighting > over who and how to handle captive portal authentication. What bothers me first and foremost is that I'm not connecting through a captive portal, and somehow I can't fully trust systemd-resolved to DoTheRightThing(tm). On paper I would love to stick to systemd-resolved as my system-wide stub resolver, but now I'm considering going back to stubby, losing turnkey caching and DNSSEC among other interesting properties. I like the opinionated nature of systemd-resolved but the lack of NXDOMAIN makes several (mis)use cases unbearable, like the one described in this thread or even simple typos. There are test cases I can no longer run during $DAYJOB because of this specific opinion (although I still haven't ruled out a mistake on my end). I generally agree that there seems to be a lack of cohesion in the network stack, but have nothing constructive to propose in that area. Between the aforementioned applications and the nsswitch configuration, we are in flexibility hell :) [1] With Fedora 33 I'm trying to understand whether the regression on my system is a bug or a misconfiguration of systemd-resolved, and of course with the current worldwide situation I only have limited networks I can connect to to try different scenarios. None of them involve captive networks. I'll keep searching sporadically until I run out of spare time, at which point I'll have to locally undo this change and go back to my old setup. Dridi [1] exaggerating on purpose _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
