From Fedora Project Wiki

systemd-resolved

Summary

Enable systemd-resolved by default. glibc will perform name resolution using nss-resolve rather than nss-dns.

Owner

Current status

  • Targeted release: Fedora 33
  • Last updated: 2020-03-31
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

TODO(mcatanzaro)

  • Change presets in fedora-release
  • Change systemd-libs %post scriplet
  • How to create /etc/resolv.conf symlink???

Please note that we are doing this differently than Ubuntu has. Although Ubuntu has enabled systemd-resolved by default for several years, Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional nss-dns provided by glibc upstream, so glibc on Ubuntu continues to read /etc/resolv.conf, as is traditional. We want to follow upstream recommendations in using nss-resolve instead.

If you do not wish to use systemd-resolved, then manual intervention will be required:

  • Disable and stop systemd-resolved.service.
  • Modify /etc/authselect/user-nsswitch.conf and remove resolve [!UNAVAIL=return] from the hosts line. Run authselect apply-changes. (If you have disabled authselect, then edit /etc/nsswitch.conf directly.)
  • Restart the NetworkManager service. NetworkManager will create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you must manually create your own /etc/resolv.conf.)

Benefit to Fedora

Fedora will continue its history of enabling new systemd-provided services whenever it makes sense to do so. Standardizing on upstream systemd services is beneficial to the broader Linux ecosystem in addition to Fedora, since standardizing reduces behavior differences between different Linux distributions. Sadly, Fedora is no longer leading in this area. Ubuntu has enabled systemd-resolved by default since Ubuntu 16.10, so by the time Fedora 33 is released, we will be three years behind Ubuntu here. (Fortunately, being late means that showstopper bugs have been resolved.) Ubuntu has also enabled systemd-timesyncd by default since Ubuntu 16.04, which makes sense to enable in Fedora, but which is not covered by this change. Finally, systemd also provides systemd-networkd; however, this one is not suitable for Fedora because it conflicts with NetworkManager.

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, NetworkManager has no plausible way to decide which to DNS server to list first, because both ways are broken, so it just prefers whichever was connected first. In contrast, when systemd-resolved is enabled, it will send each DNS request to the DNS server corresponding to the VPN that will actually be used for the connection. 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.

Scope

  • Proposal owners: We will update Fedora presets to enable systemd-resolved by default. We will work with the systemd maintainers to enable nss-resolve using an RPM scriptlet.
  • Other developers: This change requires coordination with the systemd and authselect maintainers.
  • Release engineering: #9367
  • Policies and guidelines: none required
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

systemd-resolved will be enabled automatically when upgrading to Fedora 33. After upgrade, /etc/resolv.conf will be managed by systemd and symlinked to /run/systemd/resolve/stub-resolv.conf. glibc will no longer look at /etc/resolv.conf when performing name resolution. Instead, glibc will communicate directly with systemd-resolved via nss-resolve. systemd adds a large warning comment to the top of /etc/resolv.conf to warn system administrators that changes to this file will be ignored; however, scripts that edit this file manually will break. Because this file is usually managed by NetworkManager, impact to Fedora users will be limited to users who have manually disabled NetworkManager; such users are expected to be experienced system administrators who should be comfortable adapting to the change (or disabling systemd-resolved).

Any applications that bypass glibc and read /etc/resolv.conf directly will still work because /etc/resolv.conf will point to systemd-resolved's stub resolver running on 127.0.0.53. Nevertheless, /etc/resolv.conf is provided only for compatibility purposes, and applications should prefer to use either glibc or the systemd-resolved D-Bus API instead; see systemd-resolved(8) for details.

In short, applications that read /etc/resolv.conf will continue to work as before, but applications that write to it will no longer work as expected. Any custom system administration scripts that manage /etc/resolv.conf will need to be updated.

How To Test

Load any website in a web browser. If you succeed, then name resolution works.

Users who use multiple VPNs at the same time are encouraged to test DNS in a multiple VPN scenario, to ensure that DNS requests are sent to the expected DNS server.

User Experience

See the Benefit to Fedora section, above, for direct benefits to users who use multiple VPNs at the same time.

Users will no longer be able to edit /etc/resolv.conf, as this file will now be managed by systemd. Users will instead be able to use the resolvectl tool and the functionality it provides.

Dependencies

In Fedora, /etc/nsswitch.conf is managed by authselect. By default, authselect uses the sssd profile to generate configuration compatible with sssd. In this mode of operation, it does not modify the hosts line in /etc/nsswitch.conf. This is also true if using the winbind profile instead of the sssd profile. However, authselect's minimal and nis profiles do modify the hosts line. These authselect profiles must be updated to enable nss-resolved. If you are using authselect in one of these modes, it will not be possible to cleanly disable systemd-resolved because the hosts line in /etc/nsswitch.conf will be clobbered whenever 'authselect apply-changes' is run. If you wish to disable systemd-resolved and you are using authselect in one of these modes, then you should stop using authselect. This is not expected to cause many problems because virtually all Fedora users will be using the default sssd profile.

We do not need to directly make any changes to the /etc/nsswitch.conf shipped by glibc. Changes will be applied in the systemd-libs %post scriptlet.

Contingency Plan

  • Contingency deadline: beta freeze
  • Blocks release? No
  • Blocks product? No

Documentation

Release Notes

TODO(mcatanzaro)

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/systemd-resolved&oldid=569931"