Orthopedic surgeons must love systemd articles because of all the knee jerking happening. The systemd-resolved fallback is 1) configurable by the distro and end user [0] and 2) a really useful feature since broken DNS causes a lot hard to solve problems.
The fallback is only used when the network connection is otherwise configured and functional but no DNS servers have been defined and the entry isn't in the hosts file. The daemon respects DHCP and manually provided servers and even the hosts file before it tries a fallback.
Modern distros rely heavily on DNS because their package infrastructure is almost all load DNS load balanced groups of servers. So gone are the days where a public package mirror was just an IPv4 address and a base path, i.e. a singular server. A mirror may not have the same IP address day to day.
A distro disabling the fallback is stupid. Fedora should have at least provided some addresses for the fallback even if they didn't want to use Google.
As for the "hurr durr why does my init system have a DNS resolver?" type questions it's just painful to see that level of ignorance in what seem to be smart people. Systemd contains an init system but it's a project providing a number of system daemons (oh shit the name makes sense). It uses a bunch of useful modern Linux features.
I'm partial to the "hurr durr Unix philosophy!" arguments. They're particularly tone deaf on systems loaded with awk, sed, bash, perl, web browsers, m4, ssh, and emacs. The "Unix philosophy" is a decent idea but not a suicide pact.
If you hate systemd go use a distro without it, there's plenty. You can also use one of the BSDs. You've got options. But if you don't "trust" systemd or just hate it at least have an informed position about it. A dumb commit made without understanding or thinking about the consequences is on the distro maintainer, not the upstream project.
> It uses a bunch of useful modern Linux features.
That's the best thing about it too. It deliberately makes use of Linux features, making it much better than portable lowest common denominator software. Cgroups really does make services more manageable since even badly behaving forking daemons can't escape.
Neither Windows nor macos do this and it seems usability is fine.
Linux has a long way to go to get on par with those two for the average Joe, and no, having DNS fallback absolutely won't help with that.
Note that the article specifically mentions cloud deployments breaking, so this isn't even something that a novice user will encounter, although it confirms my impression that the cloud is being used a lot by some of the greatest idiots in tech.
>Fedora should have at least provided some addresses for the fallback even if they didn't want to use Google.
I have no problem with systemd but no, the OS should absolutely most definitely never use any other DNS than what is supplied to it from either the user or the network. Not only could the server some day become malicious but it is also extremely bad practice to hardcode something like this, even for fallback. It should fail loudly (edit: and if systemd really want a fallback, ask the user if they want to use a fallback on failure before using it).
> A dumb commit made without understanding or thinking about the consequences is on the distro maintainer, not the upstream project.
I think that's unfair they had clearly put a lot of thought into it. I'd argue this is a very clear-cut case of letting perfect be the enemy of good and software engineers thinking they're lawyers. Might want to get some real legal advice on the matter if you're potentially leaving a user without a system that can't research the problem.
It's not even clear what part of data controllers and/or processor means to the providers of software users choose to install in which a system default fallback makes the Fedora org subject to GDPR. AWS might want to worry if they're providing the running Fedora system for me.
> I'd argue this is a very clear-cut case of letting perfect be the enemy of good and software engineers thinking they're lawyers.
That's why the Fedora commit was stupid. It didn't solve any technical issues, it didn't consider negative side effects, and was completely unnecessary.
The more systemd grows, the less I trust it. This particular change to quietly fallback to what may be user-hostile servers and bypass my network controls is particularly concerning.
There are a lot of good reasons to not want a system to fallback to Google/Cloudflare. For one, I simply don't want it not obeying my own dns server in the middle.
Maybe you misunderstood the article? These default fallback servers have been in systemd-resolved for ages (at least since I started using it 3-4 years ago). This article is about a change made by Fedora recently that disabled them.
Additionally, resolved isn't "not obeying" your DNS - this is the fallback that is only used if DHCP doesn't provide a server and the user doesn't configure one. DHCP and user configuration always take precedence.
No Windows doesn't have any fallback DNS servers configured. It will use the ones provided by DHCP or the ones you configure manually.
I don't know about the newest version of macOS but iOS and the versions of macOS I used didn't have any fallback DNS servers.
I wouldn't want a feature like that enabled by default. It can be useful if I have the option to configure it but enabled by default populated with DNS servers chosen by whoever submitted the pull request? No thanks.
No, windows has no such "user friendly" features...irony off.
The fun thing even those amateurish windows users know how to configure the dns server if they use a static ip.
But maybe Linux users are not so technology affine...second irony off.
That is a particularly out of context and uncharitable take on that sentence. I have seen no announcements or discussion about systemd-resolved moving into ignoring DHCP, that is simply a comment from one of the maintainers expressing their opinion about the privacy argument. Other quotes from that same post that make his stance on when to use the fallback pretty clear:
> We use the fallback only as ultimate fallback, when the other option is to not work at all.
> we only did that in case no better DNS configuration was available, i.e. as lastresort, one step before giving up entirely
edit: my bad, the default servers are hardcoded, but you can also provide your own fallback servers. Not sure if that removes the defaults entirely though. If anything, Linux distros should decide what the defaults are, not systemd.
iirc, providing fallback servers in the config, even an empty set, disables the built in ones. The hardcoded ones are essentially just the "default value" if not changed in the config file.
Overall I think this is a positive change and it's what every distro should do. If a distro wants to define default fallback servers then it should just be in the default /etc/systemd/resolved.conf, not hardcorded into the binary.
I have/had phenomenal problems avoiding DNS leakage with openvpn on my ubuntu installation. Spent a day or two, trying fix after fix from many sources, the best solution was ripping out the POS that is systemd-resolved and throwing in dnsmasq.
I personally lost internet access as a result of this update. It was horrible; one day my internet just randomly stopped working. I used my phone to ask for help on Reddit (obviously couldn't use my computer), and it took two days for me to figure out what was going on. Honestly made me despise systemd and lose a lot of faith on Fedora. Why the fuck is my init system doing DNS resolution? Probably the stupidest design decision I've ever encountered in my ten years running Linux. Also, making this invisible change without giving less technically savvy users instructions on how to recover if things go wrong is messed up.
Actually losing DNS is very easy to diagnose, for me at least. Is example.com working? No? Can I ping any DNS server like 1.1.1.1, 4.4.4.4 or 8.8.8.8 or whatever the well-known DNS servers are? Yes? Then my network is fine, it's just DNS.
I don't mean to be condescending, just curious why you didn't figure it out.
How do you diagnose that your DNS have failed if your system seems to be working but is suddenly using a hidden DNS setting? Local DNS settings for your LAN could be dead and gone but "example.com" still work fine. Why? If I hadn't read the article I would have no clue unless I looked a a network dump. It's insane.
One of my first troubleshooting steps is replacing /etc/resolv.conf with just a basic one. By seeing that using Google's DNS directly works, I would know that it's a problem with resolved.
>Why the fuck is my init system doing DNS resolution?
SystemD is more than just an init system, it also runs some system service, like DNS. If you still think of systemd as an init system, then your knowledge of it is outdated by at least a couple of years.
But, if you want to use it as merely an init system, feel free to disable resolved and install dnsmasq instead like in the Good Old Days.
I'd much rather have my system not working than have it randomly start sending the domain part of my browser history to Google without as much as a notification. When you install Fedora, the last thing I'd expect is that it starts acting like a tracker for Google when my DNS server goes down.
I think they should've implemented this differently, sending out a notification that the DNS configuration is broken, with the option of switching to either Google, Cloudflare or letting me fix the network configuration instead of silently failing.
The less tech savvy users are still running Windows where the exact same thing would've happened, with errors just as obscure. No matter what OS you're running, the problem is with your network config, so it should be fixed by whoever manages that instead of relying on some hard-coded defaults somewhere deep inside the DNS resolver. In most cases, that means calling your ISP or calling your IT service desk for support.
I personally hate it when software goes and does some random shit like pick its own DNS server because it somehow has determined that something was broken. Windows is full of this "smart" behaviour and it's one of the reasons I always feel like I need to anticipate its responses to my actions instead of just using it.
There's been as much time between now and this blog post, than there has been between this blog post and the introduction of windows fucking XP !
> systemd is in the process of becoming a comprehensive, integrated and modular platform providing everything needed to bootstrap and maintain an operating system's userspace. It includes C rewrites of all basic early boot init scripts that are shipped with the various distributions.
> systemd is also a big opportunity for Linux standardization. Since it standardizes many interfaces of the system that previously have been differing on every distribution, on every implementation, adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. This improves the lifes of programmers, users and administrators alike.
being more than an init system has been the goal of the project since pretty much the beginning
I was trying to be conservative because I've only really dealt with systemd since about 2016, but damn, nearly a decade of systemd and people still fight systemd vs systemV like it's 2011.
I'm not against systemd myself, to be clear. I think putting services like these into modules of the systemd environment makes sense, and as long as you can disable them if you don't want them, that's perfectly fine. I've had to disable one of them on one of my servers because _something_ was going wrong preventing resolved from caching repeated DNS responses, causing a huge load when a script started scraping a particular domain without any clear indication as to why in the logs. As long as I can do that, I'm perfectly fine with whatever the systemd folks want to integrate next!
There are definitely two sides here. I ended up starting to use NAT reflection a lot in recent years because these half assed fallback configs for DNS (Docker does the same) break split horizon DNS. So everything half works and it’s a pain to diagnose the first few times you run into it.
For users that struggle to diagnose completely broken DNS, I think diagnosing half working DNS will be extremely difficult to do.
Call me old fashioned, but I prefer completely working or completely broken over the “kind of sort of half assed mostly working in fallback mode” that seems to have become popular.
i wouldn't be so fast with blaming systemd for this.
first things first: why isn't your network (via dhcp or local configuration) providing/setting a dns server?
second things: it's fedora that messed up. fallback dns servers are supposed to be there as fallback when nothing else is provided.
It's not systemd's fault, it's fedora's.
if your dhcp server isn't providing a dns server and you're not setting it explicitly then having something else other than systemd would have meant facing the same problem.
Not the person you responded to but I had the same issue across several clean fedora 33 installations and one upgrade from fedora 32.
I’m not exactly knowledgeable about networking but was able to figure out that DNS wasn’t working. Switched to Google’s DNS and went about my day, but for the premier “professional workstation“ Linux distro it’s very disappointing.
Edit: I don’t want to blame fedora too much, I assume the actual issue was with my router or ISP. Windows and every other Linux distro worked fine out of the box though so I don’t really have a reason to spend more time on it.
Just wait until systemd provides you with a hard-coded filesystem a tcp/ip stack and a "better" alternative to wayland. We then call it duolith-OS, your full OS with just two monoliths (Linux and sytemd).
I think that a lot of the reflexive systemd bashing is unwarranted. The Linux kernel provides many not-necessarily-portable-or-directly-comparable features (cgroups & namespaces come to mind, but also things like netlink & sysfs) and I am glad that the creators of systemd chose to explore the design space of an unabashedly Linux-specific "system" layer that straddles the kernel and userland.
That being said, I am somewhat disappointed that the general exploration of that solution space, and the creative use of those kernel features, seems to have ended as systemd matured, expanded its' scope and saw widespread adoption. I also think that the extent of systemd's authoritative dominance over the ecosystem has had a negative impact on user freedom in the broader world of open source. The fact that Snap has actively made a policy choice to _not_ give users the ability to completely disable automatic updates[0] and instead force at least weekly updates is I believe an example of the kind of "we know better than you" mentality that systemd has helped to foster and normalize.
I'd encourage everyone to sometime try booting a Linux machine with boot argument `init=/bin/sh` and see what it actually takes to get a system up to a running state with working networking.
I'm not really pro or con on a fallback... but I wonder why is google and cloudflare being picked here? Are the public DNS servers not allowed to be used? I mean, if privacy is being used as an argument, wouldn't you not want to use corporate controlled dns servers?
Personally, I'd rather it not work, so I can diagnose it and fix it correctly, rather than being blind to the problem, but that's the anti-grandma response not particularly cachet in today's world (which I get, I have a grandma too).
The Google and Cloudflare servers are resolving DNS servers. There are no publicly available resolving DNS servers in the standard DNS system, because the DNS protocol as offered by DNS resolvers is vulnerable to a traffic amplification attack, and only large entities like Google and Cloudflare can afford to spend the resources needed to mitigate that. Of course, Google and Cloudflare don’t do it out of the kindness of their hearts; by monitoring the DNS traffic, they gain enormous insight into what everybody is doing.
>by monitoring the DNS traffic, they gain enormous insight into what everybody is doing.
Both companies only collect anonymous analytics. Google does not use the data for personalizing ads. They both do this to improve speed and security of the Internet. For cloudflare it probably also serves as marketing to help get their name out there.
> Both companies only collect anonymous analytics. Google does not use the data for personalizing ads.
I did not claim that. I said “gain enormous insight into what everybody is doing”, and I chose my words with care. They might only gain insight into what everyone in aggregate is doing, if they are not saving information about each request. But, of course, almost nobody in the world is in the position to know if they are not doing that. It is almost impossible to be in a position to know that Google or Cloudflare is not doing some specific thing.
> They both do this to improve speed and security of the Internet.
Let’s get real. They are doing this to make money. Exactly how this is making Google and Cloudflare money is anyone’s guess, and it might be via some version of what you wrote, and it might be different reasons at different times and at different companies. But again, as I wrote above, almost nobody is in a position to know these things.
> For cloudflare it probably also serves as marketing to help get their name out there.
The upgrade to Fedora 33 killed my laptop's internet, as well, due to the switch over to systemd-resolved. I figured it had to be DNS related, because some of my programs were able to connect to the internet, while anything at the OS-level was failing. While troubleshooting, I was able to at least restore Firefox to a working state by enabling DNS-over-HTTPS, and that confirmed my theory, since it was essentially offloading DNS lookup from the OS to a third-party service.
Fixing it required issuing this not-at-all intuitive command on the command-line:
Fuck if I know what it's doing, and that fix was only applied to my individual home WiFi network, so, for all I know it will still be broken the next time I'm at a coffee shop.
It's the Network Manager command line tool (nice to know its name, that's why I could never find it). The option you are setting has this description: "Do not use DNS Resolver from DHCP".
I didn't find a GUI switch on my computer with that meaning.
Thanks, I think I did eventually figure that out via googling, but the documentation then said it would use "hard-coded public DNS servers", which didn't sound great.
And yeah, I think my bigger irk is that this seems to contradict the network settings in my DE's GUI, where I had explicitly tried setting the DNS lookup servers to 1.1.1.1 instead of using DHCP.
I have yet to understand why we want systemd to take over DNS lookups in the first place, and honestly fallback servers are of debatable value. I personally would prefer to configure fallback servers explicitly, especially since there are cases where the fallback servers could be problematic (e.g. if you are using HE's tunnelbroker service and need to selectively block AAAA records for Netflix; the fallback servers will not do this, and systemd could unexpectedly switch to the fallback servers). Obviously others like the behavior and were surprised when it stopped working as expected.
Systemd is a project to create a unified architecture for all system daemons. The various daemons plug in to systemd via its apis (dmesg, etc) and can all be managed through the same mechanisms (unit files, systemctl, etc). If we want DNS lookups to be managed by a system daemon, then it makes sense for systemd to provide such a daemon.
Fallback servers can be explicitly configured via a configuration file. Systemd provided default fallback servers, if none were set in the config file. IIUC the config file having fallback servers set would prevent the default fallbacks from being used, even if the config file servers weren't responding.
That all sounds very counterintuitive. The "fallback" amounts to a statically configured list of DNS servers, separate from the other lists of statically configured DNS servers, with the property that if no DNS servers were explicitly configured by any method the systemd developers assume DNS servers will be configured by then the system will use the DNS servers that systemd developers thought were a good idea to use. Not only is it complicated and brittle, it also is not clear why a project that intends "to create a unified architecture for all system daemons" is rewriting the rules of how DNS servers are configured. For that matter, why is this logic (which is of questionable value) in systemd instead of NetworkManager (which already deals with DNS server configuration and is user-facing and better able to inform users that the fallbacks are being used)?
The fix for this nonsense is to put what you want into /etc/resolv.conf and chattr +i which sets the immutable bit on the file. I do this on the servers I manage to stop NetworkManager/dhcpd/resolved/systemd/whatever is today's new thing from messing with the file. Although I suppose it's only a matter of time before something works this out and starts "helpfully" adjusting the immutable bit. At which point I'll patch the kernel.
The only reason it's using systemd at all is because on Fedora /etc/resolv.conf is a soft link to /run/systemd/resolve/resolv.conf. As it states in the file ...
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
So if you don't want to use systemd for DNS then just replace the soft link with your own file. For static servers that makes sense; you're going to want to configure resolv.conf to use your own company/data center nameservers. But for not laptops where systemd is managing the DHCP service and the details (and nameservers) will change depending on your location.
Seems like a perfectly legitimate fallback to me. If the DNS server of my ISP is down again (happens once every decade) and then my computer connects to a fallback reasonably trusted by my distribution or otherwise won’t function, then I’d rather have it function. Fedora comes with a huge mirrorlist, and I don’t have to opt-in to every one of those for a functioning computer either.
> [...] and then my computer connects to a fallback reasonably trusted by my distribution or otherwise won’t function, then I’d rather have it function.
I'd rather have it not function, because that way I know something is wrong.
If something breaks somewhere on my network, but my experience stays 'the same', I may miss the fact that something broke because of this 'magic' that occurs behind my back.
If I'm surfing the web, and my browsers hangs with "Looking up news.ycombinator.com..." or returns and error with "Cannot resolve/find server with name example.com.", then I know to start digging into things.
On the other hand, I use HE's tunnelbroker for IPv6 and need to prevent AAAA results for Netflix (which blocks HE IPv6 addresses because in theory someone could evade geographic restrictions on streaming). Easy enough since I run my own DNS server. It sounds like systemd might, without any warning, switch to the fallback servers if something goes wrong, only for someone in my house to complain later on when Netflix is not working (meanwhile the underlying problem goes undetected for who knows how long, because everything is using the fallbacks and nobody notices that something went wrong).
This is a pretty niche edge case: you're enabling a completely unnecessary service and want to tamper with third-party DNS responses, are concerned about something which will only be used if you have multiple DNS servers go down, but don't monitor core network infrastructure or control the settings on those client systems. That's an edge case on an edge case and it's not surprising that they would not prioritize it.
...and the case where DNS servers are not configured by DHCP, not configured statically in NetworkManager or resolve.conf, and not explicitly configured in systemd's own DNS config files, is not an edge case? I am not asking that systemd developer "prioritize" anything -- I am asking that they not introduce some new, counterintuitive logic that unexpectedly breaks things.
But that isn't the only option. You could do that and use Google or systemd could have done the right thing and fallen back on its own recursive resolver. This is basically that worst possible option. I guess it is because it would require more work for systemd.
A fallback should not silently start disclosing your Personally Identifiable Information (IP address in this scenario) to an unrelated third party. It's the law (GDPR).
In the face of failing or missing primary DNS, the system should loudly complain about it, then get authorization from the user to fall back to a default DNS server.
But what about GP's point regarding mirrors? Your IP will be transmitted to potentially a wide range of effectively 3rd party hosts. Looking at my /var/log/dnf.librepo.log I can see requests from a number of hosts, including:
I never explicitly agreed to connect to all of these hosts (some are from repos I did manually enable), and it wasn't made abundantly clear to me during install they would be used. As far as trying to keep GDPR hygiene up, I don't see why this is better than configuring a default DNS server if you're worried about IP address transmission.
There's a huge difference between disclosing your IP and disclosing all the various websites you visit. Moreover, those websites are being disclosed to entities whose commercial business is to track you--for marketing, for performance, w'ever.
Relatedly, your IP is also disclosed via NTP. NTP hosts can be advertised over DHCP, similar to DNS resolvers. And systemd also has built-in fallbacks for NTP, which has actually caused major headaches working on security compliance for U.S. government services because the instances should never use any NTP server other than time.nist.gov. But if time.nist.gov is unavailable for w'ever reason, systemd by default falls back to non-compliant NTP hosts. Disabling this is tricky if you rely on DHCP-advertised NTP servers (which is preferable to minimize the diff between govcloud and non-govcloud deployment images).
A lot of people do not understand what systemd-resolved is, from an architectural standpoint, and because of that do not ask this, which is actually the right question. Yes, running one's own resolving proxy DNS server is widely regarded, by those in the know anyway, as the preferable course of action to using an external service.
The answer is (I suspect) that the systemd people haven't supplied a resolving proxy DNS server of their own to be run, and don't want to tie themselves to running a particular third-party's software. So they tie themselves to a particular third-party's service instead. systemd-resolved has to have somewhere to forward to by default, it being architecturally a purely forwarding proxy DNS server.
It's a complicated topic with lots of pros and cons, which also depend on the role you have. Masking network configuration problems is great for a user, not as great for the admin, but I believe this should be something the network admins test for, not every user ever in the network.
The exposure of the IP address is another aspect. While DNS can expose more info, the complaint also includes IP addresses specifically. I believe this has severe implications: Does any outside communication need to be acked on setup? Should ntp servers be preconfigured on OSes at all? I wonder which other services depend on similar behaviour. Will it end up like consent forms on websites?
I personally think a fallback DNS which masks network errors is a nice thing, as systems should be resilient for users. Errors just need to be discoverable for admins. I usually want things to work, not debug errors of others (or even my own).
Distros can change or remove the default fallback servers at compile time if they want to. This is exactly what happened here, Fedora disabled the default fallback DNS servers.
Im sure this is bound to end up downvoted because its "user hostile" but in the venerable words of the grey beards, linux is already user friendly, its just picky about its users.
replace the word cloud with computer and the cloud argument for fallback evaporates. Cloud has somehow become a surrogate for competent understanding of basic internetworking? cloud-init cant provide a DNS server? provider DHCP isnt a good enough default? Cloud is in this case some premium hand-waving from the systemd community.
fallback in itself is a disingenuous offering as it tries to sidestep and clean up some seriously fundamental problems a user might face that they should address before even standing up their microservice or app or whatnot. If you dont have a cogent DNS provider you should stop deploying, not complain loudly and continue merrily on. Google and Cloudflare have on numerous occasions proven they can and will arbitrarily terminate any and all service to a user for any or no reason at all.
Cloudflare DoH in particular has open and recurring threads for shadow domain blocks or SRVFAIL they return from their service that are neither announced to users or explained. usbank is a TLD that sees a good deal of quietly planned intervention from the DoH service for some reason.
> Cloudflare DoH in particular has open and recurring threads for shadow domain blocks or SRVFAIL they return from their service that are neither announced to users or explained. usbank is a TLD that sees a good deal of quietly planned intervention from the DoH service for some reason.
Could you provide a link or other source for this? I've never heard of this (and can't find anything via google), and I feel like it would be front page news on sites like HN if cloudflare was intentionally providing bad DNS replies.
Edit: Nevermind, I've found it - and found out you're basically trolling with that level of misrepresentation:
Cloudflare DoH in particular has open and recurring threads for shadow domain blocks or SRVFAIL they return from their service that are neither announced to users or explained.
There is no 1.1.1.1 shadowbanning. This is a bunch of crap.
> Cloud has somehow become a surrogate for competent understanding of basic internetworking? cloud-init cant provide a DNS server? provider DHCP isnt a good enough default?
Exactly. If you can’t deal with basic DNS, that’s a good sign you’re not qualified to manage a bunch of cloud infrastructure.
To me Quad9 seem a viable alternative for google/cloudflare
- no logging policy, iow adheres to GDPR
- global anycast service with Multiple points of presence around the world
- 99.999% uptime since 2016
- not opinionated: supports blocklist and 'no security blocklist' (9.9.9.10)
- supports ipv6
- support for dns over tls
- support for DNSSEC
- works with systemd-resolver
No offense to Poettering, but from reading some of the stuff he wrote one just has to wonder why won't he just go away and start working for either Apple or Microsoft, as their OSes are more aligned with what his vision for Linux is.
More examples of the Linux distro world telling us that they know better than all of us, and in spite of decades of something working well one way, this new way, which just happens to benefit certain large monopoly-aspiring companies, is better.
Disabling "fallback" to Cloudflare, Google, et al, is what everyone should do. The idea of "fallback" is completely and horribly flawed, and only an idiot or a corporate shill could think that it's a good idea.
This might explain the growth in distros that expect the user to install and configure his own packages with minimal changes from upstream.
Such include Void and Arch.
As an anecdote, it took me a while to tweak my Void installation to be just right, but I've had no surprises like that. The distro offers you the choice of any or no network manager, any DNS resolver, ALSA or Pulse, etc and assumes nothing. The guidebook specifies how to configure your choice of these packages too.
It's unfortunate to see well-known distros go this way, but there are others who keep user choice alive.
The Linux community is hugely varied. What part of the community do you mean? If you feel that particular part of the community isn't serving you, then there must be a distro that caters to you.
Except for systemd-nspawn[0] systemd is utter mess not because the concept is broken ( it is not, it is actually really clever ) but because its main driver/developer despises his users when they do not agree with his decisions as one can clearly see by looking at the Github issues.
[0] I have a strong suspicion that systemd-nspawn is not a mess because it does exactly one thing - sets up cgroups and namespaces to run a container and runs a container.
> Systemd-resolved continues the systemd tradition of replacing venerable, low-level system components
Serious question: what is vulnerable in my (non systemd-resolved) desktop DNS configuration I've been using for years? This statement is presented as if it were a "everyone knows this" fact about workstation DNS, but I don't. Just your average Linux desktop, nothing fancy.
>> Systemd-resolved continues the systemd tradition of replacing venerable, low-level system components
> Serious question: what is vulnerable in my (non systemd-resolved) desktop DNS configuration I've been using for years? This statement is presented as if it were a "everyone knows this" fact about workstation DNS, but I don't. Just your average Linux desktop, nothing fancy.
Was that corrected later? I could swear I saw "vulnerable" too and interpreted it as "old unmaintained software that could be easily took over by systemd".
The fallback is only used when the network connection is otherwise configured and functional but no DNS servers have been defined and the entry isn't in the hosts file. The daemon respects DHCP and manually provided servers and even the hosts file before it tries a fallback.
Modern distros rely heavily on DNS because their package infrastructure is almost all load DNS load balanced groups of servers. So gone are the days where a public package mirror was just an IPv4 address and a base path, i.e. a singular server. A mirror may not have the same IP address day to day.
A distro disabling the fallback is stupid. Fedora should have at least provided some addresses for the fallback even if they didn't want to use Google.
As for the "hurr durr why does my init system have a DNS resolver?" type questions it's just painful to see that level of ignorance in what seem to be smart people. Systemd contains an init system but it's a project providing a number of system daemons (oh shit the name makes sense). It uses a bunch of useful modern Linux features.
I'm partial to the "hurr durr Unix philosophy!" arguments. They're particularly tone deaf on systems loaded with awk, sed, bash, perl, web browsers, m4, ssh, and emacs. The "Unix philosophy" is a decent idea but not a suicide pact.
If you hate systemd go use a distro without it, there's plenty. You can also use one of the BSDs. You've got options. But if you don't "trust" systemd or just hate it at least have an informed position about it. A dumb commit made without understanding or thinking about the consequences is on the distro maintainer, not the upstream project.
[0] https://wiki.archlinux.org/index.php/Systemd-resolved#Fallba...