Hacker News new | past | comments | ask | show | jobs | submit login

The more systemd grows, the less I trust it. This particular change to quietly fallback to what may be user-hostile servers and bypass my network controls is particularly concerning.

There are a lot of good reasons to not want a system to fallback to Google/Cloudflare. For one, I simply don't want it not obeying my own dns server in the middle.




Maybe you misunderstood the article? These default fallback servers have been in systemd-resolved for ages (at least since I started using it 3-4 years ago). This article is about a change made by Fedora recently that disabled them.

Additionally, resolved isn't "not obeying" your DNS - this is the fallback that is only used if DHCP doesn't provide a server and the user doesn't configure one. DHCP and user configuration always take precedence.


It does seem like an odd choice of behavior. Does Windows or MacOS do anything like this?


No Windows doesn't have any fallback DNS servers configured. It will use the ones provided by DHCP or the ones you configure manually.

I don't know about the newest version of macOS but iOS and the versions of macOS I used didn't have any fallback DNS servers.

I wouldn't want a feature like that enabled by default. It can be useful if I have the option to configure it but enabled by default populated with DNS servers chosen by whoever submitted the pull request? No thanks.


My Windows 10, fresh install, did not.


No, windows has no such "user friendly" features...irony off. The fun thing even those amateurish windows users know how to configure the dns server if they use a static ip.

But maybe Linux users are not so technology affine...second irony off.


But that looks like the general direction:

"One could even go further: the privacy level using those public DNS servers might actually be higher than using the DHCP-provided ones in many cases"

(I'm a massive systemd fan, but ignoring DHCP provided DNS servers is IMHO a bold move)


That is a particularly out of context and uncharitable take on that sentence. I have seen no announcements or discussion about systemd-resolved moving into ignoring DHCP, that is simply a comment from one of the maintainers expressing their opinion about the privacy argument. Other quotes from that same post that make his stance on when to use the fallback pretty clear:

> We use the fallback only as ultimate fallback, when the other option is to not work at all.

> we only did that in case no better DNS configuration was available, i.e. as last resort, one step before giving up entirely


It doesn't account for networks which simply lack DNS (not every network peers with the public Internet).


Well in that case, this logic still works. An application that does a DNS lookup on such a network will receive an error whatever logic you use.


That is the exact opposite of what this change did. It REMOVED the option to quietly fall back to servers that might compromise your privacy.


It's not an option, those servers are hardcoded.

edit: my bad, the default servers are hardcoded, but you can also provide your own fallback servers. Not sure if that removes the defaults entirely though. If anything, Linux distros should decide what the defaults are, not systemd.


iirc, providing fallback servers in the config, even an empty set, disables the built in ones. The hardcoded ones are essentially just the "default value" if not changed in the config file.


Yeah, you're right.

Overall I think this is a positive change and it's what every distro should do. If a distro wants to define default fallback servers then it should just be in the default /etc/systemd/resolved.conf, not hardcorded into the binary.


> the Fedora project changed its default configuration for that service to *eliminate* fallback DNS servers


I have/had phenomenal problems avoiding DNS leakage with openvpn on my ubuntu installation. Spent a day or two, trying fix after fix from many sources, the best solution was ripping out the POS that is systemd-resolved and throwing in dnsmasq.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: