|Line 26:||Line 26:|
== Detailed Description ==
== Detailed Description ==
systemd-libs %post scriplet
to //resolv.conf ? ?
note we are doing this differently than Ubuntu has. 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. 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:
If you do not wish to use systemd-resolved, then manual intervention will be required :
* Disable and stop systemd-resolved.service.
* Disable and stop systemd-resolved.service.
* Restart the NetworkManager service. NetworkManager will create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you create your own /etc/resolv.conf.)
* Restart the NetworkManager service. NetworkManager will create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you
== Benefit to Fedora ==
== Benefit to Fedora ==
Revision as of 20:24, 31 March 2020
Enable systemd-resolved by default. glibc will perform name resolution using nss-resolve rather than nss-dns.
- Name: Michael Catanzaro
- Email: <firstname.lastname@example.org>
- 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>
We will enable systemd-resolved by default.
- We will change the fedora-release presets to enable systemd-resolved instead of disable it.
- systemd-libs currently has a %post scriplet to enable nss-myhostname and nss-systemd by either (a) modifying authselect's user-nsswitch.conf template, if authselect is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We will enable nss-resolve here as well.
- We will symlink /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf (and not any of the various other stubs supported by systemd). To be determined: how will we do this? systemd-libs %post scriptlet?
systemd-resolved has been enabled by default in Ubuntu since Ubuntu 16.10, but please note we are doing this differently than Ubuntu has. 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. But . This extra step is not useful and is presumably only kept around , and 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 to disable it:
- 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.)
- Disable and stop systemd-resolved.service.
- Restart the NetworkManager service. NetworkManager will then create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you may 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. (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, and 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. 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.
- 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)
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.
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.
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.
The contingency plan, in the unlikely event of unexpected problems, is simply to revert any changes and not enable systemd-resolved.
- Contingency deadline: beta freeze
- Blocks release? No
- Blocks product? No
- systemd-resolved is documented in several manpages: resolvectl(1), resolved.conf(5), nss-resolve(8), systemd-resolved(8).
- Arch Wiki documentation
- NetworkManager DNS documentation