3 ms·

systemd-resolved and dnsmasq are the only two clients that can properly route DNS queries via the proper interface to their respective authoritative server base

systemd-resolved and dnsmasq are the only two clients that can properly route DNS queries via the proper interface to their respective authoritative server based on the resolved hostname itself. It would be hard to argue, that systemd-resolved is worse/more-limited/more error prone/buggy than dnsmasq. The socket activation is intended for services, that are not normally needed, but occasionally they might be. It doesn't apply much to servers serving well-defined services, but for desktop, it is a godsend (together with dbus-activation). Just because you don't have use for it for your use cases doesn't mean it is not useful for other people.

ahartmetz 6y ago
Well. This http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html sells socket activation as the best thing since sliced bread, including for boot time. It has its uses for some rarely used services and for some startup order problems, yes. About the DNS service, I remember a bug where the fallback behavior was not what people wanted (it was something that seemed to be a good idea to systemd developers but didn't work well in completely reasonable real-world configurations), and the developers rejected the idea that systemd's behavior was wrong. Can't find it right now. I have disabled it on my system as well due to a problem I don't remember. Maybe it didn't use my router's DNS server and went straight to the internet. Maybe I just wanted it to leave my resolv.conf alone.
- vetinari 6y ago
  > About the DNS service, I remember a bug where the fallback behavior was not what people wanted (it was something that seemed to be a good idea to systemd developers but didn't work well in completely reasonable real-world configurations), and the developers rejected the idea that systemd's behavior was wrong. It was a fallback DNS used when the user has configured nothing. Not only that, it was a default fallback that can be changed by both the distribution package and the user (including disabling completely). It was a tempest in the teapot, by people who have to find some drama.
  - ahartmetz 6y ago
    I think I remember what it was now. Local configuration (DHCP?) contained two DNS servers. systemd-resolved switched to the global fallback when it tried one of the local servers and it failed, instead of falling back to the other local server first. It's a completely reasonable configuration to have two local servers for redundancy as well as load balancing, and systemd-resolved broke the redundancy aspect. It was not about a "wrong" global fallback, but about using it when a local alternative still works. It breaks local network name resolution.
    - vetinari 6y ago
      If it behaved like that, yes, it is a bug that needs to be fixed. I don't remember that (not saying that it didn't happen, after a quick search I didn't find any filed issue, #18769 could in theory have similar symptoms), but I remember several threads, including LWN article about the existence of the global fallback.
      - mst 6y ago
        It can both be true that there are a bunch of annoying things about systemd and their response to genuine bugs sometimes leave something to be desired, and that there's a lot of hate for the sake of hate directed at it. This, naturally, just makes everything harder to have a sensible conversation about.
    - totony 6y ago
      What you may be referring to is systemd treating resolv.conf entries as identical DNS servers, where they used to be processed sequentially. Previous discussion: https://news.ycombinator.com/item?id=15228940 https://news.ycombinator.com/item?id=15228940 It's a breaking change for some users. I remember experiencing that bug.
cout 6y ago
> It would be hard to argue, that systemd-resolved is worse/more-limited/more error prone/buggy than dnsmasq. I'll take up that argument. On Ubuntu 14.04 (and I think also 16.04), systemd-resolved used to crash on my desktop machine after about a week of uptime. I never figured out the reason; I got in the habit of manually pointing `/etc/resolv.conf` at a real server whenever it happened. I don't remember ever having that problem with dnsmasq, but I've seen so many DNS proxy things over the years that I can't keep them all straight. I think it's probably fair to compare systemd-resolved and nscd; both were there by default doing something with DNS, and both crashed often enough to annoy me. It's not a new problem, either. I remember whatever came with RedHat or Mandrake or whatever I was running circa 2001 also seemed to stop working after a while. I ended up writing my own DNS proxy in C++ and ended up learning a lot. The protocol is wildly different enough from almost any other common protocol that I'm not surprised when software gets it wrong (I sure did!). The takeaway for me is that designing a protocol is as much a human problem as it is a technical one.
nijave 6y ago
Yup, not-too-long-ago we setup OpenVPN at work with split tunneling which required DNS to work correctly. Windows worked out of the box (except for a small pool of users who had their DNS manually set which was a checkbox fix). macOS was more irritating because OpenVPN didn't native support the DNS API and it turned out the defacto way was Tunnelblick third party software. Linux... Absolute nightmare. Every system had a slightly different DNS stack and trying to get queries to route over the VPN interface was an acrobatic exercise in docs navigation and trial and error. Ultimately, newer desktops with systemd-resolved were the easiest systemd-resolved supporting DNSSEC is also a big win!

ahartmetz 6y ago

Well. This http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html sells socket activation as the best thing since sliced bread, including for boot time. It has its uses for some rarely used services and for some startup order problems, yes. About the DNS service, I remember a bug where the fallback behavior was not what people wanted (it was something that seemed to be a good idea to systemd developers but didn't work well in completely reasonable real-world configurations), and the developers rejected the idea that systemd's behavior was wrong. Can't find it right now. I have disabled it on my system as well due to a problem I don't remember. Maybe it didn't use my router's DNS server and went straight to the internet. Maybe I just wanted it to leave my resolv.conf alone.

vetinari 6y ago
> About the DNS service, I remember a bug where the fallback behavior was not what people wanted (it was something that seemed to be a good idea to systemd developers but didn't work well in completely reasonable real-world configurations), and the developers rejected the idea that systemd's behavior was wrong. It was a fallback DNS used when the user has configured nothing. Not only that, it was a default fallback that can be changed by both the distribution package and the user (including disabling completely). It was a tempest in the teapot, by people who have to find some drama.
- ahartmetz 6y ago
  I think I remember what it was now. Local configuration (DHCP?) contained two DNS servers. systemd-resolved switched to the global fallback when it tried one of the local servers and it failed, instead of falling back to the other local server first. It's a completely reasonable configuration to have two local servers for redundancy as well as load balancing, and systemd-resolved broke the redundancy aspect. It was not about a "wrong" global fallback, but about using it when a local alternative still works. It breaks local network name resolution.
  - vetinari 6y ago
    If it behaved like that, yes, it is a bug that needs to be fixed. I don't remember that (not saying that it didn't happen, after a quick search I didn't find any filed issue, #18769 could in theory have similar symptoms), but I remember several threads, including LWN article about the existence of the global fallback.
    - mst 6y ago
      It can both be true that there are a bunch of annoying things about systemd and their response to genuine bugs sometimes leave something to be desired, and that there's a lot of hate for the sake of hate directed at it. This, naturally, just makes everything harder to have a sensible conversation about.
  - totony 6y ago
    What you may be referring to is systemd treating resolv.conf entries as identical DNS servers, where they used to be processed sequentially. Previous discussion: https://news.ycombinator.com/item?id=15228940 https://news.ycombinator.com/item?id=15228940 It's a breaking change for some users. I remember experiencing that bug.

cout 6y ago

> It would be hard to argue, that systemd-resolved is worse/more-limited/more error prone/buggy than dnsmasq. I'll take up that argument. On Ubuntu 14.04 (and I think also 16.04), systemd-resolved used to crash on my desktop machine after about a week of uptime. I never figured out the reason; I got in the habit of manually pointing `/etc/resolv.conf` at a real server whenever it happened. I don't remember ever having that problem with dnsmasq, but I've seen so many DNS proxy things over the years that I can't keep them all straight. I think it's probably fair to compare systemd-resolved and nscd; both were there by default doing something with DNS, and both crashed often enough to annoy me. It's not a new problem, either. I remember whatever came with RedHat or Mandrake or whatever I was running circa 2001 also seemed to stop working after a while. I ended up writing my own DNS proxy in C++ and ended up learning a lot. The protocol is wildly different enough from almost any other common protocol that I'm not surprised when software gets it wrong (I sure did!). The takeaway for me is that designing a protocol is as much a human problem as it is a technical one.

nijave 6y ago

Yup, not-too-long-ago we setup OpenVPN at work with split tunneling which required DNS to work correctly. Windows worked out of the box (except for a small pool of users who had their DNS manually set which was a checkbox fix). macOS was more irritating because OpenVPN didn't native support the DNS API and it turned out the defacto way was Tunnelblick third party software. Linux... Absolute nightmare. Every system had a slightly different DNS stack and trying to get queries to route over the VPN interface was an acrobatic exercise in docs navigation and trial and error. Ultimately, newer desktops with systemd-resolved were the easiest systemd-resolved supporting DNSSEC is also a big win!