If you could create a browser plug in that would requery accurately and only on the domains that you wanted, you'd still be leaving a trail. I have thought about masking traffic, but the only thing that gets you is that now instead of whomever you believe is watching your traffic seeing you visit one site, they see you visit six sites. You're not getting rid of that true query, and any semi-professional analytics routine will see that you visiting
google.com aiusne.kl jaifijaiiena.net and
whoopwhoop.theritis is going to know the real from the fake. You're not trying to block your traffic from the local hacker consortium, you're trying to mask your traffic from a Governement Actor, and you lose, everytime, all the time.
Now, lets dismiss that argument, and look at local caching of an entire TLD. A look for today at http://www.dailychanges.com shows that for the .COM TLD there was the following:
.COM NEW 136,169 DELETED 130,344 TRANSFERRED 209,116 TOTAL 128,130,769
So, you'd have to account for that. (That's just domain names, doesn't take in to consideration the number of DNS record changes, but that's a really hard number to nail down so I just went with the number of domain transactions which would require changes to DNS SOA records.)
I totally agree that users need to be in control of their information, and have some say to whom it is provided and released. That's why I donate my time to the Pi-hole project.
Automating the setup of your own upstream isn't something I'm looking to do, as I don't want to contribute to the proliferation of unsecured resolvers ripe for abuse. And doing the encryption and certification properly isn't something you should be scripting. I know there are instructions on how to do it, and there are scripts on how to do it, but it's a big no-no to leave the CA on the same device that is authenticating the clients. Compromise the CA and the whole house falls in on you. Scripts that just have you create a CA without explaining the ramification of that process are failing the users. False sense of security is worse than knowing you are running in the open. But if you know what you are doing, and use wise security practices, you could tweak something like GitHub - jedisct1/dnscrypt-server-docker: A Docker image for a non-censoring, non-logging, DNSSEC-capable, DNSCrypt-enabled DNS resolver and use that as a base to a setup that is as secure as a non-governement entity would be able to run.
So, know your enemy. And know as much as you can about their capabilities and then you know how to start to plan your approach. And as always, Pi-hole is NOT a security product, for that you need other software.