Announcement

Collapse
No announcement yet.

Fedora 33 Planning To Enable Systemd-Resolved By Default

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

  • pal666
    replied
    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

    Leave a comment:


  • pal666
    replied
    Originally posted by Spam View Post
    What problem is resolvd fixing?
    name resolution

    Leave a comment:


  • oiaohm
    replied
    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.

    Leave a comment:


  • Terrablit
    replied
    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:

    https://github.com/systemd/systemd/issues/5755

    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.

    Leave a comment:


  • loinad
    replied
    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.

    Leave a comment:


  • Mark Rose
    replied
    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.

    Leave a comment:


  • loinad
    replied
    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:

    https://github.com/systemd/systemd/issues/5755

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

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

    Leave a comment:


  • oiaohm
    replied
    Originally posted by loinad View Post


    No, it hasn't. OpenDNS name resolution is totally broken by default on Ubuntu 19.10 for my corporate VPN. The "solutions" presented in this thread either don't work or work temporarily and unreliably for some minutes or until the next reboot: https://askubuntu.com/questions/1032...ted-to-openvpn

    Of course the old and expected behavior of editing resolv.conf and adding a nameserver at the top could fix it (if systemd-resolved didn't auto-manage it), but systemd guys couldn't restrain themselves in order not to break the simple and sane behavior of true and tested Linux tools.
    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.

    https://github.com/systemd/systemd/issues/6076

    Originally posted by Mark Rose View Post

    Ubuntu 18.04's packages, so systemd 237 and network-manager 1.10.6-2ubuntu1.4. It exists with the latest packages, and myself and coworkers have reproduced the bug on at least five different machines. https://bugs.launchpad.net/ubuntu/+s...r/+bug/1851407
    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.

    Leave a comment:


  • Mark Rose
    replied
    Originally posted by usta View Post

    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?
    Ubuntu 18.04's packages, so systemd 237 and network-manager 1.10.6-2ubuntu1.4. It exists with the latest packages, and myself and coworkers have reproduced the bug on at least five different machines. https://bugs.launchpad.net/ubuntu/+s...r/+bug/1851407

    Originally posted by intelfx View Post

    It’s quite the inverse. systemd-resolved (when paired with an intelligent enough network tool, e. g. NetworkManager) is the only Linux software in existence that will do the right thing by default when you have multiple interfaces each with its own internal DNS.
    Except when it doesn't work at all. The solution we found was just getting rid of resolved: https://askubuntu.com/a/907249

    Leave a comment:


  • cjcox
    replied
    And remember, don't fork, contribute. Unless.... .... d.

    Leave a comment:

Working...
X