Why even bother covering this case? It seems most likely to come up when this situation is created intentionally, in which case you don't want to go and ruin it by trying to be clever.
On the other hand, if it does present the servers and it's still configurable, might be a bit of a different story.
It's sort of a sane/understandable default, considering all the context.
Though maybe they could switch to CloudFlare.
Google keeps Permanent Logs and doesn't make it easy for me to see whether that information can be shared and to whom.
Cloudflare only stores Public Resolver Logs, deletes them after 25 hours, and acknowledges it shares an anonymized subset of the data only with APNIC Labs.
Your comments about build pipeline and firmware are interesting, and to me fall into two rough camps:
* preventing bugs from leaking private info: to be honest, I trust neither on this, and I'm more worried about Google being sneaky in its ToS than Cloudflare being sloppy in their dev process.
* preventing infiltration from state actors and hackers -- this is a non-goal for me.
So for my goal of limiting the power of surveillance capitalism on my life, Cloudflare appears to be a clear winner.
But I think hard failure is best approach in this case, because this behavior will also make it harder to troubleshoot issues, let say you are setting up a network and misconfigured your router that doesn't provide DNS now you will be puzzled why Internet works on some machines while it doesn't work on others.
Which is in fact the core of the problem. It's actually a fairly rare kind of proxy DNS server software, one for which there isn't really a sensible universal default for the unconfigured case.
In my experience with systemd-resolvd, things happen that make it _believe_ there is no DNS configured, and you end up with something incomprehensible (a "hidden default" or some such).
Please let it just fail so that one at least has a chance of understanding what's happening rather than some magic.
Typical systemd rationalization, imho: "should anything be perceived as wrong, perform hidden magic."
It’s /etc/resolv.conf, and systemd overwrites it, Network Manager overwrites it (like every 10 minutes), dhcp overwrites it, etc. What do they overwrite it to? Most just get it from the router even if the router has no assigned servers. These days manually managing /etc/resolv.conf by hand requires hooking into every service that overwrites it on most systemd distributions. So really the people this change would affect are those with misconfigured routers.
My issue is why they didn’t go with a more private DNS such as Open DNS or even Cloudfare DNS. Google’s privacy policy is worse than either of the two. It seems the questioner asked in bad faith but I would’ve hoped Poettering would respond to the validity and dismiss the malintent instead of dismissing the whole issue.
chattr +i /etc/resolv.conf
Both of them have yaml syntax though, which is imo extremely unfortunate for this kind of configuration.
It’s /etc/resolv.conf, and systemd overwrites it,
Network Manager overwrites it (like every 10 minutes),
dhcp overwrites it, etc. What do they overwrite it to?
/etc/resolv.conf is routinely touched by stuff like NetworkManager and other stuff. Systemd-resolved config seems like the correct place, but I'm not sure how that plays with network-manager.
1. local resolving/forwarding proxy DNS server on loopback
2. resolving/forwarding proxy DNS server on another machine on the LAN with a known IP address
3. resolving/forwarding proxy DNS server on another machine on the LAN but only the LAN's DHCP server definitively knows what its IP address is
4. resolving/forwarding proxy DNS server out on the WAN with a known IP address
5. resolving/forwarding proxy DNS server out on the WAN but only the LAN's DHCP server definitively knows what its IP address is
There's scope for variation within each of these categories, moreover.
Part of the confusion is that most DHCP clients assume that you are doing #3 or #5, and continually switch over to them, until you turn that off by ignoring/superseding the relevant DHCP options. Traditionally in the Unix world one actually generally did #1, with a local BIND being as much a thing as a local Sendmail. Some DHCP clients can do a forwarding variant of #1, but only interoperate (easily) with a few forwarding proxy DNS server softwares. That nowadays #1 might be done with dnscache, or dnsmasq, or PowerDNS, or MaraDNS, or unbound, or something else, introduces configuration file variance but doesn't change the fundamental nature of #1.
systemd-resolved is mainly #1 too, but can operate in a mode where it is #3 or #5, in which case you have it and the DHCP clients doing overlapping work. One of the things that, in fairness, one can actually praise about systemd-resolved is that whilst conventional DHCP clients actually end up rewriting /etc/resolv.conf itself (via resolvconf and similar mechanisms) systemd-resolved instead rewrites two files of its own, and lets you rather choose to symbolically link /etc/resolv.conf to (one of) them. If the conventional DHCP clients also did this more, there'd be less of the conflict between #1/#2/#4 and #3/#5.
chattr +i /etc/resolv.conf
I'm not sure I'm personally a fan, just saying it's something that might become more common based on my read of the systemd docs awhile back.
Not only that, with suitably configured nsswitch.conf, (e.g. with nss-resolve), you might find out that your /etc/resolv.conf is used only by apps that have their own resolver and ignore the glibc one.
If you are using NetworkManager, then in NetworkManager, per each connection. You can also configure which zones each of them can resolve, if they are not global.
So you can things like using your prefered global DNS and then have per-VPN DNS that can resolve hosts in whatever network you VPN into.
There isn't. There are half a dozen packages on a Linux install that each will reset the DNS settings as they wish.
Setting your network DHCP with the correct values tends to work, because everything queries it. But I still didn't manage to replace the upstream DNS on the DHCP server.
NetworkManager? No it's in sysconfig/interfaces. No that was last release. Now it's in a netplan YAML file you get to learn all about.
So many terrific "improvements" every release!
As you mention, this _is_ a rare circumstance, and likely self-induced by some sort of "power user". I assume there are few of those power users who want the choice made for them.
Would be 9.9.9.9 instead of 8.8.8.8. If this would be better is probably a matter of preference. Google owns many, many servers, so maybe using the underdog eases the mind of some people.
These are set for testing/development purposes. For which the priorities are availability/reliability/speed. For those criteria, Google/Cloudflare are empirically the best worldwide.
This literally is used for test-resolving that at best probably would identify a systemd-dev. Everyone else shouldn't care because it's overwritten by distro maintainers.
I assume some of these use it.
>why the tests can't be modified to set DNS/NTP?
I am not a systemd maintainer, they probably could be adjusted, but frankly I don't imagine they or I care enough to do so.
Like I said, this change only affects the devs, so why should it matter to anyone else.
It's working anyway, i think it's resolving off the root nameservers...
I guess... You couldn't go more private than that.
This fallback will only be used when:
* You have no DNS and NTP servers assigned via DHCP (your router does by default in 99.99% of cases) * You have no DNS configured in /etc/resolve.conf * Your distro does not change the defaults to nothing or something else (almost every distro does) * You still have internet connectivity (somehow)
In most cases, these conditions would simply not be met because everyone has DNS configured somehow. This isn't a fallback for when your DNS is unreachable, it's for when no DNS has been configured at all anywhere (including by distro upstream) but you still want to use the internet.
So in that rare circumstance, where your distro didn't change upstream defaults and you don't have any DNS configuration, it will fall back to Google DNS.