alt Hacker News> Sure, as long as the solution isn't to just bolt on another distinct DNS monolith
Why not? And I don't mean this in tongue-in-cheek, but as a genuine interrogation: why not go the macOS/systemd route?
DNS is a complex topic. Much more complex than people admit it is, and that can definitely not be expressed fully with resolv.conf. I do agree that it is too late to get rid of it (and was not my concern actually), but it is too limited to be of actual use outside of the simple "I have a single DNS server with a single search domain". IMHO, a dedicated local daemon with its own bespoke config definitely has value, even if it solely provides a local cache for applications that don't have one already (like most of them outside of browsers). And for more complex cases, simple integration with the network configuration daemon provides actual value in e.g. knowing that a specific server is reachable through a specific interface that has a specific search domain. That is, native routing to the correct servers to avoid the timeout dance as soon as you have split networks.
Also, for the local ad-hoc configuration part. We already have nsswitch which is its own can of worms that pretty much nobody have ever heard about let even touched its configuration. Heck, I've written DNS servers but only looked once at nsswitch. resolved's configuration is integrated in the systemd ecosystem, has an approachable and well documented configuration, and is pretty useful in general.
Anyways, the main gripe I had was not really at the mess that is DNS on Linux, but the general stance in the UNIX-like world against anything that's not a lego of shell scripts because "that's not the unix philosophy". Yeah you can write an init system fully with sh, have their "units" also all be written in sh, but oh lord has stuff like systemd improved the situation for the init + service part. Having a raw string from a network packet land in a shell script is a recipe for disaster, seeing how much quoting in scripts is famously difficult.
> The problem with the new, alternative monoliths is they very quickly run off into the weeds with their crazy features and configuration
Agreed for the crazy features. systemd is a godsend for the modern linux world, but I'm skeptical when I see the likes of systemd-home. Yet the configuration is not where I'd pick at those systems though, because they tend to be much more configurable. They are opiniated, yes, but the configuration is an actual configuration and not a patchwork of shell scripts somewhere in /etc, when they're not direct patches to the foundational shell scripts!
> in ways that create barriers for userland applications
How so? In the specific example of resolved, I'd argue it's even less work for applications, because they don't need to query multiple DNS servers at once (it'll handle it for them), don't need to try resolution with and without search domain, etc.
In the end, I find that resolved's approach at symlinking its stub resolv.conf is the most elegant approach with our current setups.
PS: I talk a lot about resolved because that's the one I know best, not the one I think is the best! It has loads of shortcomings too, yet it's still a net improvement to whatever was in place before.
Replies
> DNS is a complex topic. Much more complex than people admit it is, and that can definitely not be expressed fully with resolv.conf. I do agree that it is too late to get rid of it (and was not my concern actually), but it is too limited to be of actual use outside of the simple "I have a single DNS server with a single search domain".
resolv.conf is limited, but it's also been highly stable for decades, and it's sufficient if not ideal for controlling how getaddrinfo works (at least for on-the-wire requests), including controlling things like EDNS0, parallel requests, etc. Most if not all libc resolvers support things like parallel querying and other simple knobs which are configurable (if at all--see musl libc) through resolv.conf, demonstrating that it's expressive enough for most if not all common requirements shared among various client-side stub resolvers.
> And for more complex cases, simple integration with the network configuration daemon
But which one? Are you suggesting integration by way of loading it's configuration(s) (which puts us back at square 0), or by a modified query protocol, or by interfacing with the broader but even more diverse native configuration systems? None of the options seem remotely practical from the perspective of most open source projects, unless they're specifically targeting a single environment like Linux/systemd/resolvd. I don't see a viable pathway to make that happen. By contrast, embracing and hopefully improving resolv.conf as an integration point could be done piecemeal, environment by environment. The syntax is already effectively universal across systems, with the options directive providing most of the knobs. We could even make an initial push through POSIX by officially standardizing the syntax, which may even convince musl libc to make its resolver actually configurable.
> In the specific example of resolved, I'd argue it's even less work for applications, because they don't need to query multiple DNS servers at once (it'll handle it for them), don't need to try resolution with and without search domain, etc.
Yes, in most cases it's sufficient for userland applications to just make simple requests to the locally managed resolver service defined in resolv.conf. But the cases and projects needing more control over how they do their requests, using their own resolvers, only grows, especially with the proliferation of DNS schemes-see, e.g., the various recent HTTP-related DNS records which often require multiple queries and can benefit from parallel queries managed internally. A prime example is getaddrinfo itself, some implementations of which do parallel queries for A/AAAA lookups. Which brings us back to my main point: resolv.conf is the only common centralized point across almost all environment (Windows being the major exceptoin) for configuring basic DNS services.
I'm not arguing for improving resolv.conf integration as a way to replace local DNS services or their configuration. Just that for decades the staleness of resolv.conf has been a conspicuous and growing pain point from both a system configuration and userland integration perspective, and a little coordinated love & attention across the ecosystem, if only firmly committing to what's already there (especially for glibc and FreeBSD) as a reliable and more easily leveraged source of truth for code that needs it, would go a long way.
Yet despite using systemd installing Tailscale on Manjaro and other Linux’s still can’t handle integrating with MagicDNS without some hackery.
So far tailscale magicdns just works on FreeBSD.
I second that systemd is great, for services. Anything beyond that? Just a gargantuan opaque buggy overreach.