3 ms·

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.

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.