Am I the only one who is getting fed up with everything under the sun having their own DNS resolver and DNS cache? It's border-lining madness right now.<p>Before you had a situation like this. ISP: Server and cache. Router: Client, server and cache. OS: Client and cache.<p>So if you ever encounter DNS failing, you only had 3 possible places to look for errors, or maybe not even errors, just stale data that may or may not correct itself over time. Flush the caches you can and hope for the best. Rinse and repeat.<p>But then came the browsers and decided that 3 levels of caching was good enough. Let's add more which can fail in the name of performance!<p>Combine this with mobile, mobility and data-roaming and now you not only have a DNS-cache (based on already tripple-cached data) which often is guaranteed to be wrong, your browser may actually have cached the wrong DNS-servers, so when you roam from Wifi to cell-data your precious LAN DNS servers are no longer available and your browser just looks stupid.<p>And now systemd adds to this. What the flying <i>fuck</i>?<p>All this nonsense because someone somewhere decided that a nice, shared, global OS level client and cache wasn't good enough. Handling this complexity once would just be <i>too easy</i>.<p>Can someone tell me why? Why wasn't it good enough? What was it that prompted someone to go reimplement all this wrongly, yet again?<p>Yes this is a rant, but if there are underlying technical reasons for this nonsense, I'm very, very interested to hear about it.
I find the design of systemd-resolved to be very strange. It uses dbus to talk to glibc, and it seems to be a new, from-scratch implementation of a DNS resolver. To be clear, I don't really think it matters whether systemd-resolved is under the systemd umbrella, but I do think that the design has a lot of unnecessary NIH syndrome.<p>It turns out that there's a very well-specified protocol by which clients can ask a local cache on their system to answer DNS queries. That protocol is called DNS :) I don't see why routing something DNS-like over dbus makes any sense in contrast to doing it using DNS itself on port 53.<p>Fedora is experimenting with running unbound as a local caching resolver [1]. This gives caching, DNSSEC validation, and all the benefits from the fact that unbound is probably much better hardened than the average libc or application-side DNS client implementation.<p>[1] <a href="http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations" rel="nofollow">http://fedoraproject.org/wiki/Features/DNSSEC_on_workstation...</a>
This is a perfect example of why the systemd approach of putting a bunch of disparate components under a single tightly-coupled umbrella is bad engineering. Generally, projects focused on doing one thing are able to do it well, while projects that attempt to do many things have a hard time doing any of them well. Unfortunately, as the steady stream of cache poisoning vulnerabilities in other DNS servers have demonstrated, implementing DNS securely is <i>really hard</i>. A less-than-perfect attempt at implementing a caching DNS resolver <i>will</i> be insecure. For this reason, it's a task best left to a mature project run by people with DNS-specific experience who can focus on doing that one thing well.
Pretty weird for Systemd to have its own cache and resolver. If you need a local resolver and a cache simply run a local DNS server rather than to re-invent the wheel (in a broken way at that). I'm sure they have their reasons but this is not the unix way.
Interesting background discussion here for those wondering why systemd has its own DNS resolver: <a href="https://news.ycombinator.com/item?id=8203080" rel="nofollow">https://news.ycombinator.com/item?id=8203080</a>
The submitter doesn't state affected versions, but judging from systemd's NEWS file, the resolved component was first introduced in 213 and later dubbed as "a pretty complete caching DNS and LLMNR stub resolver" in 216: <a href="http://lwn.net/Articles/609740/" rel="nofollow">http://lwn.net/Articles/609740/</a><p>Considering most users run on a backported 208-stable IIRC (I know RHEL 7 settled on that), I'm not sure how widespread this is. Still concerning that they felt to roll their own and not follow RFC guidelines, though.<p>Considering how plagued with vulnerabilities BIND was, I'd assume DNS is a hard thing to do.
Of all the components of systemd that doesn't need to exist, resolved is definitely one of them. Why they're reinventing the wheel rather than allowing the user to set up something that works and is battle-tested, such as unbound, is beyond me.
Caches are bugs waiting to happen.
Rob Pike @rob_pike 21 Mar 2014<p>By the same author<p>"There's no such thing as a simple cache bug."<p>"Caches aren't architecture, they're just optimization."
Systemd... a very large mass of c code being written in a short amount of time with huge functionality creep. Yeah, this is going to end/begin really well. I swear all of the people commenting about it being a good thing are not seasoned developers.