Announcement

Collapse
No announcement yet.

Fedora 33 Planning To Enable Systemd-Resolved By Default

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora 33 Planning To Enable Systemd-Resolved By Default

    Phoronix: Fedora 33 Planning To Enable Systemd-Resolved By Default

    Fedora 33 this autumn is looking to make use of systemd-resolved by default rather than NSS-DNS for name resolution...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      Alpha/beta versions must be called systemd-is-gonna-resolve.

      Comment


      • #4
        What problem is resolvd fixing?

        Comment


        • #5
          Originally posted by Spam View Post
          What problem is resolvd fixing?
          It's pretty nice to have a resolver that supports DNS over TLS natively available.

          Comment


          • #6
            I had to disable systemd-resolved because it won't consistently resolve DNS over OpenVPN connections.

            Comment


            • #7
              Originally posted by Mark Rose View Post
              I had to disable systemd-resolved because it won't consistently resolve DNS over OpenVPN connections.
              and in which version of systemd and when you had that problems ? Did you have any chance to give it a try to test if the problems still exist?

              Comment


              • #8
                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.

                Comment


                • #9
                  Originally posted by Spam View Post
                  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.

                  Comment


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

                    Comment

                    Working...
                    X