5 ms·

The most dangerous thing about systemd-resolved is that it exposes its own non-standard DNS resolution protocol over dbus, which the documentation recommends ap

by agwa 9y ago

The most dangerous thing about systemd-resolved is that it exposes its own non-standard DNS resolution protocol over dbus, which the documentation recommends applications use instead of standard, interoperable protocols[1]: > The native, fully-featured API systemd-resolved exposes on the bus. See the API Documentation for details. Usage of this API is generally recommended to clients as it is asynchronous and fully featured (for example, properly returns DNSSEC validation status and interface scope for addresses as necessary for supporting link-local networking). systemd wants applications to depend on systemd-resolved so it becomes irreplaceable. This is very bad, because the first thing you should do on a system with systemd-resolved is uninstall it. The systemd developers are not qualified to write either DNS software[2] or C code that talks to the network. [1] https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html https://www.freedesktop.org/software/systemd/man/systemd-res... [2] See http://seclists.org/oss-sec/2014/q4/592 http://seclists.org/oss-sec/2014/q4/592, which came out after Lennart Poettering had the hubris to call systemd-resolved a "pretty complete caching DNS and LLMNR stub resolver"[3] even though the dangers of DNS cache poisoning were already well known at the time. [3] https://lwn.net/Articles/609740/ https://lwn.net/Articles/609740/

RussianCow 9y ago
Does anyone have any insight as to why systemd has its own DNS resolution API? That seems like a very strange decision. Is it really only so that systemd "becomes irreplaceable"?
- 5ilv3r 9y ago
  It's more about dbus, really. They are trying to get rid of 'everything is a file' and move to a pub/sub service model.
  - deleted 9y ago
    [deleted]
  - rsync 9y ago
    "They are trying to get rid of 'everything is a file' and move to a pub/sub service model." I thought we were trying to move towards "everything is a file" ... isn't that the goal of the plan9/Inferno movement ? I thought that was the progressive direction in UNIX design. We want to move away from "everything is a file" ?
    - deno 9y ago
      Everything is a file ≠ everything is a blob/adhoc plaintext interface. DBus is a much superior “everything is a file” abstraction, except DBus calls files objects and doesn’t special-case directories. Quick comparison: Inode — Client address .. e.g. 3597293 — :1.32 Mount points — Well-known addresses .. e.g. /proc/subsystem — org.foo.subsystem1 Directory/file hierarchy — Object hierarchy .. e.g. /foo/bar/xyz — /foo/bar/xyz Implicit RPC — Explicit RPC .. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int, int, string) Security .. sudo vs Polkit etc.
      - wahern 9y ago
        > Everything is a file ≠ everything is a blob/adhoc plaintext interface. Actually, yes, it more or less means exactly that. Everything is a file means your interfaces (i.e. object methods) are generally limited to open, read, write, and close. Of course you can synthesize whatever you want on top of that, but the basic contract relies on those primitives exclusively.
        deno 9y ago
        And this is better how exactly?
        wahern 9y ago
        Ever try to use a dbus service from the shell? From any language that _doesn't_ rely on a binding to the C library? Therein lies your answer. It's like ioctl. The ioctl interface is an abomination precisely because it breaks the open/read/write/close interface. Ever try to use an ad hoc ioctl interface from any language other than C or C++? If all the world used the same programming language with the same control flow constructs then a strongly typed RPC interface would make a ton of sense. But it doesn't. The everything-is-a-file contract works well for the same reason that IP works well: because it pushes the complexity to the edges, and when the technology changes you don't need to upgrade every piece of middleware. Almost every modern language supports open, read, write, and close from day 1, giving you the necessary primitives to communicate with anything supporting that model. Of course, maybe batteries aren't included and you have to do some grunt work. But that's often the interface designers fault. Opening a TCP connection on Plan 9 is as easy as a single open call, vs multiple complex system calls using a more typed interface like the BSD Sockets API. Even dbus can be exported through the file model. Theoretically you could expose dbus through the filesystem namespace using something like FUSE. And, actually, here's an attempt at that: https://github.com/sidorares/dbusfs https://github.com/sidorares/dbusfs Which goes to show how flexible the open/read/write/close model truly is.
- pas 9y ago
  Because the basic glibc resolver is still in the last century. (No cache, no DNSSEC, no link-local multicast name resolution, no concept of per-interface DNS resolution worlds, and so on. See the relevant part of the NEWS file: https://github.com/systemd/systemd/blob/master/NEWS#L3966 https://github.com/systemd/systemd/blob/master/NEWS#L3966 ) See also: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html# https://www.freedesktop.org/software/systemd/man/systemd-res...
  - agwa 9y ago
    Cache and DNSSEC do not require a non-standard DBUS API. LLMNR and per-interface DNS resolution are features that very few applications need. Those that do can link with their own resolver libraries.
  - JdeBP 9y ago
    nscd, which is part of the GNU C library, is a cache. Moreover: Strictly speaking what is in the C library, to use the jargon, is a stub resolver; with all of the things that you mention not actually belonging in the C library in the first place.
    - pas 9y ago
      Yes, you're of course right. And Ubuntu used dnsmasq as a caching resolver for quite a long time. (Via using 127.0.0.1 in /etc/resolv.conf) systemd-resolved is sort of the same thing (and it listens on 127.0.0.53, which doesn't require the DBus dance that the nss plugin does) I don't know why systemd reinvented the wheel (nscd), but probably because nscd lacks a DBus API.
vhvhbbv 9y ago
Please note that this guy is a troll and has been called out for not knowing what he's talking about in the past[0] [0]: https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-... Thanks.
- 5ilv3r 9y ago
  An opinion backed up with facts and sources is trolling? Go look in a mirror next time you troll hunt.
