7 ms·

> First release of unwind(8), a validating, recursive nameserver for 127.0.0.1. It is particularly suitable for laptops moving between networks. When systemd-r

> First release of unwind(8), a validating, recursive nameserver for 127.0.0.1. It is particularly suitable for laptops moving between networks. When systemd-resolvd was first released it was the biggest mistake ever to write a new recursive resolver instead of using unbound or dnsmasq. Also since DNS ".. wasn't broken, so it did not need fixing". I wonder if unwind will be received with the same hostility.

snazz 8y ago
Seems to be well-received: https://undeadly.org/cgi?action=article;sid=20190128061321 https://undeadly.org/cgi?action=article;sid=20190128061321
moviuro 8y ago
See https://man.openbsd.org/unwind.8 https://man.openbsd.org/unwind.8 And also in general, I'm far less concerned about software released by a well-established security-minded team than I am about whatever Lennart wants to ship...
- busterarm 8y ago
  literally, "whatever Lennart wants to ship"
  - fmajid 8y ago
    s/p/t/g
mises 8y ago
People are probably less upset because it doesn't take the "systemd all the things" approach of getting rid of huge chunks of old stuff for what is ostensibly an init system. I don't have much of an issue with systemd (except binary logging; I hate that) and just put up with it, but the reasons for which people objected to systemd don't seem to extend to this.
- Spivak 8y ago
  The only connection that systemd-resolved has to the init system is the name prefix. Seems odd to praise the BSDs for developing everything in a single repo but faulting systemd for the same approach.
  - yarrel 8y ago
    The BSDs are operating systems. SystemD hasn't yet admitted that it is.
    - chousuke 8y ago
      Hasn't admitted? As far as I know, it is an explicitly stated goal of the systemd project to provide an integrated (compared to whatever each distribution assembled together to provide one) base system on top of the Linux kernel with the intent of making the best use of the features provided by the kernel. It seems to me that Lennart looked at the tightly integrated base system + kernel approach of the BSDs and decided he wanted that for Linux too (in addition to whatever other influences he had), and then he made it happen.
      - brohee 8y ago
        Except it's not tightly integrated on OpenBSD, and that you can replace any component for any reason without the whole thing collapsing.
        genghizkhan 8y ago
        Fwiw, apart from journald and logind that’s true for systemd as well. You can choose to run nothing other than pid 1 and these two daemons. Everything else is optional.
      - _emacsomancer_ 8y ago
        My understanding is that he was influenced in part by launchd.
Hello71 8y ago
> new recursive resolver instead of using unbound or dnsmasq systemd-resolved is a non-recursive resolver. so is dnsmasq.
- floatboth 8y ago
  What's the correct word for "something local that talks to 8.8.8.8/whatever and caches responses" if not recursive? Forwarding?
  - toast0 8y ago
    That's a stub resolver.
  - JdeBP 8y ago
    Forwarding, yes. This terminology is tricky, and the fact that toast0 incorrectly thinks that this is a "stub resolver" is indicative of how people get this stuff wildly wrong. A "stub resolver" is in fact the client that makes requests of the server that you are asking about. I use terminology borrowed from HTTP when explaining this to people. A DNS server that listens on a local IP address and makes back-end queries to another DNS server is a proxy DNS server, and the fact that it hands off all of the grunt work (of stitching together the back-end partial answers to make the front-end complete answers) to another proxy DNS server makes it a forwarding proxy DNS server. If it didn't hand off the grunt work and did all of the query resolution itself, talking directly to content DNS servers, it would be a resolving proxy DNS server. And the software that is in applications, that formulates requests and sends them over to a proxy DNS server, is a DNS client library. 8.8.8.8 is a resolving proxy. * http://jdebp.eu./FGA/dns-server-roles.html http://jdebp.eu./FGA/dns-server-roles.html * http://jdebp.eu./FGA/dns-query-resolution.html http://jdebp.eu./FGA/dns-query-resolution.html * https://unix.stackexchange.com/a/500565/5132 https://unix.stackexchange.com/a/500565/5132
  - AndyMcConachie 8y ago
    Stub resolver: A resolver that cannot perform all resolution itself. Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function. Stub resolvers are discussed but never fully defined in Section 5.3.1 of [RFC1034]. They are fully defined in Section 6.1.3.1 of [RFC1123]. https://tools.ietf.org/html/rfc8499 https://tools.ietf.org/html/rfc8499
