10 ms·

Resolvd(8) – daemon to handle nameserver configuration

40 points by protomyth 6y ago

eqvinox 6y ago
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?
- pxeboot 6y ago
  Having a static resolv.conf file can/does lead to many issues when connecting to multiple networks or a VPN with different dns servers.
  - dsr_ 6y ago
    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.
    - vetinari 6y ago
      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.
      - dsr_ 6y ago
        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.
        vetinari 6y ago
        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.
  - _jal 6y ago
    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?
    - stonogo 6y ago
      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.
      - _jal 6y ago
        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.
        stonogo 6y ago
        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.
    - rleigh 6y ago
      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.
- cperciva 6y ago
  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.
  - folmar 6y ago
    I also use it on gentoo and works great.
    - rnhmjoj 6y ago
      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.
- asveikau 6y ago
  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.
  - eqvinox 6y ago
    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.
    - chousuke 6y ago
      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.
      - asveikau 6y ago
        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.
    - asveikau 6y ago
      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.
- cat199 6y ago
  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 :)
- tedunangst 6y ago
  Sockets allow for more robust serialization than argv.
  - eqvinox 6y ago
    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.
    - tedunangst 6y ago
      Calling exec() in fact requires more privileges than holding a socket open.
gbrown_ 6y ago
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 https://marc.info/?l=openbsd-cvs&m=161435621007396&w=2
midasuni 6y ago
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.
- Joyfield 6y ago
  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.

40 points by protomyth 6y ago

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?

pxeboot 6y ago
Having a static resolv.conf file can/does lead to many issues when connecting to multiple networks or a VPN with different dns servers.
- dsr_ 6y ago
  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.
  - vetinari 6y ago
    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.
    - dsr_ 6y ago
      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.
      - vetinari 6y ago
        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.
- _jal 6y ago
  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?
  - stonogo 6y ago
    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.
    - _jal 6y ago
      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.
      - stonogo 6y ago
        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.
  - rleigh 6y ago
    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.
cperciva 6y ago
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.
- folmar 6y ago
  I also use it on gentoo and works great.
  - rnhmjoj 6y ago
    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.
asveikau 6y ago
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.
- eqvinox 6y ago
  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.
  - chousuke 6y ago
    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.
    - asveikau 6y ago
      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.
  - asveikau 6y ago
    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.
cat199 6y ago
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 :)
tedunangst 6y ago
Sockets allow for more robust serialization than argv.
- eqvinox 6y ago
  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.
  - tedunangst 6y ago
    Calling exec() in fact requires more privileges than holding a socket open.

gbrown_ 6y ago

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 https://marc.info/?l=openbsd-cvs&m=161435621007396&w=2

midasuni 6y ago

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.

Joyfield 6y ago
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.