Resolvd(8) – daemon to handle nameserver configuration | Hacker News Reader

Resolvd(8) – daemon to handle nameserver configuration

undeadly.org

40 pointsprotomyth26 comments

In the olden days I could rely on looking at resolv.conf to see my dns settings and servers.

Then systemd came along and broke it (on linux), driving my hatred of that environment up another notch (see also things like ntp, syslog)

I hope BSD doesn’t follow the same path.

On Ubuntu it is a yearly thing googling how to change DNS settings. There is always another level where the file pointing saying to not change the file and then pointing to the next file that does not should be edited.

I like undeadly and OpenBSD in general but this "reporting" feels a little premature as dhcpleased(8) has just shown up too. It seems these daemons are being introduced as part of a larger co-ordinated design change. I imagine clarification about the motivation behind these changes will appear in the near future (before the 6.9 release).

[1] https://marc.info/?l=openbsd-cvs&m=161435621007396&w=2

The reason this is a daemon is ... because a process started from dhclient/slaacd/unwind couldn't directly write to /etc/resolv.conf?

I mean, resolv.conf is only going to change based on some event happening in one of these other daemons (or user input), so this could just as well be an executable that is started to handle that event? Am I missing something?

Having a static resolv.conf file can/does lead to many issues when connecting to multiple networks or a VPN with different dns servers.

Imagine how awful it would be if services that wanted to change your DNS resolution had to place stanzas in, say, /etc/resolv.conf.d/ -- and even registered parts of the tree that they wanted to be responsible for, with most specific winning?

Oh, wait, that would be pretty useful, and avoid having a daemon running all the time. And be easier to debug.

Most solutions for split DNS use daemons (including dns client in windows, macos resolver, systemd-resolved or dnsmasq), because they look at the name being resolved and then forward that query to the right DNS server via the right interface (the VPN DNS might depend on whether the interface is up, after all).

Similarly, reading /etc/resolv.conf and doing the resolving in-app will quickly lead to wrong results.

There are n different daemons that can clash over /etc/resolv.conf, or you could put the responsibility on the actual system resolver library routines by extending resolv.conf syntax a little.

This would also solve the network namespace issue.

It is simpler to persuade those few daemons that want to update resolv.conf to do something else (e.g. talk to networkmanager), than to ensure that every program that directly reads resolv.conf is updated for the new syntax.

Programs are not supposed to read resolv.conf and implement their own resolver anyway (due to nss), but many still do.

For machines that never leave their normal network, changing it to reduce the risk of detection is one step in many compromises.

We already use configuration management to do manage resolv.conf; any other method of modification is noncompliant. So this is just more at-best-wasteful cruft to strip out.

More generally, why make this a daemon? There is zero reason for it to be resident other than on network changes. Should we have dedicated daemons for /etc/hosts, ldap.conf, and nsswitch.conf, too? How about inittab?

  We already use configuration management to do manage 
  resolv.conf; any other method of modification is 
  noncompliant.

So don't run resolvd. Problem solved forever.

This exists as daemon because OpenBSD is in the process of rewriting certain parts of their code to have explicit privilege separation. They just committed another one to handle DHCP leases, for example.

And I preemptively agreed with you:

> cruft to strip out

> rewriting certain parts of their code to have explicit privilege separation

I was unaware that this was the goal. If it is, that's a better explanation for changing things than I've heard elsewhere.

Still doesn't explain why it should be a daemon instead of a helper binary.

It's a daemon so it can monitor the routing sockets for messages from dhcp/slaac/etc utilities that send updates. If it were a helper binary it would violate the privsep efforts.

For nsswitch, yes it should be a daemon. The current design maps in all sorts of unrelated (and potentially incompatible) junk into you process' address space. Far cleaner just to query over a socket. Doesn't need to be a system-wide daemon; it could just as easily be fired up on demand within a session (as in setsid) and shared between processes.

this could just as well be an executable that is started to handle that event?

Indeed, that's what FreeBSD does, with resolvconf(8).

The reason this is a daemon is ... because a process started from dhclient/slaacd/unwind couldn't directly write to /etc/resolv.conf?

I would say couldn't or shouldn't:

     resolvconf manages resolv.conf(5) files from multiple sources, such as
     DHCP and VPN clients.  Traditionally, the host runs just one client and
     that updates /etc/resolv.conf.  More modern systems frequently have wired
     and wireless interfaces and there is no guarantee both are on the same
     network.  With the advent of VPN and other types of networking daemons,
     many things now contend for the contents of /etc/resolv.conf.

FreeBSD's resolvconf comes with a configuration file which tells it how to combine instructions from multiple sources.

I also use it on gentoo and works great.

Same here on NixOS. I'm running dhcpcd: on new leases/router adverts it calls resolvconf and updates /etc/resolv.conf accordingly. I don't feel the need for yet another daemon to perform such a simple task.

I think it's a little messy to have each of those independently stomping on resolv.conf. There could be race conditions. There could be duplicated code. There could be no one place to disable these things overwriting a handwritten config.

A central piece of code managing that is therefore a good idea. Could be a library rather than a daemon. But a daemon would be one way to resolve races.

Strikes me that this is all a little bit "on the systemd spectrum" though.

I'm not suggesting each of these stomps on resolv.conf. I'm suggesting the functionality in the daemon is instead in an executable that just doesn't run permanently, it's just started whenever an event happens and does its thing.

A daemon that's listening on a socket is not "running permanently". It'll consume approximately no resources until the kernel wakes it up.

Having a separate daemon also saves you from having to grant the other daemons credentials to edit the file.

I do not think this deserves the downvotes. It's absolutely true that with no activity on the socket, it stays off the CPU, and whatever memory use it has could be paged out if needed.

Right, but as I alluded to, a daemon provides a nice place to synchronize concurrent requests and maybe apply some logic to combine them intelligently. If you had that as an external program you would need a cross process locking scheme and perhaps saving some extra state on disk.

i get the sense (no direct insight other than following overall feature trajectory) that openbsd is going to gradually build up some level of quasi-SDN networking/vm clustering around virtual interfaces, VMM, pf/pfsync/ifstated, etc - if even some of this is correct, long run it probably makes sense to provide some kind of dynamic/api driven component in the system to support more flexible DNS functionality

again, just a hunch, but it helps me make sense of the world :)

Sockets allow for more robust serialization than argv.

While that is certainly true, you could also just serialize over stdin/stdout. Or even have fd 0/1 be a socket you got from socketpair().

A daemon running in the background consumes resources and generally increases attack surface re. security issues - though in this specific case the one-shot executable would admittedly need the same privileges.

Calling exec() in fact requires more privileges than holding a socket open.

Reply on news.ycombinator.com