Wondering if it's worth the effort to set up the unbound configuration or just use Quad9 as the resolver for anything that's not in the pi-hole list? What are the benefits and drawbacks of each of these approaches?
Hi. I'm on the board of the Quad9 Foundation, so can generally answer questions about how Quad9 works. I've also built a lot of smaller or personal-use recursive resolvers (like you're contemplating with Unbound) over the years. Functionally, of course, in the big picture, Quad9 and Unbound are both recursive resolvers, so the question is fundamentally whether to run your own or use a shared one.
The benefits and drawbacks can probably best be evaluated in terms of privacy, security, and performance.
From a privacy point of view, as others will always point out, DNS alone can't solve problems, it's one element of an overall solution. You can't have privacy if you're broadcasting your queries, but you also can't have privacy if you're sending subsequent traffic in the clear, or accepting cookies or loading ads or whatever. So, assuming that you're also working on other aspects of protecting your traffic's privacy, the DNS portion can best be kept privacy by (a) encrypting it against inspection while in flight and (b) minimizing the number of parties seeing each query. There's a more complex issue around DNS-over-TLS (good) and DNS-over-HTTPS (bad), but that's a story for another day, if anyone cares. So, if you use DNS-over-TLS ("DoT") between your stub resolvers (the ones on your devices) and the recursive resolver, and your TLS stack has done a reasonable job of ensuring that it's talking to the recursive resolver you think it is, then you only need to worry about the privacy of queries on the other side of that link. By maintaining a large cache in your stub resolver, you can minimize the number of queries that go to the recursive resolver, but you can't change the number of unique queries. So it really pays to understand the motivations and economics of the party with whom you're sharing all of your activity. If we didn't think this was a particularly fraught problem, we as a community wouldn't have put all the effort into setting up and maintaining Quad9 that we have. So, read the privacy policy, and look for weasel-words: does it say that they only keep the "raw data" for a period of time? Then it means that they keep the "raw data" long enough to boil it down to something more compact and salable. Does it say that they don't share it with unassociated or external parties? Then ask who the "associated" or "internal" parties are, and what they do with it, who they share it with, and what their privacy policies are. But policies are just policies... The only thing that really gives any of this teeth is criminal law. What, if any, criminal law binds the recursive resolver and its corporate or human operators? If it's incorporated in the U.S., the answer is "none." Ironically, if the business model of a recursive resolver is data-sales, a lot of practices which seem like they're privacy-protecting are actually just there to drive up the value of the data by minimizing the number of parties selling it. Extended Client Subnet, for instance, is really bad, and you should not use a recursive resolver that passes it unless you
really understand what you're doing and why you think it's necessary. For a recursive resolver that does not collect data in the first place, also not passing the ECS data to authoritatives (and everyone on the path) is a win. But when the business model of the recursive resolver is monetizing queries, they're just reducing the number of competitors who can sell your data, to drive the price up. Likewise query-minimization, which means only passing the minimal necessary information to each authoritative resolver. Good practice, and if you were running your own recursor, you'd definitely want to turn it on. But in the hands of a commercial recursive resolver operator, it just reduces their competition and increases their profits, it doesn't actually provide you with improved privacy.
As regards security, the DNS is sometimes used as a first line of defense in a layered defensive strategy. By blocking responses which would lead a user (or their devices or software or agents or proxies) to harm, the DNS can be used as a tool to frustrate many classes of attack, such as phishing, malware drive-bys, stalkerware, et cetera. You can do this yourself, in a recursive resolver that you operate, by aggregating threat intelligence data from many sources, and curating it. Removing things when they're outdated, and fixing false-positives. Quad9 does this, aggregating roughly thirty threat intelligence sources, tracking false-positive reports and resolving them, resulting in a block-list of about four million domains at any given time, with a churn of roughly 10%, or 400,000 new domains added each day, and a like number removed. The result is a block rate of about 97% - 98% of malware, as tested by independent labs. It's relatively easy to get to 10%. With a little bit of work, you can get to 50%. 98% is relatively difficult, and at that point, much of the work is in identifying and clearing false positives, and making sure the list doesn't grow full of cruft. So, if you're going to use the DNS for malware blocking, Quad9 does a lot of that work for you, but there's no secret sauce... You could, hypothetically, come to the same arrangements with threat intelligence analysts that Quad9 has. It's just a matter of leg-work and convincing them that it's in the public interest. Which is a lot easier if it benefits hundreds of millions of people than if it benefits just you individually. One thing Quad9 doesn't do right now, and isn't on the near-term horizon, is ad-blocking. So a lot of people use something like Pi-Hole as their caching/forwarding resolver (ideally with a big local cache), feeding it with ad-blocking data, and then pass cache misses to Quad9.
As regards performance, the main thing to remember is that differences much below 100ms can't really be distinguished by people. So the difference between a resolver that takes 20ms and one that takes 30ms really isn't going to change your life. But the difference between a resolver that's available six-nines versus one that's available two-nines is pretty noticeable. So looking at topological nearness and uptime is probably much more informative than looking at latency. Though latency can be a good warning of topological problems, particularly when you see a step-function change for the worse.
Happy to expand on any of this if it's useful.
-Bill
Facebook
Twitter
Instagram