Originally posted by loinad
View Post
Announcement
Collapse
No announcement yet.
Fedora 33 Planning To Enable Systemd-Resolved By Default
Collapse
X
-
-
Originally posted by loinad View PostAnd here's a good article precisely on the bad state tracking that resolved implements:
http://edgeofsanity.net/rant/2017/12...is-broken.html
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 Postdecades of things that just worked, regardless of whether we may consider them as having "hidden, masked faults" or not:
Originally posted by Mark Rose View PostI 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.
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.
- Likes 1
Leave a comment:
-
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
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
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.
- Likes 1
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
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.
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
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
Leave a comment:
-
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.
Submission type Request for enhancement (RFE) systemd version the issue has been seen with systemd 232 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL...
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
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:
-
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?
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.
Leave a comment:
Leave a comment: