Systemd: Don’t fallback to Google NTP and DNS(github.com)
github.com
Systemd: Don’t fallback to Google NTP and DNS
https://github.com/systemd/systemd/issues/12499
235 コメント
The likelihood of this scenario is mind-bogglingly small. You need to have a valid IP configuration for the network you are on, including a default gateway that will route you to the internet, yet somehow do not have any DNS servers configured at all?
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.
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.
It's used for testing. (At least that was the rationale given for the NTP default setting, I guess the same applies for DNS too.)
It's sort of a sane/understandable default, considering all the context.
Though maybe they could switch to CloudFlare.
It's sort of a sane/understandable default, considering all the context.
Though maybe they could switch to CloudFlare.
Cloudflare has a dns privacy policy that is exactly like Google’s but without as many robust internal controls to enforce it. There are reasons to prefer it but a rational risk model isn’t one.
Can you elaborate on these extra internal controls?
Google is pretty vocal about how only reviewed, submitted, and hermetically built code can run in production, how they audit such things, how their hardware security module helps them achieve this, etc. Cloudflare has been pretty vocal about the opposite: how they use tons of off-the-shelf software components, vendor firmware, etc. There's no reason to believe that Cloudflare is as able to provide the privacy they promise as Google is.
Caveat that I am a DNS layman, but I disagree that Google's logging described in https://developers.google.com/speed/public-dns/privacy is equivalent to Cloudflare's described in https://developers.cloudflare.com/1.1.1.1/privacy/public-dns...
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.
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.
I agree, I would find it extremely unintuitive. I'm only scanning the issue at a high level like most others, so it really depends on how systemd presents this information. If it sort of happens in the background with the systemd resolver and shows no DNS servers but queries magically work I would be extremely confused, especially since no upstream resolution is a scenario we see in particular networks with our products.
On the other hand, if it does present the servers and it's still configurable, might be a bit of a different story.
On the other hand, if it does present the servers and it's still configurable, might be a bit of a different story.
The fallback is just stupid. Make it a hard fail in that case, as you pointed out it is a very uncommon scenario. If you really, really want to have fallback, why not have list of root DNS servers and have the resolver do recursive query. I set up my network that way (don't use google, cloudflare, my ISP or anything else) and used it for years without problem.
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.
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.
The fundamental flaw in your argument is that systemd-resolved is not a resolving proxy DNS server. Many other proxy DNS server softwares indeed are switchable between resolving and forwarding modes, some even doing both at once, but systemd-resolved only provides forwarding proxy DNS service. There is no resolving mode to default to.
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.
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.
It’s not “stupid”, it’s reasoned out based on premises that you disagree with. The rest of your argument is weakened by that opening, even if it’s a point worth considering.
The discussion seems to be a logical circle. If the default fallback is such rare circumstance that it doesn't matter, then the best options seems to leave it blank as suggest last in the ticket. Let it fail hard and if any users has a complaint they can direct that towards downstream which should have set a sensible fallback. If the default fallback actually do matter then it seems reasonable to have a discussion about what it should be.
I agree.
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."
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."
> /etc/resolve.conf
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.
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.
I do:
chattr +i /etc/resolv.conf
It seems kinda brutal to just stop writing, but I guess there's a bit of a dogpile for writes on this file, does dhcpconf let you specify DNS servers kind of a 'layer up' from resolvconf?
I usually just add it to either netplan or cloudconfig, whichever is active.
Both of them have yaml syntax though, which is imo extremely unfortunate for this kind of configuration.
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.
There is no definitive place, because there are several ways in which people set up DNS service:
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.
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.
Universal practice is editing the resolv.conf file and then write-protecting it with.
chattr +i /etc/resolv.conf
I think it get's a bit harder than this, with newer systemd supporting name resolution over dbus. It's conceivable that some programs may move away from libc resolvers using resolv.conf and start querying the service directly over dbus.
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.
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.
> with newer systemd supporting name resolution over dbus.
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.
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.
Ah, I didn't want to get into the stupidity and sysadmin nightmare of systemd-resolved, but rest-assured even with systemd-resolved active most users can simply manage their /etc/resolv.conf file and systemd-resolved should respect it. It gets trickier when you don't have a network manager program or are use dhcp, VPNs, etc.
> I still haven't understood where is the definitive place to set dns nowadays.
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.
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.
> I still haven't understood where is the definitive place to set dns nowadays.
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.
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.
That's because distro releases just love to keep changing where network configuration goes.
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!
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!
Are you sure systemd overwrites it? I believe it maintains its own /run/systemd/resolve/{resolv,stub-resolv}.conf file, and it's up to you whether you want to symlink /etc/resolv.conf to one of these or not.
I've run into this situation at home when setting up some new networking equipment with much more configurability than I'm used to. My system had no DNS, alerting me to the issue, and I fixed it. I don't need nor want my systems to decide for me to use Google's DNS, or any other DNS.
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.
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.
This makes it worse. For all those conditions to be met, it would have to be a conscious choice on the part of the user/administrator. And then systemd decides it knows better and resolves using 8.8.8.8 anyways?
You can configure an invalid DNS server or set the DNSConfig in systemd-resolved. The DNS server option being set at all causes the fallback to not be used, regardless if it's empty or not.
Maybe people would have fewer controversy with quad 9?
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.
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.
so... why google and not a privacy-concerning alternative?
Because the privacy concerning aspects are literally irrelevant.
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.
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.
Could you give more details about these tests and why the tests can't be modified to set DNS/NTP?
Likely unit tests...
https://github.com/systemd/systemd/tree/master/test/test-res...
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.
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.
Google offers better documentation than most, and the privacy aspects are good. [1]
Of course you have to trust them but that would be true for any company. Given that the natural default would be even less trustworthy ISP, is not that bad.
https://developers.google.com/speed/public-dns/faq
https://developers.google.com/speed/public-dns/faq
i set up a bind nameserver for my internal network, and mistakenly i did not set upstream resolvers.
It's working anyway, i think it's resolving off the root nameservers...
I guess... You couldn't go more private than that.
It's working anyway, i think it's resolving off the root nameservers...
I guess... You couldn't go more private than that.
> I will block discussions here now, since I don't think we need the input from the script kiddie peanut gallery here.
How not to interact with your community 101.
Defaults matter, because even if they are changeable via a build-time flag, most of the time they won't (how many people knew this was a default before now?)
How not to interact with your community 101.
Defaults matter, because even if they are changeable via a build-time flag, most of the time they won't (how many people knew this was a default before now?)
> How _not_ to interact with your community 101.
On the contrary, I think he handled it perfectly.
I've become exhausted with most discussions on social media, because conversations frequently get hijacked by loud people with strong opinions that don't express them in good faith. Without strict moderation, it can become impossible to have a rational discussion on certain topics. For example, pretty much anything on HN involving Google devolves into worthless noise.
In the case discussed in the OP, Poettering clearly has no intention of changing the default configuration (at least based on the reasons given in the issue), and has provided a way of modifying the configuration for those that care enough to change it. There's no value in further debate, and closing the issue to further discussion keeps Poettering and other contributors from getting distracted/burned out by unproductive conversation.
If people don't like it, they're free to fork Systemd or start up their own competing software project, and then they can handle community interaction for their own project in whatever way suits them.
Frankly, I wish more discussion were handled this efficiently.
On the contrary, I think he handled it perfectly.
I've become exhausted with most discussions on social media, because conversations frequently get hijacked by loud people with strong opinions that don't express them in good faith. Without strict moderation, it can become impossible to have a rational discussion on certain topics. For example, pretty much anything on HN involving Google devolves into worthless noise.
In the case discussed in the OP, Poettering clearly has no intention of changing the default configuration (at least based on the reasons given in the issue), and has provided a way of modifying the configuration for those that care enough to change it. There's no value in further debate, and closing the issue to further discussion keeps Poettering and other contributors from getting distracted/burned out by unproductive conversation.
If people don't like it, they're free to fork Systemd or start up their own competing software project, and then they can handle community interaction for their own project in whatever way suits them.
Frankly, I wish more discussion were handled this efficiently.
Its not really efficiently.
Something like: "we've discussed this a number of times, see #12345" closing now
would have closed the ticket and not made the front page.
By being a top draw dick about it (when the originator was at least being earnest) the debate rolls on.
He had given a full answer, he could have left it there, but chose not to.
its this kind of "rock star" and cheerleaders that give IT a bad smell.
Something like: "we've discussed this a number of times, see #12345" closing now
would have closed the ticket and not made the front page.
By being a top draw dick about it (when the originator was at least being earnest) the debate rolls on.
He had given a full answer, he could have left it there, but chose not to.
its this kind of "rock star" and cheerleaders that give IT a bad smell.
Are you talking about the comment that closed the ticket [1]? Are we not seeing the same thing, because that's not a "top draw dick" I'm seeing.
He was perfectly reasonable. And I don't know if you've ever managed any popular open source projects, however it's best to close tickets fast instead of letting them linger on, especially when you have over 1000 opened issues and especially if, as a maintainer, you know that you won't change your mind about that issue.
Then he got accused of being funded by Google. He actually showed restraint.
[1] https://github.com/systemd/systemd/issues/12499#issuecomment...
He was perfectly reasonable. And I don't know if you've ever managed any popular open source projects, however it's best to close tickets fast instead of letting them linger on, especially when you have over 1000 opened issues and especially if, as a maintainer, you know that you won't change your mind about that issue.
Then he got accused of being funded by Google. He actually showed restraint.
[1] https://github.com/systemd/systemd/issues/12499#issuecomment...
> Are we not seeing the same thing, because that's not a "top draw dick" I'm seeing.
> He was perfectly reasonable.
The original complaint had the form "this default should be changed for reason X". Poettering's response was "our defaults are Y, and you can change them". That's not perfectly reasonable. It's a non sequitur. Poettering's response passively-aggressively ignores what the original complaint was all about, instead of simply issuing a direct rejection.
> He was perfectly reasonable.
The original complaint had the form "this default should be changed for reason X". Poettering's response was "our defaults are Y, and you can change them". That's not perfectly reasonable. It's a non sequitur. Poettering's response passively-aggressively ignores what the original complaint was all about, instead of simply issuing a direct rejection.
It isn't a non-sequitur, he offered a solution for users that would like different settings, while choosing not to engage in pointless arguments.
While professional courtesy is recommended, maintainers don't really owe an explanation for their work when provided for free. Put that man on a payroll and you might deserve a more detailed answer.
While professional courtesy is recommended, maintainers don't really owe an explanation for their work when provided for free. Put that man on a payroll and you might deserve a more detailed answer.
It is absolutely a non-sequitur to tell someone what the defaults are when they are complaining that they do not like what the defaults are. "Choosing not to engage in pointless arguments" would be not responding at all, rather than responding in a manner that is implicitly insulting. Poettering phrased his response as if he was answering a different issue than the one he was actually responding to. Deliberately misinterpreting someone's question instead of directly saying he didn't want to get into that matter is poor behavior.
If they don't like the defaults, they could just fork the project.
Its more basic than that. He chose not to give a _detailed_ answer, and diverted from the original point. Thats perfectly fine
then to go off on one here: https://github.com/systemd/systemd/issues/12499#issuecomment... its just being a dick. Its not even entertaining.
then to go off on one here: https://github.com/systemd/systemd/issues/12499#issuecomment... its just being a dick. Its not even entertaining.
yes, and he would have been able to close it again, instead he wrote this:
https://github.com/systemd/systemd/issues/12499#issuecomment...
https://github.com/systemd/systemd/issues/12499#issuecomment...
After being insulted with that comment on Google finding?
As I said, he showed restraint.
As I said, he showed restraint.
It’s sad times when “showing restraint” means insulting an entire community because one person asked a stupid question first.
He probably should have worded it better but the comment does not refer to the entire community. Unfortunately there absolutely is a collection of anti-systemd trolls within the community that have been egging him on for quite some time now and will gladly dog-pile on these github issues with insults and conspiracy theories. I honestly did not even know who he was before I saw lots of this type of toxic and hateful post being directed at him on reddit.
It is regrettable that this comment got down-voted (at the moment of writing this).
I very much agree — and I would add that there's a strong entitlement complex among loud non-contributors.
If you don't contribute anything but opinions, then be respectful, respect the author's choices, or start your own fork, which is what open source is about.
I very much agree — and I would add that there's a strong entitlement complex among loud non-contributors.
If you don't contribute anything but opinions, then be respectful, respect the author's choices, or start your own fork, which is what open source is about.
Name calling is never productive, and the maintainer of a project sets the tone for the interaction of the entire community.
> In the case discussed in the OP, Poettering clearly has no intention of changing the default configuration (at least based on the reasons given in the issue),
Poettering never even acknowledged that there are privacy concerns. Simply saying "if you don't like the defaults, change it yourself" is in no way equivalent to saying "I don't care about or share your privacy concerns, but here's how to override the defaults if they bother you".
Poettering never even acknowledged that there are privacy concerns. Simply saying "if you don't like the defaults, change it yourself" is in no way equivalent to saying "I don't care about or share your privacy concerns, but here's how to override the defaults if they bother you".
Handled perfectly would be "No, reference bug #X, closing" and closing/locking the thread. Question gets answered, nobody gets insulted.
Denigrating your community as the "script kiddie peanut gallery" is, at best going to piss off your community and at worse make them less likely to work with you in the future.
Denigrating your community as the "script kiddie peanut gallery" is, at best going to piss off your community and at worse make them less likely to work with you in the future.
To be fair to Poettering, someone accused the systemd devs of being on Google's payroll, if I were him I'd be annoyed as well.
> if I were him I'd be annoyed as well.
Especially when he had to answer in the affirmative, that there is indeed a conflict of interest, but it's a really tiny one that hardly anyone would be bothered by.
Especially when he had to answer in the affirmative, that there is indeed a conflict of interest, but it's a really tiny one that hardly anyone would be bothered by.
Google has a well known, and well documented history of donating to open source projects to get their own products added as defaults. Combine with a for-profit company (RedHat) who does not disclose all of their financials (and that’s their prerogative), and it’s a perfectly reasonable question to ask.
The original question was stupid. We all get that. We’ve all suffered that on occasions at work. But that doesn’t justify his grossly unprofessional response.
Defaults matter, but he's right to say each distro should be the ones setting the default. Most people aren't compiling systemd themselves, they're using the one compiled by their distro maintainer(s). I don't think this is anything to worry about and he's right to shut out pointless conversation from people who misunderstand the actual situation. Accusations of being paid by Google (or any other entity) is ludicrous and can easily be interpreted as insulting too.
> Defaults matter, but he's right to say each distro should be the ones setting the default. Most people aren't compiling systemd themselves, they're using the one compiled by their distro maintainer(s).
In that case, the final comment in the discussion is correct: systemd itself should not have a default, and should require the distro maintainer to explicitly set these values to whatever default they want to use.
In that case, the final comment in the discussion is correct: systemd itself should not have a default, and should require the distro maintainer to explicitly set these values to whatever default they want to use.
I agree. There shouldn't be any hardcoded DNS/NTP fallbacks. I don't use systemd on any of my personal systems or my dedicated server (Gentoo/Void), so I don't have to worry about this. But on my Ubuntu VMs, I guess there's a fallback DNS/NTP in my startup process I never knew about.
I agree. The default should be set (and required; without defaults) by the distro maintainers downstream. Just leave them out here.
I agree. The default should be set (and required; without defaults) by the distro maintainers downstream. Just leave them out here.
I'm inclined to agree, though without being familiar with systemd's codebase and infrastructure, there may be technical reasons why that hasn't been done
There were no accusations. Someone asked a fair question. The maintainer clearly overreacted.
No, that question was asked in bad faith. By asking the question, you implying that there's a conflict of interest or some monetary motivation for the decision. If they truly wanted to ask a neutral question, something like "Given the for-profit nature and potential privacy concerns, why is Google's DNS the default instead of some other non-profit entity?"
> No, that question was asked in bad faith. By asking the question, you implying that there's a conflict of interest or some monetary motivation for the decision.
It's not bad faith to ask that question, when raising the issue previously got a complete non-answer that failed to acknowledge that there was a reason behind wanting different defaults. "Why didn't you answer the question the first time?" is fair game; Poettering provoked that response.
It's not bad faith to ask that question, when raising the issue previously got a complete non-answer that failed to acknowledge that there was a reason behind wanting different defaults. "Why didn't you answer the question the first time?" is fair game; Poettering provoked that response.
Been poorly worded doesn't make the question bad. Your example makes the exact same assumptions.
And they're fair assumptions - Google is well known for giving funding to open source projects to get their products set as defaults.
And they're fair assumptions - Google is well known for giving funding to open source projects to get their products set as defaults.
> Your example makes the exact same assumptions
My example does not make the assertion that Google donated/bribed the systemd project, so no, it does not make the same assumptions. It intentionally leaves any implied motivations open ended.
> And they're fair assumptions - Google is well known for giving funding to open source projects to get their products set as defaults.
The only case I'm aware of is Firefox, which had a contract with Mozilla to have the Google search engine be the default. I'm curious to hear about more though.
The privacy concerns with Google DNS seem to be partially unfounded too [1]. Granted, that is coming from Google themselves, but privacy policies are legally binding. For the record, I don't think there should be a default at all, but I have no problems with how Poettering handled this.
[1]: https://developers.google.com/speed/public-dns/faq#privacy
My example does not make the assertion that Google donated/bribed the systemd project, so no, it does not make the same assumptions. It intentionally leaves any implied motivations open ended.
> And they're fair assumptions - Google is well known for giving funding to open source projects to get their products set as defaults.
The only case I'm aware of is Firefox, which had a contract with Mozilla to have the Google search engine be the default. I'm curious to hear about more though.
The privacy concerns with Google DNS seem to be partially unfounded too [1]. Granted, that is coming from Google themselves, but privacy policies are legally binding. For the record, I don't think there should be a default at all, but I have no problems with how Poettering handled this.
[1]: https://developers.google.com/speed/public-dns/faq#privacy
The defaults have kicked me in the genitals a number of times
Stuff magically failing, with no obvious reason why. The I realise that someone has cocked up the DNS config, its been silently rejected and is now defaulting back to the default DNS config.
I want it to fail, and fail loudly, not limp on and cause odd errors.
Stuff magically failing, with no obvious reason why. The I realise that someone has cocked up the DNS config, its been silently rejected and is now defaulting back to the default DNS config.
I want it to fail, and fail loudly, not limp on and cause odd errors.
> With the above response, might I ask the developers a question: has this project received any donations from Google?
That sounds very accusatory to me. It’s just worded as a question.
That sounds very accusatory to me. It’s just worded as a question.
Don't sound accusatory to me and only requires a one word response: No
Just mentioning Google or money does not an accusation make.
Just mentioning Google or money does not an accusation make.
Uh... RedHat is owned by IBM.
Given:
1) how broadly Google spreads its money to open source projects to get its products set as defaults
2) that Redhat is a private company who does not disclose their funding sources
I think it's a perfectly reasonable question, given the situation (Google product set as a default in an open source project).
1) how broadly Google spreads its money to open source projects to get its products set as defaults
2) that Redhat is a private company who does not disclose their funding sources
I think it's a perfectly reasonable question, given the situation (Google product set as a default in an open source project).
> that Redhat is a private company who does not disclose their funding sources
Red Hat's IPO was in 1999, and they were bought by IBM in 2019.
Red Hat's IPO was in 1999, and they were bought by IBM in 2019.
Did you read the link you posted? There's no shift of burden of proof, as all the maintainer would have to do is answer "No". I agree that there are people who do this in bad faith, but the question seemed totally reasonable to me.
> all the maintainer would have to do is answer "No"
That would technically be a lie. The answer is actually a qualified "yes".
That would technically be a lie. The answer is actually a qualified "yes".
If the distro is supposed set a default, don't provide one.
> How not to interact with your community 101.
Maybe, but lowering a discussion to accusations of bribery is also not how to interact with project members.
Maybe, but lowering a discussion to accusations of bribery is also not how to interact with project members.
No, it's not.
But one person is a paid maintainer for the project, the other an (admittedly paranoid) non-paid user. The standards for a paid employee are (and should be) higher.
But one person is a paid maintainer for the project, the other an (admittedly paranoid) non-paid user. The standards for a paid employee are (and should be) higher.
You don't get to be an asshole to waiters just because they're "paid" and it's "their job".
You don't get to be an asshole to open source maintainers just because they're "paid" and it's "their job".
If in either situation, a person is an asshole to the paid employee, said employee most definitely has a right to defend themselves.
You don't get to be an asshole to open source maintainers just because they're "paid" and it's "their job".
If in either situation, a person is an asshole to the paid employee, said employee most definitely has a right to defend themselves.
If a waiter said something like this, they would likely have been fired. What was said was only a bit rude, not even remotely abusive, and hardly justifies the attitude expressed towards the community as a whole (the so-called "script kiddy peanut gallery").
If a waiter said something like this to a client being an asshole, some restaurants may fire them if the client is "important" enough, primarily because waiters are easily replaced.
But nowadays, a lot of restaurants will side with the waiter on such issues and they're damn right to do so.
I'll add that what you're seeing here is but the tip of the iceberg of abuse that Lennart has to deal with every day. I challenge you to put up with 1/100th of what he's putting up with without "raising your voice" or what have you.
But nowadays, a lot of restaurants will side with the waiter on such issues and they're damn right to do so.
I'll add that what you're seeing here is but the tip of the iceberg of abuse that Lennart has to deal with every day. I challenge you to put up with 1/100th of what he's putting up with without "raising your voice" or what have you.
This isn't something normally set by the end-user but by vendors, and I do presume that distro teams absolutely have enough opinion and energy to set DNS defaults.
Poettering being insulting and smug? Who'd've guessed.
This is why Linux and SystemD will struggle to find maintainers in the future: https://www.theregister.com/2020/06/30/hard_to_find_linux_ma...
I'm not sure I agree; Poettering isn't being harsh to his collaborators, here. He's protecting them against the implicit accusation of a hostile community member. I'd be _more_, not less likely to want to work on a project with someone who does that.
>I'm not sure I agree; Poettering isn't being harsh to his collaborators
Not accepting any discussion by blocking all community efforts is quite bad imo. Would like still like to start any discussion, put effort into making even smallest change, to be blocked? This is strong sign of ignorance.
I often contribute to OSS on gitlab and github. When a single/first MR is not merged OR commented on within a week I don't even try there again, waste of time.
Not accepting any discussion by blocking all community efforts is quite bad imo. Would like still like to start any discussion, put effort into making even smallest change, to be blocked? This is strong sign of ignorance.
I often contribute to OSS on gitlab and github. When a single/first MR is not merged OR commented on within a week I don't even try there again, waste of time.
In open source, today's community member is tomorrow's collaborator. If you are a tool to your community members, you will end up getting less new collaborators.
It was called for. The commenters were pretty toxic IMO.
Yeah. That was very rude. I’d heard the systemd developers severely lack social skills. The way he went from 0 - EXASPERATED was surprising and uncalled for.
Almost as if he'd been the target of a nearly-non-stop decade of constant hostility and abuse or something.
Lennart is not that good at the human-facing parts of maintainership. That's fine, he doesn't have to be.
I'm just surprised that people don't see how his communication style (in general and in the linked thread) makes interactions harder than it needs to be for himself and everyone involved.
I'm just surprised that people don't see how his communication style (in general and in the linked thread) makes interactions harder than it needs to be for himself and everyone involved.
> How not to interact with your community 101.
Give Poettering a break! You have no clue what is to be in his shoes. ;)
Give Poettering a break! You have no clue what is to be in his shoes. ;)
Whoever knows how to build systemd should know about this build-time flag
I have to picture that systemd has hundreds, if not thousands, of build time flags. Is it reasonable to expect all non-systemd builders to grok every flag? My opinion is that it is not - that pushing it back on the individual distros is a cop out on Red Hat's side.
EDIT: 172 distinct build-time options, in today's master. Not all appear to be used as part of the build, since the build script only references 142 of the options set in meson_options.txt.
EDIT: 172 distinct build-time options, in today's master. Not all appear to be used as part of the build, since the build script only references 142 of the options set in meson_options.txt.
systemd plays a crucial role on systems that use it. Whoever builds systemd for a distribution should definitely be aware of those flags; if you don’t understand them, then you are not qualified sufficiently to ship systemd for others to use.
Edit: Speaking as a package maintainer myself.
Edit: Speaking as a package maintainer myself.
How many packages do you, as a package maintainer, maintain? Can you say with high confidence that you are aware of all of the flags offered by all of those packages, including changes to the defaults between package releases?
I expect that package maintainers are human, and put a fair bit of trust in the upstream developers, and will only tinker with build flags for issues which are specific to the distro. I also expect that they will miss changes to defaults, or new flags, or deprecated flags, quite often.
I looked at the systemd defaults to see this issue for myself, and the fact that Google's nameservers are in the DNS defaults didn't immediately pop out to me (it's a list of 8 mixed IPv4 and IPv6 addresses).
I expect that package maintainers are human, and put a fair bit of trust in the upstream developers, and will only tinker with build flags for issues which are specific to the distro. I also expect that they will miss changes to defaults, or new flags, or deprecated flags, quite often.
I looked at the systemd defaults to see this issue for myself, and the fact that Google's nameservers are in the DNS defaults didn't immediately pop out to me (it's a list of 8 mixed IPv4 and IPv6 addresses).
> How many packages do you, as a package maintainer, maintain? Can you say with high confidence that you are aware of all of the flags offered by all of those packages, including changes to the defaults between package releases?
Absolutely. For a responsible package maintainer, reading changelogs and release notes of new releases is a must. For sensitive software (eg: key system libraries), I usually also look at the full diff between releases. I also run tests with dependent software before uploading my version, lest I break any packages that depend on mine. etc.
And this is quite typical of your average distribution package maintainer.
Absolutely. For a responsible package maintainer, reading changelogs and release notes of new releases is a must. For sensitive software (eg: key system libraries), I usually also look at the full diff between releases. I also run tests with dependent software before uploading my version, lest I break any packages that depend on mine. etc.
And this is quite typical of your average distribution package maintainer.
Fair enough - thank you!
[deleted]
Usually if I'm building something from source I read the entire set of configuration flags and take notes on which configurations I might like, which configurations I might want to turn off, and which configurations I don't understand. So yes I would read all the options in the meson_options.txt and decide how I want to configure systemd before beginning the cross-compile.
Someone posted the other day that an autotools/automake should canonically be run like this:
Someone posted the other day that an autotools/automake should canonically be run like this:
./configure
make
make install
./configure --help
(read "help" intently)
mkdir build_output_dir
cd build_output_dir
../configure [huge list of options for the build]
make
make install
> (how many people knew this was a default before now?)
Pretty much everyone who ever opened /etc/systemd/resolved.conf
Pretty much everyone who ever opened /etc/systemd/resolved.conf
Did you know that there are at least four different file locations that resolvers can be set in for systemd-resolved?
The defaults being in a commented-out section in one of these four locations (and in a file whose name does not match the linux standard of resolv.conf) is, frankly, not a big help in identifying what's really being used.
https://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved....
The defaults being in a commented-out section in one of these four locations (and in a file whose name does not match the linux standard of resolv.conf) is, frankly, not a big help in identifying what's really being used.
https://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved....
Actually, it's five, or even six. systemd doco is bad at including /usr/local/ .
You are pointing to the wrong manual page, incidentally. It's resolved.conf(5). This fails to list /usr/local/lib/systemd/resolved.conf.d/ , which is scanned before /usr/lib/systemd/resolved.conf.d/ (and if configured /lib/systemd/resolved.conf.d/).
You are pointing to the wrong manual page, incidentally. It's resolved.conf(5). This fails to list /usr/local/lib/systemd/resolved.conf.d/ , which is scanned before /usr/lib/systemd/resolved.conf.d/ (and if configured /lib/systemd/resolved.conf.d/).
How do any of those 4 resolv.conf location variants change where the compiled-in fallback is configured/visible?
If user wants to know what's really being used for name resolution he should go to /etc/nsswtich.conf and /etc/hosts and /etc/resolv.conf as usual.
If user wants to know what's really being used for name resolution he should go to /etc/nsswtich.conf and /etc/hosts and /etc/resolv.conf as usual.
If systemd-resolved is actually being used, /etc/resolv.conf will list only 127.0.0.53, and to find out what systemd-resolved itself is using one has to visit the resolved.conf configuration files, which is what falcolas is apparently talking about.
But then if one is using, say, dnscache or dnsmasq or MaraDNS or BIND or PowerDNS or any other such software, one has to do the same thing. /etc/resolv.conf will list simply 127.0.0.1 or some such, and one has to go further to the configuration files of those softwares to find out what they are using for resolution/forwarding.
DNS softwares having their own configuration files is normal. falcolas is apparently getting at the fact that systemd-resolved uses the same style of configuration as the other systemd programs do: files and drop-in directories in /etc/systemd, /run/systemd, /usr/local/lib/systemd, /usr/lib/systemd, and (if configured) /lib/systemd, meaning that one has to read all of this together.
But then if one is using, say, dnscache or dnsmasq or MaraDNS or BIND or PowerDNS or any other such software, one has to do the same thing. /etc/resolv.conf will list simply 127.0.0.1 or some such, and one has to go further to the configuration files of those softwares to find out what they are using for resolution/forwarding.
DNS softwares having their own configuration files is normal. falcolas is apparently getting at the fact that systemd-resolved uses the same style of configuration as the other systemd programs do: files and drop-in directories in /etc/systemd, /run/systemd, /usr/local/lib/systemd, /usr/lib/systemd, and (if configured) /lib/systemd, meaning that one has to read all of this together.
It would be clearer if he linked to https://jlk.fjfi.cvut.cz/arch/manpages/man/resolved.conf.5.e... then.
Anyway, in default config, there will be only the file I mentioned. And whole this issue is about default configuration.
Anyway, in default config, there will be only the file I mentioned. And whole this issue is about default configuration.
Actually, no. The headlined issue is about what the fallback is when there is no file, or a file that doesn't specify a setting.
Pretty much everyone who ever opened /etc/systemd/resolved.conf
That's a vanishingly small percentage of people who use systemd.
That's a vanishingly small percentage of people who use systemd.
Perhaps, but still larger than the set of people who compile their own systemd builds.
Also it's the answer to the question. The defaults are visible in config files as commented out lines. No need to check build scripts, etc.
Also it's the answer to the question. The defaults are visible in config files as commented out lines. No need to check build scripts, etc.
If you are correct, Poettering doesn’t understand how to configure the last resort fallback.
He says the easiest way is to recompile systemd from source.
Presumably he knows more about systemd then the average Linux user.
He says the easiest way is to recompile systemd from source.
Presumably he knows more about systemd then the average Linux user.
You're assuming a lot of things. That I'm an average user (I'm not) and that thing about Poettering.
Also, “work with your downstream”
rings hollow coming from a RedHat employee.
Anyway, per his advice, here is how I worked with my Linux distribution to fix the problem: I switched away, and donated to ones that don’t use systemd.
Anyway, per his advice, here is how I worked with my Linux distribution to fix the problem: I switched away, and donated to ones that don’t use systemd.
Does it matter now (that the maintainers can't dialogue with the community)?
In one side major linux distros took in systemd (as, ok, granted, the "less worse" of the options) so the point is moot. I mean everybody should know how LPs management of the project works.
At the same time I can understand trying to cut down on drama in online discussions (though I agree that default might make more sense as a run-time configurable, not as a build-time one).
(And yes defaults are important)
In one side major linux distros took in systemd (as, ok, granted, the "less worse" of the options) so the point is moot. I mean everybody should know how LPs management of the project works.
At the same time I can understand trying to cut down on drama in online discussions (though I agree that default might make more sense as a run-time configurable, not as a build-time one).
(And yes defaults are important)
Systemd being the default init system in the distro, and google being a default resolver in systemd, are separate issues.
Yes, it does matter. It's being pushed out as the init system for a lot of linux systems, and I believe it's perfectly reasonable to expect that your fallback DNS resolver is not set to a for-profit data-collection organization.
Yes, it does matter. It's being pushed out as the init system for a lot of linux systems, and I believe it's perfectly reasonable to expect that your fallback DNS resolver is not set to a for-profit data-collection organization.
Why is this repeatedly raised? This is only done like this for development purposes. It has been discussed for years at this point.
Distros/users are encouraged to change these defaults and many do.
Seems pretty clear cut and simple to me.
Distros/users are encouraged to change these defaults and many do.
Seems pretty clear cut and simple to me.
> Distros/users are encouraged to change these defaults and many do.
Haven't we learned enough over the years from projects like PHP and MySQL that having defaults "for developers" and expecting them to be changed for production use is a terrible idea?
The defaults should be sane, secure, and privacy-forward for the majority of users. If such defaults can't be agreed upon, there should be no defaults and the users should be forced to set it appropriately for their needs.
---
Personally I gave in to the Google monster years ago so it doesn't bother me, but I can certainly see why a lot of people would find these defaults concerning.
Beyond that, I definitely agree with those who are pointing out that the fallback behavior altogether is undesirable. If my chosen DNS servers fail to respond I don't want my system to go out and try some other random servers, I want it to indicate a failure and let me fix it.
Haven't we learned enough over the years from projects like PHP and MySQL that having defaults "for developers" and expecting them to be changed for production use is a terrible idea?
The defaults should be sane, secure, and privacy-forward for the majority of users. If such defaults can't be agreed upon, there should be no defaults and the users should be forced to set it appropriately for their needs.
---
Personally I gave in to the Google monster years ago so it doesn't bother me, but I can certainly see why a lot of people would find these defaults concerning.
Beyond that, I definitely agree with those who are pointing out that the fallback behavior altogether is undesirable. If my chosen DNS servers fail to respond I don't want my system to go out and try some other random servers, I want it to indicate a failure and let me fix it.
Probably because it shows the character of the systemd devs.
I hope if I were in the maintainer's shoes I wouldn't have raised my hackles quite as quickly, but speaking as anyone responsible for making any decisions that might be unpopular, it does get pretty tiring when someone very quickly reaches for the good old "I'm not saying you're a shill, I'm just asking if you're a shill."
The part of the comment in question:
With the above response, might I ask the developers a question: has this project received any donations from Google?
The part of the comment in question:
With the above response, might I ask the developers a question: has this project received any donations from Google?
I can imagine it getting a little frustrating to have to constantly reiterate the same point over and over again.
Especially when people are refusing to understand the reasoning and logic explained from last time. It's already been explained, a quick duckduckgo search can show quickly what the reasons are and why the whole privacy argument is irrelevant here.
Especially when people are refusing to understand the reasoning and logic explained from last time. It's already been explained, a quick duckduckgo search can show quickly what the reasons are and why the whole privacy argument is irrelevant here.
Easy fix! Just change it or dont set it at all.
Instead, he chooses drama.
Instead, he chooses drama.
He chose the option that was the fastest for development purposes/testing. On average Google/Cloudflare worldwide has the fastest and most reliable DNS services.
Why would he change it?
He says it clearly that it's the responsibility of distro maintainers to modify these defaults which they are encouraged to do.
It's everyone else who is choosing drama. This is for development purposes, the entire privacy argument is completely irrelevant.
Why would he change it?
He says it clearly that it's the responsibility of distro maintainers to modify these defaults which they are encouraged to do.
It's everyone else who is choosing drama. This is for development purposes, the entire privacy argument is completely irrelevant.
If it's so irrelevant, then why _not_ change it? That's what good leaders do. Small price to pay to get good will and a large group of bystanders on your side.
His way generates conspiracy and alienation.
His way generates conspiracy and alienation.
Because all of the alternatives are simply less reliable, less performant, less available and offer no benefits for development/testing. That is the only factor that matters here.
>That's what good leaders do. Small price to pay to get good will and a large group of bystanders on your side.
I don't think he cares about people who are determined to stay ignorant. Especially of those who refuse to comprehend the needs/use cases for different parties.
Frankly considering he has received death threats about systemd, I am surprised he even put a response at this point. It would make sense to me if he just closed the ticket immediately with a link to the previous discussion.
>That's what good leaders do. Small price to pay to get good will and a large group of bystanders on your side.
I don't think he cares about people who are determined to stay ignorant. Especially of those who refuse to comprehend the needs/use cases for different parties.
Frankly considering he has received death threats about systemd, I am surprised he even put a response at this point. It would make sense to me if he just closed the ticket immediately with a link to the previous discussion.
Actually, the people involved did not send things for Lennart Poettering to have received.
* https://news.ycombinator.com/item?id=8417369
* https://news.ycombinator.com/item?id=12859758
* https://news.ycombinator.com/item?id=8417369
* https://news.ycombinator.com/item?id=12859758
>with a link to the previous discussion
Some people are really bad at "information retrieval" (and some people are unusually non-worried about public pressure), so maybe finding a link into the previous discussion would've been more work for Poettering than what he actually did.
Some people are really bad at "information retrieval" (and some people are unusually non-worried about public pressure), so maybe finding a link into the previous discussion would've been more work for Poettering than what he actually did.
Sure, he doesn't care, and so then this happens. We happen. Drama.
The only factor here that matters is development/testing.
Drama is irrelevant and wouldn't change anything. At worst, he gets his issue tracker filled. If it bothers you, then the only thing that you can do is change to Devuan or don't use systemd-networkd/systemd-resolved. Distros are going to continue using systemd irrespective of this nonsense drama.
Drama is irrelevant and wouldn't change anything. At worst, he gets his issue tracker filled. If it bothers you, then the only thing that you can do is change to Devuan or don't use systemd-networkd/systemd-resolved. Distros are going to continue using systemd irrespective of this nonsense drama.
> It would make sense to me if he just closed the ticket immediately with a link to the previous discussion.
That would have been overwhelmingly preferable to
> Christ, what's next? You accuse us of controlling people's minds with vaccinations we get directly from Bill Gates? And that systemd uses 5G to spread CoV-2?
, yes!
That would have been overwhelmingly preferable to
> Christ, what's next? You accuse us of controlling people's minds with vaccinations we get directly from Bill Gates? And that systemd uses 5G to spread CoV-2?
, yes!
It also shows how many people are coaching from the sidelines so to speak.
Although the decision theoretically affects them, they shouldn't constantly nag the maintainers. (Not respecting their decision is not a sign of great character either.)
Although the decision theoretically affects them, they shouldn't constantly nag the maintainers. (Not respecting their decision is not a sign of great character either.)
Could someone explain why systemd needs DNS/NTP fallbacks to begin with? Why aren’t these both runtime configs?
EDIT: I assumed there were also runtime configs based on the name "fallback."
My question is primarily why you need compiled-in fallbacks, and secondarily why the fallback configs aren't pulled from config files.
EDIT: I assumed there were also runtime configs based on the name "fallback."
My question is primarily why you need compiled-in fallbacks, and secondarily why the fallback configs aren't pulled from config files.
They are runtime configs. The build-time defaults are fallbacks for when no runtime config is set.
https://www.freedesktop.org/software/systemd/man/systemd.net...
https://www.freedesktop.org/software/systemd/man/timesyncd.c...
https://www.freedesktop.org/software/systemd/man/systemd.net...
https://www.freedesktop.org/software/systemd/man/timesyncd.c...
It would better to fail than to use fallbacks that are not desired.
If I want my systems to fail in DNS resolution if the DHCP server doesn't give them a DNS server address (by design), I'm essentially SoL then? My option then is to block outgoing TCP/UDP 53 on my firewall, except from my forwarders. Or maybe I should just suck it up and start building systemd in-house an give it a bogus default, with all the maintenance and overhead that involves?
So, in a few months to a few years, when systemd silently switches to DNS over HTTPS, what then? Maintain a (growing) blacklist of public DoH servers?
I'd much prefer my software to fail (and let me know), rather than assume some default someone, somewhere, somewhen thought a good idea.
So, in a few months to a few years, when systemd silently switches to DNS over HTTPS, what then? Maintain a (growing) blacklist of public DoH servers?
I'd much prefer my software to fail (and let me know), rather than assume some default someone, somewhere, somewhen thought a good idea.
More to the point: does any Linux software at all use a default DNS or NTP server? NSS resolver library doesn't default to using a specific DNS provider, and it's a DNS resolver. NTPd might default to using ntp.org pools, but that might just be my distro's default configs.
To me this is more evidence that Systemd is really just "Poetteringd": whatever he feels like it should have, it has. Really disappointed that distros continue to use this software rather than start a community replacement that addresses its shortcomings.
If I re-did systemd, it would retain the same functionality, but not come enabled by default, and it'd be broken up into independent packages to be installed as needed. It would also use standard interfaces and do away with the binary formats, defer to existing system software rather than default to its own custom versions, de-complicate its awkward filesystem tree and simplify management of service configs, make the command-line interface more sane, and begin integrating more cloud-specific features to replace more complex cloud software (such as for service discovery, cluster management, and HA).
All these fixes would allow the "anti-systemd" crowd (of which I am a card-carrying member) to run a simple init system if they want, or extend it to the full range of systemd functionality. It would remove glaring pain points and user friction, embrace the existing system's default functionality (and backwards compatibility), and extend the software to be more useful in cluster environments. In addition, if this were maintained by the community, all distros could adopt it like they did systemd, and we don't have a half dozen different service systems like before.
Now please somebody reply and tell me why this is a terrible idea...
To me this is more evidence that Systemd is really just "Poetteringd": whatever he feels like it should have, it has. Really disappointed that distros continue to use this software rather than start a community replacement that addresses its shortcomings.
If I re-did systemd, it would retain the same functionality, but not come enabled by default, and it'd be broken up into independent packages to be installed as needed. It would also use standard interfaces and do away with the binary formats, defer to existing system software rather than default to its own custom versions, de-complicate its awkward filesystem tree and simplify management of service configs, make the command-line interface more sane, and begin integrating more cloud-specific features to replace more complex cloud software (such as for service discovery, cluster management, and HA).
All these fixes would allow the "anti-systemd" crowd (of which I am a card-carrying member) to run a simple init system if they want, or extend it to the full range of systemd functionality. It would remove glaring pain points and user friction, embrace the existing system's default functionality (and backwards compatibility), and extend the software to be more useful in cluster environments. In addition, if this were maintained by the community, all distros could adopt it like they did systemd, and we don't have a half dozen different service systems like before.
Now please somebody reply and tell me why this is a terrible idea...
It more-or-less worked that way for decades (and it worked better), so it’s not a terrible idea.
My theory is that the big distros are intentionally destroying forwards and backwards compatibility on the desktop as much as possible.
The more often window managers, desktop software, etc., stop working, the less their own teams have to compete with existing software. Wayland’s X11-as-a-second-class-citizen and gtk’s elimination of API stability are two other good examples of this.
Also, tearing down established standards is a great way to sabotage the various BSD’s out there.
What they don’t get is that sabotaging the rest of the community is undermining their own market share within Linux, even as it shrinks Linux’s market share.
My theory is that the big distros are intentionally destroying forwards and backwards compatibility on the desktop as much as possible.
The more often window managers, desktop software, etc., stop working, the less their own teams have to compete with existing software. Wayland’s X11-as-a-second-class-citizen and gtk’s elimination of API stability are two other good examples of this.
Also, tearing down established standards is a great way to sabotage the various BSD’s out there.
What they don’t get is that sabotaging the rest of the community is undermining their own market share within Linux, even as it shrinks Linux’s market share.
> My theory is that the big distros are intentionally destroying forwards and backwards compatibility on the desktop as much as possible. The more often window managers, desktop software, etc., stop working, the less their own teams have to compete with existing software. Wayland’s X11-as-a-second-class-citizen and gtk’s elimination of API stability are two other good examples of this. Also, tearing down established standards is a great way to sabotage the various BSD’s out there.
I see this sentiment a lot and I don't get it. The developers I've talked to have been doing a lot of work to get XWayland working and to fix all the edge cases. And GTK has been API stable for years, the only thing that really seems to have broken was themes. And actually now GTK3 is feature complete and will not be receiving any more changes except bug fixes.
As far as init systems go, there seems to have never been any real standard and most distros always seem to have done their own thing. It does not seem like anything could be done there especially when a low level piece of software like this needs to use Linux- or BSD-specific APIs. It simply is not possible to have a portable standard there right now.
I have a humble request, please don't continue by promoting these unfounded theories and accusing people of sabotage. I personally would welcome a friendly fork of systemd to make some positive changes but it won't happen if people are doing it out of hostility. Many of the issues in the GP post have been brought up over the years. Upstream and the distros all have a stance on them and there is a reason why things are the way they are. It would be unwise to proceed without having substantial discussions with them to put resources where they are actually needed most. There was already a hostile fork that died because of not paying attention to this.
I see this sentiment a lot and I don't get it. The developers I've talked to have been doing a lot of work to get XWayland working and to fix all the edge cases. And GTK has been API stable for years, the only thing that really seems to have broken was themes. And actually now GTK3 is feature complete and will not be receiving any more changes except bug fixes.
As far as init systems go, there seems to have never been any real standard and most distros always seem to have done their own thing. It does not seem like anything could be done there especially when a low level piece of software like this needs to use Linux- or BSD-specific APIs. It simply is not possible to have a portable standard there right now.
I have a humble request, please don't continue by promoting these unfounded theories and accusing people of sabotage. I personally would welcome a friendly fork of systemd to make some positive changes but it won't happen if people are doing it out of hostility. Many of the issues in the GP post have been brought up over the years. Upstream and the distros all have a stance on them and there is a reason why things are the way they are. It would be unwise to proceed without having substantial discussions with them to put resources where they are actually needed most. There was already a hostile fork that died because of not paying attention to this.
Please start this project. If it used C or Go I could even contribute.
I could imagine if you want to fetch external resources for first boot configuration on embedded or satellite installations. You need DNS for that, and NTP (or hardware time) for https to work. Nowadays even pre-OS processes (UEFI) use internet. For example internet recovery on Mac's.
interesting point, but I'd think DHCP or a baked-in config file in the system image would do the trick no?
it is runtime config. these are defaults in case the distro doesn't change it, or the admin doesn't set it.
They are, these are the defaults for unset.
As Lennart says, asking your distro vendor to set defaults or just doing it on your own system is much better. This issue is just being upset on behalf of the people that don't mind or care and just want working infrastructure.
As Lennart says, asking your distro vendor to set defaults or just doing it on your own system is much better. This issue is just being upset on behalf of the people that don't mind or care and just want working infrastructure.
> Christ, what's next? You accuse us of controlling people's minds with vaccinations we get directly from Bill Gates? And that systemd uses 5G to spread CoV-2?
> I will block discussions here now, since I don't think we need the input from the script kiddie peanut gallery here.
Ohh my what a toxic open source community. I can't imagine working on a software project where the lead dev/maintainer says things like that to people.
Edit: I suppose with all the downvotes apparently lot's of people here think such responses from the leader of a open source project is acceptable behavior.
> I will block discussions here now, since I don't think we need the input from the script kiddie peanut gallery here.
Ohh my what a toxic open source community. I can't imagine working on a software project where the lead dev/maintainer says things like that to people.
Edit: I suppose with all the downvotes apparently lot's of people here think such responses from the leader of a open source project is acceptable behavior.
More like - that community leader takes an unbelievable amount of flack and is still generately polite and helpful in most of his interactions.
How about we cut them a little slack for occassionally being human?
How about we cut them a little slack for occassionally being human?
I'll admit that I don't actively seek out Poettering's online postings, so I pretty much only see his behavior when it's bad enough to make the news. But isn't it a little silly to say he's generally polite and helpful in most of his interactions? What really matters is whether he's capable of being polite and helpful when there's a real disagreement, and especially when he's wrong. His reputation indicates he tends to have a distinctly impolite "my way or the highway" attitude in those circumstances, and examples of it are plentiful. Are there counterexamples where he humbly admits being wrong, or at least acknowledges the validity of criticism when affirming his stance?
Even before systemd, Poettering was one of the more uncaring, abrasive project maintainers, e.g. in pulseaudio. If there is no slack for Torvalds, there shouldn't be for Poettering.
I don’t care if Poettering's an a—hole or not. I enjoy reading Torvald’s rants, in fact. They’re usually informative.
I’m upset that he has done more than any other developer to break my machines, and he keeps getting more authority so screw things up.
PulseAudio was bad enough, but at least it only broke one subsystem. SystemD has unapologetically broken: background process management, time keeping, network resolution, pam authentication, screen saver session management, x11 startup, logging, and probably more.
I’m upset that he has done more than any other developer to break my machines, and he keeps getting more authority so screw things up.
PulseAudio was bad enough, but at least it only broke one subsystem. SystemD has unapologetically broken: background process management, time keeping, network resolution, pam authentication, screen saver session management, x11 startup, logging, and probably more.
> I’m upset that he has done more than any other developer to break my machines, and he keeps getting more authority so screw things up.
I may be wrong, but you should be blaming the ones who made the _actual_ decision of replacing whichever init system, with systemd.
systemd was developed under Red Hat's umbrella. Nowadays, the vast majority of mainstream Linux distributions use it, and I doubt it was because Red Hat/Poettering pressure them to do so.
I may be wrong, but you should be blaming the ones who made the _actual_ decision of replacing whichever init system, with systemd.
systemd was developed under Red Hat's umbrella. Nowadays, the vast majority of mainstream Linux distributions use it, and I doubt it was because Red Hat/Poettering pressure them to do so.
I would expect that an experienced leader would have learned the lesson that the satisfaction of writing a nasty comment is short but the consequences are much longer, not sure if he just can't control himself or maybe he enjoys the spectacle and making himself a "victim".
The guy is paid for his work so I would have expect he would act more professional, the excuse that he works for free in his spare time does not apply.
The guy is paid for his work so I would have expect he would act more professional, the excuse that he works for free in his spare time does not apply.
I wouldn't consider any of those responses as being "generally polite", He could have just said we already discussed this, linked to the old discussion and thanked the people for their concern and closed the issue, no need for him to respond with nasty language.
I don't like it either, but Lennart Poettering already has a reputation for this. If you've spent time listening to criticism of systemd and some of his other projects, this is not news.
I think it may be a mistake to extrapolate his attitude to the scale of "open source community", even though it is also fair to say he is not the only one with this problem either.
Edit:
> Christ, what's next? You accuse us of controlling people's minds with vaccinations we get directly from Bill Gates? And that systemd uses 5G to spread CoV-2?
A joke occurrs to me. Systemd already does so much. It wouldn't surprise me if that were in there too!
I think it may be a mistake to extrapolate his attitude to the scale of "open source community", even though it is also fair to say he is not the only one with this problem either.
Edit:
> Christ, what's next? You accuse us of controlling people's minds with vaccinations we get directly from Bill Gates? And that systemd uses 5G to spread CoV-2?
A joke occurrs to me. Systemd already does so much. It wouldn't surprise me if that were in there too!
I didn't mean the entire open source community, just the Systemd open source community, sorry for the confusion.
>I can't imagine working on a software project where the lead dev/maintainer says things like that to people.
But have you ever written a unit file? So much better than writing an init shell script. That apparently excuses any other issue with systemd for a lot of people.
But have you ever written a unit file? So much better than writing an init shell script. That apparently excuses any other issue with systemd for a lot of people.
Shell really isn’t that hard to learn, and it’s a skill that transfers to many other problems.
I’ve looked at Unit files in a futile attempt to debug a startup failure. They seem worse (much less debuggable or transparent) than the old init system Linux had in the 90’s and worlds away from modern implementations, like OpenBSD’s.
I’ve looked at Unit files in a futile attempt to debug a startup failure. They seem worse (much less debuggable or transparent) than the old init system Linux had in the 90’s and worlds away from modern implementations, like OpenBSD’s.
In case it wasn't obvious, I was mocking the excuses I see thrown around for systemd eleswhere.
> But have you ever written a unit file? So much better than writing an init shell script.
Have you ever added a daemon to OpenBSD? There are better options.
Have you ever added a daemon to OpenBSD? There are better options.
I don't use Linux and have no any opinion on systemd either way, but based on what I saw on Slashdot about it some years back, there are a significant number people out there who acted as if systemd and Lennart Poettering (one of its creators) were one of the worst things to happen since Hitler.
I'm largely ambivalent as to whether or not his behaviour here was acceptable, but I am pretty sure he has received death threats and other types of abuse from systemd haters in the past, so his complete lack of patience at baseless accusations does not surprise me at all.
On a related note, while I still skim Slashdot's front page daily, I just can't stand to look at the comments anymore. I think the trolls, "bitter sysadmins" and bigots have largely frightened away everyone else. For example, if you just mention you're actually alright with Microsoft Windows, then you're accused of being a shill who's life goal is to make everyone else's life miserable.
I'm largely ambivalent as to whether or not his behaviour here was acceptable, but I am pretty sure he has received death threats and other types of abuse from systemd haters in the past, so his complete lack of patience at baseless accusations does not surprise me at all.
On a related note, while I still skim Slashdot's front page daily, I just can't stand to look at the comments anymore. I think the trolls, "bitter sysadmins" and bigots have largely frightened away everyone else. For example, if you just mention you're actually alright with Microsoft Windows, then you're accused of being a shill who's life goal is to make everyone else's life miserable.
The original title was much more explicit: "Systemd Fallbacks to Google NTP and DNS".
I guess @dang changed it with good intentions, but he accidentally destroyed the meaning. "We wanted the best, you know the rest."
I guess @dang changed it with good intentions, but he accidentally destroyed the meaning. "We wanted the best, you know the rest."
> Don't fallback to Google NTP and DNS. #12499
[deleted]
What are the 'obvious privacy reasons' to not use google DNS/NTP?
I am being 100% serious when I ask: What bad does someone expect to happen as a result of this.
I am being 100% serious when I ask: What bad does someone expect to happen as a result of this.
This is a breakdown of some issues many people have with Google's Privacy Policy for their DNS.
Temporarily Logs (2 days):
- Google logs the IP address of every device sending a DNS query.
- For DNS-over-HTTPS, logs Content-Type & Accept HTTP headers
Permanently Logs:
- Client's autonomous system number
- User's geolocation within 1 km^2 and 1000 people.
- Timestamp
- Requested Domain Name
- Request Domain type
- Transport Protocol
- EDNS version, option
- and a few more, essentially everything but your IP address.
This is enough permanent information to successfully identify the vast majority of people even if they never permanently log your IP - and that's just by itself, not including if you use other google services. Other services such as Cloudflare DNS or OpenDNS provide a higher degree of privacy and can even be faster than Google's DNS.
Google's DNS policy: https://developers.google.com/speed/public-dns/privacy
Cloudflare's DNS policy: https://developers.cloudflare.com/1.1.1.1/privacy/public-dns...
OpenDNS's policy: https://umbrella.cisco.com/blog/privacy-policy-update
Temporarily Logs (2 days):
- Google logs the IP address of every device sending a DNS query.
- For DNS-over-HTTPS, logs Content-Type & Accept HTTP headers
Permanently Logs:
- Client's autonomous system number
- User's geolocation within 1 km^2 and 1000 people.
- Timestamp
- Requested Domain Name
- Request Domain type
- Transport Protocol
- EDNS version, option
- and a few more, essentially everything but your IP address.
This is enough permanent information to successfully identify the vast majority of people even if they never permanently log your IP - and that's just by itself, not including if you use other google services. Other services such as Cloudflare DNS or OpenDNS provide a higher degree of privacy and can even be faster than Google's DNS.
Google's DNS policy: https://developers.google.com/speed/public-dns/privacy
Cloudflare's DNS policy: https://developers.cloudflare.com/1.1.1.1/privacy/public-dns...
OpenDNS's policy: https://umbrella.cisco.com/blog/privacy-policy-update
"This is enough permanent information to successfully identify the vast majority of people even if they never permanently log your IP"
How? I don't think this is true. You also reworded and omitted stuff from the disclaimer.
How? I don't think this is true. You also reworded and omitted stuff from the disclaimer.
Could you please point to what I've reworded that you believe is misleading or misconstrued, I will happily edit my comment and fix it - I have more or less directly quoted within context. I have omitted stuff because I didn't feel the need to include the whole privacy policy in a comment (which is why I linked it) but nothing I felt was misleading. If there is a critical point you feel I should include, let me know and I will add it.
As for this not being enough information to identify someone, it really is. Lets assume you use Google's DNS and no google tools, block all trackers, etc. (which the vast majority of people do not do). Lets say the authorities grab your computer, and somehow have access to Google DNS data (CLOUD Act) and want to see what you did online. They can already filter down DNS queries to 1000 people (and thats assuming all 1000 people use google dns, which again they do not). They can figure out what software performed queries based on EDNS data. Timestamps further filter down the dataset if you have a general idea of a person's schedule. With ECS they can further narrow down by service provider. All of sudden those 1000 autonomous ids have been significantly narrowed down using just general techniques, if you're targeting a person you will almost certainly be able to use the rest of the data to tie an ID to machine. If you use other google services or even just visit sites with google analytics that ID is even easier to compromise. Every piece of data collected is a piece of data that can be used to identify you, that's the price of convenience.
EDIT: Would like to mention even the act of an machine going offline, which will occur if an authority confiscates your machine will narrow down IDs as now you only have to look for IDs that stopped communicating with Google's DNS at time of confiscation.
As for this not being enough information to identify someone, it really is. Lets assume you use Google's DNS and no google tools, block all trackers, etc. (which the vast majority of people do not do). Lets say the authorities grab your computer, and somehow have access to Google DNS data (CLOUD Act) and want to see what you did online. They can already filter down DNS queries to 1000 people (and thats assuming all 1000 people use google dns, which again they do not). They can figure out what software performed queries based on EDNS data. Timestamps further filter down the dataset if you have a general idea of a person's schedule. With ECS they can further narrow down by service provider. All of sudden those 1000 autonomous ids have been significantly narrowed down using just general techniques, if you're targeting a person you will almost certainly be able to use the rest of the data to tie an ID to machine. If you use other google services or even just visit sites with google analytics that ID is even easier to compromise. Every piece of data collected is a piece of data that can be used to identify you, that's the price of convenience.
EDIT: Would like to mention even the act of an machine going offline, which will occur if an authority confiscates your machine will narrow down IDs as now you only have to look for IDs that stopped communicating with Google's DNS at time of confiscation.
Google logs and stores forever every DNS request (and other info related to it like approximate geolocation), they also temporary store even more information that can identify you (like your IP address).
https://developers.google.com/speed/public-dns/privacy
Edit: let's suppose for a moment that Google is not evil, does not cooperate with the NSA and doesn't make bad use of that information. It's still a liability and any data leak will be a problem for anyone using Google's DNS. Some things are better not being logged at all or at least not permanently.
https://developers.google.com/speed/public-dns/privacy
Edit: let's suppose for a moment that Google is not evil, does not cooperate with the NSA and doesn't make bad use of that information. It's still a liability and any data leak will be a problem for anyone using Google's DNS. Some things are better not being logged at all or at least not permanently.
There’s also the CLOUD Act, which compels them to share the information with law enforcement in the US and abroad. (The latter don’t have to have any due process around the data requests they issue, unless they have other laws requiring it.)
stores forever every DNS request
That’s not what your link says.
The permanent logs are a sampling of the temporary logs
That’s not what your link says.
The permanent logs are a sampling of the temporary logs
I may have misinterpreted this part:
> The permanent logs are a sampling of the temporary logs where your IP address is removed and replaced by a city or region-level location.
What I understood from it is that they replace your IP address with an approximate location but keep the rest of the data. Can you explain me how you interpreted it?
> The permanent logs are a sampling of the temporary logs where your IP address is removed and replaced by a city or region-level location.
What I understood from it is that they replace your IP address with an approximate location but keep the rest of the data. Can you explain me how you interpreted it?
Wouldn't storing 98% of requests still be "a sampling"?
> What bad does someone expect to happen as a result of this.
Google is enriched when it can associate consumer IPs with DNS queries. Collecting that sort of information and compiling it into a advertising profile is part of Google's business. Giving state actors a view of that information part of Google's history.
Some people are just philosophically opposed to Google's information gathering mission. From such people's perspective, anything that directly helps Google learn something (or even make a little money) is bad.
Google is enriched when it can associate consumer IPs with DNS queries. Collecting that sort of information and compiling it into a advertising profile is part of Google's business. Giving state actors a view of that information part of Google's history.
Some people are just philosophically opposed to Google's information gathering mission. From such people's perspective, anything that directly helps Google learn something (or even make a little money) is bad.
I mean, could? Sure. They specifically claim not to though: https://developers.google.com/speed/public-dns/privacy
The question was posed, "What bad does someone expect to happen as a result of this[?]". So I'm putting on my least-charitable-to-Google hat. I'm not trying to make the most accurate predictions.
> They specifically claim not to though
That additional vector for monetization still exists. I stand by the statement that the ability to make those ad-relevant associations enriches Google. They are not necessarily monetizing that part of their empire right now, but they've pivoted other products in the past from "we're just trying to improve the Internet for it's own sake" to "we use this for advertising".
Privacy policies change all the time, often with little warning. There'll be a post here on HN if it happens and a bunch more techie folks will switch their DNS to 1.1.1.1 or something, but lots of people will just stick with 8.8.8.8, many of them unknowingly. Perhaps unknowingly because the Google address has become so common that FOSS projects are using it as a default.
> They specifically claim not to though
That additional vector for monetization still exists. I stand by the statement that the ability to make those ad-relevant associations enriches Google. They are not necessarily monetizing that part of their empire right now, but they've pivoted other products in the past from "we're just trying to improve the Internet for it's own sake" to "we use this for advertising".
Privacy policies change all the time, often with little warning. There'll be a post here on HN if it happens and a bunch more techie folks will switch their DNS to 1.1.1.1 or something, but lots of people will just stick with 8.8.8.8, many of them unknowingly. Perhaps unknowingly because the Google address has become so common that FOSS projects are using it as a default.
Yeah, but I got this uneasy feeling about relying too much on google services. Their policy can change in the future, and when it do change, we will scramble trying migrate to something else, only to find that the competitions in the space has been killed. Think about Reader, when they shut it down, there were no good alternatives for users to migrate to. Also google maps api, when they suddenly jack up the price and there were nothing the users could migrate to.
Google can tie the DNS requests you make to your IP address and then tie that to you Google accounts. Google now knows every website you go to and can either monetize the data or sell access to it. It also knows your name.
For fun uses of this data, I recently talked to a company that ties medical conditions derived from your browsing behavior to your online profile and then provides a platform for insurances companies to target you based on it.
For fun uses of this data, I recently talked to a company that ties medical conditions derived from your browsing behavior to your online profile and then provides a platform for insurances companies to target you based on it.
I just looked through Google DNS’s privacy policy and what you claim seems incompatible with their claims: https://developers.google.com/speed/public-dns/privacy
Do you have any concrete evidence of what you claim?
Do you have any concrete evidence of what you claim?
That assumes you trust Google and many people don't. The fines companies face for violations are peanuts and there may be real incentives internally to using this data. "Accidents" happen after all in complex data systems and they're already allowed to mix the data for "security and abuse". On that note, as I read it, closing all your Google accounts as a result of suspected abuse due to DNS data would be fine under the policy.
First is whether you can trust it, second yes, their privacy states that they don't log IP, and frankly with dynamic IP it isn't really that much valuable anyway. The other information together can tie that to you as a person. Combined with other information that you are disclosing when using their services (since their policy changed many years ago, to allow sharing data between their services) they know exactly who you are and what you're doing on the net.
I really don't understand why those DNS services are so popular. All you need is list of 13 root DNS servers[1] (you only need one, but 13 for resiliency) and a recursive resolver and you can run your own caching server.
[1] https://www.iana.org/domains/root/servers
I really don't understand why those DNS services are so popular. All you need is list of 13 root DNS servers[1] (you only need one, but 13 for resiliency) and a recursive resolver and you can run your own caching server.
[1] https://www.iana.org/domains/root/servers
What is your legal recourse if Google changes their privacy policy?
After the PRISM revelations this argument became very weak.
From Google’s DNS privacy page:
> We do not correlate or associate personal information in Google Public DNS logs with your information from use of any other Google service except for addressing security and abuse.
https://developers.google.com/speed/public-dns/privacy
> We do not correlate or associate personal information in Google Public DNS logs with your information from use of any other Google service except for addressing security and abuse.
https://developers.google.com/speed/public-dns/privacy
DNS queries aren’t considered personal information in the US. They’re considered metadata. So, they can correlate the queries according to this wording.
Also, the wording implies they can aggregate data, then use it for other purposes (like spying on competitive web sites, etc.)
Finally, it implies they are retained, which means law enforcement has access to the logs (in many cases, without a subpoena).
Also, the wording implies they can aggregate data, then use it for other purposes (like spying on competitive web sites, etc.)
Finally, it implies they are retained, which means law enforcement has access to the logs (in many cases, without a subpoena).
The assumption is that Google will do what it always does, and use your request stream to spy on you.
> I believe Google's DNS service is used for monitoring DNS traffic from IPs. This is then most likely used for personalisation, which aids Google's mission to take freedom and privacy away from nontechnical and technical users.
Not questioning if Google does it or not but I was made to believe that IP is not really useful for ads targeting because it just doesn't work great with multiples users behind a single IP. Now with CGNAT on both type of networks (fixed and mobile), using IP for targeting does not seem pertinent to me.
Not questioning if Google does it or not but I was made to believe that IP is not really useful for ads targeting because it just doesn't work great with multiples users behind a single IP. Now with CGNAT on both type of networks (fixed and mobile), using IP for targeting does not seem pertinent to me.
Timestamps are usually enough to infer end users, even on much larger data sets. (Researchers used the Twitter firehose to deanonymize a large dataset a few years ago).
>Christ, what's next? You accuse us of controlling people's minds with vaccinations we get directly from Bill Gates? And that systemd uses 5G to spread CoV-2?
That seems a very aggressive response to a perfectly valid question in modern times. Google pays Mozilla tens of millions to be their default search provider. Companies use money to influence things to their benefit all the time.
edit: Another example was all the extensions that Kite bought out and had their service offering added to (which sent all your code back to Kite servers).
That seems a very aggressive response to a perfectly valid question in modern times. Google pays Mozilla tens of millions to be their default search provider. Companies use money to influence things to their benefit all the time.
edit: Another example was all the extensions that Kite bought out and had their service offering added to (which sent all your code back to Kite servers).
Asking someone if they are a shill is never "a perfectly valid question".
> Asking someone if they are a shill is never "a perfectly valid question".
It was more of a question whether there is a conflict of interest; "shill" is a more loaded term than what was used. And the answer was actually a qualified yes, so there was at least a sliver of validity to the question.
It was more of a question whether there is a conflict of interest; "shill" is a more loaded term than what was used. And the answer was actually a qualified yes, so there was at least a sliver of validity to the question.
I think it is a valid question when the defaults are google and there is a reasonable suggestion to not use google as the defaults in lieu of community or open-source options. When that question isn't answered (evaded) it's perfectly reasonable ask why.
And responding like that is never a valid answer.
So what colour should we paint the bikeshed?
Fair response IMO, this is the type of issue that can attract a lot of noisy opinions so very reasonable to lock comments to contributors.
Fair response IMO, this is the type of issue that can attract a lot of noisy opinions so very reasonable to lock comments to contributors.
> I believe Google's DNS service is used for monitoring DNS traffic from IPs. This is then most likely used for personalisation, which aids Google's mission to take freedom and privacy away from nontechnical and technical users.
The Privacy Policy for Google's public DNS service explicitly says that they don't do that. If you really think Google is doing it then you should take it up with the FTC who would really enjoy making an example out of Google.
The Privacy Policy for Google's public DNS service explicitly says that they don't do that. If you really think Google is doing it then you should take it up with the FTC who would really enjoy making an example out of Google.
> you should take it up with the FTC who would really enjoy making an example out of Google.
How do you prove it though? Google will not just give you the source code of their DNS infrastructure and even if they did there is no way to prove that it's indeed that code that is running and not a modified version that does collect data?
How do you prove it though? Google will not just give you the source code of their DNS infrastructure and even if they did there is no way to prove that it's indeed that code that is running and not a modified version that does collect data?
Actually google is one of the few organizations out there with real reproducible builds. If they gave you the sources and the program image, you could prove the latter was derived from the former.
This has nothing to do with what software they're running internally though, and again as I said even if you can audit and build your own version of the Google DNS infrastructure there's nothing guaranteeing that it's exactly what's running internally.
The problem is that ultimately there is a conflict of interest - Google is an advertising company that benefits from knowing as much as possible about people for ad targeting purposes, and as such some people (like me) might not be willing to trust them.
The problem is that ultimately there is a conflict of interest - Google is an advertising company that benefits from knowing as much as possible about people for ad targeting purposes, and as such some people (like me) might not be willing to trust them.
My personal bias is that I've worked at Google and I've worked elsewhere and I know that Google's control over what code runs in prod is years ahead of the other places I've worked. They have strong controls that audit that binaries running as sensitive roles (roles with access to real user data and logs) were produced from reviewed and submitted code and built in the official hermetic build farm. For very sensitive roles (gmail etc) they audit the command line and everything. The controls everywhere else I've worked are a complete joke by comparison.
This quote is from Google's security infrastructure whitepaper:
"""Google’s source code is stored in a central repository where both current and past versions of the service are auditable. The infrastructure can additionally be configured to require that a service’s binaries be built from specific reviewed, checked in, and tested source code. Such code reviews require inspection and approval from at least one engineer other than the author, and the system enforces that code modifications to any system must be approved by the owners of that system. These requirements limit the ability of an insider or adversary to make malicious modifications to source code and also provide a forensic trail from a service back to its source. """
I don't think the conflict you mention exists. Google benefits when people use the open web. They run DNS because DNS is critical to web user experience and ISP DNS is garbage. Also, by the way, ISP DNS privacy story is a complete disaster.
This quote is from Google's security infrastructure whitepaper:
"""Google’s source code is stored in a central repository where both current and past versions of the service are auditable. The infrastructure can additionally be configured to require that a service’s binaries be built from specific reviewed, checked in, and tested source code. Such code reviews require inspection and approval from at least one engineer other than the author, and the system enforces that code modifications to any system must be approved by the owners of that system. These requirements limit the ability of an insider or adversary to make malicious modifications to source code and also provide a forensic trail from a service back to its source. """
I don't think the conflict you mention exists. Google benefits when people use the open web. They run DNS because DNS is critical to web user experience and ISP DNS is garbage. Also, by the way, ISP DNS privacy story is a complete disaster.
I am not talking about malicious code contrary to Google's intention being ran on their infrastructure. I am talking about code that Google wants to run. Code that harvests DNS queries for ad targeting might be within Google's objectives and wouldn't be considered as malicious, but it would be malicious when looking at it from the user's point of view.
You're saying that Google has a plan to intentionally subvert their published privacy policy, and act which if discovered would end the company's existence, and that some engineer on the project wrote and another reviewed this change, that none of the dozens of privacy zealots in their internal privacy org[1] have managed to notice, and that the people who operate 8.8.8.8, some of whom are just as privacy-deranged as anyone you've ever met, and who collectively own a disturbing number of fedoras, kilts, and unicycles, who are the biggest nerds you've ever seen, happily run this service 24x7 without blowing the whistle?
Seems unlikely.
1: https://gizmodo.com/meet-the-woman-who-leads-nightwatch-goog...
Seems unlikely.
1: https://gizmodo.com/meet-the-woman-who-leads-nightwatch-goog...
Facebook has been caught doing that where phone numbers for 2FA purposes that were promised not to be used for ad targeting started being used for exactly that purpose. Facebook is of comparable size and operates within the same regulatory environment as Google, so if they can do it and get away with it there's no reason to believe it would be different for Google.
That’s basically ridiculous. Facebook is a corrupt organization. It was established to sexually harass young women. It was irredeemable from the beginning.
[deleted]
> Actually google is one of the few organizations out there
Where are you gathering that knowledge from? Can you cite a source please.
Where are you gathering that knowledge from? Can you cite a source please.
Somehow this is funny.
> The Privacy Policy for Google's public DNS service explicitly says that they don't do that. If you really think Google is doing it then you should take it up with the FTC who would really enjoy making an example out of Google.
Stop pretending like there's no regulatory capture going on. Otherwise we would already have antitrust cases going on with many of those big corporations.
Stop pretending like there's no regulatory capture going on. Otherwise we would already have antitrust cases going on with many of those big corporations.
FYSA: you can override Potterings delights in /etc/systemd/resolved.conf.d/fallback_dns.conf by specifying an empty string for the fallbacks.
How to delete the fallback Google DNS and setup Cloudflare for example:
/etc/systemd/resolved.conf.d/fallback_dns.conf
/etc/systemd/timesyncd.conf
/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
/etc/systemd/timesyncd.conf
[Time]
FallbackNTP=time.cloudflare.comHow do you completely disable the fallback, though?
From a technical standpoint, there seems to be absolutely no reason to put cruft like this in systemd. If the network isn't configured (or configured correctly), there's no point in making sure DNS "always works". It has more potential to leak information at the wrong moment than to fix anything the user/administrator did wrong.
Seriously, what the hell? This is one of the most blatant instances of lazy crosscutting leakage, but the general trend is why I've moved net horizon isolation more towards full vms rather than relying on local firewall rules.
Probably the best way to get this "fixed" is to propose that resolved fall back to being a full recursive resolver. Poettering won't be able to resist adding more scope.
Probably the best way to get this "fixed" is to propose that resolved fall back to being a full recursive resolver. Poettering won't be able to resist adding more scope.
This is probably part of networkd, which is a different daemon in charge of managing the network
Or is it systemd-resolvd? Who can tell these days?
if it is systemd-resolvd, then privacy oriented solution would be to not use google, cloudflare or even the non profits. It would be to just have list of 13 DNS root servers and do recursive name resolutions (i.e. what caching resolvers were meant to do).
But the absolute correct behavior would be a hard failure, because if you have IP properly assigned and routing setup but no DNS, then you either purposefully set it up that way and don't want DNS to work, or you have misconfigured network setup which you should be aware about it, without having to troubleshoot why some machines don't have working Internet while others seem perfectly fine.
But the absolute correct behavior would be a hard failure, because if you have IP properly assigned and routing setup but no DNS, then you either purposefully set it up that way and don't want DNS to work, or you have misconfigured network setup which you should be aware about it, without having to troubleshoot why some machines don't have working Internet while others seem perfectly fine.
It's a quick and dirty sane default used for development.
I'm kind of behind on systemd, can someone explain why it has DNS and NTP at all? Shouldn't it just use whatever the rest of the computer uses?
Systemd is kind of like the Borg. It slowly assimilates daemons until it eventually replaces all system level functionality. Its next target is home directories[1], then who knows what else.
[1] https://systemd.io/HOME_DIRECTORY/
[1] https://systemd.io/HOME_DIRECTORY/
You're confusing systemd (the replacement for init) with systemd (the replacement for init, dns, syslog, login/getty, grub, your home directory, etc).
Both are called systemd but one is actually only a single module of the other.
Both are called systemd but one is actually only a single module of the other.
[deleted]
the more i grow up the more i emphatize with Poettering.
So to summarize:
When discussing privacy and Google a common refrain is "just don't use Google products then". But Google's DNS is used as the default for a key system daemon in the majority of Linux systems?
I'm going to file this under "voting with your wallet is bullshit".
I also hope that the systemd team is watching the Google DNS ToS like a hawk because: "We may modify the Terms or any portion to, for example, reflect changes to the law or changes to our APIs. You should look at the Terms regularly."
When discussing privacy and Google a common refrain is "just don't use Google products then". But Google's DNS is used as the default for a key system daemon in the majority of Linux systems?
I'm going to file this under "voting with your wallet is bullshit".
I also hope that the systemd team is watching the Google DNS ToS like a hawk because: "We may modify the Terms or any portion to, for example, reflect changes to the law or changes to our APIs. You should look at the Terms regularly."
The singular party who is entitled to complain about this default configuration is Google.
At flare-up #237 you'd think one would have figured out a professional way to handle questions like this.
Buried in the pointless flamewar is the maintainer's own reply which is the way forward:
> Anyway, if there's a well respected network of community DNS servers that can roughly match Cloudflare/Google we can add, sure.
That is the correct and initial response the maintainer should have given. It puts the onus on OP to show how their preferred DNS stacks up against Cloudfare/Google.
Instead, the maintainer plays dumb wrt the importance of defaults, essentially guaranteeing that OP will escalate the rhetoric. Worse, the maintainer responds in kind.
If the maintainer had gone the correct (and easy!) route, we'd all benefited by having learned how this non-profit DNS stacks up against the others from a technical standpoint. (How does it, anyway?)
And to cover my bases-- when spam gets through to the inbox, no serious person asks, "Why doesn't anyone ever talk about the spammer's responsibility to prevent spam? What about the spammer?" Similar logic applies for why I'm talking about maintainer and not OP.
Buried in the pointless flamewar is the maintainer's own reply which is the way forward:
> Anyway, if there's a well respected network of community DNS servers that can roughly match Cloudflare/Google we can add, sure.
That is the correct and initial response the maintainer should have given. It puts the onus on OP to show how their preferred DNS stacks up against Cloudfare/Google.
Instead, the maintainer plays dumb wrt the importance of defaults, essentially guaranteeing that OP will escalate the rhetoric. Worse, the maintainer responds in kind.
If the maintainer had gone the correct (and easy!) route, we'd all benefited by having learned how this non-profit DNS stacks up against the others from a technical standpoint. (How does it, anyway?)
And to cover my bases-- when spam gets through to the inbox, no serious person asks, "Why doesn't anyone ever talk about the spammer's responsibility to prevent spam? What about the spammer?" Similar logic applies for why I'm talking about maintainer and not OP.
Buried? As the 6th post in an 8-post thread? And I don't see any flaming at all. Your comment here is far more aggressive than any in the Github issue.
It's after another maintainer post, and then the post begins by ... weird name calling about the funding question (which, albeit maybe a bit excessive, I'd still consider valid to ask.)
I think "buried" is an OK description of that.
I think "buried" is an OK description of that.
[deleted]
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.