7 ms·

That is not what springs to mind, more "why the fuck are you reimplementing DNS in init". Like, this stuff was built tens of years ago and that code is crappy

That is not what springs to mind, more "why the fuck are you reimplementing DNS in init". Like, this stuff was built tens of years ago and that code is crappy too but we have pretty much got rid of the most obvious security issues. Nobody wants to relive history so you can finally implement a broken DNS client.

s_kilk 9y ago
> "why the fuck are you reimplementing DNS in init" Because systemd
vertex-four 9y ago
systemd is not "just" init, it's a suite of various tools, most of which (including systemd-resolved) don't run as PID 1. It's a monolith by the fact that this project decided to take over a variety of normal system daemons and make it as difficult as possible to use many of them without using the rest - it's not a monolith in the sense of everything running in the same process. I believe systemd-resolved, however, is one of those components that is entirely optional, and which nothing explicitly depends on... which makes it weird that Ubuntu chose to use it by default.
- icebraining 9y ago
  Ubuntu already had a resolver installed by default on desktops (dnsmasq). They decided to switch because: we picked "resolved" as that is small and lightweight, already present (part of the systemd package), does not require D-Bus (unlike dnsmasq), supports DNSSEC, provides transparent fallback to contacting the real DNS servers directly (in case anything goes wrong with the local resolver), and avoids the first issue above that /etc/resolv.conf always shows 127.0.0.1.
  - digi_owl 9y ago
    Do not require dbus?! https://www.freedesktop.org/wiki/Software/systemd/resolved/ https://www.freedesktop.org/wiki/Software/systemd/resolved/
    - icebraining 9y ago
      Are you confusing "can use" with "requires"?
      - digi_owl 9y ago
        I suspect any alternative is a fall back that cause as much troubles as it "solves". After all, the principle devs of systemd are all very much in love with dbus (bloody thing require a copy to be started by initramfs even).
      - JdeBP 9y ago
        You are missing the part where the user manual and the systemd new features announcement state that the Desktop Bus API is systemd-resolved's "native, fully-featured API"; and describe the GNU C library NSS API and the DNS APIs as limited functionality APIs, whose avoidance by applications is "strongly recommended" in the case of the latter.
  - talideon 9y ago
    dnsmasq doesn't require dbus though: that's an optional dependency that has to be enabled at compile time.
    - vbernat 9y ago
      To make it work with Network Manager, it needs DBus support. So distributions compile it with DBus support.
      - talideon 9y ago
        Sure, but the key there is NetworkManager. dnsmasq itself doesn't require DBus.
      - digi_owl 9y ago
        So eliminate Network Mangler, two problems with one stone...
      - detaro 9y ago
        How does systemd-resolved work with NM? If the goal in general is to have a non-dbus version when NM isn't used, then provide both versions as packages.
  - feld 9y ago
    DNSSEC is dead and useless unless every application is written to understand the error messages and every device runs its own DNS resolver (not forwarding, because it's not really validating then and the responses could be spoofed). We don't need DNSSEC because it doesn't solve any existing problems. The validation is done at the application protocol level with TLS, and apps that aren't running TLS need to fix this gap. So as it turns out DNSCrypt is winning the internet even though the standards bodies blocked it. Additionally, OpenDNS has massive deployment of DNSCrypt users and this is being furthered by Cisco Umbrella. Cisco is adding this capability to iPhones now as announced earlier this week. tl;dr DNSSEC has always been DOA, but DNSCrypt is just getting started. The one and only application I knew of that added DNSSEC for DANE removed it because it was worthless (irssi, irc client).
- setq 9y ago
  Indeed. It's not just init, it's Windows service manager, COM, MSMQ, task scheduler and event log and all the associated problems in one convenient package for Linux!
  - talideon 9y ago
    Not just that, but it's both a floor polish and a dessert topping!
- interestingemu 9y ago
  > I believe systemd-resolved, however, is one of those components that is entirely optional, and which nothing explicitly depends on... Yet. Wouldn't be the first time some "optional" component became mandatory.
  - icebraining 9y ago
    Which optional systemd components became mandatory?
    - dijit 9y ago
      Journald
      - icebraining 9y ago
        When was journald optional?
        dijit 9y ago
        When systemd first landed in Fedora 16. You could use syslog or journald (or both. But journald was optional)
        icebraining 9y ago
        Journald didn't even exist when Fedora 16 was released, so how could it be optional? Meanwhile, from the first public document of journald[1], it was always designed as an indispensable component of systemd. [1] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...
        dijit 9y ago
        I have strong memories of installing it on fedora 16 long before the 17 release was announced. I don't know about intent but I was a very avid fedora user and I was pro-journald before it was forced down my throat.

s_kilk 9y ago

> "why the fuck are you reimplementing DNS in init" Because systemd

vertex-four 9y ago

systemd is not "just" init, it's a suite of various tools, most of which (including systemd-resolved) don't run as PID 1. It's a monolith by the fact that this project decided to take over a variety of normal system daemons and make it as difficult as possible to use many of them without using the rest - it's not a monolith in the sense of everything running in the same process. I believe systemd-resolved, however, is one of those components that is entirely optional, and which nothing explicitly depends on... which makes it weird that Ubuntu chose to use it by default.

icebraining 9y ago
Ubuntu already had a resolver installed by default on desktops (dnsmasq). They decided to switch because: we picked "resolved" as that is small and lightweight, already present (part of the systemd package), does not require D-Bus (unlike dnsmasq), supports DNSSEC, provides transparent fallback to contacting the real DNS servers directly (in case anything goes wrong with the local resolver), and avoids the first issue above that /etc/resolv.conf always shows 127.0.0.1.
- digi_owl 9y ago
  Do not require dbus?! https://www.freedesktop.org/wiki/Software/systemd/resolved/ https://www.freedesktop.org/wiki/Software/systemd/resolved/
  - icebraining 9y ago
    Are you confusing "can use" with "requires"?
    - digi_owl 9y ago
      I suspect any alternative is a fall back that cause as much troubles as it "solves". After all, the principle devs of systemd are all very much in love with dbus (bloody thing require a copy to be started by initramfs even).
    - JdeBP 9y ago
      You are missing the part where the user manual and the systemd new features announcement state that the Desktop Bus API is systemd-resolved's "native, fully-featured API"; and describe the GNU C library NSS API and the DNS APIs as limited functionality APIs, whose avoidance by applications is "strongly recommended" in the case of the latter.
- talideon 9y ago
  dnsmasq doesn't require dbus though: that's an optional dependency that has to be enabled at compile time.
  - vbernat 9y ago
    To make it work with Network Manager, it needs DBus support. So distributions compile it with DBus support.
    - talideon 9y ago
      Sure, but the key there is NetworkManager. dnsmasq itself doesn't require DBus.
    - digi_owl 9y ago
      So eliminate Network Mangler, two problems with one stone...
    - detaro 9y ago
      How does systemd-resolved work with NM? If the goal in general is to have a non-dbus version when NM isn't used, then provide both versions as packages.
- feld 9y ago
  DNSSEC is dead and useless unless every application is written to understand the error messages and every device runs its own DNS resolver (not forwarding, because it's not really validating then and the responses could be spoofed). We don't need DNSSEC because it doesn't solve any existing problems. The validation is done at the application protocol level with TLS, and apps that aren't running TLS need to fix this gap. So as it turns out DNSCrypt is winning the internet even though the standards bodies blocked it. Additionally, OpenDNS has massive deployment of DNSCrypt users and this is being furthered by Cisco Umbrella. Cisco is adding this capability to iPhones now as announced earlier this week. tl;dr DNSSEC has always been DOA, but DNSCrypt is just getting started. The one and only application I knew of that added DNSSEC for DANE removed it because it was worthless (irssi, irc client).
setq 9y ago
Indeed. It's not just init, it's Windows service manager, COM, MSMQ, task scheduler and event log and all the associated problems in one convenient package for Linux!
- talideon 9y ago
  Not just that, but it's both a floor polish and a dessert topping!
interestingemu 9y ago
> I believe systemd-resolved, however, is one of those components that is entirely optional, and which nothing explicitly depends on... Yet. Wouldn't be the first time some "optional" component became mandatory.
- icebraining 9y ago
  Which optional systemd components became mandatory?
  - dijit 9y ago
    Journald
    - icebraining 9y ago
      When was journald optional?
      - dijit 9y ago
        When systemd first landed in Fedora 16. You could use syslog or journald (or both. But journald was optional)
        icebraining 9y ago
        Journald didn't even exist when Fedora 16 was released, so how could it be optional? Meanwhile, from the first public document of journald[1], it was always designed as an indispensable component of systemd. [1] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...
        dijit 9y ago
        I have strong memories of installing it on fedora 16 long before the 17 release was announced. I don't know about intent but I was a very avid fedora user and I was pro-journald before it was forced down my throat.