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.
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.