- digi_owl 9y ago
  Ah yes, being called a troll by a systemd dev. At this point i would consider it a badge of honor.
qb45 9y ago
> This is very bad, because the first thing you should do on a system with systemd-resolved is uninstall it. Thanks, I just realized that my Arch installation has nih-emd-resolved enabled as the default backend for glibc getaddrinfo and friends. This is how it happens: https://www.freedesktop.org/software/systemd/man/nss-resolve.html https://www.freedesktop.org/software/systemd/man/nss-resolve... I'm not responsible for any harm to systemd resulting from the use of this information ;) edit: And yes, the current version of the package is 232, built in January, so should be vulnerable.

by agwa 9y ago

RussianCow 9y ago

Does anyone have any insight as to why systemd has its own DNS resolution API? That seems like a very strange decision. Is it really only so that systemd "becomes irreplaceable"?

5ilv3r 9y ago
It's more about dbus, really. They are trying to get rid of 'everything is a file' and move to a pub/sub service model.
- deleted 9y ago
  [deleted]
- rsync 9y ago
  "They are trying to get rid of 'everything is a file' and move to a pub/sub service model." I thought we were trying to move towards "everything is a file" ... isn't that the goal of the plan9/Inferno movement ? I thought that was the progressive direction in UNIX design. We want to move away from "everything is a file" ?
  - deno 9y ago
    Everything is a file ≠ everything is a blob/adhoc plaintext interface. DBus is a much superior “everything is a file” abstraction, except DBus calls files objects and doesn’t special-case directories. Quick comparison: Inode — Client address .. e.g. 3597293 — :1.32 Mount points — Well-known addresses .. e.g. /proc/subsystem — org.foo.subsystem1 Directory/file hierarchy — Object hierarchy .. e.g. /foo/bar/xyz — /foo/bar/xyz Implicit RPC — Explicit RPC .. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int, int, string) Security .. sudo vs Polkit etc.
    - wahern 9y ago
      > Everything is a file ≠ everything is a blob/adhoc plaintext interface. Actually, yes, it more or less means exactly that. Everything is a file means your interfaces (i.e. object methods) are generally limited to open, read, write, and close. Of course you can synthesize whatever you want on top of that, but the basic contract relies on those primitives exclusively.
      - deno 9y ago
        And this is better how exactly?
        wahern 9y ago
        Ever try to use a dbus service from the shell? From any language that _doesn't_ rely on a binding to the C library? Therein lies your answer. It's like ioctl. The ioctl interface is an abomination precisely because it breaks the open/read/write/close interface. Ever try to use an ad hoc ioctl interface from any language other than C or C++? If all the world used the same programming language with the same control flow constructs then a strongly typed RPC interface would make a ton of sense. But it doesn't. The everything-is-a-file contract works well for the same reason that IP works well: because it pushes the complexity to the edges, and when the technology changes you don't need to upgrade every piece of middleware. Almost every modern language supports open, read, write, and close from day 1, giving you the necessary primitives to communicate with anything supporting that model. Of course, maybe batteries aren't included and you have to do some grunt work. But that's often the interface designers fault. Opening a TCP connection on Plan 9 is as easy as a single open call, vs multiple complex system calls using a more typed interface like the BSD Sockets API. Even dbus can be exported through the file model. Theoretically you could expose dbus through the filesystem namespace using something like FUSE. And, actually, here's an attempt at that: https://github.com/sidorares/dbusfs https://github.com/sidorares/dbusfs Which goes to show how flexible the open/read/write/close model truly is.
pas 9y ago
Because the basic glibc resolver is still in the last century. (No cache, no DNSSEC, no link-local multicast name resolution, no concept of per-interface DNS resolution worlds, and so on. See the relevant part of the NEWS file: https://github.com/systemd/systemd/blob/master/NEWS#L3966 https://github.com/systemd/systemd/blob/master/NEWS#L3966 ) See also: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html# https://www.freedesktop.org/software/systemd/man/systemd-res...
- agwa 9y ago
  Cache and DNSSEC do not require a non-standard DBUS API. LLMNR and per-interface DNS resolution are features that very few applications need. Those that do can link with their own resolver libraries.
- JdeBP 9y ago
  nscd, which is part of the GNU C library, is a cache. Moreover: Strictly speaking what is in the C library, to use the jargon, is a stub resolver; with all of the things that you mention not actually belonging in the C library in the first place.
  - pas 9y ago
    Yes, you're of course right. And Ubuntu used dnsmasq as a caching resolver for quite a long time. (Via using 127.0.0.1 in /etc/resolv.conf) systemd-resolved is sort of the same thing (and it listens on 127.0.0.53, which doesn't require the DBus dance that the nss plugin does) I don't know why systemd reinvented the wheel (nscd), but probably because nscd lacks a DBus API.

vhvhbbv 9y ago

Please note that this guy is a troll and has been called out for not knowing what he's talking about in the past[0] [0]: https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-... Thanks.

5ilv3r 9y ago
An opinion backed up with facts and sources is trolling? Go look in a mirror next time you troll hunt.
digi_owl 9y ago
Ah yes, being called a troll by a systemd dev. At this point i would consider it a badge of honor.

qb45 9y ago

> This is very bad, because the first thing you should do on a system with systemd-resolved is uninstall it. Thanks, I just realized that my Arch installation has nih-emd-resolved enabled as the default backend for glibc getaddrinfo and friends. This is how it happens: https://www.freedesktop.org/software/systemd/man/nss-resolve.html https://www.freedesktop.org/software/systemd/man/nss-resolve... I'm not responsible for any harm to systemd resulting from the use of this information ;) edit: And yes, the current version of the package is 232, built in January, so should be vulnerable.