Fedora 33 Planning To Enable Systemd-Resolved By Default

[spstarr]

I am assuming this will break my own private DNS server and my own domain... so have to disable this in kickstart for good. I do not want a caching nameserver when I run my own DNS.

[CommunityMember]

I can't be bothered to look it up

So it has been resolve(d).

[CommunityMember]

It's pretty nice to have a resolver that supports DNS over TLS natively available.

*This* proposal will not enable DoH / DoT by default (but maybe in F34?), but individuals can choose to do so. One of the challenges with DoH / DoT are the various strong differences in opinions in exactly when one should try to use it, and exactly which server you should try to use, so what defaults should be chosen? And that does not even include the various fall back scenarios and all those various hotspot logins that use DNS intercept in order to let you use that "free" WiFi (remember the past where there were signs saying "connect to http://192.0.2.1 to login"? We could have to go back to those).

Can you share the RHBZ# on the bug you opened on the issue?

I can't be bothered to look it up, but there's definitely an issue ticket either on systemd's Git or Ubuntu that specifically mentions this problem. I ran into this on Ubuntu months ago.

[CommunityMember]

i had to disable Systemd-Resolved years ago because it was leaking dns in case of a vpn connection

Can you share the RHBZ# on the bug you opened on the issue?

[bug77]

It also doesn't work with local network searches:
e.g.:
1. I have some DNS servers set up using dnsmasq on my home network.
2. My router uses those DNS servers for all static DHCP-based clients.
3. The machines on my network are configured with 'search mydomain.net' in /etc/resolv.conf so that I can easily resolve any hostname on the network without typing in a fully-qualified DNS name (I was sick of keeping /etc/hosts files synchronized between all of my machines).
4. systemd-resolved refuses to resolve any local names by appending the search suffix and querying my DNS servers. I've had to disable an otherwise workable DNS resolver because they refuse to fix this issue. https://github.com/systemd/systemd/issues/2514

Apparently that is the right thing to do.

[Veerappan]

It also doesn't work with local network searches:
e.g.:
1. I have some DNS servers set up using dnsmasq on my home network.
2. My router uses those DNS servers for all static DHCP-based clients.
3. The machines on my network are configured with 'search mydomain.net' in /etc/resolv.conf so that I can easily resolve any hostname on the network without typing in a fully-qualified DNS name (I was sick of keeping /etc/hosts files synchronized between all of my machines).
4. systemd-resolved refuses to resolve any local names by appending the search suffix and querying my DNS servers. I've had to disable an otherwise workable DNS resolver because they refuse to fix this issue. https://github.com/systemd/systemd/issues/2514

[mhartzel]

SystemD is a secret project born in the secret chambers of NSA. Mark my words

[discordian]

What problem is resolvd fixing?

You will have systemdwide cached queries by default,
you dont have a tool modifying stuff in the admin directory (discovered DNS servers/domain),
settings can be provided by the network link configuration.

Many more I guess.

[usta]

From proposal :
When systemd-resolved is enabled, users who use multiple VPNs at the same time will notice that DNS requests are now sent to the correct DNS server by default. Previously, this scenario would result in embarrassing "DNS leaks" and, depending on the order that the VPN connections were established, possible failure to resolve private resources. These scenarios will now work properly. For example, consider the scenario of Distrustful Denise, who (quite reasonably) does not trust her ISP. Denise uses a public VPN service, public-vpn.example.com, to hide her internet activity from her ISP, but she also needs to use her employer's corporate VPN, corporation.example.com, in order to access internal company resources while working from home. Using the Network panel in System Settings, Denise has configured her employer's VPN to "use this connection only for resources on its network." Distrustful Denise expects that her employer's VPN will receive all traffic for corporation.example.com, and no other traffic. And while this mostly works in Fedora 32, she discovers that it does not work properly for DNS:

• If Denise connects to public-vpn.example.com first and corporation.example.com second, she is unable to access internal company resources. All DNS requests are sent to public-vpn.example.com's DNS server, so she is unable to resolve names for internal company websites.
• If Denise connects to corporation.example.com first and public-vpn.example.com second, then she is able to access internal company resources. However, it only works because all her DNS requests are sent to corporation.example.com's DNS server. Sadly for Distrustful Denise, her employer discovers that she has been making some embarrassing DNS requests that she had expected to go through public-vpn.example.com instead.

Whichever VPN Denise connects to first receives all DNS requests because glibc's nss-dns module is not smart enough to split the requests. /etc/resolv.conf is just a list of DNS servers to try in order, and NetworkManager has no plausible way to decide which to list first, because both ways are broken, so it just prefers whichever was connected first. And if one server fails to respond, then the next server in the list will be tried, likely resulting in a DNS leak. In contrast, when systemd-resolved is enabled, it will send each DNS request only to the correct DNS server. The DNS server that will be used for each tun interface can be inspected using the resolvectl tool.

Migrating away from /etc/resolv.conf will also avoid an annoying footgun with this legacy file: only the first three listed nameservers are respected. All further nameservers are silently ignored. NetworkManager adds a warning comment when writing more than three nameservers to this file, but it cannot do any better than that.