asveikau 8y ago
OpenBSD has done a few of these daemons over the years, where they reject existing popular implementations to do their own with their own priorties. I started typing a list but really there are too many, big and small. They tend to have the OpenBSD minimalist, security focused, "no bullshit" approach. It's not very much like systemd.
- kbenson 8y ago
  In a way, OpenBSD isn't really written in C. It's written in a special subset of C that uses some different, more secure core functions and any where any trade-off for performance instead of security is ruthlessly weeded out when reviewed by the people involved. I'm of the opinion that using C and C++ for future major work where there's not good reasons forcing you to is more trouble than it's worth, but I wouldn't mind if it was all done with the care and attention the OpenBSD developers put into their projects.
  - tptacek 8y ago
    While I'm generally sold on the OpenBSD strategy of replacing mainstream daemons with stripped down secure versions, I don't think it is at all reasonable to suggest that OpenBSD's library idioms mean it's implemented in something other than C (nor would it be reasonable to say that about Dan Bernstein's software, which goes even further in this direction). It's still C, and it still has memory corruption vulnerabilities.
    - kbenson 8y ago
      Sure. I just meant that since they adopt and enforce the usage of secure equivalents to some common functions (e.g. some string utilities), and along with very strictly enforced rules about how code gets accepted, it's about the best we can expect in some situations. Not everyone is willing to consider using something other than C. I think the pragmatic approach is to point to C projects that have been largely successful in their security approach. If it causes them to adopt the onerous requirements for safe C, or to reevaluate their position, I count those both as positive outcomes.
wahern 8y ago
unwind uses libunbound, so it's basically just a different front-end. See https://cvsweb.openbsd.org/src/sbin/unwind/ https://cvsweb.openbsd.org/src/sbin/unwind/ OpenBSD also still includes Unbound (/usr/sbin/unbound) as the standard local recursive resolver, and NSD (/usr/sbin/nsd) as the standard authoritative server.
toast0 8y ago
The difference is mostly in the track record of the people behind the effort. DNS software in general has left behind a trail of security vulnerabilities. The systemd team has also left behind a trail of security vulnerabilities. I don't want a team who isn't focused on security to replace something security critical when the existing software seemed fine enough. On the other hand, the OpenBSD team consistently delivers on small, focused utilities, built with security in mind that usually reduce the scope of the utility to the minimum required.
admax88q 8y ago
OpenBSD and its associated daemons is fairly well engineered. Systemd is not.

snazz 8y ago

Seems to be well-received: https://undeadly.org/cgi?action=article;sid=20190128061321 https://undeadly.org/cgi?action=article;sid=20190128061321

moviuro 8y ago

See https://man.openbsd.org/unwind.8 https://man.openbsd.org/unwind.8 And also in general, I'm far less concerned about software released by a well-established security-minded team than I am about whatever Lennart wants to ship...

busterarm 8y ago
literally, "whatever Lennart wants to ship"
- fmajid 8y ago
  s/p/t/g

mises 8y ago

People are probably less upset because it doesn't take the "systemd all the things" approach of getting rid of huge chunks of old stuff for what is ostensibly an init system. I don't have much of an issue with systemd (except binary logging; I hate that) and just put up with it, but the reasons for which people objected to systemd don't seem to extend to this.

Spivak 8y ago
The only connection that systemd-resolved has to the init system is the name prefix. Seems odd to praise the BSDs for developing everything in a single repo but faulting systemd for the same approach.
- yarrel 8y ago
  The BSDs are operating systems. SystemD hasn't yet admitted that it is.
  - chousuke 8y ago
    Hasn't admitted? As far as I know, it is an explicitly stated goal of the systemd project to provide an integrated (compared to whatever each distribution assembled together to provide one) base system on top of the Linux kernel with the intent of making the best use of the features provided by the kernel. It seems to me that Lennart looked at the tightly integrated base system + kernel approach of the BSDs and decided he wanted that for Linux too (in addition to whatever other influences he had), and then he made it happen.
    - brohee 8y ago
      Except it's not tightly integrated on OpenBSD, and that you can replace any component for any reason without the whole thing collapsing.
      - genghizkhan 8y ago
        Fwiw, apart from journald and logind that’s true for systemd as well. You can choose to run nothing other than pid 1 and these two daemons. Everything else is optional.
    - _emacsomancer_ 8y ago
      My understanding is that he was influenced in part by launchd.

Hello71 8y ago

> new recursive resolver instead of using unbound or dnsmasq systemd-resolved is a non-recursive resolver. so is dnsmasq.

floatboth 8y ago
What's the correct word for "something local that talks to 8.8.8.8/whatever and caches responses" if not recursive? Forwarding?
- toast0 8y ago
  That's a stub resolver.
- JdeBP 8y ago
  Forwarding, yes. This terminology is tricky, and the fact that toast0 incorrectly thinks that this is a "stub resolver" is indicative of how people get this stuff wildly wrong. A "stub resolver" is in fact the client that makes requests of the server that you are asking about. I use terminology borrowed from HTTP when explaining this to people. A DNS server that listens on a local IP address and makes back-end queries to another DNS server is a proxy DNS server, and the fact that it hands off all of the grunt work (of stitching together the back-end partial answers to make the front-end complete answers) to another proxy DNS server makes it a forwarding proxy DNS server. If it didn't hand off the grunt work and did all of the query resolution itself, talking directly to content DNS servers, it would be a resolving proxy DNS server. And the software that is in applications, that formulates requests and sends them over to a proxy DNS server, is a DNS client library. 8.8.8.8 is a resolving proxy. * http://jdebp.eu./FGA/dns-server-roles.html http://jdebp.eu./FGA/dns-server-roles.html * http://jdebp.eu./FGA/dns-query-resolution.html http://jdebp.eu./FGA/dns-query-resolution.html * https://unix.stackexchange.com/a/500565/5132 https://unix.stackexchange.com/a/500565/5132
- AndyMcConachie 8y ago
  Stub resolver: A resolver that cannot perform all resolution itself. Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function. Stub resolvers are discussed but never fully defined in Section 5.3.1 of [RFC1034]. They are fully defined in Section 6.1.3.1 of [RFC1123]. https://tools.ietf.org/html/rfc8499 https://tools.ietf.org/html/rfc8499

asveikau 8y ago

OpenBSD has done a few of these daemons over the years, where they reject existing popular implementations to do their own with their own priorties. I started typing a list but really there are too many, big and small. They tend to have the OpenBSD minimalist, security focused, "no bullshit" approach. It's not very much like systemd.

kbenson 8y ago
In a way, OpenBSD isn't really written in C. It's written in a special subset of C that uses some different, more secure core functions and any where any trade-off for performance instead of security is ruthlessly weeded out when reviewed by the people involved. I'm of the opinion that using C and C++ for future major work where there's not good reasons forcing you to is more trouble than it's worth, but I wouldn't mind if it was all done with the care and attention the OpenBSD developers put into their projects.
- tptacek 8y ago
  While I'm generally sold on the OpenBSD strategy of replacing mainstream daemons with stripped down secure versions, I don't think it is at all reasonable to suggest that OpenBSD's library idioms mean it's implemented in something other than C (nor would it be reasonable to say that about Dan Bernstein's software, which goes even further in this direction). It's still C, and it still has memory corruption vulnerabilities.
  - kbenson 8y ago
    Sure. I just meant that since they adopt and enforce the usage of secure equivalents to some common functions (e.g. some string utilities), and along with very strictly enforced rules about how code gets accepted, it's about the best we can expect in some situations. Not everyone is willing to consider using something other than C. I think the pragmatic approach is to point to C projects that have been largely successful in their security approach. If it causes them to adopt the onerous requirements for safe C, or to reevaluate their position, I count those both as positive outcomes.

wahern 8y ago

unwind uses libunbound, so it's basically just a different front-end. See https://cvsweb.openbsd.org/src/sbin/unwind/ https://cvsweb.openbsd.org/src/sbin/unwind/ OpenBSD also still includes Unbound (/usr/sbin/unbound) as the standard local recursive resolver, and NSD (/usr/sbin/nsd) as the standard authoritative server.

toast0 8y ago

The difference is mostly in the track record of the people behind the effort. DNS software in general has left behind a trail of security vulnerabilities. The systemd team has also left behind a trail of security vulnerabilities. I don't want a team who isn't focused on security to replace something security critical when the existing software seemed fine enough. On the other hand, the OpenBSD team consistently delivers on small, focused utilities, built with security in mind that usually reduce the scope of the utility to the minimum required.

admax88q 8y ago

OpenBSD and its associated daemons is fairly well engineered. Systemd is not.