5 ms·

This is also very likely to cause DNS leaks while using VPN. Which kind of makes whole idea of VPN unreliable and/or dangerous to rely on. Not because VPN desig

This is also very likely to cause DNS leaks while using VPN. Which kind of makes whole idea of VPN unreliable and/or dangerous to rely on. Not because VPN design has anything to do with this security hole but systemd tries hard to do stuff it doesn't really understand.

geofft 9y ago
Quite the opposite. The system of expecting resolver order to be respected (the glibc behavior) is the one that is likely cause DNS leaks while using a VPN: if your VPN connection or its DNS server is intermittently flaky, glibc will gladly go try your next, public resolver with the internal domain name. Meanwhile, systemd has actual functionality for scoping your VPN domain names to your VPN's DNS server only: https://www.freedesktop.org/software/systemd/man/systemd.network.html#Domains= https://www.freedesktop.org/software/systemd/man/systemd.net...
- binaryapparatus 9y ago
  Regardless of marketing pitch, resolver is no job for systemd. Or any other init/pid 1 process. Systemd is known to but in into areas that are not / should not be of concern for it. Also known to do stuff half baked or changing things because you can. So I'd very much love to see systemd fingers completely outside of dns resolver, that way we wouldn't have this conversation at all.
  - geofft 9y ago
    > Regardless of marketing pitch, resolver is no job for systemd. Or any other init/pid 1 process. Correct, which is why it's not part of /bin/systemd or any other init/pid 1 process.
    - binaryapparatus 9y ago
      You know, first thing that raised some flags with systemd for me, couple of years ago, is constant marketing push, like this one. Having one monolith executable or ten executables that increasingly demand each other is the same thing. Oh wait its name also suggests it is part of the package, being named Systemd-resolved. There is number of reality distortions like this one that systemd people tried to perform, during the several past years.
      - geofft 9y ago
        I don't know what you mean by "marketing". I am mentioning technical facts; you are saying things like "systemd tries hard to do stuff it doesn't really understand" and "reality distortions." Can we have a technical conversation?
        SomeStupidPoint 9y ago
        Because being technically correct while strawmanning the other person's position for your comment to even be relevant is the worst, not best, kind of correct. Being technically correct is only the best kind of correct if your technical point is actually relevant. Having a "technical conversation" would require you engaged with the person you were replying to, not engaging in what can only be described as "technical trolling". For the record, the vocal "technical trolls" are why I don't like systemd, despite having little opinion on the technical merits.
        geofft 9y ago
        That's a fair objection, thanks. I don't believe I am trolling or taking a strawman interpretation of 'binaryapparatus's arguments, but if I am I'd appreciate correction! I think it is relevant that the current state of affairs (with glibc) isn't actually better at preventing DNS leakage, and that systemd-networkd has relevant functionality specifically to address the underlying use case in a way that reliably blocks DNS leakage. I also think it is relevant that the functionality is not in pid 1 and (although I didn't say it, and maybe I should have) there is no particular obligation or desire on the part of systemd's pid 1 binary to use systemd-resolved. They're developed in the same project, and there are some nice things you get by using them together, but you don't have to, and you experience no loss of functionality as compared to the status quo ante systemd if you choose to use systemd as init plus the glibc stub resolver. (In particular, I think that's the standard way most distros configure systemd.) I was probably rude in my reply about how this functionality is not in pid 1, and for that I apologize, but I don't think I was irrelevant. Maybe I don't understand the objection to having systemd-resolved developed alongside an init system? (Developing everything together and using common routines where possible is the traditional UNIX approach, epitomized by the current BSDs.)
  - jryan49 9y ago
    It's a separate program, it's not part of init.

geofft 9y ago

Quite the opposite. The system of expecting resolver order to be respected (the glibc behavior) is the one that is likely cause DNS leaks while using a VPN: if your VPN connection or its DNS server is intermittently flaky, glibc will gladly go try your next, public resolver with the internal domain name. Meanwhile, systemd has actual functionality for scoping your VPN domain names to your VPN's DNS server only: https://www.freedesktop.org/software/systemd/man/systemd.network.html#Domains= https://www.freedesktop.org/software/systemd/man/systemd.net...

binaryapparatus 9y ago
Regardless of marketing pitch, resolver is no job for systemd. Or any other init/pid 1 process. Systemd is known to but in into areas that are not / should not be of concern for it. Also known to do stuff half baked or changing things because you can. So I'd very much love to see systemd fingers completely outside of dns resolver, that way we wouldn't have this conversation at all.
- geofft 9y ago
  > Regardless of marketing pitch, resolver is no job for systemd. Or any other init/pid 1 process. Correct, which is why it's not part of /bin/systemd or any other init/pid 1 process.
  - binaryapparatus 9y ago
    You know, first thing that raised some flags with systemd for me, couple of years ago, is constant marketing push, like this one. Having one monolith executable or ten executables that increasingly demand each other is the same thing. Oh wait its name also suggests it is part of the package, being named Systemd-resolved. There is number of reality distortions like this one that systemd people tried to perform, during the several past years.
    - geofft 9y ago
      I don't know what you mean by "marketing". I am mentioning technical facts; you are saying things like "systemd tries hard to do stuff it doesn't really understand" and "reality distortions." Can we have a technical conversation?
      - SomeStupidPoint 9y ago
        Because being technically correct while strawmanning the other person's position for your comment to even be relevant is the worst, not best, kind of correct. Being technically correct is only the best kind of correct if your technical point is actually relevant. Having a "technical conversation" would require you engaged with the person you were replying to, not engaging in what can only be described as "technical trolling". For the record, the vocal "technical trolls" are why I don't like systemd, despite having little opinion on the technical merits.
        geofft 9y ago
        That's a fair objection, thanks. I don't believe I am trolling or taking a strawman interpretation of 'binaryapparatus's arguments, but if I am I'd appreciate correction! I think it is relevant that the current state of affairs (with glibc) isn't actually better at preventing DNS leakage, and that systemd-networkd has relevant functionality specifically to address the underlying use case in a way that reliably blocks DNS leakage. I also think it is relevant that the functionality is not in pid 1 and (although I didn't say it, and maybe I should have) there is no particular obligation or desire on the part of systemd's pid 1 binary to use systemd-resolved. They're developed in the same project, and there are some nice things you get by using them together, but you don't have to, and you experience no loss of functionality as compared to the status quo ante systemd if you choose to use systemd as init plus the glibc stub resolver. (In particular, I think that's the standard way most distros configure systemd.) I was probably rude in my reply about how this functionality is not in pid 1, and for that I apologize, but I don't think I was irrelevant. Maybe I don't understand the objection to having systemd-resolved developed alongside an init system? (Developing everything together and using common routines where possible is the traditional UNIX approach, epitomized by the current BSDs.)
- jryan49 9y ago
  It's a separate program, it's not part of init.