[justinsaccount]

> 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.

[asveikau]

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]

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]

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]

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.

[makz]

As far as I have seen, every time a project uses C, they end up transforming it in some subset and if you want to contribute, you must learn that C subset. It’s almost like DSLs.

I think that’s expected, and cool, given that C is a general purpose language and very flexible.

[nickpsecurity]

It's C with better libraries and coding standards for security. A different dialect might be something like Cyclone, Cilk, MetaC, Frama-C, or ZL that change the language to help them achieve their goals.

[wahern]

unwind uses libunbound, so it's a little different then some of their other greenfield projects. (See my post elsethread.) Like with OpenSSL/libressl they're not reinventing the wheel so much as just inventing a new kind of vehicle to place atop the wheels.

[moviuro]

See 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]

literally, "whatever Lennart wants to ship"

[fmajid]

s/p/t/g

[toast0]

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.

[wahern]

unwind uses libunbound, so it's basically just a different front-end. See 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.

[snazz]

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

[mises]

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]

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.

[throw0101a]

> Seems odd to praise the BSDs for developing everything in a single repo but faulting systemd for the same approach.

I think it is more accurate to say that the (supposed) problem with systemd's approach is actually tight coupling as opposed to a single repo.

OpenSSH, OpenSMTP, OpenBGPD, LibreSSL, Mandoc, the recent Unwind, etc, may all be in the same repo, but none depending on each other. Try taking systemd-resolved (or journald) and running it on its own.

If the various systemd "components" were actual components that could be swapped out for something else there would be fewer complains IMHO.

systemd-as-init-replacement is/was fine. systemd-as-kitchen-sink is where things went sideways.

[CameronNemo]

Chrome OS runs systemd-journald on top of Upstart. Not that such a setup is supported or encouraged.

One of my main gripes about resolved is the D-Bus interface. Lennart needs to remove his lips from that protocol's ass.

[Spivak]

> Lennart needs to

And replace it with what? I genuinely don't know anything that exists right now that could replace it. Linux and ecosystem have a lot of IPC primitives but very few usable systems: I know of dbus and ip.

[mises]

I didn't praise them for that. It's more that I don't like the systemd way of making everything systemd. The difference is that the stuff openbsd develops is largely standalone applications, whereas systemd wants to take over the world and replace everything.

This makes it very hard to tweak a system, and I would again bring up the logging issue. Systemd-journald stores files in binary format, which is a pain. I was working on something where I accidentally bricked the system (VM, thankfully) due to configuring some in-depth security stuff. I mounted the disk and tried to read off the log, but couldn't. It's also a pain to replace it, and non-systemd alternatives are becoming increasingly poorly supported.

Systemd wants to take over temporary files, journaling, and much, much more. Many of the implementations are imperfect. That's fine; I understand it's hard to get that much right. Which is why I wish they made it easier to replace systemd components or didn't use it.

The init itself (units etc.) is good, and I actually like it. I just wish they got that polished, then made another, separate project if they thought they could do another piece better.

[Spivak]

> I mounted the disk and tried to read off the log, but couldn't.

I mean yes, you need something to parse the logs and turn them into human readable text, but the logs are perfectly readable.

journalctl --file /mnt/var/log/journal/`</mnt/etc/machine-id`/system.journal | my-favorite-log-reader

A lot, dare I say most, of the parts of systemd actually are optional or do nothing until you use them like systemd-machined.

[structural]

The assumption here is that the machine you're using to do the log analysis is also a Linux machine that uses systemd (and thus has a journalctl binary). This is not necessarily true.

A lot of the annoyance that some people have with the systemd crowd is that these kind of assumptions are made all over the place. The actual software is not bad (I really do prefer dealing with systemd units than writing shell scripts for each service) but it can be hard to get past.

[mises]

Exactly. I was doing a competition that required me to run windows with a linux vm on top of it. This means I couldn't easily do it. Ended up having to use WSL, which is much more hassle than I ought to have to go through.

I agree as well with the unit comment; they're great. But I just can't get past the plans for world domination.

[viraptor]

I'm not sure I see the problem. At scale, you're logging into an aggregator anyway. If part of your job is log recovery/analysis then you need to get the right tools working (docker works almost everywhere now, so that should solve it). In a small environment, I'm you can find a way to run a VM somewhere temporarily.

[yarrel]

The BSDs are operating systems. SystemD hasn't yet admitted that it is.

[chousuke]

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]

Except it's not tightly integrated on OpenBSD, and that you can replace any component for any reason without the whole thing collapsing.

[genghizkhan]

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_]

My understanding is that he was influenced in part by launchd.

[Hello71]

> new recursive resolver instead of using unbound or dnsmasq

systemd-resolved is a non-recursive resolver. so is dnsmasq.

[floatboth]

What's the correct word for "something local that talks to 8.8.8.8/whatever and caches responses" if not recursive? Forwarding?

[JdeBP]

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-query-resolution.html

* https://unix.stackexchange.com/a/500565/5132

[AndyMcConachie]

   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

[toast0]

That's a stub resolver.

[admax88q]

OpenBSD and its associated daemons is fairly well engineered.

Systemd is not.