Announcement

Collapse
No announcement yet.

Fedora 33 Planning To Enable Systemd-Resolved By Default

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

  • #41
    Originally posted by oiaohm View Post

    Except that does not in fact fix it just make the bug less frequent. Resolved does multi dns resolve so it walks down the DNS list very quickly. In fact shows a fault in your configuration that would normally be hidden. The fault with what you said add nameserver at top of resolv.conf under the past system was that if that DNS server did not respond for some reason old resolve system will walk down the list as well. Basically you need to set DNS priorities and you need to give directives that DHCP got DNS servers don't nuke you VPN ones. On business networks this can be setting particular domains to be resolved by particular DNS servers. Reality you need to do this bit with or without resolved.
    Seems you're basically suggesting one of the proposed solutions from my link and also from the GitHub issue you linked, which - if you're using NetworkManager -- consists of running

    Code:
    nmcli -p connection modify MY_VPN_CONNECTION ipv4.never-default no
    nmcli -p connection modify MY_VPN_CONNECTION ipv4.ignore-auto-dns no
    nmcli -p connection modify MY_VPN_CONNECTION ipv4.dns-priority -42
    If so, no, it doesn't fix it. It makes it work for a little while, but resolved eventually does its magic again and breaks everything one more time and you need to rerun all of that. In practice, its idiotic behavior that Poettering calls "memory" -- and is an implementation of *state tracking* against a *stateless protocol* -- makes it so that resolved often gets stuck with trying the ISP/non-OpenVPN DNS after a reconnect or any small instability from the OpenVPN network/DNS and does not switch back to the OpenVPN one (although in theory it should).

    Here's the golden thread in which Poettering tries justifying the new behavior against everyone's expectations -- and decades of things that just worked, regardless of whether we may consider them as having "hidden, masked faults" or not:

    Submission type Bug report Request for enhancement (RFE) NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker! systemd version the issue has been seen with Version 232 ...


    And here's a good article precisely on the bad state tracking that resolved implements:

    http://edgeofsanity.net/rant/2017/12...is-broken.html

    Comment


    • #42
      Originally posted by oiaohm View Post

      Except that bug says developers could not reproduce fault. And are asking if you missed ipv4.never-default=yes in all those cases. Yes not setting this in network manager and using the old resolve system still leaves you open to security bug just now requiring the first server not to respond triggering a walk down the list.

      Basically resolved makes a fairly hidden bug caused by miss configuration happen really commonly and it cause is still miss configuration expect now people want to blame resolved instead of waking up o crap our configuration as been wrong all this time.
      I would say it does fall on Ubuntu's shoulders. We're not doing anything other than installing the network-manager-openvpn package, and adding a VPN profile. The fact is that private DNS entries over the VPN connection sporadically don't resolve was introduced in 1.10.6-2ubuntu1.2. This change was related to the DNS leaking, but there remains an unsolved bug. If `ipv4.never-default=yes` needs to be set, why doesn't network-manager just do it? Sounds like a distribution bug to me then.

      Comment


      • #43
        Originally posted by Mark Rose View Post

        I would say it does fall on Ubuntu's shoulders. We're not doing anything other than installing the network-manager-openvpn package, and adding a VPN profile. The fact is that private DNS entries over the VPN connection sporadically don't resolve was introduced in 1.10.6-2ubuntu1.2. This change was related to the DNS leaking, but there remains an unsolved bug. If `ipv4.never-default=yes` needs to be set, why doesn't network-manager just do it? Sounds like a distribution bug to me then.
        That setting is only a temporary workaround. resolved eventually "ignores" it after any temporary blip in connectivity to internal DNS servers and end up blacklisting them indefinitely, so that you must perform the workarounds again to make resolved try the internal servers once more.

        Comment


        • #44
          Originally posted by loinad View Post

          Seems you're basically suggesting one of the proposed solutions from my link and also from the GitHub issue you linked, which - if you're using NetworkManager -- consists of running

          Code:
          nmcli -p connection modify MY_VPN_CONNECTION ipv4.never-default no
          nmcli -p connection modify MY_VPN_CONNECTION ipv4.ignore-auto-dns no
          nmcli -p connection modify MY_VPN_CONNECTION ipv4.dns-priority -42
          If so, no, it doesn't fix it. It makes it work for a little while, but resolved eventually does its magic again and breaks everything one more time and you need to rerun all of that. In practice, its idiotic behavior that Poettering calls "memory" -- and is an implementation of *state tracking* against a *stateless protocol* -- makes it so that resolved often gets stuck with trying the ISP/non-OpenVPN DNS after a reconnect or any small instability from the OpenVPN network/DNS and does not switch back to the OpenVPN one (although in theory it should).

          Here's the golden thread in which Poettering tries justifying the new behavior against everyone's expectations -- and decades of things that just worked, regardless of whether we may consider them as having "hidden, masked faults" or not:

          Submission type Bug report Request for enhancement (RFE) NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker! systemd version the issue has been seen with Version 232 ...


          And here's a good article precisely on the bad state tracking that resolved implements:

          http://edgeofsanity.net/rant/2017/12...is-broken.html
          So yeah, this behavior being mandatory is beyond obstinate of the systemd team. I'm also in general pro-systemd. But as long as systemd is forcing you to use this goofy state tracking with no configurability, I'll have to disable resolved or do some hacky single dns server with a local DNS cache server. Honestly, it shouldn't be that hard to make the state tracking optional.

          I'm generally "pro-progress", but I hate when the old behavior was expected or required for basic functionality and it's deliberately obfuscated or blocked in a new release/product with the excuse that what they really need is some future feature that's not there. Fine, then, until the new stuff is there, let me do it the old way. But no, the developers get all purist about the approach and just leave massive amounts of people in the lurch. Regardless of how you're interpreting the spec, the reality of how DNS servers work now is its own spec that you need to learn to follow. Even if you make another hyper-secure mode that goes the extra mile.

          It reminds me of the current kerfluffle with Elm and how obnoxiously obtuse the Elm core team is being about gatekeeping native modules when there's no suitable alternative for many features.

          Comment


          • #45
            Originally posted by loinad View Post
            And here's a good article precisely on the bad state tracking that resolved implements:

            http://edgeofsanity.net/rant/2017/12...is-broken.html
            This gets something badly wrong. The glibc rotate on resolve use work globally not per process before 2007. Yes the rotate stopped working globally when Linux gets cgroups when people notice that glibc is creating a area of shared memory being shared between all processes storing things like PID lookup results to reduced syscall and resolves and where the rotation on the resolve and when o crap this is a security nightmare. So basically before you time this is a 2007 breakage by the way basically 10 years before that write up and you guys noticed something. There were complaints from those with multi DNS servers that requests were not being correctly load balanced back in 2007.

            Technically resolved restores the old glibc before 2007 rotation system. Please note glibc was not the only Unix world resolve where rotate was global. Glibc was the only one that when from rotate being global back to per process.

            So the rotate feature was broken resolved fixs that only to make you have to configure stuff with more detail.

            Originally posted by loinad View Post
            decades of things that just worked, regardless of whether we may consider them as having "hidden, masked faults" or not:
            No the reality is not decades it is a single decade. Since a decade has past from the resolve rotate stop working and glibc sharing resolving state between processes you are no longer use to that horrible behaviour. Resolved is doing the old early Linux behaviour.

            Originally posted by Mark Rose View Post
            I would say it does fall on Ubuntu's shoulders. We're not doing anything other than installing the network-manager-openvpn package, and adding a VPN profile. The fact is that private DNS entries over the VPN connection sporadically don't resolve was introduced in 1.10.6-2ubuntu1.2. This change was related to the DNS leaking, but there remains an unsolved bug. If `ipv4.never-default=yes` needs to be set, why doesn't network-manager just do it? Sounds like a distribution bug to me then.
            Its not that straight forwards. If you are connecting to a company domain you may have in your DNS resolve for particular wild card domain names to go particular server in that case you don't need ipv4.never-default and load balancing across the DNS servers is kind of right.

            Hard reality here there is no hard rule that resolve files have to be processed in order top to bottom either not all Unix or Linux historically have done that.

            Basically due feature being removed in 2007 from glibc people have got use to doing VPN set-ups without enough detail in configuration to really correctly guide DNS requests in the correct direction.
            Last edited by oiaohm; 16 April 2020, 12:28 AM.

            Comment


            • #46
              Originally posted by Spam View Post
              What problem is resolvd fixing?
              name resolution

              Comment


              • #47
                Originally posted by loinad View Post
                OpenDNS name resolution is totally broken by default on Ubuntu 19.10 for my corporate VPN.
                that's ubuntu's (or your) problem. i don't use ubuntu and systemd-resolved works like a charm

                Comment

                Working...
                X