Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday, April 14, 2020 12:23:27 PM MST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/systemd-resolved
> 
> == Summary ==
> 
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
> 
> == Owner ==
> * Name: [[User:catanzaro| Michael Catanzaro]]
> * Email: <mcatanzaro@xxxxxxxxxx>
> 
> == Detailed Description ==
> 
> We will enable systemd-resolved by default.
> 
> # We will change the
> [https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233e5
> e984a487e385def0ddca/f/90-default.preset fedora-release presets] to enable
> systemd-resolved instead of disable it.
> # systemd-libs currently has
> [https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede
> 5d234b7878753/f/systemd.spec#_606 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 work with the systemd
> maintainers to enable nss-resolve here as well.
> # We will work with the authselect maintainers to update authselect's
> minimal and nis profiles to enforce nss-resolve. These profiles modify
> the hosts line of /etc/resolv.conf. (By default, Fedora uses
> authselect's sssd profile, which does not modify the hosts line and
> therefore does not have this problem.)
> # We will remove our downstream patch to systemd that prevents systemd
> from symlinking /etc/resolv.conf to
> /run/systemd/resolve/stub-resolv.conf on new installs. For system
> upgrades, a systemd-libs %post scriptlet will be used to reassign the
> symlink during upgrade. Upon detecting this symlink, NetworkManager
> will automatically enable its systemd-resolved support and configure
> split DNS as appropriate.
> 
> 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. This extra step is not
> useful and not recommended by upstream. 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 ==
> 
> === Standardization ===
> 
> 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.
> 
> === resolvectl ===
> 
> `resolvectl` has several useful functions (e.g. `resolvectl status` or
> `resolvectl query`) that will be enabled out-of-the-box.
> 
> === Caching ===
> 
> systemd-resolved caches DNS queries for a short while. This can
> [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
> dramatically] improve performance for applications that do not already
> manually cache their own DNS results. (Generally, only web browsers
> bother with manually caching DNS results.)
> 
> === Split DNS ===
> 
> 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.
> 
> === DNS over TLS ===
> 
> systemd-resolved supports DNS over TLS (different from DNS over
> HTTPS). Although this feature will not initially be enabled by
> default, using systemd-resolved will enable us to turn on DNS over TLS
> in a future Fedora release, providing improved security if the user's
> DNS server supports DNS over TLS.
> 
> == Scope ==
> * Proposal owners: We will update Fedora presets to enable
> systemd-resolved by default.
> 
> * Other developers: This change requires coordination with the systemd
> and authselect maintainers.
> 
> * Release engineering: [https://pagure.io/releng/issue/9367 #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.''' Applications that write to it will no longer work
> as expected, but this only previously worked if NetworkManager is
> disabled, a non-default configuration. It remains possible to disable
> systemd-resolved if desired. Otherwise, any custom system
> administration scripts that manage /etc/resolv.conf will need to be
> updated.
> 
> === DNSSEC ===
> 
> systemd-resolved's DNSSEC support is known to cause compatibility
> problems with certain network access points. Per recommendation from
> the systemd developers, we will change the default value of this
> setting in Fedora from the upstream default `DNSSEC=allow-downgrade`
> to `DNSSEC=no` by building systemd with the build option
> `-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if
> it is working, but automatically disable it otherwise, allowing
> man-in-the-middle attackers to disable DNSSEC. Sadly, even the
> allow-downgrade setting suffers known compatibility problems. Because
> Fedora is not prepared to handle an influx of DNSSEC-related bug
> reports, we will disable this feature altogether. We anticipate that
> enabling DNSSEC by default will not be possible in the foreseeable
> future, or perhaps ever. Instead, enabling DNS over TLS (when
> supported by the DNS server) seems likely in the near future.
> 
> === Multicast DNS ===
> 
> systemd-resolved's multicast DNS support conflicts with Avahi. Per
> recommendation from the systemd developers, we will change the default
> value of this setting in Fedora from the upstream default
> `MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
> will be enabled, but responding will be disabled. This will require
> adding a new systemd build option to control the default value of the
> MulticastDNS setting, similar to the existing `default-dnssec` and
> `default-dns-over-tls` build options.
> 
> == How To Test ==
> 
> Load any website in a web browser. If you succeed, then name
> resolution probably works.
> 
> Try using `resolvectl status` and, for example, `resolvectl query
> fedoraproject.org`, to see how they work and sanity-check their
> output.
> 
> 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 be able to use the resolvectl tool and the functionality it
> provides.
 
> /etc/resolv.conf will now be managed by systemd rather than by
> NetworkManager. As before, this file must not be modified directly
> when it is managed.
> 
> == 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 ==
> 
> 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
> 
> == Documentation ==
> 
> * systemd-resolved is documented in several manpages: resolvectl(1),
> resolved.conf(5), nss-resolve(8), systemd-resolved(8).
> * [https://wiki.archlinux.org/index.php/Systemd-resolved Arch Wiki
> documentation]
> * [https://wiki.gnome.org/Projects/NetworkManager/DNS NetworkManager
> DNS documentation]
> 
> == Release Notes ==
> 
> systemd-resolved is now enabled by default. systemd-resolved provides
> a system-level DNS cache that can substantially improve performance
> for applications that do not cache their own DNS results, allows
> correct handling of split DNS scenarios such as when multiple VPNs are
> in use, and will allow Fedora to enable DNS over TLS in the future.
> /etc/resolv.conf will now be managed by systemd-resolved rather than
> by NetworkManager. /etc/resolv.conf will no longer be read when
> performing name resolution using glibc; however, it is still provided
> for compatibility with applications that manually read this file to
> perform name resolution. Writing to /etc/resolv.conf will no longer
> work as expected.
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis

Really, it may be best to go about this in the same way as Ubuntu, with nss-
dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done 
on Fedora, especially on servers. In fact, I never knew that NetworkManager 
would clobber that until this thread. If this isn't mean to wreck everyone's 
systems, backwards compatibility is key.

If not by using nss-dns, could systemd-resolved be modified such that it would 
read /etc/resolv.conf?

-- 
John M. Harris, Jr.
Splentity

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux