[HN Gopher] Resolvd(8) - daemon to handle nameserver configuration
___________________________________________________________________
Resolvd(8) - daemon to handle nameserver configuration
Author : protomyth
Score : 35 points
Date : 2021-02-26 15:55 UTC (7 hours ago)
(HTM) web link (undeadly.org)
(TXT) w3m dump (undeadly.org)
| midasuni wrote:
| 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.
| gbrown_ wrote:
| 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
| eqvinox wrote:
| 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?
| cperciva wrote:
| _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 wrote:
| I also use it on gentoo and works great.
| rnhmjoj wrote:
| 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.
| pxeboot wrote:
| Having a static resolv.conf file can/does lead to many issues
| when connecting to multiple networks or a VPN with different
| dns servers.
| _jal wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| 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.
| asveikau wrote:
| 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 wrote:
| 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 wrote:
| 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.
| cat199 wrote:
| 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 wrote:
| Sockets allow for more robust serialization than argv.
| eqvinox wrote:
| 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 wrote:
| Calling exec() in fact requires more privileges than
| holding a socket open.
___________________________________________________________________
(page generated 2021-02-26 23:02 UTC)